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 • Exﬁltrating 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 inﬁltrate/exﬁltrate/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 signiﬁcant 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 ﬂoor’ 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 ﬁrst two are classiﬁed 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 Forensic Resistance 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 Good 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 Bootstrap '' Concrete Implementation So, let me get this Forensic Con- straight... you're quoting a siderations Multi-snapshot/FTL website on data hiding to

Summary tell me you're not hiding anything?! Magical Ingredients with Steganographic Disk Encryption?

Overview History VeraCrypt Appraisal 1 Forensics: Encrypted hidden

Deniability data should masquerade as Requirements legitimate random data; hidden Essentials Technical system should never touch Requirements cover system (e.g. swap) System Design I Randomization/ Overwrites 2 Deniability: Cover system Concrete Implementation (e.g. Ubuntu) should appear

System completely normal. There Design II should be NO incriminating Cascading Bootstrap Concrete software visible. The cover Implementation

Forensic Con- system should appear, siderations bit-for-bit, as if it were installed Multi-snapshot/FTL with default settings* Summary Basic Idea: Conceal Data in Slack Space

Overview History VeraCrypt Appraisal

Deniability Requirements Essentials Technical e.g./dev/sda e.g./dev/sda Requirements System In use by OS In use by OS Design I Randomization/ Free ("slack") Free ("slack") Overwrites Concrete repurposed to Implementation store hidden System data Design II

Cascading Bootstrap bytes) 4096 (512 or Sectors Concrete Implementation { Forensic Con- siderations Multi-snapshot/FTL • In a system with FDE, slack space has been initialized with random data Summary • This random data can actually be the ciphertext of hidden data • Similar to VC hidden partition, but no restrictions on cover system Consequence 1: Concealed Data is Damaged

Overview History VeraCrypt Appraisal

Deniability Requirements e.g./dev/sda Essentials Technical Requirements In use by OS System Free ("slack") Design I repurposed to Randomization/ Overwrites store hidden Concrete data Implementation

System Design II Cascading Bootstrap Concrete Implementation Forensic Con- • Ongoing overwrites continually damage the underlying hidden data siderations Multi-snapshot/FTL • But for large hard drives, most slack space may never be overwritten! Summary • As the cover system (a default installation of Linux) acts completely normally, there is nothing suspicious about this picture Consequence 1.1: Concealed Data is Stored Diffused/Redundantly

Overview History VeraCrypt Appraisal Deniability diﬀuse Requirements Essentials "redundify" Technical Requirements

System Design I Randomization/ Overwrites Concrete Implementation

System Design II secret.doc secret.doc Cascading Bootstrap Concrete Implementation Forensic Con- e.g./dev/sda siderations Multi-snapshot/FTL Summary • To protect "secret.doc", add redundancy and diffuse across slack space • To recover "secret.doc", collect intact sectors and extract original ﬁle Consequence 2: Cover System Overwrites are Sacrosanct

Overview History VeraCrypt Appraisal

Deniability Requirements e.g./dev/sda Essentials Technical Requirements NEVER! In use by OS System Free ("slack") Design I Randomization/ repurposed to Overwrites store hidden Concrete Implementation data System Design II Cascading Bootstrap Concrete Implementation

Forensic Con- siderations • Sectors in current or previous use by the cover system must never be Multi-snapshot/FTL overwritten—This would corrupt cover OS and/or suggest that something ﬁshy is Summary going on • Hidden system must reliably detect sectors used by cover OS Consequence 3: Kernel Module is Incriminating

Overview Problem: Cover system Problem: Randomization & EC History overwrites hidden data kill performance VeraCrypt Appraisal Solution: Error Correction Solution: Kernel module with Deniability Requirements (EC) & Randomization deep cache that mitigates EC Essentials and randomization Problem: Kernel module Technical Requirements is really incriminating!

System Problem: Hidden system must Solution: Have the Design I respect cover-system overwrites system hide itself! Randomization/ Overwrites Solution: Sector hash checks by Concrete Implementation a kernel module

System Design II The problem factors into two relatively independent sub-problems: Cascading Bootstrap Concrete 1 Develop a kernel module that does error correction, randomization, caching, and Implementation

Forensic Con- detection of cover system writes siderations 2 Multi-snapshot/FTL Develop a set of tools that hide, extract, and load the kernel module in the most

Summary automated way possible (and without leaving a forensic trace) • For ﬂexibility, hidden data reads/writes should be to a block device Bird’s-eye View of a Running System

/dev/mapper/crypt Overview Cover System History VeraCrypt Appraisal Deniability Cover Requirements FS (ext4) dm-crypt Essentials OS /dev/sda cover Technical Requirements

System Only one system Design I runs at a given Randomization/ time Overwrites Hidden System /dev/mapper/crypt Concrete Implementation /dev/steg System Design II Cascading Bootstrap Hidden FS (ext4) Steg dm-crypt Concrete OS Implementation { hidden Forensic Con- Reserved sectors siderations accessible to Multi-snapshot/FTL userspace utility Summary • Blue boxes = kernel space; ext4 & device names are just examples Primer on Information Theory and Communication Channels

Overview History VeraCrypt Appraisal

Deniability Requirements Essentials Technical Requirements System H(X) Input Channel Output H(Y) Design I (Corrupted) Randomization/ Overwrites Concrete Implementation

System Design II Noise Cascading Bootstrap Concrete I(Y;X) = H(X) – H (Y|X) Implementation

Forensic Con- siderations • The mutual information, I(Y ; X), is related to the channel capacity Multi-snapshot/FTL

Summary • For example, given a binary alphabet, a transmission might look like:

0 1 1 0 1 0 1 0 0 1 0 0 1 1 1 0 From General Channels to the Binary Erasure Channel

Overview • History Many channel models exists: VeraCrypt Appraisal • Input/output symbols from discrete or continuous alphabets Deniability • Noise can be many forms (e.g. white Gaussian, bit ﬂips etc.) Requirements Essentials • Channel noise may also take the form of erasures Technical Requirements

System • Designating pe as the probability of 1 – pe Design I erasure, the Binary Erasure 0 0 Randomization/ Overwrites Channel p Concrete e Implementation X can be modeled as =⇒ pe System • input Design II X denotes erasure output Cascading Bootstrap • Mental note for later: pe is 1 1 Concrete Implementation assumed constant 1 – pe Forensic Con- • Transmission through a binary erasure channel might look like: siderations Multi-snapshot/FTL Summary 0 1 1 0 1 0 1 0 0 1 X 0 1 X 1 0 Primer on Forward Error Correction

Overview 1 1 History VeraCrypt Appraisal 0 X

Deniability 0 0 channel 0 0 Requirements 1 1 1 1 Essentials 0 0 0 0 Technical ! ! Requirements 1 1 X 1 encode System 1 1 1 decode 1 Design I 0 0 Reconstructed Randomization/ Data Overwrites 0 0 Concrete Implementation Original System Data Design II Corrupted Cascading Bootstrap Concrete Codeword Codeword Implementation Forensic Con- • siderations Basic idea: Add highly interwoven redundancy to correct most errors Multi-snapshot/FTL • Coding rate = size(data) / size(codeword) Summary • If the code is properly constructed for the channel, complete error correction should almost always be possible • There should not be any more redundancy than is necessary Low-Density Parity-Check (LDPC)

Overview History • An LDPC code can be described by its Tanner graph: VeraCrypt Appraisal

Deniability Requirements Check Nodes: Essentials Technical Requirements

System Design I Randomization/ Variable Nodes: Overwrites Concrete Implementation System • Nodes belong to an additive group (for GF(2n), "+" is just XOR) Design II Cascading Bootstrap • Regular (Irregular) codes have variable nodes of (non-)ﬁxed degree Concrete Implementation • A codeword might look like: Forensic Con- siderations Multi-snapshot/FTL 1 0 1 0 0 1 0 0 1 1 0 Summary Iterative Decoding Example

Overview History VeraCrypt Appraisal

Deniability Requirements Essentials Technical Requirements I. System • Decoding employs extremely Design I 2 Randomization/ fast Belief Propagation Overwrites 1 Concrete Implementation • Residual errors may be 1 System correctable with Gaussian II. Design II Cascading Bootstrap elimination (albeit at much Concrete Implementation reduced dimensionality) 4 Forensic Con- siderations Multi-snapshot/FTL 3 Summary III. 3 Importance of Randomization

Overview History VeraCrypt Appraisal Data with FEC checksum Deniability Requirements • Data is stored on the underlying device in Essentials Technical multiple independent coding blocks that Requirements include redundancy for error correction 1 1 System } } Design I Randomization/ • Overwrites A small number of overwrites might 2 2 Concrete } } Implementation irrecoverably damage a coding block if its System spatial arrangement is statistically similar to 3 3 Design II the overwriting process } } Cascading Bootstrap Concrete Implementation • E.g. Coding block 1 is damaged but 4 4 Forensic Con- } } siderations recoverable; coding block 2 cannot be Multi-snapshot/FTL recovered Pristine Damaged from Summary Overwrites Importance of Randomization (2)

Overview randomization derandomization History VeraCrypt Appraisal Damage is 1 1 Deniability } } beneath critical Requirements threshold for all Essentials Technical 2 2 coding blocks. Requirements } } System All data can FEC checksum 3 3 Design I } } now be Randomization/ Overwrites recovered with Concrete 4 4 through error Implementation } } correction! System

Design II Data Original, Randomized Randomized, Original, Cascading Bootstrap Pristine Pristine Damaged Damaged Concrete Implementation

Forensic Con- siderations • Randomization of data is equivalent to randomization of error Multi-snapshot/FTL • This means the pe (probability of erasure of a given datum) is constant across Summary all data • System is now described perfectly as a Binary Erasure Channel! Kernel Module Design

Overview /dev/mapper/crypt History Cover System VeraCrypt Appraisal

Deniability Requirements Essentials Cover FS (ext4) dm-crypt Technical OS /dev/sda Requirements cover System Design I Only one system Randomization/ Overwrites runs at a given Concrete Implementation Hidden System time /dev/mapper/crypt System Design II /dev/steg Cascading Bootstrap Concrete Implementation Hidden FS (ext4) Steg Subjectdm-crypt of Forensic Con- OS siderations hidden Multi-snapshot/FTL { Reserved sectors next slide Summary accessible to userspace utility Cache

1 thread Periodic several threads Sync Coding Blocks Service Block LDPC En/De- Coding Pending Blocks FIFO of coding Service Pending Block blocks scheduled for de/en-coding Block Load/Sync States, etc. Implemented as Sector Group FIFO queue Sector ErasureState Queue of sectors 1 thread In-Flight Requests DataState scheduled for I/O Request RecoveryState (dynamically sorted) Hash BIO Request Data 1+ threads Handler Request Disk I/O Coding Blocks are Service dynamically sorted OS by last access time OS Randomization Implementation

Overview History • Require an injective (1:1) function mapping each sector original VeraCrypt Appraisal pseudorandomly to another n-bit integer Deniability I : {1,..., n} → {1,..., n} Requirements pseudorand lower bits upper bits Essentials Technical Requirements • Can’t use a hash since it’s not 1:1 • System Can’t use LUT (2 TB drive = 16 GB LUT!) HASH Design I • Randomization/ Can’t use e.g. AES CTR mode, as block size is Overwrites 128 Concrete ﬁxed at 128 bits (n = 2 ) Implementation

System • Need a ﬂexible n that is not much bigger than actual Design II number of sectors of given hardware Cascading Bootstrap HASH Concrete Implementation • Use a Feistel network! Forensic Con- siderations • Two rounds and a simple hash is ﬁne; "adversary" is lower bits upper bits Multi-snapshot/FTL erasure noise, not a cryptanalyst Summary permutated • However, (balanced) Feistel network is still some power n-bit integer of 4....if we had 1777 sectors? Randomization Implementation (2)

Overview History VeraCrypt Appraisal Starting FirstValue IterationSecond Third • E.g. assume we require UpperLower Fourth Deniability {0,..., 10} → {0,..., 10} 11 11 15 Requirements pseudorand 11 10 14 Essentials (i.e. 11 sectors) Technical 11 01 13 Requirements 11 00 12 • Next largest balanced Feistel network System 10 11 11 Design I will implement 10 10 10 Randomization/ 10 01 9 Overwrites {0,..., 15} →pseudorand {0,..., 15} 10 00 8 Concrete Implementation (i.e. 16 instead) 01 11 7 01 10 6 System Design II • That’s ok; repeated iterations that 01 01 5 01 00 4 Cascading Bootstrap start in {0,..., 10} will always Concrete 00 11 3 Implementation return to {0,..., 10} 00 10 2 Forensic Con- 00 01 1 siderations • Usually this process is very fast; 00 00 0 Multi-snapshot/FTL average computational complexity is Summary constant

done: 3→done:1 6→2 done: 9→9 LDPC Implementation

Overview History HASH DATA erasure = [hash(DATA) != HASH] VeraCrypt Appraisal

Deniability 32B 480B = 3840b (boolean) Requirements Essentials Technical • Requirements Error correction are implemented as concatenation of two regular LDPC codes 3840 System with 480-byte integer nodes belonging to GF(2 ) Design I • Randomization/ Codes found via computational search that excised 2-, 4-, and 6- cycles Overwrites Concrete • Final codes were veriﬁed with binary erasure channel simulations and were found Implementation to be reasonably close to capacity achieving System Design II • Codes can easily be modiﬁed; concatenation has object-oriented implementation; Cascading Bootstrap Concrete a single coding block is ∼ 5 MB Implementation

Forensic Con- siderations Code Regularity #Check #Variable Deg Check Rate Multi-snapshot/FTL

Summary Outer Regular 5,100 5,100 6 50% Inner Regular 100 5,000 300 98% Combined N/A N/A N/A N/A 49% Deep Cache Implementation

Overview History • Default cache size is 320 coding blocks VeraCrypt Appraisal • Deniability Cache is periodically synced to disk when idle Requirements Essentials • Encoding/Decoding done in place by multiple concurrent threads Technical Requirements • Coding blocks have two status variables, load_state and sync_state System Design I that form 19-state space (SCB) and "dirtiness" fcns Randomization/ Overwrites • Complete space is 320 × , where captures queued req’s Concrete SCB SQ SQ Implementation • Very complex supervisory logic optimizes data access patterns and System Design II services requests as quickly as possible while minimizing accesses to Cascading Bootstrap Concrete base block device Implementation

Forensic Con- • Multiple coding blocks can (un)load simultaneously; data reads /writes are siderations interleaved via downstream elevator scheduler(s) Multi-snapshot/FTL Summary • Debugging multithreaded kernel-space asynchronous ﬁnite-state machine was a nightmare (what’s the LD50 of caffeine again?) Performance & SSD / HDD Variants

Overview History VeraCrypt Appraisal • Steg kernel module can be customized with extensive parameters that tune Deniability Requirements performance characteristics Essentials • Technical Some parameters, like SECTORS_PER_GROUP have many derivative Requirements parameters System Design I • Makefile allows selection between two predefined parameter sets: Randomization/ Overwrites • SSD: Assigns low value to SECTORS_PER_GROUP resulting in greater Concrete Implementation randomization of data and improved error correction System • HDD: Assigns a higher value to SECTORS_PER_GROUP resulting in more Design II Cascading Bootstrap "clumpy" data that is less randomized but generates fewer random seeks Concrete Implementation • So what does typical performance look like? Forensic Con- siderations Multi-snapshot/FTL Normal 4x PCIE Steg running Normal HDD Steg running Windows 95 Summary NVME machine>on 4x PCIE >machine >on HDD >machine NVME machine needing a machine defrag Reflexive Bootstrapping?

Overview History VeraCrypt Appraisal Hidden System /dev/mapper/crypt /dev/sda Deniability /dev/steg Requirements Essentials Technical Requirements Hidden FS (ext4) Steg dm-crypt System OS Design I hidden Randomization/ Overwrites Concrete steg.ko Implementation

System insmod steg.ko Design II Cascading Bootstrap Concrete Implementation • If we had a system that was already running, it would be simple: Forensic Con- siderations 1 Retrieve steg.ko (it’s just a ﬁle on the hidden system FS) Multi-snapshot/FTL 2 Load steg.ko into kernel with e.g. insmod Summary • If only things were so simple...(neverminding technicalities with FS) • How do we get around this catch 22? Leaving Aside the Steg LKM and Hidden System for a Moment...

Overview /dev/mapper/crypt /dev/sda History Hidden System VeraCrypt Appraisal /dev/steg steg.ko Deniability Requirements Essentials Hidden FS (ext4) Steg dm-crypt Technical OS Requirements steg.ko hidden System Design I Randomization/ Overwrites Concrete Implementation System • Could we store steg.ko LKM directly on the mapped crypt device? Design II Cascading Bootstrap • Problem: It will likely be at least partly overwritten, as LKM is ∼MB Concrete Implementation • Especially true for big ﬁles, as few large contiguous regions will exist Forensic Con- under the cover system, even if its disk use is sparse siderations Multi-snapshot/FTL • Could we just store the steg.ko kernel multiple times? Summary • Problem: Probability of a surviving intact copy might still be small • Problem: Even if one exists, how do we ﬁnd it? Repeatedly try running corrupted code in kernel space? (rhetorical question) What we could do instead...(i.e. a recursive bootstrap system)

Overview /dev/mapper/crypt /dev/sda History Hidden System VeraCrypt Appraisal /dev/steg Deniability Requirements Essentials Hidden FS (ext4) Steg dm-crypt Technical OS Requirements 2-sector hidden System ELF Design I (multiple Randomization/ copies) Overwrites Concrete Implementation System • Store multiple copies of a very short executable at regular intervals Design II Cascading Bootstrap • For lightly/moderately used cover, any one copy is likely intact and will Concrete Implementation execute perfectly! Execute in userspace (try again if needed) Forensic Con- siderations • What can you do with a 1-kB executable? Lots!! Multi-snapshot/FTL 1 Scan mapped crypt device for other shards of intact information; do Summary rudimentary error correction to recover original shards 2 Assemble shards into a new (much bigger) ELF and execute 3 Repeat...each time with more sophisticated error correction Overview of Hidden System Boot Sequence

Overview History User involvement VeraCrypt Appraisal

Deniability Requirements Cover Cover Early ELF ELF Hidden Hidden Final Essentials Bootloader Userspace Primary Secondary Early Target (e.g. Technical Requirements e.g. GRUB $ Bootstrap Bootstrap Userspace Graphical)

System Design I A user hits 'e' Using With primitive With The hidden Completely Randomization/ and adds cryptsetup, a error correction, sophisticated system's functional Overwrites 'break' to user copies the primary error correction, cryptographic system; Concrete Implementation kernel over a 2-sector bootstrap the secondary mapping and /etc/fstab command line ﬁle to tmpfs bootstrap steg kernel System extracts and has /dev/steg Design II } and executes executes a extracts and module is loaded entry instead of Cascading Bootstrap it larger, loads, via kexec, from a custom e.g. /dev/sda1 Concrete secondary a replacement hook from within Implementation bootstrap kernel and the hidden Forensic Con- initramfs system's early siderations Just a thought...could this be userspace Multi-snapshot/FTL automated by rolling some environment Summary limited functionality into cryptsetup? Stacked Decomposition of Base Block Device Contents

Overview Cover OS Secondary Bootstrap History VeraCrypt Appraisal Primary Bootstrap Hidden OS e.g./dev/sda Deniability Requirements x Essentials x Technical Requirements x System x x Design I x Randomization/ Overwrites Concrete x x Implementation x System xx Design II Cascading Bootstrap Concrete Implementation cover hidden hidden hidden Forensic Con- siderations Multi-snapshot/FTL

Summary • Each of a layer’s utilized blocks overwrite those to its right • Note ascending sophistication of error correction from left to right ( none, user repetition, automated repetition, LDPC) Early Userspace Bootstrap Process: Launching Primary Bootstrap

Overview $cryptsetup open --type=plain --size=2 History 1 VeraCrypt Appraisal --skip=10000 --offset=10000 /dev/sda crypt

Deniability Requirements 9,999 Essentials 10,000 Technical dm-crypt 10,001 Requirements 10,002 /dev hidden System /mapper Design I /dev/sda Randomization/ /crypt Overwrites Concrete Implementation $cp /dev/mapper/crypt /steg (this is tmpfs!) System 2 $chmod +x /steg Design II $/steg Cascading Bootstrap Concrete Implementation ELF... Forensic Con- Primary siderations /dev Multi-snapshot/FTL Bootstrap /mapper /crypt Summary /primary_bootstrap

Upon running /steg, the user’s job is done. Note /steg is only 1024 Bytes Early Userspace Bootstrap Process: Primary Bootstrap Ops (1)

Overview History Running VeraCrypt Appraisal ELF... Deniability Requirements Primary 9,999 1. Take down old, 2- Essentials Bootstrap 10,000 Technical 1 dm-crypt 10,001 sector crypto Requirements 10,002 /dev hidden mapping (no longer System /mapper Design I /crypt /dev/sda needed) Randomization/ Overwrites Concrete Implementation

System Design II Cascading Bootstrap 2. Re-establish crypto Concrete Implementation 2 dm-crypt mapping under same Forensic Con- hidden key but for entire siderations Multi-snapshot/FTL /dev/sda sector range (i.e. no /dev Summary /mapper "size" parameter in /crypt cryptsetup) Early Userspace Bootstrap Process: Primary Bootstrap Ops (2)

Overview Running History ELF... dm-crypt VeraCrypt Appraisal 1. Extract shards of a new ELF Primary Deniability Bootstrap hidden image. Each shard was stored Requirements /dev /dev/sda multiple times at pseudo- Essentials /mapper Technical random locations to allow the Requirements /crypt error correction done here. System Design I Compare each shard copy's Randomization/ A B C D header against magic Overwrites 1 Concrete number: = pass, = fail Implementation A B C D System A B C D Design II 2. Concatenate good copies of Cascading Bootstrap B C D shards (using the non-header Concrete A Implementation Multiple Copies portion) to generate new ELF, Forensic Con- which is about 350 kB. When siderations done, transfer control to Multi-snapshot/FTL ELF... new ELF via execve() Summary 2 A B C D Secondary Bootstrap system call /secondary_bootstrap (again: tmpfs!) Early Userspace Bootstrap Process: Secondary Bootstrap Ops

Running Userspace emulation Overview ELF... of kernel module 1. Establish userspace History VeraCrypt Appraisal Secondary "kernel module" Bootstrap mapping that exposes Deniability steg dm-crypt Requirements "reserved sectors" to the Essentials 1 hidden secondary bootstrap Technical Requirements reserved /dev /dev/sda program sectors /mapper System } 2. Extract three ﬁles Design I /dev /crypt Randomization/ /steg from reserved sectors Overwrites Concrete and save them to tmpfs Implementation 3. Soft boot into hidden System cryptsetup LVM (again: tmpfs!) system via kexec_load Design II steg.ko etc... Cascading Bootstrap system call Concrete Implementation steg kernel kernel param steg initramfs parameterized with

2 } Forensic Con- /vmlinuz-linux /cmdline.txt /initramfs-linux.img three extracted ﬁles siderations Multi-snapshot/FTL contains steg kernel module loaded Summary 3 kexec_load( ) during boot of hidden system

Kernel & initramfs are many MB—hence the need for LDPC error correction Hidden System Boot: Wrapping Up...

Overview • Hidden system initramfs contains the steganographic kernel module History VeraCrypt Appraisal • Signiﬁcant waypoints within hidden system early userspace boot: Deniability Requirements 1 Establish hidden-perspective cryptographic mapping Essentials Technical (e.g. /dev/sda -> /dev/mapper/crypt) with cryptsetup (password can Requirements be stored in hidden system initramfs) System Design I 2 Randomization/ Establish steganographic mapping Overwrites /dev/mapper/crypt -> /dev/steg Concrete (e.g. ) by loading steganographic Implementation loadable kernel module System Design II • Typical hidden system /etc/fstab will associate / with /dev/steg. Cascading Bootstrap Concrete Implementation • Sundry points Forensic Con- • Primary bootstrap (1024 Bytes) contains primitive EC functionality and was siderations Multi-snapshot/FTL hand coded in assembly with lots of cheats/optimizations Summary • Secondary bootstrap (∼ 350 kB) contains heavyweight LDPC functionality and was written in C/C++ with all libraries linked in, symbols stripped out, and compressed with UPX Final Points on Software Development

