Valkyria Besiada – szyfrowany komunikator end-to-end
Na początku była rozmowa i prywatność.
Aplikacja Valkyria Besiada
Valkyria Besiada jest komunikatorem szyfrowanym E2E działającym w kryptosystemie Rabina. Aplikacja ta oferuje następujące funkcje:
- szyfrowaną korespondencję tekstową wraz z możliwością osadzania plików i obrazów (czat),
- szyfrowane połączenia głosowe,
- weryfikację rozmówcy poprzez podpisy cyfrowe,
- rozproszoną architekturę serwerową (możliwość wyboru serwera komunikacyjnego),
- połączenia bezpośrednie P2P,
- ochronę przeciw telemarketerom poprzez mechanizm zawołania,
- szyfrowaną historię połączeń i listy kontaktów,
- możliwośc sporządzania kopii historii połączeń i listy kontaktów w formie zaszyfrowanego pliku,
- mechanizm uwierzytelnionych podpisem cyfrowym aktualizacji.
Aby pobrać komunikator Valkyria Besiada, wystarczy, że klikniesz poniższy link. Pobrany plik przenieś od razu do lokalizacji, w której chcesz go przechowywać (powinna być stała) zanim go uruchomisz. Zmiana lokalizacji pliku, z przyczyn bezpieczeństwa dotyczącego przeglądarek, powoduje uniemożliwienie dostępu do historii zapisanej w pamięci przeglądarki. Korzystaj też w miarę często z opcji tworzenia kopii zapasowej listy kontaktów i korespondencji.
Pobierz komunikator Valkyria Besiada
Szyfrowanie E2E w komunikatorze
Szyfrowanie E2E (end-to-end) polega na takim zastosowaniu kryptografii, aby wiadomości były zaszyfrowywane na komputerze nadawcy i odszyfrowywane dopiero u odbiorcy. Zapewnia to brak możliwości zapoznania się z treścią korespondencji przez podmioty trzecie, pod warunkiem nieistnienia luk bezpieczeństwa w komputerach osób komunikujących się na odległość.
Użycie samego TLS nie zapewnia tej funkcji z tej przyczyny – każdy komunikat jest odszyfrowywany przez pośredniczący serwer i ponownie szyfrowany podczas wysyłania do drugiej osoby. W celu uniemożliwienia zapoznania się z wiadomościami przez osoby trzecie stosuje się kryptografię asymetryczną.
Kryptografia asymetryczna
Kryptografia asymetryczna dostarcza takie narzędzia jak szyfrowanie i podpisy kryptograficzne. W kryptografii asymetrycznej generuje się klucz prywatny i klucz publiczny. Klucz prywatny umożliwia odszyfrowywanie oraz podpisywanie wiadomości. Klucz publiczny umożliwia zaszyfrowywanie wiadomości oraz weryfikację poprawności podpisu elektronicznego.
Osoby, które chcą zachować prywatność korespondencji, generują klucze prywatne i na podstawie nich obliczają klucze publiczne. Klucz publiczny jest przekazywany osobom, z którymi chcą prowadzić korespondencję. Wymiana kluczy co do zasady powinna nastąpić zaufanym kanałem komunikacyjnym. Może to być na przykład przekazanie klucza na dysku USB podczas spotkania.
Po wymianie kluczy publicznych o odpowiedniej złożoności możliwe jest komunikowanie się w taki sposób, że osoba trzecia nie jest w stanie podejrzeć treści wiadomości. Wie jedynie, że trwa komunikacja, ale nie wie o czym jest rozmowa.
Przykładami algorytmu kryptografii asymetrycznej są RSA, ElGamal oraz kryptosystem Rabina. Valkyria Besiada używa algorytmu Rabina do utajniania treści komunikatów oraz do ich podpisywania.
Podpis kryptograficzny zapewnia, że nadana wiadomość pochodzi rzeczywiście od osoby, która ją podpisała.
Implementacja kryptografii w Valkyrii Besiadzie
Poniżej znajduje się opis zaimplementowanej funkcjonalności krypotograficznej w komunikatorze Valkyria Besiada. Ważnym jest, aby użytkownik końcowy miał podstawowe informacje jak działa oprogramowanie i miał pewność, że zapewnia odpowiedni stopień poufności informacji. Każdy twórca komunikatora stosującego szyfrowanie E2E powinien w sposób przejrzysty informować jakie algorytmy stosuje. Siła kryptografii bowiem tkwi w jawności algorytmów, a nie w zaciemnieniu kodu i tajności zastosowanego rozwiązania. Tajne powinny pozostać jedynie klucze prywatne.
Klucz tożsamości kryptograficznej
Podczas tworzenia tożsamości kryptograficznej tworzony jest klucz prywatny, którym użytkownik uwierzytelnia się w aplikacji. Klucz ten ma długość 6144 bitów i aktualnie jest bardzo silnym kluczem oficjalnie niemożliwym do złamania (w roku 2024 wystarczająca długość klucza RSA / Rabina wynosi 2048 bitów). Klucz ten jest niezmienny i służy jedynie do podpisywania i odszyfrowywania nielicznych komunikatów, takich jak zmiana statusu, utworzenie nowego klucza i wymiana podstawowych informacji przy wymianie zaproszeń.
Klucz ten pozostaje zawsze w miejscu wskazanym przez użytkownika (najczęściej na zewnętrznym dysku USB). Prywatny klucz tożsamości kryptograficznej (umożliwiający między innymi odszyfrowywanie wiadomości) nigdy nie jest wysyłany na serwer. Klucz ten przechowywany jest zawsze w sposób zaszyfrowany, dlatego przy każdym rozpoczęciu pracy z Valkyrią Besiadą potrzebne jest podanie hasła, które umożliwia odszyfrowanie klucza tożsamości kryptograficznej.
Publiczny klucz tożsamości kryptograficznej (umożliwiający zaszyfrowanie i weryfikację podpisu) przekazywany jest innym użytkownikom dowolnym kanałem w postaci zaproszenia. Zaproszenie zawiera wskazanie serwera, za pomocą którego rozmówca odbiera komunikaty oraz wskazanie klucza tożsamości kryptograficznej. Klucz ten jednoznacznie identyfikuje użytkownika, bowiem w interesie użytkownika chcącego zachować prywatność jest nieprzekazywanie klucza prywatnego komukolwiek.
Zagubienie pliku tożsamości kryptograficznej (wygenerowanego przy pierwszym użyciu Valkyrii Besiady) lub hasła powoduje brak możliwości ich przypomnienia. Oznacza to także, że bez włamania do komputera nie jest możliwe podsłuchiwanie i czytanie korespondencji.
W tym miejscu zastanów się jak wygląda logowanie do większości innych komunikatorów E2EE. Czy nie jest tak, że wysyłasz do serwera swoje hasło i serwer odsyła Ci klucz? Jeżeli tak jest, oznacza to, że ktoś inny może mieć dostęp do klucza prywatnego. Jeżeli dotychczas używany komunikator nie jest transparentny w zakresie informacji kto posiada klucz prywatny i gdzie jest on przechowywany – taki komunikator nie powinien być używany, bowiem nie zapewnia on prawdziwej prywatności.
Dobrym testem, czy komunikator zapewnia prywatność, jest próba uzyskania dostępu do własnej komunikacji i listy kontaktów poprzez oddzielny komputer (lub maszynę wirtualną). W tym celu należy spróbować zalogować się na komunikatorze z komputera, na którym nigdy wcześniej nie komunikowano się z danego konta. Jeżeli komunikator umożliwi odczytanie listy kontaktów lub listę wiadomości bez przekazania mu klucza kryptograficznego, oznacza to, że ktoś trzeci odpowiedzialny za serwer posiada niezbędne informacje (lub prawie wszystkie niezbędne informacje), aby samodzielnie odszyfrować treść twoich kontaktów i wiadomości. Tak być nie powinno. Prawidłowa implementacja to taka, gdzie musisz samodzielnie dbać o swój prywatny klucz kryptograficzny i nigdy go nie przekazujesz innym osobom.
Valkyria Besiada używa jawnych algorytmów szyfrowania i weryfikacji podpisów. Posiada także otwarty kod źródłowy oprogramowania dostępny w języku JavaScript oraz wymaga każdorazowo od Ciebie podania klucza prywatnego, którego nikomu nie wysyła. Masz pewność, że klucz znasz tylko Ty, o ile nie masz szkodliwego oprogramowania (np. antywirusowego, wysyłającego pliki do chmury w celu «skanowania»).
Generowanie kluczy pomocniczych i budowa komunikatu
Po wygenerowaniu klucza tożsamości kryptograficznej i jego załadowaniu (opcja logowania się do osobliwości kryptograficznej) następuje wygenerowanie klucza prywatnego Rabina o długości od 2048 do 5120 bitów, który jest używany do szyfrowania wszystkich innych komunikatów niż podane wyżej. Tym kluczem są więc szyfrowane wszystkie wiadomości tekstowe, pliki i obrazy wysyłane do Ciebie.
Ze względu na fakt, że szyfrowanie czystym algorytmem Rabina jest kosztowne obliczeniowo, na etapie wysyłania wiadomości następuje wygenerowanie klucza AES-256, osadzenie tego klucza na początku wiadomości wraz z początkową częścią komunikatu do zaszyfrowania. Dalsze bloki wiadomości szyfrowane są kluczem AES-256 w trybie PCBC. Uniemożliwia to atak na szyfrowanie AES-256, ponieważ kluczem tym zaszyfrowana jest mała porcja danych – jeden komunikat. Algorytm ten jednocześnie jest znacznie szybszy od algorytmu Rabina. Aby móc rozszyfrować dane zaszyfrowane algorytmem AES-256, najpierw trzeba odszyfrować pierwszy blok wiadomości, w której znajduje się klucz AES-256. Tym sposobem zachowana jest oryginalna siła algorytmu Rabina i jednocześnie została uzyskana szybkość działania pozwalająca na płynną komunikację.
Każdy komunikat (inny niż głosowy) składa się z nagłówka wiadomości pozwalającego na weryfikację integralności wiadomości, klucza AES-256, którym dą zaszyfrowane dalsze bloki wiadomości, danych zaszyfrowanych algorytmem AES-256 oraz podpisu cyfrowego skrótu wiadomości, znajdującego się na samym końcu wiadomości. Skróty wiadomości są wyliczane algorytmem SHA-512.
Komunikaty głosowe przesyłane są w sposób zaszyfrowany jedynie AES-256. Klucz AES-256 do komunikatów głosowych jest nadawany najrzadziej co 2 minuty lub co 1 MB danych głosowych – zależnie który limit osiągnięty zostanie szybciej. Jest to podyktowane faktem, że dane głosowe trzeba najrzadziej szyfrować 5 razy na sekundę i traktowanie ich algorytmem tym samym co dla wiadomości tekstowych powoduje brak wyrobienia się na czas. Rzadsze zaś wykonywanie szyfrowania i wysłania generuje nieakceptowalne opóźnienia.
Faktem pozostaje jednak, że połączenia głosowe prościej jest podsłuchać stojąc po prostu pod drzwiami i wykorzystując ich niedoskonałość – przepuszczanie dźwięku – lub też stosując pomiar wychylenia szyby w pokoju za pomocą lasera (szyba drga tak samo jak dźwięk, drgająca szyba powoduje odchylanie wracającej wiązki lasera). Łamanie AES-256 z losowo wygenerowanym kluczem, posiadając tylko próbkę 1 MB danych, jest niezmiernie trudne lub nawet niemożliwe. Prościej jest zorganizować podsłuch mieszkania, w którym rozmawiasz.
Historia korespondencji i lista kontaktów
Aby uniemożliwić osobom niepowołanym dostęp do twojej korespondencji równie ważne co szyfrowanie transmisji jest szyfrowanie listy kontaktów oraz historii korespondencji.
Wiadomości po odebraniu i wyświetleniu w oknie rozmowy są następnie zapisywane na dysku (w wersji HTML oprogramowania – w postaci «bazy danych» IndexedDB). Nie wierzymy dostawcom przeglądarek, że poczynili zadość temu, by zapewnić prywatność podczas przechowywania tej bazy danych. Dlatego każda informacja bez wyjątku trafiająca do IndexedDB jest podpisywana i zaszyfrowana przed zapisaniem jej do IndexedDB. Kluczem prywatnym jest klucz tożsamości kryptograficznej. Odczytanie wiadomości historycznych i listy kontaktów jest możliwe tylko po zalogowaniu się do osobliwości kryptograficznej.
Lista kontaktów oraz ustawienia programu (poza informacją o motywie graficznym i stosowanym powiększeniu interfejsu) są zapisywane tak samo jak historia korespondencji, w tym samym formacie. Informacja o stosowaniu jasnego lub ciemnego motywu oraz stosowanym powiększeniu interfejsu nie jest szyfrowana i jest trzymana w localStorage, co umożliwia czytelne wyświetlenie interfejsu graficznego już w momencie podawania klucza prywatnego i wpisywania hasła. Niezaszyfrowane dane nie mają charakteru poufnego. Niezaszyfrowane dane (informacja o wybranym motywie i powiększeniu) mają entropię 3 bitów.
Forma aplikacji HTML
Oprogramowanie w początkowej wersji dostępne jest w postaci jednoplikowej aplikacji HTML. Forma taka została wybrana ze względu na możliwość uruchomienia w prawie każdym systemie operacyjnym. Przeglądarka jest popularnym oprogramowaniem dostępnym na większości komputerów.
Forma jednoplikowa do jednorazowego pobrania z serwera została wybrana po to, by uniemożliwić nieautoryzowaną podmianę oprogramowania bez wiedzy użytkownika. Każda podmiana oprogramowania wymaga aktywnego udziału użytkownika (musi on nadpisać wskazany plik). Każde następne pobrane oprogramowanie musi być podpisane cyfrowo i podpis ten jest sprawdzany. Nieprawidłowy podpis uniemożliwia aktualizację oprogramowania.
Każdą aktualizację należy wykonywać za pośrednictwem dostępnej w bocznym menu opcji. Tylko to zapewnia, że oprogramowanie jest wolne od szkodliwych modyfikacji.
Ponieważ przeglądarka teoretycznie może być źródłem wycieku haseł i kluczy kryptograficznych (przy istnieniu odpowiednich podatności lub zgniłych polityk prywatności), rozważane jest stworzenie aplikacji natywnych na poszczególne systemy operacyjne. Autorka Valkyrii Besiady nie dysponuje jednak na ten moment potrzebnymi środkami finansowymi na taki rozwój oprogramowania. Potrzebny jest do tego czas i pieniądze. Przy odpowiednim wsparciu rozwoju oprogramowania przekazanymi przez Was środkami będzie to możliwe. Gdy autorka nie będzie musiała pracować i będzie mogła utrzymać się z przekazanych środków – możliwe będzie poświęcenie czasu w wymiarze minimum pełnego etatu na rozwój tego oprogramowania bez potrzeby poświęcenia tego czasu dla pracodawcy.
Valkyria Besiada jako system rozproszony
Komunikator ten jest stworzony w architekturze rozproszonej. Twoje wiadomości historyczne są przechowywane tylko na twoim komputerze, jednak każdy użytkownik może korzystać z dowolnego serwera implementującego protokół DMTP-1.0 (Direct Message Transfer Protocol) do odbioru wiadomości wysłanych do niego. Serwer ten wskazywany jest podczas powitania i jest możliwa późniejsza jego zmiana.
Kod serwera DMTP-1.0 zostanie wkrótce opublikowany po końcowym etapie testów stabilności z większą ilością użytkowników. Protokół ten jest tak prosty, jak to możliwe i służy jedynie do wpisywania komunikatów bezpośrednio (bez odszyfrowywania) w odpowiednią przegródkę dla użytkownika końcowego.
Poza możliwością wskazania serwera jest opcjonalna możliwość łączenia się bezpośrednio między użytkownikami. Opcja ta dostępna jest w ustawieniach pod nazwą «Odrzuć połączenia P2P». Domyślnie połączenia P2P nie są odrzucane i możliwa jest bezpośrednia komunikacja między użytkownikami. Powoduje to konieczność przekazania adresu IP pomiędzy użytkownikami (adres IP nie jest ujawniany, gdy połączenia są odrzucane).
Połączenie bezpośrednie jednak każdorazowo wymaga napisania chociaż jednej wiadomości i wysłania jej przez serwer, by umożliwić nawiązanie połączenia P2P. Dzieje się tak, ponieważ użytkownicy zazwyczaj znajdują się w odseparowanych od sieci Internet sieciach lokalnych (są chronieni przez NAT).
Połączenia bezpośrednie realizowane są w technologii WebRTC. Dane przesyłane poprzez WebRTC są szyfrowane przez oprogramowanie Valkyria Besiada. Możliwe na dzień dzisiejszy jest pisanie bezpośrednich wiadomości (które nie trafiają nigdy na serwer) oraz prowadzenie rozmów głosowych. W planach, po odpowiednim waszym wsparciu, jest umożliwienie rozmów konferencyjnych (między wieloma użytkownikami), dzielenia pulpitu oraz prowadzenie videokonferencji. W dalszych planach jest także stworzenie dobrowolnej usługi «atlas» oferującej e-wizytówki.
Możesz wspierać rozwój niniejszego komunikatora również zlecając autorce wykonanie systemów zabezpieczonych przed włamaniami za pomocą technologii PKI. Twoje dane firmowe mogą być tak bezpieczne, jak wiadomości w niniejszym komunikatorze.