Aujourd'hui, seul un paresseux n'a pas écrit sur la technologie blockchain, les cryptomonnaies et à quel point c'est incroyable. Mais dans cet article, il n'y aura pas d'éloge de cette technologie, nous allons aborder ses inconvénients et les moyens de les surmonter.

En travaillant sur l'un des projets de la société Altirix Systems, un besoin s'est présenté pour une confirmation de données protégée et résistante à la censure à partir d'une source externe pour la blockchain. Il était nécessaire de confirmer les modifications dans les enregistrements d'un tiers et, sur la base de ces modifications, d'effectuer tel ou tel chemin dans la logique du smart contract. La tâche, à première vue, semble assez triviale, mais lorsque le résultat de son exécution dépend de la situation financière d'une des parties impliquées dans le processus, des exigences supplémentaires apparaissent. Avant tout, c'est la confiance totale envers un tel mécanisme de validation. Mais parlons de tout cela dans l'ordre.

Le problème réside dans le fait que la blockchain est en soi un objet autonome et fermé, donc les smart contracts au sein de la blockchain ne savent rien sur le monde extérieur. En même temps, les conditions des smart contracts sont souvent liées à des informations sur des événements réels (retard de vol, taux de change, etc.). Pour un bon fonctionnement des smart contracts, les données obtenues en dehors de la blockchain doivent être fiables et vérifiées. Ce problème est résolu avec l'utilisation d'oracles, tels que Town Crier et DECO. Ces oracles permettent à un smart contract sur la blockchain de faire confiance à des informations provenant d'un serveur web vérifié, on peut dire que ce sont des fournisseurs d'informations fiables.

Oracles

Imaginez un smart contract qui effectue un transfert de 0.001 btc vers votre portefeuille bitcoin en cas de victoire de votre club de football préféré en Coupe de Russie. En cas de victoire réelle, il est nécessaire de transmettre au smart contract l'information concernant le club gagnant, et c'est ici qu'un certain nombre de problèmes surviennent : où obtenir cette information, comment la transmettre en toute sécurité au smart contract et comment s'assurer que l'information transmise au smart contract correspond bien à la réalité ?

Dans le domaine des sources d'information, deux scénarios peuvent se présenter : connecter un contrat intelligent à un site web de confiance, où les résultats des matchs sont stockés de manière centralisée, ou connecter plusieurs sites et sélectionner les informations à partir de la majorité des sources fournissant des données identiques. Pour s'assurer de l'exactitude des informations, des oracles sont utilisés, comme Oraclize, qui utilise TLSNotary (une modification de TLS pour prouver l'authenticité des données). Cependant, il existe suffisamment d'informations sur Oraclize dans Google, et plusieurs articles sur Habré. Aujourd'hui, je vais parler des oracles qui adoptent une approche légèrement différente pour transmettre des informations : Town Crier et DECO. Cet article décrit les principes de fonctionnement des deux oracles ainsi qu'une comparaison détaillée.

Town Crier

Town Crier (TC) a été introduit par IC3 (The Initiative for CryptoCurrencies and Contracts) en 2016 lors de CCS’16. L'idée principale de TC est de transmettre des informations d'un site web à un contrat intelligent et de s'assurer que les informations délivrées par TC sont identiques à celles présentes sur le site. TC utilise un TEE (Trusted Execution Environment) pour garantir l'authenticité de la propriété des données. Dans sa version originale, TC décrit le travail avec Intel SGX.
Town Crier se compose d'une partie dans la blockchain et d'une partie au sein du système d'exploitation lui-même — le serveur TC.

Le contrat TC se trouve dans la blockchain et agit comme l'interface utilisateur pour TC. Il reçoit des requêtes du CU (contrat intelligent utilisateur) et renvoie des réponses du serveur TC. Au sein du serveur TC se trouve un relais qui établit la connexion entre l'enclave et Internet (trafic bidirectionnel) et relie l'enclave à la blockchain. L'enclave contient progencl, qui est un code exécutant les requêtes de la blockchain et renvoyant des messages dans la blockchain avec une signature numérique ; progencl inclut une partie du code du contrat intelligent et exécute en fait certaines de ses fonctions.

