From petr at vmware.com  Tue Oct  2 15:36:09 2018
From: petr at vmware.com (Petr Vandrovec)
Date: Tue, 2 Oct 2018 19:36:09 +0000
Subject: [Fw_Os_Forum] How to correctly sign EFI Firmware Volume?
Message-ID: <b9f877b7-d575-66af-6f81-fa6b888d5ba9@vmware.com>

Good morning,

I'm looking at options how to sign our EFI firmware through some 
industry-standard embedded signature option, and signing whole firmware 
volume as described in Platform Initialization spec would definitely fit 
the bill.

Unfortunately problem is that I cannot make sense of what should be 
actually signed.  Chapter 3.2.1.1 of PI_Spec_1_6.pdf says:

<quote>
3.2.1.1 EFI Signed Firmware Volumes

There may be one or more headers with a FormatType of value 
EFI_FIRMWARE_CONTENTS_SIGNED_GUID.

A signed firmware volume is a cryptographic signature across the entire 
volume. To process the contents and verify the integrity of the volume, 
the EFI_FIRMWARE_VOLUME_EXT_ENTRY_GUID_TYPE Data[] shall contain an 
instance of WIN_CERTIFICATE_UEFI_GUID where the CertType = 
EFI_CERT_TYPE_PKCS7_GUID or EFI_CERT_TYPE_RSA2048_SHA256_GUID.
</quote>

Part about WIN_CERTIFICATE_UEFI_GUID is easy.  But what should be signed?

Text says 'A signed firmware volume is a cryptographic signature across 
the entire volume.' - beside that 'firmware volume' is not a signature, 
what is 'the entire volume' ?  Clearly Data[] entry holding signature 
cannot be part of the signature, as otherwise adding signature would 
invalidate that very same signature, so it cannot be signature of entire 
volume from first 16 reserved bytes in the header to the last byte of 
the image, but something else.

Can someone provide clarification what should be signed?  It seems to me 
like that intention is to only sign data portion of the volume, from the 
end of extended header to the end of volume.  But that means that anyone 
can modify anything in the header or extended header without breaking 
signature.

Are there any examples of signed firmware volumes?  Unfortunately there 
does not seem to be any code in UDK for this feature.

Thanks,
Petr Vandrovec

From brian.richardson at intel.com  Tue Oct  2 16:00:48 2018
From: brian.richardson at intel.com (Richardson, Brian)
Date: Tue, 2 Oct 2018 20:00:48 +0000
Subject: [Fw_Os_Forum] How to correctly sign EFI Firmware Volume?
In-Reply-To: <b9f877b7-d575-66af-6f81-fa6b888d5ba9@vmware.com>
References: <b9f877b7-d575-66af-6f81-fa6b888d5ba9@vmware.com>
Message-ID: <80AC2BAA3152784F98F581129E5CF5AFBAA4E624@ORSMSX114.amr.corp.intel.com>

Petr:

Signing should be covered by UEFI Capsule Update in EDK II.
https://github.com/tianocore/tianocore.github.io/wiki/Capsule-Based-Firmware-Update-and-Firmware-Recovery

https://github.com/tianocore/edk2/tree/master/SignedCapsulePkg
https://github.com/tianocore/edk2/tree/master/FmpDevicePkg 

If you run into issues or have further questions, please ping the edk2-devel mailing list.
https://lists.01.org/mailman/listinfo/edk2-devel 

Thanks ... br
---
Brian Richardson, Senior Technical Marketing Engineer, Intel Software
brian.richardson at intel.com -- @intel_brian (Twitter & WeChat)
https://software.intel.com/en-us/meet-the-developers/evangelists/team/brian-richardson 

-----Original Message-----
From: fw_os_forum-bounces at mailman.uefi.org <fw_os_forum-bounces at mailman.uefi.org> On Behalf Of Petr Vandrovec
Sent: Tuesday, October 2, 2018 3:36 PM
To: fw_os_forum at mailman.uefi.org
Subject: [Fw_Os_Forum] How to correctly sign EFI Firmware Volume?

Good morning,

I'm looking at options how to sign our EFI firmware through some industry-standard embedded signature option, and signing whole firmware volume as described in Platform Initialization spec would definitely fit the bill.

Unfortunately problem is that I cannot make sense of what should be actually signed.  Chapter 3.2.1.1 of PI_Spec_1_6.pdf says:

<quote>
3.2.1.1 EFI Signed Firmware Volumes

There may be one or more headers with a FormatType of value EFI_FIRMWARE_CONTENTS_SIGNED_GUID.

A signed firmware volume is a cryptographic signature across the entire volume. To process the contents and verify the integrity of the volume, the EFI_FIRMWARE_VOLUME_EXT_ENTRY_GUID_TYPE Data[] shall contain an instance of WIN_CERTIFICATE_UEFI_GUID where the CertType = EFI_CERT_TYPE_PKCS7_GUID or EFI_CERT_TYPE_RSA2048_SHA256_GUID.
</quote>

Part about WIN_CERTIFICATE_UEFI_GUID is easy.  But what should be signed?

Text says 'A signed firmware volume is a cryptographic signature across the entire volume.' - beside that 'firmware volume' is not a signature, what is 'the entire volume' ?  Clearly Data[] entry holding signature cannot be part of the signature, as otherwise adding signature would invalidate that very same signature, so it cannot be signature of entire volume from first 16 reserved bytes in the header to the last byte of the image, but something else.

Can someone provide clarification what should be signed?  It seems to me like that intention is to only sign data portion of the volume, from the end of extended header to the end of volume.  But that means that anyone can modify anything in the header or extended header without breaking signature.

Are there any examples of signed firmware volumes?  Unfortunately there does not seem to be any code in UDK for this feature.

