TLS developers should ditch 'pseudo constant time' crypto processing
Fixes for Lucky 13-type bugs could still be vulnerable
More than five years after cracks started showing in the Transport Layer Security (TLS) network crypto protocol, the author of the "Lucky 13" attack has poked holes in the fixes that were subsequently deployed.
Back in 2013, University of London Royal Holloway professor Kenneth Paterson popped the then-current version of TLS.
Lucky 13 was based on using fake message padding to induce timing changes in the processing of encrypted messages. Those differences in timing eventually gave an attacker enough information to compute the original message. It was fixed with patches to SSL libraries such as OpenSSL.
Unlucky for you: UK crypto-duo 'crack' HTTPS in Lucky 13 attackREAD MORE
In the intervening years there's been a lot of work on crypto processing, and that prompted Paterson to take a look at the patched versions – what he found isn't encouraging.
In a paper published late last week at the International Association for Cryptologic Research (IACR), to be presented in October at the ACM SIGSAC Conference on Computer & Communications Security, Paterson said implementations that used the "pseudo constant time" approach to fixing Lucky 13 are still vulnerable.
The paper fingered "Amazon's s2n, GnuTLS, mbed TLS and wolfSSL", going on to say that the flaws "apply in a cross-VM attack setting and are capable of recovering most of the plaintext whilst requiring only a moderate number of TLS connections".
"We consider our complete set of results surprising in the light of the huge amount of effort spent on correcting and verifying CBC-mode and HMAC implementations in TLS over the last 5 years," the paper said. It added that "the vulnerable s2n HMAC code had also passed formal verification... nothing short of the full 'belt and braces' approach adopted in OpenSSL is sufficient to provide a robust defence against Lucky 13 style attacks in all their forms".
The researchers' attack on Amazon's open-source implementation of the protocol, s2n, has provided a good insight into how they worked. The team discovered an access pattern to a dynamically allocated memory location – "a buffer used to store part of he key in the HMAC [hash-based message authentication code] calculation".
"For each handshake, we trace the cache set while processing valid messages, and find the cache set exhibiting the activity pattern we expect for the HMAC code," the paper continued.
Access to the right part of memory is what provides the opportunity to launch a timing attack on the cryptography: the researchers split a message into two parts and hashed each part separately, watching how "the number of calls to the internal hash compression function might vary depending on the split point".
Here's a simplified version of their s2n attack algorithm:
Algorithm 1 s2n Simplified Attack 1: function SimplifiedS2NPadOracle(valid msg,attack msg) 2: xor pad ← FindXorPadCache(valid msg) 3: Prime(xor pad) >evict xor pad set from cache 4: Send attacker’s TLS record to target 5: Wait for verification error 6: if Probe(xor pad) then 7: return 1 >buffer was accessed 8: else 9: return 0 >buffer was not accessed 10: end if 11: end function
The researchers notified the relevant package maintainers of the issues. WolfSSL was patched in June 2018; mbed TLS has implemented an interim fix while it works on full patches; GnuTLS has implemented partial patches, and advised users to use Encrypt-then-MAC if users require legacy cipher suites; and Amazon's s2n team will remove CBC-mode cipher suites and take code from BoringSSL to replace its own CBC-mode decryption.
Since researching this kind of attack demanded a close reading of the relevant source code, the researchers noted that they also notified developers of other serious "but easy to patch" bugs in their TLS implementations. ®