X.509

X.509 este un standard propus de Uniunea Internațională a Telecomunicațiilor (UIT-T), utilizat pentru a defini formatul certificatelor cu cheie publică (PKC) și ale autorităților de certificare (CA). Certificatele sunt utilizate pentru validarea identității și transmiterea datelor criptate pe care numai proprietarul (persoana, organizația sau aplicația) unui certificat specific este capabil să le decripteze și să le citească. Acestea sunt emise de Autoritatea de certificare (CA), o terță parte de încredere care asigură corespondența unei chei publice cu o identitate specifică. Una dintre cele mai răspândite utilizări ale X.509 este pe internet , certificatul SSL / TLS este utilizat în protocolul omonim pentru a cripta comunicațiile dintre un site web și browserul nostru.

Standardul definește, de asemenea, sub diferite aspecte, utilizarea certificatelor în infrastructurile cu cheie publică (PKI) și în infrastructurile de gestionare a privilegiilor (PMI). În plus față de certificatul de cheie publică și certificatele de atribut, sunt descrise și următoarele tipuri de date: lista de revocare a certificatului (CRL) și lista de revocare a certificatului de atribut (ACRL). ^[1]

Listele de revocare a certificatelor (CRL) conțin lista certificatelor care au fost revocate de autoritatea emitentă. CRL-urile sunt consultate pentru a asigura validitatea și fiabilitatea certificatelor pe care urmează să le utilizați. Operație efectuată de browser de fiecare dată când vă conectați la un site prin SSL / TLS .

Istorie și utilizare

ITU-T X.509 a fost introdus pentru prima dată în 1988 ca parte a standardului X.500 , un set de recomandări pentru un serviciu director . Formatul certificatului definit în 1988 este versiunea unu (v1). Acest lucru necesita un sistem strict de ierarhii ale autorității de certificare (CA) pentru a asigura legitimitatea unui certificat. Spre deosebire de modelul rețelei de încredere (rețeaua de încredere), utilizat de PGP , unde oricine, nu doar CA, poate semna și apoi atesta (certifica) corespondența dintre o cheie publică și subiectul căruia îi aparține.

Standardul a fost revizuit în 1993 cu adăugarea de suport pentru două atribute noi în certificat, această extensie constituie versiunea a doua (v2). În același an, cu Internet Privacy Enhanced Mail (PEM) [rfc-1422] a fost propusă o infrastructură cu cheie publică bazată pe versiunea X.509 prima (v1). Experiența dobândită până acum a scos la iveală necesitatea unei extinderi suplimentare, pentru a face certificatele mai detaliate și a facilita interoperabilitatea acestora în sisteme cu profiluri diferite, cum ar fi Internetul. În 1996, versiunea trei (v3) a fost apoi finalizată, prin colaborarea ISO / IEC , ITU-T șiANSI X9. Versiunea trei (v3) a X.509 permite o mai mare flexibilitate în structuri pentru crearea certificatelor X.509, cu posibilitatea utilizării topologiilor PKI în stil mesh sau bridge [rfc-4158] , chiar și într-o rețea peer de încredere. ca cel al Open-PGP , dar este rar implementat în acest fel. Acest lucru ajută la depășirea structurii ierarhice rigide a PKI-urilor.

Sistemul X.500 nu a fost niciodată complet finalizat, iar IETF și grupurile de lucru pentru infrastructura cu cheie publică (PKIX) au adaptat standardul cu o structură mai flexibilă, potrivită pentru Internet. De fapt, termenul de certificat X.509 se referă în general la profilul certificatului și listei de revocare a certificatului (CRL) IETF bazat pe standardul X.509 v3, așa cum este descris în RFC 5280 .

Certificate

În sistemul X.509, o autoritate de certificare (CA) emite un certificat care asociază o cheie publică cu un nume unic sau cu o entitate, cum ar fi o adresă de e-mail sau o înregistrare DNS . Autenticitatea unui certificat și a unei autorități de certificare depinde de certificatul rădăcină . Certificatele rădăcină sunt implicit de încredere. Unul dintre exemplele de software distribuit cu certificate rădăcină preinstalate sunt browserele , ceea ce face posibilă funcționarea certificatelor SSL / TLS . ^[2]

Structura unui certificat

Structura unui certificat X.509.

