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."
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.
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
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.
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.