Optimizing Dm-Crypt for XTS-AES: Getting The
Total Page：16
File Type：pdf, Size：1020Kb
Optimizing dm-crypt for XTS-AES: Getting the Best of Atmel Cryptographic Co-Processors (long version) Levent Demir, Mathieu Thiery, Vincent Roca, Jean-Michel Tenkes, Jean-Louis Roch To cite this version: Levent Demir, Mathieu Thiery, Vincent Roca, Jean-Michel Tenkes, Jean-Louis Roch. Optimizing dm-crypt for XTS-AES: Getting the Best of Atmel Cryptographic Co-Processors (long version). SE- CRYPT 2020 - 17th International Conference on Security and Cryptography, Jul 2020, Paris, France. pp.1-11. hal-02555457 HAL Id: hal-02555457 https://hal.archives-ouvertes.fr/hal-02555457 Submitted on 27 Apr 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Optimizing dm-crypt for XTS-AES: Getting the Best of Atmel Cryptographic Co-Processors (long version) Levent Demir1,2, Mathieu Thiery1,2, Vincent Roca1, Jean-Michel Tenkes2, and Jean-Louis Roch3 1Incas ITSec, France 2Univ. Grenoble Alpes, Inria, France 3Univ. Grenoble Alpes, Grenoble INP, LIG, France Keywords: Full disk encryption, XTS-AES, Linux dm-crypt module, cryptographic co-processor, Atmel board. Abstract: Linux implementation of Full Disk Encryption (FDE) relies on the dm-crypt kernel module, and is based on the XTS-AES encryption mode. However, XTS-AES is complex and can quickly become a performance bottleneck. Therefore we explore the use of cryptographic co-processors to efficiently implement the XTS-AES mode in Linux. We consider two Atmel boards that feature different cryptographic co-processors: the XTS-AES mode is completely integrated on the recent SAMA5D2 board but not on the SAMA5D3 board. We first analyze three XTS-AES implementations: a pure software implementation, an implementation that leverages the XTS-AES co-processor, and an intermediate solution. This work leads us to propose an optimization of dm-crypt, the extended request mode, that enables to encrypt/decrypt a full 4kB page at once instead of issuing eight consecutive 512 bytes requests as in the current implementation. We show that major perfor- mance gains are possible with this optimization, a SAMA5D3 board reaching the performance of a SAMA5D2 board where XTS-AES operations are totally offloaded to the dedicated cryptographic co-processor, while remaining fully compatible with the standard. Finally, we explain why bad design choices prevent this optimization to be applied to the new SAMA5D2 board and derive recommendations for future co-processor designs. 1 Introduction crypt module (Broˇzet al., 2020) within kernel- space, which allows transparent encryption and Data protection is a necessity: large amounts decryption of blocks. of sensitive information are stored in many differ- A crucial aspect for FDE is the cipher mode ent devices, smartphones, tablets and computers. of operation, AES being the main cipher choice. If such devices are lost or stolen, the unauthorized Until 2007, the standard for data encryption in access to information could have disastrous con- FDE was the CBC-AES mode. But this mode has sequences (e.g., psychological or economic (LLC, several drawbacks. For instance, as explained in 2010)). We also have to pay attention not only to (IEEE Computer Society, 2008): "an attacker can data at rest, but also to data in different memo- flip any bit of the plaintext by flipping the cor- ries like RAM and swap spaces. responding ciphertext bit of the previous block" One possible approach is to use Full Disk En- which can be dangerous. Furthermore, encryp- cryption (FDE), which consists of encrypting an tion is not parallelizable which is an issue for cer- entire disk, content as well as associated meta- tain use cases. data, all information being encrypted/decrypted Therefore a new mode has been introduced in on-the-fly and transparently. At the system 2008, XTS-AES (IEEE Computer Society, 2008). level, data is stored either in a logical parti- The previous two limitations have been solved tion or in a file container. Different tools ex- because the encryption/decryption of a 16-byte ist for FDE. With Linux, the native solution is block is now performed independantly of any pre- based on cryptsetup/LUKS application (Fruh- vious 16-byte block. Each 16-byte block can wirth, 2005a), within user-space, and the dm- be accessed in any order and parallelization is 2 1 INTRODUCTION now possible during both encryption and decryp- co-processor with ECB-AES support only of the tion. In spite of that, the XTS-AES encryp- old SAMA5D3 board. Our benchmarks demon- tion/decryption operations are complex and the strated that the performance achieved in all use of this mode in lightweight environments over cases was still behind expectations and did not huge amounts of data is challenging. match our objective of efficient on-the-fly encryp- The motivation for this work is to offload all tion/decryption of large amounts of data within XTS-AES cryptographic operations to a dedi- the Atmel boards. cated board, in charge of FDE. This feature can An analysis of in-kernel data paths highlighted be useful to design a security board that would be a limitation of plaintext sizes to a hard-coded 512 in charge of all cryptographic operations required bytes value, in particular because this is the com- to outsource user's data in an external, untrusted mon sector size on most devices, and also because storage facility (e.g., a Cloud). This architecture, test vectors are limited to a maximum of 512 with a security board in the middle, between the bytes in the official XTS-AES standard (IEEE client and the storage facility, was our initial goal Computer Society, 2008). We therefore explored that triggered the present work. The question the possibility of having 4 KB long requests (i.e., of improving the performance of the XTS-AES a page size), a rational choice and a pretty natu- mode in embedded, lightweight environments, is ral idea for kernel operations. We called this op- therefore critical. timization "extended request mode", or extReq. We therefore modified of dm-crypt as well Choice of Atmel Boards: the Importance of as the underlying atmel-aes driver, two highly Detailed Technical Specifications: We con- complex tasks, in order to support extended sidered two Atmel boards, both equipped with a encryption/decryption requests. We then ana- cryptographic co-processor, the (old) SAMA5D3 lyzed its impacts on performance. With this board (ATMEL, 2017b) and the (new) SAMA5D2 optimization, a mixed implementation with the board (ATMEL, 2017a). These boards have been (old) SAMA5D3 ECB-AES co-processor features chosen because of their low price, because of their roughly the same performance as that of the wide acceptance in industrial systems, and also (new) SAMA5D2 XTS-AES co-processor. because the cryptographic co-processor documen- Finally we analyzed the existing XTS-AES tation is publicly available, a requirement for ad- cryptographic co-processor of the SAMA5D2 vanced developments. This is not always the case board in order to apply the extReq optimization as we discovered after buying another more pow- to it directly. Unfortunately, because of bad de- erfull board: the provided information turned out sign choices by Atmel, this new cryptographic co- to be too limited for our needs and our academic processor is not compatible with this optimiza- status did not enable us to obtain the technical tion, therefore limiting the opportunities for ma- documentation from the manufacturer, even after jor performance improvements. We explain why asking their support. it is so and conclude this work with recommen- A major difference exists between these two dations for future co-processor designs. Atmel boards, which justifies that we consider Note that this work only considers crypto- both of them: the cryptographic co-processor of graphic operations over large data chunks, which the first board supports common AES modes but is pretty common with FDE use-cases. It does not not XTS-AES, while the second one also supports consider the opposite case, i.e., large numbers of XTS-AES. Those constraints led us to consider small data chuncks, which is not the target of our different implementation options that are the sub- optimisation. ject of this work. Contributions of this Work: The contribu- Scientific Approach Followed in this Work: tions of this work are threefold: The first step of our work was the experi- • this works explores the implementation of mental analysis of three XTS-AES implemen- cryptographic primitives in Linux systems, tations: a pure software implementation (the detailing the complex interactions between legacy baseline), an implementation that lever- software and hardware components, and the ages the dedicated cryptographic co-processor dm-crypt kernel module internals. Note that with XTS-AES support of the SAMA5D2 board this work implied major in-kernel low-level (the most favourable case), and in between an software developments and complex perfor- implementation that leverages the cryptographic mance evaluation campaigns. 3 • this work shows that significant performance possible to encrypt the same plaintext into differ- gains are possible thanks to the "extended ent ciphertexts without additional storage. request mode", extReq, optimization, even Throughout this paper, we are focusing with boards that do not feature cryptographic on performance issues. Because of the huge co-processors supporting XTS-AES. Although amount of data to be encrypted, the encryp- the idea behind this optimisation is pretty tion/decryption throughput is essential in FDE.