On Selected Issues of Full Disk Encryption

On Selected Issues of Full Disk Encryption

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).

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    31 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us