linux-kernel - Re: [Linux-ima-devel] [PATCH v3 0/6] Updated API for TPM 2.0 PCR extend

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <03e70c05-5127-5c95-de8b-fedf90a23d7e@huawei.com>
Date:   Mon, 26 Jun 2017 16:56:02 +0200
From:   Roberto Sassu <roberto.sassu@...wei.com>
To:     Mimi Zohar <zohar@...ux.vnet.ibm.com>,
        Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>
CC:     <linux-ima-devel@...ts.sourceforge.net>,
        <linux-security-module@...r.kernel.org>,
        <tpmdd-devel@...ts.sourceforge.net>, <keyrings@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        Kenneth Goldman <kgoldman@...ibm.com>
Subject: Re: [Linux-ima-devel] [PATCH v3 0/6] Updated API for TPM 2.0 PCR
 extend

On 6/26/2017 2:33 PM, Mimi Zohar wrote:
> On Sat, 2017-06-24 at 11:03 +0200, Jarkko Sakkinen wrote:
>> On Wed, Jun 21, 2017 at 04:29:35PM +0200, Roberto Sassu wrote:
>
>
>> To move this forward and be more constructive here's how I see it
>> should be done (along the lines, draft):
>>
>> int tpm_pcr_extend(u32 chip_num, int pcr_idx, unsigned int alg,
>> 		   const u8 *hash);
>>
>> The paramater 'alg' is crypto ID as specified by crypto subsystem.
>
> Based on Kenneth Goldman's input, the new IMA TPM-2.0 crypto hash
> agile measurement list will contain the TPM crypto hash algorithm ids
> (TPM crypto-ID).
>
>> TPM driver must have a precompiled table of mappings for crypto IDs
>> and TPM algorithm IDs.
>
> We could map the TPM crypto-IDs to the crypto subsystem IDs and then
> map them back, but is that necessary?
>
>>
>> In addition it must have dynamically acquired list of TPM alg IDs.
>> For those algs that static mapping does not exist it must extend
>> them like we do now everything else except SHA-1 (Naynas changes).
>
> Padding/truncating an unknown bank using SHA1 is fine, but at some
> point, as Roberto pointed out to me, TPM 2.0's might not support SHA-
> 1.  So for the record, we're hard coding the use of SHA1 for the
> unknown algorithms whether or not the TPM supports SHA1.

This solution requires that SHA1 digests are always calculated
and included in the event log, even if SHA1 has not been selected
by the user. I think this is not acceptable in the scenarios where
saving power and memory is important.

I would instead use the first digest passed to tpm_pcr_extend()
(it must be the first also in the event log) to extend banks
for which the digest is missing.

If TPM users want to pad/truncate a different digest, they can
pass to tpm_pcr_extend() a digest for each TPM algorithm.
This is possible with the patches I sent because TPM users
receive the TPM algorithm IDs and the digest size for each
algorithm.

Regarding the possibility that SHA1 could not be supported,
for now this shouldn't happen because, according to TCG,
SHA1 support is mandatory for TPM 2.0:

https://trustedcomputinggroup.org/wp-content/uploads/TCG_Algorithm_Registry_Rev_1.24.pdf

I don't know if SHA1 can be marked as Legacy in a next
revision of the document.

Roberto


>> There's absolutely no need to pass digest size like you do BTW as it is
>> defined by the standard.
>
> For algorithms known to the crypto subsystem, that is fine, but for
> the unknown TPM crypto algorithms, we would need to somehow query the
> TPM for the digest sizes to create the mapping.
>
> Mimi
>
>> I also except that where ever this interleaves with trusted keys there
>> won't be duplicate structures and code.
>>
>> /Jarkko
>>
>

-- 
HUAWEI TECHNOLOGIES Duesseldorf GmbH, HRB 56063
Managing Director: Bo PENG, Qiuen PENG, Shengli WANG