{"id":93794,"date":"2020-09-10T07:42:27","date_gmt":"2020-09-10T05:42:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/town-crier-vs-deco-kakoj-orakul-ispolzovat-v-blokchejne"},"modified":"2020-09-10T07:42:27","modified_gmt":"2020-09-10T05:42:27","slug":"town-crier-vs-deco-kakoj-orakul-ispolzovat-v-blokchejne","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/town-crier-vs-deco-kakoj-orakul-ispolzovat-v-blokchejne","title":{"rendered":"Town Crier vs DECO : quel oracle utiliser dans la blockchain ?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Aujourd'hui, seul un paresseux n'a pas \u00e9crit sur la technologie blockchain, les cryptomonnaies et \u00e0 quel point c'est incroyable. Mais dans cet article, il n'y aura pas d'\u00e9loge de cette technologie, nous allons aborder ses inconv\u00e9nients et les moyens de les surmonter. <\/p>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

En travaillant sur l'un des projets de la soci\u00e9t\u00e9 Altirix Systems, un besoin s'est pr\u00e9sent\u00e9 pour une confirmation de donn\u00e9es prot\u00e9g\u00e9e et r\u00e9sistante \u00e0 la censure \u00e0 partir d'une source externe pour la blockchain. Il \u00e9tait n\u00e9cessaire 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\u00e2che, \u00e0 premi\u00e8re vue, semble assez triviale, mais lorsque le r\u00e9sultat de son ex\u00e9cution d\u00e9pend de la situation financi\u00e8re d'une des parties impliqu\u00e9es dans le processus, des exigences suppl\u00e9mentaires apparaissent. Avant tout, c'est la confiance totale envers un tel m\u00e9canisme de validation. Mais parlons de tout cela dans l'ordre. <\/p>\n

<\/a><\/noindex><\/p>\n

Le probl\u00e8me r\u00e9side dans le fait que la blockchain est en soi un objet autonome et ferm\u00e9, donc les smart contracts au sein de la blockchain ne savent rien sur le monde ext\u00e9rieur. En m\u00eame temps, les conditions des smart contracts sont souvent li\u00e9es \u00e0 des informations sur des \u00e9v\u00e9nements r\u00e9els (retard de vol, taux de change, etc.). Pour un bon fonctionnement des smart contracts, les donn\u00e9es obtenues en dehors de la blockchain doivent \u00eatre fiables et v\u00e9rifi\u00e9es. Ce probl\u00e8me est r\u00e9solu avec l'utilisation d'oracles, tels que Town Crier et DECO. Ces oracles permettent \u00e0 un smart contract sur la blockchain de faire confiance \u00e0 des informations provenant d'un serveur web v\u00e9rifi\u00e9, on peut dire que ce sont des fournisseurs d'informations fiables. <\/p>\n

<\/p>\n

Oracles<\/h1>\n

<\/p>\n

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\u00e9f\u00e9r\u00e9 en Coupe de Russie. En cas de victoire r\u00e9elle, il est n\u00e9cessaire de transmettre au smart contract l'information concernant le club gagnant, et c'est ici qu'un certain nombre de probl\u00e8mes surviennent : o\u00f9 obtenir cette information, comment la transmettre en toute s\u00e9curit\u00e9 au smart contract et comment s'assurer que l'information transmise au smart contract correspond bien \u00e0 la r\u00e9alit\u00e9 ? <\/p>\n

<\/p>\n

Dans le domaine des sources d'information, deux sc\u00e9narios peuvent se pr\u00e9senter : connecter un contrat intelligent \u00e0 un site web de confiance, o\u00f9 les r\u00e9sultats des matchs sont stock\u00e9s de mani\u00e8re centralis\u00e9e, ou connecter plusieurs sites et s\u00e9lectionner les informations \u00e0 partir de la majorit\u00e9 des sources fournissant des donn\u00e9es identiques. Pour s'assurer de l'exactitude des informations, des oracles sont utilis\u00e9s, comme Oraclize, qui utilise TLSNotary (une modification de TLS pour prouver l'authenticit\u00e9 des donn\u00e9es). Cependant, il existe suffisamment d'informations sur Oraclize dans Google, et plusieurs articles sur Habr\u00e9. Aujourd'hui, je vais parler des oracles qui adoptent une approche l\u00e9g\u00e8rement diff\u00e9rente pour transmettre des informations : Town Crier et DECO. Cet article d\u00e9crit les principes de fonctionnement des deux oracles ainsi qu'une comparaison d\u00e9taill\u00e9e. <\/p>\n

