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

1. Institute for System Programming Russian Academy of Sciences An approach to on the flyactivation and deactivation ofvirtualization-based security systems Denis Efremov (evdenis@gmail.com) Pavel Iakovenko (yak@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 haveaccess 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 proofsthat 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 ofreported 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 “activate” “dynaload” driver SKINIT Secure loader JMP Hypervisor 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 Sign Hash 0x00000000 0xAB17CF86 0xAB17CF86 | Signed • PCR17 may be zeroed only by SKINIT instruction • SKINITprovides 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 • 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 Request confirmation (nonce) Confirm (nonce | signed) • Checks sent nonce against the received one • Checks user’s signature • Deactivates if both of them are valid

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?