Applied cryptography in practice (advanced)¶

Above, cryptography has been presented mostly “bottom-up”, although, for example, a very central application area—mobile phone encryption—has been discussed. This section examines three other application areas.

TLS, Transport Layer Security¶

The TLS protocol has already been mentioned several times in passing. It has a long history, and version 1.3 was finalised in 2018. TLS is a complex protocol consisting of three interrelated subprotocols: the handshake, i.e. the TLS Handshake Protocol, uses (typically) an asymmetric algorithm to establish session keys. These are then used by the TLS Record Protocol to encrypt and authenticate application data. The TLS Alert Protocol carries control information and error messages. (More technical detail is provided in the network security module.) Today, TLS protects approximately 95% of all HTTP traffic, and it uses the web PKI to authenticate servers.

TLS 1.3 represents a multi-year effort by engineers and researchers from various organisations working within the IETF to build a general-purpose secure communication protocol. The primary motivations for initiating the work were, firstly, to improve the security of the previous version by updating the core structure and removing obsolete cryptographic primitives, and secondly, to improve performance by reducing the number of message exchanges required to establish a secure connection. In earlier versions of TLS, two exchanges (four messages) were required, whereas TLS 1.3 typically requires only one exchange (two messages). In some cases, the connection can even be resumed immediately if keys were established in a previous session.

An important difference in the design process of TLS 1.3 compared to earlier versions is the extensive reliance on formal security analysis. This led to several research publications, and parts of the analysis uncovered weaknesses in earlier versions of the protocol, which had a decisive impact on the design. One example is the use of HKDF in a consistent, hierarchical manner for handling key material. The protocol was also modified to make it more amenable to formal analysis. TLS 1.3 is almost a complete success story of how universities and industry can work together. There are relatively few criticisms of the process and the result:

Not all security and functionality requirements were identified at the outset, which led to many changes along the way and posed challenges for researchers performing the analysis. However, such an iterative approach appears unavoidable in a complex protocol designed to serve many use cases.
Formal analysis missed a few special cases, particularly those where authentication is based on pre-shared symmetric keys. Later (in 2019), an attack was discovered in one such scenario.
The zero round trip mode of TLS 1.3 is attractively fast, but it sacrifices forward secrecy. Defending against replay attacks in this mode is generally difficult and likely impossible in the case of distributed servers and typical browsers. Research has already proposed improvements to add forward secrecy to this mode.

Secure instant messaging¶

At first glance, instant messaging systems require similar security to that provided by TLS: the communicating parties want to exchange messages securely in pairs. However, there are significant differences that lead to different cryptographic solutions. First, instant messaging is asynchronous, which already means that parties cannot easily use the TLS Handshake Protocol to establish symmetric keys. Second, there is no infrastructure equivalent to the web PKI that could be used for authentication. Third, group messaging is an important use case alongside pairwise communication. Fourth, a dedicated server is typically used to relay messages, and it should not have access to the message contents.

We examine three different instant messaging systems: Apple iMessage, WhatsApp Signal, and Telegram. The focus is on communication between two parties.

Apple iMessage¶

Apple’s iMessage system previously used a signcryption scheme, in which significant vulnerabilities were discovered in 2016. This was despite the fact that signcryption is a well-known and modelled cryptographic primitive, based on general, provably secure structures for public-key encryption and signature. It has been concluded that the designers had to rely on implementations available in Apple’s cryptographic library. This conclusion, as well as further analysis of the system, is based on reverse engineering, as the iMessage implementation is not open source. It is known that the system relied entirely on trust in Apple’s servers when distributing users’ public keys. The system was also designed to provide end-to-end security. Without actively replacing keys, Apple could not read users’ messages. However, the protocol lacked forward secrecy: if a user’s decryption key was compromised, all messages intended for that user could be read. With the release of iOS 14 in 2020, Apple is known to have patched the remaining iMessage vulnerabilities that still existed in version 13.

Signal¶

