Avui, només els mandrosos no han escrit sobre la tecnologia blockchain, les criptomonedes i el genial que és. Però aquest article no elogiarà aquesta tecnologia; parlarem de les seves mancances i de les maneres d'eliminar-les.

Mentre treballava en un dels projectes d'Altirix Systems, va sorgir la tasca de confirmar les dades de manera segura i resistent a la censura d'una font externa a la cadena de blocs. Calia confirmar els canvis en els registres del tercer sistema i, a partir d'aquests canvis, executar una o altra branca en la lògica del contracte intel·ligent. La tasca a primera vista és bastant trivial, però quan la situació financera d'una de les parts que participen en el procés depèn del resultat de la seva implementació, apareixen requisits addicionals. En primer lloc, això és una confiança completa en aquest mecanisme de validació. Però primer és el primer.

El problema és que la cadena de blocs en si és una entitat autònoma i tancada, de manera que els contractes intel·ligents dins de la cadena de blocs no saben res del món exterior. Al mateix temps, els termes dels contractes intel·ligents sovint estan relacionats amb informació sobre coses reals (retard de vol, tipus de canvi, etc.). Perquè els contractes intel·ligents funcionin correctament, la informació rebuda des de fora de la cadena de blocs ha de ser fiable i verificada. Aquest problema es resol utilitzant oracles com ara Town Crier i DECO. Aquests oracles permeten que un contracte intel·ligent a la xarxa blockchain confiï en la informació d'un servidor web de confiança; podem dir que es tracta de proveïdors d'informació fiable.

Oracles

Imagineu que un contracte intel·ligent transfereix 0.001 btc a la vostra cartera de bitcoins si el vostre club de futbol favorit guanya la Copa de Rússia. En cas d'una victòria real, el contracte intel·ligent ha de transferir informació sobre quin club va guanyar, i aquí sorgeixen una sèrie de problemes: on obtenir aquesta informació, com transferir-la de manera segura al contracte intel·ligent i com assegurar-se que la informació rebut en el contracte intel·ligent és vàlid en realitat coincideix amb la realitat?

Quan es tracta de la font d'informació, hi pot haver 2 escenaris: connectar un contracte intel·ligent a un lloc web de confiança on la informació sobre els resultats dels partits s'emmagatzema de manera centralitzada i la segona opció és connectar diversos llocs alhora i seleccionar informació de la majoria de fonts. que proporcionen les mateixes dades. Per verificar la correcció de la informació, s'utilitzen oracles, per exemple Oraclize, que utilitza TLSNotary (TLS Notary Modification to Prove the Authenticity of Data). Però a Google hi ha prou informació sobre Oraclize, i hi ha diversos articles sobre Habré.Avui parlaré d'oracles que utilitzen un enfocament una mica diferent per transmetre informació: Town Crier i DECO. L'article proporciona una descripció dels principis de funcionament d'ambdós oracles, així com una comparació detallada.

Pregoner de la ciutat

Town Crier (TC) va ser introduït per IC3 (The Initiative for CryptoCurrencies and Contracts) el 2016 a CCS'16. La idea principal de TC: transferir informació d'un lloc web a un contracte intel·ligent i assegurar-se que la informació que ofereix TC és la mateixa que la del lloc web. TC utilitza TEE (Trusted Execution Environment) per autenticar la propietat de les dades. La versió original de TC descriu com treballar amb Intel SGX.
Town Crier consta d'una part dins de la cadena de blocs i una part dins del propi sistema operatiu: TC Server.

