Overview
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.
What is PKCS#11?
PKCS#11 is a standard specifying an application programming interface (API) for:
- Management (creation, modification, deletion) of cryptographic objects such as:
- Keys (RSA, Symmetric keys, Elliptic Curve Cryptography etc.)
- Certificates (X.509)
- Using the cryptographic objects to perform operations such as:
- Encryption and decryption
- Signature generation and verification
Why use PKCS#11?
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.
PKCS#11 system view
A system supporting PKCS#11 typically comprises of these elements:
- PKCS#11 provider, the backend implementing the crypto store for the objects and supporting the necessary algorithms/operations specified by the API.
- PKCS#11 utilities for loading, configuring and managing the PKCS#11 provider libraries.
- Application support for using PKCS#11 interface.
Figure illustrating PKCS#11 based system
PKCS#11 provider
Dedicated security processors
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:
- Trusted Platform Module (TPM): SLB9670, ST33.
- Hardware Security Module (HSM) / Secure Elements: NXP EdgeLock SE050, Microchip ATECC608, Silicon Labs Secure Vault, STSAFE-A110, USB based: NitroKey, YubiKey
Some considerations when using dedicated security processors are:
- Added cost to hardware
- Possibility of vulnerabilities in its firmware and/or hardware requiring replacing or re-flashing
- Quality of vendor software support may vary, possibly un-audited proprietary software
Software solutions (Backed by SoC hardware Root of Trust)
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 Application support
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.
Key management in IoT devices
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"
OP-TEE as a PKCS#11 provider
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:
- Standard default PKCS#11 PIN based authentication (Security Officer/SO and user PIN)
- Linux ACL based authentication
Note: A prerequisite to securely using OP-TEE (+ PKCS#11 TA) is:
- OP-TEE OS/TA is authenticated as part of Secure boot and chain of trust
- OP-TEE OS is setup to use SoC supported Hardware Unique Key (e.g.: NXP i.MX CAAM) for secure storage
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.
Conclusion
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.
Timesys 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.
