- TF-A - lists.trustedfirmware.org

by Iñigo Vicente Waliño

Hi, Is there any way to see the traceability or registers by the command line of the secure boot on my imx8m mini board with u-boot? Thanks Iñigo

6 years

1
0
0 0

Review request

by Pramod Kumar

Hi All, Please help me reviewing below patches- https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3493 https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3580 Regards, Pramod

6 years

1
0
0 0

Tentatively Accepted: TF-A Tech Forum @ Thu Mar 12, 2020 10:30pm - 11:30pm (IST) (Bill Fletcher via TF-A)

by sandeep.tripathy＠broadcom.com

sandeep.tripathy(a)broadcom.com has replied "Maybe" to this invitation. Title: TF-A Tech Forum This meeting originally contained an attachment. Please contact your organizer for the attachment. This event has been changed. TF-A Tech Forum When Thu 12 Mar 2020 17:00 – 18:00 United Kingdom Time Calendar tf-a(a)lists.trustedfirmware.org Who (Guest list has been hidden at organiser's request) more details » Changed: We are starting an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Future invites will be via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ Trusted Firmware is inviting you to a scheduled Zoom meeting. Join Zoom Meeting https://zoom.us/j/9159704974 Meeting ID: 915 970 4974 One tap mobile +16465588656,,9159704974# US (New York) +16699009128,,9159704974# US (San Jose) Dial by your location +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 915 970 4974 Find your local number: https://zoom.us/u/ad27hc6t7h (updated due to content filtering issues) Going (tf-a(a)lists.trustedfirmware.org)? Yes - Maybe - No more options » Invitation from Google Calendar You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more . When: Thu Mar 12, 2020 10:30pm – 11:30pm India Standard Time - Kolkata Calendar: Bill Fletcher via TF-A Who: * Bill Fletcher via TF-A - organizer * sandeep.tripathy(a)broadcom.com - creator Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively you can sign up for a Google account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organizer and be added to the guest list, or invite others regardless of their own invitation status, or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

6 years

1
0
0 0

Updated invitation: TF-A Tech Forum @ Thu 12 Mar 2020 17:00 - 18:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

This event has been changed. Title: TF-A Tech Forum We are starting an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Future invites will be via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h  (updated due to content filtering issues) (changed) When: Thu 12 Mar 2020 17:00 – 18:00 United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organiser's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=MGVhNDdsMGVqNnEzZ3BpY… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

6 years

1
0
0 0

Invitation: TF-A Tech Forum @ Thu 12 Mar 2020 17:00 - 18:00 (GMT) (tf-a@lists.trustedfirmware.org)

by Bill Fletcher

You have been invited to the following event. Title: TF-A Tech Forum We are starting an open technical forum call for anyone to participate and it is not restricted to Trusted Firmware project members. It will operate under the guidance of the TF TSC. Feel free to forward this invite to colleagues. Future invites will be via the TF-A mailing list and also published on the Trusted Firmware website. Details are here: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/Tr… Firmware is inviting you to a scheduled Zoom meeting.Join Zoom Meetinghttps://zoom.us/j/9159704974Meeting ID: 915 970 4974One tap mobile+16465588656,,9159704974# US (New York)+16699009128,,9159704974# US (San Jose)Dial by your location        +1 646 558 8656 US (New York)        +1 669 900 9128 US (San Jose)        877 853 5247 US Toll-free        888 788 0099 US Toll-freeMeeting ID: 915 970 4974Find your local number: https://zoom.us/u/ad27hc6t7h   When: Thu 12 Mar 2020 17:00 – 18:00 United Kingdom Time Calendar: tf-a(a)lists.trustedfirmware.org Who: (Guest list has been hidden at organiser's request) Event details: https://www.google.com/calendar/event?action=VIEW&eid=MGVhNDdsMGVqNnEzZ3BpY… Invitation from Google Calendar: https://www.google.com/calendar/ You are receiving this courtesy email at the account tf-a(a)lists.trustedfirmware.org because you are an attendee of this event. To stop receiving future updates for this event, decline this event. Alternatively, you can sign up for a Google Account at https://www.google.com/calendar/ and control your notification settings for your entire calendar. Forwarding this invitation could allow any recipient to send a response to the organiser and be added to the guest list, invite others regardless of their own invitation status or to modify your RSVP. Learn more at https://support.google.com/calendar/answer/37135#forwarding

6 years

1
0
0 0

Re: [TF-A] FIP header flags available for feature selection

by Soby Mathew

Hi Scott Please add the platform specific flags as a field in fip_dev_state_t. typedef struct { uintptr_t dev_spec; uint32_t plat_toc_flag; } fip_dev_state_t; Then this field can be updated as part of verifying the FIP header. This header needs to be cleared when the device is closed. Introduce a helper in fip driver to query the flags: int fip_dev_get_plat_toc_flag(io_dev_info_t *dev_info, uint32_t *plat_toc_flag); That should satisfy your requirement. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Scott > Branden via TF-A > Sent: 07 February 2020 18:57 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] FIP header flags available for feature selection > > Hello, > > The fip header has reserved fields available for platform specific use. > The fiptool allows these header fields to be filled in using the --plat-toc-flags. > > A call needs to be available in the ATF framework to get these flags without > accessing the FIP file again to get these flags. > We have a solution we've used for ATF for quite some time to access these > flags. > > It's finally being upstreamed here: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2839 > > If there are any other efficient methods to access these flags or a better > proposal please suggest. > > Thanks, > Scott > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years

2
1
0 0

Re: [TF-A] [RFC] Multiple Signing Domains

by Sandrine Bailleux

Hi Raghu, Thanks a lot for the review comments and feedback! On 2/25/20 3:45 AM, Raghu Krishnamurthy via TF-A wrote: > The patch stack looks great! I do have a suggestion for the long term > evolution/future work on root's of trust and cert_create. It would be > great to generalize "dual-root" to "multi-root". It is conceivable that > firmware supporting secure partitions/SPCI etc, could move to having > multiple root's of trust. Here we have the silicon provider, and the > platform owner as two roots, but a more complex system could contain > silicon firmware, platform firmware and multiple secure partitions, each > signed by different entities. To remove the signing dependencies between > each of these entities, we could have a ROTPK for each of these entities > and the same solution used here, can be applied to solve multiple root's > of trust and is summarized very well by your statement -"As long as > there is a defined contract between BL2 and the (P)(*)ROTK-rooted images > as to how/where to securely get this key or hash, there should not be > any need for the two vendors to do any cross-signing." >> To do this, If possible, we should start moving away from tables such as > the ones in cert_create/src/dualroot/cot.c and have platforms provide > the certificate dependencies and keys used to sign them in a config > file. This achieves two things: it makes cert_create independent of the > cert chain a platform wants to use and the number of roots of trust, > and, makes cert_create more usable by reducing the number of command > line arguments to be provided, which is a long list today. You could > potentially use the config file provided to auto generate the tbbr_cot.c > file being linked into the firmware too. > > Let me know what you think. I agree with everything you said above. Indeed, there's no reason to stop at 2 roots of trust and as you pointed out there are real use cases to enable more. The dualroot chain of trust is only the first step in that direction and is a useful way to experiment with extending the TBBR implementation and chain of trust, while addressing a real use case. Also completely agree with the lack of flexibility of the hard-coded chain of trust in cert_create/src/dualroot/cot.c and drivers/auth/dualroot/cot.c for that matter. In fact, we (at Arm) are thinking along the same lines as you and have had similar ideas boiling for some time. We are making gradual changes to introduce more flexibility into TF-A, not just for the chain of trust, but for any platform-specific data. Maybe you've seen the recent FConf framework patches, which is a key piece into enabling platform layers to move platform-specific data into configuration files. There is still work to do but down the line we are already thinking about moving the chain of trust description into such a configuration file. Moving the CoT into a configuration file has many advantages: - It could constitute the single input source for the chain of trust, serving both the cert_create tool and the firmware. Today, the CoT is described and duplicated in both places and there is really no good reason to keep things like that IMO. As you said, we could auto-generate the tbbr_cot.c file and build into the firmware, or even have the firmware dynamically parse the configuration file at runtime and extract its CoT. - It could simplify the description of the CoT. Today, I think that the C data structures in tbbr_cot.c are quite complex and not straight-forward to understand at first. If we described them using some configuration language, I believe we could abstract some of these details away or at least organize them in a more intuitive way. Regards, Sandrine

6 years

2
1
0 0

Re: [TF-A] [RFC] Multiple Signing Domains

by Raghu Krishnamurthy

Hi Sandrine, The patch stack looks great! I do have a suggestion for the long term evolution/future work on root's of trust and cert_create. It would be great to generalize "dual-root" to "multi-root". It is conceivable that firmware supporting secure partitions/SPCI etc, could move to having multiple root's of trust. Here we have the silicon provider, and the platform owner as two roots, but a more complex system could contain silicon firmware, platform firmware and multiple secure partitions, each signed by different entities. To remove the signing dependencies between each of these entities, we could have a ROTPK for each of these entities and the same solution used here, can be applied to solve multiple root's of trust and is summarized very well by your statement -"As long as there is a defined contract between BL2 and the (P)(*)ROTK-rooted images as to how/where to securely get this key or hash, there should not be any need for the two vendors to do any cross-signing." To do this, If possible, we should start moving away from tables such as the ones in cert_create/src/dualroot/cot.c and have platforms provide the certificate dependencies and keys used to sign them in a config file. This achieves two things: it makes cert_create independent of the cert chain a platform wants to use and the number of roots of trust, and, makes cert_create more usable by reducing the number of command line arguments to be provided, which is a long list today. You could potentially use the config file provided to auto generate the tbbr_cot.c file being linked into the firmware too. Let me know what you think. Thanks Raghu On 2/24/20 3:43 AM, Sandrine Bailleux via TF-A wrote: > Hi, > > Following up on my email sent in November 2019: > https://lists.trustedfirmware.org/pipermail/tf-a/2019-November/000124.html > > and the proof-of-concept code and documentation shared at that time: > [1] > https://developer.trustedfirmware.org/w/tf_a/poc-multiple-signing-domains/ > [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2443 > > I've made a number of improvements and cleanups in the code. I am > posting a new version that introduces this new chain of trust (called > "dualroot", as it has 2 roots of trust) as an alternative to the default > TBBR one. Right now, it is only enabled on some Arm platforms but it > should be pretty straight-forward to extend this to other platforms. > > The code is available there: > https://review.trustedfirmware.org/q/topic:%22sb%252Fdualroot%22 > > and is comprised of the following patches: > - Introduce a new "dualroot" chain of trust > - cert_create: Define the dualroot CoT > - Build system: Changes to drive cert_create for dualroot CoT > - plat/arm: Provide some PROTK files for development > - plat/arm: Add support for dualroot CoT > - plat/arm: Pass cookie argument down to arm_get_rotpk_info() > - plat/arm: Retrieve the right ROTPK when using the dualroot CoT > > This patch stack is based on preparatory work (which has already been > merged) to select a different CoT. This patch stack: > - Did some build system refactoring. > - Introduced a new 'COT' build option to select the chosen chain of trust. > - Made no functional change. > See > http://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=dcd03… > > Note that I've not updated the TF-A documentation just yet to reflect > these changes. I will do that once I've had some initial feedback from > the community and feel that we're reaching a consensus (in the interest > of saving time keeping documentation aligned with code going under rework). > > > Changes Compared to the Proof-of-Concept Patch [2] > -------------------------------------------------- > > - Introduced a proper, separate chain of trust rather than hijacking the > TBBR one. It also has its own header file for certificate extensions > OIDs now. > > - NS-ROTPK has been renamed into "Platform ROTPK", or PROTPK for short. > Going forward, this key would sign both non-trusted images (such as > BL33) and secure partitions. The NS- prefix did not fit well this use > case. The "Platform" prefix instead refers to the owner of this key, > i.e. the platform owner, as opposed to the Silicon Provider. > > - Removed Non-Trusted World Bootloader Key Certificate. > This didn't seem needed in this context and simplifies the CoT. > > - Removed the Non-Trusted Key from the Trusted Key Certificate, as it's > not used in this CoT (the PROTPK signs all non-trusted images instead). > > - As a consequence, the corresponding option for feeding the PROTPK to > the cert_create tool has been renamed into --prot-key (was --ns-rot-key). > > - The hash of the PROTPK is now provided in a file rather than being > hard-coded into the code. This is cleaner than polluting the code with a > byte array. > > - Proper integration in the build system. > Using the dualroot chain of trust is achieved through the COT build > option: > > make <usual trusted boot build options> COT=dualroot > > - plat_get_rotpk_info() is unchanged if using the TBBR CoT. > The alternative implementation managing both ROTPK or PROTPK is > selected only if the dualroot CoT has been chosen at build time. > > > Testing and Supported Platforms > ------------------------------- > > Tested on AEMv8-A Base Platform (AArch32 and AArch64 execution states), > rde1edge, rdn1edge, SGI-575 and SGM-775 FVPs (all available on > https://developer.arm.com/tools-and-software/simulation-models/fixed-virtua…). > > Arm Juno is not supported right now because it has its own > implementation of plat_get_arm_rotpk_info() instead of piggy-backing on > the Arm common one. > > Ran the standard set of tests available in the TF-A-Tests repository: > http://git.trustedfirmware.org/TF-A/tf-a-tests.git/about/ > > Also ran the firmware update tests available in the same repository. See > > https://trustedfirmware-a-tests.readthedocs.io/en/latest/user-guide.html#ns… > for more information. > > Finally, performed some end-to-end boot tests to Linux. > > And of course, ran our regression tests to make sure that existing > configurations using the TBBR chain of trust are still working as expected. > > > Caveats > ------- > > The PROTPK hash is embedded into the firmware. It's unlikely that a real > system would like to do that. The use case targeted here is to remove > the need for the primary ROTPK owner to interact with the PROTPK owner. > If BL2 embeds the hash, this defeats the purpose, as now the BL2 owner > (which is expected to be the primary ROTPK owner) has to get the PROTPK > from the other vendor. > > In a real system, we would expect the PROTPK to be provisioned in such a > way that BL2 is able to retrieve it. For example, the PROTPK owner might > burn it (or a hash of it) in some OTP memory. As long as there is a > defined contract between BL2 and the PROTK-rooted images as to how/where > to securely get this key or hash, there should not be any need for the > two vendors to do any cross-signing. > > This caveat was already present in the proof-of-concept [2] and stays > out of the scope for this work, as this ties into broader topics such as > key provisioning. Right now, the onus is on the platform layer to handle > this appropriately. > > > Future work > ----------- > > We have plans to change the "dualroot" CoT further and extend the PROTPK > signing domain with a secure partition. This would demonstrate the use > of several secure partitions, some owned by the silicon provider, others > owned by the platform owner. > > > Regards, > Sandrine >

