Embedded LUKS (E-LUKS): A Hardware Solution to IoT Security

: The Internet of Things (IoT) security is one of the most important issues developers have to face. Data tampering must be prevented in IoT devices and some or all of the conﬁdentiality, integrity, and authenticity of sensible data ﬁles must be assured in most practical IoT applications, especially when data are stored in removable devices such as microSD cards, which is very common. Software solutions are usually applied, but their effectiveness is limited due to the reduced resources available in IoT systems. This paper introduces a hardware-based security framework for IoT devices (Embedded LUKS) similar to the Linux Uniﬁed Key Setup (LUKS) solution used in Linux systems to encrypt data partitions. Embedded LUKS (E-LUKS) extends the LUKS capabilities by adding integrity and authentication methods, in addition to the conﬁdentiality already provided by LUKS. E-LUKS uses state-of-the-art encryption and hash algorithms such as PRESENT and SPONGENT. Both are recognized as adequate solutions for IoT devices being PRESENT incorporated in the ISO/IEC 29192-2:2019 for lightweight block ciphers. E-LUKS has been implemented in modern XC7Z020 FPGA chips, resulting in a smaller hardware footprint compared to previous LUKS hardware implementations, a footprint of about a 10% of these LUKS implementations, making E-LUKS a great alternative to provide Full Disk Encryption (FDE) alongside authentication to a wide range of IoT devices.


Introduction
The Internet of Things (IoT) industry has grown steadily in the last few years. Many facts indicate that this growth is an upward trend [1], with IoT data traffic expected to reach around 2000 petabytes of information by 2024 [2]. The use of IoT devices has reached many fields such as industrial production [3], health care [4], or quality-of-life-related devices [5]. Its implementations in our homes and personal environments has had a great impact on many daily life processes [6,7]. However, IoT is still a recent technology in which numerous devices with low resources share a large amount of personal and sensible data, making data security one of the major issues of IoT. The security problem in IoT has been addressed by many authors, mainly from the perspective of data communication between nodes [8,9]. However, the security of the data stored internally by these devices should also be addressed.
Currently, many IoT nodes based on complex embedded systems use a Flash memory as their main storage for user applications. Some of these systems can expand their storage by adding external Flash mass storage devices such as an SD card. If the application requires some kind of confidentiality in the stored data, some type of data encryption must be used. Data encryption can be implemented at the operating system (OS) level by using dedicated libraries and factory software in order to encrypt single files or the complete block device that holds the file system. Solutions such as Bitlocker from Microsoft, FileVault from Apple, or VeraCrypt, among others, can be used at the user level by running software tools in the OS. But these kinds of solution have to face challenges such as key storage, key change, and interoperability with other systems; for example, when the Flash storage device is removable and needs to be accessed from a desktop computer.
In any case, the presence and evolution of IoT security must be studied in order to use the available knowledge. Only in doing so can the way new devices and application areas evolve be decided [10][11][12][13].
Implementing file encryption is not an option for many IoT devices. On the contrary, block device encryption adds a new layer between the physical device and the read/write device operations. This is much more resource-friendly and allows IoT applications to access encrypted memory in a transparent way. It can pose a solution even for a very simple IoT device that does not run an OS but a standalone application. In fact, there are already solutions that implement this kind of Full Disk Encryption (FDE), such as the Linux Unified Key System (LUKS) [14].
Another important aspect of IoT security is that IoT nodes must be robust against the use of reverse engineering [15,16] and/or malware such as the Mirai botnet [17]. Thus, it is necessary to ensure the integrity and authenticity of user data in addition to its confidentiality.
In this paper, a lightweight IoT protocol based on LUKS is introduced, which provides, on top of the FDE of LUKS, both the integrity, and authenticity of the user data. This protocol has been called Embedded LUKS (E-LUKS) and it has been especially tailored to allow an efficient hardware implementation, making possible the implementation of a small footprint hardware module that is able to read/write into a final storage device. In this sense, the hardware E-LUKS module implemented will act as a transparent layer between embedded systems and their storage memories.
This paper has been organized as follows. First, the Related Work section describes other hardware solutions that can also provide security of the data. Then, in the Section titled Linux Unified Key Setup, the LUKS specification used as blueprints for the proposed solution, necessary to understand it, is described. Next, the section named Embedded LUKS details the proposed solution and its changes compared to LUKS, finishing with the E-LUKS core hardware implementation. The Results section follows, in which the experiment conducted to verify the proposed solution is represented, displaying the execution time of the system with E-LUKS and without it. Furthermore, this section also proves the advantages of E-LUKS via the comparison, and describes the subsequent analysis of the employ of resources between E-LUKS and the alternatives presented in the Related Work section. Lastly, a brief evaluation of the proposed solution is provided in Conclusions.

