Next week at Intel Developer Forum 2016 I will be demonstrating a prototype feature of the Bromium platform that leverages Intel Secure Guard Extensions (SGX) to protect a user’s on-line credentials from theft. In this post I aim to briefly describe SGX and highlight its complementary use with micro-virtualization.
Today Bromium uses micro-virtualization to hardware isolate end-user tasks that access untrusted content and the web, to protect the endpoint host OS. Although we monitor the host (desktop) for signs of compromise using the same LAVA technology that gives us precise forensics for introspection of micro-VMs, we have always wanted to enhance the protection of the host from (for example) east-west attacks. We want to protect high-value information on the endpoint (eg: credentials) from theft using a clean, hardware based capability that does not rely on detection, and SGX is a key technology that helps us to achieve this.
To quote Intel:
Intel® Software Guard Extensions (Intel® SGX) is an Intel technology for application developers who are seeking to protect select code and data from disclosure or modification. Intel SGX makes such protections possible through the use of enclaves, which are protected areas of execution. Application code can be put into an enclave by special instructions and software made available to developers via the Intel® SGX SDK. The Intel SGX SDK is a collection of APIs, libraries, documentation, sample source code, and tools that allows software developers to create and debug Intel SGX enabled applications in C/C++.
SGX first shipped in Skylake CPUs, and the technology has a promising roadmap that you can explore in the links below. It will heavily influence the security of both cloud computing infrastructure and enhance resilience of endpoint systems and applications over time. One can envisage SGX eliminating the need for dedicated HSMs, for example. Of course, like any crypto-related security technology it has the potential for misuse, an area that is being explored by the research community.
- Intel® Software Guard Extensions(Intel® SGX)
- The Invisible Things Lab’s blog: Thoughts on SGX
- Cryptology ePrint Archive: Report 2016/086
SGX today has some substantial limitations that limit its utility as a general purpose secure enclave:
- Windows SGX enclaves today leave about 80MB of memory for the application developer to use. Great for storing sensitive data, but not useful for general purpose compute or storing large data structures.
- Paging or swapping SGX memory requires specific support in the host operating system or the hypervisor. Intel has released drivers for SGX for Windows 7-10, but the fixed-size SGX enclave memory must be allocated by the BIOS / UEFI stack, and that memory is specifically out of reach of the OS memory management code, so enclave management is up to the developer. This problem is apparently addressed in Windows 10 TH2, but I haven’t been able to validate that. Ultimately I expect enclave memory to be fully controlled by the host OS or hypervisor.
- (But – you guessed it – for current systems the Microvisor, which is just a specialized hypervisor, can with a couple of tweaks, manipulate the memory in the enclave. More on this in another post.)
Incorporating SGX into Bromium Protected Chrome
We have prototyped an extension to our product that uses Intel SGX to protect the browser password manager from attack by malware that executes on the Windows host. The goal is to ensure that in addition to our existing protection for the user’s Windows credentials, we protect credentials that the user relies on to access SaaS sites, for work or play.
Today Bromium isolates untrusted sites in micro-VMs, as shown above. Malware that shows up in a particular tab of the browser is hardware isolated by the CPU virtualization extensions, and cannot access high-value data, credentials, devices, networks or sites. The browser chrome runs on the Windows desktop and the user experience is composed by a browser extension that ensures that the output from the right isolated micro-VM is composited into the tab that the user is viewing.
We extended this architecture to support use of SGX on the host OS as shown in the following diagram. Untrusted sites are isolated as before, but the diagram shows that a SaaS site (here Salesforce.com) is running natively on the host OS. We have extended our browser support for Chrome also to protect the browser password manager by embedding it in an SGX enclave. When a site prompts the user to enter credentials, we ensure that the site is trusted, that its TLS certificate has not been revoked, and then inject the relevant credentials from the SGX enclave as shown below. On Windows 10 systems with Windows Hello, where we have an assurance (from biometric hardware authentication) of the user’s identity, we have an additional assurance that only the real user can access credentials in the enclave, protecting users from malicious insiders who might borrow their PC for a bit to browse the web.
- Chrome stores website passwords together with the associated html form data for each site in a flat file, in sql-lite format. Passwords are looked up via fuzzy matching on the form data. The form data is stored in clear-text whereas the password is encrypted with a key seeded from the user’s Windows logon credentials.
- The SGX protected enclave exposes APIs that permit the secure browser to access it, supporting methods to create(), update(), search(), retrieve() the form & password data.
- Even if an attacker knows the user password and has managed to get access to the password file (for example by uploading it to a C&C server) he will be unable to access information in the file because it is sealed by the enclave. The only way to access information in the file is to execute the enclave locally, in the context of the host and the secure browser.
- In our implementation we store the password and form data in an SGX sealed password file. All search and update operations scan through the file in linear fashion loading a single entry into memory at a time. Each entry is sealed separately and preceded by the length of the sealed data.
- Through enclave sealing we can make the encryption of the data robust to updates, since the complexity is managed by SGX and the enclave.
- The Bromium password manager manages the enclave via an “enclave access” DLL which also provides external functions used by the enclave to scan and write to the password file.
- Our modifications are directly applicable to main-line Chrome (and not only the Bromium product) and we hope to offer it as an upstream patch once we’ve cleaned it up for submission.
We are in the earliest days of our work on SGX, but so far are convinced that it can substantially enhance protection without adding substantial complexity to our product. Watch this space as our product plans for use of this technology become firmer. If you’re coming to IDF16, drop by the software developer pavilion and I’ll give you a tour.