1. Re-envisioning of the TPM

2. Where are TPMs today?
Over 1,000,000,000 shipped machines with TPMs in them
All business class machines (except Apple)
Used by Bitlocker
Most are not turned on
Hard to turn on (BIOS controlled)
Not FIPS (yet)
SHA-1 is integral in design (expires end of 2013)
TPM 2.0 fixes the problems
Required for MS 8.0 phones / tablets

3. Outline How TPM 1.2 and 2.0 are the same
How TPM 1.2 and 2.0 are different
Algorithms
Hierarchies
Extended Authorization
PCR Brittleness
Sessions
Working with the Spec
New Use Cases

4. How TPM 1.2 and 2.0 are the same

5. Comparison of capabilities (10,000 feet)
Capability
TPM 1.2
TPM 2.0
Root of trust for storage
Yes
RNG
Secure Key gen
Secure Key store
NVRAM
Attestation
Anti-hammer
RTS – can keep root keys stored, which in turn can store other keys kept outside the TPM
RNG = Random number generator
Secure Key gen – knows how to create RSA, ECC, and AES keys
Secure Key store – can store keys encrypted with the RTS, or in NV on the device (if there is enough room)
NVRAM – Non volatile random access memory
Attestation – PCRs + signatures
Anti-hammer – if you try too many times to guess a password, you go to time out.
So what is the difference?

6. How TPM 1.2 and 2.0 are different

7. Differences are architectural (Code size reduced by almost a factor of 2)
Architecture
1.2
2.0
Algorithms
Fixed: RSA2048/SHA-1
Any: RSA/ECC SHA-1, SHA-2, AES
Anti-hammer
Principles enacted
Architected: Leaky bucket
Authorization
HMAC, PCR, Physical presence
Extended Authorization (more about this in later slides)
Different for different objects in a TPM
Unified
Difficult to revoke keys
Relatively easy to revoke keys
Difficult to manage – owner_auth conflated with privacy authorization, TPM management, anti-hammering management
Easy to manage – authorization is separated out by what is being managed. Principle of Least Privilege followed

8. Differences are architectural
Architecture
1.2
2.0
Manageability
Difficult
Always “on”
NVRAM
Fixed
Can be used for counters, PCRs, authorization, storage
Object references
By pointer
By name (no substitution attacks possible)
Side channel attacks
HMAC protected SRK
Keys checked on loading before they are used; new forms of authorization;
Types of keys
Fixed types (AIK, signing, Binding, etc.)
Flexible types (But you can still make keys with 1.2-like behavior)
FIPSable
Yes (level 1)
Yes (level 2)
PCRs
Brittle
Easily managed
Single Sign On
Easy
SRKs
One, RSA 2048
As many as you want, you pick the algorithm
HMAC
Not available
Available

