MCUboot ECIES encryption

RE: MCUboot ECIES encryption

Richard R — Mon, 22 Jun 2020 12:39:33 GMT

Thanks Simon. I think I got it now. I will just do some experiments on my end to check.

RE: MCUboot ECIES encryption

Simon — Mon, 22 Jun 2020 07:04:39 GMT

I got some answers:

"MCUboot is only officially supported by us in NCS scope. There, this is only possible with mbed TLS (nrf_security) which is available"

"But in nRF5 SDK, it's possible to use the APIs he's talking about to do ECDH with curve25519 (which means we support x25519)."

Best regards,

Simon

RE: MCUboot ECIES encryption

Simon — Thu, 18 Jun 2020 13:28:45 GMT

I've forwarded your questions internally and currently waiting for an answer. However, I'll be gone tomorrow and will not be available until Monday.

Best regards,

Simon

RE: MCUboot ECIES encryption

Richard R — Thu, 18 Jun 2020 13:10:36 GMT

Hi Simon,

based on you last message, I was under the impression that you are following up internally on your side on the crypto backend?

Just so we are on the same page, I am trying to use the design from MCUBoot, but the codebase I am working on is based on nRF-SDK and its libraries.

On my front I have figured out that the SDK allows configuration of specific curves on the crypto engine and uses curve specific data structures (e.g. nrf_crypto_ecdh_curve25519_shared_secret_t)

I know that is driven by code and memory space saving.

I am hoping that this does not mean that it cannot compute ECDH shared secrets generated by other curve parameters. I am curious because the actual API to compute ECDH (nrf_crypto_ecdh_compute) seems to be curve agnostic (as in it does not need to be told the curve parameters itself).

hopefully the internal team can shed some light into this.

RE: MCUboot ECIES encryption

Simon — Thu, 18 Jun 2020 12:17:02 GMT

Have you gotten any progress on this? Have you figured out the question about the crypto backend?

RE: MCUboot ECIES encryption

Simon — Tue, 16 Jun 2020 00:44:28 GMT

I tried to investigate this a little, and I think I got a little smarter. I will share what I've figured out so far:

First you need to create a public key (pub_key_dev1) and private key (priv_key_dev1), the private key should be put inside ncs\bootloader\mcuboot\boot\zephyr\keys.c
- This is the public/private keyset belonging to the device and will not change
- This private/public keyset will be used to create the shared secret through the Elliptic curve Diffie Hellman method (ECDH). The ECDH method needs another public/private keyset (belonging to the deice/computer generating the DFU image), and this keyset will be regenerated (new unique key-pair) on every new image update.
Then, after you've created the public/private keyset (pub_key_dev1 and priv_key_dev1), put the private key in your software, create your product, and maybe a year later you want to do a DFU update, then you do the following:
- On your computer create the ephemeral (temporary) keyset (public key = pub_key_eph, private key = priv_key_eph)
- Then create a shared secret using the ephemeral private key (priv_key_eph) and the public key (pub_key_dev1) that correspond to the private key
  stored in ncs\bootloader\mcuboot\boot\zephyr\keys.c.
  - The same shared secret can be calculated later in the device as well using pub_key_eph (resides in the TLV area) and priv_key_dev1 (in keys.c)
- The key derivation method HKDF can now be used to generate 48 bytes of key material (the salt is the string "MCUBoot_ECIES_v1")
  - The same 48 bytes of key material can also be calculated in the device (MCUboot), since it has the shared secret and uses the same salt "MCUBoot_ECIES_v1"
  - Let's call this key_hkdf
- Then, on the computer you create a new random AES encryption key of 16 bytes (priv_key_AES)
- Next, you encrypt the payload of the image (the executable firmware/code) using that key (priv_key_AES). The header and the TLV area is not encrypted as stated here:
  - "When encrypting an image, only the payload (FW) is encrypted. The header, TLVs are still sent as plain data."
  - As you can see here, the header is stored
    first followed by the payload, and the TLV area is placed at the end, after the payload
- Then you encrypt this key (priv_key_AES) using the keys derived from the shared secret (key_hkdf):
  - "The key is encrypted with AES-128-CTR and a nonce of 0 using the first 16 bytes of key material generated previously by the HKDF."
  - "The encrypted key now goes through a HMAC-SHA256 using the remaining 32 bytes of key material from the HKDF."
  - The aes key (priv_key_AES) is now encrypted. Let's call it priv_key_AES_cipher
- The ephemeral public key (pub_key_eph) and the ciphered AES key (priv_key_AES_cipher) should be placed in the TLV area of the image that should be sent to the device through DFU.
- When the device receives the image, it can now calculate the shared secret (using priv_key_dev1 and pub_key_eph) and get the key key_hkdf, which can be used to decrypt the priv_key_AES_cipher (in the TLV) to get the AES key (priv_key_AES) to decrypt the image.
  - All this is implemented in MCUboot.
  - Look at the function ncs\bootloader\mcuboot\boot\bootutil\src\loader.c-->boot_image_check()-->boot_enc_load()-->boot_enc_decrypt() which is used to get priv_key_AES
  - Look at the function ncs\bootloader\mcuboot\boot\bootutil\src\image_validate.c-->bootutil_img_validate()-->bootutil_img_hash()-->boot_encrypt(), which is used to decrypt the image payload.

Be aware that I am still learning this, and this answer may contain errors/misunderstandings. I've not looked into the practicalities of this and how to actually do this, but if you have problems with this, don't hesitate to ask and I will look into it.

Regarding your question about crypto backend, I will ask internally about this and get back to you.

Best regards,
Simon

RE: MCUboot ECIES encryption

Richard R — Mon, 15 Jun 2020 13:10:45 GMT

Thanks for the follow up Simon. I have been reading the material in nrf_crypto sections of the product spec as well and I think it has began to illuminate my understanding. I think the HKDF is performed on both the image-generator and the bootloader receiving the encrypted image and they need to compute to the same 48-byte key material. Will be doing experiments today to confirm.

Also, If you can help me, also pass along this question internally. In the nrf_crypto section, what does it mean when a specific crypto backend "supports" a specific elliptical curve (e.g. secp256r1) - if I pick for example nrf_oberon as a backend, can it not do operations with `secp256k1`?

RE: MCUboot ECIES encryption

Simon — Mon, 15 Jun 2020 08:11:50 GMT

Hello, I'm currently looking into your issue. I'm not too familiar with this topic but will investigate/ask internally and try to provide you with an answer today/tomorrow.

Best regards,

Simon