- TF-A - lists.trustedfirmware.org

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

5 years, 11 months

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

5 years, 11 months

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

5 years, 11 months

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

5 years, 11 months

2
1
0 0

Re: [TF-A] Who better implements a safe environment: cortex-M or cortex-A?

by Joanna Farley

Hi Iñigo, We needs a little bit more information to know how best to answer your question. Is this just an academic question of is there a real use case you are trying to decide on which way to go? Its not so much a question of which architecture is easier its just that they are different with Cortex-M powering the most energy-efficient embedded devices where as Cortex-A is offering supreme performance at optimal power. Each architecture offers different hardware constraints and the secure TrustZone is implemented to handle each and an ecosystem of solutions surrounds each. If this is an academic question I would refer you to Arm's pages on TrustZone as a starting point: https://www.arm.com/why-arm/technologies/trustzone-for-cortex-m https://www.arm.com/why-arm/technologies/trustzone-for-cortex-a If there is need for guidance on a specific solution or difficulties you are trying to overcome while building a solution please give us some more details. Thanks Joanna On 22/01/2020, 08:07, "TF-A on behalf of Iñigo Vicente Waliño via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hi, Can someone explain to me why it is easier to implement a secure TrustZone environment with secure boot and storage and PSA certificate in cortex-M than in cortex-A? Who better implements a safe environment: cortex-M or cortex-A? Why? Thanks. -- 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. 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.

5 years, 11 months

1
0
0 0

Who better implements a safe environment: cortex-M or cortex-A?

by Iñigo Vicente Waliño

Hi, Can someone explain to me why it is easier to implement a secure TrustZone environment with secure boot and storage and PSA certificate in cortex-M than in cortex-A? Who better implements a safe environment: cortex-M or cortex-A? Why? Thanks.

5 years, 11 months

1
0
0 0

Please revert "Remove RSA PKCS#1 v1.5 support from cert_tool"

by Scott Branden

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

5 years, 11 months

1
0
0 0

Re: [TF-A] Gerrit review latency

by Joanna Farley

Hi Varun, It can be a challenge to keep on top of the reviews and we are aware of the backlog increase after the end of year break and trying different approaches to get reviews completed. Any suggestions on process improvements from the developer community at large are welcome. Cheers Joanna On 16/01/2020, 17:34, "TF-A on behalf of Varun Wadekar via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: Hello, We (NVIDIA) frequently post changes on the TF-A gerrit dashboard and wait for the maintainers to gradually get to them. This is very time consuming and non-deterministic. Curious to know if other developers face the same problems or are we missing something when asking for reviews? If most of us face the same problems, then we should try to formulate a process to reduce the latency. Thoughts? -Varun ----------------------------------------------------------------------------------- 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 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. 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.

5 years, 11 months

2
1
0 0

Gerrit review latency

by Varun Wadekar

Hello, We (NVIDIA) frequently post changes on the TF-A gerrit dashboard and wait for the maintainers to gradually get to them. This is very time consuming and non-deterministic. Curious to know if other developers face the same problems or are we missing something when asking for reviews? If most of us face the same problems, then we should try to formulate a process to reduce the latency. Thoughts? -Varun ----------------------------------------------------------------------------------- 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. -----------------------------------------------------------------------------------

5 years, 11 months

1
0
0 0

Re: [TF-A] SMC to intentionally trigger a panic in TF-A

by Soby Mathew

