Seguridad de transporte en la capa de la aplicación

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

El contenido incluido en este documento está actualizado a diciembre del 2017 y representa la situación en el momento en que se redactó. Es posible que los sistemas y las políticas de seguridad de Google Cloud cambien a medida que mejoramos la protección de nuestros clientes.

Resumen para directores de sistemas de información

  • La Seguridad de transporte en la capa de la aplicación (ALTS) es un sistema de autenticación mutua y de encriptado durante el transporte desarrollado por Google. Por lo general, se utiliza para proteger las comunicaciones de llamadas a procedimientos remotos (RPC) que se realizan dentro de la infraestructura de Google. El concepto de este sistema es similar al del protocolo de autenticación mutua de seguridad en la capa de transporte (TLS), pero está diseñado y optimizado para satisfacer las necesidades de los entornos de los centros de datos de Google.
  • El modelo de confianza de ALTS se ha diseñado específicamente para las aplicaciones en contenedores similares a la nube. Las identidades están vinculadas a entidades en lugar de a un nombre o host del servidor concretos. De este modo, es posible replicar microservicios, llevar a cabo el balanceo de carga y cambiar la programación entre los hosts de forma fluida.
  • El sistema ALTS está basado en dos protocolos: el protocolo handshake (con reanudación de sesiones) y el protocolo record. Estos protocolos regulan la manera de establecer, autenticar, encriptar y reanudar las sesiones.
  • ALTS es una solución de seguridad en la capa de transporte personalizada que usamos en Google. Como este sistema está adaptado a nuestro entorno de producción, hay algunas diferencias entre trabajar con él y hacerlo con el protocolo TLS, que es el estándar del sector. Encontrarás más información al respecto en la sección Diferencias con respecto a otros sistemas.

Introducción

Los sistemas de producción de Google se componen de una red de microservicios1 que, entre todos, emiten más de 1010 RPC por segundo. Cuando un ingeniero de Google programa una carga de trabajo de producción2, el sistema ALTS protegerá de forma predeterminada cualquier RPC que se realice o se reciba. El sistema Seguridad de transporte en la capa de la aplicación (ALTS) de Google ofrece esta protección automática sin ninguna configuración. Además de proteger las RPC automáticamente, ALTS también permite replicar servicios, llevar a cabo el balanceo de carga y hacer cambios en la programación entre los hosts más fácilmente en las máquinas de producción. En este informe se describe el sistema ALTS y se ofrece más información sobre su despliegue en la infraestructura de producción de Google.

Destinatarios: este documento está dirigido a los profesionales de seguridad de infraestructura a quienes les interese conocer los procesos de autenticación y la seguridad de transporte a gran escala en Google.

Requisitos: además de haber leído esta introducción, el lector debe tener conocimientos básicos sobre la gestión de clústeres en Google.

Seguridad a nivel de la aplicación y ALTS

Muchas aplicaciones, desde navegadores web hasta VPNs, utilizan protocolos de comunicación seguros, como TLS (Seguridad en la capa de transporte) e IPSec, para proteger los datos en tránsito.3 En Google utilizamos ALTS, un sistema de autenticación mutua y encriptado durante el transporte que se ejecuta en la capa de la aplicación para proteger las comunicaciones RPC. Al utilizar un protocolo de seguridad a nivel de la aplicación, las aplicaciones tienen una identidad de emparejamiento remoto autenticada que se puede usar para implementar políticas de autorización pormenorizadas.

Ventajas con respecto a TLS

Puede parecer extraño que Google utilice una solución de seguridad personalizada como ALTS, cuando la mayor parte del tráfico de Internet se encripta con TLS. Empezamos a desarrollar ALTS en el 2007, cuando TLS se utilizaba con otros protocolos antiguos que no cumplían nuestros requisitos de seguridad mínimos. En ese momento, podríamos haber diseñado nuestra solución de seguridad a partir de los componentes de TLS que necesitábamos para luego añadir las funciones más oportunas. Sin embargo, las ventajas de desarrollar desde cero un sistema más acorde con las necesidades de Google superaban los beneficios de tratar de enmendar un sistema que ya existía. ALTS se acerca más a lo que necesitamos y, en el tiempo que lleva en activo, ha demostrado ser más seguro que el protocolo TLS. A continuación, explicamos las principales diferencias entre TLS y ALTS:

  • Existe una gran diferencia entre los modelos de confianza4 de TLS con semánticas de HTTPS y ALTS. En TLS, las identidades del servidor están vinculadas a un nombre específico y a su esquema de nombres correspondiente. En cambio, en ALTS puede usarse una misma identidad con varios esquemas de nombres. Este nivel de indeterminación ofrece más flexibilidad y simplifica en gran medida la replicación de microservicios, el balanceo de cargas y modificar y la reprogramación entre hosts.
  • ALTS tiene un diseño más sencillo y es más fácil de implementar que TLS. De este modo, se pueden detectar errores y vulnerabilidades más fácilmente, ya sea mediante una inspección manual del código fuente o a través de pruebas de vulnerabilidad exhaustivas ante datos aleatorios o inesperados.
  • ALTS usa un búfer de protocolo para serializar sus mensajes de protocolo y certificados, mientras que TLS utiliza certificados X.509 codificados con ASN.1. La mayoría de nuestros servicios de producción utilizan búferes de protocolo para comunicarse (y a veces para almacenar datos), lo que hace que ALTS se adapte mejor al entorno de Google.

