Authenticated Encryption and Secure Channels. Kenny Paterson Information Security ;

Transcription

1 Authenticated Encryption and Secure Channels Kenny Paterson Information Security ;

2 Overview Monday: Secure channels and their properties Security for symmetric encryption from block ciphers to AEAD Tuesday: TLS SSH 2

3 TLS Overview

4 Introducing TLS SSL = Secure Sockets Layer. Developed by Netscape in mid 1990s. SSLv2 deprecated, SSLv3 broken; both widely supported on servers. TLS = Transport Layer Security. IETF-standardised version of SSL. TLS 1.0 = SSLv3 with minor tweaks, RFC 2246 (1999). TLS 1.1 = TLS tweaks, RFC 4346 (2006). TLS 1.2 = TLS more tweaks, RFC 5246 (2008). TLS 1.3 = major redesign currently underway in TLS WG of IETF. 4

5 Introducing TLS Originally for secure e-commerce, now used much more widely. Retail customer access to online banking facilities. User access to gmail, facebook, Yahoo. Mobile applications, including banking apps. Payment infrastructures. User-to-cloud. Post Snowden: back-end operations for Google, Yahoo, TLS has become the de facto secure protocol of choice. Used by hundreds of millions of people and devices every day. 5

6 Highly Simplified View of TLS Used by client and server to 1. Negotiate ciphersuite 2. Authenticate 3. Establish keys used in the Record Protocol Client Handshake Protocol Server Record Protocol Provides confidentiality and authenticity of application layer data using keys from Handshake Protocol 6

7 TLS Protocol Architecture Handshake Protocol Change Cipher Spec Protocol Alert Protocol HTTP, other apps Record Protocol TCP 7

8 The TLS Ecosystem (1/3) Servers Including managed service providers (CloudFlare, Akamai) Clients Of all shapes and sizes Certification service providers Of all shapes, sizes and levels of security Software vendors From Google down to one-man open-source operations OpenSSL somewhere in-between Hardware vendors 8

9 The TLS Ecosystem (2/3) TLS versions: SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2 Many servers even still support SSL 2.0 (--> DROWN attack) 200+ ciphersuites Some quite common, e.g. TLS_RSA_WITH_AES_128_CBC_SHA256 Some more esoteric, e.g.tls_krb5_with_3des_ede_cbc_md5 Some offering no security: TLS_NULL_WITH_NULL_NULL! TLS extensions DTLS 9 Too numerous to mention.

10 The TLS Ecosystem (3/3) IETF TLS Working Group Also IETF UTA Working Group (UTA = Using TLS in Applications) And CFRG (Crypto Forum Research Group) Growing community of researchers The TLS ecosystem has become very complex and vibrant. 10

11 The TLS Ecosystem (4/3) (bonus slide) 11

12 A Newsworthy Protocol TLS has been in the news.. BEAST (2011), CRIME (2012), Lucky 13 (2013), RC4 attacks (2013), POODLE (2014), RC4 (again) (2015), AES-GCM with bad randomness (2016), SWEET32 (2016), Renegotiation attack (2009), triple Handshake attack (2014), FREAK and LOGJAM (2015), SLOTH (2016), DROWN (2016), Poor quality of implementations (particularly in certificate handling). Why Eve and Mallory Love Android (2012) The most dangerous code in the world (2012) Apple goto fail (2013) GnuTLS certificate processing bug (2013) Truncation and cookie cutter attacks (2013, 2014) OpenSSL CCS bug (2014) Frankencerts (2014) Mostly tech press, with limited crossover to mainstream media. 12

13 A Newsworthy Protocol TLS has really been in the news... Heartbleed bug. Pressure built and the dam finally broke? Severity of the threat: leakage of private information, inc. server private keys + widespread use of OpenSSL. Practical demonstration of threat. A good logo! 13

14 TLS Protocol Architecture Handshake Protocol Change Cipher Spec Protocol Alert Protocol HTTP, other apps Record Protocol TCP 14

15 TLS Record Protocol TLS Record Protocol provides: - Data origin authentication, integrity using a MAC. - Confidentiality using a symmetric encryption algorithm. - Anti-replay using sequence numbers protected by the MAC. - Optional compression. - Fragmentation of application layer messages (but not reassembly!). - A streaming interface to calling applications. 15

16 TLS Record Protocol: MAC-Encode-Encrypt SQN HDR Payload MAC Payload MAC tag Padding Encrypt HDR Ciphertext 16 MAC Encrypt Padding HMAC-MD5, HMAC-SHA1, HMAC-SHA256 CBC-AES128, CBC-AES256, CBC-3DES, RC or or or. or FF FF.FF

17 Operation of TLS Record Protocol Data from layer above is received and partitioned into fragments (max size 2 14 bytes). Optional data compression. Default option is no compression. Calculate MAC on sequence number, header fields, and data, and append MAC to data. Pad (if needed by encryption mode), then encrypt. Prepend 5-byte header, containing: Content type (1 byte, indicating content of record, e.g. handshake message, application message, etc), SSL/TLS version (2 bytes), Length of fragment (2 bytes). Submit to TCP. 17

18 Operation of TLS Record Protocol In-bound processing steps reverses these steps: 1. Receive message, of length specified in HDR. 2. Decrypt. 3. Remove padding. 4. Check MAC. 5. (Decompress payload.) 6. Pass payload to upper layer (note: no defragmentation; TLS provides a stream of fragments to the application). Errors can arise from any of decryption, padding removal or MAC checking steps. All of these are fatal errors in TLS. 18

