Exploring Integrity of AEADs with Faults: Definitions and Constructions

. Implementation-based attacks are major concerns for modern cryptography. For symmetric-key cryptography, a significant amount of exploration has taken place in this regard for primitives such as block ciphers. Concerning symmetric-key operating modes, such as Authenticated Encryption with Associated Data (AEAD), the state-of-the-art mainly addresses the passive Side-Channel Attacks (SCA) in the form of leakage resilient cryptography. So far, only a handful of work address Fault Attacks (FA) in the context of AEADs concerning the fundamental properties – integrity and confidentiality. In this paper, we address this gap by exploring mode-level issues arising due to FAs. We emphasize that FAs can be fatal even in cases where the adversary does not aim to extract the long-term secret, but rather tries to violate the basic security requirements (integrity and confidentiality). Notably, we show novel integrity attack examples on state-of-the-art AEAD constructions and even on a prior fault-resilient AEAD construction called SIV $. On the constructive side, we first present new security notions of fault-resilience, for PRF ( frPRF ), MAC ( frMAC ) and AEAD ( frAE ), the latter can be seen as an improved version of the notion introduced by Fischlin and Gunther at CT-RSA’20. Then, we propose new constructions to turn a frPRF into a fault-resilient MAC frMAC ( hash-then-frPRF ) and into a fault-resilient AEAD frAE ( MAC-then-Encrypt-then-MAC or MEM )


Introduction
Right from their introduction, Fault Attacks (FA) [BDL97,BS97] have received significant attention from the research community. Over the years, both analysis and fault injection techniques have improved significantly [TMA11, FJLT13, SBHS15, SH07, SBR + 20, DEK + 18, PCNM15, ZLZ + 18, MOG + 20, DEK + 18, DEG + 18, SBR + 20, SBJ + 21], making FAs practical for a large spectrum of devices ranging from embedded platforms to cloud environments. However, most of the existing research on FA in symmetric-key cryptography is dedicated to block ciphers. Given that FAs often target key recovery, and block ciphers are the most widely deployed symmetric-key primitives, this is not surprising. However, the fact that a given computation can be tampered with at any point by a fault makes the scope of FAs much wider. In other words, it is important to explore state-of-the-art symmetric-key operating modes with respect to FAs where, other than key recovery, faults can also disrupt the mode execution.
Authenticated Encryption with Associated Data (AEAD) is a class of symmetric-key operating modes that has gained prominence in the research community in the past years.

Our Contributions:
Novel Fault-based Attack on Integrity. In this paper, we shed light on the integrity issues arising due to FAs. We first characterize different attack surfaces violating the integrity, and then propose a new class of fault-assisted integrity attack called decoupling attack. For any given message M , the decoupling attack can generate a valid forgery with message M ⊕ ∆, where ∆ is any difference. It also extends to message length modifying attacks. We show that the fault resilient scheme in [FG20] is vulnerable to this attack.
We carefully distinguish the proposed decoupling attack from attacks which corrupt the message/nonce/Associated Data (AD) at the input of the AEAD with a fault ∆, and uses the output of the encryption module as a forgery. One may notice that the attack on the nonce input mentioned previously also falls in this category. In the decoupling attack, the fault is injected during the computation and not at the beginning. While corrupting the inputs indeed qualifies as a practical attack, their triviality follows from the fact that the inputs can also be tampered at their very sources to create an equivalent effect. Such tampers are typically "out-of-the-scope" for the AEAD security and these "generic" attacks are excluded from potential attacks in this work. Our security model (ref. next paragraph) abstracts away input faults where faults happen at the input itself or slightly after, thus, drawing a boundary between what is considered an input fault and what is not. Upon fault injection, the adversary might get a valid ciphertext equivalent to manipulating the input (i.e. a valid plaintext ciphertext-pair) but nothing more. Regardless of the validity of the ciphertext, it cannot generate/predict a new ciphertext.
New Security Notions for Fault Resilience. Faults may corrupt different parts of an execution -the data-flow, control-flow, the memory elements, and even the constants and tables. Furthermore, the nature of the corruption can be diverse -from flipping a few bits to fixing a (full/partial) state to a predefined value. Finally, a fault can be a transient or a persistent fault staying in the system for several encryptions. We capture this diversity within a unified template. Such unified modeling helps us to formally argue the security of constructions with respect to adversaries having varying power. Next, we introduce new security notions called fault-resilient-PRF (frPRF), fault-resilient-Random Oracle (frRO), fault-resilient-MAC (frMAC) and fault-resilient-AEAD (frAE). Informally, a frPRF is simply a PRF where the PRF security is not affected by faulty queries. Practically speaking, this property can be ensured if the PRF keys cannot be recovered with faulty queries, so it can be obtained from a primitive with fault countermeasures. This frPRF notion will then be used as a building block for our constructions.
Fault Resilient MAC and AEAD from Fault Resilient PRF. Our final contributions are two new constructions. First, we describe hash-then-frPRF, a fault-resilient MAC (frMAC) based on the frPRF notion, having similar properties as frPRF along with MAC security. The hash-then-frPRF construction takes a randomness-augmented input and generates a tag. The security of this construction is ensured for an adversary capable of doing a single differential fault per query, before the challenge query is submitted.
Regarding AEAD, a straightforward way to achieve security against faults is to duplicate the entire computation multiple times and check for any mismatch in the results. More precisely, one may encrypt the same (N, A, M ) tuple t times and only output if the results match for all the cases. However, this entails a computational overhead of t times. Another alternative is to apply t different AEADs (or maybe the same AEAD algorithm with different keys) on the same message and let the decryption module check if all the decrypted messages are the same. This approach typically increases the ciphertext length and the amount of computation by t times. In search of a more elegant and practical solution, we found that it is somewhat inevitable to get rid of the redundancy completely, at least for the MAC computations. However, the order of the encryption and the MAC operations plays a crucial role in the security. After a careful analysis, we propose a three-pass mode called MAC-then-Encrypt-then-MAC or MEM, from which the MAC and the encryption steps are realized with frMAC and frPRF primitives, respectively. The reason for realizing a three-pass mode is that single and two pass modes, in general, fail to prevent the proposed decoupling attacks. It was also interesting to observe that several other possible three-pass constructions may not achieve the desired security as the decoupling attack works on them.
MEM ensures integrity for single differential fault injected per encryption query. Additionally, it achieves confidentiality if there is no fault in the challenge queries. An AEAD security game is designed for this purpose, which carefully excludes the generic attacks mentioned before. We note that faulty encryption and non-faulty decryption emulates numerous practical scenarios where the encryption module can be accessed and faulted by an adversary, but the decryption module runs in a secure environment. Also, single differential fault per encryption is the most common scenario that can be realized for a large class of practical devices.
The rest of the paper is organized as follows. In Sec. 2, we present the notations, and concepts utilized throughout the paper. We formalize the fault modeling in Sec. 3, followed by a discussion on fault-tolerance of conventional AEADs in Sec. 4. We present the decoupling attack and discuss the vulnerability of SIV$ to this attack in Sec.5. We present the new security notions and the new hash-then-frPRF MAC construction in Sec. 6, and the MEM construction with associated security games in Sec. 7. We conclude the paper in Sec. 8 with some open issues discussed in Appendix D (supp. material).

