Hi,

On 6/25/20 3:24 AM, Raghu K via TF-A wrote:

One option you can look at is in bl1_fwu.c if you already haven't, in bl1_fwu_image_auth() function, that uses the auth_mod_verify_img, which is provided an image id, address and size. You can repeatedly call this function on the different image ID's that you have in your FIP. You will likely need to calculate the address to pass to this function based on reading the FIP header(maybe you can use the IO framework for this by opening different image ID's). Don't think there is a straight forward way but what you are trying to do should be achievable using existing code,  rearranged to fit your needs.

Yes, Raghu's approach sounds right to me. As he pointed out, this is not something that's supported out of the box because the firmware update feature is normally invoked through an SMC into BL1 as part of the firmware update flow early during the boot. Things are different in your case as you're looking to provide this feature much later as a runtime service so this will surely require some amount of tweaking but sounds feasible to me.

Best regards, Sandrine

Thanks Raghu

On 6/24/20 12:42 PM, arm in-cloud via TF-A wrote:

...

Hi Sandrine,

Waiting for your suggestions on this query.

Thanks

On Mon, Jun 22, 2020 at 3:40 PM arm in-cloud via TF-A <tf-a@lists.trustedfirmware.org mailto:tf-a@lists.trustedfirmware.org> wrote:

<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.

 2. 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?

 3. What cryptographic key would sign the FIP image? Would TF-A
    have access to this key to authenticate it?

 4. 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.html
https://trustedfirmware-a.readthedocs.io/en/latest/components/firmware-update.html

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.html#cryptographic-module-cm


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.



-- 
TF-A mailing list
TF-A@lists.trustedfirmware.org <mailto:TF-A@lists.trustedfirmware.org>
https://lists.trustedfirmware.org/mailman/listinfo/tf-a