Add key generation for private encryption key

[Wika-Group-IIoT-RD]

Current Implementation

In the default Mcuboot implementation, the private key used for firmware decryption is compiled directly into the bootloader binary.

• The key pair is generated externally (e.g, on a production machine).
• The public is used to encrypt the firmware image.
• The private key is embedded in the bootloader and used to decrypt and verify the firmware during boot.

New functionalities in this PR

During the first boot, the microcontroller automatically generates a key pair. The process includes:

1. Secure random number generation using hardware TRNG (True Random Generator).
2. ECC key pair creation (SECP256R1) using the mbedTLS library.
3. Conversion of the private key to DER format following the PKCS#8 standard.
4. Conversion of the public key to PEM format for export.

The private key remains stored in a secure area of the microcontroller and is never exposed. The public key can be retrieved during the update.

[de-nordic]

No. Heh, I did not even see feature proposal for that in issues.

I am not sure whether description in this PR is just making shortcuts, but as far as I can tell AES is used for encryption, ec255 is used for encryption key exchange using DH.

Anyway, my main issue with the PR: if you have a way to ask a device for a key on the first boot, that has been written by a device itself to itself, you have a way to provision one of the pair you generate outside of a device and just obliterate the original private key.

And why bloat the device into certificate generator, by adding the der and pem encoder.

[Wika-Group-IIoT-RD]

@de-nordic we reached out to David on Discord regarding this topic, and he suggested opening a PR.
About the PR:
MCUboot uses the Elliptic-Curve Integrated Encryption Scheme (ECIES), which relies on Diffie-Hellman (DH) to establish a shared secret. This shared secret is then used as the AES key to encrypt the firmware.

For ECIES, each device needs its own key pair. Currently, these key pairs are generated by the imagetool (we refer to them as “encryption keys” for simplicity). The private key is compiled into the bootloader code via the key.h file.

This approach means that once the bootloader is compiled, all devices flashed with that image share the same encryption key pair. In a large fleet of devices, having identical encryption keys is a significant security concern.

To address this, we decided that each device should have its own unique encryption key pair. There are two possible approaches:

1. Build a separate bootloader image for every device with a different key embedded.
2. Enable the device to generate its own key pair during initialization.
   The PR focuses on the second approach: device-side generation of the encryption key pair.

The idea is to generate the encryption key pair during the first boot of the device, store the private key in a secure key storage unit inside the chip, and expose the public key over a secure production interface.
Since storing and exposing the public key is chip/solution-dependent, this part is not included in the PR.

[Wika-Group-IIoT-RD]

@de-nordic If I understand your concern correctly, it’s about preventing the device from generating a new key pair on the next boot?
The PR does not introduce any mechanism to provision keys from the outside. The idea is that the device generates a key pair internally during its first boot and then exposes only the public key for encryption purposes. The idea was that the key generation inside the device is a strictly one-time function. Meaning when the device generates the key once during boot it will skips the key generation step on all subsequent boots.

If i get it wrong please correct me