Related Work
LUKS is a block-device encryption specification that aims to be implemented in software, although there are some hardware implementations on FPGA chips as well [18,19]. In Reference [18], the implementation is focused on an energy-efficient LUKS design that can compete in terms of speed against software solutions on higher-end devices. Alternatively, there is another LUKS implementation, which achieves high performance due to a pipeline implementation, proposed in [19]. These designs are not suited for resource constrained devices, since both use multiple instances of a cryptographic algorithm implementation in order to increase the performance at the expense of additional FPGA resources.
Other hardware-solutions such as Sancus [20] are specifically designed for resource constrained devices. Sancus is an open-source solution that focuses on the integrity and authenticity of the data. Its objective is to assure that each file or program on the memory device is untampered and authenticated without trusting any infrastructural software. For this purpose, the device uses a symmetric key to assure the integrity and authenticity of each file independently by means of a Key Derivation Function (KDF) implemented in the hardware. The KDF, together with the device key and file parameters, such as its contents and location on the memory device, generates a digest for each file.
To isolate each in the device; Sancus uses a variation of the program-counter based memory access control [21]. It allows access to the protected data of the file if and only if the program counter is in its text section. In addition, the text section of a file can only be executed if the program counter jumps to its defined entry point. A call to another file can only be executed if a digest of the file to be accessed has been previously deployed in the memory device.
Based on Sancus, several additional solutions have appeared. One of them is Soteria [22], which adds confidentiality to the previous solution, and a specific software loader module. This module is responsible for the confidentiality of the other modules in the node.
Other solutions are those that implement confidentiality on a System-on-Chip (SoC) FPGA RAM memory. In Reference [23], the authors present a transparent encryption/decryption hardware module that uses block ciphers to provide confidentiality of the data. It is also able to achieve authenticity of the data by implementing a Tamper Evident Counter (TEC) tree with a nonce value as a root stored on-chip. This TEC serves to provide a nonce value, which is used only when the block cipher is the Authenticated Encryption (AE) cipher Ascon. Another proposed solution is Atlas [24], which offers confidentiality alone. The idea of Atlas is to use the entry point of the file or code as the Initialization Vector (IV) employed in the encryption/decryption of that file. Currently, the lightweight SIMON block cipher is used.
The proposed solution in this paper, E-LUKS, provides FDE as the LUKS solutions do in [18,19]. Nevertheless, as opposed to LUKS, E-LUKS has been designed for constrained resources devices and also supports data authentication in addition to confidentiality. While the solutions based on Sancus [20] require modifying the processor itself and its own firmware, the E-LUKS solution is independent of the processor and, in fact, it can be used in systems with no processor at all. Sancus-based solutions allow for the isolation of different programs in the external RAM memory of the device. In contrast, E-LUKS uses external Flash storage, which may be present as the main or complementary data storage of the system, such as a microSD card, which is usually more vulnerable to data tampering. The solutions in [23] and Atlas [24] also focus on securing the RAM memory of the system. Atlas implements instructions for the selected processor but does not support the integrity and authentication of the data. Finally, the work presented in [23] depends only on the bus interfaces of the system. However, to allow integrity and authentication of the data, it requires part of the TEC tree in the memory alongside the data, excluding the root nodes, which may consume a significant amount of memory resources.

Linux Unified Key Setup
Linux Unified Key Setup (LUKS) is a specification intended to standardize cryptographic key setup for data storage encryption. LUKS was introduced in 2005, and a new version (LUKS2) [25] was released in 2018. This last version extends the previous one, taking all its basic concepts as blueprints. The structure and operations described below are taken from LUKS1.
LUKS performs full user data encryption using a master key that is itself encrypted and stored in front of the encrypted data. The master key can be stored multiple times using different user passwords, allowing many users to have access to the encrypted data.
An LUKS formatted block device consists of two parts: (1) a small unencrypted part that consists of an LUKS header followed by several slots for each granted user; (2) an encrypted part starting with eight slots, each one containing the encrypted master key for one possible user, followed by the user data. All encryption is performed using symmetric cryptography.
To retrieve the encrypted data, a user must unlock one of the eight slots and decrypt the corresponding encrypted master key. A formatted LUKS device must have at least one active slot with the corresponding encrypted master key.

