Question:
Pourquoi ne devrait-on pas utiliser la même clé asymétrique pour le chiffrement que pour la signature?
Iszi
2011-01-22 02:06:42 UTC
view on stackexchange narkive permalink

Dans une réponse à une question sur RSA et PGP, PulpSpy a noté ceci:

Il est possible de générer une paire de clés RSA en utilisant GPG (pour le chiffrement et signature - vous ne devez pas utiliser la même clé pour les deux).

Quel est le raisonnement derrière cela?

Ma compréhension du chiffrement par clé publique est peut-être erronée, mais je pensais que les opérations ressemblaient à ceci:

  • Lorsque Bob veut crypter un message à Alice, il utilise la clé publique d'Alice pour le cryptage. Alice utilise ensuite sa clé privée pour déchiffrer le message.
  • Quand Alice veut signer numériquement un message à Bob, elle utilise sa clé privée pour le signer. Bob utilise ensuite la clé publique d'Alice pour vérifier la signature.

Pourquoi est-il important d'utiliser des clés différentes pour le chiffrement et la signature? Cela ne signifie-t-il pas également que vous devez distribuer deux clés publiques à toutes les personnes avec lesquelles vous souhaitez communiquer? J'imagine que cela pourrait facilement entraîner une certaine confusion et une mauvaise utilisation des clés.

Six réponses:
#1
+69
nealmcb
2011-01-22 02:13:26 UTC
view on stackexchange narkive permalink

La plupart du temps, les approches de gestion et les délais diffèrent pour l'utilisation des clés de signature et de chiffrement.

Pour la non-répudiation, vous ne voulez jamais que quelqu'un d'autre contrôle votre clé de signature car il pourrait usurper l'identité tu. Mais votre lieu de travail voudra peut-être déposer votre clé de chiffrement afin que les autres personnes qui en ont besoin puissent accéder aux informations que vous avez chiffrées.

Vous pouvez également souhaiter qu'une clé de signature soit valide pendant une longue période afin que les gens autour le monde peut vérifier les signatures du passé, mais avec une clé de chiffrement, vous voulez souvent la remettre plus tôt et pouvoir en révoquer les anciennes sans autant de tracas.

Ouais, c'est une bonne raison. Une autre raison est que la réutilisation de la même paire de clés dans les deux cas est ** potentiellement non sécurisée **.
"Mais votre lieu de travail voudra peut-être déposer votre clé de cryptage afin que d'autres personnes qui en ont besoin puissent accéder aux informations que vous avez cryptées." - cela peut être pertinent pour les clés symétriques mais pas pour PKI.
@user93353 Si une clé publique n'est utilisée que pour le chiffrement, quelle serait votre objection à son séquestre dans un environnement de travail?
@nealmcb - Je n'aurais aucune objection du tout.
@user93353 Y a-t-il quelque chose dans votre commentaire précédent sur les clés symétriques vs publiques qui me manque alors?
@nealmcb - Votre réponse indique que vous ne devriez pas utiliser la même paire de clés pour le chiffrement et la signature. Dans PKI, vous utilisez votre clé privée pour la signature et vous utilisez une clé publique pour le chiffrement. Alors, quel est exactement le problème avec l'utilisation de la même paire de clés pour le cryptage et la signature?
@nealmcb et si le lieu de travail veut déposer votre clé publique - et alors? Je ne comprends pas du tout votre réponse.
@user93353 Si votre lieu de travail détient une clé de signature, il peut se faire passer pour vous, signer des déclarations en votre nom, vous causer des ennuis, etc. Votre paire de clés de signature devrait donc être la vôtre seule. S'il y a un besoin d'entiercement d'une paire de clés de chiffrement (pour fournir l'accès aux données créées par vous mais appartenant à votre lieu de travail, par exemple), il doit s'agir d'une paire de clés distincte.
Les lieux de travail @user93353 déposent souvent votre clé de chiffrement * privée *. De cette façon, quand ils vous licencient, que vous vous faites heurter par un bus ou que vous vous enfuyez avec la fille du patron, ils ont toujours accès à vos fichiers. Tout employeur qui autorise le chiffrement d'un produit professionnel avec une clé qu'il ne détient pas en séquestre demande des ennuis.
@nealmcb, Re "veut le faire rouler plus tôt";Pourquoi?Pourquoi ne pas en utiliser un avec plus de permanence?
@pacerier Plus une clé de chiffrement dure longtemps, plus il y a de chances de compromettre et plus elle crypte de contenu, plus un compromis cause de problèmes.Un roulement si fréquent présente de nombreux avantages.Ainsi, des systèmes existent pour permettre aux gens d'avoir simplement besoin de faire confiance à une clé racine très bien protégée, qui à son tour est utilisée pour identifier plus de clés de chiffrement éphémères comme authentiques.
#2
+34
D.W.
2011-03-09 11:35:46 UTC
view on stackexchange narkive permalink