<\/p>\n

Town Crier<\/h1>\n

<\/p>\n

Town Crier (TC) a \u00e9t\u00e9 introduit par IC3 (The Initiative for CryptoCurrencies and Contracts) en 2016 lors de CCS\u201916. L'id\u00e9e principale de TC est de transmettre des informations d'un site web \u00e0 un contrat intelligent et de s'assurer que les informations d\u00e9livr\u00e9es par TC sont identiques \u00e0 celles pr\u00e9sentes sur le site. TC utilise un TEE (Trusted Execution Environment) pour garantir l'authenticit\u00e9 de la propri\u00e9t\u00e9 des donn\u00e9es. Dans sa version originale, TC d\u00e9crit le travail avec Intel SGX.
\nTown Crier se compose d'une partie dans la blockchain et d'une partie au sein du syst\u00e8me d'exploitation lui-m\u00eame \u2014 le serveur TC.
\n\"Town
\nLe contrat TC se trouve dans la blockchain et agit comme l'interface utilisateur pour TC. Il re\u00e7oit des requ\u00eates du CU (contrat intelligent utilisateur) et renvoie des r\u00e9ponses du serveur TC. Au sein du serveur TC se trouve un relais qui \u00e9tablit la connexion entre l'enclave et Internet (trafic bidirectionnel) et relie l'enclave \u00e0 la blockchain. L'enclave contient progencl, qui est un code ex\u00e9cutant les requ\u00eates de la blockchain et renvoyant des messages dans la blockchain avec une signature num\u00e9rique ; progencl inclut une partie du code du contrat intelligent et ex\u00e9cute en fait certaines de ses fonctions. <\/p>\n

<\/p>\n

L'enclave Intel SGX peut \u00eatre consid\u00e9r\u00e9e comme une biblioth\u00e8que commune avec une API, fonctionnant par le biais d'ecall. Ecall transf\u00e8re le contr\u00f4le \u00e0 l'enclave. L'enclave ex\u00e9cute son code jusqu'\u00e0 son ach\u00e8vement ou jusqu'\u00e0 ce qu'une exception se produise. Pour appeler des fonctions d\u00e9finies en dehors de l'enclave, des ocall sont utilis\u00e9s. Ocall s'ex\u00e9cute en dehors de l'enclave et est trait\u00e9 comme un appel non fiable. Apr\u00e8s l'ex\u00e9cution de l'ocall, le contr\u00f4le est restitu\u00e9 \u00e0 l'enclave.
\n\"Town
\nDans la partie Enclave, un canal s\u00e9curis\u00e9 est configur\u00e9 avec le serveur web, l'enclave effectue elle-m\u00eame la poign\u00e9e de main TLS avec le serveur cible et ex\u00e9cute toutes les op\u00e9rations cryptographiques en interne. La biblioth\u00e8que TLS (mbedTLS) et le code HTTP en version r\u00e9duite sont export\u00e9s vers l'environnement SGX. De plus, l'Enclave contient des certificats racine CA (une collection de certificats) pour v\u00e9rifier les certificats des serveurs distants. Le gestionnaire de requ\u00eates accepte une demande de datagramme au format fourni par Ethereum, la d\u00e9chiffre et l'analyse. Ensuite, il g\u00e9n\u00e8re une transaction Ethereum contenant le datagramme demand\u00e9, la signe avec skTC et la transmet au Relay.<\/p>\n

<\/p>\n

