Identify the Initial Deployment of CIP Security
Wireshark is a widely used network protocol analyzer. It is a free and open-source packet analyzer commonly used for network troubleshooting, protocol analysis, software and communications protocol development, and education. The purpose of traffic analysis is to determine who is talking to whom.
In the initial release of the CIP Security feature in Rockwell Automation products, the ODVA PUSH method is used for CIP Security provisioning. In this method, the initial deployment of the CIP Security model sets the configuration tool (FTPM/FTSS) as the client initiating the connection and the IACS device as the server in a TLS handshake. Figure 4-6 captures the initial deployment of CIP Security from the computer hosting FactoryTalk Policy Manger (FTPM) and FactoryTalk System Service (FTSS) to a 1756-L85E (Blue_L85E).
1. A reliable TCP connection is needed for communication between the two IACS devices. The TCP connection is established on the secure port 2221. The client is the FTPM/FTSS computer and the server the Blue_L85E.
- Client -> Server: SYN
- Client <- Server : SYN, ACK
- Client -> Server: ACK
2. A secure TLS connection is created for the TLS handshake protocol. The client is the FTPM/FTSS computer and the server the Blue_L85E.
- Client -> Server: CLIENT_HELLO
The client sends a message to the server, asking for an encrypted session, which includes:
– The highest TLS version supported by the client.
– Ciphers supported by the client. The ciphers are listed in order of preference.
– Data compression methods that are supported by the client.
– The session ID. If the client is starting a new TLS session, the session ID is 0.
– Random data that is generated by the client for use in the key generation process.
- Client <- Server : SERVER_HELLO
The server sends a SERVER_HELLO command to the client, which includes:
– The TLS version that will be used for the TLS session.
– The cipher that will be used for the TLS session.
– Data compression method that will be used for the TLS session.
– The session ID for the TLS session.
– Random data that is generated by the server for use in the key generation process.
- Client <- Server : CERTIFICATE
The server responds with their server certificate, which includes the server public key in it. The server is the 1756-L85E and the certificate it sends is the born on certificate or vendor certificate as a root certificate-see—see Figure 4-7.
- Client <- Server : SERVER_KEY_EXCHANGE
This message is optional and sent when the public key that is present in the server’s certificate is not suitable for key exchange or if the cipher suite places a restriction requiring a temporary key. This key is used by the client to encrypt Client Key Exchange later in the process. The 1756-L85E does not use its born on certificate or vendor certificate as a basis for trust when it is being configured with new trust anchors and certificates. Once security has been set up by FactoryTalk Policy Manager, trust is limited to the trust anchors that the tool has provisioned, and the vendor certificate becomes irrelevant.
- Client <- Server : SERVER_HELLO_DONE
The server sends the SERVER_DONE command. This command indicates that the server has completed this phase of the TLS handshake and is awaiting the client's response.
- Client -> Server: CLIENT_KEY_EXCHANGE
Using all data generated in the handshake thus far, both will perform the following:
– The client generates the pre-master secret "random value" for the session, encrypts it with the server's public key (obtained from the server's certificate) and sends the encrypted pre-master secret to the server. The pre-master secret is a random value generated by the client and encrypted with the server public key. The pre-master key's length can vary depending on the algorithm used during key exchange. This along with the client and server random number is used to create the master secret. If the server can decrypt the message using the server's private key and can create the master secret locally, then the client is assured that the server has authenticated itself.
– The server uses its private key to decrypt the pre-master secret.
– Both the client and the server use the pre-master key and performs a series of steps to compute and generate the same master secret locally. The master secret is then used to derive a shared secret key/session key for symmetric encryption and MAC. The master secret is of fixed-length value.
– Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity.
- Client -> Server: CHANGE_CIPHER_SPEC
The client sends a message to the server informing it that future messages from the client will be encrypted with the session key and indicates that its portion of the handshake is finished.
- Client <- Server : CHANGE_CIPHER_SPEC
The server sends a verification message to the client, which has the HMAC for data integrity and encrypted by shared secret key. It also indicates that its portion of the handshake is finished.
The TLS handshake is now complete and the session begins. The client and the server use the shared secret key to encrypt and decrypt the data they send to each other and to validate its integrity.
3. At this point, both client (FTPM/FTSS computer) and server (Blue_L85E) have successfully completed the TLS handshake. Application data is then exchanged using the symmetric encryption and HMAC. In symmetric encryption, the exact same key is used on both sides of a conversation, for both encrypting and decrypting. The application data packets exchanged set the initial configurations deployed in the FactoryTalk Policy Manager security model to the CIP Security capable IACS devices. During this time, application data packets are exchanged to set the appropriate CIP Security objects including the CIP Security object, the certificate management object (CMO) and EtherNet/IP Security object. It also includes the provisioning of the client certificate or new trust anchors for the CIP Security devices in that security model. The client (FTPM/FTSS computer) instructs the server (Blue_L85E) to create a certificate signing request (CSR), which includes the server creating a public/private key pair. The private key stays on the server and is never shared with the client or any other IACS devices. The client reads the CSR, digitally signs it then sends it back as a client certificate, which will be used as device authentication.
Figure 4-6 Initial Deployment of CIP Security
Figure 4-7 CIP Security Vendor Certificate