Key Management with Trusted Platform Modules

A N D R E A S N I L S S O N

Master of Science Thesis Stockholm, Sweden 2006

Key Management with Trusted Platform Modules

A N D R E A S N I L S S O N

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

AbstractKey Management with Trusted Platform Modules

The concept of Trusted Computing, which aims at making computing platforms morereliable, is based on a chip called Trusted Platform Module (TPM). The TPM is a chipwhich 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-bootauthentication for the disc encryption software Pointsec for PC. The system was analysedwith respect to manageability and security.

With regard to manageability the findings were that two critical implementationfactors will be interoperability and user transparency. Some TPM features are notstandardized which complicates the implementation of a general system. Recovery frompassword loss or hardware failure can be achieved with Remote help or TPM key backup.

The security analysis focused on the software and hardware attack mitigationintegrated into the TPM. The chip was found to be somewhat vulnerable to sophisticatedlaboratory based attacks but fully comparable to smartcards.

A prototype using the TPM for RSA key storage and RSA-wrapping of the discencryption key was developed. The prototype has two parts; one Windows based userinstallation utility and one pre-boot authentication module. In order to communicate withthe TPM in the pre-boot environment a kernel device driver was developed.

SammanfattningNyckelhantering med Trusted Platform Modules

Konceptet Trusted Computing, som syftar till att göra dator-plattformar mer pålitliga, ärbaserat på en krets kallad Trusted Platform Module (TPM). En TPM är ett kryptografisktchip med inbyggd RSA-kryptering och säker nyckellagring. Syftet med dettaexamensarbete var att analysera och implementera TPM-baserad pre-boot autentiseringför diskkrypterings-programvaran Pointsec for PC. Systemet analyserades med avseendepå hanterbarhet och säkerhet.

Vad gäller hanterbarhet visade det sig svårt att åstadkomma interoperabilitet ochanvändartransparens. Viss TPM-funktionalitet är inte standardiserad vilket komplicerarutvecklandet av ett generellt system. Återställning vid lösenordsförlust eller hårdvarufelkan göras med Remote help eller nyckel-backup inbyggd i TPM-kretsen.

Säkerhetsanalysen fokuserades på funktionalitet inbyggd i chipet för att förhindramjuk- och hårdvaruattacker. TPM-kretsen visade sig inte vara designad för att stå emotsofistikerade attacker med avancerad laboratorieutrustning men fullt jämförbar medsmartcards.

En prototyp som använder en TPM för lagring av RSA-nycklar och RSA-krypteringutvecklades. Prototypen består av två delar; ett Windows baserat användarinstallations-verktyg och en pre-boot autentiseringsmodul. För att kommunicera med chipet i pre-bootmiljö utvecklades en drivrutin.

ForewordThis report describes my Master’s project in Computer Science at the School ofComputer Science and Communication (CSC), Royal Institute of Technology (KTH),Stockholm, Sweden. The project was carried out at Pointsec Mobile Technologies AB, inStockholm. Pointsec is a software company developing disc encryption software. I wouldlike 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 thepossibility 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

1 IntroductionAs a response to the increased mobility of information storing devices like laptops andmobile phones, disc encryption systems are becoming more popular. Disc encryptionsystems protect sensitive information stored on the devices. Typical kinds of informationneeding to be protected (in the enterprise world) include corporate secrets andconfidential customer data. Apart from receiving bad publicity and providing competitorswith company secrets, losing sensitive information about customers can also render largefines. These factors have lead up to an extended usage of disc encryption. The process ofprotecting information stored on a disc is really not that different from protectingphysical items with locks. By implementing an electronic lock only a user in possessionof 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 problemis somewhat different from its real world lock analogy since normally physical keys canbe carried in a handbag or pocket. The electronic keys are unfortunately to complex toremember so they cannot be “carried around” but instead has to be matched tocorresponding passwords. In this project a key storage plug-in to the disc encryptionsystem Pointsec for PC was developed. The task of the plug-in was to store the electronicencryption 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 harddisc or on removable tokens called smartcards. Various aspects, such as security of thecombined system (plug-in together with original software) were investigated.

1.1 Disc EncryptionIn today’s mobile world an increasing amount of sensitive information is stored onportable devices like laptops and smartphones. Such devices can easily be lost or stolenand as such need adequate protection against data theft. There are of course built-insecurity 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 violationstrategy applying to laptops is to transfer the hard disc into another computer. Evendeleting files will not help since the information still is present on the hard disc (untiloverwritten) and available to anyone with the right knowledge and tools.

The solution to the problem is to use cryptography to render the information storedon the device unreadable to non-authorized persons. For readers not familiar with basiccryptographic concepts like keys, encryption and decryption a presentation is given inAppendix A. The basic idea is however simple; to replace readable information withinformation only persons in possession of a special key can understand. A disc encryptionsystem does exactly this for you with the information stored on the hard disc, principallyusing the login password to control access to the key. Disc encryption systems encrypt

2

everything on the hard disc and are not to be confused with simple utility programs thatlet the user encrypt specific files. A consequence of encrypting the complete hard disc isthat the encryption system needs to run and decrypt the operating system files before theoperating system can be loaded. This requires so called pre-boot authentication, a processperformed by the encryption system before the operating system is started, where the useris asked for login name and password. If correct login information is entered the discencryption software decrypts the operating system files and the operating system canload.

A crucial security topic in all kinds of cryptography is key management. Discencryption systems are no exception; the key used to decrypt the hard disc must be storedsomewhere. There are two principal alternatives for protecting the encryption keys, insoftware or in hardware. Software based protection includes storage on commonunprotected storage devices like hard discs, flash memories etc. Hardware protectionrequires special hardware like smartcards or special purpose cryptographic chips. Ingeneral hardware protection is more secure then software protection. If the keys arestored on unprotected discs, even if in obfuscated1 or encrypted form, rogue software canaccess and manipulate the stored information. If the keys instead are stored inside oftamper-proof hardware devices unauthorized access is if not completely prevented, atleast obstructed.

1.2 Pointsec Mobile Technologies ABThe project was carried out in cooperation with Pointsec Mobile Technologies inStockhom. My supervisor at Pointsec was Fredrik Gustafsson. Pointsec develops discencryption software for use on laptops, PDAs, smartphones and removable media. Theproduct mainly concerned by this project is Pointsec for PC, a disc encryption system forPC 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), alightweight “operating system” which launches before Windows is loaded and performspre-boot authentication of the user. The second part is a normal Windows program whichis used for system management and disc encryption/decryption while in the operatingsystem environment.

The aim of this project was to develop and investigate a prototype for a key storageplug-in to Pointsec for PC. The function of the plug-in is to provide hardware based keystorage using a cryptographic chip called a Trusted Platform Module (TPM). SincePointsec for PC operates in both the PPBE and Windows environment the plug-inconsists 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 usingsome predefined confusion scheme. A simple example would be to store the key backwards.

3

1.3 Trusted Platform ModulesThe TPM is a cryptographic chip which provides RSA2 key generation, built-in RSAencryption and decryption and secure key storage. The TPM chip has been developed aspart of a strategy for making computing platforms more reliable, called TrustedComputing (TC). Trusted Computing is described in Section 2.1 on page 5 but basicallyit is a set of cooperating hardware and software that is supposed to make the computers(and other communication devices) more reliable and trustworthy. The TPMmicrocontroller is the hardware part of this concept. The TPM specification is platformagnostic but all current applications are for PC platforms.

In addition to providing RSA functionality a TPM can furthermore be used to bind astored resource (like a key) to a certain machine configuration by measuring a platformshardware and software. This is not a normal function of cryptographic chips but isimplemented as part of the TC strategy. In general the TPM offers a wide range offunctions that would not be needed by Pointsec for PC. However Trusted Computing is agrowing concept, and financially backed up by several IT company giants. This hasresulted in that computer vendors ship many of their platforms with TPM chips installedmaking it practical to use already installed hardware.

1.4 Problem and ObjectiveThe project consists of two parts, a theoretical survey and the implementing of a softwareprototype. Both parts relate to the use of the cryptographic functionality built into theTPM.

The theoretical investigation consists of two major parts. The first part is an analysisof manageability of a TPM based system for disk encryption. A critical issue here isrecovery when users lose passwords or a hardware failure occurs. The second part dealswith security issues regarding for instance the access to and storage of encryption keys inthe TPM. An attempt is made to identify possible security problems and estimate theirimpact.

The practical part consists of writing a prototype addressing the TPM from bothWindows and from the Pointsec Pre-boot Environment (PPBE) mentioned in Section 1.2on 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 bymeans of authentication. Since the operations from the PPBE have to be performedoutside an OS environment it will not be possible to use software or interfaces providedby 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 detaileddescription see Appendix A.1.

4

