Ik heb iemand anders nodig om geheime gegevens te versleutelen met mijn openbare sleutel, die ik vervolgens kan ontsleutelen met mijn privésleutel. Ik heb een RSA privé / publieke sleutelpaar gemaakt met OpenSSL gaf ze de publieke sleutel en alles werkte.
Meer recentelijk heeft iemand erop gewezen dat we het onderwerp zijn van een mogelijke man-in-the-middle-aanval waar de slechteriken mijn openbare sleutel zouden accepteren en hun eigen openbare sleutel aan de andere kant zouden doorgeven. De andere kant zou dan plichtsgetrouw de geheime gegevens versleutelen, ze doorgeven aan de MITM die ze zou ontsleutelen, ze opnieuw versleutelen met mijn publieke sleutel alvorens ze aan mij door te geven zonder dat ik het wijzer was. De aanbevolen oplossing is om mijn openbare sleutel te laten ondertekenen door een CA die de andere partij vertrouwt voordat ik deze doorgeef.
Als experiment heb ik een CSR gemaakt die ik met mijn eigen CA kon ondertekenen, maar het resulterende certificaat bevat ook de (versleutelde) privésleutel. Ik geef mijn geheime sleutel liever niet aan iemand anders, versleuteld of niet.
Is er een manier om gewoon mijn openbare sleutel te laten ondertekenen?
Opmerkingen
- Certificaat bevat privésleutel? Huh? Hoe heb je dit voor elkaar gekregen? Kunt u dat bestand op pastebin.com plaatsen? (Doe het opnieuw met een tweede sleutelpaar zodat je ‘ het origineel niet hoeft te delen.)
- Ik denk dat ik het begin te begrijpen. Ook al heb ik de private key nodig om een CSR te maken, de CSR en het resulterende certificaat bevatten niet de private key. Een certificaat is in feite een ondertekende openbare sleutel en dat is precies wat ik wil.
Antwoord
Een openbare sleutel ondertekenen is in feite een certificaat. Dit zijn de stappen die ik neem om een openbare sleutelcertificaat te produceren dat ik aan anderen kan verspreiden, zodat ze veilig met mij kunnen communiceren:
Installatie
- Genereer de privésleutels:
openssl genrsa -out private.pem 2048
- Genereer de publieke sleutels:
openssl rsa -in private.pem -outform PEM -pubout -out public.pem
- Maak een CSR (Certificate Signing Request)
openssl req -new -key private.pem -out certificate.csr
- Maak een zelfondertekend certificaat (u kunt dit certificaat delen)
openssl x509 -req -days 365 -in certificate.csr -signkey private.pem -out certificate.crt
Versleuteling
openssl rsautl -encrypt -inkey private.pem -keyform PEM -in data> encrypted_data
Decoderen
- Haal de openbare sleutel uit de certificaten
openssl x509 -pubkey -noout -in certificate.crt> certpubkey.pem
- Decodeer de gegevens
openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data> data
Als u van plan bent uw sleutel te laten ondertekenen door een CA, moet u uw CSR-bestand (en wat geld) naar de CA van uw keuze sturen. Zij geven u het certificaat dat u kunt gebruiken in plaats van het zelfondertekende certificaat. vermeld in de bovenstaande stappen.
Opmerkingen
- Dit is een beetje het omgekeerde van wat ik vraag, maar het zal doen voor de doeleinden van discussie. Om de andere partij te laten ontsleutelen, hebben ze ofwel de openbare sleutel nodig zoals deze door mij is geëxtraheerd en die onderhevig is aan de MITM-aanval, of ze hebben het hele certificaat nodig dat de (versleutelde) privésleutel bevat.
- @ user1683793 De het andere uiteinde heeft twee certificaten nodig. De eerste die ze al zouden moeten hebben (het zelfondertekende CA-certificaat). De tweede bevat de openbare sleutel die u wilt verifiëren, en is ondertekend met het CA-certificaat (met behulp van de bijbehorende persoonlijke CA-sleutel). De geldigheid van het tweede certificaat wordt getest met de openbare sleutel in het CA-certificaat. Privésleutels worden altijd privé gehouden.
- Ik denk dat je ” -encrypt ” en -decrypt ” in plaats van ” -teken ” en ” -verify “. (Details hier: czeskis.com/random/openssl-encrypt-file.html )
- Werkt niet: 2. Het decoderen van de gegevens werkte niet voor mij. Met:
openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data > data
krijg ik deze foutmelding / msg:A private key is needed for this operation
- Sectie
Setup
, step2
geeftpublic.pem
– het wordt niet ‘ niet gebruikt in verdere stappen. Wat is het nut van die openbare sleutel wanneer de CSR wordt gegenereerd met een privésleutel?
Antwoord
Er zouden drie entiteiten bij het proces moeten zijn betrokken:
- De afzender – u
- De ontvanger – de gebruiker
- Certificeringsinstantie – vertrouwde derde partij (of u in sommige gevallen)
Het proces dat alles veilig houdt is “The Sender”, genereert een paar sleutels (openbaar en privé). Ik noem deze graag sleutel en slot voor een beter beeld. De sleutel (privé) mag nooit het bezit van de afzender verlaten, daarom wordt het een privésleutel genoemd.
De afzender genereert vervolgens een Certificate Signing Request (CSR) met de openbare sleutel (lock ) die wordt doorgestuurd naar de Certificate Authority (Trusted Third Party), ondertekent de Certificate Authority de publieke sleutel (slot) met de Private Key van de Certificate Authorities.
De Certificate Authority verstuurt nu de “The Senders” publieke sleutel die is ondertekend door de privésleutel van de certificaatautoriteiten terug naar “The Sender”, wat nu het certificaat is.
De ontvanger krijgt het certificaat (laten we zeggen via de webbrowser) en verifieert dat het geldig is met de openbare sleutel van de certificeringsinstanties die zowel “The Sender” als “The Receiver” hebben aangezien zij de vertrouwde derde partij zijn. Eenmaal geverifieerd, kan de openbare sleutel in het certificaat worden vertrouwd * als de openbare sleutel van “The Sender” ongewijzigd.
Als “The Receiver” gegevens naar “The Sender” moet verzenden, gebruiken ze de openbare sleutel van het vertrouwde certificaat om de gegevens te versleutelen in cypertext die vervolgens wordt doorgegeven aan “The Sender”. Aangezien alleen de privésleutel van “The Sender” de cryptietekst kan decoderen die is gecodeerd met de openbare sleutel van “The Sender”, kan iedereen in het midden bevat in wezen nutteloze verminkte tekst.
In bepaalde gevallen kan “De afzender” zijn / haar eigen certificeringsinstantie genereren door hun eigen CSR te ondertekenen met een andere set sleutels of door zelf te ondertekenen met dezelfde set sleutels In dit geval moet de openbare sleutel van “De afzender” bekend zijn bij beide partijen via een beveiligd kanaal om vertrouwen te hebben. In software kunt u een certificaat opnemen in het product dat kan worden gebruikt als de vertrouwde derde partij.
* Trusted is alleen geldig als de certificeringsinstantie een CRL (Certificate Revocation List) bijhoudt en alle partijen de lijst controleren om ervoor te zorgen dat het uitgegeven certificaat niet is gecompromitteerd. Het geval waarin de certificeringsinstantie is gecompromitteerd en de privésleutel is gelekt, bestaat en wanneer dat gebeurt, kan de compromitterende agent de privésleutel gebruiken om een vertrouwd certificaat te genereren dat De afzender nabootst , in dat geval is een MITM mogelijk en kan de MITM gegevens van “The Sender” ontsleutelen, opslaan, versleutelen met een geldig certificaat dat eruitziet als “The Sender”, en dat vervolgens doorgeven aan “The Receiver”.
Answer
Haal de versleutelde privésleutel uit de kopie van het CA-certificaat dat je hebt gemaakt (wanneer je het aan anderen geeft). je hoeft er niet te zijn, tenzij je het gaat gebruiken om een certificaat te ondertekenen dat er nog een bevat er openbare sleutel.
Wanneer u uw openbare sleutel verzendt, verstuurt u in plaats daarvan een volledig certificaat (behalve de privésleutel), ondertekend met de bijbehorende CA privésleutel. Om de geldigheid van de openbare sleutel erin te controleren, moet u de hash van het certificaat vergelijken met de versleutelde hash (die is versleuteld met de privésleutel van de CA). Deze is ontsleuteld met de openbare sleutel van de CA . Als de decodering succesvol is en de hash overeenkomt met de hash van het certificaat, dan kan de informatie in het certificaat worden vertrouwd.
Er komt ook meer bij kijken dan alleen codering, bijvoorbeeld een replay-aanval waarbij een aanvaller stuurt eerder opgeslagen versleutelde gegevens. TLS omvat veel meer dan de gemiddelde persoon zou denken, en het implementeren van een soortgelijk systeem wordt absoluut niet aanbevolen. Gebruik TLS waar mogelijk voor alles dat bedoeld is om privé te zijn.