Authenticated Encryption in the Face of Protocol and Side-Channel Leakage

Transcription

1 Authenticated Encryption in the Face of Protocol and Side-Channel Leakage Guy Barwell, Daniel P. Martin, Elisabeth Oswald, Martijn Stam University of Bristol Crete, 13 October 2017

2 What s it about? Keywords Authenticated Encryption: A key component of secure communication Provable Security: Bootstrapping security of a complex construction from a simple primitive, say a blockcipher or pseudorandom function. Protocol Leakage: Implementations of the construction that for whatever reason aren t perfect. This is not the same as blame the implementer! Side-Channel Leakage: Implementations of the primitive that are exposed to the real-world of DPA, cache-timing attacks, etc.

3 What s it about? Provable Security for the Real World The Good Secure Primitives + Provable Security = Secure Construction

4 What s it about? Provable Security for the Real World The Good Secure Primitives + Provable Security = Secure Construction The Security of Ciphertext Stealing Phillip Rogaway 1, Mark Wooding 2, and Haibin Zhang 1 1 Dept. of Computer Science, University of California, Davis, USA 2 Thales e-security Ltd, UK Abstract. We prove the security of CBC encryption with ciphertext stealing. Our results cover all versions of ciphertext stealing recently recommended by NIST. The complexity assumption is that the underlying blockcipher is a good PRP, and the security notion achieved is the strongest one commonly considered for chosen-plaintext attacks, indistinguishability from random bits (ind$-security). We go on to generalize these results to show that, when intermediate outputs are slightly delayed, one achieves ind$-security in the sense of an online encryption scheme, a notion we formalize that focuses on what is delivered across an online API, generalizing prior notions of blockwise-adaptive attacks. Finally, we pair our positive results with the observation that the version of ciphertext stealing described in Meyer and Matyas s well-known book (1982) is not secure. Keywords: blockwise-adaptive attacks, CBC, ciphertext stealing, cryptographic standards, modes of operation, provable security. 1 Introduction Ciphertext stealing. Many blockcipher modes require the input be a sequence of complete blocks, each having a number of bits that is the blockcipher s blocksize. One approach for dealing with inputs not of this form is ciphertext stealing. The classical combination is CBC encryption and ciphertext stealing, a mode going back to at least 1982 [14]. In 2010, NIST put out an addendum [8] to Special Publication A [7], the document that had defined blockcipher modes ECB, CBC, CFB, OFB, and CTR. The addendum defines three ways to enrich CBC with ciphertext stealing. The modes are named CBC-CS1, CBC-CS2, and CBC-CS3. See Fig. 1 for the definition of these modes, which differ only in the ordering of ciphertext bits. Despite the classicism of ciphertext-stealing, its adoption in standards, and the strong preferences, these days, for proven-secure modes, there has, until now, been no proof offered for CBC with ciphertext stealing. This paper fills in this. e begin by looking at the NIST ciphertext-stealing S. Assuming a random IV, we show ional form of chosenfrom Breaking and Repairing GCM Security Proofs Tetsu Iwata 1, Keisuke Ohashi 1, and Kazuhiko Minematsu 2 1 Nagoya University, Japan iwata@cse.nagoya-u.ac.jp, k oohasi@echo.nuee.nagoya-u.ac.jp 2 NEC Corporation, Japan k-minematsu@ah.jp.nec.com Abstract. In this paper, we study the security proofs of GCM (Galois/Counter Mode of Operation). We first point out that a lemma, which is related to the upper bound on the probability of a counter collision, is invalid. Both the original privacy and authenticity proofs by the designers are based on the lemma. We further show that the observation can be translated into a distinguishing attack that invalidates the main part of the privacy proof. It turns out that the original security proofs of GCM contain a flaw, and hence the claimed security bounds are not justified. A very natural question is then whether the proofs can be repaired. We give an affirmative answer to the question by presenting new security bounds, both for privacy and authenticity. As a result, although the security bounds are larger than what were previously claimed, GCM maintains its provable security. We also show that, when the nonce length is restricted to 96 bits, GCM has better security bounds than a general case of variable length nonces. The Order of Encryption and Authentication for Protecting Communications (or: How Secure Is SSL?) Keywords: GCM, counter-example, distinguishing attack, proof of security. 1 Introduction Hugo Krawczyk GCM (Galois/Counter Mode of Operation) is the authenticated encryption mode of blockciphers designed by McGrew and Viega [26,27]. The mode is based on the counter mode encryption and the polynomial hash function, and the designers presented proofs of security both for privacy and authenticity [26,27]. It was selected as the NIST recommended blockcipher mode in 2007 [15], and is widely used in practice, e.g., in [1,2,4,5,6,7,8,14,17,19,20,25,33,34]. The security of GCM has been extensively evaluated. Ferguson pointed out that a forgery is possible if the tag length is short [16]. Joux showed that a part of the secret key can be obtained if the nonce is reused [21]. Handschuh and Preneel discussed weak keys of GCM and presented generalizations of Joux s attack [18]. Saarinen pointed out that GCM has more weak keys than previously known, and used the weak keys for forgery attacks [32]. See also [31] for comprehensive discussions on various aspects on GCM. Despite aforementioned attacks, it is widely considered that the provable security results of GCM are sound, in the sense that the previous attacks do not contradict the claimed security bounds by the designers, and that no flaw in the proofs has been identified. Some of these attacks show the tightness of the security bounds, and others are outside the security model (e.g., nonce reuse). Therefore, there is no attack that undermines the security bounds or th GCM uses the counter mode encryption, and the initial nonce, where there are two different ways to the length of the nonce. When padded with a EE Department, Technion, Haifa, Israel. hugo@ee.technion.ac.il Abstract. We study the question of how to generically compose symmetric encryption and authentication when building secure channels for the protection of communications over insecure networks. We show that any secure channels protocol designed to work with any combination of secure encryption (against chosen plaintext attacks) and secure MAC must use the encrypt-then-authenticate method. We demonstrate this by showing that the other common methods of composing encryption and authentication, including the authenticate-then-encrypt method used in SSL, are not generically secure. We show an example of an encryption function that provides (Shannon s) perfect secrecy but when combined with any MAC function under the authenticate-then-encrypt method yields a totally insecure protocol (for example, finding passwords or credit card numbers transmitted under the protection of such protocol becomes an easy task for an active attacker). The same applies to the encrypt-and-authenticate method used in SSH. On the positive side we show that the authenticate-then-encrypt method cure if the encryption method in use is either CBC mode (with an a stream cipher (that xor the data neric The low-call diet: Authenticated Encryption for call c HSM users M. Bond 1, G. French 2, N.P. Smart 3, and G.J. Watson 3 1 Cryptomathic A/S, Cambridge, UK. 2 Barclays Bank Plc, London, UK. 3 University of Bristol, UK.. Abstract. We present a new mode of operation for obtaining authenticated encryption su in environments, e.g. banking and government, where cryptographic services are only ava Hardware Security Module (HSM) which protects the keys but offers a limited API. Th problem is that despite the existence of better modes of operation, modern HSMs still prov but a basic (unauthenticated) CBC mode of encryption, and since they mediate all access solutions must work around this. Our mode of operation makes only a single call to the provides a secure authenticated encryption scheme; authentication is obtained by manipula plaintext being passed to the HSM via a call to an unkeyed hash function. The scheme o siderable performance improvement compared to more traditional authenticated encryption which must be implemented using multiple calls to the HSM. Our new mode of operation with a proof of security, on the assumption that the underlying block cipher used in the CB a strong pseudorandom permutation, and that the hash function is modelled as a random 1 Introduction Authenticated symmetric encryption, namely an encryption scheme which is both INT-CTXT secure [3], is regarded as the goal for symmetric encryption. There is constructions in the literature for such authenticated encryption (AE) schemes. The these is the Encrypt-Then-MAC construction, which first encrypts the message usin encryption scheme and then appends a secure MAC to the ciphertext. Over the last special modes of operation have been defined which implement authenticated enc OCB [17], CCM [19], EAX [5] and GCM [12]. However, while these modes have for modern use and parallel services, there are some situations in which generic con Encrypt-Then-MAC) or special modes cannot be used. In the financial and government sectors, a common industrial deployment of c for keys to reside within a special piece of hardware known as a Hardware Secu HSM. Such HSMs store the keys and manipulate sensitive data on behalf of applica a measure of assurance that neither a lone corrupt insider manipulating his own external hacker will be able to steal or abuse cryptographic keys. Another benefit of is that they define the point at which any abuse of the key material may occur; so

5 What s it about? Provable Security for the Real World The Bad Secure Primitives + Provable Security + The Real World Secure Construction

6 What s it about? Provable Security for the Real World The Bad Secure Primitives + Provable Security + The Real World Secure Construction Lucky Thirteen: Breaking the TLS and DTLS Record Protocols Nadhem J. AlFardan and Kenneth G. Paterson Information Security Group Royal Holloway, University of London, Egham, Surrey TW20 0EX, UK {nadhem.alfardan.2009, kenny.paterson}@rhul.ac.uk 27th February 2013 Abstract The Transport Layer Security (TLS) protocol aims to provide confidentiality and integrity of data in transit across untrusted networks. TLS has become the de facto secure protocol of choice for Internet and mobile applications. DTLS is a variant of TLS that is growing in importance. In this paper, we present distinguishing and plaintext recovery attacks against TLS and DTLS. The attacks are based on a delicate timing analysis of decryption processing in the two protocols. We include experimental results demonstrating the feasibility of the attacks in realistic network environments for several different implementations of TLS and DTLS, including the leading OpenSSL implementations. We provide countermeasures for the attacks. Finally, we discuss the wider implications of our attacks for the cryptographic design used by TLS and DTLS. Keywords TLS, DTLS, CBC-mode encryption, timing attack, plaintext recovery 1 Introduction TLS is arguably the most widely-used secure communications protocol on the Internet today. Starting life as SSL, the protocol was adopted by the IETF and specified as TLS 1.0 [10]. It has since evolved through TLS 1.1 [11] to the current version TLS 1.2 [12]. Various other RFCs define additional TLS cryptographic algorithms and extensions. TLS is now used for securing a wide variety of application-level traffic and has beious rival to IPsec for general VPN usage. It is widely er software and in cryptographic lies, and web applid 1.0 [31], which roughly matches TLS 1.1 and DTLS 1.2 [32], which aligns with TLS 1.2. Both TLS and DTLS are actually protocol suites, rather than single protocols. The main component of (D)TLS that concerns us here is the Record Protocol, which uses symmetric key cryptography (block ciphers, stream ciphers and MAC algorithms) in combination with sequence numbers to build a secure channel for transporting application-layer data. Other major components are the (D)TLS Handshake Protocol, which is responsible for authentication, session key establishment and ciphersuite negotiation, and the TLS Alert Protocol, which carries error messages and management traffic. Setting aside dedicated authenticated encryption algorithms (which are yet to see widespread support in TLS or DTLS implementations), the (D)TLS Record Protocol uses a MAC-Encode-Encrypt (MEE) construction. Here, the plaintext data to be transported is first passed through a MAC algorithm (along with certain header bytes) to create a MAC tag. The supported MAC algorithms are all HMAC-based, with MD5, SHA-1 and SHA-256 being the allowed hash algorithms in TLS 1.2 [12]. Then an encoding step takes place. For the RC4 stream cipher, this just involves concatenation of the plaintext and the MAC tag, while for CBC-mode encryption (the other possible option), the plaintext, MAC tag, and some encryption padding of a specified format are concatenated. In the encryption step, the encoded plaintext is encrypted with the selected cipher. In the case where CBC-mode is selected, the block cipher is DES, 3DES or AES (with DES being deprecated in TLS 1.2). Following [28], we refer to this MEE construction as MEE-TLS-CBC. We provide greater detail on its operation in the (D)TLS Record Protocol in Section 2. The widespread use of TLS (and the increasing use of DTLS) makes the continued study of the security of these protocols of great importance. Indeed, the evolution of the TLS l has largely been driven by cryptographic atagainst it, including those in The fragility of AES-GCM authentication algorithm Shay Gueron 1,2, Vlad Krasnov 2 1 Department of Mathematics, University of Haifa, Israel 2 Intel Corporation, Israel Development Center, Haifa, Israel March 15, 2013 Abstract. A new implementation of the GHASH function has been recently committed to a Git version of OpenSSL, to speed up AES-GCM. We identified a bug in that implementation, and made sure it was quickly fixed before trickling into an official OpenSSL trunk. Here, we use this (already fixed) bug as a real example that demonstrates the fragility of AES-GCM s authentication algorithm (GHASH). One might expect that incorrect MAC tag generation would only cause legitimate message-tag pairs to fail authentication (which is already a serious problem). However, since GHASH is a polynomial evaluation MAC, the bug can be exploited for actual message forgery. Keywords: AES-GCM, GHASH, polynomial evaluation MAC, message forgery, OpenSSL. 1 Introduction AES-GCM (Galois Counter Mode; [1]) is considered to be a most efficient NIST standard Authenticated Encryption scheme. Its software implementation on modern processors is an important optimization target, and various improvements have been introduced in the last few years (e.g., [2], [4]). Recently (February 2013 [8]), a new implementation of the function 'gcm_ghash_clmul' was been committed (by OpenSSL Development Team member A. Polyakov) to the Git version of OpenSSL [7], and was awaiting interception in the next revision (1.0.2) of this library. Since [8] was committed and also passed all of the built-in OpenSSL tests, it is fair to assume if it had not been intercepted, it would have appeared in the next OpenSSL version (1.0.2). We uncovered a bug in [8], and to stop it from appearing in an official OpenSSL version, we notified OpenSSL (March 5, 2013); the bug was fixed immediately (March 6; [9]). Therefore, the current situation allows us to analyze a real vulnerability (not just theoretical), but without pointing to a real exposure. We emphasize the following: although the message forgery vulnerability that we rep here can be reproduced from the references and examples we p security threat is already removed (even from the d As we show here, the crypto algorithm can exte ) #!% , Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS... Serge Vaudenay Swiss Federal Institute of Technology (EPFL) Serge.Vaudenay@epfl.ch Abstract. In many standards, e.g. SSL/TLS, IPSEC, WTLS, messages are first pre-formatted, then encrypted in CBC mode with a block cipher. Decryption needs to check if the format is valid. Validity of the format is easily leaked from communication protocols in a chosen ciphertext attack since the receiver usually sends an acknowledgment or an error message. This is a side channel. In this paper we show various ways to perform an efficient side channel attack. We discuss potential applications, extensions to other padding schemes and various ways to fix the problem. 1 Introduction Variable input length encryption is traditionally constructed from a fixed input length encryption (namely a block cipher) in a special mode of operation. In RFC2040 [2], the RC5-CBC-PAD algorithm is proposed, based on RC5 which enables the encryption of blocks of b = 8 words where words are bytes. Encryption of any word sequence with an RC5 secret key K is performed as follows. 1. Pad the word sequence with n words, all being equal to n, such that 1 n b and the padded sequence has a length which is a multiple of b. 2. Write the padded word sequence as a block sequence x1,..., xn in which each block xi consists of b words. 3. Encrypt the block sequence in CBC mode with a (either fixed or random or secret) IV with a permutation C defined by RC5 with key K: get y1 = C(IV x1), yi = C(yi 1 xi); i = 2,..., N (1) where denotes the XOR operation. The encryption of the message is the block sequence y1,..., yn. Although decryption is not clearly defined in RFC2040 [2], it makes sense to assume that the receiver of an encrypted message first decrypts in CBC mode, then checks if the padding is correct and finally removes it. The question is: how must the receiver behave if the padding is not correct? Although the receiver should not tell the sender that the padding is not correct, it is meaningful that non-procession of a decrypted message ultimately leaks this bit of information.

7 What s it about? Provable Security for the Real World The Ugly Secure Primitives + Provable Security = Secure Construction + The Real World

8 What s it about? Provable Security for the Real World The Ugly Secure Primitives + Provable Security = Secure Construction + The Real World

9 What s it about? Provable Security for the Real World The Ugly Secure Primitives + Provable Security = Secure Construction + The Real World We need better models!

10 Authenticated Encryption Alice c = E N,A k (m) The Network Bob Two parties share a key and want to communicate securely Their messages should be confidential and authentic An adversary wants to stop them doing this

11 Authenticated Encryption Alice c = E N,A k (m) The Network Bob Two parties share a key and want to communicate securely Their messages should be confidential and authentic An adversary wants to stop them doing this

12 Authenticated Encryption Alice c =??? The Network Bob Two parties share a key and want to communicate securely Their messages should be confidential and authentic An adversary wants to stop them doing this

13 Modern AE A Brief History Standard BN00 First recognisable notion, probabilistic Rog02 Addition of Associated Data Rog04 Move to nonce-based RS06 Deterministic encryption, All-in-one definition Decryption Leakage BDPS13 Special leakage case of multiple decryption errors ABL14+ Special leakage case Release of Unverified Plaintext HKR15 Special leakage case based on Encode-then-Encrypt BPS15 Any deterministic leakage on invalid ciphertexts

14 Modern AE A Brief History Standard BN00 First recognisable notion, probabilistic Rog02 Addition of Associated Data Rog04 Move to nonce-based RS06 Deterministic encryption, All-in-one definition Decryption Leakage BDPS13 Special leakage case of multiple decryption errors ABL14+ Special leakage case Release of Unverified Plaintext HKR15 Special leakage case based on Encode-then-Encrypt BPS15 Any deterministic leakage on invalid ciphertexts

15 Outline 1 Modern Authenticated Encryption Syntax Security Composition 2 Leakage Scenarios Protocol Leakage Primitive Leakage AE under Leakage

16 Modern Authenticated Encryption Syntax Authenticated Encryption (AE) Syntax An Authenticated Encryption scheme is a pair of algorithms E : K N A M C D : K N A C M { } Where: K Key space N Nonce space A Associated Data M Message Space C Ciphertext Space Invalid ciphertext symbol

17 Modern Authenticated Encryption Syntax Authenticated Encryption (AE) Syntax An Authenticated Encryption scheme is a pair of algorithms E : K N A M C D : K N A C M { } Nice-Behaviour Assumptions Correctness D N,A k Tidyness E N,A k (D N,A k (E N,A k (m)) = m (c)) = c whenever D N,A k (c) Length-Regular E N,A k (m) = m + τ( m )

18 Modern Authenticated Encryption Security Authenticated Encryption (AE) All-in-One Security Notion [RS06] E k A A $ D k How well can an adversary distinguish?

19 Modern Authenticated Encryption Security Authenticated Encryption (AE) All-in-One Security Notion [RS06] Exp ae-0 E (A) Exp ae-1 E (A) E k A A $ D k Real AE world Ideal AE world Adv ae E (A) = [ Pr Exp ae-0 E (A) = 0 ] Pr [ Exp ae-1 E (A) = 0 ]

20 Modern Authenticated Encryption Security Authenticated Encryption (AE) All-in-One Security Notion [RS06] E k A A $ D k This single notion is equivalent to IND CPA + ciphertext integrity

21 Modern Authenticated Encryption Security Authenticated Encryption (AE) All-in-One Security Notion [RS06] E k A A $ The IND CPA game

22 Modern Authenticated Encryption Security Authenticated Encryption (AE) All-in-One Security Notion [RS06] E k E k A A D k The ciphertext integrity game

23 Modern Authenticated Encryption Security Authenticated Encryption (AE) Security Flavours E k E k A D k E k really E N,A k (m) Any restrictions on N, A, m?

24 Modern Authenticated Encryption Security Authenticated Encryption (AE) Security Flavours E k How can A pick N? E k D k A E k really E N,A k (m) Any restrictions on N, A, m? iv random (initial vector) n unique (nonce, number used once) mr no restrictions (misuse-resistant)

25 Modern Authenticated Encryption Security Authenticated Encryption (AE) Security Flavours E k How can A pick N? E k D k A E k really E N,A k (m) Any restrictions on N, A, m? iv random (initial vector) n unique (nonce, number used once) mr no restrictions (misuse-resistant) No restrictions on A, m

26 Modern Authenticated Encryption Security Authenticated Encryption (AE) Aspects to Ignore secret nonces LoR, RoR, Inj multi-user and corruptions variable length tags and stretch streaming and online issues

27 Modern Authenticated Encryption Composition Generic Composition Goals of Composition Domain extension From fixed input length (FIL) to variable input length (VIL) hash-then-mac, CTR, CBC, CFB, etc. Boost security From iv via n to mr randomize-then-encrypt Compose security confidentiality + integrity authenticated encryption Encrypt-then-Mac, Mac-then-Encrypt, Encrypt-and-Mac

28 Modern Authenticated Encryption Composition Domain Extension Cipher FeedBack Mode (CFB) I M 1 M 2 M 3 M 4 F k F k F k F k C 1 C 2 C 3 C 4

29 Modern Authenticated Encryption Composition Boosting Security From IV-based to Nonce-based N M F kf I ive ke Randomized IV Using an independently keyed PRF to turn the nonce into a random iv. C

30 Modern Authenticated Encryption Composition Generic Composition Nonce-based Encrypt-then-Mac [NRS14] N M A N M E ke F kf I ive ke T km + C T C The scheme N2 IV-to-N Conversion

31 Modern Authenticated Encryption Composition Generic Composition Nonce-based Encrypt-then-Mac [NRS14] N M A N M E ke F kf I ive ke T km + C T C The scheme N2 IV-to-N Conversion

32 Modern Authenticated Encryption Composition Generic Composition Nonce-based Encrypt-then-Mac [NRS14] N M A F kf I ive ke T km C T The scheme A5

33 Modern Authenticated Encryption Composition Generic Composition Nonce-based Encrypt-then-Mac [NRS14] N M A F kf I ive ke T km C T The Encrypt-and-MAC scheme A1

34 Leakage Scenarios Protocol Leakage Multiple Decryption Errors Implementation Details Matter... [BDPS13] N M A F kf I ive ke T km C T The Encrypt-and-MAC scheme A1 Adding Padding Imagine that M is a bitstring ive only accepts blockstrings Natural to include encoding: {0, 1} ({0, 1} n )

35 Leakage Scenarios Protocol Leakage Multiple Decryption Errors Implementation Details Matter... [BDPS13] N M A F kf I ive ke T km C T The Encrypt-and-MAC scheme A1 Decryption errors Now two errors could occur: The MAC verification fails The encoding was invalid These errors might be distinguishable!

36 Leakage Scenarios Protocol Leakage Release of Unverified Plaintext (RUP) Implementation Details Matter Too [ABLMMY14] N M A F kf I ive ke T km C T The Encrypt-and-MAC scheme A1

37 Leakage Scenarios Protocol Leakage Release of Unverified Plaintext (RUP) Implementation Details Matter Too [ABLMMY14] N M A F kf I ive ke T km C T The Encrypt-and-MAC scheme A1 Decryption buffers In order to verify M is needed What if it leaks before? Release of Unverified Plaintexts

38 Leakage Scenarios Protocol Leakage Subtle Authenticated Encryption Joint work with Guy Barwell and Dan Page Λ k Λ k E k A A $ D k Deterministic Leakage for Decryption Failures Leakage oracle Λ k returns if D k doesn t Relationships between notions reconsidered

39 Leakage Scenarios Protocol Leakage Comparison of Robust AE notions Joint work with Guy Barwell and Dan Page RAE[τ] [HKR15] SAE RUPAE [ABLMMY14] CTI scpa + ERR-CPA + IND-CPA INT RUP + DI + IND-CPA [BDPS13] IND$ CCA3

40 Leakage Scenarios Protocol Leakage Protocol Leakage Beyond Subtle Authenticated Encryption N M A F kf I ive ke T km C T E k /$ D k / Λ k A What about Other Wires? For instance I could leak during encryption (relevant for SS-MPC) Or even the correct tag during decryption!?

41 Leakage Scenarios Primitive Leakage Blockciphers and PRFs Leaking S-boxes Low-level primitive Blockciphers (or FIL-PRFs) are the smallest building block for AE They might still leak about internal variables... such as noisy Hamming weight of first-round S-box

42 Leakage Scenarios Primitive Leakage Blockciphers and PRFs Leaking S-boxes Low-level primitive Blockciphers (or FIL-PRFs) are the smallest building block for AE They might still leak about internal variables... such as noisy Hamming weight of first-round S-box Challenge Many countermeasures (masking) to thwart key recovery But how does primitive leakage affect larger construction s security? How to model and argue about such leakage?

43 Leakage Scenarios Primitive Leakage Only Computation Leaks Information Micali Reyzin s Framework For each computation Assume the adversary can specify a leakage function To model leakage on the current computation s input Granularity of the modelling of the computation affects what can leak! Different models emerge by considering different classes of leakage functions.

44 Leakage Scenarios Primitive Leakage Leakage Resilience A Fully-Specified Framework based on OCLI [DP08] Continuous and Arbitrary Leakage Leakage functions are only restricted in their output length to prevent leaking the full input. Repeated invocation results in leakage cumulating.

45 Leakage Scenarios Primitive Leakage Leakage Resilience A Fully-Specified Framework based on OCLI [DP08] Continuous and Arbitrary Leakage Leakage functions are only restricted in their output length to prevent leaking the full input. Repeated invocation results in leakage cumulating. Caveats The model allows future leakage The model allows inefficient leakage functions Split-state model (like masking) inevitable

46 Leakage Scenarios AE under Leakage Authenticated Encryption, Revisited Deconstructing the Rogaway Shrimpton Definition Goals What does the adversary want to do? Learn something about the content of a message Send a message that was not intended Powers What can they do to help them achieve this? Some sort of oracle access they ve discovered/created eg request encryptions or decryptions

47 Leakage Scenarios AE under Leakage Authenticated Encryption, Revisited Deconstructing the Rogaway Shrimpton Definition Goals What does the adversary want to do? Distinguish encryptions from random Distinguish real decryption from one that always rejects Powers What can they do to help them achieve this? Make queries to an honest encryption oracle Make queries to an honest decryption oracle Implicitly usurped by goal oracles How does leakage fit in?

48 Leakage Scenarios AE under Leakage Authenticated Encryption, Revisited Powers and Goals E k D k E k D k E k A A $ D k Looking at powers and goals simultaneously

49 Leakage Scenarios AE under Leakage Authenticated Encryption, Revisited Powers and Goals E k D k E k D k E k A A $ D k The oracles corresponding to powers

50 Leakage Scenarios AE under Leakage Authenticated Encryption, Revisited Powers and Goals E k D k E k D k E k A A $ D k The oracles corresponding to goals

51 Leakage Scenarios AE under Leakage Authenticated Encryption, Revisited Different Adversarial Powers Goals Ek Dk Ek Dk Ek Dk Ek Dk PAS CPA CDA CCA Ek/$ IND Dk/ Ek/$ AE Dk/ Ek/$ CTI Dk/

52 Leakage Scenarios AE under Leakage Authenticated Encryption with Leakage Modelling Choices E k D k Modelling Leakage E k /$ D k / A Only true E k and D k leak Adversary picks leakage function Security is relative to a class of leakage functions.

53 Leakage Scenarios AE under Leakage Authenticated Encryption with Leakage Modelling Choices E k D k Modelling Leakage E k /$ D k / A Only true E k and D k leak Adversary picks leakage function Security is relative to a class of leakage functions. Leaking on challenge oracles can sometimes be reasonable (SS-MPC), but not in a leakage-resilience setting.

54 Leakage Scenarios AE under Leakage Generic Composition Revisited, Revisited How Well do the [NRS14] Schemes hold up? Decimating the NRS Schemes N M A F kf I ive ke C T km T NRS identified eight favoured schemes A1 A4 are Encrypt-and-Mac A5 and A6 are Encrypt-then-Mac A7 and A8 are Mac-then-Encrypt Only A5 and A6 cope well with leakage. For composition, need to relate leakage classes!

55 Leakage Scenarios AE under Leakage Generic Composition Revisited, Revisited How Well do the [NRS14] Schemes hold up? Decimating the NRS Schemes N M A F kf I ive ke C T km T NRS identified eight favoured schemes A1 A4 are Encrypt-and-Mac A5 and A6 are Encrypt-then-Mac A7 and A8 are Mac-then-Encrypt Only A5 and A6 cope well with leakage. Only A4 was mrae

56 Leakage Scenarios AE under Leakage The New Mode SIVAT MRAE with Leakage N M A N M A F kf ive ke ivd ke V km T km I C T I C T SIVAT is MRAE with Leakage If the underlying primitives are the Mac-verification doesn t leak the true tag the PRF is strongly adaptive secure Note ive can be instantiated with CFB.

57 Leakage Scenarios AE under Leakage Conclusion Results 1 A general framework to argue about AE in the face of leakage 2 Shown that A5, A6 (and CFB) behave mostly as expected provided tag verification doesn t recompute the tag 4 Showed a pairing-based fully adaptive leakage-resilient PRF secure in the generic group model.

58 Leakage Scenarios AE under Leakage Conclusion Results 1 A general framework to argue about AE in the face of leakage 2 Shown that A5, A6 (and CFB) behave mostly as expected provided tag verification doesn t recompute the tag 4 Showed a pairing-based fully adaptive leakage-resilient PRF secure in the generic group model. Open Problems Ever more AE definitional options; can one deal with various options more cleanly? Do other constructions allow weaker assumptions on the PRF? How leakage-resilient can standard model PRFs get?