ArchiTecnologia

Aprendizaje abierto. Conocimiento libre.

ArchiTecnologia
Linux FoundationSeguridad

Confidential Computing: ¿qué es?

La seguridad informática ya era importante, pero en los últimos tiempos es simplemente imprescindible. Una parte esencial de los sistemas computacionales que jamás debe descuidarse en el hogar (especialmente con BYOD), y tampoco en las empresas, organizaciones y gobiernos. Algo en lo que la Confidential Computing puede ayudar, como podrás comprobar más adelante.

La información es poder, por tanto, no hay que dejar ese poder en manos de posibles enemigos (con intereses geopolíticos) y ciberdelincuentes. De lo contrario, éstos podrían acceder a información privada sensible, eliminarla, modificarla, e incluso usarla de forma maliciosa. En definitiva, no proteger un sistema suele desencadenar en consecuencias desastrosas para las empresas y organizaciones, derivando en pérdidas productivas, económicas, o de otra índole.

Importancia de los datos

seguridad datos

Puede que los datos que se manejan en algunos dispositivos domésticos no parezcan demasiado relevantes. Pero sí lo son en tanto y en cuanto pueden revelar mucho sobre ti y comprometer tu privacidad. Las filtraciones o ciberataques que comprometan los datos de ciertas empresas y organizaciones son aún más críticos que en el caso de un dispositivo doméstico.

Por tanto, en cualquier caso, los datos sí son importantes, y por ello deben protegerse frente a ciberamenazas. Si quieres algunos motivos para hacerlo, aquí tienes algunos:

  • El acceso por parte de certeros no autorizados a datos personales puede terminar en estafas, suplantación de identidad, robos en servicios bancarios, fugas de imágenes o datos comprometidos para la persona (a veces pueden terminar lastrando la vida laboral de esa persona, llevar al suicidio, etc.).
  • Para ciertas organizaciones puede significar pérdidas económicas muy elevadas, publicación de datos de clientes, propiedad intelectual, etc. Se estima que en 2018 se alcanzaron pérdidas empresariales por robo de datos de hasta 895.000€, subiendo hasta 910.000€ en 2019, y subiendo… (según un informe de Dell Technologies)
  • Las pérdidas pueden ir más allá de lo económico, y también afectar a la productividad o actividad de la organización. Por ejemplo, algunos estudios, como el de Global Data Protection Index 2020, estiman que el promedio de tiempo de inactividad no planificado en los sistemas que reciben ciberataques aumentó un 54% en un año, llegando a pérdidas por inactividad de 473.000€ en 2018 y de 727.000€ en 2019, y subiendo…
  • En sistemas críticos, como los de ciertas estaciones energéticas, hospitales, o instalaciones militares, podría significar problemas que pueden ir desde cortes en el suministro eléctrico, hasta la pérdida de vidas humanas.

En Europa no solo tenemos todos esos problemas sino que, además, la mayoría de los datos están bajo servicios que no cumplen con la GDPR, y que se encuentran fuera del territorio comunitario (véase GAFAM). Afortunadamente se están creando iniciativas como GAIA-X.

Pese a ello, aún se toma un poco a «broma» y multitud de empresas y usuarios siguen sin dar importancia a la ciberseguridad. Si eres de ellos, te sigo aportando algunos datos que deberían hacerte cambiar de idea:

  • Existen informes que aseguran que las amenazas cibernéticas siguen creciendo años tras año. Se estima que el 82% de las organizaciones sufrieron algún tipo de ciberataque. Tal vez la cifra sea muy superior a eso, pero aún no se han percatado de ello. Ningún sistema es seguro 100%, por tanto, la cuestión no es si vas a sufrir un ataque o no, sino cuándo.
  • A ese riesgo creciente se une que las organizaciones cada vez manejan mayor cantidad de datos sensibles. En 2018 se estimaba el volumen de datos en una media de 9,70PB de información, siendo en 2019 un 40% superior, es decir, una media de 13.53 PB.
  • Otro agravante proviene de la creciente cantidad de dispositivos conectados con la llegada del IoT. Ya no solo son una amenaza los PCs y servidores, también lo pueden ser otros muchos sistemas, como los vehículos, o un aparente juguete conectado…

En definitiva, cada vez se debería de prestar más atención a la seguridad, ya que cada vez vivimos en un entorno más hostil y con mayor cantidad de puertas de entrada…

¿Qué es la computación confidencial (Confidential Computing)?

Computación confidencial

La computación confidencial, o Confidential Computing, es una tecnología de computación en la nube que pretende aislar los datos confidenciales en un enclave de CPU protegida durante el procesamiento. Es decir, los datos procesados solo son accedidos por el código del programa autorizado, siendo invisibles o incognoscibles para cualquier otro proceso o persona, incluido para el proveedor del servicio cloud.

Cada vez más organizaciones y empresas dependen de los servicios de la nube pública e híbrida, por lo que la privacidad y seguridad de los datos en la nube debe ser imperativa. La confidential computing viene a resolver esto, brindando a los clientes de esta nube de mayor protección y confidencialidad.

Hasta ahora, lo que se ha venido haciendo es usar servicios de cifrado para proteger los datos en reposo (almacenados) o en tránsito (movidos a través de redes). Pero se olvidaban de los datos en uso, es decir, los que se encuentran en pleno proceso de ejecución. Algo que se aún más importante debido a toda la variedad de vulnerabilidades de la CPU encontradas (véase ataques de canal lateral o side-channel attack).

Hacer de la nube una plataforma más confiable

servidor, centro de datos - granja de servidores

El objetivo principal de la confidential computing es mejorar la confianza en los servicios de la nube. De esta forma, los proveedores podrán darles a sus clientes una plataforma con mayor protección de los datos (los que se almacenan, los que se transmiten, y los que se procesan).

Además de los sistemas de cifrado, que pueden servir tanto para los datos almacenados en los servicios de almacenamiento, como para los que se transmiten (mediante túneles cifrados como una VPN, pre-cifrados,), también se protegerán los datos usados en los procesos en ejecución que hasta ahora eran más sensibles a ciertos ataques durante el tiempo de ejecución.

Esto implica que los datos privados de clientes, la propiedad intelectual, ciertos valores que manejan las aplicaciones (contraseñas,…), etc., estarán ahora más protegidos en los centros de datos. Todo gracias al TEE (Trusted Execution Evironment), o entorno de ejecución confiable, es decir, un área segura de la CPU que garantiza que las instrucciones y los datos cargados desde la memoria estén protegidos en cuanto a confidencialidad e integridad.

El CCC también pretende aprovechar esta tecnología para otras mejoras más allá de la seguridad. Por ejemplo, para ahorrar ancho de banda y reducir las latencias. Eso se podría conseguir a una mejor optimización y colaboración entre los diseñadores de hardware y de software.

Con la iniciativa de la computación confidencial se necesita la implicación de los diseñadores de HW y los desarrolladores de SW. En la actualidad, la colaboración en algunos casos es casi nula, pero con este tipo de iniciativas se estrechan esos lazos…

¿Qué es TEE?

microprocesador

Ya existían métodos para aislar procesos y reservar espacios en memoria. Sin embargo, el concepto TEE (Trusted Execution Environment) viene a solventar algunas carencias. De esa forma se garantiza que las instrucciones y datos cargados en el interior de la CPU estén protegidos.

En estos sistemas hay un REE (Rich Execution Environment), y un espacio protegido especial llamado SE (Secure Element) donde hay un SO más restringido y seguro. Ambos ejecutándose sobre la CPU, en algunos casos, o sobre una CPU dedicada en otros. Por ejemplo, AMD usa su PSP, un procesador ARM independiente, mientras que ARM TrustZone lo hace en el mismo procesador en algunos casos (en otros existe un coprocesador dedicado)…

Fuente: Hardware-assisted Isolated Execution Environment to run trusted OS and applications on RISC-V (AIST) by Kuniyasu Suzaki and Akira Tsukamoto

De ese modo, los procesos normales se ejecutan en el primero, en ese Rich OS (un sistema operativo rico, con más funcionalidad, como podría ser GNU/Linux, Android,…). Mientras que algunos procesos más sensibles, como los referentes a la autenticación, DRM, servicios financieros, etc., se pueden ejecutar en ese entorno seguro, bajo el Trusted OS (TOS), para evitar que sean susceptibles a ciertos ataques.

Ese TOS es un sistema operativo suficiente para dar soporte para la seguridad multinivel para cumplir con una serie de requisitos. En la actualidad existen varios sistemas operativos certificados para ser TOS, como por ejemplo:

  • HP-UX
  • GNU/Linux (algunas distros clasificadas como EAL 4+, como RHEL, SLES, Oracle Linux,…). El kernel también tiene un subsistema TEE. Más información.
  • Trusted Solaris
  • AIX
  • FreeBSD con extensiones TrustedBSD.
  • Ultrix
  • etc.

EAL (Evaluation Assurance Level) es la calificación asignada a un sistema tras ser evaluado en función de unos Criterios Comunes de seguridad (unos estándares internacionales establecidos en 1999).

