Transport layer

The worldwide common standard Transport Layer Security (TLS) is used in the TwinCAT IoT driver for the secure transmission of data. The following chapter describes the TLS communication flow, taking TLS version 1.2 as an example.

The TLS standard combines symmetric and asymmetric cryptography to protect transmitted data from unauthorized access and manipulation by third parties. In addition, TLS supports authentication of communication devices for mutual identity verification.

	Contents of this chapter The information in this chapter refers to the general TLS communication flow, without specific reference to the implementation in TwinCAT. They are only intended to provide a basic understanding in order to better comprehend the reference to the TwinCAT implementation explained in the following sub-chapters.

Supported functions

The TwinCAT IoT driver enables the use of the following TLS functions.

Function	Description
Self-signed client certificates	Use a self-signed client certificate to authenticate to the message broker.
CA-signed client certificates	Use of a CA-signed client certificate to authenticate to the message broker. The CA certificate can also be specified to establish a trust relationship.
Certificate revocation lists	Use of certificate revocation lists (CRL).
Pre-Shared Key (PSK)	Use of a pre-shared key (PSK) to authenticate to the message broker.

Cipher suite definition

A cipher suite is by definition a composition of algorithms (key exchange, authentication, encryption, MAC) for encryption. The client and server agree on these during the TLS connection establishment. For more information on cipher suites please refer to the relevant technical literature.

TLS communication flow

Communication with TLS encryption starts with a TLS handshake between server and client. During the handshake asymmetric cryptography is used; after successful completion of the handshake the server and client communicate based on symmetric cryptography, because this is many times faster than asymmetric cryptography.

There are three different types of authentication for the TLS protocol:

The server identifies itself through a certificate (see Server certificate)
The client and server identify themselves through a certificate (see Client/Server certificate)
Pre-shared keys (see Pre-shared keys)

Please refer to the relevant technical literature for information about the advantages and disadvantages of the different authentication types.

	Exemplary explanation based on RSA All messages marked with * are optional, i.e. not mandatory. The following steps refer to the RSA procedure and are not generally valid for other procedures.

The following table explains the individual steps from the communication flow shown above.

Step	Description
ClientHello	The client initiates a connection to the server. The TLS version used, a random sequence of bytes (client random) and the cipher suites supported by the client are transmitted, among other parameters.
ServerHello	The server selects one of the cipher suites offered by the client and specifies it for the communication. If there is no intersection between the cipher suites supported by the client and server, the TLS connection establishment is aborted. In addition, the server also communicates a random sequence of bytes (server random).
Certificate	The server presents its certificate to the client to enable the client to verify that the server is the expected server. If the client does not trust the server certificate, the TLS connection establishment is aborted. The server certificate also contains the server's public key.
ServerKeyExchange	For certain key exchange algorithms, the information from the certificate is not sufficient for the client to generate the so-called pre-master secret. In this case the missing information is transferred using Server Key Exchange.
CertificateRequest	The server requests a certificate from the client to verify the identity of the client.
ServerHelloDone	The server notifies the client that sending of the initial information is complete.
Certificate	The client communicates its certificate, including the public key, to the server. The procedure is the same as in the opposite direction: If the server does not trust the certificate sent by the client, the connection establishment is aborted.
ClientKeyExchange	The client generates an encrypted pre-master secret and uses the server's public key to send the secret to the server using asymmetric encryption. This pre-master secret, the "server random" and the "client random" are then used to calculate the symmetric key that is used for communication after the connection has been established.
CertificateVerify	The client signs the previous handshake messages with its private key. Since the server has obtained the client's public key by sending the certificate, it can verify that the certificate presented really "belongs" to the client.
ChangeCipherSpec	The client notifies the server that it is switching to symmetric cryptography. From here on every message from the client to the server is signed and encrypted.
Finished	The client notifies the server in encrypted form that the TLS connection establishment on its side is complete. The message contains a hash and a MAC relating the previous handshake messages.
ChangeCipherSpec	The server decrypts the pre-master secret that the client encrypted with its public key. Since only the server has its private key, only the server can decrypt this pre-master secret. This ensures that the symmetric key is only known to the client and the server. The server then calculates the symmetric key from the pre-master secret and the two random sequences and notifies the client that it too is now communicating using symmetric cryptography. From here on every message from the server to the client is signed and encrypted. By generating the symmetric key, the server can decrypt the client's Finished message and verify both hash and MAC. If this verification fails, the connection is aborted.
Finished	The server notifies the client that the TLS connection establishment on its side is also finished. As with the client, the message contains a hash and a MAC relating to the previous handshake messages. On the client side, the same verification is then performed as on the server. Here too, if the hash and MAC are not successfully decrypted, the connection is aborted.
ApplicationData	Once the TLS connection establishment is complete, client and server communicate using symmetric cryptography.

Further Information