Transcript Технология виртуализации: акцент на защ

Institute for System Programming
Russian Academy of Sciences
An approach to on the fly
activation and deactivation of
virtualization-based security systems
Denis Efremov ([email protected])
Pavel Iakovenko ([email protected])
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
2/17
Preventing data leakages through network
Main virtual machine
Network
isolated
Linux
Network
connected
Sensitive data
Service virtual machine
Linux
Trusted
process
Delegate
Hypervisor
Access
allowed
Access
NOT
allowed
Internet
3/17
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
–
–
•
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
–
•
It may be “OFF” when network cable is disconnected
It must be “ON” when trusted applications that require network access are executed
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
4/17
Objectives
•
Make it possible to dynamically activate security system on user request without
rebooting the computer
–
–
–
•
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
–
•
Launch hypervisor
Virtualize the up and running operating system
Launch service virtual machine
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
5/17
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
6/17
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
7/17
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
8/17
Virtualizing up and running operating system
Virtual machine
Operating system
Operating system
Hypervisor
Access is validated
Hypervisor image
Operating
system keeps
direct access
to hardware
9/17
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)
10/17
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
11/17
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
–
•
At the end of the attestation user is provided with the signed checksum that represents
platform configuration
–
–
•
NONCE prevents replay attacks
User reproduces checksum evaluation on separate trusted device (e.g. mobile phone)
–
•
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
–
•
Uses Trusted Platform Module security chip
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
12/17
Attestation procedure
“activate” “dynaload”
driver
• ZERO  PCR-17
• HASH(secure loader)  PCR-17
SKINIT
Secure
loader
JMP
 PCR-17
• HASH(nonce)  PCR-17
• HASH(hypervisor)
PCR17
SHA-1
Hypervisor
• SIGN(PCR17 | Private Key)
• Signed checksum  User
TPM Private Key
Trusted Platform Module
13/17
Attestation robustness
SKINIT
•
0x00000000
Hash
0xAB17CF86
Sign
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
14/17
Dynamic deactivation
User
Hypervisor
Deactivate
Request confirmation (nonce)
Confirm (nonce | signed)
• Checks sent nonce against the received one
• Checks user’s 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 user’s Public key
– This key must be included into hashing procedure, e.g. be hardcoded
into hypervisor image
15/17
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
16/17
Questions?
17/17