Achtung:

Sie haben Javascript deaktiviert!
Sie haben versucht eine Funktion zu nutzen, die nur mit Javascript möglich ist. Um sämtliche Funktionalitäten unserer Internetseite zu nutzen, aktivieren Sie bitte Javascript in Ihrem Browser.

Info-Icon This content is not available in English
System Security
Studierende in den Seminarräumen des O-Gebäudes, Foto: Universität Paderborn, Fotografin: Judith Kraft Show image information

Studierende in den Seminarräumen des O-Gebäudes, Foto: Universität Paderborn, Fotografin: Judith Kraft

Partitioning Oracle Attacks on TLS Session Tickets

A student is currently working on this.

This thesis aims to check the applicability of Partitioning Oracle Attacks [1] against Session Tickets [2] in TLS.

Background

TLS and Session Tickets

TLS is split into two phases. The handshake and actual transmission of (protected) application data. The handshake establishes the parameters, including keys, for the second phase. Usually, this includes a key exchange (Diffie-Hellman) which is computationally expensive and also introduces further round trips/latency.

Hence, session resumption was introduced. For this to work, the server assigns each session an ID. Both, client and server, store the session parameters associated with this ID. Upon resumption, the client sends the ID and reuses the parameters. The server sees the ID, looks up the parameters from a database and can reuse the parameters as well. However, this requires server-side state which is expensive and difficult to manage in multi-server scenarios.

Therefore, session resumption without server-side state [2] ("session tickets") was introduced. Here the server sends the parameters in some structure to the client. This structure is called a session ticket. Upon resumption the client sends the ticket to the server. The server can extract the parameters and reuse them.
It is sufficient that the server understands the format of the tickets. Thus, it is not standardized. As the contents of the tickets (e.g., key material) are confidential, the tickets are usually encrypted using a key only known to the server.

Partitioning Oracle Attacks

Partitioning Oracle Attacks were published in 2021 [1]. These attacks target some AEAD Schemes, including AES-GCM and ChaCha20/Poly1305. In these schemes, the resulting ciphertext is already authenticated. That is, the decryption also checks the authenticity of the ciphertext.
However, the authors have shown that a single specifically constructed ciphertext can be considered valid under multiple keys. That is, it is possible for a single ciphertext C to be considered validly authenticated under multiple keys. Thus, the decryption will not fail, however the resulting plaintext might be malformed.

An attacker can now observe the following behaviors:

  1. The ciphertext is not authenticated (and decryption failed)
  2. The ciphertext is authenticated (and the decryption itself worked)
    • Note that the decrypting party might still throw an error due to the malformed plaintext

Using this information the attacker can more efficiently search for the used key than by just using brute-force:

  1. Choose a set K consisting several keys
  2. Create a ciphertext that is valid under all keys in K
  3. Send the ciphertext to the decrypting party
  4. Observe the behavior
    1. not authenticated -> the used key is not in K
      • try different set: in case of binary search we know the key is in the other set
    2. authenticated -> the used key is in K
      • search in this set; can perform binary search

Goal of this Thesis: Combining the Topics

Several Libraries use AES-GCM or ChaCha20/Poly1305 to protect the ticket contents (cf. list below). Therefore, the question arises whether (and to what extent) the libraries are vulnerable against such attacks.

When a TLS Server receives a ticket modified in this way, we anticipate the following behaviors:

  • Ticket is not authenticated
    • The ticket is ignored -> normal handshake is performed
    • (unlikely) The server sends an explicit error
  • Ticket is authenticated
    • The plaintext cannot be parsed
      • (most likely)  and the ticket is ignored -> normal handshake
      • and the server sends an explicit error
    • The plaintext can be parsed
      • The extracted state is unknown, however we can observe that the server tries to continue with a session resumption handshake

Your job would be trying to differentiate these two behaviors under controlled conditions. We would like to see this integrated into TLS-Attacker.

Requirements

  • Programming skills
  • Knowledge of TLS and session resumption
  • Mathematical know-how
    • Be able to understand how to implement the Partitioning Oracle Attack algorithm for GCM (and possibly Poly1305)

Challenge

(Needs to be done after the Topic was assigned, but before the proposal is written)

Create the code for the Multi-Collide-GCM algorithm [Figure 1, 1] in Java. This is the core algorithm needed for the attack. This will give you insight on how the attack works.

Additionally, you should provide a unit test for this code which checks that it works correctly:

  • Create a set K of N random keys
  • Select a random key k from this set to be used by the oracle
  • Create a ciphertext c valid under this key k
  • Create an oracle function that returns whether a given ciphertext decrypts successfully
  • Use your created code to search for the used key (using binary search)
    • Your code may only take the key set K, the ciphertext c, and the oracle function as an input

References:

[1]: Julia Len, Paul Grubbs, Thomas Ristenpart: Partitioning Oracle Attacks https://www.usenix.org/conference/usenixsecurity21/presentation/len

[2]: RFC 5077: Transport Layer Security (TLS) Session Resumption without Server-Side State. https://datatracker.ietf.org/doc/html/rfc5077

Other Related Work

Algorithms used by TLS Libraries:

  • GCM
    • Botan
    • MatrixSSL (in TLS 1.3)
    • s2n
    • mbedTLS
  • ChaCha20/Poly1305
    • RusTls
Further information:

The University for the Information Society