On Selected Issues of Full Disk Encryption

Home , Lyra2, Sponge function

MASARYK UNIVERSITY

FACULTY OF INFORMATICS

On selected issues of full disk encryption

DISSERTATION THESIS PROPOSAL

Milan Brož

Supervisor: prof. RNDr. Václav Matyáš, M.Sc, Ph.D.

Brno, January 2015

Supervisor's signature: Table of contents

1 Introduction 2 1.1 Full disk encryption 2 1.2 FDE in different layers 3 1.3 FDE problem domains 4 1.4 Storage system 4 1.5 Cryptography and limiting factors 5 2 State-of-the-art research 7 2.1 Threat models 7 2.2 Storage architecture 8 2.3 Secure wipe on storage 8 2.4 Sector encryption algorithms 9 2.4.1 Block ciphers and modes 9 2.4.2 Narrow encryption modes 10 2.4.3 Initial vectors in CBC 11 2.4.4 Wide encryption modes 12 2.4.5 Integrity protection and authenticated modes 12 2.5 Key storage and management 13 2.5.1 How to store volume key 14 2.5.2 Password-based key derivation functions 15 2.5.3 Password hashing competition 16 3 Planned future research 18 3.1 Considered issues in FDE 18 3.2 Research proposal 20 4 Summary of own results 21 A Appendix 22 A.l Storage architecture 22 A. 1.1 Rotational disks 22 A. 1.2 Flash memory based storage 22 A. 1.3 Network attached storage, block storage in cloud services 23 Bibliography 23

1 1 Introduction

As the requirements for security and privacy grow, encryption becomes an essential part of most systems involved in processing of sensitive data. With the availability of processors that are able to perform data encryption with throughput even higher than the throughput of high-end storage devices, the possibility to encrypt the whole storage device on-the-fiy becomes reality even for mobile and embedded devices. Full disk encryption (FDE) as transparent on-the-fly encryption of storage devices operates directly on the disk sector level. This means that it can be implemented inside an operating system (or even inside a storage device itself) without the need to adapt higher layers like filesystem or applications. FDE does not rule out encryption on higher layers. Independent encryption on various layers can still complement one another perfectly. This layer separation is an important factor in designing secure and reliable storage systems but also requires very responsible design of all involved components. In theory, the layer separation is ideal and FDE could be completely transparent for the layers below and above. In reality, security and performance of an FDE system is directly influenced by the underlying storage architecture and design should take into account relevant physical and operational limits. This leads to many inevitable trade-off decisions (and often to design mistakes deflating security).

1.1 Full disk encryption

From a high level perspective, FDE just provides transparent access to a storage device using another virtual device layered on top of the encrypted one. The top level device contains clear data (plaintext) and applications can access this virtual device as normal storage. The encryption layer then encrypts and decrypts sectors on-the-fly, so that the underlying device contains only encrypted data (ciphertext). The whole underlying storage device is encrypted and if the device is properly wiped before initial use, the whole underlying disk should contain only encrypted data statistically not distinguishable from a random noise. Handling of (secure) wipe in combination with unused disk space management in modern storage systems uncovers the first problem for FDE discussed in next sections. Once a user activates the plaintext device (usually by providing a password or using some security token-based unlocking mechanism) the encryption

2 1. INTRODUCTION

layer is activated and plaintext device is made accessible to the system. Management of encryption keys, in particular the techniques for generating keys and storing them securely, is a critical part of the system.

1.2 FDE in different layers

FDE can be implemented in various layers, beginning with the hardware itself and ending with full software implementation running solely on the host processor. The problems to solve in various layers are usually quite similar, but implementations differ in utilizing various kinds of hardware. The hardware level FDE is processed directly inside the drive. There is a lot of products using this kind of hardware level FDE with various marketing names (meaning the same in reality). Examples are Hitachi (bulk data encryption), Seagate (full disk encryption) or Toshiba (self-encrypting drives). There is also the Opal storage specification [1] that tries to create a common standard for manufacturers of these drives. A recent security analysis of hardware FDEs is provided in [2]. Another hardware-based FDE is the Chipset FDE. This is a common stock drive without encryption capabilities, combined with a special hard• ware interface (bridge) placed between the drive and disk interface that provides encryption. The only difference from self-encrypting drives is that the encryption bridge is clearly (both logically and physically) separated from the drive. Example of such systems are almost all external USB drives with hardware-based encryption (because the USB Bridge is an additional interface, combining with encryption functionality seems to be a cost effective solution for manufacturers). The layer we are mainly interested in is a software-based FDE. The encryption runs directly on the host system processor (either directly as a generic sub-procedure or utilizing special instructions like Intel AES-NI). There can be also a special crypto processing units integrated (examples are VIA PadLock, AMD Geode AES engine or from the mainframe world IBM System z9 - CP Assist for Cryptographic functions - CPACF). The special borderline case are embedded systems using software based FDE encryption but solely designed to present storage over the network. These devices (usually running some Linux derivative inside) are very common for low-cost network attached storage (NAS) products.

3 1. INTRODUCTION

Symmetric Encryption RNG Key Derivation Algorithms Modes (randomness) Algorithms 1 1 1 1

Encryption User Data Key Storage |- (plaintext) Engine Steganography

Key Passphrase User Data Storage Multi-Factor (ciphertext) Authentication

Storage Hardware Security Performance Secure Wipe Architectures Keystore Policy

Figure 1.1: A schematic concept of FDE architectural design domains.

1.3 FDE problem domains

The issues (simplified) related to FDE are illustrated in Figure 1.1. In the following description, we will focus on the cryptographic part, but under• standing other domains is crucial to designing secure and practically usable FDE systems.

1.4 Storage system

A storage system here means a device intended for persistent data store. In real systems it is disk, either rotational or flash memory based, connected to operating system as a block device. The atomic accessible unit of this device is indeed block (consisting of one or more low-level disk sectors), but to avoid confusion we will use sector as the description for an atomic unit of a block device. Storage system can be locally or remotely attached. The internal architecture of storage systems is important not only for performance reasons, but also for secure design of FDE.

4 1. INTRODUCTION

A good example of a performance-related attribute is the alignment of filesystem blocks to sectors (in flash memory storage even to internal memory blocks). There can be multiple virtual storage layers so the alignment of all layers becomes a critical part of the storage performance (misalignment usually means increasing of input/output operations for the drive because it must split the writing area between one or more underlying sectors). If we add a transparent encryption layer between any of these layers, we should respect all restrictions to avoid a significant performance decrease. The storage architecture can also directly influence security of the system. For example, modern solid state drives (SSDs) contain processors capable of highly sophisticated operations. The need of a complex flash sector storage management also often implies that various garbage collector and optimiza• tion processes are running inside these drives. These processes are running invisible in the background to provide optimal performance and life-time optimizations (called wear-leveling). The drive shuffles the sectors to keep the drive performance optimal. Unfortunately, it also means that with these drives it is impossible to ensure that erasing a sector really destroys the information stored there. There can be even more copies of the same sector internally as a side effect of drive optimization algorithms. The sector reallocation problem is not new. For rotational media, sector reallocation exists as well (if a drive detects a physically defective area it reallocates sectors to special reserved area). Yet what is an exceptional procedure (usually caused by a media error) for rotational drives, it becomes normal operating mode for SSDs. We will discuss relevant storage architecture issues in detail in section 2.2 and in appendix A.l.