La partie Relay comprend l'interface client, TCP et l'interface blockchain. L'interface client est n\u00e9cessaire pour l'attestation du code de l'enclave et la communication avec le client. Le client envoie une requ\u00eate d'attestation via ecall et re\u00e7oit un horodatage, sign\u00e9 par skTC, avec att (signature d'attestation), ensuite att est confirm\u00e9 via Intel Attestation Service (IAS) et l'horodatage est v\u00e9rifi\u00e9 par un service de temps de confiance. L'interface blockchain v\u00e9rifie les demandes entrantes et place les transactions dans la blockchain pour la livraison des datagrams. Geth est le client officiel Ethereum et permet \u00e0 Relay d'interagir avec la blockchain via des appels RPC. <\/p>\n

<\/p>\n

En travaillant avec TEE, TC permet de lancer plusieurs enclaves en parall\u00e8le, augmentant ainsi la vitesse de traitement des informations par trois. Si avec une seule enclave en fonctionnement, la vitesse \u00e9tait de 15 tx\/sec, alors avec 20 enclaves lanc\u00e9es simultan\u00e9ment, la vitesse augmente jusqu'\u00e0 65 tx\/sec, pour comparaison, la vitesse maximale de fonctionnement dans la blockchain Bitcoin est de 26 tx\/sec.<\/p>\n

<\/p>\n

DECO<\/h1>\n

<\/p>\n

DECO (Oracles D\u00e9centralis\u00e9s pour TLS) a \u00e9t\u00e9 pr\u00e9sent\u00e9 lors de CCS'20, il fonctionne avec des sites prenant en charge la connexion TLS. Il garantit la confidentialit\u00e9 et l'int\u00e9grit\u00e9 des donn\u00e9es.
\nDECO avec TLS utilise le cryptage sym\u00e9trique, permettant ainsi au client et au serveur web de disposer de cl\u00e9s de cryptage, et le client, s'il le souhaite, peut falsifier les donn\u00e9es de la session TLS. Pour r\u00e9soudre ce probl\u00e8me, DECO utilise un protocole de poign\u00e9e de main tripartite entre le prouveur (smart contract), le v\u00e9rificateur (oracle) et le serveur web (source de donn\u00e9es).<\/p>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

Le principe de fonctionnement de DECO est que le v\u00e9rificateur (prouveur) obtienne une partie des donn\u00e9es D et confirme au v\u00e9rificateur que D provient du serveur TLS S. Un autre probl\u00e8me est que TLS ne signe pas les donn\u00e9es et le client TLS a du mal \u00e0 prouver que les donn\u00e9es proviennent bien de ce serveur (difficult\u00e9 de provenance). <\/p>\n

<\/p>\n

Dans le protocole DECO, des cl\u00e9s de chiffrement KEnc et KMac sont utilis\u00e9es. Le client envoie une requ\u00eate Q \u00e0 serveur web<\/a>, la r\u00e9ponse du serveur R arrive sous forme chiffr\u00e9e, mais le client et le serveur poss\u00e8dent les m\u00eames KMac, permettant au client de falsifier un message TLS. La solution de DECO consiste \u00e0 \"cacher\" KMac du client (prover) jusqu'\u00e0 ce qu'il r\u00e9ponde \u00e0 la requ\u00eate. Maintenant, KMac est divis\u00e9 entre le prover et le v\u00e9rificateur \u2014 KpMac et KvMac. Le serveur obtient KMac pour chiffrer la r\u00e9ponse \u00e0 l'aide de l'op\u00e9ration sur les parties de la cl\u00e9 KpMac \u2295 KvMac = KMac.<\/p>\n

<\/p>\n

Avec un \u00e9change \u00e0 trois voies \u00e9tabli, les donn\u00e9es entre le client et le serveur seront \u00e9chang\u00e9es avec une garantie de s\u00e9curit\u00e9.
\n\"Town
\nEn parlant des syst\u00e8mes d'oracles d\u00e9centralis\u00e9s, on ne peut pas manquer de mentionner Chainlink, qui cherche \u00e0 cr\u00e9er un r\u00e9seau d\u00e9centralis\u00e9 de n\u0153uds d'oracle compatible avec Ethereum, Bitcoin et Hyperledger, en tenant compte de la modularit\u00e9 : chaque partie du syst\u00e8me peut \u00eatre mise \u00e0 jour. De plus, pour assurer la s\u00e9curit\u00e9, Chainlink propose \u00e0 chaque oracle participant \u00e0 la mission d'\u00e9mettre une combinaison de cl\u00e9s (publique et priv\u00e9e). La cl\u00e9 priv\u00e9e est utilis\u00e9e pour g\u00e9n\u00e9rer une signature partielle, qui contient leur r\u00e9ponse \u00e0 la demande de donn\u00e9es. Pour obtenir une r\u00e9ponse, il est n\u00e9cessaire de combiner toutes les signatures partielles des oracles du r\u00e9seau.<\/p>\n

<\/p>\n

Chainlink pr\u00e9voit de r\u00e9aliser un PoC DECO initial ax\u00e9 sur des applications financi\u00e8res d\u00e9centralis\u00e9es telles que Mixicles. Au moment de la r\u00e9daction, une nouvelle sur Forbes indiquait que Chainlink avait acquis DECO de l'Universit\u00e9 Cornell.<\/p>\n

<\/p>\n

Attaques sur les oracles<\/h1>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

Du point de vue de la s\u00e9curit\u00e9 de l'information, les attaques suivantes sur Town Crier ont \u00e9t\u00e9 examin\u00e9es :<\/p>\n

<\/p>\n

    \n
  1. \n

    Injection de code malveillant sur des n\u0153uds TEE.
    \nNature de l'attaque : transmission d'un code de contrat intelligent manifestement incorrect dans le TEE, permettant \u00e0 un attaquant ayant acc\u00e8s au n\u0153ud d'ex\u00e9cuter son propre contrat intelligent (frauduleux) sur des donn\u00e9es d\u00e9chiffr\u00e9es. Cependant, les valeurs retourn\u00e9es seront chiffr\u00e9es \u00e0 l'aide de la cl\u00e9 priv\u00e9e, et la seule mani\u00e8re d'acc\u00e9der \u00e0 ces donn\u00e9es r\u00e9side dans la fuite du texte chiffr\u00e9 lors du retour \/ de la sortie.
    \nLa protection contre cette attaque r\u00e9side dans la v\u00e9rification par l'enclave de la validit\u00e9 du code \u00e0 l'adresse actuelle. Cela peut \u00eatre accompli gr\u00e2ce \u00e0 un sch\u00e9ma d'adressage o\u00f9 l'adresse du contrat est d\u00e9termin\u00e9e par le hachage du code du contrat. <\/p>\n

    \n<\/li>\n

  2. \n

    Les changements de ciphertext de l'\u00e9tat du contrat provoquent des fuites.
    \nLa nature de l'attaque : Les propri\u00e9taires des n\u0153uds sur lesquels s'ex\u00e9cutent des smart contracts ont acc\u00e8s \u00e0 l'\u00e9tat du contrat sous une forme chiffr\u00e9e en dehors de l'enclave. Un attaquant qui prend le contr\u00f4le d'un n\u0153ud peut comparer l'\u00e9tat du contrat avant et apr\u00e8s l'ex\u00e9cution d'une transaction et peut d\u00e9terminer quels arguments ont \u00e9t\u00e9 ajout\u00e9s et quelle m\u00e9thode sp\u00e9cifique du smart contract a \u00e9t\u00e9 utilis\u00e9e, car le code m\u00eame du smart contract et ses sp\u00e9cifications techniques sont accessibles au public.
    \nProtection en garantissant la fiabilit\u00e9 du n\u0153ud lui-m\u00eame.<\/p>\n

    \n<\/li>\n

  3. \n

    Attaques par canaux auxiliaires.
    \nUn type particulier d'attaques qui utilise la surveillance des acc\u00e8s \u00e0 la m\u00e9moire et au cache de l'enclave dans divers sc\u00e9narios. Un exemple de cette attaque est le Prime and Probe.
    \n\"Town
    \nProc\u00e9dure de l'attaque :<\/p>\n

    <\/p>\n