Este contenido se actualizó por última vez en octubre de 2023 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. Estos controles, compilados sobre un proceso de inicio medido, ayudan a garantizar que Google pueda recuperar sus máquinas de centros de datos de vulnerabilidades en toda su pila de inicio y mostrarlas a partir de estados de inicio a configuraciones buenas conocidas.
Introducción
La postura de seguridad de una máquina de centro de datos se establece 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, al mismo tiempo 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 de la industria para aplicar el estado de inicio que esperamos y ayudar a mantener los datos del cliente seguros. Estos controles ayudan a garantizar que nuestras máquinas se inicien en su 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 muestra cómo operan nuestros controles en cada paso del flujo de inicio.
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 una autenticación mutua cuando establecen canales seguros. Para realizar una autenticación mutua, cada máquina posee las claves públicas de CA de Google. Además, cada máquina posee su propio par de claves públicas/privadas, así como un certificado para ese par de claves.
El par de claves públicas/privadas de cada máquina, junto con el certificado firmado por la CA, se conoce como una 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 CA públicas de otras máquinas estén certificadas por la CA de Google antes de intercambiar tráfico.
Raíz de confianza del hardware y sellado criptográfico
A medida que los dispositivos de computación 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 cuentan con raíces de hardware personalizadas y diseñadas por Google que están 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.
La serialización criptográfica es similar al sellado con una Módulo de plataforma segura (TPM), una especificación que publicó el Grupo de computación de confianza, pero la unión criptográfica tiene algunas ventajas adicionales. Titan ofrece una mejor capacidad para medir y certificar un firmware de bajo nivel.
El sellado criptográfico consta de los dos controles siguientes:
- Encriptación de datos sensibles
- Una política que se debe cumplir antes de que los datos se puedan desencriptar
Credenciales selladas
La infraestructura de credenciales de Google usa sellos criptográficos para encriptar las credenciales en reposo de una máquina con una clave controlada por la raíz de confianza de hardware de la máquina. La clave privada de la credencial encriptada y el certificado correspondiente se conocen como una credencial cerrada. Además de las credenciales de la máquina, Google usa este mecanismo de sellado para proteger otros datos sensibles.
Cada máquina puede desencriptar y acceder a su credencial de máquina solo si puede satisfacer 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 a una política que especifique la versión deseada del kernel del sistema operativo garantiza que la máquina no pueda participar en su clúster de máquina, a menos que haya iniciado la versión de kernel requerida.
La política de desencriptación se aplica a través de un proceso llamado inicio medido. Cada capa de la pila de inicio mide la siguiente capa, y la máquina certifica esta cadena de mediciones al final del inicio. Esta medición suele ser un hash criptográfico.
Proceso de unión de credenciales
En esta sección, se describe el sello 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 en una política de arranque en particular, ocurren los siguientes pasos:
- La infraestructura de automatización de Google inicia una actualización de software en la máquina. Pasa las versiones de software a la infraestructura de credenciales.
- La infraestructura de credenciales de Google solicita una clave de sello de Titan, vinculada a la política, de modo que Titan solo la usa si la máquina se inicia en su software previsto.
- La infraestructura de credenciales compara la política de la clave que se muestra con el intent que comunica la infraestructura de automatización de máquinas. Si la infraestructura de credenciales cumple con que la política coincide con el intent, emite una credencial de máquina certificada para la máquina.
- La infraestructura de credenciales encripta esta credencial mediante la clave de sello que se obtiene en el paso 2.
- Las credenciales encriptadas se almacenan en el disco para la desencriptación de Titan en los inicios posteriores.
Proceso del inicio medido
La pila de arranque 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 Es el nivel de software más bajo que proporciona una abstracción sobre las funciones de hardware, como las herramientas de redes, el sistema de archivos o la memoria virtual en el espacio de usuario.
- Firmware de arranque: El firmware que inicializa el kernel, como un BIOS y un bootloader.
- Raíz de confianza del hardware: En las máquinas de Google, un chip Titan mide de manera criptográfica el firmware y otros servicios de CPU de bajo nivel.
Durante el inicio, cada capa mide la siguiente capa 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 mediciones que se capturan durante el inicio cumplen con la política de desencriptación de las credenciales selladas, como lo especifica la infraestructura de credenciales de Google. Por lo tanto, si la máquina puede realizar operaciones con sus credenciales cerradas, es evidencia de que la máquina cumplió con su política de inicio medida. 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 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 A de kernel, pero los investigadores de seguridad descubren que esta versión de kernel tiene una vulnerabilidad. En estos casos, Google aplica un parche a la vulnerabilidad y lanza una versión B de kernel actualizada a la flota.
Además de aplicar un parche a la vulnerabilidad, Google también emite credenciales nuevas de máquina a cada máquina de la flota. Como se describe en Proceso de sello de credencial, las credenciales de máquina nuevas están vinculadas a una política de desencriptación que solo se cumple si la versión B de kernel se inicia en la máquina. Cualquier máquina que no ejecute el kernel previsto no puede desencriptar sus credenciales nuevas, ya que las mediciones de firmware de arranque 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 la máquina anterior.
Como resultado, estas máquinas no pueden participar en el clúster de máquina hasta que el 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 vulnerable A no puedan recibir trabajos o datos del usuario hasta que se actualicen a la versión de kernel B.
Recuperación ante vulnerabilidades en el firmware de inicio
Supongamos que existe una vulnerabilidad en el firmware de inicio, en lugar del kernel del sistema operativo. Los mismos controles descritos en Recuperación de vulnerabilidades en el kernel ayudan a Google a recuperarse de una vulnerabilidad de este tipo.
El chip Titan de Google mide el firmware de arranque de una máquina antes de que se ejecute, de modo que pueda determinar si el firmware de arranque cumple con la política de inicio de la credencial de la máquina. Cualquier máquina que no ejecute su firmware de inicio previsto no puede obtener credenciales de máquina nuevas y no puede participar en el clúster de máquina hasta que el 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 arranque de Titan implementa un flujo de inicio seguro y medido por su cuenta. Cuando se enciende un chip Titan, su hardware mide de forma criptográfica el bootloader del Titan, que, a su vez, mide el firmware de Titan. De manera similar al firmware de kernel y de arranque de la máquina, el firmware 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, lo que alimenta el número de versión 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 clave con versión, en el que el firmware Titan con versión X puede obtener claves únicas de chip vinculadas a todas las versiones menores o iguales a X. El hardware Titan permite el firmware con la versión X para acceder a las claves que están vinculadas a versiones inferiores o iguales a X, pero que no son mayores que X. Todos los secretos sellados en Titan, incluida la credencial de máquina, se encriptan con una clave con versión.
Las claves de certificación y sello son únicas para cada chip Titan. Las claves únicas permiten que Google solo confíe 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 claves de versión. No se puede acceder a la clave Versión X+1 con el firmware de la versión X, pero a todas las claves anteriores a esa se puede acceder.
En el caso de una vulnerabilidad grave en el firmware 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 de firmware Titan superior. Cualquier firmware 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 ejecuta el firmware Titan actualizado.
Garantiza la raíz de la autenticidad de confianza
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 entropía única. La rutina de arranque de bajo nivel de Titan convierte esa entropía en una clave única para el dispositivo. Un elemento seguro en la línea de fabricación 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, mediante un flujo similar al Device Identifier Composition Engine (DICE). La recomendación incluye información sobre la versión de firmware Titan. Esta certificación ayuda a evitar que un atacante robe la identidad de una firma emitida por un chip Titan y a revertir el firmware Titan anterior y a suplantar el firmware Titan más reciente. Estos controles ayudan a Google a verificar que las firmas recibidas de Titan sean emitidas por un hardware Titan auténtico que ejecuta el firmware Titan auténtico.
Compila según la integridad de inicio
En este documento, se describen 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 de hardware.
El modelo de amenaza de Google incluye atacantes que pueden interponer físicamente en el bus entre la CPU y el RoT, con el objetivo de obtener de manera 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 sobre cómo Google ayuda a garantizar la integridad de las pilas de arranque complejas desagregadas, consulta Certificación remota de las máquinas separadas.
- Para obtener información general sobre la infraestructura de seguridad de Google, consulta la Descripción general del diseño de seguridad de la infraestructura de Google.
- Para obtener más información sobre cómo Google contribuyen las 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 de Trusted Computing Group.
- Para obtener más informes de seguridad, consulta Informes de seguridad.
Autores: Jeff Andersen, Kevin Plybon