Hoy en día, solo el perezoso no ha escrito sobre la tecnología blockchain, las criptomonedas y cuán impresionante es. Pero en este artículo no se exaltará esta tecnología, sino que se hablará de sus desventajas y de las formas de solucionarlas.

Mientras trabajábamos en uno de los proyectos de Altirix Systems, surgió la necesidad de un mecanismo seguro y resistente a la censura para la verificación de datos de una fuente externa a blockchain. Era necesario validar los cambios en los registros de un tercer sistema y, basándose en esos cambios, ejecutar diferentes ramas en la lógica del contrato inteligente. La tarea, a primera vista, parece bastante trivial, pero cuando el resultado de su ejecución afecta la situación financiera de una de las partes implicadas en el proceso, aparecen requisitos adicionales. En primer lugar, debe haber una confianza total en este mecanismo de validación. Pero vayamos por partes.

El problema radica en que el blockchain por sí solo es un objeto autónomo y cerrado, por lo que los contratos inteligentes dentro del blockchain no tienen conocimiento del mundo exterior. Al mismo tiempo, las condiciones de los contratos inteligentes a menudo están relacionadas con información sobre cosas reales (retraso de vuelos, tipo de cambio, etc.). Para que los contratos inteligentes funcionen correctamente, la información que se obtiene desde fuera del blockchain debe ser fiable y verificada. Este problema se resuelve utilizando 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 verificado, se puede decir que son proveedores de información confiable.

Oráculos

Imagina que un contrato inteligente realiza la transferencia de 0.001 btc a tu billetera de bitcoin en caso de que tu club de fútbol favorito gane la Copa de Rusia. En caso de una victoria real, el contrato inteligente necesita recibir información sobre qué club ganó, y aquí surgen varios problemas: ¿cómo obtener esa información, cómo transmitirla de forma segura al contrato inteligente y cómo asegurarse de que la información recibida por el contrato inteligente realmente coincide con la realidad?

En términos de la fuente de información, pueden existir dos escenarios: conectar un contrato inteligente a un sitio web de confianza que almacena de manera centralizada la información sobre los resultados de los partidos, o conectar varios sitios y luego seleccionar la información de la mayoría de las fuentes que proporcionan los mismos datos. Para garantizar la precisión de la información, se utilizan oráculos, como Oraclize, que emplea TLSNotary (una modificación de TLS para validar la autenticidad de los datos). Sin embargo, hay mucha información sobre Oraclize en Google y varios artículos en Habré, hoy hablaré de los oráculos que utilizan un enfoque ligeramente diferente para la transmisión de información: Town Crier y DECO. El artículo describe los principios de funcionamiento de ambos oráculos, así como una comparación detallada.

Town Crier

Town Crier (TC) fue presentado por IC3 (The Initiative for CryptoCurrencies and Contracts) en 2016 en CCS’16. La idea principal de TC es transmitir información desde un sitio web a un contrato inteligente y asegurarse de que la información entregada por TC sea la misma que la del sitio web. TC utiliza TEE (Trusted Execution Environment) para la autenticidad de la propiedad de los datos. En la versión original, se describe el trabajo con Intel SGX.
Town Crier consta de una parte dentro de la blockchain y una parte dentro del propio sistema operativo: TC Server.

El contrato TC se encuentra en la blockchain y actúa como un front end para TC. Acepta solicitudes del CU (contrato inteligente del usuario) y devuelve la respuesta del TC Server. Dentro del TC Server se encuentra Relay, que establece la conexión entre el enclave y la red de Internet (tráfico bidireccional) y conecta el enclave con la blockchain. El enclave contiene progencl, que es el código que ejecuta solicitudes desde la blockchain y devuelve mensajes a la blockchain con una firma digital; progencl contiene parte del código del contrato inteligente y, en esencia, realiza algunas de sus funciones.

El enclave Intel SGX puede considerarse como una biblioteca general con API, funcionando a través de ecall. Ecall transfiere el control al enclave. El enclave ejecuta su código hasta que termina, o hasta que ocurre una excepción. Para llamar a funciones definidas fuera del enclave, se utilizan ocall. Ocall se ejecuta fuera del enclave y es manejado por este como una llamada no confiable. Después de la ejecución de ocall, el control regresa al enclave.

En la parte de Enclave se configura un canal seguro con el servidor web; el enclave realiza el handshake de TLS con el servidor objetivo y realiza todas las operaciones criptográficas internamente. La biblioteca TLS (mbedTLS) y el código HTTP en versión reducida están exportados al entorno SGX. Además, el Enclave contiene certificados de CA raíz (una colección de certificados) para verificar los certificados de los servidores remotos. El manejador de solicitudes recibe la solicitud de datagrama en el formato proporcionado por Ethereum, la descifra y la analiza. Luego genera una transacción de Ethereum que contiene el datagrama solicitado, la firma utilizando skTC y la envía a Relay.

La parte de Relay incluye la Interfaz del Cliente, TCP y la Interfaz de Blockchain. La Interfaz del Cliente es necesaria para la atestación del código del enclave y la comunicación con el cliente. El cliente envía una solicitud de atestación mediante ecall y recibe un timestamp, firmado con skTC, junto con att (la firma de atestación); luego, att se confirma mediante el Servicio de Atestación de Intel (IAS) y el timestamp se verifica con un servicio de tiempo confiable. La Interfaz de Blockchain verifica las solicitudes entrantes y coloca las transacciones en la cadena de bloques para la entrega de datagrams. Geth es el cliente oficial de Ethereum y permite que Relay interactúe con la cadena de bloques mediante llamadas RPC.

Trabajando con TEE, TC permite iniciar varios enclaves simultáneamente, aumentando así la velocidad de procesamiento de información tres veces. Si con un enclave funcionando la velocidad era de 15 tx/sec, con 20 enclaves ejecutándose en paralelo, la velocidad aumenta a 65 tx/sec; para comparación, la velocidad máxima de operación en la cadena de bloques de Bitcoin es de 26 tx/sec.

DECO

DECO (Oráculos Descentralizados para TLS) fue presentado en CCS’20 y trabaja con sitios que soportan conexión TLS. Asegura la privacidad y la integridad de los datos.
DECO con TLS utiliza cifrado simétrico, de modo que el cliente y el servidor web tienen claves de cifrado, y el cliente, si lo desea, puede falsificar los datos de la sesión TLS. Para resolver este problema, DECO utiliza un protocolo de handshake tripartito entre prover (smart contract), verifier (oráculo) y web-server (fuente de datos).

El principio de funcionamiento de DECO es que el verificante (prover) obtenga una parte de los datos D y confirme al verificador (verifier) que D provino del servidor TLS S. Otro problema es que TLS no firma los datos y al cliente TLS le resulta difícil demostrar que los datos se han recibido exactamente del servidor (dificultad de procedencia).

En el protocolo DECO se utilizan las claves de cifrado KEnc y KMac. El cliente envía una solicitud Q al servidor web, la respuesta del servidor R llega de forma cifrada, pero el cliente y el servidor tienen los mismos KMac, y el cliente puede falsificar un mensaje TLS. La solución de DECO consiste en "ocultar" KMac del cliente (prover), hasta que él responda a la solicitud. Ahora, KMac se divide entre prover y verifier: KpMac y KvMac. El servidor recibe KMac para cifrar la respuesta usando la operación sobre las partes de la clave KpMac ⊕ KvMac = KMac.

Al configurar un apretón de manos tripartito, el intercambio de datos entre el cliente y el servidor se realizará con garantía de seguridad.

Hablando del sistema de oráculos descentralizados, no se puede dejar de mencionar a Chainlink, que busca crear una red descentralizada de nodos oráculos compatibles con Ethereum, Bitcoin y Hyperledger, teniendo en cuenta la modularidad: cada parte del sistema puede ser actualizada. Para garantizar la seguridad, Chainlink ofrece a cada oráculo que participa en la tarea, proporcionar una combinación de claves (pública y privada). La clave privada se utiliza para generar una firma parcial que contiene su solución a la solicitud de datos. Para obtener una respuesta, es necesario la combinación de todas las firmas parciales de los oráculos de la red.

Chainlink planea realizar un PoC inicial de DECO con énfasis en aplicaciones financieras descentralizadas, como Mixicles. En el momento de escribir este artículo, salió una noticia en Forbes sobre 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 han considerado los siguientes ataques a Town Crier:

1. Inyección de código de contacto inteligente malicioso en nodos TEE.
   La esencia del ataque: transmisión a TEE de un código de contrato inteligente deliberadamente incorrecto, de modo que un atacante que acceda al nodo tendrá la capacidad de ejecutar su propio contrato inteligente (fraudulento) sobre los datos descifrados. Sin embargo, los valores devueltos estarán cifrados con la clave privada, y la única forma de acceder a esos datos es mediante la filtración del texto cifrado al devolverlo/extraerlo.
   La protección contra este ataque radica en la verificación de la validez del código por parte del enclave, ubicado en la dirección actual. Esto puede lograrse mediante un esquema de direccionamiento, donde la dirección del contrato se determina mediante el hash del código del contrato.

2. Los cambios en el texto cifrado del estado del contrato filtran información.
   La esencia del ataque: Los propietarios de nodos en los que se ejecutan contratos inteligentes tienen acceso al estado del contrato en una forma encriptada fuera del enclave. Un atacante que logre tomar control del nodo puede comparar el estado del contrato antes y después de ejecutar la transacción y puede determinar qué argumentos se han ingresado y qué método específico del contrato inteligente se ha utilizado, ya que el código del contrato inteligente y sus especificaciones técnicas son de acceso público.
   Protección en garantizar la confiabilidad del propio nodo.

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

   • t0: El atacante llena toda la caché de datos del proceso de la víctima.
   • t1: La víctima ejecuta código con accesos a la memoria que dependen de datos confidenciales de la víctima (claves criptográficas). La elección de la línea de caché se realiza según el valor de keybit. En el ejemplo de la imagen, keybit = 0 y se ha leído la dirección X en la línea de caché 2. Los datos almacenados en X se cargan en la caché, despojando a los datos que estaban allí antes.
   • t2: El atacante verifica cuáles de sus líneas de caché han sido desplazadas - las líneas utilizadas por la víctima. Esto se hace midiendo el tiempo de acceso. Repitiendo esta operación para cada keybit, el atacante obtiene toda la clave.

