In this digital era, almost everything is becoming virtualized and put online with the promise of making our lives easier and more convenient. However, this has jeopardized users’ privacy.
More people now realize that many of the free online services aren’t really ‘free’ (nor some paid services) and that the data they are inputting is being collected, distributed and used for profit or for more malicious purposes when they unwittingly agree to the long-winded terms and conditions of use. Various privacy regulations have been introduced to address online privacy concerns. However, privacy regulations may limit the innovation of data technology and hinder free competition on the market.
Is it possible to allow visitors to select trustworthy web services without giving up privacy?
Most online web services communicate via the HTTP protocol, which essentially kicked off the Internet era. Like many foundational protocols, it didn’t provide good security guarantees.
HTTPS was proposed to address this issue and has greatly improved security, protecting web traffic from eavesdropping and tampering. However, HTTPS doesn’t solve the problem of trust. For example:
- Visitors have to trust the digital certificate of the website.
- If users only want to use a certain service managed by the website, they usually need to trust the entire website. If users refuse to trust some of its services, then they have to give up using any of the services provided by that website. That shows a concern that visitors may lose the freedom of using certain services at all. Along with the significant expansion of websites, this problem can frustrate visitors who are forced to choose an all-or-nothing option.
- HTTPS only vouches for communication between two endpoints, protecting web traffic against man-in-the-middle attacks. When it goes beyond communication, visitors lose control of their data. If the underlying host is compromised by malware, the received sensitive information residing in system memory can easily be stolen by an adversary, for example, credit card transactions. Because sensitive data is processed and stored in plaintext, visitors need to accept what a service provider claims to protect data security and privacy with no other measurement but only ‘crowd reputation’.
The result is users have become ignorant and trust web service providers blindly.
It’s time to upgrade HTTPS
Hardware-based Trusted Execution Environment (TEE) technology provides one means to address the privacy concerns that HTTPS can’t handle.
TEE technology uses CPU hardware to isolate the running code and its processing data from other parts of the system strictly through memory-controller managed encryption so that the workload can be kept confidential with integrity. Even privileged users can’t easily break it.
When the web service runs inside TEE, it can greatly reduce the risk of data being stolen or leaked even if the entire website is hacked. Therefore, TEE can help limit a website provider’s liability to a certain degree.
TEE can also provide attestation — a way for applications to obtain assurance that the data is being handled by trusted software in secure execution environments — locally and remotely. Regarding local attestation, the SGX-featured CPU can generate hardware-related credentials, which are encapsulated in a data structure called REPORT.
REPORT can provide information about the details of TEE itself and the initial state of the codes inside TEE, so it can be used as proof of the identity for TEE and the web service running inside. With TEE and its REPORT, the protected service code can retrieve secrets from its relying party locally with strong assurances.
Although local attestation provides assurances, it isn’t sufficient for building trust via the Internet. On the Internet, visitors access the web service in TEE remotely. Therefore, the remote attestation mechanism comes into play, which provides users with three levels of verification:
- Users can verify the service’s identity.
- Users can verify that the service instance is intact.
- Users can verify whether the service instance is running inside a genuine TEE or not.
This process requires a key data structure called QUOTE, which is a derived REPORT signed by the key fused in the CPU. QUOTE can be used to vouch for an identifiable service code, which is running in an authenticated TEE on a remote web host. More importantly, the signatures of the service code, which is embedded in QUOTE, is verifiable and explicitly identifiable to visitors or remote parties.
By using the QUOTE-carried information, visitors can distinguish trustworthy services from less trusted versions when they’re requesting sensitive information, submitting private data, for example, credit card information. Furthermore, the identity of a website, which launches its TEE protected services, becomes secondary evidence to rely on. Therefore, visitors get more freedom to trust such services, that are developed by trustworthy independent software vendors (ISVs), running on specific highly secure CPU hardware platforms only.
In summary, TEE technology addresses major problems of privacy and trustworthiness. It largely reduces the trusted computing base and allows the CPU hardware alone to protect the service code and its processing data. Therefore, visitors don’t need to risk using services that aren’t CPU protected.
HTTPS-Attestable (HTTPA)
We at Intel recently proposed the HTTPA protocol, which seeks to build upon the HTTPS protocol to include TEE technology.
HTTPA introduces a set of new methodologies and workflows to establish trust between any live web service and its visitors with strong assurances.
It enhances online security with remote attestation. Applications use certificates or cryptographic methods to verify that the code running in a server-side TEE is the expected code and that it hasn’t been modified by a rogue process, tool, or administrator.
The process requires extending the HTTPS handshake — the initial network connection between the client and server to verify each other before sending data — to include the attestation. The protocol calls for HTTP preflight request and response, HTTP ATTEST request and response, and HTTP trusted session request and response.
Importantly, the solution leverages the current HTTPS protocol, so it does not introduce as much complexity as other approaches do.
If we can allow visitors to select the trustworthy web service to use, they are no longer bound to the loose granularity of trust for the website, and they can enjoy benefits from the finer granularity of trust for a specific web service.
To learn more about our proposal, please refer to our paper.
Contributors: Hans Wang, AI/ML research scientist, Intel Labs.
Gordon King is a software engineer at Intel.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.