Seguridad de transporte de la capa de la aplicación

Por Cesar Ghali, Adam Stubblefield, Ed Knapp, Jiangtao Li, Benedikt Schmidt y Julien Boeuf

El contenido de este documento corresponde a diciembre de 2017. Este informe técnico representa el statu quo en el momento de su redacción. Es posible que los sistemas y las políticas de seguridad de Google Cloud cambien, ya que mejoramos la protección de nuestros clientes de forma continua.

Resumen para directores generales de información

  • La seguridad de transporte de la capa de la aplicación de Google (ALTS) es un sistema de autenticación mutua y de encriptación de transporte desarrollado por Google que, por lo general, se utiliza para proteger las comunicaciones de llamadas de procedimiento remoto (RPC) dentro de la infraestructura de Google. ALTS es similar en concepto a la TLS autenticada de forma mutua, pero se diseñó y optimizó para satisfacer las necesidades de los entornos de los centros de datos de Google.
  • El modelo de confianza de ALTS se adapta a aplicaciones en contenedores similares a la nube. Las identidades están vinculadas a entidades, y no a un host o nombre de servidor específico. Este modelo de confianza facilita la replicación de microservicios sin interrupciones, balanceo de cargas y reprogramación entre hosts.
  • ALTS se basa en dos protocolos: el protocolo de enlace (con reanudación de sesión) y el protocolo de registro. Estos protocolos rigen cómo se establecen, autentican, encriptan y reanudan las sesiones.
  • ALTS es una solución de seguridad de la capa de transporte personalizada que utilizamos en Google. Adaptamos ALTS a nuestro entorno de producción, por lo que existen algunas compensaciones entre ALTS y el estándar de la industria, TLS. Se pueden encontrar más detalles en la sección Compensaciones.

Introducción

Los sistemas de producción en Google consisten en una constelación de microservicios1 que emiten de forma colectiva O(1010) llamadas de procedimiento remoto (RPC) por segundo. Cuando un ingeniero de Google programa una carga de trabajo de producción2, cualquier RPC emitida o recibida por esa carga de trabajo está protegida con ALTS de forma predeterminada. La seguridad de transporte de la capa de la aplicación (ALTS) de Google proporciona esta protección automática sin configuración. Además de las protecciones automáticas conferidas a las RPC, ALTS también facilita la replicación del servicio, el balanceo de cargas y la reprogramación en las máquinas de producción. En este documento, se describe la ALTS y se explora su implementación en la infraestructura de producción de Google.

Público: este documento está dirigido a profesionales de seguridad de infraestructura que desean saber cómo se realizan la autenticación y la seguridad del transporte a gran escala en Google.

Requisitos: además de esta introducción, se debe tener un entendimiento básico acerca de la administración de clústeres en Google.

Seguridad de nivel de aplicación y ALTS

Muchas aplicaciones, desde navegadores web hasta VPN, dependen de protocolos de comunicación seguros, como IPSec y TLS (seguridad de la capa de transporte), para proteger los datos en tránsito3. En Google, utilizamos ALTS, un sistema de encriptación de transporte y autenticación mutua que se ejecuta en la capa de la aplicación para proteger las comunicaciones de RPC. El uso de la seguridad en el nivel de la aplicación permite que las aplicaciones tengan una identidad de par remoto autenticada, que se puede usar para implementar políticas de autorización detalladas.

¿Por qué no TLS?

Puede parecer inusual que Google utilice una solución de seguridad personalizada como ALTS cuando la mayoría del tráfico de Internet hoy en día está encriptado mediante TLS. ALTS comenzó su desarrollo en Google en 2007. En ese momento, TLS era compatible con muchos protocolos heredados que no cumplían con nuestros estándares mínimos de seguridad. Podríamos haber diseñado nuestra solución de seguridad mediante la adopción de los componentes de TLS que necesitábamos y, luego, implementábamos los que deseábamos. Sin embargo, las ventajas de construir un sistema más adecuado para Google desde cero superaban los beneficios de enmendar un sistema existente. Además, la ALTS es más apropiada para nuestras necesidades y tradicionalmente más segura que la TLS anterior. A continuación, se describen las diferencias clave entre TLS y ALTS.

  • Existe una gran diferencia entre los modelos de confianza4 de TLS con las semánticas de HTTPS y ALTS. En el primero, las identidades del servidor están vinculadas a un nombre específico y al esquema de nombres correspondiente. En ALTS, la misma identidad se puede utilizar con varios esquemas de nombres. Este nivel de indirección proporciona más flexibilidad y simplifica enormemente el proceso de replicación de microservicio, balanceo de cargas y reprogramación entre hosts.
  • En comparación con TLS, ALTS es más simple en su implementación y diseño. Como resultado, es más fácil supervisar los errores y las vulnerabilidades de seguridad mediante la inspección manual del código fuente o fuzzing extensivo.
  • ALTS usa un búfer de protocolo para serializar sus mensajes de protocolo y certificados, mientras que TLS usa certificados X.509 codificados con ASN.1. La mayoría de los servicios de producción usan búferes de protocolo para la comunicación (y, a veces, el almacenamiento), lo que hace que ALTS se adapte mejor al entorno de Google.

