Electronics Guide

Security Boundaries and Trust Anchors

An HSM establishes a clearly defined security boundary, often called the cryptographic boundary, within which all sensitive operations occur. This boundary is enforced through physical and logical mechanisms that prevent unauthorized access to the internal state. The root of trust begins with secure key storage, where cryptographic keys are generated within the HSM and never leave the protected environment in plaintext form.

Trust anchors within HSMs typically include:

• Root keys - Master keys provisioned into the device, frequently into one-time-programmable fuses, that establish the foundation of the key hierarchy
• Secure boot verification - Mechanisms to verify the integrity and authenticity of firmware and software before execution
• Unique device identity - Cryptographic identifiers that distinguish each device and enable authentication, sometimes anchored in a physical unclonable function (PUF)
• Monotonic counters - Non-volatile counters that only increment, used to prevent rollback and replay attacks and to track security-relevant events

Tamper Protection Mechanisms

Physical security is a defining characteristic of HSMs. Various tamper protection mechanisms work together to detect and respond to physical attacks:

• Tamper-evident enclosures - Physical packaging, such as security seals or potting compound, that shows visible signs of opening attempts
• Active mesh sensors - Fine conductive patterns surrounding the secure die that detect drilling, cutting, or probing attempts
• Environmental sensors - Monitors for temperature, voltage, and clock frequency anomalies that may indicate fault-injection or glitching attacks
• Zeroization circuits - Mechanisms that rapidly erase keys and critical security parameters when tampering is detected
• Light sensors - Detection of package decapsulation through exposure to ambient light

The response to detected tampering, often called a tamper response or zeroization event, typically involves immediate erasure of all cryptographic keys and sensitive data. This renders the device unusable for further attacks while protecting the secrets it contained.

TPM Architecture

A TPM contains several functional components that work together to provide security services:

• Cryptographic processor - Dedicated hardware for RSA, ECC, and symmetric cryptographic operations
• Random number generator - A hardware entropy source used for key generation and nonces
• Platform Configuration Registers (PCRs) - Shielded registers that hold cumulative measurements of platform state; the PC Client profile defines twenty-four such registers, and TPM 2.0 maintains a separate bank of them for each supported hash algorithm
• Non-volatile storage - Persistent storage for keys, certificates, and configuration data
• Endorsement Key (EK) - A unique, manufacturer-provisioned key pair, certified by an EK credential, that anchors the TPM's identity and is used to derive attestation keys

Measured Boot and Attestation

One of the TPM's primary functions is supporting measured boot, in which each stage of the boot process measures (hashes) the next stage before execution. These measurements are extended into PCRs: an extend operation replaces the register contents with the hash of the previous contents concatenated with the new measurement. Because the operation is one-way and order-dependent, software cannot rewind a PCR to an earlier value or forge a particular final value, so the registers accumulate a tamper-evident record of the boot state that persists until the platform is reset.

Remote attestation allows external parties to verify the platform's configuration by requesting a TPM-signed quote of PCR values. This mechanism enables scenarios such as:

• Verifying that a device is running approved firmware before granting network access
• Ensuring endpoint compliance with security policies
• Detecting unauthorized modifications to the boot chain
• Enabling conditional access to encrypted data based on platform state, as used by disk-encryption schemes that seal keys to specific PCR values

TPM 2.0 Specifications

TPM 2.0 represents a significant evolution from the original TPM 1.2 specification, offering improved cryptographic flexibility and enhanced features:

• Algorithm agility - Support for multiple hash algorithms (including SHA-256 and SHA-384) and asymmetric algorithms (RSA and ECC), rather than the fixed RSA-and-SHA-1 design of TPM 1.2
• Enhanced authorization - Policy-based access control that can combine PCR state, passwords, signatures, and other conditions
• Hierarchy separation - Distinct platform, storage, and endorsement hierarchies for different use cases, each with its own seed and authorization
• Improved key management - More flexible key attributes, usage policies, and the ability to create primary keys on demand from persistent seeds

Types of Secure Elements

Secure elements come in various form factors to suit different integration requirements:

