Exams of IT, IT Certification, Plaintext integrity, Security of generic composition

Authenticated decryption with CCM – Authenticated Encryption

Posted by Whitney Koehler

15.5.2 Authenticated decryption with CCM

To decrypt and authenticate Alice’s message using CCM, Bob must provide the following four inputs:

  • The shared secret key ke
  • The nonce n
  • Additional authenticated data d
  • The encrypted and authenticated message c ∥U

In the first step, Bob computes the key stream Si = ek(Ai) and decrypts Alice’s message by XORing it with the key stream. As a result, Bob obtains the following:

  • The original plaintext message m
  • The decrypted MAC value T

In the second step, Bob uses m and the additional authenticated data d to compute the CBC-MAC value T. If the received T and the computed T are equal, Bob accepts Alice’s message.

To preserve the security guarantees, the maximum number of block cipher encryption operations in CCM – that is, encryptions in CBC-MAC and in CTR – is 261. In other words, using CCM, Alice can authenticate and encrypt a maximum of roughly 16 million terabytes under the same shared secret k.

Moreover, the nonce n must never be used more than once for a given key k. The reason behind this is that CCM uses CTR mode for encryption and CTR is effectively a stream cipher. Reusing the nonce will therefore lead to repetition of the key stream.

15.6 AEAD in TLS 1.3

In TLS version 1.3 – in contrast to previous TLS versions – all ciphers used to protect the payloads in the TLS Record protocol are AEAD ciphers. As discussed above, an AEAD algorithm takes the following data as input:

  • A plaintext to be encrypted and authenticated
  • A single shared secret key
  • A nonce
  • Additional data to be authenticated, but not encrypted

In TLS 1.3, either client˙write˙key or server˙write˙key is the shared secret key. Moreover, one of the two initializations vectors client˙write˙iv (supplied by the client) or server˙write˙iv (supplied by the server) and a sequence number are used for generating the nonce. Finally, the plaintext is stored in the TLSInnerPlaintext structure, and the additional data to be authenticated is in the record header:
additional_data = TLSCiphertext.opaque_type || TLSCiphertext.legacy_record_version || TLSCiphertext.length

The output of the AEAD algorithms consists of the ciphertext and authentication tag computed in the authenticated encryption process, as follows:
AEADEncrypted = AEAD-Encrypt(write_key, nonce, additional_data, plaintext)

Subsequently, the encrypted˙record field in the TLSCiphertext data structure is set to the AEADEncrypted value. When the receiver wants to verify and decrypt the record, it uses the ADAD operation, which takes the following data as input:

  • The single shared secret key
  • The nonce
  • The additional data to be authenticated
  • The ciphertext

The plaintext of the encrypted TLS record is then computed as follows:
plaintext of encrypted_record = AEAD-Decrypt(peer_write_key, nonce, additional_data, AEADEncrypted)

The ADAD operation produces one of the following outputs. If the decryption failed – for example, because the integrity of the message could not be successfully verified – ADAD returns an error. In that case, the receiving TLS endpoint immediately terminates the TLS connection and sends a bad˙record˙mac message. Otherwise, if the message’s authenticity and integrity can be successfully verified, ADAD returns the plaintext.

The TLS 1.3 specification does not allow an AEAD algorithm to produce an expansion larger than 255 bytes. Thus, if a TLS 1.3 endpoint receives a TLS record with TLSCiphertext.length larger than 214 + 256 bytes, it has to end the connection, sending a record˙overflow alert. The limit is the sum of the maximum TLSInnerPlaintext length of 214 + 1 bytes for ContentType and the maximum AEAD expansion of 255 bytes.

15.7 Summary

In this chapter, we covered authenticated encryption and authenticated encryption with additional data. To understand the security implications of different authenticated encryption schemes, we first introduced the security notions IND-CPA, IND-CCA, NM-CPA, INT-PTX, and INT-CTX.

We then studied the encrypt-and-MAC, MAC-then-encrypt, and encrypt-then-MAC variants of generic composition that can be used to construct an authenticated encryption scheme from simpler cryptographic primitives (namely, a block cipher and a message authentication code).

Finally, we had a closer look at the counter with cipher block chaining message authentication code as a concrete example of an AEAD algorithm. Moreover, we looked into how AEAD algorithms are used in TLS 1.3.

In the next chapter, we will take a detailed look at the Galois/Counter Mode (GCM), the mandatory-to-implement AEAD algorithm used in TLS 1.3.

Related Post

Leave A Comment