IPsec - IPsec
Suită de protocol Internet |
---|
Strat de aplicație |
Stratul de transport |
Stratul Internet |
Strat de legătură |
În calcul , Internet Protocol Security ( IPsec ) este o rețea securizată suită de protocoale care autentifică și cifrează la pachetele de date pentru a furniza asigurarea de comunicații criptate între două calculatoare de peste un Internet Protocol de rețea. Este utilizat în rețelele private virtuale (VPN).
IPsec include protocoale pentru stabilirea autentificării reciproce între agenți la începutul unei sesiuni și negocierea cheilor criptografice de utilizat în timpul sesiunii. IPsec poate proteja fluxurile de date între o pereche de gazde ( gazdă-gazdă ), între o pereche de gateway-uri de securitate ( rețea-la-rețea ) sau între un gateway de securitate și o gazdă ( rețea-la-gazdă ). IPsec folosește servicii de securitate criptografice pentru a proteja comunicațiile prin rețelele Internet Protocol (IP). Acceptă autentificarea peer la nivel de rețea, autentificarea originii datelor, integritatea datelor, confidențialitatea datelor (criptare) și protecția împotriva redării.
Suita inițială IPv4 a fost dezvoltată cu puține dispoziții de securitate. Ca parte a îmbunătățirii IPv4, IPsec este un model OSI de nivel 3 sau o schemă de securitate end-to-end de nivel internet . În schimb, în timp ce alte sisteme de securitate pe Internet utilizate pe scară largă funcționează deasupra stratului 3, cum ar fi Transport Layer Security (TLS) care operează deasupra stratului de transport și Secure Shell (SSH) care funcționează la nivelul aplicației, IPsec poate securiza automat aplicațiile la stratul IP.
Istorie
Începând cu începutul anilor 1970, Agenția pentru Proiecte de Cercetare Avansată a sponsorizat o serie de dispozitive experimentale de criptare ARPANET , la început pentru criptarea nativă a pachetelor ARPANET și ulterior pentru criptarea pachetelor TCP / IP; unele dintre acestea au fost certificate și puse pe câmp. În perioada 1986-1991, ANS a sponsorizat dezvoltarea de protocoale de securitate pentru Internet în cadrul programului său de securitate a rețelelor de date (SDNS). Acest lucru a reunit diverși furnizori, inclusiv Motorola, care au produs un dispozitiv de criptare a rețelei în 1988. Lucrarea a fost publicată în mod deschis din 1988 în jurul NIST și, dintre aceștia, Protocolul de securitate la nivelul 3 (SP3) s-ar transforma în cele din urmă în standardul ISO Protocolul de securitate al stratului de rețea. (NLSP).
Din 1992 până în 1995, diferite grupuri au efectuat cercetări privind criptarea stratului IP.
- 1. În 1992, Laboratorul Naval de Cercetare al SUA (NRL) a început proiectul Simple Internet Protocol Plus (SIPP) pentru cercetarea și implementarea criptării IP.
- 2. În 1993, la Columbia University și AT&T Bell Labs , John Ioannidis și alții au cercetat software-ul experimental Software IP Encryption Protocol (swIPe) pe SunOS .
- 3. În 1993, sponsorizat de proiectul serviciului de internet Whitehouse, Wei Xu de la Trusted Information Systems (TIS) a cercetat în continuare Protocoalele de securitate software IP și a dezvoltat suportul hardware pentru triplul DES Data Encryption Standard , care a fost codificat în kernel-ul BSD 4.1 și a acceptat atât arhitecturile x86 cât și SUNOS. Până în decembrie 1994, TIS a lansat produsul Guntlet Firewall open-source sponsorizat de DARPA cu criptare hardware 3DES integrată la viteze peste T1 . A fost pentru prima dată folosind conexiuni VPN IPSec între coasta de est și vest a statelor, cunoscută sub numele de primul produs comercial IPSec VPN.
- 4. Sub LNR lui DARPA -finantat efort de cercetare, LNR a dezvoltat specificațiile IETF standarde de cale ferată (RFC 1825 prin RFC 1827) pentru IPSec, care a fost codificat în kernel - ul BSD 4.4 și sprijinit atât x86 și arhitecturi CPU SPARC. Implementarea IPsec a NRL a fost descrisă în lucrarea lor în cadrul Conferinței USENIX din 1996. Implementarea IPsec open source a NRL a fost pusă la dispoziție online de MIT și a devenit baza pentru majoritatea implementărilor comerciale inițiale.
Internet Engineering Task Force (IETF) au format Grupul de lucru pentru securitate IP în 1992 pentru a standardiza extensiile de securitate specificate în mod deschis la IP, numite IPsec . În 1995, grupul de lucru a organizat câteva dintre atelierele de lucru cu membrii celor cinci companii (TIS, CISCO, FTP, Checkpoint etc.). În timpul atelierelor IPSec, standardele NRL și software-ul Cisco și TIS sunt standardizate ca referințe publice, publicate ca RFC-1825 prin RFC-1827.
Arhitectura de securitate
IPsec este un standard deschis ca parte a suitei IPv4. IPsec folosește următoarele protocoale pentru a îndeplini diferite funcții:
- Autentificarea antetelor (AH) oferă integritatea datelor fără conexiune și autentificarea originii datelor pentru datagramele IP și oferă protecție împotriva atacurilor de redare .
- Încapsularea încărcăturilor utile de securitate (ESP) oferă confidențialitate , integritate a datelor fără conexiune, autentificarea originii datelor , un serviciu anti-reluare (o formă de integritate a secvenței parțiale) și confidențialitate limitată a fluxului de trafic.
- Internet Security Association and Key Management Protocol (ISAKMP) oferă un cadru pentru autentificare și schimb de chei, cu materiale de autentificare autentice furnizate fie prin configurare manuală cu chei pre-partajate , schimb de chei Internet (IKE și IKEv2), negociere kerberizată de chei ( KINK) sau înregistrări DNS IPSECKEY . Scopul este de a genera Asociațiile de Securitate (SA) cu pachetul de algoritmi și parametri necesari pentru operațiunile AH și / sau ESP.
Antet de autentificare
Security Authentication Header ( AH ) a fost dezvoltat la Laboratorul de Cercetări Navale al SUA la începutul anilor 1990 și este derivat parțial din munca anterioară a standardelor IETF pentru autentificarea versiunii 2. Protocolul de gestionare a rețelei simple (SNMP). un membru al suitei de protocol IPsec. AH asigură integritatea fără conexiune utilizând o funcție hash și o cheie partajată secretă în algoritmul AH. AH garantează, de asemenea, originea datelor prin autentificarea pachetelor IP . Opțional, un număr de secvență poate proteja conținutul pachetului IPsec împotriva atacurilor de redare , folosind tehnica ferestrei glisante și aruncând pachetele vechi.
- În IPv4 , AH previne atacurile de inserare a opțiunilor. În IPv6 , AH protejează atât împotriva atacurilor de inserare a antetului, cât și a atacurilor de inserare a opțiunilor.
- În IPv4 , AH protejează sarcina utilă IP și toate câmpurile de antet ale unei datagrame IP, cu excepția câmpurilor modificabile (adică cele care ar putea fi modificate în tranzit), precum și opțiunile IP, cum ar fi opțiunea de securitate IP (RFC 1108). Câmpurile antet IPv4 modificabile (și, prin urmare, neautentificate) sunt DSCP / ToS , ECN , Flags, Fragment Offset , TTL și Header Checksum .
- În IPv6 , AH protejează majoritatea antetului de bază IPv6, AH în sine, anteturile de extensie nemutabile după AH și sarcina utilă IP. Protecția pentru antetul IPv6 exclude câmpurile modificabile: DSCP , ECN , Flow Label și Hop Limit.
AH funcționează direct pe IP, utilizând numărul de protocol IP 51 .
Următoarea diagramă de pachete AH arată cum este construit și interpretat un pachet AH:
Compensări | Octetul 16 | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Octetul 16 | Bit 10 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
0 | 0 | Următorul antet | Încărcare utilă Len | Rezervat | |||||||||||||||||||||||||||||
4 | 32 | Indexul parametrilor de securitate (SPI) | |||||||||||||||||||||||||||||||
8 | 64 | Număr de secvență | |||||||||||||||||||||||||||||||
C | 96 |
Valoarea verificării integrității (ICV) ... |
|||||||||||||||||||||||||||||||
... | ... |
- Următorul antet (8 biți)
- Tipul următorului antet, indicând ce protocol de strat superior a fost protejat. Valoarea este preluată din lista numerelor de protocol IP .
- Încărcare utilă Len (8 biți)
- Lungimea acestui antet de autentificare în unități de 4 octeți, minus 2. De exemplu, o valoare AH de 4 este egală cu 3 × (câmpuri AH cu lungime fixă pe 32 de biți) + 3 × (câmpuri ICV pe 32 de biți) - 2 și astfel o valoare AH de 4 înseamnă 24 de octeți. Deși dimensiunea este măsurată în unități de 4 octeți, lungimea acestui antet trebuie să fie un multiplu de 8 octeți dacă este transportată într-un pachet IPv6. Această restricție nu se aplică unui antet de autentificare transportat într-un pachet IPv4.
- Rezervat (16 biți)
- Rezervat pentru utilizare viitoare (toate zero-urile până atunci).
- Indexul parametrilor de securitate (32 biți)
- Valoare arbitrară care este utilizată (împreună cu adresa IP de destinație) pentru a identifica asocierea de securitate a părții destinatare.
- Număr secvență (32 biți)
- Un număr de secvență monoton strict crescător (incrementat cu 1 pentru fiecare pachet trimis) pentru a preveni atacurile de reluare . Când este activată detectarea reluării, numerele de secvență nu sunt niciodată reutilizate, deoarece o nouă asociere de securitate trebuie renegociată înainte de a încerca să incrementeze numărul de secvență peste valoarea sa maximă.
- Valoare de verificare a integrității (multiplu de 32 de biți)
- Valoare de verificare a lungimii variabile. Poate conține umplutură pentru a alinia câmpul la o limită de 8 octeți pentru IPv6 sau o limită de 4 octeți pentru IPv4 .
Incapsularea sarcinii utile de securitate
IP Encapsulating Security Payload (ESP) a fost dezvoltat la Laboratorul de Cercetări Navale începând din 1992 ca parte a unui proiect de cercetare sponsorizat de DARPA și a fost publicat în mod deschis de IETF SIPP Working Group elaborat în decembrie 1993 ca o extensie de securitate pentru SIPP. Acest ESP a fost inițial derivat din protocolul SP3D al Departamentului Apărării al SUA , mai degrabă decât derivat din Protocolul de securitate ISO Network-Layer (NLSP). Specificația protocolului SP3D a fost publicată de NIST la sfârșitul anilor 1980, dar proiectată de proiectul Secure Data Network System al Departamentului Apărării din SUA. Encapsulating Security Payload (ESP) este un membru al suitei de protocol IPsec. Acesta oferă origine autenticitate prin sursa de autentificare , integritatea datelor prin intermediul funcțiilor hash și confidențialitate prin criptare de protecție pentru IP pachete . ESP acceptă, de asemenea, criptarea - numai și autentificarea - numai configurațiile, dar utilizarea criptării fără autentificare este puternic descurajată, deoarece este nesigură.
Spre deosebire de Authentication Header (AH) , ESP în modul de transport nu oferă integritate și autentificare pentru întregul pachet IP . Cu toate acestea, în modul Tunel , unde întregul pachet IP original este încapsulat cu un nou antet de pachet adăugat, protecția ESP este acordată întregului pachet IP interior (inclusiv antetul interior) în timp ce antetul exterior (inclusiv orice opțiuni externe IPv4 sau extensie IPv6 anteturi) rămâne neprotejat. ESP funcționează direct pe IP, utilizând protocolul IP numărul 50.
Următoarea diagramă de pachete ESP arată cum este construit și interpretat un pachet ESP:
Compensări | Octetul 16 | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Octetul 16 | Bit 10 | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
0 | 0 | Indexul parametrilor de securitate (SPI) | |||||||||||||||||||||||||||||||
4 | 32 | Număr de secvență | |||||||||||||||||||||||||||||||
8 | 64 | Date privind sarcina utilă | |||||||||||||||||||||||||||||||
... | ... | ||||||||||||||||||||||||||||||||
... | ... | ||||||||||||||||||||||||||||||||
... | ... | Căptușeală (0-255 octeți) | |||||||||||||||||||||||||||||||
... | ... | Lungimea tamponului | Următorul antet | ||||||||||||||||||||||||||||||
... | ... |
Valoarea verificării integrității (ICV) ... |
|||||||||||||||||||||||||||||||
... | ... |
- Indexul parametrilor de securitate (32 biți)
- Valoare arbitrară utilizată (împreună cu adresa IP de destinație) pentru a identifica asocierea de securitate a părții destinatare.
- Număr secvență (32 biți)
- Un număr de secvență în creștere monotonă (incrementat cu 1 pentru fiecare pachet trimis) pentru a proteja împotriva atacurilor de reluare . Există un ghișeu separat pentru fiecare asociație de securitate.
- Date privind sarcina utilă (variabilă)
- Conținutul protejat al pachetului IP original, inclusiv orice date utilizate pentru a proteja conținutul (de exemplu, un vector de inițializare pentru algoritmul criptografic). Tipul de conținut protejat este indicat de câmpul Next Header .
- Căptușeală (0-255 octeți)
- Căptușire pentru criptare, pentru a extinde datele privind sarcina utilă la o dimensiune care se potrivește cu dimensiunea blocului de cifrare al criptării și pentru a alinia câmpul următor.
- Lungime pad (8 biți)
- Dimensiunea căptușelii (în octeți).
- Următorul antet (8 biți)
- Tipul următorului antet. Valoarea este preluată din lista numerelor de protocol IP .
- Valoare de verificare a integrității (multiplu de 32 de biți)
- Valoare de verificare a lungimii variabile. Poate conține umplutură pentru a alinia câmpul la o limită de 8 octeți pentru IPv6 sau o limită de 4 octeți pentru IPv4 .
Asociația de securitate
Protocoalele IPsec utilizează o asociere de securitate , în care părțile comunicante stabilesc atribute de securitate partajate, cum ar fi algoritmi și chei. Ca atare, IPsec oferă o gamă largă de opțiuni odată ce s-a stabilit dacă se utilizează AH sau ESP. Înainte de a face schimb de date, cele două gazde sunt de acord asupra algoritmului utilizat pentru a cripta pachetul IP, de exemplu DES sau IDEA și care funcție hash este utilizată pentru a asigura integritatea datelor, cum ar fi MD5 sau SHA . Acești parametri sunt conveniți pentru sesiunea respectivă, pentru care trebuie să fie convenită o viață și o cheie de sesiune .
Algoritmul pentru autentificare este de asemenea convenit înainte ca transferul de date să aibă loc și IPsec acceptă o serie de metode. Autentificarea este posibilă prin cheia pre-partajată , unde o cheie simetrică este deja în posesia ambelor gazde, iar gazdele își trimit reciproc hashuri ale cheii partajate pentru a dovedi că dețin aceeași cheie. IPsec acceptă, de asemenea , criptarea cheii publice , unde fiecare gazdă are o cheie publică și una privată, își schimbă cheile publice și fiecare gazdă îi trimite celuilalt o nonce criptată cu cheia publică a celeilalte gazde. Alternativ, dacă ambele gazde dețin un certificat de cheie publică de la o autoritate de certificare , acesta poate fi utilizat pentru autentificarea IPsec.
Asociațiile de securitate ale IPsec sunt stabilite utilizând Internet Security Association și Key Management Protocol (ISAKMP). ISAKMP este implementat prin configurare manuală cu secrete pre-partajate, schimb de chei Internet (IKE și IKEv2), negociere kerberizată a cheilor (KINK) și utilizarea înregistrărilor DNS IPSECKEY . RFC 5386 definește Better-Than-Nothing Security (BTNS) ca un mod neautentificat de IPsec folosind un protocol IKE extins. C. Meadows, C. Cremers și alții au folosit metode formale pentru a identifica diferite anomalii care există în IKEv1 și, de asemenea, în IKEv2.
Pentru a decide ce protecție trebuie asigurată pentru un pachet de ieșire, IPsec folosește Security Parameter Index (SPI), un index al bazei de date de asociere de securitate (SADB), împreună cu adresa de destinație într-un antet de pachet, care împreună identifică în mod unic o asociație de securitate pentru acel pachet. O procedură similară este efectuată pentru un pachet de intrare, în care IPsec adună cheile de decriptare și verificare din baza de date a asociației de securitate.
Pentru IP multicast, este furnizată o asociație de securitate pentru grup și este duplicată la toți receptorii autorizați ai grupului. Poate exista mai multe asociații de securitate pentru un grup, utilizând SPI diferite, permițând astfel mai multe niveluri și seturi de securitate în cadrul unui grup. Într-adevăr, fiecare expeditor poate avea mai multe asociații de securitate, permițând autentificarea, deoarece un receptor poate ști doar că cineva care știe cheile a trimis datele. Rețineți că standardul relevant nu descrie modul în care asociația este aleasă și duplicată în cadrul grupului; se presupune că o parte responsabilă va fi făcut alegerea.
Moduri de funcționare
Protocoalele IPsec AH și ESP pot fi implementate într-un mod de transport gazdă-gazdă, precum și într-un mod de tunelare a rețelei.
Mod de transport
În modul de transport, doar sarcina utilă a pachetului IP este de obicei criptată sau autentificată. Rutarea este intactă, deoarece antetul IP nu este nici modificat, nici criptat; cu toate acestea, atunci când se folosește antetul de autentificare , adresele IP nu pot fi modificate prin traducerea adresei de rețea , deoarece aceasta invalidează întotdeauna valoarea hash . Cele de transport și de aplicare straturile sunt întotdeauna asigurate printr - un hash, astfel încât acestea nu pot fi modificate în nici un fel, de exemplu , prin traducerea în portul numerelor.
Un mijloc de încapsulare a mesajelor IPsec pentru traversarea NAT a fost definit de documentele RFC care descriu mecanismul NAT-T .
Mod tunel
În modul tunel, întregul pachet IP este criptat și autentificat. Apoi este încapsulat într-un nou pachet IP cu un nou antet IP. Modul tunel este utilizat pentru a crea rețele private virtuale pentru comunicații de la rețea la rețea (de exemplu, între routere pentru a lega site-uri), comunicații gazdă la rețea (de exemplu, acces la distanță de utilizator) și comunicații gazdă la gazdă (de exemplu, chat privat).
Modul tunel acceptă traversarea NAT.
Algoritmi
Algoritmi de criptare simetrică
Algoritmii criptografici definiți pentru utilizare cu IPsec includ:
- HMAC - SHA1 / SHA2 pentru protecția integrității și autenticitate.
- TripleDES - CBC pentru confidențialitate
- AES- CBC și AES-CTR pentru confidențialitate.
- AES- GCM și ChaCha20 - Poly1305 oferă confidențialitate și autentificare împreună eficient.
Consultați RFC 8221 pentru detalii.
Algoritmi de schimb de chei
- Diffie – Hellman (RFC 3526)
- ECDH (RFC 4753)
Algoritmi de autentificare
Implementări
IPsec poate fi implementat în stiva IP a unui sistem de operare , care necesită modificarea codului sursă. Această metodă de implementare se face pentru gazde și gateway-uri de securitate. Diverse stive IP compatibile IPsec sunt disponibile de la companii, cum ar fi HP sau IBM. O alternativă este așa-numita implementare bump-in-the-stack (BITS), unde codul sursă al sistemului de operare nu trebuie modificat. Aici IPsec este instalat între stiva IP și driverele de rețea . Astfel, sistemele de operare pot fi adaptate cu IPsec. Această metodă de implementare este utilizată și pentru gazde și gateway-uri. Cu toate acestea, atunci când se adaptează IPsec, încapsularea pachetelor IP poate cauza probleme pentru descoperirea automată MTU , unde este stabilită dimensiunea maximă a unității de transmisie (MTU) pe calea rețelei între două gazde IP. Dacă o gazdă sau o poartă de acces are un criptoprocesor separat , care este comun în armată și poate fi găsit și în sistemele comerciale, este posibilă așa-numita implementare IPsec bump-in-the-wire (BITW).
Când IPsec este implementat în kernel , gestionarea cheilor și negocierea ISAKMP / IKE se efectuează din spațiul utilizatorului. „PF_KEY Key Management API, versiunea 2” dezvoltat și specificat în mod deschis de NRL este adesea utilizat pentru a permite aplicației de gestionare a cheilor de spațiu de aplicație să actualizeze Asociațiile de securitate IPsec stocate în implementarea IPsec de kernel-spațiu. Implementările IPsec existente includ de obicei ESP, AH și IKE versiunea 2. Implementările IPsec existente pe sistemele de operare similare UNIX, de exemplu, Solaris sau Linux, includ de obicei PF_KEY versiunea 2.
IPsec încorporat poate fi utilizat pentru a asigura comunicația sigură între aplicațiile care rulează pe sisteme de resurse constrânse, cu o cheltuială redusă.
Statutul standardelor
IPsec a fost dezvoltat împreună cu IPv6 și inițial trebuia să fie susținut de toate implementările IPv6 conforme cu standardele înainte ca RFC 6434 să o facă doar o recomandare. IPsec este, de asemenea, opțional pentru implementările IPv4 . IPsec este cel mai frecvent utilizat pentru securizarea traficului IPv4.
Protocoalele IPsec au fost inițial definite în RFC 1825 prin RFC 1829, care au fost publicate în 1995. În 1998, aceste documente au fost înlocuite de RFC 2401 și RFC 2412 cu câteva detalii inginerești incompatibile, deși erau identice din punct de vedere conceptual. În plus, a fost definit un protocol de autentificare reciprocă și schimb de chei Internet Key Exchange (IKE) pentru a crea și gestiona asociații de securitate. În decembrie 2005, noile standarde au fost definite în RFC 4301 și RFC 4309, care sunt în mare parte un superset al edițiilor anterioare, cu o a doua versiune a standardului de schimb de chei Internet IKEv2 . Aceste documente din a treia generație au standardizat abrevierea IPsec la majuscule „IP” și minuscule „sec”. „ESP” se referă în general la RFC 4303, care este cea mai recentă versiune a specificației.
De la mijlocul anului 2008, un grup de lucru IPsec Maintenance and Extensions (ipsecme) este activ la IETF.
Presupusă interferență NSA
În 2013, ca parte a scurgerilor Snowden , s-a dezvăluit că Agenția Națională de Securitate a SUA a lucrat activ la „Inserarea vulnerabilităților în sistemele comerciale de criptare, sistemele IT, rețelele și dispozitivele de comunicații finale utilizate de ținte” ca parte a programului Bullrun . Există acuzații că IPsec a fost un sistem de criptare vizat.
Stiva OpenBSD IPsec a venit mai târziu și a fost copiată pe scară largă. Într-o scrisoare pe care dezvoltatorul principal OpenBSD Theo de Raadt a primit-o pe 11 decembrie 2010 de la Gregory Perry, se pretinde că Jason Wright și alții, care lucrează pentru FBI, au introdus „o serie de uși din spate și mecanisme de scurgere a cheilor canalului lateral ” în cripta OpenBSD cod. În e-mailul trimis din 2010, Theo de Raadt nu și-a exprimat la început o poziție oficială cu privire la validitatea revendicărilor, în afară de aprobarea implicită de la transmiterea e-mailului. Răspunsul lui Jason Wright la acuzații: „Fiecare legendă urbană este făcută mai reală prin includerea de nume, date și ore reale. E-mailul lui Gregory Perry se încadrează în această categorie.… Voi afirma clar că nu am adăugat ușile din spate la sistemul de operare OpenBSD sau sistemul de criptare OpenBSD (OCF). " Câteva zile mai târziu, de Raadt a comentat că „cred că NETSEC a fost probabil contractat să scrie ușile din spate așa cum se presupune.… Dacă acestea ar fi scrise, nu cred că au intrat în arborele nostru”. Acest lucru a fost publicat înainte de scurgerile Snowden.
O explicație alternativă prezentată de autorii atacului Logjam sugerează că NSA a compromis VPN-urile IPsec prin subminarea algoritmului Diffie-Hellman utilizat în schimbul de chei. În lucrarea lor, ei pretind că NSA a construit special un cluster de calcul pentru precomputarea subgrupurilor multiplicative pentru primele și generatoarele specifice, cum ar fi pentru al doilea grup Oakley definit în RFC 2409. Începând cu mai 2015, 90% din VPN-urile IPsec adresabile au sprijinit al doilea grup Oakley ca parte a IKE. Dacă o organizație ar pre-calcula acest grup, ar putea obține cheile schimbate și decripta traficul fără a introduce niciun software din spate.
O a doua explicație alternativă care a fost prezentată a fost că Equation Group a folosit exploatări de zi zero împotriva echipamentelor VPN ale mai multor producători, care au fost validate de Kaspersky Lab ca fiind legate de Equation Group și validate de acei producători ca fiind exploit-uri reale, dintre care unele au fost exploatări de zi zero în momentul expunerii lor. De Cisco PIX si ASA firewall au vulnerabilități care au fost utilizate pentru interceptarea convorbirilor telefonice de către ANS.
Mai mult, VPN-urile IPsec care utilizează setările „Mod agresiv” trimit un hash al PSK în clar. Acest lucru poate fi și se pare că este vizat de NSA folosind atacuri de dicționar offline.
Documentația IETF
Urmărirea standardelor
- RFC 1829 : Transformarea ESP DES-CBC
- RFC 2403 : Utilizarea HMAC-MD5-96 în ESP și AH
- RFC 2404 : Utilizarea HMAC-SHA-1-96 în ESP și AH
- RFC 2405 : Algoritmul de cifrare ESP DES-CBC cu IV explicit
- RFC 2410 : Algoritmul de criptare NULL și utilizarea sa cu IPsec
- RFC 2451 : Algoritmii de cifrare ESP CBC-Mode
- RFC 2857 : Utilizarea HMAC-RIPEMD-160-96 în ESP și AH
- RFC 3526 : Grupuri Diffie-Hellman mai modulare exponențiale (MODP) pentru schimbul de chei Internet (IKE)
- RFC 3602 : Algoritmul de cifrare AES-CBC și utilizarea sa cu IPsec
- RFC 3686 : Utilizarea modului de contorizare Advanced Encryption Standard (AES) cu IPsec Encapsulating Security Payload (ESP)
- RFC 3947 : Negocierea NAT-Traversal în IKE
- RFC 3948 : UDP încapsularea pachetelor ESP IPsec
- RFC 4106 : Utilizarea modului Galois / Counter (GCM) în IPsec Encapsulating Security Payload (ESP)
- RFC 4301 : Arhitectura de securitate pentru protocolul Internet
- RFC 4302 : Antet de autentificare IP
- RFC 4303 : Sarcină utilă de securitate de încapsulare IP
- RFC 4304 : Addendum Număr de secvență extinsă (ESN) Addendum la IPsec Domain of Interpretation (DOI) pentru Internet Security Association și Key Management Protocol (ISAKMP)
- RFC 4307 : Algoritmi criptografici pentru utilizare în Internet Key Exchange Version 2 ( IKEv2 )
- RFC 4308 : suite criptografice pentru IPsec
- RFC 4309 : Utilizarea modului CCM Advanced Encryption Standard (AES) cu IPsec Encapsulating Security Payload (ESP)
- RFC 4543 : Utilizarea codului de autentificare a mesajului Galois (GMAC) în IPsec ESP și AH
- RFC 4555 : IKEv2 Mobility and Multihoming Protocol (MOBIKE)
- RFC 4806 : Extensii ale protocolului de stare a certificatului online (OCSP) la IKEv2
- RFC 4868 : Utilizarea HMAC-SHA-256, HMAC-SHA-384 și HMAC-SHA-512 cu IPsec
- RFC 4945 : Profilul PKI de securitate IP pe Internet al IKEv1 / ISAKMP, IKEv2 și PKIX
- RFC 5280 : Certificat de infrastructură cu cheie publică Internet X.509 și profil de listă de revocare a certificatului (CRL)
- RFC 5282 : Utilizarea algoritmilor de criptare autentificată cu sarcina utilă criptată a protocolului de schimb de chei Internet versiunea 2 (IKEv2)
- RFC 5386 : Securitate mai bună decât nimic: un mod neautentificat de IPsec
- RFC 5529 : Moduri de funcționare pentru Camellia pentru utilizare cu IPsec
- RFC 5685 : Mecanism de redirecționare pentru protocolul de schimb de chei Internet versiunea 2 (IKEv2)
- RFC 5723 : Internet Key Exchange Protocol Versiunea 2 (IKEv2) Sesiune reluare
- RFC 5857 : Extensii IKEv2 pentru a sprijini compresia robustă a antetului pe IPsec
- RFC 5858 : Extensii IPsec pentru a sprijini compresia robustă a antetului peste IPsec
- RFC 7296 : Internet Key Exchange Protocol Versiunea 2 (IKEv2)
- RFC 7321 : Cerințe de implementare a algoritmului criptografic și ghid de utilizare pentru încapsularea sarcinii utile de securitate (ESP) și antetul de autentificare (AH)
- RFC 7383 : Internet Key Exchange Protocol Versiunea 2 (IKEv2) Fragmentarea mesajului
- RFC 7427 : Autentificare semnătură în schimbul de chei Internet versiunea 2 (IKEv2)
- RFC 7634 : ChaCha20, Poly1305 și utilizarea lor în Internet Key Exchange Protocol (IKE) și IPsec
RFC experimentale
- RFC 4478 : Protocol de autentificare repetată în Internet Key Exchange (IKEv2)
RFC-uri informaționale
- RFC 2367 : Interfață PF_KEY
- RFC 2412 : Protocolul de determinare a cheii OAKLEY
- RFC 3706 : O metodă bazată pe trafic de detectare a interlocutorilor morti de chei de internet (IKE)
- RFC 3715 : Cerințe de compatibilitate IPsec-Network Address Translation (NAT)
- RFC 4621 : Proiectarea protocolului IKEv2 Mobility and Multihoming (MOBIKE)
- RFC 4809 : Cerințe pentru un profil de management al certificatului IPsec
- RFC 5387 : Declarație de problemă și aplicabilitate pentru securitate mai bună decât nimic (BTNS)
- RFC 5856 : Integrarea compresiei robuste a antetului peste asociațiile de securitate IPsec
- RFC 5930 : Utilizarea Advanced Encryption Standard Counter Mode (AES-CTR) cu protocolul Internet Key Exchange version 02 (IKEv2)
- RFC 6027 : Declarație de problemă cluster IPsec
- RFC 6071 : Foaia de parcurs a documentelor IPsec și IKE
- RFC 6379 : Suite Criptografice Suite B pentru IPsec
- RFC 6380 : Profilul Suite B pentru Internet Protocol Security (IPsec)
- RFC 6467 : Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)
Cele mai bune practici actuale RFC
- RFC 5406 : Liniile directoare pentru specificarea utilizării versiunii 2 a IPsec
RFC-uri învechite / istorice
- RFC 1825 : Arhitectura de securitate pentru protocolul Internet (depășită de RFC 2401)
- RFC 1826 : antet de autentificare IP (depășit de RFC 2402)
- RFC 1827 : IP Encapsulating Security Payload (ESP) (învechit de RFC 2406)
- RFC 1828 : autentificare IP folosind MD5 cu cheie (istoric)
- RFC 2401 : Arhitectura de securitate pentru protocolul Internet (prezentare generală IPsec) (învechită de RFC 4301)
- RFC 2406 : IP Encapsulating Security Payload (ESP) (învechit de RFC 4303 și RFC 4305)
- RFC 2407 : Domeniul de interpretare al securității IP Internet pentru ISAKMP (învechit de RFC 4306)
- RFC 2409 : Schimbul de chei Internet (depășit de RFC 4306)
- RFC 4305 : Cerințe de implementare a algoritmului criptografic pentru încapsularea sarcinii utile de securitate (ESP) și antetul de autentificare (AH) (depășit de RFC 4835)
- RFC 4306 : Protocol de schimb de chei Internet (IKEv2) (învechit de RFC 5996)
- RFC 4718 : IKEv2 Clarificări și ghiduri de implementare (învechit de RFC 7296)
- RFC 4835 : Cerințe de implementare a algoritmului criptografic pentru încapsularea sarcinii utile de securitate (ESP) și antetul de autentificare (AH) (învechit de RFC 7321)
- RFC 5996 : Internet Key Exchange Protocol Version 2 (IKEv2) (învechit de RFC 7296)
Vezi si
- Rețea privată virtuală multipunctă dinamică
- Securitatea informațiilor
- Traversarea NAT
- Criptare oportunistă
- tcpcrypt
Referințe
linkuri externe
- Computer Security la Curlie
-
Toate grupurile de lucru de securitate active IETF
- IETF ipsecme WG ( Grupul de lucru „Întreținerea și extensiile securității IP”)
- IETF btns WG (Grupul de lucru „Securitate mai bună decât nimic”) (autorizat pentru a lucra pe IPsec neautentificat, API-uri IPsec, blocarea conexiunii)]
- Securizarea datelor în tranzit cu articolul IPsec WindowsSecurity.com de Deb Shinder
-
IPsec pe Microsoft TechNet
- Instrumentul de diagnosticare Microsoft IPsec din Centrul de descărcare Microsoft
- Un ghid ilustrat pentru IPsec de Steve Friedl
- Arhitectura de securitate pentru IP (IPsec) Conferințe de comunicare a datelor de Manfred Lindner Partea IPsec
- Crearea VPN-urilor cu articol IPsec și SSL / TLS Linux Journal de Rami Rosen