Signature verification in GRUB

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,
-- 
Geoffrey Thomas
gthomas@mokafive.com

Re: Signature verification in GRUB

[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

Re: Signature verification in GRUB

[Geoffrey Thomas]

On Tue, 9 Oct 2012, Chris Murphy wrote:

> 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

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?

-- 
Geoffrey Thomas
gthomas@mokafive.com

Re: Signature verification in GRUB

[Matthew Garrett]

On Tue, Oct 09, 2012 at 06:32:49PM -0600, Chris Murphy wrote:

> 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.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: Signature verification in GRUB

[Chris Murphy]

On Oct 10, 2012, at 12:33 PM, Matthew Garrett wrote:

> On Tue, Oct 09, 2012 at 06:32:49PM -0600, Chris Murphy wrote:
> 
>> 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

Re: Signature verification in GRUB

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2004 bytes --]

On 10.10.2012 00:54, Geoffrey Thomas wrote:

> 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.

> 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.

> 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,



-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Signature verification in GRUB

[Geoffrey Thomas]

[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]

On Sat, 13 Oct 2012, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

>> 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.

> 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.

-- 
Geoffrey Thomas
gthomas@mokafive.com

Re: Signature verification in GRUB

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 2559 bytes --]

On 15.10.2012 23:33, Geoffrey Thomas wrote:

> On Sat, 13 Oct 2012, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> 
>>> 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.

> 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.

>> 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.

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



-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 294 bytes --]

Re: Signature verification in GRUB

[Geoffrey Thomas]

[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]

On Thu, 18 Oct 2012, Vladimir 'φ-coder/phcoder' Serbinenko wrote:

>> 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.

-- 
Geoffrey Thomas
gthomas@mokafive.com