CMP in EJBCA and Bouncy Castle

CMP has been around for a relatively long time. While the first standard, namely RFC 2510, was written already back in 1999, any modern client would implement the more modern RFC 4210 which came out in 2005.

About CMP support in EJBCA and Bouncy Castle

The CMP standard is quite complex, and EJBCA only implements a subset of it. For all practical purposes, this has proven to be enough for most, if not all use cases we have encountered. What it boils down to is the classical triad of certificate lifecycle management - issuance, revocation and renewal.

For these operations, CMP defines three message types, known as an Initialization Request (IR), a Revocation Request (RR), and a Key Update Request (KUR). These messages are DER encoded and can be sent over any reliable transport medium. While PrimeKey did offer a separate CMP proxy which could relay these messages directly over TCP, as most customers wisely decided to use CMP over HTTP (as described in RFC 6712), we decided to put the proxy on the legacy rubbish dump.

What this means in practice is that CMP messages can be sent and received directly by EJBCA.

EJBCA implements the CMP business workflow and graphical web component in the form of an alias configuration page, but relies on Bouncy Castle for the low-level CMP implementation (such as encoding and decoding of CMP messages). Along with the server-side implementation, we also provide a Java client, aptly named cmpclient, which can be used to make CMP requests to EJBCA. The client takes care of generating key pairs, creating the certificate signing request, and assembling the appropriate CMP messages. EJBCA has also been tested with the CMP client provided with OpenSSL v3, if you would prefer to use that instead.

Finally, if you want to build your own CMP client using Bouncy Castle's APIs directly, the PKI at the Edge training helps you get started and hopefully gets the job done. The training also covers the integration with EJBCA. Watch the Training: PKI at the Edge with Bouncy Castle and EJBCA.

Security first

CMP messages are signed either with a private key or a secret shared between the client and the server (HMAC). This provides authenticity and integrity, but not confidentiality. If confidentiality is needed, one can rely on TLS to provide this by sending the CMP messages over HTTPS instead. In EJBCA, this does not require any additional configuration, as the CMP endpoint is exposed over both HTTP and HTTPS by default.

Any private key used to sign CMP messages sent by the client must be signed by a CA trusted by EJBCA. This is usually done by issuing a client certificate to the CMP client, which can be done from your internal PKI (using EJBCA) or from a PKI provided by a third-party (such as GlobalSign).

Use cases

Below, we will describe some common use cases for the CMP protocol.

CMP in telecom

With the advent of 5G, many carriers have had to take a second look at the 3GPP TS 33.310 standard, describing how to secure the communication within mobile networks. Not surprisingly, CMP is being used.

Base stations connecting to the network are provisioned with a certificate from the vendor, known as a vendor certificate, which is used to sign the CMP messages sent to the PKI operated by the carrier. This PKI is then issuing a device certificate which is used to establish an IPSec tunnel to the security gateway sitting in front of the carrier's core network.

This workflow is straightforward to configure in EJBCA using CMP vendor mode and the ability to pre-register end entities with the serial number of the base stations to be deployed in the RAN. By using EJBCA's external RA feature, it is possible to make the CMP enrollment endpoint available to devices in the RAN without exposing the CA itself. For containerized RAN workloads, where the vendor is unable to stamp the vendor certificate on any hardware, certificates can be issued dynamically through for example Altiostar cert-manager which plugs directly into EJBCA.

EJBCA is used by many carriers all over the world to secure their mobile network infrastructure, and our CMP implementation has been tested against all major telecom manufacturers, including Ericsson, Nokia and Huawei. You can read more about how to use CMP with 3GPP in our documentation.

CMP for rail traffic management

UNISIG is an industrial consortium which was created to develop the ERTMS/ETCS technical specifications. ERTMS being the European Rail Traffic Management System will rely heavily on IoT, needing a high level of security. In the ERTMS specification subsection 137 (On-line Key Management FFFIS), the usage of PKI is specified profiling CMP for digital certificate distribution, as well as OCSP for revocation checking.

CMP in the factory

CMP is also the messaging protocol behind our product called Identity Authority Manager (or IdAM for short). It is a small hardware box, which can be installed right next to your assembly line. It helps you to provisioning certificates for your units during the production process to protect against supply chain attacks. Take a look in the IdAM documentation on our website or contact PrimeKey if you want to know more.

There is a standards track in IETF to produce an RFC profiling CMP for industrial IoT usage.

For more information

• See our online documentation on the Certificate Management Protocol (CMP) and how it works with EJBCA.
• Watch the Training: PKI at the Edge with Bouncy Castle and EJBCA.