A Practical Guide for CIP Security Device Developers

Ron Floyd, Pyramid Solutions
Mike Mann, Pyramid Solutions
Jack Visoky, Rockwell Automation
Joakim Wiberg, HMS Industrial Networks
February 22, 2017

What is “A Practical Guide to CIP Security For Developers”?
• We want to give developers some hints and tips on what to do when
implementing this functionality• Although there is a lot of information in the spec, there is also some use in“non-normative” information• None of the recommendations would be necessary for compliance– In some places perhaps no recommendation is made, just importantconsiderations are noted

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

2

Before CIP Security
ProductCIP Stack

Ethernet Port(1 or more)

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

3After CIP Security
Product(D)TLS
LibraryCertificate(Vendor orself-signed)

CIP Stack
New CIP Objects(CIP Security,EtherNet/IP
Security, Certificate
Management)

Secure Key
Storage?

Technical Track© 2017 ODVA, Inc.

CryptoAcceleration
Hardware2017 Industry Conference & 18th Annual Meeting
All rights reserved.

Ethernet Port(1 or more)

www.odva.org

4Topic: Library Selection•The core component in CIP Security over EtherNet/IP– Transport Layer Security (TLS)– Datagram Transport Layer Security (DTLS)••

A large and complex piece of software
It’s probably a lot better to get a (D)TLS librarythan to try and write this code yourself EtherNet/IP over TLS and DTLS(D)TLS library

TCP/IP stackPhysical layer

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

5Topic: Library Selection•

Many different vendors and projects––––•OpenSSLwolfSSL
mbed TLS (formerly PolarSSL)
MatrixSSL

At least a few vendors are using WolfSSL, that is a commercial library thatis working for these purposes– Others?

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

6Topic: Library Considerations•Cost/Licensing– What is the budget for a (D)TLS library?
– Is it open source?
– Royalty based or licensed outright?

•Support– What happens when there are questions/work requests?
– What level of documentation is available?
– How intuitive is the API?

•Reputation– Is the library/vendor respected in industry?
– Do the library developers have security expertise?

•Vulnerability Management– How are updates produced and consumed?
– Are people actively testing the library for security issues?

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

7

Topic: Library Considerations•Footprint– Memory constraints, what size is acceptable (both RAM and non-volatile)?
– How configurable is the library; can unneeded features be compiled out of the binary?

•Capabilities– Does it support everything that is needed for CIP Security (e.g. NULL Ciphersuites)?

•Performance– Can it be optimized?
– Does it integrate with hardware?

•Technology– Does it work well in the given environment (e.g. a Java library won’t work in a Cenvironment)?
– Is the API standard and fits in with the product’s architecture?

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

8Topic: Key Management and Secure Identity•

What identity does
the device containout of box

Vendor Certificate vs. Self-Signed Certificate– If a Vendor Certificate is used, private key must be stored
securely– Both work equally well for CIP Security– Vendor Certificate has may be useful for other things(securely identify a given vendors products, bootstrapping
other things, etc…)– Essentially, low cost option vs. a more expensive yet
more flexible/extensible option

Device has Secure
Key Storage
Hardware?

NoImplement Self
Signed Certificate

NoImplement SelfSigned Certificate

YesYour organization
has a PKI
implemented?

Yes

Use Vendor
Certificate

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

9

Vendor Certificate CIP Security Benefit•

Vendor Certificate can be used to protect against “Man In The Middle”
attacks on initial provisioning– However, only if the Vendor’s root was built in to the product– And only if both sides have a Vendor Certificate (unlikely for a software tool tohave this)ClientAttacker’sCertificate

Self-SignedCertificate

AttackerTechnical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

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.

www.odva.org

10Topic: Key Management with Vendor Certificate•

Need a secure place to store the key– There are solutions for this; TPMs, Secure Key
Store chips, some FPGAs have built-in
capabilities, etc…

•Need a mechanism to sign the VendorCertificate– PKI; this comes with all the issues that arenormally associated with the PKI• Managing a Certificate Authority – protect the keys!
• Managing a Registration Authority – how to validate
identity of requestors• How to access the PKI (e.g. just over a network orother mechanisms?)

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

11Topic: Connection Origination••

Lots of devices are just “targets”, don’t originate connections
Connection origination has additional considerations– How would a device know to originate connections as secure?
• In an environment that has a mix of CIP Security capable devices and non-CIP Security
capable devices this can be challenging• Otherwise non-secure ports can be disabled and all communications can be over CIP
Security sessions

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

12Topic: Debugging••

