TPM 2.0
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
2
Research & Exploratory Development Department (REDD)
Outline









3
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
Research & Exploratory Development Department (REDD)
How TPM 1.2 and 2.0 are the same
4
Research & Exploratory Development Department (REDD)
Comparison of capabilities (10,000 feet)
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?
5
Research & Exploratory Development Department (REDD)
How TPM 1.2 and 2.0 are different
6
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, antihammering 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
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
8
Research & Exploratory Development Department (REDD)
Command family comparison
(some 1.2 functions not included as seldom used)
9
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)
Algorithms
10
Research & Exploratory Development Department (REDD)
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)
11
Research & Exploratory Development Department (REDD)
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)
12
Research & Exploratory Development Department (REDD)
Hierarchies
13
Research & Exploratory Development Department (REDD)
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
14
Research & Exploratory Development Department (REDD)
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
15
Research & Exploratory Development Department (REDD)
Quick break for questions before EA
16
Research & Exploratory Development Department (REDD)
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
17
Research & Exploratory Development Department (REDD)
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
18
Research & Exploratory Development Department (REDD)
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 You can only use this key if the Dell
is met
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
19
Research & Exploratory Development Department (REDD)
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
20
Research & Exploratory Development Department (REDD)
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
21
Research & Exploratory Development Department (REDD)
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
HMAC
AND
PCRS
22
Research & Exploratory Development Department (REDD)
Authorized
A more complicated policy
A Policy built for Bill OR Sally
Bill’s CAC card
Bill’s HMAC
AND
PCRS
OR
Sally’s CAC card
Sally’s biometric
AND
PCRS
23
Research & Exploratory Development Department (REDD)
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
24
is a reference so you know what you are authorizing.
Research & Exploratory Development Department (REDD)
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
HMAC
AND
PCRS
Authorized
Final policy = P4
AND is done with a kind of hash extend –like a PCR.
25
Research & Exploratory Development Department (REDD)
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
26
Research & Exploratory Development Department (REDD)
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
27
Research & Exploratory Development Department (REDD)
In pictures: Authenticate with a CAC card
 Start session
 Sign nonce, label with CAC
card
Send signature to TPM
for verification.
Signature
TPM
Session Policy Buffer
0x00000000
0x00000000
TPM calculates P2
Session nonce “N”
N=0xBB443FE5
N
0xA3B62234
SHA256 (0x00000000 || TPM_CC_POLICYSIGN|| SHA256(A) ||0x01)
CAC public key
label (0x01)
A=1011……………..1+label
Signature Verifies!
Note: Signature includes label
28
Research & Exploratory Development Department (REDD)
In pictures: Authorizing with a CAC card policy
 Load Signing Key (not shown)
 Ask TPM to sign “Hello” with
Key
• TPM checks if policy Buffer
matches key Policy
• If they match, it produces
the signature
TPM
Session Policy Buffer
0xA3B62234
0x00000000
Signing Key policy = 0xA3B62234
“Hello”
Signature of “Hello”
Key Policy matches Buffer!
29
Research & Exploratory Development Department (REDD)
In pictures: Authenticate with a CAC card
and PCRs
 Start session
 Sign nonce, label with CAC
card
Send signature to TPM
for verification.
Signature
TPM
Session Policy Buffer
0x00000000
0x00000000
TPM calculates P2
Session nonce “N”
N=0xBB443FE5
N
0xA3B62234
SHA256 (0x00000000 || TPM_CC_POLICYSIGN|| SHA256(A) ||0x0000)
CAC public key
label (0x0000)
A=1011……………..1+label
Signature Verifies!
Note: Signature includes label
30
Research & Exploratory Development Department (REDD)
In pictures: Authenticate with CAC card
and PCRs
 Tell TPM to record current PCR
0,2,4,8 and 12 values
 TPM pulls current PCR digest,
calculates new policy buffer
value
TPM
Session Policy Buffer
0xA3B62234
 TPM establishes PCR state
variable in session, sets it
equal to zero.
 TPM replaces session buffer
with new value.
0x0EE51220
SHA256 (TPM_CC_POLICYPCR|| 0xA3B62234 || PCR || digest)
PCR state = 0
Certain PCRs can be configured in the TPM to not trigger a PCR state change
31
Research & Exploratory Development Department (REDD)
In pictures: Authorizing with a CAC card and
PCR policy
 Load Signing Key (not shown)
 Ask TPM to sign “Hello” with
