Part 3:
The Nonce that came Twice

TLS symmetric cipher options

  • CBC/HMAC (Padding Oracles)
  • RC4 (Stream biases)
  • AEAD modes: AES-GCM and Poly1305/ChaCha20 (new)

Let's look at GCM

"There's also an annoying niggle with AES-GCM in TLS because the spec says that records have an eight byte, explicit nonce. Being an AEAD, the nonce is required to be unique for a given key. Since an eight-byte value is too small to pick at random with a sufficiently low collision probability, the only safe implementation is a counter. [...] Thankfully, all the major implementations use a counter and I did a scan of the Alexa, top 200K sites to check that none are using random values - and none are."

Langley, 2014

Nonce

If you use the same Nonce twice (with the same key) it's no longer a nonce.

TLS: 8 Byte / 64 Bit nonce for GCM

Shall we look at TLS 1.2 again?

Each value of the nonce_explicit MUST be distinct for each distinct invocation of the GCM encrypt function for any fixed key. Failure to meet this uniqueness requirement can significantly degrade security. The nonce_explicit MAY be the 64-bit sequence number.

TLS 1.2 / RFC 5246, 2008

In other words:

Dear Developer, please make sure this is a Nonce. How you do that is your problem.

Of course nobody will get that one wrong.

Let's check

Internet-wide scan

184 hosts with repeating nonces

72445 hosts with random looking nonces

Finding affected vendors

This is often quite difficult.

There's a widespread mentality to hide what hardware or software products people use for their infrastructure.

This mentality makes it harder to fix things and can harm security.

Some hints

Certificate info, website content, HTTP "Server:" header.

Headers

HTTP "Server:" header can be misleading due to load balancers / firewalls.

"X-Forwarded-By" header is supposed to fix this, but it is hardly used.

Duplicate nonces

We could identify two vendors

Radware (Cavium chip), update from vendor

Brocade (several pages from VISA Europe), status unknown

Devices with random nonces

A10, IBM Lotus Domino (both published updates).

Sangfor (no vendor response).

It looks random, but isn't

40:3e:64:76:20:5b:1a:de
20:1f:32:3b:90:2d:0d:6f

Check Point devices using LFSR - this is secure.

More?

There are more devices with different behaviors that we were unable to identify.

Security test tools and pen testers should checks for this.

What's this? (Radware and others)

0100000003001741
0100000003001741
f118cd0fa6ff5a15
f118cd0fa6ff5a16
f118cd0fa6ff5a74

OpenSSL 1.0.1j

t1_enc.c:

	if (EVP_CIPHER_mode(c) == EVP_CIPH_GCM_MODE)
		{
		EVP_CipherInit_ex(dd,c,NULL,key,NULL,(which & SSL3_CC_WRITE));
		EVP_CIPHER_CTX_ctrl(dd, EVP_CTRL_GCM_SET_IV_FIXED, k, iv);
		}

e_aes.c (EVP_CIPHER_CTX_ctrl/aes_gcm_ctrl):

		if (c->encrypt &&
			RAND_bytes(gctx->iv + arg, gctx->ivlen - arg) <= 0)
			return 0;

The Forbidden Attack

Described by Antoine Joux during NIST GCM standardization (2006).

Nonce reuse allows an attacker to recover the authentication key.

Given the authentication key an attacker can manipulate known content simply by XORing.

(Without authentication GCM is just Counter Mode.)

Video / PoC

Böck et al, 2016

How to fix?

1.  The 64-bit record sequence number is encoded in network byte
    order and padded to the left with zeros to iv_length.

2.  The padded sequence number is XORed with the static
    client_write_iv or server_write_iv, depending on the role.

The resulting quantity (of length iv_length) is used as the per-
record nonce.

TLS 1.3, draft 21

Nonce value is completely derived from other values.

Any implementation that gets this wrong couldn't connect any more.

Outlook

Synthetic IV / Nonce-misuse resistance

Encryption modes that derive the Nonce from the message.

AES-SIV / RFC 5297

Several modes with nonce-misuse resistance in CAESAR competition.

Conclusion

  • Nonce repetition in GCM is a severe risk.
  • TLS 1.2 makes this particularly problematic due to lack of guidance.
  • TLS 1.3 improves situation considerably with implicit nonce construction.