• Embedded Secure Elements (eSE) - Soldered directly to device circuit boards, providing permanent security functionality in phones, wearables, and payment terminals
• Integrated Secure Elements (iSE) - Built into system-on-chip designs, sharing the die with application processors while maintaining logical isolation
• Universal Integrated Circuit Cards (UICC) - Removable or embedded (eUICC) cards that combine secure element functionality with cellular subscriber identity
• Secure microSD cards - Removable storage cards incorporating secure element capabilities

Common Criteria Certification

Secure elements typically undergo Common Criteria (CC) certification, an international standard (ISO/IEC 15408) for evaluating IT security products. Evaluation Assurance Levels range from EAL1 (lowest) to EAL7 (highest), with most secure elements targeting EAL4+ to EAL6+ against a smart card protection profile, depending on the intended application. The "+" denotes additional assurance components, commonly including resistance to high-attack-potential penetration testing.

The certification process evaluates:

• Security functional requirements, including the cryptographic implementation
• Resistance to physical and logical attacks, evaluated by an accredited laboratory
• Secure development lifecycle practices
• Documentation and guidance for secure deployment

Smart Card Standards

Many secure elements conform to smart card standards that define electrical interfaces, communication protocols, and command sets:

• ISO/IEC 7816 - Contact interface specifications and APDU command structure
• ISO/IEC 14443 - Contactless proximity card interface used by NFC applications
• GlobalPlatform - Specifications for managing applications and security domains on smart card platforms
• Java Card - A runtime platform for executing Java applets on smart cards and secure elements

Types of Cryptographic Accelerators

Modern embedded processors often include integrated cryptographic accelerators supporting various algorithms:

• Symmetric cipher engines - Hardware acceleration for AES, ChaCha20, and other block and stream ciphers, exposed either as processor instructions on application-class cores, such as the x86 AES-NI extensions and the Armv8-A cryptographic extensions, or as memory-mapped peripheral engines on microcontrollers
• Hash accelerators - Dedicated units for SHA-2, SHA-3, and keyed message authentication codes such as HMAC
• Public key accelerators - Hardware support for RSA and elliptic-curve operations, with newer designs adding large-integer and lattice arithmetic for post-quantum algorithms
• True random number generators (TRNG) - Hardware entropy sources, typically conditioned by a deterministic random bit generator, for cryptographic random number generation

DMA and Memory Protection

Cryptographic accelerators often include direct memory access (DMA) capabilities for efficient data transfer without processor intervention. However, DMA introduces security considerations that must be addressed:

• Memory isolation - Ensuring cryptographic keys and intermediate values cannot be accessed by other DMA masters on the bus
• Input/output memory management units (IOMMU) - Hardware enforcement of memory access policies for DMA operations
• Secure key storage - Dedicated registers or memory regions, sometimes accessed only by key handle, that keep raw key material out of general-purpose memory

Side-Channel Countermeasures

Well-designed cryptographic accelerators incorporate countermeasures against side-channel attacks that attempt to extract secrets through indirect observation of timing, power, or electromagnetic emissions:

• Constant-time execution - Operations that take the same time regardless of key or data values
• Power analysis resistance - Techniques such as random delays, noise injection, and balanced logic to frustrate simple and differential power analysis
• Electromagnetic shielding - Physical protection against EM emanation analysis
• Masking - Randomization techniques that split intermediate values into shares so that observed quantities are statistically independent of the secret

Key Hierarchies

HSMs typically implement key hierarchies in which a small number of master keys protect larger numbers of operational keys:

• Root keys - Factory-provisioned keys that form the ultimate trust anchor and are never exported
• Key encryption keys (KEKs) - Keys used to protect other keys during storage or transport
• Operational keys - Keys used for day-to-day cryptographic operations
• Session keys - Ephemeral keys used for a single communication session and then discarded

Key Provisioning Methods

Securely provisioning keys into HSMs requires careful procedures to maintain the chain of trust:

• Factory provisioning - Keys injected during manufacturing in a controlled environment
• Key injection facilities - Dedicated secure rooms where key-loading ceremonies are performed under dual control
• Remote key injection - Secure protocols for provisioning keys over network connections after deployment
• Key derivation - Generating operational keys from root secrets using deterministic key-derivation functions

Key Wrapping and Export

When keys must be stored outside the HSM or transferred between devices, key wrapping provides protection:

