Support entropy source for targets without TRNG H/W

[ccli8]

Description

This issue is created for (Nuvoton) targets that don't have TRNG H/W but still want to support mbedtls and Pelion application.

1. For Nuvoton targets like below, they have PRNG H/W but no TRNG H/W. Could come out with an acceptable solution to implementing TRNG HAL with PRNG H/W, or ADC+PRNG? If the criteria requires real TRNG H/W, then PRNG H/W gets of no use. It's a pity.

   • NUMAKER_PFM_NUC472
   • NUMAKER_PFM_M487
   • NUMAKER_IOT_M487

2. Discard TRNG and go NV seed (MBEDTLS_ENTROPY_NV_SEED). See that:

   1. For PSA targets, MBEDTLS_ENTROPY_NV_SEED, MBEDTLS_PSA_INJECT_ENTROPY, MBEDTLS_PSA_CRYPTO_C, MBEDTLS_PSA_CRYPTO_STORAGE_C are necessary. PSA ITS is implemented with KVStore on secure side.
   2. For non-PSA targets (like NUC472/M487), besides above, MBEDTLS_PSA_ITS_FILE_C and MBEDTLS_FS_IO are also needed. With MBEDTLS_PSA_ITS_FILE_C, PSA ITS is emulated over files, but the files are not protected. With MBEDTLS_FS_IO, mbedtls library doesn't compile. I guess on mbed-os, mbedtls with file system access is not supported yet. To go NV seed, could PSA ITS implement with KVStore just like on PSA targets?

Related PR

Continuation of #11176 (comment)

Issue request type

[x] Question
[ ] Enhancement
[ ] Bug

@yanesca @kjbracey-arm @cyliangtw

[0xc0170]

cc @ARMmbed/mbed-os-crypto

[yanesca]

1. Alternative solutions:

   • HW PRNG: Adding a TRNG HAL integrates it automatically with the entropy collector module of Mbed TLS. The intended way of providing randomness for the library is to seed one of the provided PRNGs (NIST CTR-DRBG and HMAC-DRBG) with entropy provided by the entropy collector module. TRNG is not an alternative to PRNG, it is an input to it. If the hardware PRNG on these targets is cryptographically secure, then applications could potentially use it instead of the software PRNGs provided by Mbed TLS. By the way what algorithm does the HW PRNG implement?
   • ADC: Using a disconnected ADC as a sole entropy source is arguable at best, and most certainly does not provide equivalent security to a TRNG. Therefore I don't think we can find a solution here that is acceptable as a TRNG for Mbed OS.

2. NV seed:

   • I don't think non-PSA targets need any option other than MBEDTLS_NV_SEED. If a target would like to use NV seed with KVStore, it should register their own nv_seed_read() and nv_seed_write() functions with the platform abstraction layer in Mbed TLS:
     https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/config.h#L1195

[Patater]

I don't think non-PSA targets need any option other than MBEDTLS_NV_SEED. If a target would like to use NV seed with KVStore, it should register their own nv_seed_read()

