Re: IMA metadata format to support fs-verity

[Mimi Zohar <zohar@linux.ibm.com>]

On Wed, 2020-08-26 at 18:00 -0700, Eric Biggers wrote:
> On Wed, Aug 26, 2020 at 08:53:33PM -0400, Mimi Zohar wrote:
> > On Wed, 2020-08-26 at 13:51 -0700, Eric Biggers wrote:
> > > Of course, the bytes that are actually signed need to include not just the hash
> > > itself, but also the type of hash algorithm that was used.  Else it's ambiguous
> > > what the signer intended to sign.
> > > 
> > > Unfortunately, currently EVM appears to sign a raw hash, which means it is
> > > broken, as the hash algorithm is not authenticated.  I.e. if the bytes
> > > e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 are signed,
> > > there's no way to prove that the signer meant to sign a SHA-256 hash, as opposed
> > > to, say, a Streebog hash.  So that will need to be fixed anyway.  While doing
> > > so, you should reserve some fields so that there's also a flag available to
> > > indicate whether the hash is a traditional full file hash or a fs-verity hash.
> > 
> > The original EVM HMAC is still sha1, but the newer portable & immutable
> > EVM signature supports different hash algorithms.
> > 
> 
> Read what I wrote again.  I'm talking about the bytes that are actually signed.

I agree including the hash algorithm in the digest would be
preferrable, but it isn't per-se broken.   The file signature and the
file metadata hash algorithms are the same, otherwise signature
verification fails[1].   The same tool calculates the file metadata
digest and then signs the digest, using the same hash algorithm.  In
terms of the HMAC, it is (still) limited to SHA1.

Mimi

[1] commit 5feeb61183dd ("evm: Allow non-SHA1 digital signatures")