Cómo funciona AWS Signature Version 4 (SigV4) - La mecánica criptográfica de la autenticación de APIs
Un análisis criptográfico profundo del proceso de firma SigV4 en 4 pasos (solicitud canónica, cadena para firmar, derivación de clave, firma), URLs prefirmadas y SigV4A para multi-región.
Por qué es necesaria la firma
Cada solicitud API a AWS debe estar autenticada para verificar la identidad del solicitante y garantizar que la solicitud no ha sido alterada en tránsito. A diferencia de los tokens Bearer simples, SigV4 firma criptográficamente cada solicitud individual, proporcionando protección contra ataques de repetición (mediante la inclusión de marca temporal), verificación de integridad del mensaje (cualquier modificación invalida la firma) y autenticación sin transmitir el secreto (la clave secreta nunca se envía por la red). Este diseño permite que las solicitudes transiten por redes no confiables sin comprometer la seguridad.
El proceso de firma en 4 pasos
El proceso SigV4 consta de 4 pasos secuenciales. Paso 1: Crear la solicitud canónica, que normaliza el método HTTP, la URI, los parámetros de consulta, los encabezados y el hash del cuerpo en un formato determinista. Paso 2: Crear la cadena para firmar (String to Sign), que combina el algoritmo, la marca temporal, el ámbito de credenciales y el hash de la solicitud canónica. Paso 3: Derivar la clave de firma mediante una cadena de operaciones HMAC-SHA256. Paso 4: Calcular la firma aplicando HMAC-SHA256 con la clave derivada sobre la cadena para firmar. El resultado se incluye en el encabezado Authorization o como parámetros de consulta.
Derivación de clave de firma - Por qué HMAC en múltiples etapas
La derivación de clave utiliza 4 operaciones HMAC encadenadas: HMAC(HMAC(HMAC(HMAC("AWS4" + SecretKey, fecha), región), servicio), "aws4_request"). Este diseño multi-etapa proporciona aislamiento temporal (las claves derivadas son válidas solo para un día específico), aislamiento regional (una clave derivada para us-east-1 no funciona en eu-west-1), aislamiento de servicio (una clave para S3 no funciona para DynamoDB) y limitación de daño (si se compromete una clave derivada, el impacto se limita a un día/región/servicio específico). Los SDKs de AWS cachean las claves derivadas durante el día para evitar recalcularlas en cada solicitud.
URLs prefirmadas - Incorporando la firma en la URL
Las URLs prefirmadas permiten compartir acceso temporal a recursos sin exponer credenciales. En lugar de incluir la firma en el encabezado Authorization, se incorpora como parámetros de consulta (X-Amz-Algorithm, X-Amz-Credential, X-Amz-Date, X-Amz-Expires, X-Amz-Signature). El parámetro Expires define la validez (máximo 7 días para S3). Esto permite generar URLs de descarga temporales para objetos S3 privados, compartir acceso sin requerir credenciales AWS del receptor y limitar el acceso tanto temporal como por recurso específico.
SigV4A - Nuevo método de firma para multi-región
SigV4A (Signature Version 4 Asymmetric) extiende SigV4 para soportar solicitudes que abarcan múltiples regiones. Mientras SigV4 incluye la región en el ámbito de credenciales (limitando cada firma a una región), SigV4A utiliza criptografía asimétrica (ECDSA) que permite firmar solicitudes válidas para múltiples regiones simultáneamente. Esto es esencial para S3 Multi-Region Access Points y otros servicios que enrutan solicitudes entre regiones. SigV4A utiliza un par de claves efímeras derivadas de las credenciales del usuario, manteniendo la compatibilidad con el modelo de seguridad existente.