Unlike desktop security that logs errors and continues, TA 2.1’s philosophy is detect and destroy .
The boot_format (PBL) and subsequent images (U-Boot, Linux Kernel) are signed using the private key. Step 3: Fusing the Device
The computer used to sign software must be highly protected.
Apply the required programming voltage to permanently blow the eFuses ( PROG_SFP pin). 5. Runtime Integrity and Tamper Detection qoriq trust architecture 2.1 user guide
Before provisioning a device, the user must generate RSA or ECC cryptographic keys. The private keys will be used to sign software images, while the public key hash will be programmed into the processor’s fuses. 2. Creating Signed Images
Secure Boot is the foundation of Trust Architecture 2.1. It ensures the processor executes only authentic, untampered code. Phase 1: Power-On Reset (POR)
For higher security, the Trust Architecture supports booting with confidentiality. In this scenario, the boot image is not only signed but also encrypted. This protects the OEM's intellectual property (IP) by ensuring that even if the storage medium is compromised, the boot code cannot be read or analyzed. The bootloader uses the esbc_validate command to instruct the Security Engine (SEC) to perform a blob decryption, writing the decrypted output to a secure RAM region before executing it. Unlike desktop security that logs errors and continues, TA 2
TA 2.1 allows developers to disable the JTAG interface entirely, or protect it using a challenge-response authentication protocol. This prevents attackers from reading internal registers or modifying execution flow. Monotonic Counters
Triggered by a signature mismatch or a runtime tamper event. The system immediately isolates key storage and executes a reset or shutdown routine. 6. Development Tools and Implementation
: If you’re new to QorIQ security, read Chapter 3 (Boot Flow) first, then skip to Appendix A (Lifecycle states), and only deep-dive into registers later. Apply the required programming voltage to permanently blow
Creating a trusted device begins at the factory. The manufacturing process must ensure that only you, the OEM, are in control of the device provisioning. The process outlined in TA 2.1 documentation has three main objectives: (1) installing the OEM's root of trust into the silicon, (2) securely provisioning unique device secrets, and (3) ensuring the device is in a known and trusted state before it leaves the factory floor.
To debug a device locked in SEC_PROD mode, you cannot simply attach an open JTAG debugger. Trust Architecture 2.1 requires Secure Debug Authentication. You must challenge the processor via JTAG, sign the returned challenge token with your private OEM development key, and return the signature block to open JTAG debugging access windows. This process ensures developers can troubleshoot field returns without exposing the broader device fleet to physical exploitation.
This kind of warning is critical and repeated appropriately.
To prevent constant exposure of the SRK, OEMs typically use the SRK to sign subordinate operational keys. These subordinate keys are then used for daily software image signing during software release cycles. Step-by-Step Key Provisioning Workflow