Intel engineers have proposed a new protocol, HTTPA (HTTPS Attestable), extending HTTPS with additional guarantees of the security of the calculations performed. HTTPA helps ensure the integrity of the user’s request is processed on the server and make sure that the web-service is trustworthy and works in TEE -okruzhenii (Trusted Execution Environment) server code was not changed as a result of hacking or sabotage administrator.
HTTPS protects the transmitted data at the stage of transmission over the network, but cannot exclude the violation of their integrity as a result of attacks on the server. Isolated enclaves created with technologies such as Intel SGX (Software Guard Extension), ARM TrustZone, and AMD PSP (Platform Security Processor) protect critical computing and reduce the risk of leaking or altering sensitive information at the endpoint.
HTTPA allows the use of attestation tools provided by Intel SGX to ensure the authenticity of transmitted information , which validates the authenticity of the enclave in which the calculations were performed. Essentially, HTTPA extends HTTPS with the ability to remotely attest an enclave to validate that it is running in a genuine Intel SGX environment and the web service can be trusted. The protocol is initially being developed as a universal one and, in addition to Intel SGX, can be implemented for other TEE systems.
In addition to the standard HTTPS process of establishing a secure connection, HTTPA additionally requires the negotiation of a trusted session key. The protocol introduces a new “ATTEST” HTTP method, which allows you to process three types of requests and responses:
- “preflight” to check if the remote side supports enclave attestation;
- “attest” to agree on the attestation parameters (selection of a cryptographic algorithm, exchange of random sequences unique for the session, generation of a session identifier and transfer of the enclave’s public key to the client);
- “trusted session” – generation of a session key for trusted information exchange. The session key is generated on the basis of a previously agreed pre-session secret, generated by the client using the TEE public key received from the server, and random sequences generated by each side.
HTTPA assumes that the client is trustworthy and the server is not, i.e. the client can use this protocol to verify computations in a TEE environment. At the same time, HTTPA does not guarantee that other non-TEE computations made during the operation of the web server have not been compromised, which requires a separate approach to the development of web services. Thus, HTTPA is mainly aimed at use with specialized services that have increased requirements for the integrity of information, such as financial and medical systems.
For situations where calculations in TEE must be confirmed for both the server and the client, a variant of the mHTTPA (Mutual HTTPA) protocol is provided that performs two-way verification. This option is more complicated due to the need for two-way generation of session keys for the server and client.