Cryptography
The type of cryptography used is a key factor in any secure specification. Modern cryptography is mainly supported by ciphering algorithms and cryptographic hash functions. The LUKS specification allows for the use of a variety of block ciphers and hash functions. Possible block ciphers that can be used with LUKS are shown in Table 1, together with supported modes, key lengths, and block lengths. Supported hash functions are listed in Table 2. In addition, LUKS uses Password-Based Key Derivation Function 2 (PBKDF2) as the Key Derivation Function (KDF), following the recommendations of RFC8018 [26].

Linux Unified Key Setup Internal Layout
As previously mentioned, the layout of an LUKS block device is divided into two parts, one is unencrypted and the other one is encrypted, as depicted in Figure 1. The unencrypted part is called the LUKS partition header (LUKS phdr). It starts at the beginning of the block device and holds two types of blocks: the header and various Key Slots (KS x ). The encrypted part contains two types of blocks as well: Key Materials (KM x ) blocks and User Data blocks. The header identifies the block device as an LUKS partition and stores information about the master key, together with information about the cryptographic algorithms selected in the LUKS block device. Table 3 summarizes the fields of the phdr. The Key Slots (KS x ) have information about the user key and the parameters to recover the master key. The 8 KS x allow up to eight users to access the master key, each one with a different personal user password. Each of the KS x blocks (x = 1, 2, . . . , 8) points to a KM x block, which is the encrypted master key that can only be recovered using the corresponding personal user password. Table 4 shows all fields of a KS x . Following the KM x blocks are the User Data, which are encrypted with the master key.

Operations
LUKS devices are managed using four types of operation: initialisation, add new password, master key recover, and password revocation. By using these functions, LUKS is able to store and retrieve the necessary master key to perform any operation on disk. These functions are summarized below.

Initialisation
The initialisation operation consists of formatting the block device according to the LUKS layout. This operation requires the following parameters: the master key, the salt for the KDF (mk-digest-salt), and a number of iterations (mk-digest-iter). These parameters are auto-generated by the software that performs the LUKS formatting. In the process, a new LUKS phdr is written in the block device, followed by KS x . It is also mandatory to specify which cryptographic algorithms (block cipher and hash function) are selected to be used on the block device. To complete the LUKS phdr, the master key is used as a parameter, along with the salt and the number of iterations, to generate a digest (mk-digest). Lastly, the LUKS format must store the encrypted master key in at least one KM x . Because the master key is encrypted by a user key, a new user password needs to be added in the way described below.

Add New Password
This operation consists of adding a new password for a user, using one of the eight KS x available. When the block device is being formatted, the unencrypted master key is available from the initialisation operation. On the contrary, for an already LUKS-formatted device, the master key is retrieved by the Master Key Recovery operation. The Add New Password operation begins with the user providing a new user password. After that, it generates random values from the salt and iteration count for the KS x and stores them.
Once the values are generated, the KDF takes the new password along with the salt and the iteration count. The master key is then processed by an anti-forensic splitter, generating a new derived key. This derived key is encrypted using the KDF output as the key for the cipher. Then, the encrypted password is stored on the device as KM x for later use.

Master Key Recovery
The third operation is to recover the master key from a KM x . This operation consists of decrypting the encrypted master key for two purposes: access to the encrypted user data or to change a user password by using the Add New Password operation. The Master Key Recovery operation requires the user password associated with the KS x . It uses the KS x salt and iteration count values, along with the user password, as parameters for the KDF. Next, the KM x is recovered from the storage device and is decrypted using the KDF output as the cipher key. Then, the decrypted result is processed by an anti-forensic merge, generating a new candidate key. This candidate key, the mk-digest-salt and the mk-digest-iter are passed as parameters to the KDF. Finally, the KDF output is compared with the mk-digest from the header, and if both values match, the candidate key is returned.

Password Revocation
The last operation is the password revocation for a selected key slot. This operation consists of deleting the selected KM x and setting the activate field of the KS x to inactive.

Embedded LUKS
Embedded LUKS (E-LUKS) is a new proposal to bring LUKS to devices with limited resources, such as IoT devices. It can be applied in scenarios where the security of the local data is an issue, such as devices in public locations, where an attacker has easy access to the device. E-LUKS performs FDE of the block device. To perform this task, it requires a master key, which is used to create the user keys, as well as in LUKS. The difference being that E-LUKS allows integrity and authentication, on top of confidentiality, of the user data.
Another major aspect to consider is the cryptographic algorithm used for small devices with limited resources. In the last few years, a growing trend of low footprints cryptographic algorithms has emerged for these types of devices. Although these algorithms are designed mainly to optimize the use of internal device resources, at the same time, they also decrease the security level. Nevertheless, the security provided by these algorithms is enough and presents more advantages than disadvantages.

E-LUKS Internal Layout
The E-LUKS layout is heavily based on LUKS. In Figure 2, a diagram of the layout is shown. However, in E-LUKS, the Key Material (KM x ) is integrated into the Key Slot (KS x ). In addition, some parts present differences in their number of fields, as can be seen in Tables 5 and 6 with respect to the E-LUKS header and KS x . Another characteristic of E-LUKS is that the E-LUKS header and the KS x must be located in the first 512 bytes of the memory. This limitation is due to the fact that embedded devices usually have an external flash memory, such as a microSD card, as their main storage. These flash memories are typically divided into blocks of 512 bytes and, to facilitate the HDL design, it has been decided that the first block of the memory contains all the E-LUKS related data, while the rest of the memory is reserved for the user encrypted data. The fields below are taken by selecting the PRESENT cipher with an 80-bit key and, as a hash function, the same as that used in the KDF and the HMAC, the SPONGENT-88. With these requirements, the E-LUKS header takes 52 bytes, and each KS x takes 40 bytes. Therefore, the maximum number of KS x is up to 11. user data ks 1 header Unencrypted data (E-LUKS phdr) ks 2 ks 3 ks 4 ks 5 ks 6 ks 7 ks 8 ks 9 ks 10 Encrypted data ks x : key slot X ks 11 user data user data ...

Cryptographic Algorithms
The cryptography used in ELUKS inherits from LUKS the way to store the master key. In this sense, ELUKS uses a block cipher, a HASH function, and a KDF. The main feature of E-LUKS is the fact that it uses cryptographic algorithms designed for resource constrained devices. To simplify the design and standardize the internal layout, it has been decided that there will be only one choice for each of the algorithms (block cipher, hash function, HMAC, and KDF). These algorithms are introduced in the following sections.

PRESENT
PRESENT is a block cipher optimized for low resource usage that also has low power consumption. In recent years, multiple implementations of this cipher have appeared with different hardware architectures to boost certain aspects [35]. However, even though there are multiple alternatives for PRESENT, this work has implemented it as was originally presented in [36]. PRESENT is a substitution-permutation network (SP-network) of 31 rounds of encryption-decryption, all of them with the same structure, which uses a block length of 64 bits and allows keys of 80 bits and 128 bits. Its pseudocode is shown in Algorithm 1.
• sBoxLayer: Is a function with an input of 64 bits that returns an output of 64 bits. Internally, the input data are divided into 16 groups of 4 bits, such that . . , w 0 . Each group (w i ) is then processed by Sboxes, an S-box S transforms 4-bit input into 4-bit output such that S : F 4 2 → F 4 2 . Table 7 shows all possible S-boxes results. Finally, the sBoxLayer and the result are calculated as follows: CTR mode (counter mode). In this mode, the cipher behaves as a stream cipher, thus being used to generate a keystream s. In the equation below, the CTR mode is described where m i is the i-th 64-bit unencrypted block and c i is the i-th encrypted block. In this mode, x 1 begins at a random value IV (Initialization Vector) and behaves as a counter. Therefore, this mode allows each encrypted block to be different, regardless of its data.

