Verification & Validation

1. Verification & Validation

2. Possible Topics • TPM Specifications • TPM Protection Profile • TPM Compliance Specifications • The Compliance of Specific TPMs • Platforms • Virtual TPMs • Systems incorporating TPM platforms

3. Possible Topics • TPM Specifications • TPM Protection Profile • TPM Compliance Specifications • Specification Compliance of Specific TPMs • Platforms • Virtual TPMs • Systems incorporating TPM platforms Functional & TCG Issues At present a requirements/specification rather than V&V problem

4. TPM Specifications

5. Status • Knowledgeable design. • Limited validation: individual protocols (Math behind DAA) or limited sub-sets; work (BSI) started on certified migration protocol.

6. Questions • Does the Protection Profile reflect the complete security requirement of a TPM? • What are the critical security properties or concerns? • Are there usage modes (combinations of messages, unexpected interleaving etc) that break critical properties? • How much does the scope for different implementations vary the strength of security mechanisms offered? • Should the current scope for product differentiation be further constrained by security concerns?

7. Security Concerns - Protocols • Set PCRs to zero, or chosen value • i.e. not from trust root or designated locality • Via TPM commands, locality mechanisms, system reset. • Copy EK or AIKs into different platforms. • Reset/Roll back monotonic counters. • Fail to fully restore cached state • e.g. mix different states. • Deadlocks due to caching. • Inappropriately give (or fail to give) success report. • Obtain inappropriate privilege via delegation.

8. Security Concerns - Other • Are the underlying crypto algorithms consistent with good practice for the relevant crypto processes? • Are some commands particularly sensitive to implementation variations: • E.g. poor random number generation. • Re-ordering of actions within a command (this is a property of some implementations). (These concerns may apply equally to specific TPMs; since implementations will manage memory, buffers etc.)

9. Platforms and Systems

10. Platforms • A TPM on its own is not a system component – needs to be composed with minimum platform functionality; e.g: • Trust root: trusted boot. • Virtualisation supported by memory protection. • Worry: is this already too big for most types of analysis?

11. Platforms - Questions • What properties do we need of the components to make a secure (what does this mean?) platform? • Do we need all the TPM, or is there a subset of functionality or security that is critical? • If the distribution of protection mechanisms between hardware & software is different, how does that change the (flavour) security profile/strength of mechanism.

12. Security Concerns • Is it possible to modify or export TPM state, via: • The functionality of other devices integrated with the TPM (e.g a USB controller); or • Vendor specific TPM commands? • Are there formats of platform credential that are inadequate (e.g. are unlikely to be correctly interpreted)? • What are the essential process requirements for granting a platform credential? • Is the integration of the TPM and the platform sound: • A TPM must be bound to a single platform. • The Platform must correctly implement the root of trust & also locality.

13. Systems - Questions • How do we describe a platform/TPM at the system level: what is abstracted & what retained? • How do we relate these components to risk? • ‘Know everything v know nothing’ models for privacy the CA – what are the detailed pros & cons and correct balance in different scenarios?

14. Summary • It is unlikely that the TPM protocols will be ‘broken by inspection’. However • There is considerable scope for further analysis, and this is likely to inform how such systems are used, protected and assembled. What Next • Interest group - Email hrchivers@iee.org