Autor: Dr. Shunfan (Shelven) Zhou, investigador principal de Phala Network y uno de los autores del documento técnico de Phala, se ha dedicado a la investigación de seguridad durante más de 7 años. Es el autor principal de An Ever-evolving Game: Evaluation of Real-world Attacks and Defenses in Ethereum Ecosystem, USENIX Security Symposium 2020 y otros artículos sobre análisis de programas.

Resumen

El 30 de noviembre, el experto en seguridad Andrew Miller señaló que las vulnerabilidades de Intel SGX habían causado grandes riesgos de seguridad a proyectos como Secret Network, lo que ha suscitado amplias discusiones en la comunidad. Intel SGX, la implementación de TEE más ampliamente adoptada, también es utilizada por los trabajadores fuera de la cadena de Phala; sin embargo, Phala utiliza un diseño de sistema novedoso que reduce la superficie de ataque y mitiga las consecuencias de posibles ataques. Nuestro equipo de desarrollo considera que los impactos de tales vulnerabilidades en Phala son controlables.

Este artículo explicará a los lectores:

• Por qué las vulnerabilidades ÆPIC Leak y MMIO socavaron la seguridad de Secret Network
• Las razones por las que Phala utiliza Secure Enclave (TEE)
• Cómo Phala se asegura de que no se verá comprometida por las vulnerabilidades de SGX
• Futuros mecanismos de seguridad

1. ¿Qué causó la vulnerabilidad en Secret Network?

• El hardware con vulnerabilidades sin parches ( vulnerabilidades ÆPIC Leak y MMIO , anunciadas por Intel el 9 de agosto de 2022) pudo unirse a Secret Network y operar nodos. El equipo de Secret congeló el registro después de que whitehat informara sobre este problema;
• La misma clave maestra de descifrado en Secret Network se comparte en todos los nodos.

2. ¿Qué podrían lograr los atacantes?

Como cito dehttps://sgx.fail: “Estas vulnerabilidades podrían usarse para extraer la semilla de consenso, una clave maestra de descifrado para las transacciones privadas en la Red Secreta. La exposición de la semilla de consenso permitiría la divulgación retroactiva completa de todas las transacciones privadas de Secret-4 desde que comenzó la cadena”.

3. ¿Phala Network está afectada por las mismas vulnerabilidades?

No. Phala adopta el control de acceso en el registro del nodo (llamado ' trabajador' en Phala) y la gestión de la jerarquía de claves, que trataré más adelante.

Recursos :

• https://scrt.network/blog/notice-successful-resolution-of-xapic-vulnerability
• https://sgx.fail/

Por qué Phala necesita Secure Enclave (TEE)

Phala es una nube de cómputo sin permisos que permite que cualquier computadora se una como trabajadores, por lo que nuestro modelo de amenazas es que no se confía en ningún trabajador de manera predeterminada. Los malos actores que operan como trabajadores pueden intentar:

• echar un vistazo a los datos de los usuarios;
• proporcionar resultados de ejecución falsos o no realizar ningún cálculo;
• proporcionar servicios de baja calidad, como reducir el rendimiento de la CPU o bloquear el acceso a la red.

Secure Enclave proporciona importantes promesas de seguridad basadas en hardware, que incluyen:

• Confidencialidad : todos los valores de la memoria están encriptados;
• Integridad de la ejecución : nadie puede corromper la corrección de la ejecución, incluso si controla el sistema operativo y la computadora física;
• Atestación remota : los usuarios pueden verificar de forma remota el hardware y el software que se ejecutan dentro de Secure Enclave.

Estas características sirven como base de confianza para que podamos "tomar prestada" la potencia informática de las personas. Vale la pena señalar que, como nube informática, los valores centrales de Phala son la ejecución correcta de los programas de los usuarios y la privacidad de los datos de los usuarios. Esto diferencia a Phala de otros proyectos que se centran únicamente en la confidencialidad.

¿Puede Phala utilizar la prueba de conocimiento cero, la computación multipartita o el cifrado completamente homomórfico como trabajadores?

La respuesta es no, sí y sí, ya que estas soluciones funcionan de diferentes maneras.

• En el caso de ZKP, el usuario hace su propia ejecución y solo proporciona la prueba en cadena de que realmente ha realizado el trabajo. Este no es el caso de la computación en la nube en el que delega su computación a otros;
• MPC divide los trabajos en diferentes partes, por lo que ninguno de los ejecutores puede conocer la entrada original o la salida final;
• FHE permite a los ejecutores calcular directamente con texto cifrado, por lo que no pueden conocer los datos de los usuarios.

Control de Acceso en el Registro de Trabajadores

Incorporarse a Phala como trabajador implica dos requisitos previos:

• Los trabajadores deben suministrar hardware con soporte de Secure Enclave. Actualmente solo admitimos Intel SGX, pero nuestra investigación sobre AMD-SEV ha demostrado que también es compatible con nuestro sistema actual;
• Los trabajadores ejecutan programas creados por Phala sin modificar, incluido el nodo Phala y pRuntime fuera de la cadena (abreviatura de Phala Runtime) .