1.5 Cryptography and limiting factors

The following section introduces type of cryptographic primitives and algo• rithms used in the FDE area while the more rigorous description follows in section 2.4. High performance is an important factor for real-world usability of FDE. The storage encryption layer uses symmetric block ciphers for data encryption that can provide the needed performance. While the block size of block ciphers is usually smaller than the sector size, block ciphers must be operated in a cipher mode. Price for using a cipher mode is increased computational and time requirements. An authenticated cipher mode can also provide integrity protection. The encryption layer preserves sectors as independently accessible units.

5 1. INTRODUCTION

We can define it as a format-preserving encryption where independent N-bytes sectors of plaintext encrypts into another N-bytes ciphertext sectors. Therefore there is no space available for any additional context information inside encrypted sectors (sector size is not increased). The same plaintext data located in different sectors must be encrypted to different ciphertexts. To fulfill this requirement without using any additional space for context information, we have to use implicit distinctive per-sector information. Most of FDE systems depend on the sector number (offset from the block device start). The sector number is visible information to an attacker and it is usually transformed into initial vector (or tweak) by an additional operation. The symmetric key used for sector-level encryption is called volume key (or master key). It can be either derived from a user passphrase by a password- based key derivation function (PBKDF) or generated by a random number generator (RNG). The generated key can be stored using different encryption methods in some special metadata area (on the disk or on another device) or stored on a special device (token). Disk encryption is widely used in corporations and the government sector, where it provides a basic protection to data theft for portable devices. Many of these users are strictly bound by various standards and requirements for cryptography use. Design of some disk encryption systems is done with these limitations in mind and sometimes lead to constructions that are used just to fulfill these requirements. The best known standard is the Federal Information Processing Standard (FIPS) 140 that defines requirements for the US government cryptography use. The standard is published by the National Institute of Standards and Technology (NIST) that also drives a validation program for cryptography products (modules). There is a require• ment to use validated cryptography modules for unclassified information in US government and related organizations. In European Union, there exists a similar recommendation for cryptography use, published by the European Union Agency for Network and Information Security (ENISA) [3]. Another limitation is the patent status of ciphers and cipher modes (and algorithms in general). In the context of FDE this applies mainly in area of block cipher mode selection where many modes are patent encumbered.

G 2 State-of-the-art research

2.1 Threat models

The common FDE threat model [2, 4, 5] covers the situation when the encrypted storage media content (containing ciphertext only) is accessible to an attacker while the storage device itself (or virtual image) is not in use (it is powered down or detached from the system in a safe state). The attacker can have direct physical access to the media with the encrypted content. In other words, it protects data on storage from unauthorized access in situation when the device is lost, seized or when the attacker is able to remotely create an encrypted disk image snapshot (e.g., for a virtual machine in a datacenter). Sometimes the attacker can have access to some plaintext of stored data (like cached images from web pages or known files from a common OS installation). In general, FDE does not fully protect in situation when the attacker has repeated access to the storage media and is able to create multiple snapshots of ciphertext in time. FDE also does not protect data when an authorized user is using the system (the system is powered on and the encryption layer is active), including various standby modes when the RAM contains plaintext data or even encryption key. While most threat models are not explicitly covering situations when the device is in use, the design of FDE system could prevent or complicate attacks for specific attack vectors outside our threat model boundary. (An example is erasing the encryption key from RAM in the standby mode.) Threat models expect that all used security primitives are cryptographi- cally strong enough to resist direct attacks to used algorithms (in other words that crypto primitives are not broken). Hardware-based FDE (either self-encrypted drives or chipset-based en• cryption) have other attack vectors [2, 6] but the threat model is in principle the same. While the threat models presented above provide confidentiality (plaintext is available only to a user with the secret key), they do not cover integrity protection and authentication. Integrity protection assures that all attempts to tamper the data by an attacker without secret key knowledge are detected (in other words it proves that data are not modified). Authentication then proves that the data was created by the authenticated user (using the secret key).

7 2. STATE-OF-THE-ART RESEARCH

2.2 Storage architecture

The low-level underlying storage architecture develops in time and not only enables growth in storage sizes, but also introduces new issues and challenges. Especially an enterprise storage can be a very complex layered system [7]. Currently used devices for FDE are hard disk drives (HDDs) that are rotational disks, solid state drives (SSDs) that are build on flash based storage and block devices connected remotely. In the near future we can also expect massive use of persistent byte- addressable memory. Persistent byte-addressable storage has similar charac• teristics as a random access memory (RAM), just it is non-volatile (it keeps content after power-off). While it is not yet widely available, methods how to integrate it in operating systems are already discussed [8]. It is possible that there will be a transitioning period during that storage devices are accessed through a emulation interface of a legacy block-based storage [9]. A more detailed introduction to storage devices mentioned above is provided in appendix A.l.

2.3 Secure wipe on storage

The safe way to wipe data on a storage device is an important factor in evaluating security of an FDE system. We need to use secure wipe in several contexts. Secure wipe is an operation that will:

• fill the whole storage (or part of it) with data not distinguishable from a random noise:

• wipe the exact area of storage to destroy specific information (area with the encrypted key):

• re-write the exact area in such a way that no copies of previous area content exist.

There can exist an algorithm how to implement some of the secure wipe operation types for the specific storage configuration. Yet for the generic storage (with all possible configurations) the secure wipe could be very hard (or even impossible) to implement correctly. For HDDs, Guttman analyzed secure wipe and suggested some meth• ods [10], followed by analyzing the same problem for semiconductor de• vices [11]. The author notes that described algorithms are no longer valid for

8 2. STATE-OF-THE-ART RESEARCH

modern HDDs with ultra-high densities and different technology [10] (online version). For solid state drives, effective wipe method must bypass flash translation layer (see appendix A.1.2) and clear directly physical flash blocks. Many drives do not expose interfaces to allow that. Partial alternative is to use special TRIM command (if available), which should guarantee that all following reads of the area specified in command will return a zeroed area (defined as the deterministic read zero after TRIM - DZAT [12]). If we want to sanitize the whole drive, there are more methods. The drive itself can support erase unit command. An alternative is to wipe the whole drive twice (to be sure that the hidden area is overwritten as well). Unfortunately, as analyzed in [13], sanitizing is effective only for some drives.

2.4 Sector encryption algorithms

