Presentation is loading. Please wait.

Presentation is loading. Please wait.

Re-envisioning of the TPM TPM 2.0. Research & Exploratory Development Department (REDD)  Over 1,000,000,000 shipped machines with TPMs in them  All.

Similar presentations


Presentation on theme: "Re-envisioning of the TPM TPM 2.0. Research & Exploratory Development Department (REDD)  Over 1,000,000,000 shipped machines with TPMs in them  All."— Presentation transcript:

1 Re-envisioning of the TPM TPM 2.0

2 Research & Exploratory Development Department (REDD)  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 2 Where are TPMs today?

3 Research & Exploratory Development Department (REDD)  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 3 Outline

4 Research & Exploratory Development Department (REDD) 4 How TPM 1.2 and 2.0 are the same

5 Research & Exploratory Development Department (REDD) Comparison of capabilities (10,000 feet) 5 CapabilityTPM 1.2TPM 2.0 Root of trust for storage Yes RNGYes Secure Key genYes Secure Key storeYes NVRAMYes AttestationYes Anti-hammerYes So what is the difference?

6 Research & Exploratory Development Department (REDD) 6 How TPM 1.2 and 2.0 are different

7 Research & Exploratory Development Department (REDD) Differences are architectural (Code size reduced by almost a factor of 2) 7 Architecture1.22.0 AlgorithmsFixed: RSA2048/SHA-1Any: RSA/ECC SHA-1, SHA-2, AES Anti-hammerPrinciples enactedArchitected: Leaky bucket AuthorizationHMAC, PCR, Physical presence Extended Authorization (more about this in later slides) AuthorizationDifferent for different objects in a TPM Unified AuthorizationDifficult to revoke keysRelatively easy to revoke keys AuthorizationDifficult 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 Research & Exploratory Development Department (REDD) Differences are architectural 8 Architecture1.22.0 ManageabilityDifficultAlways “on” NVRAMFixedCan be used for counters, PCRs, authorization, storage Object referencesBy pointerBy name (no substitution attacks possible) Side channel attacksHMAC protected SRKKeys checked on loading before they are used; new forms of authorization; Types of keysFixed types (AIK, signing, Binding, etc.) Flexible types (But you can still make keys with 1.2-like behavior) FIPSableYes (level 1)Yes (level 2) PCRsBrittleEasily managed Single Sign OnDifficultEasy SRKsOne, RSA 2048As many as you want, you pick the algorithm HMACNot availableAvailable

9 Research & Exploratory Development Department (REDD) 9 Command family comparison (some 1.2 functions not included as seldom used) Command FamilyNumber of Commands 1.2 Number of Commands 2.0 Self test33 Sessions0 (in TPM mgmnt)2 Key management1410 (EA reduction) Key use79 (symmetric keys) Random Numbers22 Hash / Hmac3 (Hash only)8 Integrity Collection and Attestation1110 Authorization718 (EA) TPM management3328 Clocks and Timers2 (timer only)4 Non Volatile memory management1014 (new functions) Total92108

10 Research & Exploratory Development Department (REDD) 10 Algorithms

11 Research & Exploratory Development Department (REDD) 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 Research & Exploratory Development Department (REDD)  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) 12 Symmetric Keys

13 Research & Exploratory Development Department (REDD) 13 Hierarchies

14 Research & Exploratory Development Department (REDD)  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 14 Multiple Hierarchies

15 Research & Exploratory Development Department (REDD)  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 15 Seed based hierarchies

16 Research & Exploratory Development Department (REDD) 16 Quick break for questions before EA

17 Research & Exploratory Development Department (REDD) 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 Research & Exploratory Development Department (REDD) 18 Extended Authorization You can make as simple or as complicated an authorization policy for an object as you wish. TypeExampleUse case Password“cat”Entered during BIOS boot, from trusted path HMACUsing SHA256Entered from remote device Private keyCAC cardAdministrative features Private key plus data Signed biometricIdentify fingerprint + reader it came from + freshness Private Key plus data LocationGPS location + GPS identity + freshness CounterWhen 1 { "@context": "http://schema.org", "@type": "ImageObject", "contentUrl": "http://images.slideplayer.com/3289263/11/slides/slide_17.jpg", "name": "Research & Exploratory Development Department (REDD) 18 Extended Authorization You can make as simple or as complicated an authorization policy for an object as you wish.", "description": "TypeExampleUse case Password cat Entered during BIOS boot, from trusted path HMACUsing SHA256Entered from remote device Private keyCAC cardAdministrative features Private key plus data Signed biometricIdentify fingerprint + reader it came from + freshness Private Key plus data LocationGPS location + GPS identity + freshness CounterWhen 1

19 Research & Exploratory Development Department (REDD) 19 Extended Authorization (continued You can make as simple or as complicated an authorization policy for an object as you wish. TypeExampleUse case Authorize different object Link objects to use the same authorization Single Sign on PCRWhen PCR 0=12345324…. You can only use this key if you booted correctly LocalityWhen command comes from approved location Intel / AMD virtualization modes DRTM (New localities: 32-255) Signed PolicyWhen 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 ANDRequire multiple authorizations Multi-factor authentication ORAllow different authorizations Bob OR Sally OR Bill can use the object

20 Research & Exploratory Development Department (REDD)  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 20 Mix and match

21 Research & Exploratory Development Department (REDD)  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 21 Policy is represented by a single hash OR AND

22 Research & Exploratory Development Department (REDD) 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. 22 Policy is represented by a single hash AND CAC card HMAC PCRS Authorized

23 Research & Exploratory Development Department (REDD) 23 A more complicated policy AND Bill’s CAC card Bill’s HMAC PCRS AND Sally’s CAC card Sally’s biometric PCRS OR A Policy built for Bill OR Sally

24 Research & Exploratory Development Department (REDD) 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_PolicySigned 1 || SHA256(A) || label 2 ) 24 A Policy Hash with a single authentication based on a signature 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 2 label is a reference so you know what you are authorizing. = SHA256(0x00000000 || TPM_CC_PolicySigned 1 ||SHA256(A) || NULL) = SHA256(0x00000000 || 0x00000160 || SHA256(A) || 0x0000) Final Policy = P2

25 Research & Exploratory Development Department (REDD)  Always start with all zeros (32 zeros for SHA256) = P1 25 Details of calculating the Policy Hash with AND CAC card AND HMAC AND PCRs AND CAC card HMAC PCRS Authorized AND is done with a kind of hash extend –like a PCR. Final policy = P4  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)

