XTS-AES模式主要是解决什么问题，是怎样解决的? XTS-AES模式主要是解决什么问题，是怎样解决的?作者：蒋伟伟链接：https://www.zhihu.com/question/26452995/answer/142440391来源：知乎著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。XTS即基于XEX(XOR-ENCRYPT-XOR)的密文窃取算法的可调整的密码本模式（Tweakable Codebook mode），该算法主要用于以数据单元（包括扇区、逻辑磁盘块等）为基础结构的存储设备中静止状态数据的加密。以上是官方的解释，谈一下我的理解。我们都知道磁盘上的数据是有一定格式的，比如一个扇区是512字节，磁盘加密直接要对写入扇区的明文进行加密，记录在磁盘扇区上的是相应的密文。而我们通过传统的AES加密方法，比如CBC加密模式，密文须包含一个128bit的初始向量。那么问题来了，我们岂不是要腾出额外的128个bit专门存储初始向量？这样做是增加了磁盘的开销，而且明文和密文在扇区上的存储也不是一一对应的，这给磁盘底层的加密实现带来很大的麻烦。更为关键的是，传统的加密算法，更改密匙非常不便，一旦更改，就意味着要重新进行密匙扩展算法，对磁盘来说要增加很大的开销，同时还要担心密匙泄露的问题。在这种情况下，针对磁盘加密的特点，2002年，Moses Liskov，Ronald L.Rivest, David Wagner,首次提出了可调整的分组密码这个概念，跟传统的分组密码相比，除了密匙和明文这两个输入外，还引入另外一个输入---tweak，即可调整值。这样做的好处是，在不更改密匙的情况下，仅仅改变tweak值，就可以给加密系统提供多变性，既减少了磁盘的开销，也不怕密匙泄露，因为tweak值是公开的，就算泄露了tweak值，如果不知道密匙，是无法破解系统的。而且，这种算法，不需要初始向量，也就避免我们上面所述的明文和密文在扇区上的存储不对应的问题。XTS-AES算法是基于以上思想，被IEEE采用的一个标准。简单介绍下其原理，以传输单个128bit数据块为例：i为128-bit调整值，j为128-bit数据块在数据单元中的位置值,C为128-bit密文数据块。AES-enc为标准AES算法，key2为调整值密匙，key1为数据密匙，模乘操作中 α为GF(2^128)域中对应于多项式x的本源。计算的步骤顺序如下：T <---- AES-enc(key2,i) ⓧ (α^j );PP <----P⊕Thttp://3.CC<---AES-enc(Key1,PP)C<--CC⊕T需要指出的是，j代表数据块在数据单元里的index，比如256个bit数据块，那么 0bit-127bit的j=1，128bit-256bit 的j=2。j 的引入，是让各个数据块的加密保持独立。Disk encryption theoryFrom Wikipedia, the free encyclopediaJump to navigationJump to searchDisk encryption is a special case of data at rest protection when the storage medium is a sector-addressable device (e.g., a hard disk). This article presents cryptographic aspects of the problem. For an overview, see disk encryption. For discussion of different software packages and hardware devices devoted to this problem, see disk encryption software and disk encryption hardware.Contents1Problem definition2Block cipher-based modes2.1Cipher-block chaining (CBC)2.1.1Encrypted salt-sector initialization vector (ESSIV)2.1.2Malleability attack2.2Liskov, Rivest, and Wagner (LRW)2.3Xor–encrypt–xor (XEX)2.3.1XEX-based tweaked-codebook mode with ciphertext stealing (XTS)2.3.2XTS weaknesses2.4CBC–mask–CBC (CMC) and ECB–mask–ECB (EME)3Patents4See also5References6Further reading7External linksProblem definition[edit]Disk encryption methods aim to provide three distinct properties:1.The data on the disk should remain confidential.2.Data retrieval and storage should both be fast operations, no matter where on the disk the data is stored.3.The encryption method should not waste disk space (i.e., the amount of storage used for encrypted data should not be significantly larger than the size of plaintext).The first property requires defining an adversary from whom the data is being kept confidential. The strongest adversaries studied in the field of disk encryption have these abilities:1.they can read the raw contents of the disk at any time;2.they can request the disk to encrypt and store arbitrary files of their choosing;3.and they can modify unused sectors on the disk and then request their decryption.A method provides good confidentiality if the only information such an adversary can determine over time is whether the data in a sector has or has not changed since the last time they looked.The second property requires dividing the disk into several sectors, usually 512 bytes (4096 bits) long, which are encrypted and decrypted independently of each other. In turn, if the data is to stay confidential, the encryption method must be tweakable; no two sectors should be processed in exactly the same way. Otherwise, the adversary could decrypt any sector of the disk by copying it to an unused sector of the disk and requesting its decryption.The third property is generally non-controversial. However, it indirectly prohibits the use of stream ciphers, since stream ciphers require, for their security, that the same initial state not be used twice (which would be the case if a sector is updated with different data); thus this would require an encryption method to store separate initial states for every sector on disk—seemingly a waste of space. The alternative, a block cipher, is limited to a certain block size (usually 128 or 256 bits). Because of this, disk encryption chiefly studies chaining modes, which expand the encryption block length to cover a whole disk sector. The considerations already listed make several well-known chaining modes unsuitable: ECB mode, which cannot be tweaked, and modes that turn block ciphers into stream ciphers, such as the CTR mode.These three properties do not provide any assurance of disk integrity; that is, they don't tell you whether an adversary has been modifying your ciphertext. In part, this is because an absolute assurance of disk integrity is impossible: no matter what, an adversary could always revert the entire disk to a prior state, circumventing any such checks. If some non-absolute level of disk integrity is desired, it can be achieved within the encrypted disk on a file-by-file basis using message authentication codes.Block cipher-based modes[edit]Like most encryption schemes, block cipher-based disk encryption makes use of modes of operation, which allow encrypting larger amounts of data than the ciphers' block-size (typically 128 bits). Modes are therefore rules on how to repeatedly apply the ciphers' single-block operations.Cipher-block chaining (CBC)[edit]Main article: Cipher-block chainingCipher-block chaining (CBC) is a common chaining mode in which the previous block's ciphertext is xored with the current block's plaintext before encryption:Since there isn't a "previous block's ciphertext" for the first block, an initialization vector (IV) must be used as . This, in turn, makes CBC tweakable in some ways.CBC suffers from some problems. For example, if the IVs are predictable, then an adversary may leave a "watermark" on the disk, i.e., store a specially created file or combination of files identifiable even after encryption. The exact method of constructing the watermark depends on the exact function providing the IVs, but the general recipe is to create two encrypted sectors with identical first blocks  and ; these two are then related to each other by . Thus the encryption of  is identical to the encryption of , leaving a watermark on the disk. The exact pattern of "same-different-same-different" on disk can then be altered to make the watermark unique to a given file.To protect against the watermarking attack, a cipher or a hash function is used to generate the IVs from the key and the current sector number, so that an adversary cannot predict the IVs. In particular, the ESSIV approach uses a block cipher in CTR mode to generate the IVs.Encrypted salt-sector initialization vector (ESSIV)[edit]ESSIV[1] is a method for generating initialization vectors for block encryption to use in disk encryption. The usual methods for generating IVs are predictable sequences of numbers based on, for example, time stamp or sector number, and prevents certain attacks such as a watermarking attack. ESSIV prevents such attacks by generating IVs from a combination of the sector number SN with the hash of the key. It is the combination with the key in form of a hash that makes the IV unpredictable.ESSIV was designed by Clemens Fruhwirth and has been integrated into the Linux kernel since version 2.6.10, though a similar scheme has been used to generate IVs for OpenBSD's swap encryption since 2000.[2]ESSIV is supported as an option by the dm-crypt[3] and FreeOTFE disk encryption systems.Malleability attack[edit]While CBC (with or without ESSIV) ensures confidentiality, it does not ensure integrity of the encrypted data. If the plaintext is known to the adversary, it is possible to change every second plaintext block to a value chosen by the attacker, while the blocks in between are changed to random values. This can be used for practical attacks on disk encryption in CBC or CBC-ESSIV mode.[4]Liskov, Rivest, and Wagner (LRW)[edit]In order to prevent such elaborate attacks, different modes of operation were introduced: tweakable narrow-block encryption (LRW and XEX) and wide-block encryption (CMC and EME).Whereas a purpose of a usual block cipher  is to mimic a random permutation for any secret key , the purpose of tweakable encryption is to mimic a random permutation for any secret key  and any known tweak . The tweakable narrow-block encryption (LRW)[5] is an instantiation of the mode of operations introduced by Liskov, Rivest, and Wagner[6] (see Theorem 2). This mode uses two keys:  is the key for the block cipher and  is an additional key of the same size as block. For example, for AES with a 256-bit key,  is a 256-bit number and  is a 128-bit number. Encrypting block  with logical index (tweak)  uses the following formula:Here multiplication  and addition  are performed in the finite field ( for AES). With some precomputation, only a single multiplication per sector is required (note that addition in a binary finite field is a simple bitwise addition, also known as xor): , where  are precomputed for all possible values of . This mode of operation needs only a single encryption per block and protects against all the above attacks except a minor leak: if the user changes a single plaintext block in a sector then only a single ciphertext block changes. (Note that this is not the same leak the ECB mode has: with LRW mode equal plaintexts in different positions are encrypted to different ciphertexts.)Some security concerns exist with LRW, and this mode of operation has now been replaced by XTS.LRW is employed by BestCrypt and supported as an option for dm-crypt and FreeOTFE disk encryption systems.Xor–encrypt–xor (XEX)[edit]Main article: Xor–encrypt–xorAnother tweakable encryption mode, XEX (xor–encrypt–xor), was designed by Rogaway[7] to allow efficient processing of consecutive blocks (with respect to the cipher used) within one data unit (e.g., a disk sector). The tweak is represented as a combination of the sector address and index of the block within the sector (the original XEX mode proposed by Rogaway[7] allows several indices). The ciphertext, , is obtained using:where: is the plaintext, is the number of the sector, is the primitive element of  defined by polynomial ; i.e., the number 2, is the number of the block within the sector.The basic operations of the LRW mode (AES cipher and Galois field multiplication) are the same as the ones used in the Galois/Counter Mode (GCM), thus permitting a compact implementation of the universal LRW/XEX/GCM hardware.XEX has a weakness.[8]XEX-based tweaked-codebook mode with ciphertext stealing (XTS)[edit]Ciphertext stealing provides support for sectors with size not divisible by block size, for example, 520-byte sectors and 16-byte blocks. XTS-AES was standardized on 2007-12-19[9] as IEEE P1619.[10] The standard supports using a different key for the IV encryption than for the block encryption; this is contrary to the intent of XEX and seems to be rooted in a misinterpretation of the original XEX paper, but does not harm security.11 As a result, users wanting AES-256 and AES-128 encryption must supply 512 bits and 256 bits of key respectively.On January 27, 2010, NIST released Special Publication (SP) 800-38E[12] in final form. SP 800-38E is a recommendation for the XTS-AES mode of operation, as standardized by IEEE Std 1619-2007, for cryptographic modules. The publication approves the XTS-AES mode of the AES algorithm by reference to the IEEE Std 1619-2007, subject to one additional requirement, which limits the maximum size of each encrypted data unit (typically a sector or disk block) to 220 AES blocks. According to SP 800-38E, "In the absence of authentication or access control, XTS-AES provides more protection than the other approved confidentiality-only modes against unauthorized manipulation of the encrypted data."XTS is supported by BestCrypt, Botan, NetBSD's cgd,[13] dm-crypt, FreeOTFE, TrueCrypt, VeraCrypt,[14] DiskCryptor, FreeBSD's geli, OpenBSD softraid disk encryption software, OpenSSL, Mac OS X Lion's FileVault 2, Windows 10's BitLocker[15] and wolfCrypt.XTS weaknesses[edit]XTS mode is susceptible to data manipulation and tampering, and applications must employ measures to detect modifications of data if manipulation and tampering is a concern: "...since there are no authentication tags then any ciphertext (original or modified by attacker) will be decrypted as some plaintext and there is no built-in mechanism to detect alterations. The best that can be done is to ensure that any alteration of the ciphertext will completely randomize the plaintext, and rely on the application that uses this transform to include sufficient redundancy in its plaintext to detect and discard such random plaintexts." This would require maintaining checksums for all data and metadata on disk, as done in ZFS or Btrfs. However, in commonly used file systems such as ext4 and NTFS only metadata is protected against tampering, while the detection of data tampering is non-existent.[16]The mode is susceptible to traffic analysis, replay and randomization attacks on sectors and 16-byte blocks. As a given sector is rewritten, attackers can collect fine-grained (16 byte) ciphertexts, which can be used for analysis or replay attacks (at a 16-byte granularity). It would be possible to define sector-wide block ciphers, unfortunately with degraded performance (see below).[17]CBC–mask–CBC (CMC) and ECB–mask–ECB (EME)[edit]CMC and EME protect even against the minor leak mentioned above for LRW. Unfortunately, the price is a twofold degradation of performance: each block must be encrypted twice; many consider this to be too high a cost, since the same leak on a sector level is unavoidable anyway.CMC, introduced by Halevi and Rogaway, stands for CBC–mask–CBC: the whole sector encrypted in CBC mode (with ), the ciphertext is masked by xoring with , and re-encrypted in CBC mode starting from the last block. When the underlying block cipher is a strong pseudorandom permutation (PRP) then on the sector level the scheme is a tweakable PRP. One problem is that in order to decrypt  one must sequentially pass over all the data twice.In order to solve this problem, Halevi and Rogaway introduced a parallelizable variant called EME (ECB–mask–ECB). It works in the following way:the plaintexts are xored with , shifted by different amount to the left, and are encrypted: ;the mask is calculated: , where  and ;intermediate ciphertexts are masked:  for  and ;the final ciphertexts are calculated:  for .Note that unlike LRW and CMC there is only a single key .CMC and EME were considered for standardization by SISWG. EME is patented, and so is not favored to be a primary supported mode.[18]Patents[edit]While the authenticated encryption scheme IAPM provides encryption as well as an authentication tag, the encryption component of the IAPM mode completely describes the LRW and XEX schemes above, and hence XTS without the ciphertext stealing aspect. This is described in detail in Figures 8 and 5 of the US patent 6,963,976.[19]See also[edit]Data remanenceCold boot attackDisk encryption softwareDisk encryption hardwareIEEE P1619, standardization project for encryption of the storage dataReferences[edit]1.^ Clemens Fruhwirth (July 18, 2005). "New Methods in Hard Disk Encryption" (PDF). Institute for Computer Languages: Theory and Logic Group (PDF). Vienna University of Technology.2.^ "Encrypting Virtual Memory" (Postscript).3.^ Milan Broz. "DMCrypt dm-crypt: Linux kernel device-mapper crypto target". gitlab.com. Retrieved April 5, 2015.4.^ Jakob Lell (2013-12-22). "Practical malleability attack against CBC-encrypted LUKS partitions".5.^ Latest SISWG and IEEE P1619 drafts and meeting information are on the P1619 home page [1].6.^ M. Liskov, R. Rivest, and D. Wagner. Tweakable block ciphers [2], CRYPTO '02 (LNCS, volume 2442), 2002.7.^ Jump up to:a b c Rogaway, Phillip (2004-09-24). "Efficient Instantiations of Tweakable Blockciphers and Refinements to Modes OCB and PMAC" (PDF). Dept. Of Computer Science(PDF). University of California, Davis.8.^ https://link.springer.com/content/pdf/10.1007/978-3-540-74462-7_8.pdf section 4.1.9.^ Karen McCabe (19 December 2007). "IEEE Approves Standards for Data Encryption". IEEE Standards Association. Archived from the original on 2008-03-06.10.^ Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices. IEEE Xplore Digital Library. April 18, 2008. doi:10.1109/IEEESTD.2008.4493450. ISBN 978-0-7381-5363-6.11.^ Liskov, Moses; Minematsu, Kazuhiko (2008-09-02). "Comments on XTS-AES" (PDF)., On the Use of Two Keys, pp. 1–3.12.^ Morris Dworkin (January 2010). "Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices" (PDF). NIST Special Publication 800-38E. National Institute of Standards and Technology.13.^ "NetBSD cryptographic disk driver".14.^ "Modes of Operation". VeraCrypt Documentation. IDRIX. Retrieved 2017-10-13.15.^ "What's new in BitLocker?". November 12, 2015. Retrieved 2015-11-15.16.^ Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices (PDF), IEEE P1619/D16, 2007, p. 34, archived from the original (PDF) on 14 April 2016, retrieved 14 September 201217.^ Thomas Ptacek; Erin Ptacek (2014-04-30). "You Don't Want XTS".18.^ P. Rogaway, Block cipher mode of operation for constructing a wide-blocksize block cipher from a conventional block cipher, US Patent Application 20040131182 A1.19.^ * U.S. Patent 6,963,976, "Symmetric Key Authenticated Encryption Schemes" (filed Nov. 2000, issued Nov. 2005, expires 25 Nov. 2022) 3.Further reading[edit]S. Halevi and P. Rogaway, A Tweakable Enciphering Mode, CRYPTO '03 (LNCS, volume 2729), 2003.S. Halevi and P. Rogaway, A Parallelizable Enciphering Mode [5], 2003.Standard Architecture for Encrypted Shared Storage Media, IEEE Project 1619 (P1619), [6].SISWG, Draft Proposal for Key Backup Format [7], 2004.SISWG, Draft Proposal for Tweakable Wide-block Encryption [8], 2004.James Hughes, Encrypted Storage — Challenges and Methods [9]J. Alex Halderman, Seth D. Schoen, Nadia Heninger, William Clarkson, William Paul, Joseph A. Calandrino, Ariel J. Feldman, Jacob Appelbaum, and Edward W. Felten (2008-02-21). "Lest We Remember: Cold Boot Attacks on Encryption Keys" (PDF). Princeton University. Archived from the original (PDF) on 2008-05-14.Niels Fergusson (August 2006). "AES-CBC + Elephant Diffuser: A Disk Encryption Algorithm for Windows Vista" (PDF). Microsoft.External links[edit]Security in Storage Working Group SISWG."The eSTREAM project". Retrieved 2010-03-28.