FDE uses block ciphers for encryption of sectors in a block encryption mode. The history of proposing encryption modes is rich [4, 14], but we will focus on currently used or proposed modes only.

2.4.1 Block ciphers and modes

Some systems use variety of block ciphers according to user selection, but most of them have Advanced Encryption Standard (AES) as default. The first important issue is on what granularity we can localize a change in plaintext based only on snapshots of ciphertext. In an ideal situation it is the whole sector (as it is the best possible situation in random sector access model). The ideal encryption produces ciphertext change diffused through the whole ciphertext sector for every possible change in the plaintext sector. To provide such a granularity, we can use a block cipher with a large- enough block [15, 16]. With increasing sectors sizes, this solution is not applicable in reality. Also, the performance of these ciphers is not adequate for storage encryption [16]. Most of the block ciphers today use small block (like 128 bits in AES). Another option is to use an additional independent operation before the encryption step (and symmetrically after the decryption step) that preprocesses the plaintext so the final encryption meets the whole-sector change requirement. This approach was used in BitLocker [16] with a diffuser operation called Elephant. It consists of two mixing operations that work in opposite directions and are applied sequentially. There is also an additional per-sector key applied to the ciphertext.

9 2. STATE-OF-THE-ART RESEARCH

While the BitLocker design allowed to use encryption both with and without the Elephant diffuser, in the new versions of Windows operating systems one can use only the mode without it [17]. While the use of block encryption modes is the most common in FDE, we will discuss it separately later in this section. For sector encryption we do not need to solve any padding (variable size of plaintext) because storage sector size is always multiple of encryption block size. Padding is performed on higher layers (page cache or filesystem).

2.4.2 Narrow encryption modes

Traditional cipher modes, more specifically called narrow-block modes because of the comparison to sector size, are the basic building blocks for a practical use of block ciphers. In the context of FDE, a very detailed analysis of many available modes (except for the most recent ones, more notable XTS) is in the work of Fruhwirth [4]. The electronic code-book (ECB) mode [15] is the simplest application of a block cipher to a sector. The plaintext (sector) is split into blocks of the block cipher size and these blocks are encrypted without any additional tweaks. We mention the ECB mode because it is basic building block for other constructions, a direct use of the ECB mode would be very weak and vulnerable to known-plaintext pattern matching or reply attacks. Very common mode for sector encryption is the cipher-block chaining (CBC) mode. CBC is probably the most analyzed and most widely used mode (it was invented in 1976 and used since then in many applications), principle of the CBC mode is the exclusive or (XOR) applied between the previous ciphertext block and the following plaintext block. For the first block (where there is no previous ciphertext block), the initialization vector (IV) is used instead. The initialization vector must be unique for every sector. The IV is tweaked by the sector number and must not be predictable by an attacker. Fruhwirth documented the whole series of CBC issues in the special chapter of his work [4]. IEEE P1619 Security in Storage Working Group (SISWG) adopted the new narrow-block mode XTS (XOR-encrypt-XOR with ciphertext stealing) specifically designed for storage encryption [18, 19]. The standard itself defines AES as the given block cipher but XTS mode can be used with any block cipher. The XTS mode uses two keys. The first key is used to generate an IV and the second key is used for the encryption. XTS mode eliminates the problem with unpredictable IV internally so the sector number can be used directly as

10 2. STATE-OF-THE-ART RESEARCH

a tweak value. Unlike the CBC, XTS is fully parallelizable (after the initial IV calculation all blocks can be processed in parallel). The concept is based on the XEX construction initially described by Rogaway in [20]. Independent encryption of blocks in XTS mode implies that a simple change in plaintext propagates only to one block, so the granularity of a change is just one cipher block. The annex in IEEE P1619.2 standard [19] mentions that the mode offers better protection against ciphertext manipulations than the CBC. The public comments for NIST XTS document [21] discuss various problems in XTS mode. One observation is that limited propagation of a small plaintext change provides an attacker possibility to easily collect many cipher blocks with the same tweak and key. It can be used to perform fine-grained ciphertext manipulation attacks.

2.4.3 Initial vectors in CBC

The IV in CBC mode can be fixed (which causes similar problems as using ECB mode), it can be simple counter (sector number) or generated IV with sector number as one input parameter [22]. The randomly or nonce generated IVs are not usable (we do not have space to store context information). The counter IV is sometimes denoted as plain IV. The counter IV must never overflow otherwise one IV is used for more sectors. This can happen for example if the IV is stored in a limited space in size and growth in data storage sizes exceeds the maximal size above this sector limit. To remedy the problem of public IV we can define a simple function calculating the IV based on other attributes not known to the attacker. An example of such a design is the encrypted salt-sector IV (ESSIV) [4]. The IV is generated by encryption of the sector number. It is encrypted using the same block cipher as for sector encryption just with the key derived from the volume key using a hash function. If we have n as a sector number (padded by zero to the required length),

K as a volume key, Kiv as the derived key, E encryption function of the block cipher and H as a, hash function (where hash size can be used as key size for E) then ESSIV is defined as

Kiv = H(K),

IVn = E(Kiv,n).

ESSIV does not need an additional information, the Kiv is simply derived from the volume key.

11 2. STATE-OF-THE-ART RESEARCH

Another example is the IV calculation used in BitLocker [16], where the IV is calculated simply as encryption of the sector number with the same key as used for data encryption

IVn = E{K,n). (2.2)

Yet another example that uses additional encryption key is TrueCrypt in the CBC mode. Here the IV is calculated as

IVn = {n\\n)®Ky (2.3)

where 11 is a simple concatenation operation, © is the XOR operation and

the key Kiv is provided externally. This IV construction is known to be not secure (with a properly aligned consecutive sectors we know which bits in n will change and with a properly formatted first block in the sector we can create a special detectable pattern in ciphertext).

2.4.4 Wide encryption modes

There are several wide-block encryption modes that operates sector-wise (the whole sector changes on a random plaintext change). As an example, EME (ECB-mix-ECB) is a cipher mode developed by Halevi and Rogaway [23]. EME consist of 5 stages with two encryption phases and 3 complete data traversals. The IEEE 1619.3 standard proposal (not updated for several years) contains a draft of EME2 block mode [24]. Another wide-block mode CMC (CBC-mask-CBC) by the same authors is based on the CBC mode (reusing possible existing CBC implementation) [25]. Unlike EME, the CMC is not parallelizable. Due to performance reasons (time cost of at least a two-pass encryp• tion) and patent status wide-block modes are not yet widely used in sector encryption applications.

2.4.5 Integrity protection and authenticated modes

Integrity protection assures that data were not tampered with and that all attempts of tampering are detected [26]. The authentication is then built on top of integrity protection (if content is not altered it was created by the authenticated user). In the context of block encryption it usually means using a separate integrity layer or an authenticated block-encryption mode. In both cases it also means additional storage space requirement for storing sector integrity information (or authentication tags). The major question is