Versiunea trei (v3) a certificatelor digitale X.509 are trei intrări principale: certificatul, identificatorul algoritmului de semnare a certificatului și semnarea certificatului. Certificatul este descris printr-o serie de atribute, cum ar fi versiunea, ID-ul algoritmului, numărul de serie, emitentul, solicitantul, validitatea, informațiile cheii publice ale solicitantului, extensiile și alte intrări opționale. Informațiile despre cheia publică a solicitantului sunt apoi detaliate în continuare cu algoritmul utilizat și cheia publică în sine, în timp ce valabilitatea este indicată de data de începere și de sfârșit, care determină în cele din urmă perioada de viață a certificatului.

Codurile unice de identificare ale emitentului și ale solicitantului au fost introduse în versiunea a doua (v2), pentru a permite reutilizarea acestora în alte certificate. De exemplu, dacă o autoritate de certificare (CA) eșuează și nu mai este autorizată să exercite. Mai târziu, o altă CA cu același nume s-ar putea înregistra în lista publică a CA, chiar dacă nu are nicio relație cu prima CA. Cu toate acestea, IETF recomandă să nu refolosiți același nume. Prin urmare, versiunea doi (v2) nu a avut o utilizare pe scară largă pe Internet .

Extensiile au fost introduse în versiunea trei (v3). O CA poate utiliza extensii numai pentru certificate care au o utilizare specifică, cum ar fi semnarea obiectelor digitale. Fiecare extensie de certificat are propriul identificator, exprimat ca identificator de obiect (OID) , un set de valori care pot fi critice sau non-critice. Dacă, în timp ce analizează un certificat, un sistem întâlnește o extensie critică pe care nu o recunoaște, certificatul este respins. O extensie non-critică poate fi ignorată dacă nu este recunoscută, dar în caz contrar trebuie procesată. RFC 5280 definește, în secțiunea 4.2 ^[3] , extensiile utilizate în Internet PKI. Se pot utiliza extensii suplimentare, dar trebuie acordată atenție includerii extensiilor critice, deoarece acestea pot compromite interoperabilitatea certificatului.

În toate versiunile, numărul de serie trebuie să fie unic pentru fiecare certificat emis de o autoritate de certificare (CA) specifică.

Extensii tipice de fișiere cu certificate X.509

Extensii comune pentru fișierele care conțin certificate X.509:

• .pem - Mail optimizat pentru confidențialitate , este un certificat codificat cu Base64 , inclus în „----- BEGIN CERTIFICATE -----” și „----- END CERTIFICATE -----”;
• .cer , .crt , .der - certificat codificat DER , uneori secvențe de certificate;
• .p7b , .p7c - .p7c PKCS # 7 SignedData fără date, numai certificatul (certificatele) sau CRL (Lista revocării certificatului);
• .pfx , .P12 - PKCS # 12 , poate conține certificate și chei publice și private (protejate prin parole);

PKCS # 7 este un standard pentru semnarea sau criptarea (numită „învăluire”, „încapsulare”, „învăluire” în limba engleză) a datelor. Deoarece este necesar un certificat pentru a verifica datele semnate, acesta poate fi inclus într-o structură SignedData. Un fișier .p7c nu este altceva decât o structură „degenerată” SignedData (fără date semnate).

PKCS # 12 provine din standardul PFX (Personal inFormation eXchange) și este utilizat pentru a schimba obiecte publice și private în același fișier.

Un fișier .pem poate fi utilizat nu numai pentru certificate, ci și pentru chei private, cuprinse în liniile corespunzătoare BEGIN / END.

Cum să solicitați un certificat

O persoană / entitate poate solicita certificarea cheii sale publice prin trimiterea unei cereri de semnare a certificatului (CSR) către o autoritate de certificare (CA). Mai întâi se generează o pereche de chei (private / publice). Cheia privată este păstrată secretă și este utilizată pentru a semna CSR-ul. Solicitarea conține toate informațiile necesare pentru validarea identității solicitantului, pe lângă cheia publică. În urma verificărilor, certificatul este semnat digital de CA pentru a evita modificări ulterioare. În acest moment, CA publică certificatul pentru al găsi.

Există diferite tipuri de entități definite în X.509:

• Autoritatea de certificare (CA): emite certificate, generează CRL-uri, generează perechea de chei Pb și Pr, confirmă faptul că fiecare utilizator care solicită eliberarea certificatului este în posesia cheii private corespunzătoare, verifică unicitatea cheii Pb.
• Autorități de înregistrare locale: unele CA necesită prezența fizică a utilizatorului final și, prin urmare, un LRA joacă rolul de intermediar, care rezolvă această problemă.
• Autoritatea rădăcină: este autoritatea responsabilă cu aprobarea politicii globale de certificare. De obicei, este utilizat pentru certificarea altor CA, nu a utilizatorilor.
• Autoritatea de certificare a politicii: vă permite să creați, pentru unele grupuri de utilizatori, extensii ale politicilor de certificare stabilite inițial.
• Utilizatorul final: generează și verifică documentele semnate