Notation and Terminology
We denote deterministic assignments with '←'. Assignments with uniform random sampling from a set are denoted as' $ ← −'. Definitional assignments are represented with ':='. By |X| we denote the length, if X is a string and size, if X is a set. ε represents an empty string, and ∅ denotes an empty set. x ⊕ y denote the bitwise XOR operation between two strings x and y, provided |x| = |y|. Similarly, for strings x 1 , x 2 , · · ·, x n , x 1 ||x 2 || · · · x n denotes their concatenation. For two sets A and B, A ∪ B denotes the set union and A ∩ B denotes the set intersection. For two sets D, R, f : D → R denotes a function with domain D, range R and Im(f ) := {f (x) : x ∈ D} ⊆ R. ⋆ denotes a placeholder.
• Dec(K, N, A, C): On input a secret key K, a nonce N ∈ N , an AD A ∈ AD, and a ciphertext C ∈ C, the deterministic Dec outputs M ∈ M∪⊥ (M ← Dec(K, N, A, C)).
Definition 2 (Pseudo-Random Function (PRF)). A keyed function F : K × M → Z, denoted as F (K, M ) (or F K (M )) takes a secret key K ∈ K, and a message M ∈ M and returns a fixed length string Z ∈ Z. For K ∈ K, let PRF K (M ) be an oracle which takes as input a message M ∈ M and returns F K (M ). A (q m , t)-adversary against the prf security of F is an adversary A with oracle access to PRF K , making at most q m queries, and running in time at most t. F qualifies as a PRF, if for all A, trying to distinguish the real world PRF K , and an ideal world oracle RF returning independent random values (instantiating a truly random function) the advantage: is negligible in the security parameter. An adversary A is not allowed to repeat queries.
Definition 3 (Message Authentication Code (MAC)). For K ∈ K, let Mac K (M ) be the MAC oracle which takes as input a message M ∈ M and returns F K (M ), and Verify K (M ) be the verification oracle that takes (M, τ ) ∈ M × T as input and returns 1 if F K (M ) = τ and 0, otherwise. We assume that an adversary makes queries to the two oracles Mac K and Verify K for a secret key K ∈ K. A (q m , q v , t)-adversary against the mac security of F is an adversary A with oracle access to Mac K and Verify K , making at most q m queries to its first oracle and at most q v verification queries to its second oracle, and running in time at most t. We say that A forges if any of its queries to Ver K returns 1. The advantage of A against the mac security of F is defined as: where the probability is also taken over the random coins of A, if any. The adversary is not allowed to ask a Verify K query (M, τ ) if a previous query M to Mac K returned τ . However, it is still possible that a Verify K query (M, τ ) is first made, possibly rejected, and a Mac K query M is subsequently made. We define Adv mac F (q m , q v , t) as the maximum of Adv mac F (A) over all (q m , q v , t)-adversaries. Finally, we represent the mac security using the advantage of an adversary trying to distinguish the real world (Mac K , Verify K ) and the ideal world. The ideal world oracles are (RF, Rej), where RF returns an independent random value (instantiating a truly random function) and Rej returns 0 for every verification query.
whereas for mac security, an adversary makes at most q m queries to its first oracle and q v verification queries to its second oracle, runs in time at most t, and returns a decision bit. We note that q v = 0, this is equivalent to PRF security.

Modelling the Faults
The first step towards formalizing fault resilience is to model the faults with a unified structure, which encodes the fault location, width, physical model,. . .etc. Such a unified representation is useful for quantifying the security. The unified representation that we present in this section is similar to the one presented in [FG20], but is a bit more elaborate 3 . It captures different variable classes for fault injection, which was not covered in [FG20].
Before formally presenting the model let us briefly describe the type of faults practically observed on devices. In practice, localized (say within one bit/byte of a variable) and temporally precise (at a specific line/statement in the code) transient faults are observed in most of the devices [SGD08, DEK + 18, MOG + 20]. The faults may result in random corruption of the affected variable, flipping of specific bits, or specific data-dependent corruption such as bit set/reset [SBHS15, SBJ + 21]. Persistent bit-flips at tables/constants are also feasible, where the fault remains in the system till a reset [ZLZ + 18]. For software implementations, instruction-corruption/skip faults are observed which eventually results in corrupting the data-flow or control-flow of the program [KPB + 17, MHER14]. Overall, the main impact of any fault in a cryptographic setting results in a data/control flow corruption. The precision, width, and repeatability of a fault are largely dependent on the quality of the injection setup. For example, it is difficult to make targeted bit-flips with clock-glitch, but such targeted bit flips are common with laser-setups. Our unified representation and fault models, however, abstracts necessary traits of practical faults.
The fault in a computation is characterized by the tuple: The parameters in Eq.
(1) are defined in Table 1, along with a classification of the variables to be faulted, and a classification of the fault models. In order to explain why classifying variables is important, we distinguish between data and control faults. Control faults, for example, may skip an entire function call, which cannot be represented easily with a data fault. In general, control faults can be realized by corrupting the loop-counter, a  loop-decision variable, or the decision variable of an if-else statement, which do not always  contain the data/state being encrypted. Similarly, faults in constants may have different consequences on both control and data. For example, fault in a constant domain separator may open up scopes for several attacks. Therefore, a holistic analysis should capture each of these variable classes separately, to clearly specify the scope of the claimed security with respect to faults. The fault models capture the physical faults. The temporal and spacial precision of faults can be captured by the variables, transient/persistent nature, and the fault width parameters. At the level of a pseudocode, the temporal precision of a fault can be captured by specifying the position (e.g., line number) of the statement where the target variable resides. Also, if the statement resides inside a loop, the loop counter is used as an extra parameter to specify the exact timing of the fault during loop execution. All of these parameters depend on the target implementations, and, therefore, helps to capture different (hardware/software) implementations under our unified template. The diff faults model a large class of faults (including single/multi-bit flips) changing the value of a variable. The rand faults model the random corruption of variables and is a special case of diff faults. fix is the strongest fault model in this case in terms of physical realization. It requires setting a variable (or a part of it) to a desired value, which is practically difficult for a large fault width (w i ). However, fix models the data dependent bit set/reset faults. It can also model a a specific case of diff faults, where the value of the target variable is known. In this case, fix faults can be be interpreted as diff faults having a different ∆ corresponding to each valuation of the target variable. Regarding persistent faults, it is worth mentioning that we do not assume the faults to persist during the challenge queries of the schemes we are going to propose in this work. This is a natural choice as in this work we shall only argue security for non-faulty challenges.

nf
The number of faults injected throughout the computation (in the same or different clock cycles).
control Denotes the set of control-flow variables (branch statements).
wi Denote the width (how many bits within a target variable are corrupted) of a fault (0 ≤ wi ≤ |vi|).
constant Denotes the set of constants, tables, and domain separators of the AEAD algorithm.

modi
The logical abstraction of physical nature of faults (fault models).
ti Denote if the fault is transient/persistent and the temporal fault location.

Fault Models
fix Denote faults where the adversary is allowed to fix wi bits of the target variable to some desired value.
diff Denote the differential faults where the adversary is allowed to select a bitwise differential ∆i for variable vi (with HW (∆i) = wi) and set v

