12. The Security Framework

The Security Framework provides a collection of high-level cryptographic algorithms. It is intended to allow the application to access the cryptographic algorithms. It follows a layered software architecture approach that consists of the LLDs of the hardware cryptographic engines, the system services and adapters that provide a higher level API for using the engines and the algorithm implementations. The layered architecture is depicted in Figure 30.

Security framework architecture:

Figure 30 Security framework architecture

12.1. LLDs of the security framework

12.1.1. TRNG Engine LLD

The True Random Number Generator (TRNG) engine is a non-deterministic 32-bit random number generator. The TRNG LLD provides the API for reading generated random numbers, controlling clock enable signals and handling TRNG interrupts. Please refer to the Doxygen documentation of the LLD for details of the API.

12.1.2. AES/HASH Engine LLD

The AES/HASH engine is a hardware accelerator for AES (Advanced Encryption Standard) encryption and HASH functions. It supports ECB, CBC and CTR AES for 128, 192 or 256 bit keys. The supported hash functions are MD5, SHA-1 and SHA-2. The AES/HASH LLD provides the API for controlling clock enable signals, configuring the engine, and handling its interrupts. Please refer to the Doxygen documentation of the LLD for details of the API.

12.1.3. ECC Engine LLD

The ECC engine is a hardware accelerator for Elliptic Curve Cryptography (ECC) operations. It supports arbitrary operand sizes up to 256 bits and uses a part of the system RAM for exchanging input and output data. The ECC LLD provides an API for controlling clock enable signals, configuring the engine, handling its interrupts, writing and reading input/output data. Please refer to the Doxygen documentation of the LLD for details of the API.

12.1.4. Crypto engines LLD

The AES/HASH and ECC engines share a common interrupt source towards the ARM Cortex M0 (crypto_irq). The Crypto Engines LLD provides an API for managing this common interrupt for each of the two engines. Please refer to the Doxygen documentation of the LLD for details of the API.

12.2. TRNG service

The TRNG service is a system service for providing random numbers while minimizing the power consumption due to the TRNG engine. It provides an API for reading one or multiple 32-bit numbers or bytes. Please refer to the Doxygen documentation of the service for details of the API.

12.3. Crypto adapter

The crypto adapter is a module that guarantees exclusive access to each of the cryptographic engines (AES/HASH and ECC). It also prevents the system from going into sleep mode while a task has acquired one of the engines for performing cryptographic operations. Finally, it provides a mechanism for event notification related to the engines’ operation, thus allowing a task to block until an operation is completed.

The crypto adapter is also the module that allocates and configures the system RAM block that is needed by the ECC engine and loads the ECC microcode whenever it is necessary.

The use of the crypto adapter by a task follows the sequence shown in Figure 71. When task has acquired the resource via the adapter it can then directly call the relevant LLD APIs. When it is finished it must release the resource through the adapter so that any other tasks with pending acquisition requests can use it.

It is possible to reduce the code size of the crypto adapter as an optimization in the use case of only one task needing to access the resource or when the application uses only one of the two cryptographic resources. This is achieved through specific configuration macros that can be found in the adapter’s header file located in the <sdk_root_directory>/bsp/adapters/include/folder. Please note that the BLE framework is one of the users of the ECC engine.

Please refer to the Doxygen documentation of the crypto adapters for details of the API and application examples.

12.4. Cryptographic algorithms

A set of high-level security-related cryptographic algorithm implementations are provided in folder <sdk_root_directory>/sdk/interfaces/crypto/include. These implementations hide the details of the lower layers of the security framework architecture and provide an easy to use API.

12.4.1. Hash-based Message Authentication Code (HMAC)

The hash-based message authentication code (HMAC) is a specific type of message authentication code algorithm that involves the use of a specific cryptographic hash function. The process of generating an HMAC and then validating it at the receiver is shown in Figure 31 and further details on the algorithm can be found in [Ref_05] and [Ref_06]. The SmartSnippets™ DA1468x SDK provides an implementation of a SHA256 based HMAC, the API of which can be found in <sdk_root_directory>/sdk/interfaces/crypto/include/crypto_hmac.h. The API is fully documented in Doxygen and provides examples of use.

Figure 31 HMAC algorithm

12.4.2. Elliptic Curve Diffie-Hellman (ECDH)

Elliptic Curve Diffie-Hellman is an elliptic curve variant of the Diffie-Hellman algorithm. It allows two parties to generate a common shared secret by exchanging public keys over an insecure channel, after agreeing to use a common set of domain (curve) parameters, as shown in Figure 32. More information about ECDH with ECC can be found in [Ref_07]. Curve25519 is a specific Diffie-Hellman function that allows fast and secure implementations of ECDH. More details about Curve25519 can be found in [Ref_08].The SmartSnippetsTM DA1468x SDK provides an implementation of ECDH in <sdk_root_directory>/sdk/interfaces/crypto/include/crypto_ecdh.h. The curves supported currently are secp192r1, secp224r1, secp256r1 and Curve25519. It is possible to reduce the code size of the ECDH by configuring specific macros regarding the use of Curve25519. For more details you can refer to the Doxygen documentation that includes also examples of usage.

Note

The shared secret obtained with the ECDH key agreement protocol should not be used directly. Instead it should be passed through some form of key derivation function (KDF). The SmartSnippets™ DA1468x SDK security framework does not currently provide KDF implementations.

Figure 32 ECDH algolithm