Secure communication is a prerequisites for Industry 4.0 applications. That bold statement becomes even clearer if we compare the impact of a hacker attack on personal, private IoT applications and industrial IoT (IIoT) applications. Malicious access to your personal email account is bad news for you and in case of your business mails for the department you are working for. A successful attack on a company however can cause big losses through espionage, cloning or slowed down production – which will eventually be bad news for a lot of people in the company and the supply chain.
Let’s take a look at a common challenge for industrial companies. Setting up a modern and connected production line will require several wireless and wired connections in order to add sensors, to steer machines and to collect and analyse data. This may not be limited to the company in itself as connection may also be set up towards customers e.g. in the case of smart metering when electricity providers need to get access to the meter data.
One very important cryptographic protocol which can be used in order to implement the necessary security in IIoT applications is TLS (Transport Layer Security; the successor of SSL). Besides being best known from the use in web browsing, email and voice-over-IP it is also well-suited for many other complex fields of deployment like the IoT.
To get a clear understanding why TLS is a good solution for IIoT applications it is essential to understand the basic working method of the protocol. The following will provide you with a quick summary of how the second layer, the TLS handshake protocol (used to identify and authenticate the communication partners via asymmetric encryption and public key cryptography) works but is greatly simplified in order to keep this post short. The TLS record protocol (which is the first layer of the two, secures the connection and sits directly on the transport layer) will be left out.
The communication is kicked off by the client sending a message to the server asking for a secure connection (“client hello”). The message includes information on the latest version of TLS which the client can support and a list of symmetric algorithms it can use. The server responds with a message that defines the version of TLS and the algorithm that will be used along with its certificate which includes the public key of the server, information about the website and Certificate Authority (“server hello”).
After the client verified the certificate it sends an one-time key for the session (random generated pre-master secret), encrypted with the server’s public key, to the server. The server decrypts this session key with its own private key and both, server and client, calculate the master secret and the session key (only valid for this session; will be “thrown away” afterwards) used along with the agreed symmetric algorithm for the rest of the session; this means a secure connection between client and server has been established.
Take a look at the graphic below, illustrating the simplified working method of a TLS session.
The flexible addition of securely connected parts to a system especially in the areas of energy management (grid automation, smart metering), industrial automation (sensors, industrial equipment and components) as well as medical and security technology can be a major challenge.
In such cases TLS offers the benefit that there is no need for client and server to have a pre-shared key, which means new parts can be added easily to a system. Furthermore TLS is not entirely implemented in the software which raises the security level significantly as all crypto functions for key establishment are performed by the secure element (security hardware).
One weak spot of TLS can be found if the TLS client is implemented in simple hardware as the random number for the pre-master secret has to be generated by the client. This is a task which many common microcontrollers struggle with. However there is a feasible solution which can eliminate this weakness if a MCU is chosen which is equipped with a true random number generator or if an external chip is used to generate the random number such as the Atmel ATSHA208A and ATECC508A or the Infineon Optiga Trust E and Optiga Trust P.
In conclusion it seems like many Industry 4.0 applications can benefit from security hardware solutions supporting TLS such as the Atmel ATECC508A and the NXP A70CM.
To learn more about TLS click here to read a memo of The Internet Engineering Task Force (IETF®) on TLS Version 1.2.