Posts Tagged TPM

Trusted Platform Module

 Trusted Platform Module

Team Project by: Philip Roman, Vouthanack Sovann, Kenneth Triplin, David Um, Michael Violante, Amy Wees

CSEC640, 9046

November 25, 2012



The focus of this paper is to discuss both current issues and recent developments in Trusted Platform Module (TPM) security as well as its strengths and weaknesses.  The main reasoning behind TPM security devices was to establish a means of trusted computing.  These devices utilize unique hardcoded keys to perform software authentication, encryption, and decryption among other things.  This paper will discuss what TPM is comprised of, its strengths and weaknesses, possible vulnerabilities, TPM attestation, and potential uses for TPM.  The intended audience for this paper are those who are technically savvy with an in depth knowledge of security concepts and a general understanding of TPM, encryption and other cybersecurity concepts.


As trusted computing becomes more prevalent and necessary, TPM enhances the security of information systems acting as a trusted entity that can be utilized for securing storage and cryptographic key generation among other capabilities (Aaraj, Raghunathan, & Jha, 2008).  TPM was created by the Trusted Computing Group (TCG), an initiative between some of the most prevalent information technology corporations in the world, to establish a better means of trusted computing.  The utilization of a TPM chip helps to ensure the security of an information system as it allows the implementation of security from a hardware perspective.  Although TPM technologies and the software that utilizes them inherently contain flaws and vulnerabilities, the primary hesitation numerous groups have had with implementing TPM is that it is too inefficient.  Some organizations, especially those that demand extensive end-user monitoring and activity logging, are hesitant to implement TPM as it will limit their ability to scrutinize activity or capture activity logs.

TPM is composed of three basic elements; root of trust for measurement, the root of trust for reporting, and root of trust for storage.  These three elements refer to platform integrity measurements, the storage of these measurements, and the reporting of values stored (Aaraj, Raghunathan, & Jha, 2008).  A secondary use of TPM is the generation of cryptographic keys.  Figure 1 details the make-up of TPM:

Figure 1: Make-Up of TPM (Aaraj, Raghunathan, & Jha, 2008)


Benefits and Strengths of TPM

            TPM offers three primary benefits: storage for secure content, secure platform specific criteria reporting, and hardware authentication (Ryan, 2009).  By using a TPM to secure content, the user has the benefit of storing files securely without relying on a software based operating system.  In the instance of mobile devices, users can encrypt entire hard drives using TPM thus reducing the risk of loss of sensitive information.  Authors Van Dijk, Sarmenta, Rhodes, and Devadas (2007) explain how it is possible for many users to connect to an untrusted storage device over an untrusted network and protect the information being shared without reliance on a secured common operating system using TPM 1.2 technology.  For example, many users today rely on secure storage servers hosted online so that they can share data between multiple devices and access information from anywhere.  This requires the user to trust that their hosted information is secured with administrators, server and client OS and additional security software, and the server BIOS and CPU.  Van Dijk et al. (2007) argue that in utilizing a TPM chip in the user’s machine and the online server; even peer-to-peer transactions can be completely secured using one-time certificates.  A one-time certificate uses the TPM to verify the identity of the sender and receiver of the information which can be verified at any time after the transaction has occurred.  The verifier also requires no contact with the issuer and need only rely on the TPM chip in the originating machine. Significantly, one-time certificates cannot be counterfeit or falsified even from a hacked machine which could open up their utilization to multiple offline applications (Van Dijk et al., 2007).

A TPM can also collect, secure, and report information about the state of a computer’s components such as the BIOS, boot records and sectors, applications and OS.  The TPM can do this using platform configuration registers (PCRs) to securely pass information measured by one component about the state of another component.  Upon boot-up, component X measures the status of component Y and inserts the data into a PCR where it is secured and able to provide the status of the platform from that point forward (Ryan, 2009).  In order to pass this information known as platform configuration to another entity, the TPM encrypts the configuration using a secured signature key which can only be decrypted by a remote TPM key with the required authentication information (Sadeghi & Stüble, 2004).

