7:26
8/7/2014

* Invisible.im

Zapowiedź nowego narzędzia, które ma utrudnić identyfikację źródeł przecieków. Kilka znanych nazwisk zastanawia się jak sprawić, aby analiza metadanych połączeń/kontaktów dziennikarza nie wskazała źródła, bo nawet jeśli wiadomości pomiędzy nimi były szyfrowane, to czasem nie ich treść a sam fakt kontaktu ma kluczowe znaczenie w namierzeniu wycieku.

Ten wpis pochodzi z naszego linkbloga *ptr, dlatego nie widać go na głównej.
*ptr możesz czytać przez RSS albo przez sidebar po prawej stronie serwisu.

Dowiedz się, jak zabezpieczyć swoje dane i pieniądze przed cyberprzestępcami. Wpadnij na nasz kultowy ~3 godzinny wykład pt. "Jak nie dać się zhackować?" i poznaj kilkadziesiąt praktycznych i przede wszystkim prostych do zastosowania porad, które skutecznie podniosą Twoje bezpieczeństwo i pomogą ochronić przed atakami Twoich najbliższych. Uczestnicy tego wykładu oceniają go na: 9,34/10!

Na ten wykład powinien przyjść każdy, kto korzysta z internetu na smartfonie lub komputerze, prywatnie albo służbowo. Wykład prowadzimy prostym językiem, wiec zrozumie go każdy, także osoby spoza branży IT. Dlatego na wykład możesz spokojnie przyjść ze swoimi rodzicami lub mniej technicznymih znajomych. W najbliższych tygodniach będziemy w poniższych miastach:

Zobacz pełen opis wykładu klikając tutaj lub kup bilet na wykład klikając tu.

4 komentarzy

Dodaj komentarz
  1. tl;dr: Chcą używać XMPP via Tor z własnym serwerem jako Tor hidden service na Twoim adresie .onion.

    W sumie nie najgorzej, ale problem z IM wynika z pierwszej litery: instant. Ataki timingowe (korelacyjne) na Tor były już teoretycznie demonstrowane.

    Ja w roli takiego oprogramowania do przesyłania wrażliwych materiałów źródłowych bez ujawniania źródła widziałbym raczej jakiś anonimowy remailer ze sztucznym, losowym opóźnieniem utrudniającym korelację + sieć węzłów, które agregują wiadomości. W ten sposób powstały szum znacznie utrudniałby powiązanie endpointów. Nawet, gdyby ktoś (NSA) przeanalizował globalnie połączenia i skorelował je ze sobą, miałby zbyt dużo możliwych trafień i musiałby sprawdzać każde z osobna.

    Problemem jest oczywiście “centralizacja” takiego rozwiązania (+ reszta opisana w Invisible.im, tak jak spam) – aby remailer hub generował odpowiedni poziom szumu, musi się do niego podłączać dużo klientów (najlepiej ludzkich, nie botów, żeby analiza wzorców zachowań nie mogła ich łatwo odfiltrować).

    Różne szyfrowane “dropboksy” też mają tę właśnie przewagę nad IM, że wydają się być odporniejsze na ataki korelacyjne.

    A może coś odnośnie rozwiązania invisible.im mi umyka i rzeczywiście nie jest to tak niebezpieczne, jak zakładam?

    • Niedługo ataki timingowe to może być najmniejszy problem, jeżeli to co mają pokazać na najnowszym Black Hat okaże się prawdą: https://www.blackhat.com/us-14/briefings.html#you-dont-have-to-be-the-nsa-to-break-tor-deanonymizing-users-on-a-budget

    • Dzięki, fajny link. Chociaż nie zdziwiłbym się, gdyby ten atak polegał nadal na klasycznej korelacji, wspomaganej faktem, że atakujący ma po prostu dużo węzłów w sieci. Za tym przypuszczeniem przemawia też fakt, że mówią “a handful of powerful servers and gigabit links” – być może atak wymaga np. uruchomienia kilkudziesięciu tysięcy instancji procesu Tor. Maksymalizowałoby to prawdopodobieństwo, że klient wybierze trasę, która przebiega w sporej części przez naszą sieć.

  2. NSA incoming, zamkną stronę za kilkanaście dni.

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.

RSS dla komentarzy: