New Methods in Hard Disk Encryption

Total Page:16

File Type:pdf, Size:1020Kb

New Methods in Hard Disk Encryption New Methods in Hard Disk Encryption Clemens Fruhwirth <[email protected]> Institute for Computer Languages Theory and Logic Group Vienna University of Technology July 18, 2005 Abstract This work investigates the state of the art in hard disk cryptography. As the choice of the cipher mode is essential for the security of hard disk data, we discuss the recent cipher mode developments at two standardisation bodies, NIST and IEEE. It is a necessity to consider new developments, as the most common cipher mode – namely CBC – has many security problems. This work devotes a chapter to the analysis of CBC weaknesses. Next to others, the main contributions of this work are (1) efficient algorithms for series of multiplications in a finite field (Galois Field), (2) analysis of the security of password-based cryptography with respect to low entropy attacks and (3) a design template for secure key management, namely TKS1. For the latter, it is assumed that key management has to be done on regular user hardware in the absence of any special security hardware like key tokens. We solve the problems arising from magnetic storage by introducing a method called anti-forensic information splitter. This work is complemented by the presentation of a system implementing a variant of TKS1. It is called LUKS and it was developed and implemented by the author of this work. Contents Preface v 1 Introduction 1 2 Design ingredients 3 2.1 The many faces of n ........................ 3 2.2 Galois Field arithmetic . 4 2.3 Algorithms for GF(2η)....................... 9 2.4 Sequences of multiplications in GF(2η) . 11 2.5 Gray Code . 21 3 Cipher Modes 25 3.1 Traditional cipher modes and their shortcomings . 26 3.2 Modes for authentication . 30 3.3 Modes accepted for NIST consideration . 33 3.4 NIST: Authenticated Encryption modes . 37 3.5 NIST: Encryption modes . 45 3.6 SISWG . 47 3.7 NIST: Authentication modes . 53 3.8 Evaluating the modes for Hard Disk Encryption . 54 3.9 Summary of Cipher Modes . 56 3.10 Implementation Guide . 58 4 CBC attacks 59 4.1 Initialisation Vector Modes . 59 4.2 Content leak attack . 61 4.3 Watermarking . 65 4.4 Data modification leak . 67 4.5 Malleability . 68 4.6 Movable cipher blocks . 70 4.7 Threat models . 70 5 Password management 73 5.1 Key hierarchies for passwords . 73 5.2 Anti-forensic data storage . 75 5.3 Passwords from entropy weak sources . 79 5.4 TKS1: Template Key Setup 1 . 87 i 6 A tour of LUKS: Linux Unified Key Setup 91 6.1 Disk layout . 92 6.2 Semantics . 94 6.3 LUKS for dm-crypt . 99 A Mathematical supplements 101 Bibliography 107 List of Figures 2.6 Aligned optimise . 15 2.8 Aligned negative logic . 19 2.12 Reflexive Gray code . 22 3.1 CBC Mode . 27 3.2 CFB Mode encryption . 29 3.3 OFB Mode encryption . 30 3.4 CTR Mode encryption . 30 3.5 XCBC-MAC . 32 3.7 2D-Encryption Mode . 46 3.8 LRW-AES Mode . 48 3.10 EME Mode . 50 3.11 ABL4 . 51 4.1 The inflexion point of the collision function . 64 5.1 AFsplitter . 78 5.2 The worlds Top 500 supercomputers’ processing power . 83 5.5 TKS1 scheme . 88 5.6 TKS2 scheme . 89 List of Tables 2.5 The many faces of n . 12 2.7 binary difference table . 16 ii 2.11 Gray Code difference table . 21 5.3 Traversal times for an entire password domain . 86 5.4 Minimum password bits for different security requirements . 87 6.1 PHDR layout . 93 6.2 Key slot layout . 94 Listings 2.1 xtime: multiplication with x and modulo reduction . 9 2.2 base algorithm, xtime-version . 10 2.3 an implementable c’-recursion . 10 2.4 base algorithm, lookup table version . 11 2.5 alignment determination . 14 2.6 Single step via negative logic . 16 2.7 Base algorithm for negative logic . 17 2.9 carry prevention . 18 2.10 Multiplication sequence (hybrid) . 20 3.6 OMAC algorithm . 33 3.9 EME algorithm . 49 3.12 LRW encryption . 58 3.13 optimised EME algorithm, Encryption . 58 6.3 Partition initialisation . 95 6.4 Key setting . 97 6.5 Master key recovery . 98 iii Preface I got involved with hard disk cryptography for the first time in the year 2000. This was much too early, since the regular desktop processors were not able to fulfil my performance expectations. Two years later I repeated my attempt to encrypt my data by default, this time with loop-AES, a high performance encryption package for Linux. But due to its unrefined coding style, next to the author’s dislike for cooperation, the code was never included into any mainstream Linux project. I have always been a fan of integration. For my personal projects, I could say, I wanted my work to be part of something bigger and to be useful to the community. But to be honest, I cooperate with bigger projects like Linux distri- butions or the Linux kernel primarily, because it takes maintenance work away from me. Otherwise, I would have to reintegrate my work with all components when new versions are released. Therefore, I started to put my efforts into another crypto project, which was more likely to be included into mainstream Linux, named “kerneli”. With the advent of Linux 2.6 in 2003 and after having gained experience in how to lobby my code into the Linux kernel, cryptoloop was included into the new release, and the Linux users received a hard disk encryption ready kernel for the first time. cryptoloop was my port based on the loop back device driver from a former kerneli component. But the loop back driver had many unsolved problems attached, and half a year later Christophe Saout presented his superior dm-crypt implementation that was based on a new block device layer called device-mapper. Recognising this, I readjusted my road map and concentrated my efforts on dm-crypt. In the first quarter of 2004, Jari Ruusu, the author of loop-AES, imple- mented the water marking attack against the CBC on-disk format both – cryptoloop and dm-crypt – were using. The attack was not taken seriously, especially not by me, as Jari Ruusu had no good reputation and was known to spread more confusion than facts. After new threat models had shown that this attack can be relevant in some situations, I invented ESSIV to remedy the problem. Unfortunately, most Linux users were not well educated with respect to cryptography and were confused from the mixture of correct and unobjective claims Ruusu was still posting to the Linux mailing list. I started to write a full-disclosure document on all known problems my implementation had. The primary intention was to provide information to the Linux users. But this undertaking lead me much farer. I stumbled consecu- tively into the world of SISWG and their alternative cipher modes. Stunned by the variety of flaws I collected for CBC, I was eager to start using the new SISWG modes. Until now, I have submitted many patches to the Linux v vi PREFACE developers for implementing my favourite of the SISWG modes, LRW-AES. Unfortunately, the Linux kernel virtual memory subsystem is a pure disaster. I refused to create an unaesthetic workaround for its limitations, as my fellow developers requested, and so I stopped my development. Unless this problems are cleared up, there will be no working LRW implementation any time soon for Linux. In fact, there will be no other hard disk solution operating with a SISWG cipher mode any time soon, as my implementation efforts were the only attempt (known to me) to implement them. So, the user has no other option than to use CBC and its probably secure (or not) variants that are included with loop-AES and TrueCrypt. Probably more important than cipher modes is password management. A big step towards tighter security in this field is achieved with my own software I baptised LUKS. This paper presents the theoretic foundations of LUKS in Chapter 5, “Password Management”, and gives a tour of its concrete imple- mentation in Chapter 6. The following work founds on three years of practical experience with usage and programming of encryption systems. I implemented most of the advised solutions on my own, and some of them are already available with default installations. Contributions of this work 1. mathematical primer for Galois Field algorithms, 2. development of specialised algorithms for multiplicative sequences in Ga- lois Fields, 3. analysis of NIST cipher modes with respect to applicability for hard disk encryption, 4. presentation of the Anti-forensic Information Splitter, 5. development and analysis of a technological growth model for quantifying PBKDF2 security, 6. Template Key Setup 1 (TKS1), a guideline for designing secure key man- agement systems, 7. case study of a hard disk encryption system incorporating TKS1, namely Linux Unified Key Setup (LUKS). Acknowledgements I would like to thank Christophe Saout for his rock-stable dm-crypt imple- mentation, Herbert Valerio Riedel for being forthcoming in my early kerneli efforts, Ernst Molitor, Arno Wagner, James Hughes, Pascal Brisset, Grzegorz Kulewski, Ulrich Kuehn, and Adam J. Richter for reviewing the full-disclosure document of CBC, which is predecessor of Chapter 4, the anonymous commen- tator for pointing out an improvement concerning the last block of anti-forensic storage and Laszlo Hars for correcting the false hypothesis of independent prob- abilities in Chapter 4. Thanks to Peter Wilson, who created many useful LATEX vii packages. Without his work, this document would not look as nice.
Recommended publications
  • Taxonomy of Linux Kernel Vulnerability Solutions
    Taxonomy of Linux Kernel Vulnerability Solutions Serguei A. Mokhov Marc-Andre´ Laverdiere` Djamel Benredjem Computer Security Laboratory Computer Security Laboratory Computer Security Laboratory Concordia Institute for Concordia Institute for Concordia Institute for Information Systems Engineering Information Systems Engineering Information Systems Engineering Concordia University, Concordia University, Concordia University, Montreal, Quebec, Canada Montreal, Quebec, Canada Montreal, Quebec, Canada Email: [email protected] Email: ma [email protected] Email: d [email protected] Abstract—This paper presents the results of a case study on C programs in general, as well as statistics on their relative software vulnerability solutions in the Linux kernel. Our major importance. We also introduce a new methodology to track contribution is the introduction of a classification of methods used the patch solving a security issue based only on the contents to solve vulnerabilities. Our research shows that precondition validation, error handling, and redesign are the most used of the security advisory. methods in solving vulnerabilities in the Linux kernel. This The paper is organized as follows: we examine previous contribution is accompanied with statistics on the occurrence work that was done regarding Linux and C security in of the different types of vulnerabilities and their solutions that Section II, followed by a description of the methodology we observed during our case study, combined with example used in order to obtain the solutions to the vulnerabilities in source code patches. We also combine our findings with existing programming guidelines to create the first security-oriented Section III. Afterwards, in Section IV, we show our results, coding guidelines for the Linux kernel.
    [Show full text]
  • Cryptographic File Systems
    Cryptographic Filesystems Background and Implementations for Linux and OpenBSD Background ● Loop device primer ● Keys, cipher modes, salting, key hashing ● Journaling file systems and encrypted swap ● Offset, sizelimit, hard/soft block size paramters explained ● Issues with software suspend Loopback Primer /dev/hda1 losetup /dev/loop0 myloop.dat /dev/loop0 /dev/hda2 losetup /dev/loop1 \ /dev/hda2 Filesystem with various /dev/loop1 files and directories Loopback Primer G76g(*gF *^tF0OB( 6g)%)f5( /dev/loop0 *&(*6bP( Dear Bob, this is the message ● The loopback device supports cryptographic transforms ● Knowing the key reveals a filesystem within a normal file (or block device) Keys ● Encryption with user supplied key ● Encryption with hashed key – rmd160, sha256, sha384, sha512, ... ● Using multiple keys (typically 64) – every sector (512b) uses different key Basic block cipher modes ● Currently only ECB (Electronic Code Book) and CBC (Cipher Block Chaining) widely supported ● ECB directly encipher plaintext – Same plaintext block always encrypts to same ciphertext. Is considered weak. ● CBC uses the previous block as IV – Basically solves ECB's dictionary problem – Only provides very limited integrity Key iterations and salt ● Key can be hashed 1000 times – significantly slows down brute force attack on password ● Salt is a string appended to the password – slows down brute force attack on password – poor man's two factor authentication Journaling ● Fine on device backed loop device ● Avoid on file backed loop devices – The VM can write
    [Show full text]
  • Cryptographic File Systems Performance: What You Don't Know Can Hurt You Charles P
    Cryptographic File Systems Performance: What You Don't Know Can Hurt You Charles P. Wright, Jay Dave, and Erez Zadok Stony Brook University Appears in the proceedings of the 2003 IEEE Security In Storage Workshop (SISW 2003) Abstract interact with disks, caches, and a variety of other com- plex system components — all having a dramatic effect Securing data is more important than ever, yet cryp- on performance. tographic file systems still have not received wide use. In this paper we perform a real world performance One barrier to the adoption of cryptographic file systems comparison between several systems that are used is that the performance impact is assumed to be too high, to secure file systems on laptops, workstations, and but in fact is largely unknown. In this paper we first moderately-sized file servers. We also emphasize multi- survey available cryptographic file systems. Second, programming workloads, which are not often inves- we perform a performance comparison of a representa- tigated. Multi-programmed workloads are becoming tive set of the systems, emphasizing multiprogrammed more important even for single user machines, in which workloads. Third, we discuss interesting and counterin- Windowing systems are often used to run multiple appli- tuitive results. We show the overhead of cryptographic cations concurrently. We expect cryptographic file sys- file systems can be minimal for many real-world work- tems to become a commodity component of future oper- loads, and suggest potential improvements to existing ating systems. systems. We have observed not only general trends with We present results from a variety of benchmarks, an- each of the cryptographic file systems we compared but alyzing the behavior of file systems for metadata op- also anomalies based on complex interactions with the erations, raw I/O operations, and combined with CPU operating system, disks, CPUs, and ciphers.
    [Show full text]
  • I.MX Encrypted Storage Using CAAM Secure Keys Rev
    AN12714 i.MX Encrypted Storage Using CAAM Secure Keys Rev. 1 — 11/2020 Application Note Contents 1 Preface 1 Preface............................................1 Devices often contain highly sensitive information which is consistently at risk 1.1 Intended audience and scope......1 1.2 References...................................1 to get physically lost or stolen. Setting user passwords does not guarantee data 2 Overview......................................... 1 protection against unauthorized access. The attackers can simply bypass the 2.1 DM-Crypt......................................1 software system of a device and access the data storage directly. Only the 2.2 DM-Crypt accelerated by CAAM use of encryption can guarantee data confidentiality in the case where storage .....................................................2 media is directly accessed. 2.3 DM-Crypt using CAAM's Secure Key...............................................3 This document provides steps to run a transparent storage encryption at block 3 Hands-On........................................4 level using DM-Crypt taking advantage of the secure key feature provided 3.1 Installation....................................4 by i.MXs Cryptographic Accelerator and Assurance Module (CAAM). The 3.2 Usage...........................................6 document applies to all i.MX SoCs having CAAM module. The feature is not 3.3 Performance................................ 9 available on i.MX SoCs with DCP. 4 Revision History............................ 10 5 Appendix A. Configuration...........
    [Show full text]
  • Efficient Cache Attacks on AES, and Countermeasures
    J. Cryptol. (2010) 23: 37–71 DOI: 10.1007/s00145-009-9049-y Efficient Cache Attacks on AES, and Countermeasures Eran Tromer Computer Science and Artificial Intelligence Laboratory, Massachusetts Institute of Technology, 32 Vassar Street, G682, Cambridge, MA 02139, USA [email protected] and Department of Computer Science and Applied Mathematics, Weizmann Institute of Science, Rehovot 76100, Israel Dag Arne Osvik Laboratory for Cryptologic Algorithms, Station 14, École Polytechnique Fédérale de Lausanne, 1015 Lausanne, Switzerland dagarne.osvik@epfl.ch Adi Shamir Department of Computer Science and Applied Mathematics, Weizmann Institute of Science, Rehovot 76100, Israel [email protected] Communicated by Lars R. Knudsen Received 20 July 2007 and revised 25 June 2009 Online publication 23 July 2009 Abstract. We describe several software side-channel attacks based on inter-process leakage through the state of the CPU’s memory cache. This leakage reveals memory access patterns, which can be used for cryptanalysis of cryptographic primitives that employ data-dependent table lookups. The attacks allow an unprivileged process to attack other processes running in parallel on the same processor, despite partitioning methods such as memory protection, sandboxing, and virtualization. Some of our meth- ods require only the ability to trigger services that perform encryption or MAC using the unknown key, such as encrypted disk partitions or secure network links. Moreover, we demonstrate an extremely strong type of attack, which requires knowledge of nei- ther the specific plaintexts nor ciphertexts and works by merely monitoring the effect of the cryptographic process on the cache. We discuss in detail several attacks on AES and experimentally demonstrate their applicability to real systems, such as OpenSSL and Linux’s dm-crypt encrypted partitions (in the latter case, the full key was recov- ered after just 800 writes to the partition, taking 65 milliseconds).
    [Show full text]
  • E:\Ghcstop\AESOP Ghcstop Doc\Kernel\Ramdisk Howto\060405-Aesop2440-Ramdisk-Howto.Txt 200 06-04-06, 12:43:53오후 Aesop 2440 Kernel 2.6.13 Ramdisk Howto
    파일: E:\ghcstop\AESOP_ghcstop_doc\kernel\ramdisk_howto\060405-aesop2440-ramdisk-howto.txt 200 06-04-06, 12:43:53오후 aesop 2440 kernel 2.6.13 ramdisk howto - 20060406(까먹고 민방위 못간날...^^) by godori 1. kernel설정을 다음과 같이 바꾼다. Device Drivers -> Block device쪽을 보시면.... Linux Kernel v2.6.13-h1940-aesop2440 Configuration qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq Block devices qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk x Arrow keys navigate the menu. <Enter> selects submenus --->. x x Highlighted letters are hotkeys. Pressing <Y> includes, <N> excludes, x x <M> modularizes features. Press <Esc><Esc> to exit, <?> for Help, </> x x for Search. Legend: [*] built-in [ ] excluded <M> module < > module x x lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk x x x < > XT hard disk support x x x x <*> Loopback device support x x x x < > Cryptoloop Support x x x x <*> Network block device support x x x x < > Low Performance USB Block driver x x x x <*> RAM disk support x x x x (8) Default number of RAM disks x x x x (8192) Default RAM disk size (kbytes) x x x x [*] Initial RAM disk (initrd) support x x x x () Initramfs source file(s) x x x x < > Packet writing on CD/DVD media x x x x IO Schedulers ---> x x x x < > ATA over Ethernet support x x x x x x x x x x x x x x x x x x x mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj x tqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqu x <Select> < Exit > < Help > x mqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqj 여기서 8192 는 ramdisk size 입니다 . 만드는 ramdisk 크기에 맞게끔 바꿔주시고... File systems쪽에서 Linux Kernel v2.6.13-h1940-aesop2440 Configuration qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq lqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq File systems qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqk x Arrow keys navigate the menu.
    [Show full text]
  • Comparison of Disk Encryption Software 1 Comparison of Disk Encryption Software
    Comparison of disk encryption software 1 Comparison of disk encryption software This is a technical feature comparison of different disk encryption software. Background information Name Developer First released Licensing Maintained? ArchiCrypt Live Softwaredevelopment Remus ArchiCrypt 1998 Proprietary Yes [1] BestCrypt Jetico 1993 Proprietary Yes BitArmor DataControl BitArmor Systems Inc. 2008-05 Proprietary Yes BitLocker Drive Encryption Microsoft 2006 Proprietary Yes Bloombase Keyparc Bloombase 2007 Proprietary Yes [2] CGD Roland C. Dowdeswell 2002-10-04 BSD Yes CenterTools DriveLock CenterTools 2008 Proprietary Yes [3][4][5] Check Point Full Disk Encryption Check Point Software Technologies Ltd 1999 Proprietary Yes [6] CrossCrypt Steven Scherrer 2004-02-10 GPL No Cryptainer Cypherix (Secure-Soft India) ? Proprietary Yes CryptArchiver WinEncrypt ? Proprietary Yes [7] cryptoloop ? 2003-07-02 GPL No cryptoMill SEAhawk Proprietary Yes Discryptor Cosect Ltd. 2008 Proprietary Yes DiskCryptor ntldr 2007 GPL Yes DISK Protect Becrypt Ltd 2001 Proprietary Yes [8] cryptsetup/dmsetup Christophe Saout 2004-03-11 GPL Yes [9] dm-crypt/LUKS Clemens Fruhwirth (LUKS) 2005-02-05 GPL Yes DriveCrypt SecurStar GmbH 2001 Proprietary Yes DriveSentry GoAnywhere 2 DriveSentry 2008 Proprietary Yes [10] E4M Paul Le Roux 1998-12-18 Open source No e-Capsule Private Safe EISST Ltd. 2005 Proprietary Yes Dustin Kirkland, Tyler Hicks, (formerly [11] eCryptfs 2005 GPL Yes Mike Halcrow) FileVault Apple Inc. 2003-10-24 Proprietary Yes FileVault 2 Apple Inc. 2011-7-20 Proprietary
    [Show full text]
  • Block Devices and Volume Management in Linux
    Block devices and volume management in Linux Krzysztof Lichota [email protected] L i n u x b l o c k d e v i c e s l a y e r ● Linux block devices layer is pretty flexible and allows for some interesting features: – Pluggable I/O schedulers – I/O prioritizing (needs support from I/O scheduler) – Remapping of disk requests (Device Mapper) – RAID – Various tricks (multipath, fault injection) – I/O tracing (blktrace) s t r u c t b i o ● Basic block of I/O submission and completion ● Can represent large contiguous memory regions for I/O but also scattered regions ● Scattered regions can be passed directly to disks capable of scatter/gather ● bios can be split, merged with other requests by various levels of block layer (e.g. split by RAID, merged in disk driver with other disk requests) s t r u c t b i o f i e l d s ● bi_sector – start sector of I/O ● bi_size – size of I/O ● bi_bdev – device to which I/O is sent ● bi_flags – I/O flags ● bi_rw – read/write flags and priority ● bi_io_vec – memory scatter/gather vector ● bi_end_io - function called when I/O is completed ● bi_destructor – function called when bio is to be destroyed s t r u c t b i o u s a g e ● Allocate bio using bio_alloc() or similar function ● Fill in necessary fields (start, device, ...) ● Initialize bio vector ● Fill in end I/O function to be notified when bio completes ● Call submit_bio()/generic_make_request() ● Example: process_read() in dm-crypt O t h e r I / O s u b m i s s i o n f u n c t i o n s ● Older interfaces for submitting I/O are supported (but deprecated),
    [Show full text]
  • Unbreakable Enterprise Kernel Release Notes for Unbreakable Enterprise Kernel Release 6 Update 1
    Unbreakable Enterprise Kernel Release Notes for Unbreakable Enterprise Kernel Release 6 Update 1 F35561-04 May 2021 Oracle Legal Notices Copyright © 2020, 2021 Oracle and/or its affiliates. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software" or "commercial computer software documentation" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract.
    [Show full text]
  • Cache Attacks and Countermeasures: the Case of AES 2005-08-14
    Cache Attacks and Countermeasures: the Case of AES 2005-08-14 Dag Arne Osvik1, Adi Shamir2 and Eran Tromer2 1 [email protected] 2 Department of Computer Science and Applied Mathematics, Weizmann Institute of Science, Rehovot 76100, Israel {adi.shamir, eran.tromer}@weizmann.ac.il Abstract. We describe several software side-channel attacks based on inter-process leakage through the state of the CPU’s memory cache. This leakage reveals memory access patterns, which can be used for cryptanalysis of cryptographic primitives that employ data-dependent table lookups. The attacks allow an unprivileged process to attack other processes running in parallel on the same processor, despite partitioning methods such as memory protection, sandboxing and virtualization. Some of our methods require only the ability to trigger services that perform encryption or MAC using the unknown key, such as encrypted disk partitions or secure network links. Moreover, we demonstrate an extremely strong type of attack, which requires knowledge of neither the specific plaintexts nor ciphertexts, and works by merely monitoring the effect of the cryptographic process on the cache. We discuss in detail several such attacks on AES, and experimentally demonstrate their applicability to real systems, such as OpenSSL and Linux’s dm-crypt encrypted partitions (in the latter case, the full key can be recovered after just 800 writes to the partition, taking 65 milliseconds). Finally, we describe several countermeasures which can be used to mitigate such attacks. Keywords: side-channel attack, cache, memory access, cryptanalysis, AES 1 Introduction 1.1 Overview Many computer systems concurrently execute programs with different privileges, employing vari- ous partitioning methods to facilitate the desired access control semantics.
    [Show full text]
  • I.MX Linux® User's Guide NXP Semiconductors
    NXP Semiconductors Document identifier: IMXLUG User Guide Rev. LF5.10.52_2.1.0, 30 September 2021 i.MX Linux® User's Guide NXP Semiconductors Contents Chapter 1 Overview............................................................................................... 6 1.1 Audience....................................................................................................................................6 1.2 Conventions...............................................................................................................................6 1.3 Supported hardware SoCs and boards..................................................................................... 6 1.4 References................................................................................................................................ 7 Chapter 2 Introduction........................................................................................... 9 Chapter 3 Basic Terminal Setup.......................................................................... 10 Chapter 4 Booting Linux OS................................................................................ 11 4.1 Software overview................................................................................................................... 11 4.1.1 Bootloader.................................................................................................................................12 4.1.2 Linux kernel image and device tree.........................................................................................
    [Show full text]
  • Linux Kernel Security Overview
    Linux Kernel Security Overview Kernel Conference Australia Brisbane, 2009 James Morris [email protected] Introduction Historical Background ● Linux started out with traditional Unix security – Discretionary Access Control (DAC) ● Security has been enhanced, but is constrained by original Unix design, POSIX etc. ● Approach is continual retrofit of newer security schemes, rather than fundamental redesign “The first fact to face is that UNIX was not developed with security, in any realistic sense, in mind; this fact alone guarantees a vast number of holes.” Dennis Ritchie, “On the Security of UNIX”, 1979 DAC ● Simple and quite effective, but inadequate for modern environment: – Does not protect against flawed or malicious code ● Linux implementation stems from traditional Unix: – User and group IDs – User/group/other + read/write/execute – User controls own policy – Superuser can violate policy “It must be recognized that the mere notion of a super-user is a theoretical, and usually practical, blemish on any protection scheme.” Ibid. Extended DAC ● POSIX Capabilities (privileges) – Process-based since Linux kernel v2.2 ● Limited usefulness – File-based support relatively recent (v2.6.24) ● May help eliminate setuid root binaries ● Access Control Lists (ACLs) – Based on abandoned POSIX spec – Uses extended attributes API Linux Namespaces ● File system namespaces introduced in 2000, derived from Plan 9. – Not used much until mount propagation provided more flexibility (e.g. shared RO “/”) – Mounts private by default ● Syscalls unshare(2) and
    [Show full text]