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

Roadmap Motivation StrongBox Contribution and Limitations Conclusion Implementation Overview Threat Model Performance Evaluation Contribution and Limitations Conclusion Future Work

Motivation Part 1: Technology Trends Then: HDD Now: SSD/eMMC/Flash Infrequently used in mobile/portable electronics Offers direct LBA API (no translation layer) Increasingly popular I/O managed by Flash Translation Layer (FTL) FTL operates very similarly to a Log- structured File System (LFS) Logical Block Addressing API instead of going through an FTL

Motivation Part 1: Technology Trends Trusted Platform Module (TPM) Supports secure monotonic counters TPM/TEE enjoy increasingly widespread adoption As of 2009, TPM is used by nearly all PC manufacturers and exists in nearly 600 million PCs, mobile devices, and hard drives*** ARM has supported TEE since ARMv6 Secure counters are good for preserving state and protecting against rollback attacks!

Motivation Part 2: Securing Data at Rest The State of the Art for FDE: AES in XTS mode 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

Motivation Part 2: Securing Data at Rest FDE with a Stream Cipher Sectors don’t even factor in when we’re using a stream cipher.

Motivation Part 2: Securing Data at Rest FDE with a Block Cipher (AES) FDE with a Stream Cipher

The Problem with FDE & Stream Ciphers Naïve FDE implementations using stream ciphers are trivially vulnerable! Many-time pad attacks Rollback attacks The general wisdom: use the slower block cipher (AES) instead of a stream cipher These problems with stream ciphers and FDE are well understood by the community The common assumption: workarounds for the above problems are too expensive; result in steep performance degradation

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 performant encryption layer to OS without API changes Leverage FTL/LFS append-only nature to protect against many-time pad attacks Leverage TPM/TEE secure counter support to protect against metadata rollback

StrongBox Illustration Merkle Tree: … Keycount Store: … Transaction Journal: … Device controller can be crafted to communicate with SSD controllers, HDD drivers, VFS, etc.

Threat 1: Passive Attack (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) Track writes to ensure that the same location is never overwritten

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

Conclusion (tell them what you told them but succinctly)

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

Reference StrongBox Repo: https://github.com/ananonrepo2/StrongBox Images are from Wikipedia/OS *** TCG: How to use TPM. Technical report, Trusted Computing Group (2009, 2012)

END Any Questions?