6 years

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 3 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 354288: Memory - corruptions (OVERRUN) ________________________________________________________________________________________________________ *** CID 354288: Memory - corruptions (OVERRUN) /plat/intel/soc/common/socfpga_psci.c: 138 in socfpga_system_reset() 132 133 extern uint64_t intel_rsu_update_address; 134 135 static void __dead2 socfpga_system_reset(void) 136 { 137 if (intel_rsu_update_address) >>> CID 354288: Memory - corruptions (OVERRUN) >>> Overrunning buffer pointed to by "&intel_rsu_update_address" of 8 bytes by passing it to a function which accesses it at byte offset 15. 138 mailbox_rsu_update(&intel_rsu_update_address); 139 else 140 mailbox_reset_cold(); 141 142 while (1) 143 wfi(); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

6 years

1
0
0 0

Re: [TF-A] [RFC] Multiple Signing Domains

by Sandrine Bailleux

Hi, Following up on my email sent in November 2019: https://lists.trustedfirmware.org/pipermail/tf-a/2019-November/000124.html and the proof-of-concept code and documentation shared at that time: [1] https://developer.trustedfirmware.org/w/tf_a/poc-multiple-signing-domains/ [2] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2443 I've made a number of improvements and cleanups in the code. I am posting a new version that introduces this new chain of trust (called "dualroot", as it has 2 roots of trust) as an alternative to the default TBBR one. Right now, it is only enabled on some Arm platforms but it should be pretty straight-forward to extend this to other platforms. The code is available there: https://review.trustedfirmware.org/q/topic:%22sb%252Fdualroot%22 and is comprised of the following patches: - Introduce a new "dualroot" chain of trust - cert_create: Define the dualroot CoT - Build system: Changes to drive cert_create for dualroot CoT - plat/arm: Provide some PROTK files for development - plat/arm: Add support for dualroot CoT - plat/arm: Pass cookie argument down to arm_get_rotpk_info() - plat/arm: Retrieve the right ROTPK when using the dualroot CoT This patch stack is based on preparatory work (which has already been merged) to select a different CoT. This patch stack: - Did some build system refactoring. - Introduced a new 'COT' build option to select the chosen chain of trust. - Made no functional change. See http://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=dcd03… Note that I've not updated the TF-A documentation just yet to reflect these changes. I will do that once I've had some initial feedback from the community and feel that we're reaching a consensus (in the interest of saving time keeping documentation aligned with code going under rework). Changes Compared to the Proof-of-Concept Patch [2] -------------------------------------------------- - Introduced a proper, separate chain of trust rather than hijacking the TBBR one. It also has its own header file for certificate extensions OIDs now. - NS-ROTPK has been renamed into "Platform ROTPK", or PROTPK for short. Going forward, this key would sign both non-trusted images (such as BL33) and secure partitions. The NS- prefix did not fit well this use case. The "Platform" prefix instead refers to the owner of this key, i.e. the platform owner, as opposed to the Silicon Provider. - Removed Non-Trusted World Bootloader Key Certificate. This didn't seem needed in this context and simplifies the CoT. - Removed the Non-Trusted Key from the Trusted Key Certificate, as it's not used in this CoT (the PROTPK signs all non-trusted images instead). - As a consequence, the corresponding option for feeding the PROTPK to the cert_create tool has been renamed into --prot-key (was --ns-rot-key). - The hash of the PROTPK is now provided in a file rather than being hard-coded into the code. This is cleaner than polluting the code with a byte array. - Proper integration in the build system. Using the dualroot chain of trust is achieved through the COT build option: make <usual trusted boot build options> COT=dualroot - plat_get_rotpk_info() is unchanged if using the TBBR CoT. The alternative implementation managing both ROTPK or PROTPK is selected only if the dualroot CoT has been chosen at build time. Testing and Supported Platforms ------------------------------- Tested on AEMv8-A Base Platform (AArch32 and AArch64 execution states), rde1edge, rdn1edge, SGI-575 and SGM-775 FVPs (all available on https://developer.arm.com/tools-and-software/simulation-models/fixed-virtua…). Arm Juno is not supported right now because it has its own implementation of plat_get_arm_rotpk_info() instead of piggy-backing on the Arm common one. Ran the standard set of tests available in the TF-A-Tests repository: http://git.trustedfirmware.org/TF-A/tf-a-tests.git/about/ Also ran the firmware update tests available in the same repository. See https://trustedfirmware-a-tests.readthedocs.io/en/latest/user-guide.html#ns… for more information. Finally, performed some end-to-end boot tests to Linux. And of course, ran our regression tests to make sure that existing configurations using the TBBR chain of trust are still working as expected. Caveats ------- The PROTPK hash is embedded into the firmware. It's unlikely that a real system would like to do that. The use case targeted here is to remove the need for the primary ROTPK owner to interact with the PROTPK owner. If BL2 embeds the hash, this defeats the purpose, as now the BL2 owner (which is expected to be the primary ROTPK owner) has to get the PROTPK from the other vendor. In a real system, we would expect the PROTPK to be provisioned in such a way that BL2 is able to retrieve it. For example, the PROTPK owner might burn it (or a hash of it) in some OTP memory. As long as there is a defined contract between BL2 and the PROTK-rooted images as to how/where to securely get this key or hash, there should not be any need for the two vendors to do any cross-signing. This caveat was already present in the proof-of-concept [2] and stays out of the scope for this work, as this ties into broader topics such as key provisioning. Right now, the onus is on the platform layer to handle this appropriately. Future work ----------- We have plans to change the "dualroot" CoT further and extend the PROTPK signing domain with a secure partition. This would demonstrate the use of several secure partitions, some owned by the silicon provider, others owned by the platform owner. Regards, Sandrine

6 years

1
0
0 0

Need to synchronize pending EA

by Madhukar Pappireddy

Hi, I have pushed a patch [1] to use a barrier to synchronize pending EA at the entry and exit of exception handlers in BL31(EL3S). There is an interesting discussion as seen in the gerrit review comments of the patch. It looks like this patch is just enabling early panic/crash of the system in the event of SErrors but it does come with performance penalty (due to DSBs) for common exceptions like SMC calls. We believe this needs broader discussion to understand the practical approach to handle SErrors, especially in SoCs without RAS support. Please let us know your thoughts on this patch. [1] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3440 Thanks, Madhukar

6 years

1
0
0 0

Re: [TF-A] Protecting Secure World Translation Tables

by Petre-Ionut Tudor

Hi Raghu, Thank you for your comments. My own comments are inline. ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Raghu Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 18 February 2020 00:16 To: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Protecting Secure World Translation Tables I think it is worth implementing this to raise the bar for successful attacks. To Varun's point, in today's systems without S-EL2(<v8.4), it would be less effective as pointed out, since EL3 memory can be completely accessed by SEL1 and SEL1 code tends to have a larger code base on mobile devices(OPTEE, tlk etc). However, on systems with very thin SEL1 shims(typically servers), this would definitely raise the bar for attacks, since you effectively only have SEL0 and EL3. SEL1 cannot be exploited practically. For new SoCs with SEL2, this mitigation can still be very effective if we can ensure future SEL2 implementations have much smaller code bases and implements this mitigation itself. Effectively, i view SEL2 and EL3 as being equally privileged(it is no different than SEL1 because SEL2 can barf all over EL3 memory and TZ resources if exploited). SEL2 extensions, however, gives EL3 protection from SEL1 and can prevent SEL1 from accessing ALL TZ resources. If you view SEL2 and EL3 as equally privileged and view both together as a single entity, v8.4 systems effectively have EL3, SEL1, SEL0 AND the ability for EL3 to protect itself and other TZ resources from SEL1. In such a system, EL3(and SEL2) having this mitigation will definitely raise the bar for successful attacks. Also, the cost to implement this mitigation is relatively low for a fairly significant raise in the bar for successful attacks. PS - I say significantly raise the bar since an attacker will potentially require gadgets to modify TTBRx, invalidate TLB's, and enough gadgets in the code base to have a successful attack. If code in TF-A EL3 is fairly small, and code that writes to TTBR_EL3 can be in some section of the image that can be reclaimed/erased after initial setup, the attacker would have no gadget to modify TTBR_EL3, so there would be virtually no way to change TTBR_EL3. On a default build of FVP, there is a grand total of 1 instruction that writes to TTBR0_EL3 in enable_mmu_direct_el3. This might be a nice follow up change to this mitigation, if others think it is worth it. The same could be extended to other system registers that don't ever need to be changed(VBAR_EL3? SCTLR_EL3?). Petre: enable_mmu_direct_el3 is also used in the read-only xlat tables API, because the change is made while the MMU is on (so it must be disabled first). I decided to implement it this way in order to allow a platform to make any changes it needs to the translation tables (e.g. for reclaiming initialization code) before calling this API. So, it is kind of "dynamic"...but after it is called nothing can be done to the tables from that EL. This means that we have to reclaim before using this API (otherwise we would have to choose between reclaiming and this feature since RO tables won't allow changing the memory map). I was afraid the change might impose too much rigidity on the initialization of platform BL images, so I went with this approach instead of making the tables read-only at creation by the init_xlat_tables* functions. Thanks Raghu On 2/17/20 12:35 PM, Varun Wadekar via TF-A wrote: > Hello Petre, > > Thanks for the patch. Before I review the actual code, would like to understand how effective this patch will be and if you have seen a real world attack that this patch mitigates. > > AFAIU, the ARM architecture provides the TZ bit as the only protection to create "partitions" on a CPU core. So, potentially S-EL1 can access almost all TZ resources that EL3 can access. Thus, creating a silo inside EL3 exception mode is not an effective mitigation against any other TZ component writing to the physical memory where the page tables are stored. For the scope of this attack vector, are we assuming that the system cannot be compromised by attacking other TZ software components in the system? > > I feel until we have a way to distinguish between CPU realms (EL3 v S-EL2 v S-EL1) at the hardware bus level (ARM v9?), these mitigations are not that effective. > > Thoughts? > > -Varun > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Petre-Ionut Tudor via TF-A > Sent: Monday, February 17, 2020 9:40 AM > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Protecting Secure World Translation Tables > > External email: Use caution opening links or attachments > > > Hello Everyone, > > For quite some time I have been working on a security hardening feature that offers extra protection against tampering with the Secure world translation tables. An example would be using a gadget that can perform writes to arbitrary Secure memory locations to change memory attributes and/or the memory map. > > A real world exploit that uses read/write gadgets to tamper with translation tables can be found here: https://vimeo.com/335948808. If you only want the slide deck, it's available here: https://speakerdeck.com/hhj4ck/el3-tour-get-the-ultimate-privilege-of-andro…. > > A patch implementing this feature has been recently pushed upstream here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3349. It extends v2 of the translation tables library with an API that can be called by a BL image any time after the initialization of the xlat tables to make them read-only. > > It would be great to hear your opinions about this, particularly whether or not it is a desirable feature to have in TF-A and what extra work needs to be done for it to meet the use cases that you consider most relevant. > > Best wishes > Petre > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > ----------------------------------------------------------------------------------- > This email message is for the sole use of the intended recipient(s) and may contain > confidential information. Any unauthorized review, use, disclosure or distribution > is prohibited. If you are not the intended recipient, please contact the sender by > reply email and destroy all copies of the original message. > ----------------------------------------------------------------------------------- > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years

2
5
0 0

Re: [TF-A] Protecting Secure World Translation Tables

by Petre-Ionut Tudor

Hi Varun, Thank you for the suggestions. My comments are inline. Petre ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Varun Wadekar via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 18 February 2020 05:44 To: Raghu Krishnamurthy <raghu.ncstate(a)icloud.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org> Subject: Re: [TF-A] Protecting Secure World Translation Tables Thanks Raghu. I agree that this patch reduces the attack surface and would be a good addition, if we consider use cases where EL3 code runs in a silo. Since S-EL1 can contain any third party code, there is an opportunity to change memory contents without EL3 ever noticing the change. A hash for the RO page tables would improve this change immensely IMO. > Petre: Thank you for the suggestion. Sounds like an interesting improvement to make (maybe in a follow-up to this change?, since my rotation in the TF-A team is nearing its end). This change is not effective for platforms that use dynamic page tables e.g. Tegra platforms, so we won't be enabling it. But if other maintainers think this is a good addition to their platforms, I don’t have any objection. > Petre: Do you think it would be worth making this feature play more nicely with the dynamic translation library? I'm thinking providing a counter-API to make tables writable again. So that, every time a dynamic API is needed, since the translation context will be aware of the tables being RO, it first calls a make_tables_writable API before doing whatever it needs to and after it completes (whether successfully or not) calls make_tables_readonly. Essentially, it would act like a wrapper around the dynamic library functions. What do you think of this? Is the disable MMU + cache flush penalty too severe (incurred twice for each dynamic xlat API call)? -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Raghu Krishnamurthy via TF-A Sent: Monday, February 17, 2020 4:16 PM To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Protecting Secure World Translation Tables External email: Use caution opening links or attachments I think it is worth implementing this to raise the bar for successful attacks. To Varun's point, in today's systems without S-EL2(<v8.4), it would be less effective as pointed out, since EL3 memory can be completely accessed by SEL1 and SEL1 code tends to have a larger code base on mobile devices(OPTEE, tlk etc). However, on systems with very thin SEL1 shims(typically servers), this would definitely raise the bar for attacks, since you effectively only have SEL0 and EL3. SEL1 cannot be exploited practically. For new SoCs with SEL2, this mitigation can still be very effective if we can ensure future SEL2 implementations have much smaller code bases and implements this mitigation itself. Effectively, i view SEL2 and EL3 as being equally privileged(it is no different than SEL1 because SEL2 can barf all over EL3 memory and TZ resources if exploited). SEL2 extensions, however, gives EL3 protection from SEL1 and can prevent SEL1 from accessing ALL TZ resources. If you view SEL2 and EL3 as equally privileged and view both together as a single entity, v8.4 systems effectively have EL3, SEL1, SEL0 AND the ability for EL3 to protect itself and other TZ resources from SEL1. In such a system, EL3(and SEL2) having this mitigation will definitely raise the bar for successful attacks. Also, the cost to implement this mitigation is relatively low for a fairly significant raise in the bar for successful attacks. PS - I say significantly raise the bar since an attacker will potentially require gadgets to modify TTBRx, invalidate TLB's, and enough gadgets in the code base to have a successful attack. If code in TF-A EL3 is fairly small, and code that writes to TTBR_EL3 can be in some section of the image that can be reclaimed/erased after initial setup, the attacker would have no gadget to modify TTBR_EL3, so there would be virtually no way to change TTBR_EL3. On a default build of FVP, there is a grand total of 1 instruction that writes to TTBR0_EL3 in enable_mmu_direct_el3. This might be a nice follow up change to this mitigation, if others think it is worth it. The same could be extended to other system registers that don't ever need to be changed(VBAR_EL3? SCTLR_EL3?). Thanks Raghu On 2/17/20 12:35 PM, Varun Wadekar via TF-A wrote: > Hello Petre, > > Thanks for the patch. Before I review the actual code, would like to understand how effective this patch will be and if you have seen a real world attack that this patch mitigates. > > AFAIU, the ARM architecture provides the TZ bit as the only protection to create "partitions" on a CPU core. So, potentially S-EL1 can access almost all TZ resources that EL3 can access. Thus, creating a silo inside EL3 exception mode is not an effective mitigation against any other TZ component writing to the physical memory where the page tables are stored. For the scope of this attack vector, are we assuming that the system cannot be compromised by attacking other TZ software components in the system? > > I feel until we have a way to distinguish between CPU realms (EL3 v S-EL2 v S-EL1) at the hardware bus level (ARM v9?), these mitigations are not that effective. > > Thoughts? > > -Varun > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > Petre-Ionut Tudor via TF-A > Sent: Monday, February 17, 2020 9:40 AM > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Protecting Secure World Translation Tables > > External email: Use caution opening links or attachments > > > Hello Everyone, > > For quite some time I have been working on a security hardening feature that offers extra protection against tampering with the Secure world translation tables. An example would be using a gadget that can perform writes to arbitrary Secure memory locations to change memory attributes and/or the memory map. > > A real world exploit that uses read/write gadgets to tamper with translation tables can be found here: https://vimeo.com/335948808. If you only want the slide deck, it's available here: https://speakerdeck.com/hhj4ck/el3-tour-get-the-ultimate-privilege-of-andro…. > > A patch implementing this feature has been recently pushed upstream here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3349. It extends v2 of the translation tables library with an API that can be called by a BL image any time after the initialization of the xlat tables to make them read-only. > > It would be great to hear your opinions about this, particularly whether or not it is a desirable feature to have in TF-A and what extra work needs to be done for it to meet the use cases that you consider most relevant. > > Best wishes > Petre > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > ---------------------------------------------------------------------- > ------------- This email message is for the sole use of the intended > recipient(s) and may contain confidential information. Any > unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please contact the sender by > reply email and destroy all copies of the original message. > ---------------------------------------------------------------------- > ------------- > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years

2
2
0 0

Re: [TF-A] Protecting Secure World Translation Tables

by Varun Wadekar

Hello Petre, Thanks for the patch. Before I review the actual code, would like to understand how effective this patch will be and if you have seen a real world attack that this patch mitigates. AFAIU, the ARM architecture provides the TZ bit as the only protection to create "partitions" on a CPU core. So, potentially S-EL1 can access almost all TZ resources that EL3 can access. Thus, creating a silo inside EL3 exception mode is not an effective mitigation against any other TZ component writing to the physical memory where the page tables are stored. For the scope of this attack vector, are we assuming that the system cannot be compromised by attacking other TZ software components in the system? I feel until we have a way to distinguish between CPU realms (EL3 v S-EL2 v S-EL1) at the hardware bus level (ARM v9?), these mitigations are not that effective. Thoughts? -Varun -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Petre-Ionut Tudor via TF-A Sent: Monday, February 17, 2020 9:40 AM To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Protecting Secure World Translation Tables External email: Use caution opening links or attachments Hello Everyone, For quite some time I have been working on a security hardening feature that offers extra protection against tampering with the Secure world translation tables. An example would be using a gadget that can perform writes to arbitrary Secure memory locations to change memory attributes and/or the memory map. A real world exploit that uses read/write gadgets to tamper with translation tables can be found here: https://vimeo.com/335948808. If you only want the slide deck, it's available here: https://speakerdeck.com/hhj4ck/el3-tour-get-the-ultimate-privilege-of-andro…. A patch implementing this feature has been recently pushed upstream here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3349. It extends v2 of the translation tables library with an API that can be called by a BL image any time after the initialization of the xlat tables to make them read-only. It would be great to hear your opinions about this, particularly whether or not it is a desirable feature to have in TF-A and what extra work needs to be done for it to meet the use cases that you consider most relevant. Best wishes Petre IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a ----------------------------------------------------------------------------------- This email message is for the sole use of the intended recipient(s) and may contain confidential information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. -----------------------------------------------------------------------------------

6 years

2
1
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Soby Mathew

On 18/02/2020 05:52, Sumit Garg wrote: > On Tue, 18 Feb 2020 at 00:44, Soby Mathew <Soby.Mathew(a)arm.com> wrote: >> >> Hi Everyone, >> I have confirmation from the TBFU architect that both decrypt-then-verify and verify-then-decrypt is acceptable and neither case affects boot integrity. > > Thanks for this confirmation. > >> So I think the flexibility should be given to the platform to choose this. >> >> @Sumit Garg, could you please rework the patches as I mentioned in my previous feedback and submit again? > > Sure I will try to address implementation specific concerns. Actually > earlier I was waiting for above design specific confirmation. > > -Sumit [Adding back the tf-a list] OK, Thanks Sumit. >> >> Best Regards >> Soby Mathew >> >>> -----Original Message----- >>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Raghupathy >>> Krishnamurthy via TF-A >>> Sent: 28 January 2020 14:58 >>> To: Sumit Garg <sumit.garg(a)linaro.org> >>> Cc: Daniel Thompson <daniel.thompson(a)linaro.org>; Miklos Balint >>> <Miklos.Balint(a)arm.com>; Kiyoshi Owada <owada.kiyoshi(a)socionext.com>; tf- >>> a(a)lists.trustedfirmware.org; Joakim Bech <joakim.bech(a)linaro.org>; nd >>> <nd(a)arm.com>; Sandrine Bailleux <Sandrine.Bailleux(a)arm.com> >>> Subject: Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads >>> >>> Hi Sumit, >>> >>> >>> I completely agree with you! All i'm asking for is that what you are proposing is >>> ratified in the spec clearly, without any ambiguities and that we don't >>> implement what we *think* is correct, but implement the spec. If the spec >>> specifies encryption, we should implement encryption, not authenticated >>> encryption. One is not a direct substitute for the other and requires careful >>> thinking. Similarly, the order of signing, encryption, decryption and >>> authentication must be specified and explained clearly, specifically to avoid >>> these kinds of discussions. >>> >>> >>> Thanks >>> -Raghu >>> >>> On January 27, 2020 at 10:49 PM, Sumit Garg <sumit.garg(a)linaro.org> wrote: >>> >>> >>> On Mon, 27 Jan 2020 at 22:54, Raghupathy Krishnamurthy >>> <raghu.ncstate(a)icloud.com> wrote: >>> >>> >>> >>> Sumit, >>> >>> >>> Great point. This perhaps needs to be added to the list of things that need >>> clarification(Sandrine can you help with this too?) in the PSA-TBFU . I believe >>> the answer to your concern lies in the PSA-TBFU in section 3.5, where it talks >>> about optimizing the trusted boot process. To overcome the problem you're >>> talking about, you would: >>> 1) Verify asymmetric signature. >>> 2) Decrypt firmware using SSK on successful signature verification. >>> 3) Rekey the firmware using BSSK(or as the PSA specifies, a key derived from >>> the HUK using a KDF). >>> You will only verify the asymmetric signature on every firmware update, and >>> use the rekeyed firmware(encrypted and mac;d with device specific key) on >>> normal boot. >>> >>> >>> >>> Following is the quote from PSA-TBFU spec: >>> >>> "An implementation **can** optimize the trusted boot process at the expense >>> of **simplicity**" >>> >>> It doesn't seems to be a recommended practice from spec. And especially for >>> DRM use-cases, this approach is NOT recommended due to following concerns >>> raised by DRM vendors (original concerns were with respect to TAs but will >>> equally apply for firmware as well): >>> - allows the device to self sign code authorized to run on the device. >>> - increase the attack surface by having two different ways to load firmware. >>> - allow a break once break forever situation, if you defeat the RSA 'install' once, >>> no matter how hard it is, now your firmware is nicely transformed in a secure >>> firmware and can be reused. >>> >>> Whereas on the other hand, considering >>> "sign-then-encrypt-then-authenticate", it provides two mutually exclusive >>> crypto layers (signature layer and authenticated encryption >>> layer) which in turns provides implementation flexibility as follows: >>> >>> Firmware update: >>> - Require both layers. >>> >>> Normal boot: >>> - DRM use-case, require both layers. >>> - Boot time optimization required, can use only authenticated encryption. >>> - Platform provides secure on-chip NVM and boot time optimization required, >>> can use only signature verification (or simply hash stored in secure on-chip >>> NVM memory). >>> >>> -Sumit >>> >>> >>> Thanks >>> Raghu >>> >>> >>> On January 26, 2020 at 10:34 PM, Sumit Garg <sumit.garg(a)linaro.org> wrote: >>> >>> >>> On Fri, 24 Jan 2020 at 16:36, Sumit Garg <sumit.garg(a)linaro.org> wrote: >>> >>> >>> >>> >>> On Fri, 24 Jan 2020 at 04:02, Raghupathy Krishnamurthy >>> >>> >>> <raghu.ncstate(a)icloud.com> wrote: >>> >>> >>>> >>> >>> >>>> I also just realized that both the TBBR and ARM PSA only talk about >>> encryption of the image, and not authenticated encryption. The guarantees >>> provided by both are completely different. Your >>> review(https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/) >>> talks about the requirement R060_TBBR_FUNCTION being implemented, which >>> is technically not true(and potentially misleading). We must make a note of this >>> difference and use the appropriate terminology, without mixing the two, in the >>> documentation, commit messages, source code comments and error prints. >>> The tool is also called 'encrypt_fw ' but should maybe be named appropriately >>> to indicate it is doing authenticated encryption. >>> >>> >>> >>> >>> I wouldn't call it misleading. Since firmware encryption feature >>> >>> >>> essentially provides confidentiality protection and authenticated >>> >>> >>> encryption is the type of crypto algorithm which we have used to >>> >>> >>> implement it. >>> >>> >>> >>> >>>> >>> >>> >>>> BTW, ARM PSA(file:///home/raghu/repos/fvp/DEN0072-PSA_TBFU_1-0- >>> REL.pdf) expects that the image manifest(X509 certificate) contain the hash of >>> the ENCRYPTED image(Table 2 and as described in my answer to your question >>> "How would this ensure integrity of ciphertext"). The TBBR spec completely >>> misses this fact, and is a crucial detail if we only implement encryption(as >>> opposed to authenticated encryption).Build_macros.mk, in your change, passes >>> the un-encrypted image to cert-tool. You can get away with it in your >>> implementation, since you are using authenticated encryption, not if you were >>> only implementing firmware encryption. >>> >>> >>> >>> >>> I have already highlighted the issue with signing the ciphertext in my >>> >>> >>> previous reply which deviates from security properties provided by >>> >>> >>> signature verification of plain firmware. So I think we need to >>> >>> >>> revisit ARM PSA TBFU spec. >>> >>> >>> >>> >>> >>> >>> In addition to this, there are implementation specific issues with "signing the >>> ciphertext" too. It simply makes the ciphertext immutable for device and >>> disallows meeting following firmware re-encryption requirement as per TBBR >>> spec: >>> >>> >>> R070_TBBR_PROTECTION. The Trusted boot firmware may do the binding of >>> software image updates at run- time by decrypting the updated SoC certificates >>> and software images using the OTP/Fuse Secret Symmetric Key (SSK), followed >>> by the re-encrypting these SoC certificates and software images using a >>> reproducible secret unique per device symmetric key (BSSK), and then updating >>> the ToC correspondingly. >>> >>> >>> Also, externally signing every firmware image encrypted with BSSK doesn't >>> seem scalable as well. It also hampers the case where encryption key is never >>> exposed out from device eg. encryption key is only accessible to hardware >>> crypto engine etc. >>> >>> >>> -Sumit >>> >>> >>> >>> >>>> >>> >>> >>>> Is it possible for somebody from ARM to have the TBBR spec updated to >>> reflect this? Also perhaps talk to the spec writers about incorporating >>> authenticated encryption into TBBR and PSA? This patch set is somewhat >>> trailblazing in this regard. >>> >>> >>>> >>> >>> >>>> -Raghu >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> On January 23, 2020 at 12:08 PM, Raghupathy Krishnamurthy via TF-A <tf- >>> a(a)lists.trustedfirmware.org> wrote: >>> >>> >>>> >>> >>> >>>> Hi Sumit, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Thanks for your response. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> So firstly I would suggest you to revisit TBBR spec [1], >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] I'm very familiar with the TBBR spec and the requirements. Note >>>> that not all SoC's adhere perfectly to the TBBR spec, since it does >>>> not apply to devices in all market segments. However, these devices do >>>> use arm trusted firmware and TBBR CoT in a slightly modified form, >>>> which is still perfectly valid. Also, the TBBR spec can be changed if >>>> required :) >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Why would one use authenticated decryption only to establish TBBR >>> >>> >>>> >>> >>> >>>> Chain of Trust providing device the capability to self sign its firmware? >>> >>> >>>> >>> >>> >>>> [RK] Fair point. However, you may have devices that don't have the >>> processing power or hardware budget or cost factors(paying for HSM's to store >>> private asymmetric keys), to implement asymmetric verification, in which case >>> using authenticated decryption to verify firmware authenticity and integrity is >>> perfectly valid. The attacks on devices that use symmetric keys to verify >>> firmware authenticity and integrity are usually related to exploiting firmware >>> flaws that leak the key or insiders leaking keys, but that is a different problem >>> and requires different solutions. Fundamentally, there is nothing wrong with >>> using symmetric keys for this purpose, so long as the key is well protected. Also >>> note, security requirements and guarantees are different for different systems. >>> The risk is taken by the system designer and should not be imposed by >>> framework code. I don't advocate doing this but it is an option that your >>> implementation does not provide(and perhaps rightly so). >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> How would this ensure integrity of ciphertext? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] You sign the ciphertext. In your design, you pass bl31_enc.bin to >>> cert_tool to sign. You don't decrypt the encrypted cipher text until you have >>> verified the asymmetric signature(which provides integrity). As far as signature >>> verification is concerned, whether you sign the plain text or ciphertext is >>> immaterial, since you are simply verifying that the absolute bits you loaded >>> have not been modified(assuming you use a secure signature scheme). >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Have a look at some defective sign and encrypt techniques here [2] >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] Again, very familiar with [2]. In the S/MIME case, you have multiple >>> parties. With secure boot, you have one party, effectively verifying its own >>> messages across time. There is only one key used to verify signatures. 1.1 and >>> 1.2 does not apply. Also you are encrypting and signing with completely >>> different keys and algorithms. Section 1.2 applies when you use RSA/El-gamal >>> encryption. Here you use symmetric encryption and asymmetric signing. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Why would one not use TBBR CoT here? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] see above. Not all systems are designed equal. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> and why would one like to hardcode in a device during >>> >>> >>>> >>> >>> >>>> provisioning to boot only either an encrypted or a plain firmware >>> >>> >>>> image? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] Why would you not? You typically want to have the same security policy >>> for a class of devices and not be modifiable by an attacker. It isn't common for >>> the same class of devices to use encrypted firmware some times, and un- >>> encrypted firmware other times. If it is common, there is no problem with >>> setting the bit in the FIP header, as long as verified boot is mandatory. The only >>> concern(as my original email said) is the coupling of the FIP layer and the >>> crypto module, in the implementation. I still don't like that fact that the bit >>> saying the file is encrypted is not signed and this may require talking to the >>> TBBR spec writers. Page 22 of the TBBR spec calls out ToC as "Trusted Table of >>> Contents". The FIP header cannot be "trusted", if it is not in ROM or its integrity >>> is verified by some means! R010_TBBR_TOC should perhaps be mandatory >>> then. Also see R080_TBBR_TOC that says the TOC MUST be ROM'ed or tied by >>> hardware in readable registers. This requirement seems contradictory to >>> R010_TBBR_TOC, given that the FIP header(TOC) is copied from mutable NVM >>> by ROM or some boot stage and then ROM'd or loaded into registers. I may be >>> misunderstanding R080_TBBR_TOC, but i'd interpret it as the TOC(FIP header >>> in ATF implementation of TBBR) as being in ROM or integrity verified. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> How would one handle a case where BL31 is in plain format and BL32 is in >>> encrypted format? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK]TBBR CoT is equipped to do this. The table is defined on a per image >>> basis. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> If you are really paranoid about authentication of FIP header... >>> >>> >>>> >>> >>> >>>> [RK] I don't mean to pontificate but there are real world customers buying >>> real hardware, running ATF code, who care about such details and ask about >>> such things routinely. It is not just me being paranoid and is definitely not a >>> minor matter to think of such details. We should discuss more and consider the >>> implications of R080_TBBR_TOC and R010_TBBR_TOC, perhaps on a different >>> thread, without blocking your code review. Can somebody from ARM clarify >>> these requirements with the spec writers? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Thanks >>> >>> >>>> -Raghu >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> On January 23, 2020 at 12:38 AM, Sumit Garg <sumit.garg(a)linaro.org> >>> wrote: >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Hi Raghu, >>> >>> >>>> >>> >>> >>>> I guess you have completely misunderstood this feature. This is an >>> >>> >>>> optional feature which allows to load encrypted FIP payloads using >>> >>> >>>> authenticated decryption which MUST be used along with signature >>> >>> >>>> verification (or TBBR CoT). >>> >>> >>>> >>> >>> >>>> So firstly I would suggest you to revisit TBBR spec [1], especially >>> >>> >>>> requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. >>> >>> >>>> >>> >>> >>>> On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy >>> >>> >>>> <raghu.ncstate(a)icloud.com> wrote: >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Hello, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> The patch stack looks good. The only comment i have is that the FIP layer has >>> now become security aware and supports authenticated decryption(only). This >>> is a deviation from the secure/signed/verified boot design, where we use the >>> TBBR COT to dictate the security operations on the file. This is nice, because >>> file IO is decoupled from the security policy. This may be a big deviation(i >>> apologize if this was considered and shot down for some other reason), but it >>> may be worthwhile to consider making authenticated decryption a part of the >>> authentication framework as opposed to coupling it with the FIP layer. >>> >>> >>>> >>> >>> >>>> It looks like you have mixed both TBBR CoT and this authenticated >>> >>> >>>> decryption feature. They both are completely different and rather >>> >>> >>>> complement each other where TBBR CoT establishes >>> >>> >>>> secure/signed/verified boot and this authenticated decryption feature >>> >>> >>>> provides confidentiality protection for FIP payloads. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> At a high level, this would mean adding a new authentication >>> method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having >>> the platform specify that the image is using authenticated encryption in the >>> TBBR COT. >>> >>> >>>> >>> >>> >>>> Why would one use authenticated decryption only to establish TBBR >>> >>> >>>> Chain of Trust providing device the capability to self sign its >>> >>> >>>> firmwares? We must use signature verification for TBBR CoT (see >>> >>> >>>> section: 2.1 Authentication of Code Images by Certificate in TBBR spec >>> >>> >>>> [1]). >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> The authentication framework is already well designed and well equipped to >>> handle these types of extensions. >>> >>> >>>> 1) This would make the change simpler, since you would not require changes >>> to the FIP tool and the FIP layer. >>> >>> >>>> 2) This would also allow for future cases where a platform may want to only >>> encrypt the file and use public key authentication on the encrypted file(for ex. >>> the soc does not have a crypto accelerator for aes-gcm but only for AES and >>> public key verification, for whatever reason). >>> >>> >>>> >>> >>> >>>> How would this ensure integrity of ciphertext? This approach may be >>> >>> >>>> vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag as >>> >>> >>>> part of AES-GCM provides integrity protection for ciphertext. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> 3) This would let you choose the order in which you want to do the >>> authenticated decryption(or just decryption) and signature verification, if you >>> use both, one or the other. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Have a look at some defective sign and encrypt techniques here [2]. >>> >>> >>>> The order can't be any arbitrary one, we need to be careful about >>> >>> >>>> this. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> One other thing i'm not entirely comfortable with is that the flag indicating if >>> there are encrypted files or not in the FIP, is in the *unsigned* portion of the >>> FIP header. An attacker could simply flip bits that dictate security policy in the >>> header and avoid detection(in this case, the indication that the file needs >>> authenticated decryption). If a platform only uses authenticated encryption, but >>> not verified boot, an attacker could flip the bit in the FIP header and have any >>> image loaded on the platform. >>> >>> >>>> >>> >>> >>>> Why would one not use TBBR CoT here? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> If authenticated encryption cannot be used without verified boot(which >>> requires build time flags), having a flag to indicate that there are encrypted >>> files in the FIP header is moot, since this can come at build time through the >>> TBBR COT. In any case, it seems like the security policy that firmware images >>> need to be decrypted or authenticated with authenticated decryption, seems >>> like a firmware build time or manufacturing time decision(perhaps a bit set in >>> the e-fuses). >>> >>> >>>> >>> >>> >>>> Again you are confusing TBBR CoT with authenticated decryption >>> >>> >>>> feature. And why would one like to hardcode in a device during >>> >>> >>>> provisioning to boot only either an encrypted or a plain firmware >>> >>> >>>> image? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> There seems to be no benefit to having a flag in the FIP header. >>> >>> >>>> >>> >>> >>>> How would one handle a case where BL31 is in plain format and BL32 is >>> >>> >>>> in encrypted format? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Otherwise, I cant think of any attacks due to this and it may be completely >>> okay, but generally, consuming data that dictates security policy/operations >>> before verifying its integrity seems like a recipe for disaster. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> If you are really paranoid about authentication of FIP header then you >>> >>> >>>> should look at implementing optional requirement: R010_TBBR_TOC as per >>> >>> >>>> TBBR spec [1]. >>> >>> >>>> >>> >>> >>>> [1] >>>> https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requi >>>> rements-client-tbbr-client-armv8-a >>> >>> >>>> [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html >>> >>> >>>> >>> >>> >>>> -Sumit >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> -Raghu >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf- >>> a(a)lists.trustedfirmware.org> wrote: >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Hi Sandrine, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux >>> >>> >>>> <Sandrine.Bailleux(a)arm.com> wrote: >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Hello Sumit, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Thank you for reworking the patches and addressing all of my review >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> comments. I am happy with the latest version of these and consider >>>> them >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> ready to go. I plan to leave them in Gerrit for another week to give >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> extra time for other potential reviewers to have a look and comment. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Thanks for your review. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> To everyone on the list: Please raise any concerns you may have about >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> these patches in the coming week. If I don't hear anything by 29th >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> January 2020, I will merge these patches. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> @Sumit: One of the next actions for this patch stack would be to have >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> some level of testing in the CI system to detect any potential >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> regressions. We (at Arm) can quite easily add a few build tests but >>>> then >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> testing the software stack on QEMU is a bit more involved for various >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> ...) so this might have to wait for some time. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Okay, will wait for CI testing. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> -Sumit >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Regards, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Sandrine >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> -- >>> >>> >>>> TF-A mailing list >>> >>> >>>> TF-A(a)lists.trustedfirmware.org >>> >>> >>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >>> >>> >>>> -- >>> >>> >>>> TF-A mailing list >>> >>> >>>> TF-A(a)lists.trustedfirmware.org >>> >>> >>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >>> -- >>> TF-A mailing list >>> TF-A(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Soby Mathew

On 17/02/2020 23:25, Raghu Krishnamurthy wrote: > Thanks Soby. Couple of questions: > 1) Is this going to be clarified in the PSA-TBFU ? Hi Raghu, Yes, this clarification will added to the spec. > 2) Is authenticated encryption/decryption going to be addressed ? One of > the issues i had was the fact that AES-GCM was being used here instead > of just encryption such as aes-cbc/ctr etc. I think it is worth adding a > note in the spec stating that it can be used safely instead of > encryption, and probably preferred. Yes, clarification regarding using AEAD algorithms/AES-GCM will be provided as I understand. Best Regards Soby Mathew > > Thanks > Raghu > > On 2/17/20 11:14 AM, Soby Mathew wrote: >> Hi Everyone, >> I have confirmation from the TBFU architect that both decrypt-then-verify and verify-then-decrypt is acceptable and neither case affects boot integrity. So I think the flexibility should be given to the platform to choose this. >> >> @Sumit Garg, could you please rework the patches as I mentioned in my previous feedback and submit again? >> >> Best Regards >> Soby Mathew >> >>> -----Original Message----- >>> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Raghupathy >>> Krishnamurthy via TF-A >>> Sent: 28 January 2020 14:58 >>> To: Sumit Garg <sumit.garg(a)linaro.org> >>> Cc: Daniel Thompson <daniel.thompson(a)linaro.org>; Miklos Balint >>> <Miklos.Balint(a)arm.com>; Kiyoshi Owada <owada.kiyoshi(a)socionext.com>; tf- >>> a(a)lists.trustedfirmware.org; Joakim Bech <joakim.bech(a)linaro.org>; nd >>> <nd(a)arm.com>; Sandrine Bailleux <Sandrine.Bailleux(a)arm.com> >>> Subject: Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads >>> >>> Hi Sumit, >>> >>> >>> I completely agree with you! All i'm asking for is that what you are proposing is >>> ratified in the spec clearly, without any ambiguities and that we don't >>> implement what we *think* is correct, but implement the spec. If the spec >>> specifies encryption, we should implement encryption, not authenticated >>> encryption. One is not a direct substitute for the other and requires careful >>> thinking. Similarly, the order of signing, encryption, decryption and >>> authentication must be specified and explained clearly, specifically to avoid >>> these kinds of discussions. >>> >>> >>> Thanks >>> -Raghu >>> >>> On January 27, 2020 at 10:49 PM, Sumit Garg <sumit.garg(a)linaro.org> wrote: >>> >>> >>> On Mon, 27 Jan 2020 at 22:54, Raghupathy Krishnamurthy >>> <raghu.ncstate(a)icloud.com> wrote: >>> >>> >>> >>> Sumit, >>> >>> >>> Great point. This perhaps needs to be added to the list of things that need >>> clarification(Sandrine can you help with this too?) in the PSA-TBFU . I believe >>> the answer to your concern lies in the PSA-TBFU in section 3.5, where it talks >>> about optimizing the trusted boot process. To overcome the problem you're >>> talking about, you would: >>> 1) Verify asymmetric signature. >>> 2) Decrypt firmware using SSK on successful signature verification. >>> 3) Rekey the firmware using BSSK(or as the PSA specifies, a key derived from >>> the HUK using a KDF). >>> You will only verify the asymmetric signature on every firmware update, and >>> use the rekeyed firmware(encrypted and mac;d with device specific key) on >>> normal boot. >>> >>> >>> >>> Following is the quote from PSA-TBFU spec: >>> >>> "An implementation **can** optimize the trusted boot process at the expense >>> of **simplicity**" >>> >>> It doesn't seems to be a recommended practice from spec. And especially for >>> DRM use-cases, this approach is NOT recommended due to following concerns >>> raised by DRM vendors (original concerns were with respect to TAs but will >>> equally apply for firmware as well): >>> - allows the device to self sign code authorized to run on the device. >>> - increase the attack surface by having two different ways to load firmware. >>> - allow a break once break forever situation, if you defeat the RSA 'install' once, >>> no matter how hard it is, now your firmware is nicely transformed in a secure >>> firmware and can be reused. >>> >>> Whereas on the other hand, considering >>> "sign-then-encrypt-then-authenticate", it provides two mutually exclusive >>> crypto layers (signature layer and authenticated encryption >>> layer) which in turns provides implementation flexibility as follows: >>> >>> Firmware update: >>> - Require both layers. >>> >>> Normal boot: >>> - DRM use-case, require both layers. >>> - Boot time optimization required, can use only authenticated encryption. >>> - Platform provides secure on-chip NVM and boot time optimization required, >>> can use only signature verification (or simply hash stored in secure on-chip >>> NVM memory). >>> >>> -Sumit >>> >>> >>> Thanks >>> Raghu >>> >>> >>> On January 26, 2020 at 10:34 PM, Sumit Garg <sumit.garg(a)linaro.org> wrote: >>> >>> >>> On Fri, 24 Jan 2020 at 16:36, Sumit Garg <sumit.garg(a)linaro.org> wrote: >>> >>> >>> >>> >>> On Fri, 24 Jan 2020 at 04:02, Raghupathy Krishnamurthy >>> >>> >>> <raghu.ncstate(a)icloud.com> wrote: >>> >>> >>>> >>> >>> >>>> I also just realized that both the TBBR and ARM PSA only talk about >>> encryption of the image, and not authenticated encryption. The guarantees >>> provided by both are completely different. Your >>> review(https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/) >>> talks about the requirement R060_TBBR_FUNCTION being implemented, which >>> is technically not true(and potentially misleading). We must make a note of this >>> difference and use the appropriate terminology, without mixing the two, in the >>> documentation, commit messages, source code comments and error prints. >>> The tool is also called 'encrypt_fw ' but should maybe be named appropriately >>> to indicate it is doing authenticated encryption. >>> >>> >>> >>> >>> I wouldn't call it misleading. Since firmware encryption feature >>> >>> >>> essentially provides confidentiality protection and authenticated >>> >>> >>> encryption is the type of crypto algorithm which we have used to >>> >>> >>> implement it. >>> >>> >>> >>> >>>> >>> >>> >>>> BTW, ARM PSA(file:///home/raghu/repos/fvp/DEN0072-PSA_TBFU_1-0- >>> REL.pdf) expects that the image manifest(X509 certificate) contain the hash of >>> the ENCRYPTED image(Table 2 and as described in my answer to your question >>> "How would this ensure integrity of ciphertext"). The TBBR spec completely >>> misses this fact, and is a crucial detail if we only implement encryption(as >>> opposed to authenticated encryption).Build_macros.mk, in your change, passes >>> the un-encrypted image to cert-tool. You can get away with it in your >>> implementation, since you are using authenticated encryption, not if you were >>> only implementing firmware encryption. >>> >>> >>> >>> >>> I have already highlighted the issue with signing the ciphertext in my >>> >>> >>> previous reply which deviates from security properties provided by >>> >>> >>> signature verification of plain firmware. So I think we need to >>> >>> >>> revisit ARM PSA TBFU spec. >>> >>> >>> >>> >>> >>> >>> In addition to this, there are implementation specific issues with "signing the >>> ciphertext" too. It simply makes the ciphertext immutable for device and >>> disallows meeting following firmware re-encryption requirement as per TBBR >>> spec: >>> >>> >>> R070_TBBR_PROTECTION. The Trusted boot firmware may do the binding of >>> software image updates at run- time by decrypting the updated SoC certificates >>> and software images using the OTP/Fuse Secret Symmetric Key (SSK), followed >>> by the re-encrypting these SoC certificates and software images using a >>> reproducible secret unique per device symmetric key (BSSK), and then updating >>> the ToC correspondingly. >>> >>> >>> Also, externally signing every firmware image encrypted with BSSK doesn't >>> seem scalable as well. It also hampers the case where encryption key is never >>> exposed out from device eg. encryption key is only accessible to hardware >>> crypto engine etc. >>> >>> >>> -Sumit >>> >>> >>> >>> >>>> >>> >>> >>>> Is it possible for somebody from ARM to have the TBBR spec updated to >>> reflect this? Also perhaps talk to the spec writers about incorporating >>> authenticated encryption into TBBR and PSA? This patch set is somewhat >>> trailblazing in this regard. >>> >>> >>>> >>> >>> >>>> -Raghu >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> On January 23, 2020 at 12:08 PM, Raghupathy Krishnamurthy via TF-A <tf- >>> a(a)lists.trustedfirmware.org> wrote: >>> >>> >>>> >>> >>> >>>> Hi Sumit, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Thanks for your response. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> So firstly I would suggest you to revisit TBBR spec [1], >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] I'm very familiar with the TBBR spec and the requirements. Note >>>> that not all SoC's adhere perfectly to the TBBR spec, since it does >>>> not apply to devices in all market segments. However, these devices do >>>> use arm trusted firmware and TBBR CoT in a slightly modified form, >>>> which is still perfectly valid. Also, the TBBR spec can be changed if >>>> required :) >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Why would one use authenticated decryption only to establish TBBR >>> >>> >>>> >>> >>> >>>> Chain of Trust providing device the capability to self sign its firmware? >>> >>> >>>> >>> >>> >>>> [RK] Fair point. However, you may have devices that don't have the >>> processing power or hardware budget or cost factors(paying for HSM's to store >>> private asymmetric keys), to implement asymmetric verification, in which case >>> using authenticated decryption to verify firmware authenticity and integrity is >>> perfectly valid. The attacks on devices that use symmetric keys to verify >>> firmware authenticity and integrity are usually related to exploiting firmware >>> flaws that leak the key or insiders leaking keys, but that is a different problem >>> and requires different solutions. Fundamentally, there is nothing wrong with >>> using symmetric keys for this purpose, so long as the key is well protected. Also >>> note, security requirements and guarantees are different for different systems. >>> The risk is taken by the system designer and should not be imposed by >>> framework code. I don't advocate doing this but it is an option that your >>> implementation does not provide(and perhaps rightly so). >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> How would this ensure integrity of ciphertext? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] You sign the ciphertext. In your design, you pass bl31_enc.bin to >>> cert_tool to sign. You don't decrypt the encrypted cipher text until you have >>> verified the asymmetric signature(which provides integrity). As far as signature >>> verification is concerned, whether you sign the plain text or ciphertext is >>> immaterial, since you are simply verifying that the absolute bits you loaded >>> have not been modified(assuming you use a secure signature scheme). >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Have a look at some defective sign and encrypt techniques here [2] >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] Again, very familiar with [2]. In the S/MIME case, you have multiple >>> parties. With secure boot, you have one party, effectively verifying its own >>> messages across time. There is only one key used to verify signatures. 1.1 and >>> 1.2 does not apply. Also you are encrypting and signing with completely >>> different keys and algorithms. Section 1.2 applies when you use RSA/El-gamal >>> encryption. Here you use symmetric encryption and asymmetric signing. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Why would one not use TBBR CoT here? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] see above. Not all systems are designed equal. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> and why would one like to hardcode in a device during >>> >>> >>>> >>> >>> >>>> provisioning to boot only either an encrypted or a plain firmware >>> >>> >>>> image? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK] Why would you not? You typically want to have the same security policy >>> for a class of devices and not be modifiable by an attacker. It isn't common for >>> the same class of devices to use encrypted firmware some times, and un- >>> encrypted firmware other times. If it is common, there is no problem with >>> setting the bit in the FIP header, as long as verified boot is mandatory. The only >>> concern(as my original email said) is the coupling of the FIP layer and the >>> crypto module, in the implementation. I still don't like that fact that the bit >>> saying the file is encrypted is not signed and this may require talking to the >>> TBBR spec writers. Page 22 of the TBBR spec calls out ToC as "Trusted Table of >>> Contents". The FIP header cannot be "trusted", if it is not in ROM or its integrity >>> is verified by some means! R010_TBBR_TOC should perhaps be mandatory >>> then. Also see R080_TBBR_TOC that says the TOC MUST be ROM'ed or tied by >>> hardware in readable registers. This requirement seems contradictory to >>> R010_TBBR_TOC, given that the FIP header(TOC) is copied from mutable NVM >>> by ROM or some boot stage and then ROM'd or loaded into registers. I may be >>> misunderstanding R080_TBBR_TOC, but i'd interpret it as the TOC(FIP header >>> in ATF implementation of TBBR) as being in ROM or integrity verified. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> How would one handle a case where BL31 is in plain format and BL32 is in >>> encrypted format? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> [RK]TBBR CoT is equipped to do this. The table is defined on a per image >>> basis. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> If you are really paranoid about authentication of FIP header... >>> >>> >>>> >>> >>> >>>> [RK] I don't mean to pontificate but there are real world customers buying >>> real hardware, running ATF code, who care about such details and ask about >>> such things routinely. It is not just me being paranoid and is definitely not a >>> minor matter to think of such details. We should discuss more and consider the >>> implications of R080_TBBR_TOC and R010_TBBR_TOC, perhaps on a different >>> thread, without blocking your code review. Can somebody from ARM clarify >>> these requirements with the spec writers? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Thanks >>> >>> >>>> -Raghu >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> On January 23, 2020 at 12:38 AM, Sumit Garg <sumit.garg(a)linaro.org> >>> wrote: >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Hi Raghu, >>> >>> >>>> >>> >>> >>>> I guess you have completely misunderstood this feature. This is an >>> >>> >>>> optional feature which allows to load encrypted FIP payloads using >>> >>> >>>> authenticated decryption which MUST be used along with signature >>> >>> >>>> verification (or TBBR CoT). >>> >>> >>>> >>> >>> >>>> So firstly I would suggest you to revisit TBBR spec [1], especially >>> >>> >>>> requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. >>> >>> >>>> >>> >>> >>>> On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy >>> >>> >>>> <raghu.ncstate(a)icloud.com> wrote: >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Hello, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> The patch stack looks good. The only comment i have is that the FIP layer has >>> now become security aware and supports authenticated decryption(only). This >>> is a deviation from the secure/signed/verified boot design, where we use the >>> TBBR COT to dictate the security operations on the file. This is nice, because >>> file IO is decoupled from the security policy. This may be a big deviation(i >>> apologize if this was considered and shot down for some other reason), but it >>> may be worthwhile to consider making authenticated decryption a part of the >>> authentication framework as opposed to coupling it with the FIP layer. >>> >>> >>>> >>> >>> >>>> It looks like you have mixed both TBBR CoT and this authenticated >>> >>> >>>> decryption feature. They both are completely different and rather >>> >>> >>>> complement each other where TBBR CoT establishes >>> >>> >>>> secure/signed/verified boot and this authenticated decryption feature >>> >>> >>>> provides confidentiality protection for FIP payloads. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> At a high level, this would mean adding a new authentication >>> method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having >>> the platform specify that the image is using authenticated encryption in the >>> TBBR COT. >>> >>> >>>> >>> >>> >>>> Why would one use authenticated decryption only to establish TBBR >>> >>> >>>> Chain of Trust providing device the capability to self sign its >>> >>> >>>> firmwares? We must use signature verification for TBBR CoT (see >>> >>> >>>> section: 2.1 Authentication of Code Images by Certificate in TBBR spec >>> >>> >>>> [1]). >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> The authentication framework is already well designed and well equipped to >>> handle these types of extensions. >>> >>> >>>> 1) This would make the change simpler, since you would not require changes >>> to the FIP tool and the FIP layer. >>> >>> >>>> 2) This would also allow for future cases where a platform may want to only >>> encrypt the file and use public key authentication on the encrypted file(for ex. >>> the soc does not have a crypto accelerator for aes-gcm but only for AES and >>> public key verification, for whatever reason). >>> >>> >>>> >>> >>> >>>> How would this ensure integrity of ciphertext? This approach may be >>> >>> >>>> vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag as >>> >>> >>>> part of AES-GCM provides integrity protection for ciphertext. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> 3) This would let you choose the order in which you want to do the >>> authenticated decryption(or just decryption) and signature verification, if you >>> use both, one or the other. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Have a look at some defective sign and encrypt techniques here [2]. >>> >>> >>>> The order can't be any arbitrary one, we need to be careful about >>> >>> >>>> this. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> One other thing i'm not entirely comfortable with is that the flag indicating if >>> there are encrypted files or not in the FIP, is in the *unsigned* portion of the >>> FIP header. An attacker could simply flip bits that dictate security policy in the >>> header and avoid detection(in this case, the indication that the file needs >>> authenticated decryption). If a platform only uses authenticated encryption, but >>> not verified boot, an attacker could flip the bit in the FIP header and have any >>> image loaded on the platform. >>> >>> >>>> >>> >>> >>>> Why would one not use TBBR CoT here? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> If authenticated encryption cannot be used without verified boot(which >>> requires build time flags), having a flag to indicate that there are encrypted >>> files in the FIP header is moot, since this can come at build time through the >>> TBBR COT. In any case, it seems like the security policy that firmware images >>> need to be decrypted or authenticated with authenticated decryption, seems >>> like a firmware build time or manufacturing time decision(perhaps a bit set in >>> the e-fuses). >>> >>> >>>> >>> >>> >>>> Again you are confusing TBBR CoT with authenticated decryption >>> >>> >>>> feature. And why would one like to hardcode in a device during >>> >>> >>>> provisioning to boot only either an encrypted or a plain firmware >>> >>> >>>> image? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> There seems to be no benefit to having a flag in the FIP header. >>> >>> >>>> >>> >>> >>>> How would one handle a case where BL31 is in plain format and BL32 is >>> >>> >>>> in encrypted format? >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Otherwise, I cant think of any attacks due to this and it may be completely >>> okay, but generally, consuming data that dictates security policy/operations >>> before verifying its integrity seems like a recipe for disaster. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> If you are really paranoid about authentication of FIP header then you >>> >>> >>>> should look at implementing optional requirement: R010_TBBR_TOC as per >>> >>> >>>> TBBR spec [1]. >>> >>> >>>> >>> >>> >>>> [1] >>>> https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requi >>>> rements-client-tbbr-client-armv8-a >>> >>> >>>> [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html >>> >>> >>>> >>> >>> >>>> -Sumit >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> -Raghu >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf- >>> a(a)lists.trustedfirmware.org> wrote: >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Hi Sandrine, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux >>> >>> >>>> <Sandrine.Bailleux(a)arm.com> wrote: >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Hello Sumit, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Thank you for reworking the patches and addressing all of my review >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> comments. I am happy with the latest version of these and consider >>>> them >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> ready to go. I plan to leave them in Gerrit for another week to give >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> extra time for other potential reviewers to have a look and comment. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Thanks for your review. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> To everyone on the list: Please raise any concerns you may have about >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> these patches in the coming week. If I don't hear anything by 29th >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> January 2020, I will merge these patches. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> @Sumit: One of the next actions for this patch stack would be to have >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> some level of testing in the CI system to detect any potential >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> regressions. We (at Arm) can quite easily add a few build tests but >>>> then >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> testing the software stack on QEMU is a bit more involved for various >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> ...) so this might have to wait for some time. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Okay, will wait for CI testing. >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> -Sumit >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Regards, >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> Sandrine >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> -- >>> >>> >>>> TF-A mailing list >>> >>> >>>> TF-A(a)lists.trustedfirmware.org >>> >>> >>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >>> >>> >>>> -- >>> >>> >>>> TF-A mailing list >>> >>> >>>> TF-A(a)lists.trustedfirmware.org >>> >>> >>>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a >>> -- >>> TF-A mailing list >>> TF-A(a)lists.trustedfirmware.org >>> https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Soby Mathew

Adding back tf-a list, > Hi Everyone, > I have confirmation from the TBFU architect that both decrypt-then-verify and > verify-then-decrypt is acceptable and neither case affects boot integrity. So I > think the flexibility should be given to the platform to choose this. > > @Sumit Garg, could you please rework the patches as I mentioned in my > previous feedback and submit again? > > Best Regards > Soby Mathew > > > -----Original Message----- > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > > Raghupathy Krishnamurthy via TF-A > > Sent: 28 January 2020 14:58 > > To: Sumit Garg <sumit.garg(a)linaro.org> > > Cc: Daniel Thompson <daniel.thompson(a)linaro.org>; Miklos Balint > > <Miklos.Balint(a)arm.com>; Kiyoshi Owada <owada.kiyoshi(a)socionext.com>; > > tf- a(a)lists.trustedfirmware.org; Joakim Bech <joakim.bech(a)linaro.org>; > > nd <nd(a)arm.com>; Sandrine Bailleux <Sandrine.Bailleux(a)arm.com> > > Subject: Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP > > payloads > > > > Hi Sumit, > > > > > > I completely agree with you! All i'm asking for is that what you are > > proposing is ratified in the spec clearly, without any ambiguities and > > that we don't implement what we *think* is correct, but implement the > > spec. If the spec specifies encryption, we should implement > > encryption, not authenticated encryption. One is not a direct > > substitute for the other and requires careful thinking. Similarly, the > > order of signing, encryption, decryption and authentication must be > > specified and explained clearly, specifically to avoid these kinds of discussions. > > > > > > Thanks > > -Raghu > > > > On January 27, 2020 at 10:49 PM, Sumit Garg <sumit.garg(a)linaro.org> wrote: > > > > > > On Mon, 27 Jan 2020 at 22:54, Raghupathy Krishnamurthy > > <raghu.ncstate(a)icloud.com> wrote: > > > > > > > > Sumit, > > > > > > Great point. This perhaps needs to be added to the list of things that > > need clarification(Sandrine can you help with this too?) in the > > PSA-TBFU . I believe the answer to your concern lies in the PSA-TBFU > > in section 3.5, where it talks about optimizing the trusted boot > > process. To overcome the problem you're talking about, you would: > > 1) Verify asymmetric signature. > > 2) Decrypt firmware using SSK on successful signature verification. > > 3) Rekey the firmware using BSSK(or as the PSA specifies, a key > > derived from the HUK using a KDF). > > You will only verify the asymmetric signature on every firmware > > update, and use the rekeyed firmware(encrypted and mac;d with device > > specific key) on normal boot. > > > > > > > > Following is the quote from PSA-TBFU spec: > > > > "An implementation **can** optimize the trusted boot process at the > > expense of **simplicity**" > > > > It doesn't seems to be a recommended practice from spec. And > > especially for DRM use-cases, this approach is NOT recommended due to > > following concerns raised by DRM vendors (original concerns were with > > respect to TAs but will equally apply for firmware as well): > > - allows the device to self sign code authorized to run on the device. > > - increase the attack surface by having two different ways to load firmware. > > - allow a break once break forever situation, if you defeat the RSA > > 'install' once, no matter how hard it is, now your firmware is nicely > > transformed in a secure firmware and can be reused. > > > > Whereas on the other hand, considering > > "sign-then-encrypt-then-authenticate", it provides two mutually > > exclusive crypto layers (signature layer and authenticated encryption > > layer) which in turns provides implementation flexibility as follows: > > > > Firmware update: > > - Require both layers. > > > > Normal boot: > > - DRM use-case, require both layers. > > - Boot time optimization required, can use only authenticated encryption. > > - Platform provides secure on-chip NVM and boot time optimization > > required, can use only signature verification (or simply hash stored > > in secure on-chip NVM memory). > > > > -Sumit > > > > > > Thanks > > Raghu > > > > > > On January 26, 2020 at 10:34 PM, Sumit Garg <sumit.garg(a)linaro.org> wrote: > > > > > > On Fri, 24 Jan 2020 at 16:36, Sumit Garg <sumit.garg(a)linaro.org> wrote: > > > > > > > > > > On Fri, 24 Jan 2020 at 04:02, Raghupathy Krishnamurthy > > > > > > <raghu.ncstate(a)icloud.com> wrote: > > > > > > > > > > > > > > I also just realized that both the TBBR and ARM PSA only talk about > > encryption of the image, and not authenticated encryption. The > > guarantees provided by both are completely different. Your > > review(https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/ > > 2495/) talks about the requirement R060_TBBR_FUNCTION being > > implemented, which is technically not true(and potentially > > misleading). We must make a note of this difference and use the > > appropriate terminology, without mixing the two, in the documentation, > > commit messages, source code comments and error prints. > > The tool is also called 'encrypt_fw ' but should maybe be named > > appropriately to indicate it is doing authenticated encryption. > > > > > > > > > > I wouldn't call it misleading. Since firmware encryption feature > > > > > > essentially provides confidentiality protection and authenticated > > > > > > encryption is the type of crypto algorithm which we have used to > > > > > > implement it. > > > > > > > > > > > > > > > > > > BTW, ARM PSA(file:///home/raghu/repos/fvp/DEN0072-PSA_TBFU_1-0- > > REL.pdf) expects that the image manifest(X509 certificate) contain the > > hash of the ENCRYPTED image(Table 2 and as described in my answer to > > your question "How would this ensure integrity of ciphertext"). The > > TBBR spec completely misses this fact, and is a crucial detail if we > > only implement encryption(as opposed to authenticated > > encryption).Build_macros.mk, in your change, passes the un-encrypted > > image to cert-tool. You can get away with it in your implementation, > > since you are using authenticated encryption, not if you were only > implementing firmware encryption. > > > > > > > > > > I have already highlighted the issue with signing the ciphertext in my > > > > > > previous reply which deviates from security properties provided by > > > > > > signature verification of plain firmware. So I think we need to > > > > > > revisit ARM PSA TBFU spec. > > > > > > > > > > > > > > In addition to this, there are implementation specific issues with > > "signing the ciphertext" too. It simply makes the ciphertext immutable > > for device and disallows meeting following firmware re-encryption > > requirement as per TBBR > > spec: > > > > > > R070_TBBR_PROTECTION. The Trusted boot firmware may do the binding of > > software image updates at run- time by decrypting the updated SoC > > certificates and software images using the OTP/Fuse Secret Symmetric > > Key (SSK), followed by the re-encrypting these SoC certificates and > > software images using a reproducible secret unique per device > > symmetric key (BSSK), and then updating the ToC correspondingly. > > > > > > Also, externally signing every firmware image encrypted with BSSK > > doesn't seem scalable as well. It also hampers the case where > > encryption key is never exposed out from device eg. encryption key is > > only accessible to hardware crypto engine etc. > > > > > > -Sumit > > > > > > > > > > > > > > > > > > Is it possible for somebody from ARM to have the TBBR spec updated > > > to > > reflect this? Also perhaps talk to the spec writers about > > incorporating authenticated encryption into TBBR and PSA? This patch > > set is somewhat trailblazing in this regard. > > > > > > > > > > > > > > -Raghu > > > > > > > > > > > > > > > > > > > > > On January 23, 2020 at 12:08 PM, Raghupathy Krishnamurthy via TF-A > > > <tf- > > a(a)lists.trustedfirmware.org> wrote: > > > > > > > > > > > > > > Hi Sumit, > > > > > > > > > > > > > > > > > > > > > Thanks for your response. > > > > > > > > > > > > > > > > > > > > > So firstly I would suggest you to revisit TBBR spec [1], > > > > > > > > > > > > > > > > > > > > > > > > > > > > [RK] I'm very familiar with the TBBR spec and the requirements. Note > > > that not all SoC's adhere perfectly to the TBBR spec, since it does > > > not apply to devices in all market segments. However, these devices > > > do use arm trusted firmware and TBBR CoT in a slightly modified > > > form, which is still perfectly valid. Also, the TBBR spec can be > > > changed if required :) > > > > > > > > > > > > > > > > > > > > > Why would one use authenticated decryption only to establish TBBR > > > > > > > > > > > > > > Chain of Trust providing device the capability to self sign its firmware? > > > > > > > > > > > > > > [RK] Fair point. However, you may have devices that don't have the > > processing power or hardware budget or cost factors(paying for HSM's > > to store private asymmetric keys), to implement asymmetric > > verification, in which case using authenticated decryption to verify > > firmware authenticity and integrity is perfectly valid. The attacks on > > devices that use symmetric keys to verify firmware authenticity and > > integrity are usually related to exploiting firmware flaws that leak > > the key or insiders leaking keys, but that is a different problem and > > requires different solutions. Fundamentally, there is nothing wrong > > with using symmetric keys for this purpose, so long as the key is well > protected. Also note, security requirements and guarantees are different for > different systems. > > The risk is taken by the system designer and should not be imposed by > > framework code. I don't advocate doing this but it is an option that > > your implementation does not provide(and perhaps rightly so). > > > > > > > > > > > > > > > > > > > > > How would this ensure integrity of ciphertext? > > > > > > > > > > > > > > > > > > > > > > > > > > > > [RK] You sign the ciphertext. In your design, you pass bl31_enc.bin > > > to > > cert_tool to sign. You don't decrypt the encrypted cipher text until > > you have verified the asymmetric signature(which provides integrity). > > As far as signature verification is concerned, whether you sign the > > plain text or ciphertext is immaterial, since you are simply verifying > > that the absolute bits you loaded have not been modified(assuming you use a > secure signature scheme). > > > > > > > > > > > > > > > > > > > > > Have a look at some defective sign and encrypt techniques here [2] > > > > > > > > > > > > > > > > > > > > > > > > > > > > [RK] Again, very familiar with [2]. In the S/MIME case, you have > > > multiple > > parties. With secure boot, you have one party, effectively verifying > > its own messages across time. There is only one key used to verify > > signatures. 1.1 and > > 1.2 does not apply. Also you are encrypting and signing with > > completely different keys and algorithms. Section 1.2 applies when you > > use RSA/El-gamal encryption. Here you use symmetric encryption and > asymmetric signing. > > > > > > > > > > > > > > > > > > > > > Why would one not use TBBR CoT here? > > > > > > > > > > > > > > > > > > > > > > > > > > > > [RK] see above. Not all systems are designed equal. > > > > > > > > > > > > > > > > > > > > > > > > > > > > and why would one like to hardcode in a device during > > > > > > > > > > > > > > provisioning to boot only either an encrypted or a plain firmware > > > > > > > image? > > > > > > > > > > > > > > > > > > > > > [RK] Why would you not? You typically want to have the same security > > > policy > > for a class of devices and not be modifiable by an attacker. It isn't > > common for the same class of devices to use encrypted firmware some > > times, and un- encrypted firmware other times. If it is common, there > > is no problem with setting the bit in the FIP header, as long as > > verified boot is mandatory. The only concern(as my original email > > said) is the coupling of the FIP layer and the crypto module, in the > > implementation. I still don't like that fact that the bit saying the > > file is encrypted is not signed and this may require talking to the > > TBBR spec writers. Page 22 of the TBBR spec calls out ToC as "Trusted > > Table of Contents". The FIP header cannot be "trusted", if it is not > > in ROM or its integrity is verified by some means! R010_TBBR_TOC > > should perhaps be mandatory then. Also see R080_TBBR_TOC that says the > > TOC MUST be ROM'ed or tied by hardware in readable registers. This > > requirement seems contradictory to R010_TBBR_TOC, given that the FIP > > header(TOC) is copied from mutable NVM by ROM or some boot stage and > > then ROM'd or loaded into registers. I may be misunderstanding > R080_TBBR_TOC, but i'd interpret it as the TOC(FIP header in ATF > implementation of TBBR) as being in ROM or integrity verified. > > > > > > > > > > > > > > > > > > > > > How would one handle a case where BL31 is in plain format and BL32 > > > is in > > encrypted format? > > > > > > > > > > > > > > > > > > > > > > > > > > > > [RK]TBBR CoT is equipped to do this. The table is defined on a per > > > image > > basis. > > > > > > > > > > > > > > > > > > > > > If you are really paranoid about authentication of FIP header... > > > > > > > > > > > > > > [RK] I don't mean to pontificate but there are real world customers > > > buying > > real hardware, running ATF code, who care about such details and ask > > about such things routinely. It is not just me being paranoid and is > > definitely not a minor matter to think of such details. We should > > discuss more and consider the implications of R080_TBBR_TOC and > > R010_TBBR_TOC, perhaps on a different thread, without blocking your > > code review. Can somebody from ARM clarify these requirements with the > spec writers? > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > -Raghu > > > > > > > > > > > > > > > > > > > > > On January 23, 2020 at 12:38 AM, Sumit Garg <sumit.garg(a)linaro.org> > > wrote: > > > > > > > > > > > > > > > > > > > > > Hi Raghu, > > > > > > > > > > > > > > I guess you have completely misunderstood this feature. This is an > > > > > > > optional feature which allows to load encrypted FIP payloads using > > > > > > > authenticated decryption which MUST be used along with signature > > > > > > > verification (or TBBR CoT). > > > > > > > > > > > > > > So firstly I would suggest you to revisit TBBR spec [1], especially > > > > > > > requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. > > > > > > > > > > > > > > On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy > > > > > > > <raghu.ncstate(a)icloud.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello, > > > > > > > > > > > > > > > > > > > > > The patch stack looks good. The only comment i have is that the FIP > > > layer has > > now become security aware and supports authenticated decryption(only). > > This is a deviation from the secure/signed/verified boot design, where > > we use the TBBR COT to dictate the security operations on the file. > > This is nice, because file IO is decoupled from the security policy. > > This may be a big deviation(i apologize if this was considered and > > shot down for some other reason), but it may be worthwhile to consider > > making authenticated decryption a part of the authentication framework as > opposed to coupling it with the FIP layer. > > > > > > > > > > > > > > It looks like you have mixed both TBBR CoT and this authenticated > > > > > > > decryption feature. They both are completely different and rather > > > > > > > complement each other where TBBR CoT establishes > > > > > > > secure/signed/verified boot and this authenticated decryption > > > feature > > > > > > > provides confidentiality protection for FIP payloads. > > > > > > > > > > > > > > > > > > > > > At a high level, this would mean adding a new authentication > > method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and > having the > > platform specify that the image is using authenticated encryption in > > the TBBR COT. > > > > > > > > > > > > > > Why would one use authenticated decryption only to establish TBBR > > > > > > > Chain of Trust providing device the capability to self sign its > > > > > > > firmwares? We must use signature verification for TBBR CoT (see > > > > > > > section: 2.1 Authentication of Code Images by Certificate in TBBR > > > spec > > > > > > > [1]). > > > > > > > > > > > > > > > > > > > > > The authentication framework is already well designed and well > > > equipped to > > handle these types of extensions. > > > > > > > 1) This would make the change simpler, since you would not require > > > changes > > to the FIP tool and the FIP layer. > > > > > > > 2) This would also allow for future cases where a platform may want > > > to only > > encrypt the file and use public key authentication on the encrypted file(for ex. > > the soc does not have a crypto accelerator for aes-gcm but only for > > AES and public key verification, for whatever reason). > > > > > > > > > > > > > > How would this ensure integrity of ciphertext? This approach may be > > > > > > > vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag > > > as > > > > > > > part of AES-GCM provides integrity protection for ciphertext. > > > > > > > > > > > > > > > > > > > > > 3) This would let you choose the order in which you want to do the > > authenticated decryption(or just decryption) and signature > > verification, if you use both, one or the other. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Have a look at some defective sign and encrypt techniques here [2]. > > > > > > > The order can't be any arbitrary one, we need to be careful about > > > > > > > this. > > > > > > > > > > > > > > > > > > > > > One other thing i'm not entirely comfortable with is that the flag > > > indicating if > > there are encrypted files or not in the FIP, is in the *unsigned* > > portion of the FIP header. An attacker could simply flip bits that > > dictate security policy in the header and avoid detection(in this > > case, the indication that the file needs authenticated decryption). If > > a platform only uses authenticated encryption, but not verified boot, > > an attacker could flip the bit in the FIP header and have any image loaded on > the platform. > > > > > > > > > > > > > > Why would one not use TBBR CoT here? > > > > > > > > > > > > > > > > > > > > > If authenticated encryption cannot be used without verified > > > boot(which > > requires build time flags), having a flag to indicate that there are > > encrypted files in the FIP header is moot, since this can come at > > build time through the TBBR COT. In any case, it seems like the > > security policy that firmware images need to be decrypted or > > authenticated with authenticated decryption, seems like a firmware > > build time or manufacturing time decision(perhaps a bit set in the e-fuses). > > > > > > > > > > > > > > Again you are confusing TBBR CoT with authenticated decryption > > > > > > > feature. And why would one like to hardcode in a device during > > > > > > > provisioning to boot only either an encrypted or a plain firmware > > > > > > > image? > > > > > > > > > > > > > > > > > > > > > There seems to be no benefit to having a flag in the FIP header. > > > > > > > > > > > > > > How would one handle a case where BL31 is in plain format and BL32 > > > is > > > > > > > in encrypted format? > > > > > > > > > > > > > > > > > > > > > Otherwise, I cant think of any attacks due to this and it may be > > > completely > > okay, but generally, consuming data that dictates security > > policy/operations before verifying its integrity seems like a recipe for disaster. > > > > > > > > > > > > > > > > > > > > > > > > > > > > If you are really paranoid about authentication of FIP header then > > > you > > > > > > > should look at implementing optional requirement: R010_TBBR_TOC as > > > per > > > > > > > TBBR spec [1]. > > > > > > > > > > > > > > [1] > > > https://developer.arm.com/docs/den0006/latest/trusted-board-boot-req > > > ui > > > rements-client-tbbr-client-armv8-a > > > > > > > [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html > > > > > > > > > > > > > > -Sumit > > > > > > > > > > > > > > > > > > > > > -Raghu > > > > > > > > > > > > > > > > > > > > > On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf- > > a(a)lists.trustedfirmware.org> wrote: > > > > > > > > > > > > > > > > > > > > > Hi Sandrine, > > > > > > > > > > > > > > > > > > > > > On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux > > > > > > > <Sandrine.Bailleux(a)arm.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hello Sumit, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thank you for reworking the patches and addressing all of my review > > > > > > > > > > > > > > > > > > > > > comments. I am happy with the latest version of these and consider > > > them > > > > > > > > > > > > > > > > > > > > > ready to go. I plan to leave them in Gerrit for another week to give > > > > > > > > > > > > > > > > > > > > > extra time for other potential reviewers to have a look and comment. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks for your review. > > > > > > > > > > > > > > > > > > > > > To everyone on the list: Please raise any concerns you may have > > > about > > > > > > > > > > > > > > > > > > > > > these patches in the coming week. If I don't hear anything by 29th > > > > > > > > > > > > > > > > > > > > > January 2020, I will merge these patches. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > @Sumit: One of the next actions for this patch stack would be to > > > have > > > > > > > > > > > > > > > > > > > > > some level of testing in the CI system to detect any potential > > > > > > > > > > > > > > > > > > > > > regressions. We (at Arm) can quite easily add a few build tests but > > > then > > > > > > > > > > > > > > > > > > > > > testing the software stack on QEMU is a bit more involved for > > > various > > > > > > > > > > > > > > > > > > > > > reasons (first instance of QEMU testing, dependencies on OPTEE, > > > UEFI, > > > > > > > > > > > > > > > > > > > > > ...) so this might have to wait for some time. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Okay, will wait for CI testing. > > > > > > > > > > > > > > > > > > > > > -Sumit > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > > > > > > > Sandrine > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > TF-A mailing list > > > > > > > TF-A(a)lists.trustedfirmware.org > > > > > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > > > > > > -- > > > > > > > TF-A mailing list > > > > > > > TF-A(a)lists.trustedfirmware.org > > > > > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years