Protección contra el ataque: Intel SGX tiene protección contra ataques de canal lateral, que prohíbe el monitoreo de eventos relacionados con la caché, pero el ataque Prime and Probe aún pasará, ya que el atacante observa los eventos de caché de su propio proceso y comparte la caché con la víctima.

Por lo tanto, hasta el momento no hay una protección confiable contra este ataque.

También se conocen ataques como Spectre y Foreshadow (L1TF), similares a Prime and Probe. Permiten la lectura de datos de la memoria caché a través de un canal lateral. Hay una protección contra la vulnerabilidad Spectre-v2, que funciona contra estos dos ataques.

En relación con DECO, el apretón de manos tripartito proporciona una garantía de seguridad:

1. Integridad del Prover: un prover comprometido no puede falsificar información sobre el origen del servidor y no puede obligar al servidor a aceptar solicitudes no válidas o responder incorrectamente a solicitudes válidas. Esto se logra a través de patrones de solicitudes entre el servidor y el prover.
2. Integridad del Verifier: un verifier comprometido no puede obligar al prover a recibir respuestas incorrectas.
3. Privacidad: Un verificador comprometido solo examina información pública (consulta, nombre del servidor).

En DECO, solo son posibles vulnerabilidades relacionadas con la inyección de tráfico. Al principio, durante el apretón de manos de tres vías, el verificador puede establecer la identidad del servidor utilizando un nonce fresco. Sin embargo, después del apretón de manos, el verificador debe confiar en indicadores de nivel de red (IP). Así, la conexión entre el verificador y el servidor debe estar protegida contra la inyección de tráfico. Esto se logra mediante el uso de un Proxy.

Comparación de oráculos

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

Town Crier
DECO

rendimiento
Más rápido (0.6s para finalizar)
Más lento (10.50s para finalizar el protocolo)

seguridad
Menos seguro
Más seguro

costo
Más caro
Más barato

practicidad
Requiere hardware específico
Funciona con cualquier servidor que soporte TLS

Rendimiento: Para trabajar con DECO se requiere la configuración de un apretón de manos de tres vías, al configurarlo a través de LAN, esto toma 0.37 segundos, para la interacción después de establecer la conexión, 2PC-HMAC es efectivo (0,13 s en escritura). El rendimiento de DECO depende de los conjuntos de cifrado TLS disponibles, el tamaño de los datos personales y la complejidad de las pruebas para una aplicación específica. Tomando como ejemplo la aplicación de opciones binarias de IC3: la finalización del protocolo a través de LAN toma aproximadamente 10,50 s. En comparación, Town Crier requiere para ejecutar una aplicación similar aproximadamente 0.6 segundos, es decir, 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ño real a los participantes del contrato inteligente. Con respecto a DECO, son posibles ataques relacionados con la inyección de tráfico, pero el uso de proxy mitiga tales ataques. Por lo tanto, DECO es más seguro.

Costo: El costo del hardware que soporta el trabajo con Intel SGX es más alto que el costo de configurar el protocolo en DECO. Por lo tanto, TC es más caro.

Practicidad: Para trabajar con Town Crier es necesario un equipo especial que soporte TEE. Por ejemplo, Intel SGX es compatible con procesadores de la familia Intel Core de sexta generación en adelante. DECO, por otro lado, permite trabajar con cualquier equipo, aunque hay una configuración DECO que utiliza TEE. En el proceso de configuración, el apretón de manos tripartito de DECO puede tardar un poco, pero esto no se compara con la limitación de hardware de TC, lo que hace que DECO sea más práctico.

Conclusión

Al considerar los dos oráculos por separado y compararlos en cuatro criterios, se observa que Town Crier pierde frente a DECO en tres de los cuatro puntos. DECO es más fiable desde el punto de vista de la seguridad de la información, es más económico y más práctico, aunque la configuración del protocolo tripartito puede llevar un tiempo y tiene sus desventajas, como operaciones adicionales con claves de cifrado. TC funciona más rápido que DECO, pero la vulnerabilidad asociada con un ataque de canal lateral lo hace susceptible a la pérdida de privacidad. Hay que tener en cuenta que DECO fue presentado en enero de 2020, y no ha pasado suficiente tiempo para considerarlo seguro. Town Crier ha sido atacado durante 4 años y ha pasado por múltiples pruebas, por lo que su uso en muchos proyectos está justificado.

Fuente: habr.com