WIXLIB

many of the security issues and practical concerns of previous versions 1.0–1.2. According to this specification, a TPMprovides a number of desirable hardware and security features. It is equipped with secure non-volatile memory, a set ofplatform configuration register (PCR) banks, a processor torun TPM code in isolation, co-processors for common cryptographic primitives (e.g., RSA, ECC, SHA-1, SHA-256), aclock, and a random number generator. By default, a TPMis deployed as a hardware chip soldered onto a platform’smotherboard. Besides acting as a cryptographic co-processor,a TPM provides the facilities to securely store measurementabout the host platform’s configuration (e.g., software state)in its PCRs and to reliably report those measurements to aremote verifier (remote attestation based on a pre-installedendorsement key), as well as creating secure storage throughTPM protected credentials and data sealing with extended authorization policies. Further, the TPM non-volatile memory,including secure monotonic counters, can be attractive forbuilding security solutions, e.g., version rollback preventionfor software updates.By now, a number of real world applications make use ofTPM. For instance, IBM’s password manager uses it for storing keys, Microsoft windows management instrumentationuses TPM for cryptographic co-processing, Intel’s TrustedeXecution Technology or AMD’s Secure Technology relyon a hardware TPM, several VPN apps can make use of it,TPM is used in full disk encryption (e.g., Microsoft Bitlocker,dm-crypt), and even browsers like Chrome make use of TPMfor different purposes.Measured boot: Of particular relevance for this paper ismeasured (or authenticated) boot based on TPM (see Figure 1). During a measured boot, every component in the bootchain P# measures the next component—a cryptographichash of the component—and then stores this measurement inthe PCR of the TPM ( M# ) before passing on control. SinceBL1 does not have a preceding component, it is not measured and acts as the Root of Trust for Measurement, whichstarts the measurement chain. In contrast to a secure boot,the components are not verified and the boot is not aborted,however, after a measured boot the software configuration ofthe boot components can be attested by the TPM or used toseal storage to this configuration (i.e., values in the PCR).2.3Subscriber Identification Module (SIM)SIM card is the module that authenticates the mobile devicein the network. The primary job of the SIM card is to provethe identity of the owner of subscription to the cellular carrierto enable services like calling, Internet, and various others.Through physically separated pins, a SIM module canachieve the same degree of independence from power supply,reset capability, clock signal, and separated I/O communication with the host platform like a TPM.Since SIM cards are smart cards, they use command-USENIX Associationresponse communication and the application protocol dataunit (APDU) to communicate with their reader. The Androidradio interface layer can be extended to send specializedAPDU commands to the SIM card, which we use in simTPM.It is worth noting, that this APDU command sent by the Android radio interface has to go through the baseband processor. The structure of the APDU commands are definedin the ISO/IEC 7816-4 standard and are recalled later on inSection 4.3Requirement Analysis & Systematization ofExisting SolutionsThere exists many approaches to realize TPM in a way different than using a dedicated hardware TPM. In this section,we systematically compare different solutions of trusted computing procedures using both hardware and software thatare representative for the different implementation options.For comparison, we first re-enumerate the objectives a secure and practical TPM implementation needs to fulfill (Section 3.1) and then discuss the existing solutions (Sections 3.2through 3.4). In particular, this systematization should helpto understand the trade-off of the proposed solutions in comparison to the default hardware TPM and where our simTPMsolution fits into. Table 1 summarizes the discussion in theremainder of this section.3.1ObjectivesWe start by briefly formulating the objectives a trusted module, in particular for mobile devices, should fulfill. We groupthem into security of the TPM itself, the applicability of theimplementation, and desirable deploy-ability objectives.3.1.1Security of TPMThese are objectives that should be fulfilled to ensure thesecurity of the TPM state, its execution and trustworthiness,and secure operations.S1 Confidentiality and integrity of TPM state: The TPMstate should be confidential and protected against untrustedcode (e.g., host platform, non-TEE apps) and only be available to authorized entities. We assign 4 if the confidentialityand integrity of the state is protected through strong securitymeans (e.g., physical isolation), J if they depend on softwareintegrity (e.g., of the OS), and 8 in other cases.S2 Rollback Protection: Reverting the TPM state back toa former version must be prevented or at least be detectable.We assign 4 if rollback protection is guaranteed throughhardware means (e.g., hardware counters), J if there is adependency on untrusted OS but rollbacks can be detected, 8if no rollback protection or detection is provided.28th USENIX Security Symposium535

