Trusted? 05/4/2016 Charles Sheehe, CCSDS Security Working Group GRC POC All information covered is from public sources 1

University Illinois Urbana designed malware in hardware with 406 gates. ₁ They did not modify the hardware in any way. No modification of gate structures etc.. Stuxnet was specifically designed to affect two Supervisory Control And Data Acquisition (SCADA) controllers.₂ SCADA is a system for remote monitoring and control that operates with coded signals over communication channels Siemens 315 and 417 controllers only. Was a timing attack like the ones created by the students and it created a man in the middle attack. This security issue can not be patched and only can be controlled by employing a sound security architecture. ₁Designing and implementing malicious hardware by King, Samuel et. All ₂ Stuxnet: Dissecting a Cyberwarfare Weapon, by Ralph Langer

What is needed for trusted computing Strong Process Isolation Memory isolation Process isolation/separation Sealed Storage Data bound to an environment TCG Storage Opal 1.0 specification for the self-encrypting hard drives. Secure I/O No keyboard sniffing Attestation Ability to verify the operating environment (Doing what it is suppose to be doing) Attestations by the TPM and Platform Attestation digitally signed using various TPM bound and Platform-bound certificates. Provide unique, unspoofable identity to the embedded system that incorporates a TPM. Participate in integrity measurement services upon the firmware and software in the embedded system and store the results of measurement for subsequent reporting.

“Platform” Trusted computed Access to credentials shall be designed to be assurance that the “Platform” is operating with the certified software system with which it was designed. For example, storage of this certificate, and any needed boot assurance required for certification, may be done using a Trusted Platform Module, a Secure Element, an ARM TrustZone, or other similar technology

Hypervisor with TrustZone™

Architecture for trusted computing Secure embedded system hardware design. A flexible security and trust enhanced approach by, Apostolos P. Fournaris a,b,., Nicolas Sklavos b

Build Trust Chain A Device Manufacturer CA serves as the trust anchor for certificates used by Device Manufacturers. Device Manufacturer certificates will be used to cryptographically sign various manufacturing parameters to be verified by service providers. Device Manufacturer CAs shall generate and maintain their keys under auditable conditions. Device Manufacturer CAs shall follow all operating procedures required by the Webtrust Principles and Criteria for Certification Authorities 2.0

Build Life cycle trust Protection Profile PC Client Specific TPM TPM Library specification Family “2.0” Level 0 Revision 1.16 January 19, 2015 Version 1.0

Questions?

Backup

Operational trust

Certificates trust chain Certificates should follow the web PKI structure in these details: Issuer: This data element should be formatted identically to the way web PKI structures the “Issuer” element: as a record reflecting the identity of the CA. These fields are present: CCountry STState LCity OOrganizational name OUOrganizational Unit name CNDomain name

Certificates continued Subject: This data element carries the same format as the “Issuer” element, and the same fields. It represents the identity of the subject to whom the certificate is issued. CAs signing certificates shall ensure that the O, OU, and CN fields reflect the identity and that the C, ST, and L fields (if present) reflect the legitimate location of signed certificates.

Web PKI trust chain Web PKI certificates contain several other X.509 data elements which correspond to capabilities or attributes of the certificate. Version Serial Number Algorithm ID Validity Not Before Not After Subject Public Key Info Public Key Algorithm Subject Public Key Issuer Unique Identifier (optional) Subject Unique Identifier (optional) Any extensions with defined meanings in the web PKI (optional) When these X.509 data elements (and any other common certificate metadata which may added in subsequent versions of Transport Layer Security (TLS)) are present, they have the same meaning as they do in the web PKI. X.509 extensions which have the same meanings as in the web PKI:

X509v3 Certificate Policies: If present, this policy should refer to a number managed under the IANA Private Enterprise Number (to be applied for if it does not already exist), and which refers to particular specifications of certificate policies. X509v3 Key Usage: If present, this data element contains information on the use of the certificate. X509v3 Subject Key Identifier: If present, this data element contains the hash of the key for the subject of the certificate. X509v3 Authority Key Identifier: If present, this data element contains the hash of the key for the CA issuing key. X509v3 Subject Alternative Name: If present, this data element contains the domain name (DNS name) corresponding to the subject of the certificate. This extension may also contain permanent identifier descriptors as in RFC X509v3 Extended Key Usage: If present, this data element contains information on the use of the certificate. In addition to the web PKI standard extensions, entities can make use of an additional extension. This extension is rooted in a Private Enterprise Number from IANA granted to the CA..x extensions: These sections are custom extensions within the X509 extension system. They will be defined as being strings comprised of string field names and values.