search

ProteGO-Safe / specs

Opis, specyfikacja i zadania. Zacznij tutaj.
GNU General Public License v3.0
118 stars 29 forks source link

Oznaczanie zagrożonych i powiązanie identyfikatorów z użytkownikiem nie powinno być po stronie serwera #84

Closed jasisz closed 4 years ago

jasisz commented 4 years ago

W specach jest teraz:

Dla każdego użytkownika (identyfikatora), który był w pobliżu, może zobaczyć daty, częstotliwość kontaktów i siłę sygnału (bliskość). Na tej podstawie pracownik decyduje, którym użytkownikom zmienić status.

Dopiero doszło do mnie, że pomimo rezygnacji z numeru telefonu to dalej po stronie serwera:

  1. Istnieje profil użytkownika (również zdrowego).
  2. Znana jest historia jego tymczasowych identyfikatorów.
  3. Arbitralnie (i nie do potwierdzenia w jaki sposób) oznaczany jest status użytkownika.

Nie wiem dlaczego zamknięto issue https://github.com/ProteGO-app/specs/issues/54 które właśnie na tym się skupiało, bo nie rowiązano nijak tego problemu.

System ściągania swojego statusu bezpośrednio z endpointa jest bardzo podatny na manipulacje i ataki (MITM, włamanie na centralny serwer, błąd operatora, celowe działanie), których obejście jest nietrywialne. Przy scenariuszu z publikowaniem klucza który posłużył do wygenerowania tymczasowych identyfikatórw bezposrednie na telefonie są one niemożliwe, bo klucza prywatnego nie da się nijak "zgadnąć" i opublikować.

potiuk commented 4 years ago

Jest dużo debat na temat modelu scentralizowanego/zdecentralizowanego i wydaje się, że są na ten temat różne opinie. Osobiście nie jestem zwolennikiem modelu zdecentralizowanego jak opisałem w https://github.com/DP-3T/documents/issues/13#issuecomment-610279344 i (zwłaszcza jeśli zaadresowane będą kwestie komunikacyjne z #83) wydaje się ze to rozwiązanie scentralizowane może być akceptowalne. Profil użytkownika faktycznie istnieje ale nie można go (po stronie serwerowej) praktyce powiązać z numerem jeśli nie zostanie on podany, lub jeśli zostanie wprowadzone rozwiązanie .4 z #83

jasisz commented 4 years ago

Ja rozumiem, że rozwiązanie scentralizowane ma dwa plusy:

Ale to jest koniec plusów. Reszta to same minusy:

Aplikacja staje się tylko "frontendem" do zbierania danych i wysyłania osób na kwarantannę. Łamie punkty z deklaracji, którą sam @potiuk podpisałeś https://panoptykon.org/7-filarow-zaufania Punkt 1 (Minimalizacja i poprawność danych) - nie są to minimalne dane potrzebne do orzekania Punkt 3 (Dane przechowywane na urządzeniu obywatela) - tworzy to nową bazę danych przechowywanych na publicznyms erwerze Punkt 4 (Bezpieczeństwo, szyfrowanie i anonimizacja danych) - jest to wprost deanonimizacja tymczasowych identyfikatorów (tak, powiazanie ich ze sobą jest ich deaonimizacją) Punkt 5 (Czytelna informacja dla obywateli) - nie wiem w jaki sposóļ kto z tych danych korzysta, bo są na nich odpalane dowolne algorytmy Punkt 6 (Otwartość kodu i przejrzystość algorytmów) - jak wyżej, algorytmy są niejawne Punkt 7 (Publiczna kontrola nad narzędziami) - tak jak pisałem, jest to rozwiązanie utrudniające zachowanie bezpieczeństwa

ghost commented 4 years ago

Cel działania aplikacji ProteGO wcale nie wymaga wysyłania niczego na żaden serwer. Jeśli chcemy posłużyć się zasadą Minimalizacji i poprawności danych, którą przytoczył @jasisz to aplikacja nie będzie wysyłała żadnych danych na żaden serwer.

Baza kontaktów bluetooth stworzona lokalnie w aplikacji jest w 100% wystarczająca do podjęcia decyzji czy mieliśmy kontakt z osobą zakażoną i określenie ryzyka (siły sygnału bluetooth i czasu kontaktu). Żaden MiTM czy manipulacja danymi po stronie backend nie może mieć miejsca.

