Hoy en día, sólo los perezosos no han escrito sobre la tecnología blockchain, las criptomonedas y lo genial que es. Pero este artículo no elogiará esta tecnología, hablaremos de sus deficiencias y de cómo eliminarlas.

Mientras trabajaba en uno de los proyectos de Altirix Systems, surgió la tarea de confirmar de forma segura y resistente a la censura los datos de una fuente externa a la cadena de bloques. Era necesario confirmar los cambios en los registros del tercer sistema y, en base a estos cambios, ejecutar una u otra rama en la lógica del contrato inteligente. La tarea a primera vista es bastante trivial, pero cuando la situación financiera de una de las partes que participan en el proceso depende del resultado de su implementación, aparecen requisitos adicionales. En primer lugar, se trata de una confianza total en dicho mecanismo de validación. Pero primero lo primero.

El problema es que la cadena de bloques en sí es una entidad cerrada y autónoma, por lo que los contratos inteligentes dentro de la cadena de bloques no saben nada sobre el mundo exterior. Al mismo tiempo, los términos de los contratos inteligentes suelen estar relacionados con información sobre cosas reales (retrasos de vuelos, tipos de cambio, etc.). Para que los contratos inteligentes funcionen correctamente, la información recibida desde fuera de la cadena de bloques debe ser confiable y verificada. Este problema se resuelve mediante el uso de oráculos como Town Crier y DECO. Estos oráculos permiten que un contrato inteligente en la red blockchain confíe en información de un servidor web confiable; podemos decir que estos son proveedores de información confiable.

Oráculos

Imagine que un contrato inteligente transfiere 0.001 btc a su billetera bitcoin si su club de fútbol favorito gana la Copa de Rusia. En caso de una victoria real, el contrato inteligente necesita transferir información sobre qué club ganó, y aquí surgen una serie de problemas: dónde obtener esta información, cómo transferirla de forma segura al contrato inteligente y cómo asegurarse de que la información ¿La validez recibida en el contrato inteligente realmente coincide con la realidad?

En cuanto a la fuente de información, puede haber 2 escenarios: conectar un contrato inteligente a un sitio web confiable donde la información sobre los resultados de los partidos se almacena centralmente, y la segunda opción es conectar varios sitios a la vez y luego seleccionar información de la mayoría de las fuentes. que proporcionan los mismos datos. Para verificar la exactitud de la información se utilizan oráculos, por ejemplo Oraclize, que utiliza TLSNotary (TLS Notary Modification to Prove the Authenticity of Data). Pero hay suficiente información en Google sobre Oraclize y hay varios artículos sobre Habré. Hoy hablaré de oráculos que utilizan un enfoque ligeramente diferente para transmitir información: Town Crier y DECO. El artículo proporciona una descripción de los principios operativos de ambos oráculos, así como una comparación detallada.

Pregonero

Town Crier (TC) fue presentado por IC3 (La Iniciativa para Criptomonedas y Contratos) en 2016 en CCS'16. La idea principal de TC: transferir información de un sitio web a un contrato inteligente y asegurarse de que la información entregada por TC sea la misma que en el sitio web. TC utiliza TEE (entorno de ejecución confiable) para autenticar la propiedad de los datos. La versión original de TC describe cómo trabajar con Intel SGX.
Town Crier consta de una parte dentro de la cadena de bloques y una parte dentro del propio sistema operativo: TC Server.

TC Contract está en la cadena de bloques y actúa como interfaz para TC. Acepta solicitudes de CU (contrato inteligente de usuario) y devuelve una respuesta del servidor TC. Dentro del TC Server hay un Relay, que establece una conexión entre el enclave e Internet (tráfico bidireccional) y conecta el enclave con la blockchain. Enclave contiene progencl, que es un código que realiza solicitudes desde blockchain y devuelve mensajes a blockchain con una firma digital, progencl contiene parte del código de contrato inteligente y esencialmente realiza algunas de sus funciones.

El enclave Intel SGX puede considerarse como una biblioteca compartida con una API que se ejecuta mediante ecall. Ecall transfiere el control al enclave. El enclave ejecuta su código hasta que sale o hasta que ocurre una excepción. ocall se utiliza para llamar a funciones definidas fuera del enclave. Ocall se ejecuta fuera del enclave y este lo trata como una llamada que no es de confianza. Después de ejecutar ocall, el control regresa al enclave.

En la parte del Enclave, se configura un canal seguro con un servidor web, el propio enclave realiza un protocolo de enlace TLS con el servidor de destino y realiza todas las operaciones criptográficas internamente. La biblioteca TLS (mbedTLS) y el código HTTP reducido se han exportado al entorno SGX. Además, Enclave contiene certificados de CA raíz (una colección de certificados) para verificar los certificados de servidores remotos. Request Handler acepta una solicitud de datagrama en el formato proporcionado por Ethereum, la descifra y la analiza. Luego genera una transacción Ethereum que contiene el datagrama solicitado, lo firma con skTC y lo transmite a Relay.

La parte de retransmisión incluye interfaz de cliente, TCP, interfaz Blockchain. La interfaz del cliente es necesaria para certificar el código de enclave y comunicarse con el cliente. El cliente envía una solicitud de atestación usando ecall y recibe una marca de tiempo firmada por skTC junto con att (firma de atestación), luego att se verifica usando Intel Attestation Service (IAS) y la marca de tiempo se verifica mediante un servicio de tiempo confiable. La interfaz Blockchain verifica las solicitudes entrantes y coloca transacciones en la cadena de bloques para la entrega de datagramas. Geth es un cliente oficial de Ethereum y permite que Relay interactúe con la cadena de bloques mediante llamadas RPC.

Al trabajar con TEE, TC le permite ejecutar varios enclaves en paralelo, aumentando así la velocidad de procesamiento de la información 3 veces. Si con un enclave en ejecución la velocidad era de 15 tx/seg, entonces con 20 enclaves en ejecución en paralelo la velocidad aumenta a 65 tx/seg; a modo de comparación, la velocidad operativa máxima en la cadena de bloques de Bitcoin es de 26 tx/seg.

DECO

DECO (Oráculos descentralizados para TLS) se presentó en CCS'20 y trabaja con sitios que admiten conexiones TLS. Garantiza la confidencialidad e integridad de los datos.
DECO con TLS utiliza cifrado simétrico, por lo que el cliente y el servidor web tienen claves de cifrado y el cliente puede falsificar datos de sesión TLS si así lo desea. Para resolver este problema, DECO utiliza un protocolo de enlace de tres vías entre el probador (contrato inteligente), el verificador (oracle) y el servidor web (fuente de datos).

La forma en que funciona DECO es que el verificador recibe un dato D y le confirma que D proviene del servidor TLS S. Otro problema es que TLS no firma los datos y es difícil para el cliente TLS demostrar que el los datos se recibieron exactamente del servidor correcto (dificultad de procedencia).

El protocolo DECO utiliza claves de cifrado KEnc y KMac. El cliente envía una solicitud Q al servidor web, la respuesta del servidor R viene en forma cifrada, pero el cliente y el servidor poseen el mismo KMac y el cliente puede falsificar el mensaje TLS. La solución de DECO es "ocultar" el KMac al cliente (prover) hasta que responda a la solicitud. Ahora KMac se divide entre probador y verificador: KpMac y KvMac. El servidor recibe KMac para cifrar la respuesta utilizando la operación de parte clave KpMac ⊕ KvMac = KMac.

Al configurar un protocolo de enlace de tres vías, el intercambio de datos entre el cliente y el servidor se realizará con garantía de seguridad.