Diseño de ALTS

ALTS se diseñó para ser un sistema altamente confiable que permite la seguridad y autenticación entre servicios con una participación mínima del usuario. Para lograr esto, las propiedades que se describen a continuación son parte del diseño de ALTS:

  • Transparencia: la configuración de la ALTS es transparente para la capa de la aplicación. De forma predeterminada, las RPC del servicio están protegidas con ALTS. Esto permite que los desarrolladores de aplicaciones se enfoquen en la lógica funcional de sus servicios sin tener que preocuparse por la administración de credenciales o las configuraciones de seguridad. Durante el establecimiento de la conexión entre servicios, ALTS proporciona aplicaciones con una identidad de par remoto autenticada que se puede usar para auditorías y verificaciones de autorización detalladas.
  • Criptografía de vanguardia: todos los protocolos y funciones iniciales cristalográficos que utiliza ALTS están actualizados con los ataques conocidos actuales. ALTS se ejecuta en máquinas controladas por Google, lo que significa que todos los protocolos criptográficos compatibles se pueden actualizar y también implementar fácilmente.
  • Modelo de identidad: ALTS realiza la autenticación principalmente por identidad en lugar de nombre de host. En Google, cada entidad de red (p. ej., un usuario corporativo, una máquina física o un servicio de producción o carga de trabajo) tiene una identidad asociada. Todas las comunicaciones entre servicios se autentican mutuamente.
  • Distribución de claves: ALTS se basa en que cada carga de trabajo tenga una identidad, que se expresa como un conjunto de credenciales. Estas credenciales se implementan en cada carga de trabajo durante la inicialización, sin la participación del usuario. Al mismo tiempo, se establecen una raíz de confianza y una cadena de confianza en estas credenciales para máquinas y cargas de trabajo. El sistema permite la rotación y revocación automática de certificados sin la participación de los desarrolladores de aplicaciones.
  • Escalabilidad: ALTS se diseñó para ser altamente escalable y así admitir la escala masiva de la infraestructura de Google. Este requisito dio como resultado el desarrollo de una reanudación de sesión eficaz.
  • Conexiones de larga duración: las operaciones criptográficas de intercambio de claves autenticadas son costosas en términos de procesamiento. Para adaptarse a la escala de la infraestructura de Google, después de un protocolo de enlace de ALTS inicial, las conexiones se pueden mantener por más tiempo para mejorar el rendimiento del sistema en general.
  • Simplicidad: de manera predeterminada, TLS es compatible con versiones de protocolo heredadas y con versiones anteriores. ALTS es considerablemente más simple, ya que Google controla tanto a los clientes como a los servidores que diseñamos para que sea compatible de forma nativa con ALTS.

Modelo de confianza de ALTS

ALTS realiza la autenticación principalmente por identidad y no por host. En Google, cada entidad de red (p. ej., un usuario corporativo, una máquina física o un servicio de producción) tiene una identidad asociada. Estas identidades se incorporan en los certificados de ALTS y se utilizan para la autenticación de pares durante el establecimiento de la conexión segura. El modelo que deseamos es que nuestros servicios de producción se ejecuten como entidades de producción que nuestros ingenieros de confiabilidad de sitios (SRE)5 puedan administrar. Las versiones de desarrollo de estos servicios de producción se ejecutan como entidades de prueba que los SRE y los desarrolladores pueden administrar.

Por ejemplo, supongamos que tenemos un producto con dos servicios: service-frontend y service-backend. Los SRE pueden iniciar la versión de producción de estos servicios: service-frontend-prod y service-backend-prod. Los desarrolladores pueden compilar y, luego, iniciar versiones de desarrollo de estos servicios, service-frontend-dev y service-backend-dev, para fines de prueba. La configuración de autorización en los servicios de producción se establecerá para que no confíe en las versiones de desarrollo de los servicios.

Credenciales de ALTS

Existen tres tipos de credenciales de ALTS y todas se expresan en formato de mensaje de búfer de protocolo.

  • Certificado principal: firmado por un servicio de firmas remoto; se utiliza para verificar los certificados de protocolo de enlace. El certificado principal contiene una clave pública asociada a una clave privada principal, p. ej., par de claves RSA. Esta clave privada se utiliza para firmar certificados de protocolo de enlace. Estos certificados, cuando se utilizan en combinación con la política de ALTS que se analiza a continuación, son esencialmente certificados intermedios restringidos de autoridad certificada (CA). Por lo general, los certificados principales se emiten para programadores y máquinas de producción de cargas de trabajo en contenedores, como el Borgmaster6.
  • Certificado de protocolo de enlace: creado y firmado localmente por la clave privada principal. Este certificado contiene los parámetros utilizados durante el protocolo de enlace de ALTS (establecimiento de conexión segura), por ejemplo, los parámetros estáticos Diffie-Hellman (DH) y los cifrados del protocolo de enlace. Además, el certificado de protocolo de enlace contiene el certificado principal del que se deriva, es decir, el asociado con la clave privada principal que firma el certificado de protocolo de enlace.
  • Clave de reanudación: es un secreto que se utiliza para encriptar los tickets de reanudación. Esta clave se identifica mediante un IDR de identificador de reanudación que es único y se comparte entre todas las cargas de trabajo de producción que se ejecutan con la misma identidad y en la misma celda del centro de datos. Para obtener más detalles sobre la reanudación de sesión en ALTS, consulta Reanudación de sesión.

La figura 1 muestra la cadena de certificados de ALTS, que consta de una clave de verificación del servicio de firma, un certificado principal y un certificado de protocolo de enlace. Las claves de verificación del servicio de firmas son la raíz de confianza en ALTS y se instalan en todas las máquinas de Google en nuestras redes de producción y corporativas.

Figura 1: Cadena de certificados de ALTS

En ALTS, un servicio de firmas certifica certificados principales que, a su vez, certifican certificados de protocolo de enlace. Como los certificados de protocolo de enlace se crean más a menudo que los certificados principales, esta arquitectura reduce la carga en el servicio de firma. La rotación de certificados ocurre con frecuencia en Google, en especial para los certificados de protocolo de enlace7. Esta rotación frecuente compensa los pares de intercambio de claves estáticas que llevan los certificados de protocolo de enlace8.

Emisión del certificado

Para participar en un protocolo de enlace seguro en ALTS, las entidades en la red deben aprovisionarse con certificados de protocolo de enlace. Primero, el emisor obtiene un certificado principal firmado por el servicio de firmas y, opcionalmente, lo pasa a la entidad. Luego, la clave privada principal asociada crea y firma un certificado de protocolo de enlace.

Normalmente, el emisor es nuestra autoridad certificada (CA) interna si emite certificados a máquinas y personas, o el Borgmaster si emite certificados a cargas de trabajo. Sin embargo, puede ser cualquier otra entidad, p. ej., un Borgmaster restringido para una celda de centro de datos de prueba.

La figura 2 muestra cómo se utiliza el servicio de firmas para crear un certificado principal. El proceso consta de los siguientes pasos.

Figura 2: Emisión del certificado

  1. El emisor del certificado envía una solicitud de firma de certificado (CSR) al servicio de firmas. Esta solicitud le pide al servicio de firmas que cree un certificado para la identidad A. Esta identidad, por ejemplo, puede ser un usuario corporativo o la identidad de un servicio de producción de Google.
  2. El servicio de firmas establece el emisor del certificado (incluido en la CSR) para el solicitante (el emisor del certificado en este caso) y lo firma. Recuerda que la clave (de verificación) pública del servicio de firmas correspondiente está instalada en todas las máquinas de Google.
  3. El servicio de firmas devuelve el certificado firmado.
  4. Se crea un certificado de protocolo de enlace para la identidad A, el cual está firmado por la clave privada asociada del certificado principal.

Como se muestra en el proceso anterior, con ALTS, el emisor y el firmante de un certificado son dos entidades lógicas diferentes. En este caso, el emisor es la entidad emisora del certificado, mientras que el firmante es el servicio de firma.

Existen tres categorías comunes de certificados en ALTS: de persona, de máquina y de carga de trabajo. Las siguientes secciones describen cómo se crean y se utilizan cada uno de estos certificados en ALTS.

Certificados de persona

En Google, utilizamos ALTS para asegurar las RPC emitidas por usuarios humanos a los servicios de producción. Para emitir una RPC, un usuario debe proporcionar un certificado de protocolo de enlace válido. Por ejemplo, si Alice desea usar una aplicación para emitir una RPC con seguridad de ALTS, se puede autenticar ante nuestra CA interna. Alice se autentica ante la CA con su nombre de usuario, contraseña y autenticación de dos factores. Esta operación hace que Alice obtenga un certificado de protocolo de enlace válido por 20 horas.

Certificados de máquina

