From: Petr Vandrovec <petr@vmware.com>
To: edk2-devel@lists.01.org
Subject: How to correctly sign EFI Firmware Volume?
Date: Tue, 2 Oct 2018 14:12:53 -0700 [thread overview]
Message-ID: <7fbefed2-f287-7dd2-4271-fba23ffaae8d@vmware.com> (raw)
Hi,
I've sent this ot fw_os_forum, and was redirected here. Sorry if you
are receiving this twice.
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.
On fw_os_forum I got recommendation to use EFI capsule format for signing.
Unfortunately I cannot figure out how to make out-of-band signatures
work for firmware volumes in a secure way: firmware module has to be
multiple of (at least) 4KB, and must cover last 16 bytes of ROM (as that
is where execution starts). Then I need to prepend capsule header (or
wrapping firmware volume header) and signature in front of that. Dual
SHA1/256 signing with timestamps takes about 5KB, so there are 3KB of
free unsigned space left.
If I leave those 3KB unsigned, anybody can remove them, shift signed
image down by 3KB, and then have 3KB of unsigned code running at the
reset vector :-(
Or I can do trial signing, figure out how long signature will probably
be, and then extend signed area so that only capsule header and
signature unsigned. That could work, but then I'm not signing firmware
volume, but firmware volume with 3KB of data prepended to it (or
firmware volume that is not multiple of 4KB, if I let our firmware
volume to have arbitrary size), which is not exactly industry standard.
And even if I do this, as image is dual signed, someone can remove SHA1
signature, shift rest down, and get about 1KB for the malicious code.
So for all non-embedded signatures I'm always coming up with <do this
standard thing> and require that signed payload ends with end of ROM,
while I'm looking for just <do this standard thing>, without strings
attached.
Thanks,
Petr Vandrovec
next reply other threads:[~2018-10-02 21:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-02 21:12 Petr Vandrovec [this message]
2018-10-03 0:28 ` How to correctly sign EFI Firmware Volume? Andrew Fish
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7fbefed2-f287-7dd2-4271-fba23ffaae8d@vmware.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox