Articulo Original en Ingles de HangYi
Puedes pensar que blockchain tiene poco que ver con el hardware. Después de todo, desde Bitcoin hasta Etherum, las cadenas de bloques están definidas por software. La solución basada en hardware suele ser más centralizada. Sin embargo, en el mundo de la cadena de bloques que preserva la privacidad, al combinar cuidadosamente el software y el hardware, podríamos diseñar una solución con el mejor equilibrio entre escalabilidad y confidencialidad, sin dejar de ser confiable.
Confidencialidad en la blockchain basada en TEE
Phala Network implementa un contrato inteligente confidencial. Se diferencia de los contratos tradicionales porque los contratos se ejecutan dentro de un enclave de hardware especial en la CPU, es decir, Trusted Execution Environment (Entorno de ejecucion confiable). El programa que se ejecuta dentro de TEE está muy aislado del resto del mundo. Un ataque malintencionado no puede leer los datos en la memoria sin autorización ni manipular el programa para producir un comportamiento no deseado.
En Phala Network,llamamos al programa que se encarga de la ejecución dentro de TEE “pRuntime”. pRuntime es el entorno de ejecución que mantiene el minero de TEE básico y el protocolo Gatekeeper dentro del TEE. Gestiona la Certificación remota TEE, el registro en cadena, la administración de claves y la ejecución de contratos confidenciales.
Pero, ¿cómo convencer a un usuario de que el contrato inteligente se está ejecutando dentro de pRuntime, y no en un emulador que no proporcionaria ninguna seguridad de datos? Aquí viene el concepto central: Certificación remota(Remote Attestation)
Remote Attestation — Certificación Remota
“ Una aplicación que aloja un enclave también puede pedirle al enclave que produzca un informe y luego pasar este informe a un servicio de una plataforma para producir un tipo de credencial que refleje el estado del enclave y la plataforma. Esta credencial se conoce como quote . Este quote se puede pasar a entidades fuera de la plataforma y verificar … ”
La Certificación remota es la clave para garantizar la seguridad de un sistema TEE. Citado por Intel, demuestra que un cierto código (medido por el hash del código), opcionalmente con algunos datos personalizados generados en el código, se está ejecutando dentro de un enclave Intel SGX genuino actualizado.
Aprovisionamiento secreto
La Certificación remota es un componente básico para los contratos inteligentes confidenciales. Pero no es muy útil si no podemos establecer un canal de comunicación seguro de un extremo a otro (desde un parte hasta el TEE). Intel SGX también proporciona un protocolo de aprovisionamiento secreto para resolver el problema con elegancia.
Al adoptar el protocolo de aprovisionamiento secreto, se puede establecer una cadena de confianza entre el usuario y pRuntime:
- La cadena de bloques tiene el hash del código canónico pRuntime
- pRuntime ejecuta el protocolo de Certificación remota, obtiene un informe con los datos: hash del código certificado (pRuntime en sí); y la clave pública de un par de claves de identidad efímeras.
- El informe de RA (Certificación remota) se envía a la cadena de bloques y se valida en la cadena
- La cadena de bloques compara el hash del informe de RA (implica: el participante es un pRuntime canónico en TEE)
- La clave pública de identidad está registrada en la cadena de bloques (implica: solo el pRuntime actual tiene control sobre esta clave de identidad)
Como resultado, siempre que un mensaje esté firmado por la clave de identidad, este debe ser producido por un pRuntime registrado. Los usuarios pueden establecer una conexión similar a TLS a un pRuntime con su clave pública registrada.
Para comunicarse con TEE, el usuario puede obtener la clave pública de un determinado pRuntime de la cadena de bloques (del registro de TEE). Luego, el usuario puede usar la clave pública de su cuenta substrate para ejecutar un protocolo Diffie-Hellman. Deriva una clave secreta para la comunicación entre el usuario y el pRuntime.
Como se estableció la cadena de confianza, también implica que la clave de identidad es suficiente para representar de forma única la identidad del pRuntime. Por lo tanto, una sola Certificación remota puede proteger toda la comunicación actual y futura con el pRuntime, si se asume que no hay una violación de hardware TEE (lo que se discutirá más adelante).
¿Cómo es la actualización?
La actualización On-Chain es un requisito crítico, ya que reduce en gran medida los riesgos de seguridad expuestos por un hard fork. Substrate admite de forma nativa la actualización en tiempo de ejecución de la cadena. Se realiza mediante la plataforma de gobernanza en cadena (on-chain governance pallet). Por parte de TEE, también se puede actualizar en tiempo de ejecución.
Al actualizar pRuntime, debemos enviar el hash de la nueva versión de pRuntime a la blockchain. Despues, la comunidad puede revisar el código, discutir y votar por la actualización mediante un proceso de gobernanza en cadena similar al Substrate.
Tanto los Gatekeepers como los mineros deben actualizar pRuntime una vez que se acepta una nueva versión en la cadena. Los mineros son más fáciles porque simplemente pueden detener la minería, realizar la actualización y reanudar la minería. Esto es posible porque no se requiere que los mineros estén siempre en línea. Los guardianes tienen requisitos de alta disponibilidad. Entonces, o ejecutan otro cliente TEE con la versión más reciente y esperan un cambio natural de Gatekeepers en el próximo período de elección, o hacen un volcado cifrado de emergencia de los estados y lo recuperan al nuevo pRuntime.
Aunque hay riesgos al realizar el volcado del estado, sigue siendo útil en caso de emergencia. SGX proporciona una función “sellar a enclave”, que puede producir un cifrado que solo puede ser descifrado por el mismo enclave.
Para mitigar los riesgos de las vulnerabilidades de seguridad del hardware, las claves en los Gatekeepers se distribuyen mediante un esquema de intercambio secreto de Shamir, lo que significa que incluso si el sellado se estropea , el host no puede obtener las claves originales salvo pacto masivo con terceras partes.
Ataque y Defensa
Nuestro modelo de mitigacion de amenazas asume parcialmente que se puede confiar en el fabricante de TEE. Esto es razonable. Primero, no saben cómo se utilizará su hardware y, por lo tanto, solo pueden planificar el ataque con anticipación, reduciendo los riesgos. En segundo lugar, si se ven afectadas por ataques de día cero, las otras aplicaciones que se ejecutan en esta CPU también estarán en riesgo.
Aunque tenemos la suposición anterior, sabemos que las vulnerabilidades de hardware reales ocurrieron en el pasado. Afortunadamente, las vulnerabilidades generalmente se pueden mitigar de varias maneras.
Es común pensar que las vulnerabilidades del software se pueden parchear, mientras que las vulnerabilidades del hardware no. Este no es siempre el caso. La CPU se puede parchear mediante actualizaciones de microcódigo. Con el diseño especial de la arquitectura Intel SGX, la mayoría de las vulnerabilidades se pueden solucionar. Recientemente, hubo un ataque llamado SGAxe, que se solucionó mediante una actualización de microcódigo seguida de una rotación de clave de grupo. Después de la rotación y revocación de claves, la certificación remota rechaza todos los dispositivos obsoletos.
Pero podría preguntarse, ¿qué pasa si alguien todavía encuentra una vulnerabilidad de día cero en el hardware ? Supongamos que la vulnerabilidad requiere acceso físico para explotarla, los mineros podrán robar datos del contrato confidencial. En este caso, puede mitigarse aplicando aleatoriedad. La cadena de bloques puede asignar aleatoriamente a algunos mineros a los contratos confidenciales en un período. Los mineros barajan cada uno de esos períodos. Mientras la parte malintencionada no tenga control sobre una gran cantidad de mineros, el costo de realizar tal ataque será significativamente alto porque requiere un control masivo en un tiempo relativamente largo.
En el peor de los casos, donde el enclave está completamente resquebrajado, exponiendo los datos confidenciales disponibles el atacante y permitiendo que el atacante manipule arbitrariamente la ejecución, todavía no queremos renunciar a la exactitud del contrato confidencial. Por lo tanto,por diseño tenemos el requerimiento de que los contratos confidenciales necesitan una o más réplicas.
El número de replicación no afecta la forma en que se ejecuta el contrato porque todas las entradas son de la cadena de bloques y, por lo tanto, deterministas. Sin embargo, si existe más de una réplica, varios TEE intentarán devolver los estados a la cadena de bloques. En este caso, habrá un sencillo proceso de votación en cadena. SE requerira una mayoría simple para “finalizar” los estados.
Al tener replicaciones, el exito del fallo vuelve a depender de un modelo de seguridad similar al validador de Polkadot. El atacante debe controlar una cantidad suficiente de mineros para romper la corrección, incluso en el supuesto de romper la seguridad de SGX
Sumario
En el pasado, las cadenas de bloques eran solo software. La falta de confidencialidad se ha convertido durante mucho tiempo en una limitación para la adopción masiva. Con la ayuda de hardware y un protocolo cuidadosamente diseñado, demostramos que es posible construir una cadena de bloques segura, escalable y que preserve la confidencialidad.
Sobre Phala
Es la primera plataforma de contratos inteligentes desarrollada cobre Substrate , en la cual se puede desarrollar apps con preservación del secreto y protección de la privacidad. Miembros del Parity Builders Program . Ganadora de Web3 Foundation Grant.
Prueba la demo W3A Dev