Overview History • Languages used: Assembly, C, C++, Make, KMake VeraCrypt Appraisal

Deniability • ∼ 30,000 lines of code spanning main kernel module, userspace utilities (for Requirements Essentials installation, diagnostics, etc.), and various components of bootstrap system Technical Requirements • ∼ 180 class deﬁnitions System Design I • ∼ 900 functions/methods Randomization/ Overwrites • Concrete Extensive validation of cover system preservation by hidden system Implementation

System • Seems to function well; no instability or data corruption observed Design II Cascading Bootstrap • Tested with various combinations of Arch and Ubuntu Concrete Implementation • Conﬁrmed that VirtualBox/Windows works very well on hidden system Forensic Con- siderations Multi-snapshot/FTL

Summary Multi-Snapshot Imaging and Countermeasures

Overview History VeraCrypt Appraisal

Deniability Requirements Essentials Technical • Ongoing use of the hidden system will change Requirements the data in the slack space of the cover system System Design I • Differential analysis of slack space between Randomization/ Overwrites temporally separated snapshots may reveal Concrete Implementation changes indicative of steganography use System Design II • Countermeasures: Cascading Bootstrap Concrete • Cease all hidden system use after ﬁrst Implementation imaging Forensic Con- These siderations • e.g./dev/sda Reinstall entire system if allowed by cover should Multi-snapshot/FTL story not have Summary In use by OS changed! Purportedly free ("slack") Flash Translation Layer (FTL) Analysis and Countermeasures

