Verification Validation Possible Topics TPM Specifications TPM Protection

Verification & Validation

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

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

TPM Specifications

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

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?

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.

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

Platforms and Systems

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?

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.

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.

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?

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