Have you ever had the experience of being so close to a thing that you really can’t explain it to other people? That often happens with experts. I have a cousin that graduated from the Massachusetts Culinary Institute. It’s the MIT of cooking. Listening to her tell me how easy it is to make a souffle is difficult because she finds it hard to talk to cooking novices. I’ve had the same kind of problems explaining simple protocols like Modbus TCP.
And I know that’s what’s happened to me in the past when I’ve tried to explain CIP Security for EtherNet/IP: I hadn’t really formed a clear definition that makes sense to the average control engineer. So here is another attempt – let me know if I’m successful.
CIP Security defines the security-related requirements and capabilities of CIP devices and specifically for EtherNet/IP. It provides three benefits to a manufacturing system using EtherNet/IP:
- Data integrity – It rejects data that has been altered during transmission.
- Authentication – It rejects data transmitted by untrusted entities.
- Authorization – It rejects actions that an entity is not allowed to perform.
To accomplish these objectives, CIP Security employs two standard IT cryptographic protocols: Transport Layer Security (TLS) and DTLS (Datagram Transport Layer Security). TLS is the standard cryptographic protocol used to secure internet communications and online traffic. CIP Security uses TLS to secure EtherNet/IP acyclic messages (Explicit messages). DTLS is a version of TLS designed to secure UDP (User Datagram Protocol) messages. It is used by CIP Security to secure EtherNet/IP cyclic traffic (Implicit messages).
But secure TLS and DTLS traffic is only possible if two entities trust one another. CIP Security for EtherNet/IP supports two mechanisms for entities to trust another: Pre-Shared Key (PSK) and X.509 Certificates.
PRE-SHARED KEY (PSK) – Pre-Shared Key is an uncomplicated mechanism that works well in small systems. A private key is known and shared by all the devices in a network. The key is used to encrypt messages. Any device that knows the private key is authenticated and able to encrypt and decrypt messages. For added protection, the key is typically changed at some set interval, sometimes as part of a maintenance cycle.
X.509 CERTIFICATES – X.509 Certificates are a standard way for two devices to securely communicate. The devices share their certificates. Each certificate identifies the entity authenticating the certificate. That entity can be the device itself (self-signed certificate), the vendor who manufactures the device, or some outside authority that is trusted by all the devices in a network. The public key in a certificate is used to send encrypted messages to the certificate owner, who uses their private key to decrypt the message. A private key associated with the certificate is never disclosed.
A fundamental design tenet of CIP Security is that not all devices on an EtherNet/IP network need the same level of protection. Some devices are less critical and some are more critical to an automation system. The required protection is not identical. CIP Security defines two security profiles to provide that different level of protection.
The EtherNet/IP Confidentiality Profile provides secure communications by requiring authentication and data integrity for all EtherNet/IP messages. Authentication means that an EtherNet/IP device identity is verified to be the device it claims to be. Data integrity means that the data within the EtherNet/IP message can be relied upon to be accurate and consistent. Devices that are not authenticated are unable to make a secure connection. Messages that fail the integrity check are rejected.
The EtherNet/IP Authorization Profile goes one step further than the Confidentiality Profile. It provides User Authorization. With the Authorization profile, an application requesting an action like opening or closing a valve would have to be authorized to take that action. The EtherNet/IP Authorization profile is not currently part of CIP Security, and the specification describing how this is to be accomplished isn’t available at the time of this writing.
Devices that do not support CIP Security can coexist with devices that support the Confidentiality or Authorization Profiles.
Hopefully, that’s a more clear and concise definition. Check out more of our blogs on CIP Security here.