Cum să revocați un certificat

Standardul X.509 definește formatul și semantica listelor de revocare a certificatelor (CRL) pentru PKIs. Fiecare obiect al listei de revocare a certificatului include numărul de serie al certificatului revocat și data revocării. Fișierele CRL sunt, de asemenea, semnate de autoritatea de certificare pentru a preveni manipularea. Informații opționale, cum ar fi o limită de timp, pot fi adăugate dacă revocarea se aplică numai pentru o perioadă de timp sau motivul revocării.

Problema cu CRL-urile, ca și în cazul tuturor listelor negre , este dificultatea de a le menține și reprezintă un mod ineficient de distribuire a informațiilor critice într- un sistem în timp real . Totul depinde de frecvența actualizării CRL-urilor, chiar dacă sunt actualizate la fiecare oră, de exemplu, un certificat revocat poate fi totuși acceptat. De asemenea, dacă un CRL nu este disponibil, orice serviciu care se bazează pe acesta nu este utilizabil.

Protocolul de stare a certificatului online (OCSP) este o alternativă la CRL-uri, acesta trimite certificatul către CA-uri pentru a fi verificat direct de acestea, un mod utilizat de browsere . Folosind mai puțin trafic de date pentru verificare. ^[4]

Lanț certificat

Un serviciu care utilizează certificate X.509 necesită cunoașterea unei chei publice, înainte de a utiliza certificatul care îl conține, acesta trebuie validat. Dacă serviciul nu are deja o copie validă a cheii publice a CA care a semnat certificatul, numele CA și informații conexe (cum ar fi perioada de valabilitate), are nevoie de certificate suplimentare pentru a obține acea cheie publică. În general, aveți nevoie de o listă de certificate, inclusiv certificatul de entitate finală semnat de o CA, urmat de unul sau mai multe certificate CA semnate de alte CA. Aceste lanțuri de certificate (numite și căi de certificare ^[3] ) sunt necesare, deoarece software-ul este inițializat de obicei cu un număr limitat de chei publice CA verificate.

Un lanț de certificate are următoarele proprietăți:

1. Entitatea emitentă a fiecărui certificat trebuie să corespundă solicitantului pentru următorul certificat din listă. Cu excepția ultimei, de obicei autosemnate.
2. Fiecare certificat trebuie să fie semnat de cheia privată corespunzătoare următorului certificat din lanț. Prin urmare, semnătura unui certificat poate fi verificată folosind cheia publică conținută în certificatul următor.
3. Ultimul certificat din listă este certificatul rădăcină , numit și ancoră de încredere : un certificat de încredere intrinsecă.

Putem distinge între un certificat emis pentru CA și cel emis pentru entitățile finale (de exemplu, utilizatori, dispozitive, servere web , procese) datorită extensiei Basic Constraints ^[5] . Un certificat emis unei CA se numește certificat încrucișat . Certificatele încrucișate sunt utilizate atât într-un model cu o structură ierarhică, unde un CA mai autorizat (încrucișat) certifică o CA subordonată, cât și într-un model distribuit, unde mai multe CA pot emite certificate unul pentru celălalt ^[6] .

Toate certificatele din lanț trebuie verificate. În general, procesarea unui lanț de certificate are loc în două etape:

1. Construirea unuia sau mai multor lanțuri de validare a certificatelor posibile. Posibil deoarece unele dintre acestea pot să nu fie valabile din diverse motive, cum ar fi lungimea lanțului sau pentru restricții / constrângeri întâlnite.
2. Validarea lanțului, care include verificarea faptului că fiecare certificat din lanț se află încă în perioada de valabilitate, nu a fost revocat, este intact și, de asemenea, că sunt îndeplinite orice extensii critice.

Diagrama unui certificat încrucișat.

Prin examinarea modului în care este construit și validat un lanț de certificate, se poate vedea că un certificat poate face parte din mai multe lanțuri de certificate, cel mult toate valabile. Acest lucru se datorează certificatelor încrucișate . De fapt, mai multe certificate pot fi generate pentru o CA cu același subiect și cheie publică, dar semnate cu chei private diferite, de către diferite CA. Astfel, deși un singur certificat X.509 poate avea un singur emitent și o singură semnătură, acesta poate fi legat la mai multe certificate în mod valid. Acesta este un aspect crucial pentru certificarea (încrucișată) a mai multor PKI și aplicații diferite.

