Secure boot and cryptography

Quick Cap

Secure boot ensures that only authenticated firmware runs on a device by building a chain of trust from immutable ROM through each boot stage to the application. Cryptographic primitives -- AES for symmetric encryption, ECC/RSA for signatures, SHA for hashing -- protect data in transit and at rest. On resource-constrained MCUs, hardware crypto accelerators and secure elements offload these operations from the CPU while keeping keys physically isolated.

Interviewers test whether you understand the chain-of-trust model, know when to use hardware vs software crypto, can discuss TLS tradeoffs for embedded, and are aware of common attack vectors like JTAG exploitation and fault injection.

Key Facts:

• Chain of trust: ROM verifies bootloader, bootloader verifies application -- each stage checks the signature of the next
• Hardware crypto: AES-128/256, SHA-256, ECC P-256, TRNG -- 10-100x faster than software, resistant to timing attacks
• TLS for embedded: Mutual authentication, certificate or PSK mode, mbedTLS/wolfSSL, typically 30-50 KB RAM
• Key management: Root key in OTP fuses (write-once), session keys in SRAM, secure elements (ATECC608) for isolated key storage
• Common attacks: Buffer overflow, fault injection (voltage glitching), side-channel (power/timing analysis), JTAG left enabled

Deep Dive

Secure Boot Chain of Trust

The chain of trust starts from an immutable root -- typically ROM code burned into the chip at manufacturing. Each boot stage verifies the cryptographic signature of the next stage before executing it. If any verification fails, boot halts.

Secure Boot Chain
  =================

  +------------------+
  |  ROM Bootloader  |  Immutable (mask ROM or OTP)
  |  Contains:       |  - Root public key hash
  |                  |  - Signature verification code
  +--------+---------+
           | verifies signature of
           v
  +------------------+
  | First-Stage      |  Updatable (flash)
  | Bootloader       |  - Signed with vendor private key
  |                  |  - Contains app public key
  +--------+---------+
           | verifies signature of
           v
  +------------------+
  | Application      |  Updatable (flash)
  | Firmware         |  - Signed with app private key
  |                  |  - Contains runtime crypto keys
  +------------------+

The root public key (or its hash) is stored in OTP fuses -- once written, it cannot be changed. This makes the root of trust tamper-resistant. If an attacker replaces the bootloader in flash, the ROM code will detect the invalid signature and refuse to execute it.

Anti-rollback protection extends the chain: a monotonic counter in OTP fuses records the minimum acceptable firmware version. The bootloader checks this counter before loading the application, preventing downgrade to older versions with known vulnerabilities.

Hardware Crypto Accelerators

Most modern MCUs include hardware peripherals for common crypto operations:

Why hardware crypto matters beyond speed:

1. Constant-time execution: Hardware accelerators process data in fixed time regardless of key value, eliminating timing side-channel attacks that plague software implementations
2. Key isolation: Some accelerators (e.g., STM32 CRYP with key protection) can load keys from a secure register that software cannot read back -- the key is used for operations but never exposed to the CPU bus
3. Power efficiency: A hardware AES operation uses a fraction of the energy of a software implementation -- critical for battery-powered devices running TLS

When software crypto is acceptable: On MCUs without hardware accelerators, libraries like mbedTLS and wolfSSL provide portable implementations. Software crypto works for infrequent operations (e.g., verifying a firmware signature once at boot) but is impractical for high-throughput tasks (e.g., encrypting a continuous sensor data stream at 100 samples/second).

TLS for Embedded Systems

TLS (Transport Layer Security) provides encrypted, authenticated communication between a device and a server. Embedded TLS has unique constraints:

Certificate vs PSK: Certificate-based TLS uses X.509 certificates and public-key cryptography, providing the strongest authentication but requiring certificate storage (~1-2 KB per cert) and a PKI infrastructure. PSK mode uses a pre-shared symmetric key provisioned during manufacturing -- simpler, lower RAM, but the PSK must be securely stored and cannot be revoked per-device without a management system.

Key Management

Key management is often the weakest link in embedded security. The principle: keys should never exist in plaintext in flash or in code.

Storage options:

• OTP fuses: Write-once memory for the root public key hash. Cannot be read by software on some MCUs (read-protected fuses). Ideal for root of trust anchoring.
• Secure elements (ATECC608, OPTIGA Trust): Dedicated ICs that store private keys in tamper-resistant hardware. The key never leaves the chip -- crypto operations happen inside the secure element. Connected via I2C. Cost: $0.50-$2.00.
• TPM (Trusted Platform Module): More capable than secure elements, supporting key hierarchy, attestation, and sealed storage. Common in embedded Linux systems.
• Key derivation: Derive session keys from a master secret using HKDF (HMAC-based Key Derivation Function). The master secret is stored in OTP or secure element; session keys exist only in SRAM and are lost on reset.

/* Example: using a secure element for ECDSA signature */
/* The private key NEVER leaves the ATECC608 chip      */

#include "atca_basic.h"

bool verify_firmware_signature(const uint8_t *fw_data, size_t fw_len,
                               const uint8_t *signature) {
    uint8_t digest[32];
    /* SHA-256 hash of firmware image */
    atcab_sha(fw_len, fw_data, digest);

    /* Verify signature using public key in slot 0     */
    /* Private key is locked inside the secure element */
    ATCA_STATUS status = atcab_verify_stored(
        digest, signature, 0 /* key slot */);

    return (status == ATCA_SUCCESS);
}

Common Embedded Security Attacks

Debugging Story

