One of the things I have found is that if I encrypt something on a real TPM and try do decrypt it on the TPM simulator, it doen't work - and vice versa in all combinations. I'm talking RSA here. I find that all instances of the real TPM will talk to one another, and all instance of the simulated TPM will talk to one another. Is this deliberate, or is something strange doing on? The real TPM in question is on an Intel NUC5i3MYHE.
Last edit: Nigel Hathaway 2018-03-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have tested the 'vice versa", encrypting on a SW TPM and decrypting on three vendor HW TPMs, as part of the MakeCredential / ActivateCredential protocol. This uses the endorsement key, both RSA and ECC. But I haven't tested with the Intel part.
The fastest path is if you can send a failing test case using the TSS utility scripts. Otherwise, send me the detailed key attributes, and I'll try to reproduce it.
A few more questions:
This sounds like a TPM issue, not a TSS issue, right?
Does it fail with other HW TPM vendors, or just Intel?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did a simple test based off your testrsa.sh, and the simulated and real TPMs did inter-operate. For a given identical imported openssl RSA key, both sides produced the same enc.bin file.
There must be something strange going on in the wider context of our application.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Agreed. In the end it was found to be due to the way different versions of openssl generate AES keys from passwords. We were using a TPM-RSA-encrypted packet to store the AES key password used in transferring data, which generated different AES keys at the sender and the receiver (which ran different openssl versions). (Generating the AES key did not involve any TPM operations). So this issue had nothing to do with the TPM. I am putting this here to warn people not to generate AES keys using passwords on openssl. Always give openssl the key and IV directly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One of the things I have found is that if I encrypt something on a real TPM and try do decrypt it on the TPM simulator, it doen't work - and vice versa in all combinations. I'm talking RSA here. I find that all instances of the real TPM will talk to one another, and all instance of the simulated TPM will talk to one another. Is this deliberate, or is something strange doing on? The real TPM in question is on an Intel NUC5i3MYHE.
Last edit: Nigel Hathaway 2018-03-31
I have tested the 'vice versa", encrypting on a SW TPM and decrypting on three vendor HW TPMs, as part of the MakeCredential / ActivateCredential protocol. This uses the endorsement key, both RSA and ECC. But I haven't tested with the Intel part.
The fastest path is if you can send a failing test case using the TSS utility scripts. Otherwise, send me the detailed key attributes, and I'll try to reproduce it.
A few more questions:
This sounds like a TPM issue, not a TSS issue, right?
Does it fail with other HW TPM vendors, or just Intel?
The Intel NUC in question uses the Infineon SLB9665TT2.0 as its TPM. Is this one of the parts you have tried? (See https://www.intel.com/content/dam/support/us/en/documents/boardsandkits/NUC5i3MYBE_TechProdSpec.pdf page 44)
I will do some further tests and get back to you.
Yes. We use the SLB9665 rev 116 Firmware: 00050032 0007e600.
Hmm... strange.
I did a simple test based off your testrsa.sh, and the simulated and real TPMs did inter-operate. For a given identical imported openssl RSA key, both sides produced the same enc.bin file.
There must be something strange going on in the wider context of our application.
I'll consider this thead suspended. Please repost if you discover the issue.
Agreed. In the end it was found to be due to the way different versions of openssl generate AES keys from passwords. We were using a TPM-RSA-encrypted packet to store the AES key password used in transferring data, which generated different AES keys at the sender and the receiver (which ran different openssl versions). (Generating the AES key did not involve any TPM operations). So this issue had nothing to do with the TPM. I am putting this here to warn people not to generate AES keys using passwords on openssl. Always give openssl the key and IV directly.