• información de hardware
• Si pRuntime se ejecuta dentro de SGX;
• Las vulnerabilidades conocidas dada la versión actual de hardware y firmware. En base a esto, Phala blockchain rechazará el hardware con vulnerabilidades en la lista negra y asignará a cada trabajador un nivel de confianza .
• Información del programa
• El hash del binario del programa, que ayuda a garantizar que pRuntime no se modifique;
• Se determina el diseño de memoria inicial del programa, por lo que se determina su estado inicial.

Además, nuestro Supply-end Tokenomic incentiva un servicio de alta calidad por parte de los trabajadores. Esto está fuera del alcance de este artículo, pero puede obtener más información en nuestra página de tokenómica vinculada anteriormente.

Gestión de jerarquía de claves

La primera jerarquía de claves del mundo para el sistema híbrido blockchain-TEE fue propuesta por el artículo de Ekiden en 2019 y sirve como base para el proyecto Oasis. Como nube informática, Phala mejora este diseño para que sea viable para una red de ~100k nodos. También presentamos un mecanismo novedoso como la rotación de claves para mejorar aún más la solidez de la nube.

Antes de profundizar en los detalles de la gestión de claves de nuestro contrato, es importante que los lectores sepan que cada entidad de nuestro sistema tiene su propia clave de identidad. Cada usuario tiene su cuenta, y cada trabajador y guardián (que son elegidos por los trabajadores) tiene su propio par sr25519 WorkerKey , que se genera dentro de pRuntime (también en SGX) y la clave privada nunca sale del SGX. La clave de identidad se utiliza para:

• Identificar el mensaje de una entidad con firma;
• Establezca un canal de comunicación encriptado entre usuarios, trabajadores y gatekeepers con acuerdo de clave ECDH . Por defecto, cualquier comunicación entre cualquier entidad está encriptada en Phala.

• Los guardianes son trabajadores del más alto nivel de confianza: son inmunes a todas las vulnerabilidades conocidas de SGX;
• A diferencia de los trabajadores normales, los puntos finales de los guardianes no son públicos y no puede implementarles contratos. Esto reduce el acceso remoto a los guardianes;
• Se requieren mayores cantidades de apuestas por parte de los guardianes para desalentar el mal comportamiento de sus operadores.

Finalmente, cuando se implementa un contrato en un clúster, se implementa en todos los trabajadores de ese clúster. Estos trabajadores seguirán el proceso determinista y obtendrán la ClusterKey para obtener la misma ContractKey. Las ContractKeys son únicas para diferentes contratos.

¿Cuáles son las vulnerabilidades si se filtran ciertas claves?

• Si se filtra una WorkerKey, los atacantes pueden descifrar todos los mensajes que se le envían, como la ClusterKey de su clúster, que se puede usar para acceder a las ContractKeys de ese clúster. Los atacantes podrían incluso hacerse pasar por un trabajador para proporcionar resultados falsos a los usuarios. Dicha actividad maliciosa se puede detectar comparando los resultados de varios trabajadores, y luego la cadena cortaría al trabajador comprometido y confiscaría el PHA en juego de ese trabajador;
• Si se filtra una ContractKey, los atacantes pueden descifrar los estados y todas las entradas históricas de ese contrato;
• Si se filtra una ClusterKey, los atacantes pueden conocer la información anterior de todos los contratos en ese clúster;
• Si se filtra la MasterKey, se filtran todos los datos históricos.

• Phala ha implementado la Rotación de claves para los guardianes, lo que significa que con el permiso del Consejo, los guardianes pueden actualizar la MasterKey, y luego las ClusterKeys y ContractKeys correspondientes.
• Entonces, cuando ocurra el peor de los casos, primero registraremos los nuevos guardianes con el hardware más reciente, cancelaremos el registro de todos los antiguos (ya que es probable que sean vulnerables) y cambiaremos a una nueva MasterKey.

1. Use la computación de múltiples partes para administrar MasterKey

2. Habilite la actualización de cotizaciones de RA

Dado que Phat Contract actualmente no es compatible con la red principal, los trabajadores solo deben enviar las cotizaciones de RA una vez durante su registro. Cuando se publique Phat Contract, habilitaremos una actualización regular de cotizaciones de RA para que los trabajadores vulnerables se reduzcan drásticamente una vez que se informen nuevas vulnerabilidades y los trabajadores no apliquen los parches.

Finalmente, me gustaría agradecer a Andrew Miller y al equipo de investigación de seguridad que incluye a Christina Garman, Daniel Genkin, Stephan van Schaik y otros por su contribución al campo de la seguridad. Como dijo Andrew, el objetivo de su equipo es ayudar a mejorar la seguridad y reducir la ocurrencia de accidentes de seguridad. Sinceramente espero tener discusiones más profundas con los investigadores de seguridad para consolidar la infraestructura sin confianza para el mundo Web3.