Unexpected Lessons from Secure Boot and Disk Encryption | GRiSP

Skip to content

Return to top

Why Secure Boot Makes Disk Encryption Provisioning Harder Than It Looks ​<br>Secure boot and disk encryption sound like two independent security features. In a real embedded product, however, their interaction can turn final factory provisioning into a delicate sequence of irreversible operations. Perform the right steps in the wrong order and a device that worked perfectly during production may no longer boot or decrypt its data after restart.<br>The management takeaway ​<br>Secure boot ensures that a device runs only authorised software. Disk encryption ensures that data copied from the device cannot simply be read elsewhere. Application secrets can additionally be protected by a separate secure-element chip or by a trusted execution environment: an isolated security area inside the main processor.<br>Each mechanism is understandable on its own. The difficulty appears when the disk-encryption key is itself protected by hardware whose behaviour depends on whether the device has already been permanently locked into its secure-boot state.<br>This creates a one-way transition:<br>The device begins in an open manufacturing state.<br>Factory software prepares and tests the hardware.<br>Secure boot is permanently enabled.<br>The device reboots into its final security state.<br>Encryption keys are created or imported and bound to that state.<br>Production software replaces the factory software.<br>A failure between these steps can leave a device unable to continue provisioning. A power interruption at the wrong moment can have the same result.<br>This is why “enable secure boot and add disk encryption” is not merely a checklist item. It is a manufacturing workflow, a recovery design and a security architecture that must be developed together.<br>What happened in our i.MX 8M products ​<br>We recently implemented secure boot, encrypted storage and protected application secrets for two customer products: one based on the NXP i.MX 8M Plus and another based on the i.MX 8M Mini.<br>One important lesson concerned the end-of-line firmware.<br>Here, end of line means the final manufacturing station, not the end of the product’s lifetime. The end-of-line firmware performs the last device-specific operations before a unit leaves production. These can include:<br>hardware tests;<br>assignment of device identities;<br>installation of certificates and secrets;<br>activation of secure boot;<br>creation of encrypted storage;<br>installation of the final production firmware.<br>Our initial instinct was to treat this firmware like any other system image and let it use encrypted storage. That creates a circular dependency.<br>The encryption key is protected using device-specific hardware. But the result of that protection is tied to the device’s security state. A key prepared while the device is still open must not be assumed to work after secure boot has permanently changed that state.<br>The provisioning firmware therefore cannot depend on encrypted storage that requires the final key before the device has entered its final state.<br>Why the provisioning root filesystem stays unencrypted ​<br>An embedded Linux system normally has several storage areas rather than one monolithic encrypted disk.<br>The bootloader and some boot files must remain accessible before Linux is running. The operating system may have a read-only root filesystem, while changing application data is kept in a separate encrypted partition.<br>For the manufacturing transition, our provisioning root filesystem remains unencrypted. Before secure boot is enabled, the provisioning system can mount a temporary or empty data area that does not depend on the final encryption key.<br>The sequence then looks roughly like this:<br>Boot the temporary provisioning firmware.<br>Test the device and prepare its manufacturing data.<br>Verify that the signed firmware and recovery path are correct.<br>Permanently enable secure boot.<br>Reboot and confirm that the device starts in its final security state.<br>Obtain or generate the disk-encryption key.<br>Immediately convert that key into a device-bound protected form.<br>Create and test the encrypted data partition.<br>Install the production root filesystem.<br>Remove every development path that accepts an unprotected key.<br>Reboot again and verify the complete production system.<br>The reboot after enabling secure boot is not just ceremonial. It proves that the device can actually operate after the irreversible transition.<br>Only then should key material be bound to the final hardware state.<br>What is a “black key”? ​<br>NXP’s i.MX 8M processors contain a hardware cryptographic subsystem called the Cryptographic Acceleration and Assurance Module , usually abbreviated to CAAM.<br>CAAM can perform encryption without exposing the processor’s deepest device-specific secrets to Linux. One of these secrets is derived from one-time-programmable information inside the chip. It is unique to the device and cannot simply be read by normal software.<br>A normal plaintext...