Signering av en offentlig nøkkel er faktisk et sertifikat. Dette er trinnene jeg tar for å lage et sertifikat for offentlig nøkkel jeg kan distribuere til andre, slik at de kan kommunisere sikkert med meg:

Oppsett

1. Generer de private nøklene:
   

   openssl genrsa -out private.pem 2048

2. Generer de offentlige nøklene:
   

   openssl rsa -in private.pem -outform PEM -pubout -out public.pem

3. Opprett en CSR (Certificate Signing Request)
   

   openssl req -new -key private.pem -out certificate.csr

4. Opprett et selvsignert sertifikat (du kan dele dette sertifikatet)
   

   openssl x509 -req -days 365 -in certificate.csr -signkey private.pem -out certificate.crt

Kryptering

openssl rsautl -encrypt -inkey private.pem -keyform PEM -in data> encrypted_data

Dekryptering

1. Trekk ut den offentlige nøkkelen fra sertifikatene
   

   openssl x509 -pubkey -noout -in certificate.crt> certpubkey.pem

2. Dekrypter dataene
   

   openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data> data

Hvis du har til hensikt å få nøkkelen din signert av en CA, må du sende CSR-filen (og litt kontanter) til den valgte CA, de vil gi deg sertifikatet du kan bruke i stedet for det selvsignerte certet I nevnt i trinnene ovenfor.

Kommentarer

• Dette er litt omvendt av det jeg spør, men det vil gjøre for diskusjonsformål. For at den andre siden skal dekryptere, trenger de enten den offentlige nøkkelen som er hentet ut av meg som er underlagt MITM-angrepet, eller de trenger hele sertifikatet som inkluderer (kryptert) privat nøkkel
• @ user1683793 The andre enden trenger to sertifikater. Den første skal de allerede ha (det selvsignerte CA-sertifikatet). Den andre inneholder den offentlige nøkkelen du vil bekrefte, og er signert med CA-sertifikatet (ved hjelp av den tilhørende private private nøkkelen). Gyldigheten til det andre sertifikatet testes med den offentlige nøkkelen i CA-sertifikatet. Private nøkler holdes alltid private.
• Jeg tror du vil ha » -kryptere » og » -decrypt » i stedet for » -sign » og » -verifiser «. (Detaljer her: czeskis.com/random/openssl-encrypt-file.html )
• Fungerer ikke: 2. Dekryptere dataene fungerte ikke for meg. Med: openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data > data får jeg denne feilen / msg: A private key is needed for this operation
• Seksjon Setup, trinn 2 gir public.pem – det er ikke ‘ t brukt i ytterligere trinn. Hva er bruken av den offentlige nøkkelen når CSR genereres med privat nøkkel?

Det bør være tre enheter involvert i prosessen:

1. Avsenderen – Du
2. Mottakeren – Brukeren
3. Sertifiseringsmyndighet – Tillit tredjepart (Eller du i noen tilfeller)

Prosessen som holder ting trygt er «Avsenderen», genererer et par nøkler (offentlige og private). Jeg refererer til disse som nøkkel og lås for bedre visuelt. Nøkkelen (privat) skal aldri forlate avsenderens besittelse, det er derfor den kalles en privat nøkkel.

Avsender genererer deretter en Certificate Signing Request (CSR) med den offentlige nøkkelen (lås ) som blir videresendt til Certificate Authority (Trusted Third Party), signerer Certificate Authority den offentlige nøkkelen (lås) med Certificate Authorities private key.

Certificate Authority sender nå «The Senders» offentlig nøkkel som er signert av sertifiseringsmyndighetens private nøkkel tilbake til «Avsenderen», som nå er sertifikatet.

Mottakeren får sertifikatet (kan si gjennom nettleseren) og verifisere at det er gyldig med sertifikatmyndighetens offentlige nøkkel som både «avsenderen» og «mottakeren» har siden de er den pålitelige tredjepart. Når den er bekreftet, kan den offentlige nøkkelen i sertifikatet stole på at den er «Avsenderens» offentlige nøkkel uendret.

Hvis «Mottakeren» trenger å sende data til «Avsenderen», vil de bruke offentlig nøkkel fra det pålitelige sertifikatet for å kryptere dataene i cypertekst som deretter sendes videre til «Avsenderen». Siden bare «Avsenderens» private nøkkel kan dekryptere cypherteksten som ble kryptert med «Avsenderens» offentlige nøkkel i midten har i det vesentlige unyttig forvrengt tekst.

I visse tilfeller kan «Avsenderen» generere sin egen sertifikatmyndighet ved å signere sin egen CSR med et annet sett med nøkler eller selvsignere med samme sett med nøkler. I dette tilfellet må «avsenderens» offentlige nøkkel være kjent av begge parter gjennom en sikker kanal for å ha tillit. I programvare kan du inkludere et sertifikat i leveransen som kan brukes som den pålitelige tredjeparten.

* klarert er bare gyldig hvis sertifikatmyndigheten opprettholder en CRL (Certificate Revocation List) og alle parter overvåker listen for å sikre at det utstedte sertifikatet ikke er kompromittert. Saken der sertifikatmyndigheten er kompromittert og den private nøkkelen er lekket, eksisterer, og når det skjer, kan den kompromitterende agenten bruke den private nøkkelen til å generere et klarert sertifikat som etterligner «Avsenderen» , i så fall er en MITM mulig og MITM kan motta data fra «The Sender» dekryptere, lagre, kryptere med et gyldig sertifikat som ser ut som «The Sender», og deretter sende det til «The Receiver».

Ta den krypterte private nøkkelen ut av kopien av CA-sertifikatet du opprettet (når du gir den til andre). trenger ikke å være der med mindre du skal bruke det til å signere et sertifikat som inneholder anoth er offentlig nøkkel.

Når du sender over den offentlige nøkkelen, sender du i stedet et helt sertifikat (bortsett fra den private nøkkelen), signert ved hjelp av den tilknyttede CA private nøkkelen. For å sjekke gyldigheten av den offentlige nøkkelen inne i den, må du sjekke sertifikatets hash mot den krypterte hashen (som ble kryptert med CAs private nøkkel). Denne dekrypteres ved hjelp av CAs offentlige nøkkel . Hvis dekrypteringen er vellykket og hashen samsvarer med hasjen til sertifikatet, kan informasjonen inne i sertifikatet stole på.

Det er også mer til det enn bare kryptering, for eksempel et repriseangrep der en angriper sender tidligere lagrede krypterte data. TLS dekker mye mer enn den gjennomsnittlige personen skulle tro, og det anbefales absolutt ikke å implementere et lignende system. Bruk TLS når det er mulig for alt som er ment å være privat.