Exemplu de certificat încrucișat

În diagramă, fiecare dreptunghi reprezintă un certificat, cu subiectul în caractere aldine. A → B înseamnă „A a fost semnat de B” (mai exact, „A a fost semnat de cheia privată corespunzătoare cheii publice din certificatul B”). Certificatele cu aceeași culoare (cu excepția celor transparente) conțin aceeași cheie publică.

De exemplu, pentru a se asigura că entitățile finale certificate în PKI.2, cum ar fi cert.2.2, sunt verificabile prin PKI.1, CA.1 generează un certificat care conține cheia publică a CA.2, în acest caz cert. 2.1. Acum, atât cert.2, cât și cert.2.1 în verde au același subiect și cheie publică. Astfel, există două lanțuri valide pentru cert.2.2 (User.2):

• cert.2.2 → cert.2
• cert.2.2 → cert.2.1 → cert.1

În mod similar, CA.2 poate genera un certificat care conține cheia publică a CA.1 (cert.1.1), astfel încât certificatele din PKI.1 să fie recunoscute de PKI.2.

Siguranță

Există numeroase publicații despre problemele PKI ale lui Bruce Schneier , Peter Gutmann și alți experți în securitate. ^{[7] [8] [9]}

Legăturile slabe din arhitectura standardului

• CRL-urile sunt liste negre pentru certificate care nu mai sunt valabile. Una dintre cele mai frecvente cauze pentru revocarea unui certificat este compromiterea cheii sale private. Problema constă în menținerea listei și distribuția ineficientă a acesteia. Deci, pentru un sistem, un certificat ar putea fi valabil, chiar dacă a fost revocat în mod formal. În plus, CRL-urile pot atinge dimensiuni considerabile, motiv pentru care listele sistemelor cache intervin de obicei în calea verificării stării unui certificat, pentru a evita să fie descărcat la fiecare cerere. Acest lucru pune, de asemenea, problema actualizării cache - ului . În cazul în care CRL-urile nu sunt disponibile, orice serviciu legat de certificate este inutilizabil, ceea ce poate crea un refuz de serviciu , pierzând astfel capacitatea de a opera offline .
• Protocolul de stare a certificatului online (OCSP) este un protocol utilizat de browsere pentru verificarea certificatelor SSL / TLS . Este o versiune îmbunătățită a CRL-urilor. Și aceasta, la fel ca CRL-urile, poate prezenta probleme de latență și indisponibilitate a serverelor CA. În general, pentru a continua să folosim un anumit serviciu, tindem să ignorăm răspunsul OCSP care nu a primit problema sau mesajele de eroare, un comportament numit soft-fail . Adam Langley ^{[10] a} spus că verificarea soft-fail a CRL-urilor este ca centura de siguranță care funcționează, cu excepția cazului în care ar trebui:

• O altă problemă apare din faptul că diferite browsere utilizează modalități diferite de verificare a CRL-urilor. Dacă nu se folosește un certificat de validare extinsă , unele browsere verifică doar validitatea certificatului de server și nu întregul lanț de certificate. De asemenea, permit sesiunii să continue fără niciun mesaj de eroare.
• O alternativă la OCSP este capsarea OCSP . Acest lucru vă permite să mutați procesul de interogare CRL din browser pe serverul HTTPS . Prin urmare, serverul poate verifica periodic starea certificatului său și poate informa clientul . Acest lucru elimină dependența dintre browser și CA, cu o scădere consecventă a timpului de interogare, o confidențialitate mai mare pentru cei care utilizează un serviciu și o încărcare mai mică pe serverele CA. Cu toate acestea, browserul nu știe când să se aștepte la un răspuns OCSP Stampling, deoarece acesta este opțional. Deci, un certificat revocat utilizat fără OCSP Stampling cade în aceeași problemă ca OCSP. ^[11] Deși OCSP Stampling are multiple avantaje față de OCSP, adoptarea sa nu este răspândită și este slab acceptată de browsere și servere .
• Revocarea certificatelor rădăcină este o problemă care nu este abordată. Dacă lista certificatelor rădăcină este compromisă cu cheile rădăcină publice nelegitime, acestea pot fi folosite pentru a crea certificate valide. Prin urmare, nu este suficient să păstrați cheile publice rădăcină într-un certificat rădăcină , deoarece acesta este auto-semnat și nu oferă securitate suplimentară. ^[7]
• PKI în stilul X.509 sunt un director de nume, pe baza căruia se găsește cheia publică a entității cu care doriți să comunicați. Dar pot exista ambiguități în nume sau mai multe entități cu același nume, astfel încât alte informații sunt adăugate pentru a crea un identificator unic, pentru a face o entitate distinctivă în cadrul aceleiași CA. ^[9]

