Small update on this.
TL;DR:
It seems the bug is in software, either with the way tpm_tools calls the
TSS methods or in the TSS itself. I can show the raw output from the TPM
is correct, but the output of tpm_getpubek is still wrong. Root cause
unknown as of yet.
Full version:
The output directly from the TPM is OK. The driver (accessed directly via
/sys) generates it's output in that way. It is once the key structure is
in the TSS that the software calls to get key attributes return bad info.
In other words, the TSS calls to get attributes don't match what was in the
raw response. Therefore there are potentially bugs below, which I haven't
spotted yet, or in Tspi_GetAttribUint32(...)
(from tpm tools)
TSS_RESULT
getAttribUint32(TSS_HOBJECT a_hObject,
TSS_FLAG a_fAttr, TSS_FLAG a_fSubAttr, UINT32 * a_uiData)
{
TSS_RESULT result =
Tspi_GetAttribUint32(a_hObject, a_fAttr, a_fSubAttr, a_uiData);
tspiResult("Tspi_GetAttribUint32", result);
return result;
}
I compiled 0.3.13 with debugging and ran tpm tools tpm_getpubek, yielding:
TCSD TCS tcsi_key.c:286 Entering OwnerReadInternalPub
TCSD TCS tcsi_key.c:290 OwnerReadInternalPub: handle: 0x40000006
To TPM: 00 C2 00 00 00 3B 00 00 00 81 40 00 00 06 00 B8
To TPM: 29 B8 B7 37 A0 2A ED A6 A2 B8 EB A7 B3 C8 B7 33
To TPM: 39 9C 1B 32 D2 5D 00 F3 48 28 BC 1A AC BB 18 A8
To TPM: C1 38 4C A2 9E 30 6F E2 7D 40 EF
TCSD TDDL tddl.c:171 Calling write to driver
From TPM: 00 C5 00 00 01 4F 00 00 00 00 00 00 00 01 00 03
From TPM: 00 01 00 00 00 0C 00 00 08 00 00 00 00 02 00 00
From TPM: 00 00 00 00 01 00 XX XX XX XX XX XX XX XX XX XX
From TPM: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
From TPM: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
From TPM: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
From TPM: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
From TPM: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
From TPM: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
From TPM: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
From TPM: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
From TPM: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
From TPM: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
From TPM: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
From TPM: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
From TPM: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
From TPM: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
From TPM: XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
From TPM: XX XX XX XX XX XX A9 E7 F2 EB 02 9C BB 0C F8 D5
From TPM: 9B 13 27 CB 85 43 FB 63 BF 72 00 7D 01 8A 7D A8
From TPM: 53 53 69 DE 74 76 C7 1F C6 A7 76 06 56 54 8E
Alt-tabbing and Ctl-Fing through specs (fun!) leads to interpreting the TPM
response:
// TPM_TAG_RSP_AUTH1_COMMAND
00 C5
// Total number of output bytes (correct)
00 00 01 4F
// TPM_RESULT (SUCCESS)
00 00 00 00
// TPM_PUBKEY
// TPM_KEY_PARMS
TPM_ALGORITHM_ID
00 00 00 01 - RSA ***-> Correct <-***
TPM_ENC_SCHEME
00 03 - TPM_ES_RSAESOAEP_SHA1_MGF1 ***-> Correct <-***
TPM_SIG_SCHEME
00 01 - TPM_SS_NONE ***-> Correct <-***
parmSize
00 00 00 0C
parms
00 00 08 00
00 00 00 02
00 00 00 00 // zero exp length?
// TPM_STORE_PUBKEY
// Key Length
00 00 01 00
// PubEK
XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX
// TPM_NONCE (odd)
A9 E7 F2 EB 02 9C BB 0C F8 D5
9B 13 27 CB 85 43 FB 63 BF 72
// Continue auth session?
00
// TPM_AUTHDATA
7D 01 8A 7D A8 53 53 69 DE 74 76 C7 1F C6 A7 76 06 56 54 8E
Thanks,
Post by Ken GoldmanOr you could run trousers in verbose mode and examine the byte streams.
Good idea, I never tried that. I'll try it, maybe I can pinpoint what's
happening.
-Tadd
Post by Ken GoldmanIt does indeed look strange.
Post by Tadd SeiffThe only way I can think to get good properties is to bypass most of the
stack and send the TPM_OwnerReadPubek command straight to TCSD.
That's what I'd do.
Or you can experiment with the utilities that I ship with my software
TPM, which bypass Trousers completely and go directly to /dev/tpm0.
Or you could use trousers, but run them through the proxy that I ship
with my SW TPM and examine the actual byte streams.
Or you could run trousers in verbose mode and examine the byte streams.
Post by Tadd SeiffAny other ideas or thoughts on why these values are wrong?
No. Sorry.
At the TPM level, there is no actual getpubek or ownerreadpubek command,
so I can't even tell exactly what was running. It seems unlikely that
there would be a bug in the TPM tools at this point.
The ReadPubek command (probably what's running) is often disabled, so I
thought you might be missing an error code and dumping garbage.
However, if the public key is correct, that's unlikely.
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
TrouSerS-users mailing list
https://lists.sourceforge.net/lists/listinfo/trousers-users