Devices for the Internet-of-Things (IoT) often operate in hostile environments. That makes securing cryptographics keys even more important, as you don’t want your keys to access the infrastructure (LAN and back-end) floating around in cyberspace.
Cryptographic keys are used in numerous IoT applications. They protect access to the WLAN using WPA-Enterprise authentication, ensure port security for connections to the switch, authenticate data that is collected in the IoT device or simply protect communication to backend systems with TLS client authentication. Using X.509 certificates and a Public Key Infrastructure (PKI) are a standard mechanism to achieve a high level of security.
In the past, protecting cryptographic keys and enrolling certificates on an IoT devices used to be a complicated thing. The SmartCard-HSM comes with new tools and techniques to make this process a little less painfull.
A couple of years ago, chip manufacturer started to design special chips called secure elements. Secure elements offer a tamper-resistant runtime environment for cryptographic code and secure memory to store cryptographic keys. Several secure elements are based on a smartcard controller, enhanced with interface logic to ease embedding in the IoT device.
A popular secure element is the A700x from NXP. This secure element is based on a JCOP JavaCard runtime environment, which happens to be our preferred target platform for the SmartCard-HSM.
A key feature of the SmartCard-HSM is the use of a protocol called Remote Application Management over HTTP (RAMoverHTTP). This protocol allows an IoT device to establish an end-to-end secure communication link between a SmartCard-HSM and a back-end server. An implementation of the protocol for the client side is available as open-source in our sc-hsm-embedded project. The server part of the protocol is available in the OpenCard Framework, with an actual implementation in the OpenSCDP ScriptingServer.
The PKCS#11 module from the sc-hsm-embedded project allows the IoT application to access the SmartCard-HSM using a standardized programming API. It also contains the low-level protocol T=1 required to exchange APDUs with the device, as it was specifically designed for embedded systems.
The RAMoverHTTP protocol supports both, the production and the provisioning process. During production, the IoT device connects to the Device Issuer CA using RAMoverHTTP, later it connects to the PKI-as-a-Service platform using the same protocol. The first process is required to initialize the secure element, load the required software and prepare the build-in provisioning PKI. The second process, which can happen in production or after roll-out of the device, implements provisioning of keys and certificates.
An important security mechanism in this two-step process is the build-in PKI for device identification, authentication, secure channel establishment and key attestation. The core level of trust is established during production, all later provisioning processes rely on it. The IoT application itself only contains the application logic to use the keys, the key management part is provided by the back-end.
As the whole infrastructure parts are available as open-source, developers get a chance to extent it for their own needs, implement variations of the default process or add functionality not provided by the core.