SPONGENT
SPONGENT [37] is a hash function based on the sponge architecture and the use of the permutation operation introduced in PRESENT.
The sponge architecture is an iterative design composed of stages. It takes an arbitrary length of input data and generates an output whose length is related to the number of stages in the architecture. The parameters and operations are the following: • r: bits length of the ratio. • c: bits length of the capacity. • R: number of rounds that take place in each stage. • n: bits length for the output of the sponge architecture. • b: bits length for the internal state, which is b = r + c. • π b : represents the function for the permutation operation. This function π b (x) = y such that x, y ∈ 0, 1 b . In addition, this function is the main operation in each stage of the sponge architecture.
Once the parameters are defined, it is necessary to describe the three phases of the sponge architecture. SPONGENT offers five different variants to reach different levels of security. Variants, as well as the value of the parameters, are shown in Table 8. PRESENT Permutation π b The permutation operation π b is the main part of the design. The behaviour of the function can be defined as follows: The sBoxLayer b and pLayer b functions are based on their homology described in the PRESENT section. The main difference is that these functions are modified to accept either input or output of b-bit. In the case of the sBoxLayer b , more S-boxes have been used in parallel. Thus, pLayer b is defined as: Regarding the lCounter b , it is an LFSR of log 2 (R)-bits. This register is activated in each iteration i = 1, 2, . . . , R. It uses different irreducible polynomials as coefficients and different initial values for each variant of SPONGENT, as shown in Table 9. Table 9. lCounter b values.

Variant Polynomial Initial Value
SPONGENT-88 SPONGENT-160 SPONGENT-224 SPONGENT-256 The hash function is used in E-LUKS as part of the HMAC construction. An HMAC allows both: integrity and authentication. The HMAC used was presented in [38] with the following definition: First, the key K is XORed with a repetitive pattern of bits called ipad. Then, m 0 is calculated as the hash of the input of the HMAC with a suffix of the XORed key. ipad = 0x33, 0x33, . . . , 0x33 After that, it proceeds to calculate the output of the HMAC. To this end, another repetitive pattern of bits called opad is XORed with the key and is used as a suffix with the previous hash output m 0 . These data are then passed to the hash function to get the output: opad = 0x5C, 0x5C, . . . , 0x5C

KDF
The KDF used in E-LUKS is based on the PBKDF2, the KDF used in LUKS. Therefore, this function will be explained.
PBKDF2(P, S, c, dkLen) contains the following parameters: • P: the master key. First, PBKDF2 checks that the desired derived key is in the range in which hLen represents the output length of the hash function.
Then, it calculates the number of blocks of length hLen used in the derivated key. This value is stored and, for the last block, in the case of a non-integer result dividing by hLen, the number of bytes is also stored.
For each of the blocks of length hLen, T i , the F function will be applied, which takes P, S, c and the index block as a parameter.
The function F is the XOR of the first c iterations of the HMAC function H. F(P, S, c, i) =U 1 ⊕ U 2 ⊕ · · · ⊕ U c (12) . . .
Lastly, all the calculated blocks are concatenated in order to generate the derivated key DK.
However, this construction could be improved as shown in [39]. This has been the alternative chosen for E-LUKS.
In this construction, instead of an HMAC, a hash function was used for the F function. In addition, the parameter c is passed as a parameter for the hash function.
Here, H c represents the hash function executed c times as follows: . . . y c =H(y c−1 ).

Operations
Similarly to the previous subsection, E-LUKS has the same operations as LUKS, adding a new one that allows the integrity and authentication of the user data.

Initialisation
The main difference in this operation compared to LUKS is the inclusion of integrity and authentication of the user data. Therefore, to allow integrity and authentication, this stage requires the calculation of the HMAC of all the encrypted user data. Below is a brief description of the whole operation.
The initialisation operation requires the master key, mk-digest-iter, mk-digest-salt and mk-IV. It can be divided into three parts; the first one populates the simple fields of the E-LUKS header as: the random value for the salt of the KDF, the constant value of the magic field, the count value, and the initial value. The second part generates the KDF of the master key with the salt and count parameters. Lastly, the third part generates the HMAC digest of all the encrypted user data.

Add New Password
The most significant change in this operation with respect to LUKS is the exclusion of the anti-forensic functions. Therefore, there is no need to calculate the split key.
The Add New Password operation requires the master key, the count iteration value for the KS x , and the user key. This operation begins by setting the selected KS x to activate. Doing so, random values start to generate for the salt and Initial Value fields. Once all the values have been generated for the KS x , the user key is processed by the KDF given the user key digest. Then, the master key will be divided into chunks the size of the block cipher size. Each chunk will be encrypted with the user key digest and is concatenated to create the KM x .