12 2. STATE-OF-THE-ART RESEARCH

on which layer the integrity protection should be applied. If it is placed at the upper filesystem layer then it can save a lot of operations as the filesystem knows what data are really used, so it does not need to waste time with verification of unused sectors. If it is at the sector encryption layer, it is fully transparent and integrity protection can be integral part of the cipher mode (but wasting time for integrity protection of the unused space). An example of authenticated mode is Galois Counter Mode (GCM). GCM is using the encrypt-then-authenticate scheme and utilizing a hash function for the authentication tag [27]. There are more ways how to provide an integrity protection at the sector level. One option is to place another layer on top or below sector encryption that validates additional integrity data. One such solution is dm-verity used in secure boot for Google's Chrome- books and recent Android systems [28]. This layer has a pre-computed tree of hashes (Merkle tree) of fixed-size blocks (the device itself is read-only in normal operation). The top-level hash (root hash) is verified by a public key stored on the device. While dm-verity provides integrity protection only (anyone can recompute hash tree, there is no secret key) the top level hash is signed. This operation adds authentication (only a user with the valid private key can sign the root hash). Another example is the GELI encryption system in FreeBSD that uses integrity protection layer in parallel with sector encryption [29]. The trick to get additional space for integrity data is to use different (larger) sector presented to the upper layer while using smaller sectors on the device. A hash message authentication code (HMAC) of data is used for integrity protection and HMAC is stored in the same (smaller) sector. Several sectors are then combined, decrypted, verified and presented to upper layer as one atomic sector of larger size. The downside of this is of course a smaller data device (with a larger sector) presented to the system.

2.5 Key storage and management

Encryption key is the secret that should guarantee confidentiality in FDE systems. Initially, the volume key is generated by using a random number generator (RNG) or it is derived from a passphrase. Key management should provide a reliable way for a key manipulation while still providing enough comfort for the user. There are many hardware devices helping to solve this problem - tokens, smartcards, Trusted Platform Modules (TPMs). For example BitLocker key scheme allows to unlock the same device by a passphrase combined with

13 2. STATE-OF-THE-ART RESEARCH

TPM or token (multi-factor authentication) or alternatively using recovery password [5]. A common way for authentication is still a password (or passphrase) and it seems that this is not going to change in the next years [30]. Moreover, software-based encryption works with common drives that do not contain any special encryption and key storage capabilities. The goal in a software-based FDE is to provide a secure system even if using only these common drives and without any help of a specialized hardware.

2.5.1 How to store volume key

The encryption key can be stored on the encrypted device itself (or on different but common storage media) in a special area (metadata area or header) encrypted with a different key. We are creating a key-hierarchy system here, one key is stored as data in another encryption. An example of a simple key-hierarchy system is TKS1 defined by Fruhwirth for the LUKS encryption system [31]. Key hierarchy systems allow to change a passphrase without a change to the volume encryption key. Validity of a decrypted candidate volume key can be verified by using fingerprint (LUKS, BitLocker) or by searching for a known signature (TrueCrypt) in the decrypted metadata

The metadata on-disk can contain visible signature (in this case is clearly detectable that device uses encryption) or it can be encrypted in such way that without a key it should not be possible to detect that an encryption is in place. Metadata without signature can be used to build deniable encryption storage systems. Deniable encryption [32] (also named plausibly deniable encryption) in FDE is often a simple steganographic technique for hiding an encrypted device inside a so-called decoy device. This allows users to provide decoy keys (in a plausible manner) when someone seized his device, but the confidential data are still stored on the hidden device. An example of a plausibly deniable encrypted device is the hidden disk in TrueCrypt (or hidden operating system that is just an extension of this basic concept) and was analyzed in [33]. It makes use of a trivial linear allocation strategy in FAT filesystem that allows hide another encrypted volume inside unused continuous space. According to the provided passphrase the system unlocks either the decoy or the hidden volume. There are several shortcomings. The first is dependence on the filesystem type (hidden device cannot be used on modern filesystems like NTFS that stores internal metadata backups

14 2. STATE-OF-THE-ART RESEARCH

spread out the whole volume). Even using FAT for a decoy volume could be suspicious today. The second shortcoming is that SSDs with TRIM treat the whole hidden disk area as unused (from the decoy volume point of view) and the first issued TRIM command destroys the hidden drive. Another recent design of a plausible deniable storage on a mobile platform (Android) is Mobiflage [34]. Its design supports more hidden (or decoy hidden) volumes. A special case of storing the key is depositing the key to an authenticated third party (held in escrow, sometimes called as key escrow). Such stored key will recover access to the device in the situation when a user forgets the password, the authentication device is lost or an administrator needs to access the device without a user interference.

2.5.2 Password-based key derivation functions

When the volume key is stored in a key-hierarchy system, the unlocking key (in key-hierarchy the key which encrypts the volume key) can be derived from a user passphrase by password-based key derivation function (PBKDF) [35]. PBKDF is an algorithm that produces an output directly usable as a cryptographic key from a secret password or passphrase (and from other public attributes). The main goal of PBKDF is to increase complexity of key search attacks (dictionary attacks to password). The password or passphrase is provided by the user and as such has usually bad randomness characteristic and low entropy. (While here we mention password or passphrase, PBKDF can have another key on input.) For the FDE case, unlocking can be an offline process (common use case is a fully encrypted laptop, the user has to provide his password before the network is even initialized). PBKDF runs always on the user's machine and is limited by the available resources there. The attacker can use any resource he can afford. The cost of attack has also economic property - if the attack requires a lot of energy, it can slow down attacker significantly [36]. The most used (and the only one based on standardization document) PBKDF is PBKDF2 [37]. PBKDF2 can be defined as

K = PBKDF2(PRF, password, salt, iterations, Kiength), (2-4)

where K is derived key of length Kiength- PRF is a pseudo-random function (HMAC based on a hash function), password is the secret information provided by the user and salt is a public cryptographic salt with purpose to avoid building dictionary of precomputed hashes (rainbow tables). The iterations

15 2. STATE-OF-THE-ART RESEARCH

parameter specifies how many times the process repeats until the K is provided. Increasing iterations implies increasing work (and time) needed for de• riving the key. The PBKDF2 is designed to be not internally parallelizable. Iteration attribute should be set to as high as it can be tolerated for the environment and acceptable for the user [35]. The main downside of PBKDF2 is a constant (and small) memory foot• print during the whole operation. This allows an attacker to use massive parallel systems like graphics processing units (GPUs) or application-specific integrated circuit (ASIC) to speed up dictionary search [38]. The problems with no longer suitable PBKDF2 lead to proposal of new PBKDF algorithms. The first one was scrypt [39, 40]. Scrypt introduces the concept of sequential memory-hard algorithms (which try to use as much memory as possible for a given number of operations and also that it cannot be computed on parallel systems more efficiently). The goal is to make the parallel attacks more expensive.

