STRONGBOX: CONFIDENTIALITY, INTEGRITY, AND PERFORMANCE USING STREAM CIPHERS FOR FULL-DISK ENCRYPTION Bernard Dickens III

Roadmap Motivation Current State of the Art Key Insight of Log-structured File Systems StrongBox Implementation Overview Threat Model Performance Evaluation Contribution and Limitations Conclusion Future Work

Motivation Modern devices use fast flash-based storage Flash storage, including SSDs, flash drives, eMMC, etc. are extremely popular Extremely fast unencrypted storage Full disk encryption is slow Really slow: 3-5x slower than unencrypted storage … because the AES block cipher is slow (in XTS mode) Full disk encryption (FDE) is ubiquitous Every Android device at or past Android M employs FDE by default Windows 10 devices come with TPM-based BitLocker FDE schemes Trusted hardware TPMs/TEEs are already widely integrated Stream ciphers are very fast Google replaced AES with a fast stream cipher for HTTPS in 2014! Can we leverage the speed of modern stream ciphers to make FDE faster? Split into two Better (more provocative) titles: securing data at rest, technology trends

Current Solutions (State of the Art) Everyone implements FDE using AES in XTS mode dm-crypt is standard for Linux/Android; uses AES-XTS All Windows computers, laptops, tablets with BitLocker use AES-XTS Apple iOS/FileVault uses AES-XTS VeraCrypt/TrueCrypt et al. employ AES-XTS by default Add illustration of AES-XTS (basic internal diagrams of AES-XTS/block cipher) Better title Split this into two columns: how block cipher works vs stream cipher works w/ diagrams too Really slow vs really fast Why is one favored over the other? <add more pictures> Technology trends lead to the second being favored now (flash over normal disks; hardware secure counter support)

The Problem with FDE and Stream Ciphers Naïve FDE implementations using stream ciphers are trivially vulnerable! Trivial many-time pad attacks Rollback attacks These problems with stream ciphers and FDE are well understood by the community The common assumption: workarounds for the above problems are too expensive The general wisdom: use a block cipher instead of a stream cipher for FDE

Key Insight In context, the disks that are being encrypted are often flash-based Flash-based storage allows I/O via Flash Translation Layer (FTL) FTLs behaves very similarly to Log-structured File Systems (LFS) LFSes are filesystems that write data and metadata to a circular buffer in a sequential fashion LFSes (and FTLs) are in effect append-only filesystems with garbage colletion We can avoid the many-time pad vulnerability if the filesystem consistently makes forward writes (i.e. append-only) 5 minutes by this point!

Solution: StrongBox We propose StrongBox A drop-in replacement for AES-XTS-backed FDE providers such as dm-crypt Goals of our StrongBox implementation Provide a transparent encryption layer without API changes Track writes to ensure that the same location is never overwritten Ensure metadata used for tracking writes is secure and is not subject to side channel leaks or rollback attacks Accomplishing the above without cutting too deep into the performance gained by use of the stream cipher

StrongBox Illustration

Threat 1: Passive Attacker (describe standard attacks that all FDE was created to defend against) (describe solution)

Threat 2: Many-time Pad Attack (describe many-time pad attack unique to stream cipher use in FDE) (describe solution)

Threat 3: Rollback Attack (describe rollback attack) (describe how it’s handled with AES-XTS) (describe how it’s different with stream ciphers) (describe solution)

Performance Evaluation (add metrics from paper showing the defeat of dm-crypt in majority of cases as ratios; i.e. 2.5x faster than Y) Multiple slides, one result/sentence per slide

X Contribution (Key insight is a contribution?) (StrongBox itself?) <<is this a necessary page at all?>>

X Limitations (describe the several limitations inherent in the current StrongBox implemention)

Conclusion (tell them what you told them but succinctly)

Future Work and Improvements (summarize the three future work sections from the paper)

Reference (paper url or something goes here?) (link to anonymous repo goes here)

END Any Questions?