Cada máquina de producción en los centros de datos de Google tiene un certificado principal de máquina. Este certificado se utiliza a fin de crear certificados de protocolo de enlace para las aplicaciones principales en esa máquina, p. ej., daemons de administración de máquinas. La identidad primaria incorporada en un certificado de máquina se refiere al propósito típico de la máquina. Por ejemplo, las máquinas utilizadas para ejecutar tipos diferentes de cargas de trabajo de producción y desarrollo pueden tener identidades distintas. Solo las máquinas que ejecutan pilas de software verificadas pueden utilizar los certificados principales. En algunos casos, esta confianza tiene su raíz en el hardware de seguridad personalizado9. La CA emite todos los certificados principales de máquinas de producción, que rotan cada pocos meses. Además, todos los certificados de protocolo de enlace rotan cada pocas horas.

Certificados de carga de trabajo

Una ventaja clave de ALTS es que funciona con la idea de una identidad de carga de trabajo que facilita la reprogramación, el balanceo de cargas y la replicación del servicio simple en todas las máquinas. En nuestra red de producción, usamos un sistema llamado Borg10 para la administración de clústeres y la asignación de recursos de máquina a gran escala. La forma en que Borg emite certificados es parte de la implementación de la identidad de la carga de trabajo independiente de la máquina de ALTS.

Cada carga de trabajo en nuestra red de producción se ejecuta en una celda de Borg. Cada celda contiene un controlador lógicamente centralizado llamado el Borgmaster, y varios procesos de agente llamados Borglets que se ejecutan en cada máquina en esa celda. Las cargas de trabajo se inicializan con certificados de protocolo de enlace de cargas de trabajo asociados emitidos por el Borgmaster. La figura 3 muestra el proceso de certificación de la carga de trabajo en ALTS con Borg.

Figura 3: Creación del certificado de protocolo de enlace en la red de producción de Google

El Borgmaster ahora está listo para programar las cargas de trabajo que necesita usar ALTS. Los pasos que se describen a continuación suceden cuando un cliente programa una carga de trabajo para ejecutarse en Borg como una identidad dada.

  1. Cada Borgmaster viene preinstalado con un certificado principal de máquina y una clave privada asociada (no se muestra en el diagrama).
  2. ALTSd11 genera un certificado de protocolo de enlace de Borgmaster y lo firma con la clave privada principal de la máquina. Este certificado de protocolo de enlace permite a Borgmaster emitir RPC con seguridad de ALTS.
  3. El Borgmaster crea un certificado principal de carga de trabajo base y la clave privada correspondiente. El Borgmaster inicia una solicitud (una RPC con seguridad de ALTS) para obtener este certificado principal de carga de trabajo base firmado por el servicio de firmas. Como resultado, el servicio de firmas coloca el Borgmaster como el emisor en este certificado.
  4. El Borgmaster verifica que el cliente esté autorizado para ejecutar cargas de trabajo como la identidad que se especifica en la configuración de la carga de trabajo. Si es así, el Borgmaster programa la carga de trabajo de Borg en el Borglet y emite un certificado de protocolo de enlace de carga de trabajo y su clave privada correspondiente. Este certificado está encadenado desde el certificado principal de carga de trabajo base. El certificado de protocolo de enlace de carga de trabajo y su clave privada se envían de forma segura al Borglet (a través de un canal con protección de ALTS mutuamente autenticado entre Borgmaster y Borglet). El Borgmaster rota su certificado principal de carga de trabajo base y vuelve a emitir certificados de protocolos de enlace para todas las cargas de trabajo que se ejecutan aproximadamente cada dos días. Además, cada carga de trabajo que se ejecuta como el mismo usuario en la misma celda recibe el mismo identificador (IDR) y la misma clave de reanudación que aprovisiona el Borgmaster.
  5. Cuando la carga de trabajo necesita hacer una RPC con seguridad de ALTS, utiliza el certificado de protocolo de enlace de carga de trabajo en el protocolo de enlace. El IDR también se utiliza como parte del protocolo de enlace para iniciar la reanudación de sesión. Para obtener más información sobre la reanudación de sesión en ALTS, consulta Reanudación de sesión.

Aplicación de la política de ALTS

La política de ALTS es un documento que muestra cuáles son los emisores que están autorizados a emitir ciertas categorías de certificados y para qué identidades. Se distribuye a cada máquina en nuestra red de producción. Por ejemplo, la política de ALTS le permite a la CA emitir certificados a máquinas y personas. También le permite a Borgmaster emitir certificados a cargas de trabajo.

Descubrimos que la aplicación de políticas durante la verificación de certificados, a diferencia de la emisión de certificados, es un enfoque más flexible, ya que permite aplicar políticas diferentes en tipos de implementaciones diferentes. Por ejemplo, es conveniente que una política en un clúster de prueba sea más permisiva que una en un clúster de producción.