2.5.3 Password hashing competition

The lack of adequate standardized algorithms is not only a problem for PBKDFs, but also for services for password protection (online services). To invite more algorithm candidates, the Password Hashing Competition (PHC) was started as an effort of independent panel of experts [41]. The main goal of the competition is to identify and analyze new password hashing schemes (that would also not be patent encumbered). Key derivation for disk encryption application is also intended use of these algorithms, but it is not the main focus of the competition. There were 24 candidates submitted (2 of them were later withdrawn) and for the second round of evaluation 9 candidates are selected [42]. A comparison of candidates is available in [43]. Candidates for the second round are shortly introduced below. A generic requirement in PHC was to provide a parametrized scheme to fine-tune resources used during calculation. Most of the candidates separated attributes for memory complexity and computation time. Argon [44] is based on permutation implemented as 5-round AES-128 function. (The submitted version is tightly bound to AES block cipher internals. The design allows to use another permutation function, the authors mention it as a possible future extension.) Argon can be used as a KDF.

16 2. STATE-OF-THE-ART RESEARCH

Battcrypt [45] uses the Blowfish block cipher and the SHA-512 hash function. The goal is to construct a memory-hard algorithm based on Blowfish. Battcrypt can be used as a KDF just with slight modifications. Catena [46] is based on an underlying generic cryptographic hash primitive and the Bit Reversal Graph structure (BRG). The parameters include garlic (tweaks time and memory) and pepper (tweaks time). KDF is implemented as different mode of operation named Catena-KG. Lyra2 [47] is based on a sponge function that operates in the stateful mode as a strictly sequential process. It can be used also as a KDF. Makwa [48] is not designed to be a memory-hard algorithm. It introduced the idea of delegation - the part of the computation can be delegated to untrusted systems. Parallel [49] submission is based on the SHA-512 hash function. It uses a simple design comparable to PBKDF2. KDF use requires a slight modification. POMELO [50] is a simple design that does not use any existing underlying cryptographic primitive. It is based on a simple non-linear feedback function and two random memory access functions. It is not usable directly as a KDF. PuSerhsh [51] is an extension of the bcrypt algorithm (which is based on Blowfish) and its main intent is to address known problems in bcrypt. It is usable KDF. Yescrypt [52] is an extension of scrypt with improved scalability and possible hash upgrades option (computed password hash can be upgraded to use more resources without password knowledge). It can be used as a KDF. The future replacement of PBKDF in FDE applications by some of the proposed candidates is currently an important issue for research (as shown in [38] and [30], PBKDF2 is not able to effectively defend against massive parallel password searches).

17 3 Planned future research

The goal for our research is to analyze and describe certain known problematic areas of existing full disk encryption design and propose modification or even novel approach to the identified problems. We have started with the evaluation of the TrueCrypt FDE encryption system. The whole format was already fully analyzed, reimplemented and integrated to open-source cryptsetup1 project. A summarizing article of our work was published in IEEE Security &i Privacy [53]. We have investigated several issues in the TrueCrypt format history, including the vulnerable CBC encryption mode (that allowed the watermarking attack to reveal the hidden disk existence), questionable use of non-cryptographic algorithms in deriving the unlocking key (key file processing). We also discussed how block ciphers and modes have been evaluated and gradually replaced by new algorithms (illustrating state-of-the-art in FDE in recent years). The unexpected end of development of this project on May 2014 just underlines the need of truly open design solutions in this area. We will also use our extensive experience with maintaining cryptsetup and its kernel counterpart dm-crypt2 (these tools are used as a native FDE solution in most Linux distributions). For the PHC algorithm candidates, we have started to evaluate usability for proof-of-concept implementation in FDE systems, the current tests covers several basic parameters [54]. The availability of massive parallel systems (GPU usable for these attacks is on many desktop computers today) and largely scalable distributed com• puting present a challenge for FDE key storage algorithms (recent example is cracking TrueCrypt keys [38]).

3.1 Considered issues in FDE

The major focus of our future work will be on designing a new key management system based on recent research in password hashing functions (and mainly the password-based key derivation function applications).

1. https://code.google.com/p/cryptsetup/ 2. https://code.google.com/p/cryptsetup/wiki/DMCrypt

18 3. PLANNED FUTURE RESEARCH

We have defined following requirements for the PBKDF function for FDE use, partially based on [30]:

• KDF must behave as a random function. Its output is not distin• guishable from a random fuction output and it is a one-way collision resistant function.

• It must be able to configure resources to use. Resources can be time of calculation, level of parallelism or amount of memory. It should allow for predictable runtime calculations (to benchmark the algorithm on the particular machine and select attributes which fit best).

• Configured resources should not significantly influence each other.

• Possible configurations should cover high variety of systems from embedded systems to high-end storage servers.3

• The algorithm must be able to take input (password) of any length.4

• Maximal output length (keys) should not be significantly limited.5

• Running time must be independent of input password length. While the large input passwords surely increase the running time, this increase should be marginal and must not provide any possible infor• mation about password attributes.

• Underlying cryptographic primitives should be upgradable, inter• changeable and should be available in common cryptographic libraries.

• Cryptographic algorithms should not be hard-coded in design to allow for future extensions.

• KDF should be friendly to user's system hardware in general while try to be unfriendly to attacker hardware (with respect to expected advances in hardware development in future).

• Algorithms must not be patent encumbered.

3. For example, KDF should not require floating point calculations or large memory that is not available on embedded systems. 4. Algorithm can implement this by applying a hash function on the input before internal KDF processing. 5. The output can produce several keys. The most complicated FDE password scheme today seems to be chaining cipher mode in TrueCrypt. It needs to produce 1536 bits of a concatenated key. Unlimited KDF output provides possibility to construct new key storage schemes.

19 3. PLANNED FUTURE RESEARCH

The next issue is extending FDE for usage of a wide-block encryption mode. A common complaint to XTS is that it does not hide enough loca• tion of small changes inside a sector. EME2 as the IEEE 1619.3 proposed wide-block algorithm was never used (and the draft proposal seems to be abandoned but not withdrawn). The patent status of EME2 appears to be not problematic [55]. Another issue is usage of an authenticated mode at the FDE level and to design and to implement reliable space for storing authentication tags. For example, GCM mode is already used at the filesystem level, the use in software-based FDE has not yet been studied to a sufficient detail. All proposed changes will be provided as an extension to the open-source LUKS system implementation with intention to incorporate it to widely used Linux FDE.

3.2 Research proposal

Future work will cover the following objectives:

1. Identification and description of KDF parameters and other issues (wide-mode, authentication) for FDE storage use according to require• ments described in 3.1 and also based on the analysis of existing FDE systems [53].

Definition of benchmarking and test evaluation criteria. Extension of own, already existing benchmarks [54]. Publication of findings.

