Re: [pkix] More fun and games with the Trusted Platform Module

Michael StJohns <msj@nthpermutation.com> Wed, 14 February 2018 18:18 UTC

Return-Path: <msj@nthpermutation.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 344F212D7F8 for <pkix@ietfa.amsl.com>; Wed, 14 Feb 2018 10:18:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJjww9VtxuKz for <pkix@ietfa.amsl.com>; Wed, 14 Feb 2018 10:18:13 -0800 (PST)
Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 592B8126D45 for <pkix@ietf.org>; Wed, 14 Feb 2018 10:18:13 -0800 (PST)
Received: by mail-qt0-x22a.google.com with SMTP id q18so8851158qtl.3 for <pkix@ietf.org>; Wed, 14 Feb 2018 10:18:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=CZoyBzxRivdg2xcRgZ68416xShjsbx4cDvknRjgQGGM=; b=MPltmJJXnoPwUAtbvvbhRQzJWQPYOX6/prRvd0CV7yTasnCVgYSonA8axvEIAzeeyn 6pvrkW76IPnxPqvt29P9TpFuSES/89/Hxj+Jjb06JN2NLKvHktVbS+I5H/TGhMpSntXY a2AUwA3oTyjaO8T8MfqbXeCF0WciuN8e2QLRl6F1OtUpPoYFte6W1X2IrNRFYxJDm9e9 0Kg6P5+t6sF+q8libhTpwC05/REWe3SVLJJJOH99h4l8KtXtcdN9b7Y9NYxCMJbc3RjC D+nB94ImHQAc0NZfOvFzzL7Q7g+YWaVmBJRKUg5fIwVnboL4F/J/4qDPDH5+1wZXHdiE 0pYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=CZoyBzxRivdg2xcRgZ68416xShjsbx4cDvknRjgQGGM=; b=NTVzpwAWZoZpeK+akCWBeQoowxfd4AVnsZruzfF52ds7T3Vd/bZWwH6I46lQlJ6Wpw oRpCqcMOYSJMAyVhOGUtQatZXF9gDPfFvtC0DleuYQh7yKLxIp6V5FIwL0diprj1LQbD 3Tj3366LGOR54QlbEjHRRJPgModio5SWLHJCa0xkIQEg1i2ejnBaPAk2GE4OK1f0qUpm eiUf1AItJZjgiDvQihFZt7PLU4yW2KS0BvKFb4wAkFpyR6vTOR1msKOPofw2ER15jnqM 5wxCeC6p/zA7YoNUaqGcim33YNC/kQMAYSjuMcjg+GF5aM0wzVC4sJHoCLeyE3zSxqaL RX2w==
X-Gm-Message-State: APf1xPBUpNWYGClZ+4ZSg+UOM5EZbRIYMxThPWTD935kFOf0ooqvR+qt zBaqTLBtzlnQU0b15bBrQ6GUWK00
X-Google-Smtp-Source: AH8x2266Oa3xN4rJ1W7PX37AyNbRhApcSwa6c74aD6hiYSKGGZGytqBeGK1m9hPFp+uwZl5jrdc41Q==
X-Received: by 10.237.37.161 with SMTP id x30mr132091qtc.78.1518632291886; Wed, 14 Feb 2018 10:18:11 -0800 (PST)
Received: from ?IPv6:2601:152:4400:4013:e9e7:96e3:32d5:6c0e? ([2601:152:4400:4013:e9e7:96e3:32d5:6c0e]) by smtp.gmail.com with ESMTPSA id r53sm10411618qtr.57.2018.02.14.10.18.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 14 Feb 2018 10:18:10 -0800 (PST)
To: Russ Housley <housley@vigilsec.com>
Cc: IETF PKIX <pkix@ietf.org>
References: <3a8caf8a-0273-afd2-dc28-09053c36842e@nthpermutation.com> <E3AB87D0-6957-4C7B-A01F-70265BEDA276@vigilsec.com>
From: Michael StJohns <msj@nthpermutation.com>
Message-ID: <5b396732-824b-c865-d945-a92b3a609ef3@nthpermutation.com>
Date: Wed, 14 Feb 2018 13:18:00 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <E3AB87D0-6957-4C7B-A01F-70265BEDA276@vigilsec.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/Nm3lbjAzu_LmUzDoRshg98uShyc>
Subject: Re: [pkix] More fun and games with the Trusted Platform Module
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Feb 2018 18:18:15 -0000

On 2/14/2018 12:08 PM, Russ Housley wrote:
> So, the INTEGER is not being properly DER encoded before it is stored.  I assume the signature covers the leading zero octet.
>
> Russ

Correct (not properly encoded before storage) and correct, the signature 
appears to cover the leading 0 given the certificate encoding.    What 
I'm probably going to do is write code to parse the top sequence, verify 
the signature and then attempt to patch the toBeSigned portion (changing 
2 length values and deleting the 0), and then running that through a 
parser.   I'll have a better idea then, but my guess is that the 
certificate issuer did this on the cheap - a single fixed template where 
he could place a few values and then ran that through signing.

It's not pretty, but guess is there are a lot more of these in the 
wild.   (This TPM is in a Lenovo T560 - about a year old).

I also end up patching the subjectPublicKeyInfo replacing the RSA-OAEP 
oid with just the normal RSA oid.  Most of the providers have no idea 
about the OAEP oid meaning.

Up until a few revs ago, the BouncyCastle libraries ignored this issue: 
I was using BC to re-encode badly encoded ECDSA signatures from java 
cards (the code would prefix a zero if the integer had a high bit set, 
but isn't smart enough to remove leading zeros if the signature R or S 
value encoded shorter.) BC would accept poorly encoded integers, but 
re-encoded them properly.  The "fix" to BC broke this.  The Java 
Certificate library also chokes on the leading zero.

Mike


>
>
>> On Feb 13, 2018, at 8:56 PM, Michael StJohns <msj@nthpermutation.com> wrote:
>>
>> Hi -
>>
>> I thought I'd pass on a discovered stupidity.   As part of some playing with TPMs I found out that the endorsement certificate for my personal laptop has an invalid encoding.  For some unknown reason, my certificate was mis-encoded with a leading zero byte in the serialNumber field.  My best guess is that the manufacturer is mistakenly treating the serialNumber as an OCTET STRING and just plopping down the serial number of the TPM in the body of the INTEGER.
>>
>> Unfortunately, the certificate parsers I'm using barf on this.....  I'm having to basically write my own code to handle these...
>>
>> serial:
>>
>> 02 14
>> 00 04 8f e6  1d 28 82 d3  cd 48 8a b1  30 b9 4f bc
>> 8928 4b 32
>>
>> According to the TPM console, this is an intel TPM, V2.0, spec 11.8.50.3425.
>>
>> I went looking and I have no contacts with Intel in this space - I'd at least like to make them aware they are screwing up in at least one case.  Does anyone have a pointer?
>>
>> Thanks - Mike
>>
>>
>> _______________________________________________
>> pkix mailing list
>> pkix@ietf.org
>> https://www.ietf.org/mailman/listinfo/pkix