DOCSLIB.ORG

Perfectly Deniable Steganographic Disk Encryption

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Perfectly Deniable Steganographic Disk Encryption Perfectly Deniable Steganographic Disk Encryption Dominic Schaub, Ph.D.1 1Discrete Integration, Canada Black Hat Europe 2018 Outline Overview History VeraCrypt Appraisal 1 Overview Deniability • Steganography’s history and modern-day importance Requirements • Essentials Critical appraisal of True/VeraCrypt hidden-volume/OS feature Technical Requirements 2 Deniability Requirements System • Essential characteristics of steganographic disk encryption Design I Randomization/ • Technical requirements resulting from implementation Overwrites Concrete Implementation 3 System Design I System • Countering randomization & overwrites: error correction & caching Design II • Cascading Bootstrap Concrete implementation of error correction and caching Concrete Implementation 4 System Design II Forensic Con- • Overcoming steganography’s catch 22: a cascading bootstrap system siderations Multi-snapshot/FTL • Concrete Implementation Summary 5 Forensic Considerations • Multi-snapshot imaging & FTL analysis Steganography Overview Overview History VeraCrypt Appraisal • Steganography or steg (literally "covered writing") Deniability dates back to antiquity. It boils down to hiding a Requirements Essentials message in an innocuous cover; it’s a form of covert Technical Requirements communication System Design I • Cover can be a microdot (resembling a period), a JPEG Randomization/ Overwrites image of kittens, or even human hair... Concrete Implementation • Histories (440 BC) recounts how Histiaeus had a System Design II servant’s head shaved and scalp tattooed; he was Cascading Bootstrap Concrete sent off to deliver the secret message once his Implementation hair had regrown Forensic Con- siderations • We don’t do this anymore...I think? Multi-snapshot/FTL Summary • Nowadays steganography is usually digital...it’s faster than waiting for hair to regrow! Framework for Analyzing Cryptographic Systems Overview History VeraCrypt Appraisal Deniability Eve Requirements decrypt? Essentials Technical Requirements System Alice Bob Design I Randomization/ Overwrites Concrete Implementation System Design II ciphertext Cascading Bootstrap Concrete Implementation Forensic Con- siderations Multi-snapshot/FTL • Goals Summary • Alice & Bob: Communicate through unbreakable ciphertext • Eve: Break Alice and Bob’s encryption Framework for Analyzing Steganographic Systems Overview History Unfortunately, Alice and VeraCrypt Appraisal Bob relied on 3DES and Deniability detect? Requirements landed in jail... Essentials Technical 011 Requirements 001 System Design I Alice Warden Bob Randomization/ Overwrites Concrete Implementation System Design II Cascading Bootstrap Concrete hidden message under Implementation Forensic Con- innocent exchange siderations Multi-snapshot/FTL Summary • New Goals • Alice & Bob: Exchange secret messages that cannot be detected • Warden: Detect the presence of secret messages in cover Topical Applications of Steganography Overview History • Protection of journalists and their sources VeraCrypt Appraisal • Deniability Some countries have real protections for the press; most don’t Requirements • Essentials Protection of human rights observers and NGO staff Technical Requirements • Exfiltrating evidence of human rights abuses is risky; little chance violators System observe search/seizure/self-incrimination norms Design I Randomization/ • Protection against industrial espionage at border crossings Overwrites Concrete • Implementation Business travel often involves visits to countries that steal IP and System monitor/control networks (e.g. ban VPN connections) Design II • Cascading Bootstrap Deep uncover work Concrete Implementation • Agents working undercover can infiltrate/exfiltrate/conceal information, even Forensic Con- if they may be forced to surrender a password siderations Multi-snapshot/FTL Summary Encryption is adequate when there’s no risk of forced password disclosure. For everything else, use steganography! Common Digital Steganography Variants Overview History VeraCrypt Appraisal • Deniability Image/Video/Audio Steg (e.g. OpenStego, OpenPuff) Requirements • Essentials Hides information within e.g. lowest significant bit of pixels/samples Technical Requirements • 802.11 Wireless Steg (experimental) System • Conceals data in OFDM symbols; as per 802.11 standard, some frames Design I Randomization/ contain "random" data Overwrites Concrete • Implementation Disk Encryption/Filesystem Steg (e.g. StegFS, VeraCrypt) System • Allows information to be secreted in unused disk space Design II Cascading Bootstrap • Radio-frequency Steg (e.g. spread spectrum) Concrete Implementation • Transmit a signal beneath the background ‘noise floor’ Forensic Con- siderations Multi-snapshot/FTL Note for later: these all require special software (or hardware) Summary ...possibly a problem? Forensic Analysis Techniques Overview History VeraCrypt Appraisal 1 Comparison of suspected file against known original Deniability Requirements • Using a cover file from Google images is asking for trouble... Essentials Technical 2 Direct forensic analysis of (potential) cover media Requirements • System Embedding hidden information into e.g. a JPEG image often disturbs the Design I medium’s statistical characteristics Randomization/ Overwrites • Cat and mouse game between steganographic and steganalytic software’s Concrete Implementation statistical models (more sophisticated is better) System Design II 3 Forensic analysis of a computer system suspected of being used for Cascading Bootstrap steganographic activities Concrete Implementation • Searches for indirect evidence of steganography use Forensic Con- • siderations Might involve examination of temporary files, log files, swap space, etc. Multi-snapshot/FTL Summary The first two are classified as steganalysis Two Magical Ingredients Overview Plausible Deniability History VeraCrypt Appraisal Poor Good Deniability •No plausible explanation •Plausible explanation for Requirements cover medium BUT Essentials for cover medium AND Technical • Effective •Poor implementation = •Poor implementation = Requirements steganography easily detected with easily detected with System forensics forensics Design I depends on Randomization/ Overwrites combining two Concrete O X Y G E N O X Y G E N ¡ ! " £ $ % ^ & * ( ) - + + + + + + Implementation ¡ ! " £ $ % ^ & * ( ) - + + + + + + ¡ ! " £ $ % ^ & * ( ) - + home ¡ ! " £ $ % ^ & * ( ) - + home ctrl Q W E R T Y U I O P { } pgup magical ingredients ctrl Q W E R T Y U I O P { } pgup ctrl A S D F G H J K L : @ ~ pgdn ctrl A S D F G H J K L : @ ~ pgdn | Z X C V B N M < > ? ^ end | Z X C V B N M < > ? ^ end ctrl fn +Pity ctrl fn System Design II • Alone, neither Cascading Bootstrap •No plausible explanation •Plausible explanation for Concrete forensic resistance Resistance Forensic for cover medium DESPITE cover medium AND Implementation nor plausible •Good, undetectable •Good, undetectable Forensic Con- implementation implementation siderations deniability offer Multi-snapshot/FTL effective protection Summary "Enjoy your O X Y G E N O X Y G E N ¡ ! " £ $ % ^ & * ( ) - + + + + + + home ¡ ! " £ $ % ^ & * ( ) - + ¡ ! " £ $ % ^ & * ( ) - + + + + + + ctrl Q W E R T Y U I O P { } pgup ¡ ! " £ $ % ^ & * ( ) - + home ctrl pgup ctrl A S D F G H J K L : @ ~ pgdn Q W E R T Y U I O P { } ctrl pgdn | Z X C V B N M < > ? ^ end A S D F G H J K L : @ ~ ctrl fn | Z X C V B N M < > ? ^ end stay" ctrl fn Good Poor Some Colorful History... Overview History VeraCrypt Appraisal Deniability Requirements Essentials Technical Requirements System Design I Randomization/ Overwrites Concrete Implementation System Design II Cascading Bootstrap Concrete Implementation Forensic Con- siderations Multi-snapshot/FTL Summary c. 1997 2004 2013 Block-Level Encryption Overview (VeraCrypt and LUKS/dm-crypt) Overview History VeraCrypt Appraisal e.g. /dev/sda Deniability Requirements e.g. Essentials MBR/GUID Technical Requirements /dev System /mapper EFI Design I Randomization/ /encrypted Encryption Overwrites Header Concrete Implementation OS / Encryption/ Encrypted System Data Design II Filesystem Decryption Cascading Bootstrap Concrete Implementation Forensic Con- siderations AES Multi-snapshot/FTL Summary used blocks correspond VeraCrypt’s Hidden Volume Feature Overview Cover Mode Head Hidden Mode History VeraCrypt Appraisal Encr OS / FS ENC/ Data Deniability DEC Requirements Essentials Technical /dev Requirements AES /dev/sda1 /mapper System /encrypted Design I Head Randomization/ Overwrites Encr /dev Concrete nd ENC/ Implementation 2 FS Data DEC /mapper System /super_secret Design II ENC/ Hidden Cascading Bootstrap AES DEC OS / FS Concrete cover Implementation /dev ? AES Forensic Con- /mapper /dev/sda2 siderations /encrypted2 hidden Multi-snapshot/FTL Summary • Forensic security is high...but • Is it plausible to have a second frozen partition...with TRIM disabled... on top of using VeraCrypt? Is " ? " random init data or something else? Conclusion: It’s Missing a Magical Ingredient Overview History VeraCrypt Appraisal Possible Explanations for Existence of Deniability Two VeraCrypt Partitions on Single Drive Requirements Essentials An adversary might ask why you created two VeraCrypt-encrypted Technical partitions on a single drive...you can provide, for example, one of the Requirements ' ' following explanations: System Design I Randomization/ Overwrites [A number of canned explanations that are not very convincing] Concrete Implementation from www.veracrypt.fr/en/VeraCrypt Hidden Operating System Design II System.html Cascading
Load more

Recommended publications
  • Oracle® Linux Administrator's Solutions Guide for Release 6
    Oracle® Linux Administrator's Solutions Guide for Release 6 E37355-64 August 2017 Oracle Legal Notices Copyright © 2012, 2017, Oracle and/or its affiliates. All rights reserved. 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 installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S.
    [Show full text]
  • Dm-X: Protecting Volume-Level Integrity for Cloud Volumes and Local
    dm-x: Protecting Volume-level Integrity for Cloud Volumes and Local Block Devices Anrin Chakraborti Bhushan Jain Jan Kasiak Stony Brook University Stony Brook University & Stony Brook University UNC, Chapel Hill Tao Zhang Donald Porter Radu Sion Stony Brook University & Stony Brook University & Stony Brook University UNC, Chapel Hill UNC, Chapel Hill ABSTRACT on Amazon’s Virtual Private Cloud (VPC) [2] (which provides The verified boot feature in recent Android devices, which strong security guarantees through network isolation) store deploys dm-verity, has been overwhelmingly successful in elim- data on untrusted storage devices residing in the public cloud. inating the extremely popular Android smart phone rooting For example, Amazon VPC file systems, object stores, and movement [25]. Unfortunately, dm-verity integrity guarantees databases reside on virtual block devices in the Amazon are read-only and do not extend to writable volumes. Elastic Block Storage (EBS). This paper introduces a new device mapper, dm-x, that This allows numerous attack vectors for a malicious cloud efficiently (fast) and reliably (metadata journaling) assures provider/untrusted software running on the server. For in- volume-level integrity for entire, writable volumes. In a direct stance, to ensure SEC-mandated assurances of end-to-end disk setup, dm-x overheads are around 6-35% over ext4 on the integrity, banks need to guarantee that the external cloud raw volume while offering additional integrity guarantees. For storage service is unable to remove log entries documenting cloud storage (Amazon EBS), dm-x overheads are negligible. financial transactions. Yet, without integrity of the storage device, a malicious cloud storage service could remove logs of a coordinated attack.
    [Show full text]
  • Kdump, a Kexec-Based Kernel Crash Dumping Mechanism
    Kdump, A Kexec-based Kernel Crash Dumping Mechanism Vivek Goyal Eric W. Biederman Hariprasad Nellitheertha IBM Linux NetworkX IBM [email protected] [email protected] [email protected] Abstract important consideration for the success of a so- lution has been the reliability and ease of use. Kdump is a crash dumping solution that pro- Kdump is a kexec based kernel crash dump- vides a very reliable dump generation and cap- ing mechanism, which is being perceived as turing mechanism [01]. It is simple, easy to a reliable crash dumping solution for Linux R . configure and provides a great deal of flexibility This paper begins with brief description of what in terms of dump device selection, dump saving kexec is and what it can do in general case, and mechanism, and plugging-in filtering mecha- then details how kexec has been modified to nism. boot a new kernel even in a system crash event. The idea of kdump has been around for Kexec enables booting into a new kernel while quite some time now, and initial patches for preserving the memory contents in a crash sce- kdump implementation were posted to the nario, and kdump uses this feature to capture Linux kernel mailing list last year [03]. Since the kernel crash dump. Physical memory lay- then, kdump has undergone significant design out and processor state are encoded in ELF core changes to ensure improved reliability, en- format, and these headers are stored in a re- hanced ease of use and cleaner interfaces. This served section of memory. Upon a crash, new paper starts with an overview of the kdump de- kernel boots up from reserved memory and pro- sign and development history.
    [Show full text]
  • Proceedings of the Linux Symposium
    Proceedings of the Linux Symposium Volume One June 27th–30th, 2007 Ottawa, Ontario Canada Contents The Price of Safety: Evaluating IOMMU Performance 9 Ben-Yehuda, Xenidis, Mostrows, Rister, Bruemmer, Van Doorn Linux on Cell Broadband Engine status update 21 Arnd Bergmann Linux Kernel Debugging on Google-sized clusters 29 M. Bligh, M. Desnoyers, & R. Schultz Ltrace Internals 41 Rodrigo Rubira Branco Evaluating effects of cache memory compression on embedded systems 53 Anderson Briglia, Allan Bezerra, Leonid Moiseichuk, & Nitin Gupta ACPI in Linux – Myths vs. Reality 65 Len Brown Cool Hand Linux – Handheld Thermal Extensions 75 Len Brown Asynchronous System Calls 81 Zach Brown Frysk 1, Kernel 0? 87 Andrew Cagney Keeping Kernel Performance from Regressions 93 T. Chen, L. Ananiev, and A. Tikhonov Breaking the Chains—Using LinuxBIOS to Liberate Embedded x86 Processors 103 J. Crouse, M. Jones, & R. Minnich GANESHA, a multi-usage with large cache NFSv4 server 113 P. Deniel, T. Leibovici, & J.-C. Lafoucrière Why Virtualization Fragmentation Sucks 125 Justin M. Forbes A New Network File System is Born: Comparison of SMB2, CIFS, and NFS 131 Steven French Supporting the Allocation of Large Contiguous Regions of Memory 141 Mel Gorman Kernel Scalability—Expanding the Horizon Beyond Fine Grain Locks 153 Corey Gough, Suresh Siddha, & Ken Chen Kdump: Smarter, Easier, Trustier 167 Vivek Goyal Using KVM to run Xen guests without Xen 179 R.A. Harper, A.N. Aliguori & M.D. Day Djprobe—Kernel probing with the smallest overhead 189 M. Hiramatsu and S. Oshima Desktop integration of Bluetooth 201 Marcel Holtmann How virtualization makes power management different 205 Yu Ke Ptrace, Utrace, Uprobes: Lightweight, Dynamic Tracing of User Apps 215 J.
    [Show full text]
  • Linux Kernal II 9.1 Architecture
    Page 1 of 7 Linux Kernal II 9.1 Architecture: The Linux kernel is a Unix-like operating system kernel used by a variety of operating systems based on it, which are usually in the form of Linux distributions. The Linux kernel is a prominent example of free and open source software. Programming language The Linux kernel is written in the version of the C programming language supported by GCC (which has introduced a number of extensions and changes to standard C), together with a number of short sections of code written in the assembly language (in GCC's "AT&T-style" syntax) of the target architecture. Because of the extensions to C it supports, GCC was for a long time the only compiler capable of correctly building the Linux kernel. Compiler compatibility GCC is the default compiler for the Linux kernel source. In 2004, Intel claimed to have modified the kernel so that its C compiler also was capable of compiling it. There was another such reported success in 2009 with a modified 2.6.22 version of the kernel. Since 2010, effort has been underway to build the Linux kernel with Clang, an alternative compiler for the C language; as of 12 April 2014, the official kernel could almost be compiled by Clang. The project dedicated to this effort is named LLVMLinxu after the LLVM compiler infrastructure upon which Clang is built. LLVMLinux does not aim to fork either the Linux kernel or the LLVM, therefore it is a meta-project composed of patches that are eventually submitted to the upstream projects.
    [Show full text]
  • Container-Based Virtualization for Byte-Addressable NVM Data Storage
    2016 IEEE International Conference on Big Data (Big Data) Container-Based Virtualization for Byte-Addressable NVM Data Storage Ellis R. Giles Rice University Houston, Texas [email protected] Abstract—Container based virtualization is rapidly growing Storage Class Memory, or SCM, is an exciting new in popularity for cloud deployments and applications as a memory technology with the potential of replacing hard virtualization alternative due to the ease of deployment cou- drives and SSDs as it offers high-speed, byte-addressable pled with high-performance. Emerging byte-addressable, non- volatile memories, commonly called Storage Class Memory or persistence on the main memory bus. Several technologies SCM, technologies are promising both byte-addressability and are currently under research and development, each with dif- persistence near DRAM speeds operating on the main memory ferent performance, durability, and capacity characteristics. bus. These new memory alternatives open up a new realm of These include a ReRAM by Micron and Sony, a slower, but applications that no longer have to rely on slow, block-based very large capacity Phase Change Memory or PCM by Mi- persistence, but can rather operate directly on persistent data using ordinary loads and stores through the cache hierarchy cron and others, and a fast, smaller spin-torque ST-MRAM coupled with transaction techniques. by Everspin. High-speed, byte-addressable persistence will However, SCM presents a new challenge for container-based give rise to new applications that no longer have to rely on applications, which typically access persistent data through slow, block based storage devices and to serialize data for layers of block based file isolation.
    [Show full text]
  • A Linux Kernel Scheduler Extension for Multi-Core Systems
    A Linux Kernel Scheduler Extension For Multi-Core Systems Aleix Roca Nonell Master in Innovation and Research in Informatics (MIRI) specialized in High Performance Computing (HPC) Facultat d’informàtica de Barcelona (FIB) Universitat Politècnica de Catalunya Supervisor: Vicenç Beltran Querol Cosupervisor: Eduard Ayguadé Parra Presentation date: 25 October 2017 Abstract The Linux Kernel OS is a black box from the user-space point of view. In most cases, this is not a problem. However, for parallel high performance computing applications it can be a limitation. Such applications usually execute on top of a runtime system, itself executing on top of a general purpose kernel. Current runtime systems take care of getting the most of each system core by distributing work among the multiple CPUs of a machine but they are not aware of when one of their threads perform blocking calls (e.g. I/O operations). When such a blocking call happens, the processing core is stalled, leading to performance loss. In this thesis, it is presented the proof-of-concept of a Linux kernel extension denoted User Monitored Threads (UMT). The extension allows a user-space application to be notified of the blocking and unblocking of its threads, making it possible for a core to execute another worker thread while the other is blocked. An existing runtime system (namely Nanos6) is adapted, so that it takes advantage of the kernel extension. The whole prototype is tested on a synthetic benchmarks and an industry mock-up application. The analysis of the results shows, on the tested hardware and the appropriate conditions, a significant speedup improvement.
    [Show full text]
  • Coreboot - the Free Firmware
    coreboot - the free firmware vimacs <https://vimacs.lcpu.club> Linux Club of Peking University May 19th, 2018 . vimacs (LCPU) coreboot - the free firmware May 19th, 2018 1 / 77 License This work is licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/. You can find the source code of this presentation at: https://git.wehack.space/coreboot-talk/ . vimacs (LCPU) coreboot - the free firmware May 19th, 2018 2 / 77 Index 1 What is coreboot? History Why use coreboot 2 How coreboot works 3 Building and using coreboot Building Flashing 4 Utilities and Debugging 5 Join the community . vimacs (LCPU) coreboot - the free firmware May 19th, 2018 3 / 77 Index 6 Porting coreboot with autoport ASRock B75 Pro3-M Sandy/Ivy Bridge HP Elitebooks Dell Latitude E6230 7 References . vimacs (LCPU) coreboot - the free firmware May 19th, 2018 4 / 77 1 What is coreboot? History Why use coreboot 2 How coreboot works 3 Building and using coreboot Building Flashing 4 Utilities and Debugging 5 Join the community . vimacs (LCPU) coreboot - the free firmware May 19th, 2018 5 / 77 What is coreboot? coreboot is an extended firmware platform that delivers a lightning fast and secure boot experience on modern computers and embedded systems. As an Open Source project it provides auditability and maximum control over technology. The word ’coreboot’ should always be written in lowercase, even at the start of a sentence. vimacs (LCPU) coreboot - the free firmware May 19th, 2018 6 / 77 History: from LinuxBIOS to coreboot coreboot has a very long history, stretching back more than 18 years to when it was known as LinuxBIOS.
    [Show full text]
  • Secure Cloud Storage with Client-Side Encryption Using a Trusted Execution Environment
    Secure Cloud Storage with Client-side Encryption using a Trusted Execution Environment Marciano da Rocha1 a, Dalton Cezane´ Gomes Valadares2;4 b, Angelo Perkusich3 c, Kyller Costa Gorgonio4 d, Rodrigo Tomaz Pagno1 e and Newton Carlos Will1 f 1Department of Computer Science, Federal University of Technology, Parana,´ Dois Vizinhos, Brazil 2Department of Mechanical Engineering, Federal Institute of Pernambuco, Caruaru, Brazil 3Department of Electrical Engineering, Federal University of Campina Grande, Campina Grande, Brazil 4Department of Computer Science, Federal University of Campina Grande, Campina Grande, Brazil Keywords: Intel SGX, Data Sealing, File Encryption, Confidentiality, Integrity, Secure Storage, Cloud Storage. Abstract: With the evolution of computer systems, the amount of sensitive data to be stored as well as the number of threats on these data grow up, making the data confidentiality increasingly important to computer users. Currently, with devices always connected to the Internet, the use of cloud data storage services has become practical and common, allowing quick access to such data wherever the user is. Such practicality brings with it a concern, precisely the confidentiality of the data which is delivered to third parties for storage. In the home environment, disk encryption tools have gained special attention from users, being used on personal computers and also having native options in some smartphone operating systems. The present work uses the data sealing, feature provided by the Intel Software Guard Extensions (Intel SGX) technology, for file encryption. A virtual file system is created in which applications can store their data, keeping the security guarantees provided by the Intel SGX technology, before send the data to a storage provider.
    [Show full text]
  • Arxiv:1907.06110V1 [Cs.DC] 13 Jul 2019 (TCB) with Millions of Lines of Code and a Massive Attack Enclave” of Physical Machines
    Supporting Security Sensitive Tenants in a Bare-Metal Cloud∗† Amin Mosayyebzadeh1, Apoorve Mohan4, Sahil Tikale1, Mania Abdi4, Nabil Schear2, Charles Munson2, Trammell Hudson3 Larry Rudolph3, Gene Cooperman4, Peter Desnoyers4, Orran Krieger1 1Boston University 2MIT Lincoln Laboratory 3Two Sigma 4Northeastern University Abstract operations and implementations; the tenant needs to fully trust the non-maliciousness and competence of the provider. Bolted is a new architecture for bare-metal clouds that en- ables tenants to control tradeoffs between security, price, and While bare-metal clouds [27,46,48,64,66] eliminate the performance. Security-sensitive tenants can minimize their security concerns implicit in virtualization, they do not ad- trust in the public cloud provider and achieve similar levels of dress the rest of the challenges described above. For example, security and control that they can obtain in their own private OpenStack’s bare-metal service still has all of OpenStack in data centers. At the same time, Bolted neither imposes over- the TCB. As another example, existing bare-metal clouds en- head on tenants that are security insensitive nor compromises sure that previous tenants have not compromised firmware by the flexibility or operational efficiency of the provider. Our adopting a one-size-fits-all approach of validation/attestation prototype exploits a novel provisioning system and special- or re-flashing firmware. The tenant has no way to program- ized firmware to enable elasticity similar to virtualized clouds. matically verify the firmware installed and needs to fully trust Experimentally we quantify the cost of different levels of se- the provider. As yet another example, existing bare-metal curity for a variety of workloads and demonstrate the value clouds require the tenant to trust the provider to scrub any of giving control to the tenant.
    [Show full text]
  • Detecting Exploit Code Execution in Loadable Kernel Modules
    Detecting Exploit Code Execution in Loadable Kernel Modules HaizhiXu WenliangDu SteveJ.Chapin Systems Assurance Institute Syracuse University 3-114 CST, 111 College Place, Syracuse, NY 13210, USA g fhxu02, wedu, chapin @syr.edu Abstract and pointer checks can lead to kernel-level exploits, which can jeopardize the integrity of the running kernel. Inside the In current extensible monolithic operating systems, load- kernel, exploitcode has the privilegeto interceptsystem ser- able kernel modules (LKM) have unrestricted access to vice routines, to modify interrupt handlers, and to overwrite all portions of kernel memory and I/O space. As a result, kernel data. In such cases, the behavior of the entire sys- kernel-module exploitation can jeopardize the integrity of tem may become suspect. the entire system. In this paper, we analyze the threat that Kernel-level protection is different from user space pro- comes from the implicit trust relationship between the oper- tection. Not every application-level protection mechanism ating system kernel and loadable kernel modules. We then can be applied directly to kernel code, because privileges present a specification-directed access monitoring tool— of the kernel environment is different from that of the user HECK, that detects kernel modules for malicious code ex- space. For example, non-executableuser page [21] and non- ecution. Inside the module, HECK prevents code execution executable user stack [29] use virtual memory mapping sup- on the kernel stack and the data sections; on the bound- port for pages and segments, but inside the kernel, a page ary, HECK restricts the module’s access to only those kernel or segment fault can lead to kernel panic.
    [Show full text]
  • DM-Relay - Safe Laptop Mode Via Linux Device Mapper
    ' $ DM-Relay - Safe Laptop Mode via Linux Device Mapper Study Thesis by cand. inform. Fabian Franz at the Faculty of Informatics Supervisor: Prof. Dr. Frank Bellosa Supervising Research Assistant: Dipl.-Inform. Konrad Miller Day of completion: 04/05/2010 &KIT – Universitat¨ des Landes Baden-Wurttemberg¨ und nationales Forschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu % I hereby declare that this thesis is my own original work which I created without illegitimate help by others, that I have not used any other sources or resources than the ones indicated and that due acknowledgment is given where reference is made to the work of others. Karlsruhe, April 5th, 2010 Contents Deutsche Zusammenfassung xi 1 Introduction 1 1.1 Problem Definition . .1 1.2 Objectives . .1 1.3 Methodology . .1 1.4 Contribution . .2 1.5 Thesis Outline . .2 2 Background 3 2.1 Problems of Disk Power Management . .3 2.2 State of the Art . .4 2.3 Summary of this chapter . .8 3 Analysis 9 3.1 Pro and Contra . .9 3.2 A new approach . 13 3.3 Analysis of Proposal . 15 3.4 Summary of this chapter . 17 4 Design 19 4.1 Common problems . 19 4.2 System-Design . 21 4.3 Summary of this chapter . 21 5 Implementation of a dm-module for the Linux kernel 23 5.1 System-Architecture . 24 5.2 Log suitable for Flash-Storage . 28 5.3 Using dm-relay in practice . 31 5.4 Summary of this chapter . 31 vi Contents 6 Evaluation 33 6.1 Methodology . 33 6.2 Benchmarking setup .
    [Show full text]