re-envisioning of the tpm tpm 2.0. research & exploratory development department (redd) over...
TRANSCRIPT
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 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?
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
Research & Exploratory Development Department (REDD)4
How TPM 1.2 and 2.0 are the same
Research & Exploratory Development Department (REDD)
Comparison of capabilities (10,000 feet)
5
Capability TPM 1.2 TPM 2.0
Root of trust for storage
Yes Yes
RNG Yes Yes
Secure Key gen Yes Yes
Secure Key store Yes Yes
NVRAM Yes Yes
Attestation Yes Yes
Anti-hammer Yes Yes
So what is the difference?
Research & Exploratory Development Department (REDD)6
How TPM 1.2 and 2.0 are different
Research & Exploratory Development Department (REDD)
Differences are architectural(Code size reduced by almost a factor of 2)
7
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)
Authorization Different for different objects in a TPM
Unified
Authorization Difficult to revoke keys Relatively easy to revoke keys
Authorization 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
Research & Exploratory Development Department (REDD)
Differences are architectural
8
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 Difficult Easy
SRKs One, RSA 2048 As many as you want, you pick the algorithm
HMAC Not available Available
Research & Exploratory Development Department (REDD)9
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 3
Sessions 0 (in TPM mgmnt) 2
Key management 14 10 (EA reduction)
Key use 7 9 (symmetric keys)
Random Numbers 2 2
Hash / Hmac 3 (Hash only) 8
Integrity Collection and Attestation 11 10
Authorization 7 18 (EA)
TPM management 33 28
Clocks and Timers 2 (timer only) 4
Non Volatile memory management 10 14 (new functions)
Total 92 108
Research & Exploratory Development Department (REDD)10
Algorithms
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)
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
Research & Exploratory Development Department (REDD)13
Hierarchies
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 reset14
Multiple Hierarchies
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
Research & Exploratory Development Department (REDD)16
Quick break for questions before EA
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
Research & Exploratory Development Department (REDD)18
Extended AuthorizationYou 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
Research & Exploratory Development Department (REDD)19
Extended Authorization (continuedYou 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 modesDRTM (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
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 passwordIT: authorized with CAC card and iris scan.
Work_backup = Me –OR- ITWork_Nobackup = Me
20
Mix and match
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
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
ANDCAC card
HMAC
PCRS
Authorized
Research & Exploratory Development Department (REDD)23
A more complicated policy
ANDBill’s CAC card
Bill’s HMAC
PCRS
ANDSally’s CAC card
Sally’s biometric
PCRS
OR
A Policy built for Bill OR Sally
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_PolicySigned1 || SHA256(A) || label2)
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
2label is a reference so you know what you are authorizing.
= SHA256(0x00000000 || TPM_CC_PolicySigned1 ||SHA256(A) || NULL)
= SHA256(0x00000000 || 0x00000160 || SHA256(A) || 0x0000)
Final Policy = P2
Research & Exploratory Development Department (REDD)
Always start with all zeros (32 zeros for SHA256) = P1
25
Details of calculating the Policy Hash with ANDCAC card AND HMAC AND PCRs
ANDCAC 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)
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
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
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 TPMfor verification.
TPM calculates P2
Note: Signature includes label
label
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
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 TPMfor verification.
TPM calculates P2
Note: Signature includes label
label
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
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
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
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)
Research & Exploratory Development Department (REDD)
Start session
35
Matt Authenticates with his CAC cardP2=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 Ato TPM for verification.
TPM calculates P2
OR command sentWith P2, P3TPM sees current valuematches P2!
P2 = 0xA3B62234!
TPM Calculates P4 and replaces buffer with P4
0x667FFE34 OR, 0xA3B62234, 0xD37712245 SHA256( P1||TPM_CC_PolicyOR||0xA3B62234||, 0xD37712245)
label
Research & Exploratory Development Department (REDD)
Start session
36
Kathy Authenticates with her CAC cardP2=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 Bto TPM for verification.
TPM calculates P3
OR command sentWith P2, P3TPM sees current valuematches P3!
P3 = 0xD37712245!
TPM Calculates P4 and replaces buffer with P4
0x667FFE34 OR, 0xA3B62234, 0xD37712245 SHA256(TPM_CC_PolicyOR||0xA3B62234||, 0xD37712245)
Signature
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
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?
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?
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
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
Research & Exploratory Development Department (REDD)42
Break for questions about EA
Research & Exploratory Development Department (REDD)43
PCR brittleness
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?
Research & Exploratory Development Department (REDD)45
Sessions
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
Research & Exploratory Development Department (REDD)47
Tips on Reading the Spec
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.
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
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
Research & Exploratory Development Department (REDD)
Single Sign on Ephemeral Keys Locked Keys Revoking Keys
51
New Use Cases
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!
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
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
Research & Exploratory Development Department (REDD)
Revoking a key
JHUAPL55
• 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
Research & Exploratory Development Department (REDD)56
Questions