IoT devices incorporate keys / certificates for various use cases such as: authenticating to a cloud service, establishing secure network connections, securing Over-The-Air firmware update images etc.
There are multiple software and hardware based solutions to securely store and use these keys / certificates. PKCS#11 is a standard that has been around since 1995 and widely used in the Enterprise Server / PC world to provide a standardized way for applications to use keys / certificates in a platform independent manner. Support for PKCS#11 in IoT device software has been growing over the years to achieve a similar level of security and standardization.
PKCS#11 is a standard specifying an application programming interface (API) for:
PKCS#11 provides applications a platform independent manner of using keys securely AND can also be configured to ensure the keys are never exposed to the application, hence vastly reducing the attack surface. For example, applications can request signing or encrypting data without ever needing to know the private keys.
A system supporting PKCS#11 typically comprises of these elements:
Figure illustrating PKCS#11 based system
These are dedicated security IC’s typically connected to the main processor via I2C or SPI or USB interface. They support various cryptographic algorithms and have built-in non-volatile memory to store keys, certificates, etc. Many of them are also FIPS or Common Criteria certified and compliant to industry standards such as IEC 62443. They come with middleware software (e.g.: cryptoauthlib) that typically support PKCS#11. Popular security chips incorporated in IoT devices are:
Some considerations when using dedicated security processors are:
Software based solutions such as firmware TPM (fTPM) and softHSM can emulate TPM/HSM functionality and be used in conjunction with PKCS#11 libraries. However unless these software is run on a hardware isolated portion of the processor such as Trusted Execution Environment (TEE) or Secure Enclave they do not add much value from a security perspective. Hence the preferred software solution would be to run a “Trusted Application (TA)” emulating HSM functionality running on a TEE.
PKCS#11 has been long supported in popular open source software that employ security (e.g.: OpenSSH, OpenSSL, OpenVPN, httpd, wpa_supplicant etc.). Furthermore, leading IoT kits (e.g: AWS GreenGrass, Azure IoT, etc.) support PKCS#11 to authenticate devices and securely connect to cloud services. Similarly Over-the-air (OTA) firmware update clients such as swupdate, aktualizr, RAUC, mender all support PKCS#11 to varying degrees.
IoT devices are typically “userless” devices and keys/certificates are the main mechanisms to authenticate devices and secure data / network connections. With PKCS#11 support, the providers can act as key stores supporting crypto operations that the PKCS#11 enabled applications can make use of in a secure fashion.
Examples of various keys used on IoT devices include: firmware update keys / certificates, device identity keys / certificates, disk encryption keys, WPA keys, web server keys and certificates, cloud and device to device communication keys, application keys for encrypting data (PII, logs, database, configs etc.).. all of which can be secured and managed using PKCS#11.
Without PKCS (Azure IoT client: direct access to private key)
identity_pk = "file:///var/secrets/device-id.key.pem"
Note: Typically without PKCS#11 support, the key is secured with a combination of full disk encryption (dm-crypt) and discretionary access control to the file, providing a minimal baseline security.
With PKCS (PKCS#11 URI i.e. reference to crypto object):
pkcs11_lib_path = "/usr/lib/libckteec.so.0" identity_pk = "pkcs11:slot-id=0;object=device id?pin-value=1234"
IoT devices using ARM processors can leverage the combination of TrustZone hardware technology in conjunction with an open source Secure OS (e.g.: OP-TEE) to achieve the functionality provided by HSM/Secure Elements.
The OP-TEE OS can run “trusted apps” and one such app included is a PKCS#11 TA which acts as a PKCS#11 provider (i.e. implements HSM with PKCS#11 support in software). Using the PKCS#11 TA, various device secrets / certificates illustrated in the previous section can be securely provisioned within OP-TEE at manufacturing time. Cryptographic operations such as signing or encryption can be performed without the private key being made available outside of OP-TEE. Thus on embedded Linux based devices, a secure keystore with PKCS#11 support can be easily achieved with OP-TEE.
Example usage of PKCS#11 TA with OP-TEE
The user space applications running on Linux can directly use the PKCS#11 interface via cryptoki client library (libckteec) included with OP-TEE client or via other libraries/clients (e.g.: openssl engine, pkcs11-tool/OpenSC, p11-kit). The PKCS#11 libraries and tools are readily available in both Yocto and Buildroot. Access to the crypto objects and operations can be restricted by:
Note: A prerequisite to securely using OP-TEE (+ PKCS#11 TA) is:
Limitations
PKCS#11 specification does not require all cryptographic mechanisms to be supported. Some PKCS#11 providers might only support a subset of mechanisms (e.g.: AES ECB might be supported but not AES CBC). If an application has a stringent requirement on the use of a certain PKCS#11 mechanism, then it is prudent to review the mechanisms implemented by the provider. Similarly applications support might largely vary and it is prudent to review the same.
Considerations
Provisioning devices with keys / secrets needs to be done securely at the manufacturing facility after the device first boots. So appropriate mechanisms and infrastructure needs to be in place.
Leveraging OP-TEE as a PKCS#11 provider adds an additional layer of security to your IoT devices and eliminates the need for a dedicated security chip.
Lynx offers a PSA certified security solution – VigiShield which includes OP-TEE based PKCS#11 support leveraging hardware root of trust. Schedule a free security consultation with us to learn more.