Este contenido se actualizó por última vez en mayo del 2024 y representa la situación en el momento en que se redactó. Las políticas y los sistemas de seguridad de Google pueden cambiar en el futuro, ya que mejoramos constantemente la protección que proporcionamos a nuestros clientes.
En este documento se describen los controles de infraestructura que usa Google para aplicar la integridad del proceso de arranque en las máquinas de producción que están equipadas con Titan. Estos controles, basados en un proceso de arranque medido, ayudan a asegurar que Google pueda recuperar sus máquinas de centros de datos de vulnerabilidades en toda su pila de arranque y devolver las máquinas de estados de arranque arbitrarios a configuraciones correctas conocidas.
Introducción
La postura de seguridad de una máquina de un centro de datos depende en gran medida de la configuración de la máquina en el momento del arranque. El proceso de arranque de la máquina configura el hardware de la máquina e inicializa su sistema operativo, al tiempo que mantiene la seguridad de la máquina para que se ejecute en el entorno de producción de Google.
En cada paso del proceso de arranque, Google implementa controles líderes del sector para ayudar a aplicar el estado de arranque que esperamos y proteger los datos de los clientes. Estos controles ayudan a asegurar que nuestras máquinas se inicien con el software previsto, lo que nos permite eliminar las vulnerabilidades que podrían poner en peligro la postura de seguridad inicial de la máquina.
En este documento se describe el proceso de arranque y se muestra cómo funcionan nuestros controles durante el flujo de arranque. Los objetivos principales de nuestros controles son los siguientes:
- Generar confianza en las credenciales de las máquinas mediante raíces de confianza de hardware
- Sellar las credenciales de la máquina en una política de arranque que especifique las versiones de firmware y software permitidas
- Aplicar la política de arranque en las máquinas mediante un proceso de arranque medido
Fondo
En esta sección se definen los términos credenciales de máquina, raíz de confianza de hardware, credenciales selladas y sellado criptográfico, y se proporciona contexto para ellos.
Credenciales de la máquina
Uno de los componentes centrales del sistema de gestión de máquinas de Google es nuestra infraestructura de credenciales, que consta de una autoridad de certificación (CA) interna y otros elementos del plano de control que se encargan 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 al establecer canales seguros. Para realizar la autenticación mutua, cada máquina tiene las claves públicas de la CA de Google. Cada máquina también tiene su propio par de claves pública/privada, así como un certificado para ese par de claves.
El par de claves pública/privada de cada máquina, junto con el certificado firmado por la AC, se conoce como credencial de máquina, que la máquina usa para autenticarse en otras máquinas de la flota. En la red de producción, las máquinas comprueban 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 aumenta. Para tener esto en cuenta, los dispositivos incluyen cada vez más raíces de confianza (RoTs) de hardware, que son entornos de ejecución de confianza pequeños que protegen los datos sensibles de la máquina. Los RoTs también aparecen en dispositivos móviles, como portátiles o teléfonos móviles, y en dispositivos más convencionales, como ordenadores de escritorio.
Las máquinas de los centros de datos de Google incluyen 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 asegurarnos de 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 secretos. Las funciones de sellado de Titan son similares a las que se encuentran en la especificación del módulo de plataforma segura (TPM), que publica el Trusted Computing Group. El sellado criptográfico de Titan tiene una ventaja adicional, ya que Titan ofrece una mayor capacidad para medir y certificar el firmware de bajo nivel.
El cifrado criptográfico incluye los dos controles siguientes:
- Encriptación de datos sensibles
- Una política que debe cumplirse para que se puedan descifrar los datos
Credenciales selladas
La infraestructura de credenciales de Google usa el sellado criptográfico para cifrar las credenciales de la máquina en reposo con una clave controlada por la raíz de confianza de hardware de la máquina. La clave privada de la credencial cifrada y el certificado correspondiente se conocen como credencial sellada. Además de las credenciales de la máquina, Google usa este mecanismo de sellado para proteger otros datos sensibles.
Cada máquina puede descifrar y acceder a su credencial de máquina solo si puede cumplir una política de descifrado que especifique el software con el que debe haber arrancado la máquina. Por ejemplo, sellar la credencial de una máquina con una política que especifique la versión del kernel del sistema operativo que se va a lanzar ayuda a asegurar que la máquina no pueda participar en su clúster de máquinas a menos que haya arrancado la versión del kernel prevista.
La política de descifrado se aplica mediante un proceso llamado arranque medido. Cada capa de la pila de arranque mide la siguiente y la máquina certifica esta cadena de mediciones al final del arranque. Esta medición suele ser un hash criptográfico.
Proceso de sellado de credenciales
En esta sección se describe el proceso de sellado de credenciales y arranque medido que usan las máquinas de Google. En el siguiente diagrama se muestra este flujo.
Para cifrar las credenciales de un dispositivo con una política de arranque concreta, se siguen estos pasos:
- La infraestructura de automatización de máquinas de Google inicia una actualización de software en la máquina. Transfiere las versiones de software previstas a la infraestructura de credenciales.
- La infraestructura de credenciales de Google solicita una clave de sellado a Titan, que está vinculada a una política de forma que Titan solo la usa si la máquina se inicia con el software previsto.
- La infraestructura de credenciales compara la política de la clave devuelta con la intención que le ha comunicado la infraestructura de automatización de la máquina. Si la infraestructura de credenciales determina que la política coincide con la intención, emite una credencial de máquina certificada para la máquina.
- La infraestructura de credenciales cifra esta credencial con la clave de sellado que se obtiene en el paso 2.
- La credencial cifrada se almacena en el disco para que Titan la descifre en los arranques posteriores.
Proceso de arranque 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 un kernel. Es el nivel más bajo del software que proporciona una abstracción sobre las funciones de hardware, como las redes, el sistema de archivos o la memoria virtual, al espacio de usuario.
- Firmware de arranque: el firmware que inicializa el kernel, como un BIOS y un bootloader.
- Raíz de confianza de hardware: en las máquinas de Google, un chip Titan que mide criptográficamente el firmware y otros servicios de CPU de bajo nivel.
Durante el arranque, cada capa mide la siguiente antes de transferir el control a esa capa. La credencial sellada de la máquina solo se pone a disposición del sistema operativo si todas las mediciones que se capturan durante el inicio cumplen la política de descifrado de la credencial sellada, tal como se especifica en la infraestructura de credenciales de Google. Por lo tanto, si la máquina puede realizar operaciones con sus credenciales selladas, es una prueba de que la máquina ha cumplido su política de arranque 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 descifrar ni realizar operaciones con las credenciales que necesita para funcionar en la flota. Estas máquinas no pueden participar en la programación de cargas de trabajo hasta que la infraestructura de gestión de máquinas active las acciones de reparación automatizadas.
Recuperación tras vulnerabilidades en el kernel
Supongamos que una máquina ejecuta la versión A del kernel, pero los investigadores de seguridad descubren que esta versión tiene una vulnerabilidad. En estos casos, Google parchea la vulnerabilidad y lanza una versión B actualizada del kernel a la flota.
Además de parchear la vulnerabilidad, Google también emite nuevas credenciales de máquina para cada máquina de la flota. Como se describe en el proceso de sellado de credenciales, las nuevas credenciales de la máquina se vinculan a una política de descifrado que solo se cumple si la versión B del kernel se inicia en la máquina. Cualquier máquina que no ejecute el kernel previsto no podrá descifrar sus nuevas credenciales, ya que las mediciones del firmware de arranque no cumplirán la política de arranque de la máquina. Como parte de este proceso, también se revocan las credenciales de la máquina antigua.
Por lo tanto, estas máquinas no pueden participar en su clúster de máquinas hasta que se actualice su kernel para que se ajuste a la intención del plano de control. Estos controles ayudan a asegurar que las máquinas que ejecutan la versión vulnerable del kernel A no puedan recibir trabajos ni datos de usuario hasta que se actualicen a la versión B del kernel.
Recuperación tras vulnerabilidades en el firmware de arranque
Supongamos que hay una vulnerabilidad en el firmware de arranque, en lugar de en el kernel del sistema operativo. Los mismos controles que se describen en el artículo sobre recuperación tras 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 Titan puede determinar si el firmware de arranque cumple la política de arranque de la credencial de la máquina. Cualquier máquina que no ejecute el firmware de arranque previsto no podrá obtener nuevas credenciales de máquina y no podrá participar en su clúster de máquinas hasta que su firmware de arranque se ajuste a la intención del plano de control.
Recuperación tras vulnerabilidades en el firmware de la raíz de confianza
Los RoTs no son inmunes a las vulnerabilidades, pero los controles de arranque de Google permiten recuperarse de errores incluso en esta capa de la pila de arranque, dentro del propio código mutable del RoT.
La pila de arranque de Titan implementa su propio flujo de arranque seguro y medido. Cuando se enciende un chip Titan, su hardware mide criptográficamente el gestor de arranque de Titan, que a su vez mide el firmware de Titan. Al igual que el kernel y el firmware de arranque de la máquina, el firmware de Titan está firmado criptográficamente 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, que se 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 versionado, de forma que el firmware de Titan con la versión X puede obtener claves únicas del chip vinculadas a todas las versiones inferiores o iguales a X. El hardware de Titan permite que el firmware con la versión X acceda a las claves vinculadas a versiones inferiores o iguales a X, pero no superiores a X. Todos los secretos sellados en Titan, incluidas las credenciales de la máquina, se cifran con una clave versionada.
Las claves de certificación y sellado 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 en un centro de datos de Google.
En el siguiente diagrama se muestra Titan con claves de versión. El firmware de la versión X no puede acceder a la clave de la versión X+1, pero sí a todas las claves anteriores.
Si se detecta una vulnerabilidad grave en el firmware de Titan, Google lanza un parche con un número de versión superior y, a continuación, emite nuevas credenciales de máquina vinculadas a la versión superior del firmware de Titan. Las versiones anteriores y vulnerables del firmware de Titan no pueden descifrar estas nuevas credenciales. Por lo tanto, si una máquina realiza operaciones con sus nuevas credenciales en producción, Google puede afirmar con confianza que el chip Titan de la máquina ha arrancado con el firmware Titan actualizado.
Asegurar la autenticidad de la raíz de confianza
Los controles descritos en este documento se basan en la funcionalidad de la raíz de confianza de hardware. La infraestructura de credenciales de Google se basa en las firmas emitidas por estas RoTs para saber si la máquina está ejecutando el software previsto.
Por lo tanto, es fundamental que la infraestructura de credenciales pueda determinar si una raíz de confianza de hardware es auténtica y si la raíz de confianza ejecuta un firmware actualizado.
Cuando se fabrica cada chip Titan, se programa con una 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 de la línea de fabricación de Titan valida esta clave única del chip para que Google la reconozca como un chip Titan legítimo.
En el siguiente diagrama se ilustra este proceso de recomendación.
En producción, Titan usa su clave única de dispositivo para validar cualquier firma que emita. Los chips Titan usan un flujo similar al del motor de composición de identificadores de dispositivo (DICE). La certificación incluye información sobre 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 vuelva a una versión anterior del firmware de Titan y suplante una versión más reciente. Estos controles ayudan a Google a verificar que las firmas recibidas de Titan se han emitido desde hardware Titan auténtico que ejecuta firmware Titan auténtico.
Aprovechar la integridad del arranque
En este documento se describen los mecanismos para asegurar que los procesadores de aplicaciones de las máquinas arrancan el código previsto. Estos mecanismos se basan en un flujo de arranque medido, junto con un chip de raíz de confianza de hardware.
El modelo de amenazas de Google incluye atacantes que pueden interponerse físicamente en el bus entre la CPU y la raíz de confianza, con el objetivo de obtener de forma inadecuada la credencial descifrada de la máquina. Para minimizar este riesgo, Google está impulsando el desarrollo de un enfoque basado en estándares para derrotar a los interposers activos, que combina las APIs TPM y DPE de Trusted Computing Group con la raíz de confianza integrada Caliptra.
Siguientes pasos
- Para obtener información sobre cómo ayuda Google a garantizar la integridad de las pilas de arranque de máquinas complejas y desagregadas, consulta Atestación remota de máquinas desagregadas.
- Para obtener información general sobre la infraestructura de seguridad de Google, consulta el artículo Descripción general del diseño de seguridad de la infraestructura de Google.
- Para obtener más información sobre cómo contribuye Google con las soluciones de seguridad de Titan a los estándares del sector, consulta la charla Arranque certificado por TPM en entornos grandes y distribuidos en el canal de YouTube de Trusted Computing Group.