Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Les commandes entre les hôtes ou AWS KMS opérateurs du service et eux HSMs sont sécurisées par le biais de deux mécanismes décrits dans Sessions authentifiées : une méthode de demande signée par quorum et une session authentifiée utilisant un protocole hôte de service HSM.
Les commandes signées par quorum sont conçues de telle sorte qu'aucun opérateur ne puisse modifier les protections de sécurité critiques qu'elles fournissent. HSMs 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 liées au client sont sécurisées dans l'ensemble de l' AWS infrastructure.
Établissement de clé
Pour sécuriser les communications internes, AWS KMS utilise deux méthodes d'établissement 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)
La deuxième méthode d'établissement de clé est C (2, 2, ECC, DH)
Limite de sécurité des clés HSM
La limite de sécurité intérieure de AWS KMS est le 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 par quorum sont émises par les opérateurs pour. HSMs 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.
Pour présenter les concepts, supposons qu'il existe un ensemble authentique de clés et de rôles publics {QOSs} de l'opérateur, et un ensemble de règles de quorum QR = {Commandi, Rule{i, t}} où chaque règle est un ensemble de rôles et le nombre minimum N {Role, N}. t 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 {QOSs} 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 Sig1 = Sign(dOp1, Command). Un second opérateur signe également la commande Sig2 = Sign(dOp2, Command). Le message doublement signé est envoyé à une clé HSM pour exécution. La clé HSM effectue les tâches suivantes :
-
Pour chaque signature, il extrait la clé publique du signataire de l'état du domaine et vérifie la signature sur la commande.
-
Elle vérifie que l'ensemble des signataires satisfait à une règle pour la commande.
Sessions authentifiées
Vos principales opérations s'exécutent entre les AWS KMS hôtes orientés vers l'extérieur et le HSMs. 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 session entre les hôtes du service et le. HSMs 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 de signature d'identité (DHosi, QHOSi) et une copie authentique des « clés publiques d'identité HSMs ». 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.
-
Un hôte de service génère une paire de clés éphémères ECDH (d)1, Q.1) et la signe avec sa clé d'identité Sig1 = Sig(dOS, Q1).
-
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)2, Q.2). Il complète ensuite la recommandation pour ECDH-key-exchange les schémas d'établissement de clés par paires utilisant la cryptographie à logarithme discret (révisée)
pour former 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é Sig2 = Sign(dHSK, (Q2, ESK, EKT)). -
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.
