Seguridad de la comunicación interna

Los comandos entre los anfitriones del servicio o los operadores de AWS KMS y los HSM se protegen a través de dos mecanismos que se muestran en Sesiones autenticadas: un método de solicitud de firma con quórum y una sesión autenticada mediante un protocolo de anfitrión de servicio de HSM.

Los comandos firmados con quórum están diseñados para que ningún operador pueda modificar las protecciones de seguridad fundamentales que proporcionan los HSM. Los comandos que se ejecutan en las sesiones autenticadas ayudan a garantizar que solo los operadores de servicio autorizados puedan realizar operaciones con claves de KMS. Toda la información secreta vinculada al cliente se protege a través de la infraestructura de AWS.

Establecimiento de claves

Para asegurar las comunicaciones internas, AWS KMS utiliza dos métodos de establecimiento de clave diferentes. El primero se define como C (1, 2, ECC DH) en la Recomendación para los esquemas de establecimiento de claves por pares que utilizan criptografía de logaritmos discretos (Revisión 2). Este esquema tiene un iniciador con una clave de firma estática. El iniciador genera y firma una clave de ephemeral elliptic curve Diffie-Hellman (ECDH, curva elíptica de Diffie-Hellman efímera), dirigida a un destinatario con una clave de acuerdo de ECDH estática. Este método utiliza dos claves estáticas y dos claves efímeras, cada una mediante el uso de ECDH. Esa es la derivación de la etiqueta C (1, 2, ECC DH). Este método a veces se denomina ECDH directa.

El segundo método de establecimiento de claves es C (2, 2, ECC, DH). En este esquema, ambas partes tienen una clave de firma estática y generan, firman e intercambian una clave de ECDH efímera. Este método utiliza dos claves estáticas y dos claves efímeras, cada una mediante el uso de ECDH. Esa es la derivación de la etiqueta C (2, 2, ECC, DH). Este método a veces se denomina ECDH efímero o ECDHE. Todas las claves ECDH se generan en la curva secp384r1 (NIST-P384).

Límite de seguridad del HSM

El límite de seguridad interno de AWS KMS es el HSM. El HSM tiene una interfaz propietaria y ninguna otra interfaz de activación física en su estado operativo. Un HSM operativo se aprovisionará durante la inicialización con las claves criptográficas necesarias para establecer su rol en el dominio. Los materiales criptográficos sensibles del HSM solo se almacenan en la memoria volátil y se borran cuando el HSM sale del estado operativo, incluidos los bloqueos o reinicios previstos o no intencionadas.

Las operaciones de la API del HSM se autentican mediante comandos individuales o mediante una sesión confidencial mutuamente autenticada establecida por un anfitrión de servicio.

Comandos firmados por quórum

Los operadores emiten los comandos firmados por quórum a los HSM. En esta sección se describe cómo se crean, firman y autentican los comandos basados en quórum. Estas reglas son bastante simples. Por ejemplo, el comando Foo requiere dos miembros del rol Bar para que lo autentique. Hay tres pasos en la creación y verificación de un comando basado en quórum. El primer paso es la creación inicial del comando; el segundo es el envío a operadores adicionales para firmar y el tercero es la verificación y ejecución.

Con el fin de presentar los conceptos, suponga que existe un conjunto auténtico de claves públicas y roles del operador {QOS_s} y un conjunto de reglas de quórum QR = {Command_i, Rule_{{i, t}}} donde cada regla es un conjunto de roles y un número mínimo N {Role_t, N_t}. A fin de que un comando satisfaga la regla de quórum, el conjunto de datos del comando debe estar firmado por un conjunto de operadores enumerados en {QOS_s} de manera que cumplan con una de las reglas enumeradas para ese comando. Como se mencionó anteriormente, el conjunto de reglas de quórum y operadores se almacenan en el estado de dominio y el token de dominio exportado.

