HTTPA : vers une attestation d’intégrité sur TLS ?

Greffer à HTTPS un mécanisme d’attestation de l’intégrité des environnements d’exécution : c’est l’idée de HTTPA.

HTTPS sécurise le transport des données. Mais pourrait-on l’adapter pour garantir également leur protection lors du traitement ? C’est l’objet de travaux dont Gordon King et Hans Wang, d’Intel, viennent de rendre compte. Avec, à la clé, une proposition : HTTPA*.

Au cœur de ces travaux, il y a les environnements d’exécution de confiance (TEE). Chez Intel, ces zones de mémoire privées entrent dans le cadre du portefeuille SGX (Software Guard Extensions). Elles incluent des mécanismes d’attestation distante. L’idée, ici, est d’en standardiser l’usage, en les greffant à HTTPS, sur la couche TLS.

HTTPA vs HTTPS

La démarche de King et Wang consiste à ajouter trois méthodes HTTP correspondant à autant d’étapes de négociation client-serveur.

handshake

Le client envoie d’abord une requête preflight pour déterminer si le serveur prend en charge HTTPA. Dans l’affirmative, il adresse une requête attest. Celle-ci contient trois (ou quatre) en-têtes :

– Date et heure de création de la requête (facultatif)

– Identifiant de session (pour reprendre une session sans renégociation)

– Bits aléatoires dont sera dérivée une clé de chiffrement

– Liste d’algorithmes de chiffrement acceptés

Le serveur transmet les bits aléatoires au TEE et répond au client avec, entre autres, un clé publique et une autre série de bits aléatoires. Le client utilise cette clé pour encapsuler un secret qu’il communique au serveur. Et que seul le TEE peut déchiffrer. Client et serveur peuvent alors déduire des clés de session.

schéma global HTTPA

L’implémentation que décrivent King et Wang concerne l’attestation des serveurs. Mais HTTPA peut aussi permettre à un client de prouver son intégrité.

* HTTPS Attestable

Illustration principale © ktsdesign – Adobe Stock