Audyt bezpieczeństwa i prywatności Exposure Notification

[SeraMoon]

Is your feature request related to a problem? Please describe.
#141 #135 #145 #146 #129 #191

Describe the solution you'd like
Niezależny polski ekspert (np. Niebezpiecznik) dokona audytu modułu oprogramowania w oparciu o otwarty kod źródłowy rozwiązania Exposure Notification, potwierdzając tym samym, że kod wykonuje tylko to do czego został stworzony, zaś chwilowe diagnosis key nie są agregowane nigdzie z jakimkolwiek innym identyfikatorem lub danymi pozwalającymi stwierdzić kim jest jego posiadacz.

Describe alternatives you've considered
W przypadku braku pozytywnego wyniku audytu - rozwój własnego protokołu do Contact Tracingu.

Additional context
\x00

[potiuk]

Tak jak pisałem w #189 (comment) dziś wziąłem udział w spotkanu (dzięki Panoptykonowi i na ich zaproszenie) z zespołem w Google odpowiadającym za kontkakty z organizacjami NGO w zakresie "Contact Tracing".

Do spotkania zostałem doproszony dosłownie 10 minut przed więc nie miałem czasu nic napisać tiu - zadaliśmy trochę pytań i myślę że 50% naszego spotkania było poświęcone właśnie otwarciu kodu Exposure Notification.

Pokrótce czego się dowiedzieliśmy:

• Google twierdzi, że implementacja EN jest głęboko związana z "wnętrzem" systemu operacyjnego i używa rozwiązań, które wyłączają zabezpieczenia wbudowane w system (na przykład usypianie aplikacji które zbyt intensywnie korzystają z BT - tak jest w przypadku iOS, albo integracja z Play Services w przypadku Google). Dlatego pełne udostępnienie kodu do audytu w tej chwili jest trudne - jeśli nie niemożliwe bez dużej ilości pracy żeby te rzeczy rozdzielić.

Mój komentarz: Faktycznie to może być dobra argumentacja, ale myślę że w dalszej perspektywie tą pracę Google i Apple będą musiały (i będą mogły) wykonać tą pracę i otworzyć sporą część tego kodu..

• W tej chwili Google i Apple udostępniają rządom, które o to poprosiły, możliwość zaudytowania tego kodu "ręka w rękę" z inżyenierami z Google i Apple. Tak się już dzieje w przypadku niektórych rządów (z zastrzeżeniem ze nie mogę powiedzieć o które chodzi) ale nie ma na razie na tej liście Polski z tego co rozumiem (to znaczy, że nasz rząd na razie nie poprosił o to wystarczająco dobitnie). Ze względu na ograniczone możliwości czasowe, ta możliwość została udostępniona (na żądanie) rządom które albo już wypuściły aplikację, albo zaraz ją mają wypuścić. Google i Apple są bardzo zainteresowane w tym żeby ich rozwiązanie było tak bardzo "open" jak to możliwe i nie wykluczają (ale też nie commitują się do tego) że w przyszłości, kiedy potrzeby rządów które są użytkownikami API będą już mniejsze - w podobny sposób audyt kodu G+A bęðzie możliwy dla wybranych organizacji NGO które działają w obszarze prywatności i bezpieczeństwa.

Mój komentarz: Tak jak wielokrotnie już pisałem w ciągu ostatnich paru dni - to po stronie rządu teraz jest piłeczka żeby naciskać G+A na a) audyt b) docelowe jak największe otwarcie kodu. Jak widać rządy mają narzędzia do tego, żeby iść w tym kierunku i Google i Apple im to umożliwiają bo zależy im na tym, żeby ich rozwiązanie było jak najbardziej (w miarę możliwości na chwilę obecną) otwarte.

To tyle w temacie.

[SeraMoon]

