Hardware assisted isolated computing environments
1 / 29

Hardware-Assisted Isolated Computing Environments - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Hardware-Assisted Isolated Computing Environments' - hamal

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript


  • Introduction

  • Related Work

  • Our Work on Hardware-assisted ICE

    • x86 platform

      • SecureSwitch: OS level isolation [NDSS12]

    • ARM platform

      • TrustICE: Flexible ICE [under submission]

  • Summary

Why isolated computing environment
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



Lampson red green system model
Lampson Red/Green System Model

Red/Green system: Policy + Isolation + Accountability +Freedom

* Butler Lampson, Accountability and Freedom Slides, Microsoft, Sept.,2005


  • Introduction

  • Related Work

  • Our Work on Hardware-assisted ICE

    • x86 platform

      • SecureSwitch: OS level isolation [NDSS12]

    • ARM platform

      • TrustICE: Flexible ICE [under submission]

  • Summary

Software based ice solutions
Software-based ICE Solutions

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


  • Introduction

  • Related Work

  • Our Work on Hardware-assisted ICE

    • x86 platform

      • SecureSwitch: OS level isolation [NDSS12]

    • ARM platform

      • TrustICE: Flexible ICE [under submission]

  • Summary

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

Bios uefi and coreboot
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

Acpi sleeping states
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

Attack model
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

Trusted path
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

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

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

Memory isolation1
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

Hard drive isolation
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


  • 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

Linux suspend time breakdown
Linux Suspend Time Breakdown

User Space : 1517.33 ms

Kernel Space: 1590.14 ms

Linux wakeup time breakdown
Linux Wakeup Time Breakdown

Kernel Space: 1537.22 ms

User Space: 621.04 ms


  • Introduction

  • Related Work

  • Our Work on Hardware-assisted ICE

    • x86 platform

      • SecureSwitch: OS level isolation [NDSS12]

    • ARM platform

      • TrustICE: Flexible ICE [under submission]

  • Summary

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


Trustice flexible ices
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


  • Introduction

  • Related Work

  • Our Work on Hardware-assisted ICE

    • x86 platform

      • SecureSwitch: OS level isolation [NDSS12]

    • ARM platform

      • TrustICE: Flexible ICE [under submission]

  • 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


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