Summer 2015

2. Selection of one or more KDF candidates and problem evaluation according to the proposed criteria.

Winter 2015

3. Proposal of design and implementation of a key management scheme using previously selected functions. Publication of the outputs. Spring/Summer 2016

4. Evaluation of the proposed design and implementation of solutions according to selected criteria. Publication of the solution architecture.

Winter 2016

Expected submission of dissertation: Spring/Summer 2017.

20 4 Summary of own results

I am a co-author of the following paper from the area of security:

• BROŽ, Milan and Václav MATYÁŠ. The TrueCrypt On-Disk Format - An Independent View. IEEE Security & Privacy, 2014, vol. 12, No 3, p. 74-77. ISSN 1540-7993. doi:10.1109/MSP.2014.60. IF 0.721 in 2013

I am the author of these local conference papers

• BROŽ, Milan. Šifrování disků a TrueCrypt (Disk Encryption and TrueCrypt). In Europen 2013 sborník příspěvků. Plzeň: EurOpen.cz, 2013. p. 117-128. ISBN 978-80-86583-26-6.

• BROZ, Milan. Šifrování disků (nejen) v Linuxu (Disk encryption (not only) in Linux). In Europen 2011 sborník příspěvků. Plzeň: EurOpen.CZ, 2011. p.57-68. ISBN 978-80-86583-22-8.

As the primary maintainer of the Linux FDE system (LUKS) I am actively participating in community discussions related to security topic. I successfully passed all attended courses, included Postgraduate seminar on IT security and cryptography (PA168), English for Academic Purposes (post-graduate) (VV041). The TrueCrypt research material was directly used in preparation of exercises Laboratory of security and applied cryptography II (PV204) course. I also supervise three bachelor theses (User interface for storage encryp tion application, Key derivation functions and their GPU implementation, Encrypted remote storage).

21 A Appendix

A.l Storage architecture

Operating systems use usually 64-bit linear address for sectors on block devices. Common sector sizes are 512 bytes or 4096 bytes (with prediction to grow up to 64 kilobytes in several years) [56]. Some drives intended for use in disk arrays provide special space for parity (typically 520-byte sector consisting of 512 bytes of data and 8 bytes for checksum).

A. 1.1 Rotational disks

Drives with rotational media (disks), called hard disk drives (HDDs), are still the most common persistent storage devices. A modern HDD usually consists of several rapidly rotating platters and an arm with read-and-write heads. The data are stored by magnetizing ferromagnetic material on the platters surface. Downside of rotational media is mainly caused by the mechanical nature of accessing sectors. Most notable is the seek time (time that an arm need to move to proper location on platters). There are also hybrid drives (drives combining rotational platters with smaller cache on non-volatile flash tech• nology). The non-rotational memory can be presented outside as a separate drive (dual-drive) or it is integrated into an internal drive caching strategy, these drives are called solid-state hybrid drives (SSHDs).

A. 1.2 Flash memory based storage

The flash memory is a non-mechanical and non-volatile memory. The core of flash memory are cells (NOR or NAND gates) that can persistently store information. For single-level cell (SLC) it is one bit, multi-level cells (MLC) can recognize multiple levels of electrical charge and store more than one bit in one cell. Also, the types of flash chips differ according to the intended use (by accessing times, erase times), different kind of chips are used in memory cards and in fast SSDs. Flash memory eliminates unpredictable seek time. The main downside of flash memory is the rewriting procedure. While cells can be read randomly (in byte or work granularity), they must be erased only by larger blocks. Rewriting a sector implies erasing a larger block followed by write of the changed sector (and all remaining data in the whole block).

22 Misalignment to internal flash block boundaries during a large write operations can significantly decrease data throughput. Various optimizations can be used to mitigate a slow erase procedure. Drive usually contains an additional spare area to keep pre-erased blocks. Also there is an interface that informs the drive that particular sectors are no longer used and can be erased in advance. This operation is called TRIM command for SSDs. Filesystems use TRIM operation to maintain high drive performance during the whole life-time. The number of block erase counts is limited by the used physical technology (memory wear). Drives use wear-leveling that distributes write operations uniformly across all cells to maximize life-time. The sector addressing used for an operating system block device is different than the internal representation of a flash storage. The addressing layer is called flash translation layer (FTL). FTL can be implemented inside the drive (most of SSDs and flash disks) or can be implemented or accessed in software (in specialized flash-friendly filesystems). In the second case there must be a low-level interface to allow a software access to internal physical layer.

A. 1.3 Network attached storage, block storage in cloud services

Storage attached remotely can provide direct access to a block device (the sector operations are routed to a storage controller). An example is iSCSI device. Large enterprise storage can also use a special dedicated storage area network (SAN). The Network Attached Storage (NAS) usually means IP-based file-sharing service [7]. For the cloud services, the situation is even more complicated. Various dis• tributed systems can provide access to the storage on various levels including distributed block storage. For performance reasons, there can be various layers that provides thin- provisioning (allocating only used sectors from common storage pool), dedu- plication services (the same data in various sectors are stored only once), virtual layers which provides snapshots in time (using copy-on-write logic) or cache layers.

23 Bibliography

[1] Trusted Computing Group. Storage Work Group Storage Security Subsystem Class: Opal, http://www.trustedcomputinggroup.org/ resources/storage_work_group_storage_security_subsystem_ class_opal, [online], accessed December 15, 2014, 2014.

[2] Tilo Müller and Felix Freiling. A Systematic Assessment of the Security of Full Disk Encryption. In Transactions on Dependable and Secure Computing (TDSC), volume PP, 2014. doi: 10.1109/TDSC.2014.2369041.

[3] Algorithms, key size and parameters report 2014. Techni• cal report, European Union Agency for Network and Informa• tion Security, November 2014. https://www.enisa.europa. eu/activities/identity-and-trust/library/deliverables/ algorithms-key-size-and-parameters-report-2014/.

[4] Clemens Fruhwirth. New methods in hard disk encryption. PhD the• sis, Institute for Computer Languages Theory and Logic Group Vi• enna University of Technology, 2005. http: //Clemens. endorphin. org/ publications.

[5] Jesse D. Kornblum. Implementing BitLocker Drive Encryption for Forensic Analysis. Digital Investigation, 5(3):75-84, March 2009. doi: http://dx.doi.Org/10.1016/j.diin.2009.01.001.

[6] Tilo Müller, Tobias Latzo, and Felix Freiling. Self-Encrypting Disks pose Self-Decrypting Risks: How to break Hardware-based Full Disk Encryption. Technical report, Friedrich-Alexander-Universität Erlangen-Nürnberg, 2012. https://wwwl.informatik.uni-erlangen. de/filepool/projects/sed/seds-at-risks.pdf, [online], accessed December 15, 2014.

