Key Management
with Trusted Platform Modules
ANDREAS
NILSSON
Master of Science Thesis
Stockholm, Sweden 2006
Key Management
with Trusted Platform Modules
ANDREAS
NILSSON
Master’s Thesis in Computer Science (20 credits)
at the School of Engineering Physics
Royal Institute of Technology year 2006
Supervisor at CSC was Mikael Goldmann
Examiner was Johan Håstad
TRITA-CSC-E 2006:049
ISRN-KTH/CSC/E--06/049--SE
ISSN-1653-5715
Royal Institute of Technology
School of Computer Science and Communication
KTH CSC
SE-100 44 Stockholm, Sweden
URL: www.csc.kth.se
Abstract
Key Management with Trusted Platform Modules
The concept of Trusted Computing, which aims at making computing platforms more
reliable, is based on a chip called Trusted Platform Module (TPM). The TPM is a chip
which provides cryptographic functionality like RSA encryption and secure key storage.
The aim of the Master’s project was to analyse and implement TPM based pre-boot
authentication for the disc encryption software Pointsec for PC. The system was analysed
with respect to manageability and security.
With regard to manageability the findings were that two critical implementation
factors will be interoperability and user transparency. Some TPM features are not
standardized which complicates the implementation of a general system. Recovery from
password loss or hardware failure can be achieved with Remote help or TPM key backup.
The security analysis focused on the software and hardware attack mitigation
integrated into the TPM. The chip was found to be somewhat vulnerable to sophisticated
laboratory based attacks but fully comparable to smartcards.
A prototype using the TPM for RSA key storage and RSA-wrapping of the disc
encryption key was developed. The prototype has two parts; one Windows based user
installation utility and one pre-boot authentication module. In order to communicate with
the TPM in the pre-boot environment a kernel device driver was developed.
Sammanfattning
Nyckelhantering med Trusted Platform Modules
Konceptet Trusted Computing, som syftar till att göra dator-plattformar mer pålitliga, är
baserat på en krets kallad Trusted Platform Module (TPM). En TPM är ett kryptografiskt
chip med inbyggd RSA-kryptering och säker nyckellagring. Syftet med detta
examensarbete var att analysera och implementera TPM-baserad pre-boot autentisering
för diskkrypterings-programvaran Pointsec for PC. Systemet analyserades med avseende
på hanterbarhet och säkerhet.
Vad gäller hanterbarhet visade det sig svårt att åstadkomma interoperabilitet och
användartransparens. Viss TPM-funktionalitet är inte standardiserad vilket komplicerar
utvecklandet av ett generellt system. Återställning vid lösenordsförlust eller hårdvarufel
kan göras med Remote help eller nyckel-backup inbyggd i TPM-kretsen.
Säkerhetsanalysen fokuserades på funktionalitet inbyggd i chipet för att förhindra
mjuk- och hårdvaruattacker. TPM-kretsen visade sig inte vara designad för att stå emot
sofistikerade attacker med avancerad laboratorieutrustning men fullt jämförbar med
smartcards.
En prototyp som använder en TPM för lagring av RSA-nycklar och RSA-kryptering
utvecklades. Prototypen består av två delar; ett Windows baserat användarinstallationsverktyg och en pre-boot autentiseringsmodul. För att kommunicera med chipet i pre-boot
miljö utvecklades en drivrutin.
Foreword
This report describes my Master’s project in Computer Science at the School of
Computer Science and Communication (CSC), Royal Institute of Technology (KTH),
Stockholm, Sweden. The project was carried out at Pointsec Mobile Technologies AB, in
Stockholm. Pointsec is a software company developing disc encryption software. I would
like to thank my supervisor at Pointsec, Fredrik Gustafsson and my supervisor at KTH,
Mikael Goldmann. I would also like to thank Bertil Lundell at Pointsec for giving me the
possibility to write a report on such a dynamic and interesting subject.
Table of Contents
Foreword...............................................................................................................................................3
1 Introduction.....................................................................................................................................1
1.1 Disc Encryption........................................................................................................................1
1.2 Pointsec Mobile Technologies AB .........................................................................................2
1.3 Trusted Platform Modules.......................................................................................................3
1.4 Problem and Objective ............................................................................................................3
1.5 Scope and Focus.......................................................................................................................4
2 Trusted Platform Module Overview ...........................................................................................5
2.1 Trusted Computing ..................................................................................................................5
2.2 Basic Concepts .........................................................................................................................6
2.3 Major Components ..................................................................................................................9
2.4 Protected Storage ...................................................................................................................13
2.5 Software Interfaces ................................................................................................................15
3 Pointsec for PC Architecture......................................................................................................17
3.1 Pre-boot Authentication.........................................................................................................17
3.2 Key Management ...................................................................................................................17
3.3 PPBE Design ..........................................................................................................................18
4 Prototype Implementation ..........................................................................................................19
4.1 Goals .......................................................................................................................................19
4.2 Structure and Tools ................................................................................................................19
4.3 TPM Interfaces.......................................................................................................................20
4.4 Multiple Users ........................................................................................................................23
4.5 Tpmutil Implementation........................................................................................................26
4.6 Pre-boot Implementation .......................................................................................................27
5 Manageability................................................................................................................................32
5.1 Interoperability.......................................................................................................................32
5.2 Administration........................................................................................................................32
5.3 Recovery.................................................................................................................................34
6 Security Analysis ..........................................................................................................................36
6.1 Dictionary Attack Considerations.........................................................................................36
6.2 Physical Presence...................................................................................................................37
6.3 Command Eavesdropping .....................................................................................................37
6.4 Hardware Attacks...................................................................................................................40
6.5 Smartcard Comparison ..........................................................................................................43
6.6 Key Quality ............................................................................................................................45
6.7 Concluding Discussion ..........................................................................................................46
7 Conclusion .....................................................................................................................................47
7.1 Summary.................................................................................................................................47
7.2 Outlook ...................................................................................................................................47
References...........................................................................................................................................49
Appendix A Cryptographic Concepts ..........................................................................................53
A.1 Encryption .............................................................................................................................53
A.2 Hash Functions......................................................................................................................55
A.3 Digital Signatures and Certificates ......................................................................................56
Appendix B PKCS#11.....................................................................................................................57
B.1 Introduction ...........................................................................................................................57
B.2 Structure.................................................................................................................................57
B.3 Use Case ................................................................................................................................57
Appendix C Abbreviations.............................................................................................................60
1 Introduction
As a response to the increased mobility of information storing devices like laptops and
mobile phones, disc encryption systems are becoming more popular. Disc encryption
systems protect sensitive information stored on the devices. Typical kinds of information
needing to be protected (in the enterprise world) include corporate secrets and
confidential customer data. Apart from receiving bad publicity and providing competitors
with company secrets, losing sensitive information about customers can also render large
fines. These factors have lead up to an extended usage of disc encryption. The process of
protecting information stored on a disc is really not that different from protecting
physical items with locks. By implementing an electronic lock only a user in possession
of a key to this lock can gain access to the protected resource.
This project deals with how to store and manage such electronic keys. This problem
is somewhat different from its real world lock analogy since normally physical keys can
be carried in a handbag or pocket. The electronic keys are unfortunately to complex to
remember so they cannot be “carried around” but instead has to be matched to
corresponding passwords. In this project a key storage plug-in to the disc encryption
system Pointsec for PC was developed. The task of the plug-in was to store the electronic
encryption keys on a cryptographic chip called Trusted Platform Module (TPM).
Previously Pointsec for PC users have hade the options to either store keys on the hard
disc or on removable tokens called smartcards. Various aspects, such as security of the
combined system (plug-in together with original software) were investigated.
1.1 Disc Encryption
In today’s mobile world an increasing amount of sensitive information is stored on
portable devices like laptops and smartphones. Such devices can easily be lost or stolen
and as such need adequate protection against data theft. There are of course built-in
security mechanisms like login screens for laptops and pin codes for smartphones.
However these kinds of obstacles are easily bypassed by even an inexperienced hacker,
not to mention competing companies. A simplified example of a working violation
strategy applying to laptops is to transfer the hard disc into another computer. Even
deleting files will not help since the information still is present on the hard disc (until
overwritten) and available to anyone with the right knowledge and tools.
The solution to the problem is to use cryptography to render the information stored
on the device unreadable to non-authorized persons. For readers not familiar with basic
cryptographic concepts like keys, encryption and decryption a presentation is given in
Appendix A. The basic idea is however simple; to replace readable information with
information only persons in possession of a special key can understand. A disc encryption
system does exactly this for you with the information stored on the hard disc, principally
using the login password to control access to the key. Disc encryption systems encrypt
1
everything on the hard disc and are not to be confused with simple utility programs that
let the user encrypt specific files. A consequence of encrypting the complete hard disc is
that the encryption system needs to run and decrypt the operating system files before the
operating system can be loaded. This requires so called pre-boot authentication, a process
performed by the encryption system before the operating system is started, where the user
is asked for login name and password. If correct login information is entered the disc
encryption software decrypts the operating system files and the operating system can
load.
A crucial security topic in all kinds of cryptography is key management. Disc
encryption systems are no exception; the key used to decrypt the hard disc must be stored
somewhere. There are two principal alternatives for protecting the encryption keys, in
software or in hardware. Software based protection includes storage on common
unprotected storage devices like hard discs, flash memories etc. Hardware protection
requires special hardware like smartcards or special purpose cryptographic chips. In
general hardware protection is more secure then software protection. If the keys are
stored on unprotected discs, even if in obfuscated1 or encrypted form, rogue software can
access and manipulate the stored information. If the keys instead are stored inside of
tamper-proof hardware devices unauthorized access is if not completely prevented, at
least obstructed.
1.2 Pointsec Mobile Technologies AB
The project was carried out in cooperation with Pointsec Mobile Technologies in
Stockhom. My supervisor at Pointsec was Fredrik Gustafsson. Pointsec develops disc
encryption software for use on laptops, PDAs, smartphones and removable media. The
product mainly concerned by this project is Pointsec for PC, a disc encryption system for
PC clients running Windows. Pointsec for PC basically consists of two different parts.
The first part in operational order is the Pointsec Pre-boot Environment (PPBE), a
lightweight “operating system” which launches before Windows is loaded and performs
pre-boot authentication of the user. The second part is a normal Windows program which
is used for system management and disc encryption/decryption while in the operating
system environment.
The aim of this project was to develop and investigate a prototype for a key storage
plug-in to Pointsec for PC. The function of the plug-in is to provide hardware based key
storage using a cryptographic chip called a Trusted Platform Module (TPM). Since
Pointsec for PC operates in both the PPBE and Windows environment the plug-in
consists of two separate modules for usage in the two different environments.
1
Obfuscation is generally considered bad cryptographic practice and is the act of hiding information using
some predefined confusion scheme. A simple example would be to store the key backwards.
2
1.3 Trusted Platform Modules
The TPM is a cryptographic chip which provides RSA2 key generation, built-in RSA
encryption and decryption and secure key storage. The TPM chip has been developed as
part of a strategy for making computing platforms more reliable, called Trusted
Computing (TC). Trusted Computing is described in Section 2.1 on page 5 but basically
it is a set of cooperating hardware and software that is supposed to make the computers
(and other communication devices) more reliable and trustworthy. The TPM
microcontroller is the hardware part of this concept. The TPM specification is platform
agnostic but all current applications are for PC platforms.
In addition to providing RSA functionality a TPM can furthermore be used to bind a
stored resource (like a key) to a certain machine configuration by measuring a platforms
hardware and software. This is not a normal function of cryptographic chips but is
implemented as part of the TC strategy. In general the TPM offers a wide range of
functions that would not be needed by Pointsec for PC. However Trusted Computing is a
growing concept, and financially backed up by several IT company giants. This has
resulted in that computer vendors ship many of their platforms with TPM chips installed
making it practical to use already installed hardware.
1.4 Problem and Objective
The project consists of two parts, a theoretical survey and the implementing of a software
prototype. Both parts relate to the use of the cryptographic functionality built into the
TPM.
The theoretical investigation consists of two major parts. The first part is an analysis
of manageability of a TPM based system for disk encryption. A critical issue here is
recovery when users lose passwords or a hardware failure occurs. The second part deals
with security issues regarding for instance the access to and storage of encryption keys in
the TPM. An attempt is made to identify possible security problems and estimate their
impact.
The practical part consists of writing a prototype addressing the TPM from both
Windows and from the Pointsec Pre-boot Environment (PPBE) mentioned in Section 1.2
on page 2. Tasks to be implemented using the TPM are asymmetric key generation,
secure key storage through RSA-wrapping and unlocking of user keys in the TPM by
means of authentication. Since the operations from the PPBE have to be performed
outside an OS environment it will not be possible to use software or interfaces provided
by the TPM vendor. Instead a kernel device driver for a TPM had to be developed.
2
RSA is a cryptographic algorithm named after its inventors, Rivest, Shamir and Adleman. For detailed
description see Appendix A.1.
3
1.5 Scope and Focus
In the press, TPM technology has often been connected to the concept of Digital Rights
Management (DRM). This is an application area which is not treated in this project.
Another topic which is not investigated (or used in the prototype) is the TPM
functionality called machine binding. Additionally all functionality used to secure remote
communication has been ignored since the key storage function of a disc encryption
system is local. The only time key information would have to be sent to another platform
is in the case of key backup. Such backup is however (in Pointsec for PC) performed
using so called recovery discs (see Section 5.3.3 on page 35). The theoretical
investigation and the prototype development instead focus on the classical, cryptographic
functionality of the microcontroller.
The TPM is defined as platform agnostic but is currently only manufactured for PC
platforms. Some parts of this project like Chapter 2 Trusted Platform Modules Overview
and most of Chapter 6 Security Analysis applies to non-PC platforms as well. However
the report was written with the PC platform in mind.
4
2 Trusted Platform Module Overview
Before discussing advanced properties of the Trusted Platform Module (TPM), a
presentation of its background and major components is appropriate. The TPM is a
cryptographic chip which constitutes the hardware part of the concept Trusted Computing
(TC). Typical cryptographic areas of usage are RSA encrypt/decrypt and secure hardware
based storage. Even though the TC functionality of the TPM is not used in this project an
orientation is included in the beginning of this chapter.
2.1 Trusted Computing
The concept of Trusted Computing has been introduced in recent years as an attempt to
come to terms with the flexible but somewhat unreliable computing platforms used today.
Abstractly, Trusted Computing is a set of software and hardware components working
together in order to be able to guarantee a platform’s behaviour to both local and remote
parties. Less formally, the two overall TC goals are to have better control of what
happens inside your own computer and to be able to trust other computers on a network.
Trust in the context of Trusted Computing does not imply protection against physical
malfunctions of the computer like hard disc crashes, but rather means to be able to trust
the integrity of a certain functioning platform configuration3. By comparing a previously
trusted configuration with the current, possible unwanted changes, such as viruses,
trojans or replaced hardware can be detected.
The comparison is performed through measuring and storing a set of integrity
metrics during the boot process of the platform. For example when booting a PC, a small
piece of code, which is stored on read only memory (ROM) called the BIOS boot block,
is executed first. The BIOS continues to read another piece of code from the boot block
of the hard disc. That code in turn reads another piece of the OS, this piece itself reads the
next one and so on until the whole operating system is running. When a TC platform
boots, the TC hardware (the TPM) calculates cryptographic hashes of relevant integrity
metrics and stores them inside the chip. In order for this to work, the BIOS, in addition to
reading the next piece of code from the boot block asks the TPM to calculate and log a
hash of this second block of code. The second piece of code executes and similarly asks
the TPM to log a hash of the next code block to be executed, and so on. These collected
hashes are then compared to encrypted hashes of an earlier trusted configuration. Possible
changes can be authorized by the user and then the reference configuration is updated.
Specifications for this technology have been developed by the Trusted Computing
Group (TCG).
3
Here configuration stands for the combination of all software and hardware installed and enabled on the
computer platform.
5
2.1.1 The Trusted Computing Group (TCG)
The industry consortium Trusted Computing Platform Alliance (TCPA) was jointly
founded the year 2000 by several IT companies including HP, IBM, Intel and Microsoft.
The goal of the TCPA was to develop technical specifications for TC hardware and its
software interface. In April 2003 the Trusted Computing Group (TCG) replaced the
TCPA and adapted its specifications. Today the TCG counts over 100 member
companies which provide the organization with funding and work force [26].
The TCG has released a number of specifications dealing with different aspects of
TC implementation. The basis is the TCG Main specification [25], which discusses the
concept and applicability of TC and introduces the TPM as the core hardware component.
The TPM is further described in the TCG TPM specifications [32][33][34]. Even though
the TPM is specified to be platform agnostic most of the work put in by the TCG has
been in the PC area. A specification for mobile devices is however scheduled for the first
half of 2006. The TPM software interface is described by the TCG Software Stack (TSS)
[7] which specifies how address the TPM from within an OS environment.
There have been two major versions of the TPM specifications; versions 1.1 and 1.2
Version 1.1 received critique regarding some security and privacy issues such as lack of
I/O encryption and insufficient protection of user identity. This has lead up to version 1.2
of the TPM specification which is the one considered in this report.
2.1.2 Remote Attestation
In addition to ensuring the local user that the platform is reliable TC aims at increasing
network security. The TPM chip has a unique, certified identity called the Endorsement
Key (discussed further in 2.2.1 on page 7). The TPM attests to the platform being in a
certain state by signing the hashed integrity metrics (OS configuration etc). Another
entity (user or program on another platform) can then verify the certified identity of the
TPM. In addition to OS attestation, normal applications can also be attested. They are in
turn attested by the OS.
The process of attesting an application schematically works as follows. A
Certificate Authority (CA) ensures that the sending TPM is a real TPM. The logged OS
information is signed by the sending TPM. The OS in turn signs information about which
application communication is taking place with. If the signatures are valid, the entity that
received the attestations needs to decide whether or not to trust their corresponding
signers. If the entity trusts the CA then it can trust that the signed OS is running on the
platform (the OS is authenticated). If the entity trusts the OS then it can be certain that the
signed application is the one actually running on the other platform.
2.2 Basic Concepts
Two important TPM entities are the unique identity called the Endorsement Key and the
TPM owner. These concepts are introduced in the next Sections. Since the text contains a
6
number of references to different keys, a summary of TPM key types and special purpose
keys is included in Section 2.2.3 on page 8.
2.2.1 Endorsement Key
To able to perform attestation a TPM first needs to authenticate itself. This could be
achieved by incorporating a globally shared authorization value between all TPMs
manufactured. The problem with this approach is that it is vulnerable to a break once run
everywhere (BORE) attack. If one TPM is compromised all other are compromised as
well. Since even Microsoft (one of the big contributors to the TCG) officially admits that
the TPM is relatively vulnerable to sophisticated hardware attacks [21] it is very likely
that some chips will be compromised.
To overcome this problem every TPM has a unique 2048-bit RSA key pair called
the Endorsement Key (EK). The EK is created internally by the TPM, after
manufacturing but before shipment to customers. The EK pair uniquely4 identifies the
TPM and can never be changed. The private part (EKpr) never leaves the TPM and the
public part EKpub is used in an X.509 endorsement certificate5. The endorsement
certificate is signed by the manufacturer, or some other entity (like a test lab) that can
assure that the TPM knowing EKpr is conformant with the TC specifications. In practice
this means that whoever knows the EKpr corresponding to the public key EKpub in the
endorsement certificate can be trusted to be a genuine TPM.
However, since the EKpub uniquely identifies the TPM, which in turn identifies the
platform and its user, the endorsement certificate cannot be used directly for attestation.
Instead so called Attestation Identity Keys (AIK) are used. The use of AIKs for
attestation was proposed in version 1.1 specification and is based on the creation of one
or multiple aliases of the EK. Using a trusted third party (CA) who knows the mapping
between an AIKpub and its corresponding EKpub, attestation can be performed without
publicly revealing EKpub. However the use of AIK keys was criticized for privacy reasons
due to the dangerous reliance on the CA not to reveal the EKpub (and TPM) mapped to a
certain AIKpub. As a response to this critique a new attestation method called Direct
Anonymous Attestation (DAA) was introduced in TPM 1.2. For the interested the method
is documented in [32].
2.2.2 Ownership
After shipment but before usage the TPM needs to get an owner. Ownership is solely
represented by an authorization value known only to the TPM and the owner. This means
that from the perspective of the TPM whoever knows the owner authorization value is the
owner. In general all access to TPM resources is based on the sharing of secrets which
are represented as 160-bit numbers. All shared secrets are called AuthData in the TCG
specifications, meaning either Authorization or Authentication Data depending on if you
4
At least with large probability.
5
X.509 is a standard for issuing public key certificates.
7
have the view of the TPM or the requesting party. In this report the term authorization
value will be used to represent the shared secrets.
Certain TPM operations can only be performed by its owner. In other words, to be
able to issue these commands, the authorization value authenticating the user as the
owner needs to be presented. Such operations include for instance activation/deactivation
and the creation of AIKs. Every time someone takes ownership of a TPM, a special
purpose RSA key pair, called the Storage Root Key (SRK) is created. The SRK is used to
wrap 6 everything stored in the TPM, including other keys so when a new owner is issued
everything stored during the period of the old owner is lost, see Section 2.4.1 on page 13.
The SRK has its own authorization value, independent of the owner’s.
A platform can only have one owner at a time but it need not be the user of the
platform. Different TPM objects (i.e. keys) can have different authorization values
associated with them. It should be noted that the owner is no “super user”. Being the
owner does not automatically give access to other protected entities or operations. Such
entities can have their own authorization values not known to the TPM owner.
2.2.3 Key Type Primer
The TCG specifies four different key types presented in the following list. The usage of a
key for other than its intended purposes is strictly forbidden in the TPM design and such
an attempt will fail with an error code.
§ Storage keys are required to be 2048-bit RSA keys and are used to wrap other keys. A
typical storage key is the SRK.
§ Binding keys are RSA keys with a minimum key size of 512 bits. Binding keys are
used to encrypt generic data, possibly symmetric keys but not other TPM RSA keys.
§ Signing keys are also required to be 2048-bit RSA keys and are used for signing.
§ A legacy key is a combination of a binding and signing key. The use of legacy keys is
not encouraged in the TPM specifications but is possible.
With the exception of the three keys listed below keys can either be generated within the
TPM or can be loaded externally using migration described in Section 2.4.2 on page 14.
Following is a summary of the special purpose TPM keys and their corresponding types.
Name:
Key type:
Description:
Location:
6
SRK – Storage Root Key
2048-bit RSA storage key
A new SRK is created for every new owner. As the only non-wrapped
TPM storage key the SRK is the root of the storage tree described in
Section 2.4.
Neither SRKpub nor SRKpr is ever allowed to leave the TPM, not even by
owner request.
Wrapping in the context of public key cryptography is to encrypt data with a public key. The plaintext can
then only be retrieved by someone in the possession of the corresponding private key.
8
Name:
Key type:
Description:
Location:
Name:
Key type:
Description:
Location:
EK – Endorsement Key
2048-bit RSA signing key
The EK is the unique identifier of a TPM. By signing information with
EKpr a TPM can certify its own identity for someone in the possession of
the endorsement certificate containing EKpub.
EKpr must never leave the TPM and EKpub should only be known to
certain trusted authorities.
AIK – Attestation Identity Key
2048-bit RSA signing key
An AIK is an alias to the EK and is used for TPM authentication to
protect user integrity. The mapping between a TPM’s endorsement
certificate and its AIKs are kept at a Certificate Authority.
An AIKpr is used to authenticate the TPM and can as such never leave the
chip. AIKpub is not secret and can be obtained from the mapping CA.
2.3 Major Components
This Section contains a description of the major chip components as defined in the TPM
specification [32]. The focus of the presentation is on the cryptographic functionality of
the chip. Some of the (for this report) less significant components have been bundled
together in Section 2.3.8 on page 13. A principal sketch of the parts discussed is given in
Figure 2.1.
Major Components of a TPM
Cryptographic
Other
functionality
Components
RSA
HMAC Engine
SHA-1 Engine
RNG
Key Generation
Non-volatile Memory
Volatile Memory
Monotonic Counter
I/O
Opt-in
Power Detection
Execution Engine
Figure 2.1 The major components of a TPM chip
2.3.1 RSA encrypt/decrypt
The TPM has a number of built-in cryptographic functions. This includes an
implementation of the RSA-algorithm. The TPM specification [32] does not specify how
RSA is to be implemented but it demands RSA to be used for digital signatures and
9
storage encryption. Required key lengths to be supported by the RSA-engine are 512,
768, 1024, and 2048 bits. The RSA public exponent is required to be 2 16+1 for all
generated keys. If a vendor implementation uses the Chinese Remainder Theorem it must
include detection of failures and protection, in order not to compromise the private key.
The implementation must use PKCS#1 [19] for digital signatures, encryption, data
formats etc.
It is important to note that the TPM does not support symmetric bulk encryption.
There is no externally available symmetric encryption algorithm; instead this is a task for
the platform CPU. In a symmetric encryption use case RSA keys are used to store an
encrypted version of the symmetric key.
2.3.2 HMAC Engine
To ensure data integrity and authentication of input and output from the TPM an HMAC
engine is used. HMAC is a type of Message Authentication Code (MAC) calculated using
a hash function together with a secret shared key. AN HMAC is defined by key length
and block size and is described in RFC2104 [10]. In general an HMAC is defined as:
HMACK(m) = h(K ⊕ opad || h(K ⊕ ipad || m)
Where K is the key, m is the message, opad and ipad are predefined padding parameters
of the block size and h is a cryptographic hash function. The operand ⊕ stands for the
XOR function and || for concatenation7. The strength of HMAC depends on the properties
of the underlying hash function and the quality and length of the key. The hash function
chosen for the TPM is SHA-1. A further discussion of SHA-1 in combination with
HMAC is provided in Section 6.3.3 on page 40.
2.3.3 SHA-1 Engine
The hash function SHA-1 belongs to a group of cryptographic hash functions developed
by the NSA called SHA (Secure Hash Algorithm). SHA-1 is the one most widely spread
and is included in commonly used protocols such as SSL, PGP and SSH. The SHA-1
function is primarily used by the HMAC engine but is also externally available. The
specification requires that SHA-1 be implemented according to FIPS-180-1. The TPM is
not a cryptographic accelerator8, in other words there is no minimum throughput
requirement for hashing. It is therefore not recommended to use the SHA-1
implementation externally unless it is necessary due to limited running environment
resources. As is discussed in Section 6.3.3 on page 40 collision weaknesses have been
found in the SHA-1 algorithm. The problems however mainly concern the use of digital
signatures and certificates, which are not used in this project.
7
Concatenation of two strings is just the operation of appending the second one to the end of the first one.
Example: “abc” || “def” = “abcdef”
8
A cryptographic accelerator is a special purpose device providing cryptographic operations.
10
2.3.4 RNG
The Random Number Generator (RNG) is used by the TPM for creation of nonces9, key
generation and randomness in signatures. If no hardware entropy source10 is implemented
the TPM is allowed to use a Pseudo Random Number Generator (PRNG)11. To be able to
produce good random numbers even if no genuine source of entropy is available the TPM
uses a state register together with a mixing function (e.g. SHA-1). When the TPM is
manufactured the state register is initialized with random data. The register is then
updated internally with random entropy data. Such data can originate from hardware or
software sources, for example thermal noise or mouse movements. After the first entropy
update it is impossible for anyone, including the manufacturer and the TPM owner to
determine the current state.
To generate random numbers the mixing function takes the value in the state
register and produces RNG output. Every time a random number is created an update of
the state register is performed. Otherwise the deterministic mixing function could
produce the same random number twice. The RNG should be able to produce 32 bytes of
randomized data at every request while larger request may fail due to insufficient
randomized data available.
2.3.5 Key Generation
The TPM uses its RNG to generate keys. It has built-in support for generating symmetric
keys as well as RSA key-pairs. Asymmetric keys are to be generated in accordance with
IEEE P1363 [7]. Just like in the case with algorithm support, TPM vendors are free to
add key generation for other asymmetric crypto systems (e.g. elliptic curves) but are
forced to implement according to P1363.
The generation of symmetric keys just consists of calling the RNG to provide a
random key of appropriate length.
2.3.6 Non-Volatile and Volatile Memory
A Non-Volatile (NV) memory component is a persistent storage device, meaning that
data stored will remain when the computer is shut down. A hard disc is a non-volatile
storage device. Volatile memory content is not stored when the computer is shut down,
an example of volatile memory is RAM. Figure 2.2 gives an overview of the internal
usage of the two memory types in the TPM.
9
Nonce is an abbreviation of a ’number used once’. Nonce values are used to include randomness in the
communication between the TPM and calling applications.
10
Examples of hardware entropy sources are atmospheric and thermal noise and radioactive decay.
11
A PRNG is a software source of pseudo random numbers. The numbers may seem to be random but are
generated in a deterministic way using a seed.
11
Usage of On-chip TPM storage
Non-Volatile
Memory
Volatile
Memory
Endorsement Key
Storage Root Key
Attestation Identity Keys
Owner AuthData
RSA Key Slots
PCR 00 à PCR 15
Key Handles
Session Handles
Opaque owner data
Figure 2.2 Overview of the non-volatile and volatile memory usage.
The NV memory is used primarily for storing persistent identity and state data. The keys
stored in the NV memory are the EK, the SRK and the created AIKs. It also contains the
authorization value of the owner. Apart from storing TPM internal keys and authorization
data the NV memory is also available for allocation by owner authorized entities (only in
version 1.2). With owner authorization it is possible to write and read persistent, opaque12
data to and from the TPM. The NV memory has however some downsides; First of all it
has a limited lifetime and should be used with care, hence the owner authorization.
Secondly it is very limited in size. The size may vary between vendors but the lower limit
is set as low as 1280 bytes [27].
The volatile memory is primarily used internally by the TPM to manage the
integrity measuring and temporarily store RSA keys. A key part of the integrity checking
of the platform is played by the Platform Configuration Registers (PCR). All TPM chips
must have at least 16 of the160-bit PCR slots used to store hashed information about the
platform hardware and software. The mapping between certain integrity metrics and the
PCRs is platform specific, e.g. PCR0 is used for the BIOS hash on the PC platform. The
RSA key slots are used to store keys in the volatile memory of the TPM. When an RSA
key is loaded into the TPM, the user receives a key handle mapped to that particular key.
Session handles are used to identify authorization data across multiple commands [22].
2.3.7 Monotonic Counter
This is a feature added to the v. 1.2 specification for security reasons. In general a
monotonic counter provides an ever-increasing incremental value. A TPM must support
four coexisting monotonic counters for internal and external use. The internal counter is
for usage by the TPM only but the external counters can be accessed by resources outside
of the chip.
The purpose of including a hardware monotonic counter is to prevent replay attacks.
A replay attack is based on eavesdropping encrypted communication and then resending
encrypted messages, without using cryptanalysis to find the used key. With this
12
The meaning of opaque data in this context is data that cannot be accessed or utilized by the TPM.
12
procedure someone could for instance reset the balance on a bank account to a previous
value. To prevent this with a monotonic counter one could increase the value of the
counter every time the balance change. Then the current status of the counter is encrypted
together with the message and the decrypting application can compare the count value
sent with the real one on the counter.
2.3.8 Other Components
The I/O component manages the flow of information over the communications bus. It
routes messages to appropriate receiving components and handles encoding and decoding
over external and internal buses.
The opt-in component is responsible for managing the state of the TPM. It
maintains the state of persistent flags such as on/off, enabled/disabled,
activated/deactivated and so on. The setting of these flags requires either authorization of
the owner or physical presence of the operator. Access policies associated with Opt-in are
enforced by the I/O component.
The power detection manages the TPM power states related to the platform power
state. If any change in the platform power state occurs the TPM must be notified. There
are some vulnerable platform power states where the TPM may restrict execution of
commands. A typical example of that is during the Power on Self Test (POST) of the
platform.
The execution engine executes the commands received through the I/O component.
This is a very important component from a security point of view since it is the execution
engine that ensures that operations are properly segregated and that vulnerable data is not
exposed.
2.4 Protected Storage
Protected storage in context of Trusted Computing Platforms (TCP) is defined by Pearson
et al [18] as follows:
“Protected storage is a service to the host platform in which the Trusted Platform Module
acts as a portal to confidential data stored on an arbitrary, unprotected storage media.”
The TPM implements secure storage through an RSA wrapping storage tree. The actual
memory resources of the TPM are limited but this is solved cleverly through successive
wrapping of keys and generic data. At the root of the tree is the previously mentioned
Storage Root Key (SRK).
2.4.1 Data Protection
Secure storage is based on the fact that the SRK never leaves the TPM. The public part of
the SRK is used to encrypt the private part of the so called storage keys (which must be
2048-bit RSA keys). The storage keys can then in turn be used in the same way to
13
encrypt other storage, binding or signing keys. Generic blobs13 of data can be encrypted
with the binding keys. All encrypted entities are stored as opaque data blobs outside the
TPM on an unprotected medium like a hard disc. An example of a typical storage tree is
given in Figure 2.3.
SRK
SK
K
SK
BK
BK
GD
GD
Figure 2.3 An example of external secure storage.
In the figure, SK stands for storage key, BK for binding key, K for signing key and GD
for generic data. Signing keys cannot have children but must be leaves of the tree.
Typical generic data could for example be symmetric keys or passwords. When in an OS
environment a key-cache manager (KCM), placed outside the TPM, moves data to and
from external storage [4]. The KCM is provided by the TCG Software Stack (TSS), see
Section 2.5.1 on page 14.
2.4.2 Key Scope Attributes
A key scope attribute is established when creating the key and can never be changed [30].
There are two major categories, migratable and non-migratable keys.
A migratable key can be transferred to other TPMs. Typical use is for a key to
follow a user between several devices. Migratability also gives the opportunity to back up
crucial keys in case of TPM failure. A non-migratable key is never allowed to leave the
TPM. Examples of built-in non-migratable keys are the AIKs used for attestation. An
exotic attribute form introduced in TPM version 1.2 is the certifiable migratable key
which can be migrated only under certain circumstances. The destination TPM must be
authorized both by the TPM owner and a certain migration selection authority.
Worth to mention is that in the storage tree in Figure 2.3 any non-migratable key node
must only have non-migratable ancestors. The idea of migration is corrupted if a parent to a
non-migratable key is migrated to another platform.
13
BLOB – Binary Large Object
14
2.5 Software Interfaces
For applications to be able to use the TPM without addressing it directly on byte level a
software interface is specified. The basic API alternatives when operating from an OS are
presented in this section. Software access to the TPM is further discussed in the prototype
implementation part.
2.5.1 TSS
As was mentioned in 2.1.1 on page 5 the basic way to access the TPM from software is
through the TCG Software Stack (TSS) [29]. The interface is specified by the TCG and
all TPM vendors are required to ship a TSS implementation. The TSS API is relatively
easy to access and has the advantage of being platform independent. The primary
interface for application developers is the TSS Service Provider (TSP). It is relatively
high level and is provided as a DLL by the TSS vendor. One level down is the TCG Core
Services (TCS) which to a much higher extent resembles the pure commands sent directly
to the TPM through its I/O port. To be able to use the TCS a developer needs in depth
knowledge of the TPM command base which requires investing a considerable amount of
time. The TCS is typically accessed through a Windows COM-interface. At the lowest
level is the TCG Device Driver Library (TDDL) which provides functions for sending
commands on byte level directly to the TPM. It should be noted that access to the TPM is
exclusive and synchronized via the TDDL. This means that if TCS is running as a
Windows NT Service it must first be stopped before the TDDL gives any access to the
TPM. A schematic view of the TSS is given in Figure 2.4 with the TSP being the highest
level and the TDDL at the bottom.
TSP
TCS
TDDL
Figure 2.4 A schematic view of the TSS.
2.5.2 MS-CAPI
Microsoft Cryptographic API (MS-CAPI) is an interface for adding cryptographic
functionality to Windows based applications [16]. Access to the TPM is acquired through
use of a Cryptographic Service Provider (CSP). A CSP is a standard module that
implements cryptographic functions in hardware. Providing a CSP implementation is not
required by the TCG but most TPM vendors ship with a special TPM CSP. It is important
to note that some functions of the TSS are not available through either MS-CAPI or
PKCS#11 (mentioned below). The advantage of using MS-CAPI is of course the abstract
15
standardisation but it is at the same time its downside. MS-CAPI was examined but not
used in the prototype implementation (see Section 4.5.1 on page 26).
2.5.3 PKCS#11
Support for the public key crypto interface PKCS#11 (Cryptographic Token Interface
Standard #11) described in [20], is not mandatory but again most vendors ship with
PKCS#11 support included. PKCS#11 is developed by RSA Laboratories and has
become a worldwide standard for accessing cryptographic tokens. Its advantage over MSCAPI is that it is platform independent so an implementation using PKCS#11 would be
relatively easy to port from a PC to a Linux environment. PKCS#11 is described in
Appendix B and a lightweight PKCS#11 library is implemented by the prototype module
for the pre-boot environment.
16
3 Pointsec for PC Architecture
This chapter is an introduction to the existing Pointsec architecture for user authentication
and key management. An understanding of the existing solution provides a context for
the TPM prototype presentation in Chapter 4.
3.1 Pre-boot Authentication
As was mentioned in Chapter 1, all the information on the hard disc is encrypted.
Consequently the operating system files need to be decrypted before the operating system
can be loaded. This requires pre-boot authentication, a process where the user is asked for
login name and password. If correct login information is entered Pointsec decrypts the
operating system files and the operating system can load.
3.2 Key Management
In principle, the password provided by the user during the pre-boot authentication
unlocks the so called partition encryption key (the symmetric key used to encrypt the
hard disc). Currently in Pointsec, this key can be stored and protected in two different
ways, on the hard disc, or using a so called smartcard14. Which type should be used is
chosen specifically for each user account created. The idea with the TPM prototype is to
include a third account type, namely one using TPM based authentication. A simplified
sketch of the current and future management (dashed) of the partition encryption key is
given in Figure 3.1.
Pointsec
Hard disc
Smartcard
TPM
Figure 3.1 Current and future management (dashed) of the partition encryption key.
The figure is simplified, in that it depicts the partition encryption key as being stored
directly on the hardware devices. This is not the case, as was discussed in Section 2.4 on
page 13, but the devices (smartcard and TPM) use RSA keys stored on them to decrypt
the partition encryption key.
14
Smartcards are presented thoroughly in Section 6.5 as an alternative to the TPM. For now it suffices to
know that they can be attached to a computer and can store RSA keys protected by a pin code.
17
The advantage with storing encryption keys in hardware, like smartcards or
cryptographic chips is that the protection is better. An encryption key stored on the hard
disc can be obfuscated and encrypted with a password, but that is the limit. The same
operations can be applied to keys stored in hardware, but in addition the keys are
protected inside tamper resistant hardware. The reason for including TPM support beside
smartcards is to have a more complete product, giving customers more flexibility.
It is important to notice that the storage of keys on smartcards or TPMs applies to
the Windows part of Pointsec as well. Only the sectors of the hard disc currently
requested are decrypted requiring a continuous access to the partition encryption key.
3.3 PPBE Design
To understand the design of the pre-boot prototype a further presentation of the current
smartcard support in the PPBE (Pointsec Pre-boot Environment) is required. To
communicate with a smartcard outside of an OS environment, one needs two drivers; a
driver for the smartcard reader and a driver for the actual card. In Figure 3.2 a simplified
view of the program flow with regard to smartcard communication is displayed.
PPBE
IFD Handler
function pointers
IFD Handler
function pointers
reader.bin
p11.bin
Figure 3.2 Simplified program flow related to smartcard access in the PPBE.
The reader.bin is the smartcard reader driver. The module implements a so called
IFD15 Handler interface for communicating with smartcards via a smartcard reader. The
interface is described in ifdhandler.h included in the source library referred to in
Section 4.2.4 on page 20. The p11.bin module is a smartcard PKCS#11 library (see
Appendix C and [20]), in other words it is a special purpose smartcard driver. PKCS#11
is a standardized way to access cryptographic functions from cryptographic tokens.
The reader.bin module exposes a set of functions to access the smartcard called
IFD Handler functions. The PPBE asks reader.bin for the IFD Handler function
pointers and passes them on to p11.bin. The PKCS#11 library then uses the functions to
communicate with the smartcard (this is symbolized with the dashed connector in Figure
3.2). In the TPM plug-in described in Chapter 4, the modules reader.bin and
p11.bin are replaced to communicate with a TPM instead.
15
IFD – Interface Device, commonly called a “smartcard reader”.
18
4 Prototype Implementation
This chapter describes the prototype implementation part of the project. First the goals of
the project are presented. Next the overall structure of the prototype is described in 4.2.
After that some general preliminaries are presented in Sections 4.3 and 4.4 before the
actual implementation is described in Sections 4.5-4.6.
4.1 Goals
The primary goal was to implement a proof of concept prototype utilizing the TPM for
key generation and pre-boot authentication. The prototype was to be implemented in such
a way that remaining work to include it into Pointsec for PC was minimized. However it
was not in the scope of this project to explicitly solve all problems encountered, but
rather to point them out and propose possible further actions.
The secondary goal was to gain knowledge about how the TPM operates and which
kind of functionality and interfaces are available for developers. Therefore some parts of
this chapter will be more general then would have been needed just to document the
actual implemented prototype.
4.2 Structure and Tools
The prototype consists of two main parts. A Windows command-line utility called
tpmutil, and two binary PPBE libraries (.bin DOS files) representing the two drivers in
Figure 3.2 on page 18. These parts have been developed separately and their sole
connection point is the commonly accessed storage area discussed in Section 4.4.2 on
page 36. Some headings will be followed by a list of file names. These are the C/C++
files primarily concerned by the text in the paragraph. The source files can be obtained
from [24], see Section 4.2.4 on page 32.
4.2.1 User Installation
The main purpose of tpmutil is to act as a smartcard plug-in during the installation
phase of Pointsec for PC. Its primary task is to provide the installation wizard with a
simulated smartcard-logon certificate. The certificate will contain the currently logged in
user’s public key to use for wrapping the disc encryption key. The Windows part of the
prototype (as opposed to the PPBE-part) will not operate on the partition encryption key
but is only used to wrap the user RSA keys described in Section 4.4.1 on page 23. There
will be no real-time interaction with Pointsec for PC. Instead the certificate needs to be
created and stored with tpmutil before the installation procedure is started. The utility
is described in-depth in Section 4.5.
4.2.2 Login Procedure
The pre-boot module of the prototype is responsible for decrypting the symmetric disc
encryption key. The module was implemented as a lightweight PKCS#11 library for the
19
TPM, only supporting functions actually needed. The prototype is therefore not to be
seen as a complete pre-boot PKCS#11 library for the TPM. The provided PKCS#11
module is then used by the pre-boot authentication code after receiving login information
from the user. This is already done the exact same way in Pointsec for PC. The difference
is that the current PKCS#11 library is smartcard based whereas the library in the
prototype uses the TPM as cryptographic device. If the reader is not familiar with the
PKCS#11 standard for accessing cryptographic tokens an introduction is given in
Appendix B. In addition to the PKCS#11 library a dummy smartcard reader driver was
written to make the prototype fit into the existing PPBE structure.
A feature not implemented in the prototype is informative error messages during
pre-boot authentication. The only error message right now is “Login failed”. A typical
scenario where better error messages are needed is if the TPM is disabled or deactivated.
Giving the user “Login failed” gives the impression that the user name or password is
incorrect. The graphical user interface is not accessible from the implemented binary
libraries. A specific error message interface would therefore have to be established
between the TPM PKCS#11 library and its callers.
4.2.3 Development Tools
All code was written in C and C++ and compiled with Microsoft Visual Studio 7.0 and
DJGPP. DJGPP is a porting of GCC16 to a 32-bit DOS environment. The part of the
prototype running in Windows, tpmutil was compiled with Visual Studio while DJGPP
was used to compile the pre-boot binary libraries.
4.2.4 Source Code
The source code and makefiles for the prototype can be obtained in compressed form
from the author by e-mail or be downloaded from [24].
4.3 TPM Interfaces
In Section 2.5 the different TPM interfaces available inside operating system
environments were presented. The one chosen for tpmutil was the TSS Service
Provider Interface (TSPI) utilizing a TSS Service Provider (TSP) dll. The reasons for the
decision are presented in Section 4.5. For the pre-boot environment the direct byte-level
TPM commands have to be used. However for the actual pre-boot access method there
are two different alternatives which are discussed.
4.3.1 TSP
The definition of a TSP and its corresponding TSPI is included in the TSS Specification
[29]. Many of the function calls have one to one mappings with TPM commands but all
authorization session handling has been abstracted. There is in other words no need (or
16
GCC stands for the GNU Compiler Collection and is a set of open source programming language
compilers originally designed for the GNU project and used extensively in UNIX environments.
20
possibility) to explicitly use an authorization protocol like OIAP or OSAP since it is
managed internally by the TSP. The TSP functions are accessed through a vendor
provided dynamic link library together with the TSS header files [35] which also are
included with the prototype source code.
4.3.1.1 Class Structure
The TSPI is defined as a C interface but uses an object-oriented approach. The following
classes are defined:
§
§
§
§
§
§
§
Context class
Policy class
TPM class
Key class
Encrypted Data class
PCR Composite class
Hash class
The classes are well documented in [29]. The relevant classes for the prototype are the
Context, Policy, TPM and Key classes. Of these all but the first are all TSP objects and
are created with the Context method Tspi_Context_CreateObject.
4.3.1.2 Policy Handling
In order to hide the cumbersome authorization sessions from application developers, the
TSPI introduces the concept of Policy objects. The TSPI of course uses authorization
sessions internally, but they are abstracted from the developer. The TPM and Key objects
are both so called authorized objects. This means that they both have to be assigned to a
Policy object before usage. A Policy object contains authorization information for an
entity. The authorization value for the TPM object is the owner authorization value. The
authorization value for a Policy object is set using Tspi_Policy_SetSecret. The
caller is given the opportunity to choose between providing a password to be hashed
(TSS_SECRET_MODE_PLAIN) or a 160-bit value directly (TSS_SECRET_MODE_SHA1).
When the TSP communicates with the TPM it uses normal authorization sessions
initiated with the authorization data found in the appropriate Policy object.
4.3.1.3 Attribute Data
All TSPI objects have different attributes (properties). These attributes can be set or read
using the following functions which are inherited by all subclasses.
Tspi_SetAttribUint32 and Tspi_GetAttribUint32 for 32-bit properties
Tspi_SetAttribData and Tspi_GetAttribData for properties of arbitrary length
21
4.3.2 BIOS INT 1Ah Interface
When using the TPM from the pre-boot environment none of the previously mentioned
interfaces can be used since they are implemented for use within an OS environment.
Instead the direct byte-level communication presented in Section 4.3.1 on page 21 when
discussing authorization sessions has to be used. Input and output of these commands
need somehow be communicated to the TPM though. This would normally be taken care
of by the device driver but there is no such thing outside the OS.
To solve this problem the TCG requires the BIOS of TPM-equipped platforms to
expose an INT 1Ah assembler interface [28]. Using this interface it is possible to send
and receive byte strings from the TPM via addresses in the processor registers. A small
set of TSS functions might also be available depending on the manufacturer. There are
certain requirements on entering and exiting the interface namely;
On entry:
§ The processor’s memory mode into these INT 1Ah functions MUST be Real
Mode and the processor MUST NOT be in virtual 8086 mode.
Upon exit:
§ The processor’s memory mode MUST be Real Mode with 64K segment limits.
Furthermore the interface only supports up to 4 GB of physical address space.
It is not clear if all TPM PC platform manufacturers plan to incorporate this interface into
their BIOS’s. According to the major BIOS’ vendor Phoenix Technologies the INT 1Ah
interface will never be incorporated into the PhoenixBIOS product but will be supported
in their next generation BIOS called Trusted Core. It is required according to the TCG
specification but if there is no actual implementation that is of little use. According to a
joint presentation held by Microsoft and HP at WinHEC 05 (Windows Hardware
Engineering Conference) Microsoft’s next generation OS Windows Vista will use the
above mentioned INT 1Ah interface for its feature Secure Startup [14]. This fact will
probably constitute a rather good incitement for the BIOS vendors to expose the
interface.
4.3.3 Vendor-specific Device Driver
tpm.h, nsc_driver.c
The alternative to using the BIOS-interface is to write a kernel device driver accessing
the TPM directly on the LPC-bus via hardware I/O ports. This was the way chosen in this
project, since the BIOS interface was not implemented in any of the platforms available.
The downside of this solution is that even though the actual TPM byte commands are
standardized when and how to send these commands is vendor specific. This demands
22
development of a separate driver for every different TPM model. Such a driver collection
must also include an identification mechanism of the chip vendor and model.
Writing device drivers either requires input from the chip vendor or hardware
reverse engineering (like eavesdropping on the LPC bus or debugging a binary device
driver in kernel mode). The easiest way to get a prototype running was to look at the
Linux kernel source files. The Linux kernel does not support all manufactured TPM
microcontrollers, but does support Atmel, Infineon and National Semiconductor. The
prototype device driver was developed on an IBM Thinkpad T43 which contains an NSC
Integrated TPM 1.1. The driver is implemented in nsc_driver.c with header file
tpm.h. The only exposed functions are tpm_nsc_init and tpm_transmit which are
used for initialization and sending/receiving commands respectively. With regards to
identification the prototype checks that it deals with a NSC TPM and fails with error for
other TPM types. It should be noted that the Linux kernel code could not be copied
directly but was only used as inspiration for the device driver.
4.4 Multiple Users
Even though a TPM only can have one owner a PC platform must support multiple users.
Referring to the mapping discussion in Section 4.5 on page 27 some troubles are
introduced when trying to incorporate the prototype into a system originally developed
for smartcards. First of all there is no user concept in PKCS#11. The function C_Login
only takes a pin code (password) as parameter and no user name. For the prototype this is
solved by concatenating the username and password using a dot. The username “andreas”
together with the password “pass” would for example make up the login string
“andreas.pass”. See PKCS#11 use case in Appendix B.3.
4.4.1 Key Storage Structure
The simplest key design is to let each user have his/her own RSA wrapping key. This
means that multiple copies of the symmetric disc encryption key will be stored, but
wrapped with different parent keys. The principal storage structure is showed in Figure
4.1.
SRK
UK1
UK2
...
UKn
DK
DK
DK
DK
Figure 4.1 Storage hierarchy in practise
In the figure UKi stands for the RSA key of platform user number i. DK is an
abbreviation for disc encryption key and is the symmetric key used to encrypt and
23
decrypt the hard disc. In TCG context the user keys have to be defined as binding or
legacy keys since they encrypt and decrypt generic data.
An immediate problem with this approach is that the user then would have to
provide the SRK password17 on each single log-on. If, in addition separate user
passwords protect the individual keys, users would be asked for two passwords, which is
not acceptable. The alternative is to demand the SRK authorization value to be a certain
dummy value, for instance all 20 bytes equal to 0. This is how Windows Vista has
planned to do it in Secure Startup [15]. It is of course possible to change the dummy
value during the installation and store the authorization value on disc. This would make
the TPM useless to all other applications though, since the password resides with the
application and not with the user.
An analysis of how the TPM operates is required to see if keeping the dummy value
even after the installation is a vulnerable approach. At a first glance it seems like giving
public access to the wrap key would immediately authorize anyone to decrypt the private
keys. Luckily that is not the case. The SRK is a so called storage key (see key types in
2.2.3 on page 8) which means that it is not allowed to decrypt generic data for the user.
Storage keys are only allowed to be used for internal decryption of loaded keys. The
TPM_Decrypt command simply fails if a storage key is used as key parameter.
Consequently, even if an attacker has access to the encrypted user key blobs and knows
the SRK authorization value it is impossible to decrypt the keys. Referring back to Figure
4.1, even if the SRK can be used to decrypt and load user keys with the dummy
authorization value the user keys cannot be used for decryption without knowing their
authorization value.
4.4.2 Key Blob Storage Alternatives
The protected storage structure of the TPM demands that the encrypted keys be stored
outside the actual chip. There are two possible storage mediums for the key blobs. The
first alternative is the so called system area of the PPBE. It is a relatively space limited
area on the hard disc with an own file system. The other alternative is directly in the even
more space limited NV memory of the TPM. Remember the minimum size of the NV
memory is set as low as 1280 bytes in [28].
Before an adequate decision could be made, the maximum number of key blobs and
their sizes needed to be determined. Pointsec currently allows for fifty simultaneous users
giving a possible need of storing fifty keys. An analysis of the key blob received from the
TPM when exporting a key is shown in Figure 4.2:
17
When using the notion password it is implied that the 20 byte AuthData is derived by hashing a possibly
shorter password.
24
Entity:
TPM key info:
Public key:
Encrypted blob:
Space (bytes)
47
SK (key size)
256
Figure 4.2 Anatomy of a TPM key blob
The first 18 47 bytes is a TPM specific key info structure containing different properties of
the key. The second part is the public portion of the key in clear text. Since the public
exponent is fixed to 2 16+1 only the public modulus n is included and the required space is
equal to the key size. The last part is an encrypted TPM_STORE_ASYMKEY structure
(defined in [33]) which contains both the private key and its authorization value. Since
the SRK has to be a 2048-bit key data blobs encrypted with the SRK will be 256 bytes
long. From this table it is easy to conclude that the size of the key blob SKB is determined
by:
SKB = 47 + SK + 256
A corresponding table for the different common key sizes is given below.
Key size (bits):
512
1024
2048
Space (bytes):
367
441
559
Figure 4.3 Key blob sizes for corresponding RSA key sizes
Using the default key size 1024 bits the required disk space to store fifty keys would be
approximately 20kb19. Worst case scenario with only 2048-bit keys would need about
28kb. It is easy to see that there is no guarantee that such an amount of data would fit
onto an arbitrary TPM with a minimum of 1280 bytes storage. It is also a bit impractical
to use the NV memory space from a user interface point of view since NV usage requires
owner authorization. User interaction should be kept to a minimum so owner password
input should definitely be avoided if possible. Storing the encrypted key blobs directly on
the TPM with owner password protection gives an extra level of security but is not
qualitatively different from storing them on disk since the TPM regards everything in the
NV memory as opaque data.
18
The key information is not exactly the first 47 bytes of the key blob. Look at the TPM_KEY structure in
the TPM Specification Part 2, Structures.
19
kb as in kilo bytes.
25
4.5 Tpmutil Implementation
4.5.1 Interface Decision
In making the decision to use a TSP many factors were considered. The ideal would have
been to use MS-CAPI together with the vendor provided CSP. However MS-CAPI is an
abstract high-level interface and therefore only supports a subset of the TCG Software
Stack (TSS).
With MS-CAPI it is for instance impossible to decide on which parent key should
be used for wrapping. When loading the key blob into the TPM to use the key, the calling
application needs to know both the id and authorization data for the parent key. If the
parent key is unknown it is of course impossible to use the wrapped key. The encrypted
private keys exported from the CSP are furthermore not compatible with the
TPM_STORE_ASYMKEY structure mentioned in Section 4.4.2 on page 24. For the
TPM to load a key the authorization value needs to be in the encrypted blob as well.
The other alternative, to use a lower level interface like the TSS Core Services
(TCS) or TCG Device Driver Library (TDDL) is just unnecessary. The same operations
can be performed with a TSP making the solution less prone to errors.
4.5.2 Structure
tpm_util.c, tpm_actions.c, tsp_int.c
The command line functionality of the program is implemented in tpm_util.c. From
there, functions (implemented in tpm_actions.c) performing the chosen action are
called. These functions in turn use the TSPI which is abstracted in tsp_int.c. This file
handles the linking with the TSP dll and declaration of all TSPI functions.
4.5.3 Functionality
tpm_actions.c
The primary tasks of tpmutil are to create RSA key pairs for new users and generate
corresponding verifiable certificates to the user certificate store. Certificate stores and the
CA concept are presented in Appendix A.3. Together with every key blob a SHA-1 digest
of the username is stored. This is to tell the PKCS#11 library which key to load and use
when C_Login is called. In addition the program needs to store the generated key blobs
in the system area (or on the TPM) and needs to be able to change user passwords. In
order to achieve this some additional support functionality is required.
Before any key generation can be done, TPM ownership needs to be taken and the
SRK authorization value needs to be set. To be able to generate verifiable certificates, a
self-signed CA certificate is first created and added to the root certificate store. The CA
26
certificate is then used to sign and verify the user certificates. All certificate parsing and
creation is performed using a WIN32 version of OpenSSL20.
4.5.4 Users’ Guide
The different command line options for tpmutil are listed below:
-to
-ca
-gk
-ks arg
-cp
-dll
-?
Take Ownership
Generate CA certificate and write it to the root certificate store
Generate a user key
Choose bit key size for –gk option (default is 1024)
Change a user password
Set path to the TSP dll, the default is tsp.dll
Display the help text.
The order is somewhat thought to demonstrate in which order different actions should be
performed. First ownership needs to be taken and a CA certificate created. After that it is
possible to add users (generate user keys).
4.6 Pre-boot Implementation
The pre-boot parts rewritten for the TPM were a “smartcard reader dummy driver”
reader.bin and the PKCS#11 library p11.bin. The only interesting part from a
theoretical point of view is p11.bin which contains the PKCS#11 library for the TPM.
For TPM purposes the reader.bin module needs only to be a dummy smartcard reader
which returns dummy IFD function pointers since there will be no smartcard
communication. The dummy reader is presented in Section 4.6.1 and the rest of the
chapter is devoted to the design of the PKCS#11 library.
4.6.1 Reader.bin
pinit.h, ifdhandler.h, ifdhandler.c
The interface for passing the IFD Handler function pointers is defined in pinit.h.
However the IFD function pointers are not needed by the prototype PKCS#11 since no
smartcard communication is performed. Instead p11.bin accesses the TPM directly
using the device driver described in Section 4.3.3 on page 22. Therefore reader.bin
was implemented as a dummy smartcard reader returning empty function pointers to
make the PPBE believe there is a smartcard present.
20
OpenSSL is an open source implementation of the SSL (Secure Sockets Layer) protocol which contains
certificate handling functionality.
27
4.6.2 MuscleCard Plug-in
p11*.c, musclecard.c, tpm_plugin.c
The interface implementation is built on an open source framework called MuscleCard
for using smartcards across multiple platforms [3]. Included in the MuscleCard suite is a
PKCS#11 implementation which has been used as a base for the TPM PKCS#11 library.
All smartcard dependency has of course been removed and has been replaced with TPM
communication. However, as much code as possible, including all session and transaction
handling was left untouched in order to save time and avoid unnecessary errors. The
PKCS#11 functions are defined in the source files with the prefix p11 and the
MuscleCard interface is implemented in musclecard.c.
In order to achieve the dependency change as clearly as possible the TPM specific
code has been placed in a so called MuscleCard plug-in (tpm_plugin.c). The
MuscleCard API looks for inserted smartcards and loads their corresponding plug-in via
their ATR string21. Even though we know that the TPM is not a smartcard, a special TPM
ATR string needs to be used in order to load the correct plug-in. The MuscleCard
functions in musclecard.c calls the corresponding plug-in functions which then in turn
access the TPM as described in Figure 4.6.
4.6.3 TPM Access Architecture
TpmAccess.cpp, ViaWindows.cpp, ViaLPC.cpp
To facilitate simple change of actual access method to the TPM, a small C++ class
hierarchy was defined. The base class TpmAccess was specified containing virtual
methods which must be implemented by all subclasses. In order to keep the differences at
a minimum, as much code as possible was placed in TpmAccess.cpp. The class
hierarchy is displayed in Figure 4.5.
TpmAccess
ViaWindows
ViaLPC
ViaBIOS
Figure 4.5 Class hierarchy for the TPM access classes
The virtual methods implemented by the subclasses, besides the constructor and
destructor are:
§
21
TPM_Connect – Initializes the TPM connection.
ATR – Answer to Reset is a byte string uniquely identifying a smartcard type.
28
§
§
TPM_Disconnect – Closes the TPM connection.
TPM_TransmitData – Sends and receives a TPM command
The ViaWindows class is used for development and debugging and was compiled using
Visual Studio. For accessing the TPM it uses the vendor provided TCG Device Driver
Library (TDDL). The reason for using TDDL and not a higher level interface is to make
the transition between access methods as smooth as possible. TDDL includes the function
Tddli_TransmitData which allows the caller to send byte commands directly to the
TPM. The Windows p11 library is compiled together with p11_test.c in order to make
an executable for testing. An excerpt from p11_test.c is given in Appendix B.3;
basically it is a simplified simulation of the cryptographic actions taken by the PPBE
during pre-boot authentication.
The ViaLPC class is the “real” TPM access point and is thus compiled with DJGPP
into the p11.bin which is used by the PPBE. Its structure is very similar to the
ViaWindows class with the difference that transmit_data from the device driver is
called instead of Tddli_TransmitData from the TDDL. Before TPM_TransmitData
can be called the device driver needs to be initiated. This is done when calling
TPM_Connect. The decision between using ViaWindows or ViaLPC is made during
compile time depending on compiler set macros.
The class ViaBIOS is not fully implemented. It only contains empty function
headers, hence the dashed connector. It is possible that future BIOS versions will support
the INT 1Ah interface. If TPM support is to be incorporated into Pointsec for PC using
the INT 1Ah interface would be preferable.
4.6.4 Special Coding Adaptations
libc.a, Bridge.cpp
In the pre-boot environment no functions leading to DPMI22 calls (malloc and printf
for example) can be used. Therefore the code is not linked with the normal libc.a23 but
with a slimmed down version of the library containing only the C functions we need (and
can use). The new libc.a library is created dynamically from the makefile using the
DJGPP (originally UNIX) command ar.
Even though DPMI calls cannot be made it is still possible to allocate memory
dynamically. PPBE specific versions of the C functions malloc and free have been
implemented previously. Function pointers to these special purpose allocation functions
are passed to both reader.bin and p11.bin during initialization. The function
pointers are passed as parameters to PKernelInit in ppbe_util.c. Referring to Figure
22
DPMI or Dos Protected Mode Interface is the way Microsoft prescribes for a DOS program to run in
protected mode.
23
libc.a is the standard C linking library in DJGPP and contains commonly used functions like strlen ,
printf
etc.
29
3.2 on page 18, the function pointers follow arrows downward from the PPBE to the
drivers.
MuscleCard plug-ins are by default written in C and the TPM access class hierarchy
is written in C++. This implies a need for calling C++ functions and creating C++ objects
from C. Calling C++ functions from C is relatively straightforward. It is only a matter of
declaring the needed functions in the C++ header file with the keyword extern C and
taking care of some macro conditions. To create C++ class instances from C is a bit
trickier. It is possible to create a C struct corresponding to the C++ class and apply
some workarounds, but in this case it was easier to create a C++ non-class file
(Bridge.cpp). The functions in Bridge.cpp are called from the plug-in, and they in
turn instantiate the appropriate TPM access class.
The code for the pre-boot environment is linked24 without the use of any standard
libraries. Therefore the C++ operators new and delete had to be overloaded. This was
easily done in Bridge.cpp using the new versions of malloc and free received in
ppbe_util.c.
4.6.5 TpmAccess Class
TpmAccess.cpp
Combining the descriptions in Sections 4.6.3 and 4.6.4 the complete information flow
following a PKCS#11 call involving the TPM is illustrated in Figure 4.6.
Calling
application
Bridge
function
PKCS#11
function
MuscleCard
TpmAccess
subclass
TPM
plug-in
TPM
device
Figure 4.6 Information flow during a PKCS#11 function call.
The TpmAccess base class was designed with the intention to minimize the differences
between its subclasses. Most of the non-virtual methods in TpmAccess are direct
mappings of TPM byte commands like TPM_OIAP and TPM_LoadKey.
A non-intuitive arrangement that might need some explanation is how the password
is verified. When C_Login is called (with username and password as described in
Section 4.4 on page 23) the first thing that happens in TpmAccess is that the key is
loaded into the TPM. This operation does not require the authorization value for the key
24
Linking is the process where a linker takes one or more objects generated by a compiler and puts them
together to make an executable or a new library.
30
but only for the SRK. In order to verify the authorization value (hash of the password) an
operation that uses the key need to be attempted. The simplest command which demands
key authorization data is TPM_GetPubKey, which retrieves the public key from a key
previously loaded into the TPM. Therefore a call to TPM_GetPubKey is attempted even
though we already have the public key. If this results in an authorization failure the
password is incorrect. All TPM command responses are of course verified using the
HMAC protocol described in Section 6.3.1 on page 37.
4.6.7 Objects and Functions Supported
The implemented PKCS#11 library supports search for the following objects defined in
[20]:
§
§
CKO_PRIVATE_KEY
CKO_PUBLIC_KEY
However there is no support for encrypting data with public keys found since there is no
functional requirement for such a possibility. Of the functions described in [20] the
following have been implemented and can be counted on to function properly:
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
§
C_GetFunctionList
C_Initialize
C_Finalize
C_GetInfo
C_GetSlotList
C_GetSlotInfo
C_GetTokenInfo
C_OpenSession
C_CloseSession
C_CloseAllSessions
C_FindObjectsInit
C_FindObjects
C_FindObjectsFinal
C_GetAttributeValue
C_Login
C_Logout
C_DecryptInit
C_Decrypt
31
5 Manageability
Manageability in the context of this report means the ensuring of the continued health of
a software system with respect to performance, scalability, reliability, availability and
security. With regard to a TPM enabled disc encryption system, manageability involves
topics such as installation procedure, recovery after hardware failure or password loss
and various administration issues. The goal of this chapter is to identify and propose
solutions to manageability problems which will be encountered if incorporating TPM
support into Pointsec for PC.
5.1 Interoperability
A fundamental problem which cannot be avoided is how to deal with different TPM
models and TSS versions. As discussed was in Section 4.3 on page 20 low level access to
the TPM in a pre-boot environment is not standardized but is vendor dependent. This
creates a situation where a unique driver needs to be developed for every TPM. It is
possible that in the future a currently specified but not implemented BIOS interface can
be used (see Section 4.3.2 on page 22).
Another similar problem is that different computer vendors use different software
stacks (TSS). Unfortunately, even though TSS is standardized it seems like there are
some discrepancies between different TSS implementations. The prototype code for
instance works on the NTRU TSS but fails when using the IBM TSS. A possible solution
is to use TDDL directly and basically write a small TSP yourself. An immediate problem
with that solution is that the vendor provided TSS most likely will lock the TDDL and
prevent other applications to gain access to the TPM. The application would then have to
identify the name of the TCS NT service and shut it down with the Windows NT system
command NET STOP. Another problem is that not all TDDL implementations export
identical function names. This issue is however simply solved by checking the TDDLs of
all vendors manually and hardcode the different function names.
5.2 Administration
Currently when adding a new Pointsec user, “smartcard” can be specifically chosen as
authentication type. Adding a TPM option in the dialog would be the intuitive way of
incorporating TPM support. Typically a dll could then be called which would create the
necessary keys and return the public key used for encryption. The modularization would
minimize the changes needed in the current product and give a flexible structure.
If the TPM is disabled or deactivated during the installation phase TPM accounts
can not be created. In order to use the TPM it must currently be enabled/activated by
changing settings in the BIOS. As is further discussed below it is not possible to ask a
normal user to perform such actions.
32
5.2.1 User Transparency
An overall design goal of any successful (disc encryption) system is user transparency.
One can not assume that a typical user will be familiar with concepts like keys,
certificates and dll files. The user factor must be considered in all design decisions made
about the application’s interface. Some TPM actions unfortunately require physical
presence assertion directly from BIOS (see Section 6.2 on page 37). Changing settings in
the BIOS is well beyond what can be expected from the normal user. It is possible that
the use of the BIOS will change in the future. The problem with user transparency must
apply to all applications which possibly could make the TPM designers choose another
path. Otherwise a separation of responsibilities must be made between the user and the
system administrator. Accessing and using the BIOS is no problem for a system
administrator. Such a solution is however not optimal, the less mandatory involvement of
the system administrator, the better. For the sake of prototype development accessing the
BIOS was of course not a problem but it should not be underestimated if integrating the
prototype into a commercial product.
5.2.2 TPM Ownership
As mentioned before, a TPM must have an owner in order for protected storage to be
enabled. This is due to the fact that the SRK is created when the TPM_TakeOwnership
command is issued. The basic provision for the prototype to work at all is knowledge of
the SRK authorization value. As is concluded in Section 4.4.1 on page 23 the best choice,
if possible is to set the SRK authorization value to a dummy value. It is not necessary that
the owner password is known in order to use the SRK as storage key. Ownership
management raises a couple of questions:
§ Who should be the owner?
§ What if ownership has been taken by another application?
§ If the SRK authorization value is not a dummy value, should the current owner
be cleared?
The alternative answers to the first question are the system administrator or the Pointsec
TPM plug-in. The problem with the latter is that it is not hardware based key storage but
sophisticated obfuscation. This method is unfortunately deployed by some contemporary
TPM management software. The “right” way to do it is that the user has to provide the
owner password every time a command requiring owner authorization is performed.
If ownership has been taken by another application it is likely that the user got no
possibility to choose owner authorization value and very likely no option to choose the
SRK authorization value. In such cases it is impossible for the TPM plug-in to use the
SRK to wrap keys. The creation of TPM accounts should be disabled and the user asked
to clear the current owner via the BIOS or some middleware in order to use the TPM. Of
course the user should get a reminder that all data stored with the old keys will be lost.
If the SRK exists and its authorization value is not a dummy value the user should
be asked to clear the current owner so the plug-in can set the “right” authorization value.
33
5.3 Recovery
A necessary feature of any encryption software system is recovery of encrypted data in
the case of an unexpected accident. Such accidents include password loss, TPM or
motherboard failure and hard disc crashes. In Section 2.4.2 on page 14 the notion of
migratability was introduced. The easiest way to back up a key stored by the TPM is to
make it migratable and export it to another TPM, typically one belonging to the system
administrator. Three requirements have to be fulfilled to export a migratable key.
§ A public key (received from the destination TPM) used to encrypt the migration
blob has to be present.
§ The owner of the source TPM must authorize usage of that particular public key.
§ The key specific shared secret authorizing migration called migrationAuth
needs to be presented.
Only the “private parts” of the key pairs are migrated since the public parts are not
security sensitive. Migration is supported on the lowest command level as well as by the
TSS.
5.3.1 Loss of Password
Normally the problem with lost passwords is resolved through a single sign-on feature in
the Pointsec product family called Remote Help. Using this function administrators can
help authorized users to gain access to their encrypted data through a challenge-response
protocol even if the communication needs to take place over an insecure channel. This
requires an administrator account to be installed in parallel with the TPM account. When
logged in again the user can delete the TPM account and create a new one. The problem
with this approach is that the partition encryption key is no longer hardware protected
since there is a software based administrator account as well. To overcome this problem
the TPM key could be migrated to an administrators’ TPM. If the administrator use a
different password (authorization value) for the key then the user does, user password
loss will not matter. A related problem is that another application has been authorized by
the user to change the SRK authorization value. The easiest action is to ask the user to
enter the BIOS and clear the TPM encryption keys and then re-install the TPM account.
This would however render encrypted data stored by other applications inaccessible.
5.3.2 TPM or Motherboard Failure
If the TPM or the motherboard crashes it is of course impossible to use the TPM
anymore. This requires the TPM to be replaced and makes the TPM account useless. The
Remote Help procedure can be used with the difference that a new TPM need to be
installed before any new TPM account can be installed. Another possibility just as in the
last Section migration of the user keys to an administrator TPM. That TPM can then be
used to decrypt the partition encryption key.
34
5.3.3 Hard Disc Crash
This is the most complicated problem. The way Pointsec resolves hard disc failure and
other similar hardware problems is through the creation of a recovery boot disc. On the
boot disc the encryption keys are stored protected by passwords. In this way even if the
computer will not boot normally due to for instance a corrupt file system you can always
use the boot disc. A utility on the boot disc then decrypts the hard disc and non-corrupted
data can be retrieved. This procedure does not work if the user has lost his password. The
TPM user keys can only be decrypted by the SRK inside the TPM. Therefore the TPM
key blobs need to be stored on the recovery disc and then be loaded into the TPM if it is
still intact. The key blobs as such are already password protected but could be doubly
encrypted to comply with normal recovery disc usage.
35
6 Security Analysis
A key factor in evaluating the TPM is its protection against attacks. There are several
different strategies an adversary could try in order to compromise a TPM based security
system. Examples of such attempts are dictionary, replay and hardware attacks. An
alternative to the use of TPMs are smartcards and a comparison focusing on security
aspects is included in 6.5.
6.1 Dictionary Attack Considerations
One possible problem with authentication based solely on presentation of an
authorization value is possible lack of entropy in this secret. The authorization value is a
160-bit number giving 2160 (approximately 10 56) possible combinations which is too huge
a number for a brute-force attack25. However if the authorization value is derived from a
password using a hash function to produce the 160-bit number the protection is not better
than the password. An attacker could write software performing some kind of dictionary
attack26 on the authorization value. Using a PKCS#5 key derivation function (instead of a
normal hash function) would slow the dictionary attack down but not prevent it. Some
kind of hardware protection against this kind of attack is required but not specified in the
TPM Specification [32]. The specification states that:
“The TPM SHALL incorporate mechanism(s) that will provide some protection against
exhaustive or dictionary attacks on the authorization values stored within the TPM.”
A possible protection scenario could be that the TPM kept track of failed authorizations.
When the count would go over a specified threshold the TPM would lock up and not
respond to commands for a certain period of time. This lock-out protocol is implemented
in the Atmel AT90SP0801 TPM 1.1 with an exponentially increasing lockout time [17].
The lockout periods follow the simple schedule:
1.2, 2.4, 4.8,… min
The thresholds are set at every 32nd failure. It is very likely that other TPM manufacturers
apply the same kind of procedure even though it is not documented. Both the ST
Microelectronics 1.2 and the NSC 1.1 chip lock up when presented with repeated,
erroneous access attempts.
An important command to mention is TPM_ResetLockValue. This command
requires owner authorization and resets the failure count and lockout period. If an
attacker would gain access to the owner authorization value it would be possible to
25
A brute force attack simply consists of trying all possible keys in the key space.
26
In a dictionary attack a range of passwords are tried from a dictionary database.
36
launch dictionary attacks on other TPM resources using TPM_ResetLockValue
whenever the chip locked up.
6.2 Physical Presence
In order to prevent remote rogue software to take control of the TPM some operations
require assertion of physical presence. The thought behind including such a requirement
is that an entity with physical access to the platform is more trustworthy than an arbitrary,
local or remote process. The types of operations requiring physical assertion are:
§ Clearing an existing owner from the TPM.
§ Temporarily deactivating the TPM.
§ Temporarily disabling the TPM.
The reasons for these choices are quite intuitive. Clearing the existing owner gives the
possibility to install a new one and hence take complete control over the TPM.
Deactivating or disabling the TPM removes any protection features provided by the chip
and such actions should only be available to the owner and to the physical platform
operator. The latter plainly meaning someone with physical access to the platform. The
actual implementation approach on how to assert physical presence is platform dependent
and left to the TPM and platform manufacturer. For PCs the typical way of asserting
physical presence is to change settings in the BIOS. The TPM specification [32] also
mentions the possibility to change a hardware switch but this approach seems not to have
been favoured by manufacturers. The whole concept of physical presence is a bit
problematic since user transparency is a key to building user friendly applications. The
inconvenience with compulsory BIOS’ setting changes was already mentioned in 5.2.1.
6.3 Command Eavesdropping
An intuitive way of attacking any hardware based security solution is of course through
its I/O interface. In order to provide functionality to the platform and its user the TPM
has to send and receive information. One has to assume that a possible attacker have the
possibility to eavesdrop on this communication. In order to keep authorization data such
as passwords confidential so called authorization sessions are used.
6.3.1 Authorization Sessions
As has been mentioned when discussing TPM ownership all access to TPM protected
resources, such as keys, certificates etc. are authorized through the presentation of the
authorization value for the entity in question. Some operations, such as changing the SRK
authorization value require owner authorization as well. It is not safe to send these secrets
in plaintext but they have to be encrypted.
Another communications problem is data integrity (see Appendix C). Even if the
correct authorization value is presented asserting that the command issuer is an
37
authorized application, the TPM cannot be certain that unencrypted input data is
unaltered.
To be able to discuss confidentiality issues regarding command in- and output, the
TPM command structure needs to be presented. On the lowest level, commands sent to
the TPM are represented as byte streams on the I/O bus. A schematic view of the input
and output byte blocks is given below. It should be noted that the TPM uses big endian27
byte representation for all its operations [33]. This is in accordance with internet standard
but for instance the Intel x86 CPU family uses the opposite; little endian.
Figure 6.1 Schematic view of Input and output byte blocks for TPM commands
UINT16 tag
Type of command or response.
UINT32 size
Block size including header and possible authorization parts.
UINT32 ordinal
Unique command or response identifier.
UINT32 result
Return code of the operation, 0 implies success.
Every small block in Figure 6.1 represents one byte and the command is to be sent in the
order it appears in the figure. The upper part is the input sent to the TPM and the lower
part is its response. The structures of the headers are identical for all commands even
though they will contain different data. The authorization parts are optional depending on
whether the command requires authorization or not. Some commands require both owner
and entity authorization, hence auth1 and auth2.
The problems of data integrity and sending plaintext authorization values are solved
through the use of HMAC (see Section 2.3.2 on page 10 or Appendix C.2). In principle a
SHA-1 hash of the in-parameters are fed into an HMAC function using the authorization
value for the requested entity as HMAC key. The resulting message digest is then sent as
one of the parameters in the authorization part. When the TPM receives the command it
27
Big endian (or human readable) byte representation means that the most significant byte is stored first.
For example the number 270 would be stored as {0x01, 0x0E}. In little endian 270 would look like {0x0E,
0x01}.
38
calculates the HMAC digest (not the SHA-1 digest) for the in-parameters using yhe
shared authorization value as key and compares the value with the one received. If they
match the application sending the command knows the authorization value and in
addition the in-parameters have not been tampered with. The same procedure applies of
course for the output information sent from the TPM to the calling application. An
illustration of the principle is shown below in Figure 6.2.
User
TPM
Check HMAC digest
inparams
HMAC(inparams)
outparams
HMAC(outparams)
Check HMAC digest
Figure 6.2 Illustration of a command authorization session
This basic approach is however vulnerable to replay attacks. In a replay attack an attacker
issues a copy of a command previously sent on the communication line. To prevent such
a possibility a so called rolling-nonce scheme is deployed. The idea is that the byte
stream for every new command sent should be unique even for multiple use of the same
command ordinal with identical parameters. The uniqueness is achieved by concatenating
a random number (nonce) into each HMAC input giving the formula:
HMAC(params) = HMAC AuthData(params || nonce)
The nonce to be used the next time is always included in the current input or output
block. This results in that re-sending an eavesdropped command will not work since the
nonce will not be the same as it was the last time the command was sent.
The initial nonce is determined by sending a request for starting an authorization
session. The two main authorization protocols are called Object Independent
Authorization Protocol (OIAP) and Object Specific Authorization Protocol (OSAP). The
OIAP is the typically used session type and can be used for authorized access to multiple
entities in one session. The downside is that when accessing the same entity more than
once the authorization value is exposed (through involvement in the HMAC calculation)
more than necessary. In an OSAP session only one entity can be accessed but multiple
times without using the authorization value more than once. The OSAP session type is
mandatory for operations requiring owner authorization or for setting or resetting
authorization data.
39
6.3.2 Transport Encryption
Even though data integrity and confidentiality are preserved and replay attacks are
prohibited, sending command parameters in plaintext might not be optimal in several
circumstances. An example is that it is unnecessary to give an adversary knowledge of
program flow and operation by sending the command identifier tags in plaintext.
Therefore the notion of transport encryption was introduced in the TPM 1.2 specification.
When using transport encryption the command parameters are wrapped using a stream
cipher. The transport sessions resembles the normal authorization sessions in that it uses a
rolling-nonce scheme. No in-depth description will be given here but transport encryption
should be used by the pre-boot module since the decrypted partition encryption key
otherwise would be sent from the TPM to the user in plaintext.
6.3.3 SHA-1 Vulnerability
The SHA-1 hash algorithm (see Appendix C.2) pervades all parts of TPM usage.
Recently much attention has been paid to possible collision weaknesses of SHA-1 (and
similar) hash functions. In the light of that the choice of SHA-1 as exclusive hash
algorithm might seem a bit unfortunate.
Wang et al. [36] has showed that it is possible to find collisions for SHA-1 with a
calculation complexity less than 269 hash operations. Wang has also announced finding a
method using 2 63 operations but no paper is available yet. SHA-1 uses a 160-bit hashvalue which gives a theoretical 280 upper bound on the number of calculations needed to
find a collision. Wang’s result is not a lower bound on the complexity so there is no
reason to believe that it is impossible to improve the result even more. Brute force
calculations requiring 264 operations have already been performed by super computers
which indicate that a replacement of SHA-1 would be to prefer.
It is difficult to anticipate how the TCG will react to this development. It is possible
that SHA-1 will be replaced in future versions of the TPM specifications. The
trustworthiness of digital certificates is directly dependent on the collision resistance of
the hash function, whereas HMAC is not [11]. The critical HMAC property is that
finding the key used to produce a certain digest (using a brute force attack) must be
computationally infeasible. With 160-bit authorization values brute force still requires
2 160 operations independent of the weaker collision property. Consequently the recent
discoveries regarding SHA-1 collisions are not a major concern for the prototype
implementation in this project.
6.4 Hardware Attacks
In general, hardware protected data is safer than software protected. Hardware attacks
require physical access to the device, expert knowledge and sophisticated laboratory
equipment. Software protected data must be stored on an unprotected storage device such
as a hard disc giving for instance a possibility for remote attacks. A hardware (or side
channel) attack is based on information gained from the physical implementation of a
cryptosystem, rather than theoretical weakness in the algorithm.
40
There are numerous ways to retrieve hardware protected information. There are two
types of physical attack methods; invasive and non-invasive methods. In invasive
methods laboratory instruments are used to physically recover data from a device using
so called micro-probing. Invasive attacks normally make the analysed chip dysfunctional.
A non-invasive attack does not affect the device in question directly but instead analyses
its behaviour with regard to power consumption, clock cycles etc. The most common
non-invasive attacks are power analysis and timing attacks.
6.4.1 Timing Attacks
In a timing attack the attacker tries to extract keys by measuring the time it takes to
execute cryptographic algorithms. Especially asymmetric algorithms are vulnerable to
this approach since the computation times of operations depend on the private key. A
typical vulnerable feature of algorithm implementation is the execution paths (normal
conditional jumps). Depending on various properties of the key, different paths of the
code are executed revealing the key’s properties. Kocher [8] designed a timing attack to
extract RSA keys used for decryption; however this approach was not enough to break a
CRT implementation of RSA. Brumley et al. [1] have shown that even using the CRT for
algorithm implementation is not enough to prevent these kinds of attacks.
6.4.2 Power Analysis
In power analysis described by Kocher et al [9] the attacker studies the power
consumption of a cryptographic device when it is calculating. Typical features that can be
seen using power monitoring are the 16 DES rounds and RSA operations. Power analysis
can be used to break RSA implementations by “revealing differences between
multiplication and squaring operations” [9]. There are two types of power analysis;
Simple Power Analysis (SPA) and Differential Power Analysis (DPA). In SPA the power
consumption of the device is analyzed directly revealing the execution order of
instructions and possibly also secret keys.
Figure 6.3 SPA monitoring of a smartcard performing DES encryption, measured by Kocher et al.
41
In Figure 6.3 by Kocher et al, SPA monitoring of a smartcard28 performing DES
encryption is displayed. The upper graph shows the whole operation. It is surprisingly
easy to identify the initial permutation, the sixteen DES rounds and at the end the final
permutation. The lower graph displays the second and third DES round. Even though the
principal pattern is the same the two peaks are far from identical. From these differences
it is possible to determine which execution path that was chosen for that particular round.
DPA is a more sophisticated and powerful tool than SPA. SPA is primarily based on
visual inspection and is vulnerable to obfuscation29. DPA on the other hand is based on
statistical analysis and error correction making it less sensitive for input obfuscation. The
statistical operations used in DPA even make it possible to trace such small power
consumption changes as switching of individual transistors.
6.4.3 Invasive Attacks
It is currently not apparent which kind of invasive attacks might be applicable to the
TPM. The chip is not yet extensively used which makes it relatively uninteresting for
attackers and researchers. The next paragraph discusses some preliminary background
protection information.
6.4.4 TPM Vulnerability
There are numerous different ways of preventing side channel attacks but what is more
interesting is whether or not any such methods actually are implemented in the TPM. One
of TCGs main design goals was to make the TPM cheap to manufacture which prevented
the most advanced tamper protection from being implemented.
Statements from TCG members and contributors clarify the intents. A quote from the
report Clarifying Misinformation on TCPA [21], by IBM researcher David Safford reads
as follows: (This report is dated in 2002 and consequently only deals with TPM 1.1.)
“TCPA chips have not been designed to resist local hardware attack, such as power
analysis, RF analysis, or timing analysis.”
In the Common Criteria Protection Profile for the TPM 1.1 [2] it is stated that
“The TOE [the TPM] provides tamper evidence only. It provides no protection against
physical threats such as simple power analysis, differential power analysis, external
signals, or extreme temperature. Physical protection is assumed to be provided by the
environment.”
28
A smartcard is a removable cryptographic token used to store user authentication data. Smartcards are
further discussed in Section 4.5 as a competitor to the TPM.
29
The term obfuscation means to conceal the meaning of information by making it confusing and harder to
interpret. In this context obfuscation for instance could mean to execute unnecessary parts of the code to
avoid conditional jumps and hide the value of the key.
42
There is no indication in the TCG 1.2 specifications that the physical protection should be
increased, so the statements about TPM 1.1 are still relevant. The document Business PC
Security Solutions by HP has a more pragmatic view on the issue [5]:
“The TPM protection profile requires some physical protection on the TPM. It does not
specify the mechanism in which the manufacturer needs to design. The TPM manufacturers
are familiar with creating security chips. We anticipate that some TPMs will have stronger
physical protections than other mechanisms. The market will determine what is
appropriate.”
To conclude the discussion is an excerpt from a Microsoft report on its next generation
operating system Windows Vista [15] (formerly called Longhorn). This comment aims at
the TPM 1.2.
“Although TPMs are designed to resist tampering or electrical analysis, they are
susceptible to certain physical forms of attack. However, performing the kind of analysis
needed to uncover TPM-protected secrets requires physical access to the machine and
additional hardware, making secrets on a TPM-enabled platform more secure than those on
a software-only system.”
These statements give the impression that there is protection implemented but that it is not
sufficient to stop a determined attacker with resources. However the TPM should be judged in the
light of other alternatives such as smartcards, and bearing in mind what kind of security level is
economically defendable.
6.5 Smartcard Comparison
A highly relevant issue is a comparison to available alternatives. The currently most
apparent competitor to the TPM is the smartcard.
6.5.1 Introduction to Smartcards
A smartcard or Integrated Circuit Card (ICC) is a flat, plastic body containing integrated
circuitry. Smartcards are normally credit card sized and com in two different kinds;
memory and microprocessor cards. In addition to storage capabilities the microprocessor
cards also includes calculation components like a crypto processor. This discussion
focuses on smartcards used for authentication on a computer platform. These cards are
attached to the computer via a smartcard reader and provide cryptographic functionality
like RSA encryption and key storage. Access to resources on the smartcard is protected
by a secret pin code. A smartcard is only designed to have one user.
43
6.5.2 Main Differences to a TPM
A smartcard is a removable token while the TPM is physically attached to the platform.
This gives the two devices quite different views on users and platforms. In Figure 6.4 the
different mapping structures for the devices are displayed.
Smartcard
1
1
User
TPM
∞
∞
1
1
Platform
∞
∞
Figure 6.4 Mapping structure between smartcards, TPMs, users and platforms.
As was already mentioned there is a one to one mapping between a smartcard and its
user. A single smartcard can authenticate the same user on many platforms meaning a
one to many mapping. Each platform has only one TPM and a TPM can only be attached
to one platform giving a one to one mapping. Finally a platform must be able to support
multiple users meaning that there is a one to many mapping between a TPM and the users
of the platform. From a security perspective the mobility of the smartcard has both
positive and negative sides. On the one hand it is impractical to need a card every time
you log into your computer and a small card is easy to lose by accident or theft. On the
other hand, if the platform is stolen there is no way to gain access if the smartcard is not
present. A TPM is always present which makes it even more important to protect TPM
content.
Another difference is that a smartcard stores all keys on the actual device. A TPM
only stores the SRK and uses it to wrap other data which is then stored on an unprotected
storage device.
A clear advantage for the TPM is its low cost profile and simple use. Smartcards
requires readers which cost money and are not too practical to carry around either. A
conceptual difference is the ability of the TPM to use machine binding of resources.
6.5.3 Physical Protection Comparison
The types of physical attacks are the same for smartcards as the ones discussed in Section
6.4 on page 40; invasive and non-invasive attacks.
The vulnerability for non-invasive attacks is basically the same for TPMs and
smartcards. The need for knowledge of the design remains. Both devices are relatively
44
small and have no electromagnetic shielding or integrated batteries for better protection.
A clear advantage for the TPM is that it is attached to the motherboard and does not
require a reader. This makes it harder for an attacker to control the clock and power
supply to the chip. A major security problem with smartcards is that non-invasive attacks
on smartcards with known low level design can be performed using a “fake” reader
which extracts secret key information while the card is performing calculations. This is
particularly dangerous since it provides no tamper evidence. If the keys are stolen without
the owner noticing there is no possibility to revoke their validity. The information needed
to construct such a fake reader can be determined on an unknown card using microprobing. Once the structure of the card has been determined, the building of a reader
which stores secret authentication data is possible.
These advantages will further increase if the TPM is integrated into the CPU, which
is said to be the future plan. In general smartcards are quite vulnerable to non-invasive
attacks. Kocher et al [9] wrote 1998 that they had found some commercially available
products which resisted SPA but none that resisted DPA. That is however seven years
ago and new obfuscation designs are certainly available, however obfuscation solutions
are bound to be broken.
Using invasive methods on smartcards is a relatively well investigated area. The
goal of the attacker is to analyse and simulate the operation of the card to reveal
information like secret keys. The method is described in-depth in Design Principles for
Tamper-Resistant Smartcard Processors by Kömmerling and Kuhn [12]. They estimate
that a patient low-budget attacker could gather used micro-probing equipment to launch a
successful attack for under $10 000. For future smartcards a micro-probing workstation
might not be enough. Features below the wave-length of visible light and more metal
layers might require more advanced equipment like different forms of advanced beam
technology. However such equipment is not only very expensive but also require
specially trained professionals to operate them.
6.6 Key Quality
As was mentioned in Section 2.3.5 on page 11, the generation and prime-number testing
of RSA keys must follow the IEEE P1363 standard. This together with using 2048-bit
keys ensures the key quality.
The main factors determining the quality of symmetric keys is the RNG and the key
length. An assessment of the RNG used by the TPM is given in the Trusted Mobile
Platform Software Architecture Description [6] released by IBM, Intel, and NTT
DoCoMo. They state that:
“In a Security Class 2 or Class 3 Trusted Mobile Device, the TPM’s random number
generation function may be used as the random number source.”
The definitions of Security Classes are given in the quoted document but the relevant part
is that Security Class 3 is the highest one. Hence, according to authors of the article the
45
random data generated by the RNG holds quality high enough to be used in the most
secure kind of Trusted Platforms. This information must of course be regarded with some
scepticism since IBM and Intel are two main members of the TCG.
6.7 Concluding Discussion
Concluding the previous arguments the TPM is secure up to a certain limit. Some known
attacks on smartcards are applicable to TPM technology as well and other possibilities
might exist. It is difficult to estimate the capital and work required to launch a successful
TPM attack since the technology is relatively new and has not received much of attention
from hackers and researchers yet. Successful attacks on software using the TPM have
been launched but that is not relevant for our discussion.
With regards to dictionary attacks on the authorization values, some form of
mitigation is required. Presence of such mitigation has been confirmed on several of the
different TPMs available today.
The newly discovered vulnerability of SHA-1 does not affect the HMAC
authorization sessions used in the prototype but definitely is a problem for attestation
through digital signatures.
A considerable amount of work has been put into the open specifications of the
TPM to give a good base design for hardware security. When compared to other products
providing the same functionality the TPM technology seems like a reasonable choice.
46
7 Conclusion
Both theoretical and practical aspects of TPM usage have been examined in this project.
This chapter summarizes the results and discusses possible ways onward.
7.1 Summary
The three major topics that have been dealt with are manageability, security and
implementation.
With regards to manageability the owner concept of a TPM can be relatively
comfortably dealt with. Installation and deployment interfaces for Pointsec for PC have
been developed and used. Recovery can be performed in basically the same way as
before. A possible problem is user transparency since TPM activation requires BIOS
access. As for interoperability there are a couple of different problems. Unique device
drivers need to be developed for all TPMs and a solution to inconsistent TSS
implementations needs to be found. The design of the TPM authentication procedure
makes interoperability with other applications using the chip somewhat complicated. The
proposed solution is to let the authorization value of the SRK be a dummy value. This
way, all applications can create their own keys under the SRK without locking access for
the others.
In the security analysis the TPM was found to be comparable to smartcards. Nonstandardized dictionary attack mitigation is required by the TCG and has been found to
be implemented for all tested TPMs. In addition different forms of physical protection
have been implemented by some TPM vendors. However for cost reasons the TPM is not
designed to resist sophisticated, laboratory-based physical attacks (and neither are
smartcards). A downside compared to smartcards is that the TPM is mounted to the
platform so the keys are always present for an attacker, though of course in encrypted
form.
Writing a proof of concept plug-in providing TPM enabled disc encryption was
possible in the time frame of the project. However the implementation is fairly
specialized and a fair amount of additional work will be required for possible inclusion
into a commercial product. In general interoperability and non-standardization have been
found to be time consuming problems.
7.2 Outlook
From a general point of view it seems like TPM microcontrollers will play a role in future
computing. Apple uses some TPM support in OS X and as mentioned before Microsoft
plans to use a TPM for the Windows Vista feature Secure Startup. A TPM specification
for mobile devices is scheduled for mid 2006 and the large TCG contributors continue to
put in capital in the area. TPM deployment is even so somewhat of a riddle. Millions of
PC platforms are shipped with TPMs installed but there seem to be no real effort put into
developing applications actually utilizing the chip.
47
From a practical point of view TPM inclusion into Pointsec has been proved to be
possible but several issues remain to be solved. Perhaps the most important and time
consuming is to develop drivers for the different TPM chips. Another problem is the noncompatibility of different TSS implementations discussed in Section 5.1 on page 32. It is
likely though that TSS bugs and ambiguities will be found and removed if TPM usage is
more widely deployed. The BIOS access requirement is however not likely to disappear.
The notion of physical presence is one of the bases of the overall TCG design.
Even if no commercial implementation is developed at the moment it might be a
good idea to keep an eye on the TPM evolvement. The technology is platform
independent and is as such also applicable to Pointsec’s products for mobile devices.
Watching the development might prove useful both from a technical and marketing point
of view.
48
References
[1] BRUMLEY, D. and BONEH, D. 2003. Remote timing attacks are practical. USENIX
Security Symposium, August 2003
[2] Common Criteria Protection Profile - Trusted Platform Module. 2003
http://www.commoncriteriaportal.org/public/files/ppfiles/PP_TCPATPMPP_V1.9.7.
pdf Accessed 2005-12-02
[3] CORCORAN, D. 2002. MUSCLECARD FRAMEWORK – API. 2003
http://www.linuxnet.com/musclecard/files/muscle-api-1.3.0.pdf
Accessed: 2005-12-02
[4] FRATTO, M., 2005. Trusted Computing: Just Wishful Thinking? , Secure
Enterprise Magazine. March 2005,
http://www.nwc.securitypipeline.com/howto/
showArticle.jhtml?articleId=60400957&pgno=1
Accessed 2005-12-02
[5] HP. 2005. Business PC Security Solutions
http://h18004.www1.hp.com/products/security/qa.html
Accessed: 2005-12-02
[6] IBM, Intel, NTT DoCoMo 2004. Trusted Mobile Platform - Software Architecture
Description v 1.00
http://www.trusted-mobile.org/TMP_HWAD_rev1_00.pdf
Accessed: 2005-11-30
[7] IEEE P1363 - IEEE Standard Specifications for Public Key Cryptography. 2005
http://standards.ieee.org/
Accessed: 2005-12-02
[8] KOCHER P. 1996 Timing attacks on implementations of Diffie-Hellman, RSA,
DSS, and other systems. Advances in Cryptology, pages 104–113, 1996.
[9] KOCHER, P., JAFFE, J. and JUN B. 1998. Introduction to Differential Power
Analysis and Related Attacks,
http://www.cryptography.com/resources/whitepapers/DPATechInfo.pdf
Accessed: 2005-12-02
49
[10] KRAWCZYK, H., BELLARE, M., CANETTI, R. 1997. RFC 2104 - HMAC
http://www.faqs.org/rfcs/rfc2104.html
Accessed: 2005-11-30
[11] KRAWCZYK, H., BELLARE, M., CANETTI, R. 1996. Keying hash functions for
message authentication, Advances in Cryptology - Crypto 96 Proceedings, Lecture
Notes in Computer Science Vol. 1109, pages 1-15, N. Koblitz Ed, Springer-Verlag.
[12] KÖMMERLING, O. and KUHN, M. 1999. Design Principles for Tamper-Resistant
Smartcard Processors - Proceedings of the USENIX Workshop on Smartcard
Technology (Smartcard '99), pages 9–20, May 1999
[13] MENEZES, A., VAN OORSCHOT, P., VANSTONE, S. 1996. Handbook of
Applied Cryptography. CRC Press. ISBN 0-849-38523-7
http://www.cacr.math.uwaterloo.ca/hac/ (complete text available online)
Accessed: 2005-12-02
[14] Microsoft, HP. 2005 How To Build Hardware Support For Secure Startup, WinHEC
05 Conference Presentation http://download.microsoft.com/download/9/8/f/
98f3fe47-dfc3-4e74-92a3-088782200fe7/TWAR05010_WinHEC05.ppt
Accessed: 2005-12-02
[15] Microsoft. 2005. Trusted Platform Module Services in Windows Longhorn
http://download.microsoft.com/download/5/D/6/
5D6EAF2B-7DDF-476B-93DC-7CF0072878E6/TPM.doc
Accessed: 2005-12-02
[16] Microsoft Cryptographic API. 2005
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/
cryptography_portal.asp
Accessed: 2005-12-02
[17] National Information Assurance Partnership. 2001. Common Criteria Evaluation
and Validation Scheme Validation Report, IBM Cryptographic Security Chip for PC
Clients Manufactured by ATMEL (AT90SP0801).
http://www.commoncriteriaportal.org/public/files/epfiles/
CCEVS-VID300-VR-01-0005.pdf
Accessed: 2005-12-02
[18] PEARSON, S., BALACHEFF, B., CHEN, L., PLAQUI, D., PROUDLER, G. 2002.
Trusted Computing Platforms, TCPA Technology in Context. Prentice Hall PTR.
352 pp. ISBN 0-13-009220-7.
50
[19] RSA Laboratories. 2002. PKCS #1 v2.1: RSA Cryptography Standard.
http://www.rsasecurity.com/rsalabs/node.asp?id=2125
Accessed: 2005-11-30
[20] RSA Laboratories. 2005. PKCS #11 v2.20: Cryptographic Token Interface Standard
ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf
Accessed: 2005-12-02
[21] SAFFORD, D., 2002. Clarifying Misinformation on TCPA, IBM Research
http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf
Accessed: 2005-12-02
[22] SAFFORD, D, KRAVITZ, J. and VAN DOORN, L. 2003. Take Control of TCPA
Linux Journal, issue 112, August 2003
http://www.linuxjournal.com/article.php?sid=6633
Accessed 2005-12-02
[23] SCHNEIER. B. 1996.
Applied Cryptography, Second Edition. John Wiley & Sons.
ISBN 0-471-11709-9
[24] Source code for the prototype; tpm-plugin.zip
http://www.f.kth.se/~f00-ann/tpm-plugin.zip
Accessed: 2005-12-15
[25] TCG Main specification Version 1.1b. 2003.
https://www.trustedcomputinggroup.org/downloads/specifications/
TCPA_Main_TCG_Architecture_v1_1b.zip
Accessed: 2005-11-30
[26] TCG Newsletter May 2005, Volume 1 Issue 2. 2005
https://www.trustedcomputinggroup.org/downloads/May_Newsletter
Accessed: 2005-11-30
[27] TCG PC Client Specific TPM Interface Specification v 1.2. 2005
https://www.trustedcomputinggroup.org/groups/pc_client/
TCG_PCClientTPMSpecification_1-20_1-00_FINAL.pdf
Accessed: 2005-12-02
51
[28] TCG PC Client Specific Implementation Specification for Conventional BIOS v 1.20.
2005.
https://www.trustedcomputinggroup.org/groups/pc_client/
TCG_PCClientImplementationforBIOS_1-20_1-00.pdf
Accessed: 2005-11-30
[29] TCG Software Stack Specification, v 1.10. 2003.
https://www.trustedcomputinggroup.org/groups/software/TSS_Version__1.1.pdf
Accessed: 2005-11-30
[30] TCG Specification Architecture Overview Specification v 1.2. 2004
https://www.trustedcomputinggroup.org/downloads/
TCG_1_0_Architecture_Overview.pdf
Accessed 2005-12-02
[31] TCPA - Trusted Platform Module, Protection Profile, July 2002
http://www.commoncriteriaportal.org/public/files/ppfiles/
PP_TCPATPMPP_V1.9.7.pdf
Accessed: 2005-12-02
[32] TPM Main Part 1 Design Principles, v 1.2. 2005.
https://www.trustedcomputinggroup.org/downloads/specifications/
mainP1DP_rev85.zip
Accessed: 2005-11-30
[33] TPM Main Part 2 Structures, v 1.2. 2005.
https://www.trustedcomputinggroup.org/downloads/specifications/
mainP2Struct_rev85.zip
Accessed: 2005-11-30
[34] TPM Main Part 3 Commands, v 1.2. 2005.
https://www.trustedcomputinggroup.org/downloads/specifications/
mainP3Commands_rev85.zip
Accessed: 2005-11-30
[35] TSS Header Files. 2003.
https://www.trustedcomputinggroup.org/groups/software/TSSHeader_File1_1b.pdf
Accessed: 2005-12-12
[36] WANG, X., YIN, Y and YU, H. 2005. Finding Collisions in the Full SHA-1
Collision Search Attacks on SHA1. Crypto 05
52
Appendix A Cryptographic Concepts
This is a short introduction to the cryptographic concepts relevant for this report. The text
is not to be seen as a general introduction to the broad subject of cryptography. It is rather
a reference for readers not familiar with ideas and notions used in the report. For the
interested reader I recommend Applied Cryptography by Bruce Schneier [23 ].
The basic idea behind cryptography is to secure storage and communication of
information. The following definition is given by Menezes et al. [13].
“Cryptography is the study of mathematical techniques related to aspects of information
security such as confidentiality, data integrity, entity authentication, and data origin
authentication.”
Confidentiality is an expression synonymous with privacy and secrecy. The aim is to
keep information secret from everyone except the people authorized to access it. Data
integrity means certainty that stored or sent data has not been tampered with. Possible
alterations include addition, deletion or substitution of data. The term authentication is
related to identification of communicating entities and data sources. In a secure
communication the two parties should identify each other. Information sent over this
channel should then be authenticated as to origin, content, time of creation etc. Data
origin authentication automatically implies data integrity since a modified message must
come from another source than the origin.
A.1 Encryption
The two major tools in providing confidentiality are encryption and decryption. The
process of encryption consists of transforming the original message m, called the
plaintext into unreadable ciphertext c. Decryption is the reversed process, transforming c
back to a comprehensible message m. The sets of all possible plaintexts and ciphertexts
are called plaintext space and ciphertext space.
Encryption and decryption are performed using a cryptographic algorithm30 together
with a chosen key pair from the key space K. If the encryption and decryption
transformations are called Ee and Dd and the key pair (e, d) a general description is:
Encryption:
c =Ee (e, m)
Decryption:
m = D d ( d , c)
The encryption keys e and d can of course be identical. Let us define the sets of
encryption and decryption transformations {E e : e ∈ K } and {Dd : d ∈ K } . For these
transformations to comprise a proper encryption scheme there must for each e ∈ K exist a
30
An algorithm is finite set of instructions for accomplishing some task which, given an initial state, will
terminate in a corresponding recognizable end-state.
53
corresponding d ∈ K satisfying Dd = E e−1 . In other words all ciphertexts have to be
recoverable. A typical encryption scheme is RSA, described in A.1.2.
Before discussing different possible implementations it is worth to notice that there
actually exists such a thing as a theoretically unbreakable encryption scheme. It is called
the one-time-pad. The encryption and decryption transformations are just XOR31 with the
key, and the keys e and d are equal. The problem is that the key needs to be exactly as
long as the message. If the key is disposed and never used again it is actually impossible
to brute force32 through all possible keys. The reason for this is that all possible messages
of right length in the message space will be generated and there is no way to determine
which one is the original plaintext. However distributing and using these keys are
complicated and therefore the one-time-pad is not suitable for automated use in
computing and network environments.
A.1.1 Symmetric Encryption
In a symmetric key encryption scheme it is computationally easy to determine d from e
and vice versa. In reality most symmetric schemes uses a key pair where e = d, hence the
name symmetric. The requirement on such a scheme is naturally that both e and d be kept
secret. In other words, it is impossible to send an encrypted message to someone without
being able to decrypt all other messages encrypted with the same key. This leads to the so
called key distribution problem. A network with n entities communicating with each
other one will need unique keys for all combinations giving Ω (n 2 ) keys that somehow
need to be securely distributed. This issue is facilitated using asymmetric (public key)
encryption discussed in A.1.2.
Some of the most famous symmetric encryption algorithms are the Data Encryption
Standard (DES) and the Advanced Encryption Standard (AES). DES has a small key
length (56 bits) and is now considered relatively insecure. AES is successively replacing
DES as the standard symmetric algorithm. A major improvement of DES is triple DES
(3DES) which basically consists of three recursive DES operations.
A.1.2 Asymmetric Encryption
The characteristic of an asymmetric (public-key) encryption scheme is that given e it is
computationally infeasible to compute d. If that is the case it is safe to publish your
public key e while keeping the private key d for yourself. When someone wants to send
an encrypted message they just look up the recipient’s public key, encrypt the message
and send it away. Then only the entity in possession of the corresponding private key can
decrypt the message. The origin of the public key needs of course be authenticated but
this is in general a much simpler problem then the original key distribution problem
mentioned earlier.
31
XOR is the exclusive or between two binary strings. Example 0010 XOR 1011 = 1001
32
Brute force is an exhaustive search of the complete key space, trying all possibilities without
discrimination.
54
The security of asymmetric encryption is based on so called trapdoor functions.
These are functions that are “easy” to compute in one direction but basically impossible
to reverse. A typical example from life is dropping a vase on the floor, it is easy to drop it
but to reassemble the original from the pieces is extremely difficult if not impossible. The
trapdoor functions also need to have a back-door so that it is easy to put the vase back
together again if you know a certain secret. Unless you need a hash function (discussed in
the next section) there is no sense in making decryption impossible.
The most famous public key encryption scheme is RSA, named after its inventors
(Rivest, Shamir and Adleman). RSA is based on the fact that it is easy to compute the
product of two large primes, but practically impossible to determine prime factors given
the composite number. Take the four digit number 1887, it is fairly small but finding its
factors 37 and 51 would take most people a while (the example is only intuitive and says
nothing qualitative about the actual complexity of prime factorization). An RSA key pair
consists of the public key (n,e) where n is the composite number mentioned before and
the private key d. The public exponent e is randomly chosen and the private exponent d is
derived using the value of e and the factorization of n. In order for RSA to be secure n
needs to be large enough to make it computationally infeasible to found its prime factors.
In order for RSA to be popular, encryption and decryption must not be too slow.
Currently, 1024 bit keys are typically used with 2048 bits being recommended for utmost
security. If using the previously introduced general description of an encryption scheme,
the RSA scheme can be described as:
Encryption:
c =m e mod n
Decryption:
m = c d mod n
Encryption and decryption is in general much slower in asymmetric then in symmetric
encryption schemes. Since computation resources normally are limited, a typical use of
RSA is to encrypt a symmetric key which in turn is used for the actual encryption of the
message.
A.2 Hash Functions
Beside actual encryption algorithms hash functions play a central role in cryptography.
Hash functions are used to uniquely represent a message with a hash-value of predefined
length. A more rigorous definition is given in [13]
“A hash function is a computationally efficient function mapping binary strings of arbitrary
length to binary strings of some fixed length, called hash-values.”
The hash-value can be seen as a compact image, often called digest of the original input
string. Since the message space is much larger than the n-bit hash-value space collisions
are unavoidable. The two main goals in designing hash functions are to make it
55
computationally infeasible33 both to generate collisions deliberately and to find the
original message given a digest. The latter property is ensured by the hash function being
a one-way-function34.
A special kind of hash functions, called message authentication codes (MACs) are
used to obtain message authentication using symmetric techniques. The input to the MAC
is a message together with a key. The output is a hash-value which is “impossible” to
reproduce without knowledge of the key. One type of MAC is the HMAC which is used
by the TPM and presented in Section 2.3.2 on page 10.
One of the most widely used hash functions is SHA-1. The quality of SHA-1 has
however recently been questioned, see Section 6.3.3 on page 40.
A.3 Digital Signatures and Certificates
Another area where hash functions prove useful is digital signatures. The idea is to verify
the origin and integrity of a message. Creation and verification schematically follow the
protocol described below.
Alice wants to send a message to Bob. First she computes the digest (hash-value) of
the message and encrypts it with her private key; the digest is called the signature. Then
she sends the message and the signature encrypted with Bob’s public key. Bob receives
the message and decrypts it with his private key. He then calculates the digest for the
message and decrypts the signature with Alice’s public key. If these two values match he
can be sure that Alice sent the message and that its content has not been altered.
An application of digital signatures is so called public key certificates. A certificate
is used to bind a public key to a specific individual or organization. Information like
name, address etc. can be stored in the certificate. A certificate is typically signed by a
CA (certificate authority) which guarantees that the identity information and the public
key belong together. The CA itself uses a so called self-signed certificate which is called
a root certificate. In Windows XP there are so called certificate stores, where certificates
installed on the computer are stored and managed. The most common ones are the
personal certificate store (MY), and the root certificate store (ROOT). When an
application attempts to install a certificate into the root certificate store, a dialog pops up
asking the logged in user for consent. The installed root or CA certificate can then be
used to sign other certificates. All certificates in the root certificate store are
automatically trusted.
33
The term computationally infeasible means practically impossible due to practical limits of time and
hardware. A computationally infeasible problem is solvable with unlimited computing capacity.
34
A one-way or trapdoor function is easy to calculate in one direction but not in the other (see Appendix
A.1 on asymmetric encryption).
56
Appendix B PKCS#11
This appendix gives an introduction to the PKCS#11 standard. The text is meant to focus
on aspects particularly relevant for this project.
B.1 Introduction
PKCS#11 is a standard for accessing cryptographic tokens, published by RSA
Laboratories. Version 2.20 of the standard can be found at [33]. PKCS#11 is a part of the
suite of Public-Key Cryptography Standards from RSA Laboratories. The document is
only an interface specification. It is up to cryptographic token manufacturers to
implement a library for their own device (if they would like to). However the platform
independent PKCS#11 has become publicly accepted and most vendors ship with an
implementation included. The TPM is no exception and is commonly shipped with a
PKCS#11 module.
B.2 Structure
PKCS#11 makes all cryptographic devices look alike from an interface point of view. It
is up to the interface implementer, and not to the application developer to handle device
drivers and other device specific issues. There is of course no hardware requirement on
the actual device, it could be entirely software based.
Physical devices are internally represented as slots and tokens. Each slot is supposed
to represent a physical reader which may have a cryptographic device inserted. The
interface interpretation of an inserted device is that the slot has a token present. The
interface allows for no user concept. All devices are thought to have a single user and are
accessed through entering a secret pin code. Certain operations may be performed
without logging in to the token but there is no guarantee for this in the interface
specification. The typical way of representing multiple users of one device in PKCS#11
is through creating several different slots for a single device. This is basically a
simulation of multiple devices when actually only using one. Caution has to be taken
with the log in procedure since different users typically will have different pin codes.
B.3 Use Case
In this project a pre-boot PKCS#11 library for the TPM was developed. Following is a
typical authentication usage scenario of this library. Error handling, variable initialization
and some variable declarations have been omitted to highlight the principal usage of the
interface.
57
/********* Test of PKCS#11 library – Excerpt from p11_test.c *********/
CK_FUNCTION_LIST *fl;
CK_SLOT_ID *slots;
CK_SESSION_HANDLE hSession;
char *login_str = “username.passwd”;
CK_ATTRIBUTE decrypt_template[];
CK_OBJECT_HANDLE object[MAX_NUM_KEYS];
CK_ATTRIBUTE cka_mod_template[];
CK_MECHANISM mechanism = { 0, CKM_RSA_PKCS, 0 };
/* Get function pointers */
C_GetFunctionList(&fl);
/* Initialize library */
fl->C_Initialize(NULL_PTR);
/* Get slots with token present */
fl->C_GetSlotList(FALSE, slots, &slot_count);
/* Open a session to the first slot */
fl->C_OpenSession(slots[0],
CKF_SERIAL_SESSION,
NULL_PTR,NULL_PTR,
&hSession);
/* Log in to token */
fl->C_Login(hSession,
CKU_USER,
(unsigned char*)login_str,
strlen(login_str));
/* Find available decryption keys */
fl->C_FindObjectsInit(hSession, decrypt_template, num_attribs);
fl->C_FindObjects(session, object, MAX_NUM_KEYS, &object_count);
fl->C_FindObjectsFinal(session);
58
/* Find the correct key based on CKA_MODULUS */
for(i=0; i<object_count; i++)
{
fl->C_GetAttributeValue(hSession, objects[i], cka_mod_template, 1);
//Check if it is the right key
}
/* Decrypt data */
fl->C_DecryptInit(hSession, &mechanism, object);
fl->C_Decrypt(hSession,
encrypted_data, encrypted_len,
data, &data_len);
59
Appendix C Abbreviations
To facilitate the reading of this paper, commonly used technological abbreviations have
been used. A list of the explicit meanings of these abbreviations is given below.
3DES
AES
AIK
API
ATR
BLOB
BORE
CA
Triple DES
Advanced Encryption Standard
Attestation Identity Key
Application Programming Interface
Answer to Reset
Binary Large Object
Build Once Run Everywhere
Certificate Authority
CRTM
Core Root of Trusted Measurement
CSP
DES
DPA
DPMI
DRM
CAPI
CRT
CSP
EK
GPL
HMAC
Cryptographic Service Provider
Data Encryption Standard
Differential Power Analysis
DOS Protected Mode Interface
Digital Rights Management
Cryptographic Application Programming Interface
Chinese Remainder Theorem
Cryptographic Service Provider
Endorsement Key
GNU General Public License
ICC
IFD
IEEE
KCM
MAC
NONCE
NSA
OIAP
OS
OSAP
PCR
PKCS
PPBE
RNG
RSA
SHA-1
SPA
SRK
SSL
keyed-Hash Message Authentication Code
Integrated Circuit Card (Smartcard)
Interface Device (Smartcard reader)
Institute of Electrical and Electronic Engineers
Key Cache Manager
Message Authentication Code
Number used ONCE
National Security Agency
Object-Independent Authorization Protocol
Operating System
Object-Specific Authorization Protocol
Platform Configuration Register
Public Key Cryptography Standard
Pointsec Pre-boot Environment
Random Number Generator
Rivest, Shamir and Adleman (asymmetric cryptography scheme)
Secure Hash Algorithm 1
Simple Power Analysis
Storage Root Key
Secure Sockets Layer
60
TC
TCG
TCPA
TCS
TDDL
TOE
TP
TPM
TRNG
TSP
TSPI
TSS
Trusted Computing
Trusted Computing Group
Trusted Computing Platform Alliance
TSS Core Services
TCG Device Driver Library
Target of Evaluation
Trusted Platform
Trusted Platform Module
True Random Number Generator
TSS Service Provider
TSP Interface
TCG Software Stack
61
TRITA-CSC-E 2006: 049
ISRN-KTH/CSC/E--06/049--SE
ISSN-1653-5715
www.kth.se