Побудова власної комунікаційної мережі поверх I2P

    При сучасних тенденціях, спрямованих на тотальне прослуховування та збір всілякої інформації, використання захищених засобів комунікації як ніколи актуально. Шифрування самих переданих даних вирішує проблему лише частково, оскільки сам факт обміну інформацією між учасниками важливіше його змісту.
 
У більшості сучасних систем будь то електронна пошта, ICQ або твіттер, власник серверів володіє всіма цими даними і може, при необхідності, поділитися ними при отриманні офіційного або неофіційного запиту про це. Нижче пропонується проект мережі, побудованої поверх I2P, в якій власник використовує свої вузли тільки для забезпечення більш стабільної роботи і в якості шлюзів в звичайний інтернеті, маючи інформації не більше, ніж звичайні вузли I2P.
 
 
Розглянемо механізми забезпечення анонімності та конфіденційності I2P, на які будемо спиратися для побудови нашої мережі:
 
     
  1. Всякий учасник I2P являє собою відомий решти мережі маршрутизатор і один або декілька адрес, що утворюють власне «невидиму» мережу. Сенс I2P полягає в практичній неможливості дізнатися на якому маршрутизаторі розташовується той чи інший адресу
  2.  
  3. Адреса I2P являє собою пару відкритих ключів для асиметричного шифрування і підпису. Закрита пара ключів зберігається у власника і є підтвердженням автентичності адреси. Інакше кажучи, для авторизації замість паролів використовується цей файл з ключами — аналог електронно-цифрового підпису, може бути, при необхідності, реалізовано у вигляді токену
  4.  
  5. Злуки між маршрутизаторами шифруються з використанням AES, сеансовий ключ для якого узгоджується в кілька кроків, що включають в себе перевірку підпису адреси вузла з метою протистояння атакам типу «man-in-the-middle»
  6.  
 
 Раніше було показано, що фактично I2P являє собою дворівневу конструкцію: маршрутизатор, що забезпечує взаємодію з іншими маршрутизаторами і роботу тунелів, і протоколи, призначені для передачі даних між додатками. Якщо протоколи для маршрутизатора представляються ретельно продуманими і ефективними, то прикладні протоколи залишають бажати кращого і являють собою нагромадження різних концепції та ідей, обумовлених прагненням зробити їх максимально універсальними і «прозорими» для вже існуючих додатків. У нашому випадку завдання істотно спрощується, оскільки ми припускаємо обмін між нашими клієнтами, тому можемо використовувати власний протокол.
 
Інша проблема I2P полягає в тому, що при спробі звернутися до адресою виникає помилка «адреса не знайдено» хоча ресурс з вказаною адресою в даний момент знаходиться онлайн. Відбувається це внаслідок неповноти мережевий бази даних, наприклад, відразу після старту, коли інформація про багатьох маршрутизаторах стає застарілою і потрібен час для її оновлення. А оскільки адреси публікують свої LeaseSet-и на «ближайщих» до себе floodfill-ах, то потрібних floodfill-ів у клієнта в базі ще може просто не бути. Наші клієнти будуть використовувати другу мережеву базу даних, що містить набір вузлів, відповідні наших серверів і публікувати свої LeaseSet-и тільки на цих вузлах, що дозволить знаходити LeaseSet-и один одного негайно.
 
Кожен вузол I2P ідентифікується I2P адресою, що представляє собою 2 пари відкритих і закритих ключів, що генеруються у момент створення вузла випадковим чином, без будь-якої кореляції з IP адресою або місцем розташування. Центрального джерела адрес немає, передбачається, що ймовірність збігу двох випадково згенерували адрес пренебрежимо мала. Власником вузла є той, у кого є файл з повним набором ключів. Два відкритих ключа і 3-х байтний сертифікат (на справжній момент завжди нульовий) утворюють 387-байтний ідентифікатор вузла, під яким вузол стає відомий в I2P. Оскільки повний 387-байтний ідентифікатор досить неефективний для порівняння, сортування та передачі даних, то для позначення вузла використовується 32-х байтний SHA-256 хеш від ідентифікатора, використовуваний нами для ідентифікації клієнта. Оскільки адреса містить ключ підпису, то видавати себе за іншого клієнта зловмисникові буде скрутно, це еквівалентно підбору такої пари ключів, хеш від якої буде відповідати цим ідентифікатором. При необхідності клієнт може підтвердити, що за I2P адресою ховається саме він, підписавши якийсь документ своєї ключем.
 
Отже, наша мережа буде складатися з запускаються на комп'ютерах клієнтів нашої мережі і що належить нам серверів. І клієнти і сервера являють собою повноцінні I2P маршрутизатори, при цьому сервера оголошені високошвидкісними і розраховані в першу чергу на пропускання транзитного трафіку, клієнти ж в основному використовують власні тунелі, а транзитний трафік — для маскування своєї активності. Інформація про сервери є публічною і відомою клієнтам, у той же час сервера нічого не знають про клієнтів і не мають можливості відрізнити клієнтів від звичайних вузлів I2P. Клієнти будуть вибирати вузли для тунелів з тим розрахунком, щоб в тунелі був рівно один сервер, а інші вузли належали іншим учасникам звичайною I2P. Навіть якщо всі наші сервера опиняться під контролем зловмисника, то одного вузла буде недостатньо, щоб визначити інший кінець стандартного для I2P 3-х крокової тунелю. У користувача завжди буде можливість побачити маршрути тунелів, а також виключати підозрілі вузли.
 
