Seguridad de transporte de la capa de la aplicación

Por Cesar Ghali, Adam Stubblefield, Ed Knapp, Jiangtao Li, Benedikt Schmidt, 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 las políticas y los sistemas de seguridad de Google Cloud cambien, ya que mejoramos la protección de nuestros clientes de forma continua.

Resumen a nivel del director de sistemas de información

  • La seguridad de transporte de la capa de aplicación de Google (ALTS) es un sistema de autenticación mutua y de encriptación de transporte desarrollado por Google que se utiliza generalmente para asegurar las comunicaciones de llamadas de procedimiento remoto (RPC) dentro de la infraestructura de Google. ALTS es similar en concepto a TLS mutuamente autenticada, pero fue diseñada y optimizada para satisfacer las necesidades de los entornos de 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. Es por esto que existen 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 colectivamente 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 manera predeterminada. La seguridad de transporte de la capa de 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. Este documento describe ALTS y 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 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, ALTS es más apropiada para nuestras necesidades e históricamente más segura que la TLS anterior. A continuación, se enumeran las diferencias clave entre TLS y ALTS.

  • Existe una gran diferencia entre los modelos de confianza4 de TLS con 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 utilizan 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 ha diseñado 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 enumeran a continuación son parte del diseño de ALTS:

  • Transparencia: la configuración de ALTS es transparente para la capa de la aplicación. De manera predeterminada, las RPC de 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 ha diseñado 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 eficiente.
  • 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 durante 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 e 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 con una clave privada principal, p. ej., par de claves de 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). Los certificados principales se emiten normalmente 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, especialmente 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, puede autenticarse 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. Los certificados principales solo son utilizables por máquinas que ejecutan pilas de software verificadas. 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 entrada 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. La figura 4 ilustra cómo funciona la aplicación de políticas en ALTS. Si sigues la situación en la figura 2, supone que Mallory (un usuario corporativo que desea escalar sus privilegios) desea 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 está autorizada 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 pone en contacto 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. Para los certificados 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 utiliza como una entrada a las funciones de derivación de claves13 junto con la transcripción del protocolo para generar los secretos de sesión siguientes:

    • 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 la A derivada 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 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, fue el encargado de revisar el protocolo de enlace, y la herramienta Proverif15 de Bruno Blanchet lo verificó formalmente, con la ayuda de Martin Abadi.

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 constar de uno o más marcos. Cada cuadro contiene los campos siguientes:

  • Longitud: 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: un valor de 32 bits que especifica el tipo de marco, p. ej., marco de datos.
  • Carga útil: 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, también restringimos la cantidad de marcos que pueden encriptarse 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 opcionalmente16. 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, 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 sin formato 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 incorrectamente. 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 pueden utilizarse para reanudar conexiones futuras18. Cada boleto de reanudación en caché está indexado por 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 lado 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 con una identidad y no con 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 lado 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 utiliza para derivar secretos M', R' y A' de sesión nuevos. M' se usa para encriptar y autenticar mensajes de carga útil, A' se utiliza con el propósito de autenticar los mensajes ServerFinished y ClientFinished, y 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, PFS también se habilita para sesiones reanudadas.

Reanudación sin idas y vueltas

TLS 1.3 proporciona 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 la forma en que Google protege los datos en tránsito, consulta nuestro informe, "[Encriptación en tránsito en Google Cloud] (security/encryption-in-transit)".
4Un **modelo de confianza** es el mecanismo mediante el cual un protocolo de seguridad identifica, distribuye y rota identidades y credenciales.
5Desarrolladores se encargan directamente de administrar algunos servicios.
6Borgmaster es responsable de programar e inicializar las cargas de trabajo de producción de Google. Para obtener más información, consulta [Administración de clústeres a gran escala en Google con Borg] (https://research.google.com/pubs/pub43438.html).
7Puedes encontrar más información sobre las frecuencias de rotación de certificados en "[Encriptación en tránsito en Google Cloud] (/security/encryption-in-transit)".
8 Si una clave está comprometida, el atacante solo podrá detectar el tráfico durante la vida útil de este par de claves.
9 [Titán en profundidad: seguridad en texto sin formato] (https://cloudplatform.googleblog.com/2017/08/Titan-in-depth-security-in-plaintext.html).
10[Administración de clústeres a gran escala en Google con Borg] (https://research.google.com/pubs/pub43438.html)
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.
13Específicamente, HKDF-Extract y HKDF-Expand como 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.
15[ProVerif: verificador de protocolo criptográfico en el modelo formal] (http://prosecco.gforge.inria.fr/personal/bblanche/proverif/).
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] (http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38d.pdf), y AES-VCM se describe detalladamente en [AES-VCM, una construcción AES-GCM que utiliza una función de hash universal basada en números enteros] (https://research.google.com/pubs/pub46483.html).
18La reanudación de sesión implica operaciones simétricas ligeras solo si no están involucrados los parámetros efímeros.
19[Protocolos de acuerdo clave y su análisis de seguridad] (https://dl.acm.org/citation.cfm?id=742138).
20[Ataques de repetición sin tiempo de ida y vuelta: el caso de los candidatos de protocolo de enlace TLS 1.3] (https://eprint.iacr.org/2017/082.pdf)
¿Te sirvió esta página? Envíanos tu opinión:

Enviar comentarios sobre…