Representing Faults in an Algorithm
In order to define the security games flexibly with faults, we follow a specific syntax of defining faults with an oracle. The interaction between a faulting adversary A(F), and an oracle O f lt is defined in Table 2. O f lt maintains a list V f lt of the values taken by every variable appearing during the computation. If there is a fault in any of the variables (or At this point, it is important to distinguish the faults in two types: a) informationleaking faults, and b) altering faults. While every fault indeed alters the data or flow of computation, information-leaking faults require a special mention as the corruption is always meant for leaking some secret. By the very nature of FAs, such leakage happens from the outputs of queries faulted with information leaking faults. Our oracles does not distinguish between these altering and information-leaking faults, but only keeps the scope that some secret might leak through the faulty outcomes. There are several ways in which faults can be exploited for attacking AEAD schemes. According to the basic security goals, they can be classified into two broad classes -attacks on confidentiality; and attacks on integrity. The main focus of this paper is to shed light on integrity violations. We restrict ourselves to encryption faults.

Recovery of Long-Term Secrets
The most obvious attack on integrity is to recover the long-term secret associated with the MAC by means of faults. If the underlying scheme utilizes the same long-term key for both encryption and MAC generation, then recovering the key from either the encryption or the MAC block is feasible. Most of the existing AEADs do not include explicit fault countermeasures. Therefore, attacking the primitives processing the long-term key is always a feasible attack surface.
In order to give a concrete example, we refer to the OCB scheme [KR16] depicted in Fig. 1(a). The encryption (E K ) processes each message block (M i ) XOR-ed with a nonce-dependent mask (D), and then further XORs the same mask with the result to produce the ciphertext. In the last incomplete block, only the mask D is encrypted and the padded message is XORed with the encryption output. The MAC computes a checksum over the message blocks, which is then XOR-ed with D. Next, an encryption operation is performed on this followed by an XOR with the Auth (AD). To attack the MAC, without loss of generality, we consider the AD part to be empty. As a result, the adversary can obtain the encryption of the message checksum XOR-ed with the mask D. As the ciphertext (i.e. the tag) is available, the adversary can launch several key recovery attacks such as PFA [ZLZ + 18], SFA [DMMP18] or SIFA [DEK + 18] to recover this long-term secret (encryption key K) without nonce repeat. For example, if the encryption (E K ) is realized with AES, single-bit faults can be injected at the 10th round S-Box input and several faulty tags can be collected. Then the adversary can guess one key byte of the last round at a time to partially decrypt a byte of the faulty tags reaching the fault injection point. If the key guess is correct, then the single-bit corruption should be observed at the injection point. Computing the Hamming Distance (HD) between all partially decrypted faulty tags would expose this single-bit corruption -the key guess with lowest aggregate HD denotes a correct key byte [GYTS14]. This attack would eventually expose several key bytes. Alternatively, an adversary can perform this attack on the encryption of the incomplete message block recovering the entire key. Recovery of the long-term key is sufficient to create universal forgery attacks. Such key-recovery attacks are feasible for many other schemes beyond OCB. Therefore, each block cipher call for such schemes should be protected against FAs.
The recovery of long-term secrets can be considered as a leakage. Therefore, it is important to explore the leakage-resilient schemes in this regard. The processing of long-term secrets is often restricted to a few primitive calls in leakage resilient schemes. Let us consider the TEDT [BGP + 20] scheme as an example (ref. Fig. 1(b)). TEDT performs PSV [PSV15] encryption followed by MAC generation (Encrypt-then-MAC). The IV of the PSV encryption is generated by encrypting the nonce (N ) with a leak-free TBC with a "public key" (P K) as a tweak (i.e T = P K) and a long-term secret key K. The MAC part hashes the ciphertext, the AD, the nonce, and P K, and then encrypts the hash with a leak-free TBC with the same secret key. In case this leak-free block of TEDT is not protected against FAs, the attacks on it become straightforward. Since TEDT is nonce misuse-resilient, a large class of attacks (such as DFA) becomes feasible on the leak-free block during the MAC operation if the nonce repeats. One should note that the unavailability of the ciphertexts from the leak-free block (during the encryption of the nonce) is not an issue here. Attacks, such as FTA [SBR + 20], can work on the leak-free block (during the encryption of the nonce) without ciphertexts only based on the information whether the computation is faulty or not. Even for nonce respecting use-cases, SIFA/SFA remains feasible [DMMP18]. Finally, the leakage from the output of the leak-free components (which is allowed) also enables combined attacks [SBJ + 21]. Therefore, it is evident that the leak-free components must include FA countermeasures.

Generic Attacks on Integrity Without Secret Recovery
A crucial question is, therefore, can integrity be violated even without extracting the long-term secrets? As we shall describe in this subsection, the answer to this question is affirmative.
Our first set of attacks consider the faults to be injected at the inputs of the AEAD. The attacks are described as follows: 1. Query AE.Enc with the tuple (K, N, A, M ; r).

Inject a fault
Without loss of generality, we define a fault mask

The adversary uses (N, A, C
) as forgery.
One should note that the injection on the message M is considered trivial by any integrity game, as the adversary has to repeat (N, A, C ′ ) as a forgery, which has been seen by the encryption oracle, and listed as trivial query by default. The same is true for a fault injection on r. However, if the fault is injected on the nonce or AD, the adversary can fool the traditional game by using ( ) as a forgery, assuming the encryption oracle has only seen N and A (and not N ′ , and A ′ ) paired with C ′ . Such issue with traditional security games is natural as these games do not consider faults. We resolve this issue by augmenting the security game considering faults in our game definition in Sec. 7. Nevertheless, as already pointed out in the introduction, all these attacks are considered generic (corrupting the inputs) and their scope is beyond the AEAD security. A relevant question is, can there be a non-trivial attack on AEADs without performing an input fault or long-term key recovery? Next section shows that it is indeed feasible.

The Decoupling Attack
In this section, we present the decoupling attack. For the sake of illustration, we consider the leakage resilient scheme TEDT (ref. Fig. 1(b)). However, the attack applies to most of the existing schemes. The following attack utilizes the Encrypt-then-MAC structure of TEDT. The attack can be described as follows: 1. Query AE.Enc with the tuple (K, N, A, M ; r).

