Le Blog Amazon Web Services
Signature numérique avec les clés asymétriques d’AWS KMS
AWS Key Management Service (AWS KMS) prend en charge les clés asymétriques. Vous pouvez créer, gérer et utiliser des paires de clés publiques / privées pour protéger vos données d’application à l’aide des nouvelles API disponibles via le kit AWS SDK. Semblables aux fonctionnalités de clés symétriques proposées dans AWS KMS, les clés asymétriques peuvent être générées en tant que clés principales client (Customer Master Key – CMK) où la partie privée ne quitte jamais le service, ou en tant que clé de données où la partie privée est renvoyée à votre application, chiffrée à l’aide d’une CMK. La partie privée des clés CMK asymétriques est utilisée dans des modules de sécurité matérielle (Hardware Security Module – HSM) de AWS KMS, conçus pour que personne, y compris les employés AWS, ne puisse accéder au matériel de la clé en texte brut. AWS KMS prend en charge les types de clés asymétriques suivants : RSA 2048, RSA 3072, RSA 4096, ECC NIST P-256, ECC NIST P-384, ECC NIST-521 et ECC SECG P-256k1.
Nos clients nous disent qu’un cas d’utilisation populaire des clés asymétriques est la signature numérique. Dans cet article, nous allons vous présenter un exemple de signature et de vérification de fichiers à l’aide de certaines des nouvelles API et fonctionnalités d’AWS KMS.
Contexte
Une façon courante de garantir l’intégrité d’un message numérique lorsqu’il transite entre différents systèmes consiste à utiliser une signature numérique. Un expéditeur utilise un secret avec des algorithmes cryptographiques pour créer une structure de données qui est ajoutée au message d’origine. Un destinataire ayant accès à ce secret peut vérifier de manière cryptographique que le message n’a pas été altéré depuis que l’expéditeur l’a signé. Dans les cas où le destinataire n’a pas accès au même secret que celui utilisé par l’expéditeur pour la vérification, un schéma de signature numérique utilisant des clés asymétriques est utile. L’expéditeur peut rendre la partie publique de la clé disponible à n’importe quel destinataire pour vérifier la signature, mais l’expéditeur conserve le contrôle sur la création de signatures à l’aide de la partie privée de la clé. Les clés asymétriques sont utilisées pour les applications de signature numérique telles que la signature de code source de confiance, les jetons d’authentification / d’autorisation, la signature électronique de documents, les transactions de commerce électronique et la messagerie sécurisée.
AWS KMS prend en charge ce que l’on appelle les signatures numériques brutes, dans lesquelles aucune information d’identité sur le signataire n’est intégrée dans l’objet de signature. Une manière courante de joindre des informations d’identité à une signature numérique consiste à utiliser des certificats numériques. Si votre application repose sur des certificats numériques pour la signature et la vérification de la signature, nous vous recommandons de consulter AWS Certificate Manager et Private Certificate Authority. Ces services vous permettent de créer et de déployer de manière programmatique des certificats avec des clés pour vos applications pour les opérations de signature numérique. Une application courante des certificats numériques est la terminaison TLS sur un serveur Web pour sécuriser les données en transit.
Signature et vérification de fichiers avec AWS KMS
Supposons que vous disposez d’une application A qui envoie un fichier à l’application B dans votre compte AWS. Vous voulez que le fichier soit signé numériquement afin que l’application destinataire B puisse vérifier qu’il n’a pas été altéré pendant son transit. Vous voulez également vous assurer que seule l’application A peut signer numériquement les fichiers à l’aide de la clé, car vous ne voulez pas que l’application B reçoive un fichier en pensant qu’il provient de l’application A alors qu’il provenait réellement d’un autre expéditeur qui avait accès à la clé de signature. Étant donné qu’AWS KMS est conçu pour que la partie privée de la paire de clés asymétriques utilisée pour la signature ne puisse pas être utilisée en dehors du service ou par des utilisateurs non authentifiés, vous pouvez définir et appliquer des politiques afin que seule l’application A puisse signer avec la clé.
Pour commencer, l’application A soumettra soit le fichier lui-même, soit un condensé (hash) du fichier à l’API AWS KMS Sign pour signature avec une clé CMK asymétrique. Si le fichier est inférieur à 4 Ko, AWS KMS calculera un hash pour vous dans le cadre de l’opération de signature. Si le fichier est supérieur à 4 Ko, vous devez envoyer uniquement le hash que vous avez créé localement et vous devez indiquer à AWS KMS que vous transmettez un hash dans le paramètre MessageType de la requête. Vous pouvez utiliser l’une des nombreuses fonctions de hachage de votre environnement local pour créer un hash du fichier, mais sachez que l’application réceptrice du compte B devra être en mesure de calculer le hash en utilisant la même fonction de hachage afin de vérifier l’intégrité du fichier. Dans mon exemple, j’utilise SHA256 comme fonction de hachage. Une fois le hash créé, AWS KMS utilise la partie privée de la clé CMK asymétrique pour chiffrer le hash à l’aide de l’algorithme de signature spécifié dans la requête d’API. Le résultat est un objet de données binaire, que nous appellerons «la signature» tout au long de cet article.
Une fois que l’application B reçoit le fichier avec la signature, elle doit créer un hash du fichier. Elle transmet ensuite à l’API Verify ce hash nouvellement généré, l’enveloppe de signature, l’algorithme de signature utilisé et le keyId de la clé CMK. AWS KMS utilise la clé publique correspondante de la clé CMK avec l’algorithme de signature spécifié dans la requête pour vérifier la signature. Au lieu de soumettre la signature à l’API Verify, l’application B pourrait vérifier la signature localement en acquérant la clé publique. Cela pourrait être une option intéressante si l’application B ne disposait pas d’un moyen d’authentification AWS valide pour faire une requête à AWS KMS. Cependant, cette méthode nécessite que l’application B ait accès aux algorithmes cryptographiques nécessaires et ait préalablement reçu la partie publique de la CMK asymétrique. Dans mon exemple, l’application B s’exécute dans le même compte AWS que l’application A, elle peut donc obtenir les informations d’identification AWS nécessaires pour effectuer la requête de vérification via l’API. Nous décrirons comment vérifier les signatures à l’aide des deux méthodes de manière un peu plus détaillée plus tard dans l’article.
Création de clés de signature et configuration des autorisations sur les clés
Pour commencer, vous devez créer une clé CMK asymétrique. Lors de l’appel de l’API CreateKey, vous transmettez l’une des valeurs asymétriques du paramètre CustomerMasterKeySpec. Dans cet exemple, nous choisissons une spécification de clé ECC_NIST_P384 car les clés utilisées avec les algorithmes de courbe elliptique ont tendance à être plus efficaces que celles utilisées avec les algorithmes basés sur RSA.
Dans le cadre de la création de votre clé CMK asymétrique, vous devez attacher une politique d’autorisation à la clé pour contrôler les opérations cryptographiques que les mandataires (principals) AWS représentant les applications A et B peuvent utiliser. Une bonne pratique consiste à utiliser un mandataire IAM différent pour chaque application afin de réduire les autorisations et l’audit. Dans ce cas, vous voulez que l’application A ne puisse que signer des fichiers et que l’application B ne puisse que les vérifier. Nous supposons que chacune de ces applications s’exécute sur une instance Amazon EC2, et nous allons donc créer quelques rôles IAM.
- Le rôle IAM pour l’application A (SignRole) recevra l’authorisation de signature
kms:Signdans la stratégie de clé CMK - Le rôle IAM pour l’application B (VerifyRole) recevra l’autorisation de vérification
kms:Verifydans la stratégie de clé CMK
Le document de stratégie de clé CMK pour autoriser la signature doit ressembler à ceci (remplacez la valeur d’ID de compte <111122223333> par la vôtre):
Le document de stratégie de clé CMK permettant la vérification doit ressembler à ceci (remplacez la valeur d’ID de compte <111122223333> par la vôtre):
Workflow de signature
Une fois la clé CMK asymétrique et les rôles IAM créés, vous êtes prêt à signer votre fichier. L’application A créera un hash de message (digest) du fichier et adressera une demande de signature à AWS KMS avec l’identifiant de la clé CMK asymétrique et l’algorithme de signature. La commande CLI pour ce faire est indiquée ci-dessous. Remplacez le paramètre key-id <1234abcd-12ab-34cd-56ef-1234567890ab> par celui de votre CMK.
Nous choisissons l’algorithme de signature ECDSA_SHA_256 pour cet exemple. Consultez la spécification de l’API de signature pour une liste complète des algorithmes de signature pris en charge.
Après avoir vérifié que l’appel d’API est autorisé par les informations d’identification disponibles pour SignRole, KMS génère une signature autour du hash et renvoie le keyId de la clé CMK, la signature et l’algorithme de signature. Les valeurs des champs <aws region id>, <111122223333>, et <1234abcd-12ab-34cd-56ef-1234567890ab>, correspondront aux valeurs des identifiants de votre région AWS, de votre compte AWS et de votre CMK, respectivement.
Workflow de vérification 1 – Appel de l’API verify
Une fois que l’application B reçoit le fichier et la signature, elle calcule le hash SHA-256 sur la copie du fichier qu’elle a reçu. Elle envoie ensuite une demande de vérification à AWS KMS, en transmettant ce nouveau hash, la signature qu’elle a reçue de l’application A, l’algorithme de signature et le keyId de la clé CMK. La commande CLI pour ce faire est indiquée ci-dessous. Remplacez le paramètre key-id <1234abcd-12ab-34cd-56ef-1234567890ab>par le keyId spécifique de votre CMK.
Après avoir validé que la demande de vérification est autorisée, AWS KMS vérifie la signature en déchiffrant d’abord la signature à l’aide de la partie publique de la clé CMK. Il compare ensuite le résultat déchiffré au hash reçu dans la demande de vérification. S’ils correspondent, il renvoie un booléen SignatureValid avec la valeur “True” (Vrai), indiquant que le hash d’origine créé par l’expéditeur correspond au hash créé par le destinataire. Les valeurs des champs <aws region id>, <111122223333>, et <1234abcd-12ab-34cd-56ef-1234567890ab>, correspondront aux valeurs des identifiants de votre région AWS, de votre compte AWS et de votre CMK, respectivement.
Étant donné que le hash d’origine est unique au fichier, le destinataire peut savoir que le fichier n’a pas été altéré pendant le transit.
L’un des avantages de l’utilisation de l’API de vérification de AWS KMS est que l’appelant n’a pas à connaitre la clé publique spécifique correspondant à la clé privée utilisée pour créer la signature; l’appelant n’a qu’à connaître le keyId de la clé CMK et l’algorithme de signature utilisés. De plus, comme toutes les demandes adressées à AWS KMS sont consignées dans AWS CloudTrail, vous pouvez vérifier que les opérations de signature et de vérification ont toutes deux été exécutées comme prévu. Consultez la spécification de l’API Verify pour plus de détails sur les paramètres disponibles.
Workflow de vérification 2 – Vérification locale à l’aide de la clé publique
Outre l’utilisation directe de l’API de vérification d’AWS KMS, vous pouvez choisir de récupérer la clé publique de la clé CMK à l’aide de l’API AWS KMS GetPublicKey et de vérifier la signature localement. Vous pouvez envisager ce workflow si l’application B a besoin de vérifier plusieurs signatures à un débit élevé et que vous ne souhaitez pas appeler à chaque fois l’API Verify d’AWS KMS. Dans cette méthode, l’application B envoie une requête GetPublicKey à AWS KMS pour récupérer la clé publique. La commande CLI pour ce faire est ci-dessous. Remplacez le paramètre key-id <1234abcd-12ab-34cd-56ef-1234567890ab>par le keyId de votre clé CMK.
Notez que l’application B aura besoin d’autorisations pour envoyer une requête GetPublicKey à AWS KMS. Le document de stratégie de clé CMK pour permettre à l’identité VerifyRole de télécharger la clé publique doit ressembler à ceci (La valeur du champ <111122223333> correspondra à la valeur de l’ID de votre compte AWS):
Une fois que l’application B a la clé publique, elle peut utiliser votre fournisseur cryptographique préféré pour effectuer la vérification de la signature localement. L’application B doit garder une trace de la clé publique et de l’algorithme de signature utilisés pour chaque objet de signature qu’elle vérifiera localement. L’utilisation d’une clé publique incorrecte ne parviendra pas à valider la signature de l’application A et échouera lors de la vérification de signature.
Disponibilité et prix
Les clés asymétriques et les opérations dans AWS KMS sont désormais disponibles dans toutes les régions AWS à l’exception des régions Chine (Pékin) et Chine (Ningxia). Les informations de tarification de cette nouvelle fonctionnalité sont disponibles sur la page de tarification AWS KMS.
Résumé
Nous avons vu un exemple simple de la façon dont vous pouvez utiliser les nouvelles API AWS KMS pour signer et vérifier numériquement un fichier arbitraire. En demandant à AWS KMS de générer et de stocker la partie privée de la clé asymétrique, vous pouvez limiter l’utilisation de la clé pour la signature uniquement aux mandataires (principals) IAM que vous définissez. Les jetons d’ID OIDC, les jetons d’accès OAuth 2.0, les documents, les fichiers de configuration, les messages de mise à jour du système et les journaux d’audit ne sont que quelques-uns des types d’objets que vous voudrez peut-être signer et vérifier à l’aide de cette fonctionnalité.
Vous pouvez également effectuer des opérations de chiffrement et de déchiffrement sous des clés CMK asymétriques dans AWS KMS au lieu d’utiliser les clés CMK symétriques disponibles depuis le lancement du service. De la même manière que vous pouvez demander à AWS KMS de générer des clés symétriques pour une utilisation locale dans votre application, vous pouvez demander à AWS KMS de générer et de renvoyer des paires de clés asymétriques à usage local pour chiffrer et déchiffrer les données. Pour plus d’informations sur la prise en charge des clés asymétriques, consultez la page de documentation AWS KMS.
Si vous avez des questions sur la fonctionnalité de clé asymétrique, veuillez démarrer un nouveau fil de discussion sur le forum de discussion AWS KMS.
Article original rédigé en anglais par Raj Copparapu, Senior Product Manager chez AWS, et traduit par Djamel Bourokba, Solutions Architect chez AWS France, LinkedIn.