Comment produire une clé publique signée CA?
J'ai besoin que quelqu'un d'autre crypte les données secrètes avec ma clé publique que je peux ensuite décrypter avec ma clé privée. J'ai produit une paire de clés privée/publique RSA avec OpenSSL leur a donné la clé publique et tout fonctionne.
Plus récemment, quelqu'un a fait remarquer que nous risquions une attaque de l'homme du milieu où les méchants accepteraient ma clé publique et passeraient leur propre clé publique de l'autre côté. L'autre côté chiffrerait alors consciencieusement les données secrètes, les transmettrait au MITM qui les déchiffrerait, les rechiffrerait avec ma clé publique avant de me les transmettre sans que je sois le plus sage. La solution recommandée consiste à faire signer ma clé publique par une autorité de certification à laquelle l'autre partie fait confiance avant de la transmettre.
À titre d'expérience, j'ai produit une CSR que j'ai pu signer avec ma propre autorité de certification, mais le certificat résultant contient également la clé privée (chiffrée). Je préfère ne pas transmettre ma clé secrète à quelqu'un d'autre, cryptée ou non.
Existe-t-il un moyen de simplement faire signer ma clé publique?
La signature d'une clé publique est en fait un certificat. Voici les étapes que je prends pour produire un certificat de clé publique que je peux distribuer à d'autres afin qu'ils puissent communiquer en toute sécurité avec moi:
Installer
- Générez les clés privées:
openssl genrsa -out private.pem 2048
- Générez les clés publiques:
openssl rsa -in private.pem -outform PEM -pubout -out public.pem
- Créer une CSR (demande de signature de certificat)
openssl req -new -key private.pem -out certificate.csr
- Créez un certificat auto-signé (vous pouvez partager ce certificat)
openssl x509 -req -days 365 -in certificate.csr -signkey private.pem -out certificate.crt
Chiffrement
openssl rsautl -encrypt -inkey private.pem -keyform PEM -in data> encrypted_data
Décryptage
- Extraire la clé publique des certificats
openssl x509 -pubkey -noout -in certificate.crt> certpubkey.pem
- Déchiffrez les données
openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data> données
Si vous avez l'intention de faire signer votre clé par une autorité de certification, vous devrez envoyer votre fichier CSR (et de l'argent) à l'autorité de certification de votre choix, ils vous donneront le certificat que vous pouvez utiliser à la place du certificat auto-signé I mentionné dans les étapes ci-dessus.
Il devrait y avoir trois entités impliquées dans le processus:
- L'expéditeur - vous
- Le récepteur - L'utilisateur
- Autorité de certification - tiers de confiance (ou vous dans certains cas)
Le processus qui protège les choses est "l'expéditeur", génère une paire de clés (publiques et privées). J'aime les appeler clé et serrure pour un meilleur visuel. La clé (privée) ne doit jamais quitter la possession de l'expéditeur, c'est pourquoi on l'appelle une clé privée.
L'expéditeur génère ensuite une demande de signature de certificat (CSR) avec la clé publique (verrou) qui est transmise à l'autorité de certification (tiers de confiance), l'autorité de certification signe la clé publique (verrou) avec la clé privée des autorités de certification.
L'autorité de certification renvoie désormais la clé publique "The Senders" qui est signée par la clé privée des autorités de certification à "The Sender", qui est maintenant le certificat.
Le récepteur obtient le certificat (disons par le biais du navigateur Web) et vérifie qu'il est valide avec la clé publique des autorités de certification que "l'expéditeur" et "le récepteur" possèdent puisqu'ils sont le tiers de confiance. Une fois vérifiée, la clé publique du certificat peut être approuvée * comme étant la clé publique de "l'expéditeur" inchangée.
Si "The Receiver" doit envoyer des données à "The Sender", ils utiliseront la clé publique du certificat de confiance pour crypter les données en cypertexte qui seront ensuite transmises à "The Sender". Étant donné que seule la clé privée de "The Sender" peut déchiffrer le texte crypté qui a été crypté avec la clé publique de "The Sender", quiconque au milieu a essentiellement un texte tronqué inutile.
Dans certains cas, "l'expéditeur" peut générer sa propre autorité de certification en signant son propre CSR avec un jeu de clés différent ou en signant automatiquement avec le même jeu de clés. Dans ce cas, la clé publique "The Sender's" doit être connue des deux parties via un canal sécurisé pour avoir la moindre confiance. Dans le logiciel, vous pouvez inclure un certificat dans le livrable qui peut être utilisé comme tiers de confiance.
* La confiance n'est valide que si l'autorité de certification maintient une liste de révocation de certificats (CRL) et que toutes les parties surveillent la liste pour s'assurer que le certificat émis n'a pas été compromis. Le cas où l'autorité de certification est comprimée et la clé privée est divulguée existe et lorsque cela se produit, l'agent compromettant peut utiliser la clé privée pour générer un certificat de confiance qui imite "l'expéditeur", dans ce cas, un MITM est possible et le MITM peut recevoir des données de "The Sender" décrypter, stocker, crypter avec un certificat valide qui ressemble à "The Sender", puis les transmettre à "The Receiver".
Retirez la clé privée chiffrée de la copie du certificat de l'autorité de certification que vous avez créée (en la donnant à d'autres). La clé privée n'a pas besoin d'être là sauf si vous allez l'utiliser pour signer un certificat contenant une autre clé publique.
Lorsque vous envoyez votre clé publique, envoyez plutôt un certificat entier (à l'exception de la clé privée), signé à l'aide de la clé privée CA associée. Afin de vérifier la validité de la clé publique à l'intérieur de celle-ci, vous devez vérifier le hachage du certificat par rapport au hachage chiffré (qui a été chiffré à l'aide de la clé privée de l'autorité de certification). Il est décrypté à l'aide de la clé publique de l'autorité de certification. Si le déchiffrement réussit et que le hachage correspond au hachage du certificat, les informations à l'intérieur du certificat peuvent être fiables.
Il y a aussi plus que le simple chiffrement, par exemple une attaque de relecture dans laquelle un attaquant envoie des données chiffrées précédemment enregistrées. TLS couvre bien plus que la personne moyenne ne le pense, et la mise en œuvre d'un système similaire n'est absolument pas recommandée. Utilisez TLS autant que possible pour tout ce qui est destiné à être privé.