TLS & Induytry 4.0 / IoT

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. 

simplified working method of a TLS session
Using security hardware makes it possible to store the server’s private key in a secure element which it never leaves and consequently adds to the security of the protocol. (image: EBV)

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.

Need help with security? Feel free to contact us here or take a look at our Identification Segment website here

To learn more about TLS click here to read a memo of The Internet Engineering Task Force (IETF®) on TLS Version 1.2.

  1. Mariusz Lacina

    Hi Christian

    what is the best method to secure communication between IoT nodes in low power/speed mesh networks like 6LowPAN ?
    I mean not between a “server” and/or “client” but between low power end devices (“clients” ?). How to efficiency utilize the ATECC508 features in a networks when you have to send 1 – 2 short frames per transmission ?

    Best regards
    Mariusz Lacina

    • Hi Mariusz,

      basically it is possible to use similar processes in order to secure a 6LowPAN network as you would do in “common” networks – including TLS. However if it is of concern to apply lightweight security measures it is possible to modify the TLS protocol. A possible solution would be to use the mechanisms of the TLS handshake protocol in order to to generate a shared key for an AES encryption and to use this key afterwards. Another option would be to exchange the key only during the pairing procedure and to work with AES after the exchange.

      There are two other options:
      • symmetric encryption, e.g. by using the ATAES132A with pre-shared keys
      • or in case that the transferred data isn’t highly confidential encryption could be aborted and the ATECC508A or the new ST Safe 100 could be used for authentication purposes only.

      However, the real strength of the ATECC508A is to support the TLS. All proprietary processes have the disadvantage that one has no interoperability with other systems.

      Hope this helps to answer your question.

      Daniel Bartz

Comments are closed.