• AES Key Wrap - The RFC 3394 algorithm for protecting symmetric keys whose length is a multiple of 64 bits, with RFC 5649 adding padding for arbitrary key lengths
• PKCS#11 wrapping - Standard mechanisms for key import and export operations across HSM vendors
• Key attestation - Proving that a key was generated within, and is protected by, a genuine HSM

Interface Options

HSMs connect to host systems through various interfaces depending on the application:

• I2C - A simple two-wire interface suitable for low-speed secure elements
• SPI - A higher-speed serial interface common for discrete TPMs and cryptographic coprocessors
• LPC - The Low Pin Count bus historically used to attach discrete TPMs to x86 chipsets; the TCG PC Client platform profile defines LPC, SPI, and I2C bindings for the same TPM command set
• ISO/IEC 7816 - The contact smart card interface for secure elements and SIM cards
• PCIe - A high-performance interface for enterprise and server HSM cards
• USB - A common interface for portable HSM tokens and developer keys

Driver and API Support

Software integration typically involves standardized APIs that abstract the underlying hardware:

• PKCS#11 - The Cryptographic Token Interface standard widely supported by HSM vendors and now maintained by OASIS
• Microsoft CNG - Cryptography API: Next Generation for Windows platforms, with key-storage providers for hardware backends
• OpenSSL providers - The provider interface (which superseded the legacy ENGINE mechanism) for routing operations to hardware cryptography
• Vendor-specific SDKs - Proprietary libraries providing access to device-specific features

Performance Considerations

While HSMs provide strong security, they may introduce performance overhead that must be considered:

• Latency - Communication overhead and operation completion times, which dominate for many small operations
• Throughput - The maximum number of cryptographic operations per second the device can sustain
• Parallelism - The ability to handle concurrent requests from multiple threads or processes
• Caching strategies - Techniques such as session reuse that reduce repeated HSM round-trips for the same keys

Payment Systems

The payment industry relies heavily on HSMs for protecting financial transactions, with dedicated requirements defined by the PCI standards:

• PIN block encryption - Protecting cardholder PINs during transmission and translation between zones
• Card personalization - Secure injection of keys into payment cards during manufacturing
• Transaction authorization - Validating cryptograms and authorizing payment transactions
• EMV chip cards - Secure elements embedded in credit and debit cards

Automotive Security

Modern vehicles incorporate hardware security, frequently in the form of a Secure Hardware Extension (SHE) or an automotive HSM core inside the microcontroller, for functions such as:

• Secure boot - Ensuring only authorized firmware runs on vehicle electronic control units (ECUs)
• Secure on-board communication - Authenticating CAN and automotive Ethernet messages to prevent spoofing
• Immobilizer systems - Authenticating keys to prevent vehicle theft
• V2X security - Securing vehicle-to-everything communications and managing the associated certificates

The Secure Hardware Extension, defined by the German Hersteller Initiative Software, specifies a deliberately minimal on-chip security block built around AES-128 encryption and CMAC generation, with a small set of non-volatile key slots and a volatile key slot that is cleared at power-down. It corresponds closely to the "light" profile of the EVITA research project, whose "medium" and "full" profiles add a dedicated security processor, asymmetric cryptography, and higher-throughput acceleration for gateways, domain controllers, and V2X units. Automotive microcontrollers commonly implement one of these profiles as an isolated core with its own memory and firmware, and the development process surrounding it is governed by ISO/SAE 21434 for road-vehicle cybersecurity engineering.

IoT Device Security

Internet of Things devices benefit from hardware security for:

• Device identity - Unique, unforgeable device credentials provisioned at manufacture
• Secure firmware updates - Verifying the authenticity of update packages before installation
• Data protection - Encrypting sensitive data at rest and in transit
• Cloud authentication - Establishing mutually authenticated connections to cloud services

Digital Rights Management

Content protection systems use hardware security to enforce licensing:

• Content encryption - Protecting media content with hardware-secured keys
• License enforcement - Hardware-backed verification of usage rights
• Secure video path - Protected playback pipelines that keep decrypted premium content out of accessible memory

Confused Deputy and API Attacks

An HSM protects key material, not the decisions to use it. Software that has legitimate access to the device can still ask it to sign or decrypt attacker-chosen data, so a compromised host becomes a signing oracle even though the key never leaves the module. Mitigations operate at the policy layer rather than the silicon layer: restrictive key usage attributes, per-key authorization policies, rate limiting, and audit logging that makes anomalous use visible.