Il est potentiellement non sécurisé d'utiliser la même paire de clés pour la signature et le chiffrement. Cela peut activer des attaques, selon le schéma de clé publique que vous utilisez. Ce type d'utilisation n'est pas ce pour quoi le système a été conçu, donc utiliser le système d'une manière qui n'a pas été conçue "annule la garantie".

Ne le faites pas. Cela pose des problèmes.

Pouvez-vous fournir quelques détails? Quels types d'attaques brisent cet usage? (Bien que je sois d'accord, que le système ne soit pas conçu pour cet usage ...)
Sûr. Dans un système mal conçu, si vous pouvez demander le déchiffrement de n'importe quel texte chiffré C que vous voulez et récupérer le déchiffrement correspondant (C), vous pourrez peut-être forger une signature sur le message M en laissant C = Hash (M) et puis demander Decrypt (C). Les systèmes modernes ne sont pas vulnérables à * cette * attaque particulière, mais il est difficile de savoir s'il existe des versions plus sophistiquées de ce type d'attaque sur un système particulier. Si vous réutilisez une clé à la fois pour le chiffrement et la signature, cela invalide généralement toutes les preuves de sécurité ou tout autre contrôle qui a été effectué.
Je vois. Cela a du sens, merci! Mais je comprends qu'actuellement, il n'y a pas d'attaques pratiques * connues *? (Autre que mauvaise pratique, et surtout ** manque d'assurance **)
@AviD, Je ne sais pas. Pourrait être. Je ne sais pas s'il y a des attaques connues. Cela nécessiterait une recherche documentaire minutieuse, ce que je n'ai pas fait. Même si la réponse est "aucune connue", je ne m'y fierais pas. Quand chaque cryptographe sait que c'est une mauvaise façon de concevoir des systèmes, que cela viole les conditions d'utilisation sur une bonne utilisation d'un cryptosystème, je ne sais pas si les cryptanalystes vont passer leur temps à rechercher des attaques pratiques de cette forme, et même si vous trouvé des attaques, je ne sais pas si elles seraient publiables. Bottom line: L'utilisation d'une clé aux deux fins n'est pas recommandée.
Il peut y avoir des attaques pratiques, selon où (sinon) les clés sont utilisées. Comme DW le dit, tout ce dont vous avez besoin est de pouvoir déchiffrer n'importe quel C pour vous - cela pourrait être possible dans les poignées d'authentification où des nonces aléatoires sont utilisés, par exemple. Bien qu'il soit probablement possible de concevoir cela à partir du protocole d'authentification, il est plus facile et plus sûr de le rendre simplement impossible en n'utilisant pas de clés à des fins multiples en premier lieu.
Je suis d'accord que c'est une mauvaise idée. Néanmoins, S / MIME semble fournir les deux (cryptage et signature) avec une seule paire clé / certificat, si je ne me trompe pas.
#3
+12
Am1rr3zA
2011-01-23 04:51:04 UTC
view on stackexchange narkive permalink

