Privacy is deeply rooted in human rights as principles or even law. With recent hacks and breaches, more online consumers are aware of their private data being at risk. They have no much effective control over it. Cybersecurity anxiety is the new norm for our time. The demands for cybersecurity and data privacy are rising. There are many interrelated efforts to protect sensitive data at rest, in transit, and in compute. Many of them has been applied to cloud, web service and online business. Hypertext Transfer Protocol Secure (HTTPS) [uptls, https] is widely used to secure request data in motion, but the user data may be at risk i.e. data breach if the processing code is not fully isolated from everything else including the operating system on the host machine. A hardware-based TEE such as Intel© SGX enclave is specifically designed for this concern. Remote system or user can get evidence through attestation to verify a trusted computing base (TCB) identity and state of TEE. Note that TCB includes hardware, firmware, and software to enforce security policy while TEE provides an application with the secure isolation in run time on TCB. Most of existing TEE solutions for protecting web services are very narrowly fit for addressing specific domain problems [selvi2014bypassing]. We propose a general solution to standardize attestation over HTTPS and establish multiple trusted connections to protect and manage requested data for selected HTTP [httpmr] domains. Also, our solution leverage the current HTTPS protocol, so it does not introduce much complexity as other approaches [amann2017mission]. This paper first discusses threat modeling, then goes on to constructing a new protocol for attestation over HTTPS, which is called HTTPS Attestable (HTTPA). We hope this protocol can be considered as new standard in respond to current Web security concerns. Lastly, we suggest that there are two operation modes of it to discover.
2 Threat Modeling
HTTPA is designed to provide assurances for remote attestation and confidential computing between a client and a server under the use case of World Wide Web (WWW) over Internet. For one-way HTTPA, we assume the client is trusted and the sever is not trusted, so the client wants to attest the server to establish trust. The client user can verify those assurances to decide whether they can trust to run the compute workloads on the non-trusted server or not. However, HTTPA does not provide guarantees to turn the server into being trustful. HTTPA involves two parts: communication and computation. Regarding communication security, HTTPA inheres all the assumptions of HTTPS for secure communication, including using TLS and verifying the host identity via certificate. Regarding computation security, HTTPA protocol requires providing further assurance status of remote attestation for the computing workloads to run inside the secure enclave, so the client user can run the workloads in encrypted memory with proved enclave and proved TCB). As such, attack surface of the compute is the secure enclave itself, and everything outside the secure enclave is not trusted. We assume that attackers on the server end have privilege access to the system with the ability to read, write, delete, replay and tamper with the workloads on the un-encrypted memory. On the other hand, we assume software running inside the enclave is trusted if its certificate passes the client user’s verification. Furthermore, HTTPA protocol requires that software vendor identity, TCB, quote verification provider’s identity are verifiable, so the protocol allows the client user to only trust what it agrees to trust by making its custom allowed list and denied list. Also, the HTTPA provides an assurance to confirm the client’s workloads to run inside the expected enclave with expected verified software. As such, users can confirm their workloads are running inside the expected secure enclave in the remote and have the right to reject the computation when the verification results does not meet their security requirements. Running inside the secure enclave can significantly reduce the risks for user’s codes or data to be read or modified by the attack from outside the enclave. Therefore, HTTPA can further reduce attack surface of HTTPS from the whole host system to the secure enclave. Lastly, HTTPA provides freedom for users to determine whether they agree with the assurances results or not before proceeding to the computation and thus further reduces cyber-security risks.
3 Problem Statement
Currently, many software services are vulnerable, there is no sufficient assurance for the computing workloads and the communication among them. We argue that the current HTTPS is not sufficient at all to build the fundamental trust with users, so most people’s private information and digital assets are under great risks. Although we cannot solve the fundamental problem fully, but we can provide assurance to effectively reduce risks. We propose attestation-based assurance protocol to rescue.
4 HTTPS Attestable (HTTPA) Protocol
In this section, we first describe the standard HTTPS protocol on which we build our solution to establish an initial secure channel between the web server and the client. Then, we present the HTTPA protocol by adding a new HTTP method [httpsc] of attestation to establish multiple trusted channels. The new method unifies attestation [remoteattestsrv, dcapattest] and web access operations together for web applications in a general way.
4.1 Standard HTTP over TLS
The primary purpose of TLS [tls] is to protect web application data from unauthorized disclosure and modification when it is transmitted between the client and the server. The HTTPS/TLS security model uses “certificate” to ensure authenticity. The certificate is cryptographically “signed” by a trusted certificate authority (CA) [cmp]. It is the current standard practice for communication over Internet,
Fig 1 shows the HTTPS handshake mechanism. In HTTPS, the communication protocol is encrypted using TLS. It provides authentication of the server to the client as well as integrity guarantees, forward secrecy and replay prevention. but it does not offer any of these security benefits to data that is in compute and at rest. Therefore, the request handling codes running in an untrusted environment which may expose sensitive data to attackers is not trusted. The client user cannot have enough confidence about their private information without being disclosed while the monitoring/notification processes are also running in an untrusted environment, as shown in Fig 1(a).
Fig 1(a) shows the possible attacks if only using HTTPS to protect the request data sent by remote web user or system. they can validate a certificate that represents the specific domain. To authorize a runtime environment is extremely difficult if not well protected by a hardware-based TEE because it is constantly changing. Therefore, the session keys, private key and cleartext are possible to be revealed if they are handled in untrusted environment.
4.2 Attestation over HTTPS
The Intel© SGX technology [intelsgx] is designed to provide hardware-based TEE to reduce the TCB and protect private data in compute. Smaller TCB implies reducing more security risks, because it reduces the exposure to various attacks and reduce the surface of vulnerability. Also, it can use an attestation service to establish a trusted channel. With hardware-based TEE, attestation mechanism can help rigorously verify the TCB integrity, confidentiality and identity. We propose to use remote attestation as the core interface for web users or web services to establish trust as a secure trusted channel to provision secrets or sensitive information. To achieve this goal, we add a new set of HTTP methods, including HTTP preflight [preflight] request/response, HTTP attest request/response, HTTP trusted session request/response, to realize remote attestation which can allow web users and the web services for a trusted connection directly with the code running inside the hardware-based TEE, as shown in 1(b)
The TLS protocol supports the modification of the existing secure channel with the new server certificate and ciphering parameter; there are some efforts on exploring the way to weave attestation process into TLS layer [knauth2019integrating] [bhardwaj2018spx]; however, our method doesn’t rely on it replacing existing secure channel with trusted channel. The main reason is to allow creating multiple trusted channels inside a single TLS-secure channels, as shown in Fig 3.
Fig 4 shows the overview of proposed HTTPA handshake process. The HTTPA handshake process consists of three stages: HTTP preflight request/response, HTTP attestation request/response and HTTP trusted session request/response. HTTP preflight request/response will check whether the platform is attestation available, as shown in Fig 5, has nothing to do with security, and they have no bearing on web application. Rather, the preflight mechanism benefits servers that were developed without an awareness of HTTPA, and it functions as a sanity check between the client and the server that they are both HTTPA-aware. the following attestation request is not simple request, for that, having preflight requests is kind of a ”protection by awareness”. HTTP attestation request/response can provide the quote and quote verification features. HTTP trusted session request/response can establish a trusted session to protect HTTPA traffics in which only the verified TCB codes can see the request data. A trusted session which creates a trusted channel begins with session key generated and end with destroy of it. The trusted session can temporarily store information related to the activities of HTTPA while connected. We describe our HTTPA in terms of one-way HTTPA and mutual HTTPA (mHTTPA) in details in the following sections.
4.3 One-way HTTPA
One-way HTTPA protocol is built on top of standard HTTPS. In this case, only client validates the server to ensure that it receives data from the expected TCB and its hosting server. Our methodology is to perform the HTTP attestation handshake over the established secure channel of HTTPS. Our one-way HTTPA is described as follows. The client and server establish a secure channel if the preflight request for each domain is successful. Preflight request checks if the attestation protocol is accepted by the server for using the “ATTEST” method and headers. It is an “OPTIONS request”, using one HTTP request headers: Access-Control-Request-Method. Following the preflight request/response, a new set of HTTP method is proposed to handle attestation message exchange, as shown in Fig 6. The set of HTTP methods includes HTTP attest request, HTTP attest response, HTTP trusted session request, HTTP trusted session response
First, HTTP attest request is generated by the client, using three new HTTP request headers as follows:
This item contains the date and time at which the attestation quote material was generated on the client side. This is optional for one-way HTTPA protocol.
A unique string identifies a session, Here it’s empty/null. If we had previously connected to a TEE a few seconds ago, we could potentially resume a session and avoid a full attestation handshake to happen again.
This is a set of random bytes generated by the client for key derivation.
This is a list of all of the encryption algorithms that the client is willing to support.
Second, the server will provide the received random bytes to the TEE once it got created and be ready to accept requests. The following is the HTTP attest response, including the headers.
The date and time at which the attestation quote material was generated on server side.
This item contains a quote that was generated by a TCB hosting web service that will handle HTTPA request to the domain in question. the max-age indicates how long the results of ATTEST request can be cached.
This item contains a public key that was generated inside the TEE for exchanging secret keys. Its paired private key should never leave its TEE. In addition, it needs to be bound to the identity of its TCB, so the fingerprint of the public key should be carried by its TCB quote as payload, see Fig 7
This item contains random bytes generated by the server. This will be used later.
The session id is generated by web service running inside the TEE of the server.
This is an encryption algorithm picked by the server for trusted channel encryption.
Third, the client uses the received public key of TEE to wrap a secret which is the pre-session. The wrapped pre-session secret is later used for the key derivation. The web application should send the wrapped pre-session secret directly into the web service TEE, because the secret can only be unwrapped by its paired private key inside the TEE of the web service. HTTP trusted session request includes the following headers:
Contains a pre-session secret wrapped by server-side TEE public key.
In the last step, HTTP trusted session response confirms the pre-session secret has been received by the server.
Thus far, both server and client sides (and only those sides) have a pre-session secret. Each party can calculate the “trusted session keys”, which is derived from the pre-session secret and the random bytes of both parties. To create the trusted session keys, including MAC keys, encryption keys and the IV for cipher block initialization, we need to use PRF, the “Pseudo-Random Function”, to create a ”key block” where we pull data from:
key_block = PRF(pre_session_secret, "trusted session keys", ClientAttest.random + ServerAttest.random)
The pre-session secret is the secret we sent earlier, which is simply an array of bytes. We then concatenate the random bytes sent via HTTP attest request/response from both server and client sides. We use PRF to combine the secrets with the concatenated random bytes from both server/client sides. The bytes from ”key block” are used to populate the following:
client_write_MAC_secret[size] server_write_MAC_secret[size] client_write_key[key_material_length] server_write_key[key_material_length] client_write_IV[IV_size] server_write_IV[IV_size]
The use of Initialization Vectors (IVs) depends on which cipher suite selected at very beginning. Therefore, we need two Message Authentication Code (MAC) keys for each side. In addition, the encrypt keys that both sides will need as well. Both sides will use those trusted session keyss to make sure the encrypted request data haven’t been tampered with as well as only can be seen by the request handlers running in attested TCB.
The client needs to verify the server quote to establish the trustworthiness with the platform, including verifying integrity of the codes running inside the TCB of web services. Usually, there are authorities offers such services, the client can request trusted attestation service to verify the server quote. A verifier quote may be returned to the client along with the verification result, thus, the client side can collect several identities to make a decision, the router, shown in Fig. 7, could be placed in untrusted part of web application to route service requests corresponding to HTTP header, the web applications is expected to create multiple isolated TCB to confidentially handle different kind of requests.
It is the identity issued by a Certificate Authority (CA), and it is used in TLS protocol
It is the identity of web service TCB, measured by hardware and it is embedded in a quote.
It is a signing identity of web service provided by a CA, which signs the TCB prior to distribution
The identity is received from a attestation service along with attesting result.
All those identities need to be validated by verifying their certificate chain. The user can selectively add any combinations of them to allowed list or denied list.
4.4 Mutual HTTPA (mHTTPA)
In addition to one-way HTTPA protocol, HTTPA includes another direction, so both client and server attest each other to ensure that both parties involved in the communication are trusted. Both parties share their quotes on which the verification and validation are performed.
Fig. 8 shows the handshake process of mHTTPA protocol. Compared to one-way HTTPA, see Fig. 6, the difference is that client will send its quote and its TEE public key to server in the first request to allow the server for verifying the quote, and then send a service quote back as response if the client quote got attested.
There is a slight change to the key block generation as well, for now, both sides need to include two pre-session secrets for deriving session keys in their own TEEs respectively.
key_block = PRF(server_pre_session_secret, client_pre_session_secret, "trusted mutual session keys", ClientAttest.random + ServerAttest.random)
We demonstrate the proposed HTTPA protocol where attestation is used to provide assurances that a web service is properly instantiated on a trusted platform. We believe that we can reduce security risks by considering those assurances. The remote web user or system can then gain confidence that only such intended request handlers are running on the trusted hardware. This paper presents the HTTPA as a new protocol to unify the attestation process and HTTPS along with establishing a trusted channel over HTTPS for web service access in a standard and efficient way.