9. Command family comparison (some 1
Command family comparison (some 1.2 functions not included as seldom used)
Command Family
Number of Commands 1.2
Number of Commands 2.0
Self test 3
Sessions
0 (in TPM mgmnt) 2
Key management 14
10 (EA reduction)
Key use 7
9 (symmetric keys)
Random Numbers
Hash / Hmac
3 (Hash only) 8
Integrity Collection and Attestation 11 10
Authorization
18 (EA)
TPM management 33 28
Clocks and Timers
2 (timer only) 4
Non Volatile memory management
14 (new functions)
Total 92
108

10. Algorithms

11. Algorithm Differences
Algorithm flexibility
1.2: ONLY RSA (512, 1024, 2048); SHA-1; NO exposed symmetric
2.0: Any Asymmetric, hash, or symmetric algorithm
Need to be approved by Technical Committee, Platform spec
Right now this means:
RSA / ECC (curves under discussion)
SHA-1 / SHA-2 (Russian, Chinese algorithms also likely)
AES (GOST, SMS4 also likely)
Accessible symmetric encryption
1.2: Not available (export concerns)
2.0: Available in specification. May or may not be in Platform specs
Encryption / Decryption / HMAC (signing)

12. Symmetric Keys Bulk encryption May or may not be required by PC Spec
Can be created as root keys
HMAC signing
Used for key storage (when not duplicating)

13. Hierarchies

14. Multiple Hierarchies One hierarchy for platform manufacturer
For use by BIOS and SMM –only-
Uses new authorization re-created at each boot
Likely contains permanent keys– not to contain user info
Privacy Hierarchy
Endorsement key control
Can have as many endorsement keys as you like
Can have as many keys below it as you would like
Storage Hierarchy
Can have as many SRKs as you like
Null Hierarchy
For use of TPM as crypto accelerator
Hierarchy disappears on TPM reset

15. Seed based hierarchies
Random number seed for each hierarchy
Primary keys (SRK like, EK like) derived with KDF
Use key description, seed as input to KDF (Key Derivation Function)
Can add a salt if you wish
Primary keys can be re-generated or loaded in NV
If loaded in NV, they act like the 1.2 EKs or SRKs
Handle picked by end user, not generated by TPM
Multiple EKs, SRKs, allowed (like TPM 1.2 owner-evict keys)
Limited NV likely available
Seeds may be replaced from RNG
Automatically evicts derived keys from NV
Destroys hierarchy

16. Quick break for questions before EA

17. Authorization 1.2: Everything a special case
Keys: Authorized with HMAC, PCRs, Locality, Delegation table
Authorization data changeable for use, but not migration
NVRAM could use owner_auth or different auth, PCRs, Locality
TPM functions – some owner_auth, some physical presence
Certified migratable keys – complicated authorization, including signatures
2.0: Everything unified
Many new kinds of authorization
Any can be used with any kind of entity

18. Extended Authorization You can make as simple or as complicated an authorization policy for an object as you wish.
Type
Example
Use case
Password
“cat”
Entered during BIOS boot, from trusted path
HMAC
Using SHA256
Entered from remote device
Private key
CAC card
Administrative features
Private key plus data
Signed biometric
Identify fingerprint + reader it came from + freshness
Private Key plus data
Location
GPS location + GPS identity + freshness
Counter
When 1<counter<6
You can use this key exactly 4 times
Timer
200<timer<600
You can use this key for the next 400 seconds
Clock
Clock<1:30 12/21/2012
You can use this key until 1:30 12/21/2012
Command
Signing data
Restricting user rights
Copy
Making copy of key
Restricting administrative rights
Copy to target
Copy to a particular TPM
Backup

19. Extended Authorization (continued You can make as simple or as complicated an authorization policy for an object as you wish.
Type
Example
Use case
Authorize different object
Link objects to use the same authorization
Single Sign on
PCR
When PCR 0= ….
You can only use this key if you booted correctly
Locality
When command comes from approved location
Intel / AMD virtualization modes
DRTM (New localities: )
Signed Policy
When an approved policy is met
You can only use this key if the Dell system booted from a BIOS signed by DELL as shown by PCR 0
AND
Require multiple authorizations
Multi-factor authentication OR
Allow different authorizations
Bob OR Sally OR Bill can use the object

20. Mix and match Bob authorizes with a password and CAC card
Sally authorized with her iris scan and CAC card
Bill authorized with his fingerprint, iris scan and password
Policy: Bob, Sally OR Bill can use this key.
Use case: I create a policy called work_backup and another called work_Nobackup
Me: authorize with CAC card and password
IT: authorized with CAC card and iris scan.
Work_backup = Me –OR- IT
Work_Nobackup = Me

21. Policy is represented by a single hash
Things to keep in mind:
Order *is* important
In order to construct a policy, you must know all branches
In order to fulfill a policy, you must additionally know the branch you are going to take.
Policies look like a logical circuit diagram
Policies are built sort of like PCRs OR
AND

22. Policy is represented by a single hash
Build a policy for : Bill
Bill is authorized by
a CAC card with public key A,
an HMAC
and PCRs of the system being in a particular state.
CAC card
AND
HMAC
Authorized
PCRS

23. A more complicated policy
A Policy built for Bill OR Sally
Bill’s CAC card
AND
Bill’s HMAC
PCRS OR
Sally’s CAC card
AND
Sally’s biometric
PCRS

24. A Policy Hash with a single authentication based on a signature
Authentication with a CAC card with public key A
Always start with all zeros (32 bytes of zero for SHA256) = P1
CAC card authorization is represented
P2= SHA256( P1|| TPM_CC_PolicySigned1 || SHA256(A) || label2)
= SHA256(0x || TPM_CC_PolicySigned1 ||SHA256(A) || NULL)
= SHA256(0x || 0x || SHA256(A) || 0x0000)
Final Policy = P2
1 We look up TPM_CC_PolicySigned in Table 10 in Part 2 (Structures) Section 6.5.3
of the spec and find it equals 0x
2label is a reference so you know what you are authorizing.

25. Details of calculating the Policy Hash with AND CAC card AND HMAC AND PCRs
Always start with all zeros (32 zeros for SHA256) = P1
CAC card authorization is represented
P2= SHA256(P1 || TPM_CC_PolicySigned || SHA256(A))
CAC and HMAC is represented by
P3= SHA256(P2 || TPM_CC_PolicyAuthValue )
CAC and HMAC and PCRs is represented by
P4 = SHA256(P3 ||TPM_CC_PolicyPCR || pcrs || digestTPM)
CAC card
AND
Authorized
HMAC
PCRS
Final policy = P4
AND is done with a kind of hash extend –like a PCR.

26. Details of satisfying this policy
When you try to satisfy this policy you will do as follows:
Step 1: Create a Session.
The session will establish a policy buffer.
The buffer starts out with 32 bytes of zeros in it = P1
The session returns a nonce
Step 2:
Sign the nonce with the CAC card. Send the TPM a note:
I am doing a TPM_PolicySign, here is the public key, here is the nonce signed with the corresponding private key
TPM verifies the signature, then extends TPM_CC_PolicySigned, P1, and the hash of the public key into its policy buffer.
The policy buffer now contains P2

27. Details of what this policy means (continued)
When you try to satisfy this policy you will do as follows:
Step 3: Tell the TPM you will be using an hmac to authorize an object.
The TPM extends TPM_CC_PolicyAuthValue into the policy buffer.
The policy buffer now equals P3
The TPM also sets a session HMAC flag that an hmac will be required for any executed command.
Step 4: Tell the TPM you want it to extend certain specific PCR indexes
into the session policy buffer.
The TPM extends TPM_CC_PolicyPCR, PCRs, digest of those PCRs
The policy buffer = p4
The TPM sets a session PCR flag =0.
If PCRs change now, the PCR flag will be incremented.
Step 5: execute a command with an object.
(Must include HMAC with command that uses the same authorization
data as is in the object – because of the HMAC flag. )
TPM checks the HMAC is correct
TPM checks that the PCRs have not changed (PCR flag=0)
TPM executes command

28. In pictures: Authenticate with a CAC card
Start session
TPM
Sign nonce, label with CAC card
Session Policy Buffer
Send signature to TPM
for verification. 0x 0x
TPM calculates P2
Signature
Session nonce “N” N N
N=0xBB443FE5
SHA256 (0x || TPM_CC_POLICYSIGN|| SHA256(A) ||0x01)
0xA3B62234
CAC public key
A=1011……………..1+label (0x01)
label
Signature Verifies!
Note: Signature includes label

29. In pictures: Authorizing with a CAC card policy
Load Signing Key (not shown)
TPM
Ask TPM to sign “Hello” with Key
Session Policy Buffer
0xA3B62234 0x
0xA3B62234
TPM checks if policy Buffer matches key Policy
If they match, it produces the signature
Signing Key policy = 0xA3B62234
Signature of “Hello”
“Hello”
Key Policy matches Buffer!

30. In pictures: Authenticate with a CAC card and PCRs
Start session
TPM
Sign nonce, label with CAC card
Session Policy Buffer
Send signature to TPM
for verification. 0x 0x
TPM calculates P2
Signature
Session nonce “N” N N
N=0xBB443FE5
SHA256 (0x || TPM_CC_POLICYSIGN|| SHA256(A) ||0x0000)
0xA3B62234
CAC public key
A=1011……………..1+label (0x0000)
label
Signature Verifies!
Note: Signature includes label

31. In pictures: Authenticate with CAC card and PCRs
Tell TPM to record current PCR 0,2,4,8 and 12 values
TPM
Session Policy Buffer
TPM pulls current PCR digest, calculates new policy buffer value
0xA3B62234
TPM establishes PCR state variable in session, sets it equal to zero.
SHA256 (TPM_CC_POLICYPCR|| 0xA3B62234 || PCR || digest)
0x0EE51220
TPM replaces session buffer with new value.
PCR state = 0
Certain PCRs can be configured in the TPM to not trigger a PCR state change

32. In pictures: Authorizing with a CAC card and PCR policy
Load Signing Key (not shown)
TPM
Ask TPM to sign “Hello” with Key
Session Policy Buffer
0x0EE51220 0x
TPM checks if policy Buffer matches key Policy
If they match, an PCR state=0, it produces the signature
Signing Key policy = 0x0EE51220
Signature of “Hello”
“Hello”
Key Policy matches Buffer!
PCR state = 0

33. Signing Key policy = 0x0EE51220
In pictures: What happens when a PCR changes after authentication, before authorization?
PCR 0 is changed
Load Signing Key (not shown)
TPM
Ask TPM to sign “Hello” with Key
Session Policy Buffer
0x0EE51220 0x
TPM checks if policy Buffer matches key Policy
The policy Buffer matches the key’s policy, BUT PCR state is not 0! Therefore it does NOTHING.
Key Policy matches Buffer
PCR state !=0 FAIL!!!
Signing Key policy = 0x0EE51220
“Hello”
PCR state = 1
PCR state = 0

34. A simple “OR” example: Matt OR Kathy
Matt can authenticate with his CAC card, with public key A
Kathy can authenticate with her CAC card, with public key B
Matt authenticating looks like:
Start with all zeros (32 zeros for SHA256) = P1
CAC card authorization is represented
P2= SHA256(P1||TPM_CC_PolicySigned || SHA256(A)||label)
Kathy authenticating looks like:
Start with all zeros (32 zeros for SHA256) = P1
CAC card authorization is represented
P3= SHA256(P1 || TPM_CC_PolicySigned || SHA256(B) || label)
Matt OR Kathy policy: authenticating looks like:
P4 = SHA256(P1||TPM_CC_PolicyOr || 0x ||0x0020||P2 || 0x0020||P3)

35. SHA256 (0x00000000 || TPM_CC_POLICYSIGN|| SHA256(A) || 0x0000)
Matt Authenticates with his CAC card P2=0xA3B62234, P3=0xD , P4=0x667FFE34
TPM
Start session
Sign nonce, label with CAC card
Session Policy Buffer
Send signature and A
to TPM for verification. 0x 0x
TPM calculates P2
Signature
OR command sent
With P2, P3
Session nonce “N” N N
N=0xBB443FE5
TPM sees current value
matches P2!
OR, 0xA3B62234, 0xD
SHA256( P1||TPM_CC_PolicyOR||0xA3B62234||, 0xD )
SHA256 (0x || TPM_CC_POLICYSIGN|| SHA256(A) || 0x0000)
0xA3B62234
0x667FFE34
CAC public key
P2 = 0xA3B62234!
A=1011……………..1+ label (0x0000)
label
Signature Verifies!
TPM Calculates P4 and replaces buffer with P4

36. SHA256 (0x00000000 TPM_CC_POLICYSIGN|| SHA256(B) || 0x0000)
Kathy Authenticates with her CAC card P2=0xA3B62234, P3=0xD , P4=0x667FFE34
Start session
TPM
Sign nonce with CAC card
Session Policy Buffer
Send signature and B
to TPM for verification. 0x 0x
TPM calculates P3
Signature
OR command sent
With P2, P3
Session nonce “N” N N
N=0x811662BA
TPM sees current value
matches P3!
SHA256(TPM_CC_PolicyOR||0xA3B62234||, 0xD )
SHA256 (0x TPM_CC_POLICYSIGN|| SHA256(B) || 0x0000)
0xD
0x667FFE34
OR, 0xA3B62234, 0xD
CAC public key
P3 = 0xD !
B=1101……………..1 label=0x0000
Signature Verifies!
TPM Calculates P4 and replaces buffer with P4

37. Atomic authentication of PCRs
In 1.2, PCRs were measured at the point a command was executed.
In 2.0, PCRs are measured as part of the establishment of a session policy buffer.
Isn’t this a problem?
NO! When the PCRs are measured, a bit is created in the policy and set to zero. If –any– PCRs change after that point, the bit is flipped.
If the bit is flipped, the command won’t execute.

38. How can you put an HMAC in a policy?
The session doesn’t know what object you are going to authorize.
If the authdata is part of the policy, that exposes information about the authdata.
Isn’t this a problem?
NO! The policy just says “I will authorize with HMAC at execution”
If the bit is flipped, the command won’t execute unless it is provided an HMAC corresponding to the authorized object at execution.

39. Can’t anyone replace a biometric sensor?
Aside from spoofing attacks, how do I prevent someone replacing my fingerprint reader with an identical model which they take ownership of?
The Biometric sensor must have a public / private key pair, used to sign both the identified person, and the session nonce

40. Some additional comments
Policies can be created and calculated without talking to the TPM
Policies can be re-used
Policies can be broad: “Matt can do anything he wants with this key” OR

41. Policies can be Fine grained
“Matt can sign with this key, but only Emily can copy it, and only James can certify it”
Further, Matt can only sign this year, using his CAC card for authorization
Emily has to use both a biometric and a CAC card and be in a particular location (as measured by THIS GPS) to copy the key.
James can only certify the key, and he must have the PC in a certain state (as measured by PCRs) as well a know a password and have a PIV card.

42. Break for questions about EA

43. PCR brittleness

44. PCRs are brittle in 1.2. Are they different now?
“Any problem in Computer science can be solved by adding a level of indirection” – Paul England (Microsoft)
You can lock not just to a certain set of PCRs equals a certain value
You can also lock to: “Any set of PCRs / values signed by an authority, as represented by this public key”
Examples:
You can lock to “PCR 0 (the BIOS) as signed by DELL”
Thereafter upgrading your BIOS to a signed DELL BIOS won’t cause problems!
You can lock to “PCR values signed by IT”
Thereafter IT need only sign new values to make them useable

45. Sessions

46. Sessions Password session Always considered created (Default handle)
Does not encrypt passwords sent to TPM
Auth session
Need to be created
Can be used for HMAC authorization
Can be used for Policy authorization
Can be encrypted and/or salted
Audit session
Need to be created as an auth session
Are converted when used as audit sessions
Can be used in concert with auth sessions
Trial policy sessions
Used as a helper to creating policies if you don’t want to use software

47. Tips on Reading the Spec

48. To build a command you use 1-3.
Reading the Spec
Four sections:
1) Architecture
How sessions work
How commands are put together
2) Structures
Various data types
Tables of constants
3) Commands
APIs
4) Subroutines
To build a command you use 1-3.