The fault is injected at the input of the MAC operation corrupting the ciphertext.
More precisely, the input to the MAC is corrupted to (N, The original ciphertext, however, remains unchanged. 4. The adversary modifies (C||τ ) to (C ⊕ ∆ i ||τ ), which is a valid forgery.
The proposed attack also works if the fault model is rand. However, it becomes probabilistic and remains practical for small fault widths. The traditional integrity game (INT-CTXT) or its leakage-enhanced versions cannot deal with the decoupling attack. This is because the ciphertext coming out of the encryption module, in this case, is an invalid one, and the adversary can make it valid by some offline computation. Moreover, this attack strongly depends on the structure of the AEAD scheme and should, therefore, be handled within the scope of AEAD. In the next subsection, we show that the fault resilient scheme proposed in [FG20] is also vulnerable to this decoupling attack. We shall also argue that the attack is not limited to linear encryption schemes.

Issues with Existing Fault Resilient AEAD Schemes
In this section, we show that the decoupling attack also works on the fault resilient scheme SIV$ [FG20]. The security game corresponding to [FG20] is presented in Table 11 in Appendix E (we do not need this to describe the attack). The SIV$ construction is described in Table 3, which uses a PRF for generation of an IV . The IV itself works as a tag and is also utilized to seed the encryption operation. The main difference of SIV$ from classical SIV is the incorporation of a random value r for the computation of the PRF. However, this simple trick does not ensure integrity. It is worth noting that the attacks designated as generic by us are also excluded by the game in [FG20].
Let us consider a fault in the message M at the input of the PRF step. However, M remains uncorrupted during the encryption. This can be ensured by inserting a transient fault while reading the message from the memory for the MAC step. Without loss of generality, we consider a differential fault in this case, although the results are not limited to this fault model. After injecting this fault, the IV (let us denote the faulty IV as IV ′ ) corresponds to the message M ⊕ ∆ i , while the ciphertext C ′ corresponds to M . Indeed this is an invalid output in the sense that it cannot be decrypted and verified successfully. However, if the encryption operation of SIV$ is linear (that is, if it generates a pseudorandom string that is XOR-ed with the message to encrypt it), the adversary can create a valid forgery from this by computing The linearity assumption on the encryption can be relaxed in certain cases. As a pathological example, let us consider an instantiation of SIV$ with CBC encryption. Instead of changing the value of the message M , we can drop a few message blocks during the PRF computation. This can be achieved by faulting the message-length parameter (which is a common input in many practical AEAD syntax) with a data fault, or by injecting a control fault to abort some loops before their completion. In this case, the attack works beyond linear encryptions, provided it encrypts the message block-wise. In essence, the adversary can generate the encryption of a truncated message as a valid forgery. However, applicability of such truncation attacks depends upon the scheme under consideration. For example, it can be prevented if the message-length parameter is also encrypted with each message block. The decoupling attack, in general, work against most common AEAD modes including the single-pass ones. A detailed discussion on this is provided in Appendix A (supp. material).

Fault Resilient PRF and MAC
We begin with defining a new primitive in this section called fault-resilient PRF or frPRF. We also construct hash-then-frPRF, a fault-resilient MAC (frMAC) using the frPRF as a base primitive. These constructions will be utilized for constructing a fault-resilient AEAD.

Permissible Fault Models
Our fault modelling in Sec. 3 covers possible fault scenarios. However, we only claim security against a subset of these models. We begin by restricting the adversary to inject only a single fault (i.e. nf = 1 in F; the subscript i is also dropped) during the entire encryption operation which is practical for most devices. Further, we limit the adversary to differential faults only 5 . Regarding the faultable variables, we assume that both data and a subset of control and constant faults are feasible. More precisely, at the mode-level in an AEAD pseudocode, control faults may corrupt a loop counter, or a loop-decision variable for the loops running over the message or ciphertext lengths. control faults may also happen for branch-decision (e.g., if-else) variables, if any. Likewise, constant faults are allowed for the used public constants. We note that other than modelevel, both control and constant faults can happen at a primitive-level, where the block cipher/TBC/permutation computations are corrupted. control faults may also cause skip of an entire block cipher/TBC/permutation function call at mode-level 6 . However, considering such faults would require concrete instantiations of these primitives. We leave this as a future work. We further assume that there are certain components, for which fault injection either results in a correct outcome, a ⊥, or uniformly random outcome. Such components are denoted as "fault-free components". They can be realized by incorporating primitive-level FA countermeasures. Finally, leakage of some secrets is, allowed by means of information leaking differential faults except from the fault-free components.

Modelling Faults in Idealized Primitives
One of the challenges of addressing fault resilience is modelling faults in idealized primitives, e.g., random oracles and random functions. These primitives are monolithic in nature; they do not have an implementation that can be faulted. On the other hand, these constructions are always used in a certain context, mainly to be compared with a real-world primitive. Such real-world primitive has an implementation description. Hence, we use this real-world primitive to simulate a fault behaviour that we can impose on the idealized primitive. For primitives keyed with a long term key, we assume that faults are always performed on the real-world primitive but the challenge queries in the ideal world are performed on the ideal-world primitive. For public functions, we use the difference between the faulty and non-faulty executions of the real-world function to deduce the output fault difference in the ideal-world primitive.

Fault-Resilient PRF
A fault-resilient PRF is a PRF that comes with a second oracle PRF f K (M, F), which we call a faulty PRF oracle. According a given fault model, the adversary can induce faults during the execution of PRF f K . A (q f , q m , t)-adversary against the frprf security of a PRF F is an adversary A that makes q f faulty queries PRF f K and q m queries to PRF K and runs in time t. Table 4 depicts the PRF K and PRF f K oracles. In Table 4, we separate S and S f lt to capture the resilience notion. S is the list of queries to the non-faulty oracle and S f lt is the list of queries to the faulty oracle. However, S f lt can also include non-faulty , F) also returns the set M f lt which contains all the values of M that appear during the execution, including faulty values. Note that the faulty oracle keeps track of the number of valid input/output pairs (or pre-images) that are leaked from the faulty implementation as n pre . In the ideal world, if n pre > 1, the oracle returns ⊥. Hence, if an implementation leaks more than one input/output pairs for any call, the two worlds can be easily distinguished. An adversary against frprf security of the PRF K must perform all PRF f K queries before querying PRF K . Hence, at a given query to PRF K , the adversary is considered to have performed q f queries to PRF f K followed by q m − 1 queries to PRF K . For a PRF outputting n bits, the adversary aims to distinguish the last q m outputs from a random string of length nq m . Let n i pre be the number of pre-images for faulty query i and Q f (A) = {1, · · · q f } if A makes q f faulty queries. The frprf advantage is given by: This bound follows from a simple hybrid argument. The first term bounds the advantage of distinguishing the real-world game from a similar transitional game where the faulty oracle is replaced by the ideal world faulty oracle (it returns ⊥ when more than 1 preimage is leaked in one query). The second term bounds the advantage of distinguishing the transitional game from the ideal world game. We call F K a fault-resilient PRF, if Adv frprf F (q f , q m , t) is negligible for all adversaries that do not query PRF K with a trivial query, such that q f and q m are polynomial in some security parameter. Trivial queries are defined according to the set S ∪ S f lt in Table 4.
It is crucial to note that the fault-resilient PRF must perform all faulty (and some fault-free) queries before making the challenge queries. We do not claim security for faults in post-challenge queries. Without loss of generality, let us consider a challenge query as M c for which the frPRF oracle returns X (it is interacting with PRF K ). Next, in a post-challenge query, the adversary queries M ′ c , and faults it to M c (and therefore, queries PRF f K ). In this case, the adversary will be able to distinguish the ideal world from the real world, using the PRF f K outcome. However, gaining information about future queries are not possible due to the structure of the game. We leave the security for faulty post-challenge queries an open issue at this point, and only claim security for faults at pre-challenge queries. One intuition is to use a randomized PRF to overcome this issue. However, since our construction is based on a deterministic PRF, we restrict ourselves to this model. The reasoning for this approach is that, while it might be tempting to consider a randomized PRF, such definition is not clear and leads to issues in our assumption and also in practice. The security of our construction relies on being able to build and test the deterministic frPRF in practice. For example, it can be built from a block cipher with fault countermeasure (e.g. duplication or other forms of redundancy). This can be easily tested, as we simply require two simple properties; the block cipher is secure, and fault-based key recovery attacks on the implementation are not possible. If the PRF is randomized then additional and unclear testing would be required for the PRF and this would lead to stronger assumptions. However, even restricting the faults "pre-challenge" covers several practical situations where the adversary only has access to the device for a limited time and it wants to disrupt future queries exploiting that access. Our model also differentiates between a classical adversary (q f = 0) and an adversary who performs non-faulty queries during the training phase (the first q f queries where q f ̸ = 0). The difference is in the ideal world, where in the latter case, the first q f queries always use the real-world oracle, while in the classical case all the queries will be random an independent. While this can be considered a limitation in some analyses, we see this as an inherent feature from the two-phase security notion we propose, and in our view it captures the concept of an adversary that has access to the implementation for a training phase before issuing challenge queries. We leave it as future work whether stronger security notions are better at capturing real life scenarios or not and whether a deterministic fault-resilient PRF can be built in those stronger models.  Here A can also query faulty oracle Fault(H(·), F), which we sometimes refer to as H f (·, F) for simplicity, but a collision on H f s is not considered valid.