Cuando se habla de un sistema Oracle descentralizado, no se puede dejar de mencionar Chainlink, cuyo objetivo es crear una red descentralizada de nodos Oracle compatibles con Ethereum, Bitcoin e Hyperledger, teniendo en cuenta la modularidad: cada parte del sistema se puede actualizar. Al mismo tiempo, para garantizar la seguridad, Chainlink ofrece a cada oráculo que participa en la tarea emitir una combinación de claves (pública y privada). La clave privada se utiliza para generar una firma parcial que contiene su decisión sobre la solicitud de datos. Para obtener una respuesta, es necesario combinar todas las firmas parciales de los oráculos de la red.

Chainlink planea llevar a cabo un PoC DECO inicial con un enfoque en aplicaciones financieras descentralizadas como Mixicles. Al momento de escribir este artículo, apareció en Forbes la noticia de que Chainlink adquirió DECO de la Universidad de Cornell.

Ataques a oráculos

Desde el punto de vista de la seguridad de la información, se consideraron los siguientes ataques a Town Crier:

1. Inyección de código de contacto inteligente no autorizado en nodos TEE.
   La esencia del ataque: transmitir un código de contrato inteligente deliberadamente incorrecto a TEE, de modo que un atacante que haya obtenido acceso al nodo podrá ejecutar su propio contrato inteligente (fraudulento) con los datos descifrados. Sin embargo, los valores devueltos se cifrarán con una clave privada y la única forma de acceder a dichos datos es filtrar el texto cifrado en la devolución/salida.
   La protección contra este ataque consiste en que el enclave comprueba la exactitud del código ubicado en la dirección actual. Esto se puede lograr utilizando un esquema de direccionamiento en el que la dirección del contrato se determina mediante hash del código del contrato.

2. Se filtran cambios en el texto cifrado del estado del contrato.
   La esencia del ataque: los propietarios de los nodos en los que se ejecutan contratos inteligentes tienen acceso al estado del contrato de forma cifrada fuera del enclave. Un atacante, una vez obtenido el control de un nodo, puede comparar el estado del contacto antes y después de la transacción y determinar qué argumentos se ingresaron y qué método de contrato inteligente se utilizó, ya que el código del contrato inteligente en sí y sus especificaciones técnicas están disponibles públicamente.
   Protección para garantizar la confiabilidad del propio nodo.

3. Ataques de canal lateral.
   Un tipo especial de ataque que utiliza la supervisión de la memoria del enclave y el acceso a la caché en varios escenarios. Un ejemplo de tal ataque es Prime and Probe.
   
   Orden de ataque:

   • t0: el atacante llena todo el caché de datos del proceso de la víctima.
   • t1: La víctima ejecuta código con accesos a memoria que dependen de datos sensibles de la víctima (claves criptográficas). La línea de caché se selecciona según el valor del bit clave. En el ejemplo de la figura, keybit = 0 y se lee la dirección X en la línea de caché 2. Los datos almacenados en X se cargan en el caché, desplazando los datos que estaban allí antes.
   • t2: El atacante comprueba cuáles de sus líneas de caché han sido desalojadas: líneas utilizadas por la víctima. Esto se hace midiendo el tiempo de acceso. Al repetir esta operación para cada bit de clave, el atacante obtiene la clave completa.

Protección contra ataques: Intel SGX tiene protección contra ataques de canal lateral que impide el monitoreo de eventos relacionados con el caché, pero un ataque Prime y Probe seguirá funcionando porque el atacante monitorea los eventos de caché de su proceso y comparte el caché con la víctima.

Por tanto, por el momento no existe una protección fiable contra este ataque.

También se conocen ataques como Spectre y Foreshadow (L1TF), similares a Prime y Probe. Le permiten leer datos de la memoria caché a través de un canal de terceros. Se proporciona protección contra la vulnerabilidad Spectre-v2, que funciona contra dos de estos ataques.

En relación con DECO, el protocolo de enlace de tres vías proporciona una garantía de seguridad:

1. Integridad del probador: un probador pirateado no puede falsificar la información de origen del servidor y no puede hacer que el servidor acepte solicitudes no válidas o responda incorrectamente a solicitudes válidas. Esto se hace mediante patrones de solicitud entre el servidor y el probador.
2. Integridad del verificador: un verificador pirateado no puede hacer que el probador reciba respuestas incorrectas.
3. Privacidad: el verificador pirateado examina sólo información pública (solicitud, nombre del servidor).

En DECO, sólo son posibles las vulnerabilidades de inyección de tráfico. Primero, con un protocolo de enlace de tres vías, el verificador puede establecer la identidad del servidor utilizando un nonce nuevo. Sin embargo, después del protocolo de enlace, el verificador debe confiar en los indicadores de la capa de red (direcciones IP). Por tanto, la comunicación entre el verificador y el servidor debe protegerse de la inyección de tráfico. Esto se logra mediante el uso de Proxy.

Comparación de oráculos

Town Crier se basa en trabajar con un enclave en la parte del servidor, mientras que DECO le permite verificar la autenticidad del origen de los datos mediante un protocolo de enlace de tres vías y cifrado de datos con claves criptográficas. La comparación de estos oráculos se realizó según los siguientes criterios: rendimiento, seguridad, costo y practicidad.

Pregonero
DECO

actuación
Más rápido (0.6 s para terminar)
Más lento (10.50s para finalizar el protocolo)

seguridad
Menos seguro
Más seguro

costo
Mas caro
Más barato

practicidad
Requiere hardware especial
Funciona con cualquier servidor que admita TLS

Rendimiento de velocidad: Para trabajar con DECO, se requiere un protocolo de enlace de tres vías; cuando se configura a través de LAN, demora 0.37 segundos; para la interacción después de establecer la conexión, 2PC-HMAC es efectivo (0,13 s por escritura). El rendimiento de DECO depende de los conjuntos de cifrado TLS disponibles, el tamaño de los datos privados y la complejidad de la evidencia para una aplicación en particular. Usando la aplicación de opciones binarias de IC3 como ejemplo: completar el protocolo a través de LAN tarda aproximadamente 10,50 segundos. En comparación, Town Crier tarda aproximadamente 0,6 segundos en completar una solicitud similar, lo que es aproximadamente 20 veces más rápido que DECO. En igualdad de condiciones, TC será más rápido.

seguridad: Los ataques al enclave Intel SGX (ataques de canal lateral) funcionan y pueden causar daños reales a los participantes del contrato inteligente. En cuanto a DECO, los ataques relacionados con la inyección de tráfico son posibles, pero el uso de un proxy reduce dichos ataques a nada. Por tanto DECO es más seguro.

costo de: El costo del equipo que admite Intel SGX es mayor que el costo de configurar el protocolo en DECO. Por eso el TC es más caro.

Practicidad: Para trabajar con Town Crier, se requiere equipo especial que admita TEE. Por ejemplo, Intel SGX es compatible con la familia de procesadores Intel Core de sexta generación y posteriores. DECO le permite trabajar con cualquier equipo, aunque existe una configuración DECO usando TEE. Según el proceso de configuración, el protocolo de enlace de tres vías de DECO puede llevar algún tiempo, pero esto no es nada comparado con las limitaciones de hardware de TC, por lo que DECO es más práctico.

Conclusión

Al observar los dos oráculos por separado y compararlos según cuatro criterios, está claro que Town Crier es inferior a DECO en tres de cuatro puntos. DECO es más confiable desde el punto de vista de la seguridad de la información, más barato y más práctico, aunque configurar un protocolo tripartito puede llevar algún tiempo y tiene sus desventajas, por ejemplo, operaciones adicionales con claves de cifrado. TC es más rápido que DECO, pero las vulnerabilidades de ataques de canal lateral lo hacen susceptible a la pérdida de confidencialidad. Hay que tener en cuenta que DECO se introdujo en enero de 2020, y no ha pasado el tiempo suficiente para considerarlo seguro. Town Crier ha estado bajo ataque durante 4 años y ha pasado por muchas pruebas, por lo que su uso en muchos proyectos está justificado.

Fuente: habr.com