Internetová výměna klíčů - Internet Key Exchange

v výpočetní, Internetová výměna klíčů (IKE, někdy IKEv1 nebo IKEv2, v závislosti na verzi) je protokol používaný k nastavení a bezpečnostní asociace (SA) v IPsec sada protokolů. IKE staví na Protokol Oakley a ISAKMP.[1] IKE používá X.509 certifikáty pro autentizaci - buď předem sdílené, nebo distribuované pomocí DNS (nejlépe s DNSSEC ) - a a Výměna klíčů Diffie – Hellman založit a sdílené tajemství relace z nichž kryptografické klíče jsou odvozeny.[2][3] Kromě toho musí být ručně udržována bezpečnostní politika pro každého partnera, který se připojí.[2]

Dějiny

The Pracovní skupina pro internetové inženýrství (IETF) původně definovala IKE v listopadu 1998 v řadě publikací (Žádost o připomínky ) známý jako RFC 2407, RFC 2408 a RFC 2409:

  • RFC 2407 definovala pro ISAKMP internetovou zabezpečovací IP doménu.[4]
  • RFC 2408 definoval asociaci zabezpečení internetu a protokol správy klíčů (ISAKMP). [5]
  • RFC 2409 definoval Internet Key Exchange (IKE). [6]

RFC 4306 aktualizován IKE na verzi dva (IKEv2) v prosinci 2005.[7] RFC 4718 vyjasnil některé otevřené podrobnosti v říjnu 2006.[8] RFC 5996 spojil tyto dva dokumenty plus další vysvětlení do aktualizovaného IKEv2,[9] publikováno v září 2010. Pozdější aktualizace upgradovala dokument z Navrhovaného standardu na Internetový standard, publikováno jako RFC 7296 v říjnu 2014.

Mateřská organizace IETF, Internetová společnost (ISOC), udržuje autorská práva k těmto standardům jako volně dostupná pro internetovou komunitu.

Architektura

Většina implementací protokolu IPsec se skládá z IKE démon který běží dovnitř uživatelský prostor a zásobník IPsec v jádro který zpracovává skutečné IP balíčky.

Démoni uživatelského prostoru mají podle potřeby snadný přístup k velkokapacitnímu úložišti obsahujícímu konfigurační informace, jako jsou adresy koncových bodů IPsec, klíče a certifikáty. Na druhé straně moduly jádra mohou zpracovávat pakety efektivně as minimální režií - což je důležité z důvodů výkonu.

Protokol IKE používá UDP pakety, obvykle na portu 500, a obecně k vytvoření souboru vyžaduje 4–6 paketů se 2–3 zpátečními lety SA (bezpečnostní sdružení) na obou stranách. Vyjednaný klíčový materiál se poté předá zásobníku IPsec. Může to být například AES klíč, informace identifikující koncové body IP a porty, které mají být chráněny, a také to, jaký typ tunelu IPsec byl vytvořen. Zásobník IPsec zase zachycuje příslušné pakety IP, pokud je to vhodné, a podle potřeby provádí šifrování / dešifrování. Implementace se liší v tom, jak se provádí zachycování paketů - například někteří používají virtuální zařízení, jiní vybírají část z brány firewall atd.

IKEv1 se skládá ze dvou fází: fáze 1 a fáze 2.[10]

Fáze IKEv1

Účelem fáze IKE je vytvořit zabezpečený ověřený komunikační kanál pomocí Výměna klíčů Diffie – Hellman algoritmus pro generování sdíleného tajného klíče k šifrování další komunikace IKE. Výsledkem tohoto jednání je jeden obousměrný ISAKMP Asociace pro bezpečnost (SA).[11] Ověřování lze provést pomocí kteréhokoli z nich předsdílený klíč (sdílené tajemství), podpisy nebo šifrování veřejného klíče.[12] Fáze 1 pracuje buď v hlavním režimu, nebo v agresivním režimu. Hlavní režim chrání identitu vrstevníků a hash sdíleného klíče jejich šifrováním; Agresivní režim není.[10]

Během druhé fáze IKE používají kolegové IKE zabezpečený kanál zavedený ve fázi 1 k vyjednávání bezpečnostních asociací jménem jiných služeb, jako je IPsec. Výsledkem vyjednávání jsou minimálně dvě jednosměrná přidružení zabezpečení (jedno příchozí a jedno odchozí).[13] Fáze 2 pracuje pouze v rychlém režimu.[10]

Problémy s IKE

IKE měla původně řadu možností konfigurace, ale postrádala obecnou možnost automatického vyjednávání známého výchozího případu, který je univerzálně implementován. Obě strany IKE se tedy musely přesně shodnout na typu bezpečnostní asociace chtěli vytvořit - možnost po možnosti - nebo nebylo možné navázat spojení. Další komplikace vyvstaly ze skutečnosti, že v mnoha implementacích byl výstup ladění obtížně interpretovatelný, pokud vůbec existovalo nějaké zařízení k vytvoření diagnostického výstupu.

Specifikace IKE byly otevřeny značné míře interpretace, hraničící s chybami designu (Detekce mrtvých vrstevníků je příkladem[Citace je zapotřebí ]), což vedlo k tomu, že různé implementace IKE nejsou schopny vůbec vytvořit dohodnuté přidružení zabezpečení pro mnoho kombinací možností, ať už jsou správně nakonfigurované, mohou se objevit na obou koncích.

Vylepšení s IKEv2

Protokol IKEv2 byl popsán v příloze A dokumentu RFC 4306 v roce 2005. Byly řešeny tyto problémy:

  • Méně Žádost o komentáře (RFC): Specifikace pro IKE byly pokryty alespoň ve třech RFC, více, pokud se bere v úvahu NAT traversal a další rozšíření, která se běžně používají. IKEv2 je kombinuje v jednom RFC stejně jako vylepšení podpory pro NAT traversal (Překlad síťových adres (NAT)) a firewall průchod obecně.
  • Podpora standardní mobility: Pro IKEv2 existuje standardní rozšíření s názvem [rfc: 4555 Mobility and Multihoming Protocol] (MOBIKE) (viz také IPsec ) používané na podporu mobility a multihoming pro ni a Zapouzdření bezpečnostního užitečného zatížení (ESP). Použitím tohoto rozšíření IKEv2 a IPsec mohou používat mobilní uživatelé a uživatelé s více domovy.
  • NAT traversal: Zapouzdření IKE a ESP v Protokol uživatele Datagram (Port UDP 4500) umožňuje těmto protokolům procházet výkonem zařízení nebo brány firewall NAT.[14]
  • Stream Control Protocol přenosu (SCTP) podpora: IKEv2 umožňuje SCTP protokol používaný v internetovém telefonním protokolu, Voice over IP (VoIP).
  • Jednoduchá výměna zpráv: IKEv2 má jeden mechanismus počáteční výměny čtyř zpráv, kde IKE poskytla osm výrazně odlišných mechanismů počáteční výměny, z nichž každý měl malé výhody a nevýhody.
  • Méně kryptografických mechanismů: IKEv2 používá kryptografické mechanismy k ochraně svých paketů, které jsou velmi podobné tomu, co IPsec ESP používá k ochraně paketů IPsec. To vedlo k jednodušší implementaci a certifikaci pro Společná kritéria a FIPS 140-2 (Federální standard pro zpracování informací (FIPS), které vyžadují samostatnou validaci každé kryptografické implementace.
  • Spolehlivost a správa stavu: IKEv2 používá pořadová čísla a potvrzení k zajištění spolehlivosti a vyžaduje určitou logistiku zpracování chyb a sdílenou správu stavu. IKE by mohla skončit v mrtvém stavu kvůli nedostatku takových opatření spolehlivosti, kde obě strany očekávaly, že druhá strana zahájí akci - což se nikdy nestalo. Práce kolem (jako např Detekce mrtvých vrstevníků ) byly vyvinuty, ale nebyly standardizovány. To znamenalo, že různé implementace řešení nebyly vždy kompatibilní.
  • Odmítnutí služby Odolnost proti útoku (DoS): IKEv2 neprovádí příliš mnoho zpracování, dokud nezjistí, zda žadatel skutečně existuje. To se zabývalo některými problémy DoS, které IKE utrpělo a které by provádělo hodně nákladného kryptografického zpracování vymyšlený umístění.
Předpokládám HostA má Index bezpečnostních parametrů (SPI) ze dne A a HostB má SPI z B, scénář by vypadal takto:
HostA ------------------------------------------------- - HostB | HDR (A, 0), sai1, kei, Ni --------------------------> | | <---------------------------- HDR (A, 0), N (cookie) | | HDR (A, 0), N (cookie), sai1, kei, Ni ----------------> | | <-------------------------- HDR (A, B), SAr1, ker, Nr |
Li HostB (respondér) zažívá velké množství napůl otevřených připojení IKE, odešle nezašifrovanou zprávu s odpovědí IKE_SA_INIT na HostA (iniciátor) s upozorňovací zprávou typu COOKIE, a bude očekávat HostA poslat IKE_SA_INIT požádat s touto hodnotou cookie v upozorněném nákladu na HostB. Tím je zajištěno, že iniciátor je skutečně schopen zpracovat odpověď IKE od respondenta.

Rozšíření protokolu

Pracovní skupina IETF ipsecme standardizovala řadu rozšíření, přičemž goalof modernizoval protokol IKEv2 a lépe jej přizpůsobil vysokému objemu produkčního prostředí. Mezi tato rozšíření patří:

  • Obnovení relace IKE: schopnost obnovit neúspěšnou „relaci“ IKE / IPsec po selhání, aniž byste museli projít celým procesem nastavení IKE (RFC 5723 ).
  • Přesměrování IKE: přesměrování příchozích požadavků IKE, což umožňuje jednoduché vyvažování zátěže mezi více koncovými body IKE (RFC 5685 ).
  • Viditelnost provozu IPsec: speciální značení paketů ESP, které jsou ověřené, ale ne šifrované, s cílem usnadnit prostřední schránky (například systémy detekce narušení ) analyzovat tok (RFC 5840 ).
  • Vzájemné ověřování EAP: podpora pro EAP - pouze (tj. bez certifikátu) autentizace obou vrstevníků IKE; cílem je umožnit moderní ověřování na základě hesla metody, které mají být použity (RFC 5998 ).
  • Rychlá detekce selhání: minimalizace času, než peer IKE zjistí, že jeho protějšek havaroval (RFC 6290 ).
  • Rozšíření s vysokou dostupností: zlepšení synchronizace protokolu na úrovni IKE / IPsec mezi shlukem koncových bodů IPsec a rovnocenným serverem, aby se snížila pravděpodobnost výpadku připojení po události převzetí služeb při selhání (RFC 6311 ).

Implementace

IKE je podporována jako součást IPsec implementace v Windows 2000, Windows XP, Windows Server 2003, Windows Vista a Windows Server 2008.[15] Implementaci ISAKMP / IKE vyvinuli společně společnosti Cisco a Microsoft.[16]

Microsoft Windows 7 a Windows Server 2008 R2 částečně podporuje IKEv2 (RFC 7296 ) a také MOBIKE (RFC 4555 ) skrz Připojení VPN funkce (také známá jako Agilní VPN).

Existuje několik implementací protokolu IPsec s přidruženými schopnostmi IKE. Na Linux, Libreswan, Openswan a strongSwan implementace poskytují démona IKE, který může konfigurovat (tj. vytvářet SA) na zásobníky IPsec založené na jádře KLIPS nebo XFRM / NETKEY. XFRM / NETKEY je Linux nativní implementace protokolu IPsec k dispozici od verze 2.6.

The Distribuce softwaru Berkeley také mají implementaci IPsec a démona IKE, a co je nejdůležitější kryptografický rámec (Kryptografický rámec OpenBSD, OCF), což činí podporu kryptografické akcelerátory mnohem jednodušší. OCF byl nedávno přenesen na Linux.

Značný počet prodejců síťových zařízení vytvořil své vlastní démony IKE (a implementace IPsec) nebo si licencoval jeden od druhého.

Existuje celá řada implementací IKEv2 a některé společnosti zabývající se certifikací IPsec a testováním interoperability začínají pořádat workshopy pro testování i aktualizované certifikační požadavky pro testování IKEv2. Laboratoře ICSA uspořádala v březnu 2007 svůj poslední workshop IKEv2 Interoperability Workshop v Orlandu na Floridě s 13 prodejci z celého světa.

V současné době jsou k dispozici následující implementace IKEv2 s otevřeným zdrojovým kódem:

Zranitelnosti

Unikly NSA prezentace vydané Der Spiegel označují, že IKE je využíván neznámým způsobem k dešifrování IPSec provozu, jak je ISAKMP.[17] Vědci, kteří objevili Logjam útok uveďte, že lámání 1024 bitů Skupina Diffie – Hellman rozbije 66% serverů VPN, 18% nejvýznamnějších milionů domén HTTPS a 26% serverů SSH, což podle vědců odpovídá únikům.[18] Toto tvrzení vyvrátil Eyal Ronen i Adi Shamir ve svém příspěvku „Kritický přehled nedokonalého budoucího tajemství“ [19] a Paul Wouters z Libreswan v článku „66% VPN není ve skutečnosti porušeno“ [20]

Konfigurace IPSec VPN, které umožňují vyjednávání více konfigurací, podléhají MITM -na základě downgrade útoky mezi nabízenými konfiguracemi, s IKEv1 i IKEv2.[21] Tomu lze zabránit pečlivou segregací klientských systémů na více přístupových bodů služby s přísnějšími konfiguracemi.

Obě verze standardu IKE jsou náchylné k útoku offline slovníku, když se použije heslo s nízkou entropií. U IKEv1 to platí pro hlavní režim a agresivní režim.[22][23][24]

Viz také

Reference

  1. ^ The Internet Key Exchange (IKE), RFC 2409, §1 Abstrakt
  2. ^ A b RFC 3129: Požadavky na Kerberized Internet Negotiation of Keys, Pracovní skupina pro internetové inženýrství, Červen 2001, s. 1
  3. ^ RFC 4322: Oportunistické šifrování pomocí Internet Key Exchange (IKE), Pracovní skupina pro internetové inženýrství, Červen 2001, s. 5
  4. ^ „RFC 2407 Interpretační doména IP zabezpečení Internetu pro ISAKMP“. Pracovní skupina pro internetové inženýrství (IETF).
  5. ^ „RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP)“. Pracovní skupina pro internetové inženýrství (IETF).
  6. ^ D. Harkins. „RFC 2409 The Internet Key Exchange (IKE)“. Pracovní skupina pro internetové inženýrství (IETF).
  7. ^ C. Kaufman (Microsoft) (prosinec 2005). „Protokol RFC 4306 Internet Key Exchange (IKEv2)“. Pracovní skupina pro internetové inženýrství (IETF).
  8. ^ Eronen, P .; Hoffman, P. (říjen 2006). „RFC 4718 IKEv2 Clarifications and Implementation Guidelines“. Pracovní skupina pro internetové inženýrství (IETF).
  9. ^ Kaufman, C .; Hoffman, P .; Nir, Y .; Eronen, P. (září 2010). „Protokol RFC 5996 Internet Key Exchange (IKEv2)“. Pracovní skupina pro internetové inženýrství (IETF).
  10. ^ A b C "RFC 2409 The Internet Key Exchange (IKE) “, Internet Engineering Task Force (IETF), s. 5
  11. ^ "RFC 2409 The Internet Key Exchange (IKE) ", Internet Engineering Task Force (IETF), s. 6
  12. ^ "RFC 2409 The Internet Key Exchange (IKE) ", Internet Engineering Task Force (IETF), s. 10-16
  13. ^ "RFC 4306 Protokol Internet Key Exchange (IKEv2) “, Internet Engineering Task Force (IETF), s. 11,33
  14. ^ "RFC 4306: Internet Key Exchange (IKEv2) Protocol “, Internet Engineering Task Force (IETF), s. 38-40
  15. ^ Internet Key Exchange: Zabezpečení internetového protokolu (IPsec): Technet
  16. ^ Používání protokolu IPSec ve Windows 2000 a XP, část 1
  17. ^ Fielded Capability: Kompletní recenze designu VPN SPIN9 (PDF), NSA prostřednictvím „Der Spiegel“, s. 5
  18. ^ Adrian, David; Bhargavan, Karthikeyan; Durumeric, Zakir; Gaudry, Pierrick; Zelená, Matthew; Halderman, J. Alex; Heninger, Nadia; Springall, Drew; Thomé, Emmanuel; Valenta, Luke; VanderSloot, Benjamin; Wustrow, Eric; Zanella-Béguelin, Santiago; Zimmermann, Paul (říjen 2015). Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice (PDF). 22. konference ACM o počítačové a komunikační bezpečnosti (CCS ’15). Denver. Citováno 15. června 2016.
  19. ^ Ronen, Eyal; Shamir, Adi (říjen 2015). „Kritická revize nedokonalého budoucího tajemství“ (PDF). Citovat deník vyžaduje | deník = (Pomoc)
  20. ^ Wouters, Paul (říjen 2015). „66% VPN není ve skutečnosti přerušeno“.
  21. ^ Bhargavan, Karthikeyan; Brzuska, Christina; Fournet, Cédric; Kohlweiss, Markulf; Zanella-Béguelin, Santiago; Green, Matthew (leden 2016). „Downgrade Resilience in Key-Exchange Protocols“ (PDF).
  22. ^ Pliam, John (2. října 1999). „Zranitelnosti ověřování v IKE a Xauth se slabými předem sdílenými tajemstvími“. Univerzita Johna Hopkinse. Archivováno z původního dne 10. června 2002. Citováno 5. února 2020.
  23. ^ McGrew, David (5. července 2011). „Skvělá šifra, ale kde jsi vzal ten klíč“. Blog společnosti Cisco. Archivovány od originál dne 9. července 2011. Citováno 11. února 2020.
  24. ^ Felsch, Dennis (srpen 2018). „Nebezpečí opětovného použití klíčů: praktické útoky na IPsec IKE“. 27. bezpečnostní sympozium USENIX. Citováno 11. února 2020.

externí odkazy