Observation. A (t, ϵ cr )-collision resistant hash function is also a (t, ϵ cr )-collision resistant in the presence of faults for the non-faulty queries.
Since H s is a public function, the adversary can find a collision by simulating the hash function themselves, with or without faults. However, finding a collision on a faulted version (H f s ) does not imply a collision on the non-faulty H s , as these two are different public functions, and collisions on H f s are unlikely to lead to a collision on H s . For simplicity, from now we omit the suffix "s" and use H for hash function.
When Since the adversary will be able to inject differential faults in any location inside the hash function (including its inputs and outputs), we need its state to be uniformly distributed. Hence, we need to perform the analysis in the random oracle model. We also need to define what exactly do we mean when we refer to a "fault-resilient" random oracle. Note that the frRO is a theoretical construction in nature. We assume its existence and conjecture that if a hash function is indifferentiable from a random oracle, then its faulty version is also indifferentiable from a frRO. Showing that such property is satisfied for a specific hash function (e.g. sponge-based hash functions) is one of our future research questions and is out of scope of this paper.

Fault-resilient Random Oracle (frRO):
In our constructions, we rely on the fact that the hash function used behaves like a random oracle even when differential faults can be induced. A random oracle is fault resilient if: 1. When the input is randomized, the internal state and output are also randomized and unpredictable. Injecting a differential fault leads to an unpredictable state.
2. Regardless of previous faulty queries, when an input is fresh (was not queried before) and random, the internal states and output are unpredictable.
In order to formalize these properties, we define a frRO.  Table 5 depicts this oracle.
Since a random oracle is a monolithic idealized primitive, we cannot inject faults except at its inputs or outputs. As long as F.mod ∈ {nof, diff, rand} and R f lt is collision free (i.e. bad is never asserted), the frRO behaves as a random oracle, since a uniformly sampled output will be generated for each invocation, and the fault can change the output with a specific difference. In practice, a hash function has an implementation that can also be faulted at any intermediate operation. In this case, the output is not simply, H(r∥x) ⊕ ∆, but it can be a value related to H(r∥x) and the fault location and value. However, since r is returned with the hash value, the adversary can compute H(r∥x) and deduce ∆. The frRO uses the implementation of the hash function to also deduce the output difference using both the faulty and non-faulty output. This is depicted in lines 23-25 in Table 5. The definition of the frRO is parametrized by which hash function H is being evaluated. An adversary tries to distinguish between the case of a true random oracle (ideal world) and the real world depicted in Table 5. The distinguishing advantage is given by where RO is the random oracle that takes as inputs r and M and returns a random output.
Theorem 1. As long as the bad event is never set, then frRO is indistinguishable from a fault-free random oracle.
Proof. Let q be the number of calls to frRO and q f be the number of calls to frRO f . Since each query adds at most 2 values of r to R f lt , the probability of setting bad is bound by If bad is never set, then the output of each query is uniformly distributed, which is indistiguishable from the output of a fault-free random oracle.

Conjecture 1. If a hash function H is indifferentiable from a random oracle, then its faulty implementation with differential faults is indifferentiable from an frRO.
It is clear that in case the fault is injected inside the hash function implementation, then the random oracle and the hash function do not behave in the same way. However, the description of frRO is consistent and if bad is never set, the output of the hash function (under the random oracle model) is uniformly distributed. A real-world faulty hash function is similar to Table 5, except that RO is replaced with H. If the hash function is constructed as an iterative function using a compression function and the faults can only be injected outside the compression function, then the conjecture above is straightforward, as an adversary against a fault-free random oracle can simulate the faulty queries using the compression function oracle. However, if faults can also be injected inside the compression function then a more careful analysis is needed.

Fault-Resilient Message Authentication Code (frMAC)
For K ∈ K, let Mac K (M ) be the MAC oracle which takes as input a message M ∈ M and returns F K (M ), and Verify K (M ) be the verification oracle that takes (M, τ ) ∈ ×M × T as input and returns 1 if F K (M ) = τ and 0, otherwise. We assume that an adversary makes queries to the two oracles Mac K and Verify K for a secret key K ∈ K. Besides, we also define the faulty MAC oracle Mac f K (M, F), which takes as input a message M and fault specifications F and returns (M f , τ ), such that Mac K (M f ) = τ or M f =⊥. We define the frMAC game as in Table 6, similar to the frPRF game in Table 4.
A (q f , q m , q v , t)-adversary against the frmac security of F is an adversary A with oracle access to Mac f K , Mac K and Verify K , making at most q f queries to its Mac f K oracle followed by at most q m and q v queries to its Mac K and Verify K oracles, respectively, running in time at most t, and returning a decision bit. Similar to mac, we represent the frmac security using the advantage of an adversary trying to distinguish the real world npre ← npre + 1 9: return X npre ← npre + 1 9: if npre > 1 10: return ⊥ 11: return X We note that when q v = 0, this is equivalent to frPRF security. The adversary is not allowed to repeat queries to its Mac K oracle, or ask for queries to its Mac K . Consider the hash-then-frPRF MAC, where the internal PRF is a frPRF, as depicted in Fig. 2. The frPRF can be realized with block ciphers or TBCs with fault countermeasures. We will claim that such construction is also a frMAC if M is randomized. Before that, we motivate the analysis by considering some of the attacks an adversary may try. Note that by the rules of the game in Table 6, the last q m queries must not have appeared in the set S f lt after the first q f queries. At a given query j, the adversary can try to:

Extending Fixed-length frPRF to Arbitrary-length frMAC
1. Find M such that H(r∥M ) = H(r ′ ∥M ′ ) for a previously queried message r ′ ∥M ′ , potentially using either a non-faulty query, ineffective fault or predictable-preimage fault. If r∥M = r ′ ∥M ′ , then the attack is trivial. If r∥M ̸ = r ′ ∥M ′ , then the adversary has found a collision for H.