S3 Trustworthy Endorsement: A TPM should be carryingan asymmetric encryption key called Endorsement key (EK)that can live as long as the TPM and for which credentials exist that verify the authenticity of the TPM and allow a verifierto recognize a genuine TPM. We assign 4 if endorsementcredentials are available to the TPM (e.g., pre-installed at manufacturing time or derived from other verifiable credentials),J if the TPM has to create an EK and prove it is genuinethrough a remote verification, 8 otherwise.S4 Secure Counter: TPM has to provide secure, persistentmonotonic counters, e.g., for its clients or extended authorization policies. We assign 4 if the TPM provides such countersbacked by hardware support or NV-storage of the TPM software state that is protected (i.e., S1, S2 both 4). We assignJ if the security of the counter depends on software integrity(e.g., of the OS or hypervisor). Otherwise 8.S5 Secure Clock: A clock is needed for attestation, for generation of timed attestation keys, and for authorization policieswith lock-out time. If a secure clock is available to the TPM(e.g., its own hardware clock), we assign 4; if the clock depends on shared resources but manipulation can be detectedwe assign J, otherwise 8.S6 Security of TPM Execution: The execution of the TPMcode or firmware has to be protected against compromise.We assign 4 if a strong security boundary exists betweenuntrusted code and the TPM execution environment (e.g.,dedicated physical chip). If the execution environment shareshardware resources (e.g., CPU or RAM) with untrusted codeand the shared resources provide isolation (e.g., modes ofoperation of CPU and separate memory regions), we assignJ, since the shared resources open an attack surface. If thesecurity of the TPM execution environment is based purelyon software means (e.g., hypervisor or OS), we assign 8 forthis weakest form of isolation.3.1.2ApplicabilityThese are objectives related to the application of TPM, suchas authenticated boot or providing secure storage to clients.A1 Secure Persistent Storage: TPM provides a persistentstorage to securely store limited amounts of data (e.g., certificates). We assign 4 if the TPM provides such storage (e.g.,NV-RAM in a dedicated chip) and J if the persistent storageis part of an outsourced TPM state that is protected (i.e., S1,S2 both 4). We assign 8 in other cases.A2 Early Availability: A main use-case for TPM is storingthe measurement of loaded software components, i.e., measured boot. To be able to attest the entire software stack, theTPM has to be early available during the boot sequence. If thetrusted module is available as soon as the platform has power,we assign 4. Otherwise, if the TPM becomes available at late53628th USENIX Security Symposiumstage during boot (e.g., after initializing a separate executionenvironment), we assign 8.A3 Multiple Stakeholders: Computer systems, in particularmobile platforms and enterprise devices, usually have multiple stakeholders co-existing with an interest in protectingcredentials and software on the platform (e.g., end-user, administrator, network operator, software vendor). If the TPMwas designed to support both platform software and users(e.g., distinct hierarchies), we assign 4. If the TPM primarily supports the platform but offers limited functionality tothe end-user, we give J. If the TPM was designed solely assupport for the platform vendor, we give 8.3.1.3Deploy-abilityObjectives related to the deployment of TPM, in particular ifdeployment complies with the requirements of mobile devicesor if it is bound to a specific platform.D1 Mobile Availability: We want to have the TPM availablefor mobile devices. This imposes strict constraints, such as notchanging the current architecture by adding a new on-boardchip. If the TPM implementation adheres to this constraints,we assign 4, otherwise 8.D2 Movability: The TCG specification has introduced theTPM as being bound to its host platform (e.g., fixed part ofthe motherboard). However, depending on the context, themovability of the TPM to another platform is desirable, e.g.,if an associated virtual machine migrates to another platform.If the TPM is generally easily moved to another platform, weassign 4, if it is bound to a specific platform, we assign 8.D3 Bound RTM: The measurements during a measuredboot are given to the TPM by the host platform, starting withthe Root of Trust for Measurement (RTM). To ensure that theprovided measurements indeed describe the TPM’s host platform’s configuration, TPM and RTM must be bound togetheron the same platform. If this binding is achieved via physical means (e.g., TPM and RTM are fixed parts of the samemotherboard), we assign 4. If the TPM receives those measurements from another trusted entity (e.g., another, boundTPM, or a secure boot anchored at the RTM), we assign J. Ifthe TPM cannot establish trust into the RTM, we assign 8.In Section 2.2, while introducing the hardware TPM, weexplained all its properties, which allow the TPM to achievethe objectives we defined in Section 3.1 and summarized inTable 1. Objectives S1 to S6 and A1 to A3 are our interpretation of properties derived from TCG’s mobile TPM [61, 63]and standard TPM specification [62, 64]. We define Deployability as added objectives that simTPM should achieve. Thecurrent TCG specifications do not stipulate a removable TPM.We will use the standard hardware TPM as the baseline thatsimTPM should achieve.USENIX Association

