There are four primary use cases for implementing trusted computing with a Trusted Platform Module (TPM), the cryptographic module standardized by the Trusted Computing Group. This blog will give a brief overview of those use cases, which can be combined to create more complex and powerful solutions.
HSM and Smart Card Replacement
The Public-Key Cryptography Standards (PKCS) #11 defines an API for cryptographic tokens, such as hardware security modules (HSM) and smart cards. A TPM is essentially a traditional HSM that can also emulate a smart card but adds functionality for measuring the software of a system. Applications using PKCS#11 today can use a TPM rather than a smartcard or HSM to perform the same functions, while providing additional functionality, like code measurement and remote attestation, often at a reduced cost.
Create a Transitive Trust Chain
A key part of the TPM’s trusted computing functionality is storing software measurements of the system, which is enabled by a bank of programmable configuration registers (PCRs).
During the system boot, the first program to run is an immutable “core root of trust for measurement” firmware component. It starts an unbroken chain of software measurements and security event logging. Measurements are made by hashing each block of code before it is launched, hash extending these measurements into the PCRs, and then recording these operations in the TCG Event log. These PCR values can then be used to do remote attestation, key sealing, authorization of key use, etc. These measurements assure that the system software has not been altered in any way, even protecting against rootkits and bootkits.
Enhance Performance with Sealed Keys
Many processors have cryptographic acceleration hardware (e.g. AES acceleration) that allows them to handle many cryptographic functions. But the keys are vulnerable to attacks if the system has been compromised. Key sealing allows keys protected by the TPM to be released to the main processor if the system is deemed to be healthy by verifying the system measurements.
Establish a Permanent Strong Device Identity
Public/private key pairs can be assigned to a system as a permanent ID when provisioned during manufacturing. When stored in a TPM as non-migratable keys, a “strong” identity (permanent secret) for the system is established. TPMs are required to be bound to the system, unlike its HSM counterparts. In practice, this means the TPM, which is soldered onto the system’s motherboard, can ensure that the system you are managing is an authorized part of your ecosystem.
Improve Your Overall System Management
Using the use cases above, backend servers and systems management can be designed/enhanced to fully capitalize on powerful TPM security features, including remote attestation, key/certificate provisioning, secure boot and more.
Are you interested in adding security to your IoT device but unsure how to begin? OnBoard Security offers trusted computing consulting to help identify your use cases and architect the best solution for your requirements.
Want to learn more about security system? Check out our latest whitepaper; Setting and Achieving Security Design Goals to learn more.