1
0
0 0

Re: [TF-A] Protecting Secure World Translation Tables

by Varun Wadekar

Thanks Raghu. I agree that this patch reduces the attack surface and would be a good addition, if we consider use cases where EL3 code runs in a silo. Since S-EL1 can contain any third party code, there is an opportunity to change memory contents without EL3 ever noticing the change. A hash for the RO page tables would improve this change immensely IMO. This change is not effective for platforms that use dynamic page tables e.g. Tegra platforms, so we won't be enabling it. But if other maintainers think this is a good addition to their platforms, I don’t have any objection. -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Raghu Krishnamurthy via TF-A Sent: Monday, February 17, 2020 4:16 PM To: tf-a(a)lists.trustedfirmware.org Subject: Re: [TF-A] Protecting Secure World Translation Tables External email: Use caution opening links or attachments I think it is worth implementing this to raise the bar for successful attacks. To Varun's point, in today's systems without S-EL2(<v8.4), it would be less effective as pointed out, since EL3 memory can be completely accessed by SEL1 and SEL1 code tends to have a larger code base on mobile devices(OPTEE, tlk etc). However, on systems with very thin SEL1 shims(typically servers), this would definitely raise the bar for attacks, since you effectively only have SEL0 and EL3. SEL1 cannot be exploited practically. For new SoCs with SEL2, this mitigation can still be very effective if we can ensure future SEL2 implementations have much smaller code bases and implements this mitigation itself. Effectively, i view SEL2 and EL3 as being equally privileged(it is no different than SEL1 because SEL2 can barf all over EL3 memory and TZ resources if exploited). SEL2 extensions, however, gives EL3 protection from SEL1 and can prevent SEL1 from accessing ALL TZ resources. If you view SEL2 and EL3 as equally privileged and view both together as a single entity, v8.4 systems effectively have EL3, SEL1, SEL0 AND the ability for EL3 to protect itself and other TZ resources from SEL1. In such a system, EL3(and SEL2) having this mitigation will definitely raise the bar for successful attacks. Also, the cost to implement this mitigation is relatively low for a fairly significant raise in the bar for successful attacks. PS - I say significantly raise the bar since an attacker will potentially require gadgets to modify TTBRx, invalidate TLB's, and enough gadgets in the code base to have a successful attack. If code in TF-A EL3 is fairly small, and code that writes to TTBR_EL3 can be in some section of the image that can be reclaimed/erased after initial setup, the attacker would have no gadget to modify TTBR_EL3, so there would be virtually no way to change TTBR_EL3. On a default build of FVP, there is a grand total of 1 instruction that writes to TTBR0_EL3 in enable_mmu_direct_el3. This might be a nice follow up change to this mitigation, if others think it is worth it. The same could be extended to other system registers that don't ever need to be changed(VBAR_EL3? SCTLR_EL3?). Thanks Raghu On 2/17/20 12:35 PM, Varun Wadekar via TF-A wrote: > Hello Petre, > > Thanks for the patch. Before I review the actual code, would like to understand how effective this patch will be and if you have seen a real world attack that this patch mitigates. > > AFAIU, the ARM architecture provides the TZ bit as the only protection to create "partitions" on a CPU core. So, potentially S-EL1 can access almost all TZ resources that EL3 can access. Thus, creating a silo inside EL3 exception mode is not an effective mitigation against any other TZ component writing to the physical memory where the page tables are stored. For the scope of this attack vector, are we assuming that the system cannot be compromised by attacking other TZ software components in the system? > > I feel until we have a way to distinguish between CPU realms (EL3 v S-EL2 v S-EL1) at the hardware bus level (ARM v9?), these mitigations are not that effective. > > Thoughts? > > -Varun > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > Petre-Ionut Tudor via TF-A > Sent: Monday, February 17, 2020 9:40 AM > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Protecting Secure World Translation Tables > > External email: Use caution opening links or attachments > > > Hello Everyone, > > For quite some time I have been working on a security hardening feature that offers extra protection against tampering with the Secure world translation tables. An example would be using a gadget that can perform writes to arbitrary Secure memory locations to change memory attributes and/or the memory map. > > A real world exploit that uses read/write gadgets to tamper with translation tables can be found here: https://vimeo.com/335948808. If you only want the slide deck, it's available here: https://speakerdeck.com/hhj4ck/el3-tour-get-the-ultimate-privilege-of-andro…. > > A patch implementing this feature has been recently pushed upstream here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3349. It extends v2 of the translation tables library with an API that can be called by a BL image any time after the initialization of the xlat tables to make them read-only. > > It would be great to hear your opinions about this, particularly whether or not it is a desirable feature to have in TF-A and what extra work needs to be done for it to meet the use cases that you consider most relevant. > > Best wishes > Petre > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > ---------------------------------------------------------------------- > ------------- This email message is for the sole use of the intended > recipient(s) and may contain confidential information. Any > unauthorized review, use, disclosure or distribution is prohibited. > If you are not the intended recipient, please contact the sender by > reply email and destroy all copies of the original message. > ---------------------------------------------------------------------- > ------------- > -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years

