Hispanopedia WikiApplication Layer Transport Security ( ALTS ) es un sistema de autenticación y cifrado de transporte desarrollado por Google que se utiliza para proteger las llamadas a procedimientos remotos (RPC) dentro de las máquinas de Google. [ 1 ] Google comenzó su desarrollo en 2007, como una modificación personalizada de TLS . [ 2 ]
Fondo
ALTS, similar a TLS, fue diseñado específicamente para los centros de datos de Google y se basa en dos protocolos: Handshake y Record. [ 3 ] Google comenzó a desarrollar ATLS en 2007 con el fin de crear una solución de sistema de seguridad para la infraestructura de la empresa. [ 4 ]
El documento técnico de ALTS [ 2 ] se publicó en diciembre de 2017. En aquel entonces, los protocolos de capa de aplicación dominantes eran SSL y TLS 1.1 (TLS 1.2 se publicó como RFC recién en 2008 [ 5 ] ), los cuales admitían muchos algoritmos heredados y tenían estándares de seguridad deficientes. Dado que Google tenía el control total de las máquinas que requerían el transporte seguro de RPC, el despliegue de sistemas era relativamente sencillo, por lo que los desarrolladores de Google podían permitirse diseñar su propio sistema desde cero.
Otro requisito que hizo necesario un nuevo sistema fueron los diferentes modelos de confianza : en TLS , el servidor se compromete con su propio nombre de dominio (y el esquema de nombres correspondiente), mientras que Google necesitaba que la misma identidad (es decir, RPC) se utilizara con múltiples esquemas de nombres, para simplificar la replicación de microservicios, el equilibrio de carga y la reprogramación entre hosts.
Detalles
protocolo de apretón de manos
El protocolo de enlace ALTS se basa en un esquema de intercambio de claves Diffie-Hellman autenticado y admite tanto el secreto perfecto hacia adelante (el acceso a las claves actuales no compromete la seguridad futura) como la reanudación de la sesión (aceleraciones notables en el protocolo después de la primera sesión entre las partes).
A diferencia de TLS, en ALTS ambas partes —servidor y cliente— poseen un certificado que acredita sus respectivas identidades. El certificado se enlaza a una clave de verificación de un servicio de firma de confianza, cuyo nodo hoja es una clave Diffie-Hellman de curva elíptica , que se utiliza posteriormente para el intercambio de claves. La curva elíptica empleada en el intercambio de claves es Curve25519 . [ 6 ]
El protocolo de enlace consta de cuatro mensajes, enviados en texto plano:
- ClientInit , iniciado por el cliente, contiene el certificado del cliente, la lista de conjuntos de cifrado disponibles y un intento de reanudación de la sesión;
- ServerInit , enviado por el servidor como respuesta, contiene su propio certificado, el conjunto de cifrado elegido y, opcionalmente, un ticket de reanudación cifrado;
- ServerFinished , enviado por el servidor (concatenado al mensaje anterior en la implementación predeterminada de ALTS), y contiene un autenticador de handshake, es decir, HMAC sobre una cadena de bits conocida utilizando la clave de sesión calculada;
- ClientFinished , enviado por el cliente, contiene un autenticador de handshake, similar al de ServerFinished .
Una vez que ambas partes calculan la clave de sesión ( registrar el protocolo en el documento técnico), pueden comenzar a cifrar el tráfico con el algoritmo de cifrado simétrico AES de 128 bits , utilizando principalmente GCM como modo de operación . En máquinas más antiguas, se utilizó un VCM desarrollado por Google [ 7 ] . [ 8 ]
El protocolo de enlace se verificó utilizando la herramienta de verificación formal ProVerif . [ 9 ]
Reanudación de la sesión
Para evitar repetir operaciones computacionalmente costosas, ALTS admite la reanudación de sesiones. Los tickets de reanudación son creados por el servidor o el cliente y pueden usarse en el protocolo de enlace si ambas partes poseen el mismo ticket de reanudación, indexado por un identificador de reanudación . El secreto de reanudación se usa para derivar la siguiente clave de sesión, el autenticador y el ticket/identificador de reanudación encapsulado (independiente).
Secreto perfecto hacia adelante
La confidencialidad directa perfecta (PFS) no está habilitada de forma predeterminada en ALTS; sin embargo, es compatible. En lugar de utilizar un algoritmo PFS inherente, ALTS logra PFS mediante la rotación frecuente de los certificados, que tienen una vida útil corta (20 o 48 minutos; véase [ 8 ] ). Además, si PFS está habilitado, también lo está para la reanudación de la sesión, al derivar las claves de cifrado del ticket de reanudación mediante una función pseudoaleatoria .
Véase también
Enlaces externos
- Documento técnico de ALTS
Referencias
- ↑ "Autenticación ALTS" . gRPC . Consultado el 30 de abril de 2024 .
- 1 2 "Seguridad de transporte de capa de aplicación" . Google Cloud . Consultado el 18 de noviembre de 2023 .
- ↑ Sheridan, Kelly (13 de diciembre de 2023). "Google arroja luz sobre las prácticas de cifrado de datos" . Dark Reading . Recuperado el 11 de diciembre de 2023 .
- ↑ "Google detalla cómo protege los datos dentro de su infraestructura | SecurityWeek.com" . www.securityweek.com . 14 de diciembre de 2023. Consultado el 11 de diciembre de 2023 .
- ↑ Rescorla, Eric; Dierks, Tim (agosto de 2023). "El protocolo de seguridad de la capa de transporte (TLS) versión 1.2" . tools.ietf.org . Consultado el 18 de noviembre de 2023 .
- ↑ "Autenticación, integridad y cifrado de servicio a servicio § Protocolo ALTS" . Google Cloud . Consultado el 18 de noviembre de 2023 .
- ↑ Knapp, Ed (2023). "AES-VCM, una construcción AES-GCM que utiliza una función hash universal basada en enteros" . ai.google . Recuperado el 18 de noviembre de 2023 .
- 1 2 "Cifrado en tránsito en Google Cloud" . Google Cloud . Consultado el 18 de noviembre de 2023 .
- ↑ "ProVerif: Verificador de protocolo criptográfico en el modelo formal" . prosecco.gforge.inria.fr . Consultado el 18 de noviembre de 2023 .
- Llamada a procedimiento remoto
- protocolos criptográficos
- protocolos de la capa de aplicación
- Seguridad de la capa de transporte