web-dev-qa-db-fra.com

Quels usages clés sont requis par chaque méthode d'échange de clés?

Je ne suis vraiment concerné que par les clés RSA, donc les méthodes d'échange sont RSA (générer une clé, la crypter et l'envoyer) et [EC] DHE_RSA (générer une clé DH [EC] éphémère, la signer et l'utiliser) pour accord clé).

L'opération réelle dans RSA est "Key Encipherment" et dans [EC]DHE_RSA c'est la signature numérique, mais ce sont deux formes d'accord clé. Alors, lesquels de "Key Encipherment", "Digital Signature" et "Key Agreement" sont nécessaires dans l'extension d'utilisation de clé pour chaque méthode? Je n'ai pu trouver cela spécifié nulle part et cela varie probablement selon l'implémentation, donc la réponse pourrait être une table par implémentation.

tlscertificatesx.509
28
Ben Jencks

L'extension Key Usage est décrite dans la section 4.2.1.3 de X.509 , avec les drapeaux possibles suivants:

  KeyUsage ::= BIT STRING {
       digitalSignature        (0),
       nonRepudiation          (1), -- recent editions of X.509 have
                            -- renamed this bit to contentCommitment
       keyEncipherment         (2),
       dataEncipherment        (3),
       keyAgreement            (4),
       keyCertSign             (5),
       cRLSign                 (6),
       encipherOnly            (7),
       decipherOnly            (8) }

Dans SSL/TLS , lorsque le certificat de serveur contient une clé RSA, alors:

  • une suite de chiffrement DHE ou ECDHE est utilisée, auquel cas la clé RSA est utilisée pour une signature (voir la section 7.4.3 de la RFC 5246: le message "Server Key Exchange"); cela exerce l'utilisation de la touche digitalSignature ;

  • ou "plain RSA" est utilisé, avec une valeur aléatoire (le secret pré-maître de 48 octets) qui est chiffrée par le client avec la clé publique du serveur (voir la section 7.4.7.1 de la RFC 5246); c'est juste dans la définition de l'indicateur d'utilisation de la clé keyEncipherment .

dataEncipherment ne s'applique pas, car ce qui est chiffré n'est pas des données directement significatives, mais une valeur qui est principalement générée de manière aléatoire et utilisée pour dériver des clés symétriques. keyAgreement ne s'applique pas non plus, car celui-ci concerne les algorithmes d'accord de clé qui ne sont pas un cas de chiffrement asymétrique (par exemple Diffie-Hellman). L'indicateur d'utilisation keyAgreement apparaîtrait dans un certificat qui contient une clé DH, pas une clé RSA. nonRepudiation n'est pas utilisé, car tout ce qui est signé dans le cadre d'un échange de clés SSL/TLS ne peut pas être utilisé comme preuve pour un tiers (il n'y a rien dans un tunnel SSL/TLS que le client pourrait enregistrer et ensuite utiliser pour convaincre un juge lorsqu'il tentera de poursuivre le serveur lui-même; les données qui sont échangées dans le tunnel ne sont pas signées par le serveur).

Pour résumer: digitalSignature pour les suites de chiffrement DHE (EC), keyEncipherment pour les suites de chiffrement RSA simples. Cependant, certaines implémentations acceptent également keyAgreement au lieu de keyEncipherment , ou nonRepudiation même si digitalSignature n'est pas défini; et certains ignoreront totalement l'extension Key Usage (même si elle est marquée comme critique). Pour une interopérabilité maximale, spécifiez les quatre indicateurs dans l'extension Key Usage.

35
Thomas Pornin