On Fri, Jun 26, 2020 at 1:45 AM Sandrine Bailleux <sandrine.bailleux@arm.com> wrote:

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