From TPM 1.2 to 2.

0 and some
more
Federico Mancini
AFSecurity Seminar, 30.11.2015
The trusted platform module - TPM

• The TPM (Trusted Platform Module) is both a set

of specifications and its implementation.
• In particular a library as of 2.0
• The TPM is a passive device (it can only perform
actions if asked to), soldered to the motherboard,
that can be used to perform some cryptographic
operations in a protected environment.

• Main Goal: increase trust in a platform

 Some context: Trust vs Security

• A trusted system is one that behaves as expected, not a guarantee

• A trustworthy system is one whose behaviour can be predicted – the base
on which one can decide whether to put their trust in the system or not
(trustworthy computing)
• A secure system is one that has been certified to enforce correctly and
reliably some specific security policy

• The TPM implementation can be secure, but not the platform on which it is
attached
• The platform will be trusted to report certain values in a correct way,
because it uses the TPM to do so
• I can take a decision about whether to further trust the platform with other
tasks based on the TPM supported funcionalities

I can trust that a system is running Windows because the TPM says so. That
does not make it secure.
Inside a TPM

I/O
NVRAM
CRYPTO Endorsment Key
(EK)
RNG
Storage Root Key
(SRK)
RSA Engine
Certificates

SHA-1 Engine Policies/AuthData

Key Generation

PCRs
1 17
OTHER
8 21
Program Code
16 24
Exec Engine

Opt-In
Platform Configuration Registers - PCR

I/O
• 20 bytes registers to store NVRAM
CRYPTO NVRAM
SHA-1 hashes. CRYPTO Endorsment Key
(EK)
RNG
• Cannot be written directly, only Storage Root Key
(SRK)
extended: PCR = SHA- RSA Engine
Certificates
1(Current value || new hash)
SHA-1 Engine Policies/AuthData
• 1-8 reserved. At least 24 must
be present. Key Generation
• They are always reset at boot PCRs
PCRs
time and only then. 1 17
OTHER
8 21
Program Code
16 24
Exec Engine

Opt-In
TPM main functionalities

• Better cryptographic services:

– Hardware protected crypto operations
– Hardware protected data encryption ≈ Smart cards
– Hardware protection against password guessing

• New functionalities:
– Platform integrity protection (Trusted Boot)
– Platform Attestation
– Sealing
– Anonimity
Trusted Boot

Each component involved in the boot process is measured, and the

measurement stored both in the TPM PCRs and in a Log File.

MEASURE MEASURE MEASURE MEASURE

BOOT
RUN BIOS RUN MBR RUN
LOADER
RUN OS

STORE STORE STORE STORE

PCRs
324HIAS23408ADFI

INR89403UE83FOQ

N356SDDW654SD

DS654SD97PHJD
Integrity protection
Log file
PCRs
324HIAS23408ADFI

INR89403UE83FOQ

N356SDDW654SD

DS654SD97PHJD

PCR values can be used to verify the integrity of the log file

• Why should we trust the PCR values?

• What if a malware was installed that stored fake measurements?
• Who measured the system?
Where does the trust come from?

MEASURE MEASURE MEASURE MEASURE

BOOT
RUN BIOS RUN MBR RUN
LOADER
RUN OS

CORRECT
IMPLEMENTATION
TPM PROTECTION
ASSURANCE Lv 4

TEMPER PROOF

CORRECT FILE
?
MEASUREMENTS

• Always executed (first)

ROOT OF TRUST
FOR
• Non-bypassable
MEASUREMENTS • Correctly implemented
• Immutable
Root of Trust for Measurement

CORE ROOT OF TRUST FOR MEASUREMENT

MEASURE MEASURE MEASURE MEASURE

CRTM BOOT
RUN BIOS RUN MBR RUN
LOADER
RUN OS

PCRs
324HIAS23408ADFI

INR89403UE83FOQ

N356SDDW654SD

DS654SD97PHJD
Root of Trust for Measurement

POTENTIALLY COMPROMISED

MEASURE MEASURE MEASURE MEASURE

CRTM BOOT
RUN BIOS RUN MALWARE RUN
LOADER
RUN OS

