EtherNet/IP and Transport Layer Security

We like to think that encryption is something new and different, but that couldn’t be further from the truth. The Ancient Spartans had the same need as we do: to communicate privately. In their case, they had a need for generals to send confidential messages to their field commanders. They developed a clever method to encrypt their battle instructions. They spirally wrapped a long piece of leather around a wooden log. They then wrote a message vertically using each spiral strip of leather.  When unwrapped from the wooden log, the horizontal message was nonsensical. The leather could then be carried to an intended recipient who, knowing the diameter of the log (the “key”), could read the message. If it fell into enemy hands, the message would be nonsensical. Of course, this was far from foolproof: brute force decryption – trying rods of different diameters – could eventually decode the message, but it was ingenious for the time.

The encryption mechanism that most of us use – and what’s being used in EtherNet/IP – is, you might say, a bit more complex than that. It’s called TLS (Transport Layer Security), and it’s the successor of SSL (Secure Sockets Layer) security. It’s a well-known internet security standard designed to ensure message integrity, to authenticate endpoints and to keep the contents of messages private. You’re using TLS whenever you see that little lock and the “https:” at the beginning of a URL.

The key to TLS communications is the “handshake” that creates a secure session between a client device (your browser) and the server providing the web content.

The handshake process uses Public Key Encryption with Asymmetric key exchange to deliver a Symmetric key for the message exchange. The handshake process is a multi-step process that generally works as follows:

• A Client device initiates a conversation with a server by sending a “Hello” message using standard HTTP communications.
• The server responds to the Hello with its own Hello message. It replies with the encryption algorithm it would like to use and its security certificate.
• The client evaluates the server’s security certificate. If it fails validation, the Client aborts the communication process.
• The client generates a key, encrypts it with the Public key on the server’s certificate and sends that key to the server.
• The server decodes and saves the new shared key.
• The client sends a “Finish” message to the server using the new shared key.
• The servers send a “Finish” message to the server using the new shared key.

Once complete, the client and server can exchange private, encrypted messages. And just like the Ancient Spartans, these messages could be subject to brute force decryption, but with long public and private keys, it would take a large supercomputer hundreds or thousands of years to identify the keys.