Diseño de ALTS

ALTS está diseñado para ser un sistema de alta fiabilidad con funciones de seguridad y autenticación entre servicios que requieran una participación mínima del usuario. Para conseguirlo, incluimos las propiedades que aparecen a continuación en su diseño:

  • Transparencia: la configuración de ALTS es transparente en la capa de la aplicación. De forma predeterminada, las RPC de servicio están protegidas con ALTS. De este modo, los desarrolladores de aplicaciones pueden centrarse en la lógica funcional de sus servicios, sin tener que preocuparse por gestionar credenciales ni de las configuraciones de seguridad. Durante la conexión entre los servicios, ALTS proporciona a las aplicaciones una identidad de emparejamiento remoto autenticada que se puede usar para realizar auditorías y comprobaciones detalladas de las autorizaciones.
  • Criptografía de última generación: todos los protocolos y las primitivas criptográficas de ALTS están actualizadas para hacer frente a los ataques conocidos. ALTS se ejecuta en máquinas controladas por Google, lo que significa que todos los protocolos criptográficos compatibles se pueden actualizar de forma sencilla y desplegar con rapidez.
  • Modelo de identidad: ALTS se basa principalmente en la identidad, y no en el nombre del host, para llevar a cabo la autenticación. En Google, cada entidad de red (por ejemplo, un usuario empresarial, 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: con ALTS, cada carga de trabajo debe tener una identidad, que se expresa mediante un conjunto de credenciales. Estas credenciales se despliegan en cada carga de trabajo durante el proceso de inicialización sin que el usuario intervenga. Al mismo tiempo, se establecen una raíz de confianza y una cadena de confianza en estas credenciales, y se asignan a las máquinas y cargas de trabajo. El sistema permite la rotación y revocación automáticas de certificados sin que los desarrolladores de la aplicación tengan que hacer nada.
  • Escalabilidad: ALTS está diseñado para ser muy escalable y, de este modo, adaptarse a la gran escala de la infraestructura de Google. Para ello, desarrollamos una función de reanudación de sesiones eficiente.
  • Conexiones de larga duración: las operaciones criptográficas de intercambio de claves autenticadas requieren una gran cantidad de recursos informáticos. Las conexiones pueden prolongarse durante un periodo de tiempo mayor después del handshake inicial de ALTS para adaptarse a la escala de la infraestructura de Google y mejorar el rendimiento general del sistema.
  • Sencillez: de manera predeterminada, TLS es compatible con versiones de protocolo antiguas y con versiones anteriores del sistema. ALTS es mucho más simple, ya que Google controla tanto a los clientes como los servidores. Además, diseñamos estos últimos para que sean compatibles con ALTS de forma nativa.

Modelo de confianza de ALTS

ALTS se basa principalmente en la identidad para llevar a cabo la autenticación, no en el host. En Google, cada entidad de red (por ejemplo, un usuario empresarial, una máquina física o un servicio de producción) tiene una identidad asociada. Esta identidad se incorpora en los certificados de ALTS y se utiliza para llevar a cabo la autenticación de pares mientras se establece una conexión segura. En el modelo que proponemos, nuestros servicios de producción se ejecutan como entidades de producción que nuestros ingenieros de Site Reliability Engineering (SRE) puedan gestionar.5 Las versiones de desarrollo de estos servicios de producción se ejecutan como entidades de prueba que pueden gestionar tanto los SRE como los desarrolladores.

Por ejemplo, supongamos que tenemos un producto con dos servicios: servicio‑frontend y servicio‑backend. Los SRE pueden ejecutar la versión de producción de estos servicios: servicio‑frontend‑prod y servicio‑backend‑prod, y los desarrolladores pueden utilizar las versiones de desarrollo de estos servicios, servicio‑frontend‑des y servicio‑backend‑des, para hacer pruebas. La configuración de la autorización de los servicios de producción cambiará para que no se confíe en las versiones de desarrollo de estos servicios.

Credenciales de ALTS

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

  • Certificado maestro: está firmado por un servicio de firmas remoto y se utiliza para verificar los certificados handshake. Este certificado contiene una clave pública asociada a una clave privada maestra (es decir, a un par de claves RSA). Esta última se usa para firmar los certificados handshake. Cuando se utilizan con la política ALTS que se describe más adelante, estos certificados se convierten básicamente en certificados intermedios restringidos de autoridad de certificación (CA). Los certificados maestros se conceden normalmente a programadores y máquinas de producción de cargas de trabajo en contenedores, como el borgmaster.6
  • Certificado handshake: la clave privada maestra se crea y firma de forma local. Este certificado contiene los parámetros que se usan durante el handshake de ALTS (es decir, cuando se establece la conexión), como sucede con los parámetros estáticos Diffie‑Hellman (DH) y los algoritmos de cifrado de handshake. Además, el certificado handshake contiene el certificado maestro del que procede (es decir, el certificado vinculado a la clave privada maestra que firma el certificado handshake).
  • Clave de reanudación: es un secreto que se utiliza para encriptar las incidencias de reanudación. Esta clave se identifica mediante un identificador de reanudación (IDR) único que comparten todas las cargas de trabajo de producción que se ejecutan con la misma identidad y la misma celda del centro de datos. Si necesitas más información sobre la reanudación de sesiones en ALTS, consulta la sección Reanudación de sesiones.

En la imagen 1, se muestra una cadena de certificados de ALTS, que está compuesta por una clave de verificación del servicio de firmas, un certificado maestro y un certificado handshake. Las claves de verificación del servicio de firmas son la raíz de confianza en ALTS y están instaladas en todas las máquinas de Google que forman parte de nuestra cadena de producción y nuestras redes empresariales.

Imagen 1: Cadena de certificados de ALTS

En ALTS, el servicio de firmas certifica los certificados maestros que, a su vez, hacen lo propio con los certificados handshake. Como en esta arquitectura los certificados handshake se crean más a menudo que los maestros, la carga del servicio de firmas es menor. La rotación de certificados es muy frecuente en Google, sobre todo en el caso de los certificados handshake.7 Esta rotación compensa los pares de intercambio de claves estáticas que transportan los certificados handshake.8

Emitir un certificado

Para participar en un handshake de ALTS, las entidades de la red deben aprovisionarse con certificados handshake. Primero, el emisor necesita obtener un certificado maestro firmado por el servicio de firmas para luego concedérselo a la entidad en cuestión (de forma opcional). A continuación, se crea un certificado handshake y la clave privada maestra asociada lo firma.

Por regla general, si emitimos el certificado a máquinas o personas, el emisor es nuestra autoridad de certificación (CA) interna y, si lo emitimos a cargas de trabajo, el emisor es el borgmaster. No obstante, puede ser cualquier otra entidad, como un borgmaster restringido a una celda del centro de datos de prueba.

En la imagen 2, se muestra cómo se usa el servicio de firmas para crear un certificado maestro. El proceso consta de los siguientes pasos.

Imagen 2: Proceso de emisión de certificados

  1. La entidad emisora del certificado envía una solicitud de firma de certificado (CSR) al servicio de firmas. Con esta solicitud, se pide al servicio de firmas que cree un certificado para la identidad A. Esta identidad puede ser, por ejemplo, un usuario empresarial o la identidad de un servicio de producción de Google.
  2. El servicio de firmas asigna la entidad emisora del certificado (incluido en la CSR) a la entidad solicitante 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 handshake para la identidad A firmado por la clave privada asociada del certificado maestro.

Como puedes ver en estos pasos, la entidad que concede el certificado y la que lo firma son dos entidades lógicas diferentes en ALTS. En este caso, el emisor es la entidad que concede el certificado y el firmante es el servicio de firmas.

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

Certificados de humano

En Google, utilizamos ALTS para proteger las RPC que emiten los usuarios humanos a los servicios de producción. Los usuarios deben proporcionar un certificado handshake válido para emitir una RPC. Por ejemplo, si Alicia quiere usar una aplicación para emitir una RPC protegida con ALTS, puede autenticarse en nuestra CA interna. Para hacerlo, tiene que introducir su nombre de usuario y su contraseña, y completar la autenticación de dos factores. Como resultado, obtiene un certificado handshake válido durante 20 horas.

Certificados de máquina

Cada máquina de producción de los centros de datos de Google tiene un certificado maestro de máquina. Este se utiliza para crear certificados handshake para las aplicaciones principales de la máquina, como los daemons de gestión de máquinas. La identidad primaria incorporada en un certificado de máquina responde al propósito típico de la máquina. Esto significa, por ejemplo, que las máquinas utilizadas para ejecutar tipos diferentes de cargas de trabajo de producción y desarrollo pueden tener identidades distintas. Los certificados maestros solo pueden utilizarlos las máquinas que ejecutan pilas de software verificadas. En algunos casos, esta confianza tiene su raíz en el hardware de seguridad personalizado.9 La CA concede todos los certificados maestros de las máquinas de producción, que rotan cada pocos meses. Por su parte, los certificados handshake rotan cada pocas horas.

Certificados de carga de trabajo

Una de las ventajas principales del sistema ALTS es que se basa en la idea de la identidad de las cargas de trabajo, lo que facilita la reprogramación, el balanceo de cargas y la replicación de servicios entre máquinas. En nuestra red de producción, usamos un sistema llamado Borg10 para gestionar los clústeres y asignar las máquinas a escala. La forma en que Borg concede certificados forma parte de la implementación de identidades de cargas de trabajo independiente de las máquinas de ALTS.

Todas las cargas de trabajo de nuestra red de producción se ejecutan en celdas de Borg. Cada celda contiene un controlador centralizado de forma lógica denominado "borgmaster" y hay varios procesos de agente llamados "borglets" que se ejecutan en cada máquina de la celda. Las cargas de trabajo se inicializan con certificados handshake de cargas de trabajo asociados concedidos por el borgmaster. En la imagen 3, se muestra el proceso de certificación de cargas de trabajo que realiza Borg en ALTS.

Imagen 3: Proceso de creación de certificados handshake en la red de producción de Google

El borgmaster está listo para programar las cargas de trabajo que necesita ALTS. A continuación, describimos lo que sucede cuando un cliente programa que una carga de trabajo se ejecute en Borg con una identidad determinada.

  1. Cada borgmaster tiene preinstalados un certificado maestro de máquina y una clave privada asociada (no aparecen en el diagrama).
  2. El ALTSd11 genera un certificado handshake de borgmaster y lo firma con la clave privada maestra de máquina. Este certificado handshake es el que permite al borgmaster realizar RPCs con la seguridad de ALTS.
  3. El borgmaster crea un certificado maestro de carga de trabajo base y la clave privada correspondiente. A continuación, realiza una solicitud (una RPC con seguridad ALTS) para hacer que el servicio de firmas autorice el certificado maestro de carga de trabajo base. Como resultado, el servicio de firmas registra al borgmaster como el emisor del 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. A continuación, este programa la carga de trabajo de Borg en el borglet y concede un certificado handshake de carga de trabajo y su clave privada correspondiente. Este certificado está encadenado desde el certificado maestro de carga de trabajo base. El certificado handshake 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 ALTS mutuamente autenticado entre borgmaster y borglet). El borgmaster rota su certificado maestro de carga de trabajo base y vuelve a emitir certificados handshake a todas las cargas de trabajo en ejecución (esto sucede aproximadamente cada dos días). Además, las cargas de trabajo que se ejecutan como el mismo usuario en la misma celda reciben la misma clave y el mismo identificador de reanudación (ID R) que ha aprovisionado el borgmaster.
  5. Cuando la carga de trabajo tiene que realizar una RPC protegida con ALTS, utiliza el certificado handshake de carga de trabajo en el protocolo handshake. El identificador de reanudación también se utiliza como parte del handshake para iniciar el proceso de reanudación de la sesión. Si necesitas más información sobre la reanudación de sesiones en ALTS, consulta la sección Reanudación de sesiones.

