Poczta elektroniczna to usługa, w której zadbanie o prywatność komunikacji jest nadzwyczaj trudne. Wymaga sporej wiedzy, obniża ogromnie użyteczność a metadane i tak pozostają dostępne. Czy można to zmienić?
Wiele podstawowych usług internetowych powstawało w czasach, gdy kwestie bezpieczeństwa i prywatności nie zajmowały umysłów tworzących je naukowców. Niektóre z nich udało się w kolejnych generacjach poprawić – przykładem niech będzie powszechne wdrożenie protokołu HTTPS, umożliwiającego zarówno uwierzytelnienie serwera jak i szyfrowanie całej komunikacji. Inne stawiają do tej pory spore problemy, jak np. protokoły routingu – wspomnijmy chociażby ataki polegające na złośliwym przejmowaniu tras BGP. Prawdziwym jednak problemem, który do tej pory nie znalazł sensownego rozwiązania, jest poczta elektroniczna.
Problemy z pocztą
Aby zdać sobie sprawę ze skali problemu, spójrzcie w swoje skrzynki. Zobaczcie, ile jest w nich spamu (nawet tego lepiej lub gorzej odfiltrowanego), pomyślcie ile z wiadomości ma fałszywy adres nadawcy oraz ile czasu spędziliście próbując odszyfrować wiadomość w PGP (tak, wiemy, że część z Was sobie z tym świetnie radzi – ale jesteście znikomą mniejszością wobec liczby wszystkich użytkowników poczty). Do tego dodajcie fakt, że spora część Waszej poczty podróżowała między serwerami w formie niezaszyfrowanej oraz to, że informacje, kto, kiedy i z jakim tematem wiadomości do Was pisał mogło zostać utrwalone na każdym serwerze po drodze. A na koniec przypomnijmy, że dla większości z Was, nawet nie korzystających z Gmaila, skrzynki pewnie połowy Waszych korespondentów obsługuje właśnie Google. Wygląda zatem na to, że jest kilka problemów do rozwiązania. Co prawda istnieją projekty niektóre z nich rozwiązujące, lecz jest im daleko do ogłaszania sukcesów. Podsumowując dzisiejszy stan poczty elektronicznej:
- w dużej mierze treść korespondencji jest przesyłana jawnym tekstem,
- wszystkie metadane są przesyłane jawnym tekstem,
- szyfrowanie treści jest skomplikowane,
- powszechny brak uwierzytelnienia nadawcy.
Nadchodzi nowe
Czy problemy poczty można rozwiązać kompleksowo? Autorzy zestawu protokołów DIME twierdzą, że tak. By zrozumieć ich motywację, trzeba sięgnąć do roku 2013, kiedy to dostawca bezpiecznej poczty elektronicznej Lavabit, z usług którego korzystał między innymi Edward Snowden, otrzymał nakaz udostępnienia kluczy prywatnych protokołu SSL swojego serwisu. Ladar Levison, właściciel Lavabit, wolał swoją firmę zamknąć (wraz z kontami 400 tysięcy użytkowników) niż umożliwić podsłuchiwanie ich komunikacji. Jego historię znajdziecie po tymi dwoma linkami. Lavabit zniknął, lecz Levison się nie poddawał. Uruchomił projekt Kickstartera by móc rozwijać swoją koncepcję prywatnej, użytecznej poczty elektronicznej. Wygląda na to, że w tym roku może ona zostać uruchomiona – zatem warto się jego rozwiązaniu przyjrzeć.
DIME, czyli Dark Internet Mail Environment, to zestaw protokołów, które mają znacząco podnieść poziom prywatności poczty, jednocześnie nie podnosząc poziomu wiedzy i umiejętności wymaganych do jej obsługi i maksymalnie wykorzystując istniejące narzędzia, protokoły i infrastrukturę. Na stronie projektu znajdziecie specyfikację techniczną z marca 2015 (miała być nowa ale ciągle nie ma), my tymczasem spróbujemy streścić najważniejsze elementy koncepcji.
Aby rozwiązać problem metadanych, DIME wykorzystuje koncepcję podobną do sieci Tor. Poszczególne elementy wysyłanej wiadomości są szyfrowane różnymi kluczami publicznymi w zależności od odbiorców, którzy mają się z nimi zapoznać. Innym kluczem szyfrowany jest login nadawcy, innym jego domena, jeszcze innym login odbiorcy a jeszcze innym jego domena. Jeszcze innym kluczem zaszyfrowana jest treść. Dzięki temu na poszczególnych etapach komunikacji mogą być widoczne różne elementy wiadomości:
- treść zobaczyć może tylko nadawca i odbiorca – tylko ich kluczami publicznymi zaszyfrowana zostaje wiadomość,
- wiadomość jest także podpisana kluczem prywatnym nadawcy, dzięki czemu odbiorca może zweryfikować jego tożsamość,
- serwer nadawcy widzi informację o jego loginie (by móc go uwierzytelnić) oraz o domenie odbiorcy – nie widzi loginu odbiorcy, bo nie potrzebuje takiej wiedzy, wystarczy, że wie, do którego serwera ma wiadomość przekazać,
- serwer odbiorcy widzi login odbiorcy, lecz nie widzi loginu nadawcy – widzi jedynie jego domenę, więcej informacji nie potrzebuje.
Jak dla nas pomysł jest całkiem ciekawy – na pewno może ograniczyć ilość widocznych metadanych i dopiero skuteczny atak na serwery zarówno nadawcy jak i odbiorcy może ujawnić pełne informacje o przebiegu korespondencji – o ile serwery te będą przechowywały logi komunikacji.
Kwestia zaufania
Oczywiście kolejnym wyzwaniem staje się bezpieczna i zaufana sieć dystrybucji i weryfikacji kluczy. Podstawowym źródłem kluczy będą serwery, na których użytkownicy będą posiadali swoje konta. Dodatkowym zaufanym źródłem mają być usługi weryfikacji kluczy oparte o infrastrukturę CA. Obsługa kluczy ma być maksymalnie zautomatyzowana – zarówno ich pobieranie jak i weryfikacja powinna odbywać się bez potrzeby wykonywania przez użytkownika dodatkowych czynności. Ma to pozwolić na korzystanie z dobrodziejstwa kryptografii klucza publicznego szerokim rzeszom internautów.
Usługa DIME ma być dostępna w trzech podstawowych modelach, realizujących potrzeby różnych grup odbiorców: ufającym (Trustful), ostrożnym (Cautious) i paranoicznym (Paranoid). W sieci pojawiły się komentarze, że właściwa terminologia to niebezpieczny, zhakowany i nieużyteczny – przyjrzyjmy się im jednak po kolei.
W trybie ufającym użytkownik opiera bezpieczeństwo swojej poczty w 100% na bezpieczeństwie serwera, z którego korzysta. W trybie tym klucz użytkownika znajduje się w pamięci serwera, który wykonuje za użytkownika operacje szyfrowania i deszyfrowania wiadomości. Serwer udostępnia takie usługi jak webmail, POP czy SMTP, umożliwiając kontynuowanie używania tego samego klienta poczty co do tej pory. Potencjalnymi użytkownikami mogą być np. duże firmy, które nie chcą zmieniać zbyt wiele po stronie użytkownika lub użytkownicy przyzwyczajeni do swojego programu pocztowego i nie mający problemu z zaufaniem serwerowi.
W trybie ostrożnym klucz szyfrujący w formie jawnej nie opuszcza urządzenia końcowego użytkownika, oferując faktyczne szyfrowanie kanału pomiędzy nadawcą a odbiorcą (end-to-end). Klucz szyfrujący jest wysyłany na serwer zabezpieczony hasłem użytkownika i gdy użytkownik zechce usługę uruchomić np. na drugim urządzeniu, serwer może mu wysłać jego zaszyfrowany klucz, który użytkownik odszyfrowuje na urządzeniu. Serwer przechowuje zaszyfrowane wiadomości i udostępnia jedynie usługę webmaila, gdzie wiadomości są szyfrowane i odszyfrowywane na urządzeniu klienta.
W trybie paranoicznym klucz w żadnej formie nie opuszcza urządzenia końcowego użytkownika. Użytkownik sam musi zadbać o jego przeniesienie z komputera na telefon czy na inne urządzenia, z którego będzie korzystał. Serwer nie udostępnia usługi webmail.
Trzeba przyznać, że różne poziomy bezpieczeństwa i wygody faktycznie brzmią sensownie sprawiając, że każdy może znaleźć swój poziom komfortu. Gdzie zatem tkwi haczyk całego projektu?
Jak to wdrożyć
DIME udostępnia komplet potrzebnego oprogramowania w formie open source plus specyfikację protokołów, w tym DMTP (Dark Mail Transfer Protocol) który ma zastąpić SMTP. Haczyk polega jednak na tym, że DIME nie jest kompatybilne z istniejącymi rozwiązaniami pocztowymi. Co prawda ma umożliwiać równoległe funkcjonowania „starej” i „nowej” poczty na tym samym serwerze, ale wygląda na to, że np. dopóki Gmail nie wdroży DIME, to zaszyfrowanego emaila do użytkownika Gmaila nie wyślemy za pomocą tego protokołu. Niestety wygląda na to, że do przejścia internetu na DIME droga może być daleka.
Powraca Lavabit
W dniu inauguracji Trumpa Levison ogłosił także powrót usługi poczty Lavabit. Jak na razie jest to powrót dość ograniczony – można zapisać się na nową skrzynkę (w promocyjnej cenie 15 dolarów rocznie za 5GB – zamiast 30) lub reaktywować swoją starą usługę (opcja dla istniejących klientów Lavabit sprzed kilku lat). Istotną zmianą jest inny sposób przechowywania klucza prywatnego SSL – tym razem trzymany jest w module sprzętowym uniemożliwiającym jego eksport, a próby jego siłowego wyciągnięcia powinny kończyć się jego zniszczeniem (hasło umożliwiające zapisanie i odczytanie zawartości modułu zostało wylosowane, użyte do zapisania klucza i zniszczone). Lavabit nie będzie zatem mógł zostać zmuszony do wyjawienia treści klucza, zatem komunikacja z jego serwerem powinna pozostać poza zasięgiem zainteresowanych służb.
Czy Lavabit i DIME odniosą sukces? Dalecy jesteśmy od hurraoptymizmu w tej kwestii – konieczność migracji na inne oprogramowanie serwerowe będzie pewnie sporym wyzwaniem dla wielu firm dostarczających usługi pocztowe. Projekt ma kilka silnych stron:
- cały kod udostępniony jest w formie open source – pozostałe serwisy „bezpiecznej poczty” nie umożliwiają postawienia swojego własnego serwera,
- siłę projektu będą stanowili jego użytkownicy, zachęcający swoich administratorów do migracji,
- siłą jest także postać Levisona, który wolał zamknąć firmę, która budował 10 lat, niż narazić na niebezpieczeństwo swoich klientów – to daje nadzieje na przyszłość.
Trzymamy kciuki za jego przedsięwzięcie – kiedyś trzeba pocztę zreformować i być może właśnie nadszedł ten dzień.
Komentarze
Chciałbym tylko doprecyzowac jeżeli chodzi o „pozostałe serwisy bezpiecznej poczty” – ProtonMail jest rownież Open Source.
Protonmail nie jest open-source.
Open-source jest tylko webmail protonmaila.
tutamail
Bardzo ciekawe. A jak w świetle tych informacji widzisz bezpieczeństwo takich dostawców jak protonmail i tutanota?
Oni zapewniają, że wszystko jest szyfrowane po stronie klienta, że sami nie mogą nic odczytać.
Jak to z tym naprawdę jest?
Odczytają u odbiorcy :)
Tutanota i protonmail trzymają wiadomości zaszyfrowane na serwerze, ale cokolwiek opuści ich serwery (jak wysyłamy do kogoś maila) to już leci jawnym tekstem. Dodatkowo ani proton ani tutanota nie ukrywają metadanych.
Czy „klucz zapisany w module sprzętowym” nie oznacza mniej więcej tyle, że Służby(TM) nie będą musiały prosić, tylko sobie po prostu odczytają?
Jeżeli natomiast chodzi o same protokoły – fajne, ale „kogo to obchodzi”? I to pytanie nie jest retoryczne. Dla normalnej większości ludzkości, czyli fejsbukowiczowych retardów, podstawowy problem z pocztą jest taki, że do maila nie da się wepchnąć 100 zdjęć z obiadu i procesu jego wydalania. Cała reszta jest wystarczająco dobra, więc ŻADNEJ presji na dostawcach usług nie będzie. Jeżeli zastosowanie oprogramowania specjalistycznego (szyfrującego) wymaga zaangażowania dwóch stron konwersacji, to jeszcze JAKOŚ od biedy da radę to przeprowadzić (patrz: problemy Snowdena z nawiązaniem kanału PGP z dziennikarzem). Tutaj trzeba zaangażować jeszcze 2 dostawców poczty, a mechanizmy nie są dodatkami do istniejącej infrastruktury – powodzenia życzę.
Rozwiązaniem takich problemów nie jest wymiana protokołu, ale całego procesu komunikacji. Brzmi nierealnie? To przypomnę – kiedyś do przesyłania plików stosowano FTP, oferującego bezpieczeństwo na podobnym poziomie, co ówczesne SMTP i POP3 (pamiętacie hasła wysyłane w base64?). O ile sam proces logowania jakośtam połatano szybko (digesty), o tyle reszta transmisji nadal jest jawna. Rozwiązaniem problemu podsłuchu było szyfrowanie (SSL/TLS) klient-serwer, ale nadal – administrator serwera widzi czyste dane. Rozwiązaniem tego problemu jest szyfrowanie end2end – i jeżeli komuś jest potrzebne, to może użyć go w dowolnej chwili już teraz (PGP). Mimo to, jakoś nie widać już „w dziczy” powszechnego użycia FTP do przesyłania plików (przekazywanie loginów haseł, zakładanie ich wcześniej – PITA), gdyż został zastąpiony właśnie zupełnie innym narzędziem: „chmurą”. Wysyp różnych dropboxów i ownCloudów spowodował, że wrzucamy sobie „gdzieśtam” plik i mówimy, komu go udostępnić – koniec roboty.
Czy e-maila można zastąpić? W wielu obszarach to się już stało – najpierw komunikatory, a później „socjal media” zdjęły z e-maila funkcję przekazywania codziennych bzdetów. Jakie funkcje pełni dziś e-mail?
– awaryjnego kanału łączności (link do resetu hasła),
– sposobu specjalistycznej dyskusji (listy mailingowe),
– miejsca docelowego dla różnych zrzutów generowanych z automatów (faktury za usługi, aktualizacje statusów zamówień itp.),
– przekazywanie spraw firmowych.
Pewnie jeszcze trochę by się tego znalazło, ale już na pierwszy rzut oka widać, że wiele zastosowań zwykłego użytkownika POWINNO być przeniesione do innego kanału, a mail zostać zredukowany do zadań specjalistycznych, tak jak FTP.
Nie, moduły sprzętowe są bezpieczne.
A to są jakieś nielegalne moduły made in PRC (anty-NSA)? Osobiście odebrane z linii produkcyjnej przez użytkownika? Czy może obudziłeś się właśnie z kilkuletniej śpiączki i jeszcze nie nadrobiłeś? Nie to, żebym miał jakiekolwiek informacje o backdoorach, ale wystarczy chwilę pomyśleć – jeszcze tego samego dnia, którego pojawi się element szyfrujący w pełni odporny na służby, problem zostanie rozwiązany odpowiednią legislacją lub siłą US Army, tak jak broniony jest petrodolar.
Zatem ja informację powyżej czytam tak:
„Lavabit nie będzie zatem MUSIAŁ zostać zmuszAny do wyjawienia treści klucza, GDYŻ komunikacja z jego serwerem powinna pozostać BACKUPOWANA NA SERWERACH zainteresowanych służb – ale wszystko to będzie już bez jakiejkolwiek winy operatora.”
To bierz tryb „paranoid”, gdzie nie ma znaczenia czy ktoś zna klucz SSL. Ale zaraz, na czym tę pocztę napiszesz… Chyba już tylko papier i długopis pozostał.
Przecież w tej nowouruchomionej usłudze nie ma żadnego trybu „paranoid”, on jest jedynie w propozycji protokołów, której nikt nigdy nigdzie nie wdroży. Nie widzisz tej subtelnej róznicy?
Ty tak naprawdę czy po prostu trollujesz? Tryb paranoid jest zaimplementowany na poziomie protokołu i serwera i będzie dostępny gdy tylko ruszy DMTP.
Gratuluję, dałeś radę zaprzeczyć sam sobie w jednym zdaniu… „BĘDZIE dostępny gdy tylko ruszy DMTP” oznacza tyle, że go NIE MA.
A cały ten tryb paranoid, z kluczem po stronie klienta, to zwyczajne szyfrowanie end2end, którego możesz używać od 2 dekad przynajmniej i NIC NIE ZMIENIA w tym, że służby mające dostęp do certyfikatów SSL operatora BĘDĄ NADAL MIAŁY KOMPLET METADANYCH.
Zanim zarzucisz komuś trollowanie, następnym razem postaraj się zrozumieć, CO konkretnie zabezpieczać ma konkretny element proponowanego systemu, bo na razie chyba widzisz młotek i kilka gwoździ.
Jaki komplet metadanych??? Czytałeś może artykuł?
Od razu rozświetlę ci pewną oczywistość, która jest zawarta już wcześniej nie-wprost: skoro jedynym operatorem DMTP będzie Lavabit, co cała 'bezpieczna’ poczta będzie przekazywana w obrębie Lavabit-Lavabit. Stosowanie jakichkolwiek protokołów zabezpieczających metadane do przekazywania maili w obrębie serwera mija się z celem.
Gdyby takich operatorów było (zaszalejmy, a co!) trzech, to wciąż – wszystkie metadane uzyskujesz obserwując ruch na stykach klienckich, dokładnie tak samo, jak bada się korelacje na exit-node’ach torowych.
Skoro zatem DMTP:
– w ukrywaniu treści nic nie wnosi – end2end mamy od zarania dziejów.
– w komunikacji klient-serwer oraz serwer-serwer nic nie wnosi – SSL/TLS mamy od zarania dziejów i całe zabezpieczenie opiera się na tajności kluczy,
to JEDYNE, co rozwiązuje, to zabezpiecza część METAdanych użytkownika przed wzrokiem administratora poczty – jednocześnie generując dodatkowe problemy (typu: serwer odbierający nie może wygenerować DSN po przyjęciu do kolejki, gdyż to wymagałoby trzymania stanu przez serwer nadawcy, czyli całe przetwarzanie musi odbyć się w czasie trwania sesji serwer-serwer).
Czy ktokolwiek na poważnie sądzi, że przynajmniej promil populacji interesuje się własnymi METAdanymi?!
„The Dark Mail system as it’s currently designed still has some limitations. If someone wants to send email to someone in the same domain, the server will know both sender and recipient. Levison plans to address this by inserting a third-party server in the chain—what he’s calling a public onion. But the details for implementing this are tricky and haven’t been completely worked out.” (https://www.wired.com/2014/07/dark-mail-hides-metadata-from-nsa/)
A czy ty czytasz posta, na którego odpisujesz? Bo twoje zdawkowe odpowiedzi wskazują, że ogarniasz zaledwie ostatnie 3-4 słowa. W dyskusji należy posługiwać się nieco szerszym buforem, przydałoby się pomieścić w głowie przynajmniej treść ostatniego akapitu, więc jeszcze raz, specjalnie dla „złotych rybek” dyskusji:
„służby MAJĄCE DOSTĘP do certyfikatów SSL _JEDYNEGO_operatora_czyli_Lavabit_ BĘDĄ NADAL MIAŁY KOMPLET METADANYCH”
Jako że jest to jest twój kolejny post, w którym wyrażasz jedynie opinie bez poparcia ich żadnym argumentem merytorycznym, czy też wskazaniem błędów w moim rozumowaniu, kolejne zignoruję.
Co do standardowego maila – jest jeszcze jeden duży problem:
Nigdy (o ile nie otrzymamy mailowej odpowiedzi) nie wiemy czy mail dotarł do adresata. Potwierdzenia odbioru to zwykła uprzejmość (można odpowiedzieć, że się nie odebrało maila, ale jednak móc go przeczytać).
Zawsze, kiedy wysyłamy maila leci on w próżnię, jakim jest serwer odbiorcy i łudzimy się, że z tej próżni zostanie on zassany do odpowiedniej szufladki, po czym trafi na odpowiednie biurko. A co jeśli ta odpowiednia szufladka nie istnieje lub jest zamknięta, bądź przepełniona? Każdy serwer w takich sytuacjach decyduje według własnych reguł. Może się też zdarzyć, że serwer w ogóle nie istnieje, albo z dowolnych powodów nie działa poprawnie.
W powyższych sytuacjach, jeśli mamy dużo szczęścia, dostaniemy informację, że mail nie dotarł, ale nie zawsze tak się dzieje.
Wysyłając odpowiednio podpisanego maila z pytaniem do urzędu jest on traktowany równoznacznie z listem wysłanym pocztą. Urząd musi odpowiedź w ciągu X dni. My czekamy na odpowiedź, a urząd dalej czeka na nasze pytanie.
Masz przeciez 'delivery status notification’ w kazdym kliencie pocztowym i zdecydowana wiekszosc serwerow odpowiada stosowna informacja
DSN generuje MTA i nie ma nic wspólnego z żadnym klientem pocztowym, natomiast powiadomienie o przeczytaniu, z którym zapewne mylisz, nie jest tworzone przy udziale serwera. I ta ostatnia rzecz jest jedną z głupszych, jakie wymyślono, a właściwie to skonstruowano – pułapkę na mniej ogarniających. To tak, jakby otwarcie strony banku dawało wybór: chcesz skorzystać z wersji HTTPS, czy HTTP+CSRF+XSFblablabla – to drugie ma więcej literek, więc jest „lepiej zabezpieczone”, prawda?
Ale wiesz, że także listy wysyłane tradycyjną pocztą czasem giną? I nawet jeżeli będziesz mieć wiedzę, że dotarł (śledzenie poleconych), to nadal nie wiesz, czy sprawie został nadany jakikolwiek bieg – kancelaria urzędu też może zgubić. Mail od papierowego listu różni się jedynie nośnikiem, ale bieg SPRAWIE wciąż nadawany jest ANALOGOWO – przez człowieka; w szczególności można się było pośmiać z urzedów drukujących sprawy kierowane do nich e-puapem.
Zmiana ściezki na cyfrową wymaga uzycia narzędzia kompletnie innego, niż e-mail – systemu, w którym od razu po wypełnieniu ticketu sprawie zostaje nadany numer i zaczynają lecieć terminy; sprawa musi w całości być obsłużona w systemie, żeby zawsze komuś 'mrugało’ przypomnienie o niej, inaczej zawsze ma prawo się zgubić.
Problem, który nadgryzłeś, to e-administracja, tego się nie da poprawić na poziomie e-maila, bo żaden-mail się do tego kompletnie nie nadaje. A pierwszym elementem e-administracji, jaki jest niezbędny, to podpis cyfrowy w dowodzie, za którego brak możemy podziękować ministrowi zacofania Boniemu.
Od zawsze twierdziłem, że mamy 21 wiek, wynaleziono już gołębie pocztowe a nawet krojony chleb w foliowych torbach więc po co nam więcej. Gołębie na ogół dolatują chyba, że świnia z domu obok złośliwie wysypie ziarno u siebie. No ale ja jestem ta rybka cyfrowa w okrągłym akwarium.
A moim zdaniem, t cały ten problem z korespondencją do urzędów zaczyna się… Niestety na poziomie świadomości cyfryzacyjnej pracowników urzędów , którzy zwą się „informatykami”! Problem znacznie by uproszczono, gdyby korespondencja z urzędem była na jeden adres e-mail, a nie na konto nazwiskoImię_urzędnika@urząd.pl ! Jeden adres, to jeden system weryfikacji „zdrowia” przesyłki i jej załączników! Jeden, a zatem dużo droższy i efektywniejszy niż dziesiątki tanich anty_coś_tam na każdym komputerku! Jeden adres, to możliwość posadzenia nad dozorem korespondencji, osób o większej wiedzy informatycznej niż dwuklik stosowany! Przy okazji, jednej skrzynki wchodzącej poczty, także TYLKO JEDEN ADRES poczty wychodzącej z urzędu! Aby odbiorca korespondencji nie miał wątpliwości z kim koresponduje! A to wszystko na serwerze podległym urzędowi! Skąd kadry do obsługi urzędów? A co? Może taniej jest utrzymywać scentralizowane systemy poczty elektronicznej? Gdzie pad centrum uwala pracę wielu urzędów! A spamu i tak nie weryfikują ludzie tylko booty! A boot nie wyłapie 100% spamu! Zresztą… Temat jest tematem rzeką i szkoda czasu na rozwodzenie się o czymś na co wpływu podatnik NIE MA! Urzędy wydają kasę nie swoją, to nie oszczędzają, bo i po co?! Odpowiedzialności za niegospodarność NIE MA!
Dosyć dobrze działa bitmessage.
Prowizoryczny e-mail, ale działą.
Moze to pomoze , opinia fachowca od kryptografii , dzisiaj w BIZNES ALERT
Na stronie Generalnego Inspektora Danych Osobowych jest do wglądu „Opinia w sprawie bezpieczeństwa danych przekazywanych przy użyciu poczty elektronicznej”, która wywołała kontrowersje ze względu na proponowane tam narzędzia do szyfrowania poczty elektronicznej – pisze mgr inż. Kamil Kaczyński, kryptolog, członkiem International Association for Cryptologic Research.
Zacznijmy jednak od początku: w opinii GIODO trafnie zauważono, iż poufność przekazywanych informacji można uzyskać, wykorzystując metody kryptograficzne, a konkretnie szyfrowania danych.
Drugą z wymienionych metod jest też odpowiednie zabezpieczenie infrastruktury, na którą składają się komputer nadawcy i odbiorcy, serwery pocztowe nadawcy i odbiorcy oraz kanały komunikacyjne do przesyłania informacji między nimi. Również ta metoda wymaga zastosowania metod kryptograficznych.
Zgodnie z treścią przedstawionego dokumentu, szyfrowanie przekazywanych informacji może być realizowane z wykorzystaniem mechanizmów symetrycznych, zintegrowanych w popularnych archiwizatorach.
Jednym z proponowanych przez specjalistów GIODO rozwiązań jest program 7-zip, dostępny na licencji GNU LGPL (Open Source), rozszerzoną o restrykcje UnRAR. Oprogramowanie to zostało wytworzone i jest nadal utrzymywane przez rosyjskiego programistę – Igora Pawłowa.
7-zip pozwala na tworzenie archiwów, poddanych kompresji metodami LZMA, LZMA2, PPMD, BCJ, BCJ2, BZip2 i Deflate. Wytwarzane archiwa mogą być szyfrowane z wykorzystaniem algorytmu AES i mogą umożliwiać automatyczną dekompresję. Oprogramowanie pozwala tworzyć archiwa w formie samodzielnych aplikacji dla systemu Windows.
Wykorzystywany w 7-zip sposób szyfrowania wymusza jednak na użytkowniku zastosowanie klucza symetrycznego – takiego samego dla procesu szyfrowania, jak i deszyfrowania informacji. Zastosowanie takiego rozwiązania niesie za sobą zarówno szereg zalet, jak i wad. Do podstawowych zalet należy znacząco uproszczony proces budowy oprogramowania (brak potrzeby obsługi sieci), a także szybkość działania. Systemy takie mają jednak bardzo duże ograniczenia związane z wymianą kluczy kryptograficznych, a także problemy związane z koniecznością pełnego zaufania pomiędzy stronami wymiany danych.
Problem wymiany kluczy wynika z faktu, że komunikujące się ze sobą strony muszą w sposób bezpieczny wymienić ze sobą tajny klucz, zanim jakakolwiek poufna komunikacja może zostać zainicjowana. Obydwie strony muszą mieć pewność, co do posiadania przez każdą z nich wspólnego sekretu. Nie zawsze możliwa jest bezpośrednia wymiana kluczy, ze względu na czynniki kosztowe, czasowe, ponoszenie dodatkowego ryzyka, czy też po prostu brak wygody takiego rozwiązania. Możemy sobie wyobrazić, że niekiedy taka wymiana może mieć miejsce, jednak przesłanie takich informacji jak klucze kryptograficzne z wykorzystaniem poczty elektronicznej czy SMS nie jest rozwiązaniem zapewniającym poufność archiwum. Kolejnym istotnym ograniczeniem, jest fakt prowadzenia komunikacji pomiędzy stronami, które nigdy wcześniej ze sobą się nie komunikowały, tym samym nie miały możliwości wcześniejszej, bezpiecznej wymiany kluczy kryptograficznych. Strony takie zazwyczaj nie znają się na tyle dobrze, by osiągnąć odpowiedni wzajemny poziom zaufania, niezbędny do wykorzystania algorytmu symetrycznego także do realizacji funkcji uwierzytelniających. Gwałtowny rozwój wykorzystania Internetu w prowadzeniu komunikacji, powoduje, że liczba przypadków komunikacji pomiędzy nieznanymi sobie wcześniej stronami jest zdecydowanie coraz bardziej częsta. W takim przypadku jedynym bezpiecznym rozwiązaniem jest wykorzystanie algorytmów asymetrycznych.
Kolejnym problemem wynikającym z zastosowania algorytmów symetrycznych jest brak możliwości sprawdzenia integralności i pochodzenia danych. Przykładowo, jeżeli chronione dane będą dokumentacją finansową, albo propozycją umowy, zapewnienie integralności i gwarancja pochodzenia jest niepomijalna. W różnych przypadkach, problem ten dotyczy także zwykłej korespondencji e-mail, gdyż przy ewentualnych postępowaniach karnych niezwykle istotne jest wskazanie kręgu osób posiadających wiedzę o zawartości danych dokumentów. W tym przypadku systemy oparte na algorytmach symetrycznych, a w szczególności proste archiwizery nie mogą stanowić właściwego rozwiązania.
Powróćmy jednak do wykorzystania 7-zip jako wskazanej metody ochrony poufności przesyłanych za pośrednictwem poczty elektronicznej plików. Wskazaliśmy już wadę wykorzystania systemów klucza symetrycznego w komunikacji. Jednak, w przypadku każdej aplikacji mogą także wystąpić błędy w poprawnej implementacji wybranych mechanizmów. Błędy takie częściej występują w oprogramowaniu otwartym, niż w lepiej dofinansowanych projektach komercyjnych. W przypadku rekomendowanego przez GIODO 7-zip szerokim echem odbiły się wykryte w zeszłym roku luki bezpieczeństwa. Pozostawione w oprogramowaniu błędy pozwalały atakującym na zdalne wykonanie kodu, a także na wykonanie operacji mających na celu uszkodzenie stosu pamięci lub przepełnienie bufora. Co bardziej znaczące, 7-zip jako oprogramowanie Open Source jest składową wielu innych aplikacji. Wykorzystanie błędnego kodu spowodowało efekt lawinowy i wiele z tych aplikacji do dnia dzisiejszego posiada niezałatane podatności. Zgodnie z informacjami podanymi przez Talos, podatności te wynikały z błędnej weryfikacji wprowadzanych danych. Dane wprowadzone do aplikacji mogą zawsze pochodzić z potencjalnie niezaufanego źródła, dlatego odpowiednia ich weryfikacja jest kluczowa dla bezpieczeństwa każdej aplikacji. Należy zaznaczyć, iż nie była to jedyna wzmianka dotycząca problemów z rosyjskim oprogramowanie. Na temat 7-zip w wersji portable można także odnaleźć wzmiankę w najnowszym wycieku dokumentów opublikowanym przez WikiLeaks.
Podsumowując, wykorzystanie rozwiązań przeznaczonych do kompresji danych, jako narzędzi gwarantujących poufność komunikacji nie jest rozwiązaniem prawidłowym i nie powinno być stosowane do celów profesjonalnych. Problem narasta przy prowadzeniu komunikacji z szerokim gronem odbiorców. Zdecydowanie lepszym rozwiązaniem jest wykorzystanie dedykowanych platform wymiany plików, pozwalających na wskazanie docelowych adresatów, uzgadniając ich wspólne klucze kryptograficzne z wykorzystaniem odpowiednich mechanizmów asymetrycznych.
Chciałbym nawiązać do potwierdzenia maila.Zdarzyło się wielokrotnie że maile wysyłane za granicę nie dochodziły do adresata.[ Niemcy ] Wprowadzenie potwierdzenia spowodowało ,że jestem poinformowany o zaistniałej sytuacji.W efekcie wysyłam kopię ,ewentualnie telefonicznie sprawdzam.Czy dotarło.Śmieszne ale prawdziwe.