The CIP Security PULL Model

One of the things I truly dislike is programming the remote control on television. The instructions aren’t hard –just a little obtuse – but the real difficulty is that I don’t do it often enough to make it pain-free.

I expect that configuring a CIP Security device and loading a certificate will cause me equal amounts of frustration. Like the programming options of your remote control, there are multiple mechanisms for installing a certificate into a CIP Secure device:

1. Not do it at all – You can choose to not use CIP Security for a device. CIP Security allows for the fact that some devices on an EtherNet/IP network will be secured with CIP Security and others won’t use security. The fastest way to configure it is to not configure at all.
2. Use the vendor’s self-signed certificate that is shipped with the device. These certificates are as low-level as you can get. The level of protection you get from using the vendor’s certificate may not be the best, but you might decide that it’s good enough for your application.
3. Use a certificate that the vendor installed from an authorized CA (Certificate Authority) that you accept at your plant. [1]
4. Install your own certificate into the device.

At present, the CIP Security specification defines two mechanisms to load certificates into a device, the PUSH model and the PULL model. This article discusses the PULL model – the default mechanism for an EtherNet/IP CIP Secure device to obtain a certificate.

The PULL model is aptly named as the device “Pulls” the certificate into it from an enrollment server. It is the default way for a device to load a certificate.

There are multiple steps for a device to load a certificate with the PULL model:

STEP 1 – The device locates the Enrollment Server (EST) on your network. The Enrollment Server provides certificates (and key pairs) to end devices. To find the Enrollment Server on the network, the device uses the standard Service Discovery (SD) protocol.

STEP 2 – The device acting as a Client establishes a TLS (Transport Layer Security) session with the Enrollment server using the temporary certificate already in the device. This establishes a secure session with both verifiable device identity and encryption.

STEP 3 – The device builds a Certificate Service Request (CSR).  The CSR contains the information needed by an EST to generate a new certificate. A CSR typically contains the common name of the device, the name of the organization, its location and the public key that will be used by the device to encode messages sent to the device.

The common name is one of the most important fields of the CSR. It distinguishes the device on the network. As of the date of this article, there are no operational rules as to how a device would form a common name – especially in factories where standards have been created that specify certificates must use the common name.

STEP 4 – The enrollment server sends the CSR to the Certificate Authority as an application for a certificate. The CA returns the certificate to the EST, which then passes it to the device.

The next article in this series will discuss the PUSH model.

[1] As of the date of this writing, there are no generally accepted CAs for manufacturing systems.