Aujourd’hui, seuls les paresseux n’ont pas écrit sur la technologie blockchain, les crypto-monnaies et à quel point c’est cool. Mais cet article ne fera pas l'éloge de cette technologie, nous parlerons de ses défauts et des moyens de les éliminer.

Alors qu'il travaillait sur l'un des projets d'Altirix Systems, la tâche s'est posée de confirmer de manière sécurisée et résistante à la censure des données provenant d'une source externe à la blockchain. Il était nécessaire de confirmer les modifications apportées aux enregistrements du troisième système et, sur la base de ces modifications, d'exécuter l'une ou l'autre branche dans la logique du contrat intelligent. La tâche à première vue est assez triviale, mais lorsque la situation financière de l'une des parties participant au processus dépend du résultat de sa mise en œuvre, des exigences supplémentaires apparaissent. Tout d’abord, il s’agit d’une confiance totale dans un tel mécanisme de validation. Mais tout d’abord.

Le problème est que la blockchain elle-même est une entité autonome et fermée, de sorte que les contrats intelligents à l’intérieur de la blockchain ne savent rien du monde extérieur. Dans le même temps, les termes des contrats intelligents sont souvent liés à des informations sur des choses réelles (retard de vol, taux de change, etc.). Pour que les contrats intelligents fonctionnent correctement, les informations reçues de l’extérieur de la blockchain doivent être fiables et vérifiées. Ce problème est résolu en utilisant des oracles tels que Town Crier et DECO. Ces oracles permettent à un contrat intelligent sur le réseau blockchain de faire confiance aux informations provenant d'un serveur web de confiance ; on peut dire que ce sont des fournisseurs d'informations fiables.

Oracles

Imaginez qu'un contrat intelligent transfère 0.001 BTC sur votre portefeuille Bitcoin si votre club de football préféré remporte la Coupe de Russie. En cas de victoire réelle, le contrat intelligent doit transférer des informations sur le club qui a gagné, et un certain nombre de problèmes surviennent ici : où obtenir ces informations, comment les transférer en toute sécurité vers le contrat intelligent et comment garantir que les informations reçu dans le contrat intelligent est valide coïncide réellement avec la réalité ?

En ce qui concerne la source d'information, il peut y avoir 2 scénarios : connecter un contrat intelligent à un site Web de confiance où les informations sur les résultats des matchs sont stockées de manière centralisée, et la deuxième option consiste à connecter plusieurs sites à la fois, puis à sélectionner les informations de la plupart des sources. qui fournissent les mêmes données. Afin de vérifier l'exactitude des informations, des oracles sont utilisés, par exemple Oraclize, qui utilise TLSNotary (TLS Notary Modification to Prove the Authenticity of Data). Mais il y a suffisamment d'informations sur Google sur Oraclize, et il y a plusieurs articles sur Habré. Aujourd'hui, je vais parler des oracles qui utilisent une approche légèrement différente pour transmettre l'information : Town Crier et DECO. L'article fournit une description des principes de fonctionnement des deux oracles, ainsi qu'une comparaison détaillée.

Crieur public

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 : transférer les informations d'un site internet vers un contrat intelligent et s'assurer que les informations délivrées par TC sont les mêmes que sur le site internet. TC utilise TEE (Trusted Execution Environment) pour authentifier la propriété des données. La version originale de TC décrit comment travailler avec Intel SGX.
Town Crier se compose d'une partie à l'intérieur de la blockchain et d'une partie à l'intérieur du système d'exploitation lui-même - TC Server.

TC Contract est sur la blockchain et fait office de frontal pour TC. Il accepte les demandes du CU (contrat intelligent utilisateur) et renvoie une réponse du serveur TC. À l'intérieur du serveur TC se trouve un relais qui établit une connexion entre l'enclave et Internet (trafic bidirectionnel) et connecte l'enclave à la blockchain. Enclave contient progencl, qui est un code qui effectue des requêtes depuis la blockchain et renvoie des messages à la blockchain avec une signature numérique, progencl contient une partie du code du contrat intelligent et remplit essentiellement certaines de ses fonctions.

