Re-envisioning of the TPM

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

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

How TPM 1.2 and 2.0 are the same

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?

How TPM 1.2 and 2.0 are different

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

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

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

Algorithms

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)

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)

Hierarchies

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

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

Quick break for questions before EA

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

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

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=12345324…. You can only use this key if you booted correctly Locality When command comes from approved location Intel / AMD virtualization modes DRTM (New localities: 32-255) 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

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

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

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

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

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.

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.

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

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

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. 0x00000000 0x00000000 TPM calculates P2 Signature Session nonce “N” N N N=0xBB443FE5 SHA256 (0x00000000 || TPM_CC_POLICYSIGN|| SHA256(A) ||0x01) 0xA3B62234 CAC public key A=1011……………..1+label (0x01) label Signature Verifies! Note: Signature includes label

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

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. 0x00000000 0x00000000 TPM calculates P2 Signature Session nonce “N” N N N=0xBB443FE5 SHA256 (0x00000000 || TPM_CC_POLICYSIGN|| SHA256(A) ||0x0000) 0xA3B62234 CAC public key A=1011……………..1+label (0x0000) label Signature Verifies! Note: Signature includes label

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

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

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

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 || 0x00000002||0x0020||P2 || 0x0020||P3)

SHA256 (0x00000000 || TPM_CC_POLICYSIGN|| SHA256(A) || 0x0000) Matt Authenticates with his CAC card P2=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 OR command sent With P2, P3 Session nonce “N” N N N=0xBB443FE5 TPM sees current value matches P2! OR, 0xA3B62234, 0xD37712245 SHA256( P1||TPM_CC_PolicyOR||0xA3B62234||, 0xD37712245) SHA256 (0x00000000 || 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

SHA256 (0x00000000 TPM_CC_POLICYSIGN|| SHA256(B) || 0x0000) Kathy Authenticates with her CAC card P2=0xA3B62234, P3=0xD37712245, P4=0x667FFE34 Start session TPM Sign nonce with CAC card Session Policy Buffer Send signature and B to TPM for verification. 0x00000000 0x00000000 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||, 0xD37712245) SHA256 (0x00000000 TPM_CC_POLICYSIGN|| SHA256(B) || 0x0000) 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

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.

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.

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

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

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.

Break for questions about EA

PCR brittleness

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

Sessions

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

Tips on Reading the Spec

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.

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)

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

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

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!

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

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

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

Questions