Hardware security module support in Anjay

At AVSystem, we take security very seriously and aim to support all modern technologies in the field. One highly sought-after feature of the recent years, especially in the embedded field, is the hardware security module, in which encryption and authentication is handled in a secure enclave, isolated in hardware from application software.

The key benefit of hardware-based security is that even when the application code is compromised, the attacker has no access to the confidential information. Private keys are safe within the security hardware, and cannot be obtained for e.g. cloning the device’s identity.

Types of hardware-based security

There are two main ways of achieving security in a way that is isolated in hardware:

• Secure Elements (SE) are dedicated secure cryptoprocessors that provide a hardware interface (often through a serial bus such as I2C or SPI) for secure storage of keys and certificates, as well as various cryptographic algorithms, notably encryption and signing using the keys stored in the cryptoprocessor. They may be discrete chips or integrated within an SoC. Examples include the Trusted Platform Module (TPM) found in modern PCs and chips like NXP A71CH or MicroChip ATECC608A designed for embedded applications.
• Trusted Execution Environment (TEE) is a feature of modern CPUs and microcontrollers that provides a secure enclave within the processor. That secure enclave can, in principle, execute any code, but is completely isolated from the main operating system and applications, as if running on a separate processor, and a hardware root of trust is provided to ensure authenticity of the code running in this mode. The code run in TEE mode can be programmed by the device manufacturer – often to provide functionality similar to Secure Elements, but can also include other tasks, e.g. biometrics. Examples include ARM TrustZone and Intel SGX.

Sometimes the two techniques can even be combined. For example, the T1 and T2 chips found in Intel-based Apple computers since 2016, contain a secure element, while in principle being general-purpose SoCs. Similarly, SIM cards used in cellular communication, may provide secure element functionality (e.g. via the IoT SAFE specification), while also handling all traditional SIM card functions.

Hardware security module for developers

Due to many different ways of how hardware-based security may be enabled, and solutions available from different vendors, a number of software interfaces have been designed to be portable across many solutions. Some of the most important are:

• PKCS#11, also known as Cryptoki, originally developed by RSA Security for use with smart cards, and currently an OASIS standard used for a variety of security hardware and software.
• Platform Security Architecture (PSA), designed by ARM, contains functional APIs including those for cryptography and secure storage.
• Common security libraries such as OpenSSL and Mbed TLS usually include APIs for plugging the hardware security module into their overall architecture.

The quest for the hardware security module in Anjay

Anjay has long offered support for both OpenSSL and Mbed TLS as a choice of security backend library. We have chosen to add the hardware security module support to the OpenSSL backend first – partially due to requirements of a customer, and partially due to OpenSSL's elegant "engine" API – plugin-like support for third-party security engines, ideal for integrating with hardware.

We also decided to make the reference integration use PKCS#11 as the underlying interface – again, partially due to requirements and suggestions from a customer, but also because SoftHSM, a software "emulator" of the hardware security module is readily available, which is a very important thing to have for development and debugging.

OpenSSL does not include native support for PKCS#11, but an open source wrapper library called libp11 is available from the OpenSC project. In addition to an OpenSSL engine implementation, libp11 also provides some wrapper APIs for common tasks such as storage and generation of keys and X.509 certificates on PKCS#11 tokens.

In the process, we found a couple of memory leaks and a bug in certificate storing routine in libp11 and submitted pull requests to fix them.

Using the hardware security module in Anjay

Much of this work is available in our open-source Commons library – the public key cryptographic APIs have been updated to allow loading keys and certificates from an external engine – you can look for functions containing the word “engine” in avs_crypto_pki.h for details. However, integration that makes use of these new Commons APIs in Anjay is only available in the commercial version.

The general architecture of the hardware security module support in Anjay is summed up on this diagram:

While the libp11-based PKCS#11 engine is included as a reference implementation, the user may replace it at compile time and opt to implement their own engine instead.

There are two most common use cases for hardware-based security in Anjay:

Factory-provisioned hardware-based security

In many cases, certificates and keys will be provisioned on the secure element or secure enclave at the factory. This is especially true for certificates used for connecting to the Bootstrap server.

In this case, when initializing the anjay_security_instance_t structure as described in the certificate mode tutorial, one can use the new public_cert and private_key fields and load data using the aforementioned new Commons APIs, for example:

anjay_security_instance_t security_instance = {
    .ssid = 1,
    .server_uri = "coaps://try-anjay.avsystem.com:5684",
    .security_mode = ANJAY_SECURITY_CERTIFICATE,
    .public_cert = avs_crypto_certificate_chain_info_from_engine(
            "pkcs11:token=tokenId;object=deviceCertId;pin-value=1234"),
    .private_key = avs_crypto_private_key_info_from_engine(
            "pkcs11:token=tokenId;object=keyId;pin-value=1234"),
};

EST with hardware-based key storage

Enrollment over Secure Transport (EST) is an industry standard protocol for provisioning device certificates from the server with the private key generated on the client side. Commercial versions of Anjay include full support for the CoAP-based variant of EST since version 2.6.0. Since version 2.8.0, secure storage may be used for the generated key and provisioned certificates. Everything that is needed is PKCS#11 URIs at which these objects will be stored:

const anjay_configuration_t CONFIG = {
    /* ... usual Anjay configuration ... */
    .est_engine_key_address =
            "pkcs11:token=tokenId;object=estKeyId;pin-value=1234",
    .est_engine_cert_address =
            "pkcs11:token=tokenId;object=estDeviceCertId;pin-value=1234"
};

Storing trusted CA certificates provisioned via EST in the secure storage is also supported – due to the fact that multiple certificates may be provisioned, an implementation of a simple callback that returns the URI for a new certificate to be stored is required.

Summary

By including support for the hardware security module, Anjay can now be used in applications where protection against hackers impersonating existing devices, or tampering with devices, is critical. Thanks to using industry standards, well-supported open-source libraries and modular design, it can work with many different Secure Elements and TEE-based solutions. If you’re interested, be sure to contact our sales at [email protected] and ask for an evaluation of the commercial version of Anjay.