L'enclave Intel SGX peut être considérée comme une bibliothèque partagée avec une API exécutée via ecall. Ecall transfère le contrôle à l'enclave. L'enclave exécute son code jusqu'à sa sortie ou jusqu'à ce qu'une exception se produise. ocall est utilisé pour appeler des fonctions définies en dehors de l'enclave. Ocall est exécuté en dehors de l’enclave et est traité comme un appel non fiable par celle-ci. Une fois ocall exécuté, le contrôle est rendu à l'enclave.

Dans la partie Enclave, un canal sécurisé est configuré avec un serveur web, l'enclave effectue elle-même une prise de contact TLS avec le serveur cible et effectue toutes les opérations cryptographiques en interne. La bibliothèque TLS (mbedTLS) et le code HTTP réduit ont été exportés vers l'environnement SGX. Enclave contient également des certificats d'autorité de certification racine (une collection de certificats) pour vérifier les certificats des serveurs distants. Request Handler accepte une requête 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 à Relay.

La partie relais comprend l'interface client, TCP, l'interface Blockchain. L'interface client est nécessaire pour certifier le code de l'enclave et communiquer avec le client. Le client envoie une demande d'attestation à l'aide d'ecall et reçoit un horodatage signé par skTC avec att (signature d'attestation), puis att est vérifié à l'aide du service d'attestation Intel (IAS) et l'horodatage est vérifié par un service de temps de confiance. Blockchain Interface vérifie les demandes entrantes et place les transactions sur la blockchain pour la livraison des datagrammes. Geth est un client Ethereum officiel et permet à Relay d'interagir avec la blockchain via des appels RPC.

En travaillant avec TEE, TC vous permet d'exécuter plusieurs enclaves en parallèle, augmentant ainsi de 3 fois la vitesse de traitement de l'information. Si avec une enclave en cours d'exécution, la vitesse était de 15 tx/s, alors avec 20 enclaves en parallèle, la vitesse augmente à 65 tx/s ; à titre de comparaison, la vitesse de fonctionnement maximale dans la blockchain Bitcoin est de 26 tx/s.

DÉCO

DECO (Decentralized Oracles for TLS) a été présenté à CCS'20, fonctionne avec des sites prenant en charge les connexions TLS. Assure la confidentialité et l’intégrité des données.
DECO avec TLS utilise un cryptage symétrique, de sorte que le client et le serveur Web disposent de clés de cryptage et que le client peut falsifier les données de session TLS s'il le souhaite. Pour résoudre ce problème, DECO utilise un protocole de négociation à trois entre le prouveur (contrat intelligent), le vérificateur (oracle) et le serveur Web (source de données).

La façon dont DECO fonctionne est que le vérificateur reçoit une donnée D et lui confirme que D provient du serveur TLS S. Un autre problème est que TLS ne signe pas les données et il est difficile pour le client TLS de prouver que le les données ont été reçues exactement du bon serveur (difficulté de provenance).

Le protocole DECO utilise les clés de chiffrement KEnc et KMac. Le client envoie une requête Q à serveur WebLa réponse du serveur R arrive chiffrée, mais le client et le serveur partagent le même KMac, et le client peut falsifier le message TLS. La solution de DECO consiste à « masquer » le KMac au client (le prouveur) jusqu'à ce qu'il réponde à la requête. Le KMac est alors partagé entre le prouveur et le vérificateur : KpMac et KvMac. Le serveur obtient le KMac pour chiffrer la réponse grâce à l'opération de partitionnement de clé : KpMac ⊕ KvMac = KMac.

En mettant en place une poignée de main à trois, l'échange de données entre le client et le serveur s'effectuera avec une garantie de sécurité.