Google twierdzi, że implementacja EN jest głęboko związana z "wnętrzem" systemu operacyjnego i używa rozwiązań, które wyłączają zabezpieczenia wbudowane w system (na przykład usypianie aplikacji które zbyt intensywnie korzystają z BT - tak jest w przypadku iOS, albo integracja z Play Services w przypadku Google). Dlatego pełne udostępnienie kodu do audytu w tej chwili jest trudne - jeśli nie niemożliwe bez dużej ilości pracy żeby te rzeczy rozdzielić.

Udostępnianie AOSP a tłumaczenie się, że WYŁACZA ZABEZPIECZENIA i dlatego tego nie zobaczymy to:

• krętactwo - w sytuacji gdy udostępnią część,
• ma to swoją nazwę w informatyce: Security by obscurity. Nie muszę chyba tłumaczyć z czym się je i jak profesjonalne to jest. Bezpieczeństwo "w głębokim ukryciu"...

Reszta działań Google przeczy wszystkim 7 filarom zaufania.

Dla mnie wystarczające otwarcie kodu będzie takie, że zadziała to na AOSP (i innych klonach) i również uda się z sukcesem posłużyć PIN-em (czyli zgłaszanie infekcji).

Czekam więc dalej na linki do działającego rozwiązania open source, które będzie można poddać audytowi.

[KoderFPV]

@SeraMoon
Rozumiem twoje postulaty ale to kolejny raz który w ciągu kilku godzin oskarżasz kogoś o krętactwo na tym forum jak tutaj #189 (comment)

@potiuk wyraźnie zaznaczył że nie możliwość udostępniania EN jako open source wynika z

Google twierdzi, że implementacja EN jest głęboko związana z "wnętrzem" systemu operacyjnego i używa rozwiązań, które wyłączają zabezpieczenia wbudowane w system (na przykład usypianie aplikacji które zbyt intensywnie korzystają z BT - tak jest w przypadku iOS, albo integracja z Play Services w przypadku Google). Dlatego pełne udostępnienie kodu do audytu w tej chwili jest trudne - jeśli nie niemożliwe bez dużej ilości pracy żeby te rzeczy rozdzielić.

Prace nad otwartością EN będą postępować z czasem.

[SeraMoon]

@Tarvald nazwałam po imieniu jak wygląda wycinanie fragmentów kodu z EN, by dać nam produkt EN2 do audytu, który już nie jest produktem EN.

Częściowy audyt (audyt części rozwiązania) nadal pozostawia produkt bez audytu. Audyt prywatności i audyt bezpieczeństwa (domagam się obu) jest przeprowadzany dla konkretnego rozwiązania - potrzebuję mieć możliwość samodzielnie (lub z pomocą pieniędzy i Niebezpiecznika oraz Panoptykonu) móc zaudytować produkt EN, nie EN2.

Owszem opcją jest rozwiązanie EN2, ale wtedy o ile będzie działało wchodzi w grę używanie tylko na rootowanym telefonie z Androidem kompilowanym z AOSP lub projektami pochodnymi, które zawierają opublikowany kod Exposure Notification.

---

Przepraszam za pomyłkę w nazewnictwie / pojęciach.

[MateuszRomanow]

Mój komentarz: Tak jak wielokrotnie już pisałem w ciągu ostatnich paru dni - to po stronie rządu teraz jest piłeczka żeby naciskać G+A na a) audyt b) docelowe jak największe otwarcie kodu. Jak widać rządy mają narzędzia do tego, żeby iść w tym kierunku i Google i Apple im to umożliwiają bo zależy im na tym, żeby ich rozwiązanie było jak najbardziej (w miarę możliwości na chwilę obecną) otwarte.

@potiuk temat otwartej rozmowy z Google i Apple w tym obszarze jest dla nas ważny, dlatego jak wspominałem, pilotowałem żeby Ministerstwo Cyfryzacji formalną drogą było w kontakcie. Poprosiłem o ska tego co zostało wysłane. Poniżej list napisany i wysłany w tej sprawie przez Ministra Zagórskiego.

List MMZ.pdf