Update crypto API to use a Microship secure element such as ATECC608A

[LizzieDE110]

I am working on boards that embed an ATECC608A (Microchip secure element), and I would like to perform all ECC/ECDH operations using it. This approach offers the benefit of enhanced security, as private keys are not directly manipulated.

Initially, I am working with RIOT. When I started looking for solutions to secure RF communication, I came across tinydtls and was convinced by its implementation of DTLS. I noticed some issues on my board (reported here Issue 224), and a PR to replace ecc with micro-ecc is now open (PR 229).

Micro-ecc works on my boards and significantly accelerates the handshake process. However, as mentioned earlier, I have an ATECC608A on my boards, so I would like to add a feature allowing users to choose whether to use it or not.

Since not all boards embed a secure element, I have added an environment variable (DTLS_ATECC608A) to give users the choice to use it or not. The CryptoAuth library is used to control the secure element (CryptoAuthLib).

This PR is still a work in progress, but I have opened it so that we can discuss and improve my work.

[boaks]

As short term work around, maybe.
But I guess, if a peer executes 2 handshakes simultaneously, that will fail.

[LizzieDE110]

CryptoAuthLib offers a mutex implementation. However, I suspect that if the handshake takes too long, a connection might fail due to timeout?

[boaks]

I still haven't been able to spend time into digging deeper. Other stuff, as Eclipse/Californium has consumed my free time and so I wasn't able to spend it into this.

Therefore just some rough ideas:

• I would try to "encode" the slot ID into the private key, e.g. 1. byte 1, 2. byte slot id, all others 0.
• for ECDHE the dtls_ecdsa_generate_key requires a dtls_ecdsa_release_key in order to do house keeping for the slots. (For the RAM only version, free the memory in dtls_handshake_free will work, for the HW, such an additional function called within that dtls_handshake_free will do the job for the client side)
• keep a list of used and free slots will enable the implementation to select a free slot when required.

That should do the job on the client side.

On the server that may cause pretty fast a DoS when all slots are used doing simultaneously handshakes with a couple of peers. Therefore I think, the ECDHE keys would be required to be exported to RAM and imported on usage. Not sure if that is possible.

[LizzieDE110]

1. I believe encoding the slot ID shouldn't be too difficult. I can give it a try.

2. I'm not entirely sure I understand your point. As far as I know, the keys are stored in the ATECC608A. I'm not convinced we need to free those keys. If we need to generate new keys, we can simply call the atcab_genkey function, which will overwrite the previous keys (assuming the slot is configured to allow it). The main advantage of the ATECC608A is that we don't need to store keys in our processor's RAM, especially with private keys that we can't read at all.

3. That sounds reasonable. However, my primary concern is that the ATECC608A can be fully personalized depending on the chosen configuration. With my proof-of-concept configuration, I only have two slots capable of performing a 'correct' handshake. Furthermore, because I locked the configuration zone to test my implementation, I can't change the device's configuration without obtaining a new one. Nevertheless, I can add accessors so that users can provide a list of slots rather than just one slot?

[boaks]

1. cool

2. there are two type of keys:

• the long term keys for ECDSA, they must stay in the ATECC608A.
• the ephemeral keys for ECDHE. This keys are generated at the begin of the handshake and then used once later in the handshake to generate the premaster secret. AFAIK, the ATECC608A has only a limited number of key slots. If, e.g. the implementation reserves 10 slots for ECDHE, only 10 handshakes in parallel are possible. That's also great for a client, because it's up to the client to initiate handshakes and not to overload the ATECC608A.
  For a server this will require to decide, what happens, if more than 10 clients want to do a handshake in parallel. A common idea will then be, to reject or ignore more handshakes. But that opens then a door for so called "exhaust attacks". Someone may start handshakes from several endpoints just to trigger the server to create ECDHE keys and block the slots. Once the server create the keys and sent the server key exchange, the attacker ignores further message, which extends then the time period, where the slot is blocked. Real clients will be faced to be rejected, because no free key slot is available.
  Anyway, this is just a consideration when used as server. I consider the ATECC608A be mainly used on the client side.

[boaks]

About 3.
I'm still not common enough to the ATECC608A. I would expect, that it provides the function to protect some key slots for ECDSA (some to identify the device, some for trusts to validate the other peers). It depends now on the intended usage. For a peer, which is intended to support a specific number of parallel handshakes, it requires to have free slots for the generated ECDHE keys. Even if that number maybe 1.

[Fl-Al-Ve]

This PR seems interesting.
Are there any updates on this topic?

[boaks]

Unfortunately, no.
Both projects, Californium and tinydtls, are not longer part of my professional/paid work and my free time is very limited. In Californium I started to switch to a new major release, that eats up the time for now. Using the micro-ecc already eliminates the time penalty, so I have to confess, that I don't know, when I will be able to spend time into it again.