Thanks,
Petr Vandrovec
_______________________________________________
fw_os_forum mailing list
fw_os_forum at mailman.uefi.org
http://lists.mailman.uefi.org/mailman/listinfo/fw_os_forum

From petr at vmware.com  Tue Oct  2 16:49:00 2018
From: petr at vmware.com (Petr Vandrovec)
Date: Tue, 2 Oct 2018 20:49:00 +0000
Subject: [Fw_Os_Forum] How to correctly sign EFI Firmware Volume?
In-Reply-To: <80AC2BAA3152784F98F581129E5CF5AFBAA4E624@ORSMSX114.amr.corp.intel.com>
References: <b9f877b7-d575-66af-6f81-fa6b888d5ba9@vmware.com>
	<80AC2BAA3152784F98F581129E5CF5AFBAA4E624@ORSMSX114.amr.corp.intel.com>
Message-ID: <fa68b69b-7764-5a42-4ca3-06f8bde205da@vmware.com>

Richardson, Brian wrote on 10/2/2018 1:00 PM:
> Petr:
> 
> Signing should be covered by UEFI Capsule Update in EDK II.
> https://github.com/tianocore/tianocore.github.io/wiki/Capsule-Based-Firmware-Update-and-Firmware-Recovery
> 
> https://github.com/tianocore/edk2/tree/master/SignedCapsulePkg
> https://github.com/tianocore/edk2/tree/master/FmpDevicePkg

Thanks.

We are looking way how remote attestation can be done for our platform's 
firmware.  As our platform H-RTM measured our 2MB EFI ROM to TPM's PCR0, 
now only thing we need is that 3rd party tool can extract 2MB image, 
verify hash matches with TPM event log, and that image is signed by VMware.

Problem is that 3rd party tool must be able to know where to find 
signature and how to validate it.

And as Tianocore (and so VMware's UEFI) uses EFI Firmware Volume format 
for the ROM content, saying that our firmware volume has embedded 
signature conforming to PI spec 1.6 would be easiest for everybody: 
there is public standard, VMware implements signing & 3rd party 
implements verification, and all is good.

If that's not the way through, then I can take a look at making our ROM 
content being UEFI capsule with firmware volume payload, rather than 
just firmware volume, and then use UEFI capsule to hold signature.

But at that point I could also just wrap another firmware volume around 
our current one, and sign that embedded volume using FV's ability to 
sign individual files.  Or wrap image in Microsoft's PE format, and use 
their authenticode to sign then image.

We've prototyped both, but we feel uneasy with both as for both of them 
there is unsigned area that could be used to compromise ROM without 
breaking signature.

 > If you run into issues or have further questions, please ping the 
edk2-devel mailing list.
 > https://lists.01.org/mailman/listinfo/edk2-devel

Thanks.  I'll ask there.

Petr

> Thanks ... br
> ---
> Brian Richardson, Senior Technical Marketing Engineer, Intel Software


> -----Original Message-----
> From: fw_os_forum-bounces at mailman.uefi.org <fw_os_forum-bounces at mailman.uefi.org> On Behalf Of Petr Vandrovec
> Sent: Tuesday, October 2, 2018 3:36 PM
> To: fw_os_forum at mailman.uefi.org
> Subject: [Fw_Os_Forum] How to correctly sign EFI Firmware Volume?
> 
> Good morning,
> 
> I'm looking at options how to sign our EFI firmware through some industry-standard embedded signature option, and signing whole firmware volume as described in Platform Initialization spec would definitely fit the bill.
> 
> Unfortunately problem is that I cannot make sense of what should be actually signed.  Chapter 3.2.1.1 of PI_Spec_1_6.pdf says:
> 
> <quote>
> 3.2.1.1 EFI Signed Firmware Volumes
> 
> There may be one or more headers with a FormatType of value EFI_FIRMWARE_CONTENTS_SIGNED_GUID.
> 
> A signed firmware volume is a cryptographic signature across the entire volume. To process the contents and verify the integrity of the volume, the EFI_FIRMWARE_VOLUME_EXT_ENTRY_GUID_TYPE Data[] shall contain an instance of WIN_CERTIFICATE_UEFI_GUID where the CertType = EFI_CERT_TYPE_PKCS7_GUID or EFI_CERT_TYPE_RSA2048_SHA256_GUID.
> </quote>
> 
> Part about WIN_CERTIFICATE_UEFI_GUID is easy.  But what should be signed?
> 
> Text says 'A signed firmware volume is a cryptographic signature across the entire volume.' - beside that 'firmware volume' is not a signature, what is 'the entire volume' ?  Clearly Data[] entry holding signature cannot be part of the signature, as otherwise adding signature would invalidate that very same signature, so it cannot be signature of entire volume from first 16 reserved bytes in the header to the last byte of the image, but something else.
> 
> Can someone provide clarification what should be signed?  It seems to me like that intention is to only sign data portion of the volume, from the end of extended header to the end of volume.  But that means that anyone can modify anything in the header or extended header without breaking signature.
> 
> Are there any examples of signed firmware volumes?  Unfortunately there does not seem to be any code in UDK for this feature.
> 
> Thanks,
> Petr Vandrovec
> _______________________________________________
> fw_os_forum mailing list
> fw_os_forum at mailman.uefi.org
> https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.mailman.uefi.org%2Fmailman%2Flistinfo%2Ffw_os_forum&amp;data=02%7C01%7Cpetr%40vmware.com%7C344acf52176447b2c72108d628a1c068%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C1%7C0%7C636741072529537964&amp;sdata=zgJ91p7OCJMDWvcRrlHJ1bsYBwPRT4QRTVjlMYX92Pw%3D&amp;reserved=0
>