TreVisor - Cryptography & Security Department

TreVisor 

OS-Independent Software-Based Full Disk Encryption 

Secure Against Main Memory Attacks 

June 26 - 29 • ACNS 2012 • Singapore 

Tilo Müller, Benjamin Taubmann, and Felix C. Freiling 

Department of Computer Science 

Friedrich-Alexander University of Erlangen-Nuremberg

Contents 

I. Motivation: Memory Attacks on Full Disk Encryption 

II. Background & Design 

• TRESOR Runs Encryption Securely Outside RAM 

• TreVisor: The TRESOR Hypervisor 

• BitVisor: A Thin Hypervisor for Enforcing I/O Device Security 

III. Implementation Details: The BitVisor Patch 

IV. Evaluation: Performance, Compatibility, Security 

V. Conclusion 

June 26 - 29, 2012 · ACNS '12 Singapore · TreVisor · Tilo Müller, Benjamin Taubmann, and Felix C. Freiling

Part I 

Motivation 


II. Background & Design: TRESOR, TreVisor, BitVisor 



V. Conclusion

Disk Encryption 

● Full disk encryption (FDE) protects data against physical loss 

and theft of the hard drive. 

● It does generally not protect against remote attacks. 

Source: http://bvinews.com/bvi/wp-content/uploads//2011/07/laptop-theft-in-action.jpg 



But current (software-based) FDE solutions do not protect data 

effectively if an adversary gains physical access! 

Why? 


Software Disk Encryption 

RAM 

(unencrypted) CPU 

en/decrypt 

HDD 

(encrypted) 

● Software-based disk encryption stores necessary keys in RAM 

● Including BitLocker, FileVault, dm-crypt, and TrueCrypt 


Attacks on Main Memory 

Problem: main memory is no secure storage 

for cryptographic keys. 

1) DMA Attacks via Firewire, Thunderbolt, PCIe, etc. 

2) Cold Boot Attacks on Encryption Keys 


DMA Attacks 

Direct Memory Access is exploitable: 

2004: Firewire 

0wned by an iPod from Maximilian Dornseif -- All Your Memory 

Are Belong To Us 

... PC Card / ExpressCard / PCIe / more Firewire ... 

2012: Thunderbolt 

Adventures with Daisy in Thunderbolt-DMA-land: Hacking Macs 

through the Thunderbolt interface 


Cold Boot Attacks 

● Remanence effect of DRAM: 

● 2008: Lest We Remember: Cold Boot Attacks on Encryption Keys 

Source: https://citp.princeton.edu/research/memory/media/ 



Memory attacks require target systems to be 

running or in suspended mode 

● Lost and theft of suspended laptops at 

public places 

● Confiscation of running servers by law 

enforcement authorities 

Source: http://i.dailymail.co.uk 

Source: http://gottabemobile.wpengine.netdna-cdn.com 



Basically all memory contents can be read out. 

We focus on the security of 

disk encryption keys 


Disk Encryption Solutions 

Software FDE Hardware FDE TRESOR/TreVisor 

RAM 

HDD 

CPU 

RAM 

HDD 

CPU 

RAM 

HDD 

CPU 


Part II 

Background & Design 





V. Conclusion

TRESOR 

TRESOR Runs Encryption Securely Outside RAM 

● Published at USENIX 2011 

● Keys are stored in CPU registers (dr0-dr3) rather than in RAM 

● All intermediate states / runtime variables are stored only in CPU 

registers as well 

● Challenges: 

● No use of stack and heap 

● Scheduling, hardware interrupts, and context switches 

● Userland access to debug registers (dr0-dr3) 

● Swapping and Suspend-to-Disk / RAM 

● ... 

● Linux kernel patch (originally for 2.6.36); dm-crypt support 

● AES-128, -192, and -256 accelerated by Intel's AES-NI 


TRESOR Problems 

● TRESOR effectively defeats cold boot attacks, but 

is still vulnerable to: 

● write-able DMA attacks on running machines (code infiltration) 

● local privilege escalations (loadable kernel modules and /dev/kmem) 

● buggy drivers can lead to data corruption 

● full disk encryption (FDE) is tricky to set up 

● works for Linux only; no other OS supported 



The TRESOR HyperVisor 

● TreVisor is a ``thin hypervisor`` that encrypts hard 

disks transparently for the guest OS. 

● one unmodified guest, including Linux and Windows. 

● Most devices are just passed through, except 

● hard disk: hook into file access in order to en-/decrypt data 

transparently with TRESOR technology. 

● DMA devices: filter memory transfers by means of the 

IOMMU ; access to hyperspace is disallowed. 


TRESOR vs. TreVisor 

App App 

TRESOR patched Linux 

HDD 

(a) TRESOR 

unused 

unused 

App 

App 

Other Hardware 

ring 3 

ring 1+2 

ring 0 

ring -1 

App App 

Any Operating System 


HDD 

(b) TreVisor 

unused 

App 

Other Hardware 

June 26 - 29, 2012 · ACNS '12 Singapore · TreVisor · Tilo Müller, Benjamin Taubmann, and Felix C. Freiling 

App

BitVisor 

A Secure and Lightweight Hypervisor 

● University of Tsukuba ; published at VEE '09 

● Thin hypervisor that implements various security 

features: FDE, VPN, VT-d/IOMMU, TCG, etc. 

● Parapass-through architecture 

� no drivers required for most devices 


Tresor + BitVisor = TreVisor 

We use BitVisor as a basis for TreVisor 


Part III 

Implementation Details 





V. Conclusion

Registers 

Debug registers: SSE Registers: General Purpose: 

dr0 (64-bit) 

dr1 (64-bit) 

dr2 (64-bit) 

dr3 (64-bit) 

xmm0 (128-bit) 

xmm1 (128-bit) 

... 

xmm15 (128-bit) 

● dr0 to dr3 are exclusively reserved as key storage ; hardware 

breakpoints cannot be set by userland applications anymore 


rax (64-bit) 

rbx (64-bit) 

rcx (64-bit) 

rdx (64-bit) 

● xmm0 to xmm15 and GPRs are used only temporarily inside 

atomic sections

Key Storage Registers 

● Usually, debug registers (dr0 - dr7) can be accessed with 

ring 0 privileges from guest OS 

● Now we need exclusive access from ring -1 (VMM) 

● We must protect the debug registers from guest OS: 

● Throw VMEXIT exception when the guest tries to access 

debug registers (virtualization control: "MOV-DR exiting") 

● Exception handler: ignore instruction (increment IP), don't 

throw exception to guest, mirror guest debug regs in RAM 

� Changes privilege level of debug regs from ring 0 to -1 


Key Management 

● Every CPU core should be able to do encryption 

� Key has to be present in every single core 

� Use Inter-Processor Interrupts (IPIs) to distribute the 

key 

(For key distribution, RAM is used briefly but cleared 

thoroughly afterwards) 



● BitVisor already knows about FDE 

● drivers for ATA and USB disks 

● routines for hooking disk accesses 

● So what is missing? 

● the "TRESOR" crypto module 

● e.g.: implement crypto_tresor_init(), 

crypto_tresor_encrypt(), and crypto_tresor_decrypt() 

● most of the routines implemented in assembly (AES-NI) 

● Important: TRESOR code must run atomically and zero-fill 

used registers (SSE + GPRs) before exiting 


Availability 

http://www1.cs.fau.de/trevisor 

● In active development by Benjamin Taubmann 

● Latest patch from mid of June 

● 3.800 lines of code, mixture of C and assembly 


Part IV 

Evaluation 





V. Conclusion

TreVisor Performance 

Linux (write) 

Linux (read) 

Windows 

10 20 30 40 50 60 MB/s 

59.3 MB/s 

54.4 MB/s 

56.0 MB/s 

38.8 MB/s 

36.3 MB/s 

32.5 MB/s 

43.3 MB/s 

39.4 MB/s 

35.3 MB/s 


AES-128 

AES-192 

AES-256

Linux Performance 

No 

VMM 

No 

Crypto 

AES-NI 

256 

StdAES 

256 

TRESOR 

256 

10 20 30 40 50 60 MB/s 

60.7 MB/s 

63.7 MB/s 

59.9 MB/s 

63.2 MB/s 

59.2 MB/s 

62.9 MB/s 

57.6 MB/s 

37.8 MB/s 

56.0 MB/s 

32.5 MB/s 


write 

read

Compatibility: Hardware 

● CPU requirements: 

● x86-64 

● Multimedia Extensions (SSE / AVX / ...) 

● Virtualization (VT-x) 

● VT-d/IOMMU 

● Hardware Encryption (AES-NI) 

● Those are currently: 

● Intel Core-i5 

● Intel Core-i7 

● Many upcoming CPUs, also from AMD 


Compatibility: Software 

● Operating systems: basically all x86 OSs. Most 

noteworthy: 

● LINUX 

● WINDOWS 

● Userland 

● Debuggers: Yes, but without hardware breakpoints. 

● Virtualization: Yes, but without hardware acceleration. 

● Everything else: w/o restrictions 


Security Overview 

Threat Model Hard Disk Encryption 

Memory 

Attack 

cold boot 

DMA * 

System 

State 

off 

running 

suspend 

off 

running 

suspend 

OS independent 

BitLocker 

/ dmcrypt 

*) running on a CPU with VT-d/IOMMU support 

TRESOR BitVisor TreVisor 


Security Analysis 

● We spent considerable effort to ensure that no key 

data enters RAM 

● Methods we used to dump RAM 

● cold boot attacks 

● BitVisor debugging shell 

● virtualization 

● DMA attacks (Firewire; IOMMU switched off) 

● We were not able to recover any keybits 


Part V 

Conclusion 





V. Conclusion

Conclusion 

We solved the main drawbacks of 

TRESOR 

● secure against local privilege escalations 

● secure against data corruption through buggy 

drivers 

● secure against write-able DMA attacks 

● easy to set up full disk encryption 

● Windows support (and many other OSs) 


The End 

Thank you for your attention!

TreVisor - Cryptography & Security Department

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?