Aunque estos están marcados como tales, las plataformas suelen tener sistemas embebidos bastante básicos. De hecho, está bastante limitados, por eso su propósito no es reemplazar al SO principal (con millones de líneas de código), sino asegurar ciertos recursos con un pequeño impacto en el rendimiento. Existen algunos como T6, Trust-E,

Por ejemplo, podrías encontrarte con una plataforma ARMv8 con TrustZone con un sistema embebido Trusted OS (EL3), el hipervisor (EL2) y un sistema Linux principal (EL1).

Además, suelen ser sistemas propietarios, o basados en SSOO de código abierto en algunos casos. De ser de código abierto, suelen tener licencias permisivas, ya que así se pueden cerrar al antojo del fabricante, haciéndolos más opacos (un arma de doble filo). Por ejemplo, aunque Intel ME no es uno de estos sistemas de los que trata este artículo, sí que se ha conocido que usa Minix como sistema, ya que la licencia BSD permite cerrar el código si se quiere, algo que no permitiría la GPL.

El TEE tomará al REE como potencialmente malicioso. No quiere decir que lo sea, pero así se evitará la divulgación de ciertos datos del TEE al REE. Es similar a la arquitectura de un castillo, donde se usan murallas o anillos. Cada uno de esos anillos de protección se construyeron asumiendo que los muros exteriores fueron vulnerados.

Dicho de otro modo, REE proporciona una capa externa de protección, como la muralla o foso de un castillo medieval. Dispone de mecanismos de seguridad como la separación de procesos, mecanismos IPC bien diseñados, permisos y similares. Luego está TEE, que se aísla y proporciona sus propias defensas adicionales. TEE no confía en REE del mismo modo que los diseñadores de las defensas del castillo asumieron que las defensas externas podrían penetrarse. Se asume siempre que un atacante ha penetrado REE (el peor de los casos).

Como puedes comprobar en los diagramas, además de modo usuario y el modo kernel o privilegiado, también hay un nivel extra de seguridad en el que se encuentra esa zona segura para los procesos confidenciales. Solo esos procesos tendrían acceso a todas las funciones del procesador, espacio de memoria (memoria principal y periféricos del E/S). Además, estarán protegidas entre sí mediante cifrado.

Las claves privadas (endorsement keys o provisioned secrets) usadas para estos sistemas se insertan directamente en el chip durante la fabricación (p.e.: memorias programables como eFuses) del mismo para evitar otro tipo de suspicacias. No se podrán manipular y sus contrapartes públicas residen en la base de datos del fabricante, junto con un hash para esta clave para firmarlo. [véase cifrado asimétrico]

El hardware actuará de tal forma que todo aquel código no firmado por la clave pública que se pretenda ejecutar, no pueda acceder a las funciones privilegiadas. La clave pública se proporciona en tiempo de ejecución con el hash, dicho hash se compara luego con el incrustado en el chip para ver si realmente coincide o no.

¿Podría vulnerarse? Ciertamente se podría, pero es más complicado. Se podría simular hardware de manera que permita una autenticación, pero para eso, el atacante tendría que extraer las claves del hardware. Eso implica tener unos conocimientos de ingeniería inversa avanzados y equipamiento muy costoso (microscopios electrónicos de barrido, microsondas, material para desencapsular el chip, instrumentación FIB, etc.). Pero algunos diseños podrían incluso destruirse por esas técnicas de ingeniería inversa, por lo que incluso extrayendo las claves no se podrían usar en otro dispositivo…

Ahora bien, solo los fabricantes de los chips pueden tener acceso y control sobre esos certificados y algoritmos, otorgando acceso también a los desarrolladores de software con los que tienen acuerdos comerciales con el fabricante. La pregunta es… ¿son éstos de fiar (especialmente teniendo en cuenta que suelen ser fabricantes extra-europeos)? ¿Pueden tener vulnerabilidades?

Y lo más importante ¿pueden terminar generando más problemas de los que resuelven? ¿en PCs pueden ser una excusa para impedir a los usuarios modificar o restringir ciertas acciones? ¿una forma de obligar a usar solo sistemas firmados?

TEE vs TPM vs SE

Una vez explicado todo esto, decir que no esto no es algo realmente nuevo que se vaya a hacer, sino que ya se está haciendo desde hace algunos años. La primera en definir un sistema bajo este concepto fue la OMTP (Open Mobile Terminal Platform), aunque la primera solución comercial fue TrustZone, una tecnología de ARM.

Además, existen otras muchas implementaciones de TEEs, como por ejemplo:

  • Microprocesadores con AMD PSP (Platform Security Processor), AMD Secure Encrypted Virtualization, y AMD Secure Nested Paging Extension.
  • Microprocesadores con tecnología ARM TRustZone.
  • IBM Secure Service Container y Secure Execution para sus IBM z/Architecture modernos (mainframes con LinuxONE y chips z13, z15,…).
  • Tecnologías Intel TXT (Trusted Execution Technology), SGX (Software Guard Extensions), y Silent Lake para los Atom.
  • RISC-V MultiZone Security Trusted Execution Environment, Keystone Customizable TEE Framework, y Penglai Scalable TEE.

Sobre si son realmente seguros, seguramente sepas que SGX y TXT de Intel tienen algunas vulnerabilidades (puedes buscar en las bases de datos los códigos CVE correspondientes). Sin ir más lejos, Foreshadow es una de ellas… Tampoco escapa a estas vulnerabilidades el sistema Arm TrustZone. Por tanto, existen algunos vectores de ataque para los TEE como se ha venido demostrando, y todo debido a fallas de seguridad de las que obtener exploits para atacarlos…

TPM
TPM

Aunque se puedan englobar como sistemas similares, me gustaría dejar claro la diferencia entre SE, TEE y TPM, que son términos que han aparecido a lo largo del texto. A veces se pueden confundir o tomar como sinónimo, pero hay diferencias:

  • TPM (Trusted Platform Module): básicamente es una pieza de hardware multiplataforma creada específicamente para realizar cálculos de cifrado, DRM, mailing seguro, navegación SSL/TLS, túneles, etc. Es decir, un criptoprocesador seguro (cada uno tiene un número ID único) que está físicamente aislada del resto del sistema de procesamiento y, a menudo, es un chip pasivo (solo el usuario puede elegir activarlo) separado. Además, permite también almacenar claves de cifrado para proteger los datos, y presentar robustez ante ataques lógicos y físicos contra las claves. Trusted Computing Group (TCG) es la encargada de publicar las especificaciones, como la versión TMP 2.0. Además, estas especificaciones también están disponibles como estándar internacional (ISO/IEC). En cuanto a las partes involucradas en el TPM:
    • Memoria volátil y no volátil. La segunda es resistente a modificaciones y permite almacenar claves no migrables (e.j.: EK y SRK). En la primera se pueden almacenar de forma segura las mediciones de integridad.
      • Clave RSA Storage Root Key (SRK): está en lo alto de la jerarquía, la parte confiable del RTS, una clave no migrable (no sale del dispositivo) y que protege a otras claves de cifrado que se almacenan fuera del TPM.
      • Clave RSA Endorsement Key (EK): parte RTR. También es una clave no volátil y no migrable que será única y distinta en cada TPM (creada por el fabricante). Gracias a ella se puede verificar que el TPM es genuino.
      • Clave RSA Attestation Identity Key (AIK): esta clave se usa para firmar un valor de medición de integridad para una prueba de atestación. Es similar a la EK, solo que para esto no se emplea la EK para preservar la privacidad. Además, a diferencia de la EK, el TPM podría tener un número ilimitado de AIKs y no se crean por el fabricante, sino por el propietario del TPM.
    • Generador de números aleatorios.
    • Algoritmos de generación de claves de cifrado.
    • Funciones de cifrado y descifrado RSA, hash…
    • Otras funciones para que la plataforma sea confiable, como monitorización y auditado de la integridad para verificar la seguridad, sellado de datos, etc.
  • TEE: es el área en la que me he centrado en explicaciones previas, es decir, una parte del sistema que funciona como un TPM, pero que no tiene que estar aislada del resto del chip.
  • SE (Secure Element): es un almacenamiento seguro resistente a la manipulación. Su propósito principal es almacenar claves secretas para el cifrado. Un TPM y TEE necesitan de un SE, junto con otras piezas que componen el puzle completo, como el firmware, TOS, etc.

Confidential Compute Architecture

Arm también presentó una nueva arquitectura basada en TrustZone para el aislamiento y mejora de la seguridad. Se denomina CCA (Confidential Compute Architecture) y gracias a ella los datos de las aplicaciones estarán protegidos mientras están en uso. Esto previene que se puedan acceder a ellos incluso desde código privilegiado, como el kernel del sistema operativo o con un hipervisor.

En principio, esta arquitectura será opcional en la ISA Armv9.2, aunque probablemente se transforme en una extensión por defecto para futuras especificaciones.

Los desarrolladores de software podrán comprobar la compatibilidad de los programas con CCA si la función Realm Management Extension (RME) de la CPU está presente.

Realms