[7] EMC Education Services. Information storage and management. Wiley Publishing, 2009. ISBN 978-0-470-29421-5.

[8] Shuichi Oikawa. Integrating memory management with a file system on a non-volatile main memory system. In Proceedings of the 28th Annual ACM Symposium on Applied Computing, SAC '13, pages 1589-1594, New York, NY, USA, 2013. ACM. ISBN 978-1-4503-1656-9. doi: 10. 1145/2480362.2480660. URL http://doi.acm.org/10.1145/2480362. 2480660.

24 [9] Feng Chen, Michael P. Mesnier, and Scott Hahn. A protected block device for persistent memory. In 30th Symposium on Mass Storage Systems and Technologies (MSST), pages 1-12, June 2014. doi: 10.1109/ MSST.2014.6855541.

[10] Peter Gutmann. Secure deletion of data from magnetic and solid- state memory. In Proceedings of the 6th Conference on USENIX Se• curity Symposium, Focusing on Applications of Cryptography - Vol• ume 6, SSYM'96, pages 8-8, Berkeley, CA, USA, 1996. USENIX Association. URL http://dl.acm.org/citation.cfm?id=1267569. 1267577. Online version https: //www. cs .auckland.ac .nz/~pgut001/ pubs/secure_del.html, accessed December 30, 2014.

[11] Peter Gutmann. Data remanence in semiconductor devices. In Proceed• ings of the 10th Conference on USENIX Security Symposium - Volume 10, SSYM'01, Berkeley, CA, USA, 2001. USENIX Association. URL http://dl.acm.org/citation.cfm?id=1251327.1251331.

[12] American National Standards Institute. ANSI INCITS 482-2012, Infor• mation Technology - ATA/ATAPI Command Set - 2 (ACS-2), 2012.

[13] Michael Wei, Laura M. Grupp, Frederick E. Spada, and Steven Swanson. Reliably erasing data from flash-based solid state drives. In Proceed• ings of the 9th USENIX Conference on File and Stroage Technologies, FASTT1, pages 8-8, Berkeley, CA, USA, 2011. USENIX Association. ISBN 978-1-931971-82-9. URL http: //dl. acm. org/citation. cf m?id= 1960475.1960483.

[14] Phillip Rogaway. Evaluation of some blockcipher modes of operation. Technical report, University of California, Davis, February 2011. http: // web.cs.ucdavis.edu/~rogaway/papers/modes.pdf, [online], accessed December 15, 2014.

[15] Bruce Schneier. Applied Cryptography (2nd Ed.): Protocols, Algorithms, and Source Code in C. John Wiley & Sons, Inc., New York, NY, USA, 1995. ISBN 0-471-11709-9.

[16] Niels Ferguson. AES-CBC + Elephant diffuser: A disk encryption algorithm for Windows Vista. Technical report, Microsoft Corporation, 2006. URL http://download.microsoft.eom/download/0/2/3/ 0238acaf-d3bf-4a6d-b3d6-0a0be4bbb36e/BitLockerCipher200608. pdf. [online], accessed December 15, 2014.

25 [17] Dan Rosendorf. Bitlocker: A little about the internals and what changed in Windows 8. http://spi.unob.cz/presentations/ 0 23-May/07-Rosendorfy 20They C2 / A0BitLockery C2y A0Schema.pdf, 0 0 0 0 0 [online], accessed December 15, 2014, May 2013.

[18] Morris J. Dworkin. SP 800-38E. Recommendation for Block Cipher Modes of Operation: The XTS-AES Mode for Confidentiality on Storage Devices. Technical report, National Institute of Standards & Technology, Gaithersburg, MD, United States, 2010.

[19] IEEE 1619-2007 - Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices, 2008.

[20] Phillip Rogaway. Efficient Instantiations of Tweakable Blockciphers and Refinements to Modes OCB and PMAC. In Advances in Cryptol- ogy - ASIACRYPT 2004, 10th International Conference on the The• ory and Application of Cryptology and Information Security, Jeju Is• land, Korea, December 5-9, 2004, Proceedings, volume 3329 of Lec• ture Notes in Computer Science, pages 16-31. Springer, 2004. doi: 10.1007/978-3-540-30539-2_2. URL http://www.iacr.org/cryptodb/ archive/2004/ASIACRYPT/426/426.pdf.

[21] Public Comments on the XTS-AES Mode, http://csrc.nist.gov/ groups/ST/toolkit/BCM/documents/comments/XTS/collected_XTS_ comments.pdf, [online], accessed December 15, 2014, 2008.

[22] Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno. Cryptography Engineering: Design Principles and Practical Applications. Wiley Pub• lishing, 2010. ISBN 978-0-470-47424-2.

[23] Shai Halevi and Phillip Rogaway. A parallelizable enciphering mode. In Topics in Cryptology - CT-RSA 2004, volume 2964 of Lecture Notes in Computer Science, pages 292-304. Springer Berlin Heidelberg, 2004. ISBN 978-3-540-20996-6. doi: 10.1007/978-3-540-24660-2_23. URL http://dx.doi.org/10.1007/978-3-540-24660-2_23.

[24] Shai Halevi. EME*: extending EME to handle arbitrary-length mes• sages with associated data. IACR Cryptology ePrint Archive, 2004: 125, 2004. URL http://dblp.uni-trier.de/db/journals/iacr/ iacr2004.html#Halevi04.

[25] Shai Halevi and Phillip Rogaway. A tweakable enciphering mode. In Ad• vances in Cryptology - CRYPTO 2003, 23rd Annual International Cryp• tology Conference, Santa Barbara, California, USA, August 17-21, 2003,

26 Proceedings, volume 2729 of Lecture Notes in Computer Science, pages 482-499. Springer, 2003. doi: 10.1007/978-3-540-45146-4_28. URLhttp: //www.iacr.org/cryptodb/archive/2003/CRYPT0/1385/1385.pdf.

[26] Gopalan Sivathanu, Charles P. Wright, and Erez Zadok. Ensuring data integrity in storage: Techniques and applications. In Proceedings of the 2005 ACM Workshop on Storage Security and Survivability, StorageSS '05, pages 26-36, New York, NY, USA, 2005. ACM. ISBN 1-59593-233-X. doi: 10.1145/1103780.1103784. URL http://doi.acm.org/10.1145/ 1103780.1103784.

[27] Morris J. Dworkin. SP 800-38D. Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. Techni• cal report, National Institute of Standards & Technology, Gaithersburg, MD, United States, 2007.

[28] Android Secure Boot, https://source.android.com/devices/tech/ security/secureboot/index.html, [online], accessed December 15, 2014, 2014.

[29] Pawel Jakub Dawidek. FreeBSD GELI encryption system, http://svnweb.freebsd.org/base/head/sys/geom/eli/g_eli_ integrity.c?view=co, [online], accessed December 15, 2014, 2011.

