The CLNS implements security features which are meant to protect against fault injection attacks. Nonetheless, a few security-related topics require your explicit attention.
In general, the return values of all CLNS API functions must be checked. These checks should ideally be written in such a way that, on an assembly code level, the code for the error condition is executed by default. This means that skipping all branch instructions must lead to an error condition, which helps avoid fault injection vulnerabilities. The compiler may generate branch instructions to reach the code for the success condition. We encourage that you check this manually.
Almost all CLNS API functions monitor the code path taken internally and calculate a protection value that must be verified by the caller of the library. This can be done with e.g. the following code snippet:
Some CLNS API functions use parameter integrity protection, which provides additional assurance against fault injection attacks. The first parameter of such functions has the type nxpCsslParamIntegrity_Checksum_t
. In order to call these functions correctly, you must first calculate the parameter checksum. See the example below:
All sensitive data (such as private keys), including sensitive CLNS API function parameters, should be aligned on a 4-byte boundary to harden the software against side-channel analysis.