Ata a data, só os preguiceiros non escribiron sobre a tecnoloxía blockchain, as criptomoedas e o xenial que é. Pero neste artigo non haberá eloxios desta tecnoloxía, tratarase só das súas deficiencias e formas de eliminalas.

Mentres traballaba nun dos proxectos de Altirix Systems, xurdiu a tarefa de confirmar de forma segura e resistente á censura os datos dunha fonte externa á cadea de bloques. Era necesario confirmar os cambios nos rexistros do terceiro sistema e, en función destes cambios, executar unha ou outra rama na lóxica do contrato intelixente. A primeira vista, a tarefa é bastante trivial, pero cando a condición financeira dunha das partes que participan no proceso depende do resultado da súa implementación, aparecen requisitos adicionais. En primeiro lugar, é unha confianza integral nun mecanismo de validación deste tipo. Pero primeiro o primeiro.

O problema é que a propia cadea de bloques é unha entidade autónoma e pechada, polo que os contratos intelixentes dentro da cadea de bloques non saben nada do mundo exterior. Ao mesmo tempo, as condicións dos contratos intelixentes adoitan asociarse con información sobre cousas reais (atraso do voo, tipos de cambio, etc.). Para que os contratos intelixentes funcionen correctamente, a información obtida fóra da cadea de bloques debe ser fiable e verificada. Este problema resólvese usando oráculos como Town Crier e DECO. Estes oráculos permiten que un contrato intelixente na rede blockchain confíe na información dun servidor web de confianza, podemos dicir que son provedores de información fiables.

Oráculos

Imaxina que un contrato intelixente transfire 0.001 btc á túa carteira bitcoin se o teu club de fútbol favorito gaña a Copa de Rusia. No caso dunha vitoria real, o contrato intelixente necesita transferir información sobre que club gañou, e aquí xorden unha serie de problemas: onde obter esta información, como transferila de forma segura ao contrato intelixente e como asegurarse de que o a información recibida no contrato intelixente en realmente coincide coa realidade?

No problema coa fonte de información, pode haber 2 escenarios: conectar un contrato intelixente a un sitio web de confianza que almacena de forma centralizada información sobre os resultados dos partidos, e a segunda opción é conectar varios sitios á vez e despois escoller información da maioría. fontes que proporcionan os mesmos datos. Para asegurarse de que a información é correcta, utilízanse oráculos, como Oraclize, que usa TLSNotary (Modificación TLS para probar a autenticidade dos datos). Pero hai suficiente información sobre Oraclize en Google, e hai varios artigos sobre Habré, pero hoxe falarei de oráculos que usan un enfoque lixeiramente diferente para transmitir información: Town Crier e DECO. O artigo ofrece unha descrición dos principios de funcionamento de ambos oráculos, así como unha comparación detallada.

Pregoeiro

Town Crier (TC) foi presentado por IC3 (The Initiative for CryptoCurrencies and Contracts) en 2016 en CCS'16. A idea principal detrás do TC é pasar a información do sitio web ao contrato intelixente e asegurarse de que a información entregada polo TC sexa a mesma que no sitio web. TC usa TEE (Trusted Execution Environment) para autenticar a propiedade dos datos. A versión orixinal de TC describe como traballar con Intel SGX.
Town Crier consiste nunha parte dentro da cadea de bloques e unha parte dentro do propio sistema operativo: TC Server.

O contrato TC está na cadea de bloques e actúa como un front end para TC. Acepta solicitudes do CU (User Smart Contract) e devolve unha resposta do TC Server. Dentro do servidor TC hai un relé que conecta o enclave a Internet (tráfico bidireccional) e conecta o enclave á cadea de bloques. Enclave contén progencl, que é o código que fai solicitudes desde a cadea de bloques e devolve mensaxes á cadea de bloques asinada dixitalmente, progencl contén parte do código de contrato intelixente e, de feito, realiza algunhas das súas funcións.

O enclave Intel SGX pódese pensar como unha biblioteca compartida cunha API que se executa a través de ecall. Ecall transfire o control ao enclave. O enclave executa o seu código ata que remata ou ata que se produce unha excepción. Para chamar a funcións definidas fóra do enclave, use ocall. Ocall funciona fóra do enclave e é tratado como unha chamada non fiable polo enclave. Despois de executar ocall, o control volve ao enclave.

Na parte Enclave, configúrase unha canle segura co servidor web, o propio enclave realiza un enlace TLS co servidor de destino e realiza todas as operacións criptográficas dentro de si. A biblioteca TLS (mbedTLS) e unha versión reducida do código HTTP foron exportadas ao contorno SGX. Ademais, o Enclave contén certificados CA raíz (colección de certificados) para comprobar os certificados dos servidores remotos. O xestor de solicitudes acepta unha solicitude de datagrama no formato proporcionado por Ethereum, descifra e analízaa. A continuación, xera unha transacción de Ethereum que contén o datagrama solicitado, asínao con skTC e envíao a Relay.

A parte Relay inclúe Interface de cliente, TCP, Interface Blockchain. A interface de cliente é necesaria para validar o código do enclave e comunicarse co cliente. O cliente envía unha solicitude de certificación mediante ecall e recibe unha marca de tempo asinada por skTC xunto con att (a sinatura da certificación), despois att validase mediante o Intel Attestation Service (IAS) e un servizo de tempo de confianza verifica a marca de tempo. A Interface Blockchain valida as solicitudes entrantes e coloca transaccións na cadea de bloques para entregar datagramas. Geth é o cliente oficial de Ethereum e permite que Relay interactúe coa cadea de bloques mediante chamadas RPC.

Traballando con TEE, TC permítelle executar varios enclaves en paralelo, aumentando así a velocidade de procesamento da información 3 veces. Se cun enclave de traballo a velocidade era de 15 tx/s, entón con 20 enclaves paralelos a velocidade aumenta a 65 tx/s, a modo de comparación, a velocidade máxima na cadea de bloques de Bitcoin é de 26 tx/s.

Deco

DECO (Oráculos descentralizados para TLS) presentouse en CCS'20 e funciona con sitios que admiten conexión TLS. Asegura a confidencialidade e integridade dos datos.
Os DECO con TLS usan cifrado simétrico, polo que o cliente e o servidor web teñen claves de cifrado e o cliente pode falsificar os datos da sesión TLS se o desexa. Para resolver este problema, DECO utiliza un protocolo de enlace de tres vías entre o probador (contrato intelixente), o verificador (oráculo) e o servidor web (fonte de datos).

A forma en que funciona DECO é que o probador recibe un dato D e confirma ao verificador que D procede do servidor TLS S. Outro problema é que TLS non asina os datos e é difícil para o cliente TLS demostrar que o recibíronse datos dese servidor (dificultade de procedencia).

O protocolo DECO usa as claves de cifrado KEnc e KMac. O cliente envía unha solicitude Q ao servidor web, a resposta do servidor R está cifrada, pero o cliente e o servidor posúen o mesmo KMac e o cliente pode falsificar a mensaxe TLS. A solución de DECO é "ocultar" o KMac ao cliente (probador) ata que este responda á solicitude. Agora KMac divídese entre probador e verificador: KpMac e KvMac. O servidor recibe un KMac para cifrar a resposta usando a operación KpMac ⊕ KvMac = KMac nas partes da chave.

Ao configurar un apretón de mans a tres vías, o intercambio de datos entre o cliente e o servidor realizarase cunha garantía de seguridade.

Falando do sistema oráculo descentralizado, non se pode deixar de mencionar a Chainlink, que pretende crear unha rede descentralizada de nodos oráculo compatible con Ethereum, Bitcoin e Hyperledger, tendo en conta a modularidade: cada parte do sistema pódese actualizar. Ao mesmo tempo, para garantir a seguridade, Chainlink ofrece a cada oráculo que participe na tarefa emitir unha combinación de claves (públicas e privadas). A clave privada utilízase para xerar unha sinatura parcial que contén a súa decisión de solicitar datos. Para obter a resposta, é necesario combinar todas as sinaturas parciais dos oráculos da rede.

Chainlink está a planear un PoC DECO inicial centrado en aplicacións financeiras descentralizadas como Mixicles. No momento de escribir este artigo, había noticias en Forbes de que Chainlink adquirira DECO da Universidade de Cornell.

ataques aos oráculos

Desde o punto de vista da seguridade da información, consideráronse os seguintes ataques a Town Crier:

1. Inxección de código de contacto intelixente malicioso nos nodos TEE.
   A esencia do ataque: enviar un código de contrato intelixente conscientemente incorrecto a TEE, para que un atacante que teña acceso ao nodo poida executar o seu propio contrato intelixente (fraudulento) sobre os datos descifrados. Non obstante, os valores devoltos cifraranse coa clave privada e a única forma de acceder a tales datos é filtrar o texto cifrado na devolución/saída.
   A protección contra este ataque consiste en comprobar a corrección do código situado no enderezo actual polo enclave. Isto pódese conseguir cun esquema de direccionamento onde o enderezo do contrato se determina mediante o hash do código do contrato.

2. Fuga de cambios no texto cifrado do estado do contrato.
   A esencia do ataque: os propietarios dos nodos nos que se executan os contratos intelixentes teñen acceso ao estado do contrato en forma cifrada fóra do enclave. Un atacante, que obtivo o control do nodo, pode comparar o estado do contacto antes e despois da transacción e pode determinar que argumentos se introduciron e que método de contrato intelixente se utilizou, xa que o código do contrato intelixente e as súas especificacións técnicas están dispoñibles públicamente.
   Protección para garantir a fiabilidade do propio nodo.

3. Ataques de canle lateral.
   Un tipo especial de ataque que utiliza a monitorización da memoria do enclave e o acceso á caché en varios escenarios. Un exemplo deste tipo de ataque é Prime e Probe.
   
   Orde de ataque:

   • t0: O atacante enche toda a caché de datos do proceso da vítima.
   • t1: A vítima executa código con accesos á memoria que dependen dos datos sensibles da vítima (chaves criptográficas). A liña de caché se selecciona polo valor do bit de clave. No exemplo da figura, keybit = 0 e le o enderezo X na liña 2 da caché. Os datos almacenados en X cárganse na caché, desprazando os datos que estaban alí antes.
   • t2: O atacante verifica cales das súas liñas de caché foron desaloxadas - liñas utilizadas pola vítima. Isto faise medindo o tempo de acceso. Ao repetir esta operación para cada un dos keybits, o atacante obtén a clave completa.