19 AEAD and TLS Record Protocol MEE only for all versions of SSL and TLS up to TLS 1.1. Security? Dedicated Authenticated Encryption with Associated Data (AEAD) algorithms were added in TLS Single algorithm providing both confidentiality and integrity/data origin (authentication) Need not conform to MEE template. General AEAD interface specified in RFC AES-GCM specified in RFC AES-CCM specified in RFC 6655.

20 AEAD and TLS Record Protocol TLS 1.2 support on major websites: 9/2012: 5%; 9/2013: 17%; 9/2014: 43%; 9/2015: 66%; 9/2016: 79% (source: ssl pulse) TLS 1.2 support in browsers: Chrome: since release 30. Firefox: since release 28. IE: since IE11. Safari: since ios5 and OS X (source: wikipedia, Nov. 2013) 20 20

21 Historical AEAD Usage in TLS Snapshot from ICSI Certificate Notary Project (Sept. 2014): 16.3% 1.6% 21

22 Current AEAD Usage in TLS Snapshot from ICSI Certificate Notary Project (Aug. 2016): > 60% 1.2% 22

23 BEAST

24 BEAST IV chaining: use last block of previous ciphertext as IV. Default in CBC mode for SSLv3 and TLS 1.0. Leads to a chosen-plaintext distinguishing attack against TLS. 24 First observed for CBC mode in general by Rogaway in Application to TLS noted by Dai and Möller in Extended to theoretical plaintext recovery attack by Bard in 2004/2006. Turned into a practical plaintext recovery attack on HTTP cookies by Duong and Rizzo in 2011 the BEAST. BEAST = Browser Exploit Against SSL/TLS 16-year demonstration that attacks do get better with time.

25 CBC Mode Reminder P i-1 e K C i-1 P i e K C i Initialisation Vector (IV): Defines C 0 for processing first block. Chained IVs are common in applications, and in SSL 3.0 and TLS 1.o in particular. TLS 1.1 and 1.2 require IV to be random. C i-1 d K C i d K CBC mode needs some form of padding if plaintext lengths are not multiple of block length. P i-1 P i More on padding later. 25

26 Attacking Chained IVs Suppose attacker wishes to distinguish encryptions of single blocks P 0, P 1. Attacker makes LoR encryption query for message pair (P 0, P 1 ). Attacker receives ciphertext C = C 1 for message P b where some known, previous block C 0 was used as the IV. P b e K C 0 C 1 26

27 Attacking Chained IVs C 1 will be used as the IV for the next encryption. Attacker now makes LoR query on message P 0 C 0 C 1. Attacker receives single block ciphertext C 2. P b P 0 C 0 C 1 e K e K C 0 C 1 C 2 27

28 Attacking Chained IVs P b P 0 C 0 C 1 e K e K C 0 C 1 C 2 If P b = P 0, then inputs to block cipher are the same in both encryptions. Hence, if P b = P 0, then C 1 = C 2. Otherwise, if P b = P 1, then C 1 C 2. So looking at C 1 and C 2 gives us a test to distinguish encryptions of P 0 and P 1. 28

29 Attacking Chained IVs Distinguishing attack extends easily to multi-block messages. Breaks CBC mode in the IND-CPA security model. So IV chaining for CBC mode is broken in theory. How can we turn this into a practical attack on TLS? We want plaintext recovery rather than a distinguishing attack. We need to find a way to realise the chosen plaintext requirement. 29

30 The BEAST Part 1 P 0 P 14 P 15 P C 0 C 1 e K e K C 0 C 1 C 2 Assume bytes P 0, P 1, P 14 are known, try to recover P 15. Use P 0 P 1 P 14 as first 15 bytes of P. Iterate over 256 possible values in P 15. P 15 = P 15 if and only if C 1 = C 2. So average of 128 trials (each involving one chosen plaintext) to extract P 15 when remaining bytes in block are known. 30

31 The BEAST Part 2 P 0 P 1 P 2 P 3 P 4 P 5 P 6 P 7 P 8 P 9 P 10 P 11 P 12 P 13 P 14 T 0 T 1 T 2 T 3 T 4 T 5 P 0 P 1 P 2 P 3 P 4 P 5 P 6 P 7 P 8 P 9 P 10 P 11 P 12 P 13 P 14 T 0 T 1 T 2 T 3 T 4 T 5 P 0 P 1 P 2 P 3 P 4 P 5 P 6 P 7 P 8 P 9 P 10 P 11 P 12 P 13 P 14 T 0 T 1 T 2 T 3 T 4 T 5 0 P 1 P 2 P 3 P 4 P 5 P 6 P 7 P 8 P 9 P 10 P 11 P 12 P 13 P 14 T 0 T 1 T 2 T 3 T 4 T 5 Now assume attacker can control position of unknown bytes in stream with respect to CBC block boundaries (chosen boundary privilege). Repeat previous single-byte recovery attack with sliding bytes. Green: initially known bytes. Red: unknown (target) bytes. 31 Orange: recovered bytes.

32 The BEAST Part 3 Cookie for remote site Browser TLS tunnel 32

33 BEAST Key Features BEAST JavaScript loaded ahead of time into client browser from compromised or malicious wesbite. Provides chosen-plaintext capability. Attack target is HTTP secure cookie. JavaScript uses HTTP padding to control positions of unknown bytes (chosen boundary privilege). Difficult to get fine control over byte/block positions. Need to be able to inject chosen plaintext block at the very start of Record Protocol messages. JavaScript also needs to communicate with MITM attacker. Summary: it s complicated, but it can be made to work.* *Given a zero-day in the browser! 33