Durante el protocolo de enlace de ALTS, la validación del certificado incluye una verificación de la política de ALTS. La política garantiza que el emisor que figura en el certificado que se está validando esté autorizado a emitir ese certificado. Si no lo está, se rechaza el certificado y el proceso de protocolo de enlace resulta erróneo. En la figura 4, se ilustra cómo funciona la aplicación de políticas en ALTS. Si sigues la situación en la figura 2, se supone que Mallory (un usuario corporativo que desea escalar sus privilegios) quiere emitir un certificado principal al administrador de red, que es una identidad potente que puede volver a configurar la red. No hace falta decir que Mallory no tiene autorización en la política de ALTS para realizar esta operación.

Figura 4: Emisión y uso del certificado

  1. Mallory emite un certificado principal para la identidad de administrador de red y lo firma con el servicio de firmas. Esto es similar a los primeros tres pasos de la figura 2.
  2. Mallory crea y firma un certificado de protocolo de enlace localmente para el administrador de red. Lo hace mediante el uso de la clave privada principal asociada con el certificado principal que se creó.
  3. Si Mallory intenta hacerse pasar por la identidad de administrador de red con el certificado de protocolo de enlace que se creó, el ejecutor de políticas de ALTS, en el par con el que Mallory intenta comunicarse, bloqueará la operación.

Revocación del certificado

En Google, un certificado se convierte en no válido cuando caduca o se incluye en nuestra lista de revocación de certificados (CRL). Esta sección describe el diseño de los mecanismos internos de revocación de certificados de Google, que, al momento de redactar este documento, aún se encuentran en pruebas de implementación.

Todos los certificados emitidos a usuarios corporativos humanos tienen una marca de tiempo de caducidad diaria que obliga a los usuarios a volver a autenticarse todos los días. Muchos de los certificados emitidos a las máquinas de producción no utilizan marcas de tiempo de caducidad. Evitamos confiar en que las marcas de tiempo caduquen certificados de producción, ya que esto puede provocar interrupciones causadas por problemas de sincronización del reloj. En su lugar, utilizamos la CRL como nuestra fuente de verdad para la rotación y el control de respuesta a incidentes de certificados. La figura 5 muestra cómo funciona la CRL.

Figura 5: Creación del certificado principal con un ID de revocación

  1. Cuando se inicializa una instancia12 de nuestra CA, se comunica con el servicio de CRL y solicita un rango de ID de revocación. Un ID de revocación es un ID largo de 64 bits con dos componentes, una categoría de certificado de 8 bits (p. ej., un certificado de persona o de máquina) y un identificador de certificado de 56 bits. El servicio de CRL elige un rango de estos ID y lo devuelve a la CA.
  2. Cuando la CA recibe una solicitud de un certificado principal, crea el certificado e incorpora un ID de revocación que selecciona del rango.
  3. Al mismo tiempo, la CA asigna el certificado nuevo al ID de revocación y envía esta información al servicio de CRL.
  4. La CA emite el certificado principal.

Los ID de revocación asignados a los certificados de protocolo de enlace dependen de cómo se utiliza el certificado. Por ejemplo, los certificados de protocolo de enlace que se emiten a usuarios corporativos humanos heredan el ID de revocación del certificado principal del usuario. En los certificados de protocolo de enlace que se emiten a las cargas de trabajo de Borg, el ID de revocación se asigna por el rango de ID de revocación de Borgmaster. El servicio de CRL asigna este rango de ID al Borgmaster en un proceso similar al que se muestra en la figura 5. Siempre que un par esté involucrado en un protocolo de enlace de ALTS, verifica una copia local del archivo de CRL para asegurarse de que el certificado de par remoto no haya sido revocado.

El servicio de CRL compila todos los ID de revocación en un solo archivo que puede enviarse a todas las máquinas de Google que usan ALTS. Si bien la base de datos de CRL tiene varios cientos de megabytes, el archivo de CRL que se genera es solo de unos pocos megabytes debido a una variedad de técnicas de compresión.

Protocolos de ALTS

ALTS se basa en dos protocolos: el protocolo de enlace (con reanudación de sesión) y el protocolo de registro. En esta sección, se proporciona una descripción general de alto nivel de cada protocolo. Estas descripciones generales no se deben interpretar como especificaciones detalladas de los protocolos.

Protocolo de enlace

El protocolo de enlace de ALTS es un protocolo de intercambio de claves autenticado basado en Diffie-Hellman que admite tanto la confidencialidad directa perfecta (PFS) como la reanudación de sesión. La infraestructura de ALTS garantiza que cada cliente y servidor tenga un certificado con sus respectivas identidades y una clave de curva elíptica de Diffie-Hellman (ECDH) que se encadena a una clave de verificación de servicio de firmas confiable. En ALTS, la PFS no está habilitada por configuración predeterminada porque estas claves de ECDH estáticas suelen actualizarse para renovar la confidencialidad directa, incluso si la PFS no se utiliza en un protocolo de enlace. Durante un protocolo de enlace, el cliente y el servidor negocian de forma segura una clave de encriptación de tránsito compartida, y el protocolo de registro que la clave de encriptación protegerá. Por ejemplo, el cliente y el servidor pueden aceptar una clave de 128 bits que se utilizará para proteger una sesión de RPC con AES-GCM. El protocolo de enlace consta de cuatro mensajes de búfer de protocolo serializados. Puedes obtener una descripción general de estos en la figura 6.

Figura 6: Mensajes de protocolo de enlace de ALTS

  1. Para iniciar el protocolo de enlace, el cliente envía un mensaje ClientInit. Este mensaje contiene el certificado de protocolo de enlace del cliente y una lista de los cifrados y protocolos de registro relacionados con el protocolo de enlace, que son compatibles con el cliente. Si el cliente intenta reanudar una sesión terminada, incluirá un identificador de reanudación y un ticket encriptado de reanudación del servidor.

  2. Al momento de recibir el mensaje ClientInit, el servidor verifica el certificado del cliente. Si es válido, el servidor elige un protocolo de registro y de cifrado de enlace desde la lista que proporciona el cliente. El servidor utiliza una combinación de la información contenida en el mensaje ClientInit y su propia información local para calcular el resultado del intercambio de DH. Este resultado se usa como una entrada a las funciones de derivación de claves13 junto con la transcripción del protocolo para generar los siguientes secretos de sesión:

    • Una clave secreta M de protocolo de registro que se utiliza para encriptar y autenticar mensajes de carga útil.
    • Un secreto de reanudación R que se utilizará en un ticket de reanudación en sesiones futuras.
    • Un secreto de autenticador A.

    El servidor envía un mensaje ServerInit que contiene su certificado, el cifrado de protocolo de enlace seleccionado, el protocolo de registro y un ticket de reanudación encriptado opcional.

  3. El servidor envía un mensaje ServerFinished que contiene un autenticador de protocolo de enlace14. El valor para este autenticador se calcula con un código de autenticación de mensajes basado en hash (HMAC) que se calcula sobre una string de bits predefinida y el secreto de autenticador A.

  4. Una vez que el cliente recibe ServerInit, verifica el certificado del servidor, calcula el resultado del intercambio de DH similar al servidor y deriva los mismos secretos M, R y A. El cliente utiliza el secreto A derivado para verificar el valor del autenticador en el mensaje ServerFinished recibido. En este punto del proceso de protocolo de enlace, el cliente puede comenzar a usar el secreto M para encriptar mensajes. Como el cliente ahora es capaz de enviar mensajes encriptados, podemos decir que ALTS tiene un protocolo de enlace de RTT.

  5. Una vez finalizado el protocolo de enlace, el cliente envía un mensaje ClientFinished con un valor de autenticador similar (ver paso 3) calculado sobre una string de bits predefinida diferente. Si es necesario, el cliente puede incluir un ticket de reanudación encriptado para sesiones futuras. Una vez que el servidor recibe y verifica este mensaje, se concluye el protocolo de enlace de ALTS y el servidor puede comenzar a usar M para encriptar y autenticar más mensajes de carga útil.

Thai Duong, del equipo de análisis de seguridad interno de Google, revisó el protocolo de enlace y Bruno Blanchet, con la ayuda de Martin Abadi, lo verificó de manera formal con la herramienta Proverif15.

Protocolo de registro

En la sección Protocolo de enlace se describió la manera en que usamos el protocolo de enlace para negociar un protocolo secreto de registro. El secreto de protocolo se utiliza para encriptar y autenticar el tráfico de red. La capa de la pila que realiza estas operaciones se denomina protocolo de registro de ALTS (ALTSRP).

ALTSRP contiene un conjunto de esquemas de encriptación con una variedad de tamaños de clave y funciones de seguridad. Durante el protocolo de enlace, el cliente envía su lista de esquemas preferidos, ordenados por preferencia. El servidor elige el primer protocolo en la lista del cliente que coincide con la configuración local del servidor. Este método de selección de esquemas permite que tanto los clientes como los servidores tengan preferencias de encriptación diferentes y nos permite ingresar en fases (o quitar) esquemas de encriptación.

Enmarcado

Los marcos son la unidad de datos más pequeña en ALTS. Según su tamaño, cada mensaje de ALTSRP puede consistir en uno o más marcos. Cada marco contiene los campos siguientes:

  • Longitud: es un valor sin signo de 32 bits que indica la longitud del marco en bytes. Este campo de 4 bytes de longitud no se incluye como parte de la longitud total del marco.
  • Tipo: es un valor de 32 bits que especifica el tipo de marco, p. ej., marco de datos.
  • Carga útil: son los datos reales autentificados y encriptados opcionalmente que se envían.

La longitud máxima de un marco es de 1 MB más 4 bytes de longitud. Para los protocolos de RPC actuales, limitamos aún más la longitud del marco, ya que los marcos más cortos requieren menos memoria para el almacenamiento en búfer. Los marcos más grandes también pueden ser vulnerables ante un posible atacante durante un ataque de denegación de servicio (DoS) en un intento de vaciar un servidor. Además de limitar la longitud del marco, restringimos la cantidad de marcos que se pueden encriptar con el mismo secreto M de protocolo de registro. El límite varía según el esquema de encriptación que se utiliza para encriptar y desencriptar la carga útil del marco. Una vez que se alcanza este límite, la conexión debe cerrarse.

Carga útil

En ALTS, cada marco contiene una carga útil que está protegida por integridad y encriptada de forma opcional16. A partir de la publicación de este documento, ALTS admite los siguientes modos:

  • Modos AES-128-GCM, AES-128-VCM: AES-GCM y AES-VCM, respectivamente con claves de 128 bits. Estos modos protegen la confidencialidad y la integridad de la carga útil mediante el uso de GCM y los esquemas de VCM17, respectivamente.
  • AES-128-GMAC y AES-128-VMAC: estos modos son compatibles con la protección solo por integridad con GMAC y VMAC, respectivamente, para el cálculo de etiquetas. La carga útil se transfiere en texto simple con una etiqueta criptográfica que protege su integridad.

En Google, utilizamos modos diferentes de protección según el modelo de amenaza y los requisitos de rendimiento. Si las entidades comunicantes se encuentran dentro del mismo límite físico controlado por Google o en nombre de Google, solo se utiliza la protección por integridad. Estas entidades aún pueden optar por actualizar a una encriptación autenticada según la sensibilidad de sus datos. Si las entidades que se comunican se encuentran en diferentes límites físicos controlado por Google o en nombre de Google, y así las comunicaciones pasan a través de la red de área extensa, actualizamos automáticamente la seguridad de la conexión a la encriptación autenticada, independientemente del modo que se eligió. Google aplica protecciones diferentes a los datos en tránsito cuando se transmite fuera de un límite físico controlado por Google o en nombre de Google, ya que no se pueden aplicar las mismas medidas de seguridad rigurosas.

Cada marco está protegido por integridad de forma separada y está opcionalmente encriptado. Ambos pares mantienen los contadores de solicitud y respuesta, que se sincronizan mientras se opera normalmente. Si el servidor recibe solicitudes que están fuera de servicio, o que se repiten, la verificación de integridad criptográfica falla y descarta la solicitud. Del mismo modo, el cliente descarta una respuesta repetida o pedida de forma incorrecta. Además, que ambos pares mantengan los contadores (en lugar de incluir sus valores en el encabezado del marco) ahorra bytes adicionales en el cable.

Reanudación de sesión

ALTS permite a sus usuarios reanudar las sesiones anteriores sin necesidad de realizar operaciones criptográficas asimétricas pesadas. La reanudación de sesión es una función que está incorporada en el protocolo de enlace de ALTS.

El protocolo de enlace de ALTS permite a los clientes y servidores intercambiar de forma segura (y almacenar en caché) los tickets de reanudación que se pueden utilizar para reanudar conexiones futuras18. Cada ticket de reanudación almacenado en caché se indexa mediante un identificador de reanudación (IDR) que es único para todas las cargas de trabajo que se ejecutan con la misma identidad y en la misma celda del centro de datos. Estos tickets se encriptan con claves simétricas asociadas con los identificadores correspondientes.

ALTS admite dos tipos de reanudación de sesión:

  1. Reanudación de sesión del servidor: un cliente crea y encripta un ticket de reanudación que contiene la identidad del servidor y el secreto R de reanudación derivado. El ticket de reanudación se envía al servidor al final del protocolo de enlace, en el mensaje ClientFinished. En sesiones futuras, el servidor puede elegir reanudar la sesión mediante el envío del ticket al cliente en su mensaje ServerInit. Al momento de recibir el ticket, el cliente puede recuperar el secreto R de reanudación y la identidad del servidor. El cliente puede utilizar esta información para reanudar la sesión.

    El IDR siempre está asociado a una identidad y no a conexiones específicas. En ALTS, varios clientes pueden usar la misma identidad en el mismo centro de datos. Esto permite a los clientes reanudar las sesiones con servidores con los que no se comunicaron antes, p. ej., si un balanceador de cargas envía al cliente a un servidor diferente que ejecuta la misma aplicación.

  2. Reanudación de sesión del cliente: al final de un protocolo de enlace, el servidor envía un ticket de reanudación encriptado al cliente en el mensaje ServerFinished. Este ticket incluye el secreto R de reanudación y la identidad del cliente. El cliente puede usar este ticket para reanudar una conexión con cualquier servidor que comparta el mismo IDR.

