PSA: Specification for random generation and entropy drivers #3882

gilles-peskine-arm · 2020-11-13T12:16:56Z

Create an interface for PSA random generation and entropy drivers.

stevew817 · 2020-11-13T12:28:20Z

docs/proposed/psa-driver-interface.md

+
+* The random output must be of cryptographic quality, with a uniform distribution. Therefore, if the random generator includes an entropy source, this entropy source must be fed through a CSPRNG (cryptographically secure pseudo-random number generator).
+* Random generation is expected to be fast. (If a device can provide entropy but is slow at generating random data, declare it as an [entropy driver](#entropy-collection-entry-point) instead.)
+* The random generator must be able to incorporate entropy provided by an outside source.


What of the cases where a hardware RNG doesn't accept external input?

In general, that driver would only be suitable as one entropy source. It's a matter of security design: if there are multiple entropy sources, the RNG should remain strong even if all but one sources are compromised.

I do think there is a fairly common design space where there is a single peripheral that includes an entropy source and a DRBG, and the integrator does not wish to save entropy to storage. In this case, add_entropy is not needed.

Looking at what I've written, I think that add_entropy can be made optional, but a driver without an add_entropy entry point will be less portable: it can only be integrated on platforms without other entropy sources and without saved entropy.

Can you clarify that in the spec, then? It currently doesn't cater to those devices that have a single entropy source and CSPRNG prepackaged in a hardware peripheral, with no way of accessing these separately.

stevew817 · 2020-11-13T12:28:42Z

docs/proposed/psa-driver-interface.md

+* `"init_random"` (optional): if this function is present, [the core calls it once](#random-generator-initialization) after allocating a `"random_context_t"` object.
+* `"add_entropy"` (entry point): the core calls this function to [inject entropy](#entropy-injection).
+* `"get_random"` (entry point): the core calls this function whenever it needs to [obtain random data](#the-get_random-entry-point).
+* `"initial_entropy_size"` (integer): the minimum number of bytes of entropy that the core must supply before the driver can output random data.


Is this allowed to be 0?

Yes. I'll clarify.

stevew817 · 2020-11-13T12:28:47Z

docs/proposed/psa-driver-interface.md

+* `"add_entropy"` (entry point): the core calls this function to [inject entropy](#entropy-injection).
+* `"get_random"` (entry point): the core calls this function whenever it needs to [obtain random data](#the-get_random-entry-point).
+* `"initial_entropy_size"` (integer): the minimum number of bytes of entropy that the core must supply before the driver can output random data.
+* `"reseed_entropy_size"` (integer): the minimum number of bytes of entropy that the core must supply when the driver runs out of entropy.


Is this allowed to be 0?

I don't think it makes sense for this to be 0. Either the driver never runs out of entropy and this value is not meaningful (although it can be a hint if the core wants to enforce prediction resistance), or the driver can run out of entropy (because its security policy treats entropy as consumable, which is mandated by some security standards) and then 0 is not valid.

stevew817 · 2020-11-13T12:32:46Z

docs/proposed/psa-driver-interface.md

@@ -191,6 +191,8 @@ The signature of a driver entry point generally looks like the signature of the

 Some entry points are grouped in families that must be implemented as a whole. If a driver supports an entry point family, it must provide all the entry points in the family.

+Drivers can also have entry points related to random generation. For transparent drivers, these are [random generation entry points](#random-generation-entry-points). For opaque drivers, these are [entropy collection entry points](#entropy-collection-entry-point).


Why the split? Neither of these have anything to do with key material, so shouldn't both be in the realm of transparent drivers?

Good point. It's closer to opaque drivers because you can have multiple entropy sources, whereas there is a single random generator. But it's only a very minor complication to allow entropy sources in transparent drivers.

stevew817 · 2020-11-17T14:52:50Z

include/psa/crypto_platform.h

@@ -80,4 +80,10 @@ static inline int mbedtls_key_owner_id_equal( mbedtls_key_owner_id_t id1,

 #endif /* MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER */

+#if defined(MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG)
+typedef struct {
+    uint8_t opaque[32];


isn't this very inflexible for something that is dependant on the underlying driver?

Yes. This is a temporary place until we add support crypto_drivers.h. Once we finish implementing driver support, mbedtls_psa_external_random_context_t and mbedtls_psa_external_get_random will be generated from the driver description (although we may keep the ability to define the function manually until Mbed TLS 3.0 for backward compatibility). In the meantime, I don't know what to put here as a sample type. To keep the API simple, Mbed TLS allocates the context, so it needs to know the size.

It's not ideal to have to define this type, but I don't see a better solution that can be done quickly.

stevew817 · 2020-11-17T14:55:23Z

include/mbedtls/check_config.h

@@ -604,6 +605,11 @@
 #error "MBEDTLS_PSA_INJECT_ENTROPY is not compatible with actual entropy sources"
 #endif

+#if defined(MBEDTLS_PSA_INJECT_ENTROPY) &&              \
+    !defined(MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG)


I think you have inverted the logic here?

Addressed in #3895.

stevew817 · 2020-11-17T15:05:48Z

include/mbedtls/config.h

+ * of random data and set \c *output_length to \p output_size.
+ *
+ * Requires: MBEDTLS_PSA_CRYPTO_C
+ *


Would it be good to add a warning saying that this needs to be a cryptographic-quality RNG, since it will be used for generating keys?

Indeed. Addressed in #3895.

stevew817 · 2020-11-17T15:06:29Z

Maybe an additional changelog entry for MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG?

gilles-peskine-arm · 2020-11-18T14:22:36Z

To facilitate reviewing, I've split this pull request into specification and implementation. The previous version e618877 is at https://github.com/gilles-peskine-arm/mbedtls/tree/psa-random-driver-spec-3.

The new version of this PR b267d20 has the commits that change docs/proposed/psa-driver-interface.md.
Alternative random generator support for PSA #3895 has the code. Initially, at commit 25c8deb, this is the same code that was posted here in e618877.

mpg

This is looking pretty good! Other than two language issues, my only real concern is about initial_entropy_size defaulting to 0.

docs/proposed/psa-driver-interface.md

Signed-off-by: Gilles Peskine <[email protected]>

gilles-peskine-arm · 2020-12-07T17:51:23Z

As in #3878 (comment), there was a merge conflict due to the time stamp from a parallel edit, so I've moved the base to current development, removed the time stamp (using the same commit as on #3878) and rebased all the existing commits on top of the new base. The previous version is at https://github.com/gilles-peskine-arm/mbedtls/tree/psa-random-driver-spec-4. I'll address the remaining review comments in subsequent commits.

gilles-peskine-arm · 2020-12-07T19:17:07Z

@ronald-cron-arm Do the remaining threads (#3882 (comment), #3882 (comment), #3882 (comment)) require action from me? I read them as questions and I don't think they justify changing the document, but as I understand it you aren't happy with the current state of the document, so can you please clarify what kind of changes you want in each case?

ronald-cron-arm · 2020-12-08T11:35:28Z

I've proposed a change for one of the three comments that were still not resolved and resolved the two other ones.

Signed-off-by: Gilles Peskine <[email protected]>

gilles-peskine-arm · 2020-12-11T09:55:47Z

Given that Manuel and Ronald are at most requesting minor changes, and there is no opposing voice, I consider this draft approved for design. I will circulate it more widely, especially among TRNG makers, before considering the design to be fully stable.

mpg

I reviewed the changes since my previous approval and found nothing wrong.

ronald-cron-arm

LGTM as well.

gilles-peskine-arm added needs-design-approval needs-review Every commit must be reviewed by at least two team members, needs-reviewer This PR needs someone to pick it up for review labels Nov 13, 2020

gilles-peskine-arm self-assigned this Nov 13, 2020

stevew817 reviewed Nov 13, 2020

View reviewed changes

gilles-peskine-arm force-pushed the psa-random-driver-spec branch from 7bff654 to ac772ee Compare November 13, 2020 13:32

gilles-peskine-arm added component-crypto Crypto primitives and low-level interfaces enhancement HwDrivers labels Nov 13, 2020

gilles-peskine-arm mentioned this pull request Nov 13, 2020

Define an RNG instance based on the PSA RNG #3883

Closed

gilles-peskine-arm force-pushed the psa-random-driver-spec branch 2 times, most recently from 219944d to 8a54d03 Compare November 14, 2020 11:37

stevew817 reviewed Nov 17, 2020

View reviewed changes

ronald-cron-arm linked an issue Nov 17, 2020 that may be closed by this pull request

Break the dependency of psa_crypto on software AES #3675

Closed

gilles-peskine-arm force-pushed the psa-random-driver-spec branch from e618877 to b267d20 Compare November 18, 2020 14:13

gilles-peskine-arm mentioned this pull request Nov 18, 2020

Alternative random generator support for PSA #3895

Merged

4 tasks

daverodgman requested a review from mpg November 19, 2020 10:19

daverodgman removed the needs-reviewer This PR needs someone to pick it up for review label Nov 19, 2020

mpg reviewed Nov 19, 2020

View reviewed changes

docs/proposed/psa-driver-interface.md Outdated Show resolved Hide resolved

docs/proposed/psa-driver-interface.md Show resolved Hide resolved

docs/proposed/psa-driver-interface.md Outdated Show resolved Hide resolved

gilles-peskine-arm added 2 commits December 7, 2020 18:48

Add section on combining get_entropy with add_entropy

43100e3

Signed-off-by: Gilles Peskine <[email protected]>

Clarifications around reseed_entropy_size

ae7772d

Signed-off-by: Gilles Peskine <[email protected]>

gilles-peskine-arm force-pushed the psa-random-driver-spec branch from 7062181 to ae7772d Compare December 7, 2020 17:49

gilles-peskine-arm requested review from ronald-cron-arm and mpg December 7, 2020 19:17

Clarify the intent of the KEEPALIVE flag

348eeeb

Signed-off-by: Gilles Peskine <[email protected]>

gilles-peskine-arm added approved for design and removed needs-design-approval labels Dec 11, 2020

mpg approved these changes Dec 11, 2020

View reviewed changes

ronald-cron-arm approved these changes Dec 11, 2020

View reviewed changes

ronald-cron-arm removed the needs-review Every commit must be reviewed by at least two team members, label Dec 11, 2020

ronald-cron-arm merged commit 8f05aeb into Mbed-TLS:development Dec 11, 2020

gilles-peskine-arm mentioned this pull request Dec 11, 2020

Break the dependency of psa_crypto on software AES #3675

Closed

bensze01 added this to the Driver Interface: Removing unused code milestone Jul 28, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

PSA: Specification for random generation and entropy drivers #3882

PSA: Specification for random generation and entropy drivers #3882

gilles-peskine-arm commented Nov 13, 2020 •

edited

Loading

stevew817 Nov 13, 2020

gilles-peskine-arm Nov 13, 2020

stevew817 Nov 13, 2020

gilles-peskine-arm Nov 13, 2020

stevew817 Nov 13, 2020

gilles-peskine-arm Nov 13, 2020

stevew817 Nov 13, 2020

gilles-peskine-arm Nov 13, 2020

stevew817 Nov 13, 2020

gilles-peskine-arm Nov 13, 2020

stevew817 Nov 17, 2020

gilles-peskine-arm Nov 18, 2020

gilles-peskine-arm Nov 18, 2020

stevew817 Nov 17, 2020

gilles-peskine-arm Nov 18, 2020

stevew817 Nov 17, 2020

gilles-peskine-arm Nov 18, 2020

stevew817 commented Nov 17, 2020

gilles-peskine-arm commented Nov 18, 2020

mpg left a comment

gilles-peskine-arm commented Dec 7, 2020

gilles-peskine-arm commented Dec 7, 2020

ronald-cron-arm commented Dec 8, 2020

gilles-peskine-arm commented Dec 11, 2020

mpg left a comment

ronald-cron-arm left a comment

		@@ -191,6 +191,8 @@ The signature of a driver entry point generally looks like the signature of the

		Some entry points are grouped in families that must be implemented as a whole. If a driver supports an entry point family, it must provide all the entry points in the family.

		Drivers can also have entry points related to random generation. For transparent drivers, these are [random generation entry points](#random-generation-entry-points). For opaque drivers, these are [entropy collection entry points](#entropy-collection-entry-point).

PSA: Specification for random generation and entropy drivers #3882

PSA: Specification for random generation and entropy drivers #3882

Conversation

gilles-peskine-arm commented Nov 13, 2020 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stevew817 commented Nov 17, 2020

gilles-peskine-arm commented Nov 18, 2020

mpg left a comment

Choose a reason for hiding this comment

gilles-peskine-arm commented Dec 7, 2020

gilles-peskine-arm commented Dec 7, 2020

ronald-cron-arm commented Dec 8, 2020

gilles-peskine-arm commented Dec 11, 2020

mpg left a comment

Choose a reason for hiding this comment

ronald-cron-arm left a comment

Choose a reason for hiding this comment

gilles-peskine-arm commented Nov 13, 2020 •

edited

Loading