З іншого боку, один наш сервер в тунелі необхідний для підвищення надійності роботи тунелів за рахунок раннього виявлення перестали працювати тунелів. Це одна з фундаментальних проблем I2P: якщо вузол погодився брати участь в транзитному тунелі, а потім перестав працювати (наприклад, користувач його зупинив), то творець тунелю нічого про це не знає і продовжує використовувати непрацюючий тунель протягом тривалого часу. На відміну від звичайного I2P наші клієнти будуть активно посилати в тунель тестові повідомлення, і як тільки наш сервер виявить відсутність трафіку в тунелі, то опублікує про це повідомлення для клієнтів, дозволяючи тим самим клієнту припинити використання такого тунелю негайно.
 
Для обміну даними між нашими клієнтами може використовуватися I2NP повідомлення типу 20 — Data, що містить довільні дані, або ж повідомлення типу 11 — Garlic. Спочатку в I2P передбачалася наступна схема обміну між адресами: слід було запросити LeaseSet адресата, потім слід було сформувати повідомлення типу Garlic, вказавши адресу в якості місця призначення, зашифрувати його публічним ключем шифрування з LeaseSet-а і відправити у відповідний тунель. Маршрутизатор, отримавши таке повідомлення, розшифровував його і далі визначав, кому призначено повідомлення. Але в цьому випадку ключ шифрування повинен був бути однаковим для всіх адрес, що сидять на даному маршрутизаторі, що породжувало велику «діру» в безпеці, тому в сучасній реалізації I2P у кожного адреси свій набір входять тунелів і ключ шифрування, відповідно маршрутизатор може визначити адресу і без «часникового» повідомлення. Відмовившись від використання «часникового» шифрування ми позбавляємося ще від однієї громіздкої конструкції I2P — AES / ElGamal engine, і можемо використання більш ефективне для наших завдань шифрування, в той же час відправляючи повідомлення типу 11, щоб зробити наш трафік не відрізнятись від звичайного I2P.
 
 
Клієнти можуть обмінюватися поштою як між собою всередині мережі, так і з зовнішніми адресатами. У першому випадку використовуються безпосередньо I2P адреси, і повідомлення пересилаються через тунелі з LeaseSet-а адресата. Якщо клієнт не може виявити LeaseSet з такою адресою, то буде продовжувати робити це протягом певного часу, після чого згенерує повідомлення про неможливість доставки.
 
У другому випадку клієнтові слід скористатися одним з наших серверів в якості вихідного SMTP сервера. У кожного з наших серверів буде свою адресу, а адресою клієнта буде відповідати призначене сервером ім'я користувача, що разом утворюють дійсний поштову адресу. Якщо клієнт бажає відправити поштове повідомлення за межі мережі, він повинен знайти LeaseSet сервера (а він його знайде обов'язково), після чого сервер розпізнає повідомлення як поштове і відправить його адресату як звичайний SMTP сервер. Одержувач буде знати лише адреси нашого SMTP сервера, і навіть якщо хтось захоче дізнатися у нас, хто ховається за тим чи іншим адресою, максимум, що ми повідомити, це I2P адресу, а чий це адреса нам як і раніше невідомо. Якщо сервер отримує повідомлення ззовні, то по імені користувачеві знаходить його I2P адреси і далі посилає звичайним чином всередині нашої мережі.
 
З метою боротьби зі спамом ми введемо обмеження на кількість повідомлень, що відправляються з кожного I2P адреси. Щоб адресу міг відправляти повідомлення назовні він буде повинен зареєструватися на сервері і дізнатися своє ім'я, при цьому ми вимагатимемо від нього сертифікат, що виходить в результаті деякої ресурсномісткої обчислювальної задачі, тим самим ускладнивши масову генерацію адрес, в той же час не створюючи проблем тим, кому потрібен всього один або кілька адрес.
 
Таким чином ми отримуємо мережу, з одного боку забезпечує анонімність і конфіденційність переданої інформації, розкриття якої неможливо без доступу до комп'ютера клієнта, а з іншого боку підтримуючу високий рівень довіри між клієнтами за допомогою засобів криптографічного ідентифікації. Використання власного протоколу і тільки його між клієнтами дозволяє істотно спростити реалізацію і підвищити надійність роботи мережі, поява ж нових високошвидкісних маршрутизаторів поліпшить роботу і пропускну здатність самої I2P.
 
Хотілося б почути думку шановного хабрсообщества з приводу запропонованого проекту в цілому, і в першу чергу про потенційних атаках з метою деанонімізація клієнтів, а також інші слабких місцях і вразливості.
    
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.