Overview OS History • SSDs maintain ever-changing mappings between VeraCrypt Appraisal

Deniability logical/physical sectors—the FTL Requirements Log Essentials • FTL also contains metadata on previous errors, read Technical Requirements and write operations, etc. System • Design I Statistical FTL analysis may uncover historical access FTL Randomization/ Overwrites patterns that implicate steganography Logical/Physical Concrete Mapping Implementation • Disabling TRIM is suspicious System Misc Design II • Countermeasures: Cascading Bootstrap Metadata Concrete • Use magnetic storage (best) Implementation stored in persistent • Put hidden OS in cover swap (default no TRIM) Forensic Con- flash memory siderations • Re-flash SSD firmware with special software from Multi-snapshot/FTL hidden system to cover tracks (expensive) Summary • SSD firmware is costly and time consuming to reverse engineer—exploit this! Phy Takeaways

Overview History 1 Steganography software can recursively hide itself VeraCrypt Appraisal • Deniability Need to download/possess incriminating software is obviated Requirements • Forensic risk can be eliminated* Essentials Technical 2 Requirements Russian doll steganography is made much easier

System • Need to use an incriminating 802.11 steg communications tool? Inﬁltrating Design I Randomization/ this tool into a hostile location is easy... Overwrites Concrete 3 Open-channel SSDs will enable physics-based steg Implementation • System Entire new avenues of steg are on the horizon Design II Cascading Bootstrap Concrete • Insight into steganography use may go darker, variously affecting Implementation

Forensic Con- journalists, NGOs, those tasked with organizational security (e.g. ISOs), siderations Multi-snapshot/FTL law enforcement, and intelligence. Summary • Journalists/NGOs may gain better opsec; OTOH, organizations should consider proactive response and SSD forensics development. Contact Us

Overview History VeraCrypt Appraisal

Deniability Requirements Essentials Technical Requirements

System Design I Randomization/ Overwrites Please contact us! Concrete Implementation • [email protected] System Design II Cascading Bootstrap Concrete Implementation

Forensic Con- siderations Multi-snapshot/FTL

Summary