Anteriormente solo los proveedores de silicio y OEM podían acceder a un entorno de alta confianza a través de elementos como TrustZone. Con CCA, estos entornos estarán al alcance de todos los desarrolladores. Aunque en un principio esto se implementará en el propio sistema operativo, Arm pretende que en un futuro Realms se extienda al software convencional (PC, servidores, IoT, dispositivos móviles,…).

Realms (reinos) es el corazón de esta arquitectura CCA. Son entornos o enclaves pequeños e individuales, diseñados para evitar el acceso a datos privados en toda la pila directamente desde el hardware. Así, las cargas de trabajo quedarán aisladas unas de otras, permitiendo que se ejecuten en este «mundo» seguro.

En cuanto a la cantidad de reinos que un sistema operativo puede soportar, no hay un límite. El único techo será la cantidad de recursos que existan disponibles en la computadora. Además, la creación y destrucción de los reinos es una tarea muy liviana, para consumir los mínimos recursos posibles.

RME

RME (Realms Management Extension) es la función que tendrán los procesadores que admitan CCA. La CPU que admita RME dispondrán de dos nuevas capacidades de hardware:

  • Gestión de dominios: es la capacidad para crear y destruir enclaves seguros, es decir, los reinos.
  • Asignación de memoria dinámica: los sistemas con TrustZone se dividen en un mundo no seguro (o normal) y un mundo seguro. Por tanto, el mapeo de memoria está también dividido. El problema es que el monitor del sistema debía asignar memoria al mundo seguro durante el arranque , y esos e hacía con una granularidad limitada. Eso imponía algunas restricciones sobre el tipo y tamaño de los recursos asignables a este mundo seguro. Pero con la nueva RME, las páginas ahora pueden pasar del mundo no seguro al mundo seguro y viceversa. Eso permite que TrustZone se utilice para aplicaciones que consumen más memoria.

Otro detalle interesante es que en la ISA Armv8.4-SecEL2 existen dos mundos: seguro y no seguro (normal). Cada uno asociado con su propio estado de seguridad y un espacio de direcciones físicas. El mundo seguro está protegido del mundo normal en el nivel de excepción 2 y superior. Cualquier intento de acceder al espacio de direcciones del mundo seguro desde el normal genera una excepción de hardware y se detiene la ejecución. Sin embargo, el software del mundo seguro puede acceder a la memoria segura y a la normal.

En cambio, con el nuevo RME, se han agregado dos nuevos estados de seguridad: Root y Realm. También se han agregado dos nuevo espacios de direcciones físicas con el mismo nombre que los nuevos estados. Root está destinado para el nivel más bajo de la pila de hardware, el Monitor. Este espacio estará protegido de todos los demás espacios direccionables, incluso del mundo seguro.

RMM y RMI

Como parte de CCA también se define una nueva arquitectura de firmware/software. Se define un nuevo Realm Management Monitor (RMM) que se encargará de los servicios para el hipervisor y de los propios dominios. Y eso se hará a través de una interfaz de administración de reinos o RMI.

Los servicios para el hipervisor incluyen la creación y destrucción de dominios, así como la adición o eliminación de memoria. Los reinos también podrán solicitar informes de atestación a través de la RMI.

Sobre Confidential Computing Consortium (CCC)

Confidential Computing Consortium logo

Recientemente, IBM y AMD han anunciado un gran acuerdo para el desarrollo de una plataforma avanzada de Confidential Computing. Pero no son los únicos detrás de esta iniciativa. Se ha creado un consorcio llamado Confidential Computing Consortium, bajo el paraguas de la Linux Foundation, y cuyo objetivo es definir los estándares para esta tecnología, apoyar su desarrollo, y promover la adopción de herramientas de código abierto.

El Confidential Computing Consortium está apoyado por empresas como Red Hat, Accenture, AMD, Arm, Google, IBM, Oracle, VMWare, Alibaba, Facebook, Huawei, Intel, NVIDIA, IoTeX, Microsoft, etc. Como ves, son empresas que se encargan del hardware para los centros de datos, o que son proveedores de servicios cloud…

Actualmente, la comunidad ya cuenta con varios proyectos surgidos desde la transparencia y la colaboración, y con licencias de código abierto. Todos ellos enfocados en proteger los datos y acelerar la adopción de la computación confidencial.

Isaac

Apasionado de la computación y la tecnología en general. Siempre intentando desaprender para apreHender.

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Si continuas utilizando este sitio aceptas el uso de cookies. más información

Los ajustes de cookies de esta web están configurados para "permitir cookies" y así ofrecerte la mejor experiencia de navegación posible. Si sigues utilizando esta web sin cambiar tus ajustes de cookies o haces clic en "Aceptar" estarás dando tu consentimiento a esto.

Cerrar