En la práctica, un firmante inicial firma el comando Sig₁ = Sign(dO_p1, Command) . Un segundo operador también firma el comando Sig₂ = Sign(dO_p2, Command) . El mensaje con doble firma se envía a un HSM para su ejecución. El HSM realiza las siguientes tareas:

1. Para cada firma, extrae la clave pública del firmante del estado del dominio y verifica la firma en el comando.

2. Comprueba que el conjunto de firmantes cumpla una regla para el comando.

Sesiones autenticadas

Las operaciones de clave se ejecutan entre los anfitriones de AWS KMS externos y los HSM. Estos comandos se refieren a la creación y la utilización de claves criptográficas y a la generación segura de números aleatorios. Los comandos se ejecutan a través de un canal autenticado por sesión entre los anfitriones del servicio y los HSM. Además de la necesidad de autenticidad, estas sesiones requieren confidencialidad. Los comandos que se ejecutan en estas sesiones incluyen la devolución de claves de datos de texto sin cifrar y mensajería descifrada destinados a usted. Para garantizar que estas sesiones no se puedan subvertir mediante man-in-the-middle ataques, las sesiones se autentican.

Este protocolo realiza un acuerdo de clave de ECDHE mutuamente autenticado entre el HSM y el anfitrión de servicio. El anfitrión de servicio inicia el intercambio y el HSM lo completa. El HSM también devuelve una session key (SK, clave de sesión) cifrada por la clave negociada y un token de clave exportado que contiene la clave de sesión. El token de clave exportado contiene un periodo de validez, después del cual el anfitrión de servicio debe renegociar una clave de sesión.

Un anfitrión de servicio es miembro del dominio y tiene un par de claves de firma de identidad (dHOS_i, QHOS_i) y una copia auténtica de las claves públicas de identidad de los HSM. Utiliza el conjunto de claves de firma de identidad para negociar de forma segura una clave de sesión que se puede utilizar entre el anfitrión de servicio y cualquier HSM del dominio. Los tokens de clave exportados tienen un periodo de validación asociado a ellos, después del cual se debe negociar una nueva clave.

El proceso comienza con el reconocimiento del anfitrión de servicio de que requiere una clave de sesión para enviar y recibir flujos de comunicación sensibles entre sí y un miembro del HSM del dominio.

1. Un anfitrión de servicio genera un par de claves efímeras de ECDH (d₁, Q₁) y lo firma con la clave de identidad Sig1 = Sign(dOS, Q₁).

2. El HSM verifica la firma en la clave pública recibida mediante el token de dominio actual y crea un par de claves efímeras de ECDH (d₂, Q₂). Luego completa el intercambio de claves de ECDH según la Recomendación para esquemas de establecimiento de claves por pares que utilizan criptografía de logaritmo discreta (revisada) con el fin de formar una clave AES-GCM de 256 bits negociada. El HSM genera una nueva clave de sesión AES-GCM de 256 bits. Cifra la clave de sesión con la clave negociada para formar la encrypted session key (ESK, clave de sesión cifrada). También cifra la clave de sesión bajo la clave de dominio como un token de clave exportado (EKT). Finalmente, firma un valor de retorno con el par de claves de identidad Sig₂ = Sign(dHSK, [Q₂, ESK, EKT]).

3. El anfitrión de servicio verifica la firma en las claves recibidas mediante el token de dominio actual. Luego, el anfitrión de servicio completa el intercambio de claves de ECDH según la Recomendación para esquemas de establecimiento de claves por pares que utilizan criptografía de logaritmo discreta (revisada). A continuación, descifra la ESK a fin de obtener la clave de sesión (SK).

Durante el periodo de validación del EKT, el anfitrión de servicio puede utilizar la clave de sesión negociada SK para enviar comandos cifrados sobre el HSM. Todos los service-host-initiated comandos de esta sesión autenticada incluyen el EKT. El HSM responde con la utilización de la misma clave de sesión negociada SK.