Pourquoi ne devrait-on pas utiliser la même clé asymétrique pour le chiffrement que pour la signature?
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 à l'aide de GPG (pour le chiffrement et la signature - vous ne devez pas utiliser la même clé pour les deux).
Quel est le raisonnement derrière cela?
Peut-être que ma compréhension du chiffrement à clé publique est erronée, mais je pensais que les opérations allaient quelque chose de semblable à ceci:
- Lorsque Bob souhaite chiffrer un message à Alice, il utilise la clé publique d'Alice pour le chiffrement. 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 différentes clés pour le chiffrement et la signature? Cela ne signifierait-il pas également que vous devez distribuer deux clés publiques à tous ceux avec qui vous souhaitez communiquer? J'imagine que cela pourrait facilement entraîner une certaine confusion et une mauvaise utilisation des clés.
C'est principalement que 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 vous usurper l'identité. Mais votre lieu de travail peut vouloir entasser 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 longtemps pour que les gens du monde entier puissent vérifier les signatures du passé, mais avec une clé de chiffrement, vous voulez souvent la reconduire plus tôt et pouvoir révoquer les anciennes sans beaucoup de tracas.
Il est potentiellement non sécurisé d'utiliser la même paire de clés pour la signature et le chiffrement. Cela peut permettre des attaques, selon le schéma de clé publique particulier que vous utilisez. Ce type d'utilisation n'est pas prévu pour le système, donc l'utilisation du système d'une manière qui n'a pas été conçue "annule la garantie".
Ne le fais pas. C'est demander des ennuis.
Il y a certaines raisons pour lesquelles nous ne devons pas utiliser la même clé pour le chiffrement et la signature.
Nous devons sauvegarder notre clé secrète pour les données chiffrées. Plus tard, nous voulons décrypter certains anciens messages crypté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 besoin de sauvegarde.
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é. C'est ce qu'il/elle ferait:
L'attaquant doit choisir un nombre aléatoire
r, oùrdoit avoirGDC(N, r) = 1,
EtNest 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^e.r^e… (ici(e,n)Est la clé publique)Lorsque l'expéditeur signe
m′, Nous obtenonsm′^d ≡ (m^e.r^e)^d ≡ m.r (mod N)Désormais, l'attaquant n'a plus qu'à le "diviser" par
rpour obtenirm(le message secret).
Raisons d'utiliser des clés distinctes pour la signature et le chiffrement:
- Utile dans l'organisation, 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 plus disponible. Contrairement à la clé de chiffrement, la clé de signature ne doit jamais être utilisée par une personne autre que l'employé/l'utilisateur et n'a pas et ne doit pas être conservée sous séquestre.
- Permet d'avoir des délais d'expiration différents pour signer une clé de chiffrement.
- Étant donné que les mathématiques sous-jacentes sont les mêmes pour le chiffrement et la signature, uniquement à 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é, alors l'attaquant obtient l'original.
Références
Pour moi, les principales raisons sont liées à la gestion des clés, plutôt qu'à la sécurité cryptographique en soi.
Pour la cryptographie asymétrique, en particulier la période pendant laquelle vous souhaitez qu'une clé publique soit valide peut dépendre fortement 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. À côté 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 dans les deux cas. Cependant, supposons que l'autorité de certification PKI, pour des raisons de sécurité, souhaite limiter à deux ans la période pendant laquelle l'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 sur ces données doit être vérifiable pendant toute cette période. La seule façon (saine) 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 après deux ans, le certificat de signature expirera après cinq ans.
Des raisonnements similaires peuvent être appliqués à la cryptographie symétrique: si vous utilisez différentes clés à des fins différentes, vous pouvez décider de toutes les questions de gestion des clés (par exemple, la fréquence du roulement de la clé principale, la période de sauvegarde des clés, etc.) en fonction sur les exigences d'un seul objectif. Si vous utilisez une seule clé (principale) à des fins multiples, vous pouvez vous retrouver avec des exigences contradictoires.
Le chiffrement RSA est basé sur une fonction Trapdoor, c'est-à-dire une paire de fonctions. Je vais les appeler D et E. Les fonctions sont conçues de manière à ce 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 Trapdoor, 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 crypté à Alice, il calcule ciphertext := E(plaintext). Ensuite, Bob envoie ciphertext à Alice. Alice calcule D(ciphertext), qui est D(E(plaintext)), qui est juste plaintext.
Maintenant, parlons du fonctionnement de la signature. Si Alice veut vouloir signer message, alors elle calcule signature := D(message). Elle envoie ensuite message et signature à Bob. Bob calcule ensuite validation := E(signature). Puisque signature est D(message), alors validation = E(D(message)) = message.
En d'autres termes: 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 qu'ils récupèrent votre message d'origine.
Je le redis: la signature est la même opération que le décryptage.
C'est la préoccupation fondamentale de la séparation des clés de signature et de chiffrement. Si quelqu'un peut vous faire signer quelque chose, alors il vous suffit de le déchiffrer.
Supposons que vous dirigiez une entreprise notariale. Si quelqu'un vous donne 10 $ et un message (par exemple, les paroles des chansons), vous signerez ce message et vous le renverrez. Si quelqu'un copie plus tard les paroles de votre chanson, vous pouvez produire la signature de la société notariale de confiance pour démontrer que vous avez écrit ces paroles de chanson.
Supposons maintenant qu'Eve ait intercepté un message crypté à votre notaire. Comment peut-elle renverser le cryptage? Elle vous envoie ce 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é.
Dans la 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 meilleures dans des situations simples. Vous ne voulez pas que votre preuve de 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 une longue période, mais aujourd'hui MD5 est considéré comme tout à fait défectueux.) Seul, 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 chiffrement. Le maintien de cette exigence est le meilleur moyen d'assurer la sécurité de PGP. (Si je me souviens bien, c'est l'avertissement le plus fréquemment répété à propos du cryptage asymétrique dans le livre de Bruce Scheier Cryptographie appliquée .)
Maintenant, parlons d'une autre question que vous avez posée: "Cela ne signifierait-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 "clé" de niveau utilisateur, bien qu'elle puisse contenir de nombreuses 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 cryptage 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 depuis 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 crypter les messages pour moi.
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.