On 13/12/2019 22:04, Julius Werner via TF-A wrote: > On Fri, Dec 13, 2019 at 6:20 AM Joanna Farley <Joanna.Farley(a)arm.com> wrote: >> On the subject of DebugFS's purpose it was envisages and is today as Sandrine describes as a debug build only capability. Saying that though there has been some early thoughts that it could evolve into a Secure Debug feature where this type of capability or something like it is always on requiring debug certificates for authenticated access. This is something very much for a possible future evolution and is not in the patches available today. We would welcome any thoughts on such an evolution in this space. > > I guess this gets into a bit of a philosophy discussion and becomes a > matter of opinion, so there's probably no one right answer. > Personally, adding authentication on top of this doesn't really > resolve my concerns and adds yet more on top. I'm a strong proponent > of the concept of a minimal Trusted Computing Base, i.e. keeping the > amount of code executing at the highest privilege level as small and > low-complexity as possible. Any code can have bugs, so the idea is > that the more complicated the code you run in EL3 is (and the more > complicated APIs it exposes), the more likely it becomes that you > accidentally have an exploitable vulnerability in there. Like a p9 > filesystem driver, a certificate-based authentication system > (especially if it's based on x509/ASN.1 which are notoriously hard to > implement safely) is a pretty complex piece of code with a pretty > large attack surface that I'd rather not have in my EL3 firmware if I > can avoid it. I understand that for certain use cases you may need > something like this (if you really want a very extensive and > extensible debugging API that must be restricted to a few > authenticated actors), but in my use case I really just need the > ability to trigger one small debugging feature and that feature itself > doesn't need to be restricted, so a minimal SMC interface would work > much better for that case. Hi Julius, Just to trying to understand, if TF-A were to expose a crash inducing SMC, this would still be restricted to special builds for your test runs ? This would not make it to production for Chromebook right ? I agree 9p filesystem is not desirable in a EL3 runtime firmware. We could enhance it to use a more tight data structure, if there is a desire in that direction. If that is the case, leaving aside the 9p filesystem issues, can DebugFS serve this requirement (we can remove the limitation that it is restricted to only Debug builds) ? The intention that DebugFS can prove useful atleast in the verification/testing space and if there is more we can do to get there, it would be good to know. > >> On 13/12/2019, 13:01, "TF-A on behalf of Sandrine Bailleux via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote: >> Going back to the SMC-based solution then, I am not quite convinced >> SYSTEM_RESET2 is the right interface for intentionally triggering a >> panic in TF-A. I think the semantics do not quite match. If anything, a >> firmware crash seems more like a shutdown operation to me rather than a >> reset (we don't recover from a firmware crash). I am not even sure we >> should look into the PSCI SMC range, as it's not a power-management >> operation. > > Crash recovery behavior is platform dependent (via > plat_panic_handler()). On all the platforms we use in Chrome OS we > have that implemented as a system reboot. I think for most systems > (whether it's a Chromebook, a server or some embedded device) that's > probably what you want for random runtime crashes (and least in a > production environment), but I agree that TF doesn't enforce any > standard behavior so it's hard to clearly match it to one or the other > SMC. > >> So it sounds like it's not the first time that you hit this issue, is >> it? Do you have any other example of Normal World OS feature you would >> have liked to expose through a generic SMC interface? I am wondering >> whether this could help choosing the right SMC range, if we can identify >> some common criteria among a set of such features. > > No, it's the first time I've really run into this. But I think we > might quickly come up with more uses for a "non-secure OS" SMC range > if we had one. We often see roughly the same SMC again on different > platforms, because fundamentally they usually need to do the same > kinds of things -- for example, most platforms have some kind of DDR > frequency scaling which always needs part of it implemented in EL3, so > they all need some kind of SMC to switch to a new DDR frequency. Many > also need some kind of "write value to secure register" SMC that just > allows the non-secure OS to write a few whitelisted registers that are > only accessible in EL3 for some reason. If we could standardize these > interfaces in a non-vendor-specific SMC range, we might be able to > reduce some code duplication both on the TF and the Linux side. > > I guess none of these things are really Linux-specific, now that I > think of it. So really, I guess the problem is that it would be great > to have a range of "generic" SMC IDs that can be easily and > unbureaucratically allocated to try out new features, without having > to ask Arm to write a big specification document about it every time. > It's sort of a development velocity issue. > We have utilized the ARM SiP range for some "generic" purposes in the past (see PMF and the execution state switch SMCs). This could be direction for the some of use-cases. But if the SMCs are meant to be truly generic and to be relied on for use by generic normal world software components, it would need to be properly specified I would think. For dynamically modifying some EL3 registers, it would be good to get these requirements out. Perhaps there is scope for architecting some of them as an ARM specification. If not, we could revert to a TF-A standard if there is enough pull for them (perhaps utilizing the ARM SiP range). Best Regards Soby Mathew

5 years, 12 months

2
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

TF-A