Find M such that H(r∥M ) =
h where h has appeared as the input to frPRF during at least one of the first q f + j − 1 queries, using an unpredictable-preimage fault. In this case, the adversary needs to predict the value of r.
3. Find bias in τ in queries for which H(r∥M ) has never appeared in any of the first q f + j − 1 queries. This needs the adversary to break the frprf security of base frPRF.
4. The adversary can try to find a near-collision such that H(r∥M ) = H(r ′ ∥M ′ ) ⊕ ∆ where ∆ is a fault they can inject. However, to use such fault, the adversary needs to predict when r and/or r ′ will appear. Since the random value is unpredictable, this attack is not feasible.
In all cases, the adversary needs to break a strong security notion on one of the primitives or predict a random value, and the random values are shared with the verification oracle in a secure way, beyond the scope of the construction.
Here q e = 2q f + q m and q p is the number of queries made to the last oracle Hash.
The proof of this theorem is presented in Appendix B (supp. material). Table 7 presents the oracles for hash-then-frPRF.

Fault-Resilient AEAD
In this section we propose our construction for a fault-resilient AEAD (frAE). One may observe that a straightforward combination of frMAC and some encryption scheme (either as "Encrypt-then-MAC", "MAC-then-Encrypt" or "MAC-and-Encrypt") is not going to work in this case. This is because the adversary can fault the input of the frMAC and enable the decoupling attack. We, therefore propose a three-pass construction.

MAC-then-Encrypt-then-MAC (MEM)
return M 10: else return ⊥ Our proposal for frAE is presented in Table 8 and Fig. 3. The crux of this scheme lies in further authenticating the (τ 1 ||C). Both the MACs (denoted as Mac K1 and Mac K3 ) are constructed by applying the frMAC. The fault-resilient encryption (frEnc) is performed with PSV [PSV15] initiated with a frPRF. However, it can be abstracted as any pseudorandom bit generator seeded with a frPRF 7 . We assume distinct frPRF and hash functions for Mac K1 and Mac K3 and PSV enabled by different key for each frPRF 8 . The encryption operation also requires two distinct constants constants (p a , p b ). Finally, an injective function pad is required at the input of Mac K1 . Figure 3: The MEM construction. F * denotes the frPRFs realized with fault-free blocks.
One should note that our construction is computationally efficient compared to the simple duplication-based schemes. We do not need to duplicate the encryption operation. Furthermore, the MACs are computed on different variables, namely the message and the ciphertext tag pairs. This further limits the scope for decoupling attacks as the MACs has to be performed in a sequential manner and none of these variables appear at the same clock cycle. A single fault adversary cannot corrupt the MACs together to create a decoupling. Interestingly, we found that not every three-pass construction has such nice properties, and many of them are vulnerable. This point is discussed in Appendix D. Our construction also bears some structural similarities with the leakage-resilient scheme SIVAT in [BMOS17]. However, SIVAT does not include frPRFs and randomness, which are essential for security against faults (to prevent fault-assisted nonce repeat, and manipulation of the hash values). Also, SIVAT does not check one of the tags at the decryption. This is crucial in FA, as otherwise, the decoupling attack will happen.

The Fault Resilient Security Game
We first define the security game for AEAD considering encryption faults (Expt frAE,b A,F ). The game is similar to the one for frPRF -we keep a faulty encryption oracle. However, after a certain point, the adversary is only allowed to make non-faulty queries. The set of faulty queries is denoted as S f lt , and the set of correct queries is denoted as S. S f lt ∪ S comprises all trivial queries. During a query to Enc f K , the encryption oracle keeps track of the correct and faulty valuations of each corrupted variable in the set V f lt . Referring to the game in Table 9, V f lt := N f lt ∪ AD f lt . Here N f lt and AD f lt denote the set of all possible (correct/faulty) valuations of nonces and ADs, respectively. For easy explanation, we directly refer to N f lt and AD f lt instead of V f lt in the game and the proof. We choose to keep track of those variables only, which take part in the decryption. Therefore, we do not maintain the faulty messages or intermediates explicitly. The reason behind such a choice is that the faulty encryption oracle here tries to decrypt (without faults) the resulting ciphertext with whatever values (correct/faulty) it has observed for the inputs (nonce and AD). The goal of this step is to only check whether or not any possible output tuple (N ′ , A ′ , C) gets decrypted successfully. The set of such decryptable tuples is denoted by I vld , which is later added to S f lt . One may note that this extra step in the encryption oracle helps us to avoid trivial queries. Additionally, we exclude the final outcome of the Enc K as the fault injection variable, as such faults also lead to generic attacks.

Security Proof
Proof Sketch: The proof of the following theorem follows directly from the security of the frPRFs and frMACs used in the scheme, and bounding the probability of a collision on the random value r, or the first tag τ 1 . Intuitively, the fault injected in the first MAC or the encryption step will be committed by the second MAC, such that τ 1 and C cannot be decoupled. On the other hand, a fault injected in the second MAC will lead to τ 2 that is decoupled from the input message, and the message corresponding to the forged tag will be unpredictable due to the randomness. The fault-resilient confidentiality of the scheme follows naturally from the resilience of the frPRFs. In order to show the security of the MEM construction, we need an additional definition.

Definition 5 (IV-based Encryption
). An IV-based encryption scheme E : K×M×IV → C is an encryption scheme that takes a message M ∈ M, an initial vector IV ∈ IV, and a secret key K ∈ K, and returns a ciphertext C ∈ C, such that |M | = |C|. An IV-based encryption scheme is fault-resilient against all (q f , q m , t)-adversaries, if for any adversary that runs in time t, and performs q f faulty queries and q m non-faulty queries using nontrivial IVs, the advantage of distinguishing the last q m ciphertexts from a set of random strings of equal lengths is negligible. We define this advantage as where $ takes the (IV, M ) pair and returns a random string of length |M |. We build a fault-resilient IV-based encryption scheme using a secure frPRF F K , and a pseudorandom key generator KG, as: Theorem 3. If Mac K1 and Mac K3 are a two independent fault-resilient MACs against all (q f , q m , q v , t)-adversaries and E K2 is a secure IV-and-fault-resilient IND-CPA encryption scheme against all (q f , q m , t)-adversaries, built using a secure frPRF and a pseudorandom key generator KG, such that E K2 = KG(F K2 (IV )) ⊕ M , then randomized MAC-then-Encrypt-then-MAC is a secure randomized fault-resilient authenticated encryption with associated data (frAE) against all (q f , q m , q v , t)-adversaries that perform differential faults: 2 |r| where q e = 2q f + q m , and q p is the maximum number of queries made to either H 1 or H 2 .
The proof of this theorem is presented in Appendix C (supp. material).

The Security of the Encryption Layer
In the security analysis and proof of the MEM construction, we assumed the middle encryption layer is resilient against IV repetition and faults. In other words, as long as the non-faulty queries use IVs that have not been used before (including faulty IVs), the outcome of these queries is indistinguishable from random strings. To construct the exact scheme, we use the PSV [PSV15] construction. Its security in this model is captured in our security claim by Adv ivfrind , and it can be seen that as long as fresh values for τ 1 appear, the initial key k 0 is uniformly distributed due to the fault-resilience property of the second frPRF. Therefore, PSV fits well for encryption here.

