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

[Michael StJohns <[e-mail]>]

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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/pkix