Sécurité des communications internes

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 HSM protocole hôte -service.

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 exécutées sur les sessions authentifiées permettent de garantir que seuls les opérateurs de service autorisés peuvent effectuer des opérations impliquant des KMS clés. 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. Le premier est défini comme C (1, 2, ECC DH) dans la Recommandation pour les schémas d'établissement de clés par paires utilisant la cryptographie à 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, destinée à un destinataire doté d'une clé d'accord statique. ECDH Cette méthode utilise une clé éphémère et deux clés statiques. ECDH C'est la dérivation du label C (1, 2, ECC DH). Cette méthode est parfois appelée « one-pass ECDH ».

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

HSMlimite de sécurité

La limite de sécurité intérieure de AWS KMS est leHSM. HSMIl possède une interface propriétaire et aucune autre interface physique active dans son état de fonctionnement. Un opérateur HSM est approvisionné lors de l'initialisation avec les clés cryptographiques nécessaires pour établir son rôle dans le domaine. Le matériel cryptographique sensible du HSM est uniquement stocké dans une mémoire volatile et effacé lorsqu'il sort de l'HSMétat opérationnel, y compris lors d'arrêts ou de réinitialisations intentionnels ou involontaires.

Les HSM API opérations sont authentifiées soit par des commandes individuelles, soit par le biais d'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 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 le nombre minimum N {Role_t, N}. _t Pour qu'une commande satisfasse à la règle du quorum, le jeu de données de commandes doit être signé par un ensemble d'opérateurs listés dans {QOS_s} de telle sorte 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é à un HSM pour exécution. HSMEffectue les opérations suivantes :

1. Pour chaque signature, il 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 principales opérations s'exécutent entre les AWS KMS hôtes orientés vers l'extérieur et leHSMs. 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 ECDHE clé authentifié mutuellement entre l'hôte HSM et l'hôte du service. L'échange est initié par l'hôte du service et terminé par leHSM. Le renvoie HSM é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é (d HOS_i, QHOS_i) et une copie authentique des « clés publiques d'identité HSMs ». Il utilise son jeu de clés de signature d'identité pour négocier en toute sécurité une clé de session qui peut être utilisée entre l'hôte du service et n'importe quel membre du HSM 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 par l'hôte du service qu'il a besoin d'une clé de session pour envoyer et recevoir des flux de communication sensibles entre lui-même et un HSM membre du domaine.

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

2. HSMVérifie la signature sur la clé publique reçue à l'aide de son jeton de domaine actuel et crée une ECDH paire de clés éphémères (d₂, Q). ₂ Il complète ensuite la recommandation ECDH-key-exchange pour les schémas d'établissement de clés par paires utilisant la cryptographie à logarithme discret (révisée) pour former une clé négociée de 256 AES bits. GCM HSMGénère une nouvelle clé de GCM session de 256 bitsAES. Il chiffre la clé de session avec la clé négociée pour former la clé de session cryptée (ESK). Il chiffre également la clé de session sous la clé de domaine en tant que jeton EKTde clé exporté. Enfin, il signe une valeur de retour avec 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 du service effectue ensuite l'échange de ECDH clés conformément à la recommandation pour les schémas d'établissement de clés par paires utilisant la cryptographie à logarithme discret (révisée). Il déchiffre ensuite le ESK pour obtenir la clé de session SK.

Pendant la période de validité du EKT, l'hôte du service peut utiliser la clé de session négociée SK pour envoyer des commandes cryptées par enveloppe au. HSM Chaque service-host-initiated commande de cette session authentifiée inclut le EKT. Les HSM réponses utilisent la même clé de session négociée SK.