Researchers work to save trusted computing apps from keyloggers

SGX needs I/O protection, Austrian boffins reckon

Intel's Software Guard Extensions started rolling in Skylake processors in October 2015, but it's got an Achilles heel: insecure I/O like keyboards or USB provide a vector by which sensitive user data could be compromised.

A couple of boffins from Austria's Graz University of Technology reckon they've cracked that problem, with an add-on that creates protected I/O paths on top of SGX.

Instead of the handful of I/O technologies directly protected by SGX – most of which have to do with DRM rather than user security – the technology proposed in Samuel Weiser and Mario Werner's Arxiv paper, SGXIO, is a “generic” trusted I/O that can be applied to things like keyboards, USB devices, screens and so on.

And we're not talking about a merely esoteric technology that might soothe the fears of people running cloud apps on multi-tenant infrastructure. The Weiser/Werner proposal would create an SGX-supported trusted path all the way to a remote user's browser to protect (for example) an online banking session – and provide “attestation mechanisms to enable the bank as well as the user to verify that trusted paths are established and functional.”

SGXIO as a way to protect a banking app

The shortcoming SGXIO is trying to fix is that SGX's threat model considers everything outside itself a threat (which isn't a bad thing, in context).

The usual approach for trusted paths is to use encrypted interfaces. The paper mentions the Protected Audio Video Path (PAVP) – but that's a DRM-specific example, and most I/O devices don't encrypt anything.

Hence SGXIO, an attempt to add a generic trusted path to the SGX environment – and with that trusted path reaching to the end user environment, it's an attempt to protect an application from nasties like keyloggers that a miscreant might have installed on a victim's box.

The key architectural concepts in SGXIO are:

• A trusted stack – which contains a security hypervisor, secure I/O drivers, and the trusted boot (TB) enclave; and
• The virtual machine – hosting an untrusted operating system that runs secure user applications.

A user application communicating with the end user:

• 1. Opens an encrypted channel to the secure I/O driver;
• 2. This tunnels through the untrusted operating system, and establishes secure communication with the “generic” user I/O device. The hypervisor binds user devices exclusively to I/O;
• I/O on unprotected devices passes directly through the hypervisor; the trusted path names both the encrypted user-app-to-driver communication; and the exclusive driver-to-device binding;
• The TB enclave provides assurance of the trusted path setup, by attesting the hypervisor.

The paper illustrates this process like this:

SGXIO's trusted stack components

An implementation wouldn't be seamless: the SGXIO paper devices a fair chunk of copy to application design, enclave programming (fortunately something Intel provides resources for), driver design, and hypervisor choice.

Application developers, for example, have to work out a key exchange mechanism (Diffie-Hellman is supported, and SGXIO offers its own lightweight key protocol).

For hypervisors, the paper suggests the seL4 microkernel. Originally developed by Australia's NICTA and now handled by the CSIRO Data61 project, seL4 is a mathematically verified software kernel that was published as open source software in 2014.

SGXIO will get its first public airing at the CODASPY'17 conference in March, being held in Scottsdale Arizona. ®