1
0
0 0

Re: [TF-A] Protecting Secure World Translation Tables

by Raghu Krishnamurthy

I think it is worth implementing this to raise the bar for successful attacks. To Varun's point, in today's systems without S-EL2(<v8.4), it would be less effective as pointed out, since EL3 memory can be completely accessed by SEL1 and SEL1 code tends to have a larger code base on mobile devices(OPTEE, tlk etc). However, on systems with very thin SEL1 shims(typically servers), this would definitely raise the bar for attacks, since you effectively only have SEL0 and EL3. SEL1 cannot be exploited practically. For new SoCs with SEL2, this mitigation can still be very effective if we can ensure future SEL2 implementations have much smaller code bases and implements this mitigation itself. Effectively, i view SEL2 and EL3 as being equally privileged(it is no different than SEL1 because SEL2 can barf all over EL3 memory and TZ resources if exploited). SEL2 extensions, however, gives EL3 protection from SEL1 and can prevent SEL1 from accessing ALL TZ resources. If you view SEL2 and EL3 as equally privileged and view both together as a single entity, v8.4 systems effectively have EL3, SEL1, SEL0 AND the ability for EL3 to protect itself and other TZ resources from SEL1. In such a system, EL3(and SEL2) having this mitigation will definitely raise the bar for successful attacks. Also, the cost to implement this mitigation is relatively low for a fairly significant raise in the bar for successful attacks. PS - I say significantly raise the bar since an attacker will potentially require gadgets to modify TTBRx, invalidate TLB's, and enough gadgets in the code base to have a successful attack. If code in TF-A EL3 is fairly small, and code that writes to TTBR_EL3 can be in some section of the image that can be reclaimed/erased after initial setup, the attacker would have no gadget to modify TTBR_EL3, so there would be virtually no way to change TTBR_EL3. On a default build of FVP, there is a grand total of 1 instruction that writes to TTBR0_EL3 in enable_mmu_direct_el3. This might be a nice follow up change to this mitigation, if others think it is worth it. The same could be extended to other system registers that don't ever need to be changed(VBAR_EL3? SCTLR_EL3?). Thanks Raghu On 2/17/20 12:35 PM, Varun Wadekar via TF-A wrote: > Hello Petre, > > Thanks for the patch. Before I review the actual code, would like to understand how effective this patch will be and if you have seen a real world attack that this patch mitigates. > > AFAIU, the ARM architecture provides the TZ bit as the only protection to create "partitions" on a CPU core. So, potentially S-EL1 can access almost all TZ resources that EL3 can access. Thus, creating a silo inside EL3 exception mode is not an effective mitigation against any other TZ component writing to the physical memory where the page tables are stored. For the scope of this attack vector, are we assuming that the system cannot be compromised by attacking other TZ software components in the system? > > I feel until we have a way to distinguish between CPU realms (EL3 v S-EL2 v S-EL1) at the hardware bus level (ARM v9?), these mitigations are not that effective. > > Thoughts? > > -Varun > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Petre-Ionut Tudor via TF-A > Sent: Monday, February 17, 2020 9:40 AM > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] Protecting Secure World Translation Tables > > External email: Use caution opening links or attachments > > > Hello Everyone, > > For quite some time I have been working on a security hardening feature that offers extra protection against tampering with the Secure world translation tables. An example would be using a gadget that can perform writes to arbitrary Secure memory locations to change memory attributes and/or the memory map. > > A real world exploit that uses read/write gadgets to tamper with translation tables can be found here: https://vimeo.com/335948808. If you only want the slide deck, it's available here: https://speakerdeck.com/hhj4ck/el3-tour-get-the-ultimate-privilege-of-andro…. > > A patch implementing this feature has been recently pushed upstream here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3349. It extends v2 of the translation tables library with an API that can be called by a BL image any time after the initialization of the xlat tables to make them read-only. > > It would be great to hear your opinions about this, particularly whether or not it is a desirable feature to have in TF-A and what extra work needs to be done for it to meet the use cases that you consider most relevant. > > Best wishes > Petre > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > > ----------------------------------------------------------------------------------- > This email message is for the sole use of the intended recipient(s) and may contain > confidential information. Any unauthorized review, use, disclosure or distribution > is prohibited. If you are not the intended recipient, please contact the sender by > reply email and destroy all copies of the original message. > ----------------------------------------------------------------------------------- >

6 years

1
0
0 0

Protecting Secure World Translation Tables

by Petre-Ionut Tudor

Hello Everyone, For quite some time I have been working on a security hardening feature that offers extra protection against tampering with the Secure world translation tables. An example would be using a gadget that can perform writes to arbitrary Secure memory locations to change memory attributes and/or the memory map. A real world exploit that uses read/write gadgets to tamper with translation tables can be found here: https://vimeo.com/335948808. If you only want the slide deck, it's available here: https://speakerdeck.com/hhj4ck/el3-tour-get-the-ultimate-privilege-of-andro…. A patch implementing this feature has been recently pushed upstream here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3349. It extends v2 of the translation tables library with an API that can be called by a BL image any time after the initialization of the xlat tables to make them read-only. It would be great to hear your opinions about this, particularly whether or not it is a desirable feature to have in TF-A and what extra work needs to be done for it to meet the use cases that you consider most relevant. Best wishes Petre IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 354061: Memory - illegal accesses (OVERRUN) /plat/amlogic/axg/axg_pm.c: 124 in axg_pwr_domain_off() ________________________________________________________________________________________________________ *** CID 354061: Memory - illegal accesses (OVERRUN) /plat/amlogic/axg/axg_pm.c: 124 in axg_pwr_domain_off() 118 PLAT_LOCAL_STATE_OFF); 119 120 axg_pm_reset(mpidr, -1); 121 122 gicv2_cpuif_disable(); 123 >>> CID 354061: Memory - illegal accesses (OVERRUN) >>> Overrunning array "target_state->pwr_domain_state" of 2 bytes at byte offset 2 using index "2ULL". 124 if (target_state->pwr_domain_state[MPIDR_AFFLVL2] == 125 PLAT_LOCAL_STATE_OFF) 126 system_state = SCPI_POWER_OFF; 127 128 if (target_state->pwr_domain_state[MPIDR_AFFLVL1] == 129 PLAT_LOCAL_STATE_OFF) ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

6 years

1
0
0 0

TF-A on iMX8M Mini

by Iñigo Vicente Waliño

Hi, I am using an iMX8M mini, I have flashed the image with uuu.auto of L4.14.98_2.0.0_ga_images_MX8MMEVK and I have a Linux image with OP-TEE. Now I want to use TF-A but I don't know the steps to continue. I am reading this document ( https://source.codeaurora.org/external/imx/uboot-imx/tree/doc/imx/habv4/gui… and https : //trustedfirmware-a.readthedocs.io/en/latest/plat/imx8m.html <https://trustedfirmware-a.readthedocs.io/en/latest/plat/imx8m.html>) but I don't know how to get these files: u-boot.bin, u-boot-nodtb.bin, u-boot-spl.bin , DTB U-Boot file (for example, fsl-imx8mq-evk.dtb). Can anyone tell me the steps to follow? Thanks, best regards Iñigo.

