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

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