Vlákno názorů k článku
Onion routing v p2p sieťach - TOR

Zde jde identita uživatelů najít snadno, podle množství dat poslaných mezi jednotlivými uzly.

Spíš by to chtělo nějakou synchronní síť, kde se packety mezi routery budou posílat pořád stejnou rychlostí bez ohledu na to, jestli někdo komunikuje nebo ne --- to by pak prolomit nešlo, ale bylo by to pomalé a drahé. Existuje něco takového?

jak to myslis s tou identifikaci identity ?

Pokud bude mít nějaká organizace na jednotlivých routerech internetu počítadla množství přenesených dat, tak pak, pokud si v síti TOR stáhneš soubor třeba o velikosti 750MB, tak se z těch počítadel dá snadno vystopovat, přes které uzly jsi to stahoval --- a bude vidět kdo si kolik dat od koho stáhl (nebude však vidět, o jaká data šlo).

Spávně by se to mělo řešit tak, že jednotlivé uzly anonymní sítě, pokud nemají zrovna co na přenášet, si mezi sebou budou posílat náhodné packety. Pak nepůjde vystopovat, kdo od koho kolik dat stáhl, ale bude to žrát víc přenosové kapacity. --- Ještě je tu jeden problém: pokud sledovatel má podezření, od koho soubor pochází, může mu krátkodobě přerušit nebo zahltit linku a zjišťovat, zda se zpomalí download souboru --- tomu by se dalo bránit tak, že soubor bude rozdroben na kousíčky, které budou distribuovány mezi všechny účastníky sítě.

Počítadlá na routeroch vlastne znamenajú globálneho pasívneho útočníka alebo začiatok a koniec tunela musí viesť cez útočníkove routery. Pravdepodobnosť, že tunel bude viesť cez útočníkove routery závisí od zlomku routerov, ktoré v TORe ovláda (binomické rozdelenie). Obecne musí ovládať O(sqrt(n)) routerov zo siete n, aby mal nejakú rozumnú šancu, ale dá sa urobiť oveľa lepší odhad v závislosti od počtu hopov v tuneli

Napr. pravdepodobnosť, že útočník bude mať 2 alebo 3 routre v tuneli ak ovláda p=1/3 siete, je cca 26% (a celkom prudko klesá s nižším podielom v sieti). Tá pravdepodobnosť klesá ako 3*p^2-2*p^3 ako sa p blíži k nule.

Inak podozrenie vlastne znamená traffic confirmation attack, proti ktorému sa TOR nebráni. Ide o to, aby to podozrenie bolo dosť ťažké nájsť.

Zahltiť linku a sledovať či sa spomalí download:
1) útočník musí byť schopný sledovať samotnú linku príjemcu (nevie odkiaľ čo sťahuje ak nevidí aj druhý koniec)
2) útočník musí byť schopný sledovať linku odkiaľ sa sťahuje (=podozrenie=traffic confirmation attack)

Ako som už raz písal, TOR posiela bogus pakety, ale je ich pomerne málo. Na druhej strane, ešte som nevidel, že by sa cez TOR dalo prenášať rýchlejšie než cca. 15-20 kB/s (a 1-5 kB/s je tiež dosť bežná rýchlosť).

Rozdrobenie na kúsočky: fungovalo by to, podobný princíp používa ANts, volá sa to MANET protokol (http://www.myjavaserver.com/~gwren/home.jsp?page=custom&xmlName=resources, pozrite dole na linky). Cena za to je zrejme spoľahlivosť prenosu.

Na druhej strane, častá zmena trasy napomáha predecessor attacku (zistenie, kto je zdrojom komunikácie). Zase závisí na podieli útočníkových routerov v sieti, ako dlho útok musí trvať a akú pravdepodobnosť úspechu zaručuje.

Ten odhad od druhého odstavca je pre tunel dlžky 3, nejak mi to vypadlo.

A O(sqrt(n)) vymeňte za \Omega(sqrt(n))

Pokud vim, tak napr i2p uzlu se rekne, kolik pasma ma k dispozici a on to pasmo vyuziva +- stale => nelze rict, zda prave komunikuje nekdo pres ten uzel nebo zda komunikuje primo dotycny uzel. Respektive tech voleb je tam povicero a cim vic se blizi maximalni dostupne pasmo a pasmo povolene pro routovani, tim bezpecnejsi takovy uzel pro sveho uzivatele je.

TOR používa "relay drop" celly na skrývanie množstva odoslaných dát. Relay drop je v podstate "prázdny paket". Podľa množstva odoslaných dát a ich časovania by bol globálny pasívny útočník (global passive adversary) monitorujúci traffic všade pravdepodobne schopný korelovať toky dát, ale TOR vo svojom bezpečnostnom modeli sa nesnaží brániť tak silnému útočníkovi.

Náklady na stanie sa globálnym pasívnym útočníkom sú obrovské. Jedna z možností je data retention, ale pokiaľ mi je známe, tak informácie o takýchto streamoch by sa neukladali (tuším len http na štandardnom porte 80 a maily cez SMTP na porte 25 sú sledované).

Oveľa viac možností proti rozličným útočníkom ponúka I2P (o tej bude reč nabudúce), napr. príkazy (optiony) na vkladanie pozdržaní, strict ordering. I2P tiež ešte nemá mnoho z toho zatiaľ implementované, plánuje sa to postupne do nasledujúcich verzií. Inak paradoxne práve používanie špeciálnych príkazov napr. na zvýšenie latencie môže odhaliť identitu ak sa príkazy budú líšiť moc od "bežných optionov".

Ještě by šla zjistit identita poskytovatele dat v TORu, jak jsem popsal výše --- někomu krátkodobě zahltím linku příkazem ping -f (k tomu ani nemusím vlastnit žádný router) a zjišťuji, zda se zpomalil download souboru.

To je ale nepravdepodobny, pokud se nad anonymni siti pouzije jeste torrent. To by potom musel mit utocnik opravdu "z prdele kliku" a mit podezreni na uvodniho seeda uz hodne dlouho pred zahajenim sdileni. Jenze i tak je to v tomhle pripade asi pouzitelny jen stezi a jen pri velkym stesti.

Nemluve o tom, ze spojovat DOS s aktualnim zpomalenim pritoku dat je IMO velmi obtizne, az nemozne, to muze byt cira nahoda.