1.5 Scope and FocusIn the press, TPM technology has often been connected to the concept of Digital RightsManagement (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 TPMfunctionality called machine binding. Additionally all functionality used to secure remotecommunication has been ignored since the key storage function of a disc encryptionsystem is local. The only time key information would have to be sent to another platformis in the case of key backup. Such backup is however (in Pointsec for PC) performedusing so called recovery discs (see Section 5.3.3 on page 35). The theoreticalinvestigation and the prototype development instead focus on the classical, cryptographicfunctionality of the microcontroller.

The TPM is defined as platform agnostic but is currently only manufactured for PCplatforms. Some parts of this project like Chapter 2 Trusted Platform Modules Overviewand most of Chapter 6 Security Analysis applies to non-PC platforms as well. Howeverthe report was written with the PC platform in mind.

5

2 Trusted Platform Module OverviewBefore discussing advanced properties of the Trusted Platform Module (TPM), apresentation of its background and major components is appropriate. The TPM is acryptographic chip which constitutes the hardware part of the concept Trusted Computing(TC). Typical cryptographic areas of usage are RSA encrypt/decrypt and secure hardwarebased storage. Even though the TC functionality of the TPM is not used in this project anorientation is included in the beginning of this chapter.

2.1 Trusted ComputingThe concept of Trusted Computing has been introduced in recent years as an attempt tocome to terms with the flexible but somewhat unreliable computing platforms used today.Abstractly, Trusted Computing is a set of software and hardware components workingtogether in order to be able to guarantee a platform’s behaviour to both local and remoteparties. Less formally, the two overall TC goals are to have better control of whathappens 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 physicalmalfunctions of the computer like hard disc crashes, but rather means to be able to trustthe integrity of a certain functioning platform configuration3. By comparing a previouslytrusted 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 integritymetrics during the boot process of the platform. For example when booting a PC, a smallpiece 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 blockof the hard disc. That code in turn reads another piece of the OS, this piece itself reads thenext one and so on until the whole operating system is running. When a TC platformboots, the TC hardware (the TPM) calculates cryptographic hashes of relevant integritymetrics and stores them inside the chip. In order for this to work, the BIOS, in addition toreading the next piece of code from the boot block asks the TPM to calculate and log ahash of this second block of code. The second piece of code executes and similarly asksthe TPM to log a hash of the next code block to be executed, and so on. These collectedhashes are then compared to encrypted hashes of an earlier trusted configuration. Possiblechanges can be authorized by the user and then the reference configuration is updated.

Specifications for this technology have been developed by the Trusted ComputingGroup (TCG).

3 Here configuration stands for the combination of all software and hardware installed and enabled on thecomputer platform.

6

2.1.1 The Trusted Computing Group (TCG)The industry consortium Trusted Computing Platform Alliance (TCPA) was jointlyfounded 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 itssoftware interface. In April 2003 the Trusted Computing Group (TCG) replaced theTCPA and adapted its specifications. Today the TCG counts over 100 membercompanies which provide the organization with funding and work force [26].

The TCG has released a number of specifications dealing with different aspects ofTC implementation. The basis is the TCG Main specification [25], which discusses theconcept 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 thoughthe TPM is specified to be platform agnostic most of the work put in by the TCG hasbeen in the PC area. A specification for mobile devices is however scheduled for the firsthalf 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.2Version 1.1 received critique regarding some security and privacy issues such as lack ofI/O encryption and insufficient protection of user identity. This has lead up to version 1.2of the TPM specification which is the one considered in this report.

2.1.2 Remote AttestationIn addition to ensuring the local user that the platform is reliable TC aims at increasingnetwork security. The TPM chip has a unique, certified identity called the EndorsementKey (discussed further in 2.2.1 on page 7). The TPM attests to the platform being in acertain state by signing the hashed integrity metrics (OS configuration etc). Anotherentity (user or program on another platform) can then verify the certified identity of theTPM. In addition to OS attestation, normal applications can also be attested. They are inturn attested by the OS.

The process of attesting an application schematically works as follows. ACertificate Authority (CA) ensures that the sending TPM is a real TPM. The logged OSinformation is signed by the sending TPM. The OS in turn signs information about whichapplication communication is taking place with. If the signatures are valid, the entity thatreceived the attestations needs to decide whether or not to trust their correspondingsigners. If the entity trusts the CA then it can trust that the signed OS is running on theplatform (the OS is authenticated). If the entity trusts the OS then it can be certain that thesigned application is the one actually running on the other platform.

2.2 Basic ConceptsTwo important TPM entities are the unique identity called the Endorsement Key and theTPM owner. These concepts are introduced in the next Sections. Since the text contains a

7

number of references to different keys, a summary of TPM key types and special purposekeys is included in Section 2.2.3 on page 8.

2.2.1 Endorsement KeyTo able to perform attestation a TPM first needs to authenticate itself. This could beachieved by incorporating a globally shared authorization value between all TPMsmanufactured. The problem with this approach is that it is vulnerable to a break once runeverywhere (BORE) attack. If one TPM is compromised all other are compromised aswell. Since even Microsoft (one of the big contributors to the TCG) officially admits thatthe TPM is relatively vulnerable to sophisticated hardware attacks [21] it is very likelythat some chips will be compromised.

To overcome this problem every TPM has a unique 2048-bit RSA key pair calledthe Endorsement Key (EK). The EK is created internally by the TPM, aftermanufacturing but before shipment to customers. The EK pair uniquely4 identifies theTPM and can never be changed. The private part (EKpr) never leaves the TPM and thepublic part EKpub is used in an X.509 endorsement certificate5. The endorsementcertificate is signed by the manufacturer, or some other entity (like a test lab) that canassure that the TPM knowing EKpr is conformant with the TC specifications. In practicethis means that whoever knows the EKpr corresponding to the public key EKpub in theendorsement certificate can be trusted to be a genuine TPM.

However, since the EKpub uniquely identifies the TPM, which in turn identifies theplatform 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 forattestation was proposed in version 1.1 specification and is based on the creation of oneor multiple aliases of the EK. Using a trusted third party (CA) who knows the mappingbetween an AIKpub and its corresponding EKpub, attestation can be performed withoutpublicly revealing EKpub. However the use of AIK keys was criticized for privacy reasonsdue to the dangerous reliance on the CA not to reveal the EKpub (and TPM) mapped to acertain AIKpub. As a response to this critique a new attestation method called DirectAnonymous Attestation (DAA) was introduced in TPM 1.2. For the interested the methodis documented in [32].

2.2.2 OwnershipAfter shipment but before usage the TPM needs to get an owner. Ownership is solelyrepresented by an authorization value known only to the TPM and the owner. This meansthat from the perspective of the TPM whoever knows the owner authorization value is theowner. In general all access to TPM resources is based on the sharing of secrets whichare represented as 160-bit numbers. All shared secrets are called AuthData in the TCGspecifications, 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.

8

have the view of the TPM or the requesting party. In this report the term authorizationvalue will be used to represent the shared secrets.

Certain TPM operations can only be performed by its owner. In other words, to beable to issue these commands, the authorization value authenticating the user as theowner needs to be presented. Such operations include for instance activation/deactivationand the creation of AIKs. Every time someone takes ownership of a TPM, a specialpurpose RSA key pair, called the Storage Root Key (SRK) is created. The SRK is used towrap6 everything stored in the TPM, including other keys so when a new owner is issuedeverything 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 theplatform. Different TPM objects (i.e. keys) can have different authorization valuesassociated with them. It should be noted that the owner is no “super user”. Being theowner does not automatically give access to other protected entities or operations. Suchentities can have their own authorization values not known to the TPM owner.

2.2.3 Key Type PrimerThe TCG specifies four different key types presented in the following list. The usage of akey for other than its intended purposes is strictly forbidden in the TPM design and suchan attempt will fail with an error code.

§ Storage keys are required to be 2048-bit RSA keys and are used to wrap other keys. Atypical storage key is the SRK.

§ Binding keys are RSA keys with a minimum key size of 512 bits. Binding keys areused 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 theTPM 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: SRK – Storage Root KeyKey type: 2048-bit RSA storage keyDescription: 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 inSection 2.4.

Location: Neither SRKpub nor SRKpr is ever allowed to leave the TPM, not even byowner request.

6 Wrapping in the context of public key cryptography is to encrypt data with a public key. The plaintext canthen only be retrieved by someone in the possession of the corresponding private key.

9

Name: EK – Endorsement KeyKey type: 2048-bit RSA signing keyDescription: 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 ofthe endorsement certificate containing EKpub.

Location: EKpr must never leave the TPM and EKpub should only be known tocertain trusted authorities.

Name: AIK – Attestation Identity KeyKey type: 2048-bit RSA signing keyDescription: An AIK is an alias to the EK and is used for TPM authentication to

protect user integrity. The mapping between a TPM’s endorsementcertificate and its AIKs are kept at a Certificate Authority.

Location: An AIKpr is used to authenticate the TPM and can as such never leave thechip. AIKpub is not secret and can be obtained from the mapping CA.

2.3 Major ComponentsThis Section contains a description of the major chip components as defined in the TPMspecification [32]. The focus of the presentation is on the cryptographic functionality ofthe chip. Some of the (for this report) less significant components have been bundledtogether in Section 2.3.8 on page 13. A principal sketch of the parts discussed is given inFigure 2.1.

Major Components of a TPM

CryptographicfunctionalityRSAHMAC EngineSHA-1 EngineRNGKey Generation

OtherComponentsNon-volatile MemoryVolatile MemoryMonotonic CounterI/OOpt-inPower DetectionExecution Engine

Figure 2.1 The major components of a TPM chip

2.3.1 RSA encrypt/decryptThe TPM has a number of built-in cryptographic functions. This includes animplementation of the RSA-algorithm. The TPM specification [32] does not specify howRSA is to be implemented but it demands RSA to be used for digital signatures and

10

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 216+1 for allgenerated keys. If a vendor implementation uses the Chinese Remainder Theorem it mustinclude detection of failures and protection, in order not to compromise the private key.The implementation must use PKCS#1 [19] for digital signatures, encryption, dataformats 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 forthe platform CPU. In a symmetric encryption use case RSA keys are used to store anencrypted version of the symmetric key.

2.3.2 HMAC EngineTo ensure data integrity and authentication of input and output from the TPM an HMACengine is used. HMAC is a type of Message Authentication Code (MAC) calculated usinga hash function together with a secret shared key. AN HMAC is defined by key lengthand 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 parametersof the block size and h is a cryptographic hash function. The operand ⊕ stands for theXOR function and || for concatenation7. The strength of HMAC depends on the propertiesof the underlying hash function and the quality and length of the key. The hash functionchosen for the TPM is SHA-1. A further discussion of SHA-1 in combination withHMAC is provided in Section 6.3.3 on page 40.

2.3.3 SHA-1 EngineThe hash function SHA-1 belongs to a group of cryptographic hash functions developedby the NSA called SHA (Secure Hash Algorithm). SHA-1 is the one most widely spreadand is included in commonly used protocols such as SSL, PGP and SSH. The SHA-1function is primarily used by the HMAC engine but is also externally available. Thespecification requires that SHA-1 be implemented according to FIPS-180-1. The TPM isnot a cryptographic accelerator8, in other words there is no minimum throughputrequirement for hashing. It is therefore not recommended to use the SHA-1implementation externally unless it is necessary due to limited running environmentresources. As is discussed in Section 6.3.3 on page 40 collision weaknesses have beenfound in the SHA-1 algorithm. The problems however mainly concern the use of digitalsignatures 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.

11

2.3.4 RNGThe Random Number Generator (RNG) is used by the TPM for creation of nonces9, keygeneration and randomness in signatures. If no hardware entropy source10 is implementedthe TPM is allowed to use a Pseudo Random Number Generator (PRNG)11. To be able toproduce good random numbers even if no genuine source of entropy is available the TPMuses a state register together with a mixing function (e.g. SHA-1). When the TPM ismanufactured the state register is initialized with random data. The register is thenupdated internally with random entropy data. Such data can originate from hardware orsoftware sources, for example thermal noise or mouse movements. After the first entropyupdate it is impossible for anyone, including the manufacturer and the TPM owner todetermine the current state.

To generate random numbers the mixing function takes the value in the stateregister and produces RNG output. Every time a random number is created an update ofthe state register is performed. Otherwise the deterministic mixing function couldproduce the same random number twice. The RNG should be able to produce 32 bytes ofrandomized data at every request while larger request may fail due to insufficientrandomized data available.

2.3.5 Key GenerationThe TPM uses its RNG to generate keys. It has built-in support for generating symmetrickeys as well as RSA key-pairs. Asymmetric keys are to be generated in accordance withIEEE P1363 [7]. Just like in the case with algorithm support, TPM vendors are free toadd key generation for other asymmetric crypto systems (e.g. elliptic curves) but areforced to implement according to P1363.

The generation of symmetric keys just consists of calling the RNG to provide arandom key of appropriate length.

2.3.6 Non-Volatile and Volatile MemoryA Non-Volatile (NV) memory component is a persistent storage device, meaning thatdata stored will remain when the computer is shut down. A hard disc is a non-volatilestorage 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 internalusage 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 thecommunication 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 aregenerated in a deterministic way using a seed.

12

Usage of On-chip TPM storage

Non-VolatileMemoryEndorsement KeyStorage Root KeyAttestation Identity KeysOwner AuthDataOpaque owner data

VolatileMemoryRSA Key SlotsPCR 00 à PCR 15Key HandlesSession Handles

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 keysstored in the NV memory are the EK, the SRK and the created AIKs. It also contains theauthorization value of the owner. Apart from storing TPM internal keys and authorizationdata the NV memory is also available for allocation by owner authorized entities (only inversion 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 ithas 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 limitis set as low as 1280 bytes [27].

The volatile memory is primarily used internally by the TPM to manage theintegrity measuring and temporarily store RSA keys. A key part of the integrity checkingof the platform is played by the Platform Configuration Registers (PCR). All TPM chipsmust have at least 16 of the160-bit PCR slots used to store hashed information about theplatform hardware and software. The mapping between certain integrity metrics and thePCRs is platform specific, e.g. PCR0 is used for the BIOS hash on the PC platform. TheRSA key slots are used to store keys in the volatile memory of the TPM. When an RSAkey 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 CounterThis is a feature added to the v. 1.2 specification for security reasons. In general amonotonic counter provides an ever-increasing incremental value. A TPM must supportfour coexisting monotonic counters for internal and external use. The internal counter isfor usage by the TPM only but the external counters can be accessed by resources outsideof 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 resendingencrypted 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.

13

procedure someone could for instance reset the balance on a bank account to a previousvalue. To prevent this with a monotonic counter one could increase the value of thecounter every time the balance change. Then the current status of the counter is encryptedtogether with the message and the decrypting application can compare the count valuesent with the real one on the counter.

2.3.8 Other ComponentsThe I/O component manages the flow of information over the communications bus. Itroutes messages to appropriate receiving components and handles encoding and decodingover external and internal buses.

The opt-in component is responsible for managing the state of the TPM. Itmaintains the state of persistent flags such as on/off, enabled/disabled,activated/deactivated and so on. The setting of these flags requires either authorization ofthe owner or physical presence of the operator. Access policies associated with Opt-in areenforced by the I/O component.

The power detection manages the TPM power states related to the platform powerstate. If any change in the platform power state occurs the TPM must be notified. Thereare some vulnerable platform power states where the TPM may restrict execution ofcommands. A typical example of that is during the Power on Self Test (POST) of theplatform.

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 executionengine that ensures that operations are properly segregated and that vulnerable data is notexposed.

2.4 Protected Storage

Protected storage in context of Trusted Computing Platforms (TCP) is defined by Pearsonet al [18] as follows:

“Protected storage is a service to the host platform in which the Trusted Platform Moduleacts 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 actualmemory resources of the TPM are limited but this is solved cleverly through successivewrapping of keys and generic data. At the root of the tree is the previously mentionedStorage Root Key (SRK).

2.4.1 Data ProtectionSecure storage is based on the fact that the SRK never leaves the TPM. The public part ofthe SRK is used to encrypt the private part of the so called storage keys (which must be2048-bit RSA keys). The storage keys can then in turn be used in the same way to

14

encrypt other storage, binding or signing keys. Generic blobs13 of data can be encryptedwith the binding keys. All encrypted entities are stored as opaque data blobs outside theTPM on an unprotected medium like a hard disc. An example of a typical storage tree isgiven in Figure 2.3.

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 GDfor 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 OSenvironment a key-cache manager (KCM), placed outside the TPM, moves data to andfrom external storage [4]. The KCM is provided by the TCG Software Stack (TSS), seeSection 2.5.1 on page 14.

2.4.2 Key Scope AttributesA 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 tofollow a user between several devices. Migratability also gives the opportunity to back upcrucial keys in case of TPM failure. A non-migratable key is never allowed to leave theTPM. Examples of built-in non-migratable keys are the AIKs used for attestation. Anexotic attribute form introduced in TPM version 1.2 is the certifiable migratable keywhich can be migrated only under certain circumstances. The destination TPM must beauthorized 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 nodemust only have non-migratable ancestors. The idea of migration is corrupted if a parent to anon-migratable key is migrated to another platform.

13 BLOB – Binary Large Object

SRK

SK SK BK

K BK GD

GD

15

2.5 Software InterfacesFor applications to be able to use the TPM without addressing it directly on byte level asoftware interface is specified. The basic API alternatives when operating from an OS arepresented in this section. Software access to the TPM is further discussed in the prototypeimplementation part.

2.5.1 TSSAs was mentioned in 2.1.1 on page 5 the basic way to access the TPM from software isthrough the TCG Software Stack (TSS) [29]. The interface is specified by the TCG andall TPM vendors are required to ship a TSS implementation. The TSS API is relativelyeasy to access and has the advantage of being platform independent. The primaryinterface for application developers is the TSS Service Provider (TSP). It is relativelyhigh level and is provided as a DLL by the TSS vendor. One level down is the TCG CoreServices (TCS) which to a much higher extent resembles the pure commands sent directlyto the TPM through its I/O port. To be able to use the TCS a developer needs in depthknowledge of the TPM command base which requires investing a considerable amount oftime. The TCS is typically accessed through a Windows COM-interface. At the lowestlevel is the TCG Device Driver Library (TDDL) which provides functions for sendingcommands on byte level directly to the TPM. It should be noted that access to the TPM isexclusive and synchronized via the TDDL. This means that if TCS is running as aWindows NT Service it must first be stopped before the TDDL gives any access to theTPM. A schematic view of the TSS is given in Figure 2.4 with the TSP being the highestlevel and the TDDL at the bottom.

Figure 2.4 A schematic view of the TSS.

2.5.2 MS-CAPIMicrosoft Cryptographic API (MS-CAPI) is an interface for adding cryptographicfunctionality to Windows based applications [16]. Access to the TPM is acquired throughuse of a Cryptographic Service Provider (CSP). A CSP is a standard module thatimplements cryptographic functions in hardware. Providing a CSP implementation is notrequired by the TCG but most TPM vendors ship with a special TPM CSP. It is importantto note that some functions of the TSS are not available through either MS-CAPI orPKCS#11 (mentioned below). The advantage of using MS-CAPI is of course the abstract

TSP

TCS

TDDL

16

standardisation but it is at the same time its downside. MS-CAPI was examined but notused in the prototype implementation (see Section 4.5.1 on page 26).

2.5.3 PKCS#11Support for the public key crypto interface PKCS#11 (Cryptographic Token InterfaceStandard #11) described in [20], is not mandatory but again most vendors ship withPKCS#11 support included. PKCS#11 is developed by RSA Laboratories and hasbecome a worldwide standard for accessing cryptographic tokens. Its advantage over MS-CAPI is that it is platform independent so an implementation using PKCS#11 would berelatively easy to port from a PC to a Linux environment. PKCS#11 is described inAppendix B and a lightweight PKCS#11 library is implemented by the prototype modulefor the pre-boot environment.

17

3 Pointsec for PC ArchitectureThis chapter is an introduction to the existing Pointsec architecture for user authenticationand key management. An understanding of the existing solution provides a context forthe TPM prototype presentation in Chapter 4.

3.1 Pre-boot AuthenticationAs 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 systemcan be loaded. This requires pre-boot authentication, a process where the user is asked forlogin name and password. If correct login information is entered Pointsec decrypts theoperating system files and the operating system can load.

3.2 Key ManagementIn principle, the password provided by the user during the pre-boot authenticationunlocks the so called partition encryption key (the symmetric key used to encrypt thehard disc). Currently in Pointsec, this key can be stored and protected in two differentways, on the hard disc, or using a so called smartcard14. Which type should be used ischosen specifically for each user account created. The idea with the TPM prototype is toinclude a third account type, namely one using TPM based authentication. A simplifiedsketch of the current and future management (dashed) of the partition encryption key isgiven in Figure 3.1.

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 storeddirectly on the hardware devices. This is not the case, as was discussed in Section 2.4 onpage 13, but the devices (smartcard and TPM) use RSA keys stored on them to decryptthe partition encryption key.

14 Smartcards are presented thoroughly in Section 6.5 as an alternative to the TPM. For now it suffices toknow that they can be attached to a computer and can store RSA keys protected by a pin code.

Pointsec

Hard disc Smartcard TPM

18

The advantage with storing encryption keys in hardware, like smartcards orcryptographic chips is that the protection is better. An encryption key stored on the harddisc can be obfuscated and encrypted with a password, but that is the limit. The sameoperations can be applied to keys stored in hardware, but in addition the keys areprotected inside tamper resistant hardware. The reason for including TPM support besidesmartcards 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 tothe Windows part of Pointsec as well. Only the sectors of the hard disc currentlyrequested are decrypted requiring a continuous access to the partition encryption key.

3.3 PPBE DesignTo understand the design of the pre-boot prototype a further presentation of the currentsmartcard support in the PPBE (Pointsec Pre-boot Environment) is required. Tocommunicate with a smartcard outside of an OS environment, one needs two drivers; adriver for the smartcard reader and a driver for the actual card. In Figure 3.2 a simplifiedview of the program flow with regard to smartcard communication is displayed.

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 calledIFD15 Handler interface for communicating with smartcards via a smartcard reader. Theinterface is described in ifdhandler.h included in the source library referred to inSection 4.2.4 on page 20. The p11.bin module is a smartcard PKCS#11 library (seeAppendix C and [20]), in other words it is a special purpose smartcard driver. PKCS#11is a standardized way to access cryptographic functions from cryptographic tokens.

The reader.bin module exposes a set of functions to access the smartcard calledIFD Handler functions. The PPBE asks reader.bin for the IFD Handler functionpointers and passes them on to p11.bin. The PKCS#11 library then uses the functions tocommunicate with the smartcard (this is symbolized with the dashed connector in Figure3.2). In the TPM plug-in described in Chapter 4, the modules reader.bin andp11.bin are replaced to communicate with a TPM instead.

15 IFD – Interface Device, commonly called a “smartcard reader”.

reader.bin p11.bin

IFD Handlerfunction pointers

PPBE

IFD Handlerfunction pointers

19

4 Prototype ImplementationThis chapter describes the prototype implementation part of the project. First the goals ofthe 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 theactual implementation is described in Sections 4.5-4.6.

4.1 GoalsThe primary goal was to implement a proof of concept prototype utilizing the TPM forkey generation and pre-boot authentication. The prototype was to be implemented in sucha way that remaining work to include it into Pointsec for PC was minimized. However itwas not in the scope of this project to explicitly solve all problems encountered, butrather to point them out and propose possible further actions.

The secondary goal was to gain knowledge about how the TPM operates and whichkind of functionality and interfaces are available for developers. Therefore some parts ofthis chapter will be more general then would have been needed just to document theactual implemented prototype.

4.2 Structure and ToolsThe prototype consists of two main parts. A Windows command-line utility calledtpmutil, and two binary PPBE libraries (.bin DOS files) representing the two drivers inFigure 3.2 on page 18. These parts have been developed separately and their soleconnection point is the commonly accessed storage area discussed in Section 4.4.2 onpage 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 obtainedfrom [24], see Section 4.2.4 on page 32.

4.2.1 User InstallationThe main purpose of tpmutil is to act as a smartcard plug-in during the installationphase of Pointsec for PC. Its primary task is to provide the installation wizard with asimulated smartcard-logon certificate. The certificate will contain the currently logged inuser’s public key to use for wrapping the disc encryption key. The Windows part of theprototype (as opposed to the PPBE-part) will not operate on the partition encryption keybut is only used to wrap the user RSA keys described in Section 4.4.1 on page 23. Therewill be no real-time interaction with Pointsec for PC. Instead the certificate needs to becreated and stored with tpmutil before the installation procedure is started. The utilityis described in-depth in Section 4.5.

4.2.2 Login ProcedureThe pre-boot module of the prototype is responsible for decrypting the symmetric discencryption key. The module was implemented as a lightweight PKCS#11 library for the

20

TPM, only supporting functions actually needed. The prototype is therefore not to beseen as a complete pre-boot PKCS#11 library for the TPM. The provided PKCS#11module is then used by the pre-boot authentication code after receiving login informationfrom the user. This is already done the exact same way in Pointsec for PC. The differenceis that the current PKCS#11 library is smartcard based whereas the library in theprototype uses the TPM as cryptographic device. If the reader is not familiar with thePKCS#11 standard for accessing cryptographic tokens an introduction is given inAppendix B. In addition to the PKCS#11 library a dummy smartcard reader driver waswritten to make the prototype fit into the existing PPBE structure.

A feature not implemented in the prototype is informative error messages duringpre-boot authentication. The only error message right now is “Login failed”. A typicalscenario 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 isincorrect. The graphical user interface is not accessible from the implemented binarylibraries. A specific error message interface would therefore have to be establishedbetween the TPM PKCS#11 library and its callers.

4.2.3 Development ToolsAll code was written in C and C++ and compiled with Microsoft Visual Studio 7.0 andDJGPP. DJGPP is a porting of GCC16 to a 32-bit DOS environment. The part of theprototype running in Windows, tpmutil was compiled with Visual Studio while DJGPPwas used to compile the pre-boot binary libraries.

4.2.4 Source CodeThe source code and makefiles for the prototype can be obtained in compressed formfrom the author by e-mail or be downloaded from [24].

4.3 TPM InterfacesIn Section 2.5 the different TPM interfaces available inside operating systemenvironments were presented. The one chosen for tpmutil was the TSS ServiceProvider Interface (TSPI) utilizing a TSS Service Provider (TSP) dll. The reasons for thedecision are presented in Section 4.5. For the pre-boot environment the direct byte-levelTPM commands have to be used. However for the actual pre-boot access method thereare two different alternatives which are discussed.

4.3.1 TSPThe 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 allauthorization 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 languagecompilers originally designed for the GNU project and used extensively in UNIX environments.

21

possibility) to explicitly use an authorization protocol like OIAP or OSAP since it ismanaged internally by the TSP. The TSP functions are accessed through a vendorprovided dynamic link library together with the TSS header files [35] which also areincluded with the prototype source code.

4.3.1.1 Class StructureThe TSPI is defined as a C interface but uses an object-oriented approach. The followingclasses 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 theContext, Policy, TPM and Key classes. Of these all but the first are all TSP objects andare created with the Context method Tspi_Context_CreateObject.

4.3.1.2 Policy HandlingIn order to hide the cumbersome authorization sessions from application developers, theTSPI introduces the concept of Policy objects. The TSPI of course uses authorizationsessions internally, but they are abstracted from the developer. The TPM and Key objectsare both so called authorized objects. This means that they both have to be assigned to aPolicy object before usage. A Policy object contains authorization information for anentity. The authorization value for the TPM object is the owner authorization value. Theauthorization value for a Policy object is set using Tspi_Policy_SetSecret. Thecaller 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 sessionsinitiated with the authorization data found in the appropriate Policy object.

4.3.1.3 Attribute DataAll TSPI objects have different attributes (properties). These attributes can be set or readusing the following functions which are inherited by all subclasses.

Tspi_SetAttribUint32 and Tspi_GetAttribUint32 for 32-bit propertiesTspi_SetAttribData and Tspi_GetAttribData for properties of arbitrary length

22

4.3.2 BIOS INT 1Ah InterfaceWhen using the TPM from the pre-boot environment none of the previously mentionedinterfaces 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 whendiscussing authorization sessions has to be used. Input and output of these commandsneed somehow be communicated to the TPM though. This would normally be taken careof 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 toexpose an INT 1Ah assembler interface [28]. Using this interface it is possible to sendand receive byte strings from the TPM via addresses in the processor registers. A smallset of TSS functions might also be available depending on the manufacturer. There arecertain 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 intotheir BIOS’s. According to the major BIOS’ vendor Phoenix Technologies the INT 1Ahinterface will never be incorporated into the PhoenixBIOS product but will be supportedin their next generation BIOS called Trusted Core. It is required according to the TCGspecification but if there is no actual implementation that is of little use. According to ajoint presentation held by Microsoft and HP at WinHEC 05 (Windows HardwareEngineering Conference) Microsoft’s next generation OS Windows Vista will use theabove mentioned INT 1Ah interface for its feature Secure Startup [14]. This fact willprobably constitute a rather good incitement for the BIOS vendors to expose theinterface.

4.3.3 Vendor-specific Device Drivertpm.h, nsc_driver.c

The alternative to using the BIOS-interface is to write a kernel device driver accessingthe TPM directly on the LPC-bus via hardware I/O ports. This was the way chosen in thisproject, 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 arestandardized when and how to send these commands is vendor specific. This demands

23

development of a separate driver for every different TPM model. Such a driver collectionmust also include an identification mechanism of the chip vendor and model.

Writing device drivers either requires input from the chip vendor or hardwarereverse engineering (like eavesdropping on the LPC bus or debugging a binary devicedriver in kernel mode). The easiest way to get a prototype running was to look at theLinux kernel source files. The Linux kernel does not support all manufactured TPMmicrocontrollers, but does support Atmel, Infineon and National Semiconductor. Theprototype device driver was developed on an IBM Thinkpad T43 which contains an NSCIntegrated TPM 1.1. The driver is implemented in nsc_driver.c with header filetpm.h. The only exposed functions are tpm_nsc_init and tpm_transmit which areused for initialization and sending/receiving commands respectively. With regards toidentification the prototype checks that it deals with a NSC TPM and fails with error forother TPM types. It should be noted that the Linux kernel code could not be copieddirectly but was only used as inspiration for the device driver.

4.4 Multiple UsersEven 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 areintroduced when trying to incorporate the prototype into a system originally developedfor smartcards. First of all there is no user concept in PKCS#11. The function C_Loginonly takes a pin code (password) as parameter and no user name. For the prototype this issolved 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 StructureThe simplest key design is to let each user have his/her own RSA wrapping key. Thismeans that multiple copies of the symmetric disc encryption key will be stored, butwrapped with different parent keys. The principal storage structure is showed in Figure4.1.

Figure 4.1 Storage hierarchy in practise

In the figure UKi stands for the RSA key of platform user number i. DK is anabbreviation for disc encryption key and is the symmetric key used to encrypt and

SRK

UK1 UK2 UKn

DK

...

DK DKDK

24

decrypt the hard disc. In TCG context the user keys have to be defined as binding orlegacy keys since they encrypt and decrypt generic data.

An immediate problem with this approach is that the user then would have toprovide the SRK password17 on each single log-on. If, in addition separate userpasswords protect the individual keys, users would be asked for two passwords, which isnot acceptable. The alternative is to demand the SRK authorization value to be a certaindummy value, for instance all 20 bytes equal to 0. This is how Windows Vista hasplanned to do it in Secure Startup [15]. It is of course possible to change the dummyvalue during the installation and store the authorization value on disc. This would makethe TPM useless to all other applications though, since the password resides with theapplication and not with the user.

An analysis of how the TPM operates is required to see if keeping the dummy valueeven after the installation is a vulnerable approach. At a first glance it seems like givingpublic access to the wrap key would immediately authorize anyone to decrypt the privatekeys. Luckily that is not the case. The SRK is a so called storage key (see key types in2.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. TheTPM_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 knowsthe SRK authorization value it is impossible to decrypt the keys. Referring back to Figure4.1, even if the SRK can be used to decrypt and load user keys with the dummyauthorization value the user keys cannot be used for decryption without knowing theirauthorization value.

4.4.2 Key Blob Storage AlternativesThe protected storage structure of the TPM demands that the encrypted keys be storedoutside the actual chip. There are two possible storage mediums for the key blobs. Thefirst alternative is the so called system area of the PPBE. It is a relatively space limitedarea on the hard disc with an own file system. The other alternative is directly in the evenmore space limited NV memory of the TPM. Remember the minimum size of the NVmemory is set as low as 1280 bytes in [28].

Before an adequate decision could be made, the maximum number of key blobs andtheir sizes needed to be determined. Pointsec currently allows for fifty simultaneous usersgiving a possible need of storing fifty keys. An analysis of the key blob received from theTPM 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 possiblyshorter password.

25

Entity: Space (bytes)TPM key info: 47Public key: SK (key size)Encrypted blob: 256

Figure 4.2 Anatomy of a TPM key blob

The first18 47 bytes is a TPM specific key info structure containing different properties ofthe key. The second part is the public portion of the key in clear text. Since the publicexponent is fixed to 216+1 only the public modulus n is included and the required space isequal 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. Sincethe SRK has to be a 2048-bit key data blobs encrypted with the SRK will be 256 byteslong. From this table it is easy to conclude that the size of the key blob SKB is determinedby:

SKB = 47 + SK + 256

A corresponding table for the different common key sizes is given below.

Key size (bits): Space (bytes):512 3671024 4412048 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 beapproximately 20kb19. Worst case scenario with only 2048-bit keys would need about28kb. It is easy to see that there is no guarantee that such an amount of data would fitonto an arbitrary TPM with a minimum of 1280 bytes storage. It is also a bit impracticalto use the NV memory space from a user interface point of view since NV usage requiresowner authorization. User interaction should be kept to a minimum so owner passwordinput should definitely be avoided if possible. Storing the encrypted key blobs directly onthe TPM with owner password protection gives an extra level of security but is notqualitatively different from storing them on disk since the TPM regards everything in theNV 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 inthe TPM Specification Part 2, Structures.19 kb as in kilo bytes.

26

4.5 Tpmutil Implementation

4.5.1 Interface DecisionIn making the decision to use a TSP many factors were considered. The ideal would havebeen to use MS-CAPI together with the vendor provided CSP. However MS-CAPI is anabstract high-level interface and therefore only supports a subset of the TCG SoftwareStack (TSS).

With MS-CAPI it is for instance impossible to decide on which parent key shouldbe used for wrapping. When loading the key blob into the TPM to use the key, the callingapplication needs to know both the id and authorization data for the parent key. If theparent key is unknown it is of course impossible to use the wrapped key. The encryptedprivate keys exported from the CSP are furthermore not compatible with theTPM_STORE_ASYMKEY structure mentioned in Section 4.4.2 on page 24. For theTPM 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 operationscan be performed with a TSP making the solution less prone to errors.

4.5.2 Structuretpm_util.c, tpm_actions.c, tsp_int.c

The command line functionality of the program is implemented in tpm_util.c. Fromthere, functions (implemented in tpm_actions.c) performing the chosen action arecalled. These functions in turn use the TSPI which is abstracted in tsp_int.c. This filehandles the linking with the TSP dll and declaration of all TSPI functions.

4.5.3 Functionalitytpm_actions.c

The primary tasks of tpmutil are to create RSA key pairs for new users and generatecorresponding verifiable certificates to the user certificate store. Certificate stores and theCA concept are presented in Appendix A.3. Together with every key blob a SHA-1 digestof the username is stored. This is to tell the PKCS#11 library which key to load and usewhen C_Login is called. In addition the program needs to store the generated key blobsin the system area (or on the TPM) and needs to be able to change user passwords. Inorder to achieve this some additional support functionality is required.

Before any key generation can be done, TPM ownership needs to be taken and theSRK authorization value needs to be set. To be able to generate verifiable certificates, aself-signed CA certificate is first created and added to the root certificate store. The CA

27

certificate is then used to sign and verify the user certificates. All certificate parsing andcreation is performed using a WIN32 version of OpenSSL20.

4.5.4 Users’ GuideThe different command line options for tpmutil are listed below:

-to Take Ownership-ca Generate CA certificate and write it to the root certificate store-gk Generate a user key-ks arg Choose bit key size for –gk option (default is 1024)-cp Change a user password-dll 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 beperformed. First ownership needs to be taken and a CA certificate created. After that it ispossible to add users (generate user keys).

4.6 Pre-boot ImplementationThe 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 atheoretical 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 readerwhich returns dummy IFD function pointers since there will be no smartcardcommunication. The dummy reader is presented in Section 4.6.1 and the rest of thechapter is devoted to the design of the PKCS#11 library.

4.6.1 Reader.binpinit.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 nosmartcard communication is performed. Instead p11.bin accesses the TPM directlyusing the device driver described in Section 4.3.3 on page 22. Therefore reader.binwas implemented as a dummy smartcard reader returning empty function pointers tomake the PPBE believe there is a smartcard present.

20 OpenSSL is an open source implementation of the SSL (Secure Sockets Layer) protocol which containscertificate handling functionality.

28

4.6.2 MuscleCard Plug-inp11*.c, musclecard.c, tpm_plugin.c

The interface implementation is built on an open source framework called MuscleCardfor using smartcards across multiple platforms [3]. Included in the MuscleCard suite is aPKCS#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 TPMcommunication. However, as much code as possible, including all session and transactionhandling was left untouched in order to save time and avoid unnecessary errors. ThePKCS#11 functions are defined in the source files with the prefix p11 and theMuscleCard interface is implemented in musclecard.c.

In order to achieve the dependency change as clearly as possible the TPM specificcode has been placed in a so called MuscleCard plug-in (tpm_plugin.c). TheMuscleCard API looks for inserted smartcards and loads their corresponding plug-in viatheir ATR string21. Even though we know that the TPM is not a smartcard, a special TPMATR string needs to be used in order to load the correct plug-in. The MuscleCardfunctions in musclecard.c calls the corresponding plug-in functions which then in turnaccess the TPM as described in Figure 4.6.

4.6.3 TPM Access ArchitectureTpmAccess.cpp, ViaWindows.cpp, ViaLPC.cpp

To facilitate simple change of actual access method to the TPM, a small C++ classhierarchy was defined. The base class TpmAccess was specified containing virtualmethods which must be implemented by all subclasses. In order to keep the differences ata minimum, as much code as possible was placed in TpmAccess.cpp. The classhierarchy is displayed in Figure 4.5.

Figure 4.5 Class hierarchy for the TPM access classes

The virtual methods implemented by the subclasses, besides the constructor anddestructor are:

§ TPM_Connect – Initializes the TPM connection.

21 ATR – Answer to Reset is a byte string uniquely identifying a smartcard type.

TpmAccess

ViaWindows ViaLPC ViaBIOS

29

§ 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 usingVisual Studio. For accessing the TPM it uses the vendor provided TCG Device DriverLibrary (TDDL). The reason for using TDDL and not a higher level interface is to makethe transition between access methods as smooth as possible. TDDL includes the functionTddli_TransmitData which allows the caller to send byte commands directly to theTPM. The Windows p11 library is compiled together with p11_test.c in order to makean 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 PPBEduring pre-boot authentication.

The ViaLPC class is the “real” TPM access point and is thus compiled with DJGPPinto the p11.bin which is used by the PPBE. Its structure is very similar to theViaWindows class with the difference that transmit_data from the device driver iscalled instead of Tddli_TransmitData from the TDDL. Before TPM_TransmitDatacan be called the device driver needs to be initiated. This is done when callingTPM_Connect. The decision between using ViaWindows or ViaLPC is made duringcompile time depending on compiler set macros.

The class ViaBIOS is not fully implemented. It only contains empty functionheaders, hence the dashed connector. It is possible that future BIOS versions will supportthe INT 1Ah interface. If TPM support is to be incorporated into Pointsec for PC usingthe INT 1Ah interface would be preferable.

4.6.4 Special Coding Adaptationslibc.a, Bridge.cpp

In the pre-boot environment no functions leading to DPMI22 calls (malloc and printffor example) can be used. Therefore the code is not linked with the normal libc.a23 butwith a slimmed down version of the library containing only the C functions we need (andcan use). The new libc.a library is created dynamically from the makefile using theDJGPP (originally UNIX) command ar.

Even though DPMI calls cannot be made it is still possible to allocate memorydynamically. PPBE specific versions of the C functions malloc and free have beenimplemented previously. Function pointers to these special purpose allocation functionsare passed to both reader.bin and p11.bin during initialization. The functionpointers 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 inprotected mode.23 libc.a is the standard C linking library in DJGPP and contains commonly used functions like strlen,printf etc.

30

3.2 on page 18, the function pointers follow arrows downward from the PPBE to thedrivers.

MuscleCard plug-ins are by default written in C and the TPM access class hierarchyis written in C++. This implies a need for calling C++ functions and creating C++ objectsfrom C. Calling C++ functions from C is relatively straightforward. It is only a matter ofdeclaring the needed functions in the C++ header file with the keyword extern C andtaking care of some macro conditions. To create C++ class instances from C is a bittrickier. It is possible to create a C struct corresponding to the C++ class and applysome 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 inturn instantiate the appropriate TPM access class.

The code for the pre-boot environment is linked24 without the use of any standardlibraries. Therefore the C++ operators new and delete had to be overloaded. This waseasily done in Bridge.cpp using the new versions of malloc and free received inppbe_util.c.

4.6.5 TpmAccess ClassTpmAccess.cpp

Combining the descriptions in Sections 4.6.3 and 4.6.4 the complete information flowfollowing a PKCS#11 call involving the TPM is illustrated in Figure 4.6.

Figure 4.6 Information flow during a PKCS#11 function call.

The TpmAccess base class was designed with the intention to minimize the differencesbetween its subclasses. Most of the non-virtual methods in TpmAccess are directmappings of TPM byte commands like TPM_OIAP and TPM_LoadKey.

A non-intuitive arrangement that might need some explanation is how the passwordis verified. When C_Login is called (with username and password as described inSection 4.4 on page 23) the first thing that happens in TpmAccess is that the key isloaded 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 themtogether to make an executable or a new library.

PKCS#11function

Muscle-Card

TPMplug-in

Bridgefunction

TpmAccesssubclass

TPMdevice

Callingapplication

31

but only for the SRK. In order to verify the authorization value (hash of the password) anoperation that uses the key need to be attempted. The simplest command which demandskey authorization data is TPM_GetPubKey, which retrieves the public key from a keypreviously loaded into the TPM. Therefore a call to TPM_GetPubKey is attempted eventhough we already have the public key. If this results in an authorization failure thepassword is incorrect. All TPM command responses are of course verified using theHMAC protocol described in Section 6.3.1 on page 37.

4.6.7 Objects and Functions SupportedThe 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 nofunctional requirement for such a possibility. Of the functions described in [20] thefollowing 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

32

5 ManageabilityManageability in the context of this report means the ensuring of the continued health ofa software system with respect to performance, scalability, reliability, availability andsecurity. With regard to a TPM enabled disc encryption system, manageability involvestopics such as installation procedure, recovery after hardware failure or password lossand various administration issues. The goal of this chapter is to identify and proposesolutions to manageability problems which will be encountered if incorporating TPMsupport into Pointsec for PC.

5.1 InteroperabilityA fundamental problem which cannot be avoided is how to deal with different TPMmodels and TSS versions. As discussed was in Section 4.3 on page 20 low level access tothe TPM in a pre-boot environment is not standardized but is vendor dependent. Thiscreates a situation where a unique driver needs to be developed for every TPM. It ispossible that in the future a currently specified but not implemented BIOS interface canbe used (see Section 4.3.2 on page 22).

Another similar problem is that different computer vendors use different softwarestacks (TSS). Unfortunately, even though TSS is standardized it seems like there aresome discrepancies between different TSS implementations. The prototype code forinstance works on the NTRU TSS but fails when using the IBM TSS. A possible solutionis to use TDDL directly and basically write a small TSP yourself. An immediate problemwith that solution is that the vendor provided TSS most likely will lock the TDDL andprevent other applications to gain access to the TPM. The application would then have toidentify the name of the TCS NT service and shut it down with the Windows NT systemcommand NET STOP. Another problem is that not all TDDL implementations exportidentical function names. This issue is however simply solved by checking the TDDLs ofall vendors manually and hardcode the different function names.

5.2 AdministrationCurrently when adding a new Pointsec user, “smartcard” can be specifically chosen asauthentication type. Adding a TPM option in the dialog would be the intuitive way ofincorporating TPM support. Typically a dll could then be called which would create thenecessary keys and return the public key used for encryption. The modularization wouldminimize the changes needed in the current product and give a flexible structure.

If the TPM is disabled or deactivated during the installation phase TPM accountscan not be created. In order to use the TPM it must currently be enabled/activated bychanging settings in the BIOS. As is further discussed below it is not possible to ask anormal user to perform such actions.

33

5.2.1 User TransparencyAn 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 madeabout the application’s interface. Some TPM actions unfortunately require physicalpresence assertion directly from BIOS (see Section 6.2 on page 37). Changing settings inthe BIOS is well beyond what can be expected from the normal user. It is possible thatthe use of the BIOS will change in the future. The problem with user transparency mustapply to all applications which possibly could make the TPM designers choose anotherpath. Otherwise a separation of responsibilities must be made between the user and thesystem administrator. Accessing and using the BIOS is no problem for a systemadministrator. Such a solution is however not optimal, the less mandatory involvement ofthe system administrator, the better. For the sake of prototype development accessing theBIOS was of course not a problem but it should not be underestimated if integrating theprototype into a commercial product.

5.2.2 TPM OwnershipAs mentioned before, a TPM must have an owner in order for protected storage to beenabled. This is due to the fact that the SRK is created when the TPM_TakeOwnershipcommand is issued. The basic provision for the prototype to work at all is knowledge ofthe 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 thatthe owner password is known in order to use the SRK as storage key. Ownershipmanagement 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 PointsecTPM plug-in. The problem with the latter is that it is not hardware based key storage butsophisticated obfuscation. This method is unfortunately deployed by some contemporaryTPM management software. The “right” way to do it is that the user has to provide theowner 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 nopossibility to choose owner authorization value and very likely no option to choose theSRK authorization value. In such cases it is impossible for the TPM plug-in to use theSRK to wrap keys. The creation of TPM accounts should be disabled and the user askedto clear the current owner via the BIOS or some middleware in order to use the TPM. Ofcourse 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 shouldbe asked to clear the current owner so the plug-in can set the “right” authorization value.

34

5.3 RecoveryA necessary feature of any encryption software system is recovery of encrypted data inthe case of an unexpected accident. Such accidents include password loss, TPM ormotherboard failure and hard disc crashes. In Section 2.4.2 on page 14 the notion ofmigratability was introduced. The easiest way to back up a key stored by the TPM is tomake it migratable and export it to another TPM, typically one belonging to the systemadministrator. Three requirements have to be fulfilled to export a migratable key.

§ A public key (received from the destination TPM) used to encrypt the migrationblob 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 notsecurity sensitive. Migration is supported on the lowest command level as well as by theTSS.

5.3.1 Loss of PasswordNormally the problem with lost passwords is resolved through a single sign-on feature inthe Pointsec product family called Remote Help. Using this function administrators canhelp authorized users to gain access to their encrypted data through a challenge-responseprotocol even if the communication needs to take place over an insecure channel. Thisrequires an administrator account to be installed in parallel with the TPM account. Whenlogged in again the user can delete the TPM account and create a new one. The problemwith this approach is that the partition encryption key is no longer hardware protectedsince there is a software based administrator account as well. To overcome this problemthe TPM key could be migrated to an administrators’ TPM. If the administrator use adifferent password (authorization value) for the key then the user does, user passwordloss will not matter. A related problem is that another application has been authorized bythe user to change the SRK authorization value. The easiest action is to ask the user toenter 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 FailureIf the TPM or the motherboard crashes it is of course impossible to use the TPManymore. This requires the TPM to be replaced and makes the TPM account useless. TheRemote Help procedure can be used with the difference that a new TPM need to beinstalled before any new TPM account can be installed. Another possibility just as in thelast Section migration of the user keys to an administrator TPM. That TPM can then beused to decrypt the partition encryption key.

35

5.3.3 Hard Disc CrashThis is the most complicated problem. The way Pointsec resolves hard disc failure andother similar hardware problems is through the creation of a recovery boot disc. On theboot disc the encryption keys are stored protected by passwords. In this way even if thecomputer will not boot normally due to for instance a corrupt file system you can alwaysuse the boot disc. A utility on the boot disc then decrypts the hard disc and non-corrupteddata can be retrieved. This procedure does not work if the user has lost his password. TheTPM user keys can only be decrypted by the SRK inside the TPM. Therefore the TPMkey blobs need to be stored on the recovery disc and then be loaded into the TPM if it isstill intact. The key blobs as such are already password protected but could be doublyencrypted to comply with normal recovery disc usage.

36

6 Security AnalysisA key factor in evaluating the TPM is its protection against attacks. There are severaldifferent strategies an adversary could try in order to compromise a TPM based securitysystem. Examples of such attempts are dictionary, replay and hardware attacks. Analternative to the use of TPMs are smartcards and a comparison focusing on securityaspects is included in 6.5.

6.1 Dictionary Attack ConsiderationsOne possible problem with authentication based solely on presentation of anauthorization value is possible lack of entropy in this secret. The authorization value is a160-bit number giving 2160 (approximately 1056) possible combinations which is too hugea number for a brute-force attack25. However if the authorization value is derived from apassword using a hash function to produce the 160-bit number the protection is not betterthan the password. An attacker could write software performing some kind of dictionaryattack26 on the authorization value. Using a PKCS#5 key derivation function (instead of anormal hash function) would slow the dictionary attack down but not prevent it. Somekind of hardware protection against this kind of attack is required but not specified in theTPM Specification [32]. The specification states that:

“The TPM SHALL incorporate mechanism(s) that will provide some protection againstexhaustive 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 notrespond to commands for a certain period of time. This lock-out protocol is implementedin 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 manufacturersapply the same kind of procedure even though it is not documented. Both the STMicroelectronics 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 commandrequires owner authorization and resets the failure count and lockout period. If anattacker 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.

37

launch dictionary attacks on other TPM resources using TPM_ResetLockValuewhenever the chip locked up.

6.2 Physical PresenceIn order to prevent remote rogue software to take control of the TPM some operationsrequire assertion of physical presence. The thought behind including such a requirementis 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 thepossibility 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 chipand such actions should only be available to the owner and to the physical platformoperator. The latter plainly meaning someone with physical access to the platform. Theactual implementation approach on how to assert physical presence is platform dependentand left to the TPM and platform manufacturer. For PCs the typical way of assertingphysical presence is to change settings in the BIOS. The TPM specification [32] alsomentions the possibility to change a hardware switch but this approach seems not to havebeen favoured by manufacturers. The whole concept of physical presence is a bitproblematic since user transparency is a key to building user friendly applications. Theinconvenience with compulsory BIOS’ setting changes was already mentioned in 5.2.1.

6.3 Command EavesdroppingAn intuitive way of attacking any hardware based security solution is of course throughits I/O interface. In order to provide functionality to the platform and its user the TPMhas to send and receive information. One has to assume that a possible attacker have thepossibility to eavesdrop on this communication. In order to keep authorization data suchas passwords confidential so called authorization sessions are used.

6.3.1 Authorization SessionsAs has been mentioned when discussing TPM ownership all access to TPM protectedresources, such as keys, certificates etc. are authorized through the presentation of theauthorization value for the entity in question. Some operations, such as changing the SRKauthorization value require owner authorization as well. It is not safe to send these secretsin plaintext but they have to be encrypted.

Another communications problem is data integrity (see Appendix C). Even if thecorrect authorization value is presented asserting that the command issuer is an

38

authorized application, the TPM cannot be certain that unencrypted input data isunaltered.

To be able to discuss confidentiality issues regarding command in- and output, theTPM command structure needs to be presented. On the lowest level, commands sent tothe TPM are represented as byte streams on the I/O bus. A schematic view of the inputand 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 standardbut 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 theorder it appears in the figure. The upper part is the input sent to the TPM and the lowerpart is its response. The structures of the headers are identical for all commands eventhough they will contain different data. The authorization parts are optional depending onwhether the command requires authorization or not. Some commands require both ownerand entity authorization, hence auth1 and auth2.

The problems of data integrity and sending plaintext authorization values are solvedthrough the use of HMAC (see Section 2.3.2 on page 10 or Appendix C.2). In principle aSHA-1 hash of the in-parameters are fed into an HMAC function using the authorizationvalue for the requested entity as HMAC key. The resulting message digest is then sent asone 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.

39

User TPM

inparamsHMAC(inparams)

outparamsHMAC(outparams)

Check HMAC digest

Check HMAC digest

calculates the HMAC digest (not the SHA-1 digest) for the in-parameters using yheshared authorization value as key and compares the value with the one received. If theymatch the application sending the command knows the authorization value and inaddition the in-parameters have not been tampered with. The same procedure applies ofcourse for the output information sent from the TPM to the calling application. Anillustration of the principle is shown below in Figure 6.2.

Figure 6.2 Illustration of a command authorization session

This basic approach is however vulnerable to replay attacks. In a replay attack an attackerissues a copy of a command previously sent on the communication line. To prevent sucha possibility a so called rolling-nonce scheme is deployed. The idea is that the bytestream for every new command sent should be unique even for multiple use of the samecommand ordinal with identical parameters. The uniqueness is achieved by concatenatinga random number (nonce) into each HMAC input giving the formula:

HMAC(params) = HMACAuthData(params || nonce)

The nonce to be used the next time is always included in the current input or outputblock. This results in that re-sending an eavesdropped command will not work since thenonce 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 authorizationsession. The two main authorization protocols are called Object IndependentAuthorization Protocol (OIAP) and Object Specific Authorization Protocol (OSAP). TheOIAP is the typically used session type and can be used for authorized access to multipleentities in one session. The downside is that when accessing the same entity more thanonce 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 multipletimes without using the authorization value more than once. The OSAP session type ismandatory for operations requiring owner authorization or for setting or resettingauthorization data.

40

6.3.2 Transport EncryptionEven though data integrity and confidentiality are preserved and replay attacks areprohibited, sending command parameters in plaintext might not be optimal in severalcircumstances. An example is that it is unnecessary to give an adversary knowledge ofprogram 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 streamcipher. The transport sessions resembles the normal authorization sessions in that it uses arolling-nonce scheme. No in-depth description will be given here but transport encryptionshould be used by the pre-boot module since the decrypted partition encryption keyotherwise would be sent from the TPM to the user in plaintext.

6.3.3 SHA-1 VulnerabilityThe 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 (andsimilar) hash functions. In the light of that the choice of SHA-1 as exclusive hashalgorithm might seem a bit unfortunate.

Wang et al. [36] has showed that it is possible to find collisions for SHA-1 with acalculation complexity less than 269 hash operations. Wang has also announced finding amethod using 263 operations but no paper is available yet. SHA-1 uses a 160-bit hash-value which gives a theoretical 280 upper bound on the number of calculations needed tofind a collision. Wang’s result is not a lower bound on the complexity so there is noreason to believe that it is impossible to improve the result even more. Brute forcecalculations requiring 264 operations have already been performed by super computerswhich 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 possiblethat SHA-1 will be replaced in future versions of the TPM specifications. Thetrustworthiness of digital certificates is directly dependent on the collision resistance ofthe hash function, whereas HMAC is not [11]. The critical HMAC property is thatfinding the key used to produce a certain digest (using a brute force attack) must becomputationally infeasible. With 160-bit authorization values brute force still requires2160 operations independent of the weaker collision property. Consequently the recentdiscoveries regarding SHA-1 collisions are not a major concern for the prototypeimplementation in this project.

6.4 Hardware AttacksIn general, hardware protected data is safer than software protected. Hardware attacksrequire physical access to the device, expert knowledge and sophisticated laboratoryequipment. Software protected data must be stored on an unprotected storage device suchas a hard disc giving for instance a possibility for remote attacks. A hardware (or sidechannel) attack is based on information gained from the physical implementation of acryptosystem, rather than theoretical weakness in the algorithm.

41

There are numerous ways to retrieve hardware protected information. There are twotypes of physical attack methods; invasive and non-invasive methods. In invasivemethods laboratory instruments are used to physically recover data from a device usingso 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 analysesits behaviour with regard to power consumption, clock cycles etc. The most commonnon-invasive attacks are power analysis and timing attacks.

6.4.1 Timing AttacksIn a timing attack the attacker tries to extract keys by measuring the time it takes toexecute cryptographic algorithms. Especially asymmetric algorithms are vulnerable tothis approach since the computation times of operations depend on the private key. Atypical vulnerable feature of algorithm implementation is the execution paths (normalconditional jumps). Depending on various properties of the key, different paths of thecode are executed revealing the key’s properties. Kocher [8] designed a timing attack toextract RSA keys used for decryption; however this approach was not enough to break aCRT implementation of RSA. Brumley et al. [1] have shown that even using the CRT foralgorithm implementation is not enough to prevent these kinds of attacks.

6.4.2 Power AnalysisIn power analysis described by Kocher et al [9] the attacker studies the powerconsumption of a cryptographic device when it is calculating. Typical features that can beseen using power monitoring are the 16 DES rounds and RSA operations. Power analysiscan be used to break RSA implementations by “revealing differences betweenmultiplication and squaring operations” [9]. There are two types of power analysis;Simple Power Analysis (SPA) and Differential Power Analysis (DPA). In SPA the powerconsumption of the device is analyzed directly revealing the execution order ofinstructions and possibly also secret keys.

Figure 6.3 SPA monitoring of a smartcard performing DES encryption, measured by Kocher et al.

42

In Figure 6.3 by Kocher et al, SPA monitoring of a smartcard28 performing DESencryption is displayed. The upper graph shows the whole operation. It is surprisinglyeasy to identify the initial permutation, the sixteen DES rounds and at the end the finalpermutation. The lower graph displays the second and third DES round. Even though theprincipal pattern is the same the two peaks are far from identical. From these differencesit 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 onvisual inspection and is vulnerable to obfuscation29. DPA on the other hand is based onstatistical analysis and error correction making it less sensitive for input obfuscation. Thestatistical operations used in DPA even make it possible to trace such small powerconsumption changes as switching of individual transistors.

6.4.3 Invasive AttacksIt is currently not apparent which kind of invasive attacks might be applicable to theTPM. The chip is not yet extensively used which makes it relatively uninteresting forattackers and researchers. The next paragraph discusses some preliminary backgroundprotection information.

6.4.4 TPM VulnerabilityThere are numerous different ways of preventing side channel attacks but what is moreinteresting is whether or not any such methods actually are implemented in the TPM. Oneof TCGs main design goals was to make the TPM cheap to manufacture which preventedthe most advanced tamper protection from being implemented.Statements from TCG members and contributors clarify the intents. A quote from thereport Clarifying Misinformation on TCPA [21], by IBM researcher David Safford readsas 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 poweranalysis, 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 againstphysical threats such as simple power analysis, differential power analysis, externalsignals, or extreme temperature. Physical protection is assumed to be provided by theenvironment.”

28 A smartcard is a removable cryptographic token used to store user authentication data. Smartcards arefurther 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 tointerpret. In this context obfuscation for instance could mean to execute unnecessary parts of the code toavoid conditional jumps and hide the value of the key.

43

There is no indication in the TCG 1.2 specifications that the physical protection should beincreased, so the statements about TPM 1.1 are still relevant. The document Business PCSecurity 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 notspecify the mechanism in which the manufacturer needs to design. The TPM manufacturersare familiar with creating security chips. We anticipate that some TPMs will have strongerphysical protections than other mechanisms. The market will determine what isappropriate.”

To conclude the discussion is an excerpt from a Microsoft report on its next generationoperating system Windows Vista [15] (formerly called Longhorn). This comment aims atthe TPM 1.2.

“Although TPMs are designed to resist tampering or electrical analysis, they aresusceptible to certain physical forms of attack. However, performing the kind of analysisneeded to uncover TPM-protected secrets requires physical access to the machine andadditional hardware, making secrets on a TPM-enabled platform more secure than those ona software-only system.”

These statements give the impression that there is protection implemented but that it is notsufficient to stop a determined attacker with resources. However the TPM should be judged in thelight of other alternatives such as smartcards, and bearing in mind what kind of security level iseconomically defendable.

6.5 Smartcard ComparisonA highly relevant issue is a comparison to available alternatives. The currently mostapparent competitor to the TPM is the smartcard.

6.5.1 Introduction to SmartcardsA smartcard or Integrated Circuit Card (ICC) is a flat, plastic body containing integratedcircuitry. Smartcards are normally credit card sized and com in two different kinds;memory and microprocessor cards. In addition to storage capabilities the microprocessorcards also includes calculation components like a crypto processor. This discussionfocuses on smartcards used for authentication on a computer platform. These cards areattached to the computer via a smartcard reader and provide cryptographic functionalitylike RSA encryption and key storage. Access to resources on the smartcard is protectedby a secret pin code. A smartcard is only designed to have one user.

44

6.5.2 Main Differences to a TPMA 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 thedifferent mapping structures for the devices are displayed.

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 itsuser. A single smartcard can authenticate the same user on many platforms meaning aone to many mapping. Each platform has only one TPM and a TPM can only be attachedto one platform giving a one to one mapping. Finally a platform must be able to supportmultiple users meaning that there is a one to many mapping between a TPM and the usersof the platform. From a security perspective the mobility of the smartcard has bothpositive and negative sides. On the one hand it is impractical to need a card every timeyou log into your computer and a small card is easy to lose by accident or theft. On theother hand, if the platform is stolen there is no way to gain access if the smartcard is notpresent. A TPM is always present which makes it even more important to protect TPMcontent.

Another difference is that a smartcard stores all keys on the actual device. A TPMonly stores the SRK and uses it to wrap other data which is then stored on an unprotectedstorage device.

A clear advantage for the TPM is its low cost profile and simple use. Smartcardsrequires readers which cost money and are not too practical to carry around either. Aconceptual difference is the ability of the TPM to use machine binding of resources.

6.5.3 Physical Protection ComparisonThe types of physical attacks are the same for smartcards as the ones discussed in Section6.4 on page 40; invasive and non-invasive attacks.

The vulnerability for non-invasive attacks is basically the same for TPMs andsmartcards. The need for knowledge of the design remains. Both devices are relatively

TPM

UserSmartcard

Platform

∞1

∞1

∞1

∞1

45

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 notrequire a reader. This makes it harder for an attacker to control the clock and powersupply to the chip. A major security problem with smartcards is that non-invasive attackson smartcards with known low level design can be performed using a “fake” readerwhich extracts secret key information while the card is performing calculations. This isparticularly dangerous since it provides no tamper evidence. If the keys are stolen withoutthe owner noticing there is no possibility to revoke their validity. The information neededto construct such a fake reader can be determined on an unknown card using micro-probing. Once the structure of the card has been determined, the building of a readerwhich stores secret authentication data is possible.

These advantages will further increase if the TPM is integrated into the CPU, whichis said to be the future plan. In general smartcards are quite vulnerable to non-invasiveattacks. Kocher et al [9] wrote 1998 that they had found some commercially availableproducts which resisted SPA but none that resisted DPA. That is however seven yearsago and new obfuscation designs are certainly available, however obfuscation solutionsare bound to be broken.

Using invasive methods on smartcards is a relatively well investigated area. Thegoal of the attacker is to analyse and simulate the operation of the card to revealinformation like secret keys. The method is described in-depth in Design Principles forTamper-Resistant Smartcard Processors by Kömmerling and Kuhn [12]. They estimatethat a patient low-budget attacker could gather used micro-probing equipment to launch asuccessful attack for under $10 000. For future smartcards a micro-probing workstationmight not be enough. Features below the wave-length of visible light and more metallayers might require more advanced equipment like different forms of advanced beamtechnology. However such equipment is not only very expensive but also requirespecially trained professionals to operate them.

6.6 Key QualityAs was mentioned in Section 2.3.5 on page 11, the generation and prime-number testingof RSA keys must follow the IEEE P1363 standard. This together with using 2048-bitkeys ensures the key quality.

The main factors determining the quality of symmetric keys is the RNG and the keylength. An assessment of the RNG used by the TPM is given in the Trusted MobilePlatform Software Architecture Description [6] released by IBM, Intel, and NTTDoCoMo. They state that:

“In a Security Class 2 or Class 3 Trusted Mobile Device, the TPM’s random numbergeneration function may be used as the random number source.”

The definitions of Security Classes are given in the quoted document but the relevant partis that Security Class 3 is the highest one. Hence, according to authors of the article the

46

random data generated by the RNG holds quality high enough to be used in the mostsecure kind of Trusted Platforms. This information must of course be regarded with somescepticism since IBM and Intel are two main members of the TCG.

6.7 Concluding DiscussionConcluding the previous arguments the TPM is secure up to a certain limit. Some knownattacks on smartcards are applicable to TPM technology as well and other possibilitiesmight exist. It is difficult to estimate the capital and work required to launch a successfulTPM attack since the technology is relatively new and has not received much of attentionfrom hackers and researchers yet. Successful attacks on software using the TPM havebeen launched but that is not relevant for our discussion.

With regards to dictionary attacks on the authorization values, some form ofmitigation is required. Presence of such mitigation has been confirmed on several of thedifferent TPMs available today.

The newly discovered vulnerability of SHA-1 does not affect the HMACauthorization sessions used in the prototype but definitely is a problem for attestationthrough digital signatures.

A considerable amount of work has been put into the open specifications of theTPM to give a good base design for hardware security. When compared to other productsproviding the same functionality the TPM technology seems like a reasonable choice.

47

7 ConclusionBoth 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 SummaryThe three major topics that have been dealt with are manageability, security andimplementation.

With regards to manageability the owner concept of a TPM can be relativelycomfortably dealt with. Installation and deployment interfaces for Pointsec for PC havebeen developed and used. Recovery can be performed in basically the same way asbefore. A possible problem is user transparency since TPM activation requires BIOSaccess. As for interoperability there are a couple of different problems. Unique devicedrivers need to be developed for all TPMs and a solution to inconsistent TSSimplementations needs to be found. The design of the TPM authentication proceduremakes interoperability with other applications using the chip somewhat complicated. Theproposed solution is to let the authorization value of the SRK be a dummy value. Thisway, all applications can create their own keys under the SRK without locking access forthe others.

In the security analysis the TPM was found to be comparable to smartcards. Non-standardized dictionary attack mitigation is required by the TCG and has been found tobe implemented for all tested TPMs. In addition different forms of physical protectionhave been implemented by some TPM vendors. However for cost reasons the TPM is notdesigned to resist sophisticated, laboratory-based physical attacks (and neither aresmartcards). A downside compared to smartcards is that the TPM is mounted to theplatform so the keys are always present for an attacker, though of course in encryptedform.

Writing a proof of concept plug-in providing TPM enabled disc encryption waspossible in the time frame of the project. However the implementation is fairlyspecialized and a fair amount of additional work will be required for possible inclusioninto a commercial product. In general interoperability and non-standardization have beenfound to be time consuming problems.

7.2 OutlookFrom a general point of view it seems like TPM microcontrollers will play a role in futurecomputing. Apple uses some TPM support in OS X and as mentioned before Microsoftplans to use a TPM for the Windows Vista feature Secure Startup. A TPM specificationfor mobile devices is scheduled for mid 2006 and the large TCG contributors continue toput in capital in the area. TPM deployment is even so somewhat of a riddle. Millions ofPC platforms are shipped with TPMs installed but there seem to be no real effort put intodeveloping applications actually utilizing the chip.

48

From a practical point of view TPM inclusion into Pointsec has been proved to bepossible but several issues remain to be solved. Perhaps the most important and timeconsuming is to develop drivers for the different TPM chips. Another problem is the non-compatibility of different TSS implementations discussed in Section 5.1 on page 32. It islikely though that TSS bugs and ambiguities will be found and removed if TPM usage ismore 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 agood idea to keep an eye on the TPM evolvement. The technology is platformindependent 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 pointof view.

49

References

[1] BRUMLEY, D. and BONEH, D. 2003. Remote timing attacks are practical. USENIXSecurity Symposium, August 2003

[2] Common Criteria Protection Profile - Trusted Platform Module. 2003http://www.commoncriteriaportal.org/public/files/ppfiles/PP_TCPATPMPP_V1.9.7.pdf Accessed 2005-12-02

[3] CORCORAN, D. 2002. MUSCLECARD FRAMEWORK – API. 2003http://www.linuxnet.com/musclecard/files/muscle-api-1.3.0.pdfAccessed: 2005-12-02

[4] FRATTO, M., 2005. Trusted Computing: Just Wishful Thinking? , SecureEnterprise Magazine. March 2005,http://www.nwc.securitypipeline.com/howto/showArticle.jhtml?articleId=60400957&pgno=1Accessed 2005-12-02

[5] HP. 2005. Business PC Security Solutionshttp://h18004.www1.hp.com/products/security/qa.htmlAccessed: 2005-12-02

[6] IBM, Intel, NTT DoCoMo 2004. Trusted Mobile Platform - Software ArchitectureDescription v 1.00http://www.trusted-mobile.org/TMP_HWAD_rev1_00.pdfAccessed: 2005-11-30

[7] IEEE P1363 - IEEE Standard Specifications for Public Key Cryptography. 2005http://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 PowerAnalysis and Related Attacks,http://www.cryptography.com/resources/whitepapers/DPATechInfo.pdfAccessed: 2005-12-02

50

[10] KRAWCZYK, H., BELLARE, M., CANETTI, R. 1997. RFC 2104 - HMAChttp://www.faqs.org/rfcs/rfc2104.htmlAccessed: 2005-11-30

[11] KRAWCZYK, H., BELLARE, M., CANETTI, R. 1996. Keying hash functions formessage authentication, Advances in Cryptology - Crypto 96 Proceedings, LectureNotes 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-ResistantSmartcard Processors - Proceedings of the USENIX Workshop on SmartcardTechnology (Smartcard '99), pages 9–20, May 1999

[13] MENEZES, A., VAN OORSCHOT, P., VANSTONE, S. 1996. Handbook ofApplied Cryptography. CRC Press. ISBN 0-849-38523-7http://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, WinHEC05 Conference Presentation http://download.microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWAR05010_WinHEC05.pptAccessed: 2005-12-02

[15] Microsoft. 2005. Trusted Platform Module Services in Windows Longhornhttp://download.microsoft.com/download/5/D/6/5D6EAF2B-7DDF-476B-93DC-7CF0072878E6/TPM.docAccessed: 2005-12-02

[16] Microsoft Cryptographic API. 2005http://msdn.microsoft.com/library/default.asp?url=/library/en-us/seccrypto/security/cryptography_portal.aspAccessed: 2005-12-02

[17] National Information Assurance Partnership. 2001. Common Criteria Evaluationand Validation Scheme Validation Report, IBM Cryptographic Security Chip for PCClients Manufactured by ATMEL (AT90SP0801).http://www.commoncriteriaportal.org/public/files/epfiles/CCEVS-VID300-VR-01-0005.pdfAccessed: 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.

51

[19] RSA Laboratories. 2002. PKCS #1 v2.1: RSA Cryptography Standard.http://www.rsasecurity.com/rsalabs/node.asp?id=2125Accessed: 2005-11-30

[20] RSA Laboratories. 2005. PKCS #11 v2.20: Cryptographic Token Interface Standardftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdfAccessed: 2005-12-02

[21] SAFFORD, D., 2002. Clarifying Misinformation on TCPA, IBM Researchhttp://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdfAccessed: 2005-12-02

[22] SAFFORD, D, KRAVITZ, J. and VAN DOORN, L. 2003. Take Control of TCPALinux Journal, issue 112, August 2003http://www.linuxjournal.com/article.php?sid=6633Accessed 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.ziphttp://www.f.kth.se/~f00-ann/tpm-plugin.zipAccessed: 2005-12-15

[25] TCG Main specification Version 1.1b. 2003.https://www.trustedcomputinggroup.org/downloads/specifications/TCPA_Main_TCG_Architecture_v1_1b.zipAccessed: 2005-11-30

[26] TCG Newsletter May 2005, Volume 1 Issue 2. 2005https://www.trustedcomputinggroup.org/downloads/May_NewsletterAccessed: 2005-11-30

[27] TCG PC Client Specific TPM Interface Specification v 1.2. 2005https://www.trustedcomputinggroup.org/groups/pc_client/TCG_PCClientTPMSpecification_1-20_1-00_FINAL.pdfAccessed: 2005-12-02

52

[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.pdfAccessed: 2005-11-30

[29] TCG Software Stack Specification, v 1.10. 2003.https://www.trustedcomputinggroup.org/groups/software/TSS_Version__1.1.pdfAccessed: 2005-11-30

[30] TCG Specification Architecture Overview Specification v 1.2. 2004https://www.trustedcomputinggroup.org/downloads/TCG_1_0_Architecture_Overview.pdfAccessed 2005-12-02

[31] TCPA - Trusted Platform Module, Protection Profile, July 2002http://www.commoncriteriaportal.org/public/files/ppfiles/PP_TCPATPMPP_V1.9.7.pdfAccessed: 2005-12-02

[32] TPM Main Part 1 Design Principles, v 1.2. 2005.https://www.trustedcomputinggroup.org/downloads/specifications/mainP1DP_rev85.zipAccessed: 2005-11-30

[33] TPM Main Part 2 Structures, v 1.2. 2005.https://www.trustedcomputinggroup.org/downloads/specifications/mainP2Struct_rev85.zipAccessed: 2005-11-30

[34] TPM Main Part 3 Commands, v 1.2. 2005.https://www.trustedcomputinggroup.org/downloads/specifications/mainP3Commands_rev85.zipAccessed: 2005-11-30

[35] TSS Header Files. 2003.https://www.trustedcomputinggroup.org/groups/software/TSSHeader_File1_1b.pdfAccessed: 2005-12-12

[36] WANG, X., YIN, Y and YU, H. 2005. Finding Collisions in the Full SHA-1Collision Search Attacks on SHA1. Crypto 05

53

Appendix A Cryptographic ConceptsThis is a short introduction to the cryptographic concepts relevant for this report. The textis not to be seen as a general introduction to the broad subject of cryptography. It is rathera reference for readers not familiar with ideas and notions used in the report. For theinterested reader I recommend Applied Cryptography by Bruce Schneier [23].

The basic idea behind cryptography is to secure storage and communication ofinformation. The following definition is given by Menezes et al. [13].

“Cryptography is the study of mathematical techniques related to aspects of informationsecurity such as confidentiality, data integrity, entity authentication, and data originauthentication.”

Confidentiality is an expression synonymous with privacy and secrecy. The aim is tokeep information secret from everyone except the people authorized to access it. Dataintegrity means certainty that stored or sent data has not been tampered with. Possiblealterations include addition, deletion or substitution of data. The term authentication isrelated to identification of communicating entities and data sources. In a securecommunication the two parties should identify each other. Information sent over thischannel should then be authenticated as to origin, content, time of creation etc. Dataorigin authentication automatically implies data integrity since a modified message mustcome from another source than the origin.

A.1 EncryptionThe two major tools in providing confidentiality are encryption and decryption. Theprocess of encryption consists of transforming the original message m, called theplaintext into unreadable ciphertext c. Decryption is the reversed process, transforming cback to a comprehensible message m. The sets of all possible plaintexts and ciphertextsare called plaintext space and ciphertext space.

Encryption and decryption are performed using a cryptographic algorithm30 togetherwith a chosen key pair from the key space K. If the encryption and decryptiontransformations are called Ee and Dd and the key pair (e, d) a general description is:

Encryption: Decryption:),( meEc e= ),( cdDm d=

The encryption keys e and d can of course be identical. Let us define the sets ofencryption and decryption transformations : KeEe ∈ and : KdDd ∈ . For thesetransformations to comprise a proper encryption scheme there must for each Ke∈ exist a

30 An algorithm is finite set of instructions for accomplishing some task which, given an initial state, willterminate in a corresponding recognizable end-state.

54

corresponding Kd ∈ satisfying 1−= ed ED . In other words all ciphertexts have to berecoverable. A typical encryption scheme is RSA, described in A.1.2.

Before discussing different possible implementations it is worth to notice that thereactually exists such a thing as a theoretically unbreakable encryption scheme. It is calledthe one-time-pad. The encryption and decryption transformations are just XOR31 with thekey, and the keys e and d are equal. The problem is that the key needs to be exactly aslong as the message. If the key is disposed and never used again it is actually impossibleto brute force32 through all possible keys. The reason for this is that all possible messagesof right length in the message space will be generated and there is no way to determinewhich one is the original plaintext. However distributing and using these keys arecomplicated and therefore the one-time-pad is not suitable for automated use incomputing and network environments.

A.1.1 Symmetric EncryptionIn a symmetric key encryption scheme it is computationally easy to determine d from eand vice versa. In reality most symmetric schemes uses a key pair where e = d, hence thename symmetric. The requirement on such a scheme is naturally that both e and d be keptsecret. In other words, it is impossible to send an encrypted message to someone withoutbeing able to decrypt all other messages encrypted with the same key. This leads to the socalled key distribution problem. A network with n entities communicating with eachother one will need unique keys for all combinations giving )( 2nΩ keys that somehowneed 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 EncryptionStandard (DES) and the Advanced Encryption Standard (AES). DES has a small keylength (56 bits) and is now considered relatively insecure. AES is successively replacingDES 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 EncryptionThe characteristic of an asymmetric (public-key) encryption scheme is that given e it iscomputationally infeasible to compute d. If that is the case it is safe to publish yourpublic key e while keeping the private key d for yourself. When someone wants to sendan encrypted message they just look up the recipient’s public key, encrypt the messageand send it away. Then only the entity in possession of the corresponding private key candecrypt the message. The origin of the public key needs of course be authenticated butthis is in general a much simpler problem then the original key distribution problemmentioned earlier.

31 XOR is the exclusive or between two binary strings. Example 0010 XOR 1011 = 100132 Brute force is an exhaustive search of the complete key space, trying all possibilities withoutdiscrimination.

55

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 impossibleto reverse. A typical example from life is dropping a vase on the floor, it is easy to drop itbut to reassemble the original from the pieces is extremely difficult if not impossible. Thetrapdoor functions also need to have a back-door so that it is easy to put the vase backtogether again if you know a certain secret. Unless you need a hash function (discussed inthe 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 theproduct of two large primes, but practically impossible to determine prime factors giventhe composite number. Take the four digit number 1887, it is fairly small but finding itsfactors 37 and 51 would take most people a while (the example is only intuitive and saysnothing qualitative about the actual complexity of prime factorization). An RSA key pairconsists of the public key (n,e) where n is the composite number mentioned before andthe private key d. The public exponent e is randomly chosen and the private exponent d isderived using the value of e and the factorization of n. In order for RSA to be secure nneeds 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 utmostsecurity. If using the previously introduced general description of an encryption scheme,the RSA scheme can be described as:

Encryption: Decryption:nmc e mod= ncm d mod=

Encryption and decryption is in general much slower in asymmetric then in symmetricencryption schemes. Since computation resources normally are limited, a typical use ofRSA is to encrypt a symmetric key which in turn is used for the actual encryption of themessage.

A.2 Hash FunctionsBeside 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 predefinedlength. A more rigorous definition is given in [13]

“A hash function is a computationally efficient function mapping binary strings of arbitrarylength 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 inputstring. Since the message space is much larger than the n-bit hash-value space collisionsare unavoidable. The two main goals in designing hash functions are to make it

56

computationally infeasible33 both to generate collisions deliberately and to find theoriginal message given a digest. The latter property is ensured by the hash function beinga one-way-function34.

A special kind of hash functions, called message authentication codes (MACs) areused to obtain message authentication using symmetric techniques. The input to the MACis a message together with a key. The output is a hash-value which is “impossible” toreproduce without knowledge of the key. One type of MAC is the HMAC which is usedby 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 hashowever recently been questioned, see Section 6.3.3 on page 40.

A.3 Digital Signatures and CertificatesAnother area where hash functions prove useful is digital signatures. The idea is to verifythe origin and integrity of a message. Creation and verification schematically follow theprotocol described below.

Alice wants to send a message to Bob. First she computes the digest (hash-value) ofthe message and encrypts it with her private key; the digest is called the signature. Thenshe sends the message and the signature encrypted with Bob’s public key. Bob receivesthe message and decrypts it with his private key. He then calculates the digest for themessage and decrypts the signature with Alice’s public key. If these two values match hecan 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 certificateis used to bind a public key to a specific individual or organization. Information likename, address etc. can be stored in the certificate. A certificate is typically signed by aCA (certificate authority) which guarantees that the identity information and the publickey belong together. The CA itself uses a so called self-signed certificate which is calleda root certificate. In Windows XP there are so called certificate stores, where certificatesinstalled on the computer are stored and managed. The most common ones are thepersonal certificate store (MY), and the root certificate store (ROOT). When anapplication attempts to install a certificate into the root certificate store, a dialog pops upasking the logged in user for consent. The installed root or CA certificate can then beused to sign other certificates. All certificates in the root certificate store areautomatically trusted.

33 The term computationally infeasible means practically impossible due to practical limits of time andhardware. 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 AppendixA.1 on asymmetric encryption).

57

Appendix B PKCS#11This appendix gives an introduction to the PKCS#11 standard. The text is meant to focuson aspects particularly relevant for this project.

B.1 IntroductionPKCS#11 is a standard for accessing cryptographic tokens, published by RSALaboratories. Version 2.20 of the standard can be found at [33]. PKCS#11 is a part of thesuite of Public-Key Cryptography Standards from RSA Laboratories. The document isonly an interface specification. It is up to cryptographic token manufacturers toimplement a library for their own device (if they would like to). However the platformindependent PKCS#11 has become publicly accepted and most vendors ship with animplementation included. The TPM is no exception and is commonly shipped with aPKCS#11 module.

B.2 StructurePKCS#11 makes all cryptographic devices look alike from an interface point of view. Itis up to the interface implementer, and not to the application developer to handle devicedrivers and other device specific issues. There is of course no hardware requirement onthe actual device, it could be entirely software based.

Physical devices are internally represented as slots and tokens. Each slot is supposedto represent a physical reader which may have a cryptographic device inserted. Theinterface interpretation of an inserted device is that the slot has a token present. Theinterface allows for no user concept. All devices are thought to have a single user and areaccessed through entering a secret pin code. Certain operations may be performedwithout logging in to the token but there is no guarantee for this in the interfacespecification. The typical way of representing multiple users of one device in PKCS#11is through creating several different slots for a single device. This is basically asimulation of multiple devices when actually only using one. Caution has to be takenwith the log in procedure since different users typically will have different pin codes.

B.3 Use CaseIn this project a pre-boot PKCS#11 library for the TPM was developed. Following is atypical authentication usage scenario of this library. Error handling, variable initializationand some variable declarations have been omitted to highlight the principal usage of theinterface.

58

/********* 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);

59

/* 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);

60

Appendix C AbbreviationsTo facilitate the reading of this paper, commonly used technological abbreviations havebeen used. A list of the explicit meanings of these abbreviations is given below.

3DES Triple DESAES Advanced Encryption StandardAIK Attestation Identity KeyAPI Application Programming InterfaceATR Answer to ResetBLOB Binary Large ObjectBORE Build Once Run EverywhereCA Certificate AuthorityCRTM Core Root of Trusted MeasurementCSP Cryptographic Service ProviderDES Data Encryption StandardDPA Differential Power AnalysisDPMI DOS Protected Mode InterfaceDRM Digital Rights ManagementCAPI Cryptographic Application Programming InterfaceCRT Chinese Remainder TheoremCSP Cryptographic Service ProviderEK Endorsement KeyGPL GNU General Public LicenseHMAC keyed-Hash Message Authentication CodeICC Integrated Circuit Card (Smartcard)IFD Interface Device (Smartcard reader)IEEE Institute of Electrical and Electronic EngineersKCM Key Cache ManagerMAC Message Authentication CodeNONCE Number used ONCENSA National Security AgencyOIAP Object-Independent Authorization ProtocolOS Operating SystemOSAP Object-Specific Authorization ProtocolPCR Platform Configuration RegisterPKCS Public Key Cryptography StandardPPBE Pointsec Pre-boot EnvironmentRNG Random Number GeneratorRSA Rivest, Shamir and Adleman (asymmetric cryptography scheme)SHA-1 Secure Hash Algorithm 1SPA Simple Power AnalysisSRK Storage Root KeySSL Secure Sockets Layer

61

TC Trusted ComputingTCG Trusted Computing GroupTCPA Trusted Computing Platform AllianceTCS TSS Core ServicesTDDL TCG Device Driver LibraryTOE Target of EvaluationTP Trusted PlatformTPM Trusted Platform ModuleTRNG True Random Number GeneratorTSP TSS Service ProviderTSPI TSP InterfaceTSS TCG Software Stack

TRITA-CSC-E 2006:049 ISRN-KTH/CSC/E--06/049--SE

ISSN-1653-5715

www.kth.se