When you write software which makes calls to CLNS, please follow these integration requirements. Not following them will most likely make your software vulnerable to attacks.
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. Depending on the architecture, the compiler may generate branch instructions or conditional instructions to reach the code for the success condition. We encourage that you check this manually.
Most 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:
In cases where the attack handling and error handling methods are identical, the two if-statements may be merged like this:
CLNS API functions which support this feature can be identified by their declaration: if NXP_CSSL_FP_FUNCTION_DECL
is part of the declaration, the function supports code flow monitoring.
The underlying monitoring functionality is provided by a library called CSSL, which is bundled together with CLNS. For details, you may want to check the CSSL documentation.
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 (or CPU word size, whichever is greater) boundary to provide some protection against side-channel analysis.
Do not use unsanitized input to compute input values to CLNS functions.
If you integrate CLNS so that it runs at a privileged execution level and can be called from a lower privileged level, take special care that the following types of input, which are directly used as pointers by CLNS (and called at the privilege level of CLNS), are not derived in any way from unsanitized input:
Otherwise privilege escalation attacks will be possible.