A client example failed when proper entropy collector has not been implemented

[toyowata]

The issue is moved from here.

In K64F platform, the macro MBEDTLS_ENTROPY_HARDWARE_ALT is defined in the target.json and proper implementation has been done in the HAL.

ARMmbed/mbed-os#1879

Some platforms do not support RNG hardware and expect to use software solution. e.g. build client example without MBEDTLS_ENTROPY_HARDWARE_ALT macro.

In that case, I got connection error below if I removed the MBEDTLS_ENTROPY_HARDWARE_ALT macro in K64F platform (as non RNG support device).

Starting mbed Client example...
Using Ethernet

Connected to Network successfully
IP address 10.128.4.32

SOCKET_MODE : UDP
Connecting to coap://api.connector.mbed.com:5684

[ERROR:] M2MInterface::SecureConnectionFailed

Attached files is mbed-trace log: trace_log_failed.txt

So, my question is:

• Is the MBEDTLS_ENTROPY_HARDWARE_ALT macro and entropy collector implementation mandatory feature, or optional?

If this is optional, the nanostack-hal-mbed-cmsis-rtos should also have software implementation and the client example should not fail.

https://github.com/ARMmbed/nanostack-hal-mbed-cmsis-rtos/blob/master/arm_hal_random.c#L28

[ciarmcom]

ARM Internal Ref: IOTSSL-907

[pjbakker]

mbed TLS (and any other cryptographic operations) require entropy for the random they need to do those operations securely.

So that means that any target platform that wants security needs to implement support for a strong entropy source. Meaning either:

1. Support for the on-board hardware entropy source (using MBEDTLS_ENTROPY_HARDWARE_ALT)
2. Support for a (less secure) software based entropy source (such as the NV Seed entropy source provided, which requires device-unique provisioning of a seed in the NV)
3. Implementation of and support for a different strong entropy source for that target platform.
4. The target platform not being suitable for production use because there is no strong entropy source.

There is no way around it. A strong entropy source is required and that's not specifically an mbed TLS requirement but a TLS / crypto protocols requirement.

Note: For debug (AND DEBUG ONLY) purposes it's possible to put mbed TLS in a mode where it runs without a strong entropy source, BUT THIS DISABLES ANY AND ALL SECURITY AND IS THUS NOT USING TLS/CRYPTO SECURITY AT ALL AND THUS NOT INTENDED FOR USE IN PRODUCTION ENVIRONMENTS.

[yogpan01]

As @pjbakker explained this has to be supported on platform level, but since there is missing implementation for entropy on various platform, easiest way to work around is to add NULL_ENTROPY feature for example application on those non-K64F boards.
I have created a PR on mbed-client example explaining how user can do this ARMmbed/mbed-os-example-client#63

I propose we can close this issue