Il y a certaines raisons pour lesquelles nous ne devrions pas utiliser la même clé pour le chiffrement et la signature.

  1. Nous devons sauvegarder notre clé secrète pour les données chiffrées. Plus tard, nous voulons déchiffrer certains anciens messages chiffrés, mais nous n'avons pas besoin de sauvegarder notre clé secrète pour la signature. Si l'attaquant trouve la clé, nous pouvons dire à notre autorité de certification de la révoquer et d'obtenir une nouvelle clé secrète pour la signature sans avoir besoin de sauvegarde.

  2. Plus important encore: Si nous utilisons la même clé pour le chiffrement et la signature, l'attaquant peut l'utiliser pour déchiffrer notre message chiffré. Voici ce qu'il ferait:

    L'attaquant doit choisir un nombre aléatoire r , où

    r doit avoir GDC (N, r) = 1 ,
    et N est le numéro utilisé pour créer la clé privée et publique ( N = pq )

    Ensuite, l'attaquant choisit un nouveau message ( m ′ ) et l'envoie pour signature à l'expéditeur:

    m ′ = m ^ er ^ e (ici (e, n) est la clé publique)

    Lorsque l'expéditeur signe m ′ nous obtenons

    m ′ ^ d ≡ (m ^ er ^ e) ^ d ≡ mr (mod N)

    Désormais l'attaquant uniquement doit le "diviser" par r pour obtenir m (le message secret).

Cela semble spécifique au RSA, plutôt que applicable à tous les chiffrements asymétriques.
Aussi, pourquoi l'attaquant aurait-il accès à N et autres?
@Avid Attacker a par défaut accès à N, car lorsque vous souhaitez publier votre clé publique, vous devez publier (N, e).
"quand le signe de l'expéditeur m ′ nous obtenons m ′ ^ d" Pourquoi? Pour signer quelque chose avec RSA, vous ne lui appliquez pas simplement l'opération de clé privée. Vous le hachez et vous appliquez un remplissage. Donc, votre attaque ne fonctionne pas. (Il y a des exceptions, l'utilisation d'une clé pour la signature aveugle et le cryptage serait ouverte à cette attaque, mais la signature aveugle est une application spéciale, et non une signature normale).
@CodesInChaos La description du risque lié à l'utilisation de la même clé pour la signature et le chiffrement est trop simplifiée. Mais dans le domaine de la sécurité, un exemple simplifié des raisons pour lesquelles quelque chose pourrait être un problème devrait être pris au sérieux. D'un autre côté, vous voulez des preuves rigoureuses, avant que quelque chose ne soit considéré comme sûr. Si tout ce que vous avez, ce sont des arguments pour et contre la sécurité d'une pratique, il faut faire preuve de prudence.
L'exigence GDC (N, r) = 1 n'est pas très importante. Si l'attaquant choisit par hasard un r pour lequel ce n'est pas le cas, il a quand même cassé le cryptage.
@kasperd "il a cassé le cryptage de toute façon" seulement dans le cas des deux premiers. En principe, le module peut contenir deux grands facteurs et un tas de petits. Bien que ce ne soit généralement pas le cas pour les clés RSA normales, la génération de clés malveillantes est un problème dans les schémas de signature aveugle.
@CodesInChaos C'est intéressant. Je n'ai pas essayé de faire les calculs pour voir si des informations seraient divulguées si N a plus de deux facteurs premiers.
@kasperd Vous perdez des informations si vous ne vous assurez pas que le message (complété) ne divise pas le module. Cela peut être un problème si le module comporte de nombreux petits facteurs.
Certaines sources / liens seraient super ici.
#4
+7
moo
2014-05-29 06:25:40 UTC
view on stackexchange narkive permalink

Raisons de l'utilisation de clés distinctes pour la signature et le chiffrement:

  1. Utile dans l'organisation lorsque la clé de chiffrement doit être sauvegardée ou conservée sous séquestre afin de déchiffrer les données une fois qu'un employé / utilisateur de l'organisation n'est pas est plus disponible. Contrairement à la clé de chiffrement, la clé de signature ne doit jamais être utilisée par personne d'autre que l'employé / l'utilisateur et n'a pas et ne devrait pas avoir besoin d'être conservée sous séquestre.
  2. Permet d'avoir des délais d'expiration différents pour signer une clé de chiffrement.
  3. Étant donné que les mathématiques sous-jacentes sont les mêmes pour le chiffrement et la signature, seulement à l'inverse, si un attaquant peut convaincre / tromper un détenteur de clé de signer un message chiffré non formaté en utilisant la même clé, l'attaquant obtient l'original.
  4. Références

    1. https://www.entrust.com/what-is -pki /

    2. https://www.gnupg.org/gph/en/manual/c235.html

    3. http://www.di-mgt.com.au/rsa_alg.html

