DDS Security the Hard (ware) Way - SGX:Part 1 (Overview)

Parte 1 de varias partes Serie

La protección de los entornos de IoT industriales de misión crítica requiere una seguridad que se amplíe desde el borde hasta la nube, en todos los sistemas y proveedores. Como autor principal del estándar OMG DDS Security, RTI ha desempeñado un papel de liderazgo en la definición de los requisitos y entornos necesarios para proteger los entornos distribuidos. Los complementos de DDS Security proporcionan mecanismos de seguridad robustos y centrados en los datos para los datos en el cable. RTI Connext DDS Secure es el marco de conectividad confiable y comprobado que protege los sistemas a través de una seguridad flexible y detallada para un rendimiento y una eficiencia óptimos, desde el dispositivo hasta la nube.

Sin embargo, reconocemos que la seguridad es un tema complejo. Si bien RTI ha creado seguridad de alto grado en el marco del software Connext DDS, nuestro equipo de investigación está buscando otras áreas para impulsar una seguridad más sólida en IIoT. Con esto en mente, nos complace compartir con usted parte del trabajo de RTI Research, a medida que exploran enfoques nuevos e innovadores de seguridad.

En esta serie de blogs, nuestro experto en seguridad Jason Upchurch mira más allá del software a los mecanismos de hardware que brindan seguridad en un sistema poco confiable donde una aplicación crítica procesa sus datos. Con el espíritu de ir más allá de la seguridad, explora Intel SGX® dentro del contexto de RTI Connext® DDS Micro y complementos de seguridad.

Entonces empecemos.

¿Qué es SGX y por qué es importante?

SGX, o Software Guard Extensions, es una extensión de Intel ISA (Arquitectura de conjunto de instrucciones) que proporciona un TEE (Entorno de ejecución confiable) para ejecutar aplicaciones que contienen datos confidenciales. Si bien es cierto que Intel ISA no domina el IoT industrial (IIoT), tiene participación de mercado en la sala de servidores, y la sala de servidores a menudo se incorpora a varias arquitecturas IIoT. Más concretamente, es más probable que estas aplicaciones de procesamiento de datos de la sala de servidores sean objetivos de gran valor para los usuarios malintencionados, ya que pueden tener más acceso a datos protegidos que los puntos finales IIoT tradicionales. Por lo tanto, SGX podría ayudar a asegurar el IIoT, o al menos una parte de él. Exploremos por qué SGX es importante para los usuarios de DDS y otros desarrolladores de aplicaciones que requieren entornos de alta seguridad.

Figura 1:Connext DDS Secure Inside SGX Space

La seguridad inalámbrica puede no ser suficiente

Para empezar, veamos el ejemplo académico clásico de Alice y Bob de compartir un secreto. La historia comienza cuando Alice y Bob se conocen en persona, avanza con una tortuosa Eve interceptando mensajes en el cable y termina con un método probado para compartir secretos. Esta es la base para una comunicación segura, incluso si Eve intercepta todos los mensajes. Después de haber realizado varias de las investigaciones de intrusiones más importantes del mundo, puedo decir con seguridad que nunca he visto a "Eve" interceptar mensajes cifrados por cable y recopilar secretos. También puedo decir con certeza que "Eve" casi siempre obtiene los secretos que busca. Estas afirmaciones aparentemente contradictorias pueden ser ciertas porque el cifrado de red es sólido y, por lo tanto, rara vez es el objetivo de un ataque.

Para examinar el tema, veamos el escenario, donde Eve se sienta entre Alice y Bob y puede escuchar e incluso manipular los mensajes a voluntad. El escenario asume que Alice y Bob se confían mutuamente los secretos que están compartiendo; sin embargo, esta suposición resulta ser muy defectuosa en la práctica. El diagrama del libro de texto en la Figura 2 en realidad ilustra el problema, ya que Alice aparentemente se comunica con Bob a distancia sin ninguna tecnología.

Figura 2:Comunicación de Alice y Bob en el libro de texto