34 BEAST Impact The BEAST was a major headache for TLS vendors. Perceived to be a realistic attack. Most client implementations were stuck at TLS 1.0. Best solution: switch to using TLS 1.1 or 1.2. Uses random IVs, so attack prevented. But these version were not widely supported server-side at time of attack. For TLS 1.0, various hacks were done: Use 1/n-1 record splitting in client. Now implemented in most browsers. Send 0-length dummy record ahead of each real record. Breaks some implementations. Or switch to using RC4? 34

35 BEAST Lessons A theoretical vulnerability pointed out in 1995 became a practical attack in Attacks really do get better (worse!) with time. Practitioners really should listen to (some) theoreticians. And, in this case, they did: TLS 1.1 and 1.2 use random IVs. Problem was that no-one was using these versions in Tools from the wider security field were needed to make the attacks headline news. Man-in-the-browser via Javascript. Fair game given the huge range of ways in which TLS get used. Maybe those tools can be used elsewhere? 35

36 Padding Oracle Attacks

37 TLS Record Protocol: MAC-Encode-Encrypt SQN HDR Payload MAC Payload MAC tag Padding Encrypt HDR Ciphertext 37 MAC Encrypt Padding HMAC-MD5, HMAC-SHA1, HMAC-SHA256 CBC-AES128, CBC-AES256, CBC-3DES, RC or or or. or FF FF.FF

38 TLS Record Protocol Padding Padding in TLS 1.0 and up has a particular format: Always add at least 1 byte of padding. 38 If t bytes are needed, then add t copies of the byte representation of t-1. So possible padding patterns in TLS are: 00; 01 01; ; - SSLv3 has weaker format requirements: 00;?? 01;???? 02;.

39 TLS Record Protocol Padding Variable length padding is permitted in all versions of TLS (but not in SSL). Up to 256 bytes of padding in total: FF FF. FF From TLS 1.0: Lengths longer than necessary might be desirable to frustrate attacks on a protocol based on analysis of the lengths of exchanged messages. 39