Conclusion
In this paper, we take the first step to address the problem of fault-assisted integrity violations in AEADs. We examine a new attack called decoupling attack which can affect many AEADs including the leakage-resilient schemes and existing fault-resilient AEADs (SIV$). We then formalize the notion of fault-resilience (frPRF, frMAC, frRO, and frAE) and propose a resilient construction (MEM) to prevent fault-assisted integrity attacks.
However, there still exist several crucial open issues. For example, our proposals still cannot withstand faults in the challenge queries. While extensions for multiple faults in the encryption is feasible, it is not explored in this paper and requires significant amount of research in the future. Extending the security claims for the fix faults (mostly if it is a full-state fault) is another point, where further exploration is needed. Finally, the ideas presented can be combined with the state-of-the-art leakage-resilient schemes providing combined security. However, a formal exploration of this requires further research. A discussion on these open issues is presented in Appendix D as supplementary material.
[   The decoupling attack is not limited to the "Encrypt-then-MAC" structures like TEDT. It is also applicable to "MAC-then-Encrypt", "MAC-and-Encrypt" and even for single-pass schemes. The attack on SIV$ (ref. Sec. 5.1) works as a representative to show how decoupling can be performed for "MAC-then-Encrypt" schemes. To see how it applies to "MAC-and-Encrypt" (or "Encrypt-and-MAC"), we refer to the OCB mode once again (see Sec. 4.1 for a short description of OCB). During the encryption of a message M = M 1 ||M 2 || · · · ||(M * pad), we target the final incomplete message block (M * ) for attack. During the checksum computation, we corrupt this message block making it M * ⊕ ∆ i . However, the encryption of M * remains uncorrupted. The MAC stage, therefore, computes τ ′ = M AC(M 1 ||M 2 || · · · ||(M * pad) ⊕ ∆ i ). The AE.Enc finally outputs (C||τ ′ ). The adversary creates a forgery by computing ((C ⊕ ∆ i )||τ ′ ).

A Decoupling Attack on Different Modes
We next argue that single-pass schemes like GIFT-COFB [BCI + 20] are also vulnerable. A careful investigation of GIFT-COFB (ref. Fig 4) shows that even for those schemes, one message block is processed two times -once for generating the ciphertext, and once for consuming it within the state for MAC. A fault during the second processing enables the decoupling attack. In general, decoupling can take place whenever any variable, which is either an input or output of the AEAD, is used multiple times. The usage includes reading from or writing back to the memory. For example, one may also target the ASCON [DEMS21] single-pass scheme. In this case, a ciphertext block is required to be corrupted, just when it is consumed by the next permutation block for MAC (Fig. 5). Such a fault can be created in many ways, such as by corrupting initial rounds of the permutation.

B Proof of Theorem 2
Proof. We start by replacing the F K function with an ideal-world frPRF: (F f K , RF) (Table 4; column 2). We assume the hash function with a frRO. The adversary A can make direct queries to the random oracle of the form h p = H(r p ∥M p ). It maintains two tables R p and H p , such that R p includes all the values r p used in these queries and H p includes all the pairs (r p ∥M p , h p ). The number of such queries is q p .
During the game the set S f lt ∪ S contains the trivial queries. If (r∥M, τ ) ̸ ∈ S f lt ∪ S, we call (r∥M ) a fresh message. Besides, if τ = Mac K (r∥M ), we call (r∥M, τ ) a valid pair. We describe the following games. The event E i is the event that the adversary against Game i terminates, outputting 1. We note that during any faulty query, at most two values can be added to any of the transcripting sets; M f lt or R f lt , since we only consider single faults. At the same time, if during a given call, the adversary observes two messages with the same tag, this will either imply a collision is found for the frRO or distinguishing the frPRF based on the value n pre in Table 4.
Game 0: The game described in Table 7 is used with (F f K , RF) being a ideal-world frPRF. E 0 is the event that ∃j ∈ {1, · · · , q v } s.t. r j ∥M j is fresh and (r j ∥M j , τ j ) is a valid pair.

Game 1:
The game is similar to Game 0 but it terminates if a collision is found in the set R f lt , or between a value in R p and a value in R f lt . Note that an adversary can make queries to the random oracle with r p = r i received from a previous query to Mac K or Mac f K leading to a trivial condition. However, we are interested in the adversary's ability to predict a random value. In order to construct Game 1, we need to construct an adversary A ′ that simulates the oracles in Table 7 using the H, H f , RF and F f K oracles (F f K is the PRF f K oracle from Table 4). After the i th query, it checks the sets R f lt and R p and returns 1 if there one of the following two conditions is satisfied: 1. R f lt has a collision.
2. The i th query is a query to Mac K or Mac f K and r i ∈ R p Since r i is uniformly distributed and unpredictable to the adversary before it is used, then all the values in R f lt are almost uniformly distributed. Note that not all pairs in R f lt are equally likely to collide, e.g., r and r ⊕ ∆, where ∆ is a fault value will never collide. This reduces the collision probability from the case where all the values are uniformly distributed (it reduces the number of collision-pair candidates). We can upper bound the probability by taking the uniform case, which is the collision probability over |R f lt | uniformly random values, and |R f lt | ≤ 2q f + q m = q e . The probability that the second condition is satisfied after the i th query is bounded by q p /2 |r| if it a query to Mac K and 2q p /2 |r| if it a query to Mac f K . Hence, the transition is bounded by Game 2: The game is similar to Game 1 but it aborts if a collision is found in the H. In order to construct Game 2, we need an adversary B that simulates the oracles in Table 7 Game 3: This game is the same except that the F f K oracle is replaced with an oracle that is similar except that instead of returning τ , it returns (a, τ ) s.t. either F K (a) = τ or a =⊥, which occurs if the condition in line 5 of F f K of  , τ ), it sets h t = a. If a =⊥, it does not add a corresponding entry to H. It terminates if during any of the verification queries (r j , M j , τ j ), (⋆, H(r j ∥M j )) ∈ H. We call this event HP . Note that if ⋆ ̸ =⊥, then the adversary found the collision and both games will be identical. If ⋆ =⊥, then one of two cases are possible:  τ1 ← MacK 1 (N ∥A∥r∥M ∥|M |)) 32: T 1,f lt ← T 1,f lt ∪ {τ1} 33: C ← KG(FK 2 (τ1 ⊕ ∆)) ⊕ (r)∥M 34: T τ1 ← MacK 1 (N ∥A∥r∥M ∥|M |)) 44: T 1,f lt ← T 1,f lt ∪ {τ1} 45: C ← KG(FK 2 (τ1)) ⊕ r∥M 46: T return ⊥ 8: else 9: return M