6 years

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 354003: Integer handling issues (NO_EFFECT) /drivers/arm/css/scp/css_pm_scmi.c: 228 in css_scp_on() ________________________________________________________________________________________________________ *** CID 354003: Integer handling issues (NO_EFFECT) /drivers/arm/css/scp/css_pm_scmi.c: 228 in css_scp_on() 222 SCMI_SET_PWR_STATE_LVL(scmi_pwr_state, lvl, 223 scmi_power_state_on); 224 225 SCMI_SET_PWR_STATE_MAX_PWR_LVL(scmi_pwr_state, lvl - 1); 226 227 core_pos = plat_core_pos_by_mpidr(mpidr); >>> CID 354003: Integer handling issues (NO_EFFECT) >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "core_pos >= 0U". 228 assert(core_pos >= 0 && (core_pos < PLATFORM_CORE_COUNT)); 229 230 css_scp_core_pos_to_scmi_channel(core_pos, &domain_id, 231 &channel_id); 232 ret = scmi_pwr_state_set(scmi_handles[channel_id], 233 domain_id, scmi_pwr_state); ** CID 354002: Memory - corruptions (OVERRUN) /plat/arm/css/sgi/sgi_bl31_setup.c: 80 in plat_css_get_scmi_info() ________________________________________________________________________________________________________ *** CID 354002: Memory - corruptions (OVERRUN) /plat/arm/css/sgi/sgi_bl31_setup.c: 80 in plat_css_get_scmi_info() 74 scmi_channel_plat_info_t *plat_css_get_scmi_info(int channel_id) 75 { 76 if (sgi_plat_info.platform_id == RD_N1E1_EDGE_SID_VER_PART_NUM || 77 sgi_plat_info.platform_id == RD_DANIEL_SID_VER_PART_NUM) { 78 if (channel_id >= sizeof(rd_n1e1_edge_scmi_plat_info)) 79 panic(); >>> CID 354002: Memory - corruptions (OVERRUN) >>> "&rd_n1e1_edge_scmi_plat_info[channel_id]" evaluates to an address that is at byte offset 1560 of an array of 40 bytes. 80 return &rd_n1e1_edge_scmi_plat_info[channel_id]; 81 } 82 else if (sgi_plat_info.platform_id == SGI575_SSC_VER_PART_NUM) 83 return &sgi575_scmi_plat_info; 84 else 85 panic(); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

6 years

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 353989: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 353989: Integer handling issues (INCOMPATIBLE_CAST) /plat/intel/soc/common/socfpga_psci.c: 138 in socfpga_system_reset() 132 133 extern uint64_t intel_rsu_update_address; 134 135 static void __dead2 socfpga_system_reset(void) 136 { 137 if (intel_rsu_update_address) >>> CID 353989: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "&intel_rsu_update_address" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 138 mailbox_rsu_update((uint32_t *)&intel_rsu_update_address); 139 else 140 mailbox_reset_cold(); 141 142 while (1) 143 wfi(); ** CID 353988: Integer handling issues (INCOMPATIBLE_CAST) ________________________________________________________________________________________________________ *** CID 353988: Integer handling issues (INCOMPATIBLE_CAST) /plat/intel/soc/common/socfpga_sip_svc.c: 526 in sip_smc_handler() 520 521 case INTEL_SIP_SMC_RSU_NOTIFY: 522 status = intel_rsu_notify(x1); 523 SMC_RET1(handle, status); 524 525 case INTEL_SIP_SMC_RSU_RETRY_COUNTER: >>> CID 353988: Integer handling issues (INCOMPATIBLE_CAST) >>> Pointer "rsu_respbuf" points to an object whose effective type is "unsigned long long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness. 526 status = intel_rsu_retry_counter((uint32_t *)rsu_respbuf, 527 ARRAY_SIZE(rsu_respbuf), &val); 528 if (status) { 529 SMC_RET1(handle, status); 530 } else { 531 SMC_RET2(handle, status, val); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/ls/click?upn=nJaKvJSIH-2FPAfmty-2BK5tYpPkl…

6 years

1
0
0 0

FIP header flags available for feature selection

by Scott Branden

Hello, The fip header has reserved fields available for platform specific use. The fiptool allows these header fields to be filled in using the --plat-toc-flags. A call needs to be available in the ATF framework to get these flags without accessing the FIP file again to get these flags. We have a solution we've used for ATF for quite some time to access these flags. It's finally being upstreamed here: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2839 If there are any other efficient methods to access these flags or a better proposal please suggest. Thanks, Scott

6 years

1
0
0 0

Re: [TF-A] [EXT] RE: Issue with addition of NXP Platform support on TFA v2.2

by Alexei Fedorov

Hi Pankaj, Would it be possible to provide more information on your platform (what CPU, its revision, number of clusters/CPUs per cluster, etc.)? Is your platform code publically available? Regards. Alexei ________________________________ From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Pankaj Gupta via TF-A <tf-a(a)lists.trustedfirmware.org> Sent: 07 February 2020 10:57 To: Olivier Deprez <Olivier.Deprez(a)arm.com> Cc: tf-a(a)lists.trustedfirmware.org <tf-a(a)lists.trustedfirmware.org>; nd <nd(a)arm.com> Subject: Re: [TF-A] [EXT] RE: Issue with addition of NXP Platform support on TFA v2.2 Hi, Please find the comments in-line. Regards Pankaj -----Original Message----- From: Olivier Deprez <Olivier.Deprez(a)arm.com> Sent: Wednesday, February 5, 2020 6:54 PM To: Pankaj Gupta <pankaj.gupta(a)nxp.com> Cc: nd <nd(a)arm.com>; tf-a(a)lists.trustedfirmware.org Subject: [EXT] RE: Issue with addition of NXP Platform support on TFA v2.2 >Caution: EXT Email >Hi Pankaj, >Can you pls provide a bit more background: >Which boot stage (BL1/BL2/BL31...) get affected? BL2 >Is there any crash report to console? No. But, using the external debugger, it is found that core gets to non-responding. >Is this an aarch64/or aarch32 platform? aarch64 >There can be different root causes to this e.g. >1. a stale translation in TLB, or a dirty cache line remnant from earlier boot stages. If this is the case, it would need invalidating TLB and/or caches on BL entry. >2. the empty table ptr given by xlat_table_get_empty is pointing nowhere sensible because of this specific platform layout >There are multiple calls to xlat_clean_dcache_range in this file, do you confirm the crash happen within xlat_tables_map_region? Yes. Basis of saying 'yes' is: if this function is commented, the BL2 comes up successfully. Flow in the code base is : mmap_add_dynamic_region -> mmap_add_dynamic_region_ctx -> xlat_tables_map_region-> xlat_table_get_empty //....issue is seen. >Can you try one or both statements below after the call to xlat_table_get_empty (and uncomment calls to clean_dcache_range): > > inv_dcache_range((uintptr_t)subtable, XLAT_TABLE_SIZE); > > xlat_arch_tlbi_va((uintptr_t)subtable, ctx->xlat_regime); > xlat_arch_tlbi_va_sync(); mmap_add_dynamic_region -> mmap_add_dynamic_region_ctx -> xlat_tables_map_region-> xlat_table_get_empty-> xlat_arch_tlbi_va //issue is resolved. The root cause of this issue is race condition. Please correct me if I am wrong. Another observation: mmap_add_dynamic_region -> mmap_add_dynamic_region_ctx (Putting console debug logs in this function)-> xlat_tables_map_region-> xlat_table_get_empty //issue is resolved. Please share your view for this observation as well. Regards, Olivier. -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Pankaj Gupta via TF-A Sent: 05 February 2020 11:45 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Issue with addition of NXP Platform support on TFA v2.2 Hi, In the TFA v2.2 code base, the file "lib/xlat_tables_v2/xlat_tables_core.c" has the implementation for function "xlat_tables_map_region()". The implementation for this function is changed in TFAv2.2 (compared TFAv1.5), with addition of function "xlat_clean_dcache_range()". Due to this addition, my earlier* working platform on TFAv1.5, is hanging here. If the function call for the function "xlat_clean_dcache_range()", is comment, then the platform works well. Code snippet: static inline __attribute__((unused)) void xlat_clean_dcache_range(uintptr_t addr, size_t size) { if (is_dcache_enabled()) clean_dcache_range(addr, size); // On commenting this line, my platform works fine with TFAv2.2 } Please share your views on what could I be missing here. Thanks. Regards Pankaj *Earlier raised patch for this platform was not merged due to review comments are not disposed-off in time; and TF-A got migrated from github to gerrit. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru… -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

6 years

1
0
0 0

Re: [TF-A] Issue with addition of NXP Platform support on TFA v2.2

by Olivier Deprez

Hi Pankaj, Can you pls provide a bit more background: Which boot stage (BL1/BL2/BL31...) get affected? Is there any crash report to console? Is this an aarch64/or aarch32 platform? There can be different root causes to this e.g. 1. a stale translation in TLB, or a dirty cache line remnant from earlier boot stages. If this is the case, it would need invalidating TLB and/or caches on BL entry. 2. the empty table ptr given by xlat_table_get_empty is pointing nowhere sensible because of this specific platform layout There are multiple calls to xlat_clean_dcache_range in this file, do you confirm the crash happen within xlat_tables_map_region? Can you try one or both statements below after the call to xlat_table_get_empty (and uncomment calls to clean_dcache_range): inv_dcache_range((uintptr_t)subtable, XLAT_TABLE_SIZE); xlat_arch_tlbi_va((uintptr_t)subtable, ctx->xlat_regime); xlat_arch_tlbi_va_sync(); Regards, Olivier. -----Original Message----- From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Pankaj Gupta via TF-A Sent: 05 February 2020 11:45 To: tf-a(a)lists.trustedfirmware.org Subject: [TF-A] Issue with addition of NXP Platform support on TFA v2.2 Hi, In the TFA v2.2 code base, the file "lib/xlat_tables_v2/xlat_tables_core.c" has the implementation for function "xlat_tables_map_region()". The implementation for this function is changed in TFAv2.2 (compared TFAv1.5), with addition of function "xlat_clean_dcache_range()". Due to this addition, my earlier* working platform on TFAv1.5, is hanging here. If the function call for the function "xlat_clean_dcache_range()", is comment, then the platform works well. Code snippet: static inline __attribute__((unused)) void xlat_clean_dcache_range(uintptr_t addr, size_t size) { if (is_dcache_enabled()) clean_dcache_range(addr, size); // On commenting this line, my platform works fine with TFAv2.2 } Please share your views on what could I be missing here. Thanks. Regards Pankaj *Earlier raised patch for this platform was not merged due to review comments are not disposed-off in time; and TF-A got migrated from github to gerrit. -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

2
1
0 0

Re: [TF-A] CI status update - end to end boot testing on Juno

by Matteo Carlini

Hi Fathi, Thanks for the below write-up, this is really great news! > Note: this is in silent mode (links to the build job are currently disabled, > and will be re-enableb today). Please go ahead in re-enabling those jobs, so that people can see the results of the build jobs (while we work on propagating back to Gerrit also the results of the LAVA boot jobs). Thanks Matteo > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Fathi > Boudra via TF-A > Sent: 05 February 2020 12:45 > To: TF-A(a)lists.trustedfirmware.org > Cc: Ryan Arnold <ryan.arnold(a)linaro.org> > Subject: [TF-A] CI status update - end to end boot testing on Juno > > Hi, > > The end-to-end testing prototype is now completed and enabled. > This encompases an end-to-end testing pipeline whereby TF-A code > submission to gerrit results in a TF build (based on the code submission) > being injected into a file system (recovery image) and booted on a Juno > device in the Linaro TF LAVA instance with the results of the boot test > available in the LAVA instance. > > Here's the explanation of the CI pipeline: > 1. Trigger - capture gerrit events: > https://ci.trustedfirmware.org/job/trigger-tf-a-builder/ > All changes made to the trusted-firmware A repository are captured by > the trigger event and result in a build. > e.g., triggering commit: > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3100 > Note: this is in silent mode (links to the build job are currently disabled, > and will be re-enableb today). > 2. Build Binary Artifacts - Binary artifacts built via: > https://ci.trustedfirmware.org/job/tf-a-builder/ > e.g., https://ci.trustedfirmware.org/job/tf-a-builder/631/ > (with a link to the accompanying LAVA job and a link to the trigger job in > gerrit) 3. Recovery/Flash submission to LAVA - Used to flash the binary to the > board: > https://ci.trustedfirmware.org/job/post-build-lava/ > 4. LAVA tests results > e.g., Specific example of the template applied to a specific build > (631 above) > https://tf.validation.linaro.org/scheduler/job/895/definition > Results: https://tf.validation.linaro.org/results/895 > Link to all jobs: https://tf.validation.linaro.org/scheduler/alljobs > > Some additional information: > * tf-a-ci-scripts git repository has been set up and contains the CI scripts for > TF-A. > https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/ > * tf-a-job-configs git repository has been set up and contains the Jenkins jobs > configurations automatically deployed on https://ci.trustedfirmware.org > Jenkins instance. > https://git.trustedfirmware.org/ci/tf-a-job-configs.git/ > > Cheers, > -- > Fathi Boudra > Linaro.org | Open source software for ARM SoCs > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

1
0
0 0

CI status update - end to end boot testing on Juno

by Fathi Boudra

Hi, The end-to-end testing prototype is now completed and enabled. This encompases an end-to-end testing pipeline whereby TF-A code submission to gerrit results in a TF build (based on the code submission) being injected into a file system (recovery image) and booted on a Juno device in the Linaro TF LAVA instance with the results of the boot test available in the LAVA instance. Here's the explanation of the CI pipeline: 1. Trigger - capture gerrit events: https://ci.trustedfirmware.org/job/trigger-tf-a-builder/ All changes made to the trusted-firmware A repository are captured by the trigger event and result in a build. e.g., triggering commit: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3100 Note: this is in silent mode (links to the build job are currently disabled, and will be re-enableb today). 2. Build Binary Artifacts - Binary artifacts built via: https://ci.trustedfirmware.org/job/tf-a-builder/ e.g., https://ci.trustedfirmware.org/job/tf-a-builder/631/ (with a link to the accompanying LAVA job and a link to the trigger job in gerrit) 3. Recovery/Flash submission to LAVA - Used to flash the binary to the board: https://ci.trustedfirmware.org/job/post-build-lava/ 4. LAVA tests results e.g., Specific example of the template applied to a specific build (631 above) https://tf.validation.linaro.org/scheduler/job/895/definition Results: https://tf.validation.linaro.org/results/895 Link to all jobs: https://tf.validation.linaro.org/scheduler/alljobs Some additional information: * tf-a-ci-scripts git repository has been set up and contains the CI scripts for TF-A. https://git.trustedfirmware.org/ci/tf-a-ci-scripts.git/ * tf-a-job-configs git repository has been set up and contains the Jenkins jobs configurations automatically deployed on https://ci.trustedfirmware.org Jenkins instance. https://git.trustedfirmware.org/ci/tf-a-job-configs.git/ Cheers, -- Fathi Boudra Linaro.org | Open source software for ARM SoCs

6 years, 1 month

1
0
0 0

Issue with addition of NXP Platform support on TFA v2.2

by Pankaj Gupta

Hi, In the TFA v2.2 code base, the file "lib/xlat_tables_v2/xlat_tables_core.c" has the implementation for function "xlat_tables_map_region()". The implementation for this function is changed in TFAv2.2 (compared TFAv1.5), with addition of function "xlat_clean_dcache_range()". Due to this addition, my earlier* working platform on TFAv1.5, is hanging here. If the function call for the function "xlat_clean_dcache_range()", is comment, then the platform works well. Code snippet: static inline __attribute__((unused)) void xlat_clean_dcache_range(uintptr_t addr, size_t size) { if (is_dcache_enabled()) clean_dcache_range(addr, size); // On commenting this line, my platform works fine with TFAv2.2 } Please share your views on what could I be missing here. Thanks. Regards Pankaj *Earlier raised patch for this platform was not merged due to review comments are not disposed-off in time; and TF-A got migrated from github to gerrit.

6 years, 1 month

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Sandrine Bailleux

Hi all, On Tue, 2020-01-28 at 14:57 +0000, Raghupathy Krishnamurthy via TF-A wrote: > I completely agree with you! All i'm asking for is that what you are > proposing is ratified in the spec clearly, without any ambiguities > and that we don't implement what we *think* is correct, but implement > the spec. If the spec specifies encryption, we should implement > encryption, not authenticated encryption. One is not a direct > substitute for the other and requires careful thinking. Similarly, > the order of signing, encryption, decryption and authentication must > be specified and explained clearly, specifically to avoid these kinds > of discussions. Just to keep everyone in the loop, we are currently having some internal discussions within Arm about TBBR/TBFU and all the questions/concerns that have been raised in this thread. I will update you ASAP. Best regards, Sandrine

6 years, 1 month

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Raghupathy Krishnamurthy

Hi Sumit, I completely agree with you! All i'm asking for is that what you are proposing is ratified in the spec clearly, without any ambiguities and that we don't implement what we *think* is correct, but implement the spec. If the spec specifies encryption, we should implement encryption, not authenticated encryption. One is not a direct substitute for the other and requires careful thinking. Similarly, the order of signing, encryption, decryption and authentication must be specified and explained clearly, specifically to avoid these kinds of discussions. Thanks -Raghu On January 27, 2020 at 10:49 PM, Sumit Garg <sumit.garg(a)linaro.org> wrote: On Mon, 27 Jan 2020 at 22:54, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: Sumit, Great point. This perhaps needs to be added to the list of things that need clarification(Sandrine can you help with this too?) in the PSA-TBFU . I believe the answer to your concern lies in the PSA-TBFU in section 3.5, where it talks about optimizing the trusted boot process. To overcome the problem you're talking about, you would: 1) Verify asymmetric signature. 2) Decrypt firmware using SSK on successful signature verification. 3) Rekey the firmware using BSSK(or as the PSA specifies, a key derived from the HUK using a KDF). You will only verify the asymmetric signature on every firmware update, and use the rekeyed firmware(encrypted and mac;d with device specific key) on normal boot. Following is the quote from PSA-TBFU spec: "An implementation **can** optimize the trusted boot process at the expense of **simplicity**" It doesn't seems to be a recommended practice from spec. And especially for DRM use-cases, this approach is NOT recommended due to following concerns raised by DRM vendors (original concerns were with respect to TAs but will equally apply for firmware as well): - allows the device to self sign code authorized to run on the device. - increase the attack surface by having two different ways to load firmware. - allow a break once break forever situation, if you defeat the RSA 'install' once, no matter how hard it is, now your firmware is nicely transformed in a secure firmware and can be reused. Whereas on the other hand, considering "sign-then-encrypt-then-authenticate", it provides two mutually exclusive crypto layers (signature layer and authenticated encryption layer) which in turns provides implementation flexibility as follows: Firmware update: - Require both layers. Normal boot: - DRM use-case, require both layers. - Boot time optimization required, can use only authenticated encryption. - Platform provides secure on-chip NVM and boot time optimization required, can use only signature verification (or simply hash stored in secure on-chip NVM memory). -Sumit Thanks Raghu On January 26, 2020 at 10:34 PM, Sumit Garg <sumit.garg(a)linaro.org> wrote: On Fri, 24 Jan 2020 at 16:36, Sumit Garg <sumit.garg(a)linaro.org> wrote: On Fri, 24 Jan 2020 at 04:02, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: > > I also just realized that both the TBBR and ARM PSA only talk about encryption of the image, and not authenticated encryption. The guarantees provided by both are completely different. Your review(https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/) talks about the requirement R060_TBBR_FUNCTION being implemented, which is technically not true(and potentially misleading). We must make a note of this difference and use the appropriate terminology, without mixing the two, in the documentation, commit messages, source code comments and error prints. The tool is also called 'encrypt_fw ' but should maybe be named appropriately to indicate it is doing authenticated encryption. I wouldn't call it misleading. Since firmware encryption feature essentially provides confidentiality protection and authenticated encryption is the type of crypto algorithm which we have used to implement it. > > BTW, ARM PSA(file:///home/raghu/repos/fvp/DEN0072-PSA_TBFU_1-0-REL.pdf) expects that the image manifest(X509 certificate) contain the hash of the ENCRYPTED image(Table 2 and as described in my answer to your question "How would this ensure integrity of ciphertext"). The TBBR spec completely misses this fact, and is a crucial detail if we only implement encryption(as opposed to authenticated encryption).Build_macros.mk, in your change, passes the un-encrypted image to cert-tool. You can get away with it in your implementation, since you are using authenticated encryption, not if you were only implementing firmware encryption. I have already highlighted the issue with signing the ciphertext in my previous reply which deviates from security properties provided by signature verification of plain firmware. So I think we need to revisit ARM PSA TBFU spec. In addition to this, there are implementation specific issues with "signing the ciphertext" too. It simply makes the ciphertext immutable for device and disallows meeting following firmware re-encryption requirement as per TBBR spec: R070_TBBR_PROTECTION. The Trusted boot firmware may do the binding of software image updates at run- time by decrypting the updated SoC certificates and software images using the OTP/Fuse Secret Symmetric Key (SSK), followed by the re-encrypting these SoC certificates and software images using a reproducible secret unique per device symmetric key (BSSK), and then updating the ToC correspondingly. Also, externally signing every firmware image encrypted with BSSK doesn't seem scalable as well. It also hampers the case where encryption key is never exposed out from device eg. encryption key is only accessible to hardware crypto engine etc. -Sumit > > Is it possible for somebody from ARM to have the TBBR spec updated to reflect this? Also perhaps talk to the spec writers about incorporating authenticated encryption into TBBR and PSA? This patch set is somewhat trailblazing in this regard. > > -Raghu > > > On January 23, 2020 at 12:08 PM, Raghupathy Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Sumit, > > > Thanks for your response. > > > So firstly I would suggest you to revisit TBBR spec [1], > > > > [RK] I'm very familiar with the TBBR spec and the requirements. Note that not all SoC's adhere perfectly to the TBBR spec, since it does not apply to devices in all market segments. However, these devices do use arm trusted firmware and TBBR CoT in a slightly modified form, which is still perfectly valid. Also, the TBBR spec can be changed if required :) > > > Why would one use authenticated decryption only to establish TBBR > > Chain of Trust providing device the capability to self sign its firmware? > > [RK] Fair point. However, you may have devices that don't have the processing power or hardware budget or cost factors(paying for HSM's to store private asymmetric keys), to implement asymmetric verification, in which case using authenticated decryption to verify firmware authenticity and integrity is perfectly valid. The attacks on devices that use symmetric keys to verify firmware authenticity and integrity are usually related to exploiting firmware flaws that leak the key or insiders leaking keys, but that is a different problem and requires different solutions. Fundamentally, there is nothing wrong with using symmetric keys for this purpose, so long as the key is well protected. Also note, security requirements and guarantees are different for different systems. The risk is taken by the system designer and should not be imposed by framework code. I don't advocate doing this but it is an option that your implementation does not provide(and perhaps rightly so). > > > How would this ensure integrity of ciphertext? > > > > [RK] You sign the ciphertext. In your design, you pass bl31_enc.bin to cert_tool to sign. You don't decrypt the encrypted cipher text until you have verified the asymmetric signature(which provides integrity). As far as signature verification is concerned, whether you sign the plain text or ciphertext is immaterial, since you are simply verifying that the absolute bits you loaded have not been modified(assuming you use a secure signature scheme). > > > Have a look at some defective sign and encrypt techniques here [2] > > > > [RK] Again, very familiar with [2]. In the S/MIME case, you have multiple parties. With secure boot, you have one party, effectively verifying its own messages across time. There is only one key used to verify signatures. 1.1 and 1.2 does not apply. Also you are encrypting and signing with completely different keys and algorithms. Section 1.2 applies when you use RSA/El-gamal encryption. Here you use symmetric encryption and asymmetric signing. > > > Why would one not use TBBR CoT here? > > > > [RK] see above. Not all systems are designed equal. > > > > and why would one like to hardcode in a device during > > provisioning to boot only either an encrypted or a plain firmware > image? > > > [RK] Why would you not? You typically want to have the same security policy for a class of devices and not be modifiable by an attacker. It isn't common for the same class of devices to use encrypted firmware some times, and un-encrypted firmware other times. If it is common, there is no problem with setting the bit in the FIP header, as long as verified boot is mandatory. The only concern(as my original email said) is the coupling of the FIP layer and the crypto module, in the implementation. I still don't like that fact that the bit saying the file is encrypted is not signed and this may require talking to the TBBR spec writers. Page 22 of the TBBR spec calls out ToC as "Trusted Table of Contents". The FIP header cannot be "trusted", if it is not in ROM or its integrity is verified by some means! R010_TBBR_TOC should perhaps be mandatory then. Also see R080_TBBR_TOC that says the TOC MUST be ROM'ed or tied by hardware in readable registers. This requirement seems contradictory to R010_TBBR_TOC, given that the FIP header(TOC) is copied from mutable NVM by ROM or some boot stage and then ROM'd or loaded into registers. I may be misunderstanding R080_TBBR_TOC, but i'd interpret it as the TOC(FIP header in ATF implementation of TBBR) as being in ROM or integrity verified. > > > How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? > > > > [RK]TBBR CoT is equipped to do this. The table is defined on a per image basis. > > > If you are really paranoid about authentication of FIP header... > > [RK] I don't mean to pontificate but there are real world customers buying real hardware, running ATF code, who care about such details and ask about such things routinely. It is not just me being paranoid and is definitely not a minor matter to think of such details. We should discuss more and consider the implications of R080_TBBR_TOC and R010_TBBR_TOC, perhaps on a different thread, without blocking your code review. Can somebody from ARM clarify these requirements with the spec writers? > > > Thanks > -Raghu > > > On January 23, 2020 at 12:38 AM, Sumit Garg <sumit.garg(a)linaro.org> wrote: > > > Hi Raghu, > > I guess you have completely misunderstood this feature. This is an > optional feature which allows to load encrypted FIP payloads using > authenticated decryption which MUST be used along with signature > verification (or TBBR CoT). > > So firstly I would suggest you to revisit TBBR spec [1], especially > requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. > > On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy > <raghu.ncstate(a)icloud.com> wrote: > > > > Hello, > > > The patch stack looks good. The only comment i have is that the FIP layer has now become security aware and supports authenticated decryption(only). This is a deviation from the secure/signed/verified boot design, where we use the TBBR COT to dictate the security operations on the file. This is nice, because file IO is decoupled from the security policy. This may be a big deviation(i apologize if this was considered and shot down for some other reason), but it may be worthwhile to consider making authenticated decryption a part of the authentication framework as opposed to coupling it with the FIP layer. > > It looks like you have mixed both TBBR CoT and this authenticated > decryption feature. They both are completely different and rather > complement each other where TBBR CoT establishes > secure/signed/verified boot and this authenticated decryption feature > provides confidentiality protection for FIP payloads. > > > At a high level, this would mean adding a new authentication method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having the platform specify that the image is using authenticated encryption in the TBBR COT. > > Why would one use authenticated decryption only to establish TBBR > Chain of Trust providing device the capability to self sign its > firmwares? We must use signature verification for TBBR CoT (see > section: 2.1 Authentication of Code Images by Certificate in TBBR spec > [1]). > > > The authentication framework is already well designed and well equipped to handle these types of extensions. > 1) This would make the change simpler, since you would not require changes to the FIP tool and the FIP layer. > 2) This would also allow for future cases where a platform may want to only encrypt the file and use public key authentication on the encrypted file(for ex. the soc does not have a crypto accelerator for aes-gcm but only for AES and public key verification, for whatever reason). > > How would this ensure integrity of ciphertext? This approach may be > vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag as > part of AES-GCM provides integrity protection for ciphertext. > > > 3) This would let you choose the order in which you want to do the authenticated decryption(or just decryption) and signature verification, if you use both, one or the other. > > > > Have a look at some defective sign and encrypt techniques here [2]. > The order can't be any arbitrary one, we need to be careful about > this. > > > One other thing i'm not entirely comfortable with is that the flag indicating if there are encrypted files or not in the FIP, is in the *unsigned* portion of the FIP header. An attacker could simply flip bits that dictate security policy in the header and avoid detection(in this case, the indication that the file needs authenticated decryption). If a platform only uses authenticated encryption, but not verified boot, an attacker could flip the bit in the FIP header and have any image loaded on the platform. > > Why would one not use TBBR CoT here? > > > If authenticated encryption cannot be used without verified boot(which requires build time flags), having a flag to indicate that there are encrypted files in the FIP header is moot, since this can come at build time through the TBBR COT. In any case, it seems like the security policy that firmware images need to be decrypted or authenticated with authenticated decryption, seems like a firmware build time or manufacturing time decision(perhaps a bit set in the e-fuses). > > Again you are confusing TBBR CoT with authenticated decryption > feature. And why would one like to hardcode in a device during > provisioning to boot only either an encrypted or a plain firmware > image? > > > There seems to be no benefit to having a flag in the FIP header. > > How would one handle a case where BL31 is in plain format and BL32 is > in encrypted format? > > > Otherwise, I cant think of any attacks due to this and it may be completely okay, but generally, consuming data that dictates security policy/operations before verifying its integrity seems like a recipe for disaster. > > > > If you are really paranoid about authentication of FIP header then you > should look at implementing optional requirement: R010_TBBR_TOC as per > TBBR spec [1]. > > [1] https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requiremen… > [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html > > -Sumit > > > -Raghu > > > On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > > Hi Sandrine, > > > On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux > <Sandrine.Bailleux(a)arm.com> wrote: > > > > > Hello Sumit, > > > > > Thank you for reworking the patches and addressing all of my review > > > comments. I am happy with the latest version of these and consider them > > > ready to go. I plan to leave them in Gerrit for another week to give > > > extra time for other potential reviewers to have a look and comment. > > > > > > > Thanks for your review. > > > To everyone on the list: Please raise any concerns you may have about > > > these patches in the coming week. If I don't hear anything by 29th > > > January 2020, I will merge these patches. > > > > > @Sumit: One of the next actions for this patch stack would be to have > > > some level of testing in the CI system to detect any potential > > > regressions. We (at Arm) can quite easily add a few build tests but then > > > testing the software stack on QEMU is a bit more involved for various > > > reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, > > > ...) so this might have to wait for some time. > > > > > > > Okay, will wait for CI testing. > > > -Sumit > > > Regards, > > > Sandrine > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Sumit Garg

On Mon, 27 Jan 2020 at 22:43, Raghupathy Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Thanks Soby, Sumit, Sandrine and Joakim! > > > Agree with Joakim/Soby about encrypt then sign and sign then encrypt being okay, when authenticated encryption is used. I'd like to point out again, that the link provided by Sumit talks about encrypt-then-sign and sign-then-encrypt, using asymmetric encryption and asymmetric signing only, and as Joakim rightly pointed out(and as i did in my earlier email), does not necessarily apply here. They are not talking about symmetric encryption with asymmetric signing, which is what PSA-TBFU and TBBR are talking about. > I usually don't like signing plain text and encrypt(not authenticated encryption, just encryption like aes-cbc etc) plain text due to https://moxie.org/blog/the-cryptographic-doom-principle/(written by the creator of the the WhatsApp end-to-end encryption protocol, this applies to symmetric encryption and symmetric signing/MAC's, but it applies to any ciphertext that is decrypted without verifying its integrity). If we were to sign the plain text then encrypt the firmware, the size of the encrypted file needs to be integrity protected as well, not just the bit that indicates that the file is encrypted. If not, when we decrypt the firmware image, we can perform some creative attacks on symmetric encryption, as specified in the link, and requires careful implementation of error handling/reporting on decryption errors. Just to clarify here further that authenticated encryption (aes-gcm) follows “encrypt-then-authenticate” principal only, which is mentioned optimal as per https://moxie.org/blog/the-cryptographic-doom-principle/. -Sumit > > > I also like Soby's approach of having an attribute EP_ENCRYPTED and relying on platform_pre_image_load() and platform_post_image_load() to do the decryption and that addresses my non-spec related concerns. It also allows for decrypt-then-authenticate(which i wouldn't use) and authenticate-then-decrypt. It also puts the attribute that indicates firmware encryption in the image descriptor table which is integrity protected by virtue of it being in the ROM or being signed, and also leaves the FIP layer unaltered. > > > Thanks > -Raghu > > On January 27, 2020 at 6:42 AM, Soby Mathew <Soby.Mathew(a)arm.com> wrote: > > > On 27/01/2020 12:34, Joakim Bech via TF-A wrote: > > on raw binaries are there so we can be sure that > we're loading unmodified firmware coming from the one owning a private key > corresponding to the public key hardcoded into the device (or via a hash of > the public key). I think we all can agree > > OK, I have finally managed to catch up on this thread. Apologies for the > delayed response. > > As Joakim mentions, I think both the mentioned cases ie. encrypt plain > text -> sign and sign -> encrypt are valid and it depend on the threat > model and security requirement. > > I have had a brief look at the patch stack and coupling the feature to > the FIP does not seem like a good idea to me( + the added complexity > protecting the ToC). Currently meta data of the firmware images is > passed OOB via the `bl_mem_params_node_t` descriptor to the BL images > whereas this patch breaks that convention. It is better to follow the > set convention and avoid dependency on FIP format (btw platforms need > not use FIP format and can use other packaging formats). > > The iv data to decrypt seems to be prepended to the encrypted file in > the fip which is making custom manipulations file pointer manipulations > which is raising some red flags. > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/8/drive… > > IMO, this should not visible to be FIP driver. I am not sure of the best > practice for sending iv data but if it has to be prepended, it should be > FIP agnostic. > > The TBBR assumes a single owner for all images whereas the TBFU > supercedes this spec by allowing multiple owners for different images. > We are in the process of enhancing the CoT for different Root of Trusts > for different images and there needs to be capability to encrypt with > different keys for different images based on ownership. The current > implementation has some limitations like introducing a platform API > invocation within the driver layer to get the single key which is not > ideal IMO. > > I haven't fully flushed out my ideas, but thoughts are based on > enhancements done by Masahiro for adding decompression support for BL > images. See https://github.com/ARM-software/arm-trusted-firmware/pull/1224 . > > Basically, this patch series allows any filter to be setup before/after > the images are loaded. It relies on pre-load and post load hooks which > are platform specific to perform the filter operation. So, if a new > image attribute `EP_ENCRYPTED` is added ep_info_exp.h, then BL2 needs to > do the following in bl2_plat_handle_pre_image_load() > { > if EP_ENCRYPTED is set : > load the image to SRAM and decrypt using crypto module > } > > This will cater for `decrypt-then-authenticate` flow. > > The fip_tool no longer needs to be aware of encryption and the build > process just needs to pipe the encrypted binaries to the fip_tool. > > Similarly if `authenticate-then-decrypt` needs to be supported, then all > that the platform needs to do is implement decrypt in > bl2_plat_handle_post_image_load(). > > The platform can now use different keys to use for different BL images > if it needs to do so. > > Some usecases require the firmware images to be re-encrypted using HUK > after firmware update (aka firmware binding) and following this design > will allow this to be done as well. > > > Best Regards > Soby Mathew > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Raghupathy Krishnamurthy

Sumit, Great point. This perhaps needs to be added to the list of things that need clarification(Sandrine can you help with this too?) in the PSA-TBFU . I believe the answer to your concern lies in the PSA-TBFU in section 3.5, where it talks about optimizing the trusted boot process. To overcome the problem you're talking about, you would: 1) Verify asymmetric signature. 2) Decrypt firmware using SSK on successful signature verification. 3) Rekey the firmware using BSSK(or as the PSA specifies, a key derived from the HUK using a KDF). You will only verify the asymmetric signature on every firmware update, and use the rekeyed firmware(encrypted and mac;d with device specific key) on normal boot. Thanks Raghu On January 26, 2020 at 10:34 PM, Sumit Garg <sumit.garg(a)linaro.org> wrote: On Fri, 24 Jan 2020 at 16:36, Sumit Garg <sumit.garg(a)linaro.org> wrote: On Fri, 24 Jan 2020 at 04:02, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: > > I also just realized that both the TBBR and ARM PSA only talk about encryption of the image, and not authenticated encryption. The guarantees provided by both are completely different. Your review(https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/) talks about the requirement R060_TBBR_FUNCTION being implemented, which is technically not true(and potentially misleading). We must make a note of this difference and use the appropriate terminology, without mixing the two, in the documentation, commit messages, source code comments and error prints. The tool is also called 'encrypt_fw ' but should maybe be named appropriately to indicate it is doing authenticated encryption. I wouldn't call it misleading. Since firmware encryption feature essentially provides confidentiality protection and authenticated encryption is the type of crypto algorithm which we have used to implement it. > > BTW, ARM PSA(file:///home/raghu/repos/fvp/DEN0072-PSA_TBFU_1-0-REL.pdf) expects that the image manifest(X509 certificate) contain the hash of the ENCRYPTED image(Table 2 and as described in my answer to your question "How would this ensure integrity of ciphertext"). The TBBR spec completely misses this fact, and is a crucial detail if we only implement encryption(as opposed to authenticated encryption).Build_macros.mk, in your change, passes the un-encrypted image to cert-tool. You can get away with it in your implementation, since you are using authenticated encryption, not if you were only implementing firmware encryption. I have already highlighted the issue with signing the ciphertext in my previous reply which deviates from security properties provided by signature verification of plain firmware. So I think we need to revisit ARM PSA TBFU spec. In addition to this, there are implementation specific issues with "signing the ciphertext" too. It simply makes the ciphertext immutable for device and disallows meeting following firmware re-encryption requirement as per TBBR spec: R070_TBBR_PROTECTION. The Trusted boot firmware may do the binding of software image updates at run- time by decrypting the updated SoC certificates and software images using the OTP/Fuse Secret Symmetric Key (SSK), followed by the re-encrypting these SoC certificates and software images using a reproducible secret unique per device symmetric key (BSSK), and then updating the ToC correspondingly. Also, externally signing every firmware image encrypted with BSSK doesn't seem scalable as well. It also hampers the case where encryption key is never exposed out from device eg. encryption key is only accessible to hardware crypto engine etc. -Sumit > > Is it possible for somebody from ARM to have the TBBR spec updated to reflect this? Also perhaps talk to the spec writers about incorporating authenticated encryption into TBBR and PSA? This patch set is somewhat trailblazing in this regard. > > -Raghu > > > On January 23, 2020 at 12:08 PM, Raghupathy Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Sumit, > > > Thanks for your response. > > > So firstly I would suggest you to revisit TBBR spec [1], > > > > [RK] I'm very familiar with the TBBR spec and the requirements. Note that not all SoC's adhere perfectly to the TBBR spec, since it does not apply to devices in all market segments. However, these devices do use arm trusted firmware and TBBR CoT in a slightly modified form, which is still perfectly valid. Also, the TBBR spec can be changed if required :) > > > Why would one use authenticated decryption only to establish TBBR > > Chain of Trust providing device the capability to self sign its firmware? > > [RK] Fair point. However, you may have devices that don't have the processing power or hardware budget or cost factors(paying for HSM's to store private asymmetric keys), to implement asymmetric verification, in which case using authenticated decryption to verify firmware authenticity and integrity is perfectly valid. The attacks on devices that use symmetric keys to verify firmware authenticity and integrity are usually related to exploiting firmware flaws that leak the key or insiders leaking keys, but that is a different problem and requires different solutions. Fundamentally, there is nothing wrong with using symmetric keys for this purpose, so long as the key is well protected. Also note, security requirements and guarantees are different for different systems. The risk is taken by the system designer and should not be imposed by framework code. I don't advocate doing this but it is an option that your implementation does not provide(and perhaps rightly so). > > > How would this ensure integrity of ciphertext? > > > > [RK] You sign the ciphertext. In your design, you pass bl31_enc.bin to cert_tool to sign. You don't decrypt the encrypted cipher text until you have verified the asymmetric signature(which provides integrity). As far as signature verification is concerned, whether you sign the plain text or ciphertext is immaterial, since you are simply verifying that the absolute bits you loaded have not been modified(assuming you use a secure signature scheme). > > > Have a look at some defective sign and encrypt techniques here [2] > > > > [RK] Again, very familiar with [2]. In the S/MIME case, you have multiple parties. With secure boot, you have one party, effectively verifying its own messages across time. There is only one key used to verify signatures. 1.1 and 1.2 does not apply. Also you are encrypting and signing with completely different keys and algorithms. Section 1.2 applies when you use RSA/El-gamal encryption. Here you use symmetric encryption and asymmetric signing. > > > Why would one not use TBBR CoT here? > > > > [RK] see above. Not all systems are designed equal. > > > > and why would one like to hardcode in a device during > > provisioning to boot only either an encrypted or a plain firmware > image? > > > [RK] Why would you not? You typically want to have the same security policy for a class of devices and not be modifiable by an attacker. It isn't common for the same class of devices to use encrypted firmware some times, and un-encrypted firmware other times. If it is common, there is no problem with setting the bit in the FIP header, as long as verified boot is mandatory. The only concern(as my original email said) is the coupling of the FIP layer and the crypto module, in the implementation. I still don't like that fact that the bit saying the file is encrypted is not signed and this may require talking to the TBBR spec writers. Page 22 of the TBBR spec calls out ToC as "Trusted Table of Contents". The FIP header cannot be "trusted", if it is not in ROM or its integrity is verified by some means! R010_TBBR_TOC should perhaps be mandatory then. Also see R080_TBBR_TOC that says the TOC MUST be ROM'ed or tied by hardware in readable registers. This requirement seems contradictory to R010_TBBR_TOC, given that the FIP header(TOC) is copied from mutable NVM by ROM or some boot stage and then ROM'd or loaded into registers. I may be misunderstanding R080_TBBR_TOC, but i'd interpret it as the TOC(FIP header in ATF implementation of TBBR) as being in ROM or integrity verified. > > > How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? > > > > [RK]TBBR CoT is equipped to do this. The table is defined on a per image basis. > > > If you are really paranoid about authentication of FIP header... > > [RK] I don't mean to pontificate but there are real world customers buying real hardware, running ATF code, who care about such details and ask about such things routinely. It is not just me being paranoid and is definitely not a minor matter to think of such details. We should discuss more and consider the implications of R080_TBBR_TOC and R010_TBBR_TOC, perhaps on a different thread, without blocking your code review. Can somebody from ARM clarify these requirements with the spec writers? > > > Thanks > -Raghu > > > On January 23, 2020 at 12:38 AM, Sumit Garg <sumit.garg(a)linaro.org> wrote: > > > Hi Raghu, > > I guess you have completely misunderstood this feature. This is an > optional feature which allows to load encrypted FIP payloads using > authenticated decryption which MUST be used along with signature > verification (or TBBR CoT). > > So firstly I would suggest you to revisit TBBR spec [1], especially > requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. > > On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy > <raghu.ncstate(a)icloud.com> wrote: > > > > Hello, > > > The patch stack looks good. The only comment i have is that the FIP layer has now become security aware and supports authenticated decryption(only). This is a deviation from the secure/signed/verified boot design, where we use the TBBR COT to dictate the security operations on the file. This is nice, because file IO is decoupled from the security policy. This may be a big deviation(i apologize if this was considered and shot down for some other reason), but it may be worthwhile to consider making authenticated decryption a part of the authentication framework as opposed to coupling it with the FIP layer. > > It looks like you have mixed both TBBR CoT and this authenticated > decryption feature. They both are completely different and rather > complement each other where TBBR CoT establishes > secure/signed/verified boot and this authenticated decryption feature > provides confidentiality protection for FIP payloads. > > > At a high level, this would mean adding a new authentication method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having the platform specify that the image is using authenticated encryption in the TBBR COT. > > Why would one use authenticated decryption only to establish TBBR > Chain of Trust providing device the capability to self sign its > firmwares? We must use signature verification for TBBR CoT (see > section: 2.1 Authentication of Code Images by Certificate in TBBR spec > [1]). > > > The authentication framework is already well designed and well equipped to handle these types of extensions. > 1) This would make the change simpler, since you would not require changes to the FIP tool and the FIP layer. > 2) This would also allow for future cases where a platform may want to only encrypt the file and use public key authentication on the encrypted file(for ex. the soc does not have a crypto accelerator for aes-gcm but only for AES and public key verification, for whatever reason). > > How would this ensure integrity of ciphertext? This approach may be > vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag as > part of AES-GCM provides integrity protection for ciphertext. > > > 3) This would let you choose the order in which you want to do the authenticated decryption(or just decryption) and signature verification, if you use both, one or the other. > > > > Have a look at some defective sign and encrypt techniques here [2]. > The order can't be any arbitrary one, we need to be careful about > this. > > > One other thing i'm not entirely comfortable with is that the flag indicating if there are encrypted files or not in the FIP, is in the *unsigned* portion of the FIP header. An attacker could simply flip bits that dictate security policy in the header and avoid detection(in this case, the indication that the file needs authenticated decryption). If a platform only uses authenticated encryption, but not verified boot, an attacker could flip the bit in the FIP header and have any image loaded on the platform. > > Why would one not use TBBR CoT here? > > > If authenticated encryption cannot be used without verified boot(which requires build time flags), having a flag to indicate that there are encrypted files in the FIP header is moot, since this can come at build time through the TBBR COT. In any case, it seems like the security policy that firmware images need to be decrypted or authenticated with authenticated decryption, seems like a firmware build time or manufacturing time decision(perhaps a bit set in the e-fuses). > > Again you are confusing TBBR CoT with authenticated decryption > feature. And why would one like to hardcode in a device during > provisioning to boot only either an encrypted or a plain firmware > image? > > > There seems to be no benefit to having a flag in the FIP header. > > How would one handle a case where BL31 is in plain format and BL32 is > in encrypted format? > > > Otherwise, I cant think of any attacks due to this and it may be completely okay, but generally, consuming data that dictates security policy/operations before verifying its integrity seems like a recipe for disaster. > > > > If you are really paranoid about authentication of FIP header then you > should look at implementing optional requirement: R010_TBBR_TOC as per > TBBR spec [1]. > > [1] https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requiremen… > [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html > > -Sumit > > > -Raghu > > > On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > > Hi Sandrine, > > > On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux > <Sandrine.Bailleux(a)arm.com> wrote: > > > > > Hello Sumit, > > > > > Thank you for reworking the patches and addressing all of my review > > > comments. I am happy with the latest version of these and consider them > > > ready to go. I plan to leave them in Gerrit for another week to give > > > extra time for other potential reviewers to have a look and comment. > > > > > > > Thanks for your review. > > > To everyone on the list: Please raise any concerns you may have about > > > these patches in the coming week. If I don't hear anything by 29th > > > January 2020, I will merge these patches. > > > > > @Sumit: One of the next actions for this patch stack would be to have > > > some level of testing in the CI system to detect any potential > > > regressions. We (at Arm) can quite easily add a few build tests but then > > > testing the software stack on QEMU is a bit more involved for various > > > reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, > > > ...) so this might have to wait for some time. > > > > > > > Okay, will wait for CI testing. > > > -Sumit > > > Regards, > > > Sandrine > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

2
1
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Raghupathy Krishnamurthy

Thanks Soby, Sumit, Sandrine and Joakim! Agree with Joakim/Soby about encrypt then sign and sign then encrypt being okay, when authenticated encryption is used. I'd like to point out again, that the link provided by Sumit talks about encrypt-then-sign and sign-then-encrypt, using asymmetric encryption and asymmetric signing only, and as Joakim rightly pointed out(and as i did in my earlier email), does not necessarily apply here. They are not talking about symmetric encryption with asymmetric signing, which is what PSA-TBFU and TBBR are talking about. I usually don't like signing plain text and encrypt(not authenticated encryption, just encryption like aes-cbc etc) plain text due to https://moxie.org/blog/the-cryptographic-doom-principle/(written by the creator of the the WhatsApp end-to-end encryption protocol, this applies to symmetric encryption and symmetric signing/MAC's, but it applies to any ciphertext that is decrypted without verifying its integrity). If we were to sign the plain text then encrypt the firmware, the size of the encrypted file needs to be integrity protected as well, not just the bit that indicates that the file is encrypted. If not, when we decrypt the firmware image, we can perform some creative attacks on symmetric encryption, as specified in the link, and requires careful implementation of error handling/reporting on decryption errors. I also like Soby's approach of having an attribute EP_ENCRYPTED and relying on platform_pre_image_load() and platform_post_image_load() to do the decryption and that addresses my non-spec related concerns. It also allows for decrypt-then-authenticate(which i wouldn't use) and authenticate-then-decrypt. It also puts the attribute that indicates firmware encryption in the image descriptor table which is integrity protected by virtue of it being in the ROM or being signed, and also leaves the FIP layer unaltered. Thanks -Raghu On January 27, 2020 at 6:42 AM, Soby Mathew <Soby.Mathew(a)arm.com> wrote: On 27/01/2020 12:34, Joakim Bech via TF-A wrote: on raw binaries are there so we can be sure that we're loading unmodified firmware coming from the one owning a private key corresponding to the public key hardcoded into the device (or via a hash of the public key). I think we all can agree OK, I have finally managed to catch up on this thread. Apologies for the delayed response. As Joakim mentions, I think both the mentioned cases ie. encrypt plain text -> sign and sign -> encrypt are valid and it depend on the threat model and security requirement. I have had a brief look at the patch stack and coupling the feature to the FIP does not seem like a good idea to me( + the added complexity protecting the ToC). Currently meta data of the firmware images is passed OOB via the `bl_mem_params_node_t` descriptor to the BL images whereas this patch breaks that convention. It is better to follow the set convention and avoid dependency on FIP format (btw platforms need not use FIP format and can use other packaging formats). The iv data to decrypt seems to be prepended to the encrypted file in the fip which is making custom manipulations file pointer manipulations which is raising some red flags. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/8/drive… IMO, this should not visible to be FIP driver. I am not sure of the best practice for sending iv data but if it has to be prepended, it should be FIP agnostic. The TBBR assumes a single owner for all images whereas the TBFU supercedes this spec by allowing multiple owners for different images. We are in the process of enhancing the CoT for different Root of Trusts for different images and there needs to be capability to encrypt with different keys for different images based on ownership. The current implementation has some limitations like introducing a platform API invocation within the driver layer to get the single key which is not ideal IMO. I haven't fully flushed out my ideas, but thoughts are based on enhancements done by Masahiro for adding decompression support for BL images. See https://github.com/ARM-software/arm-trusted-firmware/pull/1224 . Basically, this patch series allows any filter to be setup before/after the images are loaded. It relies on pre-load and post load hooks which are platform specific to perform the filter operation. So, if a new image attribute `EP_ENCRYPTED` is added ep_info_exp.h, then BL2 needs to do the following in bl2_plat_handle_pre_image_load() { if EP_ENCRYPTED is set : load the image to SRAM and decrypt using crypto module } This will cater for `decrypt-then-authenticate` flow. The fip_tool no longer needs to be aware of encryption and the build process just needs to pipe the encrypted binaries to the fip_tool. Similarly if `authenticate-then-decrypt` needs to be supported, then all that the platform needs to do is implement decrypt in bl2_plat_handle_post_image_load(). The platform can now use different keys to use for different BL images if it needs to do so. Some usecases require the firmware images to be re-encrypted using HUK after firmware update (aka firmware binding) and following this design will allow this to be done as well. Best Regards Soby Mathew

6 years, 1 month

1
0
0 0

Re: [TF-A] What prevents BL1 FWU SMC's from being called on multiple cores ?

by Soby Mathew

On 24/01/2020 20:20, Raghupathy Krishnamurthy via TF-A wrote: > It appears that the BL1 FWU SMC's are written under the assumption that only one core can call the SMC's at any given time but i don't see anything enforcing it. What prevent's this ? > > > -Raghu > Hi Raghu The BL1 itself is uni-processor [except the early assembly code which differentiates primary core from secondaries]. Hence it makes no attempt to provide protection for the SMCs from multiple cores. Best Regards Soby Mathew

6 years, 1 month

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Raghupathy Krishnamurthy

Thanks Sumit. We are beginning to go off topic and i don't think you and i agree entirely. I'll lay out my concerns, to see if others on the list share my opinion/concerns, so i hope you can let them respond. If nobody else shares my concerns or responds, the patch will be merged soon anyway, so no point dragging this out :) I apologize for the long email. I don't know how to keep this topic short and detailed. :) Here are my concerns: 1) The patch set claims to implement R060_TBBR_FUNCTION from the TBBR spec. I don't agree with this. The patch is using authenticated encryption(which does provide confidentiality) but is different from implementing firmware encryption as described in the TBBR(and PSA) in my view. If we are implementing R060_TBBR_FUNCTION, in my view, this should be implemented such that the firmware is first encrypted(symmetric), and the encrypted firmware should be asymmetrically signed(as per PSA). Also, the order for verification should be asymmetric signature verification and then decryption(symmetric). In this patch, plain text firmware is asymmetrically signed, plain text firmware is encrypted and authenticated with a symmetric key using authenticated encryption. The order for verification in this patch is authenticate and decrypt using the symmetric key and THEN asymmetric signature verification on the decryted(and now plain text) firmware. The ordering of verification and decryption are subtly different from what the spec(TBBR and PSA) expects. Security does not *seem* to be broken as far as i can tell, but the patch is not strictly an implementation of the spec, as it claims. This can throw off people reading the spec and trying to match code to spec. This is not good when someone wants to audit and gain confidence in the security of the implementation. At a minimum, we need someone writing the spec to address this. 2) The TBBR spec does not talk about authenticated encryption of firmware and only talks about encryption of firmware. It also does not specify if the encrypted firmware needs to be signed or the plain text need to be signed. This is critical detail. It also does not specify the order in which encryption and signing, decryption and verification must be done. These are important details and need to be addressed explicitly(perhaps in both TBBR and PSA). Use of authenticated encryption needs to be explicitly discussed as well. 3) TBBR specifies that the TOC(table of contents) *may* be authenticated. The TOC contains bits that dictate security policy, in this case, if the firmware is encrypted or not. I don't think it is good to consume security policy from unauthenticated data. In my view, this information must be in the signed image manifest(certificate in ATF) since an attacker can at-least cause simple DoS attacks by flipping bits in the FIP header, undetected. If the bit is flipped, a firmware image going out to a million devices may not boot, since an attacker decided to flip a bit, and signature verification fails, since the boot loader decided not decrypt the firmware based in an unsigned bit of information. PSA appears to have a better approach and makes no provision such data to be outside the image manifest, which is always signed. 4) This last one is a matter of opinion and can live with the current design. The FIP layer is now aware of the crypto module. FIP has also become coupled with authenticated encryption(If we do this, why not have the FIP layer call auth_mod_verify_img() and why stop at cyrpto_mod_auth_decrypt()) . FIP is security aware. I'd like to keep things the way they are today, where IO and security are separate modules and glued together by another layer(load_auth_image() for example). This is cleaner in my view since security policy(should i decrypt? should i verify signatures? should i apply any security at all?) is separate from IO. Thanks Raghu On January 24, 2020 at 3:06 AM, Sumit Garg <sumit.garg(a)linaro.org> wrote: On Fri, 24 Jan 2020 at 04:02, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: I also just realized that both the TBBR and ARM PSA only talk about encryption of the image, and not authenticated encryption. The guarantees provided by both are completely different. Your review(https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/) talks about the requirement R060_TBBR_FUNCTION being implemented, which is technically not true(and potentially misleading). We must make a note of this difference and use the appropriate terminology, without mixing the two, in the documentation, commit messages, source code comments and error prints. The tool is also called 'encrypt_fw ' but should maybe be named appropriately to indicate it is doing authenticated encryption. I wouldn't call it misleading. Since firmware encryption feature essentially provides confidentiality protection and authenticated encryption is the type of crypto algorithm which we have used to implement it. BTW, ARM PSA(file:///home/raghu/repos/fvp/DEN0072-PSA_TBFU_1-0-REL.pdf) expects that the image manifest(X509 certificate) contain the hash of the ENCRYPTED image(Table 2 and as described in my answer to your question "How would this ensure integrity of ciphertext"). The TBBR spec completely misses this fact, and is a crucial detail if we only implement encryption(as opposed to authenticated encryption).Build_macros.mk, in your change, passes the un-encrypted image to cert-tool. You can get away with it in your implementation, since you are using authenticated encryption, not if you were only implementing firmware encryption. I have already highlighted the issue with signing the ciphertext in my previous reply which deviates from security properties provided by signature verification of plain firmware. So I think we need to revisit ARM PSA TBFU spec. -Sumit Is it possible for somebody from ARM to have the TBBR spec updated to reflect this? Also perhaps talk to the spec writers about incorporating authenticated encryption into TBBR and PSA? This patch set is somewhat trailblazing in this regard. -Raghu On January 23, 2020 at 12:08 PM, Raghupathy Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: Hi Sumit, Thanks for your response. So firstly I would suggest you to revisit TBBR spec [1], [RK] I'm very familiar with the TBBR spec and the requirements. Note that not all SoC's adhere perfectly to the TBBR spec, since it does not apply to devices in all market segments. However, these devices do use arm trusted firmware and TBBR CoT in a slightly modified form, which is still perfectly valid. Also, the TBBR spec can be changed if required :) Why would one use authenticated decryption only to establish TBBR Chain of Trust providing device the capability to self sign its firmware? [RK] Fair point. However, you may have devices that don't have the processing power or hardware budget or cost factors(paying for HSM's to store private asymmetric keys), to implement asymmetric verification, in which case using authenticated decryption to verify firmware authenticity and integrity is perfectly valid. The attacks on devices that use symmetric keys to verify firmware authenticity and integrity are usually related to exploiting firmware flaws that leak the key or insiders leaking keys, but that is a different problem and requires different solutions. Fundamentally, there is nothing wrong with using symmetric keys for this purpose, so long as the key is well protected. Also note, security requirements and guarantees are different for different systems. The risk is taken by the system designer and should not be imposed by framework code. I don't advocate doing this but it is an option that your implementation does not provide(and perhaps rightly so). How would this ensure integrity of ciphertext? [RK] You sign the ciphertext. In your design, you pass bl31_enc.bin to cert_tool to sign. You don't decrypt the encrypted cipher text until you have verified the asymmetric signature(which provides integrity). As far as signature verification is concerned, whether you sign the plain text or ciphertext is immaterial, since you are simply verifying that the absolute bits you loaded have not been modified(assuming you use a secure signature scheme). Have a look at some defective sign and encrypt techniques here [2] [RK] Again, very familiar with [2]. In the S/MIME case, you have multiple parties. With secure boot, you have one party, effectively verifying its own messages across time. There is only one key used to verify signatures. 1.1 and 1.2 does not apply. Also you are encrypting and signing with completely different keys and algorithms. Section 1.2 applies when you use RSA/El-gamal encryption. Here you use symmetric encryption and asymmetric signing. Why would one not use TBBR CoT here? [RK] see above. Not all systems are designed equal. and why would one like to hardcode in a device during provisioning to boot only either an encrypted or a plain firmware image? [RK] Why would you not? You typically want to have the same security policy for a class of devices and not be modifiable by an attacker. It isn't common for the same class of devices to use encrypted firmware some times, and un-encrypted firmware other times. If it is common, there is no problem with setting the bit in the FIP header, as long as verified boot is mandatory. The only concern(as my original email said) is the coupling of the FIP layer and the crypto module, in the implementation. I still don't like that fact that the bit saying the file is encrypted is not signed and this may require talking to the TBBR spec writers. Page 22 of the TBBR spec calls out ToC as "Trusted Table of Contents". The FIP header cannot be "trusted", if it is not in ROM or its integrity is verified by some means! R010_TBBR_TOC should perhaps be mandatory then. Also see R080_TBBR_TOC that says the TOC MUST be ROM'ed or tied by hardware in readable registers. This requirement seems contradictory to R010_TBBR_TOC, given that the FIP header(TOC) is copied from mutable NVM by ROM or some boot stage and then ROM'd or loaded into registers. I may be misunderstanding R080_TBBR_TOC, but i'd interpret it as the TOC(FIP header in ATF implementation of TBBR) as being in ROM or integrity verified. How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? [RK]TBBR CoT is equipped to do this. The table is defined on a per image basis. If you are really paranoid about authentication of FIP header... [RK] I don't mean to pontificate but there are real world customers buying real hardware, running ATF code, who care about such details and ask about such things routinely. It is not just me being paranoid and is definitely not a minor matter to think of such details. We should discuss more and consider the implications of R080_TBBR_TOC and R010_TBBR_TOC, perhaps on a different thread, without blocking your code review. Can somebody from ARM clarify these requirements with the spec writers? Thanks -Raghu On January 23, 2020 at 12:38 AM, Sumit Garg <sumit.garg(a)linaro.org> wrote: Hi Raghu, I guess you have completely misunderstood this feature. This is an optional feature which allows to load encrypted FIP payloads using authenticated decryption which MUST be used along with signature verification (or TBBR CoT). So firstly I would suggest you to revisit TBBR spec [1], especially requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: Hello, The patch stack looks good. The only comment i have is that the FIP layer has now become security aware and supports authenticated decryption(only). This is a deviation from the secure/signed/verified boot design, where we use the TBBR COT to dictate the security operations on the file. This is nice, because file IO is decoupled from the security policy. This may be a big deviation(i apologize if this was considered and shot down for some other reason), but it may be worthwhile to consider making authenticated decryption a part of the authentication framework as opposed to coupling it with the FIP layer. It looks like you have mixed both TBBR CoT and this authenticated decryption feature. They both are completely different and rather complement each other where TBBR CoT establishes secure/signed/verified boot and this authenticated decryption feature provides confidentiality protection for FIP payloads. At a high level, this would mean adding a new authentication method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having the platform specify that the image is using authenticated encryption in the TBBR COT. Why would one use authenticated decryption only to establish TBBR Chain of Trust providing device the capability to self sign its firmwares? We must use signature verification for TBBR CoT (see section: 2.1 Authentication of Code Images by Certificate in TBBR spec [1]). The authentication framework is already well designed and well equipped to handle these types of extensions. 1) This would make the change simpler, since you would not require changes to the FIP tool and the FIP layer. 2) This would also allow for future cases where a platform may want to only encrypt the file and use public key authentication on the encrypted file(for ex. the soc does not have a crypto accelerator for aes-gcm but only for AES and public key verification, for whatever reason). How would this ensure integrity of ciphertext? This approach may be vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag as part of AES-GCM provides integrity protection for ciphertext. 3) This would let you choose the order in which you want to do the authenticated decryption(or just decryption) and signature verification, if you use both, one or the other. Have a look at some defective sign and encrypt techniques here [2]. The order can't be any arbitrary one, we need to be careful about this. One other thing i'm not entirely comfortable with is that the flag indicating if there are encrypted files or not in the FIP, is in the *unsigned* portion of the FIP header. An attacker could simply flip bits that dictate security policy in the header and avoid detection(in this case, the indication that the file needs authenticated decryption). If a platform only uses authenticated encryption, but not verified boot, an attacker could flip the bit in the FIP header and have any image loaded on the platform. Why would one not use TBBR CoT here? If authenticated encryption cannot be used without verified boot(which requires build time flags), having a flag to indicate that there are encrypted files in the FIP header is moot, since this can come at build time through the TBBR COT. In any case, it seems like the security policy that firmware images need to be decrypted or authenticated with authenticated decryption, seems like a firmware build time or manufacturing time decision(perhaps a bit set in the e-fuses). Again you are confusing TBBR CoT with authenticated decryption feature. And why would one like to hardcode in a device during provisioning to boot only either an encrypted or a plain firmware image? There seems to be no benefit to having a flag in the FIP header. How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? Otherwise, I cant think of any attacks due to this and it may be completely okay, but generally, consuming data that dictates security policy/operations before verifying its integrity seems like a recipe for disaster. If you are really paranoid about authentication of FIP header then you should look at implementing optional requirement: R010_TBBR_TOC as per TBBR spec [1]. [1] https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requiremen… [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html -Sumit -Raghu On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: Hi Sandrine, On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux <Sandrine.Bailleux(a)arm.com> wrote: Hello Sumit, Thank you for reworking the patches and addressing all of my review comments. I am happy with the latest version of these and consider them ready to go. I plan to leave them in Gerrit for another week to give extra time for other potential reviewers to have a look and comment. Thanks for your review. To everyone on the list: Please raise any concerns you may have about these patches in the coming week. If I don't hear anything by 29th January 2020, I will merge these patches. @Sumit: One of the next actions for this patch stack would be to have some level of testing in the CI system to detect any potential regressions. We (at Arm) can quite easily add a few build tests but then testing the software stack on QEMU is a bit more involved for various reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, ...) so this might have to wait for some time. Okay, will wait for CI testing. -Sumit Regards, Sandrine -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