TC Contract es troba a la cadena de blocs i actua com a front end per a TC. Accepta sol·licituds de la CU (contracte intel·ligent d'usuari) i retorna una resposta del servidor TC. Dins del Servidor TC hi ha un Relé, que estableix una connexió entre l'enclavament i Internet (trànsit bidireccional) i connecta l'enclavament amb la cadena de blocs. Enclave conté progencl, que és el codi que fa sol·licituds des de la cadena de blocs i retorna missatges a la cadena de blocs amb una signatura digital, progencl conté part del codi de contracte intel·ligent i, bàsicament, realitza algunes de les seves funcions.

L'enclavament Intel SGX es pot pensar com una biblioteca compartida amb una API que s'executa mitjançant ecall. Ecall transfereix el control a l'enclavament. L'enclavament executa el seu codi fins que surt o fins que es produeix una excepció. ocall s'utilitza per cridar funcions definides fora de l'enclavament. Ocall s'executa fora de l'enclavament i és tractat com una trucada no fiable. Després d'executar ocall, el control es torna a l'enclavament.

A la part de l'Enclavament, es configura un canal segur amb un servidor web, l'enclavament mateix realitza una encaixada de mans TLS amb el servidor de destinació i realitza totes les operacions criptogràfiques internament. La biblioteca TLS (mbedTLS) i el codi HTTP reduït s'han exportat a l'entorn SGX. A més, Enclave conté certificats CA arrel (una col·lecció de certificats) per verificar els certificats dels servidors remots. Request Handler accepta una sol·licitud de datagrama en el format proporcionat per Ethereum, la desxifra i l'analitza. A continuació, genera una transacció Ethereum que conté el datagrama sol·licitat, el signa amb skTC i el transmet a Relay.

La part de relé inclou la interfície de client, TCP, la interfície de cadena de blocs. La interfície de client és necessària per certificar el codi d'enclavament i comunicar-se amb el client. El client envia una sol·licitud d'acreditació mitjançant ecall i rep una marca de temps signada per skTC juntament amb att (signatura d'acreditació), després att es verifica mitjançant Intel Attestation Service (IAS) i la marca de temps és verificada per un servei de temps de confiança. La interfície de la cadena de blocs verifica les sol·licituds entrants i col·loca transaccions a la cadena de blocs per al lliurament de datagrames. Geth és un client oficial d'Ethereum i permet a Relay interactuar amb la cadena de blocs mitjançant trucades RPC.

Treballant amb TEE, TC us permet executar diversos enclavaments en paral·lel, augmentant així la velocitat de processament de la informació en 3 vegades. Si amb un enclavament en funcionament la velocitat era de 15 tx/s, llavors amb 20 enclavaments en paral·lel la velocitat augmenta a 65 tx/s; per comparació, la velocitat màxima de funcionament a la cadena de blocs de Bitcoin és de 26 tx/s.

DECO

DECO (Oracles descentralitzats per a TLS) es va presentar a CCS'20, treballa amb llocs que admeten connexions TLS. Assegura la confidencialitat i integritat de les dades.
DECO amb TLS utilitza xifratge simètric, de manera que el client i el servidor web tenen claus de xifratge i el client pot forjar dades de sessió TLS si ho desitja. Per resoldre aquest problema, DECO utilitza un protocol d'enllaç de tres vies entre el provador (contracte intel·ligent), el verificador (oracle) i el servidor web (font de dades).

La manera com funciona DECO és que el verificador rep una dada D i confirma al verificador que D prové del servidor TLS S. Un altre problema és que TLS no signa les dades i és difícil que el client TLS demostri que el Les dades es van rebre exactament del servidor adequat (dificultat de procedència).

El protocol DECO utilitza claus de xifratge KEnc i KMac. El client envia una sol·licitud Q al servidor web, la resposta del servidor R arriba en forma xifrada, però el client i el servidor posseeixen el mateix KMac i el client pot falsificar el missatge TLS. La solució de DECO és "amagar" el KMac al client (provedor) fins que respongui a la sol·licitud. Ara KMac es divideix entre provador i verificador: KpMac i KvMac. El servidor rep KMac per xifrar la resposta mitjançant l'operació de part clau KpMac ⊕ KvMac = KMac.

Mitjançant la configuració d'una encaixada a tres direccions, l'intercanvi de dades entre el client i el servidor es durà a terme amb una garantia de seguretat.

Quan es parla d'un sistema oracle descentralitzat, no es pot deixar d'esmentar Chainlink, que pretén crear una xarxa descentralitzada de nodes oracle compatible amb Ethereum, Bitcoin i Hyperledger, tenint en compte la modularitat: cada part del sistema es pot actualitzar. Al mateix temps, per garantir la seguretat, Chainlink ofereix a cada oracle que participi en la tasca emetre una combinació de claus (públiques i privades). La clau privada s'utilitza per generar una signatura parcial que conté la seva decisió a la sol·licitud de dades. Per obtenir una resposta, cal combinar totes les signatures parcials dels oracles de la xarxa.

Chainlink té previst dur a terme un PoC DECO inicial centrat en aplicacions financeres descentralitzades com Mixicles. En el moment d'escriure, a Forbes van sortir notícies que Chainlink va adquirir DECO de la Universitat de Cornell.

Atacs als oracles

Des del punt de vista de la seguretat de la informació, es van considerar els següents atacs a Town Crier:

1. Injecció de codi de contacte intel·ligent rogue als nodes TEE.
   L'essència de l'atac: transmetre un codi de contracte intel·ligent deliberadament incorrecte a TEE, per tant, un atacant que hagi obtingut accés al node podrà executar el seu propi contracte intel·ligent (fraudulent) amb les dades desxifrades. Tanmateix, els valors de retorn es xifraran amb una clau privada, i l'única manera d'accedir a aquestes dades és filtrar el text xifrat a la devolució/sortida.
   La protecció contra aquest atac consisteix en la comprovació de l'enclavament de la correcció del codi situat a l'adreça actual. Això es pot aconseguir mitjançant un esquema d'adreçament en què l'adreça del contracte es determina mitjançant l'hash del codi del contracte.

2. Fuga de canvis en el text xifrat de l'estat del contracte.
   L'essència de l'atac: els propietaris dels nodes en què s'executen contractes intel·ligents tenen accés a l'estat del contracte en forma xifrada fora de l'enclavament. Un atacant, després d'haver aconseguit el control d'un node, pot comparar l'estat del contacte abans i després de la transacció i pot determinar quins arguments s'han introduït i quin mètode de contracte intel·ligent s'ha utilitzat, ja que el codi de contracte intel·ligent i les seves especificacions tècniques estan disponibles públicament.
   Protecció per garantir la fiabilitat del propi node.

3. Atacs de canal lateral.
   Un tipus especial d'atac que utilitza la supervisió de la memòria de l'enclavament i l'accés a la memòria cau en diversos escenaris. Un exemple d'aquest atac és Prime i Probe.
   
   Ordre d'atac:

   • t0: L'atacant omple tota la memòria cau de dades del procés de la víctima.
   • t1: La víctima executa codi amb accessos de memòria que depenen de les dades sensibles de la víctima (claus criptogràfiques). La línia de memòria cau es selecciona en funció del valor de bit de clau. A l'exemple de la figura, keybit = 0 i es llegeix l'adreça X a la línia de memòria cau 2. Les dades emmagatzemades a X es carreguen a la memòria cau, desplaçant les dades que hi havia abans.
   • t2: L'atacant comprova quines de les seves línies de memòria cau han estat desallotjades: línies utilitzades per la víctima. Això es fa mesurant el temps d'accés. En repetir aquesta operació per a cada bit de clau, l'atacant obté la clau sencera.

Protecció d'atacs: Intel SGX té protecció contra atacs de canal lateral que impedeix la supervisió d'esdeveniments relacionats amb la memòria cau, però un atac Prime i Probe encara funcionarà perquè l'atacant supervisa els esdeveniments de la memòria cau del seu procés i comparteix la memòria cau amb la víctima.

Per tant, de moment no hi ha cap protecció fiable contra aquest atac.

També es coneixen atacs com Spectre i Foreshadow (L1TF), similars a Prime i Probe. Us permeten llegir dades de la memòria cau a través d'un canal de tercers. Es proporciona protecció contra la vulnerabilitat Spectre-v2, que funciona contra dos d'aquests atacs.

En relació a DECO, l'encaixada a tres direccions ofereix una garantia de seguretat:

1. Integritat del provador: un provador piratejat no pot falsificar la informació d'origen del servidor i no pot fer que el servidor accepti sol·licituds no vàlides o respongui incorrectament a sol·licituds vàlides. Això es fa mitjançant patrons de sol·licitud entre el servidor i el provador.
2. Integritat del verificador: un verificador piratejat no pot fer que el provador rebi respostes incorrectes.
3. Privadesa: el verificador piratejat només examina la informació pública (sol·licitud, nom del servidor).

A DECO, només són possibles les vulnerabilitats d'injecció de trànsit. En primer lloc, amb una encaixada de mans a tres direccions, el verificador pot establir la identitat del servidor mitjançant un nou nonce. Tanmateix, després de l'encaixada de mans, el verificador ha de confiar en indicadors de la capa de xarxa (adreces IP). Així, la comunicació entre el verificador i el servidor s'ha de protegir de la injecció de trànsit. Això s'aconsegueix utilitzant Proxy.

Comparació d'oracles

Town Crier es basa en treballar amb un enclavament a la part del servidor, mentre que DECO permet verificar l'autenticitat de l'origen de les dades mitjançant una encaixada de mans a tres direccions i xifratge de dades amb claus criptogràfiques. La comparació d'aquests oracles es va dur a terme segons els criteris següents: rendiment, seguretat, cost i practicitat.

Pregoner de la ciutat
DECO

rendiment
Més ràpid (0.6 s per acabar)
Més lent (10.50 segons per acabar el protocol)

seguretat
Menys segur
Més segur

cost
Més car
Més barat

practicitat
Requereix maquinari especial
Funciona amb qualsevol servidor que admeti TLS

Velocitat: Per treballar amb DECO, cal una encaixada de mans de tres direccions, quan es configura mitjançant LAN es triguen 0.37 segons, per a la interacció després d'establir la connexió, 2PC-HMAC és efectiu (0,13 s per escriptura). El rendiment de DECO depèn de les suites de xifratge TLS disponibles, de la mida de les dades privades i de la complexitat de l'evidència d'una aplicació concreta. Utilitzant l'aplicació d'opció binària d'IC3 com a exemple: completar el protocol mitjançant LAN triga uns 10,50 segons. En comparació, Town Crier triga aproximadament 0,6 segons a completar una aplicació similar, que és aproximadament 20 vegades més ràpida que DECO. En igualtat de coses, TC serà més ràpid.

Безопасность: Els atacs a l'enclavament Intel SGX (atacs de canal lateral) funcionen i poden causar danys reals als participants del contracte intel·ligent. Pel que fa a DECO, els atacs relacionats amb la injecció de trànsit són possibles, però l'ús d'un proxy redueix aquests atacs a res. Per tant, DECO és més segur.

Cost: El cost de l'equip que admet Intel SGX és superior al cost de la configuració del protocol a DECO. Per això el TC és més car.

Pràcticitat: Per treballar amb Town Crier, cal un equip especial que admeti TEE. Per exemple, Intel SGX és compatible amb la família de processadors Intel Core de 6a generació i posteriors. DECO us permet treballar amb qualsevol equip, tot i que hi ha una configuració DECO amb TEE. D'acord amb el procés de configuració, l'encaix de mans de tres vies de DECO pot trigar una mica, però això no és res en comparació amb la limitació de maquinari de TC, de manera que DECO és més pràctic.

Conclusió

Mirant els dos oracles per separat i comparant-los amb quatre criteris, és evident que Town Crier és inferior a DECO en tres de quatre punts. DECO és més fiable des del punt de vista de la seguretat de la informació, més barat i més pràctic, encara que la configuració d'un protocol tripartit pot trigar una mica i té els seus inconvenients, per exemple, operacions addicionals amb claus d'encriptació. TC és més ràpid que DECO, però les vulnerabilitats d'atac del canal lateral el fan susceptible a la pèrdua de confidencialitat. Cal tenir en compte que DECO es va introduir el gener de 2020 i no ha passat prou temps per considerar-lo segur. Town Crier ha estat atacat durant 4 anys i ha passat per moltes proves, per la qual cosa el seu ús en molts projectes està justificat.

Font: www.habr.com