• Secure boot:
PCRs
special PCR with
good
324HIAS23408ADFI
configuration
INR89403UE83FOQ value
• Verified boot:
N356SDDW654SD signatures of
components
……
• Measured boot:
pretty much the
same

Guarantee that there is always a component that will measure the malware
S-CRTM Problems

• It should be part of the TPM, but it was too difficult to do in practice

because of that architectural changes needed.
• It is implemented instead as the first boot sector of the BIOS.
• There is no clear reference for how to implement it and every OEM
does it on its own way.
• Not surprisingly there have been uncovered many implementation
issues that reveal how PCR values are extended uncorrectly or not
at all:
– J. Butterworth, C. Kallenberg, X. Kovah and A. Herzog, "BIOS
chronomancy: fixing the core root of trust for measurement,"
Proceedings of CCS'13 - ACM Conference on Computer and
Communications Security, Berlin, Germany, 2013.
Upgrades

• What if I update my BIOS or some drivers?

• What I have have to upgrade or replace some hardware?
• How many possible «good» configurations can I have in a DB?
• Not practical

• TPM 2.0 tries to address this problem allowing more flexible policies
about the PCR values
Attestation protocol: Root of trust for Reporting

SML

SML
SML
DB with valid
configurations

Proof that PCR are genuine

PKI infrastructure

• No CA really supports any of

these specifications
• Only Infineon ships TPM with
actual pre-sintalled certificates
signed by Verisign
• A TPM cannot create standard
X.509v3 certificates
• It cannot even sign certificate
requests
TPM Keys
• A Privacy CA should take care of
for Platform
Identity it, but none is implemented and
deployed publically
• TPM 2.0 try to do something
about this
Anonimity

• Each TPM has a unique RSA key pair called Endorsment Key (EK)
and a certificate certifying that the EK belongs to a genuine TPM
• This to allow third parties to verify that they are talking to a real TPM
and that the compromise of one TPM does not affect all the other
(otherwise one global TPM key could have been used)
• However, this also means that each TPM is identifiable.
• That is why the EK cannot be used for signing, but only encrypting
and decrypting, and a TPM can create as many Attestation Identity
Keys (AIK) as it wishes to be used to sign TPM generated content
instead.
• But how to certify that these AIKs also are generated and protected
in a genuine TPM?
Privacy CA (PCA)
Direct Anonymous Attestation
CA ISSUER
(PK)CA
(PK’)PK

EK
(DAAcert)PK’ VERIFIER 1

Verify message by
using PK’ and PK
VERIFIER 2
TPM 2.0 has a standard ECC-DAA
functionality
Sealing/Binding
TRUSTED BOOT

TPM 2048 RSA KEY

NVRAM PCR[1,2,3…]

TPM 2048 RSA

KEY (Private) USER
PASSWORD
PCRs
PCRs PCR[1,2,3…] SYMMETRIC
1 17 KEY
USER
USER PASSWORD
8 21 PASSWORD
SYMMETRIC KEY
SYMMETRIC
16 24 KEY

DATA

ENCRYPTION
USER DATA
SOFTWARE
TPM 2.0 has many
more authentication
methods
TPM 1.2 Key Hierarchy
Problems

• We cannot say much about what happens «after» the OS takes

control
• We need to maintain a potentially huge database of valid platform
configurations
• We need an infrastracture parallel to PKI to manage TPM
certificates
• Users do not want someone else to have control of their machines
• Many restrictions on the key usage
After the OS

• Trusted Execution Environment (TEE) and Dynamic Root of

Trust: A secure and sanitized environment is created in hardware
on the fly in order to run code securely, even if the system is
compromised. TPM can be used to attest that code was securely
run. Implementations:
– Intel TXT
– AMD-V
– ARM TrustZone
• Separation Kernel/MILS: A secure separation kernel or hyper-visor
is securely loaded with trusted boot, and different security domains
are run in parallel. One domain is dedicated to TPM operations, so
that the user or other processes cannot interphere.
Intel TXT
SINIT AC TPM
MODULE MLE MODULE
(Measure Launch
Intel Environment) PCR 17
LOAD IN MEMORY
Signature
PCR 18

