Infineon / optiga-trust-x

OPTIGA™ Trust X Software Framework
MIT License
37 stars 19 forks source link

Using Trust-X for 1-way MQTT Authentication #35

Closed lauleehong closed 4 years ago

lauleehong commented 4 years ago

Hello,

I'm exploring and experimenting the use of the Optiga Trust-X on my custom device to do a MQTT over TLS connection with 1-way authentication for high-security risk systems to our cloud platform. We are using mbed-os (and the included mbedtls) for our rtos library.

The current implementation (used for low-security risk systems) are as follows:

  1. Generate a RSA key-pair on the MCU.
  2. Store the Public and Private Key in Flash Memory.
  3. Use the Public Key to generate a Certificate Signing Request (CSR).
  4. Send the CSR to the cloud platform, which would issue the device with a client certificate (using RESTful APIs).
  5. Use the (i) private key, (ii) client certificate, (iii) CA certificate (obtain via REST) to establish a TLS connection to the mqtt cloud server.

I'm thinking of using the Trust-X to store the private/pub key and perhaps even generate it using ECDH on the Trust-X itself, after reading through the documentations. Problem is, I see that based on the comment in https://github.com/Infineon/optiga-trust-x/issues/12#issuecomment-502134838 , it seems I can't read out the private key that will be used to establish a TLS connection.

Thoughts on this application of trust-x?

ayushev commented 4 years ago

Hi @lauleehong sorry for the long answer.

If I udnerstood your request correctly you would like to use RSA based certificate for the TLS session establishemnt. The ciphersuite is based as ECDHE key-deriviation algorithm. Is this correct?

YOu idea is to store the private/public RSA keys on the Trust X. YOu also have in mind to use the Trust X to support the ECDH. ECDH is a three steps process, first you generate a new keypair (ECC), and send the public key to the counterpart, second you receive the public key of the counterpart. Third you run ECDH on the Trust X chip giving to the optiga_crypt_ecdh function public key of the counterpart, your private key (reference to it) and the buffer where you would like to get shared secret. In this case you don't need to read the private key from the chip.

I would like as well to point you here you might find a file which helps to offload the ECDH to the secure element. It is seamlesly integrated into mbedtls.

If you would like to offload completly TLS using both RSA and EC/ECDH you might have a look on OPTIGA Trust M. It has also full mbedTLS support https://github.com/Infineon/mbedtls-optiga-trust-m

lauleehong commented 4 years ago

@ayushev thanks for the reply. My team came to conclude that this would require a rewrite of mbed-os's TLSSocket to support this secure element. I understand from mbed-os team that this feature is being looked at, and will be expected to release end-2020/early-2021.

ayushev commented 4 years ago

Hi @lauleehong I don't know details of your particular implementation and usege scenario, but in general this isn't required.

  1. mbedTLS is the library used by the mbedOS to support the TLS communication.
  2. mbedTLS implements the TLS communication by calling individual crypto functions
  3. mbedTLS does support flexibel substitution of these functions by any other implementation, as such hardware.
  4. Generally it is a matter of one macro in the mbedTLS config to switch from software implementation to hardware.
  5. In other words, generaly you don't need to change any line of code neither in mbedTLS nor in mbedOS to make it work

What is supported currently Trust X

  1. ECDSA Signature generation and verification
  2. ECDHE keypair generation and shared secret (key) deriviation
  3. Rnadom Number generation

Trust M

  1. All mentined above
  2. RSA Signature generation/verification
  3. RSA keypair generation

This Section and this figures can give you better overview on how this is integrated.