Re-writing of flash on every boot by xProvisionDevice?

[apullin]

Is your feature request related to a problem? Please describe.
It looks as though the demos, at least in their implementation for the STM32L475 platform, will erase and write a chunk of flash memory as part of xProvisionDevice on every bootup.

As far as I understand it, these are the DER format of the key and certificate, as they are parsed from PEM format.

Later, this value is used via the PKCS11_PAL_GetObjectValue port, as part of TLS_Connect.

Is this really the correct behavior, that a key that is already stored in flash (via macro) is then parsed and saved into flash again, and that same piece of flash is erased and rewritten at every startup?

While the guide for "Porting the corePKCS11 library" does state:
Cryptographic objects should be stored in a section of NVM that is not initialized and is not erased on device reprogramming

it seems like the application (demo) itself is intentionally not leveraging that, and is built around vDevModeKeyProvisioning.

Describe the solution you would like.
Some clarification or guidance of what a "production ready key provisioning mechanism", as referenced in a comment in aws_dev_mode_key_provisioning.c, should look like, insofar as the handling of keys and certificates, and the setup steps that could/would replace the choices made in Dev Mode key provisioning.

Is reflashing the area for the DER at each bootup the correct & expected behavior?
When should new PKCS objects be created, and when should they be destroyed?
Should a device never store the PEM format of its key or certificate?

Additional context
This is all done from the SDK/repo unmodified, targeting the STM32L475 IoT Node board.

FWIW, in a code base that I inherited, this was also apparently unclear enough that the application, as derived from the demo, is all built around the use of Dev Mode key provisioning. Although, the linking was not set up to put the UNINIT section into flash, so P11KeyConfig ended up in RAM, and DER format keys were being stored there. But, since they are re-pared and regenerated on every bootup, it all worked out.

Thank you!

[lundinc2]

Hi @apullin,

Sorry for the confusion regarding this part of the codebase. We are working to improve this facet of Amazon FreeRTOS. As the code explains (And you correctly already pointed out!) it is not meant to be used in production.

There are several approaches to provisioning, and a lot of those decisions rests with the design goals / threat model of your application. A good resource for some advice on provisioning can be found in this white papers: https://d1.awsstatic.com/whitepapers/device-manufacturing-provisioning.pdf?did=wp_card&trk=wp_card.

To answer your questions:

1. The reflashing is okay for development, but is not behavior that is desirable in a production environment.
2. The PKCS Long wait on MQTT Connect #11 objects should be created / destroyed during the initial provisioning and during credential rotation.
3. The device can store the PEM format of the key / certificate, but this comes with the price of a heavier memory footprint. In order to use the key / certificate with PKCS Long wait on MQTT Connect #11, they must be converted to DER.

[apullin]

OK, that does clarify things a bit. That PDF is helpful.
The taxonomy varies a bit and is only really stated from the cloud POV, e.g. in the PDF, Fig 7 refers only to "copied to the device".

If I understand it correctly, from the device's point of view, it is "provisioned" only once the PKCS11 object for private key and certificate are created and persist between reboots, or such that C_FindObjects will find return the DER formatted version of the key.

So xProvisionCertificate and xProvisionPrivateKey or equivalent operations should only be called as part of a one-time operation, and xDestroyDefaultCryptoObjects or the equivalent should only occur in the case of reissuing of credentials to a device.

Does that sound right?

[lundinc2]

Yes that's correct. There are multiple ways to provision the actual device, and it is recommended to use something like a secure element or secure enclave to follow best practices.

It is best that the private key is generated on the device, and never is read from the device, to reduce the chance of it getting leaked.

Some example approaches could be provisioning during the manufacturing process, delegating to a trusted user, using JITP/JITR or fleet provisioning.

[lundinc2]

Please re-open this issue if you have further questions. I am closing it as it has gone stale