The increasing prevalence of Internet of Things (IoT) devices means some enterprise networks may have hundreds or even thousands of headless devices connected at any given time. Their sheer number presents a large attack surface, while the autonomous nature of IoT devices makes detecting intrusions less likely, increasing the amount of time an attacker has on your network.
IoT devices are also more tempting vectors for supply chain attacks. During these attacks, malicious firmware, hardware, software or other components make their way into device components during manufacturing, meaning the threat is present from the outset. Because of these vulnerabilities, knowing the provenance and status of the devices on your network at all times is one of the most important cybersecurity priorities.
Though specifics vary by implementation, there are a few best practices for securing IoT devices on a network. That includes, for example, insisting on hardware-led device attestation, using technologies like Trusted Platform Modules (TPMs) or Apple’s Secure Enclave. The keys held in these dedicated secure subsystems can help prove a device is what it claims to be. They can also prove that a device comes from a trusted manufacturer. Other best practices include not blindly trusting API keys during enrollment and looking to asset management platforms for signals to use for ongoing device validation (even after enrollment).
A recent custom solution from SecureW2 for an enterprise client centered on headless Linux kiosks that required automatic enrollment and origin attestation. The tool is a good case study for how to do IoT attestation right.
Using TPMs for IoT Device Attestation
Designing systems and processes to ensure the attestation process is thorough, trustworthy and efficient can be challenging. When networks include devices from multiple manufacturers running different operating systems, it can become even more difficult. IoT device attestation adds another layer of difficulty as the devices aren’t associated with any humans.
The end goal is to create documentation that proves every device on a network came from where it claims to be from and has been authenticated. Kalyan Arety, the Director of Product Management at SecureW2, likens it to a human applying for a passport: “It’s like you walking into a passport office saying that I’m this person and I need a passport document for myself and I’m submitting an application.”
TPMs play a key role in this process by providing a secure, independent hardware system for storing the cryptographic keys used to prove a device’s identity and manufacturer. A TPM comes in several forms: a discrete chip, a hardware TPM integrated into a chip that also provides other functions, or a firmware TPM that runs inside a trusted execution environment on the main CPU. Each type holds keys that provide a hardware-rooted identity and allow for the generation of additional keys for attestation. TPMs can also be used to test for tampering when a device is booted by checking the hashes of each software component against those it stores. TPMs are designed to be tamper-resistant, and the level of physical protection depends on the type. A discrete TPM chip is built and evaluated to resist probing and other sophisticated physical attacks, while integrated and firmware TPMs are not.
TPMs also guard against supply chain attacks. Manufacturers add unique credentials that help establish provenance, allowing organizations to verify that a device came from a trusted source.
“The first issue with IoT devices is that they’re made by a third party. You have different hardware components that come from different vendors. How can you trust that third party?” says Arety. “You should be in a position to say that this hardware is provided by the right vendor that I trust.”
TPM-led device attestation is typically a modern network security best practice, and that’s especially true for networks with many IoT devices. For these networks, establishing where devices came from, whether they’re allowed to be on a network, and whether they continue to be trustworthy are all top priorities.
TPM Device Attestation in Practice
A SecureW2 client needed a solution for securing a number of headless Linux kiosks on their network. The solution needed to let IoT devices authenticate to the network and communicate with each other while maintaining situational awareness over device posture and compliance in real time. The request came with a few specific asks:
- Establishing provenance: How can we know these devices were made by the third party they claim to be made by?
- Fit within memory limitations: TPMs have limited memory, so, the enrollment design must account for the size and location of hardware-protected keys and any TPM-resident credentials.
- Automated enrollment: Manually enrolling many devices is time-consuming and prone to human error, and IoT devices lack an interface for humans to perform enrollment. They needed a system that performed enrollment automatically.
- Open-ended support: Any solution needed to work with the Linux operating system, which does not contain a standardized out-of-the-box attestation protocol. Additionally, the client used devices from different TPM manufacturers, meaning any solution had to be vendor-agnostic.
- PKI-mediated attestation: The solution needed to allow a device’s TPM to interact with a larger public key infrastructure (PKI) to allow validation against the root of trust.
A Custom IoT Attestation Solution From SecureW2
To meet the need for TPM attestation on IoT devices running Linux, SecureW2 built a customized solution — the IoT agent. Once provisioned on a device, the agent initiates device enrollment via the SecureW2 certificate authority, which asks the device’s TPM to complete the attestation process.
Attestation involves the device first asking the TPM for its Endorsement Key (EK). The EK is used to transfer trust to an Attestation Key (AK), which is shared with SecureW2. Our tool validates the AK against the specific root of trust from that device’s manufacturer, proving the IoT device came from where it says it did. Once device validation is complete, the device is enrolled through the SecureW2 automated enrollment platform and SecureW2 signs a Certificate Signing Request (CSR) and issues the device a certificate.
Arety says the open Linux environment was a big plus: “The beauty of these open operating systems like Android, Windows and Linux is that they allow an external agent to be deployed on that operating system.”
Importantly, the IoT agent was made to be vendor-agnostic from the start, meaning it can enroll devices no matter who made them. Authority Information Access (AIA) is an X.509 certificate extension whose caIssuers entry points to where the issuing CA’s certificate can be retrieved, letting the agent fetch intermediates and build the chain from a device’s TPM certificate up toward its manufacturer. The manufacturer roots of trust are pre-provisioned in the agent’s own trust store rather than fetched over AIA, so the client does not need to upload them manually.
A Layered Defense
TPM attestation is just one part of the larger security framework SecureW2 constructed to ensure continuous trust across IoT devices. Arety says the solution comprises four layers:
- Proof of possession: Instead of trusting an API key, SecureW2 issues a short-lived enrollment token to each device. The IoT client or device uses the token to perform an additional proof of possession challenge posed by SecureW2. Only once that challenge is met does SecureW2 sign the enrollment request and issue a certificate.
- TPM attestation: Establishes supply chain integrity, making sure each device was made by the manufacturer it claims to be made by.
- Integration with asset management platforms: The SecureW2 solution works with platforms like CrowdStrike, ServiceNow and Omnissa to constantly assess real-time information on device posture, both at enrollment and afterwards. This lets the organization instantly revoke device access if they detect suspicious behavior.
- Seamless Wi-Fi access: An additional mechanism ensures certificates are provided in a format that Wi-Fi clients can easily parse, enabling efficient network access.
Best Practices for IoT TPM Attestation
The ability to dynamically issue certificates and automate IoT device enrollment drastically lowers the odds of misconfigured or noncompliant devices on the network, a chief security risk in many systems. New devices are never trusted automatically, and a seamless system for enrolling them makes establishing trust easy.
Another priority was monitoring device compliance after deployment using security signals from the client’s CrowdStrike tenant, a strategy called adaptive defense.
“The beauty of our policy engine is that, as part of adaptive defense, we continuously monitor security signals,” Arety says. “That provides a higher level of assurance and security during enrollment and a higher level of assurance and security post-enrollment.”
Any devices that display aberrant or potentially concerning behavior can have their certificates automatically revoked, containing potential threats. These devices can then be easily re-enrolled once trust is confirmed.
Establish Continuous Trust for IoT Devices
The SecureW2 JoinNow Platform includes solutions for seamlessly enrolling and authenticating devices to your network while eliminating shared secrets.
Want to learn more about how the platform integrates with your network? Schedule a demo today.
Key Takeaways
- Device attestation allows organizations to confirm devices on their network are genuine, helping prevent supply chain attacks.
- Attestation typically makes use of dedicated systems like TPMs or Apple’s Secure Enclave.
- A custom solution from SecureW2, the IoT agent, provided seamless, TPM-backed device attestation for a fleet of headless Linux devices.
Frequently Asked Questions
What is a TPM?
A Trusted Platform Module (TPM) is a specialized security component that protects cryptographic keys and can help establish the integrity of a device. TPMs can securely generate and store cryptographic keys, perform cryptographic operations, and record measurements of software involved in the device’s startup process. Because sensitive keys are protected by the TPM, they can help defend against certain types of credential theft and tampering. TPMs are commonly used for features such as full-disk encryption, secure boot, device authentication and certificate-based security.
What is device attestation?
Device attestation is a security process that allows a device to provide verifiable evidence about its identity, configuration, or security state. Depending on the technology, this evidence can include information about the device's hardware, firmware, operating system or security components. A verifier can use this evidence to determine whether the device meets defined requirements before allowing it access. TPMs can support attestation by securely generating or protecting cryptographic keys and helping establish that measurements of a device's startup environment have not been altered. Device attestation provides stronger assurance about a device's trustworthiness compared to usernames, passwords or device identifiers.
How do I enable TPM 2.0?
TPM 2.0 is often already enabled on a device; to check, Windows users can press Windows + R, enter tpm.msc, and check the TPM information displayed. TPM 2.0 is typically enabled through your computer's UEFI/BIOS firmware settings, although the exact procedure varies by manufacturer.
If TPM 2.0 is disabled, restart the computer and enter the UEFI/BIOS setup, often by pressing a key such as F2, F10, Delete or Esc during startup. Look for a security or advanced-settings menu and enable the TPM. On some systems, the setting is called Intel PTT (Platform Trust Technology) or AMD fTPM rather than TPM.
Does Linux support TPMs?
Yes. Linux supports TPMs, including TPM 2.0 devices. The Linux kernel includes TPM support that allows the operating system and applications to interact with a TPM for functions such as cryptographic operations, key protection and platform integrity measurement. Linux distributions can also use TPMs with technologies such as full-disk encryption and measured boot. TPM 2.0 functionality is exposed through kernel interfaces and user-space tools and libraries, including tpm2-tools. The precise capabilities and configuration depend on the Linux distribution, kernel version, hardware and software being used. A TPM is not required for Linux itself to run.