OS/BIOS/V
M….
CPU
Execute SENTER
ILP=BSP MLE execution
SINIT AC MLE

1. Stop other processors 1. Test Hardware configuration

2. Mask all external events 2. Initialize SMM handling
3. Validate SINIT AC signature 3. Enable DMA handling
4. Reset PCR 17-20 to a special value and 4. Load and measure MLE
extend 17 with SINIT hash 5. Store MLE hash in TPM
5. Unlock the chipset , load the SINIT AC 6. Pass control to MLE
and pass control to it

Intel SGX (Secure Guard Extensions) is coming next to add flexibility. Reminds of Flicker.
 TPM 2.0

With content copied and pasted shamelessly from:

• David Challener, «TPM 2.0 – Re-envisioning the TPM», Trusted

Infrastructure Workshop, 2013 The Pennsylvania State University,
University Park, PA.
• David Wooten, “TPM 2.0”, Partner Architect Microsoft Corp., 25
October 2013, Trusted Computing Group.
• Liqun Chen, «From TPM 1.2 to TPM 2.0», ETISS 2013, Gratz,
Austria.
• Will Arthur and David Challener, «A Practical Guide to TPM 2.0»,
Apress Open, 2014.
• Graeme Proudler, Liqun Chen and Chris Dalton, «Trusted
Computing Platforms – TPM 2.0 in context», Springer 2014.
• Various TCG specifications
TPM 2.0
• Support for new algorithms: flexibility for the inclusion of a variety
of algorithms, Elliptic curve-based algorithms and SHA-2 . and
potentially multiple “algorithm sets” on a single TPM.
• Support for more than one “bank” of PCRs: enables the TPM to
keep track of platform state using more than one distinct hash
algorithm
• Inclusion of three ownership hierarchies: a “platform hierarchy”
for platform protection, an “endorsement hierarchy” for privacy
control and a “storage hierarchy” for general cryptographic usage
• Support for enhanced authorization: support for very flexible and
fine-grained control over how and when TPM-protected data and
keys can be accessed
• More complex policies: policies can be combined with boolean
operator and support more scenarios
• Flexible keys: only two types of keys
Algorithms

TPM 1.2 supports TPM 2.0 supports

RSA encryption RSA encryption and signature
RSA signature ECC encryption and signature
RSA-DAA ECC-DAA
SHA-1 ECDH
HMAC SHA-1, SHA-256
One-time-pad with XOR HMAC
AES (optional) AES and one-time-pad with XOR
Manufacturer can add any
algorithms with TCG IDs
More PCRs
TPM 2.0 - Hierarchies

• In TPM 1.2, everything is under the control of the “Owner”

– If the TPM is not enabled, activated, and owned; there isn’t much that
can be done with it
– If you are the Owner, you control both the security and privacy functions
• In TPM 2.0, there are three separate domains
– Security – functions that protect the security of the user
– Privacy – functions that expose the identity of the platform/user
– Platform – functions that protect the integrity of the platform/firmware
services
• Each domain has its own resources and controls
– Security – ownerAuth, storage hierarchy, hierarchy enable
– Privacy – endorsementAuth, endorsement hierarchy
– Platform – platformAuth, platform hierarchy
TPM 2.0 - Hierarchies
TPM 2.0 – Platform Hierarchy

• Platform hierarchy
– For platform firmware BIOS/UEFI
– When the platform boots, the platform hierarchy is enabled and platformAuth is
set to a new value
• Allows use of the TPM to ensure the integrity of the firmware
• This is not a capability that should be under control of the user, so it isn’t
– PlatformAuth can be used to:
• Allocate NonVolatile memory resources
• Initialize the TPM
• Control the enables of the other hierarchies
– Before platform firmware turns control of system to OS, phEnable can be turned
off or platformAuth can be randomized
• PlatformAuth would be placed in secure location (SMM) so that only platform
firmware would be able to access it
TPM 2.0 – Endorsement Hierarchy

• Endorsement hierarchy
– For privacy administrator

• Endorsment keys
– As many as one wish
– Created from a secret seed
– Can be used to sign
– Can be used with different algorithms
– Belongs to its own key hierarchy