Puncte slabe în criptografie

Securitatea unei semnături digitale se bazează pe o funcție hash criptografică . Când un PKI autorizează utilizarea unei funcții hash care nu mai este sigură, acesta poate fi exploatat pentru a compromite certificatele. Mai exact, dacă cineva reușește să producă o coliziune pentru o funcție hash, în care hashul unui certificat este identic cu un alt hash, al unui certificat al cărui conținut a fost creat de un cracker . Crackerul adaugă apoi semnătura furnizată de CA la certificatul său, care este semnat în mod legitim de către o CA. Fiind conținutul ales de cracker , de exemplu, acesta poate extinde valabilitatea numelui de gazdă dincolo de termenul său sau poate introduce câmpul CA: true permițând emiterea altor certificate.

• În 2005, Arjen Lenstra și Benne de Weger au demonstrat posibilitatea de a crea două certificate X.509 cu aceeași semnătură, dar care diferă doar în cheia publică, datorită unui atac de coliziune asupra funcției hash MD5 . ^[12]
• În 2008, Alexander Sotirov și Marc Stevens au prezentat la Chaos Communication Congress o modalitate practică de a crea o autoritate de certificare fictivă, acceptată de toate browserele obișnuite, profitând de faptul că RapidSSL a emis încă certificate bazate pe MD5 . ^[13]
• În 2009, la Conferința Eurocrypt , un cercetător australian de la Universitatea din Macquarie a prezentat o metodă pentru creșterea posibilității coliziunilor în funcția de hash SHA-1. ^[14]
• În 2017, un grup de cercetători a produs o coliziune în funcția SHA-1, demonstrând slăbiciunea acesteia. ^[15]

Măsuri luate

Exploatarea coliziunilor în funcțiile hash pentru a manipula certificatele X.509 implică faptul că crackerul cunoaște a priori conținutul certificatului semnat de CA. Această posibilitate poate fi redusă chiar de către AC, prin introducerea unei componente aleatorii în certificat, de obicei numărul de serie.

Forumul CA / Browser necesită utilizarea numărului de serie din 2011, în Cerințele sale de bază . ^[16]

Mai mult, din 2016, cerințele de bază interzic emiterea de certificate care utilizează algoritmul hash SHA-1 . Anul următor, browsere precum Chrome , Firefox , Edge și Safari nu mai acceptau certificate semnate cu SHA-1 . ^{[17] [18] [19] [20]} Cu toate acestea, există o serie de software care nu sunt browser care acceptă în continuare certificate SHA-1. ^[21]

Autoritatea de certificare

• Să criptăm , o autoritate de certificare care emite certificate gratuit. Să Criptăm , pe letsencrypt.org .
• Actalis SpA , o autoritate de certificare italiană care emite certificate X.509 gratuit, cu valabilitate anuală. Actalis SpA , pe actalis.it .
• Comodo , o autoritate de certificare din SUA care emite certificate X.509 gratuit, cu valabilitate anuală. Comodo Group , pe comod.com . Adus la 9 aprilie 2018 (Arhivat din original la 6 aprilie 2018) .
• CACert , pe cacert.org .
• StartSSL , la startssl.com .
• Thawte , pe thawte.com .
• VeriSign , pe verisign.com .

Protocoale care acceptă certificate X.509

• Transport Layer Security (SSL / TLS)
• IPSec
• Extensii securizate de poștă electronică pentru internet (S / MIME)
• Card destept
• SSH
• HTTPS
• LDAPv3
• EAP

Notă

Bibliografie

• Arjen Lenstra , Xiaoyun Wang și Benne de Weger, certificate X.509 în coliziune, 1 martie 2005, arhiva ePrint , [1] .

linkuri externe

• https://web.archive.org/web/20061205051729/http://ietf.org/html.charters/pkix-charter.html
• Certificatul de infrastructură cu cheie publică Internet X.509 și profilul CRL (RFC 5280) ( TXT ), pe ietf.org .
• Recomandarea UIT-X X.509: Tehnologia informației - Interconectare a sistemelor deschise - Director: Cadre de certificate de chei publice și certificate de atribute , su itu.int .
• Ghidul de stil X.509 al lui Peter Gutmann
• http://www.oasis-pki.org/pdfs/Understanding_Path_construction-DS2.pdf

Portal de criptografie

Portal de securitate IT