A Practical Guide for CIP Security Device
Developers
Michael Mann
Senior Systems Engineer
Pyramid Solutions
Ron Floyd
Engineering Manager
Pyramid Solutions
Jack Visoky
Product Security Architect
Rockwell Automation
Joakim Wiberg
Manager Technology and Platforms
HMS Industrial Networks
Presented at the ODVA2017 Industry Conference & 18th Annual Meeting
February 21-23, 2017
Palm Harbor, Florida, USA
Abstract
CIP Security (Profile 1) adds transport layer security to the CIP protocol, and has a large, system-wide
impact on CIP based products. As such, there are many considerations that product developers musttake into account when designing CIP Security enabled products. Many of these issues can havepotential security implications and as a result require careful thought. Although the ODVA CIP Security
specification provides sufficient information for the implementation of this protocol, it is still beneficial toproduct developers to have some additional guidance at their disposal. The aim of this paper is to provide
non-normative guidance around many of the important considerations that have an impact on CIP
Security implementations. This paper does not seek to replace or replicate the information within the CIP
Security specification, but rather provides additional guidance and information. Furthermore, as this paper
is non-normative, the information described within is not necessary for compliance (unless it is also statedwithin the official CIP Security specification).

Keywords
CIP Security, Cyber Security, Certificates, Authentication, Integrity, TLS

2017 ODVA Industry Conference

1©2017 ODVA, Inc.

Definition of Terms
Acronym/Term

Description

AES:
Advanced Encryption Standard

Symmetric Encryption Algorithm designed to be efficient withboth hardware and software. Supports 128 bit data blocks andkey sizes of 128/192/256 bits.

BSD:
Berkeley Source Distribution

Derivative works from original source are not required to be
distributed under the original terms, nor is the owner required tomake source code freely available.

Certificate Authority

A trusted entity that issues electronic documents that verifies adigital entity's identity on the internet.

Cipher Suite

Examples supported in CIP Security Specification: RSA, ECC,
PSK, NULL.

CoCo:Connection Configuration Object

CIP defined object that may be used to configure a device toreceive both secure and non-secure communication.

CVE:
Common Vulnerability and Exposure

Publically available list of security threats with unique identifiers(CVE names, numbers and ID's). Database maintained byMitre corporation and the National Cybersecurity FFRDC.

(D)TLS:
Datagram Transport Layer Security

Based on the TLS protocol, (D)TLS provides communication
security over UDP. Reference IETF RFC 6347.

Digital Certificate

A digital certificate is an electronic "passport" that allows aperson, computer or organization to exchange information
securely over the Internet using the public key infrastructure(PKI).

Digital Certificate, Self-Signed

Certificate signed by the same entity whose identity it certifies.
(i.e. signed with its own private key.) Used when parties knoweach other and trust to protect key. Hardware based key
storage not required.

Digital Certificate, Vendor

A self-signed certificate that adds product level public keys andsecure key storage.

2017 ODVA Industry Conference2©2017 ODVA, Inc.

Digital Signature

The digital equivalent of handwritten signature or stamped seal
to validate identity. It is a mathematical technique to validate
the authenticity and integrity of a message or digital content. It
also ensures the authenticity of the source such that service
cannot be denied (see non-repudiation.) Digital signatures are
based on public key infrastructure (see PKI.)

ECC:
Elliptic Curve Cryptography

public key cryptography based on algebraic structure of elliptic
curves.

Encryption, Asymmetric

Form of encryption using paired keys. One key is known toeveryone, the public key and the other is kept secret, known as
the private key. One key encrypts a message and the opposite
key decrypts the message. RSA, ECC, Diffie Hellman

Encryption, Symmetric

Form of encryption using single key to both encrypt and decrypt
data. Examples: AES, SHA

Entropy Sourcetrue random number generator, often hardware generated for
cryptography purposes. NIST SP 800-90

GCC:
GNU compiler collection
GPL:
General Public License

Software whose source code is available at no cost for anyone
to use for any purpose.

Hash Function

Any function that maps data of arbitrary size to fixed length
data. A cryptographic hash function is designed to be one way
such that it is infeasible to derive the original number. Keys inpublic key encryption are based on hash number.

HMAC:
Hash-Function Message
Authentication CodeAuthentication code based on two inputs: the message and thekey. The output is a code that cannot be used by attackers toderive the source. HMAC is an integral piece of TLS security
architecture.

Message Authentication

Confirmation that the message came from the stated sender(its authenticity) and has not been changed in transit (itsintegrity). In CIP Security message authentication is achieved
via TLS and the HMAC function.

MAC:
Message Authentication CodeA message authentication code (MAC) is a short piece of
information (e.g. code corresponding to a specific product serial
number) used to authenticate a message.

2017 ODVA Industry Conference

3©2017 ODVA, Inc.

Message Confidentiality

Assurance that the messages between two entities cannot bemonitored by untrusted entities. Message confidentiality isachieved in CIP Security via the TLS Algorithm.

Message Integrity

Assurance that the message passed between two trusted
entities has not been corrupted or altered. Message integrity isachieved in CIP Security via the TLS Algorithm.

Non-Repudiation

Repudiation is the rejection of an agreement. Nonrepudiationin cyber security refers to the ability to ensure that the party to
a communication cannot deny the authenticity of a digital
signature.

NULL

NULL Encryption cipher suite. No encryption used, cipher
used for authentication communication only, often during
debug/testing process.

PKI:
Public Key Infrastructure

A public key infrastructure (PKI) is a set of roles, policies, andprocedures needed to create, manage, distribute, use, store,
and revoke digital certificates and manage public-key
encryption.
In cryptography, a PKI is an arrangement that binds public keys
with respective user identities by means of a certificate
authority (CA).

PSK:Pre Shared Key Encryption

A shared secret key that was previously shared between two
parties used for encryption and decryption of data.

RSA

Public key asymmetric encryption algorithm. RSA acronym
based on names of authors Rivest, Shamir and Adleman.

SHA:
Secure Hash Algorithm

Hash function maps arbitrary data to data of a fixed size. The
SHA family of algorithms designed by the NSA are used increating digital signatures.

Spoofing

In network security, an attacker masquerades as a legitimate
entity on the network in order to gain access to the entity's
system or information.

SSL:
Secure Socket Layer

Standard for establishing a secure link between two entities on
a network. Transport Layer Security (TLS) standards havesuperseded SSL. However, the term “SSL” is often used torefer to either the earlier SSL protocol as well as the newer TLS
protocol and libraries.

2017 ODVA Industry Conference

4©2017 ODVA, Inc.

TCP:
Transport Control Protocol

Provides connection management and guaranteed end to end
delivery of data between two network devices. Transport Layer
Security (TLS) uses TCP services. Reference IETF RFC 5246.

TLS:
Transport Layer Security

Transport Layer Security (TLS) is the successor cryptographic
protocol to Secure Socket Layer (SSL), that provides secureconnections over a computer network. Both are often referred
to as SSL. Reference IETF RFC 5246.

UDP:
User Datagram Protocol

Connectionless data transmission protocol. D(TLS) uses UDP
services

X.509

Standard for a Digital security certificate using the PKI to verify
that the public key belongs to the entity contained within thecertificate. (Standards Organization: United Nations ITU-T)

Introduction
Adding CIP Security to a new or existing project is a serious undertaking that involves several important
decisions and considerations. It is important to understand the key points in these decisions, andramifications that a particular path may have with regard to both CIP Security and the overall product.
Within this paper, several considerations are raised and discussed, along with potential options being
offered where appropriate. Although it is not possible to exhaustively list all possible decisions andimpacts that CIP Security would have to a product, this paper aims to provide a reasonable overview tohelp product developers in adding CIP Security support to a new or existing product.

Library considerations
The (D)TLS library is one of the core components in CIP Security as it provides a secure transportmechanism using the standard Transport Layer Security (TLS) and Datagram Transport Layer Security(DTLS) protocols. TLS and DTLS make use of the IETF-standard, RFC 5246 and RFC 6347 respectively,
protocols in order to provide a secure transport for EtherNet/IP traffic. The (D)TLS library sits between the
TCP/IP stack and the application protocol (EtherNet/IP over TLS and DTLS).

EtherNet/IP over TLS and DTLS

(D)TLS library

TCP/IP stackPhysical layer
Figure 1 EtherNet/IP over TLS and DTLS Layering

2017 ODVA Industry Conference

5©2017 ODVA, Inc.

The (D)TLS library is a large and complex piece of software and it is crucial that all parts implemented inthis library are designed with security in mind. Even the smallest and simplest design flaws or bugs in the(D)TLS library might compromise the security the device and in the end the whole system. For thosereasons it is not recommended to roll your own (D)TLS library. Instead it is recommended to obtain anexisting and well known (D)TLS library.
There are many things, ranging from cost and license for the library to size and performance, to consider
when evaluating and choosing a (D)TLS library. This section will touch some of the things that should beconsidered when choosing a (D)TLS library. Since there are many factors to consider and many of them
are business related, it is not possible to give any specific recommendation. There are many (D)TLS
libraries available from different vendors and sources all with their own respective pros and cons.
Therefore, each vendor should select a (D)TLS library based on their needs.
In this paper four different (D)TLS libraries have been investigated. They have not been compared head
to head but rather used as references giving directions and pointers regarding the different things looked
at in the library consideration section. The libraries that have been of most focus are the ones targetingembedded systems running on a smaller microcontroller. The four libraries that have been looked at are:

OpenSSL
wolfSSL
mbed TLS (formerly known as PolarSSL)
MatrixSSL
Cost and license
There are both free and commercial (D)TLS libraries, some of the libraries are available under adual-license model meaning there are both a free and open source version as well as acommercial license version that can be purchased.
One of the most well-known and used libraries, OpenSSL, is a free and open source library.
Since OpenSSL is open source, anyone can view the code and for this reason security related
issues with the library can possibly be discovered earlier. The dual-license libraries use the sameidea, making the source code publically available so anyone can view it and thus possibly having
security related issues found earlier.
The dual-license libraries are usually published under GPL and thus making the libraries free to
use as along as the source code they’re integrated in also are published publically. In most cases
this is not an acceptable license for most companies building products using CIP Security.
Instead the company behind the dual-license library provide a paid version of the library and in
this case it comes under a different type of license model. The companies offer different types ofthe paid licenses, ranging from a per-unit cost to full buy-outs. The dual-license is attractive since
it’s possible to start out using the free version for testing, initial development, and prototyping andwhen getting closer to finalizing the product a paid license can be obtained making it possible tosell the product without having to disclose the full source code of the product.
Some of the free and open source libraries are available under different licenses that allow them
to be used for free and without any more restrictions than maintaining a copyright notice in thewritten documentation. OpenSSL for example is distributed under a BSD like license.
Support
Choosing a commercial (D)TLS library generally provide some sort of professional support fromthe library vendor. And as all cases when purchasing software, the support of it might comedirectly from the vendor of the library or from the distributor. That of course can be a big
difference especially in the case of (D)TLS libraries which are rather large and complicated piecesof software.

2017 ODVA Industry Conference

6©2017 ODVA, Inc.

The non-commercial (D)TLS libraries generally have a rather large and active community behindthem. And the support in those cases comes from the library developers and other users of thelibrary. This doesn’t necessarily mean that it’s of less help than the support expected from a paid
and commercial library. However, the amount of support and the time it would take to get help
from the community behind the non-commercial libraries may vary between the libraries and also
when the help is needed.
Since the of (D)TLS libraries can be configured in many different ways and also provide a lot offunction calls it’s important that they come with good documentation. The level of documentationdiffers a lot between libraries.
OpenSSL has a lot of well written documentation which is easy to access and use when alreadyup and running. However, it does not provide a good introduction to get started and set up things,
this on the other hand can be found at other places.
MatrixSSL, mbed TLS, and wolfSSL all have good and useful documentation on how to port,
setup, and get started with the libraries. They also come with easy example applications for bothclients and servers. The API documentation varies a lot between the libraries but are overall
enough and easy to understand.
Reputation
That the (D)TLS library is well-known and widely used is important to provide assurance that it’s
possible to use the library as a building block in creating a secure product. OpenSSL is probably
the most well-known library around and it’s being used in Linux and Unix distributions, amongst
others. It also has a good reputation of being stable and well tested.
MatrixSSL, mbed TLS, and wolfSSL have been around for many years and the companies behindthe libraries have been successful selling the libraries. They all have references to well-known
companies and projects using their libraries.
Vulnerability Management
Having a well-defined and working procedure for dealing with vulnerabilities is important for the
makers of a (D)TLS library. When a vulnerability is discovered and reported the makers of thelibrary must act in a timely manner to fix the vulnerability in the library.
The vulnerability management process should include procedures for how to deal with reported
common known vulnerabilities, Common Vulnerability and Exposures or CVE for short. A CVE
Identifier is a unique number that can be used over different security advisories by different
vendors to refer to the same issue.
OpenSSL, mbed TLS, and wolfSSL all list the CVEs that affect certain versions of the library andin what versions they have been addressed. By doing this users of the library can see that thelibrary makers actively update and correct issues and vulnerabilities in the library.
Another thing that’s an important part to consider when it comes to a library’s vulnerability
management process is the ability to report possible issues. It is important that vulnerabilities thatare discovered and how the makers of the library work with the reporter to find out and determine
if the issue is real and a valid vulnerability for the library.
There should also be a way to subscribe to updates and changes in the library so potential
vulnerability fixes are received quickly, instead of actively having to go out and check for updates
at the library’s website.
Footprint
Depending on the type of device that is implementing the library the memory footprint might bevery important. In the smaller embedded devices that run EtherNet/IP today there might not be2017 ODVA Industry Conference

7©2017 ODVA, Inc.

enough memory, both non-volatile and RAM, to implement a (D)TLS library. Larger devices likeconnection originators, i.e. PLCs, generally have more memory and thus the memory footprint of
the library is of less importance. Also, since the (D)TLS library is a large piece of software addingthat to an existing product that doesn’t support CIP Security over EtherNet/IP might be an issue.
For that reason the footprint of the (D)TLS library is of high importance.
There are some (D)TLS libraries that are specifically designed for embedded devices. Thoselibraries generally consume less memory, both non-volatile memory and RAM, than libraries
designed to run on a desktop computer. Also the libraries designed for embedded systems often
can be configured to use its own heap. This can, in some cases, make the design easier if theexisting design doesn’t already have dynamic memory management. The libraries designed for
desktop computers rely on existing dynamic memory system and system calls. However, theembedded libraries don’t make use of this operating system infrastructure, and often can be
configured to run in an environment with no operating system whatsoever.
Since embedded devices usually don’t have a lot of memory it’s important that the library isscalable so it can be configured to only include functionality required for CIP Security over
EtherNet/IP. The (D)TLS libraries that are designed with the intention of being used in embedded
systems generally provide an easy way to enable and disable functionality and thus allow them tobe tailored and configured in the most effective way.
Libraries like OpenSSL that were designed to be used as a (D)TLS library for computers
generally don’t provide the developer with as many configuration options to fine-tune them to thelowest level. However, since those libraries generally are used in more capable and higher
performant devices that might run Linux or similar, the memory footprint isn’t likely an issue inthose cases.
Capabilities
CIP Security over EtherNet/IP puts some requirements on the (D)TLS library. The key items thatthe (D)TLS library has to support in order to be able to use it for implementing CIP Security over
EtherNet/IP are:
TLS has to be at least version 1.2
DTLS has to be at least version 1.2
Cipher suite requirements as mandated by the specificationAllow the use of pre-shared keys or X.509 certificates for endpoint authenticationAllow use of either RSA or ECC public/private key pairsProvide data encryption (in addition to data integrity), or data integrity only (nullencryption)
OpenSSL, mbed TLS, and wolfSSL all support the requirements listed above. However,MatrixSSL doesn’t support cipher suites for data integrity only (NULL cipher suites). For thisreason MatrixSSL can’t be used as an alternative for CIP Security over EtherNet/IP.
Performance
In order to implement the TLS protocol the (D)TLS library needs to perform a number of
supporting cryptography operations and message digest operations, such as the SHA-256 hashalgorithm. Those operations are all computation and processing heavy. And in order to implement
CIP Security over EtherNet/IP on an embedded device performance is extremely important.
The TLS protocol requires a lot off processing power. However, processing power might not be
the first thing considered when choosing a microcontroller for an embedded system, so timemight have to be spent on optimizing performance. It’s been shown that it’s possible to run CIP
Security over EtherNet/IP on low end microcontrollers like Cortext-M3. But this generally requiresthat work is done to profile the system and analyze where the time is spent when performing thecryptography operations and message digest operations. The code where the most time is spent
could potentially be optimized or placed in faster memory. Also some microcontrollers have2017 ODVA Industry Conference

8©2017 ODVA, Inc.

hardware accelerators for performing cryptography and message digest functions (see thesection on hardware architecture for more information on this). The (D)TLS library can then be
ported to use the hardware accelerators instead of code that executes on the micro controller.
This can in many cases dramatically improve performance and at the same time decrease thememory footprint. Some (D)TLS libraries have porting functions to make the integration job
easier.
(D)TLS libraries also make heavy use of a heap and a lot of the cryptography and message
digest functions are performed against data on that heap. Thus it’s important that the heap isplaced in a memory with high bandwidth and latency against the microcontroller or CPU. Placing
the heap in a specific memory location is naturally easier to do if the library makes use of a
dedicated heap.
Non-scientific tests have been performed to compare the performance of mbed TLS on a
microcontroller system, using Cortex-M3, and a system running an application processor, dual
Cortext-A8. No efforts were made to optimize the code, i.e. the library was compiled out of thebox using the standard configuration options. In both cases GCC was used to compile the codeand the same optimization level was used. The application process system was running Linuxand the embedded system ran a home grown RTOS. The tests showed that the raw processing
power of the application processor did make a big difference in performance. On the application
processor system, the initial TLS handshake took tenths of milliseconds compared to seconds onthe microcontroller system. That said, it’s possible to optimize performance on the microcontroller
to achieve an initial TLS handshake in the range of 100 milliseconds.
Technology
The libraries reviewed in this section were all written in C and for that reason likely easy tointegrate in the environment most EtherNet/IP products are developed in. Beyond the four (D)TLS
libraries mentioned here there are many other libraries, some of them written in other languages.
Based on the environment used to implement a certain product, research needs to be done tofind a (D)TLS library suited for that specific environment.
Besides this, the smaller (D)TLS libraries that are designed to be used in embedded systems, like
MatrixSSL, mbed TLS, and wolfSSL are all written in a way where it’s possible to run them baremetal, i.e. without an operating system underneath.
Depending on the runtime environment where the libraries are intended to be used, this issomething that needs to be considered. If using an operating system that provides all of the APIs
and libraries that OpenSSL expects, it would likely make it easy to integrate. If the product doesn’t
have an operating system or just a simple RTOS without standardized system calls and libraries,
then it would likely make it easier to use the smaller libraries intended for embedded systems.

2017 ODVA Industry Conference

9©2017 ODVA, Inc.

Summary of library considerations
The table below give a brief summary of the sections covered above related to the libraryconsiderations. The library consideration section and table will to help assist choosing a library.
However since there are many parameters besides what is discussed in this paper that affect the
choice of TLS library, each vendor should consider their needs and do a thorough investigation.
OpenSSL
wolfSSL
mbed TLS
MatrixSSL
Cost andFree
Dual-licenseFree
Dual-licenselicenseSupport
Good
Good
Good
Good
Reputation
Good
Ok
Ok
Ok
Vulnerability Good
Good
Good
Unknown
Management
Footprint
High
Low
Low
Low
Capabilities
Good
Good
Good
Low
Performance Unknown
Unknown
Unknown
Unknown
Technology
Good
Good
Good
Good
Table 1 TLS library summary2017 ODVA Industry Conference

10©2017 ODVA, Inc.

Key Management and Secure Identity(D)TLS connections always start with at least one side having security credentials (which are either a
PSK or certificate). The general model of CIP Security is for the user to provision a product withcredentials that can be used to make and/or receive (D)TLS connections. However, this begs thequestion: how can security be applied to the connection that is used to provision the product with these
credentials? A set of default credentials are necessary to bootstrap this secure connection. Using thedefault credentials, a secure connection is made to provision the device with its initial credentials (either a
PSK or a certificate), as well as any other appropriate CIP Security configuration. Once this initial CIP
Security configuration is completed, the default credentials are no longer used to create secureconnections (unless the product is returned to a default out-of-box state).

ClientDeviceDefault credentials (certificate)is used to create a TLS
connection

InitialCredentials

ClientDefault
Credentials

DeviceInitial credentials and other CIP
Security configuration are sent overthe established TLS connection

ClientDeviceThe TLS connection is torn down,
and any new connections are
established using the Initial
Credentials

InitialCredentials

Default
Credentials

Figure 2 Commissioning credentials
2017 ODVA Industry Conference

11©2017 ODVA, Inc.

There currently exist two options for the default identity. One is a Self-Signed Certificate, and the other isa Vendor Certificate. Each of these options has advantages and disadvantages which will be discussed
in more detail. However, it is necessary first to understand the threats against initial commissioning.
There are two types of credentials that can be commissioned; a PSK or a certificate. The commissioning
for each of these types of credentials has unique risks and threats. A certificate is public information, anda PSK is private. Therefore, when a PSK is commissioned there is a risk to the confidentiality of thecommunication, as an attacker who can discover the PSK value can both communicate on the system, as
well as perform spoofing, data tampering, and information disclosure attacks on devices using the PSK.
For certificate based credentials, there is no need for confidentiality during commissioning, as all of theinformation within a certificate is public (note that there may still be a marginal benefit to this confidential
communications to prevent the attacker from knowing what type of configuration the system is using
altogether). However, an attacker that can launch a data tampering or spoofing attack on the connectionused to commission the initial credentials can certainly compromise the device being commissioned. The
attacker would have the ability to tie the certificate to a key under his/her control, or to tamper with thedevice’s credentials.

Credential TypeThreatInformation
Disclosure
Applies
Doesn’t Apply

Data Tampering

PSK
AppliesCertificate
Applies
Table 2 Credentials vs threats

Spoofing
Applies
AppliesWith the threats enumerated, it is possible to briefly discuss the risk each poses. For data tampering, inthe case of either a PSK or a certificate this would result in the endpoint’s credentials being
misconfigured. This might prevent the endpoint from communicating properly on the system, or mightcause the endpoint to communicate with other endpoints that were not intended. Information disclosure
represents no risk to the certificate, as all the information is public. However, in the case of configuring a
PSK, learning the value of the PSK has the potential to compromise the confidentiality and integrity of all
future communications. This applies not just for the endpoint in question, but for any other endpoints thatare using the same PSK as credentials. Spoofing of the target allows an attacker to provision an
endpoint under their control with the credentials intended for the original target endpoint.
The two possible categories for default credentials are a Self-Signed Certificate and a Vendor Certificate.
Each of these options provide different guarantees for the level of risk. To truly analyze the risk mitigation
provided by each of these options, one would need to understand actual implementation. However, a few
general conclusions can be made. The mitigations each of these options provide, as well as otherconsiderations, are detailed in the following sections.
Self-Signed Certificate
A Self-Signed Certificate is certainly the simpler of the two options, and in this simplicity lies thegreatest benefit of the Self-Signed Certificate. No product PKI is necessary to be created andmaintained, and no hardware-based secure key storage is necessary for the product. These arethings that generally cannot be feasibly done in a field update. However, a product can relatively
easily generate a Self-Signed Certificate via a field update. Furthermore, beyond the cost of
storing data (on the order of a few kilobytes of memory), there is very little additional cost to
implementing this beyond the general (D)TLS library.
Although the Self-Signed Certificate brings many benefits in the form of simplicity and low cost, it
does have some drawbacks. The Self-Signed Certificate does little to protect against the
spoofing case. A Self-Signed Certificate can be easily spoofed (as one can be generated by any
attacker). Without out of band checking there is no guarantee of certificate authenticity, andtherefore no guarantee that the connection is established with the intended device. However, if
2017 ODVA Industry Conference

12©2017 ODVA, Inc.

the connection is indeed established using the intended device’s Self-Signed Certificate then thatconnection does provide some security benefits. Assuming a cipher suite is chosen which
includes confidentiality, then this would be an effective mitigation against information disclosure(as well as data tampering). Note that this is predicated on the successful establishment of a TLS
connection using the intended Self-Signed Certificate. Put another way, the large weakness here
is with the initial connection establishment, as an attacker could replace the intended Self-Signed
Certificate with one under his/her control, in which case all security benefits on that connection
are lost.

ClientAttacker’s
Certificate

Self-Signed
Certificate

Attacker

DeviceThe Attacker intercepts theDevice’s Self-Signed Certificate andinserts the Attacker’s (also SelfSigned) Certificate. This action is
not detectable by the Client
without some out of band checking.

Figure 3 Certificate interception
Vendor Certificates
In contrast to a Self-Signed Certificate, the Vendor Certificate adds some level of complexity tothe product implementing it. The two main areas of complexity introduced by Vendor Certificatesare a product level PKI and secure key storage. Strictly speaking, neither of these is absolutely
necessary for the implementation of Vendor Certificates. However, these aspects help
significantly to realize the benefits of Vendor Certificates. A product level PKI is necessary forproviding the signing services that sign the Vendor Certificates. There are many considerations
for this, such as scale, availability, security, etc. Different products/organizations will havedifferent needs in this area, therefore it is not possible to describe a product level PKI that would
be appropriate for all use cases. However, in general setting up a PKI in a moderate to largeorganization is not trivial, in terms of cost, effort, and complexity. One important area ofconsideration is around the protection of the signing keys; if the signing key is compromised thenthe PKI essentially loses its value. Therefore, threat modeling and risk assessment activities
should be undertaken to guide the level of protection necessary.
The other aspect of Vendor Certificates that merits discussion is the secure key storage.
Whereas the product level PKI was around the keys and services for signing Vendor Certificates,
the secure key storage is around the protection of each product’s private key (which corresponds
to the public key present in the Vendor Certificate). Protection of this key is important because
the ability to use it allows an attacker to impersonate the product. Again, there are a wide rangeof solutions that can be applied here, from simple data obfuscation to robust hardware
2017 ODVA Industry Conference

13©2017 ODVA, Inc.

mechanisms. What solution is implemented depends on many factors that are outside the scopeof this document (but also should undergo threat modeling and risk assessment activities to drive
the decision). In summary, implementing Vendor Certificates will certainly add cost andcomplexity to a product.
In many ways Vendor Certificates are susceptible to the same risks and threats as a Self-Signed
Certificate. However, Vendor Certificates do offer a clear advantage in this area; which is the factthat their authenticity can be verified by anyone with the proper verification key. That is, thespoofing attack described with the Self-Signed Certificates changes. If the client verifies theauthenticity of the device’s Vendor Certificate, then it is no longer possible for this spoofing attack
to occur. However, this benefit comes with some caveats:
1. The client must know a priori the public key used to verify Vendor Certificates. This means
the client may need to maintain a list of several keys from several different vendors. These
keys are all public information, so it is more a matter of building this knowledge into the client.
2. Compromising any Vendor Certificate breaks this scheme. If an attacker is able tocompromise any Vendor Certificate of a trusted vendor, then it can be used to spoof thedevice’s valid Vendor Certificate. That is, this scheme is only as good as the weakest Vendor
Certificate trusted by the client. This implies that any vendors participating should implementa robust PKI as well as robust secure key storage, as both of these are likely compromise
points.
Note that similar to the Self-Signed Certificate, once a Vendor Certificate has been used toestablish a TLS session, then that session will benefit from all of the normal TLS protection
mechanisms.
Although somewhat outside the scope of CIP Security, it is useful to note that there can be otherbenefits of Vendor Certificates. These certificates allow for authenticity checks on a given
product and can be used to prevent cloned products (as a clone would presumably not haveaccess to the PKI needed to create a valid Vendor Certificate). Furthermore, Vendor Certificates
can be used to provide authenticity and non-repudiation of data produced by a given product (via
cryptographic signing). Depending on the product’s use cases this might be a useful feature toinclude, and could help to justify the cost of implementing Vendor Certificates.

Vendor Certificates and Self-Signed Certificates are both viable options for default credentials. Vendor
Certificates do provide some additional security benefits, especially in terms of the added difficulty of
spoofing the certificate used to establish an initial TLS connection, yet at the cost of increased complexity.
Another important area of discussion revolves around a system that uses both Vendor Certificates andSelf-Signed Certificates. In this case the “weakest link” of the system in the Self-Signed Certificates;
therefore, the benefits of the Vendor Certificates are vastly reduced or even lost. As the system will needto accept a Self-Signed Certificate, then that is the lowest acceptable security level, and therefore can beused to launch spoofing attacks as described. Despite this, Vendor Certificates can bring additional
benefits outside of CIP Security, and should still be considered for usage. Any decision on which
implementation is used should be made through careful consideration of requirements, as well as threats
and risks on a given product. The information here can and should be used as a basis to start thediscussion around the costs and benefits to each solution, but ultimately vendors must decide whatmakes the most sense for their given products.

Connection Origination
An EtherNet/IP network will be more exposed to attack when non-secure devices are allowed to exist on
the same network as secure devices. However, it is also recognized that the rate of adoption of CIP
Security amongst device suppliers will vary over time. Further, end users may choose to continue withcertain non-secure legacy devices after secure scanners are installed.
2017 ODVA Industry Conference

14©2017 ODVA, Inc.

In Chapter 1 of CIP Security (Volume 8) it specifies the following: Devices that support CIP Security muststill be able to interoperate with devices that do not support CIP Security, on the same network. It should
be a matter of end user configuration to allow or disallow such a mix of devices on the network. When
mixing devices with secure and non-secure communications, it is the end user’s responsibility to manage
the device and network configuration appropriately. The user may need to provide additional controls
such as firewalls or physical security means.
In the hybrid world where non-secure devices will coexist on a network, the Originator of communications(Scanner) must “know” the security related communication types of its targets. Therefore, it will beincumbent upon the scanner device vendor to offer a mechanism to differentiate both secure and nonsecure communications with devices on the EtherNet/IP network. This section of the paper is intended forscanner device implementers.
As a matter of course, vendors will develop configuration tools to accommodate the complexities of CIP
security configuration. Using vendor specific configuration tool may be the preferred mechanism toidentify connection types.
The CIP defined Connection Configuration Object (CoCo) provides a standardized method to create,configure and control CIP connections. To specify a “security” connection, include the (D)TLS port in theconnection path attribute (6) of a CoCo instance. For example, an “unsecure” connection would have aconnection path of “192.168.10.10”, while a “secure” connection would have a connection path of“192.168.10.10:2221”.

Debugging/Testing
Understanding TLS connection problems can sometimes be difficult, especially when it’s not clear whatmessages are actually being sent and received. However, since CIP Security over EtherNet/IP uses anidentical application layer and just minor deviations in the communication compared to EtherNet/IP, themessages communicated should be known. For the same reason it’s unlikely that there will be any larger
issues with the application layer data communicated. And in the cases where there are issues with the
EtherNet/IP application data or communications it’s better, if possible, to debug this without running
EtherNet/IP on top of TLS.
When running EtherNet/IP the traffic can easily be captured and decoded with Wireshark using thecorrect infrastructure devices. When running CIP Security over EtherNet/IP it’s still possible to captureand see the traffic in Wireshark, but naturally it’s not possible decode the traffic and see the exact
contents since it might be encrypted. There are however some things that should be done to help andease debugging issues when running CIP Security over EtherNet/IP. One option is only use NULL
encryption cipher suites, and thus only use authentication-only communication. Volume 8 defines three(D)TLS certificate cipher suites, one each for RAS, ECC, and PSK with NULL encryption. When using
one of those cipher suites the data won’t be encrypted, thus the data can be decoded using Wireshark.
In the cases when it’s not possible to change the cipher suite, i.e. in a real installation, it’s still possible todecode the actual traffic. This is accomplished by providing Wireshark with the private key, and naturally if
this is in a real installation this isn’t possible for security reasons. Also, it’s worth mentioning that
Wireshark cannot decrypt Diffie Helleman cipher suites. These are cipher suites with DH in their name;among the cipher suites that Volume 8 defines only three are non Diffie Helleman cipher suites.
The most likely issues that needs to be debugged are the initial communication and the TLS handshake.
There are many different things that initially can go with the TLS handshake when starting a new
development and porting the (D)TLS library for the first time. The TLS handshake can easily be captured
and analyzed using Wireshark since it is not encrypted. One tool that’s handy with doing initial tests anddebugging is OpenSSL. OpenSSL comes with a command line client, this command line client can beused to perform just the TLS handshake. This is accomplish by issuing something like:2017 ODVA Industry Conference

15©2017 ODVA, Inc.

$ openssl s_client -connect <host ip>:2221
This command in conjunction with Wireshark can be really useful during initial development. It’s also
possible to provide the OpenSSL command line client with real certificates and keys doing something like:$ openssl s_client -connect <host ip>:2221 –cert certandkey.pem –key certandkey.pem
Doing this it is possible to perform the full TLS handshake and test out that the certificate and key
handling works correctly. This is useful when testing and verifying the CIP Security object and theirinteraction to the (D)TLS library.
The OpenSSL command line tool can also be used to test and debug other things. It provides options totest protocol support making it possible to verify that for example only TLS 1.2 is supported. There arealso options to test out server-side cipher suite support. This is useful for testing out and verifying that the(D)TLS library has been correctly configured and setup to support the required cipher suites.
Another tool that is useful to verify the protocol support and implemented cipher suites in the server is
nmap. This command can be used to list all cipher suites and supported protocols. This is accomplishedwith the following command line:$ nmap --script ssl-enum-ciphers -p 2221 <host ip>

Performance Considerations
Adding CIP Security to a product is associated with a cost regarding high performance requirements on
the processing unit of the product. Before actually implementing and testing CIP Security it’s impossible
to tell if an existing product can handle the performance degradation that TLS adds to CIP Security over
EtherNet/IP. Running CIP Security over EtherNet/IP can be done on almost any processing unit but on
smaller low end 8-bit microprocessors the product would likely end up being far too slow to be consideredusable. However, many products (probably the majority) that have been developed in the last several
years are built using 32-bit microprocessors. These are also most likely to be the products in which CIP
Security is supported. Those devices are most likely capable of handling the performance degradationthat comes with TLS and CIP Security over EtherNet/IP.
It’s impossible to provide any rule of thumb if a certain processing unit will be capable of handling theaddition of CIP Security. The reason being that there are many factors that vary and influence the overall
performance requirements. Some of those factors are: the compiler being used and how well it can
optimize the code, the performance and the bandwidth between the processing unit and the memory, howwell the existing TCP/IP and EtherNet/IP stack perform, how well the TLS library used performs on theplatform being used, if the processing unit has hardware accelerators for the cryptographic primitives, andif the compiler and TLS library are capable of making use of those. Besides this there are other factorsthat may affect the overall performance such as, which development tools and which specific platform
were used. Many of those items can be overcome and worked around to make the overall productperform better.
There are some specific things that are of interest when considering the performance, the connection
startup and the data flow during the connection. These are things that can be optimized in different ways
and may need work to create a usable and well working product.
During the connection startup the TLS handshake takes place. This is when the two endpoints in thecommunication negotiate the details of which encryption algorithm and cryptographic keys to use before
the first byte of data is transmitted. Also during this time the two endpoints are authenticated which is2017 ODVA Industry Conference

16©2017 ODVA, Inc.

done using public-key cryptography. This is a computationally heavy process that requires a lot ofprocessing power from both sides in the communication.
During the data flow, i.e. primarily class 0/1 communication, two things impact the data latency: bulk
encryption and message integrity. For the bulk data encryption this can be disabled by the end user byselecting one of the NULL encryption cipher suites, this however then provides no confidentiality but inmany applications that’s an acceptable tradeoff. For the message integrity part, which is a hash function,
it can in many cases be optimized. The optimization can be done either in C or using an assemblylanguage optimized implementation.
In many processing units there are dedicated cryptographic hardware accelerators. Those hardware
accelerators can provide functionality to assist the calculation of the different cryptographic primitives
used for TLS. The hardware assisted support varies a lot and has to be looked at closely when choosing
a processing unit for a new product. Some processing units provide hardware acceleration for all thecryptographic primitives, such as hash-functions, symmetric key algorithms, and public key algorithms –both Elliptic Curve and RSA. In those cases it’s possible to offload the main processing unit a lot andachieve near line speed cryptography for both bulk data encryption and message integrity. Using
hardware assisted cryptography naturally comes with a higher per unit cost. But considering theimportance of CIP Security this is probably a good thing to consider when designing new products. Manysilicon vendors offer pin compatible processing units with and without hardware assisted cryptography
engines, thus it’s possible to add the hardware assisted option later on and release this as a new updated
product with higher and better capabilities. This without having to redesign the hardware, but justmounting a different part during manufacturing. This is discussed further in the next section, “Hardware
Architecture Considerations”.

Hardware Architecture Considerations
For CIP Security there are three main areas in which hardware may be particularly beneficial: Hardware that provides secure key storage
 Hardware that provides cryptographic acceleration
 Hardware that provides entropy generation
These hardware components are not required for CIP Security, but it is likely that many products would
benefit from this additional hardware. Each of these is discussed in more detail within this section. Notethat a single piece of hardware may perform more than one function; these functions would notnecessarily need to be implemented as three separate hardware solutions. No matter what hardware isselected, there are some issues that need to be addressed regardless of the functionality included in the
hardware:

Trust boundaries: Some hardware is within a processor, some is on a printed circuit board(PCB), and some is easily removable (as in on a USB stick). Which is chosen depends on use
case as well as the boundary of trust.
Performance: Depending on the type of countermeasures employed and the underlying
technology, hardware based secure key storage can reduce overall system performance. It is
important to understand if the performance is acceptable for the given system.
Capabilities: The key storage hardware may only support a limited number of algorithms and/or
keys. The CIP Security spec limits what must be supported, but it might be desirable to haveother algorithms for both future usage and for other uses within a product.
Cost: Including extra hardware on a product is certainly not free, an organization will need todecide what cost they are willing to pay to have the extra capabilities given by secure storage
hardware.

2017 ODVA Industry Conference

17©2017 ODVA, Inc.



Contention: More than one part of the system may need to use a given hardware resource.
Mechanisms for dealing with this are an important consideration, whether they be hardwarebased, software-based, or some combination thereof.

Beyond these general issues, there are considerations specific to each hardware function:
Secure Key Storage Hardware
As discussed in the section on secure identity, if a product implements a Vendor Certificate thensecure key storage is necessary to protect the private key associated with this certificate.
Although software based options are available for this, hardware generally provides a morerobust protection. Hardware based key storage is useful beyond just protecting the key
associated with the vendor certificate. Keys associated with the certificate sent to a device by auser (for CIP Security) can also be protected by hardware based secure key storage. Bestpractices denote that the key is generated by the device and the private portion of the key neverleaves the device. Hardware based secure key storage allows a device to achieve this for the
keys associated with (D)TLS communications. Furthermore, many devices have other uses forprotecting data, of course hardware based secure key storage may be used to protect other data
beyond that associated with (D)TLS communications.

Cryptographic Acceleration Hardware
CIP Security involves a significant amount of cryptographic operations on communications
packets, which of course results in a performance impact. However, a product that includes
specialized hardware for cryptographic acceleration can reduce or even eliminate the burden ofthese cryptographic operations on the main processor. There are two essential categories ofcryptographic operations that are needed in CIP Security. One is the public key, or asymmetric
operations. These are generally done during connection handshaking; examples include RSA,
ECC, Diffie Hellman, etc. The other are symmetric operations, which are generally during the
lifetime of the connection (once the handshaking is complete). Examples include AES, SHA, etc.
Depending on the needs of the device, hardware can be used to assist either or both of these
operations. Note that in general, the asymmetric operations take longer time and place a higher
burden on the system. However, as these are mainly done as part of the connection handshaketheir impact is limited. The symmetric operations are generally faster, but occur much more often
as there is at least one operation done on every packet that is sent or received. Throughput andlatency targets are of course product specific, but hardware can be used to help achieve thesetargets. The following flowchart can aid in the decision-making process around what type of
cryptographic accelerators to use:2017 ODVA Industry Conference

18©2017 ODVA, Inc.

New Product/
HardwareUpdateNo

No update possible

Yes

Is packet latency
a concern?

Yes

Add Symmetric
Cryptography/HMAC
No
AssistanceYes

Is connection
origination timea concern?
No

Yes

Add Asymmetric
Cryptography
Assistance

Make necessary
hardware updates

Figure 4 Hardware cryptography decision flow-chart

Entropy Generation Hardware
Another important area for hardware assistance is that of entropy generation. If possible, using a
hardware based source for randomness is generally the best option. As such, when considering
what hardware to include in a product a hardware based random number generator should
certainly be kept in mind. More discussion on this is given below on the Entropy Sources section.

2017 ODVA Industry Conference

19©2017 ODVA, Inc.

Entropy Sources
True Random Number Generators
Generation and management of cryptographically strong entropy is essential for the security of(D)TLS sessions. The CIP Security specification mentions that hardware based entropy sources,
or True Random Number Generators, are to be preferred over any software based sources.
Therefore, it is ideal if a dedicated piece of hardware for entropy generation can be placed on the
product. Even more ideal is for that hardware to include countermeasure protections such thatthe entropy source is well protected, even inthe case of other parts of the system being
compromised by an attacker. Keys generated by this hardware should stay within the hardware
for the key lifetime. Furthermore, the hardware should be designed such that it is compliant withwell-known standards for entropy generation (such as NIST SP 800-90). Although not generally
necessary, more than one True Random Number Generator (TRNG) within a product may
provide further security advantages through redundant mechanisms and diversity of sources,
albeit at greater product cost.
Lack of Specialized Hardware
The above describes the ideal entropy generation support for CIP Security. However, it isrecognized that this may not be feasible for all products. Some products may need to gather
entropy from sources other than a True Random Number Generator. If this is the case it is still
possible to gather entropy on a product (although maybe not at the same quality as a True
Random Number Generator). This section will provide some general guidelines for gathering
entropy on such a product.
oooUse Physical Sources – All products run (at some point) on some sort of hardware.
Hardware is necessarily a physical entity, subject to laws and constraints of physics. As
such, there is a degree of randomness and entropy to hardware. Inspect the system for
hardware which may exhibit some form of randomness. Likely areas of this include
oscillator drift, RAM decay, and various monitoring/diagnostic circuitry (for example atemperature monitor). Generally, the higher the resolution these sources are, the more
randomness they will exhibit (for example, a temperature monitor that reports in degrees
Celsius to more than one decimal point).
Combine Sources – The more physical sources that can be combined generally yields
better entropy, unless a second source degrades the entropy of the other more highquality sources. This also provides a diversity of input; even if an attacker compromises
one entropy source to behave in a predictable manner the other sources can still provide
entropy such that the product functions properly and robustly. Furthermore, somesources may be slower to generate high quality entropy than others. With more than one
source used, this allows entropy to be available without being subject to the limitations of
the slowest source.
Test Sources – It is important to run tests that give a measure of the quality of theentropy. NIST SP 800-90 B provides extensive tests for entropy sources. All sources
should be tested to determine if there are enough suitable sources for the product. Of
course what constitutes a suitable source is dependent on the product’s security posture,
although general guidance is given within the NIST publication.

2017 ODVA Industry Conference

20©2017 ODVA, Inc.

Cipher suites
One integral part of the TLS handshake is in which the client provides the server with a list of its
supported cipher suites. The server selects one of the offered cipher suites that will be used during thisconnection. If no acceptable cipher suites are presented to the server, the TLS handshake will fail and theconnection will be closed. Once the cipher suite has been agreed on and the connection has been
established, the cipher suite insures the privacy, authentication, and integrity for the data that passes
between the client and server over the (D)TLS session (connection).
The cipher suite is what determines the level of security for the (D)TLS session. Some cipher suites evenprovide weak security and should not be used. For this reason it’s essential that the correct cipher suites
are used and it’s of the highest importance to be careful in the cipher suites offered and accepted. The
cipher suites defined by CIP Security for EtherNet/IP should be considered reasonable in terms ofproviding security.
Since the cipher suite determines the level of strength in the cryptography algorithms used, they also
highly impact the performance of the data flow on the (D)TLS session. Thus higher cryptographic strength
picked by using a different cipher suite might degrade the packets per second a device is capable ofproducing and consuming.
For authentication and key exchange the cipher suite defines the asymmetric algorithm used. From thecipher suites defined by CIP Security for EtherNet/IP this could be RSA or Elliptic Curve. RSA is generally
more used and widely deployed then Elliptic Curve. Elliptic Curve on the other hand offer the same or
better security with smaller key sizes. As a consequence of this the performance using Elliptic Curve canbe higher.
The bulk data encryption in CIP Security for EtherNet/IP, when enabled, relies on AES. AES is a standard
for encryption and it contains a lot of variations. Though this standard is what’s adopted by the US
government and now used worldwide. What’s defined for CIP Security is considered providing reasonablesecurity for confidentiality.
The data integrity is provided by HMAC and in the case for CIP Security for EtherNet/IP SHA-1 or SHA-2.
Both SHA-1 and SHA-2 are accepted by NIST and considered providing enough security.
Table 3 is a summary of different cipher suites used by CIP Security for EtherNet/IP.
Cipher Suite
TLS_RSA_WITH_NULL_SHA256

TLS_RSA_WITH_AES_128_CBC_SHA256

TLS_RSA_WITH_AES_256_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_NULL_SHA

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

2017 ODVA Industry Conference21

Description
RSA for key exchange; null encryption;
SHA256 for message integrity. Encryption is
not provided.
RSA for key exchange. AES 128 formessage encryption, SHA256 for message
integrity.
RSA for key exchange. AES 256 formessage encryption, SHA256 for message
integrity.
ECDHE_ECDSA for key exchange; null
encryption; SHA1 for message integrity.
Encryption is not provided.
ECDHE_ECDSA for key exchange. AES
128 for message encryption, SHA256 formessage integrity.
ECDHE_ECDSA for key exchange. AES
256 for message encryption, SHA256 formessage integrity.

©2017 ODVA, Inc.

TLS_ECDHE_PSK_WITH_NULL_SHA256

TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256

ECDHE in conjunction with PSK for key
exchange; null encryption; SHA256 formessage integrity. Encryption is notprovided.
ECDHE in conjunction with PSK for key
exchange. AES 128 for message encryption,
SHA256 for message integrity.

Table 3 Example of cipher suites
The following table (included from NIST SP 800-57: Recommendation for Key Management) gives
general guidance on the strength of cryptographic keys based on their key length. Obviously longer keys
provide better security, yet what algorithm is used is also relevant to the overall strength.

Figure 5 NIST Cryptography Strengths

Considerations for System TimeAs a part of a X.509 v3 certificate there’s a field named Validity which contains two dates, named
notBefore and notAfter. The validity period for a certificate is the time from notBefore through notAfter,
inclusive. This period is set when the certificate is generated and outside of this period of time, thecertificate is invalid.
In many of the control applications and systems controlled by EtherNet/IP there’s no need for a global
system time. Generally the controller’s notion of time is sufficient, and there’s no need for a wider notionof time in the slave nodes. For this reason, most of the embedded systems on which EtherNet/IP
products are build today have no notion of the global system time or a real time clock (RTC). Even thougha CIP interface to IEEE 1588, Precision Clock Synchronization Protocol for Networked Measurement andControl Systems, is defined only niche EtherNet/IP products implement this for use in special
applications. We can expect that the number of EtherNet/IP products implementing IEEE 1588 will
increase over time and thus also the number of devices that will have a global notion of time.
To make use of the validity in a X.509 v3 certificate, the EtherNet/IP device verifying the peer needs to beaware of the system time. Since the majority of EtherNet/IP devices don’t support this today there’s anattribute in the EtherNet/IP Security Object that allows the user to enable and disable the certificate

2017 ODVA Industry Conference

22©2017 ODVA, Inc.

expiration check. Furthermore, this attribute is by default set to disabled, meaning that the peer’s
certificate expiration shall not be checked.
An EtherNet/IP device that implements IEEE 1588 or NTP to obtain the system time can enable theoption to allow for the certificate expiration check. That the certificate’s validity is checked is preferable tomaking sure that old and expired certificates are used.
It should be noted that IEEE 1588 doesn’t include any form of secure authentication mechanisms.
Although recent versions of NTP provide for the possibility of authentication, in practice that’s not used.
Most systems trust unauthenticated NTP replies to set the system clock. This mean that a Man-In-TheMiddle attacker can control a device’s clock, and by doing so violate the security properties for TLS.
Lately, initiatives have been done to develop secure alternatives to NTP. Google is funding a project
developing a secure time protocol called roughtime. The protocol aims to provide a rough timesynchronization in a secure way. The “rough” time synchronization means that it’s not providing a precise
and perfect time synchronization, rather it provides a synchronization within 10 seconds of the correcttime, which is more than enough for use with security. Roughtime is a simple and light weight protocolthat potentially could become the open secure alternative to NTP.
In the future when there’s a secure and widespread alternative to NTP, which possibly could beroughtime, CIP Security for EtherNet/IP should probably standardize on that. And at some point, werecommend that as a suggested supported protocol for all devices implementing CIP Security for
EtherNet/IP.

References[1] RFC5246, Transport Layer Security (TLS) Protocol Version 1.2, Aug 2008
[2] RFC6347, Datagram Transport Layer Security Version 1.2, Jan 2012[3] ODVA, Inc. The CIP Networks Library, Volume 8: CIP Security™, PUB00299[4] NIST, SP 800-57. Recommendation for Key Management, Part 1, Rev 4******************************************************************************************************************************************************The ideas, opinions, and recommendations expressed herein are intended to describe concepts of the author(s) for the possible useof ODVA technologies and do not reflect the ideas, opinions, and recommendation of ODVA per se. Because ODVA technologies
may be applied in many diverse situations and in conjunction with products and systems from multiple vendors, the reader andthose responsible for specifying ODVA networks must determine for themselves the suitability and the suitability of ideas, opinions,and recommendations expressed herein for intended use. Copyright ©2017 ODVA, Inc. All rights reserved. For permission to
reproduce excerpts of this material, with appropriate attribution to the author(s), please contact ODVA on: TEL +1 734-975-8840
FAX +1 734-922-0027 EMAIL odva@odva.org WEB www.odva.org. CIP, Common Industrial Protocol, CIP Energy, CIP Motion, CIP
Safety, CIP Sync, CIP Security, CompoNet, ControlNet, DeviceNet, and EtherNet/IP are trademarks of ODVA, Inc. All othertrademarks are property of their respective owners.

2017 ODVA Industry Conference

23©2017 ODVA, Inc.