1. Edk2 | Rfc
  2. Messages

Re: SubRegionAuthLib RFC

Mackay, Curtis A <curtis.a.mackay@...>
 

Hi Sean,

The binary to be signed is a blob of data to be consumed by BIOS. In the example mentioned the signed blob is packaged in an FV, but the solution should be flexible to work with other firmware management blocks.
The target use case is that the blob may be generated and signed by a 3rd party downstream of the ODM/OEM. The 3rd party needs to be able to add their own public keys to BIOS to allow BIOS to verify their blob.

After some discussion with others CC'd, the design is trending to use a separate set of variables that are reserved for data, similar to UEFI secure boot's PK/KEK/DB/DBX. This will limit the threat of attack on these keys, as only the data blobs would be compromised in the case of a compromised key, instead of all UEFI secure boot being compromised.

Regards,
Curtis

-----Original Message-----
From: Sean Brogan <spbrogan@...>
Sent: Thursday, June 25, 2020 4:41 PM
To: rfc@edk2.groups.io; Mackay, Curtis A <curtis.a.mackay@...>
Cc: Kinney, Michael D <michael.d.kinney@...>; Wang, Jian J <jian.j.wang@...>; Yao, Jiewen <jiewen.yao@...>; Sukerkar, Amol N <amol.n.sukerkar@...>; Agrawal, Sachin <sachin.agrawal@...>
Subject: Re: [edk2-rfc] SubRegionAuthLib RFC

Curtis,

Not sure I fully follow your proposal. Can you provide more on the use case? Is the "blob" a FV or is the signed_sub_region a raw section in a ffs file? or something else like binary at flash offset?

The PI spec has a filesystem that describes many options and the DxeCore has support for security validation / authentication state flags associated with FVs and FFS files.

I have also seen many designs that leverage section extraction and doing authentication thru that guided sections.

Can you provide more background as to why it is important to get this into edk2 as a "standard" and why it requires defining new structures and new library abstractions?

Finally a point on the policy. In many products (especially commercial
products) you don't see "UEFI secure boot (PK/KEK/DB/DBX)" leveraged for trust prior to EndOfDxe. Since UEFI secure boot is often user controlled this opens up your "platform" to compromise that can be impossible to recover from.

Thanks
Sean



On 6/16/2020 10:50 AM, Mackay, Curtis A wrote:
Hi,

I filed a proposal for a new library to handle UEFI BIOS sub-regions at https://bugzilla.tianocore.org/show_bug.cgi?id=2808. Attached is a slide deck with design overview of the new library.

A UEFI BIOS sub-region is an independent signed FV that can be updated independent of UEFI BIOS on flash and is part of a pre-allocated region on flash that is visible to UEFI BIOS.
The primary use-cases for such a region would be to store independently updateable firmware and large IP configuration data files to be consumed by BIOS.

To maintain the integrity of the BIOS sub-region, this ticket proposes a mechanism that:
- Leverages UEFI Secure Boot to authenticate the BIOS sub-region
- Supports PKCS#7 standard as signing/authentication mechanism to maintain the integrity of sub-region in PEI, DXE or BDS Phase.

Please provide feedback and comments on the design.

Best regards,
Curtis Mackay
Join rfc@edk2.groups.io to automatically receive all group messages.