[30] Alexander Peslyak and Simon Marechal. Password secu• rity: past, present, future (with strong bias towards pass• word hashing), December 2012. URL http://www. openwall. com/presentations/Passwordsl2-The-Future-Of-Hashing/ Passwordsl2-The-Future-0f-Hashing.pdf. [online], accessed December 15, 2014.

[31] Clemens Fruhwirth. TKS1 - An anti-forensic, two level, and iterated key setup scheme, http://clemens.endorphin.org/publications, [on• line], accessed December 15, 2014, 2004.

[32] Ran Canetti, Cynthia Dwork, Moni Naor, and Rafail Ostrovsky. De• niable encryption. In CRYPTO, volume 1294 of Lecture Notes in Computer Science, pages 90-104. Springer, 1997. ISBN 3-540-63384-7. URL http://dblp.uni-trier.de/db/conf/crypto/crypto97.html# CanettiDN097.

[33] Alexei Czeskis, David J. St. Hilaire, Karl Koscher, Steven D. Gribble, Tadayoshi Kohno, and Bruce Schneier. Defeating Encrypted and De• niable File Systems: TrueCrypt V5.1a and the Case of the Tattling

27 OS and Applications. In Proceedings of the 3rd Conference on Hot Topics in Security, HOTSEC'08, pages 7:1-7:7, Berkeley, CA, USA, 2008. USENIX Association. URL http://dl.acm.org/citation.cfm?id= 1496671.1496678.

[34] Adam Skillen and Mohammad Mannan. On implementing deniable storage encryption for mobile devices. In NDSS. The Internet Soci• ety, 2013. URL http://dblp.uni-trier.de/db/conf/ndss/ndss2013. html#SkillenM13.

[35] Meltem Sonmez Turan, Elaine B. Barker, William E. Burr, and Lidong Chen. SP 800-132. Recommendation for Password-Based Key Derivation: Part 1: Storage Applications. Technical report, National Institute of Standards & Technology, Gaithersburg, MD, United States, 2010.

[36] Alex Biryukov, Dmitry Khovratovich, and Johann Grozschaedl. Tradeoff cryptanalysis of password hashing schemes. https://www.cryptolux. org/images/5/57/Tradeoffs.pdf, [online], accessed December 15, 2014, August 2014.

[37] Burt Kaliski. Pkcs #5: Password-based cryptography specification version 2.0. RFC 2898 (Informational), September 2000. URL http: //www.ietf.org/rfc/rfc2898.txt.

[38] Markus Durmuth, Tim Giineysu, Markus Kasper, Christof Paar, Tolga Yalcin, and Ralf Zimmermann. Evaluation of standardized password- based key derivation against parallel processing platforms. In Computer Security - ESORICS 2012, volume 7459 of Lecture Notes in Computer Science, pages 716-733. Springer Berlin Heidelberg, 2012. ISBN 978-3- 642-33166-4. doi: 10.1007/978-3-642-33167-1_41. URL http://dx.doi. org/10.1007/978-3-642-33167-1_41.

[39] Colin Percival and Simon Josefsson. The scrypt password-based key derivation function. RFC Draft, March 2013. URL http: //tools. ietf . org/id/draft-josefsson-scrypt-kdf-00.txt.

[40] Colin Percival. Stronger key derivation via sequential memory-hard functions, May 2009. URL http://www.tarsnap.com/scrypt/scrypt. pdf. [online], accessed December 15, 2014.

[41] Password hashing competition, 2014. URL https: //password-hashing. net/, [online], accessed December 15, 2014.

28 [42] Password hashing competition candidates, 2014. URL https:// password-hashing.net/candidates.html. [online], accessed Decem• ber 15, 2014.

[43] Christian Forler, Eik List, Stefan Lucks, and Jakob Wenzel. Overview of the candidates for the password hashing competition - and their resistance against garbage-collector attacks. Cryptology ePrint Archive, Report 2014/881, 2014. http://eprint.iacr.org/, [online], accessed December 15, 2014.

[44] Alex Biryukov and Dmitry Khovratovich. Argon vl: Password hashing scheme, April 2014. URL https://www.cryptolux.org/index.php/ Argon, [online], accessed December 15, 2014.

[45] Steven Thomas. battcrypt (Blowfish All The Things), March 2014. URL https://password-hashing.net/submissions/specs/ battcrypt-v0.pdf. [online], accessed December 15, 2014.

[46] Christian Forler, Stefan Lucks, and Jakob Wenzel. Catena : A memory- consuming password-scrambling framework. Cryptology ePrint Archive, Report 2013/525, 2013. http://eprint.iacr.org/, [online], accessed December 15, 2014.

[47] Leonardo C. Almeida, Ewerton R. Andrade, Paulo S. L. M. Barreto, and Marcos A. Simplicio Jr. Lyra: Password-based key derivation with tunable memory and processing costs. Cryptology ePrint Archive, Report 2014/030, 2014. http://eprint.iacr.org/, [online], accessed December 15, 2014.

[48] Thomas Pornin. The MAKWA Password Hashing Function, March 2014. URL https://password-hashing.net/submissions/specs/ Makwa-vO.pdf. [online], accessed December 15, 2014.

[49] Steven Thomas. Parallel, March 2014. URL https:// password-hashing.net/submissions/specs/Parallel-vO.pdf. [on• line], accessed December 15, 2014.

[50] Hongjun Wu. POMELO: A Password Hashing Algorithm, March 2014. URL https://password-hashing.net/submissions/specs/ P0MEL0-vl.pdf. [online], accessed December 15, 2014.

[51] Jeremi M. Gosney. The pufferfish password hashing scheme, March 2014. URL https://password-hashing.net/submissions/specs/ Pufferfish-v0.pdf. [online], accessed December 15, 2014.

29 [52] Alexander Peslyak. yescrypt - a password hashing competition submission, March 2014. URL https://password-hashing.net/ submissions/specs/yescrypt-vO.pdf. [online], accessed December 15, 2014.

[53] Milan Brož and Václav Matyáš. The TrueCrypt On-Disk Format - An Independent View. IEEE Security & Privacy, 12, 2014. ISSN 1540-7993. doi: http://dx.doi.org/10.1109/MSP.2014.60.

[54] Milan Brož. Benchmarks of the PHC candidates, Novem• ber 2014. http://htmlpreview.github.io/?https://github.com/ mbroz/PHCtest/blob/master/output/index.html, [online], accessed November 11, 2014.

[55] Re: Cryptographic issues with SSD-technology and wide-block encryp• tion modes, February 2013. http: //article.gmane. org/gmane. linux. kernel.device-mapper.dm-crypt/6499, [online], accessed December 15, 2014.

[56] Theodore Ts'o. [LSF/MM TOPIC] really large storage sectors - go• ing beyond 4096 bytes. http://lwn.net/Articles/582881/, [online], accessed December 15, 2014, January 2014.