První verze | 2003 |
---|---|
Poslední verze | 0,9,45 (25. února 2020) |
Vklad | github.com/i2p/i2p.i2p , [cvs: //cvs.i2p.net/cvsroot/ cvs: //cvs.i2p.net/cvsroot] a [cvs: //cvs.invisiblenet.net: / cvsroot / freeweb cvs: //cvs.invisiblenet.net: / cvsroot / freeweb] |
Zajištění kvality | Kontinuální integrace |
Stav projektu | Aktivní |
Napsáno | Jáva |
Operační systém | Microsoft Windows , Linux , macOS , OpenBSD , FreeBSD a Android |
životní prostředí | nezávislý |
Jazyky | Francouzsky, anglicky, španělsky a mnoho dalších |
Typ | P2P klient |
Distribuční politika | Volný, uvolnit |
Licence | Licence BSD , GNU General Public License , licence MIT a uvolněná do veřejné sféry držitelem autorských práv ( d ) |
webová stránka | geti2p.net |
I2P („ Invisible Internet Project “) je anonymní síť , která poskytuje jednoduchou síťovou vrstvu typu softwarového síťového překrytí , pomocí kterého mohou aplikace navzájem anonymně a bezpečně posílat informace. Komunikace je šifrována mezi koncovými body .
K odeslání zprávy se používá celkem čtyři vrstvy šifrování . Anonymita je zajištěna konceptem „ mix network “, který spočívá v odstranění přímých spojení mezi vrstevníky, kteří si chtějí vyměňovat informace. Místo toho provoz prochází řadou dalších vrstevníků, takže pozorovatel nemůže určit, kdo je původním odesílatelem a kdo konečným příjemcem informací. Každý protějšek může na svoji obranu říci, že data pro ně nebyla určena.
Na internetu je příjemce identifikován pomocí IP adresy a portu . Tato IP adresa odpovídá fyzickému rozhraní ( modem nebo router , server atd.). Ale na I2P identifikujeme příjemce pomocí kryptografického klíče .
Na rozdíl od adresování IP nemůžete určit stroj, který vlastní tento klíč. Protože klíč je veřejný , není zveřejněn vztah mezi klíčem a rozhraním, které je jeho vlastníkem.
„Cíle“ (příklady: webový server, IRC, hra atd. ) Jsou kryptografické identifikátory (nikoli IP adresy) definované dvojicí asymetrických klíčů (pár soukromého klíče / veřejného klíče). Cíl je určen identifikátorem hostitele a číslem portu, ke kterému se má připojit. Může se jednat o POP serveru , An SMTP serveru , An IRC serveru , je web serveru , An SVN serveru , je diskusní skupiny serveru , atd.
Router staví tunely nést příchozích a odchozích zpráv. Chcete-li vytvořit tunel, router požádá jednoho z partnerů, ke kterým je připojen, aby vytvořil tento tunel. Tento partner poté kontaktuje jiného partnera, který je požádá, aby se stal dalším článkem v řetězci vrstevníků tvořících tunel. K dosažení kryptografického cíle - a tedy peer - je nutné vědět, kterému „východu“ tunelu se má věnovat, je vyřešit tento problém tím, že byla do sítě přidána určitá konkrétní třída směrovačů. Jedná se o „ Floodfill “. Udržují seznam spojení mezi tunely a cíli. Tímto způsobem, když chce směrovač dosáhnout cíle, zeptá se Floodfill, do kterého tunelu by měl jít, aby kontaktoval tento cíl. Počet routerů Floodfill se proto s růstem sítě zvýší. Všechno je automatické, pokud síť potřebuje nové Floodfills , směrovače splňující podmínky rychlosti, stability a počtu připojení se tak automaticky stanou.
Všechny směrovače v síti se podílejí na přenosu zpráv ostatních směrovačů a umožňují tak nerozeznatelný provoz, který generujete jeho utopením v neustálém toku sítě. Pro útočníka je velmi složité určit, zda byla data skutečně určena pro vás, nebo zda teprve procházela.
Plíce I2P je I2PTunnel , spravuje příchozí a odchozí tunely. Zejména si můžete vytvořit svůj vlastní jako tunel HTTP, který ukazuje na port 80 vašeho počítače, aby hostoval váš vlastní eepsite a jiný na váš server Jabber nebo POP3 .
Stejně jako u sítí VPN nebo darknets využívá I2P tunelování, aby poskytla „síť v síti“. Na rozdíl od většiny sdílení softwarových souborů v peer to peer do anonymního p2p se I2P zaměřuje na autonomní správu sítě a poskytování anonymní transportní vrstvy . Pokud se použijí samostatně, I2P neposkytuje služby, které lze nalézt na internetu ( e-mail , ke stažení , webové , atd. ). I2P však přichází s několika aplikacemi pro vyhledání některých běžných služeb při zachování kvality důvěrnosti a anonymizace nabízené sítí.
Vývoj aplikací využívajících síť je proto možný bez nutnosti úpravy projektu I2P. Tímto způsobem můžeme vidět aplikace využívající síť I2P, které používají stejné protokoly jako ty, které najdeme na internetu (např .: iMule ).
I2P původně obsahuje anonymní síť IRC : můžete se k ní připojit pomocí klientského softwaru IRC (nezáleží na tom, který z nich) směřuje na adresu serveru 127.0.0.1 a na portu 6668.
Příklady nejfrekventovanějších kanálů: # i2p-fr , # i2p-help , # i2p , #anonops ( Anonymous ).
K dispozici je také API , které usnadňuje vývoj softwaru, jako jsou nové aplikace založené na I2P ( SDK , router atd.).
Korespondenti se nevystavují přímo. Každý z nich používá řadu směrovačů I2P jako prostředníků k vytvoření I2PTunnel. Tyto tunely jsou jednosměrné a slouží k maskování příjemce i odesílatele. Můžeme tedy rozlišit dvě kategorie I2PTunnel:
Chcete-li kontaktovat člena sítě, je nutné najít směrovače I2P, které odpovídají položkám tunelů zpřístupněných příjemcem. Toto hledání se provádí pomocí síťové databáze .
U zpráv procházejících přes I2PTunnels se používá šifrování , které se říká česnekový hřebíček, aby se označil jeho rozdíl od šifrování cibule TOR . Toto šifrování zajišťuje:
Bod 1 brání tomu, aby byly informace obsažené ve zprávě použity k identifikaci korespondentů. Bod 2 brání zprostředkovatelům ve znalosti jejich polohy v tunelu, a proto jim brání rozlišovat mezi korespondenty a zprostředkovateli.
Velikost I2PTunnels je volena kýmkoli, kdo je vytvoří. Má významný vliv na všechny mechanismy, které chrání anonymitu.
Tunel bez zprostředkujícího ochrany nabídek, protože není možné rozlišit dopisovatele a zprostředkovatelům zevnitř sítě; hodnověrné popření chrání. Útočník mimo síť, který má prostředky k dohledu nad provozem takového tunelu, však může provést útok pomocí statistické analýzy.
Když zprostředkovatelé zasáhnou, musí být všichni zprostředkovatelé napadeni, než zahájí útok statistickou analýzou. Mechanismus míchání provozu tento problém řeší.
Pokud je I2PTunnel relativně efektivní při zachování anonymity v síti, sama o sobě již nestačí pro ty, kteří mohou mít globální pohled na síť I2P. Stačilo by sledovat provoz a zjistit, kde začíná a kde končí.
Tunel , I2P nebo jiné, způsobuje škrcení rychlosti a zvýšení latence . Násobení tunelů zvyšuje využití nevyužité propustnosti.
Aby mohl korespondent komunikovat, musí vytvořit tunel, aniž by musel zrušit svoji anonymitu (aby mohl předat svou zprávu vrstevníkům). Tvůrce tunelu musí nejprve vybrat partnery, kteří se budou potenciálně účastnit jeho tunelu. Poté vytvoří požadavek na požadavek (TunnelBuildMessage), který projde vybranými partnery, než se vrátí tvůrci s odpověďmi každého z nich.
Peer výběrVýběr vrstevníků se provádí na základě určitých kritérií. Mezi tato kritéria patří mimo jiné jejich doby odezvy a šířky pásma. Tento výběr se provádí na základě výkonu, spolehlivosti nebo míry anonymity požadované uživatelem.
Vytváření TunnelBuildMessageTunnelBuildMessage je zpráva postavena v tunelu tvůrce . Bude použit k vypsání odpovědí kolegů, kteří souhlasili s účastí v tunelu či nikoli. Pokud jsou všechny odpovědi kladné, pak se tunel vytvoří. Tato zpráva se skládá z osmi záznamových listů. Registrační formulář obsahuje žádost o účast peer. Tunel tedy může mít maximálně osm vrstevníků.
bytes 0-3: tunnel ID to receive messages as bytes 4-35: local router identity hash bytes 36-39: next tunnel ID bytes 40-71: next router identity hash bytes 72-103: AES-256 tunnel layer key bytes 104-135: AES-256 tunnel IV key bytes 136-167: AES-256 reply key bytes 168-183: reply IV byte 184: flags bytes 185-188: request time (in hours since the epoch) bytes 189-192: next message ID bytes 193-222: uninterpreted / random paddingPopis registračního formuláře
Klíč tunelové vrstvy AES-256 a klíč tunelu IV AES -256 : šifrovací klíče, které se použijí během transakcí v tunelu, pokud je vytvořen.
AES-256 odpověď IV a AES-256 Odpověď klíč : Šifrovací klíč odezva a jeho inicializační vektor , umožňuje peer šifrovat své odpovědi před odesláním zprávy.
next message ID : další peer v tunelu . Ten, komu má být zpráva zaslána po odpovědi.
Další možnosti umožňují zkontrolovat integritu zprávy, ale také přidat další informace k odpovědi.
Příprava na odesláníPřed odesláním TunnelBuildMessage tvůrce tunelu zašifruje tuto zprávu dvěma po sobě následujícími způsoby. Od asymetrického šifrování , která udržuje informace důvěrné v síti, pak symetrického šifrování , která zajišťuje, že zpráva prošla v pořadí stanoveném tvůrce:
Asymetrické šifrování : každý registrační formulář je šifrován veřejným klíčem odpovídajícího partnera, takže každý partner má přístup pouze ke svému registračnímu formuláři.
Symetrické šifrování : zpráva je poté zašifrována několika vrstvami, aby byl soubor vystaven pouze ve vhodnou dobu. Šifrování probíhá takovým způsobem, že když peer zakóduje zprávu své odpovědi, pak je registrační karta dalšího peer lze dešifrovat to. Můžete si to představit jako cibuli, která má odstraněnou vrstvu s každým přenosem z jednoho do druhého. Například tunel se třemi vrstevníky A, B a C:
Záznam posledního peer tunelu (C) je zašifrován klíčem odpovědi předposledního (B) takovým způsobem, že když B zašifruje jeho odpověď, pak může být záznam C dešifrován C. Podobně záznamy B a C jsou šifrovány klíčem A, takže B lze číst až po A.
Peer zpracování TunnelBuildMessage Obnova souboruKdyž peer obdrží TunnelBuildMessage , existuje pouze jedna záznamová karta, která není symetricky šifrována. Dešifruje tento soubor svým soukromým klíčem, aby získal požadavek na účast v tunelu .
Volba účastiKdyž je soubor dešifrován, nahradí jeho obsah odpovědí, ať už se účastní tunelu , nebo ne. Pokud odmítne, uvede důvod odmítnutí.
Šifrování zprávJakmile je odpověď vytvořena a zapsána do registračního formuláře, symetricky zašifruje registrační formulář pomocí klíče uvedeného v žádosti. Poté zašifruje ostatní záznamové karty. Šifrování ostatních souborů má za následek odstranění symetrické šifrovací vrstvy , takže soubor dalšího příjemce již nemá symetrické šifrování. Je připraven k dešifrování příjemcem.
Přejít na dalšíPoslední operací prováděnou peerem při vytváření tunelu je předání TunnelBuildMessage dalšímu příjemci. Další příjemce je uveden v registračním formuláři během žádosti.
Poslední vrstevník podílející se na vytvoření tunelu je tvůrcem tunelu. Dešifruje formuláře v opačném pořadí symetrického šifrování, které se provádí při vytváření TunnelBuildMessage , k načtení odpovědí.
I2P reaguje na problém směrování tím, že se snaží neohrožovat anonymitu, kvalitu sítě (latence a propustnost) a odmítnutí útoků na celou síť.
Koncept je jednoduchý, ale důležitý, NetdB (pro síťovou databázi ) je databáze obsahující identifikátory směrovačů v síti . Tato databáze je distribuována a je podobná směrovací tabulce v běžném směrovači (kromě toho, že zde obsahuje identifikační klíče směrovačů I2P). Jako záložní řešení použila DHT od Kademlie na základně, ale to bylo opuštěno.
Ke sdílení metadat ze sítě se inicializuje peer floodfill (malý počet směrovačů I2P používá tento algoritmus, druhý pomocí derivace Kademlia, ale ten se nyní již nepoužívá). Když partner Floodfill zadá nový šifrovací klíč do síťové databáze , další náhodně vybraný partner Floodfill tento klíč znovu požádá, pak pokud je platný, peer se přiblíží k prvnímu a znovu publikuje klíč. Nakonec sdílejí partneři Floodfill svůj klíč neustálým dotazováním v databázi a vytvářením kopií platných klíčů v jejich místní paměti, což vytváří účinek změny vzájemné blízkosti partií Floodfill (vrstevníci se blíží). Všechna data uložená v databázi se samy ověřují ověřením podpisu uloženého prvku. Data jsou ověřována časovým razítkem , směrovače pravidelně kontrolují čas dotazem na server SNTP (pool.ntp.org) a detekují nekonzistence v transportní vrstvě (aby se zabránilo útokům). Jednoduše řečeno, routery Floodfill zajišťují shodu klíčů, směrování informací a přenos dat v síti (3 až 5 routerů Floodfill teoreticky zajišťují správné fungování sady 10 000 routerů v síti). Použitý algoritmus není úplným algoritmem, ale byl upraven tak, aby odpovídal potřebě I2P, aniž by zatěžoval implementaci .
Kademliiny algoritmy byly použity pro výměnu metadat mezi routery . Od tohoto řešení bylo upuštěno , Kvůli obtížím s nastavením algoritmu. Algoritmus vyžadoval minimum zdrojů (PC a procesor ), které směrovače nemohly převzít (dobrý nápad na papíře, ale ne v této aplikaci).
Routeru informace pouze obchody, které jsou nezbytné pro zasílání zpráv přes síť . Jedná se o jeho identitu ( 2048bitový veřejný klíč ElGamal , veřejný klíč DSA a certifikát ) a adresy (seznam IP adres , portů a sad možností publikování). Klíčem k této struktuře je SHA256 identity směrovačů. Pokud verze I2P není ve verzi 1.0, možnosti publikace ladí data .
V takovém distribuovaném systému může hledání informací vypadat jako hledání v tradičním DHT (například v sítích v P2P ). Ale vzhledem k tomu, že síť je nestálá a neustále se vyvíjí (vzhledem k 10minutové platnosti tunelu ), iterativní vyhledávání usnadňuje skutečnost, že informace nejsou na nejbližším směrovači, ale na směrovačích, které mají identifikační klíč blízký SHA 256 (identita routeru + časové razítko ve formátu RRRRMMDD), což umožňuje mít sadu routerů s požadovanými informacemi. To také umožňuje obnovení místa informací v síti a ochranu před útoky (protože k útoku na stroj s tímto principem se umístění informací mění každý den a nutí útočníka pokaždé znovu vytvořit svůj útok). Jelikož jsou data výzkumu citlivá, procházejí průzkumnými tunely, které se liší od datových tunelů.
Ponoření užitečného zatížení umožňuje skrýt data skutečně odeslaná nebo přijatá uživatelem routeru I2P. Ponoření je velmi důležité, protože právě toto chrání anonymitu vůči externímu útočníkovi, který má přehled o síti.
Ve svém návrhu vývojáři berou v úvahu útoky a vytvářejí jejich seznam, aby zajistili ochranu uživatelů a sítě (aby nedocházelo například k přetížení routerů se zaplavením ).