Skip to content

Conversation

@Wika-Group-IIoT-RD
Copy link

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.

Copy link
Collaborator

@de-nordic de-nordic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants