De mii de ani, oamenii au folosit diverse metode pentru a ascunde informațiile transmise, precum și pentru a verifica expeditorul și mesajul. Odată cu dezvoltarea civilizației, a fost creată o singură metodă și este acum folosită pe scară largă pentru a îndeplini toate aceste trei sarcini. protocol
S / MIME este un sistem de trimitere a e-mailului securizat utilizând criptarea și semnăturile digitale.
Tehnologia de criptare curent (de închidere) sunt împărțite în două tipuri principale: algoritmi cu cheie simetrică (secretă), cum ar fi DES sau criptare AES și algoritmi asimetrice (deschis / închis) chei, cum ar fi RSA sau ECC. Instrumentele moderne de verificare a expeditorului sunt funcții matematice unice, numite coduri hash care creează semnături unice. Două metode de hashing utilizate sunt algoritmii MD5 și SHA. Calculatoarele le pot folosi pentru a crea un hash unic sau număr corespunzător unui text sursă individuală (texte sursă identice, au o valoare de cod hash). Aceste instrumente simple sunt utilizate și combinate pentru a crea o infrastructură de chei publice (PKI).
Identitate verificată
Identitatea în cadrul sistemului PKI sunt gestionate prin utilizarea certificatelor digitale, care nu sunt foarte diferite de cărți de identitate emise de stat, pe care majoritatea oamenilor sunt transportate peste granițele internaționale - pașapoarte. standard de pașapoarte în lumea certificatelor digitale - este formatul X.509, care este utilizat pe scară largă pentru tehnologiile de semnare și criptare, cum ar fi S / MIME, IPsec, SSH, precum și de securitate a rețelei fără fir, rețele private virtuale (VPN) și chiar și un mesaj de securitate server (cum ar fi site-urile Web SSL).
Certificatele sunt construite pe baza criptografiei asimetrice și a codurilor hash. Pentru a crea un certificat, solicitantul (cel care are nevoie de o cheie semnată de o autoritate de certificare mai mare) creează o cheie privată. Cheia este ținută blocată, astfel încât autenticitatea ei nu este pusă la îndoială. Împreună cu cheia secretă, se creează cheia publică corespunzătoare. După cum sugerează și numele său, partea deschisă a perechii nu este secretă și distribuită în mod liber, deși încă într-un mod care să-i garanteze autenticitatea.
Această pereche de taste permite două operații de bază. În primul rând, oricine poate folosi o cheie publică pentru a cripta orice lucru pe care numai cheia privată îl poate decripta; În al doilea rând, cheia publică poate fi utilizată pentru a decripta cheia secretă criptată. Acest lucru este important atunci când verificați o semnătură pe care o singură cheie privată o poate crea.
Cererea către autoritatea de certificare include detalii cum ar fi persoana sau computerul pentru care este destinată cheia, tipul și fiabilitatea algoritmului, precum și partea deschisă a perechii de chei. Autoritatea de certificare (CA) primește și verifică informațiile din cerere și apoi, folosind un algoritm de hash, creează un identificator unic care corespunde informațiilor.
Folosind cheia sa privată, CA criptează informațiile hash și asamblează-l într-un format standard (cum ar fi X.509), crearea unui certificat corespunzător cererii inițiale. Certificatul X.509 va conține o listă de aplicații, inclusiv identitatea certificatului (subiectul), o perioadă de valabilitate, o cheie publică și operațiunile pentru care pot fi utilizate certificatul. După aceasta, certificatul este returnat solicitantului; Acest marker, care în esență, spune: „Eu, autoritatea de certificare (CA), garantezi pentru această cheie publică și o parte secretă, care corespunde cu el, pentru toate metodele descrise aici folosesc.“
Autoritățile de certificare a autorităților de origine (situate la cel mai înalt nivel al lanțului de încredere) se auto-semnează. Cele mai multe centre acceptabile de certificare a rădăcinilor sunt livrate încorporate în sistemul de operare sau în aplicația de bază, dar pot fi actualizate sau modificate prin pachete sau personalizare corporativă. Între autoritatea de certificare a rădăcinilor și nodul final al copacului (care descrie de obicei o singură persoană sau sistem), pot exista una sau mai multe autorități de certificare a rădăcinilor.
Lanțul constă din toate nodurile și toate certificatele anterioare încorporate în acestea, semnate de autoritatea de certificare la acest nivel. O terță parte care încearcă să verifice un certificat poate verifica codul hash calculat la nivel local cu decriptata din certificatul propriu-zis, utilizând cheia comună de însoțire pentru respectiva autoritate sau persoană de certificare. Astfel, un lanț complet testat este creat din rădăcină până la nodul final al copacului - presupunând, desigur, că rădăcina se bucură de încredere.
Actualizați starea certificatului
Fiecare autoritate de certificare are modalități de a distribui o listă de certificate care nu ar mai trebui să aibă încredere. Această listă de revocare a certificatelor (CRL) descrie care CA-uri emise au fost invalidează direct. În mod convenabil, locația listei de revocare a certificatelor este de obicei o proprietate a autorității de certificare a CA.
Multe aplicații petrec mult mai mult timp descărcând certificatul dacă nu pot verifica lantul sau lista de revocare a certificatelor pentru fiecare nod din lanț. În funcție de ceea ce certificatul protejează, utilizatorul poate sau nu poate să aibă încredere în el. Un punct de distribuție actualizat în mod regulat, disponibil pe scară largă pentru listele de revocare a certificatelor, este absolut necesar pentru fiecare autoritate de certificare și în special pentru rădăcinile disponibile publicului.
Rădăcinile sunt baza lanțului de certificate, iar legătura în lanț se bazează pe toate ierarhiile certificatelor. Cele mai multe sisteme și aplicații client presupun că certificatul pentru nodul final al arborelui este valabil numai dacă este urmărit înapoi la rădăcina de încredere. Aceasta poate fi o companie CA care este deținută și administrată de respectiva companie sau de o autoritate publică de certificare a rădăcinilor (cum ar fi VeriSign).
În cele din urmă, fiecare sistem criptografic bun include conceptul de management al ciclului de viață. Mai repede decât calculatoarele, algoritmii mai puțin stabili. Orice sistem criptos bun are nevoie de abilitatea de a se actualiza și de a trece la noi algoritmi și dimensiuni cheie în timp. Autoritățile de certificare ar trebui să fie actualizate în mod corespunzător, atunci când sunt determinate instabilitățile criptografice și anumite funcții sunt puse în funcțiune sau ieșite din ele.
Implementarea S / MIME
Vom presupune că există deja o infrastructură necesară care să permită operațiunile pe care le vom descrie. În cazul nostru, utilizăm un server de certificare corporativ la nivel de întreprindere integrat cu Active Directory.
Obținerea de certificate
Prima sarcină este obținerea certificatelor corespunzătoare. Pentru a face acest lucru, deschideți consolă MMC Manager certificat (certmgr.msc), faceți clic dreapta pe dosarul Personal, selectați Toate sarcinile din lista de tip pop-up și selectați Solicitare nouă, din listă.
Ca urmare, începe expertul de instalare a certificatului, după cum se arată în Fig. 1. În mod implicit, vor fi afișate mai multe opțiuni specifice companiei, iar certificatul de utilizator este important de la ele. Ulterior, aceasta va fi utilizată pentru a face posibile procesele de semnare și criptare. Certificatul trebuie să fie adecvat pentru următoarele aspecte.
Fig. 1 Solicitarea unui certificat
- Semnături digitale (crearea de mesaje cu o ștampilă de autenticitate de la creatorul lor)
- Protecția criptografică a cheii (protecția unei chei de o alta pentru tehnologii cum ar fi sistemul de fișiere de criptare)
- Secure schimb de e-mail (mesaje criptate care pot fi citite doar de către destinatarul destinat care deține cheia secretă corespunzătoare)
Pentru a trimite un e-mail S / MIME semnat, nu este necesară proprietatea de protejare a cheii criptografice. Dar pentru a trimite sau a primi poștă criptată această proprietate este necesară, în timp ce proprietatea semnăturii nu este. Implicit, șabloanele din Serviciul de certificare Windows® includ aceste trei proprietăți. Dacă utilizatorul nu are permisiunea să solicite certificate noi, acestea nu vor fi afișate la pornirea asistentului. În cazul în care întreprinderea CA nu este disponibilă, utilizatorul va primi o "eroare de instalare" indicând faptul că este imposibil să contactați domeniul sau autoritatea de certificare. În sensul acestui ghid, presupunem că un certificat permite atât protecția semnăturii, cât și protecția criptografică.
Certificatele de schimb
Cel mai simplu mod de a începe schimbul de mesaje de e-mail criptate între doi utilizatori este de a trimite fiecare alte mesaje semnate. După compunerea mesajului, utilizatorul face clic pe butonul "Semnare". (Uneori, butonul este ascuns în mod implicit la Outlook, până când acesta a fost utilizat cel puțin o dată. Aceasta poate fi găsită selectând „Opțiuni pentru mesaje noi“, apoi pe „Setări de securitate“ și pentru a selecta „adăuga semnătura digitală la acest mesaj“ în fereastra de proprietăți siguranță. buton) semnarea (un plic galben mic, cu o panglică roșie pe el, care spune „Sign“) adaugă o semnătură digitală la mesajul pentru a determina autenticitatea sursei sale.
Fig. 2 Atunci când schimbați certificatele, nu exportați cheia secretă
Fiecare destinatar creează manual o înregistrare de contact în Outlook și adaugă certificatul la înregistrarea expeditorului. După ce doi utilizatori au făcut schimb de certificate, vor avea posibilitatea de a schimba reciproc mesajele criptate de e-mail.
Remediați problemele
Uneori destinatarul are dificultăți în deschiderea unui mesaj criptat. Cele mai probabile surse de probleme aici sunt autorități de certificare a rădăcinilor nesigure, centre de certificare intermediare care nu pot fi verificate și liste de revocare a certificatelor indisponibile.
O autoritate de certificare rădăcină fără încredere apare de obicei în Outlook ca mesaj de eroare legat de semnătura: "Există dificultăți legate de semnătură. Pentru mai multe informații, faceți clic pe butonul Semnătură. " Pentru a rezolva această problemă, deschideți certificatul din cadrul Outlook și faceți clic pe butonul "Despre autoritatea de certificare". "Din dialogul pop-up. Uitați-vă la mesajul din fila General sau în fereastra de proprietăți a certificatelor. Dacă indică faptul că certificatul rădăcină al CA nu este de încredere și trebuie să fie instalat, accesați fila informații. Faceți clic pe butonul "Copiază în fișier". "Și urmați instrucțiunile expertului, acceptând toate setările implicite și furnizând numele și dosarul fișierului la cerere.
A doua problemă a menționat mai sus, neverificarea CAs intermediare, de obicei, are loc în două situații: atunci când clientul încearcă să verifice certificatul, nu pot avea acces la informațiile de localizare a autorității certificatului (AIA), specificate în certificat, sau clientul are o versiune a certificatului de centru intermediar certificare, care nu coincide cu ceea ce produce autoritatea de certificare (clientul se situează adesea în spatele versiunii sau a două). Aceste condiții par foarte asemănătoare în interfața de utilizare Outlook. Am văzut acest lucru doar în circumstanțe speciale, în cazul în care valabilitatea certificatului de CA intermediar în lanțul expirat, iar certificatul este eliberat din nou, înainte de a expira emis certificatele CA subordonate.
De fapt, această problemă apare atunci când există lacune în lanț. Este posibil ca unele certificate-mamă să nu fie prea detaliate sau integrate în nodul final al arborelui, ceea ce complică și mai mult situația.
Fig. 3 Completarea decalajelor din lanțul certificat
După primirea lanțului certificat exportat, destinatarul va trebui să deschidă și să importe lanțul în același mod în care am importat anterior rădăcina. Singura diferență este că directorul de stocare selectat trebuie să fie "Centrele de certificare intermediare". Dacă mesajul este deschis și certificatul este afișat ca valabil în Outlook, atunci totul funcționează corect.
În ceea ce privește a treia problemă, indisponibilitatea listei de revocare a certificatelor, remedierea este relativ simplă. Răspunsul inițial din Outlook va arăta foarte asemănător cu problema anterioară. Cu toate acestea, eroarea va fi afișată chiar dacă centrele de certificare de semnare rădăcină sau intermediară sunt de încredere. Pentru fiecare nivel al lanțului de certificate deasupra destinației, deschideți proprietățile certificatului, apoi fila de informații și căutați câmpul numit "CRL".
Diseminarea certificatelor
Răspândirea este o parte simplă. De fapt, mesajul semnat este transferat la serverul de e-mail, pe care apoi îl trimite la o locație la alta modalitate dovedită - prin SMTP. Singura problemă pe care o am văzut în transmiterea semnat sau e-mail criptat este faptul că unele sisteme de e-mail a respinge sau rupe semnate sau criptate mesaje care trec prin ele. Metoda de corecție constă în lucrul cu capul sistemului IT pentru a obține tipuri valide de mesaje. Desigur, poate fi necesar să acceptați faptul că anumite tipuri de mesaje sunt blocate. Destinatarul poate avea motive întemeiate să nu permită mesaje criptate într-un anumit mediu de lucru.
Criptați răspunsurile.
Pentru a crea un răspuns criptat (presupunând că procesul de bootstrap de mai sus a fost deja finalizată), expeditorul trebuie să creeze doar un mesaj și apoi faceți clic pe „Encrypt“ (un plic galben mic cu blocare albastră pe el, care spune „Cripta“) în fereastra compune mesaje. Dacă acest buton nu este disponibil, urmați pașii pentru trimiterea unui mesaj semnat, cu excepția ultimului, în loc de care verifica „conținutul mesajului criptați și atașamentele“.
S / MIME semnătura nu este necesară pentru a trimite destinatarului unui mesaj criptat, dar ambele funcționează bine împreună, deoarece semnătura permite cititorului să verifice serverul (funcția de criptare nu certifică expeditorul). Procesul de criptare va încerca să cripteze mesajul utilizând cheile publice cunoscute ale tuturor destinatarilor. Dacă sistemul nu poate găsi certificate pentru anumiți destinatari potențiali, acestea vor fi marcate într-un dialog de tip pop-up care sugerează trimiterea mesajului necriptat, așa cum se arată în Fig. 4.
Fig. 4 Dacă aveți o problemă cu certificatul, puteți decide să trimiteți un mesaj necriptat
În mod implicit, semnarea și criptarea ar trebui să funcționeze cu alte sisteme client configurate comparabile, dar, uneori, schimb de mesaje semnate sau criptate între versiuni multiple poate duce la probleme în cazul în care hashingul sau algoritmul de criptare nu este acceptat la nivelul anterior. Ne confruntăm cu o astfel de problemă la trimiterea unui e-mail semnat (folosind SHA-512 ca algoritmul hash) utilizatorul folosind Windows XP Service Pack 2. Deoarece sistemul de recepție nu a sprijinit hash, utilizatorul nu este în măsură să verifice semnătura sau de a citi mesajul. Cu toate acestea, dacă setările prestabilite pentru Outlook nu s-au schimbat, este puțin probabil ca utilizatorii să întâlnească multe probleme în acest moment.
După primirea mesajului, destinatarul destinat trebuie să fie în măsură să îl deschidă dacă este disponibilă o cheie publică asociată cu certificatul public. În plus, utilizatorul poate fi obligat să furnizeze un jeton suplimentar care confirmă deținerea cheii private, în funcție de modul în care a fost implementată. Alți utilizatori care au efectuat o astfel de procedură de inițializare pot lua parte la o astfel de corespondență semnată și criptată cu destinatarul. În cazul în care utilizatorul a schimbat cheia secretă (de exemplu, din cauza pierderii calculatorului), este necesar să re-solicite certificate și re-distribuie fișierul mesaj sau certificat semnat printre cei cu care dorește să facă schimb de mesaje criptate.
Concluzia.
Efectuarea lucrării S / MIME semnată și criptată între doi utilizatori din două directoare sau organizații diferite nu este, de obicei, mult mai dificilă decât efectuarea celor de mai sus. Semnătura este foarte convenabilă atunci când este utilizată corect, deoarece certifică autenticitatea mesajului. Mesajele criptate oferă un nivel suplimentar de confidențialitate atunci când trimiteți date pentru mesaje confidențiale. Împreună, ele oferă atât confirmarea autenticității expeditorului, cât și păstrarea secretului datelor. Și procesul descris aici permite celor mai mulți utilizatori să profite cu ușurință de aceste oportunități.