Signature verification in GRUB

[Geoffrey Thomas]

Hi GRUB list,

I'm working on adding verified boot / Secure Boot support to my company's
OS-level product (MokaFive BareMetal). As background, we use whole-image
updates to help with reliable unattended upgrades and for debugging; an
upgrade is delivered as a new ISO image, and we have GRUB configuration to
loop-mount the ISO and load further configuration, a kernel, and an
initrd.

First, does GRUB has a mechanism for me to validate a digitally-signed
file of some sort? This could be e.g. a PGP-signed file or something from
`openssl dgst -sign`. I see that GRUB has all the relevant crypto
primitives to do this, but I can't find a command to invoke them. (As far
as I can tell, gcrypt is only used for PBKDF2 and cryptodisk support?)

If not, I'd like to add a command to verify a signature on a file, or
possibly to verify a signature on a GRUB configuration file and execute it
if it validates. Does this seem like a reasonable thing to add?

Secondarily, I'm curious if anyone has done work towards porting verity or
some similar signed (but not encrypted) disk support to GRUB. Since we're
already planning on using dm-verity once the kernel is booted, I think the
simplest solution will be to have a signature on the verity root hash,
mount the ISO using verity, and load the GRUB configuration / kernel /
initrd from the resulting block device. Does this support exist already?
(I've also asked this question on the dm-crypt list.)

Finally, if there's an easier way to do verified boot with GRUB or some
existing effort along these lines that I should be helping out with, let
me know.

Thanks,

[Chris Murphy]

Google
"secure boot" site:mjg59.dreamwidth.org

Basically Fedora 18 will be the first Fedora to support UEFI Secure Boot. They are moving to a shim bootloader before GRUB2 because GRUB2 is GPLv3 licensed, which requires making signing keys available (Installation Method requirement) so users can still make their own modifications and boot the system with those modifications.

The way I understand it is Fedora will use their own shim signed with the Microsoft key, then have the shim load GRUB2. So everything has to be signed or the adventure is pointless.

Another strategy is what SUSE is doing, which is a bit different, and worth looking into as well. This most recent post may be most applicable but sorta depends on understanding the background:
http://mjg59.dreamwidth.org/17542.html


Chris Murphy

[Geoffrey Thomas]

Post by Chris Murphy
Google
"secure boot" site:mjg59.dreamwidth.org
Basically Fedora 18 will be the first Fedora to support UEFI Secure
Boot. They are moving to a shim bootloader before GRUB2 because GRUB2 is
GPLv3 licensed, which requires making signing keys available
(Installation Method requirement) so users can still make their own
modifications and boot the system with those modifications.
The way I understand it is Fedora will use their own shim signed with
the Microsoft key, then have the shim load GRUB2. So everything has to
be signed or the adventure is pointless.
Another strategy is what SUSE is doing, which is a bit different, and
worth looking into as well. This most recent post may be most applicable
http://mjg59.dreamwidth.org/17542.html

Thanks, I've read all of those posts, and I'm already using Matthew's shim
loader. I'm planning on taking a different approach more along the lines
of Chromium OS' verified boot:

http://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot

The difference between Fedora (and SUSE, Ubuntu, etc.) on one side and
Chromium OS and us on the other is that the distros are general purpose
and support booting any userspace, so there needs to be some restricting
of the kernel's capabilities to prevent writing an initscript that e.g.
kexecs a trojanned Windows. Matthew is submitting several patches upstream
to the kernel to lock down userspace access to kernelspace memory if the
kernel has been secure-booted, and I think Fedora at least is planning on
module signing and a push towards KMS everywhere, but backporting those
patches and switching to module signing would be a pain that I don't think
we need to do.

We (and Chromium OS) have the advantage that we're shipping a complete OS
image, so if we validate the image, we know that the initscripts and so
forth are clean, and we can allow our signed userspace code to modify
kernelspace. So if I can validate the OS image from GRUB, I don't need to
make a ton of intrusive changes to our kernel and X stack.

Besides, verified boot is a feature we already have been wanting to
implement, possibly with the TPM, but Secure Boot makes this available on
commodity hardware (instead of requiring a custom ROM as on Chromebooks).
And I think GRUB commands for verifying digitally-signed files and for
implementing dm-verity would be of general interest, even independent of
Secure Boot. Do you agree?

[Matthew Garrett]

Post by Chris Murphy
Basically Fedora 18 will be the first Fedora to support UEFI Secure
Boot. They are moving to a shim bootloader before GRUB2 because GRUB2
is GPLv3 licensed, which requires making signing keys available
(Installation Method requirement) so users can still make their own
modifications and boot the system with those modifications.

This isn't quite accurate - GPLv3 wasn't an issue, but using shim makes
it easier to guarantee that users can exercise their freedoms and also
means we don't have to upload a binary to Microsoft every time we update
grub.

[Chris Murphy]

Post by Matthew Garrett

Post by Chris Murphy
Basically Fedora 18 will be the first Fedora to support UEFI Secure
Boot. They are moving to a shim bootloader before GRUB2 because GRUB2
is GPLv3 licensed, which requires making signing keys available
(Installation Method requirement) so users can still make their own
modifications and boot the system with those modifications.

This isn't quite accurate - GPLv3 wasn't an issue, but using shim makes
it easier to guarantee that users can exercise their freedoms and also
means we don't have to upload a binary to Microsoft every time we update
grub.

Thanks for the clarification. That makes more sense.

Chris Murphy

[Vladimir 'φ-coder/phcoder' Serbinenko]

Post by Geoffrey Thomas
Hi GRUB list,
I'm working on adding verified boot / Secure Boot support to my
company's OS-level product (MokaFive BareMetal). As background, we use
whole-image updates to help with reliable unattended upgrades and for
debugging; an upgrade is delivered as a new ISO image, and we have GRUB
configuration to loop-mount the ISO and load further configuration, a
kernel, and an initrd.
First, does GRUB has a mechanism for me to validate a digitally-signed
file of some sort? This could be e.g. a PGP-signed file or something
from `openssl dgst -sign`. I see that GRUB has all the relevant crypto
primitives to do this, but I can't find a command to invoke them. (As
far as I can tell, gcrypt is only used for PBKDF2 and cryptodisk support?)

