Qoriq Trust Architecture 21 User Guide -
By following its strict procedures, you can ensure that your QorIQ-based product is resistant to firmware replacement attacks, key extraction, and unauthorized debugging. However, the guide also serves as a warning: power comes with responsibility. A single misprogrammed fuse can permanently lock you out of your own hardware.
Extract the SHA-256 hash of the Super Root Key public key table. This text string of hex values is what you will program into the SoC fuses. Phase 2: Compiling and Signing the Bootloader (U-Boot)
The execution flow of a Trust Architecture 2.1 system transitions systematically from hardware validation to OS execution.
When building U-Boot via Yocto or standalone toolchains, ensure that CONFIG_SECURE_BOOT is enabled in your defconfig. Compile U-Boot to generate the raw binary ( u-boot.bin ). qoriq trust architecture 21 user guide
The IBR reads the CSF header, which contains the public keys, certificates, and cryptographic signatures of the bootloader.
This guide (approximately 257 pages) provides the deep technical details necessary for a full implementation, such as precise register descriptions for each Trust Architecture module, advanced key management and blob protocols, and in-depth secure boot configuration and troubleshooting.
Allows authorized engineers to debug the system using signed debug certificates, maintaining security while allowing development. By following its strict procedures, you can ensure
The ISBC validates the ESBC (typically the first stage bootloader, like U-Boot) using public keys stored in the SoC's fuse banks.
Every SoC includes built-in capabilities for secure boot, anti-tamper mechanisms, and secret key protection.
Use the U-Boot prog_capam or fsl_sfp command interface to write the SRK hash into the SFP registers. Extract the SHA-256 hash of the Super Root
Once these fuses are blown, the device will only boot correctly signed code. It cannot be undone. QTA 2.1 vs. Previous Architectures
: Trust 2.1+ supports an "Alternate Image" feature. If a primary image is corrupt (due to a failed update or flash wear-out), the system can check a second location for a valid, signed image to ensure the device remains bootable. Anti-Rollback
| Feature | Description | Key Benefit | | :--- | :--- | :--- | | | Validates the digital signature of boot code before execution. If the signature is invalid, the boot process is halted. | Guarantees that only trusted, authenticated firmware can run on the device, preventing malware from taking control at startup. | | Secure Debug | Prevents unauthorized access to the chip's debug interfaces. Requires proper authentication to debug the device, especially within the Arm Secure World . | Protects sensitive intellectual property and secrets from being extracted via JTAG or other debug ports. | | Anti-Tamper | Physical attack sensors (e.g., for detecting glitching or temperature/power anomalies) that trigger a security violation response. The device can securely zeroize secrets and halt operation. | Defends against sophisticated physical attacks designed to extract keys or alter device behavior. | | Run-Time Integrity Checking (RTIC) | Periodically verifies the integrity of critical code and data in memory during normal operation. | Prevents runtime attacks (e.g., rootkits) from modifying system memory undetected, providing "after-the-fact" detection. | | Secret Key Protection | Hardware-based protection of persistent secrets (like the One-Time Programmable Master Key) and ephemeral secrets (like session keys) used by the Security Engine (SEC). | Ensures cryptographic keys and sensitive data remain confidential and cannot be accessed by unauthorized software. |
