Digital signatures, when properly implemented, can provide a strong basis for believing that a message was sent by a known sender, and that it was not altered during transmission, and these two properties are fundamental to any trusted communication. The underlying public-key cryptography can provide us with a high level of assurance that the message could only have originated with the possessor of the private key corresponding to that sender’s public key. Since - in contrast with symmetric cryptography - that private key never needs to be shared with anyone else, if we are confident that the sender has appropriately protected their private key, then we can be confident that the message came from the sender, and we can use this confidence as a basis for authentication.
However, we can only have this confidence if we are sure that the public key in our possession really does belong that particular sender. If the sender is a human being who personally gave us a copy of the key then things are easy, but the estimated 30 billion devices on the Internet of things (IoT) pose a more significant problem. Many of these devices are increasingly in our homes and our vehicles, as well as in critical civilian and even military infrastructure, and their scope and number continue to grow rapidly. Compromised devices or private keys present a grave security risk, and more than ever, services for IoT devices need to be absolutely sure that they are communicating with genuine, authorized and secure devices.
The TPM Protocol can provide manufacturers of IoT devices and the services which use those devices with more confidence in their certificate-based authentication processes for IoT devices containing a TPM.
What is a TPM?
A Trusted Platform Module, or TPM, is a secure system component which, in conjunction with other system components, allows an independent entity to determine if a device’s trusted computing base has been compromised (Trusted Platform Module Library Part 1: Architecture). TPMs are in widespread use on modern PCs and notebooks for applications including secure boot, full disk encryption, and hardware-based password protection. The TPM specifications (version 2.0 being the most recent) are developed by the Trusted Computing Group (TCG). See https://trustedcomputinggroup.org/work-groups/trusted-platform-module/ for more information.
For this article, the key fact is that a TPM can function as a low-cost cryptographic co-processor, providing secure, tamper-proof, hardware-based key generation and encrypted key storage. Since each TPM has a unique and secret Endorsement Key (EK), usually certified by a trusted CA, convenient authentication solutions can be developed which ensure a communicating device contains a legitimate and identifiable TPM. When combined with other TPM capabilities such as secure boot and hardware/software attestation, the security of an IoT deployment can be greatly enhanced.
Device Certification
The EK is unique to an individual TPM. It is generated inside the TPM (or burned into the TPM by the manufacturer), and the private component is protected by the TPM hardware, and cannot be read or exported from the TPM. Once we have verified the EK public component from its certificate, then if we can prove an IoT device possesses the EK private component, we have positively identified the TPM.
When a device wants to authenticate itself with an online service, a common solution is to use certificate-based TLS client authentication. During the TLS handshake, the device provides a copy of its certificate to the server and digitally signs some protocol-defined information to prove that it possesses the private key corresponding to the public key in the certificate. The server verifies the certificate against its database of trusted CA certificates, and then cryptographically verifies the digital signature provided by the device. If both steps are successful, the device is authenticated. (Note: The server may perform additional checks, of course.)
The problem is that the use of the EK is restricted by the TPM to a limited set of decryption operations. The device therefore cannot use it create digital signatures, and so it cannot use its EK certificate for TLS client authentication in this way.
The solution is for the device to use the TPM to generate a second hardware-protected key which can be used for digital signatures, and to have that new key certified by a CA. The CA verifies the EK and, if successful, issues the device with a certificate for this new key which it can use for TLS client authentication.
This approach also has privacy benefits. Because the EK uniquely identifies the device, if the EK certificate could be used for authentication, a device’s activity could be tracked and correlated across multiple services, which may be undesirable. By using secondary certificates, a separate certificate could be issued for each different service the device accesses, or even a separate certificate for each access to the same service, and privacy can be maintained.
Of course, this shifts the burden of identifying the TPM onto the CA. If the EK can’t be used for digital signatures, how does the CA verify that the device possesses the private component?
