Re: Signature verification in GRUB

[Geoffrey Thomas]

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
address@hidden