Entorno de ejecución confiable (sellado) en Linux

No, esto no es posible. No en Linux y no en ningún otro entorno informático. No es una limitación de Linux, es una limitación de la física.

Si ejecuta su código en la computadora de otra persona ... es su computadora, por lo que controlan lo que se ejecuta en ella. Si tienen su código, pueden verlo ejecutarse, inspeccionar su memoria, hacer que haga cosas diferentes si lo desean. Pueden ejecutar su código en una máquina virtual para facilitar la depuración. Puede intentar detectar eso, pero haga lo que haga, pueden omitirlo si le dan a su programa las respuestas correctas, si están lo suficientemente motivadas.

Intel SGX funciona porque cuando compro un procesador con SGX, no es realmente mi computadora, es parcialmente una computadora de Intel. Intel retiene el control sobre el software que se ejecuta en el enclave SGX. Usted envía el código encriptado y firmado con una clave que pertenece a Intel; El enclave SGX descifra y verifica el código con una clave a la que solo puede acceder el enclave. El enclave no me pertenece, pertenece a Intel, por lo tanto, si no desea que su código tenga ingeniería inversa, solo debe confiar en Intel y no en mí. Solo recibo un blob encriptado de ti y no puedo ejecutarlo en otro lugar porque no puedo descifrarlo.

Puede usar SGX para aplicaciones que requieren E / S. Solo tiene que dividir su aplicación en dos partes: la parte confiable que se ejecuta en SGX y la parte de la interfaz de usuario (y el backend de almacenamiento) que se ejecuta fuera.

Tenga en cuenta que las defensas contra la ingeniería inversa son muy costosas (en términos de depuración y costos de soporte, así como el tiempo de desarrollo y la pérdida de rendimiento). La ingeniería inversa y la modificación de un programa son caras; Por lo general, es más económico pagarle por hacer la modificación que hacerlo y mantenerlo internamente.

Mientras el atacante no pueda obtener el anillo -1, puede configurar un hipervisor y usar Bispe, desde enlace . Es experimental, pero parece ser la solución de software más cercana a lo que está buscando. Permanecerá seguro mientras el atacante no pueda leer los registros de depuración. Es posible que se requiera una pequeña modificación para que funcione por debajo del anillo 0, pero no es inviable. Si no esperas que el malware sea capaz de obtener el anillo 0 en primer lugar, sino solo probar la memoria por otros medios, entonces debería funcionar de manera inmediata.

  

El acceso físico a un sistema permite a los atacantes leer RAM a través de un arranque en frío y ataques DMA. Hasta el momento, las medidas de contador solo protegen contra los ataques dirigidos a las claves de cifrado del disco, mientras que el contenido de la memoria restante queda vulnerable. Presentamos un intérprete de código de bytes que protege el código y los datos de los programas contra ataques de memoria ejecutándolos sin utilizar RAM para contenido sensible. Cualquier contenido del programa dentro de la memoria está encriptado, para lo cual el intérprete utiliza TRESOR, una implementación resistente al arranque en frío del cifrado AES. El intérprete se desarrolló como un módulo del kernel de Linux, aprovechando los conjuntos de instrucciones de la CPU AVX para registros adicionales y AES-NI para el cifrado rápido. Mostramos que el intérprete está seguro contra ataques de memoria y que el rendimiento general es solo un factor 4 veces más lento que el rendimiento de Python. Por otra parte, la penalización de rendimiento se debe principalmente al cifrado.

En cuanto a Intel SGX, aunque no es compatible con E / S, eso no es necesariamente un obstáculo para el juego. Se le puede agregar I / O siempre que use las API adecuadas. Incluso podría ejecutar una instancia de QEMU completa en un enclave SGX, y creo que incluso se está trabajando en eso.