Key
• TPM checks if policy Buffer
matches key Policy
• If they match, an PCR
state=0, it produces the
signature
TPM
Session Policy Buffer
0x0EE51220
0x00000000
Signing Key policy = 0x0EE51220
“Hello”
Signature of “Hello”
Key Policy matches Buffer!
PCR state = 0
32
Research & Exploratory Development Department (REDD)
In pictures: What happens when a PCR changes
after authentication, before authorization?
 PCR 0 is changed
 Load Signing Key (not shown)
 Ask TPM to sign “Hello” with
Key
• 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.
TPM
Session Policy Buffer
0x0EE51220
0x00000000
Key Policy matches Buffer
PCR state !=0 FAIL!!!
Signing Key policy = 0x0EE51220
“Hello”
1
PCR state = 0
33
Research & Exploratory Development Department (REDD)
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)
34
Research & Exploratory Development Department (REDD)
Matt Authenticates with his CAC card
P2=0xA3B62234,
P3=0xD37712245,
P4=0x667FFE34
 Start session
 Sign nonce, label with CAC card
Send signature and A
to TPM for verification.
Signature
Session Policy Buffer
0x00000000
0x00000000
TPM calculates P2
OR command sent
With P2, P3
TPM sees current value
matches P2!
OR, 0xA3B62234,
0xD37712245
CAC public key
A=1011……………..1+label
label (0x0000)
TPM Calculates P4 and
replaces buffer with P4
35
TPM
Research & Exploratory Development Department (REDD)
Session nonce “N”
N=0xBB443FE5
N
0xA3B62234
0x667FFE34
SHA256 (0x00000000
|| TPM_CC_POLICYSIGN|| SHA256(A)
|| 0x0000)
SHA256(
P1||TPM_CC_PolicyOR||0xA3B62234||,
0xD37712245)
P2 = 0xA3B62234!
Signature Verifies!
Kathy Authenticates with her CAC card
P2=0xA3B62234,
P3=0xD37712245,
P4=0x667FFE34
 Start session
 Sign nonce with CAC card
Send signature and B
to TPM for verification.
Signature
TPM
Session Policy Buffer
0x00000000
TPM calculates P3
OR command sent
With P2, P3
TPM sees current value
matches P3!
OR, 0xA3B62234,
0xD37712245
Session nonce “N”
N=0x811662BA
N
0xD37712245
0x667FFE34
SHA256
(0x00000000 TPM_CC_POLICYSIGN||0xD37712245)
SHA256(B) || 0x0000)
SHA256(TPM_CC_PolicyOR||0xA3B62234||,
CAC public key
B=1101……………..1 label=0x0000
TPM Calculates P4 and
replaces buffer with P4
36
Research & Exploratory Development Department (REDD)
P3 = 0xD37712245!
Signature Verifies!
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.
37
Research & Exploratory Development Department (REDD)
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.
38
Research & Exploratory Development Department (REDD)
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
39
Research & Exploratory Development Department (REDD)
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
40
Research & Exploratory Development Department (REDD)
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.
41
Research & Exploratory Development Department (REDD)
Break for questions about EA
42
Research & Exploratory Development Department (REDD)
PCR brittleness
43
Research & Exploratory Development Department (REDD)
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
44
Research & Exploratory Development Department (REDD)
Sessions
45
Research & Exploratory Development Department (REDD)
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
46
Research & Exploratory Development Department (REDD)
Tips on Reading the Spec
47
Research & Exploratory Development Department (REDD)
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
48
Research & Exploratory Development Department (REDD)
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 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
Research & Exploratory Development Department (REDD)
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
50
Research & Exploratory Development Department (REDD)
New Use Cases




51
Single Sign on
Ephemeral Keys
Locked Keys
Revoking Keys
Research & Exploratory Development Department (REDD)
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!
52
Research & Exploratory Development Department (REDD)
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
53
Research & Exploratory Development Department (REDD)
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
54
Research & Exploratory Development Department (REDD)
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
55
Research & Exploratory Development Department (REDD)
JHUAPL
Questions
56
Research & Exploratory Development Department (REDD)