Hardware Security Modules and mTLS for IoT: Protecting Device Private Keys

Mutual TLS (mTLS) authentication is only as strong as the protection of the device’s private key. If an attacker can extract the private key from a device — by reading unencrypted flash storage, exploiting an OS vulnerability, or physically decapping the chip — the certificate becomes useless as a security control. The attacker can impersonate the device from any machine.

Hardware security mechanisms break this attack vector. When the private key is generated inside dedicated security hardware and is physically prevented from being exported, certificate compromise requires compromising the hardware itself — a far higher bar than software exploitation.

This article covers the hardware options available for IoT devices deploying mTLS, their integration with the SocketXP agent and BastionXP PKI/CA, and the threat models each addresses.

For the complete mTLS implementation guide, see: Scaling mTLS IoT Security: The Developer’s Guide.

The Private Key Problem in Software-Only mTLS

In a standard software-only mTLS deployment, the private key is a file on the device’s filesystem — for example, /var/lib/socketxp/tls_server.key on a SocketXP-enabled device. This file is protected by filesystem permissions (typically 600, readable only by root), but that protection is only as strong as:

• The operating system’s privilege separation (bypassed by any root exploit)
• The physical security of the storage medium (bypassed by removing the SD card or eMMC chip and reading it directly)
• The encryption of the storage (not present by default on most Linux IoT distributions)

An attacker with physical access to the device can remove the storage, mount it on another machine, and copy the private key in minutes. The mTLS certificate and private key together allow the attacker to impersonate the device to the SocketXP gateway indefinitely, until the certificate expires or is revoked.

Hardware-backed keys eliminate this attack entirely.

Hardware Security Options for IoT Devices

Trusted Platform Module (TPM 2.0)

A TPM is a dedicated security microcontroller — either a discrete chip soldered to the motherboard or firmware running on an existing processor’s trusted execution environment. The TPM 2.0 specification (ISO/IEC 11889) is the current standard, supported on most modern industrial IoT hardware and readily available as an add-on module for development boards like the Raspberry Pi.

What TPM 2.0 provides for mTLS:

• Key generation inside the TPM — the private key is created within the hardware and never exists in unprotected memory
• Key non-exportability — the TPM’s primary protection: private key material cannot be read or exported through any software interface
• PKCS#11 interface — a standard API that allows standard TLS libraries (OpenSSL, mbedTLS) to use TPM-stored keys without the key material ever entering application memory
• Platform Configuration Register (PCR) binding — keys can be sealed to a specific measured boot state, so the key is unavailable if the device has been tampered with (modified firmware, altered bootloader)

Availability on common IoT platforms:

Secure Element (SE)

A Secure Element is a tamper-resistant integrated circuit dedicated to cryptographic operations and secure key storage. Unlike a TPM (which is a general-purpose security chip), a Secure Element is optimized for cryptographic operations and physical tamper resistance.

Common Secure Elements in IoT:

• ATECC608B (Microchip) — widely used in consumer and industrial IoT; I²C interface; supports ECC P-256 key generation and storage; up to 16 key slots
• SE050 (NXP) — Common Criteria EAL 6+ certified; supports RSA, ECC, AES; I²C interface; used in industrial and payment IoT
• STSAFE-A (ST Micro) — ECC-based; designed for device authentication and firmware integrity

Secure Elements are the right choice for devices that need certifiable tamper resistance (EAL 4+, EAL 6+) for regulatory compliance. They are more expensive than TPMs but provide stronger physical attack resistance.

Trusted Execution Environment (TEE)

A TEE is a secure area inside a processor that runs code isolated from the main operating system. On ARM-based IoT devices, this is implemented via ARM TrustZone. The Secure World runs a trusted operating system (OP-TEE on Linux IoT boards) that manages keys and cryptographic operations, while the Normal World runs the main Linux OS.

TEE-based key storage is weaker than a dedicated Secure Element (there is no physical tamper resistance against hardware probing) but is significantly stronger than software key storage and requires no additional hardware component.

Integrating TPM 2.0 with the SocketXP Agent on Linux

For IoT devices with a TPM 2.0 chip, the standard integration path uses the TPM2 PKCS#11 provider — a library that exposes TPM keys through the PKCS#11 interface that OpenSSL and other TLS libraries understand.

Step 1: Install TPM2 Software Stack

On Debian/Ubuntu-based Linux IoT devices:

sudo apt-get install -y \
  tpm2-tools \
  tpm2-abrmd \
  libtpm2-pkcs11-1 \
  libtpm2-pkcs11-tools

Verify the TPM is detected:

