Crypter avec une clé privée/décrypter avec une clé publique?
[Disclaimer: je sais, si vous savez quelque chose à propos de crypto, vous êtes probablement sur le point de me dire pourquoi je suis fais mal - j'ai fait assez de Googler pour savoir ce qui semble être la réponse typique.]
supposons ce qui suit: vous avez une autorité centrale qui veut émettre des cookies de connexion pour un domaine donné. Dans ce domaine, vous ne faites pas nécessairement confiance à tout le monde, mais vous avez quelques paramètres clés qui devraient être en mesure de lire le cookie. Je dis un peu, mais dans la pratique, ce nombre de "de confiance" partenaires peuvent être grandes. Le cookie ne contient pas beaucoup d'informations - un nom d'utilisateur, un horodatage, une échéance, un nombre aléatoire. Il doit rester petit, bien sûr, pour des raisons de performance, même après le cryptage (dans la limite du raisonnable). Maintenant, il y a deux problèmes de sécurité:
1) nous ne faisons pas confiance à chaque serveur web de ce domaine avec les données des utilisateurs. Pour cette raison, la capacité de lire le témoin devrait être limitée à ces partenaires de confiance. 2) tout en faisant confiance à ces partenaires pour protéger nos données de l'utilisateur, nous aimerions quand même que le point central d'autorité soit impardonnable (encore une fois, dans la limite du raisonnable).
maintenant, si nous produisons une clé RSA privée pour l'autorité et la gardons secrète, et distribuons la clé publique seulement aux "partenaires de confiance", nous devrions être en mesure de chiffrer avec la clé privée et avoir lisible par n'importe qui avec la clé publique. Ce que je ne comprends pas, est-ce qu'il serait encore nécessaire de signer le message, ou est-ce que l'acte de décryptage serait la preuve qu'il a été généré avec la clé privée? Est-ce que ce schéma serait meilleur ou pire que la diffusion d'une clé symétrique à toutes les parties concernées et l'utilisation de celle-ci pour chiffrer, tout en utilisant la clé privée uniquement pour signer? Et bien sûr, n'hésitez pas à me dire en quoi c'est une idée stupide, mais gardez à l'esprit que les arguments pratiques seront probablement plus convaincants que de ressasser Alice et Bob.
Oh, et la mise en œuvre des pointeurs serait la bienvenue, bien que l'on peut trouver les bases sur Google, s'il ya des "gotchas" impliqués qui seraient utiles!
7 réponses
Vous devez utiliser un numérique sigantures schéma d'une certaine sorte, ou d'un autre mécanisme qui vise à résoudre le l'intégrité problème de votre scénario.
le cryptage lui-même n'est pas suffisant. Comment savez-vous que le message déchiffré est ce qu'il devrait être? Décrypter un cookie crypté avec la bonne clé fournira certainement un cookie "valide", mais qu'arrive-t-il lorsque vous décryptez un cookie crypté avec la mauvaise clé? ou juste des données insignifiantes? eh bien, vous pourriez juste obtenir un cookie est valide! (les horodateurs sont dans la plage que vous considérez valide, le nom d'utilisateur est légal, le nombre aléatoire... euh... un certain nombre, etc.).
dans la plupart des algorithmes de cryptage asymétrique que je connais, il n'y a pas de validation intégrée. Cela signifie que déchiffrer un message avec la mauvaise clé ne "échouera" pas - il vous donnera seulement un faux plaintext, qui vous doit se distinguer d'un texte clair valide. C'est là que l'intégrité entre en jeu, le plus souvent - en utilisant des signatures numériques.
BTW, RSA est étudié depuis longtemps et a plusieurs "gotchas", donc si vous prévoyez de l'implémenter à partir de zéro, vous feriez mieux de lire à l'avance sur la façon d'éviter de créer des clés "relativement faciles à casser".
Nate Lawson explique ici et ici pourquoi vous ne pouvez pas utiliser la clé publique en toute sécurité comme une clé secrète de décryptage (c'est un point subtil, et une erreur que beaucoup d'autres ont faite avant vous, alors ne vous sentez pas mal!).
il suffit d'utiliser votre clé publique pour signer l'authenticité, et une clé symétrique séparée pour le secret.
j'ai assez lu sur les attaques intéressantes contre les systèmes de clés publiques, et RSA en particulier, que je suis d'accord absolument avec cette conclusion:
cryptosystèmes et systèmes RSA à clé publique particulier, sont extrêmement fragiles. Faire ne pas les utiliser différemment ont été conçus.
(cela signifie: chiffrez avec la clé publique, signez avec la clé privée, et tout le reste joue avec le feu.)
Addendum:
si vous êtes intéressé à réduire la taille des cookies résultant, vous devriez envisager D'utiliser ECDSA plutôt que RSA pour produire les signatures-les signatures ECDSA sont considérablement plus petites que les signatures RSA d'un facteur de sécurité équivalent.
En cryptographie, vous êtes ce que vous savez. Dans votre scénario, vous avez une autorité centrale qui est en mesure d'émettre vos cookies, et vous voulez qu'aucune autre entité ne puisse faire la même chose. Donc, l'autorité centrale doit "savoir" certaines données privées. De plus, vous voulez que les "serveurs Web de confiance" puissent accéder au contenu des cookies, et vous ne voulez pas que n'importe qui lise les cookies. Ainsi, les "serveurs Web de confiance" doivent également posséder leurs propres données privées.
la voie normale serait soit que l'autorité applique une signature numérique sur les cookies, et que les cookies sont cryptés avec une clé connue des serveurs Web de confiance. Ce que vos pensez ressemble à ceci:
- il y a un module RSA n et les deux exposants habituels de RSA d et e (tels que ed = 1 modulo p-1 et q-1 où n = pq). L'autorité centrale le sait d, le les serveurs Web de confiance savent!--6-- > e le module n est publique.
- le cookie est traité par l'autorité centrale en le remplaçant par un entier c modulo n, et de l'informatique s = c^D mod n.
- les serveurs Web de confiance accèdent aux données du cookie en calculant c = s^e mod n.
Bien qu'un tel système peut fonctionner, je vois les problèmes suivants dans:
- Pour la sécurité de base, e doit être grande. Dans les descriptions RSA habituelles, e est l'exposant public et est petit (comme e = 3). Un petit exposant n'est pas un problème quand il est public, mais puisque vous ne voulez pas que le contenu des cookies soit accessible par des tiers, vous devez faire e assez grand pour résister recherche exhaustive. En même temps, les serveurs web de confiance ne doivent pas savoir p et q, seulement n. Cela signifie que les serveurs Web de confiance auront besoin de calculer les choses avec un grand module et un grand exposant, et sans connaître les facteurs de module. Cela semble un point mineur, mais il disqualifie de nombreuses bibliothèques d'implémentation RSA. Vous serez "seul", avec de grands nombres entiers (et tous les problèmes d'implémentation connus sous le nom de"fuites de canaux secondaires").
- la résistance des signatures RSA, et la résistance du cryptage RSA, ont été bien étudiées, mais pas ensemble. Il se trouve que le rembourrage est essentielle, et vous n'utilisez pas le même protocole de remplissage pour le chiffrement et les signatures. Ici, vous voulez un schéma de remplissage qui sera bon pour la signature et le cryptage. Les cryptographes considèrent généralement qu'une bonne sécurité est atteinte lorsque des centaines de cryptographes formés ont examiné le schéma pendant quelques années, et n'ont trouvé aucune faiblesse évidente (ou corrigé quelles que soient les faiblesses ont été trouvées). Les plans faits maison échouent presque toujours à obtenir la sécurité.
- si plusieurs les gens connaissent un secret, alors ce n'est plus un secret. Ici, si tous les serveurs web le savent e, alors vous ne pouvez pas révoquer les privilèges d'un serveur web de confiance sans choisir un nouveau e et de communiquer la nouvelle valeur à tous les autres serveurs Web de confiance. Vous avez ce problème avec une clé symétrique partagée trop.
fondamentalement, je pense que vous serez plus heureux avec un design plus classique, avec des signatures numériques utilisées uniquement pour la signature, et un cryptage (symétrique ou asymétrique) pour la partie confidentialité. Cela vous permettra d'utiliser les bibliothèques existantes, avec le moins possible de maison code.
pour la partie signature, vous pouvez utiliser DSA ou ECDSA: ils produisent des signatures beaucoup plus courtes (typiquement 320 bits pour un DSA la signature de la sécurité de l'équivalent d'un RSA de 1024 bits de signature). Du point de vue de l'autorité centrale, ECDSA permet également de meilleures performances: sur mon PC, en utilisant un seul noyau, OpenSSL sort plus de 6500 signatures ECDSA par seconde (dans la courbe NIST P-192) et "seulement" 1145 signatures RSA par seconde (avec une clé 1024 bits). Les signatures ECDSA consistent en deux entiers de 192 bits, c'est-à-dire 384 bits à encoder, tandis que les signatures RSA sont de 1024 bits. L'ECDSA dans P-192 est considérée au moins comme fort, et probablement plus fort, que le RSA-1024.
les clés publiques sont par définition publiques. Si vous cryptez avec une clé privée et décryptez avec une clé publique, ce n'est pas à l'abri des regards indiscrets. Tout cela dit: "ces données proviennent de la personne X qui détient la clé privée X" et n'importe qui peut vérifier que, parce que l'autre moitié de la clé publique.
Qu'est-ce qui empêche quelqu'un en qui vous n'avez pas confiance de mettre la clé publique X sur un serveur en qui vous n'avez pas confiance?
Si vous voulez une ligne sécurisée de communication entre deux serveurs, vous devez avoir tous ces serveurs de confiance ont leurs propres paires de clés publiques/privées, nous dirons paire de clés Y pour un tel serveur.
Server X peut alors chiffrer un message avec la clé privée X et la clé publique Y. ceci dit "server X a envoyé un message que seul Y pouvait lire, et Y pouvait vérifier qu'il était de X."
(et ce message devrait contenir une clé symétrique de courte durée, parce que la clé publique crypto est très de temps.)
C'est ce que fait SSL. Il utilise la clé publique crypto pour configurer une clé de session.
cela dit, utilisez une bibliothèque. Ce genre de choses est facile à visser.
La réponse à votre question "la loi de décryptage des éléments de preuve qu'elle a été générée avec la clé privée", la réponse est oui si le bénéficiaire peut faire simple validation de données. Dites que vous avez "nom d'Utilisateur : Jean, horodatage :
cependant, considérez ce qui suit:
- clé publique RSA crypto n'est pas conçu pour le cryptage de masse de données structurées car il peut être exploité par l'attaquant. la cryptographie à clé publique est habituellement utilisée de deux façons: 1) pour transporter en toute sécurité la clé symétrique (qui, par définition, n'a pas de structure) qui sera utilisée dans le chiffrement global; ceci est fait en chiffrant la clé symétrique à l'aide de la clé publique et 2) en signant numériquement un document en chiffrant non pas le document mais le hachage du document (encore une fois quelque chose qui n'a pas de structure) à l'aide de la clé privée. Dans votre cas vous cryptez le cookie qui a une structure définie.
- vous comptez sur la clé publique pour ne pas tomber entre les mains de la mauvaise personne ou entité.
- le cryptage à clé publique est environ 1000 fois plus lent que le cryptage à clé symétrique. Cela peut ne pas être un facteur dans votre cas.
si vous souhaitez toujours utiliser cette approche, et êtes en mesure de distribuer la clé publique aux" partenaires de confiance", vous devez générer clé de session aléatoire (c.-à-d. clé symétrique), chiffrez-la à l'aide de la clé privée et envoyez-la à tous les destinataires qui ont la clé publique. Vous cryptez alors le cookie en utilisant la clé de session. Vous pouvez changer la clé de session périodiquement. Plus rarement, vous pouvez changer la clé publique aussi: vous pouvez générer une nouvelle paire de clés publiques / privées et chiffrer la clé publique avec la clé de session et l'Envoyer à tous les destinataires.
je présume que vous faites confiance aux 'partenaires de confiance' pour décrypter et vérifier le cookie, mais ne voulez-vous pas qu'ils puissent générer leurs propres cookies? Si ce n'est pas un problème, vous pouvez utiliser un système beaucoup plus simple: distribuer une clé secrète à toutes les parties, et l'utiliser pour crypter le cookie et générer un HMAC pour elle. Pas besoin de clé publique, pas besoin de clés multiples.
comme solution de rechange à votre approche de distribution clé, qui peut être appropriée ou non dans votre application, envisagez d'utiliser Kerberos, qui utilise le cryptage symétrique des clés, un seul serveur de bastion hautement protégé qui contrôle tout le matériel de frappe, et un ensemble intelligent de protocoles (voir le Needham-Schroder protocol)