lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1580369477.3688.8.camel@HansenPartnership.com>
Date:   Thu, 30 Jan 2020 08:31:17 +0100
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Mimi Zohar <zohar@...ux.ibm.com>,
        Roberto Sassu <roberto.sassu@...wei.com>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>
Cc:     Jerry Snitselaar <jsnitsel@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Silviu Vlasceanu <Silviu.Vlasceanu@...wei.com>
Subject: Re: [PATCH 2/2] ima: support calculating the boot_aggregate based
 on different TPM banks

On Wed, 2020-01-29 at 18:20 -0500, Mimi Zohar wrote:
> On Tue, 2020-01-28 at 10:40 -0500, Mimi Zohar wrote:
> > > This code assumes that the algorithm used to calculate
> > > boot_aggregate and the algorithm of the PCR bank can be
> > > different. I don't know if it is possible to communicate to the
> > > verifier which bank has been selected (it depends on the local
> > > configuration).
> > 
> > Agreed, but defaulting to the first bank would only happen if the
> > IMA default hash algorithm is not a configured TPM algorithm.
> > 
> > > 
> > > In my opinion the safest approach would be to use the same
> > > algorithm for the digest and the PCR bank. If you agree to this,
> > > then the code above must be moved to ima_calc_boot_aggregate() so
> > > that the algorithm of the selected PCR bank can be passed to
> > > ima_alloc_tfm().
> > 
> > Using the same hash algorithm, preferably the IMA hash default
> > algorithm, for reading the TPM PCR bank and calculating the
> > boot_aggregate makes sense.
> > 
> > > 
> > > The selected PCR bank might be not the first, if the algorithm is
> > > unknown to the crypto subsystem.
> > 
> > It sounds like you're suggesting finding a common configured hash
> > algorithm between the TPM and the kernel. 
> 
> I'd like to clarify the logic for the case when a common algorithm
> does not exist.

I'm not sure we need to twist ourselves in knots over this.  The TCG
client platform for 2.0 mandates sha256, so we should be able to count
on it being present.  I'd be happy to treat the failure to find sha256
on TPM 2.0 as a fatal error, and the same for the failure to find sha1
on TPM 1.2.

>   None of the TPM allocated banks are known by the kernel.  If the
> hash algorithm of the boot_aggregate represents not only that of the
> digest included in the measurement list, but also of the TPM PCR bank
> read, what should happen?  Should the boot aggregate be 0's, like in
> the case when there isn't a TPM?

For TPM 1.2 sha1 is required and for TPM2 sha256 is.  I'd just force
search for those, based on the TPM version, and fail to use the TPM if
they're not found.  There should be a boot time and config option for
weird hashes which might be the only ones on BRIC embedded devices,
like Streebog or ZM2, but the clear default should be the TCG mandates
and it should be up to anything weird to cope with their own induced
problems and not make it part of the standard setup.

James

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