How CIP Security For EtherNet/IP Works – Part 2 of 2

This is the second of two articles (part one is available here) on the new CIP Security Architecture from the ODVA.

The ODVA designed the CIP Security architecture to protect programmable controllers and devices on CIP networks from attacks originating on those networks. EtherNet/IP is the first network where this architecture is being applied.

How Does It Work?

EtherNet/IP supports both acyclic and cyclic communications. Acyclic communications (TCP transport) uses TLS (Transport Layer Security). TLS is a well-known Internet security standard designed to ensure message integrity, to authenticate endpoints and to keep the contents of messages private. You’re using TLS whenever you see that little lock and the “https:” at the beginning of a URL in your browser.

Cyclic communications (UDP transport) uses another standard IT communication mechanism, DTLS (Datagram Transport Layer Security). DTLS, a variant of TLS, is designed to overcome the problems associated with unacknowledged UDP communications.

Trust Models to Validate Device Connections

A trust model is an important consideration in manufacturing system security. The trust model is the collection of rules that govern how a device decides to trust another device. CIP Security requires devices supporting CIP Security to support two trust models: Pre-Shared Key (PSK) and X.509 certificates. Pre-Shared Key is an uncomplicated system that works well in small systems. A private key is known and shared by all the devices in a network. Any device that knows the private key is authenticated and able to encrypt and decrypt messages.

X.509 certificates are a standard way for two devices to communicate securely. Each device has a certificate identifying the entity issuing the certificate and some certificate authority that vouches for that issuer. A device can encrypt and decrypt messages using the public and private keys associated with its certificate.

Three New Objects

There are three new objects implemented to support CIP Security: the CIP Security Object, the Certificate Management Object, and the EtherNet/IP Security Object.

The CIP Security Object is a high-level control object. It is the simplest of the CIP Security objects. It provides a flag that external entities can check to determine if a device is in the CIP Security configuration state. It maintains a trusted authorities list and it identifies the CIP Security profiles that the device supports.

The Certificate Management object (CMO) is the CIP Security object that manages the X.509 certificates stored in the device and creates applications to a Certificate Authority for creation of a new X.509 certificate. The Certificate Management Object uses the file object to physically store the X.509 certificates.

The EtherNet/IP Security Object is the CIP Security object that manages the parameters that govern how CIP Security operates on an EtherNet/IP device. It manages the parameters that control TLS and DTLS operation, the cipher security suites, the lists of trusted authorities and the mechanisms for obtaining X.509 certificates.

Device Commissioning

Not all devices in an EtherNet/IP network need to support CIP Security, and not all devices need to be commissioned as a secure device. It is acceptable to have a mixture of unsecured and secured devices. There are several ways to commission the secure devices.

Commissioning devices in the Pre-shared key trust model requires an EtherNet/IP configuration tool to make a secure connection to a device and set the Pre-shared Key Attribute of the EtherNet/IP Security object to the key value.

Commissioning devices in the X.509 certificate trust model requires devices to exchange X.509 certificates to validate their authenticity on connection initiation. Once securely connected, they exchange certificates that are used to encrypt and decrypt EtherNet/IP message and I/O traffic.

Certificates can be pre-loaded by a vendor if their end-users accept the vendor as a Certificate Authority. If not, CIP Security provides two mechanisms for end users to load X.509 certificates: The Push Model and the Pull Model. In the Push Model, a configuration tool “pushes” a certificate into a device. In the Pull Model, a device “pulls” a certificate using uses IT devices like Device Name Servers (DNS), Enrollment Servers and Certificate Authority servers.

Rockwell Automation

Rockwell Automation is already shipping controllers supporting CIP Security. Additional EtherNet/IP Adapter devices equipped with CIP Security and an upgraded configuration tool to manage CIP Security devices are expected soon.

The Challenge

CIP Security is emerging in 2020 as a real game-changing technology within the Rockwell Automation ecosystem. Manufacturers must identify how they will deploy this new technology, how they will configure EtherNet/IP Adapter devices, what ciphers they will use, what certificates they will accept, and a lot more. Making these critical decisions is often outside the expertise of many control engineers.

Vendors have an even more difficult challenge. Vendors building CIP Security devices must decide what kind of certificate they should provide, how they will protect their private keys, and how they will address the challenges of encrypting and decrypting messages in devices never designed for that. They will certainly need to revise their EtherNet/IP software stack and possibly re-spin hardware.

Real Time Automation will be assisting EtherNet/IP vendors to meet these challenges by providing EtherNet/IP security source code, embedded modules, secure gateways, and consulting. Resources available for CIP Security include:

Source Code: You can get the source code for EtherNet/IP with CIP Security from RTA. Contact an application advisor at 1-800-249-1612.

For specific questions, use our contact form, www.rtautomation.com/contact/, email solutions@rtautomation.com or call to talk to an Application Advisor at 1-800-249-1612.