I2P – Invisible Internet Project
I2P je podobne ako TOR sieťou onion routerov. Na rozdiel od TORu nebola pôvodne navrhovaná na proxovanie na internet, aj keď sa tak dá použiť. I2P, podobne ako TOR, sama neposkytuje žiadne služby, je to len nadstavba nad TCP/IP, ktorá má zaručiť anonymitu. Je ale navrhnutá tak, aby bolo veľmi jednoduché do nej nejakú službu (web server, zdieľanie súborov, anonymné blogy, atď.) vložiť bez nutnosti modifikácie pôvodného software – akonáhle pakety prídu, sú preposlané na socket lokálne bežiacej služby. I2P software je napísaný v Jave, takže celkom žere pamäť, ale nie je to až také hrozné. Posledná vyskúšaná CVS verzia bola funkčná a stabilná. Na ich software je skvelé, že zobrazuje hádam všetky možné štatistiky a informácie o sieti (ku ktorým má prístup). Od prenesených dát cez rozličné grafy, štatistiky o tuneloch až po profily ostatných routerov, ako ich vidí z vlastnej perspektívy. Je na tom dobre vidieť, ako sieť žije.
V I2P sieti sa vytvárajú tunely, ktoré majú životnosť 10 minút. Na rozdiel od TORu sú jednosmerné: každý účastník má niekoľko inbound a outbound (príchodzích a odchodzích) tunelov. Poslaná správa vyjde z outbound tunela odosielateľa a vojde do inbound tunela príjemcu. Tým pádom je ešte ťažšie korelovať príchodzie a odchodzie správy medzi dvoma účastníkmi, pretože idú po iných cestách. Každý účastník I2P siete musí byť zároveň routerom. Je síce možné rozšíriť software, aby podporoval proxovanie pre iných klientov, ale súčasný stav zaručuje lepšiu anonymitu.
I2P software profiluje počas behu routre, ktoré pozná a rozdeľuje ich do skupín – rýchle routre, so širokým prenosovým pásmom, atď. až do kategórie „funkčné“ (ostatné sú nefunkčné). Pomáha to priepustnosti siete, pretože sa tunely vyberajú hlavne z lepších serverov. Má skôr bezpečnostné výhody ako nevýhody (prídeme k tomu pri predecessor attacku): veľmi bohatý útočník by mohol spustiť rýchle routre niekde na rýchlej linke (napr. backbone) a mal by vyššiu pravdepodobnosť, že cez neho pôjdu tunely. Aspoň pre tú časť účastníkov, ktorí naňho majú rýchle spojenie. Musel by mať ale naozaj vážnu motiváciu, takýto útok je rozhodne dosť drahý.
Dizajn I2P siete
I2P používa garlic routing, čo je drobné rozšírenie onion routingu – každá vrstva môže obsahovať viacero zašifrovaných správ („cibuliek“, alebo v prípade cesnaku „strúčikov“). Každý router má svoj verejný ElGamal kľúč a podpisovací DSA kľúč. Adresa (ID) routeru v sieti je daná SHA-256 hašom oboch spomenutých kľúčov. V I2P nie je statický zoznam routerov (ako v TORe). Používa Kademlia algoritmus, o ktorom sme hovorili minule, na vytvorenie tzv. NetDb tabuľky. V NetDb tabuľke je kľúčom ID routeru, hodnotou je RouterInfo – zoznam DSA, ElGamal kľúč routra, IP adresa, UDP port. V NetDb tabuľke sú okrem informácií o routroch zapísané ešte LeaseSety. LeaseSet je informácia o inbound tuneloch pre anonymné služby, v I2P nazývané destination. LeaseSet obsahuje verejný ElGamal a podpisovací DSA kľúč služby a vstupný bod inbound tunela – ID routera a identifikáciu tunela (32-bitové číslo). ElGamal kľúč a DSA kľúč služby sú iné ako ElGamal kľúč a DSA kľúč routera, na ktorom skutočne beží, aby sa nedalo podľa kľúča zistiť skutočné umiestnenie služby. Účastník siete neponúkajúci žiadnu skrytú službu dokonca ani nemusí svoj LeaseSet verejne publikovať v NetDb, stačí, keď ho pošle pri kontaktovaní nejakej služby.
Celá I2P sieť je postavená nad UDP protokolom, ktorý je rozšírený na ich vlastný protokol, SSU (secure semi-reliable UDP). V podstate je SSU UDP so šifrovaním a overovaním integrity. UDP hole punching, spomenutý v predchádzajúcom dieli, je podporovaný. Aby bolo možné ako skryté služby používať aplikácie založené na TCP protokole, poskytuje I2P knižnicu, ktorá realizuje streamový protokol nad SSU. Správy Kademlia algoritmu tiež nejdú po nešifrovanom UDP, ale sú tunelované cez tunely natiahnuté medzi niekoľko onion routerov (pri pripájaní do siete sa používa „falošný tunel“ s dĺžkou 0 hopov). Tým pádom sa skutočné dáta premiešajú so správami Kademlia algoritmu, čo viac skomplikuje analýzu toku dát. Routre v sieti používajú synchronizáciu času cez NTP, aby operácie závislé na čase boli čo najpresnejšie (ako napr. životnosť položiek v NetDb).
I2P má v pláne podporovať certifikáty podobne ako SSL. Na prvý pohľad sa to môže zdať ako nezmysel v sieti, kde chceme anonymitu. Certifikáty by ale zaručovali pseudonymitu. Vznikli by certifikačné autority (viac-menej neformálne), ktoré by napríklad dávali routerom certifikát na základe dôveryhodnosti (napríklad by sa tí ľudia poznali osobne, z fóra alebo na základe niečoho iného). Účastník siete by si potom mohol vybrať do tunelov len routery, ktoré majú certifikát od určitej autority, ktorej verí. Alebo používať len služby, ktoré majú taký certifikát. V I2P sieti je podobných možností viac, napríklad dá sa povedať routeru, aby vkladal určité zdržania do paketov (zatiaľ ešte nie je implementované). Tieto informácie ale poskytujú pre útočníka (s vlastnými alebo kompromitovnými routermi) postranný kanál – mohol by napríklad sledovať požiadavky s rovnakým nastavením a korelovať ich ako s určitou pravdepodobnosťou patriace jednému účastníkovi. Mohol by tak napríklad zistiť, že v tuneli určitého účastníka má toľko a toľko svojich routerov. Preto ich bude treba používať rozumne, napríklad nepožadovať po každom routri v tuneli pridávanie zdržania pre pakety.
Na šifrovanie komunikácie medzi routermi sa používa najprv ElGamal na dohodnutie na kľúčoch a neskôr AES-256 v móde CBC. Nedohadujú sa na session key pomocou Diffie-Hellmana, ale router pošle druhému routru niekoľko vygenerovaných kľúčov (zašifrovaných verejným kľúčom), každý na jedno použitie, s obmedzenou životnosťou. V budúcich implementáciách sa počíta s použitím pseudonáhodného generátoru a synchronizovanie seedu.
Vytváranie tunelov
I2P používa jedinú správu na vytvorenie tunela TunnelBuildMessage (oproti teleskopickému vytváraniu v TORe). Správa má konštantnú dĺžku a obmedzenie pre maximálne 8 routerov v tuneli (bežne sa používajú 2–3 pre inbound aj outbound tunely, je to nastaviteľné). Keď nejaký router obdrží požiadavok na vytvorenie tunelu, najprv otestuje, či nie je duplicitná (používa sa pravdepodobnostný bloom filter). Následne sa pozrie, ktorý z 8 záznamov v správe je určený jemu. Ten je zašifrovaný jeho verejným ElGamal kľúčom, tak ho rozšifruje. Router sa rozhodne, či chce participovať v danom tuneli a prepíše časť určenú jemu odpoveďou, v prípade odmietnutia uvedie dôvod. Ak aspoň jeden router odmietne, celý tunel je zahodený. Odpoveď je zašifrovaná s AES-256, ale nejde priamo späť odosielateľovi, ale ďalšiemu routeru v práve vznikajúcom tuneli. Pôvodný odosielateľ určuje poradie (a routre v tuneli). Session key a inicializačný vektor (IV) pre toto šifrovanie boli súčasťou správy TunnelBuildMessage. Session key je pre každý router v tuneli iný. Router AES-zašifruje aj ostatné časti správy určené pre ostatné routre (s rovnakým kľúčom a IV, ako šifroval odpoveď pre pôvodného odosielateľa).
Asi vás napadlo, ako potom rozšifrujú svoju správu ostatné routre, keď ten pred nimi to zašifroval nejakým neznámym kľúčom? Uvedomme si, že šifrovanie a dešifrovanie sú inverzné operácie – je jedno, či sa najprv zašifruje a potom dešifruje, alebo či sa najprv dešifruje a potom šifruje, výsledok je ten istý plaintext. Presne tento trik využije žiadateľ o tunel pri zostavovaní správy: blok pre každý router najprv určitý počet krát dešifruje – s odpovedajúcimi session kľúčmi, v opačnom poradí ako bude správa putovať cez routre. Neskôr ako blok putuje od routeru k routeru a jednotlivé routery ho zašifrujú session kľúčmi, výsledok je, že každý router akurát vidí ten svoj blok (ktorý je naviac zašifrovaný jeho verejným ElGamal kľúčom).
Router po spracovaní TunnelBuildMessage pošle spracovanú správu ďalej – ďalší hop určil žiadateľ o tunel v tejto správe pre router. Posledný hop v tuneli nevie, že je posledný, pretože ďalší hop jednoducho ukazuje na inbound tunel žiadateľa. Pri vytváraní outbound tunela žiadateľ pošle TunnelBuildMessage správu priamo prvému hopu. Ten ale nevie, že je prvý v tuneli, pretože by kľudne mohol predlžovať už existujúci tunel. Pri vytváraní inbound tunelov doručí žiadateľ správu cez svoj outbound tunel routru, ktorý bude prvý hop v novom tuneli. Ten tiež nevie, že je prvý hop. Žiadny z routrov nevie ani, či sú v inbound alebo outbound tuneli. Na začiatku, keď ešte nový uzol žiadny outbound tunel nemá, použije „falošný tunel“ s 0 hopmi.
Pripojenie do siete – bootstrap
Podobne ako pri Kademlii, na pripojenie do siete nám stačí poznať jeden uzol. Jeho sa spýtame, koho pozná a podľa toho sa naplnia k-buckety (spomenuté v diele o Kademlii). Následne si vytvoríme počiatočné tunely (inbound a outbound), a cez ne sa necháme sami vyhľadať, aby sa doplnila informácia o našom routri do NetDb. I2P software počas svojho behu vytvára náhodné „prieskumnícke“ tunely, exploratory tunnels, aby sa našlo čo najviac routrov v sieti (až do určitého limitu, myslím momentálne 500).
Útoky na siete onion routerov
Väčšina útokov na siete onion routerov sú pravdepodobnostné, na základe rozličných meraní je možné s určitou pravdepodobnosťou povedať, že napríklad dva uzly medzi sebou komunikujú. Onion routingové siete sú ale tak komplikované distribuované systémy, že povedať niečo o bezpečnosti zaručene (v zmysle matematického dôkazu) je veľký problém. Mnoho problémov sa stále rieši. Dokonca by som povedal, že oproti veľmi silným útočníkom, ako sú spravodajské služby, by súčasné implementácie mali asi problém obstáť.
Sybil attack
Nie je to úplne útok sám o sebe, ale je základom mnohých ďalších útokov. Spočíva v tom, že útočník môže do siete vložiť množstvo svojich routerov. Čím viac, tým horšie pre bezpečnosť siete. Najhorší protivník (okrem teoretického Veľkého Brata, ktorý všetko počuje) sú spolupracujúce routery (colluding routers). Čím viac spolupracujúcich routerov útočník v sieti má, tým väčšia je pravdepodobnsť, že tunely pôjdu cez niekoľko jeho serverov, v extrémnom prípade bude celý tunel viesť cez jeho servery. Tento problém sa rieši pomerne ťažko, pretože nemôžeme chcieť po účastníkoch, aby sa identifikovali. TOR rieši problém zatiaľ tak, že nedovoľuje novým uzlom spontánne pripojiť sa do siete. Treba napísať živému človeku, ktorý rozhodne, či router do siete pustí. I2P povoľuje každému routeru pripojiť sa do siete, ale uvažuje o hashcash certifikátoch. Za certifikát treba zaplatiť, vo veľkej sieti by útočník musel mať veľké prostriedky, aby získal dostatočne veľký podiel svojich routerov. Certifikáty by neboli povinné, ale účastník by mal možnosť vybrať si tunely len cez routre s týmito certifikátmi.
Intersection attack
Útok je založený na jednoduchom pozorovaní. Pravidelne pingujeme routre. Tie, čo opustili sieť, logicky nemohli byť súčasťou tunelu, ktorý ešte žije. Dá sa skombinovať s chybou v software, ktorá útočníkovi umožňuje zhodiť určité routre. Väčšia sieť a kratšia životnosť tunela znižujú pravdepodobnosť úspešnosti útoku.
Tagging attack
Útočník bude pakety označovať, aby zistil, či niektoré z jeho routerov sú v rovnakom tuneli. Označovanie paketov na IP vrste nie je príliš užitočné, pretože každý router po ceste vytvorí vždy nový paket. Musí využiť chybu v p2p protokole, aby si niekde mohol dáta označiť. Správne implementované overovanie integrity dokáže predísť označovaciemu útoku.
Eclipse attack
Sledovaného účastníka útočník „obkľúči“ v zmysle sieťovej IP topológie. Všetky jeho pakety bude potom môcť časovať a vidieť, kam idú.
Predecessor attack
Tento útok predpokladá, že sledovaný účastník vyberá routre do tunelov s určitým pravdepobnostným rozdelením (typicky uniformným, pre niektoré rozdelenia je tento útok ťažký). Druhý predpoklad je, že počas celého útoku sledovaný účastník komunikuje s rovnakým účastníkom. Útočník si všíma, kto je v tuneli hop pred ním (to vie, pretože od neho dostáva pakety). Ak sa niektorý uzol vyskytne pred ním príliš často (častejšie než iné uzly), znamená to, že ten uzol je pravdepodobne zdroj komunikácie.
Predecessor attack vyžaduje pomerne dlhý čas, aby útočník dokázal korelovať tok dát (hodiny, dni). Dlhšia životnosť tunela znižuje pravdepodobnosť útoku, pretože predpoklad je, že sledovaný účastník musí stále komunikovať.
Ako protiopatrenie slúži strict ordering – to znamená, že routre v tuneli nebudeme radiť náhodne, ale podľa nejakého pravidla, aby útočníkovi pokazil predpoklad vhodného pravdepodobnostného rozdelenie výberu routrov. V I2P sú vždy radené podľa metriky (tá je daná Kademlia algoritmom). Zároveň I2P účastník profiluje routre (ich rýchlosť, atď.) z vlastného pohľadu, čo je informácia útočníkovi typicky neznáma.
TOR je v súčasnej implementácii náchylný na jednoduchý predecessor attack – pretože zoznam všetkých TOR routerov je známy každému routeru, stačí routeru porovnať IP adresu počítača, ktorý ho kontaktuje, so zoznamom všetkých routerov. Tak router zistí, že je prvý v tuneli a pôvodca komunikácie je stroj, ktorý ho kontaktuje.
Fingerprint attack
Útok je použiteľný na protokoly ako HTTP. Útočník si vybuduje databázu webstránok, prístup na ktoré chce sledovať. Uloží si dĺžky jednotlivých odpovedí (stránok) a typické používanie (časový priebeh). Dĺžky a časovanie z databázy bude porovnávať s dĺžkami a časovaním „burstov“ v jednotlivých TCP streamoch, aby zistil, kadiaľ vedie tunel.
Záver
Záujemcov o detaily I2P siete nasmerujem na stránky I2P, na technický úvod. Celkom použiteľnú dokumentáciu k jednotlivým častiam (hoci nie kompletnú) majú v CVS (prístup cez web). Práce s detailne diskutovanými útokmi na anonymné siete nájdete medzi citáciami na CiteSeer.
Na koniec seriálu spomeniem projekt JXTA (Juxtapose), čo je framework na stavanie vlastných p2p sietí. Je vo vývoji už pomerne dlho a je dosť vyspelý, čo sa ponúkaných technológií týka. Pôvodne bol vyvíjaný v Jave, ale existujú aj C++ knižnice. Krátky prehľad vlastností JXTA nájdete na wikipedii alebo sa pozrite priamo na JXTA homepage.
