<Posting the question to tf-a mailing list from Maniphest and copied all previous conversation>
Hi,
On our boards I have an external security chip which communicates with AP (application processor) over a encrypted communication channel. I have a communication driver/PTA running in a Secure Playload (OPTEE) running in S-EL1. My firmware update workflow (FIP.BIN) is as below.
In our design, we have QSPI from where AP boots up (regular TF-A workflow) this QSPI is also accessible from external Security chip (which is responsible for AP/SOC's firmware update) On software side, I have a Non-Secure application which receives the prebuilt binary (FIP.BIN) it chopps the binary in fixed sized buffers and send to OPTEE-PTA which internally sends the binary to Security chip (which then validates and writes to QSPI).
Now in this firmware update flow, I want to do following things.
1. I want to validate/authenticate the FIP image before sending to security chip. If it authentication is successful only then send the image to security chip.
This is what I am planning:-
1. Receive the whole FIP.BIN from NS-APP and store it in RAM (in OPTEE's RAM) 2. I am planning to implement a SIP service in TF-A which will receive the address and size of FIP.BIN in RAM. 3. Calls in to auth_mod driver for authentication of the image.
I don't want to update the images immediately I just needs to authenticate the images within FIP.BIN
To design this feature, I started looking in to BL1 & BL2 code but not sure how much piece if code I can reuse or use. Also I looked in to fwu test apps if I can mimic something but looks the fwu implementation is absolutely different.
My question is how do I just use the authentication functionality available in TF-A for my purpose.
Appreciate your help!
sandrine-bailleux-arm https://developer.trustedfirmware.org/p/sandrine-bailleux-arm/ added a subscriber: sandrine-bailleux-arm https://developer.trustedfirmware.org/p/sandrine-bailleux-arm/.Tue, Jun 16, 6:50 AM https://developer.trustedfirmware.org/T763#9015
https://developer.trustedfirmware.org/T763#
Hi,
Apologies for the delay, I had missed this ticket... Generally speaking, it's better to post questions on the TF-A mailing list [1], it's got far better visibility than Maniphest (which few people monitor I believe) and you are more likely to get a quick answer there.
First of all, I've got a few questions that would help me understand your design.
1. You say that OPTEE-PTA would store the FIP image in its RAM. I am assuming this is secure RAM, that only secure software can access, right? If not, this would not seem very secure to me, as the normal world software could easily change the FIP image after it has been authenticated and replace it with some malicious firmware.
1. You'd like to implement a SiP service in TF-A to authenticate the FIP image, given its base address and size. Now I am guessing this would be an address in OPTEE's RAM, right?
1. What cryptographic key would sign the FIP image? Would TF-A have access to this key to authenticate it?
1. What would need authentication? The FIP image as a monolithic blob, or each individual image within this FIP? And in the latter case, would all images be authenticated using the same key or would different images be signed with different keys?
Now, coming back to where to look into TF-A source code. You're looking in the right place, all Trusted Boot code is indeed built into BL1 and BL2 in TF-A. The following two documents detail how the authentication framework and firmware update flow work in TF-A and are worth reading if you haven't done so already:
https://trustedfirmware-a.readthedocs.io/en/latest/design/auth-framework.htm... https://trustedfirmware-a.readthedocs.io/en/latest/components/firmware-updat...
I reckon you'd want to reuse the cryptographic module in your case. It provides a callback to verify the signature of some payload, see [2] and include/drivers/auth/crypto_mod.h. However, I expect it won't be straight forward to reuse this code outside of its context, as it expects DER-encoded data structures following a specific ASN.1 format. Typically when used in the TF-A trusted boot flow, these are coming from X.509 certificates, which already provide the data structures in the right format.
Best regards, Sandrine Bailleux
[1] https://lists.trustedfirmware.org/mailman/listinfo/tf-a [2] https://trustedfirmware-a.readthedocs.io/en/latest/design/auth-framework.htm...
arm-in-cloud https://developer.trustedfirmware.org/p/arm-in-cloud/ added a comment.Edited · Wed, Jun 17, 11:42 AM https://developer.trustedfirmware.org/T763#9018
https://developer.trustedfirmware.org/T763#
Thank you Sandrine for your feedback.
Following are the answers to your questions:
1. Yes, the image will be stored in to OPTEEs secured memory. I am guessing TF-A gets access to this memory. 2. Yes, the OPTEE's secure memory address and Size will be passed to the SiP service running in TF-A. 3. These are RSA keys, in my case only TF-A has access to these keys. On a regular boot these are the same keys used to authenticate the images (BL31, BL32 & BL33) in the FIP stored in the QSPI. 4. Yes all images will be authenticated using same key.
Thanks for the documentation links, from the firmware-update doc. I am mainly trying to use IMAGE_AUTH part. In my case COPY is already done just needs AUTH part and once AUTH is successful, optee will pass that payload the security chip for update. And after rebooting my device will boot with new firmware. (In my case we always reboot after firmware updates).
Do you want me to post this query again on the TF-A mailing list?
Thank you!
sandrine-bailleux-arm https://developer.trustedfirmware.org/p/sandrine-bailleux-arm/ added a comment.Fri, Jun 19, 3:09 AM https://developer.trustedfirmware.org/T763#9032
https://developer.trustedfirmware.org/T763#
Hi,
OK I understand a bit better, thanks for the details.
Do you want me to post this query again on the TF-A mailing list?
If it's not too much hassle for you then yes, I think it'd be preferable to continue the discussion on the TF-A mailing list. I will withhold my comments until then.