Cómo funciona la Signature Version 4 (SigV4) de AWS - El mecanismo criptográfico de la autenticación de API
Se explican desde un punto de vista criptográfico los 4 pasos (creación de la solicitud canónica, construcción de la cadena para firmar, derivación de la clave de firma y cálculo de la firma) del proceso de firma SigV4 que se usa para la autenticación de la API de AWS. También se presenta el funcionamiento de SigV4A y de las URL prefirmadas.
Por qué es necesaria la firma
Las solicitudes a la API de AWS necesitan credenciales que demuestren que el remitente de la solicitud es un usuario legítimo de AWS. Como método de autenticación, se podría pensar en incluir la clave de acceso y la clave secreta tal cual en la solicitud, pero esto es peligroso. Si la solicitud se intercepta, la clave secreta se filtra. SigV4 es un método de firma que realiza la autenticación sin incluir la clave secreta en la solicitud. Con una clave de firma derivada de la clave secreta mediante cálculos sucesivos, se calcula una firma (HMAC-SHA256) a partir del contenido de la solicitud, y esa firma se incluye en la solicitud. AWS realiza el mismo cálculo con la misma clave secreta y, si las firmas coinciden, la autenticación es correcta. La clave secreta en sí no viaja por la red. Además, la firma de SigV4 se calcula a partir de una parte de los elementos de la solicitud (el método HTTP, la URL, los encabezados incluidos en la firma y el hash del cuerpo). Por ello, si esa parte se reescribe durante el envío, la firma no coincide. Gracias a ello, se puede utilizar tanto para confirmar el remitente como para detectar manipulaciones durante el envío.
Los 4 pasos del proceso de firma
El proceso de firma de SigV4 consta de 4 pasos. El paso 1 es la creación de la solicitud canónica (Canonical Request). Se crea una cadena que concatena en un formato específico el método HTTP, la ruta de la URL, la cadena de consulta, los encabezados y el hash del cuerpo. En los encabezados, las claves se ordenan alfabéticamente y se eliminan los espacios antes y después de los valores. Con esta normalización, a partir de una misma solicitud se genera la misma solicitud canónica. El paso 2 es la construcción de la cadena para firmar (String to Sign). Se concatenan el nombre del algoritmo (AWS4-HMAC-SHA256), la marca de tiempo, el ámbito de credenciales (fecha/región/servicio/aws4_request) y el hash SHA-256 de la solicitud canónica. El paso 3 es la derivación de la clave de firma. A partir de la clave secreta, se pliegan en orden la fecha, la región y el nombre del servicio con HMAC-SHA256 para generar la clave de firma. El paso 4 es el cálculo de la firma. Con la clave de firma se calcula el HMAC-SHA256 de la cadena para firmar y se convierte en una cadena hexadecimal. Esta firma se incluye en el encabezado Authorization y se envía la solicitud.
Derivación de la clave de firma - ¿Por qué un HMAC de varias etapas?
La derivación de la clave de firma se realiza a partir de la clave secreta mediante 4 etapas de HMAC-SHA256. Son kDate = HMAC(AWS4 + SecretKey, Date), kRegion = HMAC(kDate, Region), kService = HMAC(kRegion, Service) y kSigning = HMAC(kService, aws4_request). Esta derivación en varias etapas tiene dos objetivos. El primero es limitar el alcance de la firma. Como la clave de firma está vinculada a la fecha, la región y el servicio, la clave de firma para S3 en la región de Tokio de un día determinado no se puede usar en otro día, en otra región ni en otro servicio. Aunque se filtre una clave de firma, el daño queda limitado. El segundo es hacer posible el almacenamiento en caché de la clave de firma. En las solicitudes del mismo día, a la misma región y al mismo servicio, la clave de firma es la misma. El SDK almacena en caché la clave de firma y la reutiliza hasta que cambia la fecha. Como no es necesario derivar la clave de firma a partir de la clave secreta cada vez, se puede reducir la cantidad de cálculo de la firma. En muchos casos, las solicitudes se rechazan si no llegan a AWS en un plazo de 5 minutos desde la marca de tiempo incluida en la firma. Esto es una medida contra la reutilización de firmas antiguas (ataques de repetición).
URL prefirmadas - Incrustar la firma en la URL
La URL prefirmada de S3 es una URL que incrusta la firma de SigV4 en la cadena de consulta. Quien conozca esta URL puede acceder al objeto de S3 sin credenciales de AWS. La URL prefirmada tiene un periodo de validez, que es de un máximo de 7 días (con claves de acceso de un usuario de IAM) o de un máximo de 12 horas (con credenciales temporales de STS). La cadena de consulta de una URL prefirmada incluye X-Amz-Algorithm (algoritmo de firma), X-Amz-Credential (ID de clave de acceso y ámbito de credenciales), X-Amz-Date (marca de tiempo), X-Amz-Expires (segundos del periodo de validez), X-Amz-SignedHeaders (encabezados incluidos en la firma) y X-Amz-Signature (firma). Los permisos de la URL prefirmada se evalúan en el momento en que se usa la URL, no en el momento en que se creó. Si después de generar la URL se desactiva la clave de acceso o se modifica la política de IAM, la URL deja de poder usarse.
SigV4A - Un nuevo método de firma compatible con varias regiones
Como la clave de firma de SigV4 está vinculada a una región, no es posible enviar solicitudes a varias regiones con una sola firma. Cuando existe la posibilidad de que las solicitudes se enruten a varias regiones, como en los puntos de acceso multirregión de S3, SigV4 no sirve para ese caso. SigV4A (Signature Version 4A) es una extensión introducida frente a esta restricción. SigV4A utiliza ECDSA (algoritmo de firma digital de curva elíptica) en lugar de HMAC-SHA256. Como ECDSA es criptografía asimétrica, no es necesario incluir la región en la derivación de la clave de firma. Con una sola firma se pueden enviar solicitudes a varias regiones. Actualmente, SigV4A se utiliza en los puntos de acceso multirregión de S3 y en los endpoints globales de EventBridge. El SDK y la CLI cambian automáticamente a SigV4A en las llamadas que requieren una firma multirregión, por lo que se reducen las ocasiones en que el desarrollador elige el método de firma.
Referencias (recursos oficiales de AWS)
Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.
Si esta página y la documentación oficial difieren, prevalece la documentación oficial.