Previously packets can be sniffed using Wireshark or a similar tool
If confidentiality is enabled this becomes much harder– Suggestion is just to debug it using a NULL ciphersuite– Wireshark plugins for confidentiality are available, but session keys are needed(use Wireshark 2.1.0 https://2.na.dl.wireshark.org/win64/Wireshark-win642.1.0.exe)– Considerations of how to allow for this• Don’t want this enabled in the field!!!
• But, developers would want to be able to use this relatively easily

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

13

Topic: Testing Tools•OpenSSL– Useful for initial testing during early development• Together with Wireshark the initial TLS handshake can be debugged and tested– Perform the initial shake and key-exchange• Handy when performing performance evaluation and optimizations– Test and verify supported TLS versions•Nmap– List all supported cipher suites

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

14

Topic: Testing Tools•

May want a tool that runs on a PC and originates connections– Send configuration to the device– Initiate connections to the device– Easily debug communications via a “transparent client” (simple to allow this tool
to show what communications it sends or receives)

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

15

Topic: Performance Configurations••

There is (of course!) a cost to enabling CIP Security
Can a given product handle the performance degradation?
– Connection startup• Computational cost to handshaking (especially certificate verification)• Extra steps/data over the network for handshaking– Data flow during connection lifetime• Latency concerns; can performance targets be achieved?

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

16

Topic: Hardware Architecture••

Including specialized hardware on a CIP Security product can be very
helpful (although not strictly necessary)
Three general types of hardware:– Cryptographic Accelerator– Secure Key Storage– Entropy Generator

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

17

Hardware Considerations•

Regardless of what hardware is included, there are some common
considerations–––––

Trust Boundaries: is the hardware in an ASIC, on a PCB, on a USB stick, etc…
Performance: does the hardware achieve target performance
Capabilities: algorithms supported, interfaces, etc…
Cost: can the cost of adding the extra hardware be justified?
Contention: do multiple parts of the system need to access the hardware at thesame time? If so, what mechanism can be used to arbitrate thisTechnical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

18

Topic: Cryptographic Accelerator Hardware•Hardware can be used to make increase performanceof cryptographic operations– Anywhere from a modest assist to near/at line speed– Of course this requires investment; whether or not it isworthwhile depends on many factors– However, given the importance of CIP Security, it isprobably a good thing to at least consider for any newproducts

New Product/
HardwareUpdateNo

No update possible

Yes

Is packet latency
a concern?

Yes

Add Symmetric
Cryptography/HMACNo
AssistanceYes

Is connection
origination timea concern?
NoYes

Add Asymmetric
Cryptography
Assistance

Make necessary
hardware updates

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

19

Topic: Other Hardware•Secure Key Storage Hardware– As mentioned previously, this is needed for a Vendor Certificate– Other keys can be stored here (like key provisioned as part of
the user granted identity)– It is important to consider key lengths and algorithms supported•

Entropy Generating Hardware– Including a True Random Number Generator is very helpful for secure generationof keys
– Generation of cryptographic entropy is very difficult without specialized hardware

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

20

Topic: Entropy•••

A good library will have at least one PRNG algorithm for generating random
data
However, those algorithms need to be seeded with truly random data
This has to come from something physical– Cryptographic hardware often includes a TRNG
– If you don’t have a TRNG then you need to get creative• Look for things in the system that are non-deterministic• There’s been work done on this, several papers published• Guidance could be provided for a few standard mechanisms

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

21

Topic: Cipher suites•

There are a lot of ciphersuites
available, what should be used
– CIP Security Spec defines somerequired ones
– There are many others•

Asymmetric – generally 2 choices– Elliptic Curve offers same or better
security at a smaller key size
– RSA is more widely deployed

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

22

Topic: Cipher suites•

Confidentiality, AES is essentially the gold standard– There are a lot of variations to this though– Generally the ones defined in the CIP Security Specification
should be reasonable– Most TLS libraries will support many others; if space is not
an issue other options can be given• CCM and GCM are both authenticated algorithms, give some
additional benefit at the cost of complexity•HMAC– SHA-2 is widely deployed and supported, SHA-1 still
accepted by NIST for HMAC
– SHA-3 recently released, yet to be widely adopted

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

23

Topic: System time•

X.509 v3 certificates have a field defining its validity period– notBefore and notAfter•

Likely the EtherNet/IP device doesn’t have an RTC– Thus the validity period of the certificate can’t be verified•

The EtherNet/IP device could implement NTP or IEEE-1588– Though none of them are secure•

Roughtime might be an alternative in the future

Technical Track© 2017 ODVA, Inc.

2017 Industry Conference & 18th Annual Meeting
All rights reserved.

www.odva.org

24THANK YOU