We provide a default implementation for Mbed OS PSA targets. See features/mbedtls/platform/TARGET_PSA/COMPONENT_PSA_SRV_IMPL/src/default_random_seed.cpp(https://github.com/ARMmbed/mbed-os/blob/master/features/mbedtls/platform/TARGET_PSA/COMPONENT_PSA_SRV_IMPL/src/default_random_seed.cpp).

[ccli8]

I don't think non-PSA targets need any option other than MBEDTLS_NV_SEED

For mbedtls, enabling MBEDTLS_ENTROPY_NV_SEED is enough. But for Pelion, FCC mentions fcc_entropy_set for injecting entropy. It will go the sequence:

1. fcc_entropy_set
2. pal_plat_osEntropyInject
3. mbedtls_psa_inject_entropy
4. mbedtls_psa_storage_inject_entropy

So relevant macros must enable:

• MBEDTLS_ENTROPY_NV_SEED
• MBEDTLS_PSA_INJECT_ENTROPY
• MBEDTLS_PSA_CRYPTO_C
• MBEDTLS_PSA_CRYPTO_STORAGE_C
• MBEDTLS_PSA_ITS_FILE_C
• MBEDTLS_FS_IO

For non-PSA target, per my findings, there are the following issues (repeat above):

1. With MBEDTLS_PSA_ITS_FILE_C, PSA ITS is necessary. But it is emulated over files and is not secured.
2. With MBEDTLS_ENTROPY_NV_SEED, default implementation of mbedtls_platform_std_nv_seed_read/mbedtls_platform_std_nv_seed_write is incompatible with above emulated PSA ITS.
3. With MBEDTLS_FS_IO, mbedtls library doesn't compile.

[cyliangtw]

1. Alternative solutions:

   • HW PRNG: Adding a TRNG HAL integrates it automatically with the entropy collector module of Mbed TLS. The intended way of providing randomness for the library is to seed one of the provided PRNGs (NIST CTR-DRBG and HMAC-DRBG) with entropy provided by the entropy collector module. TRNG is not an alternative to PRNG, it is an input to it. If the hardware PRNG on these targets is cryptographically secure, then applications could potentially use it instead of the software PRNGs provided by Mbed TLS. By the way what algorithm does the HW PRNG implement?
   • ADC: Using a disconnected ADC as a sole entropy source is arguable at best, and most certainly does not provide equivalent security to a TRNG. Therefore I don't think we can find a solution here that is acceptable as a TRNG for Mbed OS.

@yanesca In our chip, we have one internal voltage through MCU internal LDO solution. In our measurement, “Even the measured target is a constant voltage output, the ADC transfer result at “low bit” is jumping up and down. Actually, the low bits result will be impact by the “White Noise”. Even to use the moving average to smooth those raw data, you can also not get a constant or predict value. Though HW TRNG could encapsulate the behavior of seed fetch + PRNG output, in fact, the security of ADC+PRNG is enough for most customers. Moreover, we also could refer to AmazonFreeRTOS platform's mechanism as: If some use case need the real HW TRNG, application could plug some external TRNG component and override int mbedtls_hardware_poll( ) by themselves.

[yanesca]

@ccli8 I think in that case setting "MBEDTLS_PSA_CRYPTO_C", "MBEDTLS_ENTROPY_NV_SEED" should be enough.

Do you have the lines

"pal-user-defined-config" : ""pal_config_non_trng_MbedOS.h"",

and

"target.extra_labels_add" : ["PSA"],

under your target in your mbed_app.json? Have you got "PAL_USE_HW_TRNG=0" set?

[yanesca]

@cyliangtw We seem to have different opinion on how secure a floating ADC based entropy source is. However I hope that we can agree that it is less secure than a NIST SP 800-90B compliant TRNG.

There might be a lot of users who think that an ADC based entropy source is sufficient for their purposes, but this needs to be an explicit choice from them. When the user expects a TRNG, because that is what we promise to them in target.json, then we shouldn't silently give them an ADC based entropy source instead.

As you mentioned, if a user is happy with the security provided by an ADC based entropy source, then they are free to override int mbedtls_hardware_poll( ) as they wish.

[ccli8]

I think in that case setting "MBEDTLS_PSA_CRYPTO_C", "MBEDTLS_ENTROPY_NV_SEED" should be enough ...

@yanesca Thanks for your information. I've tried it out:

1. Define MBEDTLS_ENTROPY_NV_SEED
2. Define MBEDTLS_PLATFORM_NV_SEED_READ_MACRO / MBEDTLS_PLATFORM_NV_SEED_WRITE_MACRO and provide custom mbedtls_nv_seed_read(...) / mbedtls_nv_seed_write(...).
3. Don't define MBEDTLS_PSA_INJECT_ENTROPY. Meet mbedtls_psa_inject_entropy(...) undefined and then provide custom one, which must be compatible with mbedtls_nv_seed_read(...) / mbedtls_nv_seed_write(...).
4. For development, simulating partial provision process, inject entropy seed via mbedtls_psa_inject_entropy(...) pre-main.

Reference configuration in mbed_app.json for Pelion:

"target.macros_add": [
    "MBEDTLS_USER_CONFIG_FILE=\"mbedTLSConfig_mbedOS_SW_TRNG.h\"", 
    "PAL_USE_HW_TRNG=0",
    "MBEDTLS_PLATFORM_NV_SEED_READ_MACRO=mbedtls_platform_seed_read",
    "MBEDTLS_PLATFORM_NV_SEED_WRITE_MACRO=mbedtls_platform_seed_write"
],

[ccli8]

As you mentioned, if a user is happy with the security provided by an ADC based entropy source, then they are free to override int mbedtls_hardware_poll( ) as they wish.

@yanesca For the custom entropy source via mbedtls_hardware_poll(...), it is workable except for #11725. Thanks for your information.

[yanesca]

@ccli8 I am happy to hear that it works!

Please be careful and make sure that the functionality matches the specification when implementing mbedtls_psa_inject_entropy():
https://github.com/ARMmbed/mbed-crypto/blob/development/include/psa/crypto_extra.h#L265
For example: it should be callable only one time in the lifetime of the device, every call after the first successful call should return an error.

About #11725: I left a comment there.

[ccli8]

For example: it should be callable only one time in the lifetime of the device, every call after the first successful call should return an error.

@yanesca Thanks for your reminding. It has been taken into consideration in our custom mbedtls_psa_inject_entropy().

Now that we have two alternatives to TRNG: custom entropy source mbedtls_hardware_poll(...) and NV seed mbedtls_psa_inject_entropy(), I will revoke TRNG support on NUC472/M487 which don't have real TRNG.

[0xc0170]

@ccli8 Good to hear. Is this issue resolved now?