Tous les liens / sources pour 3 disponibles s'il vous plaît ...
@alfonx J'ai peut-être oublié les liens originaux à partir desquels j'ai obtenu ces points, mais j'ai édité les références dans l'ordre. J'espère que cela aide. Je ne sais pas si toutes ces références sont les plus fiables, mais les points ont du sens si vous avez travaillé [PKI] (https://www.comodo.com/resources/small-business/digital-certificates1.php).
Le point 3 d'@moo n'est qu'une bonne remarque sur le concept de clé RSA asymétrique.Cependant, l'attaque n'existe pas dans la pratique de signature de documents du monde réel (comme PGP que cette question examine).En effet, PGP ne signe qu'un résumé de message (c'est-à-dire un hachage sécurisé) du message d'origine, au lieu d'appliquer la clé privée à l'ensemble du message.
@JohnnyWong a convenu qu'une attaque dans le monde réel utilisant ce concept dépendrait de l'implémentation.L'OP a mentionné GPG / PGP comme exemple, mais il me semble que l'OP voulait un raisonnement plus général pour cette pratique.Étant donné que les implémentations changent assez souvent, je pense que ce point est très important pour être compris pour quiconque traite avec PKI et je choisis de ne pas supprimer le point 3. J'aurais peut-être pu mettre une note à ce sujet, mais je pense que nos commentaires servent maintenant cet objectif.Merci.
#5
+5
David Bakker
2015-04-01 15:13:56 UTC
view on stackexchange narkive permalink

Pour moi, les principales raisons sont liées à la gestion des clés, plutôt qu'à la sécurité cryptographique en soi.

Pour la crypto asymétrique, en particulier la période pendant laquelle vous voulez qu'une clé publique soit valide peut fortement dépendre de l'utilisation prévue de cette clé. Par exemple, considérons un système dans lequel un composant doit s'authentifier auprès d'autres composants. En plus de cela, ce composant doit également créer régulièrement une signature sur certaines données. En théorie, une seule clé privée pourrait être utilisée aux deux fins. Cependant, supposons que l'autorité de certification PKI, pour des raisons de sécurité, souhaite limiter à deux ans la période pendant laquelle une authentification réussie peut avoir lieu sur la base d'un seul certificat. Dans le même temps, les lois sur la conservation des données peuvent exiger que les données soient conservées pendant cinq ans et que la signature de ces données soit vérifiable pendant toute cette période. Le seul moyen (sain) de résoudre ce problème est de donner au composant deux clés privées: une pour l'authentification et une pour la signature. Le certificat de la première clé expirera au bout de deux ans, le certificat de signature expirera au bout de cinq ans.

Des raisonnements similaires peuvent être appliqués à la cryptographie symétrique: si vous utilisez des clés différentes à des fins différentes, vous pouvez décider sur toutes les questions de gestion des clés (par exemple, la fréquence de renouvellement de la clé principale, la période de sauvegarde des clés, etc.) en fonction des exigences d'un seul objectif. Si vous utilisez une seule clé (principale) à des fins multiples, vous risquez de vous retrouver avec des exigences contradictoires.

#6
+2
Piquan
2019-07-29 13:59:16 UTC
view on stackexchange narkive permalink

Le chiffrement RSA est basé sur une fonction de trappe, c'est-à-dire une paire de fonctions. Je les appellerai D et E . Les fonctions sont conçues pour que D (E (x)) = x et E (D (x)) = x (pour tout x ). En d'autres termes, D et E sont des inverses. Ce qui en fait une fonction de trappe, c'est que si vous avez une clé publique, vous ne pouvez calculer que E (pratiquement). Si vous avez une clé privée, vous pouvez calculer à la fois D et E.

Le fonctionnement du cryptage est assez évident à partir de cette description. Si Bob veut envoyer un message chiffré à Alice, il calcule ciphertext: = E (texte en clair) . Puis Bob envoie texte chiffré à Alice. Alice calcule D (texte chiffré) , qui est D (E (texte clair)) , qui est simplement plaintext.

Maintenant, parlons du fonctionnement de la signature. Si Alice veut signer message , alors elle calcule signature: = D (message) . Elle envoie ensuite à la fois message et signature à Bob. Bob calcule ensuite validation: = E (signature) . Puisque signature est D (message) , alors validation = E (D (message)) = message .

In autrement dit: pour signer un message, vous agissez comme si vous le déchiffriez, et c'est votre signature. Pour vérifier votre signature, les gens peuvent crypter la signature et s'assurer de récupérer votre message d'origine.

Je le répète: la signature est la même opération que le décryptage.

Ceci est la préoccupation fondamentale concernant la séparation des clés de signature et de chiffrement. Si quelqu'un peut vous amener à signer quelque chose, c'est qu'il vous demande de le déchiffrer.

Supposons que vous dirigiez une entreprise notariale. Si quelqu'un vous donne 10 $ et un message (par exemple, les paroles d'une chanson), vous signerez ce message et vous le renverrez. Si quelqu'un copie plus tard les paroles de vos chansons, vous pouvez produire la signature de la société notariale de confiance pour démontrer que vous avez écrit ces paroles.