The management interface deserves equal scrutiny. Cryptographic API attacks against standard token interfaces have repeatedly shown that a permissive combination of key attributes, such as allowing the same key to be used both for wrapping and for decryption, can let an attacker extract secrets through sequences of individually legitimate commands. Constraining attributes at key-creation time is the practical defense.

Scope of Certification

A FIPS or Common Criteria certificate applies to a specific hardware version, firmware version, configuration, and operational guidance. Running the module outside its certified configuration, enabling non-approved algorithms, or updating firmware to an unvalidated revision places the deployment outside the scope of the assurance. Certification also expresses resistance in terms of attacker effort rather than impossibility: an evaluation against high attack potential means that a well-funded laboratory using laser fault injection or focused ion beam probing was not able to succeed within the assumed budget, not that such attacks are infeasible in principle.

Provisioning, Availability, and Recovery

Trust in a factory-provisioned root key is inherited from the manufacturer's key-injection process and from the integrity of the supply chain that delivers the part. Systems that must survive an untrusted contract manufacturer typically layer a second identity, provisioned in a controlled facility or derived from a physical unclonable function, on top of the vendor identity.

Tamper response also creates an availability trade-off. Aggressive zeroization thresholds turn accidental conditions, such as a cold-chain excursion or a battery failure in a device that backs up its tamper sensors, into permanent loss of the device's keys. Deployments therefore need a deliberate recovery plan: escrowed key backups under dual control, re-provisioning procedures, or an architecture in which the loss of one device's keys is contained.

Security Requirements

• Certification level - The required Common Criteria EAL level or FIPS 140-3 validation level (1 through 4)
• Tamper resistance - The level of physical protection needed for the deployment environment
• Algorithm support - The required cryptographic algorithms, including post-quantum and crypto-agility considerations
• Key storage capacity - The number and size of keys that must be stored on the device

Operational Requirements

• Performance needs - The required throughput and latency for cryptographic operations
• Form factor - Physical size and integration constraints
• Power consumption - The energy budget, especially for battery-powered devices
• Operating temperature - The environmental conditions, such as the automotive grade range, that the device must withstand

Cost and Availability

• Unit cost - The per-device cost impact on product pricing
• Development tools - The availability and cost of development kits and software
• Supply chain - Long-term availability and second-source options
• Technical support - The quality of vendor documentation and support

Post-Quantum Cryptography

As quantum computing advances, HSMs are being updated to support post-quantum cryptographic algorithms that resist attacks from large-scale quantum computers. In August 2024, NIST published the first finalized standards: FIPS 203 (ML-KEM, derived from CRYSTALS-Kyber) for key encapsulation, FIPS 204 (ML-DSA, derived from CRYSTALS-Dilithium) for digital signatures, and FIPS 205 (SLH-DSA, derived from SPHINCS+) for hash-based signatures. Because these algorithms use larger keys and different arithmetic than RSA and ECC, crypto-agile HSMs are designed to add or update algorithms in the field and to support hybrid schemes that combine a classical and a post-quantum primitive during the migration period.

NIST has since selected HQC as a backup key-encapsulation mechanism built on error-correcting codes rather than lattices, so that a future break of the lattice assumption would not invalidate the entire portfolio, and a further lattice-based signature standard derived from FALCON (FN-DSA) is in preparation. For embedded HSMs the practical constraints are storage and bandwidth rather than raw computation: ML-DSA signatures and SLH-DSA signatures are far larger than ECDSA signatures, which affects certificate sizes, firmware-image headers, and the non-volatile memory budget of a secure element.

Cloud and Virtual HSMs

Cloud service providers now offer HSM-as-a-service solutions that provide hardware-backed security without requiring customers to manage physical devices. These services typically expose validated HSMs through standard interfaces such as PKCS#11, while confidential-computing technologies, including secure enclaves and trusted execution environments, extend HSM-like isolation to general-purpose cloud workloads.

Increased Integration

The trend toward integrating security functionality directly into system-on-chip designs continues, with more processors including secure subsystems, root-of-trust blocks, and on-die secure elements that provide HSM capabilities. This integration reduces cost, board area, and complexity while maintaining strong security guarantees.