3
2
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Soby Mathew

On 27/01/2020 12:34, Joakim Bech via TF-A wrote: > on raw binaries are there so we can be sure that > we're loading unmodified firmware coming from the one owning a private key > corresponding to the public key hardcoded into the device (or via a hash of > the public key). I think we all can agree OK, I have finally managed to catch up on this thread. Apologies for the delayed response. As Joakim mentions, I think both the mentioned cases ie. encrypt plain text -> sign and sign -> encrypt are valid and it depend on the threat model and security requirement. I have had a brief look at the patch stack and coupling the feature to the FIP does not seem like a good idea to me( + the added complexity protecting the ToC). Currently meta data of the firmware images is passed OOB via the `bl_mem_params_node_t` descriptor to the BL images whereas this patch breaks that convention. It is better to follow the set convention and avoid dependency on FIP format (btw platforms need not use FIP format and can use other packaging formats). The iv data to decrypt seems to be prepended to the encrypted file in the fip which is making custom manipulations file pointer manipulations which is raising some red flags. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/8/drive… IMO, this should not visible to be FIP driver. I am not sure of the best practice for sending iv data but if it has to be prepended, it should be FIP agnostic. The TBBR assumes a single owner for all images whereas the TBFU supercedes this spec by allowing multiple owners for different images. We are in the process of enhancing the CoT for different Root of Trusts for different images and there needs to be capability to encrypt with different keys for different images based on ownership. The current implementation has some limitations like introducing a platform API invocation within the driver layer to get the single key which is not ideal IMO. I haven't fully flushed out my ideas, but thoughts are based on enhancements done by Masahiro for adding decompression support for BL images. See https://github.com/ARM-software/arm-trusted-firmware/pull/1224 . Basically, this patch series allows any filter to be setup before/after the images are loaded. It relies on pre-load and post load hooks which are platform specific to perform the filter operation. So, if a new image attribute `EP_ENCRYPTED` is added ep_info_exp.h, then BL2 needs to do the following in bl2_plat_handle_pre_image_load() { if EP_ENCRYPTED is set : load the image to SRAM and decrypt using crypto module } This will cater for `decrypt-then-authenticate` flow. The fip_tool no longer needs to be aware of encryption and the build process just needs to pipe the encrypted binaries to the fip_tool. Similarly if `authenticate-then-decrypt` needs to be supported, then all that the platform needs to do is implement decrypt in bl2_plat_handle_post_image_load(). The platform can now use different keys to use for different BL images if it needs to do so. Some usecases require the firmware images to be re-encrypted using HUK after firmware update (aka firmware binding) and following this design will allow this to be done as well. Best Regards Soby Mathew