Another benefit of TPM is hardware or platform authentication whilst preserving the privacy of the user through Direct Anonymous Attestation (DAA).  Chen, Brickell, and Camenisch (2004) describe DAA as a secure group signature that cannot be tampered with after it is invoked.  Additionally, each user can choose whether or not their signature can be attributed to another allowing anonymity.  DAA requires four participants; the host or platform and its TPM, the issuer and verifier (Ryan, 2009).  The TPM generates a secret message, receives a signature for it from the issuer and then uses that signature to prove to the verifier that the attestation was received anonymously (Brickell, Camenisch, & Chen, 2004).  DAA also allows for detection of rogue or published keys because a verifier can confirm that a signature has already been used.  Brickell et al. (2004) proved that DAA is secure using the random Oracle model assuming strong RSA and Diffie-Hellman are applied.

Weaknesses of TPM

A known weakness of TPM is the cold boot attack which overcomes the disk encryption thought to protect the contents of a hard drive from physical access.  Halderman et al. (2009) report they were able to overcome the disk encryption of BitLocker, TrueCrypt, and FileVault with cold boot attacks.  The idea behind an encrypted hard drive is that if a laptop is stolen in a locked state and the thief powers down the computer, everything in memory would be erased and encryption keys lost.  Unfortunately, this is not always the case.  Bitlocker is provided by Microsoft for use with TPM and encrypts parts of the disk on demand.  Halderman et al. (2009) created an automated tool called “BitUnlocker” using an external USB hard disk with a specialized driver allowing BitLocker volumes to be remounted on a Linux OS.  The tool runs a key finder and tries each key until one works and after breaking into the system allows the disk volume to be searched using the other OS.  When rebooting a Windows laptop and connecting to the external drive, the tool successfully recovered the encryption keys and allowed the hackers to decrypt the disk in moments (Halderman et al., 2009).  An obvious mitigation technique would be to prevent physical access to the system using a defense-in-depth strategy or employing additional encryption methods on mobile technology.

Social engineering may also be a vulnerability to TPM as most Computer manufacturers such as Dell keep a master password list for each service tag number.  Information Assurance professional Morrison (2010) found he could simply call Dell and provide the service tag number and they could provide the key to unlock his BIOS.  Without requiring personally identifying information or passwords, anyone could call a company and receive the same master password.  With that same phone call Morrison also found out makers of external hard drives also record the chips in the devices they sell so the same master password can be generated.  Morrison (2010) recommends using an aftermarket external hard drive that may be less likely to provide such great customer service to protect sensitive mobile data.


TPM Discussion


Ideal Application of TPM


When one looks at applications that function well using TPM a good example is the Random Oracle Model noted by Gunupudi and Tate (2007). As noted by Gunupudi and Tate (2007, p.1) the Random Oracle Model “is an idealized theoretical model that has been successfully used for designing many cryptographic algorithms and protocols”.  The idea with this model is to prove a cryptographic scheme is secure; where all parties, including the adversary, have access to a random function, called a random oracle, and then replace the random oracle with a “good” cryptographic hash function in the standard model. As a method to prove that the random oracle model is secure, evidence was provided that generated a scheme in the form of a standard model – thereby providing an instantiation of the oracle with a hash function that demonstrates that it is secure.

Another example of an ideal application that supports TPM and the TPM functionality is Cloud Computing. This was championed by Lui et al. (2010) where they proposed an idea, and then formally implemented it as virtual TPMs in a cloud-based architecture. The premise behind this development was to provide a technology with the TPM functionality for applications that did not have the use and capability of the TPM chip as part of their platform.

According to Lui et al. (2010) the TPM functionality in cloud computing was noted to be easily accessible to various applications in diverse languages due to cloud computing’s ability to distribute services to basic protocols. TPM and its hardware chip commonly perform well in most applications.  Trusted Platforms add value to applications and services such as electronic money systems, email, workstation sharing, platform management software, single sign-on, virtual private networks, Web access, and digital content delivery (Pearson, 2005).


Law Enforcement Application

When it comes to Law Enforcement and the Trusted Platform Module (TPM), officials see benefits and drawbacks with certain features of TPM.  From a digital forensics point of view, Burmester and Mulholland (2006) note that the advent of trusted computing has strong points.  In fact, the Trusted Computer (TC) enabled features criticized by the naysayers may become a boon for cyber-investigators.  On the other hand, if file-encryption becomes the norm, trusted computing may turn out to be law enforcement’s worst nightmare.


TPM Keys