Aplicación de la política de ALTS

La política de ALTS es un documento en el que figuran los emisores autorizados para emitir ciertas categorías de certificados, así como las identidades a las que pueden ir destinados. Esta política se distribuye a todas las máquinas de nuestra red de producción (es el componente que permite a la CA emitir certificados a máquinas y personas, y al borgmaster emitir certificados a cargas de trabajos).

Hemos descubierto que aplicar la política mientras se verifican los certificados es un método más flexible, a diferencia de la emisión de certificados, ya que con él es posible aplicar distintas políticas según el tipo de despliegue. En este caso, sería conveniente hacer que una política de un clúster de prueba sea más permisiva que una de un clúster de producción.

Durante el handshake de ALTS, se realiza una comprobación de la política de ALTS con la validación de los certificados. Con esta política, nos aseguramos de que el emisor que figura en el certificado que se va a validar está autorizado para emitirlo. De lo contrario, el certificado se rechaza y el proceso de handshake no se lleva a cabo. En la imagen 4, se muestra cómo funcionan las medidas de cumplimiento de políticas en ALTS. Retomemos el ejemplo de la imagen 2, pero supongamos que Inma (una usuaria empresarial que desea ampliar sus privilegios) quiere emitir un certificado maestro al administrador de red, una identidad con muchos privilegios capaz de cambiar la configuración de la red. Evidentemente, la política de ALTS no autoriza a Inma a realizar esta operación.