Supposons maintenant qu'Eve ait intercepté un message crypté à votre société notariale. Comment peut-elle renverser le cryptage? Elle vous envoie le même message pour la notarisation! Vous exécutez maintenant l'opération de signature (qui, rappelez-vous, est la même que l'opération de déchiffrement) et vous lui renvoyez le résultat. Elle a maintenant le message déchiffré.

En pratique, les protocoles comportent des étapes qui rendent cette attaque plus difficile. Par exemple, PGP (j'entends par là le protocole; gpg est l'implémentation la plus courante ici) ne signe pas le message d'origine; il signe un hachage du message. Mais les preuves de sécurité sont les meilleures dans des situations simples. Vous ne voulez pas que votre preuve sur la sécurité de RSA dépende de la fonction de hachage. (Par exemple, de nombreuses personnes ont utilisé MD5 comme hachage préféré pendant longtemps, mais aujourd'hui MD5 est considéré comme assez cassé.) Seule, la sécurité de RSA dépend de l'idée que vous ne signerez pas de messages arbitraires avec une clé utilisée pour le cryptage. Le maintien de cette exigence est le meilleur moyen de garantir la sécurité de PGP. (Si je me souviens bien, c'est l'avertissement le plus fréquemment répété sur le cryptage asymétrique dans le livre de Bruce Scheier Applied Cryptography .)

Parlons maintenant de une autre question que vous avez posée: "Cela ne signifie-t-il pas également que vous devez distribuer deux clés publiques à toutes les personnes avec lesquelles vous souhaitez communiquer?"

Une "clé" signifie une chose pour les utilisateurs, et une chose différente pour les implémentations cryptographiques. Vous n'avez besoin de communiquer qu'une seule "clé" au niveau de l'utilisateur, bien qu'elle puisse contenir plusieurs clés publiques RSA.

PGP a un concept de sous-clés. Ma clé principale est une clé de signature uniquement. J'ai une sous-clé de chiffrement distincte. Cette sous-clé est signée par ma clé principale. Si vous importez ma clé PGP à partir des serveurs de clés, ou la téléchargez à partir de mon site Web, vous obtiendrez ma clé principale et toutes mes sous-clés. Même si vous n'avez signé que ma clé principale, ma clé principale a signé ma sous-clé de chiffrement, vous savez donc qu'elle m'appartient également. Cela signifie qu'en téléchargeant ma clé PGP (qui englobe de nombreuses clés publiques RSA), vous avez maintenant tout ce dont vous avez besoin pour vérifier mes signatures et pour crypter mes messages.

Avec les sous-clés, la gestion des clés est plus complexe d'un point de vue cryptographique (il y a une étape de vérification de clé supplémentaire à passer), mais pas d'un point de vue pratique (ma clé PGP comprend ma clé principale, ainsi que toutes mes sous-clés). La complexité supplémentaire est cachée dans l'implémentation et n'est pas exposée à l'utilisateur.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 2.0 sous laquelle il est distribué.
Loading...