PSA: separate driver initialization with a nicer fixed ordering

[gilles-peskine-arm]

Currently, the ordering of the initialization of PSA crypto (triggered by psa_crypto_init) is:

1. Random generator (both gathering entropy and starting the PRNG)
2. Key store in memory
3. Practical storage initialization (you can read a key from storage at that point)
4. Drivers
5. Theoretical storage initialization — storage shouldn't be accessed until that point, because that's where we recover if a storage transaction was interrupted, but we don't actually implement storage transactions properly yet. (Only some secure element drivers involve storage transactions: with a secure element that has its own key storage, there's a two-phase commit of (1) storing a local file indicating we're creating a key, (2) ordering the SE to create the key, (3) marking the creation as completed in local storage.)

This doesn't work in all circumstances. In particular, it doesn't work for drivers that need storage, and it doesn't work for random generators that need drivers.

The desirable order can be very platform-dependent, and ideally there should be a way for the integrator to customize it. Probably by adding a “dependency” property in JSON driver declarations, to indicate which drivers need what (e.g. a driver needs a RNG during its initialization; a secure element driver needs a key from local storage to communicate over an encrypted bus; the RNG subsystem needs a hash accelerator; …). We also have plans to define an interface for partial initialization, which could be another solution for unusual use cases.

As a simple solution to most use cases I propose to tweak the order as follows:

1. Accelerator drivers
2. Key store in memory
3. Storage
4. Random generator: a. Initialize entropy drivers b. Gather entropy c. Start PRNG
5. Secure element drivers

This covers many common cases, such as:

• Using an accelerator for the entropy accumulation.
• Reading a saved RNG seed from storage.
• Using an accelerator and a key from local storage and a random IV to communicate with a secure element over an encrypted bus.

It's a small departure from the current behavior, so it could break somebody's code if they have somewhat unusual requirements. But drivers are still considered an experimental feature, so I think that's ok, we just need to announce it in the changelog.

[oberon-sk]

A patch in TF-M (Patch 6 in 1.8.x) changes the initialization order in psa_crypto_init:

This patch amends the order of initialisations performed in psa_crypto_init() to make sure that the driver wrappers based on the PSA driver API are initialised just after the key slots in memory, both of them at the beginning of the initialisation sequence.

Can anyone imagine (or already has) a use-case, where this order would not work for a PSA Crypto implementation, together with PSA drivers, PSA key slots, PSA key storage, RNG, and entropy initialization due to interdependencies?

[gilles-peskine-arm]

I can imagine systems where entropy/RNG need to be initialized very early because they are used for side channel or glitch countermeasures. However, Mbed TLS doesn't implement such countermeasures except in some implementations of asymmetric cryptography (blinding). Mbed TLS is far more often used on devices where it's best to delay the need for entropy as much as possible, because it takes some time for the TRNG to deliver enough entropy after power on.

The interdependency between storage and drivers depends on whether the storage is encrypted. With respect to initializing the key store in memory, I can't think of anything that would depend on it. The only reason to keep it together with storage initialization is that at the moment, we don't track a state where the key store in memory is ready but persistent keys are not accessible. This will come with https://github.com/Mbed-TLS/mbedtls/issues/6007.

For secure element drivers, I do know of environments where the communication with the secure element is encrypted, and the key is in the PSA key store. That's why I propose to initialize secure elements later than accelerators.