Imagen 4: Proceso de emisión y utilización de certificados

  1. Inma emite un certificado maestro a la identidad de administrador de red y lo firma con el servicio de firmas. Este proceso es parecido a los tres primeros pasos de la imagen 2.
  2. Inma crea y firma un certificado handshake de forma local para el administrador de red mediante una clave privada maestra asociada con el certificado maestro que se crea como resultado.
  3. Si Inma intenta hacerse pasar por la identidad de administrador de red con el certificado handshake que se ha creado, las medidas de aplicación de políticas de ALTS del par con el que Inma quiere comunicarse bloquearán la operación.

Revocación de certificados

En Google, los certificados se invalidan cuando caducan o se incluyen en una lista de revocación de certificados (CRL). En esta sección, describimos el diseño de los mecanismos internos de revocación de certificados de Google. En el momento en que se redacta este artículo, esta función sigue en fase de prueba.

Todos los certificados emitidos a usuarios empresariales humanos tienen una marca de tiempo diaria que establece su fecha de caducidad. De este modo, se obliga a los usuarios a repetir el proceso de autenticación todos los días. Muchos de los certificados emitidos a las máquinas de producción no incluyen estas marcas. Así, evitamos tener que depender de marcas de tiempo para invalidar certificados de producción, ya que podrían producirse problemas relacionados con la sincronización temporal que provocarían suspensiones. En lugar de eso, utilizamos la CRL como fuente de información para llevar a cabo la rotación y el control de respuesta a incidentes de certificados. En la imagen 5, se muestra cómo funciona la CRL.

Imagen 5: Proceso de creación de certificados maestros con un identificador de revocación

  1. Cuando se inicializa una instancia de nuestra CA12, esta se pone en contacto con el servicio de CRL y solicita un intervalo de identificadores de revocación. Este ID es un número de identificación de 64 bits de longitud con dos componentes: una categoría de certificado de 8 bits (para indicar si se trata de un certificado de humano o de máquina, por ejemplo) y un identificador de certificado de 56 bits. El servicio de CRL elige un intervalo de estos ID y lo vuelve a enviar a la CA.
  2. Cuando la CA recibe una solicitud de un certificado maestro, crea el certificado e incorpora un ID de revocación que decide el intervalo.
  3. Al mismo tiempo, la CA asigna el nuevo certificado al ID de revocación y envía esta información al servicio de CRL.
  4. La CA emite el certificado maestro.

Los ID de revocación asignados a los certificados handshake dependen de cómo se utiliza el certificado. Por ejemplo, los certificados handshake que se envían a los usuarios empresariales humanos toman el ID de revocación del certificado maestro del usuario en cuestión. En el caso de los certificados handshake que se conceden a cargas de trabajo de Borg, el ID de revocación se asigna en función del intervalo de los ID de revocación de borgmaster. El servicio de CRL asigna este intervalo al borgmaster en un proceso parecido al que se muestra en la imagen 5. Cuando un par participa en un handshake de ALTS, comprueba la copia local del archivo de CRL para asegurarse de que el certificado del par remoto no se ha 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. Aunque la base de datos de CRL tiene varios cientos de megabytes, el archivo de CRL que se genera solo ocupa algunos megabytes gracias a varias técnicas de compresión.

Protocolos de ALTS

El sistema ALTS está basado en dos protocolos: el protocolo handshake (con reanudación de sesiones) y el protocolo record. En esta sección, se ofrece una descripción general de cada uno de ellos. No obstante, en ningún caso constituyen especificaciones detalladas de sus características.

Protocolo handshake

El protocolo handshake de ALTS es un protocolo de intercambio de claves autenticado basado en parámetros Diffie‑Hellman, compatible tanto con la confidencialidad directa perfecta (PFS) como con la reanudación de sesiones. Gracias a la infraestructura de ALTS, cada cliente y servidor tiene un certificado con sus respectivas identidades y una clave de curva elíptica de Diffie‑Hellman (ECDH) que se une a la cadena de una clave de verificación de servicio de firmas de confianza. En ALTS, la PFS no está habilitada de forma predeterminada, debido a que estas claves de ECDH estáticas suelen actualizarse para renovar la confidencialidad directa, incluso si la PFS no se utiliza en un handshake. Cuando se produce un handshake, el cliente y el servidor determinan una clave de encriptado de tránsito compartida, así como el protocolo Record que protegerá dicha clave. Por ejemplo, es posible que el cliente y el servidor acordasen usar una clave de 128 bits para proteger una sesión de RPC mediante AES‑GCM. El protocolo handshake consiste en cuatro mensajes de búfer de protocolo serializados, tal como se muestra en la imagen 6.

Imagen 6: Mensajes del protocolo handshake de ALTS

  1. El cliente inicia el protocolo handshake enviando un mensaje ClientInit. Este contiene el certificado handshake del cliente y una lista de algoritmos de cifrado y de protocolos Record relacionados con el handshake que utiliza. Si el cliente intenta reanudar una sesión finalizada, incluirá un identificador de reanudación y una incidencia de reanudación del servidor encriptado.
  2. Al recibir el mensaje ClientInit, el servidor verifica el certificado del cliente y, si es válido, elige un protocolo handshake de registro y de cifrado de la lista que proporciona el cliente. El servidor utiliza tanto la información incluida en el mensaje ClientInit como su propia información local para computar el resultado del intercambio de DH. Este resultado aporta información a las funciones de derivación de claves13 y, junto con la transcripción del protocolo, se utiliza para generar los siguientes secretos de sesión:

    • Una clave secreta M de protocolo Record que se utiliza para encriptar y autenticar mensajes de carga útil.
    • Un secreto de reanudación R que se utilizará en una incidencia de reanudación de las próximas sesiones.
    • Un secreto de autenticador A.

    El servidor envía un mensaje ServerInit que contiene su certificado, el algoritmo de cifrado handshake elegido, el protocolo Record y una incidencia opcional de reanudación encriptada.

  3. El servidor envía un mensaje ServerFinished que contiene un autenticador handshake.14 El valor de este autenticador se calcula con un código de autenticación de mensajes basado en hash (HMAC) que se computa utilizando una cadena de bits predefinida y el secreto de autenticador A.

  4. Cuando el cliente recibe el mensaje ServerInit, verifica el certificado del servidor, calcula el resultado del intercambio 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 esta parte del proceso del protocolo handshake, el cliente puede empezar a usar el secreto M para encriptar mensajes. Como el cliente ahora puede enviar mensajes encriptados, podemos decir que ALTS tiene un protocolo handshake de RTT.

  5. Cuando finaliza el protocolo, el cliente envía un mensaje ClientFinished con un valor de autenticador similar (ver paso 3) calculado a partir de una cadena de bits predefinida. Si fuera necesario, el cliente podría incluir una incidencia de reanudación encriptada para futuras sesiones. Cuando el servidor recibe y verifica este mensaje, el protocolo handshake de ALTS concluye, y el servidor puede empezar a usar el secreto M para encriptar y autentificar más mensajes de carga útil.

El protocolo handshake lo ha revisado Thai Duong, del equipo interno de Análisis de Seguridad de Google, y lo ha verificado formalmente Bruno Blanchet, con la ayuda de Martin Abadi, con la herramienta Proverif.15

Protocolo Record

En la sección Protocolo handshake, se describe cómo se utiliza dicho protocolo para determinar un secreto de protocolo Record. Este 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 Record de ALTS" (ALTSRP).

ALTSRP contiene una suite de esquemas de encriptado con distintos tamaños de clave y funciones de seguridad. Durante el protocolo handshake, el cliente envía su lista de esquemas ordenados por preferencia. El servidor elige el primer protocolo de la lista del cliente que coincida con su configuración local. Con este método de selección de esquemas, tanto los clientes como los servidores pueden definir sus propias preferencias de encriptado; además, nos permite introducir esquemas de encriptado en fases o quitarlos.

Marcos

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

  • Longitud: un valor sin firma de 32 bits que indica la longitud del marco en bytes. Este campo de 4 bytes de longitud no forma parte de la longitud total del marco.
  • Tipo: un valor de 32 bits que especifica el tipo de marco (por ejemplo, un marco de datos).
  • Carga útil: los datos autenticados y encriptados de forma opcional que se envían realmente.

La longitud máxima de los marcos es de 1 MB y 4 bytes de longitud. En los protocolos RPC actuales, hemos limitado la longitud de los marcos, ya que así requieren menos memoria para almacenarse en búfer. Además, los marcos de mayor tamaño pueden ser vulnerables ante posibles amenazas durante un ataque de denegación de servicio (DoS) contra el servidor. También hemos restringido la cantidad de marcos que pueden encriptarse con el mismo secreto M de protocolo Record. El límite varía en función del esquema de encriptado que se utiliza para cifrar y descifrar la carga útil del marco. Cuando se alcanza el límite, la conexión debe cerrarse.

Carga útil

En ALTS, cada marco contiene una carga útil, cuya integridad está protegida y puede encriptarse de forma opcional.16 En la fecha en que publicamos este artículo, ALTS admitía los siguientes modos:

  • AES‑128‑GCM y AES‑128‑VCM: los modos AES‑GCM y AES‑VCM, respectivamente, con claves de 128 bits. Estos modos protegen la confidencialidad y la integridad de la carga útil con GCM y los esquemas de VCM17, respectivamente.
  • AES‑128‑GMAC y AES‑128‑VMAC: estos modos admiten protección solo por integridad con GMAC y VMAC, respectivamente, para llevar a cabo el cálculo de las etiquetas. La carga útil se transfiere en texto sin formato con una etiqueta criptográfica que protege su integridad.

En Google, usamos distintos modos de protección dependiendo del modelo de amenaza y de los requisitos de rendimiento. Si las entidades que establecen comunicación se encuentran en el mismo entorno físico controlado por Google o en su nombre, solo se utiliza la protección por integridad. No obstante, estas entidades siguen teniendo la posibilidad de cambiar a un encriptado autenticado en función del grado de confidencialidad de los datos que manejen. Si las entidades que se comunican se encuentran en entornos físicos diferentes, pero siguen estando controlados por Google o en su nombre, y las comunicaciones se transfieren a través de la red de área amplia, cambiamos automáticamente la seguridad de la conexión para usar un modo de encriptado autenticado, fuera cual fuera el modo que se usara en primer lugar. Google aplica medidas de protección diferentes a los datos en tránsito cuando se transmiten fuera de un entorno físico controlado de Google, ya que los entornos externos no pueden ofrecer las rigurosas medidas de seguridad que usamos en nuestras instalaciones.

La integridad de cada marco se protege de forma independiente y se encripta de manera opcional. Ambos pares incorporan contadores de respuestas y solicitudes, que se sincronizan mientras operan con normalidad. Si el servidor recibe solicitudes incorrectas o repetidas, la verificación de integridad criptográfica fallará y se descartará la solicitud. Del mismo modo, el cliente descartará las respuestas repetidas o que se soliciten de forma incorrecta. Al hacer que ambos pares incorporen los contadores (en lugar de incluir sus valores en el encabezado del marco), se ahorran bytes durante la transmisión.

Reanudación de sesiones

ALTS permite a los usuarios reanudar sesiones anteriores sin necesidad de realizar operaciones criptográficas asimétricas complejas. La función de reanudación de sesiones está integrada en el protocolo handshake de ALTS.

Con el protocolo handshake de ALTS, los clientes y los servidores pueden intercambiar y almacenar en caché incidencias de reanudación que pueden usarse para reanudar las conexiones en el futuro.18 Los identificadores de reanudación se encargan de indexar cada incidencia de este tipo almacenada en caché. Cada carga de trabajo que se ejecute con la misma identidad y en la misma célula del centro de datos tiene su propio identificador. Estas incidencias se encriptan con claves simétricas asociadas con su identificador correspondiente.

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

  1. Reanudación de sesión del servidor: un cliente crea y encripta una incidencia de reanudación que contiene la identidad del servidor y el secreto R de reanudación derivado. La incidencia se envía al servidor al final del protocolo handshake en el mensaje ClientFinished. En sesiones futuras, el servidor puede enviar la incidencia al cliente en su mensaje ServerInit para reanudar la sesión. Cuando el cliente lo recibe, puede recuperar el secreto de recuperación R y la identidad del servidor, y usar esta información para reactivar la sesión.

    El identificador de reanudación siempre está asociado a una identidad, no a conexiones específicas. En ALTS, varios clientes pueden usar la misma identidad en el mismo centro de datos. De este modo, los clientes pueden reanudar sesiones en servidores con los que no se hayan comunicado antes (por ejemplo, si un balanceador de carga envía el cliente a un servidor distinto que ejecuta la misma aplicación).

  2. Reanudación de sesión del cliente: al final de un handshake, el servidor envía una incidencia de reanudación encriptada al cliente en el mensaje ServerFinished. Esta incidencia incluye el secreto de reanudación R y la identidad del cliente. El cliente puede usar esta incidencia para reanudar una conexión con cualquier servidor que tenga el mismo identificador de reanudación.