When trying to determine the effects and the types of TPM keys and its processes, it was noted by Liu et al. (2010) that the trust of TPM mainly lies in its capabilities for secure key management (i.e., key generation, storage, and use), and secure storage and reporting of platform configuration measurements.  Each TPM has a unique endorsement key (EK), which is generated by the chip manufacture.  Before using a TPM chip, users need to take the ownership of the chip and create a storage root key (SRK).  Both EK and SRK are RSA key pairs, and protected by storing their private keys always in the TPM chip.

The TPM contains an endorsement private key (EK) that uniquely identifies the TPM (thus, the physical host), and some cryptographic functions that cannot be modified. How this method works is by the agreeing companies endorsing the matching “public key” to certify the acceptability of the “chip and validity of the key” in question (Santos, Gummadi, & Rodrigues, 2009).


TPM Authorization Protocols


The Object Independent Authorization Protocol (OIAP), according to Ryan (2009) crafts a specific period of time that can affect any object; yet only works with specific directions. To understand how OIAP works, an authorization session which begins with the command TPM_OIAP is executed.  To set up an OIAP session, Ryan (2009) provided the following guidelines, “…the user process sends the order to the TPM simultaneously with a nonce argument.  Nonces that function under the user process are labeled as odd nonces, and nonces under the TPM format are labeled as even nonces.  When the TPM_OIAP obtains the authorization handle, the user process then comes together with the newly received even nonce.  After which, each command within the session sends the “authorization handle” as part of its process, introducing a completely different nonce that is now odd.  The response that is generated from the TPM now comprises of a nonce that is of an even nature.  All authorization Hash Message Authentication Codes (HMACs), contain the latest “odd and even” nonces as part of this process. When looking further into this technology and the OIAP session, the authorization HMACs are keyed on the authdata for the resource (e.g., key) requiring authorization.


Another feature in this process is the Object Specific Authorization Protocol (OSAP). This is where a session is ultimately created that controls an exclusive object that is specified when the session is originally set up.  When looking at OSAP and how it processes or works under TPM, Ryan (2009) again describes OSAP.  An OSAP session is created when the TPM receives the TPM_OSAP command with the name of the session key and an odd OSAP nonce. The reply incorporates the authorization handle, and an even nonce for the “rolling” nonces, as well as, an OSAP even nonce.  During this time period as described by Ryan (2009), the user process and the TPM each calculate a “secret hash value”, also known as the “OSAP secret”, which is comprised of the HMAC of the odd and even OSAP nonces within the session’s authdata.  At this point, instructions in the authorization session may be executed.  In an OSAP session, the authorization HMAC is set on the OSAP confidential value.  The rationale of this procedure is to authorize the user process to store the session key for possible prolonged durations during a particular session, without endangering the safety of the authdata on which this whole promise is based upon (Ryan, 2009).

An OSAP phase can also make use of numerous directives, yet these directives must direct a single object identified at the time the session was established.  The benefits of an OSAP session as mentioned by Ryan (2009), is so that it can be utilized for instructions that will present additional authdata to the TPM.  This OSAP phase can also make use of a number of rules, but the rules must handle a distinct object specified at the time the session was initiated.

Attestation Principle

TPM attestation is a function that allows system verification to take place by utilizing a remote party.  Validation is a key role in the design of TPM and supports the overall structure of a secure system.  This process exists to confirm no modifications have taken place that would deviate from a secure standardized process.  Attestation ensures that no deviations have taken place based on a standardized set of parameters called the Platform Configuration Registers (PCR) (Lioy, 2011).  The deviations attestation may detect include unauthorized software or hardware which can have hostile intent on the overall secure computing process.  The process begins with a platform that contains TPM and a verifier, also known as an appraiser.  TPM within the specified platform requires authentication, to confirm that the components within the system have not been modified, thus creating a trustworthy source.  The TPM possesses an endorsement key (EK) that is delivered to the verifier, which allows the verifier to authenticate the PCR (Segall, 2011).  If the verifier agrees that the platform’s configuration is secure, the verifier will grant an authentication key to the platform indicating a validated attestation.

Attestation Features

The method of attestation may be based on the needs of the organization that requires trust computing.  As attestation models differ, a baseline of relevant features should exist with each model.  According to Coker (2008), attestation architectures should have specific principles to become ideal for use.  The principles may include:

•           Current Information

•           Comprehensive data

•           Limited Disclosure

•           Clear Logical Language

•           Trust Mechanisms

