Optimizing TLS for Low Bandwidth Environments

Abstract

This paper explores alternatives to minimize the overhead of Transport Layer Security (TLS) towards making it usable in bandwidth-constrained environments. Several areas are identified where overhead can be reduced while remaining fully compatible with standard Transport Layer Security. The most relevant one consists of moving to Elliptic Curve Cryptography (ECC) from RSA in the certificates, which reduces the overhead of the TLS handshake between 22 % and 60 % depending on the chosen security level.

We also propose two TLS extensions that further reduce the size of the handshake: using a more compact certificate format and certificate caching. Using compact certificates instead of ECC based X.509 certificates reduces the overhead of the handshake between 11 % and 20 % depending on the security level. Using certificate caching avoids exchanging certificates more than once irrespective of the number of times that the handshake is performed.

A Transport Layer Security (TLS)

The TLS protocol suite, specified in RFC 5426 [9], aims at providing confidentiality and integrity between a client and a server—the end points—communicating over an untrusted network.

This appendix summarizes the most important elements of TLS for the purposes of this paper. Focus will be given to the latest version (i.e. TLS v. 1.2). We refer to [9, 26] for more authoritative and detailed descriptions of TLS.

1.1 A.1 TLS Goals

End Point Authentication. The client can authenticate the server to make sure that it is not communicating with a third party trying to impersonate the server. This authentication takes place using an X.509 [7] public key certificate provided by the server, which the client must validate. Once the client has validated the server certificate, it authenticates the server by requesting it to prove possession of the associated private key. The server may request the client to authenticate using an analogous mechanism.

The roots of trust for end point authentication are the trusted Certification Authorities (CAs), whose certificates must be provisioned to each end point. These trusted certificates need to be distributed or configured by some offline means. Additional intermediate certificates in the certificate chain can be either provisioned using the same means, or sent during the handshake (cf. Appendix A.4).

End point authentication is not mandatory in TLS. It is possible—albeit rare—to find anonymous TLS connections providing only confidentiality and integrity (but not entity authentication). Usually in TLS the client authenticates the server. The connection is said to be mutually authenticated when both client and the server have authenticated to one another.

Data Confidentiality and Integrity. Once established, TLS protects the integrity and confidentiality of the application data exchanged between the end points. This is achieved by encrypting the application data exchanged using the record protocol (cf. Appendix A.5) and adding a Hash-based Message Authentication Code (HMAC), using key material derived during the handshake (cf. Appendix A.4).

The secure tunnel that TLS provides not only guarantees integrity of the individual messages exchanged, but also of the session, i.e. the sequence of messages. This is an important benefit, as weaknesses in security protocols due to so-called Man-in-the-Middle attacks where an attacker replays, reorders, or manipulates some individual messages are not uncommon, even in security-critical protocols used for financial transactions, e.g. see [2, 4, 11, 31].

1.2 A.2 TLS Requirements

To use TLS a bidirectional, reliable link is required. If the link is not reliable, then TLS can be used only on top of a protocol ensuring reliability. Additionally, the end points must be able to perform cryptographic operations, including public key cryptography. If they do not have resources to perform such operations, then “traditional” TLS is not suitable².

1.3 A.3 Benefits of Using TLS

Using TLS is advantageous because there are existing and well maintained implementations. In addition, these implementations and the protocol itself receive wide scrutiny from the security community. TLS is very flexible regarding the security levels that can be achieved. There are known attacks, e.g. [6, 24], but most of them can be avoided by fine tuning the implementations and enabling only essential extensions. In the case of Machine-to-Machine (M2M) communication, the focus of this paper, Man In The Middle (MITM) and impersonation attacks can be prevented by having certificate checks strictly and automatically enforced.

1.4 A.4 TLS Handshake

Execution of the TLS handshake achieves the following three goals: the end points (1) agree on a cipher suite, (2) calculate a master secret, and (3) may have authenticated to each other.

A cipher suite is a combination of the following four algorithms:

• Key exchange used by the end points to agree on the pre-master secret, a shared bit string only known by the end points. There are fundamentally three key exchange mechanisms: RSA, Diffie-Hellman (DH) and Elliptic Curve Diffie-Hellman (ECDH)³. The pre-master secret is used in conjunction with random values generated by the end points to generate the master secret, which is then used to derive the keys that will subsequently be used to encrypt the application layer data and generate the HMAC to protect its integrity.

• Server authentication used by the server to authenticate to the client. The most frequent are RSA and DSS.

• Bulk encryption used to encrypt the application layer data, e.g. RC4, 3DES-EDE, Advanced Encryption Standard (AES).