During production testing of an IoT gateway, a security audit revealed that JTAG was still enabled on the production PCB. An engineer connected a J-Link, halted the CPU, and read out the entire flash contents -- including the TLS private key stored in plaintext at a fixed address. With this key, they could impersonate any gateway to the cloud backend. The immediate fix was enabling STM32 Read-Out Protection Level 2 (permanent, irreversible JTAG lockout) on all production units. The longer-term fix was moving the private key into an ATECC608 secure element so that even if flash was somehow read, the key would not be exposed. The lesson: assume physical access is possible and design key storage accordingly. Never store private keys in main flash.

What interviewers want to hear: that you understand the chain of trust from ROM to application, know why hardware crypto matters (speed, side-channel resistance, key isolation), can discuss TLS trade-offs for constrained devices (RAM, PSK vs certs, session resumption), and design key management around the principle that keys must never be readable from flash. Mentioning specific secure elements (ATECC608) and real attack vectors (JTAG, glitching) demonstrates practical experience.

Interview Focus

Classic Interview Questions

Q1: "Walk me through a secure boot chain. What happens at each stage?"

Model Answer Starter: "The chain starts with ROM code that is immutable -- burned into the chip at manufacturing. The ROM contains the hash of a root public key and minimal signature verification logic. On power-up, the ROM reads the first-stage bootloader from flash, computes its hash, verifies its ECDSA or RSA signature against the root public key, and only jumps to it if the signature is valid. The first-stage bootloader then does the same for the application firmware using a separate app-level public key. If any stage fails verification, boot halts and the device enters a recovery or error state. The root public key hash in OTP fuses is the trust anchor -- everything chains from it."

Q2: "Why use hardware crypto instead of software implementations?"

Model Answer Starter: "Three reasons beyond raw speed. First, hardware crypto executes in constant time regardless of key value, which eliminates timing side-channel attacks that can leak key bits in software implementations. Second, some hardware accelerators support key protection where the key is loaded into a register that software cannot read back -- the CPU can use the key for operations but never sees it. Third, hardware crypto is far more power-efficient, which matters for battery-powered devices doing frequent TLS handshakes. The trade-off is portability -- hardware crypto is peripheral-specific, so I use it for production and keep a software fallback for testing on development boards."

Q3: "How would you implement TLS on a device with only 64 KB of RAM?"

Model Answer Starter: "I would use mbedTLS or wolfSSL configured for minimal footprint -- disable unused cipher suites, use PSK instead of certificates to avoid X.509 parsing overhead, and enable session resumption to avoid full handshakes on reconnect. With a single cipher suite like TLS_PSK_WITH_AES_128_CCM, mbedTLS can fit in about 20 KB of RAM. I would also use hardware crypto acceleration for AES and SHA to reduce stack depth during handshakes. If mutual authentication is required, I would use a raw public key instead of a full certificate chain to save storage and parsing RAM."

Q4: "Where do you store private keys on an embedded device?"

Model Answer Starter: "Never in main flash -- it can be read via JTAG, UART bootloader exploits, or chip decapping. For the root of trust, I store the public key hash in OTP fuses. For device-specific private keys, I use a secure element like the ATECC608, which stores the key in tamper-resistant hardware and performs crypto operations internally -- the key never leaves the chip. For session keys, I derive them at runtime using HKDF from a master secret stored in the secure element, keeping derived keys in SRAM only. If no secure element is available, I use the MCU's flash read protection and store keys in a protected region, but this is a weaker defense."

Q5: "What is a fault injection attack and how do you defend against it?"

Model Answer Starter: "Fault injection uses a brief voltage glitch, electromagnetic pulse, or laser to cause the CPU to skip an instruction or corrupt a register value. A classic attack targets the signature verification branch -- if the attacker times a glitch to skip the 'if signature invalid, halt' instruction, the bootloader proceeds with unverified code. Defenses include performing critical checks twice with different code paths (so a single glitch cannot bypass both), using hardware-based secure boot in ROM (harder to glitch than flash-based code), adding voltage glitch detectors that trigger a reset, and placing critical comparison results in registers that are checked multiple times before the branch decision."

Trap Alerts

• Don't say: "I store the AES key as a const array in flash" -- this is extractable via JTAG or flash readout
• Don't forget: JTAG must be disabled in production -- it is the most common physical attack vector
• Don't ignore: Software crypto is vulnerable to timing side-channels -- always prefer hardware crypto for key-dependent operations

Follow-up Questions

• "How does STM32 Read-Out Protection differ between Level 1 and Level 2?"
• "What is the difference between a secure element and a TPM?"
• "How would you handle key provisioning during manufacturing at scale?"

Practice

Real-World Tie-In

IoT Sensor Node (Secure Boot + ATECC608) -- Designed the security architecture for a LoRaWAN environmental sensor deployed in agricultural fields. Secure boot used the STM32L4's built-in secure boot with a root key hash in OTP fuses. Device identity and TLS-PSK credentials were stored in an ATECC608 secure element connected via I2C. Each device was provisioned with a unique key pair during manufacturing using Microchip's ATECC608 provisioning flow. Over 18 months of deployment (10,000 devices), zero key compromise incidents occurred despite several devices being physically tampered with (enclosures opened) -- the secure element protected the keys even under physical attack.

Automotive Gateway ECU (Secure Boot + Hardware Crypto) -- Implemented the secure boot chain for an automotive Ethernet gateway processing CAN-to-Ethernet traffic. The Infineon AURIX TC3xx's hardware security module (HSM) stored the root key and performed all signature verifications in an isolated execution environment. JTAG was permanently disabled via device protection fuses. Firmware updates were verified against both the HSM-stored root key and an anti-rollback counter in OTP fuses. A penetration test attempted fault injection via voltage glitching on the power rail -- the AURIX's built-in glitch detector triggered a reset before the attack could bypass signature verification.