Hi Stuart,
Thanks for your response. Agree with what you are saying. So there are 2 implementation options. One where BL1 and BLX pass measurements through the DTB as the current implementation proposal specifies. The other is where each BLx hooks to the platform to "extend" the measurement, where the platform may extend it to a secure location or to a TPM directly or wherever else. The implementation currently does not *appear* to provide the platform hook for the option where BL1 (and other BL's???)write directly to a TPM/IMPDEF secure location. Perhaps the implementation here should be changed to add a platform API to extend measurements, and the arm platform implementation should write the measurements into the DTB. It would also help if the implementation used the DTB memory location to behave similar to a PCR or multiple PCR's(virtual PCR's perhaps) and BLX's extend into virtual PCR's, and finally have SEL0/SEL1 or a platform mechanism to transfer the virtual PCR's into physical PCR's.
-Raghu
On 3/25/20 1:01 PM, Stuart Yoder wrote:
Hi Raghu,
- Thanks for clarifying. With this design, the Root-of-Trust for
measurement(RTM) is the entire secure world software stack, including the config files. If the config files are in the RTM, you can use fields in the config file to indicate the crypto algoirthm, without hard-coding them at compile time. Also, note that having a huge RTM like the entire secure software stack is okay for now but definitely increases the attack surface to defeat measured boot. Ideally, you want nothing outside of BL1 to be the RTM. This can be done by providing platform hooks to "extend" the measurement into a platform specific "PCR" equivalent with IMPDEF protections(or a real TPM for that matter).
I think allowing for BL1 to write the measurement of BL2 into an implemention defined secure location sounds reasonable (including a TPM).
But, in the end some entity needs to transfer that measurement from the secure location into the real TPM and you have to trust that entity functions correctly.
I don't see how you can get out of having to trust BL2 for measured boot. You have to trust BL2 to do signature verification of all BL3x images as part of verified boot. You have to trust BL2 to accurately measure the BL3x images. Just like with BL1, ideally, BL2 would place all measurements directly into a TPM. But, the alternative is to pass the measurements in secure memory to some secure application that will do it after SEL1, SEL0 are up and running.
3,4,5,6) Thanks for clarifying. Question: Is it accurate to say that, ultimately, in this design, a platform will require a trusted application that talks to a real TPM or implements a fTPM, to provide the RTS(Root-of-Trust for storage) and RTR (Root-of-Trust for reporting)?
It needs some TPM implementation-- could be a trusted application. But, it is also valid to have a TPM that belongs to the normal world. BL2 takes measurements, places them into the TPM, then hands things off to UEFI. UEFI in turn hands things off to the OS kernel which directly operates the TPM via a kernel driver.
So, it's not necessarily a trusted application.
Thanks, Stuart