Closed kuhlmannmarkus closed 2 years ago
AndreasFuchsTPM
commented
3 years ago Said integer is the TPM2_HANDLE of the parent key. It is actually a UINT32 starting with 0x81?????? i.e. the most significant bit is set. In the PEM format this is encoded as a signed integer and thus interpreted as a negative number by ASN.1 parse. But that is not a problem afaik.
I guess this is a bug in tpm2_ptool that should be fixed there.
kuhlmannmarkus
commented
3 years ago Hi @AndreasFuchsSIT Thanks for the quick reply! Exactly: I tried to set 0x81000001, since this is predetermined by go-attestation. I will try to move this issue to tpm2_ptool.
niooss-ledger
commented
3 years ago Hi, I tried to reproduce the issue, and on my system (x86_64 Arch Linux), openssl asn1parse yields:
0:d=0 hl=4 l= 531 cons: SEQUENCE
4:d=1 hl=2 l= 6 prim: OBJECT :2.23.133.10.1.3
12:d=1 hl=2 l= 3 cons: cont [ 0 ]
14:d=2 hl=2 l= 1 prim: BOOLEAN :1
17:d=1 hl=2 l= 5 prim: INTEGER :81000001
...Looking at the hexadecimal dump of go-key.pem (with cat go-key.pem | grep -v '[-]' |base64 -d |xxd), I see near at offset 17: 02 05 00 81 00 00 01. This is the encoding for a 5-byte integer 0x0081000001, which is why asn1parse sees 0x81000001 and not -7EFFFFFF. As said in a previous comment, -7EFFFFFF is the value encoded by 81 00 00 01 (or more precisely, by the ASN.1 object 02 04 81 00 00 01 in DER notation). This can be verified with:
$ echo "02 04 81 00 00 01" |xxd -p -r |openssl asn1parse -inform DER
0:d=0 hl=2 l= 4 prim: INTEGER :-7EFFFFFFNow, why would tpm2tss-genkey create files with -7EFFFFFF on some machines and 81000001 on others? The code responsible to write this value is in function tpm2tss_tpm2data_write: https://github.com/tpm2-software/tpm2-tss-engine/blob/89327fa8b51962348c46ddc659fb8c3636336a60/src/tpm2-tss-engine-common.c#L175
As documented on https://www.openssl.org/docs/man1.1.0/man3/ASN1_INTEGER_set.html, ASN1_INTEGER_set takes a long value as parameter. On some systems (like 32-bit CPU), long are 32-bit integers, so in fact ASN1_INTEGER_set(tpk->parent, tpm2Data->parent); is setting a 32-bit signed integer. But parent is of type TPM2_HANDLE, which is unsigned 32-bit integer.
TL;DR: tpm2tss_tpm2data_write behaves differently between systems where long are 32-bit integers and those ones where long are 64-bit integers. Is this a bug which should be fixed in tpm2-tss-engine, or should all consumers of serialized keys cast parent to unsigned 32-bit integers, or both?
williamcroberts
commented
3 years ago So IIUC the root cause is that if the PEM file is generated on a 32 bit system, the ASN1 integer is getting represented as a signed value (since the top bit is high) in Python over the C code since it casts it to an unsigned 32 bit value (TPM2_HANDLE), is that correct thus far?
Secondly the fix linked in here (#222) is correcting the encoding of the ASN1 integer so it's always positive . Ie will be a length of 5 with the leading 00 followed by the handle?
Hi all,
Im using
tpm2tss-genkeyto derive a PEM representation from some key material I generated via https://github.com/google/go-attestation. Therefore I export the public and private portions according to https://github.com/google/go-tpm/issues/233 and then dotpm2tss-genkey -u pubktpmmarshal -r pktpmmarshal -P 0x81000001 go-key.pem. The key generally seems fine, but I found that the parent part probably has an overflow.cat go-key.pem | openssl asn1parseyields:I intend to link this key to a token in https://github.com/tpm2-software/tpm2-pkcs11 with
tpm2_ptool, but since the parent is faulty, I get (tpm2_ptool link --path /usr/share/tpmpkcs11store --label=mytoken2 --userpin=myuserpin --key-label="link-key" go-key.pem):Any help is appreciated. Thanks in advance!