L'enclave Intel SGX peut être considérée comme une bibliothèque commune avec une API, fonctionnant par le biais d'ecall. Ecall transfère le contrôle à l'enclave. L'enclave exécute son code jusqu'à son achèvement ou jusqu'à ce qu'une exception se produise. Pour appeler des fonctions définies en dehors de l'enclave, des ocall sont utilisés. Ocall s'exécute en dehors de l'enclave et est traité comme un appel non fiable. Après l'exécution de l'ocall, le contrôle est restitué à l'enclave.

Dans la partie Enclave, un canal sécurisé est configuré avec le serveur web, l'enclave effectue elle-même la poignée de main TLS avec le serveur cible et exécute toutes les opérations cryptographiques en interne. La bibliothèque TLS (mbedTLS) et le code HTTP en version réduite sont exportés vers l'environnement SGX. De plus, l'Enclave contient des certificats racine CA (une collection de certificats) pour vérifier les certificats des serveurs distants. Le gestionnaire de requêtes accepte une demande de datagramme au format fourni par Ethereum, la déchiffre et l'analyse. Ensuite, il génère une transaction Ethereum contenant le datagramme demandé, la signe avec skTC et la transmet au Relay.

La partie Relay comprend l'interface client, TCP et l'interface blockchain. L'interface client est nécessaire pour l'attestation du code de l'enclave et la communication avec le client. Le client envoie une requête d'attestation via ecall et reçoit un horodatage, signé par skTC, avec att (signature d'attestation), ensuite att est confirmé via Intel Attestation Service (IAS) et l'horodatage est vérifié par un service de temps de confiance. L'interface blockchain vérifie les demandes entrantes et place les transactions dans la blockchain pour la livraison des datagrams. Geth est le client officiel Ethereum et permet à Relay d'interagir avec la blockchain via des appels RPC.

En travaillant avec TEE, TC permet de lancer plusieurs enclaves en parallèle, augmentant ainsi la vitesse de traitement des informations par trois. Si avec une seule enclave en fonctionnement, la vitesse était de 15 tx/sec, alors avec 20 enclaves lancées simultanément, la vitesse augmente jusqu'à 65 tx/sec, pour comparaison, la vitesse maximale de fonctionnement dans la blockchain Bitcoin est de 26 tx/sec.

DECO

DECO (Oracles Décentralisés pour TLS) a été présenté lors de CCS'20, il fonctionne avec des sites prenant en charge la connexion TLS. Il garantit la confidentialité et l'intégrité des données.
DECO avec TLS utilise le cryptage symétrique, permettant ainsi au client et au serveur web de disposer de clés de cryptage, et le client, s'il le souhaite, peut falsifier les données de la session TLS. Pour résoudre ce problème, DECO utilise un protocole de poignée de main tripartite entre le prouveur (smart contract), le vérificateur (oracle) et le serveur web (source de données).

Le principe de fonctionnement de DECO est que le vérificateur (prouveur) obtienne une partie des données D et confirme au vérificateur que D provient du serveur TLS S. Un autre problème est que TLS ne signe pas les données et le client TLS a du mal à prouver que les données proviennent bien de ce serveur (difficulté de provenance).

Dans le protocole DECO, des clés de chiffrement KEnc et KMac sont utilisées. Le client envoie une requête Q à serveur web, la réponse du serveur R arrive sous forme chiffrée, mais le client et le serveur possèdent les mêmes KMac, permettant au client de falsifier un message TLS. La solution de DECO consiste à "cacher" KMac du client (prover) jusqu'à ce qu'il réponde à la requête. Maintenant, KMac est divisé entre le prover et le vérificateur — KpMac et KvMac. Le serveur obtient KMac pour chiffrer la réponse à l'aide de l'opération sur les parties de la clé KpMac ⊕ KvMac = KMac.

Avec un échange à trois voies établi, les données entre le client et le serveur seront échangées avec une garantie de sécurité.

En parlant des systèmes d'oracles décentralisés, on ne peut pas manquer de mentionner Chainlink, qui cherche à créer un réseau décentralisé de nœuds d'oracle compatible avec Ethereum, Bitcoin et Hyperledger, en tenant compte de la modularité : chaque partie du système peut être mise à jour. De plus, pour assurer la sécurité, Chainlink propose à chaque oracle participant à la mission d'émettre une combinaison de clés (publique et privée). La clé privée est utilisée pour générer une signature partielle, qui contient leur réponse à la demande de données. Pour obtenir une réponse, il est nécessaire de combiner toutes les signatures partielles des oracles du réseau.

Chainlink prévoit de réaliser un PoC DECO initial axé sur des applications financières décentralisées telles que Mixicles. Au moment de la rédaction, une nouvelle sur Forbes indiquait que Chainlink avait acquis DECO de l'Université Cornell.

Attaques sur les oracles

Du point de vue de la sécurité de l'information, les attaques suivantes sur Town Crier ont été examinées :

1. Injection de code malveillant sur des nœuds TEE.
   Nature de l'attaque : transmission d'un code de contrat intelligent manifestement incorrect dans le TEE, permettant à un attaquant ayant accès au nœud d'exécuter son propre contrat intelligent (frauduleux) sur des données déchiffrées. Cependant, les valeurs retournées seront chiffrées à l'aide de la clé privée, et la seule manière d'accéder à ces données réside dans la fuite du texte chiffré lors du retour / de la sortie.
   La protection contre cette attaque réside dans la vérification par l'enclave de la validité du code à l'adresse actuelle. Cela peut être accompli grâce à un schéma d'adressage où l'adresse du contrat est déterminée par le hachage du code du contrat.

2. Les changements de ciphertext de l'état du contrat provoquent des fuites.
   La nature de l'attaque : Les propriétaires des nœuds sur lesquels s'exécutent des smart contracts ont accès à l'état du contrat sous une forme chiffrée en dehors de l'enclave. Un attaquant qui prend le contrôle d'un nœud peut comparer l'état du contrat avant et après l'exécution d'une transaction et peut déterminer quels arguments ont été ajoutés et quelle méthode spécifique du smart contract a été utilisée, car le code même du smart contract et ses spécifications techniques sont accessibles au public.
   Protection en garantissant la fiabilité du nœud lui-même.

3. Attaques par canaux auxiliaires.
   Un type particulier d'attaques qui utilise la surveillance des accès à la mémoire et au cache de l'enclave dans divers scénarios. Un exemple de cette attaque est le Prime and Probe.
   
   Procédure de l'attaque :

   • t0 : L'attaquant remplit tout le cache de données du processus de la victime.
   • t1 : La victime exécute du code avec des accès à la mémoire qui dépendent des données confidentielles de la victime (clés cryptographiques). Le choix de la ligne de cache se fait selon la valeur de keybit. Dans l'exemple illustré, keybit = 0 et l'adresse X a été lue dans la ligne de cache 2. Les données stockées dans X sont chargées dans le cache, évincant les données qui y étaient précédemment.
   • t2 : L'attaquant vérifie quelles de ses lignes de cache ont été évincées — celles utilisées par la victime. Cela se fait en mesurant le temps d'accès. En répétant cette opération pour chaque keybit, l'attaquant obtient la clé entière.

Protection contre l'attaque : Intel SGX dispose d'une protection contre les attaques par canaux auxiliaires, qui interdit la surveillance des événements liés au cache, mais l'attaque Prime and Probe réussira quand même, car l'attaquant observe les événements du cache de son propre processus et partage le cache avec la victime.

Ainsi, à ce jour, il n'existe pas de protection fiable contre cette attaque.

On connaît également des attaques de type Spectre et Foreshadow (L1TF), similaires à Prime and Probe. Elles permettent de lire des données à partir de la mémoire cache par le biais d'un canal auxiliaire. Une protection contre la vulnérabilité Spectre-v2 est prévue, qui fonctionne contre ces deux attaques.

Concernant DECO, un handshake à trois voies garantit une sécurité :

1. Intégrité du Prover : un prover compromis ne peut pas falsifier les informations sur l'origine du serveur et ne peut pas amener le serveur à accepter des requêtes non valides ou à répondre incorrectement à des requêtes valides. Cela est réalisable via des modèles de requêtes entre le serveur et le prover.
2. Intégrité du Vérificateur : un vérificateur compromis ne peut pas amener le prover à recevoir des réponses incorrectes.
3. Confidentialité : Un verifier piraté n'examine que les informations publiques (requête, nom du serveur).

Dans DECO, seules les vulnérabilités liées à l'injection de trafic sont possibles. Au départ, lors de la poignée de main à trois voies, le verifier peut établir l'identité du serveur grâce à un fresh nonce. Cependant, après la poignée de main, le verifier doit compter sur des indicateurs de niveau réseau (adresses IP). Ainsi, la liaison entre le verifier et le server doit être protégée contre l'injection de trafic. Cela est réalisé en utilisant un Proxy.

Comparaison des oracles

Town Crier repose sur le travail avec un enclavement côté serveur, tandis que DECO permet la vérification de l'authenticité de l'origine des données grâce à une poignée de main à trois voies et à un chiffrement des données par des clés cryptographiques. La comparaison des données des oracles a été effectuée selon les critères suivants : performance, sécurité, coût et praticité.

Town Crier
DECO

performance
Plus rapide (0,6 s pour finir)
Plus lent (10,50 s pour finir le protocole)

sécurité
Moins sécurisé
Plus sécurisé

le coût
Plus cher
Moins cher

praticité
Nécessite un matériel spécial
Fonctionne avec n'importe quel serveur prenant en charge TLS

Performance: Pour utiliser DECO, une configuration de la poignée de main à trois voies est requise, ce qui prend 0,37 secondes via LAN, et pour les interactions après l'établissement de la connexion, 2PC-HMAC est efficace (0,13 s pour l'écriture). La performance de DECO dépend des suites de chiffrement TLS disponibles, de la taille des données personnelles et de la complexité des preuves pour une application donnée. Par exemple, pour l'application d'options binaires d'IC3 : la fin du protocole via LAN prend environ 10,50 s. En comparaison, Town Crier nécessite environ 0,6 seconde pour exécuter une application similaire, soit environ 20 fois plus rapide que DECO. Dans des conditions équivalentes, TC sera plus rapide.

