An approach to on the fly activation and deactivation of virtualization-based security systems

1
An approach to on the flyactivation and
deactivation ofvirtualization-based security
systems
Institute for System Programming Russian Academy
of Sciences

• Denis Efremov (evdenis_at_gmail.com)
• Pavel Iakovenko (yak_at_ispras.ru)

2
Hardware virtualization-based security solutions

• Hardware virtual machine
• Software emulated environment allowing executing
  unmodified operating system
• Controlled by virtual machine monitor
  (hypervisor)
• Accelerated by hardware extensions in modern CPUs
• Security system is placed in the hypervisor
• Has full access to the virtual machine resources
• Cannot be disabled from inside virtual machine
• Problems researched
• Intrusion detection systems
• Malware analysis
• Information flow tracking
• Secure file systems
• Application security oriented systems

3
Preventing data leakages through network
Network isolated
Main virtual machine
Linux
Network connected
Sensitive data
Service virtual machine
Linux
Trusted process
Delegate
Hypervisor
Access allowed
Access NOT allowed
Internet
4
Specifics of the data leakage preventing solution

• Systems enforces network isolation for all the
  software except trusted applications
• Whenever security system is not running user
  still may prevent data leakage by simply
  disconnecting network cable
• So hypervisor is not required to be active all
  the time the system is up and running
• It may be OFF when network cable is
  disconnected
• It must be ON when trusted applications that
  require network access are executed
• Limited amount of simultaneously executing
  virtual machines (just two of them)
• Virtual machines do not share hardware resources
• Each virtual machine my be assigned with
  dedicated access to certain hardware resources
• Service virtual machine is not required to be
  persistent
• Each time computer is powered off the state of
  this machine may be reset
• Operating system in the service virtual machine
  may be configured as necessary
• It may be even different from the operating
  system in the main virtual machine

5
Objectives

• Make it possible to dynamically activate security
  system on user request without rebooting the
  computer
• Launch hypervisor
• Virtualize the up and running operating system
• Launch service virtual machine
• Bring system back to native state on user
  request
• Stop service virtual machine
• De-virtualize main virtual machine
• Unload hypervisor
• Provide means of attesting launched security
  system
• Hypervisor is loaded from the untrusted
  environment and may be subverted
• Why?
• Dynamic activation does not require changes to
  the system configuration (boot sector) which is
  done when we launch hypervisor prior to booting
  operating system
• Smaller hypervisor
• BIOS is removed from the trusted components

6
Hardware considerations

• AMD/Intel CPU supporting hardware virtualization
  extensions
• Memory virtualization required (Nested/Extended
  Page Tables)
• We use AMD solution (merely due to availability)
• IOMMU / VT-d support
• Protection from DMA attacks
• Trusted Platform Module version 1.2
• Attestation of security system
• Linux operating system
• Configured with support for CPU, memory and PCI
  hot-plugging

7
System components

• Secure loader
• Required for attesting system
• Hypervisor image
• Service virtual machine kernel image
• Specifically configured Linux kernel that does
  not touch any peripheral devices except network
  interface cards
• dynaload kernel module
• Reserves hardware resources for the hypervisor
  and service virtual machine
• Control application
• Initiates activation and deactivation process
• Reports attestation results to the user
• All files are stored unprotected in the file
  system
• User knows checksums of the secure loader,
  hypervisor and service virtual machine images

8
Dynamic activation procedure

• Precondition Computer is running with network
  cable disconnected since it was powered on
• User initiates security system activation by
  executing control application which sends
  activation request to the dynaload module
• dynaload reserves part of the hardware
  resources by taking them out of the operating
  system control
• All CPU cores except one
• Certain amount of memory
• Network interface card
• dynaload securely passes control to the secure
  loader which in turn passes it to the hypervisor
• SKINIT instruction is used for transferring
  control securely
• Hypervisor virtualizes the up and running
  operating system and resumes its execution but
  now inside the virtual machine
• Hypervisor launches service virtual machine

9
Virtualizing up and running operating system
Virtual machine
Operating system keeps direct access to hardware
Operating system
Operating system
Hypervisor image
Access is validated
Hypervisor
10
Reserving hardware resources

• Public Linux kernel interfaces are used to
  reserve resources
• Architecture of data leakage preventing system
  allows virtual machines having dedicated access
  to the hardware components
• There are only two virtual machines running
• CPUs with 2 cores are a common case now
• Network interface card is used only by service
  virtual machine
• Other peripheral devices are used only by main
  virtual machine
• Resources are reserved using sysfs file system
• Network Interface Card
• Device driver is unbound from the device
• pci-stub driver is bound instead of it
• Reserving Memory
• Memory banks are hot-unplugged
• get_free_pages() fun?tion may be used instead
• CPU cores
• All CPU are hot-unplugged except bootstrap core
  (BSP)

11
Access control to the reserved resources

• Hypervisor prevents operating system attempts to
  gain control over reserved resources until the
  security system is deactivated
• CPU cores
• Intercepts re-initialization of reserved CPU
  cores
• INIT signal is ignored
• Memory
• Virtual machine may have access only to its own
  memory
• Other physical addresses are removed from Nested
  Page Tables and IOMMU tables thus preventing
  accesses from CPU and DMA contexts
• Network Interface Card
• Intercepts writes to PCI configuration space of
  the network card

12
Attestation

• Security system is activated from the untrusted
  context therefore user needs proofs that it has
  been initialized accordingly
• Attestation is based on the Trusted Computing
  architecture
• Uses Trusted Platform Module security chip
• At the end of the attestation user is provided
  with the signed checksum that represents platform
  configuration
• SHA-1 number signed with TPM identity key
  (private key)
• User must know public key to validate checksum
• Overall checksum is comprised of the checksums of
  individual security system components and NONCE
  number
• NONCE prevents replay attacks
• User reproduces checksum evaluation on separate
  trusted device (e.g. mobile phone)
• User knows checksums for all security system
  components
• Equality of reported and user-evaluated checksums
  as well as successful signature validation means
  that system has been activated accordingly
• Only in this case user may safely connect network
  cable to the computer

13
Attestation procedure
dynaload driver
Secure loader
Hypervisor
SKINIT
JMP
activate
SHA-1

• ZERO ? PCR-17
• HASH(secure loader) ? PCR-17

• HASH(hypervisor) ? PCR-17
• HASH(nonce) ? PCR-17

• SIGN(PCR17 Private Key)
• Signed checksum ? User

PCR17
TPM Private Key
Trusted Platform Module
14
Attestation robustness
SKINIT
Hash
Sign
0x00000000
0xAB17CF86
0xAB17CF86 Signed

• PCR17 may be zeroed only by SKINIT instruction
• SKINIT provides secure control transfer to the
  secure loader and further to the hypervisor
• Interception of SKINIT by malware hypervisor will
  result in incorrect initial PCR17 state
• Final PCR17 value contains accumulated checksum
  for all security system components in the order
  of their activation
• Random number (NONCE) provided by the user
  assures that the displayed checksum has been
  evaluated during this particular activation
• Was not reused from the previous sessions
• Signing checksum with the TPM private key allows
  user to check whether the resulting checksum goes
  from the TPM installed on this computer
• User must know the TPM public key to validate
  signature

15
Dynamic deactivation
User
Hypervisor
Deactivate
Request confirmation (nonce)
Confirm (nonce signed)

• Checks sent nonce against the received one
• Checks users signature
• Deactivates if both of them are valid

• Deactivate command may be sent by malware
• Hypervisor authenticates command by validating
  signature in the confirm deactivation message
  (nonce is sent in it)
• Hypervisor must know users Public key
• This key must be included into hashing procedure,
  e.g. be hardcoded into hypervisor image

16
Results and future work

• AMD x86-64 targeted hypervisor
• 4800 lines of code
• Dynamic activation and deactivation
• Access control to the reserved CPU cores and
  memory
• Linux kernel configured to work completely inside
  memory
• For service virtual machine
• Future work
• Attestation of activation and deactivation
  procedures
• Requires TPM hardware
• Access control to the peripheral devices
• Requires IOMMU hardware

17
Questions?