I have some code dating from about a year ago but because of my current
personal situation it's put on hold for some time.

Post by Geoffrey Thomas
If not, I'd like to add a command to verify a signature on a file, or
possibly to verify a signature on a GRUB configuration file and execute
it if it validates. Does this seem like a reasonable thing to add?
Secondarily, I'm curious if anyone has done work towards porting verity
or some similar signed (but not encrypted) disk support to GRUB. Since
we're already planning on using dm-verity once the kernel is booted, I
think the simplest solution will be to have a signature on the verity
root hash, mount the ISO using verity, and load the GRUB configuration /
kernel / initrd from the resulting block device. Does this support exist
already? (I've also asked this question on the dm-crypt list.)

Is there some doc on dm-verify? It may be interesting.

Post by Geoffrey Thomas
Finally, if there's an easier way to do verified boot with GRUB or some
existing effort along these lines that I should be helping out with, let
me know.
Thanks,

[Geoffrey Thomas]

Post by Vladimir 'φ-coder/phcoder' Serbinenko

Post by Geoffrey Thomas
First, does GRUB has a mechanism for me to validate a digitally-signed
file of some sort? This could be e.g. a PGP-signed file or something
from `openssl dgst -sign`. I see that GRUB has all the relevant crypto
primitives to do this, but I can't find a command to invoke them. (As
far as I can tell, gcrypt is only used for PBKDF2 and cryptodisk support?)

I have some code dating from about a year ago but because of my current
personal situation it's put on hold for some time.

Do you have something I can start from that you could drop somewhere? I
haven't begun implementing this yet, and I suspect that starting from your
code would be helpful for getting this done faster and also doing it in a
style compatible with upstream.

Also, a slightly more generic question -- what's a reasonable format here?
I'm kind of surprised to find that openssl has no generic command to sign
a file or verify it's signatures. I could use PGP, but we're already using
SSL-style certificates for Authenticode, so I'd prefer not generate
another key with a completely different format. That said, if more people
will find PGP verification useful, I can implement that.

Post by Vladimir 'φ-coder/phcoder' Serbinenko
Is there some doc on dm-verify? It may be interesting.

http://code.google.com/p/cryptsetup/wiki/DMVerity
is the official documentation.

