When using Mbed Crypto's PSA Entropy Injection feature on Mbed OS, it is
not required to opt out of having entropy sources added to your entropy
contexts by default (via MBEDTLS_NO_DEFAULT_ENTROPY_SOURCES).
As integrated in Mbed OS, MBEDTLS_PSA_INJECT_ENTROPY is compatible with
actual entropy sources. PSA entropy injection is implemented using the
standard Mbed TLS NV Seed feature, and is as compatible with other
entropy sources as the standard Mbed TLS NV Seed feature which does
support entropy mixing.
Automatically enable entropy injection when the NV Seed feature is
requested on PSA targets. Add a warning note describing the state of the
current implementation of the entropy injection API.
Fixes#10720
This commit makes the storage configurations - setting
MBEDTLS_PSA_CRYPTO_STORAGE_C, MBEDTLS_PSA_CRYPTO_STORAGE_ITS_C and unsetting
MBEDTLS_PSA_CRYPTO_STORAGE_FILE_C - dependent on the PSA label being defined for
the target.
Previously these symbols were always defined for all platforms which could
cause problems for targets that don't yet support PSA.
- Move all PSA storage code under psa/storage directory
- Create a global PSA error codes header, eliminating ITS specific ones
- Create a common header file for PSA storage type definitions,
eliminating ITS specific ones
- Create a common implementation for PS & ITS
- Implement protected storage feature
- Change ITS test to be common to PS as well
Use a singleton Mutex in platforms_alt functions, to be shared
with the trng function, to save RAM. Rename `platform_alt.c`
to `platform_alt.cpp` as the mutex is in a `singletonPtr`
template class.
Like all HAL APIs, the calls in trng_api.h are not expected to
be thread-safe.
All current accesses to the TRNG HAL are currently via
`mbedtls_hardware_poll`. Mbed TLS does not currently serialise these
calls itself, as `MBEDTLS_THREADING_C` is not enabled. But even if
Mbed TLS's own accesses were serialised, there are other direct
users of `mbedtls_hardware_poll` such as randLIB, that need to use
direct calls due to lack of API to extract entropy from Mbed TLS.
As such it makes sense to treat `mbedtls_hardware_poll` as a de facto
public Mbed OS API, akin to the C++ veneers on top of the HAL, and add a
PlatformMutex there so that it is safe for multithreaded use.
Rename the generic name `ctx` of `mbedtls_platform_context`
in `platform_alt.c` to a specific name `plat_ctx`, to avoid conflicts
when used as external in crypto modules.
To avoid collisions between the psa `crypto_platform.h` file and the
platform specific `crypto_platform.h` file, for the init \ terminate
functions, rename the latter to `crypto_device_platform`.
The DEVICE_FOO macros are always defined (either 0 or 1).
This patch replaces any instances of a define check on a DEVICE_FOO
macro with value test instead.
Signed-off-by: Alastair D'Silva <alastair@d-silva.org>
If setting the MBEDTLS_PLATFORM_NV_SEED_ALT and MBEDTLS_ENTROPY_NV_SEED flags and not
setting MBEDTLS_PLATFORM_NV_SEED_WRITE_MACRO and MBEDTLS_PLATFORM_NV_SEED_READ_MACRO flags
mbed-os will add an entropy source to the relevent partition - SPE in case of daul core or
in case of single core V7 to the main partition.
The defualt behaviour will be to read or write the data from the ITS.
Change error from `MBEDTLS_PLATFORM_HW_FAILED` to
`MBEDTLS_PLATFORM_HW_ACCEL_FAILED` and the value to 0x70,
as the previous value cannot be used as a low level error code.
1. Move the `mbedtls_platform_context` to be platform code, in `features/mbedtls/platfrom/`.
2. Add static refernce counter, to setup and teardown the platform code only once.
3. Adjust Cryptocell porting accordingly.
The configuration option for the mbed TLS specific hardware acceleration
has to be in the macro section and not in the device capabilities
section in targets.json.
The option has also been renamed to better reflect its function.
The crypto hardware acceleration might require defining a lot of mbed
TLS specific macros. Enumerating all of them in `targets.json` creates
too much noise, therefore we move it into a target specific mbed TLS
header.
The target with crypto hardware acceleration has to
- indicate its capability in `targets.json` by adding "CRYPTO"
to the "device_has" section
- has to define his crypto hardware acceleration related macros
in an `mbedtls_device.h` header
- place the `mbedtls_device.h` file in the
`features/mbedtls/targets/TARGET_XXXX`
directory specific to the target
Jaeden Amero
Simon Butcher
David Saada
Ron Eldor
Alexander Zilberkant
Martin Kojtal
Oren Cohen
Kevin Bracey
Alastair D'Silva
Netanel Gonen
Mohammad AboMokh
Danny Shavit
Janos Follath
Andres AG
Martin Kojtal