TPM 2.0

1. TPM 2.0 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) 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)

8. Differences are architectural

9. Command family comparison (some 1.2 functions not included as seldom used)

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 AuthorizationYou can make as simple or as complicated an authorization policy for an object as you wish.

19. Extended Authorization (continuedYou can make as simple or as complicated an authorization policy for an object as you wish.

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(0x00000000 || TPM_CC_PolicySigned1 ||SHA256(A) || NULL) = SHA256(0x00000000 || 0x00000160|| 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 0x00000160 2label is a reference so you know what you are authorizing.

25. Details of calculating the Policy Hash with ANDCAC card AND HMAC AND PCRs • CAC card authorization is represented • P2= SHA256(P1 || TPM_CC_PolicySigned|| SHA256(A)) • Always start with all zeros (32 zeros for SHA256) = P1 • CACandHMAC is represented by • P3= SHA256(P2|| TPM_CC_PolicyAuthValue ) • CACandHMAC andPCRs is represented by P4 = SHA256(P3 ||TPM_CC_PolicyPCR || pcrs || digestTPM) CAC card Authorized AND HMAC Final policy = P4 PCRS 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 TPM • Start session • Sign nonce, label with CAC card Session Policy Buffer Send signature to TPM for verification. 0x00000000 0x00000000 TPM calculates P2 Signature Session nonce “N” N=0xBB443FE5 N N 0xA3B62234 SHA256 (0x00000000 || TPM_CC_POLICYSIGN|| SHA256(A) ||0x01) CAC public key A=1011……………..1+label (0x01) label Signature Verifies! Note: Signature includes label

29. In pictures: Authorizing with a CAC card policy TPM • Load Signing Key (not shown) • Ask TPM to sign “Hello” with Key Session Policy Buffer 0xA3B62234 0x00000000 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 TPM • Start session • Sign nonce, label with CAC card Session Policy Buffer Send signature to TPM for verification. 0x00000000 0x00000000 TPM calculates P2 Signature Session nonce “N” N=0xBB443FE5 N N SHA256 (0x00000000 || 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 TPM • Tell TPM to record current PCR 0,2,4,8 and 12 values 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. 0x0EE51220 SHA256 (TPM_CC_POLICYPCR|| 0xA3B62234 || PCR || digest) • 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 TPM • Load Signing Key (not shown) • Ask TPM to sign “Hello” with Key Session Policy Buffer 0x0EE51220 0x00000000 • 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. In pictures: What happens when a PCR changes after authentication, before authorization? • PCR 0 is changed TPM • Load Signing Key (not shown) • Ask TPM to sign “Hello” with Key Session Policy Buffer 0x0EE51220 0x00000000 • 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 • Start with all zeros (32 zeros for SHA256) = P1 • Matt authenticating looks like: • 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 || 0x00000002||0x0020||P2 || 0x0020||P3)

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

36. Kathy Authenticates with her CAC cardP2=0xA3B62234, P3=0xD37712245, P4=0x667FFE34 TPM • Start session • Sign nonce with CAC card Session Policy Buffer Send signature and B to TPM for verification. 0x00000000 0x00000000 TPM calculates P3 Signature Session nonce “N” OR command sent With P2, P3 N=0x811662BA N N TPM sees current value matches P3! SHA256 (0x00000000 TPM_CC_POLICYSIGN|| SHA256(B) || 0x0000) SHA256(TPM_CC_PolicyOR||0xA3B62234||, 0xD37712245) 0xD37712245 0x667FFE34 OR, 0xA3B62234, 0xD37712245 CAC public key P3 = 0xD37712245! 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. 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 – Part3) • Need structures (Part 2) • Need to load a parent or use Primary seed (command – part 3) • Need structures (Part 2) • 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 structures (Part 2) • Need to create a session (or re-use previous session) (Part 1 or Part3) • Must authorize signing data: • Need to create a session (or re-use previous session) (Part 1 or Part3) • Get a random number • Use the correct command for GetRandom (Part 3) • Need structures (Part 2)

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