Este contenido se actualizó por última vez en mayo de 2024 y representa el statu quo en el momento de su redacción. Es posible que cambien las políticas y los sistemas de seguridad de Google de ahora en adelante, ya que mejoramos la protección de nuestros clientes de forma continua.
En este documento, se describen los controles de infraestructura que Google usa para aplicar la integridad del proceso de inicio en máquinas de producción equipadas con Titan. Estos controles, compilados a partir de un proceso de inicio medido, ayudan a garantizar que Google pueda recuperar sus máquinas de centros de datos de las vulnerabilidades en toda su pila de inicio y mostrar las máquinas desde estados de inicio arbitrarios a configuraciones buenas conocidas.
Introducción
La postura de seguridad de una máquina de centro de datos depende en gran medida de la configuración de la máquina en el momento del inicio. El proceso de inicio de la máquina configura el hardware de la máquina y, luego, inicializa su sistema operativo, a la vez que mantiene la máquina segura para ejecutarse en el entorno de producción de Google.
En cada paso del proceso de inicio, Google implementa controles líderes en la industria para ayudar a aplicar el estado de inicio que esperamos y para mantener seguros los datos del cliente. Estos controles ayudan a garantizar que nuestras máquinas se inicien en el software previsto, lo que nos permite quitar las vulnerabilidades que podrían comprometer la postura de seguridad inicial de la máquina.
En este documento, se describe el proceso de inicio y se demuestra cómo funcionan nuestros controles durante el flujo de inicio. Los objetivos clave de nuestros controles son los siguientes:
- Establece confianza en las credenciales de máquina a través de la raíz de confianza del hardware
- Sella las credenciales de máquina en una política de inicio que especifique las versiones de software y firmware permitidas.
- Aplica la política de inicio en las máquinas a través de un proceso de inicio medido
Formación
En esta sección, se define y proporciona contexto para los términos credenciales de máquinas, raíz de confianza de hardware, credenciales selladas y sellado criptográfico.
Credenciales de máquina
Uno de los componentes centrales del sistema de administración de máquinas de Google es nuestra infraestructura de credenciales, que consta de una autoridad certificadora (CA) interna y otros elementos del plano de control responsables de coordinar los flujos de rotación de credenciales.
Las máquinas de la flota de producción de Google realizan la autenticación mutua cuando se establecen canales seguros. Para realizar una autenticación mutua, cada máquina posee las claves públicas de la CA de Google. Cada máquina también posee su propio par de claves públicas/privadas, además de un certificado para ese par de claves.
El par de claves públicas/privadas de cada máquina, junto con el certificado que firma la CA, se conoce como credencial de máquina, que la máquina usa para autenticarse en otras máquinas de la flota. Dentro de la red de producción, las máquinas verifican que las claves públicas de otras máquinas estén certificadas por la CA de Google antes de intercambiar tráfico.
Raíces de confianza de hardware y sellado criptográfico
A medida que los dispositivos informáticos se vuelven más sofisticados, la superficie de ataque de cada dispositivo también crece. Para tener en cuenta esto, los dispositivos incluyen cada vez más raíz de confianza (RoTs) de hardware, que son entornos de ejecución pequeños y confiables que protegen los datos sensibles para la máquina. Los RoTs también aparecen en dispositivos móviles, como laptops o teléfonos celulares, y en dispositivos más convencionales, como computadoras de escritorio.
Las máquinas de centros de datos de Google tienen raíces de confianza de hardware personalizadas y diseñadas por Google integradas en las capas más profundas de cada máquina, conocidas como Titan. Usamos Titan, junto con un mecanismo llamado sellado criptográfico para garantizar que cada máquina ejecute la configuración y las versiones de software que esperamos.
El sellado criptográfico es un servicio que ofrece Titan y que se usa para proteger los objetos Secret. Las capacidades de sellado de Titan son similares a las que se encuentran en la especificación del módulo de plataforma de confianza (TPM), que publica el Trusted Computing Group. El sellado criptográfico de Titan tiene una ventaja adicional, ya que ofrece una mejor capacidad para medir y certificar el firmware de bajo nivel.
El sellado criptográfico consta de los siguientes dos controles:
- Encriptación de datos sensibles
- Una política que se debe cumplir antes de que se puedan desencriptar los datos
Credenciales selladas
La infraestructura de credenciales de Google usa el sellado criptográfico para encriptar las credenciales de máquina en reposo con una clave que controla la raíz de confianza del hardware de la máquina. La clave privada de la credencial encriptada y el certificado correspondiente se conocen como credencial sellada. Además de las credenciales de máquina, Google usa este mecanismo de sellado para proteger otros datos sensibles.
Cada máquina puede desencriptar su credencial de máquina y acceder a ella solo si puede cumplir con una política de desencriptación que especifique qué software debe haber iniciado la máquina. Por ejemplo, sellar la credencial de una máquina en una política que especifique la versión prevista del kernel del sistema operativo ayuda a garantizar que la máquina no pueda participar en su clúster de máquina, a menos que haya iniciado la versión de kernel deseada.
La política de desencriptación se aplica a través de un proceso llamado inicio medido. Cada capa en la pila de inicio mide la siguiente capa, y la máquina certifica esta cadena de medidas al final del inicio. Esta medida suele ser un hash criptográfico.
Proceso de sellado de credenciales
En esta sección, se describe el sellado de credenciales y el proceso de inicio medido que usan las máquinas de Google. En el diagrama siguiente, se ilustra este flujo:
Para sellar las credenciales de una máquina a una política de inicio en particular, se producen los siguientes pasos:
- La infraestructura de automatización de máquinas de Google inicia una actualización de software en la máquina. Pasa las versiones de software previstas a la infraestructura de credenciales.
- La infraestructura de credenciales de Google solicita una clave de sellado de Titan, de modo que Titan solo la use si la máquina se inicia en el software deseado.
- La infraestructura de credenciales compara la política de la clave que se muestra con el intent que le comunica la infraestructura de automatización de máquinas. Si se cumple la infraestructura de credenciales para que la política coincida con el intent, se emitirá una credencial de máquina certificada para la máquina.
- La infraestructura de credenciales encripta esta credencial con la clave de sellado que se adquiere en el paso 2.
- La credencial encriptada se almacena en el disco para la desencriptación de Titan en los inicios posteriores.
Proceso del inicio medido
La pila de inicio de las máquinas de Google consta de cuatro capas, que se visualizan en el siguiente diagrama.
Las capas son las siguientes:
- Espacio de usuario: aplicaciones como daemons o cargas de trabajo.
- Software del sistema: un hipervisor o kernel. El nivel más bajo de software que proporciona una abstracción de las características de hardware, como las herramientas de redes, el sistema de archivos o la memoria virtual al espacio del usuario.
- Firmware de inicio: el firmware que inicializa el kernel, como un BIOS y bootloader.
- Raíz de confianza del hardware: en las máquinas de Google, un chip Titan que mide de forma criptográfica el firmware y otros servicios de CPU de bajo nivel.
Durante el inicio, cada capa mide la capa siguiente antes de pasar el control a esa capa. La credencial sellada de la máquina solo está disponible para el sistema operativo si todas las medidas que se capturan durante el inicio cumplen con la política de desencriptación de la credencial sellada, como lo especifica la infraestructura de credenciales de Google. Por lo tanto, si la máquina puede realizar operaciones con sus credenciales selladas, significa que la máquina cumplió con su política de inicio medido. Este proceso es una forma de certificación implícita.
Si una máquina inicia un software que se desvía del estado previsto, la máquina no puede desencriptar ni realizar operaciones con las credenciales que necesita para operar dentro de la flota. Estas máquinas no pueden participar en la programación de cargas de trabajo hasta que la infraestructura de administración de máquinas active acciones de reparación automatizadas.
Recupérate de las vulnerabilidades en el kernel
Supongamos que una máquina ejecuta la versión de kernel A, pero los investigadores de seguridad descubren que esta versión del kernel tiene una vulnerabilidad. En estas situaciones, Google aplica un parche a la vulnerabilidad y lanza una versión de kernel B actualizada para la flota.
Además de aplicar un parche a la vulnerabilidad, Google también emite credenciales de máquina nuevas a cada máquina de la flota. Como se describe en Proceso de sellado de credenciales, las credenciales de máquina nuevas están vinculadas a una política de desencriptación que solo se cumple si la versión de kernel B se inicia en la máquina. Cualquier máquina que no ejecute el kernel previsto no podrá desencriptar sus credenciales de máquina nuevas, ya que las mediciones del firmware de inicio no cumplirán con la política de inicio de la máquina. Como parte de este proceso, también se revocan las credenciales de máquina antiguas.
Como resultado, estas máquinas no pueden participar en su clúster de máquina hasta que su kernel se actualice para cumplir con el intent del plano de control. Estos controles ayudan a garantizar que las máquinas que ejecutan la versión de kernel A vulnerable no puedan recibir trabajos ni datos del usuario hasta que se actualicen a la versión de kernel B.
Recupérate de las vulnerabilidades en el firmware de inicio
Supongamos que hay una vulnerabilidad en el firmware de inicio, en lugar del kernel del sistema operativo. Los mismos controles descritos en Recupérate de las vulnerabilidades en el kernel ayudan a Google a recuperarse de esa vulnerabilidad.
El chip Titan de Google mide el firmware de inicio de una máquina antes de que se ejecute, de modo que Titan pueda determinar si el firmware de inicio cumple con la política de inicio de la credencial de máquina. Cualquier máquina que no ejecute el firmware de inicio previsto no puede obtener credenciales de máquina nuevas, y esa máquina no podrá participar en el clúster de la máquina hasta que su firmware de inicio se ajuste al intent del plano de control.
Recupérate de las vulnerabilidades en el firmware de raíz de confianza
Los RoTs no son inmunes a las vulnerabilidades, pero los controles de inicio de Google permiten la recuperación ante errores, incluso en esta capa de la pila de arranque, dentro del propio código mutable de RoT.
La pila de inicio de Titan implementa su propio flujo de inicio seguro y medido. Cuando se enciende un chip Titan, su hardware mide de forma criptográfica el bootloader de Titan, que, a su vez, mide el firmware de Titan. De manera similar al kernel y al firmware de inicio de la máquina, el firmware de Titan está firmado de manera criptográfica con un número de versión. El bootloader de Titan valida la firma y extrae el número de versión del firmware de Titan, y lo envía al subsistema de derivación de claves basado en hardware de Titan.
El subsistema de hardware de Titan implementa un esquema de derivación de claves con versiones, en el que el firmware de Titan con la versión X puede obtener claves únicas de chip vinculadas a todas las versiones menores o iguales a X. El hardware de Titan permite que el firmware con la versión X acceda a las claves vinculadas a las versiones menores o iguales que X, pero que no son superiores a X. Todos los Secret sellados en Titan, incluida la credencial de máquina, se encriptan con una clave con versión.
Las claves de certificación y sellado son únicas de cada chip Titan. Las claves únicas permiten que Google confíe solo en los chips Titan que se espera que se ejecuten dentro de un centro de datos de Google.
En el siguiente diagrama, se muestra Titan con las claves de versión. No se puede acceder a la clave de la versión X+1 a través del firmware de la versión X, pero se puede acceder a todas las claves anteriores.
En caso de una vulnerabilidad grave en el firmware de Titan, Google lanza un parche con un número de versión mayor y, luego, emite credenciales de máquina nuevas que están vinculadas a la versión más alta del firmware de Titan. El firmware de Titan más antiguo y vulnerable no puede desencriptar estas credenciales nuevas. Por lo tanto, si una máquina realiza operaciones con sus credenciales nuevas en producción, Google puede confirmar con confianza que el chip Titan de la máquina inició el firmware de Titan actualizado.
Garantiza la raíz de la autenticidad de confianza
Todos los controles que se describen en este documento se basan en la funcionalidad del RoT de hardware. La infraestructura de credenciales de Google se basa en las firmas emitidas por estos RoTs para saber si la máquina ejecuta el software previsto.
Por lo tanto, es fundamental que la infraestructura de credenciales pueda determinar si un RoT de hardware es auténtico y si el firmware está actualizado.
Cuando se fabrica cada chip Titan, se programa con una entropía única. La rutina de inicio de bajo nivel de Titan convierte esa entropía en una clave única de dispositivo. Un elemento seguro en la línea de fabricación de Titan respalda esta clave única de chip, de modo que Google la reconocerá como un chip Titan legítimo.
En el siguiente diagrama, se ilustra este proceso de recomendación.
Cuando está en producción, Titan usa su clave única de dispositivo para respaldar cualquier firma que emita. Los chips Titan usan un flujo similar a Device Identifier Composition Engine (DICE). La recomendación incluye la información de la versión del firmware de Titan. Esta certificación ayuda a evitar que un atacante suplante una firma emitida por un chip Titan y que se revierta al firmware de Titan anterior y suplante la identidad del firmware de Titan más nuevo. Estos controles ayudan a Google a verificar que las firmas recibidas de Titan se emitieron a través del hardware de Titan auténtico que ejecuta el firmware de Titan auténtico.
Compila en la integridad de inicio
En este informe, se describen los mecanismos para garantizar que los procesadores de aplicaciones de las máquinas inicien el código previsto. Estos mecanismos se basan en un flujo de inicio medido, junto con un chip de raíz de confianza del hardware.
El modelo de amenaza de Google incluye atacantes que pueden intervenir de forma física en el bus entre la CPU y el RoT, con el objetivo de obtener de forma inadecuada la credencial desencriptada de la máquina. Para ayudar a minimizar este riesgo, Google impulsa el desarrollo de un enfoque basado en estándares para superar los interoperadores activos y reunir las APIs de TPM y DPE del Trusted Computing Group y la raíz de confianza integrada Caliptra.
¿Qué sigue?
- Para obtener información acerca de cómo Google ayuda a garantizar la integridad de las pilas de inicio de máquinas desagregadas complejas, consulta Certificación remota de máquinas desagregadas.
- Para obtener información general sobre la infraestructura de seguridad de Google, consulta Descripción general del diseño de seguridad de la infraestructura de Google.
- Para obtener más información acerca de cómo Google contribuye con soluciones de seguridad Titan a los estándares de la industria, consulta la charla TPM Attested Boot in Big, Distributed Environments en el canal de YouTube del Trusted Computing Group.
Autores: Jeff Andersen y Kevin Plybon