6 years, 1 month

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Sandrine Bailleux

On Mon, 2020-01-27 at 12:04 +0000, Sandrine Bailleux via TF-A wrote: > I share this concern. I was actually surprised to see that the TBBR > specification advocates putting this security policy bit in the > unencrypted part of the FIP, I do not know the rationale for that. Sorry, I meant: in the *unsigned* part of the FIP. This bit itself cannot be encrypted, as it indicates how to decrypt data!

6 years, 1 month

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Sandrine Bailleux

Hi, On Fri, 2020-01-24 at 18:39 +0000, Raghupathy Krishnamurthy via TF-A wrote: > Here are my concerns: > 1) The patch set claims to implement R060_TBBR_FUNCTION from the TBBR > spec. I don't agree with this. The patch is using authenticated > encryption(which does provide confidentiality) but is different from > implementing firmware encryption as described in the TBBR(and PSA) in > my view. If we are implementing R060_TBBR_FUNCTION, in my view, this > should be implemented such that the firmware is first > encrypted(symmetric), and the encrypted firmware should be > asymmetrically signed(as per PSA). Also, the order for verification > should be asymmetric signature verification and then > decryption(symmetric). In this patch, plain text firmware is > asymmetrically signed, plain text firmware is encrypted and > authenticated with a symmetric key using authenticated encryption. > The order for verification in this patch is authenticate and decrypt > using the symmetric key and THEN asymmetric signature verification on > the decryted(and now plain text) firmware. The ordering of > verification and decryption are subtly different from what the > spec(TBBR and PSA) expects. Security does not *seem* to be broken as > far as i can tell, but the patch is not strictly an implementation of > the spec, as it claims. This can throw off people reading the spec > and trying to match code to spec. This is not good when someone wants > to audit and gain confidence in the security of the implementation. > At a minimum, we need someone writing the spec to address this. I do not have a strong opinion on this one. As I mentioned at the start of this email thread, I am quite new to the concept of authenticated decryption and naively thought this would not differ too much from using decryption + signature verification separately. However, if these are fundamentally different things like you say, I get your point and I too am worried about the confusion this could create. > 2) The TBBR spec does not talk about authenticated encryption of > firmware and only talks about encryption of firmware. It also does > not specify if the encrypted firmware needs to be signed or the plain > text need to be signed. This is critical detail. It also does not > specify the order in which encryption and signing, decryption and > verification must be done. These are important details and need to be > addressed explicitly(perhaps in both TBBR and PSA). Use of > authenticated encryption needs to be explicitly discussed as well. TBBR is quite an old specification and it is unlikely that it will ever be updated. PSA-TBFU is meant to supersede it so I think any update/clarification/addition would only apply to TBFU. I agree that it would be good for PSA-TBFU to provide some guidance around encryption and signature together, in which order they should be done and what security properties they bring together. I can raise this to the PSA architects. > 3) TBBR specifies that the TOC(table of contents) *may* be > authenticated. The TOC contains bits that dictate security policy, in > this case, if the firmware is encrypted or not. I don't think it is > good to consume security policy from unauthenticated data. In my > view, this information must be in the signed image > manifest(certificate in ATF) since an attacker can at-least cause > simple DoS attacks by flipping bits in the FIP header, undetected. If > the bit is flipped, a firmware image going out to a million devices > may not boot, since an attacker decided to flip a bit, and signature > verification fails, since the boot loader decided not decrypt the > firmware based in an unsigned bit of information. PSA appears to have > a better approach and makes no provision such data to be outside the > image manifest, which is always signed. I share this concern. I was actually surprised to see that the TBBR specification advocates putting this security policy bit in the unencrypted part of the FIP, I do not know the rationale for that. Given that TBBR will be deprecated in the future, I wonder whether it would be better to adopt PSA's approach here and move this security policy bit in the signed part of the FIP. This will make this part of the implementation non-TBBR compliant but again, I don't see that as a big concern, as we should look at PSA-TBFU as the future and not worry too much about TBBR if we have good reasons to diverge. > 4) This last one is a matter of opinion and can live with the current > design. The FIP layer is now aware of the crypto module. FIP has also > become coupled with authenticated encryption(If we do this, why not > have the FIP layer call auth_mod_verify_img() and why stop at > cyrpto_mod_auth_decrypt()) . FIP is security aware. I'd like to keep > things the way they are today, where IO and security are separate > modules and glued together by another layer(load_auth_image() for > example). This is cleaner in my view since security policy(should i > decrypt? should i verify signatures? should i apply any security at > all?) is separate from IO. I agree with you. I too found it more elegant and cleaner to have the FIP layer and crypto layer as 2 independent modules. I too feel slightly uncomfortable about introducing such a dependency. But I could not think of a way to avoid it while keeping the security policy bit in the FIP ToC header. That said, if the latter is something we're considering to redesign then we might be able to remove this dependency and keep the design as it is. Regards, Sandrine

6 years, 1 month

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Sumit Garg

On Fri, 24 Jan 2020 at 04:02, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: > > I also just realized that both the TBBR and ARM PSA only talk about encryption of the image, and not authenticated encryption. The guarantees provided by both are completely different. Your review(https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/) talks about the requirement R060_TBBR_FUNCTION being implemented, which is technically not true(and potentially misleading). We must make a note of this difference and use the appropriate terminology, without mixing the two, in the documentation, commit messages, source code comments and error prints. The tool is also called 'encrypt_fw ' but should maybe be named appropriately to indicate it is doing authenticated encryption. I wouldn't call it misleading. Since firmware encryption feature essentially provides confidentiality protection and authenticated encryption is the type of crypto algorithm which we have used to implement it. > > BTW, ARM PSA(file:///home/raghu/repos/fvp/DEN0072-PSA_TBFU_1-0-REL.pdf) expects that the image manifest(X509 certificate) contain the hash of the ENCRYPTED image(Table 2 and as described in my answer to your question "How would this ensure integrity of ciphertext"). The TBBR spec completely misses this fact, and is a crucial detail if we only implement encryption(as opposed to authenticated encryption).Build_macros.mk, in your change, passes the un-encrypted image to cert-tool. You can get away with it in your implementation, since you are using authenticated encryption, not if you were only implementing firmware encryption. I have already highlighted the issue with signing the ciphertext in my previous reply which deviates from security properties provided by signature verification of plain firmware. So I think we need to revisit ARM PSA TBFU spec. -Sumit > > Is it possible for somebody from ARM to have the TBBR spec updated to reflect this? Also perhaps talk to the spec writers about incorporating authenticated encryption into TBBR and PSA? This patch set is somewhat trailblazing in this regard. > > -Raghu > > > On January 23, 2020 at 12:08 PM, Raghupathy Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Sumit, > > > Thanks for your response. > > > So firstly I would suggest you to revisit TBBR spec [1], > > > > [RK] I'm very familiar with the TBBR spec and the requirements. Note that not all SoC's adhere perfectly to the TBBR spec, since it does not apply to devices in all market segments. However, these devices do use arm trusted firmware and TBBR CoT in a slightly modified form, which is still perfectly valid. Also, the TBBR spec can be changed if required :) > > > Why would one use authenticated decryption only to establish TBBR > > Chain of Trust providing device the capability to self sign its firmware? > > [RK] Fair point. However, you may have devices that don't have the processing power or hardware budget or cost factors(paying for HSM's to store private asymmetric keys), to implement asymmetric verification, in which case using authenticated decryption to verify firmware authenticity and integrity is perfectly valid. The attacks on devices that use symmetric keys to verify firmware authenticity and integrity are usually related to exploiting firmware flaws that leak the key or insiders leaking keys, but that is a different problem and requires different solutions. Fundamentally, there is nothing wrong with using symmetric keys for this purpose, so long as the key is well protected. Also note, security requirements and guarantees are different for different systems. The risk is taken by the system designer and should not be imposed by framework code. I don't advocate doing this but it is an option that your implementation does not provide(and perhaps rightly so). > > > How would this ensure integrity of ciphertext? > > > > [RK] You sign the ciphertext. In your design, you pass bl31_enc.bin to cert_tool to sign. You don't decrypt the encrypted cipher text until you have verified the asymmetric signature(which provides integrity). As far as signature verification is concerned, whether you sign the plain text or ciphertext is immaterial, since you are simply verifying that the absolute bits you loaded have not been modified(assuming you use a secure signature scheme). > > > Have a look at some defective sign and encrypt techniques here [2] > > > > [RK] Again, very familiar with [2]. In the S/MIME case, you have multiple parties. With secure boot, you have one party, effectively verifying its own messages across time. There is only one key used to verify signatures. 1.1 and 1.2 does not apply. Also you are encrypting and signing with completely different keys and algorithms. Section 1.2 applies when you use RSA/El-gamal encryption. Here you use symmetric encryption and asymmetric signing. > > > Why would one not use TBBR CoT here? > > > > [RK] see above. Not all systems are designed equal. > > > > and why would one like to hardcode in a device during > > provisioning to boot only either an encrypted or a plain firmware > image? > > > [RK] Why would you not? You typically want to have the same security policy for a class of devices and not be modifiable by an attacker. It isn't common for the same class of devices to use encrypted firmware some times, and un-encrypted firmware other times. If it is common, there is no problem with setting the bit in the FIP header, as long as verified boot is mandatory. The only concern(as my original email said) is the coupling of the FIP layer and the crypto module, in the implementation. I still don't like that fact that the bit saying the file is encrypted is not signed and this may require talking to the TBBR spec writers. Page 22 of the TBBR spec calls out ToC as "Trusted Table of Contents". The FIP header cannot be "trusted", if it is not in ROM or its integrity is verified by some means! R010_TBBR_TOC should perhaps be mandatory then. Also see R080_TBBR_TOC that says the TOC MUST be ROM'ed or tied by hardware in readable registers. This requirement seems contradictory to R010_TBBR_TOC, given that the FIP header(TOC) is copied from mutable NVM by ROM or some boot stage and then ROM'd or loaded into registers. I may be misunderstanding R080_TBBR_TOC, but i'd interpret it as the TOC(FIP header in ATF implementation of TBBR) as being in ROM or integrity verified. > > > How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? > > > > [RK]TBBR CoT is equipped to do this. The table is defined on a per image basis. > > > If you are really paranoid about authentication of FIP header... > > [RK] I don't mean to pontificate but there are real world customers buying real hardware, running ATF code, who care about such details and ask about such things routinely. It is not just me being paranoid and is definitely not a minor matter to think of such details. We should discuss more and consider the implications of R080_TBBR_TOC and R010_TBBR_TOC, perhaps on a different thread, without blocking your code review. Can somebody from ARM clarify these requirements with the spec writers? > > > Thanks > -Raghu > > > On January 23, 2020 at 12:38 AM, Sumit Garg <sumit.garg(a)linaro.org> wrote: > > > Hi Raghu, > > I guess you have completely misunderstood this feature. This is an > optional feature which allows to load encrypted FIP payloads using > authenticated decryption which MUST be used along with signature > verification (or TBBR CoT). > > So firstly I would suggest you to revisit TBBR spec [1], especially > requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. > > On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy > <raghu.ncstate(a)icloud.com> wrote: > > > > Hello, > > > The patch stack looks good. The only comment i have is that the FIP layer has now become security aware and supports authenticated decryption(only). This is a deviation from the secure/signed/verified boot design, where we use the TBBR COT to dictate the security operations on the file. This is nice, because file IO is decoupled from the security policy. This may be a big deviation(i apologize if this was considered and shot down for some other reason), but it may be worthwhile to consider making authenticated decryption a part of the authentication framework as opposed to coupling it with the FIP layer. > > It looks like you have mixed both TBBR CoT and this authenticated > decryption feature. They both are completely different and rather > complement each other where TBBR CoT establishes > secure/signed/verified boot and this authenticated decryption feature > provides confidentiality protection for FIP payloads. > > > At a high level, this would mean adding a new authentication method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having the platform specify that the image is using authenticated encryption in the TBBR COT. > > Why would one use authenticated decryption only to establish TBBR > Chain of Trust providing device the capability to self sign its > firmwares? We must use signature verification for TBBR CoT (see > section: 2.1 Authentication of Code Images by Certificate in TBBR spec > [1]). > > > The authentication framework is already well designed and well equipped to handle these types of extensions. > 1) This would make the change simpler, since you would not require changes to the FIP tool and the FIP layer. > 2) This would also allow for future cases where a platform may want to only encrypt the file and use public key authentication on the encrypted file(for ex. the soc does not have a crypto accelerator for aes-gcm but only for AES and public key verification, for whatever reason). > > How would this ensure integrity of ciphertext? This approach may be > vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag as > part of AES-GCM provides integrity protection for ciphertext. > > > 3) This would let you choose the order in which you want to do the authenticated decryption(or just decryption) and signature verification, if you use both, one or the other. > > > > Have a look at some defective sign and encrypt techniques here [2]. > The order can't be any arbitrary one, we need to be careful about > this. > > > One other thing i'm not entirely comfortable with is that the flag indicating if there are encrypted files or not in the FIP, is in the *unsigned* portion of the FIP header. An attacker could simply flip bits that dictate security policy in the header and avoid detection(in this case, the indication that the file needs authenticated decryption). If a platform only uses authenticated encryption, but not verified boot, an attacker could flip the bit in the FIP header and have any image loaded on the platform. > > Why would one not use TBBR CoT here? > > > If authenticated encryption cannot be used without verified boot(which requires build time flags), having a flag to indicate that there are encrypted files in the FIP header is moot, since this can come at build time through the TBBR COT. In any case, it seems like the security policy that firmware images need to be decrypted or authenticated with authenticated decryption, seems like a firmware build time or manufacturing time decision(perhaps a bit set in the e-fuses). > > Again you are confusing TBBR CoT with authenticated decryption > feature. And why would one like to hardcode in a device during > provisioning to boot only either an encrypted or a plain firmware > image? > > > There seems to be no benefit to having a flag in the FIP header. > > How would one handle a case where BL31 is in plain format and BL32 is > in encrypted format? > > > Otherwise, I cant think of any attacks due to this and it may be completely okay, but generally, consuming data that dictates security policy/operations before verifying its integrity seems like a recipe for disaster. > > > > If you are really paranoid about authentication of FIP header then you > should look at implementing optional requirement: R010_TBBR_TOC as per > TBBR spec [1]. > > [1] https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requiremen… > [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html > > -Sumit > > > -Raghu > > > On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > > Hi Sandrine, > > > On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux > <Sandrine.Bailleux(a)arm.com> wrote: > > > > > Hello Sumit, > > > > > Thank you for reworking the patches and addressing all of my review > > > comments. I am happy with the latest version of these and consider them > > > ready to go. I plan to leave them in Gerrit for another week to give > > > extra time for other potential reviewers to have a look and comment. > > > > > > > Thanks for your review. > > > To everyone on the list: Please raise any concerns you may have about > > > these patches in the coming week. If I don't hear anything by 29th > > > January 2020, I will merge these patches. > > > > > @Sumit: One of the next actions for this patch stack would be to have > > > some level of testing in the CI system to detect any potential > > > regressions. We (at Arm) can quite easily add a few build tests but then > > > testing the software stack on QEMU is a bit more involved for various > > > reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, > > > ...) so this might have to wait for some time. > > > > > > > Okay, will wait for CI testing. > > > -Sumit > > > Regards, > > > Sandrine > > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

1
1
0 0

Re: [TF-A] What prevents BL1 FWU SMC's from being called on multiple cores ?

by Raghupathy Krishnamurthy

Never mind. No PSCI SMC's will be available. On January 24, 2020 at 12:20 PM, Raghupathy Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: It appears that the BL1 FWU SMC's are written under the assumption that only one core can call the SMC's at any given time but i don't see anything enforcing it. What prevent's this ? -Raghu -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

1
0
0 0

What prevents BL1 FWU SMC's from being called on multiple cores ?

by Raghupathy Krishnamurthy

It appears that the BL1 FWU SMC's are written under the assumption that only one core can call the SMC's at any given time but i don't see anything enforcing it. What prevent's this ? -Raghu

6 years, 1 month

1
0
0 0

Re: [TF-A] Please revert "Remove RSA PKCS#1 v1.5 support from cert_tool"

by Soby Mathew

On 22/01/2020 12:29, Scott Branden via TF-A wrote: > Please revert the removal of RSA PKCS#1 v1.5 support from cert_tool: > > https://github.com/ARM-software/arm-trusted-firmware/commit/6a415a508ea6ace… > > We have products shipping with such support. I think this problem came > up before when somebody tried removing such support. > They still need to run with the latest yocto codebase. > > Regards, > Scott > Hi Scott, It is untenable for us as maintainers to keep supporting deprecated features in the tree. We need to be able to move the codebase forward. As the commit message says, the RSA PKCS#1.5 support was removed from BL1/BL2 images before this patch, and it no longer made sense to keep the support for just the cert_tool. Seems that you are not using the latest TF-A code for your platform (since PKCS#1.5 is not supported), it does not make sense to pull the latest master just for the tool. So my suggestion would be pin your yocto scripts to a TF-A release that had the support for PKCS#1.5. Best Regards Soby Mathew

