1. Introduction
Authenticated Encryption
is a symmetric encryption scheme that aims to provide authenticity as well as confidentiality using a single construction. The ongoing CAESAR( Competition for Authenticated Encryption: Security, Applicability, and Robustness) competition [
1] has led to a spur in research and analysis of AE schemes. The idea of
was first introduced by Bellare and Namprempre in 2000 [
2]. Thereafter, several notions of authenticated encryption have emerged over a series of works [
3,
4,
5,
6,
7], which include misuse-resistant
[
8] and
for memory constrained devices [
9,
10].
Due to the ongoing Internet of Things (IoT) revolution, the area of designing lightweight AE schemes has gained momentum. Various lightweight schemes have been proposed in recent past. Some of them include Hummingbird-2 [
11], ALE [
12], ASCON [
13], NORX [
14], Ketje [
15], PFX [
16], IAR-CTR, and IAR-CFB [
17]. Due to the limited storage capabilities of these IoT devices, it has become necessary to design a
scheme which can process long messages even with these memory constraints. Encryption of the message on the fly (i.e., as they arrive) is not an issue in most of the block-cipher-based AE schemes. However, decrypting the ciphertext with limited memory poses a challenge. This is because the sender cannot return decrypted data without first verifying its authenticity, and verifying the authenticity requires the data to be seen in a first pass followed by the actual decryption in the second pass. To avoid the user supplying different data during the authentication and the decryption passes, the device needs to store the data, which may not be feasible for the devices with restricted memory space.
2. Related Work
A few methods for supporting authenticated encryption in a memory constrained scenario have been proposed. However, all of them have restrictions. The first method to support online decryption was proposed by Fouque et al. [
9], who designed a generic construction called “decrypt-then-mask” (DTM). In this method, a pseudorandom number generator is used to mask the plaintext blocks during decryption, and this masked data is released to the receiver. Once the tag gets verified, the cryptographic module returns the PRNG seed used for masking plaintext block to the receiver who can run the same PRNG at her end and unmask the received data. A drawback of this construction is that the decryption device using DTM must implement a pseudorandom number generator, which may not fit on a constrained device. To overcome this problem, a sponge-based construction called sp-AELM was proposed in [
10]. The main idea behind this construction is to store an intermediate state while performing decryption, instead of storing the complete plaintext. Depending on the ciphertext-tag pair passing the validation test, either the saved intermediate state or an invalid symbol is returned to the user. If the verification was correct, then the receiver can recover the plaintext from this intermediate state along with the already available ciphertext. A schematic representation of sp-AELM is shown in
Figure 1. The intermediate state (
) as shown in
Figure 1 is stored and released upon correct verification. For more details of the construction, one can refer to [
10]. However, the main drawback of this scheme is that it is nonce-respecting, and no security guarantees are available in the case of nonce being repeated.
In [
18], Hoang et al. introduced a new notion called OAE2, which supports both online encryption and online decryption. It processes plaintext and ciphertext by partitioning them into a sequence of segments. The size of these segment is decided by the user, and different segments can have different lengths. On an input message
M that gets segmented by a user to
, OAE2 encrypts each segment as soon as it arrives, carrying forward only a constant size state. Thus, input message
M produces a segmented ciphertext
, where
to support expedient verification of what has come so far. Each
must result in an immediate recovery of
without waiting for the availability of
. However, OAE2 is not secure when the nonce repeats. In practice, it is difficult to ensure that nonce never repeats during the operation of a device. Even when it is feasible to generate a unique nonce for each encryption, it is usually through an expensive operation. In other words, implementation of a nonce is non-trivial in practice. Moreover, repeating a nonce in an AE scheme is often devastating [
18].
With the increasing usage of low-cost RFID devices, sensors, and trusted platform modules (TPMs), the need for an AE scheme which can support both the encryption and the decryption functions in a resource-constrained environment is increasing day by day. As already mentioned, existing AE schemes which are suitable for low memory devices are vulnerable to attacks in nonce-repeating scenarios. To overcome this limitation, we propose a new deterministic authenticated encryption (DAE) scheme, which we call dAELM.
The concept of the DAE scheme was introduced by Rogaway and Shrimpton in [
8]. In a DAE scheme, the encryption algorithm deterministically produces a ciphertext for a given key, associated data, and a message. The DAE construction in [
8] was termed “SIV,” which stands for synthetic
. This construction combines a conventional
-based encryption scheme and a pseudorandom function that takes a vector of strings as input. The scheme [
8] first applies a
to associated data and a message to produce an
and uses the resultant
for the encryption scheme. The
construction is proven to be secure, assuming all of its components are secure. However, the SIV construction is not designed for resource-constrained environments; in particular, it may not be suitable for a scenario where the cryptomodule does not have enough space to store the complete message
M during decryption. This memory requirement is because the decryption procedure cannot return the plaintext before successful verification of the tag. In this work, we design an efficient and provably secure DAE scheme that is suitable for memory-constrained cryptomodules.
Our scheme resembles the SIV construction and exploits the existing entropy in messages to omit the overhead for nonces. It also saves bandwidth by eliminating the need to send nonces or random values over the communication channel.
The important feature that makes our construction differ from SIV is the use of the cryptographic module. In dAELM, we assume encryption and decryption takes place inside a cryptographic module which has a secret key embedded on it and has a very limited memory space. The reason behind using the cryptographic module is to increase the security of the key. We don’t want the key to being accessible outside the cryptographic module.
The remainder of the paper is organized as follows.
Section 3 provides definitions that we use in defining the security of the proposed scheme.
Section 4 provides a specification of the proposed scheme dAELM.
Section 5 presents the security proof of the scheme.
Section 6 compares dAELM with other existing schemes.
Section 7 shows the software implementation results of our scheme, followed by a discussion in
Section 8. Finally, we conclude in
Section 9.
5. Security Results for the New Construction dAELM
In this section, we provide the security bounds for the privacy and authenticity of the dAELM construction. We gave the security proof in the ideal cipher model. For writing this proof, we have made an assumption that the underlying MAC in the proposed scheme works in a sequential manner, i.e., as soon as it receives a message block, MAC computation starts. We used a code-based game playing framework introduced by Bellare and Rogaway in [
19] to write the proof. Theorem 1 states the privacy, and Theorem 2 states the authenticity of the proposed construction in the following sections.
5.1. Privacy
Theorem 1. Let be the proposed DAE scheme with an ideal primitive π, that operates on n bits. The adversary A is given access to π and . Then the privacy advantage of adversary A is given bywhere $ is defined in Definition 2 in Section 3, and σ is the maximum number of block calls to π and by encryption and decryption . is the prf advantage and is the related key advantage defined in Definitions 4 and 5 respectively in Section 3. Proof. For the proof of privacy, we use code-based game-playing framework introduced by Bellare and Rogaway in [
19]. We present a set of games from
to
(shown in the appendix in
Figure A1,
Figure A2,
Figure A3,
Figure A4 and
Figure A5). Starting from Game
and modifying it one step at a time, we construct a chain of games
. Here, Game
represents the actual construction, and Game
represents a completely random output. A description of each game is given the following:
: In this game, the encryption oracle perfectly simulates the proposed algorithm, and
oracle simulates the ideal permutation and its inverse. As we will consider block-cipher-based MAC only, here we represent it by
, where
represents internal block-cipher calls on an input message
M.
: Game is the same as except in the block cipher calls during MAC computation and session key generation has been replaced by subroutine g, which generates a random output for a given input. Adversary A cannot make a direct call to the subroutine g.
Let us assume that an adversary
A distinguishes these two games. We build an adversary
against the subroutine
g who uses adversary
A. The process is as shown in appendix in
Figure A6. □
Adversary : In this game, the challenger chooses the key K, and the adversary is provided with the oracles , which are simply a related key oracle and oracle. For each , query adversary internally calls oracle and replies to adversary A with answer .
Finally,
A receives the
pair for his queries either with the related key oracle or a random oracle. This game perfectly simulates the game
if
uses the related key oracle. Therefore, we have
If adversary
uses a random oracle, then this game perfectly simulates game
.
Lemma 1. For any adversary A with q queries, there exists an adversary such that
where
and
are shown in
Figure A1, and
is defined in
Figure A6.
can make only two queries:
and
.
, where
and
.
: Game
and
are exactly the same. Therefore,
: Game
and
differ only when a bad event occurs, otherwise, in absence of a bad event, both games are the same.
A bad event occurs when an input to
and
collide with the elements in set
. Therefore, the probability of a bad event will be equal to the probability of collision in
and
. Hence, the probability difference between
and
is
: Games and are exactly the same. Therefore,
: Game
and
are identical. In Game
, the
oracle itself simulates the behavior of
, so it becomes independent of
. Hence, Games
and
are the same from an adversarial point of view.
: Games and are the same except on Line 3.
Let us assume that an adversary
A distinguishes these two games. We build an adversary
D against the MAC oracle who uses adversary
A. The process is as shown in appendix in
Figure A7.
Adversary : In this game, the challenger chooses the key K, and the adversary is provided with the oracles , which is either a or oracle. For each , query adversary D internally calls oracle and replies to adversary A with answer .
Finally,
A receives the
pair for his queries either with MAC oracle or random oracle. This game perfectly simulates Game
if
D uses the MAC oracle. Therefore, we have
If adversary
D uses a random oracle, then this game perfectly simulates Game
.
Lemma 2. For any adversary A, there exists an adversary such that : In Game
, each ciphertext block is generated randomly and the concatenated ciphertext is returned to an adversary. Similarly, a tag is also generated randomly. However, in Game
, ciphertext and tag of the desired length is selected as a random string and returned to an adversary. This move from
to
does not make any difference, as in both games output is generated as a completely random value. Therefore,
Finally, by using the fundamental lemma of the game-based framework,
5.2. Authenticity
In this section, we analyze the security of the authenticity of the tag produced in our scheme. The forgery of an AE scheme is defined as the ability of an adversary A to generate a valid tuple, without directly querying it to the encryption oracle. The adversary is allowed to make a limited number of queries to encryption, decryption, and the and oracles. For an AE scheme, we say the adversary A is successful in forging if it outputs an tuple, where and adversary A has not asked fora query that resulted in response .
Let be the forging experiment for a given scheme . Then the forging experiment is defined as follows:
Adversary A can query encryption oracle and decryption oracle at most times, respectively.
All the query responses of encryption oracle are stored in a set, say, R. This set contains an tuple, which has been returned by an encryption query.
If adversary A is able to generate a new pair ∉R that produces valid message M, then he wins and output is 1; otherwise, output is 0, after trying number of queries.
We say the adversary wins, i.e., he succeeds in creating a forgery if
. Therefore, the advantage of an adversary in forging the scheme is defined as
Suppose an adversary makes a
number of encryption queries and stores a result in set
R that consists of tuple
, where
. Now his goal is to generate a new tuple
, which generates a valid
on verification.
Theorem 2. Let be the proposed authenticated encryption scheme with an ideal primitive (π) that operate on n bits. The adversary A is given access to encryption oracle , decryption oracle , and the π and oracles. Then is forgeable with the probabilitywhere σ is a maximum number of blocks to by encryption oracle , and decryption oracle and is the number of queries to the decryption oracle. is the related key advantage, and is the prf advantage. Proof. To give authenticity proof, we first use the same sequence of games (–) as in privacy proof with an additional decryption oracle. This sequence of games transforms the MAC into a pseudorandom function, and the block cipher calls into ideal permutation by considering their respective advantages. Here, we are directly using the advantages of games from the above privacy proof. After these transformations, we do further analysis. □
There are two possible cases to consider:
An adversary generates a forgery pair which produces a valid such that ; i.e., he chooses a new () pair, which corresponds to the same tag that has been previously used for some other , where . T and will correspond to the same session key for a given key K. This same will result in the same output for further block cipher calls. This can be divided into cases.
- (a)
: In this case, necessarily . As all block cipher outputs are the same, XORing them with will produce the same . For a successful forgery, we need at least one parameter to be different in the tuple. Since and , should be different from . Therefore, the probability of happening this case will be same as the birthday bound on the MAC output.
- (b)
: In this case, for , will result in . Therefore, the probability of this case will again become the same as the birthday bound on the MAC output.
Therefore, the overall probability of this case will be given by .
An adversary generates a forgery pair , where is new, i.e. . This case is further possible in two scenarios:
- (a)
An adversary is able to guess the key K correctly; i.e. he has access to the system and can generate any number of valid queries. The probability of this case will be equivalent to guessing the key, which is .
- (b)
Suppose adversary guesses the tag correctly for a given key K and pair. Then, for further calculations of ciphertext, he also needs to guess the session key . Then only he can generate the forgery. Therefore, the probability of happening this case will be the product of the probability of guessing the tag and session key that is equal to .
Therefore, the overall probability of this case will be .
Hence, the overall advantage of authenticity is given as
6. Comparison
In
Table 1, we present a comparison of the newly proposed scheme dAELM with existing schemes sp-AELM [
10], OAE2 [
18], and SIV [
8]. Among these four schemes, sp-AELM and OAE2 are randomized schemes requiring nonces to produce the randomness. The remaining two schemes, the SIV and the dAELM are deterministic. They use the available message entropy to omit the overhead of a nonce. Schemes sp-AELM and OAE2 support online encryption, whereas SIV and dAELM do not provide online encryption features due to their misuse-resistant behavior. As mentioned in [
18], misuse-resistant AE schemes cannot be online since every bit of the ciphertext must depend on every bit of plaintext in a misuse-resistant scheme. This ensures that one cannot output the first bit of a ciphertext before reading the last bit of the plaintext. Among the four schemes, only OAE2 supports online decryption at the cost of generating a tag for every individual segment of the plaintext. All these schemes provide low memory support, except SIV. Further, sp-AELM and OAE2 are vulnerable to a nonce-repeating attack, while this is not the case with SIV and dAELM.
OAE2 operates by dividing the plaintext into variable size segments of user-determined lengths, whereas sp-AELM, SIV, and dAELM process the plaintext into fixed size blocks of fixed lengths. In sp-AELM, SIV, and dAELM, the ciphertext length is a sum of plaintext and tag length (), whereas in the OAE2 scheme the tag is generated for each segment.
7. Software Implementation
We implemented the proposed scheme dAELM in ATmega128 microcontroller and compared the performance against an existing SIV scheme. ATmega128 microcontroller is an 8-bit AVR RISC-based microcontroller, which combines 128 KB of programmable flash memory, 4 KB SRAM, and a 4 KB EEPROM. The device supports throughput of 16 MIPS at 16 MHz and operates at 4.5–5.5 volts. We used the C language for programming ATmega 128. For the implementation of dAELM and SIV, we used the AES-128 as an underlying block cipher and HMACSHA1 as an underlying MAC function. We executed the experiments for the messages of various length and analyzed how much memory is taken by the program performing encryption and decryption.
Pseudocode of decryption is shown in Algorithms 3 and 4. Three additional functions are used for computing the HMACSHA1 tag without describing the details due to its wide compatibility. HMACSHA1.INIT() initializes an HMACSHA1 structure to use the hash function and the key. HMACSHA1.UPDATE() is repeatedly called with chunks of the messages to be authenticated. HMACSHA1.FINAL() completes the HMACSHA1 operation after the last message is processed and returns the message authentication code. For the decryption process, instead of storing the entire decrypted message after decrypting the entire ciphertext, it decrypts the four blocks (each of 128 bit), and HMACSHA1.UPDATE() takes them as an input repeatedly.
Figure 6 shows the memory usage during the decryption process for the various messages lengths. For the messages of length less than 512 bits, memory required by the decryption process for dAELM is a bit more than SIV due to one extra AES call for session key generation. This difference in memory usage of only 512 bits is because of the consideration of HMAC-SHA1 in our implementation, which process a message in 512 bit blocks. After 512 bits, memory usage becomes constant for dAELM, regardless of message length, whereas in SIV, the memory usage depends on the length of a message.
Algorithm 3: Decryption |
|
Algorithm 4: |
where for Return M |
In general, the memory required by dAELM is , where and is a length of a key and a session key, respectively, is the length of an associated data, and is the block size of the message processed in the MAC. For example, is 512 bits in the case of HMAC-SHA1. However, the memory required by SIV is , where , and represent the length of a key, associated data, and a message, respectively. In other words, memory usage for dAELM depends on the block size of MAC, which is constant, whereas, for SIV, it depends on the message length. If we consider a MAC with a small block size, then dAELM will perform better than SIV, even for short messages.
8. Discussion
In this work, our proposed scheme targets the devices, which have a limited amount of memory and are incapable of processing the large message. These memory-constrained devices include, in tiny IoT devices, cryptomodules such as TPMs (trusted platform modules), which are used in laptops, tablets, smartphones, set-top-boxs, ATM machines, etc. A cryptomodule is basically a secure cryptoprocessor used for carrying out the specific cryptographic operations and storing secret keys. These cryptomodules usually have a storage capacity of only a few bytes, which may not be sufficient to process long messages. For example, ATMELAT97SC3204 is a TPM that has only 1732 bytes of storage for the user-defined data. Similarly, these small IoT devices also have a limited amount of storage. Under these memory constraints, it becomes impossible to process a large data in one go. Hence, our proposed scheme provides a solution for all those memory-constrained devices to process a long message.