40 Handling Padding During Decryption TLS 1.0 error alert: decryption_failed: A TLSCiphertext decrypted in an invalid way: either it wasn`t an even multiple of the block length or its padding values, when checked, weren t correct. This message is always fatal. Suggests padding format should be checked, but without specifying exactly what checks should be done. Legacy of SSLv3, where no checking can be done because of loose requirements on padding format. 40

41 Exploiting Weak Padding Checks Möller Attack SSL/TLS decryption sequence: CBC mode decrypt, remove padding, check MAC. [M04]: failure to check padding format leads to a simple attack recovering the last byte of plaintext from any block. Assumptions for the attack: Attacker has a special TLS ciphertext containing a complete block of padding. So MAC ends on block boundary for this ciphertext. 41 Padding is removed by inspecting last byte only (cf SSLv3).

42 Möller Attack Blocks from special ciphertext C t-2 C t-1 C t d K d K d K Byte value is 0F here 42

43 Möller Attack Blocks from special ciphertext Target ciphertext block from stream C t-2 C t-1 C* d K d K d K Enabling recovery of last byte of d K (C*) here. 43 Decryption succeeds if and only if byte value is 0F here

44 Möller Attack Decryption succeeds if and only if: C t-1 d K (C*) = (??,??,...??, 0F) Failure of decryption results in visible error message. Hence attacker can recover last byte of d K (C*) with probability 1/256. Success enables recovery of last byte of original plaintext P* corresponding to C* in the CBC stream, by solving system of eqns: C t-1 d K (C*) = (??,??,...??,0F) C* -1 d K (C*) = P* where C* -1 is the block preceding C* in the stream. 44

45 POODLE attack In SSLv3, no format checking is possible! So Möller s attack already breaks CBC mode in SSLv3. Combine with BEAST ideas to move target plaintext bytes into correct position for attack one-by-one. Resulting combination of techniques is known as the POODLE attack (Duong et al. 2014). POODLE = Padding Oracle on Downgrade Legacy Attack No zero-day vulnerability is needed. 10 years from Möller s original observation to POODLE. 45

46 POODLE attack There is no effective countermeasure to POODLE attack. Receiver cannot do more rigorous padding checks, because sender cannot be relied upon to use TLS format in SSL! Cannot switch to RC4 because that s also broken. So this POODLE kills SSLv3. What s the problem? No modern browser requests SSLv3! SSL/TLS version negotiation mechanism is not properly implemented by many servers. An active MITM attacker can downgrade client and server to SSLv3 by spoofing server responses in SSL/TLS handshake. Only solution is to completely remove SSLv3 support in browsers. 46

47 Full Padding Check In TLS 1.1 and up: Each uint8 in the padding data vector MUST be filled with the padding length value. The receiver MUST check this padding. So decryption checks that bytes at the end of the plaintext have one of the following formats: 00; 01, 01; 02, 02, 02;. FF, FF,..FF; and outputs an error if none of these formats is found. NB Other sanity checks may also be needed during decryption. 47

48 Padding Oracles Vaudenay [V02] proposed the concept of a padding oracle. Padding Oracle P=Dec K (C) Check padding of P C Valid/Invalid Vaudenay showed that, for CBC mode and for certain padding schemes, a padding oracle can be used to build a decryption oracle! 48 48

49 Padding Oracle Attack for TLS Padding XOR with various Δ here and submit to padding oracle C t-1 C t d K P t-1 d K P t Recovering true plaintext byte via P t Δ = (. 00) Eventually produces valid pad 00 here 49

50 Padding Oracle Attack for TLS Padding XOR with Δ 1 Δ 0 here and submit to oracle C t-1 C t d K d K P t-1 P t This byte now set to 01 by setting Δ 0 :=Δ 01 Recovering true plaintext byte via P t (..Δ 1 Δ 0 ) = (.0101) Eventually produces valid pattern here 50

51 Padding Oracle Attack for TLS Padding An average of 128 trials are needed to extract the last byte of each plaintext block. Can extend to the entire block, with an average of 128 trials per byte. Can extend to the entire ciphertext. Because attacker can place any target block as last block of ciphertext. 51

52 TLS Padding Oracles In Practice? In TLS, an error message during decryption can arise from either a failure of the padding check or a MAC failure. Vaudenay s padding oracle attack will produce an error of one type or the other. Padding failure indicates incorrect padding. MAC failure indicates correct padding. If these errors are distinguishable, then a padding oracle attack should be possible. 52

53 TLS Padding Oracles In Practice? Good news (for the attacker): The error messages arising in TLS 1.0 are different: bad_record_mac decryption_failed Bad news: But the error messages are encrypted, so cannot be seen by the attacker. And an error of either type is fatal, leading to immediate termination of the TLS session. 53

54 TLS Padding Oracles In Practice? Canvel et al. [CHVV03] : Recall the sequence: decrypt, check padding, check MAC. A MAC failure error message will appear on the network later than a padding failure error message. Because an implementation would only bother to check the MAC if the padding is good. So timing the appearance of error messages might give us the required padding oracle. Even if the error messages are encrypted! Amplify the timing difference by using long messages. But the errors are fatal, so it seems the attacker can still only learn one byte of plaintext, and then with probability only 1/

55 OpenSSL and Padding Oracles Canvel et al. [CHVV03]: The attacker can still decrypt reliably if a fixed plaintext is repeated in a fixed location across many TLS sessions. e.g. password in login protocol or an HTTP session cookie. A multi-session attack. Modern viewpoint: use BEAST-style malware to generate the required encryptions. The OpenSSL implementation had a detectable timing difference. Roughly 2ms difference for long messages (close to 2 14 byte maximum). Enabling recovery of TLS-protected Outlook passwords in about 3 hours. 55

56 Multi-session Version XOR with various Δ here and submit for decryption C t-1, C t vary in each trial, but P t is fixed C t-1 C t d K P t-1 d K P t Recovering true plaintext byte via P t Δ = (. 00) Eventually produces valid pad 00 here 56

57 Padding Oracle Attack Countermeasures? Redesign TLS: Pad-MAC-Encrypt or Pad-Encrypt-MAC. Too invasive, did not happen. Switch to RC4? Or add a fix to ensure uniform errors: 57 Check a MAC anyway, even if the padding is bad. If attacker can t tell difference between MAC and pad errors, then maybe TLS s MEE construction is secure? Fix included in TLS 1.1 and 1.2 specifications.

58 Padding Oracles Post [CHVV03] Regarded as a solved problem for SSL/TLS. Steady trickle of other papers showing padding oracle attacks in other systems, e.g. ISO standard for CBC-mode encryption [PY04, YPM05]. Trailer oracle attack on IPsec [DP07, DP10] POET attack on ASP.NET [DR10]. XML encryption [JS11]. OpenSSL implementation of DTLS [AP12]. 58

59 Lucky 13 Attack

60 Padding Oracle Countermeasures, Revisited Response to timing attacks in [V02, CHVV03] from the TLS 1.1 and 1.2 specifications: implementations MUST ensure that record processing time is essentially the same whether or not the padding is correct. In general, the best way to do this is to compute the MAC even if the padding is incorrect, and only then reject the packet. Compute the MAC on what though? 60

61 TLS Record Protocol: MAC-Encode-Encrypt SQN HDR Payload MAC Payload MAC tag Padding Encrypt HDR Ciphertext Problem is: how to parse plaintext as payload, padding and MAC fields when the padding is not one of the expected patterns 00, 01 01,? 61

62 Ensuring Uniform Errors From the TLS 1.1 and 1.2 specifications: For instance, if the pad appears to be incorrect, the implementation might assume a zero-length pad and then compute the MAC. This approach was adopted in many implementations, including OpenSSL, NSS (Chrome, Firefox), BouncyCastle, OpenJDK, Other approaches possible (e.g. GnuTLS). 62

63 Ensuring Uniform Errors This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size of the timing signal. 63

64 Ensuring Uniform Errors This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size of the timing signal. 64

65 Lucky 13: Distinguishing Attack K C C K C = Enc K (M) M is either R or R 32 FF 256 Adversary intercepts C, mauls, and forwards on to recipient. Time taken to respond with error message will indicate whether M = R or M = R 32 FF 256. Ciphertext-only distinguishing attack. 65

66 Lucky 13 Distinguishing Attack Choose R R R... R 00 IV C R FF FF.FF IV C 66

67 Lucky 13 Distinguishing Attack Maul R R R... R 00 IV C R FF FF.FF IV C 67

68 Lucky 13 Distinguishing Attack Inject R R R... R 00 1-byte valid padding 20-byte MAC 267-byte message IV C R FF FF.FF 256-byte valid padding 20-byte MAC 12-byte message IV C 68

69 Lucky 13 Distinguishing Attack Decrypt R R R.....R IV C R IV C 69

70 Lucky 13 Distinguishing Attack Decrypt SQN HDR R R R.....R Slow MAC verification 280 bytes SQN HDR 25 bytes R Fast MAC verification Timing difference: 4 SHA-1 compression function evaluations 70

71 Lucky 13 Experimental Results for Distinguishing Attack Probability Hardware Cycles Calculated by Attacker OpenSSLv1.0.1 on server running at 1.87Ghz. 100 Mbit LAN. Difference in means is circa 3.2 μs.

72 Lucky 13 Success Probability for Distinguishing Attack Number of Sessions Success Probability

73 Lucky 13 Plaintext Recovery XOR 2-byte Δ here and submit for decryption Target ciphertext block from stream IV R 1 R 2 C t-1 C t d K d K d K d K P t 73 (HMAC-SHA-1 + AES-CBC) Produces valid patterns (or longer valid pad) or 00, OR bad pad.

74 Case 1: (or longer valid pad) XOR 2-byte Δ here and submit for decryption IV R 1 R 2 C t-1 C t d K d K d K d K SQN HDR P t = 55 bytes 20 bytes 4 SHA-1 compression function evaluations (or longer valid pad)

75 Case 2: 00 XOR 2-byte Δ here and submit for decryption IV R 1 R 2 C t-1 C t d K d K d K d K SQN HDR P t 56 bytes 20 bytes SHA-1 compression function evaluations

76 Case 3: Bad padding XOR 2-byte Δ here and submit for decryption IV R 1 R 2 C t-1 C t d K d K d K d K SQN HDR P t bytes 20 bytes 5 SHA-1 compression function evaluations zero-length pad

77 Lucky 13 Plaintext Recovery The injected ciphertext causes bad padding and/or a bad MAC. This leads to a TLS error message, which the attacker times. There is a timing difference between case and the other 2 cases. A single SHA-1 compression function evaluation. Roughly 1000 clock cycles, circa 1μs on typical processor. Measurable difference on same host, LAN, or a few hops away. (Compare with original padding oracle attack: 2ms.) Detecting the case allows last 2 plaintext bytes in the target block C t to be recovered. 77 Using the standard CBC algebra: P t (..Δ 1 Δ 0 ) = (.0101). Attack then extends to all bytes as in a standard padding oracle attack.

78 Lucky 13 Plaintext Recovery We need 2 16 attempts to try all 2-byte Δ values. And we need around 2 7 trials for each Δ value to reliably distinguish the different events. (Actual noise level depends on experimental set-up.) Each trial kills the TLS session. Hence the headline attack cost is 2 23 sessions, all encrypting the same plaintext. Seems rather theoretical? 78

79 Lucky 13 Improvements (Attacks Get Better!) If 1-out-of-2 last plaintext bytes known, then we only need 2 8 attempts per byte. If the plaintext is base64 encoded, then we only need 2 6 attempts per byte. And 2 7 trials per attempt to de-noise, for a total of BEAST-style attack targeting HTTP cookies. Malicious client-side Javascript makes HTTP GET requests. TLS sessions are automatically generated and HTTP cookies attached. GET requests are padded so that 1-out-of-2 condition always holds. Cost of attack is 2 13 GET requests per byte of cookie. 79 Now a practical attack!

80 Lucky 13 Experimental Results Hardware Cycles Calculated by Adversary xFE Byte 14 of plaintext set to 01; byte 15 set to FF. Modify Δ in position 15. OpenSSLv1.0.1 on server running at 1.87Ghz, 100 Mbit LAN. Median times (noise not shown).

81 Lucky 13 Countermeasures We really need constant-time decryption for TLS-CBC. Add dummy hash compression function computations when padding is good to ensure total is the same as when padding is bad. Add dummy padding checks to ensure number of iterations done is independent of padding length and/or correctness of padding. Watch out for length sanity checks too. 81 Need to ensure there s enough space for some plaintext after removing padding and MAC, but without leaking any information about amount of padding removed.

82 Performance of Basic Countermeasures Before After Probability Probability Hardware Cycles Calculated by Attacker Hardware Cycles Calculated by Attacker 82

83 Constant Time Decryption for MEE Better, but still not perfect. Distinguishing attack still possible. Proper constant-time, constant-memory access implementation is really needed. Challenging to test padding correctness and do sanity checking without branching on secret data. See Adam Langley s blogpost at: for full details on how Lucky 13 was fixed in OpenSSL and NSS. 83

84 Lucky 13 Impact OpenSSL patched in versions 1.0.1d, 1.0.0k and 0.9.8y, released 05/02/2013. NSS (Firefox, Chrome) patched in version , released 15/02/2013. Apple: patched in OS X v (ios version tbd). Opera patched in version 12.13, released 30/01/2013 Oracle released a special critical patch update of JavaSE, 19/02/2013. BouncyCastle patched in version 1.48, 10/02/2013 Also GnuTLS, PolarSSL, CyaSSL, MatrixSSL. Microsoft determined that the issue had been adequately addressed in previous modifications to their TLS and DTLS implementation. (Full details at: 84

85 Security proof for MEE in TLS Theorem ([PRS11], informal statement) Suppose E is a block cipher with block size n that is SPRP-secure. Suppose MAC has tag size t and is PRF-secure. Suppose that for all messages M queried by the adversary: M + t n. Then MEE with CBC mode encryption, random IVs, TLS padding, and uniform errors provides AE security. e K e K e K 85 C 0 C 1 C 2 C 3

86 Lucky 13 Lessons TLS s MAC-Encode-Encrypt construction is hard to implement securely and hard to prove positive security results about. Long history of attacks and fixes. Each fix was the easiest option at the time. Now reached point where a 500 line patch to OpenSSL was needed to fully eliminate the Lucky 13 attack. Better to use an EtM construction from day one, or eat the cost of switching at the first sign of trouble. A conservative approach seems merited for such an important protocol. 86 At the time TLS was first designed, EtM versus MtE debate was not so clear cut.

87 Current Status and Future Developments in TLS

88 Current Status CBC-mode Most CBC-mode implementations have been patched against BEAST and Lucky 13, but reputation has been damaged by long series of attacks. Large ecosystem and trickiness of proper patch means that not every implementation is patched to the same degree. Variant attacks are discovered from time-to-time. Lucky 13 strikes again flush and reload attacks [IIES15]. Lucky microseconds on AWS s2n [AP16]. Error in Lucky 13 countermeasure in OpenSSL NI codepath [S16]. Relative performance also an issue (HMAC quite slow compared to modern MAC algorithms). 88

89 Current Status RC4 RC4 is nearly dead for HTTP over TLS Usage has dropped from 50% to 1-2% since But still widely used in other TLS applications, e.g. STARTTLS for SMTP. AES-GCM and AES-CCM are available for TLS 1.2. TLS 1.2 is now supported in all major browsers and in majority of high traffic web servers (wikipedia, ssl pulse). More than 60% of TLS traffic is using TLS 1.2 (ICSI Certificate Notary). 89

90 Current Status AES-GCM AES-GCM is tricky to implement securely purely in software. Main issue is avoiding leakage of hash key via side-channel attack. Also need side-channel resistant implementation of AES. AES-GCM is relatively fast Especially with AES-NI and PCLMULQDQ instructions (Intel and AMD) to 1.03 cycles per byte, depending on processor. Roughly twice as fast as AES-CBC + HMAC-SHA-* But OCB would be even faster! 90

91 Other developments ChaCha20-Poly1305 defined in IETF RFC Important for environments where AES is not available in hardware. ChaCha20 is a stream cipher; Poly1305 a MAC algorithm based on polynomial hashing. Combination is a good AEAD scheme assuming ChaCha20 is ideal [P14]. Small amount of usage currently. Reform of MEE to EtM to make CBC-mode easier to implement securely. RFC Deployment via TLS extension, unclear how widely adopted it will become. 91

92 TLS 1.3 TLS 1.3 is now nearing completion in IETF TLS WG. Reducing latency in Handshake. Simplification of key exchange and authentication methods in Handshake. Server name/identity hiding/handshake encryption for improved privacy (?) Reform of symmetric algorithms AEAD only. 92

93 SSH

94 Introduction to SSH Secure Shell or SSH is a network protocol that allows data to be exchanged using a secure channel between two networked devices. Used primarily on Linux and Unix based systems to access shell accounts, SSH was designed as a replacement for TELNET and other insecure remote shells, which send information, notably passwords, in plaintext, leaving them open for interception. The encryption used by SSH provides confidentiality and integrity of data over an insecure network, such as the Internet. 94 Wikipedia

95 SSH Binary Packet Protocol (RFC 4253) Sequence Number 4 Packet Length 4 Pad Len 1 Payload Padding 4 Encrypt PRF-MAC Ciphertext MAC tag 95 Encode-then-E&M construction, stateful because of inclusion of 4-byte sequence number. Packet length field measures the size of the packet: PadLen + Payload + Padding. Encrypted, so sequence of encrypted packets looks like a long string of random bytes. Encryption options in RFC 4253: CBC mode; RC4. AES-CTR defined in RFC 4344.

96 CBC mode in SSH P i-1 e K C i-1 C i-1 d K P i e K C i C i d K RFC 4253 mandates 3DES- CBC and recommends AES- CBC. SSH uses a chained IV in CBC mode: IV for current packet is the last ciphertext block from the previous packet. Effectively creates a single stream of data from multiple SSH packets. 96 P i-1 P i

97 CTR mode in SSH P i C i ctr+i e K C i ctr+i e K P i CTR mode uses block cipher to build a stream cipher. CTR mode for SSH is standardised in RFC Initial value of counter is obtained from handshake protocol. Counter runs across packets. Packet format is preserved from CBC case. RFC recommends use of AES- CTR with 128, 192 and 256-bit keys, and 3DES-CTR. 97

98 SSH Binary Packet Protocol (RFC 4253) Sequence Number 4 Packet Length 4 Pad Len 1 Payload Padding 4 Encrypt PRF-MAC Ciphertext MAC tag IV chaining attack: Chosen plaintext, distinguishing attack due to Rogaway, applied to SSH in [BKN04]. Not fully realistic for SSH because of format requirements on the first block of plaintext and because of chosen plaintext requirement. Construction with random IVs is IND-sfCCA secure [BKN04]. 98

99 SSH Binary Packet Protocol (RFC 4253) Sequence Number 4 Packet Length 4 Pad Len 1 Payload Padding 4 Encrypt PRF-MAC Ciphertext MAC tag How does decryption work? Recall: receiver gets a stream of bytes, and a single ciphertext can be fragmented over several TCP messages. 99

100 Breaking CBC mode in SSH [APW09] IV C i * Target ciphertext block from stream d K P The receiver will treat the first 32 bits of the calculated plaintext block as the packet length field for the new packet. Here: P 0 = IV d K (C i *) where IV is known. Length field

101 Breaking CBC mode in SSH [APW09] IV C i * R R d K d K d K P 0 P 1 P 2 The attacker then feeds random blocks to the receiver One block at a time, waiting to see what happens at the server when each new block is processed This is possible because SSH runs over TCP and tries to do online processing of incoming blocks 101

102 Breaking CBC mode in SSH [APW09] IV C i * R R MAC tag d K d K d K P 0 P 1 P Once enough data has arrived, the receiver will receive what it thinks is the MAC tag The MAC check will fail with overwhelming probability Consequently the connection is terminated (with an error message) How much data is enough so that the receiver decides to check the MAC? Answer: whatever is specified in the length field:

103 Breaking CBC mode in SSH [APW09] IV C i * C i-1 * C i * d K d K P 0 P i * Knowing IV and 32 bits of P 0, the attacker can now recover 32 bits of the target plaintext block P i* : P i * = C i-1 * d K (C i* ) = C i-1 * IV P 0 103

104 Further details The attack as described requires the injection of circa 2 31 bytes of ciphertext (expected value of length field). It recovers 32 bits of plaintext with probability 1. And leads to an SSH connection teardown (on MAC failure). The attack works with random IVs too, breaking the scheme that was proven secure in [BKN04]. Something went wrong somewhere! 104

105 Further details Length checking RFC 4253 requires implementations to check that length field is reasonable. Details are implementation-specific. Back in 2009, the leading implementation was OpenSSH, then at version 5.1. According to SSH webpage, 80% of servers on the Internet were using OpenSSH around that time. 105

106 Further details Length checking in OpenSSH OpenSSH5.1 performs two length checks on the length field (LF) when decrypting the first ciphertext block: Check 1: 5 LF Check 2: total length (4+LF) is a multiple of the block size: LF +4 mod BL = 0. Each check produces a different error message on the network, distinguishable by attacker. If both checks pass, then OpenSSH waits for more bytes, then performs MAC check, resulting in a third kind of error message. 106

107 Further details Length checking in OpenSSH Check 1 (5 LF 2 18 ) passes with probability approx If it passes, then with high probability, 14 MSBs of LF are 0. Pass/fail detectable via error message. Hence attack with success prob recovering 14 bits of confirmed plaintext. Check 2 (LF +4 mod BL = 0) passes with probability 1/BL, typically 2-3 or 2-4. If it passes, then some (3 or 4) LSBs of LF are revealed. Pass/fail detectable via error message/connection entering wait state. If wait state is entered, then the attack proceeds as before. Overall, the attack on OpenSSH5.1 recovers 32 bits of plaintext with prob (for BL= 16) and requires injection of at most 2 18 bytes of data. 107

108 Does the attack matter? On the one hand, the attack has low success rate, only recovers 32 bits of plaintext, and causes the SSH connection to abort. On the other hand, an attacker can apply the attack to many connections, boosting his overall success rate. Can also iterate the attack against clients that perform auto-reconnects. Think about what kinds of data SSH might be protecting. SSH was meant to be bullet-proof; the attack showed it was not. It left the provable security of the SSH BPP unresolved. 108

109 Countermeasures to the attack Abandon CBC-mode? Alternatives available at that time: CTR, RC4. Dropbear implemented CTR and relegated CBC mode in version Develop new modes? Modes based on Generic EtM, AES-GCM, ChaCha20-Poly1305 were subsequently added to OpenSSH. Patch CBC-mode? OpenSSH5.2 also introduced a patch to stop the specific attack on CBC mode. 109

110 The OpenSSH patch Basic idea: hide the errors from the adversary. If the length checks fail, do not send an error message, but wait until 2 18 bytes have arrived, then check the MAC. If the length checks pass, but the MAC check eventually fails, then wait until 2 18 bytes have arrived, then check the MAC. No error message is ever sent until 2 18 bytes of ciphertext have arrived. Can no longer count bytes to see how many are required to trigger MAC failure. 110

111 Theory lesson from the SSH attack Model used for security proof in [BKN04] was inadequate. It assumed length was known and atomic processing of ciphertexts. But fragmented adversarial delivery of ciphertext over TCP is possible. Implementations have to decrypt first block to find out how long plaintext is meant to be, and act on it before performing any authentication. That s not reflected in any of the AE/AEAD security models! 111

112 More SSH security analysis [PW10]: bespoke security model for CTR mode in SSH and proved it secure (assuming block cipher is a PRP). [BDPS12]: general framework for studying Symmetric Encryption schemes supporting fragmented decryption like those used in SSH. IND-sfCFA allows the attacker to deliver ciphertext to a decryption oracle in a symbol-by-symbol fashion and observe any errors/message outputs. [BDPS12] also identified additional security properties that SSH attempts to provide: Boundary Hiding (BH) and Denial-of-Service resistance. 112

113 The State of AEAD in SSH Today

114 The state of AEAD in SSH today In [ADHP16], we performed a measurement study of SSH deployment. We conducted two IPv4 address space scans in Nov/Dec 2015 and Jan 2016 using ZGrab/ZMap. Grabbing banners and SSH servers preferred ciphers. Actual cipher used in a given SSH connection depends on client and server preferences. Roughly 2 24 servers found in each scan. Nmap fingerprinting suggests mostly embedded routers, firewalls. 114

115 The state of AEAD in SSH today: SSH versions 115 Mostly OpenSSH and dropbear; others less than 5%.

116 The state of AEAD in SSH today: SSH versions 116 Dropbear at 56-58%. 886k older than version 0.53, so vulnerable to variant of 2009 CBCmode attack!

117 The state of AEAD in SSH today: SSH versions 117 OpenSSH at 37-39% k older than version 5.2 and prefer CBC mode, so vulnerable to 2009 attack!

118 The state of AEAD in SSH today: SSH versions Dropbear now dominates OpenSSH. But may be switching back again: Comcast cable IP address range dropped from 2M+ devices running Dropbear (Feb 2016) to 83k (May 2016). Long tail of old software versions. Most popular version of OpenSSH is version 5.3, released Oct 2009 (current version is 7.2). Determined by major Linux distros? Significant percentage of Dropbear and OpenSSH servers are potentially still vulnerable to the 2009 attack. 8.4% for Dropbear. 118

119 The state of AEAD in SSH today: preferred algorithms OpenSSH preferred algorithms 119 Lots of diversity, surprising amount of generic EtM (getm). CTR dominates, followed by CBC. ChaCha20-Poly1305 on the rise? (became default in OpenSSH 6.9). Small amount of GCM.

120 The state of AEAD in SSH today: preferred algorithms Dropbear preferred algorithms 120 Less diversity than OpenSSH. CTR dominates, followed at a long distance by CBC. No exotic options.

121 A New Attack on CBC mode in OpenSSH

122 The OpenSSH patch Version CBC mode preferred by roughly 20k OpenSSH servers. Recall the OpenSSH patch, in version 5.2 and up: If the length checks fail, do not send an error message, but wait until 2 18 bytes have arrived, then check the MAC. If the length checks pass, but the MAC check eventually fails, then wait until 2 18 bytes have arrived, then check the MAC. One MAC check is done if length checks fail: on 2 18 bytes. Two MAC checks are done if length checks pass: one on roughly LF bytes, the other on 2 18 bytes. 122

123 Attacking the OpenSSH patch [ADHP16] This leads to a timing attack on CBC mode in OpenSSH5.2 and up: 1. Inject target ciphertext block C i*. 2. Then send 2 18 bytes as quickly as possible to server. 3. Time the arrival of the MAC failure message. Fast arrival indicates that length checks failed and one MAC computation. Slow arrival indicates that the length checks passed and two MAC computations. This leaks 18 bits of information about the length field, and hence 18 bits about the target block. 123

124 Attacking the OpenSSH patch [ADHP16] Size of timing difference: A MAC computation on roughly 2 17 bytes (the expected value of LF). For HMAC-SHA1, this requires 2 11 hash compression function evaluations. cf. Lucky 13 timing difference: a single hash compression function! Remote attacker can easily detect difference. Success probability of the attack: Need to pass both length checks, so Can increase success rate given partial plaintext knowledge in target block. (Idea: wait for the right IV before mounting the attack; more severe attack for random, explicit IV version.) 124

125 Attacking the OpenSSH patch [ADHP16] Increase number of plaintext bits recovered by using finer-grained timing information. Because the timing delay is proportional to the value of LF. If timing granularity = 1 compression function evaluation, then we can recover up to 30 bits of plaintext from target block. Challenging, but not impossible in co-resident attacker scenario. Possible countermeasure to the attack: if MAC fails, then compute second MAC on 2 18 LF bytes instead of on all 2 18 bytes. Still leaves residual timing difference because of fine details of HMAC. Really need constant time implementation of decryption algorithm to eliminate this class of attack. 125

126 Disclosure of the attack We notified the OpenSSH team of the attack (5/5/16). we do not feel that an emergency release is necessary, nor that the attack remain secret ahead of such a release. They added countermeasures in OpenSSH 7.3 (1/8/16). OpenSSH has steadily been deprecating old algorithms and modes. CBC mode was already disabled by default in OpenSSH 6.7 (but can be re-enabled). But OpenSSH cannot force people to stop using old versions of the software. 126

127 Security analysis of other SSH and OpenSSH modes CTR, getm, AES-GCM, ChaCha20Poly1305

128 Security analysis of other OpenSSH encryption modes In [ADHP16], we also use the framework of [BDPS12] to prove security properties of getm, AES-GCM, and ChaCha20-Poly1305 in OpenSSH. The framework allows fragmented decryption capability, multiple decryption errors, etc. We found a subtle error in the security models in [BDPS12]. We also extended the models to include integrity as well as confidentiality. 128

129 Security analysis of other OpenSSH encryption modes getm and AES-GCM in OpenSSH: Derived from AEAD schemes with AD = length field (now unencrypted). Hence sanity checking of length field cannot reveal anything useful to adversary. Issue in getm code: MAC is computed once the ciphertext has arrived but is not compared to received MAC until after decryption. Hence any errors arising during decryption step will be signalled to attacker. Arises from shared code-path and reuse of legacy E&M code. Not a security threat for any currently specified encryption schemes. Fixed in OpenSSH 7.3. Both (fixed) getm and AES-GCM are provably secure: achieving IND-sfCFA, INTsfCFA security. 129

130 ChaCha20-Poly1305 in OpenSSH SQN 4 Packet Length 4 Pad Len 1 Payload Padding 4 K 1 IV = SQN 0 64 ChaCha20 IV = SQN ChaCha20 K C 1 C 2 K 2 IV = SQN ChaCha20 K poly Poly1305 MAC tag 130

131 Security analysis of ChaCha20-Poly1305 in OpenSSH ChaCha20-Poly1305 in OpenSSH: 64-byte key is split into two halves, K 1, K 2. K 1 used to encrypt SSH length field using ChaCha20. K 2 used to encrypt everything else, also using ChaCha20. Poly1305 MAC key is obtained as: 131 ChaCha20(K 2,IV = SQN , M=0 256 ). MAC applied to both ciphertext components. Analysis more complex because of encrypted length field. Idea is that using separate keys for encrypting length field and the rest stops attacks. CTR mode analysis shows this to be unnecessary.

132 Closing remarks

133 Closing remarks Once a bad cryptographic choice is out there in implementations, it s very hard to undo. 133 Old versions of TLS hang around for a long time. There is no TLS product recall programme! Slow uptake of TLS 1.1, 1.2. TLS has come under sustained pressure from attacks. BEAST, Lucky 13 and RC4 attacks have provided incentives to move to TLS 1.2 and influenced the design of TLS 1.3. Attacks are semi-practical but we ignore such attacks at our peril. Good vendor response to Lucky 13 via patching, slower response to RC4 attacks via switching off support.

134 Closing remarks Good algorithm design is hard. But so is good protocol design. Attacks are usually obvious in retrospect, but finding them is not so easy. Keep in mind the value of attacks on paper versus attacks in practice. Implemented attacks are needed to convince practitioners. But an on-paper attack is often the harbinger of a practical attack. 134

135 Closing remarks We ve seen the evolution from simple security models for symmetric encryption to more sophisticated security notions for secure channels. The cryptography community is focussed on AEAD as an end goal. AEAD is an important tool but not the same thing as a secure channel. 135