Jag har behov av att någon annan krypterar hemlig data med min offentliga nyckel som jag sedan kan dekryptera med min privata nyckel. Jag har producerat ett RSA privat / offentligt nyckelpar med OpenSSL gav dem den offentliga nyckeln och har allt som fungerar.
Mer nyligen påpekade någon att vi är föremål för en möjlig man-i-mitten-attack där skurkarna skulle acceptera min offentliga nyckel och skicka sin egen offentliga nyckel till andra sidan. Den andra sidan skulle då pliktskyldigt kryptera de hemliga uppgifterna, överföra den till MITM som skulle dekryptera den, kryptera den igen med min offentliga nyckel innan den skickade vidare till mig utan att jag var klokare. Den rekommenderade lösningen är att ha min offentliga nyckel signerad av en CA som den andra sidan litar på innan den skickas över.
Som ett experiment producerade jag en CSR som jag kunde underteckna med min egen CA, men det resulterande certifikatet innehåller också den (krypterade) privata nyckeln. Jag vill hellre inte skicka min hemliga nyckel till någon annan, krypterad eller inte.
Finns det ett sätt att bara ha min offentliga nyckel signerad?
Kommentarer
- Certifikatet innehåller privat nyckel? Va? Hur lyckades du göra det här? Kan du lägga upp den filen på pastebin.com? (Gör om det med ett andra nyckelpar så att du inte behöver ’ behöver dela originalet.)
- Jag tror att jag börjar förstå. Även om jag behöver den privata nyckeln för att producera en CSR, innehåller CSR och det resulterande certifikatet inte den privata nyckeln. Ett certifikat är i själva verket en signerad offentlig nyckel som är exakt vad jag vill ha.
Svar
Underteckna en offentlig nyckel är faktiskt ett certifikat. Det här är stegen jag tar för att ta fram ett offentligt nyckelcertifikat som jag kan distribuera till andra så att de kan kommunicera säkert med mig:
Installation
- Skapa privata nycklar:
openssl genrsa -out private.pem 2048
- Generera de offentliga nycklarna:
openssl rsa -in private.pem -outform PEM -pubout -out public.pem
- Skapa en CSR (Certificate Signing Request)
openssl req -new -key private.pem -out certificate.csr
- Skapa ett självsignerat certifikat (du kan dela detta certifikat)
openssl x509 -req -days 365 -in certifikat.csr -signkey privat.pem -ut certifikat.crt
Kryptering
openssl rsautl -kryptera -inkey privat.pem -nyckelform PEM -in data> krypterad_data
Dekryptering
- Extrahera den offentliga nyckeln från certifikaten
openssl x509 -pubkey -noout -in certificate.crt> certpubkey.pem
- Dekryptera data
openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data> data
Om du tänker ha din nyckel signerad av en CA måste du skicka din CSR-fil (och lite kontanter) till din CA som du väljer, de kommer att ge dig det certifikat du kan använda istället för det självsignerade certifikatet I nämns i stegen ovan.
Kommentarer
- Detta är typ av motsatsen till vad jag frågar men det kommer att göra för diskussionsändamål. För att den andra sidan ska dekryptera behöver de antingen den offentliga nyckeln som extraheras av mig som är föremål för MITM-attacken eller så behöver de hela certifikatet som innehåller den (krypterade) privata nyckeln
- @ user1683793 The andra änden behöver två certifikat. Den första som de redan borde ha (det självsignerade CA-certifikatet). Den andra innehåller den offentliga nyckeln som du vill verifiera och är signerad med CA-certifikatet (med tillhörande privat CA-nyckel). Giltigheten för det andra certifikatet testas med den offentliga nyckeln i CA-certifikatet. Privata nycklar hålls alltid privata.
- Jag tror att du vill ha ” -kryptera ” och ” -decrypt ” istället för ” -sign ” och ” -verifiera ”. (Detaljer här: czeskis.com/random/openssl-encrypt-file.html )
- Fungerar inte: 2. Dekryptera data fungerade inte för mig. Med:
openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data > datafår jag det här felet / msg:A private key is needed for this operation - Avsnitt
Setup, steg2gerpublic.pem– det används inte ’ i ytterligare steg. Vad använder den offentliga nyckeln när CSR genereras med privat nyckel?
Svar
Det bör vara tre enheter involverade i processen:
- Avsändaren – Du
- Mottagaren – Användaren
- Certifikatutfärdare – Tillförlitlig tredje part (Eller du i vissa fall)
Processen som håller saker säkra är ”Avsändaren”, genererar ett par nycklar (offentliga och privata). Jag vill hänvisa till dessa som nyckel och lås för en bättre visuell. Nyckeln (privat) ska aldrig lämna avsändarens besittning, det är därför den kallas en privat nyckel.
Avsändaren genererar sedan en certifikatsigneringsförfrågan (CSR) med den offentliga nyckeln (lås ) som vidarebefordras till certifikatutfärdaren (Trusted Third Party) signerar certifikatutfärdaren den offentliga nyckeln (låset) med certifikatutfärdarens privata nyckel.
Certifikatutfärdaren skickar nu den offentliga nyckeln ”avsändarna” som signeras av certifikatutfärdarens privata nyckel tillbaka till ”avsändaren”, som nu är certifikatet.
Mottagaren får certifikatet (kan sägas genom webbläsaren) och verifierar att det är giltigt med certifikatutfärdarens offentliga nyckel som både ”avsändaren” och ”mottagaren” har eftersom de är den betrodda tredje parten. När den väl verifierade kan den offentliga nyckeln i certifikatet lita på * att den är ”Avsändarens” offentliga nyckel oförändrad.
Om ”Mottagaren” behöver skicka data till ”Avsändaren” skulle de använda offentlig nyckel från det betrodda certifikatet för att kryptera data till cypertext som sedan skickas vidare till ”Avsändaren”. Eftersom endast ”Avsändarens” privata nyckel kan dekryptera cyphertext som krypterades med ”Avsändarens” offentliga nyckel någon i mitten har i huvudsak värdelös förvrängd text.
I vissa fall kan ”avsändaren” generera sin egen certifikatutfärdare genom att underteckna sin egen CSR med en annan uppsättning nycklar eller självsignering med samma uppsättning I det här fallet måste ”Avsändarens” offentliga nyckel vara känd av båda parter genom en säker kanal för att ha något förtroende. I programvara kan du inkludera ett certifikat i leveransen som kan användas som den pålitliga tredje parten.
* betrodd är endast giltigt om certifikatutfärdaren upprätthåller en CRL (Certificate Revocation List) och alla parter övervakar listan för att säkerställa att det utfärdade certifikatet inte har äventyrats. Fallet där certifikatutfärdaren är komprometterad och den privata nyckeln läckt ut finns och när det händer kan kompromissagenten använda den privata nyckeln för att skapa ett betroddat certifikat som efterliknar ”avsändaren” , i så fall är en MITM möjlig och MITM kan ta emot data från ”The Sender” dekryptera, lagra, kryptera med ett giltigt certifikat som ser ut som ”The Sender” och sedan skicka det till ”The Receiver”.
Svar
Ta ut den krypterade privata nyckeln ur kopian av CA-certifikatet som du skapade (när du ger den till andra). behöver inte vara där om du inte använder det för att underteckna ett certifikat som innehåller anoth är offentlig nyckel.
När du skickar över din offentliga nyckel, istället skicka över ett helt certifikat (förutom den privata nyckeln), signerad med tillhörande privat CA-nyckel. För att kontrollera giltigheten för den offentliga nyckeln inuti den måste du kontrollera hash för certifikatet mot den krypterade hash (som krypterades med CA: s privata nyckel). Detta dekrypteras med CA: s offentliga nyckel . Om dekrypteringen lyckas och hash matchar hash för certifikatet kan informationen inuti certifikatet lita på.
Det finns också mer än bara kryptering, till exempel en omspelningsattack där en angripare skickar tidigare sparade krypterade data. TLS täcker mycket mer än den genomsnittliga personen skulle tro, och att implementera ett liknande system rekommenderas absolut inte. Använd TLS när det är möjligt för allt som är avsett att vara privat.