An attestation model that is constantly analyzing real-time information generated by the target system is able to further detect anomalies that could affect the decision of the verifier.  The analysis can be conducted by using system measurement tools that would provide a comprehensive array of information.  The system measurement tool will conduct research on the specific portions of the system.  For example, measuring an operating system’s kernel can help verify that the target was not a subject to a network-based attack (Coker, et al., 2008).    The full-state or attributes of a target may become a necessary feature to validate system contents enabling the attestation system to function.  The internal system data within a target is vital when it comes to the attestation decision making.  However, the full contents of the system state should be controlled by the target itself.  Having the target control the flow of system information will assist in minimizing unnecessary information disclosure, which could potentially expose users within a secure environment.  The target system delivering the encryption key must have a platform language that the attestation system can comprehend.   Moreover, the attestation system must be acknowledged by the appraiser and target system.  This allows all parties to identify the amount of variation between each of the systems.


Attestation Architecture

The design of an attestation system greatly differs based on the needs of the organization using the method to securely process transactions.  A synopsis of five general requirements can provide meaningful content through the principles of attestation (Coker, et al., 2008).  The requirements of an attestation system should include:

•           Measurement Mechanisms

•           Self Protection

•           Delegation thru Proxies

•           Decision Management

•           Target Separation

Architects should devise a comprehensive plan to configure the measurement tool within an appraiser’s system.  Each measurement tool is suited to handle specific target parameters, and will not be able to assess various details from other targets as each target contains a unique output set of information.  Each measurement tool will understand the boundaries and limitations of the target and with the proper configuration the tool will generate meaningful decisions during an appraisal.  In addition to building a sound measurement tool, the system also needs a mechanism to secure the measurement process to prevent unwanted deviations.  A preliminary baseline analysis of the measuring tool should be taken into consideration prior to conducting attestation procedures.  By establishing a baseline analysis, the attestation system will confirm the overall integrity to monitor target information.

Trust and credibility between target and attestation systems present an obstacle for designers.  The information passed from the target to the attestation system will include sensitive parameters that require the utmost protection.  An additional intermediary called an attestation proxy can be established to ensure that the target system delivers the appropriate information, while the attestation system receives the necessary amount of data to perform its decision making requirements (Coker, et al., 2008).  Therefore, trust by the target and attestation system falls on the attestation proxy, rather than having a direct-trust relationship, which would present conflict if the target information is fallible.

Several target values may deliver vast amounts of information to a single attestation system.  Since an attestation system may be required to produce values that correlate to each specific target, a systematic application such as an attestation manager may assist as a databank to perform complex decision making in various scenarios.  The manager can disable specific measurement tools to increase efficiency based on each target’s system state.  While an attestation manager is helpful in the decision making process, a target that contains corrupt information can be a sign of manipulation, which could cause unwarranted modifications to the attestation system.  To prevent the setback from taking place, designers may have the ability to implement virtually created systems that will protect the source attestation system from any potential modifications.  A separate virtual machine will create an additional boundary between targets and an attestation system, ensuring that the target’s configuration, whether valid or corrupt will not have any control over the appraiser’s measurement tools.

TPM Vulnerabilities

Existing vulnerabilities can void the credibility of certain TPM processes through hardware related modifications.  Although viable solutions exist for most vulnerabilities, each attack poses a great risk to the process, creating the possibility of unforeseen consequences.  The most recent version of TPM, version 1.2, addresses critical vulnerabilities found in version 1.1.  In version 1.1, a simple hardware attack is possible using a 3-inch insulated wire to reset a TPM bus, bypassing the protective measures of TPM’s auditing mechanism (Lawson, 2007).  The issue is resolved with TPM version 1.2., however other vulnerabilities continue to exist.

TPM is vulnerable to replay attacks, which can cause redundant processes to occur unnecessarily.  Specifically, the trust computing protocols, Object Independent Authorization Protocol (OIAP) and Object Specific Authorization Protocol (OSAP) are subjected to numerous probes including replay attacks (Bruschi, Cavallaro, Lanzi, & Monga, 2005).  The replay attack vulnerability is mitigated through the implementation of two nonce, hash key messages known as a rolling nonce protocol (Chen & Ryan, 2010).  TPM may also be subjected to the involuntary, extraction of secret keys which could pose a TPM authenticity as verifiers cannot “distinguish between real TPMs and fake ones,” known as rogue TPMs (Brickell, Camenisch, & Chen, 2004).  Viable solutions against rogue TPMs involve the utilization of an intermediary to guarantee the legitimacy of the TPM’s endorsement key.

Future of TPM

TPMs modules are currently inside 600 million PCs as the technology becomes increasingly popular.  In the future, TPM expects to distribute their technology to an additional 500 million machines to include major organizations throughout the world by 2013 (Berger, 2010).  The potential increase in TPM demand creates a widespread issue for manufacturers, as hardware suitability becomes a major setback.  The call to redesign future hardware is a viable solution that would handle new TPM version capabilities (Schoen, 2003).

As the newest version of Microsoft Windows 8 is presented to the public, a security feature labeled Unified Extensible Firmware Interface BIOS standard, a trusted boot mechanism, will be provided by the computer’s TPM (Ashford, 2012).  This component has the ability to measure the BIOS during secure boot, which can be reported through remote attestation to a party that can certify the validity of the BIOS from any possible deviations.  The Trusted Computing Group (n.d.) has released TPM 2.0’s library draft specification to the public.   The additions include:

•           Algorithm Enhancement

•           Improvements to TPM availability

•           Enhanced TPM management

•           Addition Cryptographic services for BIOS security



            The success of cybercrime is a testament to the myriad of ways criminals can infiltrate organizations and cause havoc.  Whether it is through vulnerable, malicious, or misconfigured programs, social engineering, physical theft, or electronic eavesdropping, an intruder only needs to find one weakness to exploit (Challener, Yoder, Catherman, Safford, & Van Doorn, 2008).  This leaves organizations with the daunting task of securing their machines and training their employees against an ever changing array of attacks.  TPM and Trusted Computing look to address all of these attacks in one comprehensive way through the use of key management, authorization protocols, and attestation.  When used to its maximal potential, the consumer can trust that their machines will boot up in a valid configuration, securely store data, identify what user is on what specific machine, and participate in secure protocols with uncompromised keys (Challener et al., 2008).  All of these features work towards the goal of frustrating the efforts of intruders and improving the security posture of an organization.  Being able to do this in a way that requires no in-depth interaction from the end user also means that training costs, insider threat risk, and the danger of a user introducing a threat into the organization is reduced.  Managing the security of end user’s machines from a central root of trust will allow administrators to have a reduced attack surface area to be vigilant of.  The potential impact of TPM truly extends from the top of the organization to the bottom.  With the availability of software that allows organizations to take advantage of TPM, its adoption should grow.

One important piece of software that will assist with the acceptance of TPM is Windows 8.  In Microsoft’s latest version of Windows, TPM has been integrated at many points to enable the setup and management of TPM to be as easy as possible.  An organization that is running Windows 8 along with Windows Server 2012 can take advantage of features such as automated provisioning and TPM management, measured boot with support for attestation, TPM-based virtual smart card, BitLocker network unlock, and TPM-based certificate storage (Microsoft, 2012). These features allow Windows users to take advantage of and integrate with the full suite of TPM protections from key management, to remote attestation, to tamper detection.  As more and more organizations migrate to Windows 8 their ability to adopt TPM as a security policy should grow as hardware to support TPM is also easy to procure.  All of this means that the barrier to entry for organizations to implement TPM has never been lower.  Because TPM is able to address security concerns from a hardware based perspective, it provides a unique ability to bolster an organization’s security posture.  As such, the acceptance of TPM should only increase as the software infrastructure continues to mature to support TPM hardware.

TPM is a wide ranging technology that encompasses many areas of technology.  Because TPM spans so many areas such as key management, remote attestation, and authorization it holds the potential to have a big impact on the way organizations secure their networks.  This ability is attractive to a wide swath of industries such as banks looking to ensure customers have the latest secure software before connecting to their networks, media companies wanting to enforce DRM, or companies seeking to protect sensitive information on laptops.  Although there may be some parties that may have reservations about TPM, their concerns predominantly speak to the effectiveness of TPM and the level of security it achieves.  If an organization does not have concerns regarding computer forensics or end user’s rights, then TPM is an attractive avenue to pursue.  While TPM’s hardware and protocols may have a few vulnerabilities, they have not been shown to be easily exploitable or have disastrous potential and should not serve as the impetus to forgo using TPM.  With all of the benefits mentioned and the continued maturation and expansion of capabilities, TPM’s applicability should grow as well.

The topics explored throughout the course of this writing provide a foundation for understanding what TPM is, what it provides, its strengths and weaknesses, as well as future growth.  These subjects should serve as a comprehensive basis of key current issues and developments in TPM.