• Digest used to hash the application layer data, e.g. MD5, SHA1.

A full handshake is illustrated in Fig. 2a. It is initiated by the client, who sends the ClientHello message to the server. This message lists the cipher suites and extensions supported by the client. It also includes a client-generated random value.

Upon receiving the ClientHello, the server responds with a ServerHello message. This message selects the cipher suite and a subset of the extensions that shall be used during the rest of the session, along with a server-generated random value and a server-assigned session identifier (Session ID). If the server is to authenticate to the client (which is usually the case), it sends its X.509 public key certificate in a Certificate message. It may send more than one certificate in the chain to allow the client to properly validate its certificate. The server sends a ServerKeyExchange message to provide the client with its public key to be used for deriving the pre-master secret. This message is only sent when (EC)DH is used for key exchange. The key included in the ServerKeyExchange message is signed by the server using the private key associated to the public key included in the server certificate that was sent to the client. If the server requires the client to also authenticate (to the server), then it sends the CertificateRequest message. The server signals the end of its messages by sending a ServerHelloDone message.

Fig. 2.

TLS handshake.

The client checks the messages received from the server. It makes sure that the cipher suite and extensions are actually supported and that the server certificate is valid. If the server sent a ServerKeyExchange message, it checks that the signature of the server’s public key is valid. If the server requested the client to authenticate, then the client sends its X.509 certificate in a Certificate message. The client then sends the ClientKeyExchange message. If RSA is used for key exchange, this client generates a random bit string (the pre-master secret) and encrypts it using the server public key included in the server certificate. Then it includes the result of the encryption operation in the ClientKeyExchange message. If (EC)DH is used, it just sends its DH public key to the server using this message. Upon receiving the ClientKeyExchange message, in the RSA case, the server can decrypt the pre-master secret (thus implicitly proving possession of its private key). In the (EC)DH case, the server can simply use the client public key to derive the shared secret, which is then used as the pre-master secret. In either case, after receiving this message, the client and the server share the pre-master secret, which can then be used to derive the master secret, and subsequently the shared key material that is later to be used to protect the application layer data. If client authentication takes place, the client sends a CertificateVerify message to the server. This message includes a signature (using the client’s private key) of all the handshake messages exchanged so far. The client sends the ChangeCipherSpec message⁴ to the server, to signal that from this point forth the negotiated cipher and derived keys shall be used. The client notifies the server that it has finished the handshake by sending the Finished message. This is the first message to be actually encrypted and includes a Message Authentication Code (MAC) of all handshake messages up to and including the ChangeCipherSpec.

To terminate the handshake, the server sends the ChangeCipherSpec followed by the Finished message to the client. These messages have the converse semantics as the ones received from the client.

Once the server initiated Finished message is received by the client (and its MAC has been validated), the end points can start exchanging application data using the record protocol, as described in Appendix A.5.

Resumed Handshake and Rehandshake. A full handshake (as described so far) marks the beginning of a new session. A session may span several connections between the client and the server. For example, when accessing a web site using HTTP on top of TLS (HTTPS), each object is fetched using a different connection, but most of these connections belong to the same session.

When a new connection is established, the client may indicate to the server its willingness to reuse an existing session by including the Session ID field in the ClientHello message. If the server accepts, it echoes the same Session ID in the ServerHello message. In this case a resumed handshake as illustrated in Fig. 2b takes place.

The resumed handshake reuses the master secret that has been previously calculated, but uses the new random values exchanged in the *Hello messages to calculate new session keys. Clearly, the resumed handshake is much more efficient than the full handshake because neither certificates are exchanged nor public key operations are performed.

When the client wants to negotiate a new cipher suite or refresh the session keys, it can request a rehandshake by simply sending a ClientHello to the server. Conversely, if the server decides to initiate the rehandshake, it may do so by sending a HelloRequest message to the client. Whether the subsequent handshake is full or resumed depends on the Session ID being present in the *Hello messages.

1.5 A.5 TLS Record Protocol

Application layer data is split into fragments by the TLS record protocol. Each of these fragments is appended with an HMAC, which is used to protect the integrity of the fragment and the stream. The fragment payload and the HMAC are then encrypted in order to ensure confidentiality (cf. Appendix A.1). A record is then built by prepending a header (record type = application data, protocol version, length) to the encrypted fragment. Once assembled, the record is handled to the lower (transport) layer for delivery to the receiving end point.

1.6 A.6 TLS Alert Protocol

Whenever an anomaly is detected by one of the end points, the alert protocol is used to signal it to the other one. The alert protocol builds on the record layer and includes a level (warning or fatal) and an alert code. If the level is fatal, the connection must be terminated.