On Sat, 2024-08-03 at 22:31 +0300, Jarkko Sakkinen wrote: > On Sat Aug 3, 2024 at 8:51 PM EEST, James Bottomley wrote: > > On Sat, 2024-08-03 at 20:08 +0300, Jarkko Sakkinen wrote: > > > On Fri Aug 2, 2024 at 11:25 PM EEST, James Bottomley wrote: > > > > Now that we're going to be using the NULL primary to salt > > > > sessions, the Intel TSS shim needs fixing to cope with this. > > > > In the Intel TSS, there are two internal handles representing > > > > NULL: ESYS_TR_NONE and ESYS_TR_RH_NULL. We translate > > > > TPM_RH_NULL to ESYS_TR_NONE because > > > > > > Can you split this into two paragraphs. > > > > > > I'm lost why it has two representations. > > > > Well, I actually have no idea why the Intel TSS has two > > representations for *every* handle: an internal one (specific to > > the TSS) and an external one that everyone uses, like 81000001 or > > 40000007. As far as I can see it just adds pointless complexity to > > the coding. The IBM TSS only has one, so for code which works with > > both, the shim has to transform between internal and external > > handle representations before sending the command onward to the > > Intel TSS. > > Is it possible to address this complexity and move into a single > representation? I.e. use external presentation all the way. Yes, that's what the current code does. It began life as pure IBM TSS so it used what the Intel TSS would consider as all external handle representations. The external to internal shift (and back) happens inside the TSS shim. > > Even more mysteriously the Intel TSS has three representations for > > the NULL handle: an internal one, an external one (40000007) and > > one you use for an empty session (ESYS_TR_NONE). The IBM TSS uses > > TPM_RH_NULL for all three so you can't just translate from external > > to internal you have to know if you're using the handle for a > > session or a hierarchy as well. > > Same question applies to this too. Remember this is just fixing the Intel TSS Shim. The fact that we have to use three different handles for NULL isn't visible outside the shim, so a consumer of these APIs just uses TPM_RH_NULL everywhere. The fix is that the Intel TSS Shim was using the wrong handle for some operations. > > > James > > I'm doing my own TPM2 stack with Rust, which just re-implements the > functionality of my old tpm2-scripts and tpm2.py module as nice small > app called tpm2-cli. > > It will be more use case based interface than than protocol spec as > a software interface. Main goal for now is to get this whole flow > into it (with varying parameters for the key) as single function: > > tpm2_createprimary --hierarchy o -G ecc -c owner.txt > tpm2_evictcontrol -c owner.txt 0x81000001 > openssl ecparam -name prime256v1 -genkey -noout -out private.pem > tpm2_import -C 0x81000001 -G ecc -i private.pem -u key.pub -r > key.priv > tpm2_encodeobject -C 0x81000001 -u key.pub -r key.priv -o > key.priv.pem > openssl asn1parse -inform pem -in key.priv.pem -noout -out > key.priv.der Well, that's simply the library API. That's actually what the IBM TSS uses. I think the Library API is by far the simplest TPM API to use, so beyond trying to sort out the complexity of getting a compatibility shim I've not really used the Intel TSS. I think the Intel TSS is based on the ESAPI document which introduces the handle conversion complexity. I haven't read the ESAPI spec, I just tried to reverse engineer it (from the source) into supporting an API which can be compatible with the library spec/IBM TSS. James
