CONTRA HACK: "klonowanie/streaming" kluczy (!) #109
Comments
|
CRC też by mogło być podatne na utratę prywatności, bo wprawdzie nie można zdekodować, za to utworzyć tabelę GPS-CRC. Kombinacji byłoby dużo, ale zawsze jest to możliwe.
Jeśli API GiA umożliwia dodawanie swoich danych do pakietów, to pewnie tak. Disclaimer, nie jestem ekspertem. |
|
@matsobdev zobacz co wymyśliłem w innym wątku, kluczem chwilowym jest GPS i CZAS jednocześnie, co myślisz - da radę to jakoś wykorzystać przy A+G ? |
|
Trochę poszukałem i w zasadzie jest potencjalnie niestety chyba "gotowe rozwiązanie sprzętowe" - połączenie (przez Internet, może z pośrednim węzłem) ze sobą 2szt. potencjalnie byłoby jakimś teoretycznym punktem wyjścia dla realizacji hipotetycznego zagrożenia z tematu (?) https://www.cassianetworks.com/wp-content/uploads/2019/12/Cassia-E1000-Datasheet-final.pdf Cyt. Jest do tego SDK oczywiście: https://www.cassianetworks.com/products/bluetooth-sdk/ i są różne warianty tych urządzeń (w tym nawet z możliwością LTE na donglu), są i inne zabawki z BLE/Ethernet... https://www.cassianetworks.com/products/ Odrębną już w pełni realną sprawą jest jak zachowa się technologią API G+A w sytuacji "zwykłej" obecności takiego j.w. repeatera, bo moim zdaniem to połączy "wszystkich że wszystkimi" ponieważ moc "wzajemnych" sygnałow krytycznie wzrośnie i RSSI uruchomi zapisywanie kluczy nawet osób oddalonych o kilkanaście metrów i więcej (?). Wydaje mi się, że @kierepka też już takie hipotetyczne zjawisko sygnalizował w innym wątku, poszukam. |
|
Ponieważ w komentarzu #108 (comment) zaznaczono, że trzeba poszukać osób znających się na rzeczy napisałem do: EEF, Security Affairs. To są osoby/organizacje - zawodowo zajmujące się bezpieczeństwem. Zobaczymy jaka będzie odpowiedź. ps. jak podało #Google i #Apple : Even Apple and Google admitted in a press call earlier this week that no technology is “unhackable.” |
Faktycznie ciekawe i może zrealizować pewne scenariusze "ataku". Myślę że warto by było to skonsultować z Twórcami API jak tylko opublikują swój protokół i jakie zabezpieczenia (na poziomie systemu) przewidują. Widzę że już zarówno @kierepka jak i @Dr-Kownacki się zajęli komunikacją wtym zakresie - poczekam na wyniki tych rozmów żeby sobie nie strzępić języka na tematy w których ekspertem nie jestem. Poczekam też na szczegóły rozwiązania G+A. Dodam tylko że na pewno twórcy protokołu są świadomi problemu i jest spore prawdopodobieństwo że już dawno zaimplementowali rozwiązanie.. Akurat w rozwiązaniu G+A nie było opisane jaki będzie mechanizm generacji BT-ID w szczegółach, ale zakładam że będzie uwzględniał podobne mechanizmy (ale bez niepotrzebnego szyfrowania) jak zaproponował @Dr-Kownacki w swokim rozwiązaniu. Wystarczy żeby 6-8 bitów z (32-bitowego) ID publikowanego przez protokół G+A zawierały np. hash z najbliższych Cell ID widzianych przez telefon albo właśnie hash z "lokalizacji" komórki zebranej z GPS. To będzie działało dokładnie tak samo jak to, co proponował @Dr-Kownacki (o którym sam pisał że jest "absolutnie odporne" na tego rodzaju atak). Jeśli tak będzie to (parafrazując słowa @Dr-Kownacki A+G 1:0 Dr-Kownacki 0 - bo według mnie nie spełnia podstawowych założeń o czym już pisałem w #102 ) |
|
Jeszcze takie, być może ciekawsze nawet (?) rozwiązanie sprzętowe odnalazłem: Oczywiście jest SDK i kilka wersji hardware'u od tej firmy. @potiuk działamy tutaj na wysokim poziomie abstrakcji (a ja jako amator tym bardziej jeszcze większym) , ale i tak "przegrać z Google" to jak wygrać dla takiego lamera jak ja ;-) Myślałem o logu jakimś z BTS również, ale to by miało chyba tylko sens jeżeli wszyscy mieliby tego samego providera bo osoba z PLUSa będzie miała chyba coś zupełnie innego niż osoba z ORANGE. Dlatego ten ew. pomysł z GPS... Dodatkowo jakby ktoś tutaj był od GPS ekspertem to przecież tam "niskiego poziomu" to dopiero są świetne "ukryte" źródła do synchronizacji jak nazwa/numer satelity i ta "poprawka/różnica czasu" bo pewnie to są liczby które cały czas się zmieniają więc trochę jakby generator klucza też mogłyby służyć. |
Tak naprawdę to się dzieje samo pod spodem i Cell ID/WiFi są odpowiednio mapowane do lokalizaci. Nie potrzeba używania GPS żeby znać przybliżoną lokalizację FINE/COARSE i które można po prostu użyć. Nie ma co rozwiązywać problemu który już przez programistów Apple i Google został dawno rozwiązany: Tu video, które wyjaśnia różnicę:
FINE LOCATION = GPS wymaga dodatkowych uprawnień od aplikacji. Aplikacje zgodnie z wytycznymi komisjii europejskiej #98 (comment) pobieranie lokalizacji i użycie jej czymś co jest odradzane. COARSE_LOCATION i jej zanonimizowanie jako źródło "zabezpieczeń" jest w tym kontekście na pewno dobrym pomysłem (na przykład lokalizacja z dokładnością do 1-2 km), Dodatkowym utrudnieniem jest lokalizacja wewnątrz budynków - GPS się do tego nie nadaje.
Eksperci od GPS zaimplementowali już wszystko na pozime OS (i niekoniecnie z GPS - czas i inne dane są pobierane głównie na poziomie sieci GSM). Usyskanie połączenia z GPS w większości nie zadziała wewnątrz buidynków, więc użycie GPS-a odpada na wstępie również z tego powodu.
Dajmy szansę ludziom z Google i Apple - oni to robią od 15 lat. Naprawdę wydaje mi się że próbuje Pan odkrywać koło na nowo nie mając często podstawowej wiedzy w temacie. |
Nie za dużo próbujecie śledzić? Był już GPS, teraz są BTSy? Może jeszcze triangularyzacja? Projekt należy zsabotować, ponieważ nie ma tutaj mowy o prywatności. Co chusteczka (t-issue) to propozycja naruszenia tego co powinno zostać nienaruszalne. |
GPS - jak pisałem - to słaby pomysł.
Obiema rękami się podpisuję pod tym, żeby sabotować projekt jeśli będzie naruszał prywatność. Dlatego dobrze by było uzyskać odpowiedzi od @MateuszRomanow w #104. To co jest powyżej to na razie dyskusja jak rozwiązać problem z potencjalnym atakiem. I chwilowo nie wiemy jak to zrobi protokół G+A więc sabotowanie tego z góry jest mocno przedwczesne. Skupiłbym się najpierw na tych (na razie brakujących) odpowiedziach a szczegóły protokołu G+A omówimy jak już się pojawią (połowa maja najpóźniej). Jeśli weźmiemy pod uwagę że to co jest opisane m.in w #110 jest założeniem błędnym (czyli że identyfikatory są faktycznie anonimowe i przechowywyane w komórce) To dodanie bardzo zgrubnej informacji o położeniu nie wydaje się złym pomysłem. Ale może uda się znaleźć lepsze rozwiązanie. |
|
Przebywające w swoim otoczeniu telefony/aplikacje w momencie wykrycia ryzykownego kontaktu mogły by zacząć wzajemnie rozgłaszać części tymczasowych kluczy swoich koleżanek i kolegów. Zakładając, że da się to szybko zrobić, to nastąpi synchronizacja poprzez potwierdzenie ryzykownego kontaktu poprzez to, że Bob rozmawia z Alice, a Alice zauważyła Boba i oboje blisko siebie rozmawiają, o czym zaczęła rozgłaszać, co z kolei Bob również zauważył (i robi tak samo względem Alice). A Bob i Alice to tymczasowe ksywki Janusza i Grażyny. Bez ustanawiania połączenia BLE jako takiego. Bez globalnej/bezwzględnej lokalizacji. |
|
@matsobdev |
|
Nie, nie. Chodzi o taki kontakt, który umożliwia zarażenie się. Apka loguje te pary, ktoś choruje, idzie do lekarza itd. klucz zarażonego i klucze czy ich fragmenty osób, z którymi był w kontakcie są wysyłane na serwer, inni je pobierają - taki sam zestaw. Potem te pary są już nieaktualne i nie ma co nimi handlować. Tak jak mniemam będą to wszystkie pseudonimy zarażonego określone w czasie przez lekarza - kiedy zarażał połączone z jednym pseudonimem każdego, w którym bym w kontakcie. Ci którzy go spotkali (zarażonego), będą szukać u siebie, czy w tym czasie występowali pod tym jednym pseudonimem i mieli kontakt z gościem, który przedstawiał się jednym z wielu pseudonimów. |
|
@matsobdev Czyli mielibyśmy jakby ,,podwójne rozgloszenie", czyli np. możnaby wykorzystać wtedy ten mój lamerski sposób żeby to o czym piszesz rozgłosić w BLE "nazwie urządzenia" na przykład ? I wtedy RSSI musiałyby się też zgodzić - jeśli TAK to jest OK, a jeżeli nie to podejrzewamy "teleportację do izby przyjęć szpitala zakaźnego" ;-) Jedyny szkopul w tym że (podobno) mamy nie mieć dostępu do wiedzy co/jaki klucz sami w danym momencie rozglaszamy co z dużą pewnością poruszono w wątku #108 przy mojej propozycji aby QR-kod zawierał klucz..: |
Jeśli nie będzie takiej możliwości, to można by im zaproponować taki kształt działania, jeśli oczywiście miałby on jakikolwiek sens - niech wypowiedzą się też inni. Też jestem lamer :D
Ja bym w jednej ramce zarezerwowaną przestrzeń na to miał i cyklicznie, tyle ile osób mam w bliskim zasięgu, co np. 100 ms po jednym kluczu po kolei rozgłaszał, potwierdzającym, że o "was" wiem. Krytyka mile widziana. Co do Twojego pytania, to pewnie tak. To właśnie miało być moje lamerskie rozwiązanie sprzed kilku lat. |
Tu chyba niestety niezrozumienie. Telefon nigdy nie wie czy kontakt jest ryzykowny w momencie kontaktu. Telefon przechowuje historię kontaktów i jeśli (w przyszłości) te kontakty okazały się chore (potwierdzone diagnozą) - dopiero wtedy jest ustawiony status "zagrożony" jeśli kontakt z takimi "chorymi" kontaktami trwał wystarczająco długo/blisko. Chyba że czegoś nie rozumiem ? |
Ryzykowny w sensie jak na obrazku Estimote: 5 metrów trzy sekundy ok, metr 15 minut - ryzykowny = dający możliwość transmisji wirusa w przypadku, gdyby ktoś był zarażony. Dobrze rozumiem, że API wiadomo jakie zmierza w kierunku tego, że matchować będzie w chmurze? To wtedy wychodzi na to, że ja bym przeniósł je lokalnie na telefon. |
Ok. O ile rozumiem (sparafrazuję to swoim rozumieniem) . Wszyscy przechowują wszystkie pary a) swoje id + obce id. I zarażona osoba wysyła te pary na serwer. Wszyscy inni ściągają te pary i porównują ze swoimi, Pomijając to że nie znamy ID, to że wysyłamy spotkania na serwer to już jest słabe "prywatnościowo" - choć było by możliw jeśli faktycznie by to zanonimizować, to już niestety się nie skaluje. O ile w rozwiązaniu A+G na serwer wysyłane są tylko DTS osoby zarażonej to w Twoim trzeba wysłać listę wszystkich spotkań danej osoby. I wszystkie ściągać przez wszystkich, Zakładając dziennie 5.000 osób zarażonych mamy zamiast 5.000 - 500.000 (dziennie) kluczy do przetworzenia (zakładając 100 kontaktów dziennie) i pobrania. I w żaden sposób nie zabezpiecza przed atakiem jeśli on działa tak jak to założono - czyli wszyscy w jednej lokalizacji widzą wszystkich w drugiej lokalizacji (a tak podobno działa to urządzenie o którym mowa). Zakładając że ten atak można przeprowadzić w taki sposób jak opisał @Dr-Kownacki (czekamy na opnię ekspertów bo na razie to spekulacje) będzie to wyglądało tak jakby te wszystkie osoby po obu stronach "hackujących" urządzeń stały koło siebie. Więc niestety wysylanie sąsiadów nic nie da - bo to działa w obie strony. |
Nie to właśnie Twoje rozwiązanie przenosi dane do chmury. API G+A matchuje wszystko na telefonie. Telefon osoby zdrowej ściąga wszystkie DST osób zarażonych i sprawdza w lokalnej bazie czy ich nie spotkała. W chmurze są tylko i wyłącznie DST osób zarażonych. nie ma żadnych danych na tmat kontaktów. Polecam lekturę : https://www.apple.com/covid19/contacttracing - to są naprawdę krótkie dokumenty które wszystko wyjaśniają. |
Sorki, miałem na myśli, że robota jest wykonana na telefonie, ale to też tak będzie w przypadku Google i Apple. Mój błąd |
Bardziej istotne jest, że w twoim rozwiązaniu historia kontaktów jest wysyłana na serwer. W rozwiązaniu G+A nie ma w ogóle historii żadnych kontaktów - nigdy. Są tylko identyfikatory osób zdiagnozowanych (i to tylko ich dzienne klucze a nie identyfikatory którymi się rozgłaszalli). Naprawdę polecam tę lekturę. |
|
Panowie i Panie, rozumiem, ze temat contact tracingu jest istotny z punktu widzenia informacji publicznej, ale czy to jest wlasciwe miejsce do dyskusji na temat technologii, na ktorej forme nie mamy zadnego wplywu z poziomu organizacji ProteGO-Safe? Zostawiam was z ta mysla i prosze autora @Dr-Kownacki o rozwazenie czy temat jest juz wyczerpany a jesli nie o przeniesienie go w odpowiednie do tego celu miejsce. Proponuje stackoverflow :) |
|
Jeśli mógłbym zasugerować jednak jeszcze możliwość dalszej dyskusji tutaj to byłbym @qLb niezmiernie wdzięczny, jeśli nie miałbyś nic przeciwko temu, wobec poniższej argumentacji: W moim (zaznaczam zapewne ułomnym i naiwnym) przekonaniu konkretnie w ostatnich komentarzach zaczęliśmy hipotetycznie finalizować pewien ciekawy model, który mógłby postulowany tutaj problem pokonać być może z poziomu aplikacji. Dlatego jak napisano powyżej w można byłoby tutaj jakiś hipotetyczny pasywny kanał zwrotny jako zabezpieczenie dopracować bez wpływu na samo (oczekiwane) API. Ponieważ jest chyba nadal bardzo wiele niewiadomych na temat rozwiązania G+A, to czy musimy zakładać że będzie to rozwiązanie typu "black box" i z żadnej warstwy aplikacji nie będzie można np. "nie przyjąć" klucza który z jakiegoś powodu aplikacja uznałaby po prostu za nieprawidłowy ? Czy powinniśmy z góry na obecnym etapie taką możliwość całkowicie odrzucić i zamknąć wątek na dobrych kilka tygodni przed uzyskaniem pełnej wiedzy i przed publikacją rozwiazania G+A ? Stąd przedstawiam pod rozwagę jak na początku, mając nadzieję na pozytywne rozpatrzenie mojej propozycji :-) |
|
@Dr-Kownacki oczywiscie - do momentu kiedy trzymamy sie meritum nie mam nic przeciwko. Sugerowalem tylko by ta dyskusje otworzyc na forum, ktore moze miec rzeczywisty wplyw na dostarczone rozwiazanie tj. Google lub Apple. O ile z Apple prowadzenie otwartego dialogu jest praktycznie niemozliwe - o tyle z Google mogli bysmy przeniesc sie z tym tematem na ich community forum. Moze tam jest ktos kto fizycznie pracuje nad tym rozwiazaniem i moze pomoc nam w klaryfikacji zalozen. Czy to co postuluje ma sens? |
|
PS. Szanuje wasz wklad i doswiadczenie, pomyslowosc i otwartosc ale czuje, ze tracimy energie na czyms czego empirycznie nie jestesmy w stanie zbadac. Jak wiec dojsc do obiektynych dowodow naukowych i konkluzji skoro niemozliwe sa zadne eksperymenty? W ten sposob nie dojdziemy nigdy do zadnych dowodow naukowych w tym zakresie nie wspominajac o w/w dowodach obiektywnych. |
|
@qLb bardzo dziękuję i będziemy na pewno starali się trzymać ścisłego meritum postawionej tu hipotezy :-) Jeśli chodzi o inne fora to wiem że @kierepka poruszył już temat w kilku miejscach bo ma ku temu kompetencje zawodowe, których mi niestety brakuje :-) Ad.P.S. Ja na przykład nie potrafię programować stąd chyba jakoś lepiej niż teraz nie mógłbym aktualnie spożytkować energii dla "sprawy ProteGo Safe", której bardzo kibicuję. Wiem, że to co tutaj omawiamy/wymyślamy to, póki co, czysta abstrakcja i hipotezy ale jest na pewno wiele zagadnień nawet czysto naukowych chociażby z fizyki, które po bardzo długim czasie zostały udowodnione w praktyce. Więc to jakby to samo ale na mikro skalę ;-) Jeżeli natomiast mógłbym np. jakoś "jako lekarz" Was wesprzeć dołączając do wspomnianej dzisiaj w innym wątku oficjalnej grupy supportu medycznego/prawnego/branżowego to oczywiście proszę na mnie jak najbardziej liczyć. Ponadto z uwagi na sprawowane funkcje, mógłbym się też zrealizować przy jakimś wczesnym beta-testowaniu w "warunkach szpitalnych", do czego mógłbym zaprosić pewnie liczne grono personelu medycznego. Aspekt przydatności aplikacji dla personelu jest mi szczególnie bliski i moje zainteresowanie tematem tak duże, ponieważ chociażby relacje propagacji RF są w warunkach szpitalnych bardzo szczególne. Niewiele osób chyba o tym wie jakie są wyzwania czasami. |
|
@qLb -> ja akurat też chęnie się włączę (w ramach ograniczonego czasu - generalnie na 100% albo nawet 150% staram się uczestniczyć w swoim projekcie dzięki któremu 6 osób na full time pracuje z dużym międzynarodowym klientem i dzięki temu robimy spory export usług i mamy stabilne źródło przychodu (podatki dla kraju, utrzymanie działalności firmy) - w obecnych czasach myślę że to bardzo cenne. Za to mogę robić code review, komentować rozwiązania zwłaszcza jeśli chodzi o wykorzystanie API w kontekście prywatności. Jeśli będą jakieś pomysły w których prywatność jest naruszona mogę pomóc. Chcialem to zaproponować i mam na to odrobinę czasu w nadchodzących tygodniach - czekam cały czas na odpowiedź @MateuszRomanow w kwestii tego jakie są plany na ten temat - jeśli to było by potrzebne. Moje pytania - zgodnie z prośbą @MateuszRomanow ponumerowałem i już od 2 dni czekam na odpowiedź. #104 (comment) Jeśli naprawdę chcecie żeby wam pomóc - to ja chętnię zrobię to jak wyżej (anonimowy fork Blue Trace). Możecie mieć to za free. Tylko muszę wiedzieć że to jest w planach. Dodam jeszcze - nie będę tego robił sam. Myślę, że poproszę grupę programistów których znam dobrze i którzy są super doświadczeni w IOS/Android i taki projekt mogę poprowadzić. Myślę że parę dni i będziemy mieli wersję anonimową BlueTrace. |
|
@Dr-Kownacki - skontaktuje sie dzis z PM'em w odniesieniu do pomocy medycznej. Jak tylko dostane zgode postaram sie dolaczyc Cie do grupy beta-testerow. @potiuk Wlasnie wysylam do Ciebie maila stay tuned. |
|
All, mam pytanie, od kilku tygodni robicie deep dive, pójdźcie w ślady APAC, oni wzięli WeChat w pare dni powstał bezpieczny covid plugin, weźcie GaduGadu macie z bani całe security. Stay Safe. Pitt |
|
@Dr-Kownacki. Znalazłem w końcu chwilę czasu i zagłębiłem się w zaktualizowaną specyfikację Apple + Google. https://www.apple.com/covid19/contacttracing/. I mam kilka ciekawych spostrzeżeń. Pytałeś (pozwolę sobie przejść na Ty bo nie lubię "panować") o sekwencję "ASCII" wysyłaną w tym protokole. Może nie tyle ASCII ale w https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf jest już dość dokładnie opisana zawartość (tak to się nazywa Advertsing Payload:
W dokumencie jest nieco obszerniejsze wyjaśnienie rozkładające to na poszczególne bity. Co prawda chyba nie ma w tym protokole (jeszcze) żadnych zabezpieczeń przed tego rodzaju atakami, ale jest tam miejsce (i zarezerwowane bajty danych) które na to pozwolą i to w bardzo ciekawy sposób. Mianowicie są tam 4 bajty "Associated Encrypted Metadata". Obecnie jest tam 1 bajt z numerem wersji, 1 bajt "transmit power level" i 2 bajty zarezerwowane na przyszłość.
Ale o wiele ciekawsze jest to, że te dane są zaszyfrowane. I to w bardzo ciekawy sposób. Jak opisano w https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-CryptographySpecificationv1.2.pdf do zaszyfrowania tych danych użyto zarówno Temporary Exposure Key (klucz który potem może być wysłany do serwera jeśli osoba chora zostanie zdiagnozowana) jak i RPI (Rolling Proximity Indentifier). I nie można tej informacji odszyfrować bez obu tych wartości. To znaczy że żeby odszyfrować te dane trzeba: a) odebrać ten "advertisinig payload" od osoby (w przyszłości) chorej - czyli być blisko No i tu parę ciekawostek:
Podsumowując:
Myślę (ale to oczywiście tylko spekulacja) że w następnej wersji protokołu G+A dodadzą jakieś zabezpieczenie w tych bajtach. Na razie zapewne kombinują jak to zrobić żeby nie była to de-facto informacja lokalizująca, tak żeby to nie było łatwe do zgadnięcia i wykorzystania a jednocześnie żeby osoby będące blisko siebie w danym czasie miały tą wartość taką samą. Myślę że najbardziej prawdopodobna możliwość to HASH (nie haszysz ;) ) zgrubnej lokalizacji zmiksowanej z czasem. Dla niewtajemniczonych - hash to jest taki "skrót" informacji - ciąg znaków który zmienia się jeśli informacja się zmienia, ale jest dużo krótszy niż sama informacja. I może się powtarzać dla różnych danych ale w większości algorytmów do generacji hash-a może on działać praktycznie tylko w jedną stronę. daje nam to że nie znamy dokładnej lokalizacji - bo wiele lokalizacji na świecie może mieć ten sam hash. Użycie czasu moźe zapewnić że te hashe co 15 minut będą się zmieniały - i to w taki sposób że te same lokalizacje w różnych okienkach czasowych będa miały różne hashe Takie rozwiązanie było by w pełni anonimowe, nie dawało by żadnej informacji na temat konkretnej lokalizacji i było by w pełni odporne na "streaming" attack. W międzyczasie spróbuję ten pomysł i opis ataku (oraz rozwiązanie) zgłosić do Google + Apple. Podejrzewam że już nad tym pracują od jakiegoś czasu ale warto im może to jednak zgłosić. @Dr-Kownacki -> mam nadzieję że to odpowiada na Twoje wątpliwości. |
|
@potiuk bardzo dziękuję za czas który poświęciłeś na zgłębienie nowych informacji z ver.1.2 dokimentacji i przystępne wytłumaczenie zasady działania oraz pomysłu na "uszczelnienie" tego systemu. Rzeczywiście ten zaproponowany przez Ciebie hash byłby niezłym pomysłem a te "wolne-niewykorzystane" (jeszcze) bajty etc. danych są nadzieją na pasywny "kanał zwrotny/wzorzec porównawczy" pomiędzy dwoma urządzeniami poprzez porównanie czy są rzeczywiście w tym samym fizycznym miejscu, tak jak amatorsko hipotetyzowałem w wątku powyżej. Natomiast teoretycznie przesłanie lokalizacji "coarse" jakby do tego hipotetycznego "gorącego-zakaźnego" miejsca byłoby ewentualnie możliwe (to już czysta hipoteza) na takiej zasadzie jak działają po prostu access pointy/repeatery GSM ? Ale to już się chyba robi na tyle skomplikowane że może bezużyteczne bo ten telefon "dawcy za chwilę zakażonych kluczy" (pacjent na izbie przyjęć szpitala zakaźnego) musiałby zostać przekierowany do jakiegoś emulowanego źródła informacji które tę "coarse" lokalizację by emulowała (?). Ale to się już robi duża liczba zmiennych, bo ta informacja chyba może pochodzić z a) GPS, b) GSM, c) Wi-Fi, a przy założeniu że telefon "dawcy" byłby zalogowany do sieci GSM to najpierw trzebaby ją zagłuszyć etc. itp. więc robi się o bardzo skomplikowana akcja chyba...Mission Impossible i zupełne wariactwo do pominięcia tego. Natomiast przy "coarse" to chyba i tak opisywaną tutaj metodą można by "zakażać" jednak wokół po prostu "całą okolicę izby przyjęć szpitala zakaźnego", czyli tam gdzie coarse lokalizacja byłaby taka sama jak potencjalnych "źródeł zakażenia" chyba że jeszcze RSSI to jakoś (jak teź wcześniej hipotetyzowałem powyżej) mogłoby "uszczelnić" dodatkowo. BTW: |
Proszę bardzo. Poza doświadczeniem inżynierskim mam również biznesowe/sales support/CTO a nawet byłem głównym organizatorem konferencji (https://mceconf.com) więc wiem że to tłumaczenie wszystkiego w jasny i zrozumiały sposób jest ważne żeby nasze inżynierskie spojrzenie przekazać innym. To właśnie spróbowałem zrobić w https://blog.kurasinski.com/2020/05/protego-safe-dlaczego-nie-nalezy-instalowac-aplikacji-ministerstwa-cyfryzacji/
Spróbuję, Jak tylko się ogarnę ze wszystkim co się przez te parę dni nagromadziło. Dalej na 100% pracuję przy swoim projekcie :)
No i fajnie że te dane są w taki właśnie sposób szyfrowane jak opisałem.
Dokładnie - zwłaszcza jeśli hash by się zmieniał co 15 minut i dwa miejsca mogły by mieć taki sam hash najwyżej w jednym 15 minutowym okienku a potem by się to losowo zmieniało.
No właśnie nie - tu właśnue ten sprytny mechanizm szyfrowania jest super. Nawet gdyby atakujący próbował zmodyfikować taką lokalizację w locie - nie zna Temporary Exposure Key - więc nie wie jak zaszyfrować te dane. Świetnie to jest pomyślane, naprawdę. Tam pracują super łebscy goście.
Włąśnie bez tego Temporary Exposure Key się w ogóle nie da. A on opuszcza telefon dopiero jak ktoś jest zdiagnozowany jako chory. Atakujący nie wie jak zaszyfrować takie emulowane dane. Szach-mat.
No właśnie ciekaw jestem co Google + Apple wymyślą. moja metoda z hashem ma pewne ograniczenia ale jeśli trochę więcej algorytmiki i matematyki zastosujemy to może się dać coś z tym zrobić. Chodzi o to żeby w miarę bliskie kontakty mogły to potwierdzić niezależną od BT metodą że były blisko siebie. zobaczymy co wymyślą inżynierowie.
Dokładnie.
Na razie ta część (wysyłanie) nie jest podobno zaimplementowana. Kod jest obszerny i nie byłbym w stanie sam go przejrzeć na tyle żeby być pewnym, ale z opisu działania aplikacji ma być tak że na serwer wysyłane są włąśnie "spotkania" . Może @qLb albo @MateuszRomanow raczą wyjaśnić (a najlepiej opisać w specyfikacji)
Mam nadzieję. Na razie trzeba było kilkukrotnie wymuszać na MC żeby dotrzynywało obietnic. Może tym razem zrobią to sami bez wymuszania. Ale to że chcą wprowadzić QR-cody i wstawić kioski do Galerii Handlowych świadczy o tym że nie mają zamiaru przejść na API G+A - bo w tym API się tego nie da zrobić.
Ja się przyznam że też się zgubiłem bo działania, plany, deklaracje nie są w żaden sposób spójne między sobą. Co innego jest w deklaracjach, co innego w planach a działania pokazują jeszcze co innego. Mam nadzieję że @qLb i @MateuszRomanow nam to wkrótce jasno i przejrzyście wytłumaczą.
Tak. Braków, niedomówień, nieścisłości a nawet jawnych nieprawd jest w tym projekcie sporo.
|
|
Temat handlu może być aktualny, bo taka osoba zarażona, która już coś czuję, może chcieć na tym zarobić. Za opłatą może udostępniać swoje RPIs, które będą rozgłaszane do czasu jej badania (jak schemat z QR i galeriami). Trzeba kontrolować polski darknet. |
|
@Dr-Kownacki @potiuk Albo jak wcześniej zasugerowałem, dwubajtowy hash z RPI zaobserwowanych z otoczenia. I tak kontakt zaraźliwy będzie rzędu minut, licząc 4-5 (jak w specyfikacji) paczkach na sekundę to będzie dużo paczek. Jeśli masz dostęp do Google/Apple, to też to im zaproponuj. |
Ciekawy wektor ataku - faktycznie :) Uzytkownik co prawda nie wie jakie będzie miał RPIs "z góry" . nie ma do tego dostępu. Może co najwyżej wiedzieć jakie RPI w tym momencie jego aplikacja wysyła i pieczołowicie je zbierać. Owszem, można to zautomatyzować - RPI "z rana" publikować gdzie indziej "po południu". Hash z czasu i w jakiś sposób określanej "okolicy" skutecznie by to zablokował. I myślę że czas będzie tam dodany gdzieś. Pomysł z "kilkoma kontaktami" jest ciekawy ale może być trudno zapewnić że faktycznie widzimy w danym momencie te same RPI. W BT jest tak że to może fluktuować, więc to może być trudne w ten sposób. Myślę że serio - nie trzeba im tego podrzucać. Sami kombinują i testują co może zadziałać. Te pola "Reserved" o tym świadczą. Myślę że dużą trudnością jest to że mówili że faktycznie nie będzie przekazywania informacji o lokalizacji, a umieszczenie nawet hasha może już za takie być uznane. Dajmy im jeszcze chwilę :) |
|
Nie ma co im tego podsyłać, a sam o tym wspominasz :D hehe Tylko się śmieję, bo lubię. |
|
No skoro nadarzyła się okazja, to skorzystałem :). |
|
przepraszam jeśli było(nie czytałem całego wątku) ale czy coś stoi na przeszkodzie żeby każdy pakiet uwierzytelniać HMAC ? Czyli zamiast dotychczasowego pakietu w formie: |
Niestety pakiety są przesyłane na poziomie OS. wpływ można mieć tylko na "Payload" w ramach "Advertising info". A z resztą to nic by nie pomogło, bo tu chodzi o atak w którym ktoś po prostu "teleportuje" (za pomocą odpowiednich urzadzeń) rozgłaszane "advertising info" z miejsca o "wysokim prawdopodobienstwie kontaktu" do miejsca o "niskim prawdopodobieństwie kontaktu" . Więc tu chodzi o połączenie czasu i miejsca tak naprawdę. Ale faktycznie - atak jest czysto teoretyczny i być może nie będzie on "rzeczywistym" zagrożeniem po analizie ryzyka, więc być może podjęte będą decyzje żeby nic z tym nie robić. |
|
@potiuk z @Dr-Kownacki tak szybko jak przyjdzie do niego zamówiony sprzęt wykonamy odpowiednie testy by sprawdzić - jako, że zgłaszaliśmy te uwagi jako pierwsi i wtedy była mowa o braku możliwości realizacji ich. Jak będziemy wiedzieć jak wyszły testy damy znać. |
|
Zdaje się, że nie będzie możliwości skorzystania z GPS: |
|
@adrb : tak takie złożenia są, trochę to dziwnie wygląda na tle (aktualnie na Androidzie) włączania GPS i BT razem :-) Cyt.: Apps must be created by or for a government public health authority and they can only be used for COVID-19 response efforts. Apps must require users to consent before the app can use the API. Apps must require users to consent before sharing a positive test result with the public health authority. Apps should only collect the minimum amount of data necessary and can only use that data for COVID-19 response efforts. All other uses of user data, including targeting advertising, is not permitted. Apps are prohibited from seeking permission to access Location Services. Use of the API will be restricted to one app per country to promote high user adoption and avoid fragmentation. If a country has opted for a regional or state approach, Apple and Google are prepared to support those authorities. |
|
@Dr-Kownacki
Aprpo, jeżeli w większości urządzeniach BLE nie można samemu ustalać Advertising Adress a jedynie wymusić jego ponowne wygenerowanie (nie mam doświadczenia z niskopoziomowym programowaniem BT więc ciężko mi to określić), to można spróbować dodać do pola AEM coś w rodzaju sumy kontrolnej policzonej z Advertising Adress urządzenia nadającego ramke. Nie rozwiąże to problemu, ale znacząco go utrudni i z marszu wyeleminuje amatorów. |
Ani z GPS ani z BT. Jak to opisywałem już wcześniej #132 (comment) Aplikacja rządowa korzystająca z Exposure Notification, w ogóle nie musi mieć żadnych innych uprawnień niż tylko "Exposure Notification". Exposure Notification stanie się nową "usługą systemową" dostarczaną przez system/PlayServices. I dostęp do BT jest tam realizowany na poziomie tej usługi systemowej a nie samej aplkacji. I to jest świetna wiadomość bo to natychmiast zabija wszystkie aplikacje rządowe, które chciały by zaimplementować zarówno A+G jak i "bokiem" swoje rozwiązanie. Mam nadzieję że docelowo zmieni to podejście w tych dwóch (scentralizowanych) apkach w których (w przeciwieństwie do Polski) nie było wystarczająco głośnych protestów społecznych:
|
|
Dodam jeszcze że wydaje się że da się dość prosto w tej docelowej wersji A+G (w systemie) zaimplementować podejście "federated" - to znaczy że apka będzie działała transgranicznie. I to będzie kolejny argument żeby UK + Czechy się też przestawiły na G+A. |
|
Być może nie wszyscy śledzą #134, więc dodam również i tutaj dla kompletności informację, że atak nie jest już czysto teoretyczny. Narzędzie które jest w stanie zademonstrować go w praktyce: |
|
"Moment w którym hack wyprzedził rozwiązanie" BTW: A jak/czy to "chodzi" z aktualną wersją ProteGO Safe ? |
W tym momencie tylko A+G. Nie jestem pewien czy chce dodawać ProteGO-Safe, biorąc pod uwagę, że jest to aplikacja aktywnie |
|
Mały update.
|
Dwa dni, to już odgrzewanie... Między innymi ta apka, ale ona nie kopiuje 1:1, sama o tym mówi, że tam jeszcze coś w stylu sprzętowo-systemowo zależne rzeczy będą wygenerowanie i tak automatycznie, choć tutaj pewnie wystarczy UUID, po którym beacony są filtrowane i skojarzony z nim payload |
|
Z powodu dłuższej nieaktywności w tym wątku, Jeżeli ktoś ma coś przeciwko to niech da znać, lub założy wątek zgodny z obecnymi założeniami |
|
Wątek jest jak najbardziej AKTUALNY, natomiast nie mamy żadnego feedbacku od Google/Apple w tej sprawie za pośrednictwem autorów aplikacji ani żadnym innym niestety jeszcze. Inne źródła również podają że taka podatność potencjalnie istnieje - nie wiemy czy/jakie kroki podjęto aby wyeliminować podobnie zagrożenie, jednocześnie w niniejszym wątku wskazano ewentualne rozwiązania problemu "w warstwie aplikacji". Uważam zatem że wątek należy utrzymać z powyższych powodów. |
|
@Dr-Kownacki ok nie ma problemu ;) wątek zostaje otwarty |
Przenoszę tutaj c.d. dyskusji o potencjalnej podatności rozwiązania API G+A z poniższego wątku. #108
Tam dyskusja nieoczekiwanie odbiegła od tematu QR, ale moim i @kierepka zdaniem zeszła na bardzo istotny aspekt dot. bezpieczeństwa.
Szczegóły w #108 - w skrócie chodzi o potencjalnie możliwe (?) klonowanie/streaming on-line/etc. rozglaszanych chwilowych kluczy z innych geograficznie lokalizacji z wysokiem ryzykiem obecności zakażonych osób (przykład: izba przyjęć szpitala zakaźnego).
Przypuszczalnie jedynym zabezpieczeniem systemu API G+A przed takimi hipotetycznymi atakami, byłoby wprowadzenie lokalizacji GPS do algorytmu aplikacji i obliczanie jakiegoś CRC żeby takie klucze po prostu "geograficznie" eliminować.
(ale co jeśli ktoś "podmieni" ten kod CRC/GPS...)
Najlepszym rozwiązaniem byłoby chyba eliminowanie "teleportowanych/hackowanych" kluczy ad hoc po GPS przez aplikację LOKALNIE, która by je ignorowała.
CRC/GPS byłoby tylko "chwilowo" porównywane LOKALNIE ("mój" vs "usłyszany") i znacznik NIE BYŁBY NIGDY PUBLIKOWANY NA SERWERZE.
Moim zdaniem rozwiązanie tego problemu jako "nakładka" na system z API może być bardzo trudne - ale być może wykonalne, to już pytanie do zawodowców.
@MateuszRomanow : czy masz ew. możliwość uzyskania wstepnej opinii na temat tej potencjalnej luki (?) od niebezpiecznik.pl ewentualnie adekwatnych osób z MC ?
The text was updated successfully, but these errors were encountered: