Sécurité des communications internes

Les commandes entre les hôtes de service ou AWS KMS les opérateurs et les clés HSM sont sécurisées à l'aide de deux mécanismes décrits dans Sessions authentifiées : une méthode de requête signée en quorum et une session authentifiée à l'aide d'un protocole hôte HSM Service.

Les commandes signées en quorum sont conçues de manière à ce qu'aucun opérateur ne puisse modifier les protections de sécurité essentielles fournies par les clés HSM. Les commandes qui s'exécutent sur les sessions authentifiées permettent de garantir que seuls les opérateurs de service autorisés peuvent effectuer des opérations impliquant des clés KMS. Toutes les informations secrètes associées au client sont sécurisées dans l'AWS infrastructure.

Établissement de clé

Afin de sécuriser les communications internes, AWS KMS utilise deux méthodes d'établissement de clés différentes. La première est définie comme C (1, 2, ECC DH) dans la Recommandation pour les systèmes d'établissement de clés par paires utilisant la cryptographie par logarithme discret (révision 2). Ce système dispose d'un initiateur avec une clé de signature statique. L'initiateur génère et signe une clé Diffie-Hellman (ECDH) à courbe elliptique éphémère, conçue pour un destinataire disposant d'une clé d'accord ECDH statique. Cette méthode utilise une seule clé éphémère et deux clés statiques utilisant ECDH. Ceci est la dérivation de l'étiquette C (1, 2, ECC DH). Cette méthode est parfois appelée « ECDH à passage unique ».

La deuxième méthode d'établissement de clé est C (2, 2, ECC, DH). Dans ce système, les deux parties disposent d'une clé de signature statique, et elles génèrent, signent et échangent une clé ECDH éphémère. Cette méthode utilise deux clés statiques et deux clés éphémères, chacune utilisant ECDH. Ceci est la dérivation de l'étiquette C (2, 2, ECC, DH). Cette méthode est parfois appelée « ECDH éphémère » ou « ECDHE ». Toutes les clés ECDH sont générées sur la courbe secp384r1 (NIST-P384).

Limite de sécurité des clés HSM

La limite de sécurité interne de AWS KMS est la clé HSM. La clé HSM est dotée d'une interface propriétaire et ne possède aucune autre interface physique active dans son état opérationnel. Une clé HSM opérationnelle est provisionnée lors de son initialisation avec les clés cryptographiques nécessaires à l'établissement de son rôle dans le domaine. Les éléments cryptographiques sensibles de la clé HSM sont uniquement stockés dans une mémoire volatile et effacés que lorsque la clé HSM quitte l'état opérationnel, notamment lors des arrêts ou réinitialisations prévus ou non.

Les opérations de l'API de la clé HSM sont authentifiées soit par des commandes individuelles, soit par une session confidentielle mutuellement authentifiée établie par un hôte de service.

Commandes signées en quorum

Les commandes signées en quorum sont émises par les opérateurs aux clés HSM. Cette section décrit comment les commandes basées sur le quorum sont créées, signées et authentifiées. Ces règles sont assez simples. Par exemple, la commande Foo nécessite deux membres du rôle Bar pour être authentifiée. La création et la vérification d'une commande basée sur le quorum comporte trois étapes. La première étape est la création initiale de la commande ; la seconde est la soumission à d'autres opérateurs pour signature ; et la troisième est la vérification et l'exécution.

Aux fins de l'introduction des concepts, supposons qu'il existe un ensemble authentique de clés publiques et de rôles de l'opérateur {QOS_s}, et un ensemble de règles de quorum QR = {Command_i, Rule_{{i, t}}} où chaque Règle est un ensemble de rôles et un nombre minimum N {Role_t, N_t}. Afin qu'une commande respecte la règle de quorum, le jeu de données de la commande doit être signé par un ensemble d'opérateurs répertoriés dans {QOS_s} de façon à ce qu'ils répondent à l'une des règles répertoriées pour cette commande. Comme mentionné précédemment, l'ensemble des règles et des opérateurs du quorum sont stockés dans l'état du domaine et dans le jeton de domaine exporté.

Dans la pratique, un signataire initial signe la commande Sig₁ = Sign(dO_p1, Command). Un second opérateur signe également la commande Sig₂ = Sign(dO_p2, Command). Le message doublement signé est envoyé à une clé HSM pour exécution. La clé HSM effectue les tâches suivantes :

1. Pour chaque signature, elle extrait la clé publique du signataire de l'état du domaine et vérifie la signature sur la commande.

2. Elle vérifie que l'ensemble des signataires satisfait à une règle pour la commande.

Sessions authentifiées

Vos opérations de clé s'exécutent entre les AWS KMS hôtes externes et les clés HSM. Ces commandes concernent la création et l'utilisation de clés cryptographiques et la génération sécurisée de nombres aléatoire. Les commandes s'exécutent sur un canal authentifié par une session entre les hôtes de service et les clés HSM. Outre le besoin d'authenticité, ces sessions exigent la confidentialité. Les commandes exécutées sur ces sessions comprennent le retour de clés de données en texte clair et de messages déchiffrés qui vous sont destinés. Pour s'assurer que ces sessions ne peuvent pas être subverties par man-in-the-middle des attaques, les sessions sont authentifiées.

Ce protocole exécute un accord de clé ECDHE mutuellement authentifié entre la clé HSM et l'hôte de service. L'échange est initié par l'hôte de service et achevé par la clé HSM. La clé HSM renvoie également une clé de session (SK) chiffrée par la clé négociée et un jeton de clé exporté contenant la clé de session. Le jeton de clé exporté comporte une période de validité, après laquelle l'hôte de service devra renégocier une clé de session.

Un hôte de service est membre du domaine et possède une paire de clés identité-signature (DHO_i, QHOS_i) et une copie authentique des clés publiques d'identité des clés HSM. Il utilise son ensemble de clés identité-signature pour négocier en toute sécurité une clé de session qui peut être utilisée entre l'hôte de service et toute clé HSM du domaine. Les jetons de clé exportés ont une période de validité qui leur est associée, après laquelle une nouvelle clé devra être négociée.

Le processus commence par la reconnaissance de l'hôte de service qui a besoin d'une clé de session pour envoyer et recevoir des flux de communications sensibles entre lui-même et un membre de clé HSM du domaine.

1. Un hôte de service génère une paire de clés éphémères ECDH (d)₁, Q.₁) et la signe avec sa clé d'identité Sig1 = Sig(dOS, Q₁).

2. La clé HSM vérifie la signature sur la clé publique reçue à l'aide de son jeton de domaine actuel et crée une paire de clés éphémères ECDH (d)₂, Q.₂). Elle termine ensuite l'échange de clés ECDH conformément à la Recommandation pour les systèmes d'établissement de clés par paires utilisant la cryptographie par logarithme discret (révisée) afin de constituer une clé AES-GCM 256 bits négociée. La clé HSM génère une nouvelle clé de session AES-GCM 256 bits. Elle chiffre la clé de session à l'aide de la clé négociée afin de constituer la clé de session chiffrée (ESK). Elle chiffre également la clé de session sous la clé de domaine en tant que jeton de clé exporté EKT. Enfin, elle signe une valeur de retour à l'aide de sa paire de clés d'identité Sig₂ = Sign(dHSK, (Q₂, ESK, EKT)).

3. L'hôte de service vérifie la signature sur les clés reçues à l'aide de son jeton de domaine actuel. L'hôte de service effectue ensuite l'échange de clés ECDH conformément à la Recommandation pour les systèmes d'établissement de clés par paires utilisant la cryptographie par logarithme discret (révisée). Il déchiffre ensuite la clé ESK afin d'obtenir la clé de session SK.

Au cours de la période de validité dans l'EKT, l'hôte de service peut utiliser la clé de session négociée SK pour envoyer des commandes chiffrées par enveloppe à la clé HSM. Chaque service-host-initiated commande de cette session authentifiée inclut l'EKT. La clé HSM répond en utilisant la même clé de session SK négociée.