1. Verification & Validation

2.  Validation  are we building the right product?  Verification  are we building the product right?

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

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

5. TPM Specifications

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

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

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

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

10. Platforms and Systems

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

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

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

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

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