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@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-requirement... [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@lists.trustedfirmware.org wrote:

Hi Sandrine,

On Wed, 22 Jan 2020 at 15:43, Sandrine Bailleux Sandrine.Bailleux@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@lists.trustedfirmware.org https://lists.trustedfirmware.org/mailman/listinfo/tf-a