This topic has received very interesting content. Most is not related to Trustzone itself though, and rather focus on another part of the security measures available : bare-metal level, boot and static core root of trust measurement.
@jeff if you can split the thread between Trustzone and boot security, feel free!
(also the forum engine is currently lacking multiquote)
@simne7 You asked if signed software and hardware-based root of trust are compatible with the project ethics.
Here is what I found, please correct me when I am wrong!
Trusted boot vs measured boot
NXP iMX boot security takes the trusted boot approach : it chains signed modules which must each be validated for the boot operation to continue, with the root of trust burned into the chip fuses. Another classic method is measured boot, where you first launch the machine and afterwards ensure no tampering or attack occurred.
Documentation (iMX6)
- iMX6 reference manual - IMX6DQRM
- iMX6 Linux High Assurance Boot User Guide - IMX6HABUG
- Secure boot for iMX6 using HABv4 - AN4581
- Code Signing Tool (CST) available for download with NXP registration - HAB4 API and HAB CST User Guide
- iMX6 UL Security Reference Manual - IMX6ULSRM (available under OEM request and NDA)
Boot stages :
1 BootROM (read only)
2 Bootloader (i.e. uboot, an ARM equivalent to coreboot for x86)
3 Linux kernel
Trusted boot process
The fused root of trust is a hash of multiple Super Root Keys (SRK). In iMX6 you can have 4 of those SRKs so you can revoke compromised ones (with yet other fuses), and you will chose one of those SRKs for a boot operation.
The Super Root Key is a public RSA key.
The bootloader image is signed with the private RSA key. Simply put it will be authenticated only if the RSA test passes, and the public RSA key matches the one in the fuse.
There is a Public Key Infrastructure, a tree derived from the root of trust, with subkeys and certificates.
The chain of trust working around the PKI tree is implemented as a sequence of commands written in the Command Sequence File (CSF), stored after the bootloader image.
First the CSF will be authenticated with derived keys and certifs from PKI tree. If it passes, the bootloader image will have to pass authentication too, and then on to the next step, loading bootloader, and possibly continuing the chain of trust, authenticating the Linux kernel, and so on.
The bootloader image can be encrypted in addition of its signature : this uses other independent modules, the Cryptographic Accelerator and Assurance Module (CAAM), and the Secure Non Volatile Storage (SNVS).
I found IMX6HABUG page 2, this HAB for dummies for encrypted uboot image layout, and further vulnerability link to have especially informative details.
CAAM stream cypher, full-disk encryption…
CAAM and SNVS can later on be used for stream cyphers (AES256…), for example Full-Disk Encryption.
Much like Android SHK and Apple secure enclave, CAAM stream cypher uses a hardware-enforced key, rather ill-documented. This key, called Data Encryption Key (DEK), is derived from :
1 a randomly generated key (DEK, KEK?)
2 a device-specific key burned in fuses, some sort of UID (secret key/OCOTP Master Key?)
3 a passphrase (?)
DEK is stored in a blob, the DEK blob, apparently not accessible through software : to me it looks more like the robust Apple Secure enclave scheme, with stream cypher happening in a black box, than the SHK Android scheme where FDE keys can be extracted as explained in Beniamini’s post linked above.
So to try and answer your question @simne7, the chain of trust is neither a complete black box, uboot bootloader is open-source, you can program most of the pre-bootloader sequence (CSF) using the Code Signing Tool which uses standards like openssl… You can even tweak CST, check HAB CST UG Appendix B Replacing the CST Backend Implementation.
It is far from fully documented either, as open-hardware would be, especially CAAM… And I guess most of the documentation is in the one file under NDA…
Boot end-user control
@TungstenFilament “The main opposition from our perspective to commercial phone usage of trusted enclaves is that we are not the ones who control that root key and as such are not the actual device owners.”
Nice point.
First there will be fused data unavailable even for Purism to program, the Master Key device ID is done by NXP. We can only accept they claim to not register it…
But other fuses are programmable, especially SRKs, meaning you could choose your private RSA keys to sign bootloader with. If you are really concerned about security, you should be aware that security on the host platform, where you will run CST, is of utmost importance as you store private keys and act as certificate authority for the PKI.
So @nicole.faerber, would we get to choose between off-the-shelf bootloader and the option to program fuses ourselves?
Do you think we could access NDA-IMX6ULSRM, or its equivalent if(when) you ship iMX8?
Audit and issues
I have no skill to thoroughly audit the boot process, but its general structure may look OK.
Although, it is quite complex, and security does not goes well with complexity. Researchers have found vulnerabilities : they managed to run arbitrary bootloaders using stack overflow bugs. NXP errata here.
@taylor-williamc Trammell Hudson working on Trusted Platform Module is nice, and it might have to do with possible Purism announcement of ME going from neutered to disabled? Although he seems specialized on x86, he could still audit general iMX structure I guess. Maybe could ARM experts chime in, like Gal Beniamini?
Lastly, I think we should keep in mind that the Librem5 project will first make a big push toward privacy from GAFAM-NATUs. Security is much harder I believe, and if one were to setup a security plan against nation-level intelligence agencies, maybe keep in mind that, with 2M, this is a rather small project Found these kind of measures at Hudson’s site daamn oO