Master Key Recovery
It is similar to the Add New Password operation; the main difference is the exclusion of the anti-forensic functions.
The Master Key Recovery operation requires the user key. First of all, it performs a search for each KS x . If the activate field is set, then it will create the user key digest with the KDF, using the parameters of the KS x . Next, it divides the encrypted password into chunks the size of the block cipher; each chunk is decrypted using the user key digest, and each part is concatenated into the master key candidate. This master key candidate is then processed by the KDF with the parameters from the E-LUKS header and is compared with the mk-digest. If both values are equal, then the master key candidate is returned.

HMAC Verification
The HMAC verification is a new operation for E-LUKS, which requires the master key. Once the HMAC is initialised with the master key, the user data are then divided into chunks and are fed to the HMAC. When all the data have been fed, the HMAC generates a digest, which is compared with the mk-hmac stored in the E-LUKS header.
This operation allows for the integrity and authentication of the user data. Therefore, it brings out the possibility of creating a secure boot for the device in which E-LUKS is running.

Password Revocation
The Password Revocation is the last operation, an exact duplicate of its counterpart in LUKS.

Comparison between LUKS and E-LUKS
This subsection shows the difference between LUKS and E-LUKS, as shown in Table 10. Before starting to describe the hardware implementation of E-LUKS, Table 11 shows the key differences between LUKS and E-LUKS. LUKS allows more security against bruteforce attacks, but lacks integrity and authentication of the data. Therefore, while LUKS cannot provide a mechanism of secure boot, it is possible for E-LUKS.

Hardware Implementation
E-LUKS has been implemented in SystemVerilog, the schematic of which is shown in Figure 3. The E-LUKS core has four main parts, three of them related to the aforementioned cryptographic algorithms described earlier: the PRESENT cipher core, the HMAC based on SPONGENT, and the KDF. The last part is the control module, a finite state machine, which implements the Master Key Recovery operation and the HMAC verification operation.
In addition, the control module has an SPI interface to communicate with the formatted E-LUKS memory.  Figure 3. E-LUKS core schematic.
The flow chart that represents the Master Key Recovery operation performed by the control module is shown in Figure 4.
The operation begins with the reset signal. After that, the control module resets all the internal counters and registers and proceeds to read from the memory the first block of the E-LUKS partition. Then, it stores all the fields from the E-LUKS header. Although some of the fields are not used in this operation, they will be used later by other operations (HMAC verification or reading the encrypted user data from the E-LUKS partition). After that, the magic field is compared with the E-LUKS_ID, which identifies it as an E-LUKS partition. However, in another case, it reaches the error state from which the error signal is raised, and finishing the operation. Following the operation, the control module proceeds to read each key slot KS x in order, checking for each one if the activate field is set. If all KS x are deactivated, the control module goes to the error state. If the KS x is activated, it continues to decrypt the pwd-encrypted field. First, it must calculate the key to decrypt, done by calculating the KDF of the user_psw, provided as an input of the E-LUKS core. In addition, the KDF takes the salt and iterations fields related to the KS x . Once with the key, it is able to decrypt the pwd-encryted getting a master key candidate. To verify this candidate, it generates the KDF of the candidate with the fields mk-digest-salt and mk-digest-iter. Finally, the calculated digest is compared against the field mk-digest. If both values are equal, then the candidate is the master key and is returned. Otherwise, the control module goes to the error state.
Regarding the HMAC verification operation, this is only performed if the hmac-enable signal is activated. A flow chart of this operation is shown in Figure 5. The HMAC verification operation takes place after a successful Master Key Recovery operation. Therefore, it is assumed that the required fields from the E-LUKS phdr have been precisely stored. The operation begins by initializing the HMAC with the master key. Then, it reads the encrypted user data that begins in the second block of the E-LUKS partition. It reads all data byte by byte, each of which feeds the HMAC. When all user data is processed, the control module calculates the HMAC output. Finally, the digest generated by the HMAC is compared to the mk-hmac field. If both values are equal, then the user data are proven to be authenticated and unmodified. Otherwise, the control module goes to the error state described earlier in the Master Key Recovery operation.

