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

2. 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

3. 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.

4. “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

5. Hypervisor with TrustZone™

6. 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

7. 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

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

10. Questions?

11. Backup

12. Operational trust

13. 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:
C Country
ST State
L City
O Organizational name
OU Organizational Unit name
CN Domain name

14. 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.

15. 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:

16. 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 4043.
X509v3 Extended Key Usage:
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.