Aaraj, N., Raghunathan, A., & Jha, N. K. (2008). Analysis and Design of a Hardware/ Software Trusted Platform Module for Embedded Systems. ACM Transactions On Embedded Computing Systems, 8(1). doi:10.1145/1457246.1457254

Ashford, W. (2012). Will this be the year TPM finally comes of age? Retrieved from

Berger, B. (2010). Securing Data & Systems with Trusted Computing Now and in the Future.. Retrieved from

Brickell, E., Camenisch, J., & Chen, L. (2004). Direct anonymous attestation. In Proceedings of the 11th ACM Conference on Computer and Communications Security, 132-145.

Bruschi, D., Cavallaro, L., Lanzi, A., & Monga, M. (2005, December). Replay attack in TCG specification and solution. In Computer Security Applications Conference, 21st Annual (pp. 11-pp). IEEE.

Burmester, M., & Mulholland, J. (2006, April). The advent of trusted computing: implications for digital forensics. In Proceedings of the 2006 ACM symposium on Applied computing (pp. 283-287). ACM.

Cabiddu, G., Cesena, E., Sassu, R., Vernizzi, D., Ramunno, G., & Lioy, A. (2011). The Trusted Platform Agent. IEEE Software, 28(2), 35-41. doi:10.1109/MS.2010.160

Chen, L., & Ryan, M. (2010). Attack, solution and verification for shared authorisation data in TCG TPM. Formal Aspects in Security and Trust, 201-216.

Coker, G., Guttman, J., Loscocco, P., Sheehy, J., & Sniffen, B. (2008). Attestation: Evidence and trust. Information and Communications Security, 1-18.

Halderman, J. A., Schoen, S. D., Heninger, N., Clarkson, W., Paul, W., Calandrino, J. A., & Felten, E. W. (2009). Lest We Remember: Cold-Bboot Attacks on Encryption Keys. Communications of the ACM, 5(2), 91-98.

Lawson, N. (2007). TPM Hardware Attacks. Retrieved from

Lioy, A. (2011, October 16). Remote attestation. Retrieved from Gunupudi, V., & Tate, S. R. (2007, May). Random oracle instantiation in distributed protocols using trusted platform modules. In Advanced Information Networking and Applications Workshops, 2007, AINAW’07. 21st International Conference on (Vol. 1, pp. 463-469). IEEE.

Liu, D., Lee, J., Jang, J., Nepal, S., & Zic, J. (2010, December). A cloud architecture of virtual trusted platform modules. In Embedded and Ubiquitous Computing (EUC), 2010 IEEE/IFIP 8th International Conference on (pp. 804-811). IEEE.

Morrison, A. (2010, July 21). The social hacking of the un-trusted platform module (tpm). Retrieved from Pearson, S. (2005). Trusted computing: Strengths, weaknesses and further opportunities for enhancing privacy. Trust Management, 91-117.

Ryan, M. (2009). Introduction to the TPM 1.2. DRAFT of March, 24. Retrieved from

Sadeghi, A. R., & Stuble, C. (2004). Property-Based Attestation For Computing Platforms: Caring About Properties, Not Mechanisms. In Proceedings Of The 2004 Workshop On New Security Paradigms, 67-77.

Santos, N., Gummadi, K. P., & Rodrigues, R. (2009, June). Towards trusted cloud computing. In Proceedings of the 2009 conference on Hot topics in cloud computing (pp. 3-3). USENIX Association.

Schmitz, J., Loew, J., Elwell, J., Ponomarev, D., & Abu-Ghazaleh, N. (2011). TPM-SIM: A Framework for Performance Evaluation of Trusted Platform Modules. DAC: Annual ACM/IEEE Design Automation Conference, 236-241.

Schoen, S. (2003). Trusted computing: Promise and risk. Electronic Frontier Foundation, 16, 26.

Seagall, A. (2011). Attestation and Authentication Protocols Using the TPM. Retrieved from

Trusted Computing Group. (n.d.). TPM 2.0 Library Specification FAQ. Retrieved from Trusted Computing Group. Retrieved from

Van Dijk, M., Sarmenta, L. F., Rhodes, J., & Devadas, S. (2007). Securing Shared Untrusted Storage By Using Tpm 1.2 Without Requiring A Trusted Os. Technical report, MIT CSAIL CSG Technical Memo, 498.


1 Comment