Re: More fun and games with the Trusted Platform Module
Michael StJohns <[email protected]>
| Newsgroups | gmane.ietf.x509 |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/pkix _______________________________________________ pkix mailing list [email protected] https://www.ietf.org/mailman/listinfo/pkix