D Discussion and Open Issues
The proposed MEM construction is meant for preventing single-fault attacks which it achieves successfully. It has already been argued that most of the two-pass schemes are not suitable in this regard. However, an important question is, how other three-pass options work against faults. In this section, we discuss a few other three-pass schemes in the context of fault attacks. Next, we present some open issues regarding the fault-resilient There can be several basic constructions having more than one pass of encryption and MAC steps. A tempting question is whether or not they all present security against FAs with respect to integrity. Several such potential combinations are described in Fig. 6. It is interesting to observe that most of them are vulnerable to single-fault injections. We restrict our discussions to the schemes which only allow a constant increase in the ciphertext length.
First, let us consider schemes having two encryption operations and one MAC. Two consecutive encryptions (ref. Fig. 6(a),(b)) do not help as together they can be considered as one encryption operation. Fig. 6(c) performs two parallel encryptions with the same key followed by a MAC. While this scheme may look secure until only one of the ciphertexts is corrupted, we note that it depends upon how the MAC is implemented. In the case of parallel implementations, both the ciphertexts will be processed simultaneously. A single fault can corrupt both ciphertexts at this time instant and result in a decoupling attack. If two encryptions are separated by a MAC operation (ref. Fig. 6(d)), it can be considered as "MAC-then-Enc" over an encrypted message. Decoupling attacks take place if the MAC input is corrupted with faults.
Next, we consider cases having two MAC operations. The first two constructions in this class are presented in Fig. 6(e) and (f), where the two MACs operate on the ciphertext, and the concatenation of the ciphertext and the first MAC, respectively. A decoupling fault on the ciphertext at the beginning of the MAC phase enables an attack in this case (truncation attacks are also feasible). A very similar situation arises if the encryption follows the two consecutive MACs 9 . One may abstract these consecutive MACs as a single MAC which converts the schemes to "Encrypt-then-MAC" and "MAC-then-Encrypt" modes, where attacks are clearly feasible 10 .
One may observe that the main issue with the schemes described in the last paragraph is that both MACs operate on the same variables -ciphertext and the first tag (for the second MAC operation). Faulting the ciphertext once, therefore, serves the purpose of the adversary. The third class of schemes performs the MACs on different variables -the plaintext and the ciphertext (or ciphertext + tag). Clearly, MEM is a member of this class. Another potential member is presented in Fig. 6(g) which also prevents the attacks for single fault injection. However, we note that the overall computational complexity of this scheme is the same as MEM -two MAC computations are always required. In this paper, we choose MEM due to its structural simplicity which makes the security proofs simple and enables combination with the PSV encryption. However, the other candidate in this class is also expected to show similar properties. Finally, we note that certain single-pass schemes (computing the encryption and the MAC in one pass) can be converted to a member of this class if they are augmented with another MAC operation at the end. We leave the analysis of the security and computational complexity of such potential schemes as future work.

D.2 Security Against Multiple Faults
Let us consider a scenario where the adversary is allowed to inject at least two faults per encryption query. In this case the adversary can corrupt the computation of MAC K1 for a given message M such that τ 1 ← MAC K1 (M ⊕ ∆). It then injects the same ∆ fault during the computation of MAC K2 resulting in τ 2 ← MAC K2 (C ⊕ ∆||τ 1 ). In case the encryption is linear (such as in PSV), τ 2 ← MAC K2 (M ⊕ Y ⊕ ∆||τ 1 ) where Y is the keystream generated by the encryption function. The adversary, therefore can create a successful forgery by asking for a decryption of the message (τ 1 ||(C ⊕ ∆)||τ 2 ).
While it is evident that the attack works with two faults, it still requires the faults to be equal-valued, which is hard to achieve for many practical implementations. It becomes even more difficult practically as in two different instants, two different variables are to be faulted. However, from a theoretical perspective it is still important to extend the security for multiple fault injections. While MEM allows such extension by interleaving the encryption and MAC blocks with a final MAC at the end, a detailed analysis in this regard is left as a future work.

D.3 Security Against fix Faults
Our proofs for the frMAC security relies upon the assumption that the fault is differential in nature. In the case of fix faults, the following attack can be performed on the frMAC construction.
Consider an adversary who maintains a table U of offline computations for the public hash H used in the frMAC construction. U contains entries of the form ((r j ||M j ||N j ||A j ), h j ). Now if the adversary is capable of doing a fix fault over the full state, then during the frMAC query for any given message (r i ||M i ||N i ||A i ), it can replace the desired hash value h i with h j eventually generating a tag τ j corresponding to (r j ||M j ||N j ||A j ). Now since this message has never been queried to the frMAC oracles, the adversary can use it as a valid forgery. This attack is, however, not possible for differential faults, as the output of the hash is always randomized and remains randomized even after a differential fault injection. Another reason behind not ensuring security against fix model is that fixing 9 We do not describe it here as it is obvious. 10 The attacks can be countered if the implementation performs two separate memory reads for two MAC operations. However, this is more an implementation-level protection than a mode-level solution.
the randomization to a certain value may break the security in several ways. The most obvious impact would be on confidentiality, as repeating the randomness will result in a nonce repetition.
It is worth mentioning that if we only consider the attack on the hash output with fix faults, it is solely an issue for the frMAC construction. In other words, the attack does not apply for the MEM scheme, as the verification will always fail for the second MAC. This is because the second MAC also takes the ciphertext as an input. However, analyzing this scenario formally with frMAC is not straightforward, and we leave it for the future. Currently, we only claim security with respect to differential faults.

D.4 Security against Decryption Faults
In this work, we do not claim security against decryption faults. In fact it is easy to observe that having both encryption and decryption fault can be fatal for security if the decryption fault is injected during the challenge. Considering the integrity scenario, the adversary can first fault any one of the MACs (say MAC 2 ) during the encryption operation as mentioned before. He can then modify the ciphertext offline and use it as a challenge query. While the query is still invalid in this case (as the other MAC still does not match), during the decryption the adversary can fault the other MAC (MAC 1 ) by skipping the final check. This indeed leads to a valid forgery scenario even for our protected constructions. With our current constructions, addressing the decryption faults, therefore, seems non-trivial. We leave it as one of the major open challenges to be addressed in the context of fault-resilient AEADs.

D.5 Security Against Leakage
Our "fr" constructions do not claim security against a scenario where both leakage and faults are present. However, we observe certain similarities between our frMAC construction and the leakage-resilient MACs [BKP + 18], which makes us believe that claiming combined security against both attacks should be feasible. There can be several ways for combining leakage with faults. One possible way is to limit both leakage and faults for non-challenge queries only (the simplest scenario). We believe that proving security for such scenarios should be relatively easier. The situation becomes a bit more complex if we consider both encryption and decryption leakage. Finally, allowing challenge leakage and fault (for both encryption and decryption) is the most general albeit challenging scenario. Allowing challenge leakage may lead to situations where Simple Power Analysis (SPA) attacks might be feasible, and one must ensure that such attacks do not take place. DPA attacks are relatively easier to prevent as the PSV scheme already enjoys some security against them. However, challenge faults can make the scenario even more complex. In the last paragraph, we described the situation with respect to integrity. However, challenge faults in the encryption may also lead to the recovery of the ephemeral key which breaks confidentiality. Formalizing these issues is out-of-the-scope for the current paper and, therefore, left as a future work.

E The Security Game due to [FG20]
The security game for SIV$ in [FG20] is given as follows: Table 11: The Security Game in [FG20] Expt frAE$,b