Správa klíčů na síťové úrovni

Bezpečná komunikace v Internetu bez zatěžování uživatelů, nezní to hezky? Pro zajištění transparentních přenosů...


Bezpečná komunikace v Internetu bez zatěžování uživatelů, nezní to hezky? Pro
zajištění transparentních přenosů je nejlepší síťová úroveň, tj. v rámci
směrovačů, firewallů atd. Nejsou pak potřebné zásahy do aplikací jako např.
někdy u protokolu SSL. RFC1825 až 1829 popisují potřebný protokol protokol
IPsec. Bylo vytvořeno více než dvacet realizací protokolu IPsec, je ještě
nějaký problém? Je, a velký v oblasti vhodného algoritmu pro správu klíčů.
Problém není v tom, že by žádný potřebný protokol nebyl po ruce. Je, dokonce
dva a oba kvalitní. Oba krátkodobého charakteru, oba vhodné pro virtuální
privátní sítě, oba založené na stejném algoritmu. Ale také oba principiálně
odlišné. První z nich SKIP (Simple Key-Management Protocol) je protokol na bázi
protokolu IP a je určený pro jednotlivé stanice. Druhý ISAKMP (Internet
Security Association and Key Management Protocol) tvoří multiprotokolový rámec.
Byl sice navržen ve dvojici s protokolem Oakley, který mu zajišťuje vytvoření
klíčů pro relaci, ale v budoucnu je schopen spolupracovat s libovolným
protokolem tohoto typu. SKIP je hotový a je už od roku 1994 patentován. ISAKMP
je navržen v osmé verzi, která není, zdá se, poslední. SKIP byl navržen lidmi z
firmy Sun, za dvojicí ISAKMP/Oakley stojí firma Cisco. Aby nebyla situace tak
jednoduchá, hlásí se se svým standardem S/WAN skupina výrobců bezpečnostních
produktů (nechybí mezi nimi ani TIS, CheckPoint, RSA DSI). V oblasti šifry
preferují algoritmus RC5, ale v oblasti správy klíčů jasno nemají, nejblíže
však mají k algoritmu SKIP.
Protokol IPsec
Pro zapouzdřování datových bloků z hlediska bezpečnosti jsou definována dvě
specifická záhlaví, použitelná jak pro stávající verzi 4, tak pro novou verzi 6
Internet Protokolu (IP):
Authentication Header (AH) viz RFC-1826, rámec, který slouží pro zajištění
autenticity a integrity. U IPv6 je dokonce toto záhlaví pro hostující počítače
povinné. Implicitní autentizační algoritmus je MD5 se 128bitovým klíčem (viz
RFC-1321). Záhlaví AH je odvozeno z pokusů o vytvoření 2. verze protokolu pro
řízení sítí SNMP (Simple Network Management Protocol). Příjemce paketu
vybaveného AH záhlavím má možnost si verifikovat, zda přijatý paket je tentýž,
který byl odeslán a také relevantnost zdrojové adresy. Použití záhlaví AH te-dy
výrazně redukuje riziko vzniklé z možnosti útoku s využitím ukradené adresy
resp. z použití modifikovaného paketu.
n Encapsulating Security Payload (ESP) viz RFC-1827, zapouzdření, které navíc
slouží pro zajištění důvěryhodnosti dat (případně i k tomu, aby se zabránilo
popření odeslání, resp. příjmu dat). Šifruje se zde pomocí DES-CBC, protože
tento způsob již byl použit v návrhu SNMPv2; diskutuje se také možnost použití
algoritmů 3DES, IDEA a RSA. Problémem je, že použití všech uvedených algoritmů
zatím podléhá exportním omezením. Zapouzdřit lze buď datagramy IP protokolu
včetně záhlaví (tunelový model), nebo transportní protokolové datové jednotky
(transportní model) viz RFC-1827. Za ukrývání záhlaví datagramu u tunelového
modelu se platí navýšením síťové zátěže.
Záhlaví AH a ESP mohou být použita samostatně i společně. Aplikace používající
tato záhlaví jsou zatím ve stadiu prototypů.
K popisu vztahů mezi síťovými entitami z hlediska síťových služeb slouží tzv.
Security Associations (SA). Jde o množinu bezpečnostních vlastností relace mezi
dvěma nebo
více systémy komunikujícími prostřednictvím protokolu IP. SA jsou jednocestné a
jednotně identifikovatelné a to pomocí indexu bezpečnostních parametrů SPI
(Security Parameter Index) a IP adresy. SPI závisí na své doméně interpretace
DOI (Domain of Interpretation), která jednotně definuje formát zpráv, typ
výměny klíčů a jmenné konvence. Jeden výpočetní systém přitom může podporovat
více domén DOI.
Parametry SA jsou trojího druhu:
lspeciální pro AH tj. autentizační algoritmus klíče,
lspeciální pro ESP tj. šifrovací algoritmus, délka klíče, použitá
kryptografická synchronizace, inicializační vektor,
lspolečné pro AH i ESP tj. životnost klíčů, úroveň bezpečnosti, podpora
certifikátů (orientace na uživatele nebo hosty).
SKIP
Dnes je ve světě již osm výrobců, kteří testují interoperabilitu svých SKIP
produktů. Kromě firmy Sun jsou to Novell, OpenROUTE, IRE, VPNet, Toshiba, Swiss
Federal Institute of Technology, izraelský CheckPoint a ruský Elvis+ (ruský
Sun+ ?!).
SKIP má následující vlastnosti:
používá AH a ESP zapouzdření,
pro šifrování podporuje DES, 3DES a SAFER,
pro hašování podporuje MD2, MD5 a SHA,
pro autentizaci podporuje MD5,
pro distribuci klíčů podporuje algoritmus Diffie-Hellmana,
pro D-H výpočty je použita výkonná knihovna velkých čísel,
pro veřejné klíče jsou použity certifikáty dle X.509,
je zde podpora vícenásobných certifikátů,
pro certifikáty jsou použity DSA podpisy; certifikáty jsou hašovány tzv. otisk
certifikátu,
je zde uživatelsky přívětivá manipulace se seznamy přístupových práv (ACL
Access Control List),
pro generování velkých prvočísel je použit speciální program,
je zde podpora mobilních uživatelů (s notebooky).
Zvláště poslední vlastnost je dost významná např. firma VPNet dodává klientský
software pro Windows 95 a umožňuje připojit notebooky do virtuálních privátních
sítí (VPN) vytvářených jejich kryptografickými jednotkami VSU-1000. Rovněž Sun
má svou verzi SKIPu pro PC, umožňující se připojit k jejich kryptozařízením
SunScreen SPF-100G. Obr. 1 ukazuje komponenty systému SKIP.
Obecně jsou 4 možnosti, jak bezpečně komunikovat z notebooku: zabezpečit
komunikaci s firewallem, zabezpečit komunikaci až k serveru, zabezpečit jednu
komunikaci notebook-firewall a druhou firewall-server a nakonec zabezpečit
autentizovanou komunikaci k firewallu a šifrovanou k serveru.
Šifrování resp. autentizace komunikace mezi entitami i a j jsou zabezpečeny
velmi efektivním způsobem: paket je zašifrován (autentizován) náhodně
generovaným klíčem Kp a ten klíčem Kij viz obr. 2.
Protože klíč Kij může být v cache paměti, je zřejmé, že šifrování minimálně
zdržuje přenos. Aktualizace může být bez zdržení prováděna třeba pro každý
paket zvlášť. Vždy se vypočte každý další klíč Kijn ze vztahu Kijn = h(Kij,n),
kde n je hodnota čítače a h haš funkce. Přitom 25 bitů hodnoty n lze
dekrementovat každou sekundu a tak stačí hodnoty klíče Kij měnit jedenkrát za
rok (n na nule).
Při rozesílání se používá skupinový klíč GIK (Group Interchange Key) viz obr. 3
který je přidělován podle seznamu ACL.
Proveďme si bezpečnostní analýzu SKIPu:
Útok "Man-In-The-Middle": Tomu je zabráněno autentizací veřejných klíčů.
Útok se znalostí krátkodobého klíče: Z Kp nelze vyvodit Kijn. Znalost více
klíčů Kp je ekvivalentní s útoky se znalostí dvojic původního textu a
šifrovaného textu na Kijn.
Útok přehráním: Brání mu dostatečně častá změna klíče Kij.
Útok odmítnutím služby: Může probíhat podle dvojího scénáře:
b) záplavou požadavků na certifikaci zde jsou postačující obranou tzv. sušenky
(cookies),
c) zahlcení systému výpočetně náročnými operacemi (D-H výpočty); řešením je
předem si vypočítat Kij i pro počítače, s nimiž se komunikace teprve očekává. V
případě návalu nových požadavků pak lze výpočet nových Kij klidně zastavit.
Pro propagaci SKIPu Sun umístil na http://skip.incog. com/ volně dostupný
zdrojový i binární kód SKIPu pro FreeBSD a SunOS s exportovatelnou délkou klíče
512 bitů. Pro komunikaci na území USA lze používat klíče o délce 2 048 bitů.
ISAKMP a Oakley
ISAKMP je rámec pro správu klíčů v Internetu, tj. protokolová podpora pro
jednání mezi dvěma síťovými stanicemi o bezpečnostních atributech. Není v něm
úmyslně zahrnuta žádná konkrétní kryptografická metoda, protože tyto se
vyvíjejí a mění a snaha byla oddělit to, co je stabilní, od toho proměnlivého.
Z hlediska síťové architektury je ISAKMP umístěn na aplikační úrovni viz obr. 4.
Formát datových polí protokolu ISAKMP je definován v souladu s připravovaným
protokolem IPv6. Za záhlavím (HDR) jsou pružně podle potřeby zřetězeny další
bloky protokolu, obsahující údaje o SA (SA payload), o klíčích (KE payload), o
náhodných číslech (N payload), o identifikátorech vzájemné komunikace (IDji
payload iniciátora j-té relace, IDjv payload volaného v rámci j-té relace) a o
způsobu vzájemné autentizace (AUTH payload). Proces navázání spojení v základní
variantě je zobrazen na obr. 5.
Proveďme si opět stručnou bezpečnostní analýzu protokolu:
Útok "Man-In-The-Middle": Tomu je zabráněno autentizací veřejných klíčů obdobně
jako u SKIPu.
Útok krádeží spojení: Zabraňuje se mu spojením autentizace, výměny klíčů a
výměny SA.
Útok odmítnutím služby: Je prakticky znemožněn použitím techniky tokenů.
Protokol Oakley se vyznačuje dvěma zvláštnostmi
lje zde varianta s použitím pouze "slabé" verze autentizace se sušenkami,
lautentizaci není Diffie-Hellmanův, nýbrž RSA.
Obdobný protokol na bázi algoritmu Diffie-Hellmana navrhla i jiná skupina IETF
Network Working Group a to v roce 1995; protokol se jmenuje Photuris. A tak
vládne jistý zmatek, protože jsou k dispozici návrhy pro Photuris, ISAKMP,
Oakley a ISAKMP+Oakley a tyto nejsou vzájemně konzistentní. Uživatelé Internetu
z USA a Kanady si mohou z Webu firmy Cisco Systems stáhnout démona ISAKMPv6,
který používá protokol ISAKMP +Oakley verze 2.
Seriál je rovněž k dispozici na www.idg.cz/computerworld/bvsk/
8 0585 / ram









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.