Protección contra ataques: Intel SGX ten protección contra ataques de canle lateral que desactiva o seguimento dos eventos relacionados coa caché, pero un ataque Prime e Probe aínda pasará, xa que o atacante observa os eventos da caché do seu proceso e comparte a caché coa vítima.

Así, polo momento non existe unha protección fiable contra este ataque.

Tamén se coñecen ataques Spectre e Foreshadow (L1TF) similares a Prime e Probe. Permítenche ler datos da caché a través dunha canle de terceiros. Ofrécese protección contra a vulnerabilidade Spectre-v2, que funciona contra estes dous ataques.

En relación a DECO, o apretón de mans de tres vías ofrece unha garantía de seguridade:

1. Integridade do probador: un probador comprometido non pode falsificar información de orixe do servidor e non pode facer que o servidor acepte solicitudes non válidas ou responda incorrectamente a solicitudes válidas. Isto faise a través de patróns de solicitude entre o servidor e o probador.
2. Integridade do verificador: un verificador pirateado non pode facer que o probador obteña respostas incorrectas.
3. Privacidade: o verificador pirateado só examina a información dispoñible publicamente (consulta, nome do servidor).

En DECO, só son posibles as vulnerabilidades de inxección de tráfico. En primeiro lugar, cun apretón de mans de tres vías, o verificador pode establecer a identidade do servidor cun novo nonce. Non obstante, despois do apretón de mans, o verificador debe confiar nos indicadores da capa de rede (enderezos IP). Así, a comunicación entre o verificador e o servidor debe estar protexida da inxección de tráfico. Isto conséguese usando un proxy.

Comparación de oráculos

Town Crier baséase en traballar cun enclave no back-end, mentres que DECO permítelle autenticar a orixe dos datos mediante un apretón de mans de tres vías e cifrar os datos con claves criptográficas. A comparación destes oráculos realizouse segundo os seguintes criterios: rapidez, seguridade, custo e practicidade.

Pregoeiro
Deco

rendemento
Máis rápido (0.6 s para rematar)
Máis lento (10.50 segundos para rematar o protocolo)

seguridade
Menos seguro
Máis seguro

custa
Máis caro
Máis barato

practicidade
Require hardware especial
Funciona con calquera servidor que admita TLS

DesempeñoR: DECO require unha configuración de enlace de 0.37 vías, leva 2 segundos cando se configura mediante LAN, 0,13PC-HMAC (3 s por escritura) é eficaz para a comunicación despois de establecer a conexión. O rendemento de DECO depende das suites de cifrado TLS dispoñibles, do tamaño dos datos privados e da complexidade das probas para unha aplicación concreta. Usando a aplicación de opción binaria de IC10,50 como exemplo: leva uns 0,6 segundos completar o protocolo a través da LAN. En comparación, Town Crier tarda aproximadamente 20 segundos en completar unha aplicación similar, o que é unhas XNUMX veces máis rápido que DECO. En igualdade de condicións, o TC será máis rápido.

Безопасность: Os ataques ao enclave Intel SGX (ataques de canle lateral) funcionan e poden causar danos reais aos participantes do contrato intelixente. No que respecta a DECO, os ataques por inxección de tráfico son posibles, pero o uso dun proxy anula este tipo de ataques. Polo tanto, DECO é máis seguro.

Custa: O custo do hardware que admite traballar con Intel SGX é superior ao custo da configuración do protocolo en DECO. Polo tanto, o TC é máis caro.

Práctica: Para traballar con Town Crier, é necesario un equipo especial que admita TEE. Por exemplo, Intel SGX é compatible con procesadores da familia Intel Core de 6ª xeración e posteriores. DECO permíteche traballar con calquera equipo, aínda que hai unha configuración DECO usando TEE. Segundo o proceso de configuración, o apretón de mans de XNUMX vías de DECO pode levar algún tempo, pero isto non é nada en comparación coa limitación de hardware para TC, polo que DECO é máis práctico.

Conclusión

Mirando os dous oráculos por separado e comparándoos en catro criterios, está claro que Town Crier é inferior a DECO en tres puntos de catro. DECO é máis fiable en canto á seguridade da información, máis barato e máis práctico, aínda que a configuración dun protocolo de tres vías pode levar algún tempo e ten os seus inconvenientes, como operacións adicionais con claves de cifrado. TC é máis rápido que DECO, pero unha vulnerabilidade de ataque de canle lateral fai que corra o risco de perder privacidade. Teña en conta que DECO presentouse en xaneiro de 2020 e non pasou o tempo suficiente para consideralo seguro. Town Crier leva 4 anos atacado e pasou por moitas probas, polo que está xustificado o seu uso en moitos proxectos.

Fonte: www.habr.com