Lorsqu'on parle de système oracle décentralisé, on ne peut manquer de mentionner Chainlink, qui vise à créer un réseau décentralisé de nœuds oracle compatibles avec Ethereum, Bitcoin et Hyperledger, en tenant compte de la modularité : chaque partie du système peut être mise à jour. Parallèlement, pour assurer la sécurité, Chainlink propose à chaque oracle participant à la tâche d'émettre une combinaison de clés (publiques et privées). La clé privée est utilisée pour générer une signature partielle contenant leur décision concernant la demande de données. Pour obtenir une réponse, il faut combiner toutes les signatures partielles des oracles du réseau.

Chainlink prévoit de mener un premier PoC DECO en mettant l'accent sur les applications financières décentralisées telles que Mixicles. Au moment de la rédaction de cet article, Forbes a annoncé que Chainlink avait acquis DECO de l'Université Cornell.

Attaques contre les oracles

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

1. Injection de code de contact intelligent malveillant sur les nœuds TEE.
   L'essence de l'attaque : transmettre un code de contrat intelligent délibérément incorrect à TEE, ainsi, un attaquant qui a accédé au nœud pourra exécuter son propre contrat intelligent (frauduleux) sur les données décryptées. Cependant, les valeurs de retour seront cryptées avec une clé privée, et le seul moyen d'accéder à ces données est de divulguer le texte chiffré lors du retour/sortie.
   La protection contre cette attaque consiste en ce que l'enclave vérifie l'exactitude du code situé à l'adresse actuelle. Ceci peut être réalisé en utilisant un schéma d'adressage dans lequel l'adresse du contrat est déterminée en hachant le code du contrat.

2. Le texte chiffré de l’état du contrat change de fuite.
   L'essence de l'attaque : les propriétaires des nœuds sur lesquels les contrats intelligents sont exécutés ont accès à l'état du contrat sous forme cryptée en dehors de l'enclave. Un attaquant, ayant pris le contrôle d'un nœud, peut comparer l'état du contact avant et après la transaction et déterminer quels arguments ont été saisis et quelle méthode de contrat intelligent a été utilisée, puisque le code du contrat intelligent lui-même et ses spécifications techniques sont accessibles au public.
   Protection pour assurer la fiabilité du nœud lui-même.

3. Attaques par canal secondaire.
   Un type d'attaque spécial qui utilise la surveillance de la mémoire de l'enclave et l'accès au cache dans divers scénarios. Un exemple d’une telle attaque est Prime and Probe.
   
   Ordre d'attaque :

   • t0 : l'attaquant remplit l'intégralité du cache de données du processus victime.
   • t1 : La victime exécute du code avec des accès mémoire qui dépendent des données sensibles de la victime (clés cryptographiques). La ligne de cache est sélectionnée en fonction de la valeur du keybit. Dans l'exemple de la figure, le bit de clé = 0 et l'adresse X est lue dans la ligne de cache 2. Les données stockées dans X sont chargées dans le cache, déplaçant les données qui s'y trouvaient auparavant.
   • t2 : l'attaquant vérifie lesquelles de ses lignes de cache ont été expulsées (lignes utilisées par la victime). Cela se fait en mesurant le temps d’accès. En répétant cette opération pour chaque bit de clé, l'attaquant obtient la clé entière.

Protection contre les attaques : Intel SGX dispose d'une protection contre les attaques par canal secondaire qui empêche la surveillance des événements liés au cache, mais une attaque Prime and Probe fonctionnera toujours car l'attaquant surveille les événements de cache de son processus et partage le cache avec la victime.

Ainsi, il n’existe actuellement aucune protection fiable contre cette attaque.

Des attaques telles que Spectre et Foreshadow (L1TF), similaires à Prime et Probe, sont également connues. Ils vous permettent de lire les données de la mémoire cache via un canal tiers. Une protection contre la vulnérabilité Spectre-v2 est fournie, qui fonctionne contre deux de ces attaques.

Concernant DECO, la poignée de main à trois constitue un gage de sécurité :