Cuando se reactiva la sesión, el secreto de reanudación R se utiliza para crear los secretos de sesión derivados M', R' y A'. M' se utiliza para encriptar y autenticar los mensajes de carga útil; A', para autenticar los mensajes ServerFinished y ClientFinished; y R' está encapsulado en la nueva incidencia de reanudación. Recuerda que el secreto de reanudación R nunca se usa más de una vez.

Diferencias con respecto a otros sistemas

Ataques de suplantación de claves

Por las particularidades de su diseño, el protocolo handshake de ALTS es sensible a los ataques de suplantación de claves (KCI). Si un atacante vulnera la clave privada de DH o la clave de reanudación de una carga de trabajo, puede usarlas para suplantar la identidad de otra carga de trabajo.19 Nuestro modelo de protección ante amenazas durante la reanudación incorpora expresamente esta característica, con el objetivo de que las incidencias de reanudación que emita una instancia de una identidad puedan usarlas otras instancias de esa identidad.

Existe una variante del protocolo handshake de ALTS que protege contra ataques de KCI, pero solo debe utilizarse en entornos en los que no se vaya a utilizar la función de reanudación de sesiones.

Privacidad de los mensajes handshake

ALTS no está diseñado para diferenciar qué identidades internas se están comunicando, por lo que no encripta ningún mensaje handshake 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, se emplea una rotación de certificados frecuente para establecer la confidencialidad directa de la mayoría de las aplicaciones. Con TLS 1.2 (y sus versiones anteriores), la reanudación de sesiones no está protegida con PFS. Si se habilita PFS en ALTS, también protegerá las sesiones reanudadas.

Reanudación sin idas y vueltas

TLS 1.3 ofrece una reanudación de sesiones sin idas y vueltas (0‑RTT); sin embargo, esta característica ofrece menos nivel de protección.20 Decidimos no incluir una opción 0‑RTT en ALTS porque las conexiones de RPC de Google suelen ser longevas. Por tanto, no consideramos que añadir una opción más compleja y menos segura merezca la pena con tal de reducir la latencia de configuración del canal.

Otras referencias

Notas a pie de página

1 Un microservicio es un estilo de arquitectura que se utiliza para estructurar una aplicación como un conjunto de servicios vinculados de manera flexible que implementan funciones empresariales.
2 Las cargas de trabajo de producción son aplicaciones que los ingenieros de Google programan para ejecutarlas en nuestros centros de datos.
3 Para obtener más información sobre el método que usa Google para encriptar datos en tránsito, consulta el informe Encriptado en tránsito en Google Cloud.
4 Un modelo de confianza es un mecanismo que utilizan los protocolos de seguridad para identificar, distribuir y rotar credenciales e identidades.
5 Algunos servicios los gestionan directamente los desarrolladores.
6 El borgmaster se encarga de programar e inicializar las cargas de trabajo de producción de Google. Para obtener más información, consulta el artículo Large‑scale cluster management at Google with Borg.
7 Para obtener más información sobre las frecuencias de rotación de los certificados, consulta el informe Encriptado en tránsito en Google Cloud.
8 Si se vulnera una clave, el atacante solo podrá acceder al tráfico que se transmita durante el tiempo de actividad de este par de claves.
11 ALTSd es un daemon que puede crear certificados handshake, entre otras operaciones de ALTS.
12 En la práctica, la CA tiene acceso a las claves privadas del servicio de firmas, lo que hace que dos entidades lógicas estén en una única entidad física.
13 Concretamente, HKDF‑Extract y HKDF‑Expand (según se definen en RFC‑5869).
14 La implementación del protocolo handshake de ALTS concatena mensajes ServerInit y ServerFinished en una sola carga útil de transmisión.
16 El encriptado de las cargas útiles se negocia como parte del protocolo Record en el handshake.
17 El esquema AES‑GCM de 128 bits está basado en NIST 800‑38D. En el artículo AES‑VCM, An AES‑GCM Construction Using an Integer‑Based Universal Hash Function encontrarás más información sobre AES‑VCM.
18 En la reanudación de sesiones se utilizan operaciones simétricas sencillas, siempre y cuando no participen parámetros efímeros.