49. Build a command Write out the flow Sign with a key (commands – Part 3)
Create a key (commands – Part 3)
Need structures (Part 2)
Need to load a parent or use Primary seed (command – part 3)
Need to authorize loading a parent (sessions – Part 1)
Need to a create a session or use straight password (commands – Part 3)
Must load signing key (commands – Part 3)
Need to authorize parent to load key (sessions – Part 1)
Need to create a session (or re-use previous session) (Part 1 or Part 3)
Must authorize signing data:
Get a random number
Use the correct command for GetRandom (Part 3)

50. White papers Will be published synchronously with spec
Give examples of how to use the specs to do useful things
Using a TPM to do Single Sign On
Using an audit session
Building a command
Flow charts for how a TPM works
What it does when you take ownership
Some are high level
Some give you the bits and bytes

51. New Use Cases
Single Sign on
Ephemeral Keys
Locked Keys
Revoking Keys

52. Single Sign on
Establish an NVRAM index with a restricted policy for writing: you must be able to use a private key, and also give it auth_data
This makes the index’s name unique.
Write something to it
This makes the index’s name unforgeable
Create a policy that points to the NVRAM index name’s auth_data
Use this policy when creating new keys / objects
All these objects will use the NRAM index name’s auth_data
When the NVRAM index name’s auth_data changes, all keys/object linked to it will also have their auth_data effectively changed
No “left over” keys with the old password!

53. Temporary Keys
Ephemeral keys only exist between TPM resets (power on to power off)
Keys can be created on the TPM, cached off the TPM, but will not be loadable again after the TPM is powered off.
Part of the “Null” hierarchy

54. Locked Keys
A locked key cannot be duplicated except by duplicating its parent
Similar to a non-migratable key in 1.2
Useful for virtualization
Parent is duplicated among trusted servers
Child acts like a non-migratable key while on those servers

55. Revoking a key There are multiple ways of revoking a key
Preventing the key from ever being re-loaded
Destroying the parent
Changing the hierarchy seed (nuclear option)
Preventing the key (or its parent) from ever being used
Using EA to require approval from a key signing daemon for use
Killing the daemon
Requiring a bit in NVRAM to be on for a particular user/use
Changing the bit
Requiring that a NVRAM HMAC key be used
Destroying the NVRAM named index
Using an ephemeral key
Powering the TPM off
JHUAPL

56. Questions