1 Reply by gotthardp

(8 replies, posted in wolfTPM)

Hi Dimi,

Thank you. It is meant for cellular routers, embedded Linux based IoT devices.

The statement concerning NULL signature scheme I am referring to is in the Part 2 of the TCG specification, section 12.2.3.5 (TON_RSA_PARMS), Table 186 as a NOTE for the scheme parameter. It says "shall be", moreover the TPM TSS tools and the TPM itself I have is refusing to have non-NULL scheme on a combined key.

Kind Regards,
Petr

Go to forum: wolfTPM

2 Reply by gotthardp

(8 replies, posted in wolfTPM)

Hi Dimitar,

Short answer: With the key in the TPM, I want to use WolfSSL to generate a CSR (signed by that key) and then use the generated key+certificate in strongSwan.

Long answer: I'd love to have a single secure device identity key (IEEE 802.1AR's DevID), a single PKI tool that is able to create a CSR, get the certificate enrolled via EST and then use the key+certificate to prove device's identity in both SSL and IPsec/strongSwan communication.

Facts:

  • TCG guidance for DevID's recommends using a restricted signing key and discourages (with reference to NIST SP800-57) the use of combined (signing and decryption) keys.

  • Restricted signing key can(!) be used for signing external data, but only when the TPM hash function is used, which generates a ticket to be fed to the sign operation.

  • The ticket-based sign operation is incompatible with OpenSSL (and also WolfSSL?), so these don't use it and sign using the Decrypt operation, which requires a combined (signing and decryption) key.

  • TCG TPM specification says the combined (signing and decryption) keys shall not be restricted and shall use the NULL signature scheme.

  • strongSwan reads the key scheme and hash algorithm from the key information, i.e. expects the signature scheme and hash to be non-NULL.

Boom. My conclusion is that I cannot use Open/WolfSSL to generate keys for strongSwan and I cannot use the strongSwan generated keys with Open/WolfSSL. These are incompatible when TPM based.

Based on the NIST and TCG guidance available I tend to think that the way strongSwan behaves is correct and the reason for this incompatibility is caused by the descrypt-based signing. Unless I am wrong in my reasoning, the idea of a secure device identity will not work without the ability to sign data using a restricted signing key, which is a quite sad situation.


Kind Regards,
Petr

Go to forum: wolfTPM

3 Topic by gotthardp

(8 replies, posted in wolfTPM)

Hello,

In the examples (CSR, TLS) I discovered that the RSA key created for signing is both signing and decryption key, which per the TCG specification must not be restricted. When I tried using a restricted signing key instead (made using wolfTPM2_GetKeyTemplate_RSA_AIK), I got the "TPM2_RSA_Decrypt failed" error. I suspect this is because wolfSSL signs using the Decrypt operation. OpenSSL does the same. This means that (due to this hack) a restricted RSA signing key will not work for signing operations using wolfTPM/SSL (nor OpenSSL). Am I right?

The situation feels quite sad because the TCG TPM Provisioning Guidelines introduce various attestation and identity keys AIK/IDevID/LDevID, which are required to be restricted signing keys.


Kind Regards,
Petr

Go to forum: wolfTPM