Cuando se reanuda una sesión, el secreto R de reanudación se usa para derivar los secretos M', R' y A' de sesión nuevos. El secreto M' se usa para encriptar y autenticar mensajes de carga útil, el secreto A' se utiliza con el propósito de autenticar los mensajes ServerFinished y ClientFinished, y el secreto R' se encapsula en un ticket de reanudación nuevo. Ten en cuenta que el mismo secreto R de reanudación nunca se utiliza más de una vez.

Compensaciones

Ataques de robo de identidad que vulneran claves

Por diseño, el protocolo de enlace de ALTS es susceptible a ataques de robo de identidad que vulneran claves (KCI). Si un adversario compromete la clave privada de DH o la clave de reanudación de una carga de trabajo, se puede usar la clave para robar la identidad de otras cargas de trabajo a esta carga de trabajo19. Esto está explícitamente en nuestro modelo de amenaza de reanudación, ya que queremos que los tickets de reanudación emitidos por una instancia de una identidad se puedan utilizar en otras instancias de esa identidad.

Existe una variante del protocolo de enlace ALTS que protege contra ataques KCI, pero solo valdría la pena utilizarla en entornos en los que no se desea reanudar.

Privacidad para mensajes de protocolo de enlace

ALTS no está diseñada para ocultar las identidades internas que se comunican, por lo que no encripta ningún mensaje de protocolo de enlace para ocultar las identidades de los pares.

Confidencialidad directa perfecta

La confidencialidad directa perfecta (PFS) es compatible con ALTS, pero no está habilitada de forma predeterminada. En su lugar, utilizamos la rotación de certificados frecuente a fin de establecer confidencialidad directa para la mayoría de las aplicaciones. Con TLS 1.2 (y sus versiones anteriores), la reanudación de sesión no está protegida con PFS. Cuando PFS se habilita con ALTS, también se habilita para sesiones reanudadas.

Reanudación sin idas y vueltas

TLS 1.3 proporciona la reanudación de sesión que no requiere idas y vueltas (0-RTT); sin embargo, esto tiene propiedades de seguridad más débiles20. Decidimos no incluir una opción 0-RTT en ALTS porque las conexiones de RPC en Google, generalmente, son de larga duración. En consecuencia, la reducción de la latencia de configuración del canal no fue una compensación buena para la complejidad adicional o la seguridad reducida que requieren los protocolos de enlace 0-RTT.

Referencias adicionales

Pies de página

1Un microservicio es un estilo arquitectónico que estructura una aplicación como una colección de servicios vinculados de manera flexible que implementan capacidades empresariales.
2Una carga de trabajo de producción es una aplicación que los ingenieros de Google programan para ejecutar en los centros de datos de Google.
3Para obtener más información sobre cómo Google protege los datos en tránsito, consulta nuestro informe, Encriptación en tránsito en Google Cloud.
4Un modelo de confianza es el mecanismo mediante el cual un protocolo de seguridad identifica, distribuye y rota identidades y credenciales.
5Los desarrolladores se encargan directamente de administrar algunos servicios.
6Borgmaster es responsable de programar y, luego, inicializar las cargas de trabajo de producción de Google. Para obtener más información, consulta Large-scale cluster management at Google with Borg.
7Se puede encontrar más información sobre las frecuencias de rotación de certificados en Encriptación en tránsito en Google Cloud.
8Si una clave está comprometida, el atacante solo podrá detectar el tráfico durante la vida útil de este par de claves.
11ALTSd: un daemon responsable (entre otras operaciones de ALTS) de la creación de certificados de protocolo de enlace.
12En la práctica, la CA tiene acceso a las claves privadas del servicio de firmas, lo que hace que las dos entidades lógicas sean una única entidad lógica física.
13De forma específica, HKDF-Extract y HKDF-Expand, según se define en RFC-5869.
14La implementación del protocolo de enlace de ALTS concatena los mensajes ServerInit y ServerFinished en una carga útil de cable única.
16La encriptación de la carga útil se negocia como parte del protocolo de registro en el protocolo de enlace.
17El esquema AES-GCM de 128 bits se basa en NIST 800-38D, y AES-VCM se describe en detalle en AES-VCM, An AES-GCM Construction Using an Integer-Based Universal Hash Function.
18La reanudación de sesión implica operaciones simétricas ligeras solo si no están involucrados los parámetros efímeros.