Opóźnienie w publikowaniu kluczy

[jasisz]

Nie jest to coś co wynika z dokumentacji, ale podczas prezentacji aplikacji dla społeczności GitHub padło stwierdzenie o tym, że po zuploadowaniu kluczy na serwer następuję opóźnienie w ich publikacji trwające minimum 24 godziny + randomowy jitter, co ma służyć utrudnieniu deanonimizacji takiego chorego.

Już podczas spotkania pojawiły się co do tego wątpliwości (jeżeli mnie pamięć nie myli był to @kwiszowaty ?), że w ten sposób tracone są te 24 godziny.

W odpowiedzi znowu padła kwestia utrudnienia deanonimizacji w małych miastach, ale jako argumentu użyto też że "jest to niejako wbudowane w protokół" bo API Google do wysyłki i tak nie daje nam dzisiejszego klucza (co jest niejako zrozumiałe).

Ta odpowiedź wydaje się natomiast być pozbawiona sensu - skoro dzisiejszy klucz i tak nie jest publikowany, to ryzyko deanonimizacji jest już zmniejszone, a faktyczne opóźnienie rośnie z 24 godzin do 48 godzin w krytycznym przypadku.

[SeraMoon]

W małym mieście lub na wsi włączam ProteGO tylko przy jednej osobie (telefon może mieć sobie właczone wszystko, zawinięty w folię aluminową) - odsłaniam go tylko przy 1 gospodarstwie domowym.

Dzień później dostaję powiadomienie, że jestem zagrożona. Kto mnie "zaraził"?

Przy odpowiedniej zasobności portfela można mieć 10 telefonów 😹 i śledzić 10 różnych rodzin, które mieszkają niedaleko mnie, a później wytykać ich palcami, że mają COVID-a (w normalnych krajach to absurd, ale w Polsce się zdarzyły przypadki nękania osób w kwarantannie).

To przykład jak źle użyć tej aplikacji. Opóźnienie daje to, że atak ten jest wciąż możliwy, ale jest trudniejszy do wykonania (potrwa dłużej).

[jasisz]

@SeraMoon Od początku jest to znana słabość rozwiązania. Dla "technicznego atakującego" nie trzeba do tego dziesięciu telefonów, tylko przejechania się po wsi i zapisania sobie po jednym kluczu od członka rodzinny dziennie. Klucze są zapisywane razem z czasem, więc opóźnienie ich publikowania nie zmienia w ogóle trudności tego ataku dla "technicznego atakującego". Natomiast wiedza o tym, że opóźnienie wynosi 24h+ pozwala na skojarzenie tego również dla kogoś nietechnicznego.

[SeraMoon]

@jasisz czyli z anonimowości pozostały nici. Czcze zapewnienia o anonimowości użytkowników już na poziomie samego protokołu.

Pozostaje odradzać to rozwiązanie, bo tymi "złymi technicznymi" mogą być sami funkcjonariusze Policji (zapewne kontakt przez ścianę da się złapać lub "wydłużyć" kontakt stosując komórkę z silniejszym sygnałem Bluetooth).

[kwiszowaty]

@jasisz Dzięki za zgłoszenie tej uwagi. Tak, to ja poddałem w wątpliwość taką zasadę. Wg mnie nie ma ona żadnego sensu, a dodanie tego do protokołu G+A wcale nie zwiększa prywatności czy nie utrudnia deanonimizacji.

@SeraMoon wprowadzenie opóźnienia wcale nie pomoże w przytoczonym przez Ciebie przypadku.

Kombinowanie przy algorytmie G+A by "zwiększyć bezpieczeństwo" jest moim zdaniem bezzasadne, szczególnie kosztem czasu - który tu powinien być kluczowy.

Na serwer wysyłamy klucze z ostatnich 14 dni, więc jak dostaję powiadomienie, że jestem zagrożony, to niekoniecznie musiało to być wczoraj - równie dobrze do spotkania mogło dojść 10 dni wcześniej. Dodatkowy odstęp 24h nic mi nie daje, bo tylko teoretycznie zwiększa pulę kontaktów - a praktycznie zwiększa ryzyko przekazania wirusa przez osobę narażoną, która nadal o tym nie wie. Do tego wyniki testów w PL są dostępne od kilku h do kilku(nastu) dni, więc to jest dobry randomizer. Całe sedno aplikacji jest w tym by tę informację przekazać jak najszybciej.

Co do wysyłania dzisiejszego klucza, to w DP-3T po potwierdzeniu zakażenia klucz dzisiejszy jest dostępny do wysłania na serwer i dla bezpieczeństwa generuje się nowy, czego nie ma w G+A.

Do tego zakładam, że odpowiedzialna osoba oczekując na wynik testu raczej się nie przemieszcza i unika kontaktów, więc klucz z dnia obecnego śmiało można pominąć. Idąc logiką czekania, to kolejnego dnia też nie mogę wysłać klucza z dziś, więc można tak czekać w nieskończoność.

[kwiszowaty]

A swoją droga tak mi przyszło do głowy pytanie: jak zaimplementowane jest to czekanie aż dzisiejszy klucz będzie dostępny?

Czy skoro nie jest dostępny dziś, a aplikacja może go poprać dopiero jutro, więc nie wysyła nic? I czeka do zmiany daty by wysłać wszystko razem? A co w przypadku gdy użytkownik, po wpisaniu PIN odinstaluje aplikację bo będzie myślał, że wszystko już się wysłało?

[jasisz]

@kwiszowaty Podejrzewam (i takie odniosłem wrażenie po odpowiedzi), że paczka do wysłania jest robiona raz, a opóźnianie jest po stronie serwera, który dopiero z wysłanych paczek przygotowuje paczki do pobrań.

[kwiszowaty]

@jasisz no tak, więc w ten sposób i tak nie wysyłamy klucza z dziś, prawda? Dlatego nie bardzo zrozumiałem argument z czekaniem na ten klucz...

[Dr-Kownacki]

Ja też upomnę się o swoje :-) Opisywałem konsekwencje "opóźniania ogłaszania/pobierania kluczy" na przykładzie w dyskusji z @potiuk już dawno temu - ze dwa miesiące (czas leci...) , zobaczcie poniżej:

https://github.com/ProteGO-Safe/specs/issues/107#issuecomment-617115544

Dlatego, to co piszecie o "opóźnianiu 48h" to już jest całkowity absurd w moim przekonaniu, nie mogę tego racjonalnie w żaden sposób usprawiedliwić - nie sposób tego zrozumieć...

Przecież aplikacja przestaje w takiej sytuacji pełnić swoją rolę w wielu przypadkach. Wszystko to opisałem w comment j.w. . Postulowałbym sprawdzanie co 12h