Two Intel staffers believe web services can be made more secure by not only carrying out computations in remote trusted execution environments, or TEEs, but by also verifying for clients that this was done so.
Software engineer Gordon King and Hans Wang, a research scientist at Intel Labs, proposed the protocol to make that possible. In a paper distributed this month through ArXiv, they describe a HTTP protocol called HTTPS Attestable (HTTPA) to enhance online security with remote attestation – a way for apps to obtain an assurance that data will be handled by trusted software in secure execution environments.
Essentially, it’s hoped that applications can verify through certificates and cryptography that code running in a server-side TEE is precisely the code expected to be run, unmodified by a rogue administrator, hijacked OS or hypervisor, network intruder, or malware. Ideally, the TEE should prevent or detect miscreants from snooping on or altering the code and data.
The threat model is fragile with lots of requirements and caveats. If it all falls into place, “HTTPA provides an assurance to confirm the client’s workloads [will] run inside the expected enclave with expected verified software,” as the duo put it in their paper [PDF].
“With HTTPA, we can provide security assurances to establish trustworthiness with web services and ensure integrity of request handling for web users,” King and Wang continued. “We expect that remote attestation will become a new trend adopted to reduce web services security risks, and propose the HTTPA protocol to unify the web attestation and accessing services in a standard and efficient way.”
Software services, the boffins contend, can be hijacked by network intruders, for example, and offer no real assurances about the integrity of computing workloads or communications channels. HTTPS alone, they say, isn’t up to the challenge, but HTTPA perhaps can do better.
HTTPA relies on a TEE and Intel just happens to offer such a thing: Software Guard Extensions, or SGX.
SGX can be used by applications to form what’s called enclaves in memory in which computations on sensitive information can occur in private from all other software thanks to automatic in-memory encryption of data and code as well as other protections. It should be possible to cryptographically check that all is as expected within an enclave; essentially, SGX provides the ingredients for the pair’s proposed remote attestation system.
The neutral zone
In an email to The Register, King and Wang said while their proposal focused on how SGX could be used for more secure web interaction, the protocol accommodates TEEs from other vendors, such as Arm’s TrustZone.
“The protocol is neutral and open to all the industrial participants,” they wrote.
TEEs have been utilized to protect web services before, say King and Wang, but they’ve been deployed to address specific concerns. “We propose a general solution to standardize attestation over HTTPS and establish multiple trusted connections to protect and manage requested data for selected HTTP domains,” they say.
HTTPA assumes the client is trusted and the server is not. So the client can use HTTPA to obtain a guarantee the server can be trusted to handle the requested computation within a TEE. HTTPA, however, doesn’t extend beyond the TEE to vouch for the trustworthiness of the server overall.
Put another way, it takes the security benefits of TLS – certificate-based server authentication, integrity guarantees, forward secrecy and session replay prevention – and extends protection to data at rest and during computation.
HTTPA requires extending the HTTPS handshake process, the networking back-and-forth by which the client and server talk to one another. The protocol calls for three sets of HTTP methods: HTTP preflight request and response; HTTP attest request and response; and HTTP trusted session request and response.
“Preflight request checks if the attestation protocol is accepted by the server for using the ‘ATTEST’ method and headers,” the authors explain in their paper. “It is an ‘OPTIONS request,’ using one HTTP request headers: Access-Control-Request-Method.”
The HTTP attest and HTTP trusted session methods that follow are new; HTTP preflight is an existing mechanism used with Cross-origin resource sharing (CORS) for checking to see whether a server can handle a specific protocol.
A two-way street
For scenarios where two-way attestation is necessary, the authors describe a variant called Mutual HTTPA, or mHTTPA. It’s a bit more complicated however as both the client and the server need to include two pre-session secrets for deriving session keys in their own TEEs.
King and Wang said, “We believe that [HTTPA] could be potentially beneficial to some industries, eg., fintech and healthcare.”
Asked whether the protocol might interfere with services that have stringent bandwidth or latency requirements, they replied, “Further exploration would be needed to confirm any performance impact; however, we do not anticipate any significant performance change from other HTTPS protocols.”
As to whether or when HTTPA might actually be adopted, that’s not clear. Asked whether there’s any plan to submit the spec as an RFC or to undertake some other form of standardization, they said, “We have some ongoing discussions that need to be reviewed by [Intel’s] legal team before [disclosure].” ®