To samo ma miejsce w przypadku osoby zakażonej, aplikacja na jego urządzeniu posiada lokalnie i bez dostępu do internetu wszystkie dane wymagane do stwierdzenia wszystkich kontaktów tej osoby jak również ryzyka w przypadku każdego z tych kontaktów. Osoba zakażona w momencie diagnozy udostępnia bazę danych z aplikacji i na jej podstawie w sposób transparentny, demokratyczny i otwarty podjęte zostają decyzje na temat ryzyka zakażenie osób trzecich i właściwe kroki zostają podjęte.

Dlaczego więc rozmawiamy o komunikacji tych prywatnych danych, które mogą być korelowane i przetwarzane w dowolny sposób przez osoby trzecie, gdy jest to wyraźnie sprzeczne z przytoczoną zasadą - nie jest w żaden sposób potrzebne do osiągnięcia celu aplikacji.

Taki model upraszcza też system, umożliwia użycie systemu osobom nietechnicznym (np. osobom starszym - rodzina przekazuje osobie telefon z aplikacją, osoba docelowa go ładuje i traktuje jak znane nam moduły śledzący dziecko, rower czy psa, rodzina okresowo sprawdza dane z bazy urządzenia), osobom nie posiadającym telefonów wspierających aplikację i z działającym bluetooth, osobom nieprzyjaźnie nastawionym do instalowania takiego oprogramowania. Działanie aplikacji w przypadku problemów z dostępem do internetu nie zostaje zaburzone. Ryzyko wykorzystania luk exploitowalnych poprzez bluetooth może zostać wyeliminowane poprzez użycie aplikacji na urządzeniu bez karty sim, wifi czy nawet sensorów - swoisty sandbox.

Dr-Kownacki commented 4 years ago

Zgadzam się z powyższym (lokalne bazy kontaktów) - takie były i są założenia naszej propozycji / pomysłu opisanych w CoronaHack/CoronaLog: #63 #62

rtpm commented 4 years ago

FYI https://ncase.me/contact-tracing/ Fajnie zobrazowane podejście. Myśle jednak ze sporo byłoby tych rekordów I odpytań.

jasisz commented 4 years ago

@rtpm Jest to lekkie uproszczenie (ale tylko lekkie), bo oba podejście proponowane w https://github.com/DP-3T/documents przewidują ograniczenie tego co jest publikowane - albo do klucza który posłużył do generowania identyfikatorów zarażonego (pozwala to je odtworzyć), albo do publikowania specjalnej struktury cuckoo filter, która w bardziej "skondensowany" sposób zawiera w sobie informacje o identyfikatorach. Ale super komiks! Będę się posługiwał przy wyjaśnianiu znajomym :)

niutech commented 4 years ago

@jasisz Warto przeczytać też zdanie odrębne ITO nt. PEPP-PT (którego częścią jest DP-3T). Jako alternatywę ITO proponuje protokół TCN (następcę STRICT).

jasisz commented 4 years ago

@niutech TCN też śledzę, ale zdania odrębnego nie czytałem, wielkie dzięki za polecenie.

Pojawił się też taki dokument o DP-3T https://eprint.iacr.org/2020/399.pdf (chociaż nie jest aktualny względem nowszej propozycji). Sporo z tych punktów dotyczy też TCN.

potiuk commented 4 years ago

Tak protokół TCN bardzo ciekawy. No i w końcu też Singapurczycy otworzyli https://github.com/OpenTrace-Community

jasisz commented 4 years ago

Czyli ProteGO najbardziej przypomina BlueTrace, z tym że:

jasisz commented 4 years ago

Ludzie z DP-3T zaczęli tworzyć referencyjną implementację w Pythonie https://github.com/DP-3T/reference_implementation

jasisz commented 4 years ago

Jeszcze ciekawostka z innego wątka - Apple i Google opracowują własny mechanizm - szczegóły tutaj https://www.apple.com/covid19/contacttracing/ Pobieżnie przejrzałem i nie różni się to bardzo od DP-3T z dokładnością do tego, że istnieją pośrednie klucze dzienne, które to są udostępniane w przypadku zarażenia i pobierane przez innych do porównywania. System jest zdecentralizowany, telefony lokalnie sprawdzają ryzyko.

jasisz commented 4 years ago

Zamykam issue, bo wersja 4.1 faktycznie to robi.