– Examples:
• One can create a signing EK to sign a CSR and get a Device ID
directly from the certificate autorithy that has a list of valid EK
• If EK comes with EK credentials, it should not be allowed to sign to
preserve privacy
TPM 2.0 - One seed to rule them all
TPM 2.0 – Keys

• No more many types of keys, only restricted and unrestricted, with

possibility to choose what they do. Even EK.
• Restricted simply means that they will not sign any external data that
resembles a TPM data structure.
TPM 2.0 – Enhanched Authorization (EA)

All these forms for authorizations can

also be combined to create complex
access policies.
TPM 2.0 – Locking to a PCR

• 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
How to do that

TPM2_PolicyAuthorize() allow a policy to have an “authority”

determine if some policy is OK rather than have the policy
hardwired in

– Example: The policyHash representing a set of good PCR is known to

the OEM
– The OEM signs a digest that represents the policyHash representing the
good PCR and distributes it along with their BIOS update
– The user can create a policy that says, “if the OEM approves the PCR
settings they are OK with me”
– Use TPM2_PolicyPCR() to set the policyHash to the current value of the
PCR and then use TPM2_PolicyAuthorize() to apply the OEM’s stamp
of approval to those PCR
Other TPM related things - Trusted Software
Stack (TSS)
• Teh software stack is needed by
applications to communicate
with theTPM.
• Trousers library written in C for
Linux offers TSS 2.0 support,
TSS.net from Microsoft also
supports 2.0 specs, while the
JSR321 for Java only supports
TSS 1.0
• Drivers for TPM are now
integrated in all modern OSes.

From JSR 321 wiki

A Trusted IdM for Tactical Operations
 Current solution CA
1. Fetch User certificate
2. Validate it
3. Send it to the IdP

IdP

1. Fetch attribute list

2. Issue an IS (Identity Statement)
3. Encrypt it with user public key (PK) and send it

Access control
IS, communication protected with PK
decisions based on IS

1. Send an IS Request
New Solution with TPM support

ADMIN
Certify TPM Generate AIK certificate
and Platform and store it on CA
configuration

Fetch AIK and

Ask for an IS verify configuration

Use IS and TPM protected keys

to communicate on the field
Pre-deployment scenario

Send AIK certification request to CA

Return secret AIK handle encrypted with TPM public key

1. Activate TPM
Login to CA
2. Generate AIK
and approve
3. Quote PCRs
the issuing of a
Generate and store
AIK certificate AIK certificate
indexed by a random
handle hashed
Deployment scenario
1. Hash AIK handle
2. Fetch AIK certificate
3. Fetch User certificate
4. Send them to the IdP

1. Check LK Signature
2. Compare pre and post deployment configuration
3. Fetch attributes
4. Issue an IS with degree of integrity/trust
5. Encrypt it with LK and send it

Access control
IS, communication protected with LK
decisions based on IS

1. Generate a new key pair LK

2. Bind it to the current configuration
3. Sign it with the AIK and the user certificate
Some experience with implementing with TPM

• Few available TSS, not implementing all needed functionalities

• No PCA implementation available, only some limited prototype
• Only Infineon provides EK certificates signed by Verisign
• We had to change the TSS code to unpack the TPM certificate request and
change it to Java objects
• A special x.509v3 extension called SKAE (Subject Key Attestation
Evidence) is to be used to integrated TPM info in a certificate. OpenSSL
does not support it.
• AIK cannot sign CSR (Certificate Signing Requests)
• Heavy to send your AIK certificate in all transactions
• We do not have a DB with approved configurations, but a pre-deployment
phase where we issue an AIK bound to specific PCR values and check that
the same values are still there when the user want to certificate a new
legacy key
• We re-parsed all TPM data-structure to use standard Java objects instead,
since TPM-enables and non-TPM nodes had to be interoperable.
Products using TPM

• Windows 8/10 verified/authenticated boot

• Bitlocker
• Google Chromebook
• Various vendors implementing certificate/key storage on TPM
• Integrity Measurement Architecture in Linux kernel
• Some Google routers
• Strong Swan
• …..