The CIP Security PUSH Model

Compared to the PULL model discussed in the previous article, the CIP Security PUSH model is extremely simple. The big advantage of the PUSH model over the PULL model is that the device is not in control of the process to obtain a certificate. In the PULL model, the device has to find the EST, it has to build the Certificate Service Request (CSR), and it has to manage the entire certificate installation process. The device is in control of the process. In the PUSH model, the device is just a passive receiver that receives messages from some configuration tool.

As of the date of this article, there are no configuration tools, but multiple companies have them in development. In the initial session with the tool, the device is a server and the tool is a client. The tool establishes a secure TLS session with the device using the device’s default certificate.

Using that default certificate is, of course, a bit precarious. First, that certificate is either self-generated or is a device certificate issued by the vendor. The quality of the keys and the encryption mechanism supported by the certificate may be less than adequate. Since we are replacing that certificate and its keys, that shouldn’t matter, but what does matter is that in the PUSH model, anyone can Push a certificate to the device. It doesn’t know or care if that client is legitimate or not.

The weakness in this approach is that the plan for CIP Security is to support multiple certificates. It may be possible, in the time period when the original certificate is in the device, for an attacker to install an illegitimate certificate. If when the legitimate certificate is installed, the configuration tool doesn’t remove all prior certificates, there may be a way for an attacker to gain access to this device. It’s a remote possibility but a possibility.

There are three specific steps to provision an EtherNet/IP CIP Security device with a certificate using the PUSH model.

Step 1 – A Configuration client must make a secure TLS (Transport Layer Security) connection to the EtherNet/IP device. This secure connection, as discussed above, uses the certificate shipped with the device. What is not specified is how the configuration tool discovers and identifies a specific device on the EtherNet/IP network. If there are three ABB drives on the network, there must be some mechanism for finding the one in the packaging machine as opposed to the other two of them. Neither CIP Security nor EtherNet/IP provides that mechanism.

Step 2 – The configuration tool will use the BEGIN_CONFIGURATION service of the CIP Security Object to set the current state attribute to configuration in progress.

Step 3 – The configuration tool will provide the device with the credentials for secure communication. This means two things. One, the attributes of the EtherNet/IP Object will be set to appropriate values for the application. Two, behind the scenes the configuration tool will create the CSR and define the Subject Name, an important value of the CSR. The CSR will be submitted to the installation’s CA, which will create a certificate and keys for the device. The configuration tool sends this certificate to the device.

Step 4 –The configuration tool will use the END_CONFIGURATION service of the CIP Security Object to set the current state attribute to configuration complete and close the TLS Session.

This sequence results in a fully provisioned device ready for CIP Security.