La realidad de la situación es que se utiliza algún tipo de dispositivo para permitir que Alice y Bob se comuniquen, y aquí es donde nuestra suposición nos domina. En seguridad informática, existe un concepto conocido como Trusted Computing Base (TCB). En sus términos más simples, TCB son todos los componentes (tanto individualmente como como sistema), incluido el software, en los que debe confiar para asegurar algún tipo de procesamiento. En nuestro escenario clásico de Alice y Bob, estamos intentando asegurar el intercambio de secretos a distancia. Es cierto que Alice asume que confía en Bob para compartir secretos con él, pero también confía en su entorno informático (y en el de ella). En un escenario del mundo real, este es un conjunto de cientos de componentes de varios fabricantes que (a) probablemente ejecute un sistema operativo con millones de líneas de código; (b) está lleno de aplicaciones codificadas por personas que no conoce; y (c) probablemente conectado a una red pública que permita a los atacantes y al malware de propagación automática el acceso libre para atacar el sistema a voluntad. Estos sistemas están lejos de ser confiables, por decir lo mínimo.

... la situación es análoga a construir una puerta de acero con cerraduras elaboradas en una casa con paredes de papel.

Es una fuente de humor cínico para muchos en la comunidad de seguridad informática cuando se recomienda algún esquema de cifrado nuevo y mejor para cifrar la comunicación por cable. Después de todo, los secretos se pueden extraer con poco esfuerzo desde el origen o el destino, completamente en claro, sin preocuparse por el cifrado en absoluto. Siempre he pensado que la situación es análoga a construir una puerta de acero con cerraduras elaboradas en una casa con paredes de papel.

¿Así que, qué debe hacerse? El enfoque actual en la industria se centra principalmente en encontrar los componentes viables mínimos (hardware y software) necesarios para lograr una tarea crítica, certificar y / o medir cada componente y aislarlos de otros componentes del sistema. En un nivel muy básico, este enfoque reduce la TCB y verifica que no se haya agregado ni modificado ningún componente dentro de la TCB.

Seguridad en el endpoint (y en todos los puntos intermedios)

Es útil señalar que, aunque no es trivial, hemos llegado al punto en la informática en el que es posible construir un entorno informático seguro. El problema es que la demanda actual del mercado es de un entorno informático rico, que está en desacuerdo con uno seguro. Incluso en IIoT, la demanda de entornos informáticos ricos no siempre se debe a la amplia funcionalidad que ofrecen, sino a que son populares y están bien respaldados, por lo que es mucho más económico desarrollarlos y mantenerlos. Por lo tanto, el gran problema de la TCB llega a los dispositivos que podrían protegerse con otro enfoque. En respuesta al problema, la industria ha optado por diseñar sistemas que brinden tanto un sistema operativo enriquecido como un entorno de ejecución confiable (TEE) separado (de alguna manera) en un solo dispositivo.

La mayoría de los diseños de TEE tienen esencialmente dos sistemas operativos que se ejecutan en paralelo en un solo dispositivo. El rico sistema operativo maneja tareas comunes y el sistema operativo seguro maneja tareas sensibles. El diseño TEE permite cambiar entre los dos. El conmutador suele ser compatible y ejecutado por hardware. Los mecanismos de confianza comunes, como la raíz de la carga de la cadena de confianza, se utilizan en el lado seguro para garantizar que no se haya introducido ningún código no autorizado.

SGX es bastante diferente. Incluso un TCB lateral seguro puede ser bastante grande. La raíz de confianza solo garantiza que un programa no se modifique al cargarse. Como tal, su seguridad depende de las técnicas de validación de software para cada programa cargado (incluido el sistema operativo mínimo) tanto como su proceso de arranque confiable. Intel se propuso minimizar radicalmente la TCB. La superficie de ataque en un procesador habilitado para SGX es la CPU y la aplicación. No hay ningún sistema operativo, firmware, hipervisor, otro hardware o BIOS en el que se deba confiar en un entorno SGX. El único software en el que se debe confiar es la propia aplicación. SGX proporciona un método para garantizar la carga confiable de esa aplicación de la misma manera que un inicio confiable normal, excepto que la cadena de confianza tiene solo 3 enlaces de longitud (Atestación de raíz, CPU, Aplicación) en lugar de las cadenas bastante largas en un sistema seguro tradicional. sistema de arranque.

Figura 3:Superficie de ataque en un entorno SGX

He estado experimentando con Intel SGX y DDS + Security. Mi objetivo es ejecutar una aplicación DDS en un área protegida de un Ubuntu 16.04 vanilla con SGX habilitado. La idea es que la comunic

[1] [2] 下一页