sudo tpm2_getcap properties-fixed | grep -i "tpm.*spec"
# Expected output shows TPM 2.0 specification version

Step 2: Generate the Private Key Inside the TPM

Instead of generating the key with openssl genrsa (which would place the key in memory and on disk), generate it using the TPM2 PKCS#11 provider:

# Initialize TPM2 PKCS#11 token
tpm2_ptool init
tpm2_ptool addtoken --pid=1 --label="iot-device" --userpin= --sopin=

# Generate RSA-2048 key pair inside the TPM — private key never leaves
tpm2_ptool addkey --algorithm=ecc256 --userpin= --label="iot-device"

Step 3: Generate a CSR Using the TPM-Stored Key

DEVICE_SERIAL=$(cat /proc/cpuinfo | grep Serial | awk '{print $3}')

openssl req -new \
  -engine pkcs11 \
  -keyform engine \
  -key "pkcs11:token=iot-device;type=private" \
  -out device.csr \
  -subj "/CN=${DEVICE_SERIAL}"

The CSR is signed by the TPM — the private key is used for the signing operation without ever being exposed to the OpenSSL process or written to disk.

Step 4: Obtain the Certificate

Submit the CSR to your certificate authority. SocketXP integrates with BastionXP PKI/CA to issue device certificates using the CSR generated in Step #3 — the CA signs the CSR and returns a standard X.509 certificate without the private key ever leaving the TPM.

Configure applications to use the TPM-stored key via the PKCS#11 interface rather than a key file path.

BastionXP’s Hardware Attestation Model for Linux IoT Devices

BastionXP — the standalone PKI/CA platform complementary to SocketXP’s built-in web-PKI CA module — takes hardware security a step further with device attestation for Linux IoT devices.

In BastionXP’s model, the CA does not merely trust that a CSR came from a legitimate device — it requires the device to prove its hardware identity before issuing a certificate. For Linux IoT devices with TPM 2.0, BastionXP validates the TPM’s endorsement key — a unique key burned into the TPM at the factory — as cryptographic proof that the certificate request originated from a specific, identifiable piece of hardware.

The workflow mirrors Steps 1–4 above: the Linux device generates its key pair inside the TPM, produces a CSR signed by the TPM-resident key, and submits it to BastionXP. BastionXP validates the TPM attestation alongside the CSR, then issues the certificate. SocketXP integrates with BastionXP PKI/CA to deliver this certificate to the device — the private key never leaves the TPM at any point in the process.

The consequence: BastionXP CA can issue certificates with high confidence that the private key is hardware-bound to a specific physical Linux device. Even if an attacker obtains the certificate, they cannot present valid TPM attestation without the original hardware.

This is the strongest available binding between a certificate identity and physical hardware on Linux IoT devices, and it is the appropriate choice for:

• High-value industrial assets and gateways where physical security cannot be assumed
• Healthcare IoT devices storing or transmitting protected health information
• Smart grid and critical infrastructure where device impersonation has physical-world consequences
• Linux edge compute nodes in physically exposed or public locations

Practical Guidance: Matching Security Hardware to Threat Models

For most industrial Linux IoT devices (gateways, edge compute nodes running the SocketXP agent), TPM 2.0 is the practical minimum for protecting mTLS private keys in production. It is available on most x86-based industrial PCs, can be added to ARM-based SBCs, requires no custom firmware, and integrates with Linux’s standard PKCS#11 toolchain.

For devices where a TPM is not available, encrypted storage with a key derived from device-unique secrets (device serial number + a hardware-fused secret) provides a middle ground between plaintext file storage and full hardware isolation.

Certificate Management Workflow with Hardware Keys

When private keys are TPM-backed or Secure Element-backed, the certificate renewal process changes slightly:

1. Renewal CSR generation: Use the PKCS#11 interface to sign a new CSR with the existing TPM-stored private key. The key itself does not change during renewal.
2. New certificate delivery: The CA (BastionXP standalone or SocketXP’s CA module) returns a new certificate signed by the CA.
3. Certificate installation: Store the new certificate file alongside the unchanged TPM-stored key reference. Applications reference the key by its PKCS#11 URI, not a file path.

Next Steps

• Scaling mTLS IoT Security: The Complete Developer Guide — full PKI architecture, SCEP/CRL/OCSP, and BastionXP as the alternate CA
• How to Implement mTLS in IoT — step-by-step mTLS setup with SocketXP
• Lightweight mTLS for Constrained IoT Devices — mTLS on resource-limited hardware without TPM
• Zero Touch Provisioning for IoT Devices — fleet-scale onboarding where hardware identity matters most