Results
In order to validate the proposed solution, an experiment has been conducted that provides a functional verification of E-LUKS and execution times with and without it. These resource results are then compared to the previous solution shown in Related Work.
The experiment has been designed using the SystemVerilog Hardware Description Language (HDL) and is implemented on a Nexys4DDR development board from Digilent Inc. that has an XC7A100T FPGA chip from Xilinx Inc. [40]. The selected development environment is Vivado 2020.1 from Xilinx Inc. [41]. This board features a microSD card slot.
A microSD card is the system's storage device. It is divided into two parts: the first part contains the E-LUKS partition, which stores a target file as the encrypted user data, and the second part contains the unencrypted target file.
The main goal of the experiment is to obtain the execution times when reading the target file in different ways: (1) From inside an E-LUKS partition. It can be done either without the HMAC verification as with LUKS or with the HMAC verification to provide authentication and integrity of the data; (2) From the unencrypted memory area.
To perform the experiment, three different and independent tasks have been developed: 1.
Functional verification: The first task begins by reading the unencrypted target file and storing it in a block RAM in the FPGA. Once the unencrypted target file is read, the E-LUKS partition is accessed in order to get the encrypted target file. The E-LUKS can be accessed with HMAC verification or not, depending on the hmac-enable signal attached to any switch from the board. For its part, the encrypted file is read and compared with the previously stored values. If all data are equal, then the functional verification is correct.

2.
Reading the unencrypted target file: This task reads the unencrypted target file from the microSD card. The duration of this process is measured with an internal counter that gives a precise execution time for this task. The results are displayed in a 7segments display on the board. This execution time excludes the initialisation time for the microSD card, which takes around 250 ms.

3.
Reading the target file from the E-LUKS partition: This last task retrieves the target file from the E-LUKS partition both with or without HMAC verification, depending on the value of hmac-enable. It starts by reading the phdr from the microSD card to get the master key. Once the master key is retrieved, it is stored in a volatile memory accessible only to the E-LUKS core. Thus, it is only necessary to get the master key once. As in the previous task, an internal counter is used to calculate the execution time and display it on a 7-segments display skipping the microSD card initialisation time.
All the source code is available on the authors' github [42]. The files are ready to be used with the Fusesoc tool [43], which allows the reuse of previous designs and facilitates the creation of the bitfile. This repository has three folders: 1.
hdl: Contains the SystemVerilog implementation of the E-LUKS core. In addition, it also holds the core in a format that can be used with the Fusesoc tool.