Briefly, you generate a salted hash tree of each block (and in turn of the
blocks containing the hashes) until you get a root hash. So with a trusted
way to get the root hash, the original device, and a device/file
containing the hashes, you can generate a new (read-only) device that
validates hashes up to the root, and throws an IO error if the data has
been tampered with.

The "veritysetup" command in sbin in recent cryptsetup versions can
generate the hash tree and print out the root hash.

[Vladimir 'φ-coder/phcoder' Serbinenko]

Post by Geoffrey Thomas

Post by Vladimir 'φ-coder/phcoder' Serbinenko

Post by Geoffrey Thomas
First, does GRUB has a mechanism for me to validate a digitally-signed
file of some sort? This could be e.g. a PGP-signed file or something
from `openssl dgst -sign`. I see that GRUB has all the relevant crypto
primitives to do this, but I can't find a command to invoke them. (As
far as I can tell, gcrypt is only used for PBKDF2 and cryptodisk support?)

I have some code dating from about a year ago but because of my current
personal situation it's put on hold for some time.

Do you have something I can start from that you could drop somewhere? I
haven't begun implementing this yet, and I suspect that starting from
your code would be helpful for getting this done faster and also doing
it in a style compatible with upstream.

I want to do it myself. I'm likely to get some time for it in December.

Post by Geoffrey Thomas
Also, a slightly more generic question -- what's a reasonable format
here? I'm kind of surprised to find that openssl has no generic command
to sign a file or verify it's signatures. I could use PGP, but we're
already using SSL-style certificates for Authenticode, so I'd prefer not
generate another key with a completely different format. That said, if
more people will find PGP verification useful, I can implement that.

It has to be gnupg signatures.

Post by Geoffrey Thomas

Post by Vladimir 'φ-coder/phcoder' Serbinenko
Is there some doc on dm-verify? It may be interesting.

http://code.google.com/p/cryptsetup/wiki/DMVerity
is the official documentation.
Briefly, you generate a salted hash tree of each block (and in turn of
the blocks containing the hashes) until you get a root hash. So with a
trusted way to get the root hash, the original device, and a device/file
containing the hashes, you can generate a new (read-only) device that
validates hashes up to the root, and throws an IO error if the data has
been tampered with.

Doesn't sound like best way. MAC-tree would be better cryptographically
(third party would be unable to verify, which is of advantage) and would
be easier to write to.

Post by Geoffrey Thomas
The "veritysetup" command in sbin in recent cryptsetup versions can
generate the hash tree and print out the root hash.
_______________________________________________
Grub-devel mailing list
https://lists.gnu.org/mailman/listinfo/grub-devel

[Geoffrey Thomas]

Post by Vladimir 'φ-coder/phcoder' Serbinenko

Post by Geoffrey Thomas
http://code.google.com/p/cryptsetup/wiki/DMVerity
is the official documentation.
Briefly, you generate a salted hash tree of each block (and in turn of
the blocks containing the hashes) until you get a root hash. So with a
trusted way to get the root hash, the original device, and a device/file
containing the hashes, you can generate a new (read-only) device that
validates hashes up to the root, and throws an IO error if the data has
been tampered with.

Doesn't sound like best way. MAC-tree would be better cryptographically
(third party would be unable to verify, which is of advantage) and would
be easier to write to.

Sorry, I think I might have been unclear what the purpose of this is. This
is only for read-only filesystems, and is intended for the case where the
image should be publicly verifiable. For our use case (and in that of
Chromium OS, who developed verity, and some other embedded-device users),
we want to provide a system update as a new signed image, so we can
guarantee that the image has not been tampered with. This image is
generated and signed on our build servers, and the same on all systems, so
it's intended that third parties can verify it and cannot modify to it.
Read/write user data and configuration is on a separate partition, and
does not contain things like kernels or kernel modules or initscripts.

The most obvious way to do this would be to make a digital signature of
the entire disk image. But verifying about a gigabyte of data at once
would unnecessarily slow down the boot process.

There are other solutions for read/write images using HMAC and a secret
key, including dm-integrity ( https://lwn.net/Articles/517381/ ). That's
not the use case I'm interested in, although making dm-integrity available
to GRUB would probably also be useful to some people.