IoT and Device Identities
Whether you're producing radio base stations (eNodeBs) or security gateways for telecom solutions, the latest Internet of things (IoT) devices, or connected cars - if your device communicates via the internet and especially if it is produced by an outside supplier, you are going to want to use PKI to secure communications, ensure the identity of your devices and make sure that only your devices can connect to your network. Your issuance is likely going to be completely automated and fortunately, EJBCA provides support for nearly all enrollment protocols. The following sections allow you to find out which setup fits your needs the best.
Overview of IoT PKI Use Cases
A lot has happened in the world of manufacturing in the last decades. Devices are ever more constantly connected to the internet at large and may be manufactured at third-party sites. As a manufacturer, you likely have the following main concerns:
How do I make sure that only my devices can connect to my network, to protect customer data?
How do I securely update the software of my devices over their life cycle?
How can I know that the factory producing my devices is not using my blueprints, designs, and specifications to produce devices of their own?
What if my devices do not know what PKI to enroll to upon production, but only upon deployment?
How do I sunset my devices upon failure or compromise?
The following outlines two IoT PKI use cases and the next sections show some common steps to set up EJBCA for these use cases.
Securing Communications
In the case where you have control over the production line, your goal is simply to have your devices produce their own key pair upon production and enroll for their first device certificate automatically upon activation in the factory. The end customer will be unaware of this exchange and all future renewals and can use your device securely in the knowledge that their data is being transmitted over a secure channel and that device updates come from you and only you. In turn, by controlling the enrollment process you know that no third parties are accessing your data.
In the world of IoT, securing your data is essential. EJBCA supports all of the commonly used automated enrollment protocols, including EST, CMP, Microsoft Intune, and SCEP, not to mention our own APIs. Clients for these protocols are widely available for your devices to use.
Securing Production and Greenfield Deployment
Generally, you may not fully control the production environment, having your devices or individual device components produced by a third party or a subcontractor. In this case, your priority is not only securing the connection between your device and the internet at large but also maintaining the integrity of the production line and being sure that nobody can produce counterfeit devices using your schematics. As is common in the telecom industry, devices may not be ready for enrollment upon production but need the means to securely enroll to the desired PKI upon deployment, often referred to as a Greenfield Deployment. Both these cases are solved by Identity Provisioning, making use of so-called birth certificates. PrimeKey Identity Authority Manager is a hardware appliance Registration Authority, specifically designed to provision birth certificates directly on the manufacturing floor.
Common automated protocols to solve these use cases are EST and CMP with 3GPP, see Enroll Devices over CMP with 3GPP and Enroll Devices over EST.
Create Root CA and Sub CA
Initially, you need a minimum of two instances of EJBCA, one node acting as Root CA and/or Issuing CA and a Registration Authority. If you wish to keep the Root CA air-gapped then it should be installed in a separate instance, otherwise, it can reside on the same EJBCA instance as the Issuing CA.
In practice, you are going to work with three CAs:
A Management CA, placed on any node. The role of this CA is to issue internal user certificates such as the application server key store, client certificates for administrators, TLS certificates for Peer connections, etc.
A Root CA on the same node or on a Root CA node, which is the head of the hierarchy.
An Issuing CA on the Sub CA node, signed by the Root CA. The purpose of having a Root CA and an Issuing CA is twofold:
You may have several different Issuing CAs in the same hierarchy for different tenants/purposes.
Should your Issuing CA somehow become compromised, having it signed by a Root is essential to allow you to recover your PKI.
Create Issuing CA
With a Root CA on the same node
The most straightforward solution is to have both Root and Issuing CAs on the same node.
→ How to create an Issuing CA on the same node as the Root CA
With an external Root CA
Next, import the Root CA's certificate on the Sub CA node, then create the Issuing CA and have it signed by the Root CA.
→ How to import an External CA
→ How to create the Issuing CA and have it signed by the Root CA
Set up VA Infrastructure
Next up is setting up your VA infrastructure to be able to respond to OCSP requests. While the CA is fully capable of replying to those on its own, you're unlikely to want the CA exposed to incoming requests from the greater web, thus the job is delegated to the VA. The role of the VA is mainly to reply to OCSP requests and does so by having the CA publish revocation information to it over Peers.
→ How to set up TLS authentication between the Issuing CA and a Verification Authority
→ How to connect the Issuing CA and the Verification Authority over Peers
→ How to set up a Publisher to start publishing revocation information from the Issuing CA to its VA
Set up Enrollment
Configure RA
You likely want to process an enrollment request through a Registration Authority (RA) to avoid exposing your CA to the world at large. Your RA(s) are going to be connected to the CA over the Peers protocol. Naturally, you are free to use the same EJBCA instance as VA and RA if you wish.
→ How to set up TLS authentication between the Issuing CA and a Registration Authority
→ How to connect the Issuing CA and the Registration Authority over Peers
There is no limit to the number of Registration Authorities you can connect to a CA instance. Instead, you can both scale up to handle your volumes and separate them by access rules to allow true multi-tenancy.
Enroll Devices over SCEP or Microsoft Intune
SCEP is a well-known and well-used protocol, primarily designed for enrolling networking devices (such as routers) but commonly also used for enrolling mobile devices. Microsoft Intune uses a variant of SCEP for enrollment. SCEP can be run in either Client Mode (where end entities are pre-generated on the CA) or RA Mode (where end entities are generated upon certificate request).
→ Overview of SCEP
→ How to set up enrollment over SCEP
→ How to set up enrollment over Microsoft Intune
Enroll Devices over CMP
CMP is a generic protocol for requesting X509 certificates. While more complex than for example SCEP or EST, its complexity lends itself to a wider set of use cases. Like SCEP, CMP can be set up in Client Mode or RA Mode.
Enroll Devices over CMP with 3GPP
3GPP is an extension of the CMP protocol, which allows for the provisioning of birth certificates for greenfield deployments. It was originally developed for the telecom industry, but can be implemented for any device type.
→ Overview of 3GPP CMP
→ How to set up enrollment over 3GPP CMP
Enroll Devices over EST
EST is a modern enrollment protocol with mainly the same aims as SCEP, in effect superseding it. Unlike SCEP, it is REST-based and supports TLS and Elliptic Curves.
Related Content
For a deep dive into the inner workings of EJBCA, see the EJBCA CA Concept Guide and for more information on setting up CAs, profiles, and general configuration of an EJBCA instance, see the EJBCA CA Operations Guide.
To find out more about other interesting solution areas and what you need to set up, see Solution Areas.