Semnarea unei chei publice este efectiv un certificat. Aceștia sunt pașii pe care îi fac pentru a produce un certificat de cheie publică pe care îl pot distribui altora, astfel încât să poată comunica în siguranță cu mine:

Configurare

1. Generați cheile private:
   

   openssl genrsa -out private.pem 2048

2. Generați cheile publice:
   

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

3. Creați un CSR (Cerere de semnare a certificatului)
   

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

4. Creați un certificat autosemnat (puteți distribui acest certificat)
   

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

Criptare

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

Decriptare

1. Extrageți cheia publică din certificate
   

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

2. Decriptați datele
   

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

Dacă intenționați ca cheia dvs. să fie semnată de un CA, va trebui să trimiteți fișierul CSR (și ceva bani) către CA-ul ales, vă vor oferi certificatul pe care îl puteți utiliza în locul certificatului auto-semnat I menționat în pașii de mai sus.

Comentarii

• Acesta este un fel de invers a ceea ce cer, dar va face în scopul discuției. Pentru ca cealaltă parte să decripteze, acestea au nevoie fie de cheia publică extrasă de mine care este supusă atacului MITM, fie au nevoie de întregul certificat care include cheia privată (criptată)
• @ user1683793 celălalt capăt are nevoie de două certificate. Primul dintre care ar trebui să aibă deja (certificatul CA autosemnat). Al doilea conține cheia publică pe care doriți să o verificați și este semnat cu certificatul CA (utilizând cheia privată CA asociată). Valabilitatea celui de-al doilea certificat este testată folosind cheia publică din certificatul CA. Cheile private sunt întotdeauna private.
• Cred că doriți ” -encrypt ” și ” -decrypt ” în loc de ” -sign ” și ” -verify „. (Detalii aici: czeskis.com/random/openssl-encrypt-file.html )
• Nu funcționează: 2. Decriptarea datelor nu a funcționat pentru mine. Cu: openssl rsautl -decrypt -inkey certpubkey.pem -keyform PEM -pubin -in encrypted_data > data primesc această eroare / msg: A private key is needed for this operation
• Secțiunea Setup, pasul 2 oferă public.pem – nu este ‘ folosit în alte pași. La ce folosește acea cheie publică atunci când CSR este generat cu cheie privată?

Ar trebui să existe trei entități implicate în proces:

1. Expeditorul – Dumneavoastră
2. Destinatarul – Utilizatorul
3. Autoritatea de certificare – Terță parte de încredere (Sau, în unele cazuri)

Procesul care păstrează lucrurile în siguranță este „Expeditorul”, generează o pereche de chei (publice și private). Îmi place să mă refer la acestea drept cheie și blocare pentru un vizual mai bun. Cheia (privată) nu ar trebui să părăsească niciodată posesia expeditorului, de aceea se numește cheie privată.

Expeditorul generează apoi o cerere de semnare a certificatului (CSR) cu cheia publică (blocare) ) care este redirecționat către autoritatea de certificare (terță parte de încredere), autoritatea de certificare semnează cheia publică (blocare) cu cheia privată a autorităților de certificare.

Autoritatea de certificare trimite acum cheia publică „Expeditorii” care este semnat de cheia privată a autorităților de certificare înapoi la „Expeditorul”, care este acum certificatul.

Destinatarul primește certificatul (să spunem prin browserul web) și verificăm dacă este valabil cu cheia publică a autorităților de certificare pe care o au atât „Expeditorul”, cât și „Destinatarul”, întrucât sunt părțile terțe de încredere. După verificare, cheia publică din certificat poate fi de încredere * ca fiind cheia publică „Expeditorul” nealterată.

Dacă „Destinatarul” trebuie să trimită date către „Expeditor”, aceștia ar folosi cheie publică din certificatul de încredere pentru a cripta datele în cipertext care apoi sunt transmise la „Expeditorul”. Deoarece numai cheia privată „Expeditorul” poate decripta textul criptat care a fost criptat cu cheia publică „Expeditorul” oricine în mijloc are, în esență, un text inutil.

În anumite cazuri, „Expeditorul” își poate genera propria autoritate de certificare prin semnarea propriului CSR cu un set diferit de chei sau autosemnare cu același set de chei. În acest caz, cheia publică „Expeditorul” trebuie să fie cunoscută de ambele părți printr-un canal sigur pentru a avea încredere. În software, puteți include un certificat în livrabil care poate fi utilizat ca terță parte de încredere.

* încredere este valabilă numai dacă autoritatea de certificare menține un CRL (Lista de revocare a certificatului) și toate părțile monitorizează lista pentru a ne asigura că certificatul emis nu a fost compromis. Există caz în care autoritatea de certificare este comprimată și se scurge cheia privată, iar când se întâmplă acest lucru agentul compromisor poate folosi cheia privată pentru a genera un certificat de încredere care imită „Expeditorul” , în acest caz, este posibil un MITM și MITM poate primi date de la „Expeditor” decriptează, stochează, criptează cu un certificat valid care arată ca „Expeditorul”, apoi treceți-l la „Receptor”.

Scoateți cheia privată criptată din copia certificatului CA pe care l-ați creat (când îl dați altora). Cheia privată nu nu trebuie să fii acolo decât dacă îl vei folosi pentru a semna un certificat care conține altul er cheie publică.

Când trimiteți peste cheia dvs. publică, trimiteți în schimb un întreg certificat (cu excepția cheii private), semnat folosind cheia privată CA asociată. Pentru a verifica validitatea cheii publice din interiorul acesteia, trebuie să verificați hash-ul certificatului cu hash-ul criptat (care a fost criptat folosind cheia privată a CA). Aceasta este decriptată folosind cheia publică a CA . Dacă decriptarea reușește și hash-ul se potrivește cu hash-ul certificatului, atunci informațiile din certificat pot fi de încredere.

Există, de asemenea, mai mult decât simpla criptare, de exemplu un atac de redare în care un atacator trimite date criptate salvate anterior. TLS acoperă mult mai mult decât ar crede o persoană obișnuită, iar implementarea unui sistem similar nu este absolut recomandată. Utilizați TLS ori de câte ori este posibil pentru orice intenționează să fie privat.