Sécurité: Les attaques sur l'enclavement Intel SGX (attaques par canaux auxiliaires) fonctionnent et peuvent causer des dommages réels aux participants du smart contract. Pour DECO, des attaques liées à l'injection de trafic sont possibles, mais l'utilisation de proxy les annule. Ainsi, DECO est plus sécurisé.

Coût: Le coût du matériel compatible avec Intel SGX est supérieur au coût de configuration du protocole dans DECO. Par conséquent, TC est plus cher.

Praticité: Pour utiliser Town Crier, un équipement spécial prenant en charge TEE est indispensable. Par exemple, Intel SGX est supporté sur les processeurs de la famille Intel Core de 6ème génération et plus. DECO, en revanche, fonctionne avec n'importe quel équipement, bien qu'il existe une configuration DECO utilisant TEE. Le processus de configuration du protocole à trois voies pour DECO peut prendre un certain temps, mais cela ne se compare en rien à la contrainte matérielle de TC, donc DECO est plus pratique.

Conclusion

En examinant les deux oracles séparément et en les comparant selon quatre critères, on constate que Town Crier est inférieur à DECO sur trois des quatre points. DECO est plus fiable en termes de sécurité informatique, moins cher et plus pratique, bien que la configuration du protocole à trois voies puisse prendre du temps et ait ses inconvénients, comme des opérations supplémentaires sur les clés de cryptage. TC fonctionne plus rapidement que DECO, mais la vulnérabilité liée aux attaques par canal auxiliaire le rend risqué en matière de confidentialité. Il faut également prendre en compte que DECO a été présenté en janvier 2020, et il n'y a pas eu assez de temps pour le considérer comme sûr. Town Crier a déjà été soumis à des attaques pendant 4 ans et a traversé de nombreux tests, ce qui justifie son utilisation dans de nombreux projets.

Source : habr.com