The Signal protocol, used both in Signal and WhatsApp, handles two-party communication differently from iMessage. It applies Diffie–Hellman–Merkle key exchange in an asynchronous manner known as ratcheting. At a high level, whenever Alice sends Bob a new message, she also includes a DH value and updates her symmetric key based on that DH value and the most recent DH value received from Bob. Bob combines the incoming DH value with the one he previously sent to derive the same new symmetric key. This key is called the chain key.

For each message Alice sends to Bob without receiving a response, she derives two new keys from the current chain key using a KDF (based on HKDF). One key is used as the next chain key, and the other is used to encrypt the current message. The designers of Signal also refer to this as a ratchet, and the combination of this with the DH ratchet is called the double ratchet. This mechanism provides forward secrecy for Signal messages despite their asynchronous nature. It also provides post-compromise security. However, the use of ratchets introduces synchronisation issues: if a message is lost between Alice and Bob, their keys will diverge. This is addressed by storing recent chain keys.

For symmetric encryption, Signal uses a simple and common authenticated encryption construction, where data is first encrypted in CBC mode with AES-256 and then authenticated using HMAC-SHA-256. This is a conservative and well-understood approach.

Authentication in Signal is ultimately similar to iMessage in that it relies on trust in the server. The idea is that users register a set of DH values on the server. Other users retrieve these and use them to establish initial chain keys. However, a malicious server could replace these values and thus perform a man-in-the-middle attack. The use of human-readable fingerprints derived from keys helps mitigate this attack.

The design of Signal has inspired research into how strong protection can be achieved with a two-party protocol in an instant messaging system and how this interacts with synchronisation challenges. However, none of the above implies that the security of the Signal protocol alone makes any messaging application using it entirely secure. Signal is a protocol, whereas a messaging application is complex software. In 2019, WhatsApp suffered from a buffer overflow vulnerability that allowed malware to be installed on a phone simply by placing a WhatsApp call. Answering the call was not even necessary.

Telegram¶

The third type of instant messaging protocol is the model used by Telegram. It combines various cryptographic primitives in an unusual way: RSA, finite-field Diffie–Hellman key exchange, hash-based key derivation, a hash-based MAC, and a non-standard encryption mode called IGE. In addition, it lacks proper key separation: the encryption keys used for messages from Alice to Bob share several bits with the keys used in the opposite direction, and the key bits are taken directly from the values produced by the DH exchange. These properties violate best cryptographic practices and significantly complicate formal security analysis. Furthermore, Telegram does not generally provide end-to-end encryption; instead, it offers two modes, one of which is end-to-end encrypted and the other provides secure communication only between the client and the server. The latter mode appears to be more commonly used, which is also concerning given that Telegram is particularly popular in non-democratic countries.

Contact tracing à la DP-3T¶

One of the more recent applications of cryptography arises from the consequences of the Covid-19 pandemic that began in early 2020. In fact, multiple applications were developed, as various countries created their own exposure tracing systems. Here we outline the outcome of the DP-3T project, Decentralized Privacy-Preserving Proximity Tracing (in fact DP³T). It was developed very quickly by a large working group and has particularly strict privacy properties. However, due to its decentralised structure, it is not well suited for pandemic monitoring.

On a mobile phone, DP-3T is an application that initially generates a random secret key. Based on this, the application derives a new daily key for each day (in a one-way manner), and from that further derives, at 15-minute intervals using AES in CTR mode (i.e. deterministically), a bit string which it broadcasts every couple of minutes via Bluetooth to nearby devices. This bit string is referred to as a beacon, although a flash of a beacon light might be more descriptive. The receiving phones’ application stores the identifier, time, and observed signal strength. When a user of the application receives a positive Covid-19 test result, they use a confirmation code provided by a health authority, with which the application sends recent daily keys to a central server. Other users’ applications learn these by querying the server at regular intervals. The applications compute forward from the list of daily keys to obtain beacon identifiers and may find some that they have previously recorded. The application combines the times, counts, and signal strengths of such observations to determine whether it is necessary to warn the user of exposure.

DP-3T will likely become a historical artefact as the pandemic has passed through the population. Finland’s own application, Koronavilkku, for instance, remained in operation only until the summer of 2022.