2.
examples: Contains the files needed to replicate the proposed experiment. The files needed to create the bitfile are in the fusesoc folder. Whereas the file create_partition.py in the python folder is a script that generates the layout needed in this experiment for a microSD card. 3.
cores: Contains a list of Fusesoc cores used in this experiment taken from previous designs.
In the first task, the file from the unencrypted partition is read and compared with the file read from the E-LUKS encrypted partition, both with HMAC and without HMAC verification. If the comparison is successful, E-LUKS is proven to be functionally valid.
The second and third tasks are intended to obtain the execution times of the reading operations. Different sizes have been used for the target file: 4 KB, 8 KB, and 16 KB. In addition, the count value stored in the E-LUKS header and the KS x , is also variable. The count value increases the security by stretching the original password length (88 bits) with log 2 count-value [39]. Therefore, the total password length obtained for the different count values is 93-bit for 32, 94-bit for 64, and 95-bit for 128.
The execution time results from the experiment are shown in Table 12. These results, as expected, indicate that the execution time increases when the target file size or the count value increases. It is also observed that the HMAC verification is the worst case scenario for execution time, but the best case scenario from the security perspective. Therefore, in order to provide more security to the system, the payoff is the execution time. In addition, it is noticed that the percentage of time needed for the E-LUKS, compared with the unencrypted file, is decreased with larger files (+418.8% for 4 KB, +310.3% for 8 KB, and +257.1% for 16 KB).
Regarding the resource taken from the FPGA. E-LUKS has been designed to occupy the least amount of resources. To get a better perspective, the resources' results have been compared with previous solutions. To this end, the E-LUKS core has been synthesized in different FPGAs, XC7Z020 [44] and XC6VLX240T [45]. The results can be divided in two groups: (1) results for solutions that are not specifically for resource constrained devices, and (2) results for solutions that are designed for these devices.
In the first group are the LUKS hardware implementations in [18,19], already presented in the Related Work Section. Its results, shown in Table 13, are an order of magnitude above E-LUKS. It is remarkable that E-LUKS takes less than 90% of the resources when compared to these LUKS hardware implementations. In Figure 6, it is observed that the best LUKS results are those of [18], which takes around 50% of Slice LUTs and 30% of Slice Registers from the FPGA. However, E-LUKS only takes about 5% of Slice LUTs and 3% of Slice Registers. Therefore, E-LUKS proves to be better suited to performing FDE in resource constrained devices which seek to have a small footprint over time execution. In this regard, the LUKS hardware solutions offer better performance due to their pipeline implementation.
The second group is about hardware solutions specifically for resource constrained devices. It contains Sancus [20], Soteria [22], Atlas [24], and [23]. The results are shown in Table 14 and Figures 7 and 8. All the solutions, except [23] when using authentication with the AE cipher ASCON, utilize less than 10% of any kind of resources for the FPGA. Therefore, these solutions are an adequate fit for resource constrained devices. When E-LUKS is compared to [23], it is observed that E-LUKS presents a slight improvement. Specially, when both designs are used to provide confidentiality, integrity, and authentication, whereas [23] takes up to four times more Slice LUTs. Regarding Atlas, it presents better results in Slice LUTs, 0.7% against 1.8%. However, it has worse results in number of Slices, 2.5% against 6.5%, and Slice Registers, 0.9% against 1.8%. Atlas provides confidentiality, although it lacks integrity and authenticity. Lastly, there are Sancus and Soteria. Both solutions have almost identical results, being the best suited, although it only shows when 1 SM is on the device. The overhead for an additional SM is 0.13% of Slice LUTs, and 0.013% of Slice Registers. E-LUKS takes about two times more Slice Registers and three times more Slice LUTs. However, these values represent less than 2% of both resources. With 10 SM, the Slice LUTs of E-LUKS and both solutions offer similar results. Therefore, to fit a few programs, Sancus and Soteria are the best solutions. However, to accommodate a large number of files, FDE is a better fit. Hence, to accommodate a large number of files, enough memory is required. In these kinds of devices, the storage for large files is usually a flash removable device, such as a microSD card. These memories are the target of E-LUKS, instead of the RAM memory. This leads to the advantage of being independent of any processor. It only needs to implement a bridge to the system bus, as well as [23].

Conclusions
In this work, a hardware-solution able to perform FDE on resource constrained devices is presented. In addition, E-LUKS can authenticate and verify the integrity of the user data. The results presented show that E-LUKS takes few resources from the FPGA; less than 5%. However, there are other hardware-solutions, which provide security of the user data. There are the LUKS solutions, which, due to its pipeline implementation and the use of cryptographic algorithms, occupies ten times more resources, in the best of the scenarios, than E-LUKS. The Sancus and Soteria solutions have a smaller footprint than E-LUKS when working with few files. However, to handle a large amount of data, FDE could work better. These solutions need to implement specific instructions to the processor. E-LUKS, on the other hand, is processor agnostic, depending only on the bus system in order to create a bridge module. Atlas solution and E-LUKS have similar resource results. However, while Atlas only provides confidentiality, the work presented in [23], provides confidentiality, authentication, and integrity. Nonetheless, when providing, all three of them have a cost in terms of resources that is worse than E-LUKS, especially in Slice LUTs where it is almost three times greater. Additionally, in this scenario, Reference [23] needs part of the memory to store the TEC tree, which allows the authentication and integrity of the data. Hence, we believe that E-LUKS is an excellent choice for providing security to IoT devices. In those cases, the resources of the devices are the priority.
Our future work with E-LUKS involves Secure Boot, which we believe could be a perfect fit for this solution. Due to its agnostic processor characteristic and lack of software, it could be an excellent Secure Boot to IoT devices that take few resources and boot an embedded Linux image.
Funding: This work was partially supported by the Ministerio de Industria y Competitividad of Spain under project TIN2017-89951-P (BootTimeIoT) and by the European Regional Development Fund (ERDF).The author G.C.-Q. is economically supported by the VI-PPITUS.