Write Ecc key or Rsa key to kmu

[Tide]

In v1.4.0 SDK, AES key can be written into kmu slot, but there is no related function for ECC key and RSA key in crypto/nrf_cc310_mbedcrypto/include/mbedtls/cc3xx_kmu.h file. Does the V1.4.0 SDK support writing ECC key or RSA key to kmu?

[Einar Thorsrud]

Hi,

The answer is unfortunately "no". The KMU consists of 128 bit key slots. You can combine more slots in order to store larger keys, so that part is no problem. However, you cannot push ECC or RSA keys to the CryptoCell peripheral, so you would have to make the keys readable in order to use them, making in not so useful in this case.

[kratenko]

Hej Einar,

I am just trying to do the same thing, so my question is, are there plans to do this in the future?

We are using DTLS over the Modem, but I need to do it via wired communication as well. I would hate do put my private key in a place where it can be read out. As things stand, it is securely inside the modem's key store, where it cannot be read. But that does not help me when not using LTE. I would also be fine with having a way to let the modem do it for me; I pass data there, tell it, which key from it's store to use, and let it return the ciphertext.

Right now, all I will be able to do, is pass the key to mbedtls myself, which will mean that anyone with physical access to the device will be able to read it out, if they know what they are doing. I don't want to add an external secure module to our hardware, when we have a cryptocell ready in our main processor.

[Einar Thorsrud]

Hi,

With regard to KMU and CryptoCell, the key problem here is that it is not possible to push an asymmetric key from the KMU to CryptoCell directly, and this is a limitation in the HW so that cannot be changed.

There are other mechanism that can be used to provide the key, though. With TF-M, you have Internal Trusted Storage (ITS) where the keys are protected in secure domain and not accessible to a non-secure application (see demonstration in Crypto: Persistent key storage). TF-M is still experimental though, and this does not prevent the key against an attacker with physical access that is somehow able to dump the flash content.

Another option is to use a symmetric key in KMU that is pushed to CryptoCell (typically a HW unique key), and derive a key from there. See Hardware unique key.

[kratenko]

Thanks for the quick response.

Yeah, I was afraid, it was a hardware limitation, but good to know for sure. TF-M is not really a thing for us, since we are using our own system with out own secure and non-secure firmware. Would not give us any benefit over doing our own solution, if I understand TF-M correctly.

I guess we will go for the symmetric key approach, even if that does not prevent anyone with access to the device from extracting the private key - it just makes it more complicated, some form of Security by Obscurity.

But I guess there is no other way then.

[Achim Kraus]

Maybe, you can use the "secured" symmetric key to store the asymmetric private key encrypted. That requires to decrypt the asymmetric private key only temporary and the use it for the signature in the handshake and clean it up afterwards. That maybe considered still as a critical window, but it is usually very short.

[kratenko]

The problem is not, that the key is in memory, but that anyone with access to the device, could install firmware on it, that does exactly the same, to extract the private key. Granted, you would need a lot of information about the device, but that is why I see it as security by obscurity.

[Achim Kraus]

I assumed, that you consider the KMU to address that usage of keys by other firmware.

If so, then the other firmware can not access the symmetric key of the KMU, which is required to use the asymmetric key,

[kratenko]

That is the point. I can put aes-keys in the kmu, where I can use them for en-/decryption without ever being able to read the key out myself, so there is no risk of the key ever becoming known. This is not the case for ECC. I will need it in software, so there is no way to have it not readable with this crypto cell. So there will always be a way to extract it, which is what I was trying to avoid. I can only make it hard to do.

[Achim Kraus]

So, it's not about someone may misuse the "keys", it's more, that someone gets access to it and misuse it in a larger scale.