ApplicabilityDeploy-abilityHardware TPMSecurity of TPMS1. Confidentiality and integrityS2. Rollback protectionS3. Trustworthy EndorsementS4. Secure counterS5. Secure clockS6. Security of TPM executionA1. Secure persistent storageA2. Early availabilityA3. Multiple stake holderD1. Mobile availabilityD2. MovabilityD3. Bound RTMsimTPMSecurity of TPM stateIntel SGX [19]ObjectivevTPM? [9]CategoryfTPM [54]Table 1: Comparison of existing TPM implementations4444JJJ884844/ J4/ JJ/ J4/ J4/ 84/ 84/ 84/ 44/ 48/ 84/ 48/ JR4448RJ8488444444444444J4444444448844 fulfilled by the implementation; J partially fulfilled by the implementation; 8 not fulfilled by the implementation; R not applicable for the implementation? First column is for Secure co-processor based vTPM (SCoP) implementation and second column is for Software only vTPM (SW-only) implementation3.2fTPMSpecifically for the mobile domain, a number of past implementations [25, 54, 66] leveraged trusted execution environments (TEE) to realize a software-based TPM. We useMicrosoft’s fTPM [54] as a representative for those implementations, since it is one of the most recent solutions. ThefTPM implementation is widely deployed in Microsoft mobile devices using a TEE on top of ARM TrustZone (D1: 4).TrustZone creates a memory and process isolation betweenthe protected environment ("secure world") running inside theTEE and the "normal world" (i.e., Android or similar), andallows the execution to switch contexts between those twoworlds via a secure monitor.fTPM provides confidentiality, integrity (S1: 4), and rollback protection (S2: 4) for fTPM states by creating a trustedstorage through a combination of encryption with fused keys,device UUID, and Replay Protected Memory Block (RPMB)with authenticated writes and write counter. Any form of secure persistent storage the fTPM offers to clients is based onthis securely outsourced state (A1: J), which is also used toprovide secure counters to clients (S4: 4).Due to ARM TrustZone, the execution of the fTPM environment is isolated from the normal world, however, bothworlds still share the CPU and RAM (S6: J), which hasopened TrustZone TEEs to attacks (e.g., [41]).fTPM does not have a separate secure clock. It uses theclock of the system in cooperation with the untrusted OS(S5: J). To handle the shared clock situation, fTPM implements fate sharing, where fTPM refuses to provide any func-USENIX Associationtionality if the OS does not cooperate.fTPM is primarily designed to provide TPM support tothe platform vendor (A3: 8). The fTPM is a software implementation and bound to one device (D2: 8), since it derivesmany of its credentials from device-specific keys or UUIDs,including its endorsement credentials (S3: 4).Since the fTPM is implemented as software in the TEE ontop of ARM TrustZone, the fTPM becomes only availableonce the TEE has been initialized during the boot sequence(see also Section 2). That means the fTPM (or any TEE-basedTPM) is not early enough available to store measurementsof the early boot stages (A2: 8). But this can be alleviatedby introducing shared memory between the bootloaders andTEE for measurement storage. We will discuss this solutionin more details in Section 4.3.Although the fTPM is only available after the bootchainhas created the TEE, the secure boot transitively extends thetrust put into the RTM (BL1) to the remainder of the securebootchain on the same platform as the TEE. Thus, fTPM canassume that the measurements are done as if by the RTM onthe same platform (D3: 4) if the measurements comes froma component of the secure bootchain.3.3vTPMAnother way of implementing a software TPM is by creatingvirtual instances over a physical TPM [9]. This, in particular,targets cloud environments in which virtual machines need aTPM, but sharing a single physical TPM (or providing an array28th USENIX Security Symposium537

of physical TPM) is not an option. The representative workfor virtual TPM, or vTPM, is based on the Xen hypervisor andproposes two different implementation options: 1) a softwareonly implementation with vTPM instances running inside aprivileged VM, and 2) a secure co-processor (SCoP) to run allvTPM instances with better isolation at the cost of additionalhardware. Both options are not feasible for mobile TPMs(D1: 8), since virtualization is not sufficiently supported oreffective, and adding a secure co-processor is too costly interms of space and power. However, by design vTPMs mustbe movable to different platforms to support migration ofassociated VMs between platforms (D2: 4).In both deployment options, a vTPM has to create its endorsement key at creation time. To establish trust into the EKfor a remote verifier, a genuine, primary TPM on the platform (hardware TPM) must attest the trustworthiness of thevTPM’s EK (S3: J).In case of SCoP-vTPM, the TPM logic and vTPM instances are executed inside the secure co-processor (S6 SCoPvTPM: 4). Further, the secure co-processor used in [9] (anIBM PCIXCC) provides CMOS RAM backed persistent storage. We assume it provides the confidentiality, integrity, androllback protection of the vTPM states as well as sufficient secure persistent storage to the vTPM clients (S1, S2, A1 SCoPvTPM: 4). The same co-processor also offers facilities forsecure counters (S4 SCoP-vTPM: 4) and a secure clock(S5 SCoP-vTPM: 4).For SW-only-vTPM the vTPM instances reside in Xen’sprivileged dom0. Thus, their execution is protected fromuntrusted VMs by only the Xen hypervisor (S6 SW-onlyvTPM: 8), and their state, when stored in persistent storagein dom0, is also protected by only the access control and isolation of the hypervisor and dom0 (S1, S2 SW-only-vTPM: J).Similar, the protection of any persistent storage offered tovTPM clients depends on the integrity and trustworthinessof dom0 (A1 SW-only-vTPM: 8) as does any counter storedin the vTPM state (S4 SCoP-vTPM: J). A vTPM relieson the platform’s clock shared between all vTPMs including untrusted code and not specifically protected (S5 SCoPvTPM: 8). Although vTPM instances are created after thehost platform has booted up, a vTPM receives the initial measurement from the underlying hardware TPM of its platform,which also attests the vTPM trustworthiness, and dom0 protects the vTPM state from migrating to an untrusted platform(D3 SW-only-vTPM: J). Further, vTPM instances are created together with their associated VM, hence, allowing theVM to measure its entire bootchain and store the measurements in its vTPM (A2: 4).In case of SCoP-vTPM, the TPM resides entirely in theIBM PCIXCC, a removable peripheral. Thus, no physicalbinding to the RTM exists and no authenticity/trustworthinessof the RTM is being ensured (D3 SCoP-vTPM: 8), hence,an attacker could move the TPM to an untrusted platform thatfeeds the TPM with arbitrary measurements. This situation53828th USENIX Security Symposiumis very similar to our simTPM, which is also removable, andwe discuss solutions to this challenge in Section 4.3, whichmight also be applicable to SCoP-vTPM.The vTPM does not make any assumptions about whichstakeholder—user or platform—within the associated VMuses the vTPM and supports, like a regular hardware TPM,multiple hierarchies (A3: 4).3.4Intel SGXAlthough Intel SGX is not an implementation of a TPM but asolution to allow applications to establish a TEE, enclave inSGX jargon (S1, S7: R), we include it here for comparisonbecause it offers in many dimensions similar protections asa hardware TPM and shares a lot of a TPM’s objectives (wemark non-applicable objectives with R in Table 1). For thiswork we have only considered stock SGX implementationsin Intel processor to keep the comparison on par with othercandidates. SGX is currently only supported by desktop andserver class Intel processors (D1: 8) and binds any credentials,like generated and derived keys, and transitively sealed datastrictly to the CPU (D2: 8).In SGX, attestation means verifying that a certain enclavecode was initialized correctly and not tampered with by theuntrusted host OS. For remote attestation in SGX an Intelprovided Quoting Enclave provides the facilities to enclavesto do direct anonymous attestation (DAA) using attestationkeys endorsed by Intel (S3: 4). The SGX extensions to theCPU measure the enclaves, hence, the enclaves are physicallybound to their RTM (D3: 4).SGX supports enclaves in sealing data for storing it onuntrusted persistent storage, since enclaves themselves donot have any persistent storage like NV-RAM (A1: J). Inaddition, Intel has added support for monotonic counters [30,43] that allow rollback protection of sealed data (S4, S2: 4).It is a processor based technology, so it can fully utilizethe clock of the system. But the current SGX implementationdoes not accommodate a trusted and fine grained clock for theuser-level enclaves. There is an API provided by Intel, e.g.,get trusted time, but this call can be arbitrarily modified bythe untrusted OS, since it requires to make an OCALL [4, 6,17, 31, 37]. Moreover, any timing mechanism must accountfor the fact that the OS can interrupt the enclave at any pointin its execution, wait for an arbitrary period of time, and thenresume the enclave using ERESUME (S5: 8).Both regular applications and system software can use enclaves and SGX is not restricted to particular stakeholders(A3: 4

uses TPM for cryptographic co-processing, Intel's Trusted eXecution Technology or AMD's Secure Technology rely on a hardware TPM, several VPN apps can make use of it, TPM is used in full disk encryption (e.g., Microsoft Bitlocker, dm-crypt), and even browsers like Chrome make use of TPM for different purposes.