1. Intégrité du prouveur : un prouveur piraté ne peut pas falsifier les informations sur l'origine du serveur et ne peut pas amener le serveur à accepter des demandes non valides ou à répondre de manière incorrecte à des demandes valides. Cela se fait via des modèles de requêtes entre le serveur et le prouveur.
2. Intégrité du vérificateur : un vérificateur piraté ne peut pas amener le prouveur à recevoir des réponses incorrectes.
3. Confidentialité : le vérificateur piraté examine uniquement les informations publiques (demande, nom du serveur).

Dans DECO, seules les vulnérabilités d'injection de trafic sont possibles. Initialement, lors d'une négociation en trois étapes, le vérificateur peut établir l'identité du serveur à l'aide d'un nonce neuf. Cependant, après la négociation, le vérificateur doit s'appuyer sur des indicateurs de couche réseau (Adresses IPPar conséquent, la connexion entre le vérificateur et le serveur doit être protégée contre l'injection de trafic. Ceci est réalisé grâce à l'utilisation d'un proxy.

Comparaison des oracles

Town Crier est basé sur le travail avec une enclave dans la partie serveur, tandis que DECO vous permet de vérifier l'authenticité de l'origine des données à l'aide d'une poignée de main à trois et d'un cryptage des données avec des clés cryptographiques. La comparaison de ces oracles a été réalisée selon les critères suivants : performance, sécurité, coût et praticité.

Crieur public
DÉCO

performance
Plus rapide (0.6 s pour terminer)
Plus lent (10.50hXNUMX pour terminer le protocole)

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

coût de
Plus cher
Moins cher

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

Vitesse: Pour travailler avec DECO, une poignée de main à trois est requise, lors de la configuration via LAN, cela prend 0.37 seconde, pour l'interaction une fois la connexion établie, 2PC-HMAC est efficace (0,13 s par écriture). Les performances de DECO dépendent des suites de chiffrement TLS disponibles, de la taille des données privées et de la complexité des preuves pour une application particulière. En utilisant l'application d'options binaires d'IC3 comme exemple : l'exécution du protocole via LAN prend environ 10,50 secondes. En comparaison, Town Crier prend environ 0,6 seconde pour compléter une application similaire, ce qui est environ 20 fois plus rapide que DECO. Toutes choses égales par ailleurs, TC sera plus rapide.

sécurité: Les attaques contre l'enclave Intel SGX (attaques par canal secondaire) fonctionnent et peuvent causer de réels dommages aux participants au contrat intelligent. Concernant DECO, des attaques liées à l'injection de trafic sont possibles, mais l'utilisation d'un proxy réduit à néant ces attaques. DECO est donc plus sûr.

coût de: Le coût de l'équipement prenant en charge Intel SGX est supérieur au coût de mise en place du protocole dans DECO. C'est pourquoi TC est plus cher.

Praticité: Pour travailler avec Town Crier, un équipement spécial prenant en charge TEE est requis. Par exemple, Intel SGX est pris en charge sur la famille de processeurs Intel Core de 6e génération et versions ultérieures. DECO vous permet de travailler avec n'importe quel équipement, bien qu'il existe un paramètre DECO utilisant TEE. Selon le processus de configuration, la négociation à trois de DECO peut prendre un certain temps, mais ce n'est rien comparé à la limitation matérielle de TC, donc DECO est plus pratique.

Conclusion

En regardant les deux oracles séparément et en les comparant sur quatre critères, il apparaît clairement que Town Crier est inférieur à DECO sur trois points sur quatre. DECO est plus fiable du point de vue de la sécurité de l'information, moins cher et plus pratique, même si la mise en place d'un protocole tripartite peut prendre un certain temps et présente des inconvénients, par exemple des opérations supplémentaires avec des clés de cryptage. TC est plus rapide que DECO, mais les vulnérabilités liées aux attaques par canal secondaire le rendent vulnérable à la perte de confidentialité. Il faut tenir compte du fait que DECO a été introduit en janvier 2020 et qu’il ne s’est pas écoulé suffisamment de temps pour le considérer comme sûr. Town Crier est attaqué depuis 4 ans et a subi de nombreux tests, son utilisation dans de nombreux projets est donc justifiée.

Source: habr.com