6 years, 1 month

2
3
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Raghupathy Krishnamurthy

Hi Sumit, Thanks for your response. >>So firstly I would suggest you to revisit TBBR spec [1], [RK] I'm very familiar with the TBBR spec and the requirements. Note that not all SoC's adhere perfectly to the TBBR spec, since it does not apply to devices in all market segments. However, these devices do use arm trusted firmware and TBBR CoT in a slightly modified form, which is still perfectly valid. Also, the TBBR spec can be changed if required :) >>Why would one use authenticated decryption only to establish TBBR Chain of Trust providing device the capability to self sign its firmware? [RK] Fair point. However, you may have devices that don't have the processing power or hardware budget or cost factors(paying for HSM's to store private asymmetric keys), to implement asymmetric verification, in which case using authenticated decryption to verify firmware authenticity and integrity is perfectly valid. The attacks on devices that use symmetric keys to verify firmware authenticity and integrity are usually related to exploiting firmware flaws that leak the key or insiders leaking keys, but that is a different problem and requires different solutions. Fundamentally, there is nothing wrong with using symmetric keys for this purpose, so long as the key is well protected. Also note, security requirements and guarantees are different for different systems. The risk is taken by the system designer and should not be imposed by framework code. I don't advocate doing this but it is an option that your implementation does not provide(and perhaps rightly so). >>How would this ensure integrity of ciphertext? [RK] You sign the ciphertext. In your design, you pass bl31_enc.bin to cert_tool to sign. You don't decrypt the encrypted cipher text until you have verified the asymmetric signature(which provides integrity). As far as signature verification is concerned, whether you sign the plain text or ciphertext is immaterial, since you are simply verifying that the absolute bits you loaded have not been modified(assuming you use a secure signature scheme). >>Have a look at some defective sign and encrypt techniques here [2] [RK] Again, very familiar with [2]. In the S/MIME case, you have multiple parties. With secure boot, you have one party, effectively verifying its own messages across time. There is only one key used to verify signatures. 1.1 and 1.2 does not apply. Also you are encrypting and signing with completely different keys and algorithms. Section 1.2 applies when you use RSA/El-gamal encryption. Here you use symmetric encryption and asymmetric signing. >>Why would one not use TBBR CoT here? [RK] see above. Not all systems are designed equal. >>and why would one like to hardcode in a device during provisioning to boot only either an encrypted or a plain firmware image? [RK] Why would you not? You typically want to have the same security policy for a class of devices and not be modifiable by an attacker. It isn't common for the same class of devices to use encrypted firmware some times, and un-encrypted firmware other times. If it is common, there is no problem with setting the bit in the FIP header, as long as verified boot is mandatory. The only concern(as my original email said) is the coupling of the FIP layer and the crypto module, in the implementation. I still don't like that fact that the bit saying the file is encrypted is not signed and this may require talking to the TBBR spec writers. Page 22 of the TBBR spec calls out ToC as "Trusted Table of Contents". The FIP header cannot be "trusted", if it is not in ROM or its integrity is verified by some means! R010_TBBR_TOC should perhaps be mandatory then. Also see R080_TBBR_TOC that says the TOC MUST be ROM'ed or tied by hardware in readable registers. This requirement seems contradictory to R010_TBBR_TOC, given that the FIP header(TOC) is copied from mutable NVM by ROM or some boot stage and then ROM'd or loaded into registers. I may be misunderstanding R080_TBBR_TOC, but i'd interpret it as the TOC(FIP header in ATF implementation of TBBR) as being in ROM or integrity verified. >>How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? [RK]TBBR CoT is equipped to do this. The table is defined on a per image basis. >>If you are really paranoid about authentication of FIP header... [RK] I don't mean to pontificate but there are real world customers buying real hardware, running ATF code, who care about such details and ask about such things routinely. It is not just me being paranoid and is definitely not a minor matter to think of such details. We should discuss more and consider the implications of R080_TBBR_TOC and R010_TBBR_TOC, perhaps on a different thread, without blocking your code review. Can somebody from ARM clarify these requirements with the spec writers? Thanks -Raghu On January 23, 2020 at 12:38 AM, Sumit Garg <sumit.garg(a)linaro.org> wrote: Hi Raghu, I guess you have completely misunderstood this feature. This is an optional feature which allows to load encrypted FIP payloads using authenticated decryption which MUST be used along with signature verification (or TBBR CoT). So firstly I would suggest you to revisit TBBR spec [1], especially requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: Hello, The patch stack looks good. The only comment i have is that the FIP layer has now become security aware and supports authenticated decryption(only). This is a deviation from the secure/signed/verified boot design, where we use the TBBR COT to dictate the security operations on the file. This is nice, because file IO is decoupled from the security policy. This may be a big deviation(i apologize if this was considered and shot down for some other reason), but it may be worthwhile to consider making authenticated decryption a part of the authentication framework as opposed to coupling it with the FIP layer. It looks like you have mixed both TBBR CoT and this authenticated decryption feature. They both are completely different and rather complement each other where TBBR CoT establishes secure/signed/verified boot and this authenticated decryption feature provides confidentiality protection for FIP payloads. At a high level, this would mean adding a new authentication method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having the platform specify that the image is using authenticated encryption in the TBBR COT. Why would one use authenticated decryption only to establish TBBR Chain of Trust providing device the capability to self sign its firmwares? We must use signature verification for TBBR CoT (see section: 2.1 Authentication of Code Images by Certificate in TBBR spec [1]). The authentication framework is already well designed and well equipped to handle these types of extensions. 1) This would make the change simpler, since you would not require changes to the FIP tool and the FIP layer. 2) This would also allow for future cases where a platform may want to only encrypt the file and use public key authentication on the encrypted file(for ex. the soc does not have a crypto accelerator for aes-gcm but only for AES and public key verification, for whatever reason). How would this ensure integrity of ciphertext? This approach may be vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag as part of AES-GCM provides integrity protection for ciphertext. 3) This would let you choose the order in which you want to do the authenticated decryption(or just decryption) and signature verification, if you use both, one or the other. Have a look at some defective sign and encrypt techniques here [2]. The order can't be any arbitrary one, we need to be careful about this. One other thing i'm not entirely comfortable with is that the flag indicating if there are encrypted files or not in the FIP, is in the *unsigned* portion of the FIP header. An attacker could simply flip bits that dictate security policy in the header and avoid detection(in this case, the indication that the file needs authenticated decryption). If a platform only uses authenticated encryption, but not verified boot, an attacker could flip the bit in the FIP header and have any image loaded on the platform. Why would one not use TBBR CoT here? If authenticated encryption cannot be used without verified boot(which requires build time flags), having a flag to indicate that there are encrypted files in the FIP header is moot, since this can come at build time through the TBBR COT. In any case, it seems like the security policy that firmware images need to be decrypted or authenticated with authenticated decryption, seems like a firmware build time or manufacturing time decision(perhaps a bit set in the e-fuses). Again you are confusing TBBR CoT with authenticated decryption feature. And why would one like to hardcode in a device during provisioning to boot only either an encrypted or a plain firmware image? There seems to be no benefit to having a flag in the FIP header. How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? Otherwise, I cant think of any attacks due to this and it may be completely okay, but generally, consuming data that dictates security policy/operations before verifying its integrity seems like a recipe for disaster. If you are really paranoid about authentication of FIP header then you should look at implementing optional requirement: R010_TBBR_TOC as per TBBR spec [1]. [1] https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requiremen… [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html -Sumit -Raghu On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: Hi Sandrine, On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux <Sandrine.Bailleux(a)arm.com> wrote: Hello Sumit, Thank you for reworking the patches and addressing all of my review comments. I am happy with the latest version of these and consider them ready to go. I plan to leave them in Gerrit for another week to give extra time for other potential reviewers to have a look and comment. Thanks for your review. To everyone on the list: Please raise any concerns you may have about these patches in the coming week. If I don't hear anything by 29th January 2020, I will merge these patches. @Sumit: One of the next actions for this patch stack would be to have some level of testing in the CI system to detect any potential regressions. We (at Arm) can quite easily add a few build tests but then testing the software stack on QEMU is a bit more involved for various reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, ...) so this might have to wait for some time. Okay, will wait for CI testing. -Sumit Regards, Sandrine -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

2
1
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Raghupathy Krishnamurthy

+tf a list On January 23, 2020 at 2:32 PM, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: I also just realized that both the TBBR and ARM PSA only talk about encryption of the image, and not authenticated encryption. The guarantees provided by both are completely different. Your review(https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/2495/) talks about the requirement R060_TBBR_FUNCTION being implemented, which is technically not true(and potentially misleading). We must make a note of this difference and use the appropriate terminology, without mixing the two, in the documentation, commit messages, source code comments and error prints. The tool is also called 'encrypt_fw ' but should maybe be named appropriately to indicate it is doing authenticated encryption. BTW, ARM PSA(file:///home/raghu/repos/fvp/DEN0072-PSA_TBFU_1-0-REL.pdf) expects that the image manifest(X509 certificate) contain the hash of the ENCRYPTED image(Table 2 and as described in my answer to your question "How would this ensure integrity of ciphertext"). The TBBR spec completely misses this fact, and is a crucial detail if we only implement encryption(as opposed to authenticated encryption).Build_macros.mk, in your change, passes the un-encrypted image to cert-tool. You can get away with it in your implementation, since you are using authenticated encryption, not if you were only implementing firmware encryption. Is it possible for somebody from ARM to have the TBBR spec updated to reflect this? Also perhaps talk to the spec writers about incorporating authenticated encryption into TBBR and PSA? This patch set is somewhat trailblazing in this regard. -Raghu On January 23, 2020 at 12:08 PM, Raghupathy Krishnamurthy via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: Hi Sumit, Thanks for your response. So firstly I would suggest you to revisit TBBR spec [1], [RK] I'm very familiar with the TBBR spec and the requirements. Note that not all SoC's adhere perfectly to the TBBR spec, since it does not apply to devices in all market segments. However, these devices do use arm trusted firmware and TBBR CoT in a slightly modified form, which is still perfectly valid. Also, the TBBR spec can be changed if required :) Why would one use authenticated decryption only to establish TBBR Chain of Trust providing device the capability to self sign its firmware? [RK] Fair point. However, you may have devices that don't have the processing power or hardware budget or cost factors(paying for HSM's to store private asymmetric keys), to implement asymmetric verification, in which case using authenticated decryption to verify firmware authenticity and integrity is perfectly valid. The attacks on devices that use symmetric keys to verify firmware authenticity and integrity are usually related to exploiting firmware flaws that leak the key or insiders leaking keys, but that is a different problem and requires different solutions. Fundamentally, there is nothing wrong with using symmetric keys for this purpose, so long as the key is well protected. Also note, security requirements and guarantees are different for different systems. The risk is taken by the system designer and should not be imposed by framework code. I don't advocate doing this but it is an option that your implementation does not provide(and perhaps rightly so). How would this ensure integrity of ciphertext? [RK] You sign the ciphertext. In your design, you pass bl31_enc.bin to cert_tool to sign. You don't decrypt the encrypted cipher text until you have verified the asymmetric signature(which provides integrity). As far as signature verification is concerned, whether you sign the plain text or ciphertext is immaterial, since you are simply verifying that the absolute bits you loaded have not been modified(assuming you use a secure signature scheme). Have a look at some defective sign and encrypt techniques here [2] [RK] Again, very familiar with [2]. In the S/MIME case, you have multiple parties. With secure boot, you have one party, effectively verifying its own messages across time. There is only one key used to verify signatures. 1.1 and 1.2 does not apply. Also you are encrypting and signing with completely different keys and algorithms. Section 1.2 applies when you use RSA/El-gamal encryption. Here you use symmetric encryption and asymmetric signing. Why would one not use TBBR CoT here? [RK] see above. Not all systems are designed equal. and why would one like to hardcode in a device during provisioning to boot only either an encrypted or a plain firmware image? [RK] Why would you not? You typically want to have the same security policy for a class of devices and not be modifiable by an attacker. It isn't common for the same class of devices to use encrypted firmware some times, and un-encrypted firmware other times. If it is common, there is no problem with setting the bit in the FIP header, as long as verified boot is mandatory. The only concern(as my original email said) is the coupling of the FIP layer and the crypto module, in the implementation. I still don't like that fact that the bit saying the file is encrypted is not signed and this may require talking to the TBBR spec writers. Page 22 of the TBBR spec calls out ToC as "Trusted Table of Contents". The FIP header cannot be "trusted", if it is not in ROM or its integrity is verified by some means! R010_TBBR_TOC should perhaps be mandatory then. Also see R080_TBBR_TOC that says the TOC MUST be ROM'ed or tied by hardware in readable registers. This requirement seems contradictory to R010_TBBR_TOC, given that the FIP header(TOC) is copied from mutable NVM by ROM or some boot stage and then ROM'd or loaded into registers. I may be misunderstanding R080_TBBR_TOC, but i'd interpret it as the TOC(FIP header in ATF implementation of TBBR) as being in ROM or integrity verified. How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? [RK]TBBR CoT is equipped to do this. The table is defined on a per image basis. If you are really paranoid about authentication of FIP header... [RK] I don't mean to pontificate but there are real world customers buying real hardware, running ATF code, who care about such details and ask about such things routinely. It is not just me being paranoid and is definitely not a minor matter to think of such details. We should discuss more and consider the implications of R080_TBBR_TOC and R010_TBBR_TOC, perhaps on a different thread, without blocking your code review. Can somebody from ARM clarify these requirements with the spec writers? Thanks -Raghu On January 23, 2020 at 12:38 AM, Sumit Garg <sumit.garg(a)linaro.org> wrote: Hi Raghu, I guess you have completely misunderstood this feature. This is an optional feature which allows to load encrypted FIP payloads using authenticated decryption which MUST be used along with signature verification (or TBBR CoT). So firstly I would suggest you to revisit TBBR spec [1], especially requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: Hello, The patch stack looks good. The only comment i have is that the FIP layer has now become security aware and supports authenticated decryption(only). This is a deviation from the secure/signed/verified boot design, where we use the TBBR COT to dictate the security operations on the file. This is nice, because file IO is decoupled from the security policy. This may be a big deviation(i apologize if this was considered and shot down for some other reason), but it may be worthwhile to consider making authenticated decryption a part of the authentication framework as opposed to coupling it with the FIP layer. It looks like you have mixed both TBBR CoT and this authenticated decryption feature. They both are completely different and rather complement each other where TBBR CoT establishes secure/signed/verified boot and this authenticated decryption feature provides confidentiality protection for FIP payloads. At a high level, this would mean adding a new authentication method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having the platform specify that the image is using authenticated encryption in the TBBR COT. Why would one use authenticated decryption only to establish TBBR Chain of Trust providing device the capability to self sign its firmwares? We must use signature verification for TBBR CoT (see section: 2.1 Authentication of Code Images by Certificate in TBBR spec [1]). The authentication framework is already well designed and well equipped to handle these types of extensions. 1) This would make the change simpler, since you would not require changes to the FIP tool and the FIP layer. 2) This would also allow for future cases where a platform may want to only encrypt the file and use public key authentication on the encrypted file(for ex. the soc does not have a crypto accelerator for aes-gcm but only for AES and public key verification, for whatever reason). How would this ensure integrity of ciphertext? This approach may be vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag as part of AES-GCM provides integrity protection for ciphertext. 3) This would let you choose the order in which you want to do the authenticated decryption(or just decryption) and signature verification, if you use both, one or the other. Have a look at some defective sign and encrypt techniques here [2]. The order can't be any arbitrary one, we need to be careful about this. One other thing i'm not entirely comfortable with is that the flag indicating if there are encrypted files or not in the FIP, is in the *unsigned* portion of the FIP header. An attacker could simply flip bits that dictate security policy in the header and avoid detection(in this case, the indication that the file needs authenticated decryption). If a platform only uses authenticated encryption, but not verified boot, an attacker could flip the bit in the FIP header and have any image loaded on the platform. Why would one not use TBBR CoT here? If authenticated encryption cannot be used without verified boot(which requires build time flags), having a flag to indicate that there are encrypted files in the FIP header is moot, since this can come at build time through the TBBR COT. In any case, it seems like the security policy that firmware images need to be decrypted or authenticated with authenticated decryption, seems like a firmware build time or manufacturing time decision(perhaps a bit set in the e-fuses). Again you are confusing TBBR CoT with authenticated decryption feature. And why would one like to hardcode in a device during provisioning to boot only either an encrypted or a plain firmware image? There seems to be no benefit to having a flag in the FIP header. How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? Otherwise, I cant think of any attacks due to this and it may be completely okay, but generally, consuming data that dictates security policy/operations before verifying its integrity seems like a recipe for disaster. If you are really paranoid about authentication of FIP header then you should look at implementing optional requirement: R010_TBBR_TOC as per TBBR spec [1]. [1] https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requiremen… [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html -Sumit -Raghu On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: Hi Sandrine, On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux <Sandrine.Bailleux(a)arm.com> wrote: Hello Sumit, Thank you for reworking the patches and addressing all of my review comments. I am happy with the latest version of these and consider them ready to go. I plan to leave them in Gerrit for another week to give extra time for other potential reviewers to have a look and comment. Thanks for your review. To everyone on the list: Please raise any concerns you may have about these patches in the coming week. If I don't hear anything by 29th January 2020, I will merge these patches. @Sumit: One of the next actions for this patch stack would be to have some level of testing in the CI system to detect any potential regressions. We (at Arm) can quite easily add a few build tests but then testing the software stack on QEMU is a bit more involved for various reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, ...) so this might have to wait for some time. Okay, will wait for CI testing. -Sumit Regards, Sandrine -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Sumit Garg

Hi Raghu, I guess you have completely misunderstood this feature. This is an optional feature which allows to load encrypted FIP payloads using authenticated decryption which MUST be used along with signature verification (or TBBR CoT). So firstly I would suggest you to revisit TBBR spec [1], especially requirements: R040_TBBR_TOC, R060_TBBR_FUNCTION etc. On Thu, 23 Jan 2020 at 00:14, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: > > Hello, > > The patch stack looks good. The only comment i have is that the FIP layer has now become security aware and supports authenticated decryption(only). This is a deviation from the secure/signed/verified boot design, where we use the TBBR COT to dictate the security operations on the file. This is nice, because file IO is decoupled from the security policy. This may be a big deviation(i apologize if this was considered and shot down for some other reason), but it may be worthwhile to consider making authenticated decryption a part of the authentication framework as opposed to coupling it with the FIP layer. It looks like you have mixed both TBBR CoT and this authenticated decryption feature. They both are completely different and rather complement each other where TBBR CoT establishes secure/signed/verified boot and this authenticated decryption feature provides confidentiality protection for FIP payloads. > At a high level, this would mean adding a new authentication method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having the platform specify that the image is using authenticated encryption in the TBBR COT. Why would one use authenticated decryption only to establish TBBR Chain of Trust providing device the capability to self sign its firmwares? We must use signature verification for TBBR CoT (see section: 2.1 Authentication of Code Images by Certificate in TBBR spec [1]). > The authentication framework is already well designed and well equipped to handle these types of extensions. > 1) This would make the change simpler, since you would not require changes to the FIP tool and the FIP layer. > 2) This would also allow for future cases where a platform may want to only encrypt the file and use public key authentication on the encrypted file(for ex. the soc does not have a crypto accelerator for aes-gcm but only for AES and public key verification, for whatever reason). How would this ensure integrity of ciphertext? This approach may be vulnerable to Chosen Ciphertext Attacks (CCAs). Authentication tag as part of AES-GCM provides integrity protection for ciphertext. > 3) This would let you choose the order in which you want to do the authenticated decryption(or just decryption) and signature verification, if you use both, one or the other. > Have a look at some defective sign and encrypt techniques here [2]. The order can't be any arbitrary one, we need to be careful about this. > One other thing i'm not entirely comfortable with is that the flag indicating if there are encrypted files or not in the FIP, is in the *unsigned* portion of the FIP header. An attacker could simply flip bits that dictate security policy in the header and avoid detection(in this case, the indication that the file needs authenticated decryption). If a platform only uses authenticated encryption, but not verified boot, an attacker could flip the bit in the FIP header and have any image loaded on the platform. Why would one not use TBBR CoT here? > If authenticated encryption cannot be used without verified boot(which requires build time flags), having a flag to indicate that there are encrypted files in the FIP header is moot, since this can come at build time through the TBBR COT. In any case, it seems like the security policy that firmware images need to be decrypted or authenticated with authenticated decryption, seems like a firmware build time or manufacturing time decision(perhaps a bit set in the e-fuses). Again you are confusing TBBR CoT with authenticated decryption feature. And why would one like to hardcode in a device during provisioning to boot only either an encrypted or a plain firmware image? > There seems to be no benefit to having a flag in the FIP header. How would one handle a case where BL31 is in plain format and BL32 is in encrypted format? > Otherwise, I cant think of any attacks due to this and it may be completely okay, but generally, consuming data that dictates security policy/operations before verifying its integrity seems like a recipe for disaster. > If you are really paranoid about authentication of FIP header then you should look at implementing optional requirement: R010_TBBR_TOC as per TBBR spec [1]. [1] https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requiremen… [2] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html -Sumit > -Raghu > > On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: > > Hi Sandrine, > > On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux > <Sandrine.Bailleux(a)arm.com> wrote: > > > Hello Sumit, > > > Thank you for reworking the patches and addressing all of my review > > comments. I am happy with the latest version of these and consider them > > ready to go. I plan to leave them in Gerrit for another week to give > > extra time for other potential reviewers to have a look and comment. > > > > Thanks for your review. > > To everyone on the list: Please raise any concerns you may have about > > these patches in the coming week. If I don't hear anything by 29th > > January 2020, I will merge these patches. > > > @Sumit: One of the next actions for this patch stack would be to have > > some level of testing in the CI system to detect any potential > > regressions. We (at Arm) can quite easily add a few build tests but then > > testing the software stack on QEMU is a bit more involved for various > > reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, > > ...) so this might have to wait for some time. > > > > Okay, will wait for CI testing. > > -Sumit > > Regards, > > Sandrine > > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Raghupathy Krishnamurthy

Forgot to add TF-A list(why is it not automatically on when you hit reply all ?) On January 22, 2020 at 10:44 AM, Raghupathy Krishnamurthy <raghu.ncstate(a)icloud.com> wrote: Hello, The patch stack looks good. The only comment i have is that the FIP layer has now become security aware and supports authenticated decryption(only). This is a deviation from the secure/signed/verified boot design, where we use the TBBR COT to dictate the security operations on the file. This is nice, because file IO is decoupled from the security policy. This may be a big deviation(i apologize if this was considered and shot down for some other reason), but it may be worthwhile to consider making authenticated decryption a part of the authentication framework as opposed to coupling it with the FIP layer. At a high level, this would mean adding a new authentication method(perhaps AUTH_METHOD_AUTHENTICATED_DECRYPTION), and having the platform specify that the image is using authenticated encryption in the TBBR COT. The authentication framework is already well designed and well equipped to handle these types of extensions. 1) This would make the change simpler, since you would not require changes to the FIP tool and the FIP layer. 2) This would also allow for future cases where a platform may want to only encrypt the file and use public key authentication on the encrypted file(for ex. the soc does not have a crypto accelerator for aes-gcm but only for AES and public key verification, for whatever reason). 3) This would let you choose the order in which you want to do the authenticated decryption(or just decryption) and signature verification, if you use both, one or the other. One other thing i'm not entirely comfortable with is that the flag indicating if there are encrypted files or not in the FIP, is in the *unsigned* portion of the FIP header. An attacker could simply flip bits that dictate security policy in the header and avoid detection(in this case, the indication that the file needs authenticated decryption). If a platform only uses authenticated encryption, but not verified boot, an attacker could flip the bit in the FIP header and have any image loaded on the platform. If authenticated encryption cannot be used without verified boot(which requires build time flags), having a flag to indicate that there are encrypted files in the FIP header is moot, since this can come at build time through the TBBR COT. In any case, it seems like the security policy that firmware images need to be decrypted or authenticated with authenticated decryption, seems like a firmware build time or manufacturing time decision(perhaps a bit set in the e-fuses). There seems to be no benefit to having a flag in the FIP header. Otherwise, I cant think of any attacks due to this and it may be completely okay, but generally, consuming data that dictates security policy/operations before verifying its integrity seems like a recipe for disaster. -Raghu On January 22, 2020 at 3:51 AM, Sumit Garg via TF-A <tf-a(a)lists.trustedfirmware.org> wrote: Hi Sandrine, On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux <Sandrine.Bailleux(a)arm.com> wrote: Hello Sumit, Thank you for reworking the patches and addressing all of my review comments. I am happy with the latest version of these and consider them ready to go. I plan to leave them in Gerrit for another week to give extra time for other potential reviewers to have a look and comment. Thanks for your review. To everyone on the list: Please raise any concerns you may have about these patches in the coming week. If I don't hear anything by 29th January 2020, I will merge these patches. @Sumit: One of the next actions for this patch stack would be to have some level of testing in the CI system to detect any potential regressions. We (at Arm) can quite easily add a few build tests but then testing the software stack on QEMU is a bit more involved for various reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, ...) so this might have to wait for some time. Okay, will wait for CI testing. -Sumit Regards, Sandrine -- TF-A mailing list TF-A(a)lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a

6 years, 1 month

1
0
0 0

GCC toolchain upgrade in CI

by Madhukar Pappireddy

Hi, We have upgraded Trusted Firmware-A CI to use the GCC toolchain version 9.2.-2019.12 publicly available through developer.arm.com [1]. The relevant documentation has been updated [2] to reflect the use of these cross compilers. We request the platform maintainers to update their respective platform documentation ( trusted-firmware-a/docs/plat/*.rst) as needed. AArch32 bare-metal target (arm-none-eabi) AArch64 ELF bare-metal target (aarch64-none-elf) [1] https://developer.arm.com/tools-and-software/open-source-software/developer… [2] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/commit/?id=f35e… Thanks, Madhukar

6 years, 1 month

1
0
0 0

Re: [TF-A] [RFC] New feature in TF-A to load encrypted FIP payloads

by Sandrine Bailleux

Hello Sumit, Thank you for reworking the patches and addressing all of my review comments. I am happy with the latest version of these and consider them ready to go. I plan to leave them in Gerrit for another week to give extra time for other potential reviewers to have a look and comment. To everyone on the list: Please raise any concerns you may have about these patches in the coming week. If I don't hear anything by 29th January 2020, I will merge these patches. @Sumit: One of the next actions for this patch stack would be to have some level of testing in the CI system to detect any potential regressions. We (at Arm) can quite easily add a few build tests but then testing the software stack on QEMU is a bit more involved for various reasons (first instance of QEMU testing, dependencies on OPTEE, UEFI, ...) so this might have to wait for some time. Regards, Sandrine

6 years, 1 month

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A