1 / 29

Hardware-Assisted Isolated Computing Environments

Hardware-Assisted Isolated Computing Environments. Instructor: Kun Sun, Ph.D. Outline. Introduction Related Work Our Work on Hardware-assisted ICE x86 platform SecureSwitch : OS level isolation [NDSS12] ARM platform TrustICE : Flexible ICE [under submission] Summary.

hamal
Download Presentation

Hardware-Assisted Isolated Computing Environments

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Hardware-Assisted Isolated Computing Environments Instructor: Kun Sun, Ph.D.

  2. Outline • Introduction • Related Work • Our Work on Hardware-assisted ICE • x86 platform • SecureSwitch: OS level isolation [NDSS12] • ARM platform • TrustICE: Flexible ICE [under submission] • Summary

  3. Why Isolated Computing Environment? • Bring your own device (BYOD) • Risk of data breaches • Require an ICE to separate sensitive code and data • Suspicious code or data • Trojan, e.g., BitCoinMiner, Keylogger • Run the code in an ICE to protect the host environment • Malware analysis • Rootkits compromises OS • Protect the analysis tools in an ICE http://www.technologyreview.com/sites/default/files/legacy/belt_b_x220.jpg http://b.vimeocdn.com/ts/419/611/419611391_640.jpg

  4. Lampson Red/Green System Model Red/Green system: Policy + Isolation + Accountability +Freedom * Butler Lampson, Accountability and Freedom Slides, Microsoft, Sept.,2005

  5. Outline • Introduction • Related Work • Our Work on Hardware-assisted ICE • x86 platform • SecureSwitch: OS level isolation [NDSS12] • ARM platform • TrustICE: Flexible ICE [under submission] • Summary

  6. Software-based ICE Solutions • * From 1999 to 2009, 373 vulnerabilities affecting virtualization solutions. --- “IBM X-Force 2010 Mid-year trend and risk report”

  7. Hardware-based ICE Solutions

  8. Outline • Introduction • Related Work • Our Work on Hardware-assisted ICE • x86 platform • SecureSwitch: OS level isolation [NDSS12] • ARM platform • TrustICE: Flexible ICE [under submission] • Summary

  9. SecureSwitch Architecture • BIOS-assistant OS Level Isolation • no data leakage between two OS environments • without using any mutable software layer (e.g., hypervisor) • no changes of the OS source code • fast switching time, around 6 seconds Trusted Computing Base (TCB) only contains the BIOS.

  10. BIOS, UEFI, and Coreboot • Basic Input/Output System (BIOS) • Initializing hardware components. • Stored in non-volatile ROM chips. • Unified Extensible Firmware Interface (UEFI) • A new software interface between OS and firmware. • Partially open source • Coreboot (formerly as LinuxBIOS) • Similar functionality as UEFI • Open source

  11. ACPI Sleeping States • Advanced Configuration and Power Interface (ACPI) • OS-directed configuration; Power/thermal management • Global System States • G0 --- Working (System Operational) • G1---Sleeping (CPU stopped) • G2 ---Soft Off • G3 ---Mechanical off (Physical off switch) • Sleeping States in G1: S0 – S5 • S3: also called Standby, Suspend to RAM • DRAM still maintained • S4: also called Hibernation or Suspend to Disk • DRAM not maintained • Device Power States: D0 – D3 • D0 - Fully-On • D3 -- Power off to device

  12. Attack Model • Assumption • BIOS and option ROM on devices can be trusted. • No physical access to the protected machine • Attacks from the untrusted OS • Spoofing Trusted OS attacks: faking trusted OS • Data exfiltration attacks: stealing sensitive data • Cache-based side channel attacks: extracting sensitive data • Out of the scope • Denial of Service attacks • Network attacks on trusted OS

  13. Secure Switching State Machine

  14. Trusted Path • Protect against Spoofing trusted OS attacks by assuring users that they are working with the OS they intend to use. • Protecting system variables • OS_Flag: records which OS should be woken next • Where to save it? • Untrusted OS should be truly suspended. • hardware controlled power LED lights up when system is powered on, and blinks in the sleep mode. • BIOS should be entered. • Press the power button. • OS_Flag: physical jumper, e.g., Parallel port connector

  15. Secure Switching Process

  16. System Isolation • CPU Isolation: two OSes never run concurrently. • Memory Isolation: physical-level isolation • Hard disk isolation: encrypted hard disk, RAM disk • Other I/O isolation: clean the buffers/states in devices.

  17. Memory Isolation • A motherboard may have more than one dual in-line memory module (DIMM) slot. • DIMM Mask and DQS Setting • BIOS uses “DIMM_MASK”variable to control which DIMMs to be enabled. • BIOS sets “data strobes”(DQS) parameters to enable DDR RAM memory access.

  18. Memory Isolation • Physical-level memory isolation ensured by BIOS • Two OS environments run in separate DIMMS. • BIOS only enables one DIMM for each OS. • Two DQS settings for two OSes • “DIMM_MASK” controlled by the physical jumper. • System software, except the BIOS, cannot initialize or enable DIMMs after the system boots up • Transient state of DQS setting • If “DIMM_MASK”has conflicts with DQS setting, system crashes

  19. Hard Drive Isolation • Hard disk encryption • Two hard disks, one for each OS • Disk lock in ATA specification • Need TPM to save the encryption key • RAM disk • For browser-based application, save a small amount of temporary data in the RAM

  20. Prototype • Hardware • Motherboard: ASUS M2V-MX_SE • CPU: AMD Sempron 64 LE-1300 • DDR2: Kingston HyperX 1GB • HDD: Seagate 500GB • Software • BIOS: Coreboot + SeaBIOS • Trusted OS: Linux (Centos 5.5) • Untrusted OS: Windows XP

  21. Performance Analysis

  22. Linux Suspend Time Breakdown User Space : 1517.33 ms Kernel Space: 1590.14 ms

  23. Linux Wakeup Time Breakdown Kernel Space: 1537.22 ms User Space: 621.04 ms

  24. Outline • Introduction • Related Work • Our Work on Hardware-assisted ICE • x86 platform • SecureSwitch: OS level isolation [NDSS12] • ARM platform • TrustICE: Flexible ICE [under submission] • Summary

  25. ARM TrustZone • Two isolated domains • Secure/un-secure CPU States • Virtual MMU/Secure Memory • TrustZone-Aware interrupt controller • Traditional solutions • Rich OS and un-secure apps in normal domain • Secure OS and secure apps in secure domain • Limitations • Trusted Computing Base (TCB) is large • No flexible • No isolation between secure Apps. • No protection on non-secure Apps. TraditionalSolutions

  26. TrustICE: Flexible ICEs • Basic Idea: Create ICEs in normal domain, instead of secure domain • A Trusted Domain Controller (TDC) enforces the isolation and secures the switching • Benefits: • Small TCB: TDC + Secure boot • Multiple ICEs • Self-contained code • Microkenel with necessary modules • full-featured OS • Flexible • Easy to deploy third-party software • Vendor Apps still in secure domain

  27. Outline • Introduction • Related Work • Our Work on Hardware-assisted ICE • x86 platform • SecureSwitch: OS level isolation [NDSS12] • ARM platform • TrustICE: Flexible ICE [under submission] • Summary

  28. Summary • Our Work on Hardware-assisted ICE • SecureSwitch: BIOS-based ICE on x86platform • OS level isolation with small TCB • Small switching time • TrustICE: TrustZone-based ICE on arm platform • Flexible multiple ICEs • Small TCB

  29. References • P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebauer, I. Pratt, and A. Warfield. Xen and the art of virtualization. In SOSP ’03: Proceedings of the nineteenth ACM symposium on Operating systems principles, pages 164–177, New York, NY, USA, 2003. ACM Press. • J. McCune, B. Parno, A. Perrig, M. Reiter, and H. Isozaki. Flicker: An execution infrastructure for TCB minimization. In Proceedings of the 3rd ACM SIGOPS/EuroSys European Conference on Computer Systems 2008, pages 315–328. ACM, 2008. • J. M. McCune, Y. Li, N. Qu, Z. Zhou, A. Datta, V. Gligor, and A. Perrig. TrustVisor: Efficient TCB reduction and attestation. In Proceedings of the IEEE Symposium on Security and Privacy, 2010. • AmitVasudevan, Bryan Parno, Ning Qu, Virgil D. Gligor, Adrian Perrig. Lockdown: Towards a Safe and Practical Architecture for Security Applications on Commodity Platforms. TRUST 2012. • Ahmed Azab, Peng Ning, Xiaolan Zhang, SICE: A Hardware-Level Strongly Isolated Computing Environment for x86 Multi-core Platforms, in Proceedings of 18th ACM Conference on Computer and Communications Security (CCS11), October 2011. • Fengwei Zhang, Jiang Wang, Kun Sun, Angelos Stavrou, "HyperCheck: A Hardware-Assisted Integrity Monitor," IEEE Transactions on Dependable and Secure Computing, 17 Dec. 2013. IEEE computer Society Digital Library. • Kun Sun, Jiang Wang, Fengwei Zhang, and Angelos Stavrou, SecureSwitch: BIOS-Assisted Isolation and Switch between Trusted and Untrusted Commodity OSes. In the Proceedings of the 19th Annual Network & Distributed System Security Symposium (NDSS), San Diego, California, 5-8 February 2012. • Y. Fu and Z. Lin. Space Traveling across VM: Automatically bridging the semantic gap in virtual machine introspection via online kernel data redirection. In Proceedings of the 33rd IEEE Symposium on Security and Privacy, 2012. • X. Jiang, X. Wang, and D. Xu. Stealthy malware detection through vmm-based out-of-the-box semantic view reconstruction. In Proceedings of the 14th ACM conference on CCS, 2007. • T. Leek, M. Zhivich, J. Gin, and W. Lee. Virtuoso: Narrowing the semantic gap in virtual machine introspection. In Proceedings of the 32nd IEEE Symposium on Security and Privacy, 2011.

More Related