mbed TLS supports alternative implementation for most of its cryptography modules. A common use case is for hardware accelerated cryptography engines. There are a couple of methods for alternative implementations: specific function replacement and full module replacement. The latter is the more common one.
The configuration file contains the cryptography modules, which you can replace with alternative implementation. These are named
MBEDTLS_<MODULE NAME>_ALT. In order to support alternative implementation for a module, uncomment the corresponding
*_ALT definition. Function replacement is according to the function name, with the suffix of
_ALT. To support hardware entropy source, enable
MBEDTLS_ENTROPY_HARDWARE_ALT in the configuration file.
ECP function replacement, the behavior is different. Refer to the ECP module for more information.
There are few basic rules for supporting full module alternative implementation:
1. Enable the relevant
*_ALT in the configuration file.
2. Define the module context in
3. Implement the module API in
4. The alternative implementation should cover all of the default mbed TLS functionality; if the hardware doesn't support specific functionality, such as key size, a fallback to default implementation should occur. Note: AES-192 is an exception because AES-192 is not a common use case, and many hardware cryptography engines do not support this key size.
- For "function alternative implementation" method, implement the alternative function in any file that is being compiled as part of the library.
- For hardware entropy implementation, implement
mbedtls_hardware_poll()in any file that is being compiled as part of the library.
AES example - full module replacement
mbedtls_aes_contextthat will fit the platform's needs
- define the AES API which is a superset of the API defined in aes.h
- implement the alternative AES according to the API which is defined in aes_alt.h, that will access the platform's hardware accelerated engine
MD5 example - MD5 process function replacement