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

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

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

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

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

6. 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!

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

8. StrongBox Illustration

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

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

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

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

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

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

15. Conclusion
(tell them what you told them but succinctly)

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

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

18. END
Any Questions?