Článek s podobnou tématikou vyšel na Lupě před dvěma týdny.
Cílem SEND je zabezpečit všechny operace spadající pod objevování sousedů, a to pokud možno s co nejmenšími nároky na zúčastněné stroje. Celkem očekávatelně využívá asymetrickou kryptografii a digitální podpisy, kdy jednotlivé zprávy jsou podepsány tajným soukromým klíčem, zatímco volně šířený veřejný klíč slouží k jejich ověření. I zde se objevuje notorický problém těchto systémů – jak získat veřejný klíč, aby se mu dalo důvěřovat. SEND nabízí dva odlišné recepty, používané pro různé prvky objevování sousedů.
Kryptograficky generované adresy – CGA
Zkratka CGA v této souvislosti neoznačuje dřevní grafický adaptér, ale Cryptographically Generated Address. Ve stručnosti znamená, že adresa rozhraní se odvodí z veřejného klíče dotyčného počítače.
Její výroba není zrovna jednoduchá, detailní popis najdete v RFC 3972. Ve stručnosti říká, že se veřejný klíč spojí s několika dalšími položkami, hodnota se zpracuje hashovací funkcí a část výsledku se použije jako identifikátor rozhraní. Celý proces lze navíc komplikovat omezujícími parametry, aby se ukradení adresy ještě ztížilo.
Cílem CGA je zabránit falšování ohlášení sousedů, kdy se zloduch vydává za jiný stroj a odpovídá na výzvu „sháním linkovou adresu k IP adrese XYZ“ místo něj. Při použití CGA a SEND je cílová adresa stroje odvozena z veřejného klíče. K ohlášení souseda obsahujícímu poptávanou linkovou adresu se připojí datová struktura s veřejným klíčem a dalšími položkami, která umožňuje snadno ověřit, že adresa stroje je skutečně odvozena z veřejného klíče. Zároveň je ohlášení digitálně podepsáno soukromým klíčem.
Pokud by někdo chtěl takové ohlášení padělat, musel by k existující CGA (za niž se chce vydávat) vytvořit dvojici veřejného a soukromého klíče tak, aby veřejný klíč odpovídal cílové adrese. Vzhledem k asymetrii a výpočetní náročnosti použitých algoritmů je takový úkol prakticky neřešitelný.
Hlavní předností CGA je, že k jejich ověření nejsou třeba vůbec žádné informace navíc. Vše potřebné obsahuje vlastní zpráva objevování sousedů (doplněná o volby CGA a RSA podpis).
Druhou stranou mince je, že SEND nedokáže ochránit libovolné adresy, ale jen adresy vytvořené podle principu CGA. Zapomeňte na ochranu adres vytvořených podle EUI-64, což je základní podoba identifikátorů rozhraní pro IPv6. Také ochrana soukromí s náhodně generovanými adresami podle RFC 4941 musí na ochranu SEND zapomenout. Ovšem soukromí se vzdávat netřeba. Do výpočtu CGA vstupuje i náhodná hodnota a dvojic klíčů si může počítač vytvořit několik. Jeden stroj může tedy používat několik CGA, které nejsou žádným viditelným způsobem svázány.
Certifikáty pro směrovače
SEND s CGA sice ověří spojení adresy s veřejným klíčem, nedokáže však zabránit nekorektnímu ohlašování směrovačů. Kdokoli si může vytvořit korektní CGA a následně se prohlásit za pupek světa a podstrčit okolním strojům nesmyslné prefixy adres, to vše s platným podpisem.
SEND tento problém řeší certifikací směrovačů. Lokální autorita udělí směrovači certifikát. Ten může být buď obecný „stroj X je směrovač“ (a může proto ohlašovat libovolné prefixy) nebo jej může zplnomocnit jen k ohlašování zcela konkrétních prefixů „stroj X je směrovač a smí ohlašovat prefixy Y a Z“.
K ověření certifikátu potřebuje dotyčný stroj veřejný klíč dané autority, což je dost nepříjemný požadavek. SEND připouští budování certifikačních cest, kdy jedna autorita ověří jinou, ta další a další, až se postupně dostaneme k certifikátu zkoumaného směrovače. Jedním veřejným klíčem (například autority provozované poskytovatelem Internetu) lze tedy potenciálně ověřit směrovače ve velké části Internetu, nicméně nutnost držení výchozího klíče představuje významnou komplikaci při snaze o nasazení tohoto mechanismu. Jeho distribuci si lze představit v uzavřeném prostředí (firma, Pentagon,…), ale jen těžko v prostředí otevřeném (konference, autobus,…).
Jelikož jsou certifikáty poměrně velké, může jich být několik a mají dlouhodobější platnost, nejsou součástí každého oznámení. SEND pro ně definuje dva nové typy zpráv, jimiž kterýkoli stroj může požádat o certifikační cestu a přijmout odpověď. Získané certifikáty si uloží a používá k posuzování přicházejících ohlášení směrovače.
Nasazení SEND – hudba budoucnosti
Stroj podporující SEND by měl umožnit nastavení pravidel, jak zacházet s ověřenými a neověřenými zprávami. Podle specifikace v RFC 3971 se obecně zpráva s neověřeným podpisem či certifikátem považuje za rovnocennou zprávě nezabezpečené, která SEND prvky vůbec neobsahuje. Dokument doporučuje, aby implicitní politika přijímala oba typy zpráv, alespoň do doby, než bude široká podpora SEND běžnou realitou.
Upřímně řečeno si asi počkáme. Výrobci síťového hardwaru se celkem snaží, SEND nabízí Cisco i Juniper. Na straně operačních systémů už je situace o poznání slabší. Existují implementace pro FreeBSD, Linux a některé spíše experimentální kousky, jako je Easy-SEND či v podstatě fiktivní JSend. Ovšem dokud se nedočkáme podpory v MS Windows, není příliš reálné o něm uvažovat.
Přestože minule zmiňovaný RA-Guard je teprve ve stádiu pracovního návrhu, v reálných sítích se s ním nejspíš setkáme dříve. K jeho nasazení stačí podpora v aktivních prvcích, nemusí dosahovat až do uživatelských strojů. Se SENDem se dobře doplňují a za ideální stav lze považovat kombinaci obou. Ovšem k tomuto cíli se hned tak nedostaneme.
