Trust is an EtherNet/IP Device with CIP Security

At last year’s Rockwell Automation Fair, one hundred people attended the session on CIP Security. That’s the new security system that the ODVA introduced a few years ago to secure factory floor EtherNet/IP networks. CIP security relies on a system of private keys and certificates to secure factory floor devices from intruders who get access to the factory floor.

This is a huge problem for EtherNet/IP vendors implementing CIP Security. For most of them, this is the first time that their devices will have confidential data that they have to protect. It’s extremely important to them and the integrity of the entire manufacturing system that they do this correctly. If, for example, the system is using the pre-shared key option of CIP Security, a weakly secured key in any one device compromises all the devices in its security zone (and, possibly, the controller). It’s a serious issue that EtherNet/IP vendors have never had to consider prior to CIP Security.

Over the last couple of months, I investigated the various ways that EtherNet/IP vendors could secure keys in their system, and I learned that there are many options – none of them really perfect. For software I found these options:

1. Hide the key in plain sight – An option for simple devices with no critical data (temperature sensor, possibly). THIS IS NOT AN OPTION FOR PRE-SHARED KEY OPERATION OF CIP Security.
2. Use an OS with secure key storage – shift the responsibility to the OS.
3. Use multi-level key storage – a master key that is significantly stronger than the other keys is used to secure the storage of the CIP Security keys and certificates.
4. No Key Storage – Use Physical Unclonable Function (PUF) technology to store keys. With PUF, keys are generated from the physical characteristics of a semiconductor component. The master key is never stored. There is no key to steal when you use PUF technology.

There are also hardware solutions:

1. Non-Volatile Memory – Store encryption keys in a special NVRAM that is only accessed when access to encryption/decryption is required.
2. External Hardware Security Module – this is an off-device storage solution that can protect the keys of a number of devices. Latency issues make this impractical.
3. Onboard Root of Trust Device – this is a special semiconductor made by silicon vendors that are used to store secret information. It can’t be tampered with and is only accessible by the device software.

As I examined all these options, I realized that there just isn’t a good option for securing master keys, encryption keys, certificates or any secure information in a traditional embedded device. There are issues that increase the difficulty.

The biggest problem is that vendors don’t know how their devices will be used. A simple sensor does not normally need to be secured unless the data that it has is critical to the process. A simple sensor without security in a critical application does not need all the extra expense and R&D that goes into building a secure solution. Unfortunately, the vendor won’t know whether this EtherNet/IP application is critical. The vendor must make a choice to either secure the device and charge more for it or not secure it and know that it is a risk in a critical application. Or finally, the vendor could create two versions, one critical and one not.

I spoke about all this at the ODVA conference in Florida in March 2020. The title of my talk was Establishing a Root of Trust (RoT) in EtherNet/IP Devices Implementing CIP Security. You can get more information on that conference by following the ODVA Conference link.