26 Research & Exploratory Development Department (REDD)  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 26 Details of satisfying this policy  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 Research & Exploratory Development Department (REDD)  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. 27 Details of what this policy means (continued) 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 Research & Exploratory Development Department (REDD)  Start session 28 In pictures: Authenticate with a CAC card TPM 0x00000000 Session Policy Buffer  Sign nonce, label with CAC card Session nonce “N” N=0xBB443FE5 CAC public key A=1011……………..1+label (0x01) N Signature Signature Verifies! N 0x00000000 SHA256 (0x00000000 || TPM_CC_POLICYSIGN|| SHA256(A) ||0x01) 0xA3B62234 Send signature to TPM for verification. TPM calculates P2 Note: Signature includes label label

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

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

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

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

33 Research & Exploratory Development Department (REDD)  Load Signing Key (not shown) 33 In pictures: What happens when a PCR changes after authentication, before authorization? TPM 0x00000000 Session Policy Buffer  Ask TPM to sign “Hello” with Key “Hello” Key Policy matches Buffer PCR state !=0 FAIL!!! 0x0EE51220 Signing Key policy = 0x0EE51220 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. PCR state = 0  PCR 0 is changed PCR state = 1

34 Research & Exploratory Development Department (REDD) 34 A simple “OR” example: Matt OR Kathy Matt authenticating looks like:  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  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 Research & Exploratory Development Department (REDD)  Start session 35 Matt Authenticates with his CAC card P2=0xA3B62234, P3=0xD37712245, P4=0x667FFE34 TPM 0x00000000 Session Policy Buffer  Sign nonce, label with CAC card Session nonce “N” N=0xBB443FE5 CAC public key A=1011……………..1+ label (0x0000) N Signature Signature Verifies! N 0x00000000 SHA256 (0x00000000 || TPM_CC_POLICYSIGN|| SHA256(A) || 0x0000) 0xA3B62234 Send signature and A to TPM for verification. TPM calculates P2 OR command sent With P2, P3 TPM sees current value matches P2! P2 = 0xA3B62234! TPM Calculates P4 and replaces buffer with P4 0x667FFE34 OR, 0xA3B62234, 0xD37712245 SHA256( P1||TPM_CC_PolicyOR||0xA3B62234||, 0xD37712245) label

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

37 Research & Exploratory Development Department (REDD)  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. 37 Atomic authentication of PCRs

38 Research & Exploratory Development Department (REDD)  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. 38 How can you put an HMAC in a policy?

39 Research & Exploratory Development Department (REDD)  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 39 Can’t anyone replace a biometric sensor?

40 Research & Exploratory Development Department (REDD)  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 40 Some additional comments

41 Research & Exploratory Development Department (REDD)  “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. 41 Policies can be Fine grained

42 Research & Exploratory Development Department (REDD) 42 Break for questions about EA

43 Research & Exploratory Development Department (REDD) 43 PCR brittleness

44 Research & Exploratory Development Department (REDD) “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 44 PCRs are brittle in 1.2. Are they different now?

45 Research & Exploratory Development Department (REDD) 45 Sessions

46 Research & Exploratory Development Department (REDD)  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 46 Sessions

47 Research & Exploratory Development Department (REDD) 47 Tips on Reading the Spec

48 Research & Exploratory Development Department (REDD)  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 48 Reading the Spec To build a command you use 1-3.

49 Research & Exploratory Development Department (REDD)  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 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 Part 3)  Must authorize signing data:  Need to create a session (or re-use previous session) (Part 1 or Part 3)  Get a random number  Use the correct command for GetRandom (Part 3)  Need structures (Part 2) 49 Build a command

50 Research & Exploratory Development Department (REDD)  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 50 White papers

51 Research & Exploratory Development Department (REDD)  Single Sign on  Ephemeral Keys  Locked Keys  Revoking Keys 51 New Use Cases

52 Research & Exploratory Development Department (REDD) 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 Research & Exploratory Development Department (REDD) Temporary Keys 53 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 Research & Exploratory Development Department (REDD)  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 54 Locked Keys

55 Research & Exploratory Development Department (REDD) Revoking a key JHUAPL 55 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

56 Research & Exploratory Development Department (REDD) 56 Questions


Download ppt "Re-envisioning of the TPM TPM 2.0. Research & Exploratory Development Department (REDD)  Over 1,000,000,000 shipped machines with TPMs in them  All."

Similar presentations


Ads by Google