Privacyontwerper: CoronaMelder-app niet volledig anoniem
De CoronaMelder-app is niet volledig anoniem. Het is namelijk mogelijk voor derden om te achterhalen of gebruikers van de app met corona besmet zijn, zo stelt privacyontwerper en technologiecriticus Tijmen Schep. "Je zou bijvoorbeeld stiekem in de gaten kunnen houden of je buurman besmet is geraakt."
Schep ontwikkelde een website genaamd Corona Detective waarmee dergelijke informatie te achterhalen is. De CoronaMelder-app genereert willekeurige codes en verstuurt die via bluetooth. Andere app-gebruikers in de buurt kunnen deze codes opvangen en op hun telefoon opslaan. Is iemand met corona besmet geraakt en maakt hij dit via de app kenbaar, dan worden de gegenereerde codes van deze gebruiker naar een server geüpload. De lijst met codes van besmette personen wordt dagelijks door CoronaMelder gedownload. Komt een code van deze lijst overeen met een op de telefoon opgeslagen code, dan krijgt de gebruiker een waarschuwing dat hij met een besmet persoon in contact is geweest.
Via de website Corona Detective is het mogelijk om te zien wie in de omgeving CoronaMelder geïnstalleerd heeft. Hiervoor is het niet nodig om de app zelf geïnstalleerd te hebben. De website vraagt toegang tot bluetooth en zoekt vervolgens naar alle telefoons in de omgeving die CoronaMelder geïnstalleerd hebben. Het is daarbij mogelijk om de afstand te zien en welke richting de telefoon op beweegt. Zo kan de gebruiker van Corona Detective bepalen welk signaal bij welke persoon hoort.
Vervolgens is het mogelijk om de door CoronaMelder uitgezonden code van een naam te voorzien. Wanneer de betreffende gebruiker later besmet blijkt en zijn codes naar de centrale server uploadt, zal Corona Detective die downloaden en kan vervolgens aan de hand van de eerder gemaakte koppeling tussen naam en code bepalen wie de besmette persoon is. Zo is het bijvoorbeeld mogelijk om te achterhalen wie het coronavirus in zijn omgeving heeft verspreid, stelt Schep.
De CoronaMelder-app bestaat uit twee delen. Een deel dat door de overheid is ontwikkeld en het onderliggende framework van Apple en Google. Het door de overheid gebouwde deel "is enorm transparant en behoorlijk anoniem", laat Schep in een video over de werking van Corona Detective weten. De overheid kan namelijk niet achterhalen wie, wat doet. "Maar het stuk van Apple en Google is niet anoniem. Het is pseudoniem. Daardoor wordt jouw naam alleen maar vervangen door een nummertje. Dat kan dus heel makkelijk ongedaan worden gemaakt."
Volgens Schep is het daarom belangrijk om niet het gehele systeem anoniem te noemen. Het geldt eigenlijk alleen voor het deel dat de overheid ontwikkelde, zo merkt de privacyontwerper op. Het ministerie van Volksgezondheid laat tegenover de NOS weten dat de kans dat op enige schaal codes aan appgebruikers worden gekoppeld klein is.
Meten van CoronaMelder-gebruikers
Niet alleen personen kunnen voor hun omgeving codes onderscheppen. Voor bedrijven kan het meten van CoronaMelder-gebruikers ook interessant zijn. Het bedrijf BlueMark biedt een platform voor bedrijven en organisaties om bezoekers van hun evenement, winkel of locatie via wifi of bluetooth te meten. In september publiceerde Bluemark een blogposting met de titel "Measure the COVID-19 app usage at your location using the BlueMark WiFi/Bluetooth platform", waarin het bedrijf uitlegde hoe ondernemers het platform kunnen gebruiken om te zien hoeveel mensen CoronaMelder hebben geïnstalleerd. Daarnaast zou met de data de drukte kunnen worden gemeten.
De blogposting is inmiddels door BlueMark verwijderd. Het bedrijf verklaart aan de NOS dat er geen klanten zijn die de CoronaMelder-signalen gebruiken. De verwijderde blogposting laat echter zien dat BlueMark tijdens een pilot in een winkelstraat het gebruik van CoronaMelder anderhalve maand heeft bijgehouden, zo ontdekten oplettende Twitteraars. BlueMark verklaart dat het hier om nepdata ging om klanten te laten zien wat technologisch mogelijk is. Het ministerie van Volksgezondheid heeft bij de Autoriteit Persoonsgegevens een klacht tegen het bedrijf ingediend.
Volgens het kl**tjes volk is 'gezondheid' toch belangrijker dan privacy.
Want als je die app hebt, dan is het hele probleem zo opgelost!
Niets; totdat je uitkwam bij het "presenteren op een webportal" Dan is het onrechtmatige verwerking van direct herleidbare persoonsgegevens en wordt het een privacy issue.
Eminus
Uit de officiële documentatie https://developers.google.com/android/exposure-notifications/exposure-notifications-api:
A random ID derived from the device's Temporary Exposure Key. The RPI is generated on the device and a new RPI is generated every 10-20 minutes.
Temporary Exposure Key (TEK)
A key that's randomly generated once every 24 hours. It remains on the device for up to 14 days. In the event that there's a positive diagnosis of COVID-19, and upon permission granted from the user, these keys are provided to the app.
Er worden dus vaak wisselende RPI's (wisselt elke 10 á 20 minuten) door smartphones uitgezonden via Bluetooth (BLE),
maar er worden (max. 14) dagelijks wisselende TEKs geupload wanneer je bent besmet als jij daar toestemming voor geeft. Zo kunnen namelijk anderen worden gewaarschuwd die via jou mogelijk ook corona hebben opgelopen.
Stel iemand heeft jou een keer "gepeild" zoals men beschrijft, dan is die informatie na 14 dagen waardeloos.
Immers als je meer dan 14 dagen later corona zou krijgen en je upload je TEKs, dan zitten daar geen TEKs bij
die ouder zijn dan 14 dagen, dus de "spion" vind geen match meer van peilingen die meer dan 14 dagen oud zijn.
In het youtube filmpje uit twitter wordt gepraat alsof je al je uitgezonden RPI's zou uploaden na besmetting. Dit is niet zo. Het zijn de TEKs die je upload. (waarvan de uitgezonden RPIs waren afgeleid en vervolgens (AES?) encrypted)
De TEKs zelf zijn niet eerder uitgezonden. Dus niemand kan jouw TEKs weten door met BLE in de ether te sniffen.
Het klopt wel dat de verschillende uitgezonden RPI's eigenlijk allemaal verschillende pseudoniemen zijn (volgens youtube ondertiteling: "sodomie" ...LOL...) van de actuele TEK van de dag. Het is niet onmogelijk om opnieuw alle RPIs uit een TEK te trekken en ze te vergelijken met een RPI die je van een bepaald persoon hebt opgevangen om te kijken of er een match tussen zit, maar natuurlijk alleen maar als men zulke TEK(s) heeft weten te bemachtigen!
Echter de enige bron van alle geüploade TEKs is voor zover ik weet de uploadserver.
Hierin komen je TEKs alleen terecht als je bent besmet met corona en toestemming geeft om je TEKs te uploaden.
De vraag is hoe het kan dat er geen maatregelen zijn genomen om te voorkomen dat iedereen de data van deze server kan kopiëren? Als deze uploadserver goed wordt beschermd zodat onbevoegden er geen TEKs meer van kunnen kopiëren dan lijkt mij dit potentiële lek voor het belangrijkste deel weer behoorlijk gedicht.
Niets; totdat je uitkwam bij het "presenteren op een webportal" Dan is het onrechtmatige verwerking van direct herleidbare persoonsgegevens en wordt het een privacy issue.
Eminus
De vraag is hoe het kan dat er geen maatregelen zijn genomen om te voorkomen dat iedereen de data van deze server kan kopiëren? Als deze uploadserver goed wordt beschermd zodat onbevoegden er geen TEKs meer van kunnen kopiëren dan lijkt mij dit potentiële lek voor het belangrijkste deel weer behoorlijk gedicht.
Zie https://coronamelder.nl/nl/faq/6-hoe-werkt-de-app-technisch-precies/. Elke coronamelder app heeft toegang tot de lijst met codes van besmette personen. Hoeveel beveiliging er op de API van die server zit, in hoeverre dat überhaupt mogelijk is, en ook in hoeverre de informatie op je telefoon ontoegankelijk wordt gemaakt voor andere apps (in dit geval de webbrowser) is onduidelijk. Blijkbaar - als die website echt functioneert zoals geclaimd - kan je er op de een of andere manier toch bij komen.
Volgens het kl**tjes volk is 'gezondheid' toch belangrijker dan privacy.
Want als je die app hebt, dan is het hele probleem zo opgelost!
Dit is echt nooit beweerd door politici en deskundigen.
Roep je dit ook als het over de mondkapjes gaat? "Als iedereen een mondkapje draagt is het hele probleem zo opgelost!" dit is ook noooit beweerd. Het is een van de vele hulpmiddelen die een kleine bijdrage kunnen leveren in het voorkomen van extra besmettingen.
Er worden dus vaak wisselende RPI's (wisselt elke 10 á 20 minuten) door smartphones uitgezonden via Bluetooth (BLE),
Samen met elke RPI wordt tevens versleutelde metadata uitgezonden met daarin calibratiegegevens voor het zendvermogen van het betreffende merk en type smartphone. Daarmee kan een ontvanger, mits deze de sleutel kent, te weten komen om welk (groepje) merk en type smartphone(s) het gaat (een aantal merken en types smartphones kunnen hiermee, naar verluidt, uniek worden geïdentificeerd).
In https://security.nl/posting/676257 licht ik het proces, voor zover mij nu bekend, verder toe. Zojuist zag ik dat ik bovenin de tekst schreef dat de TEK zelf als encryptie/decryptiesleutel voor de metadata wordt gebruikt. Dat is onjuist, want dan zou de versleutelde metadata 24 uur niet wijzigen (en je de smartphone kunnen tracken ondanks wijzigende RPI en MAC-adres). Verderop in die bijdrage, onder het kopje "Nog zonder TEK geen kennis van (potentieel smartphone merk+type identificerende) zendercalibratiegegevens", heb ik dit wel goed verwoord (ook heb ik in https://security.nl/posting/676431 een correctie geplaatst).
Hierin komen je TEKs alleen terecht als je bent besmet met corona en toestemming geeft om je TEKs te uploaden.
De vraag is hoe het kan dat er geen maatregelen zijn genomen om te voorkomen dat iedereen de data van deze server kan kopiëren? Als deze uploadserver goed wordt beschermd zodat onbevoegden er geen TEKs meer van kunnen kopiëren dan lijkt mij dit potentiële lek voor het belangrijkste deel weer behoorlijk gedicht.
Dat het downloaden van TEK's van de meeste landen geen probleem is, bewijst https://down.dsg.cs.tcd.ie/tact/tek-counts/. Nb. Firefox op mijn Android smartphone laat hier een gecachte pagina van zien tot ik een update forceer (met het "ronddraaiende" pijltje onder de 3 puntjes rechtsboven) - ik heb geen idee waarom. De datum en tijd van de server lijkt OK.
Uit de actuele TEK worden m.b.v. HKDF twee sleutels gegenereerd: de RPI-key(Rolling Proximity Identifier) en de AEM-key (Associated Encrypted Metadata). Beide keys lijken hetzelfde, maar het ziet er naar uit dat ze toch verschillend zijn:
RPI-key = HKDF(tek, NULL, UTF8("EN-RPIK"), 16)
AEM-key = HKDF(tek, NULL, UTF8("EN-AEMK"), 16)
De RPI-key gaat samen met het actuele "10-minuten"-intervalnummer (= "discretized representation of time") ook nog door een AES-functie. Deze AES encryptie levert de uiteindelijke RPI op die geldig is gedurende het momentane tijdsinterval.
AEM wordt gegenereerd m.b.v. een AES-CTR (- AES in counter mode -) met als inputs:
de al eerder gegenereerde AEM-key, de huidige RPI en Bluetooth -metadata.
Merk op: die "discretized representation of time" werkt in wezen als een counter die na elke 10 minuten weer één verder telt. Deze teller geeft aan in het hoeveelste 10-minuten-interval we leven sinds 1 januari 1970 0:00u UTC.
Voor wat de TEKs betreft:
voor zover ik kan nagaan bestaat elke TEK uit 16 random gegenereerde bytes uit een CRNG. Verder niets.
Er wordt dagelijks een nieuwe random TEK gegenereerd. Je kan dus niet zondermeer datum/tijd van een TEK weten.
Er wordt bovendien officieel aanbevolen om alle nieuw binnengekomen TEKs eerst door elkaar te husselen op de server alvorens ze te verzenden naar alle app-users om ervan verzekerd te zijn dat opeenvolgende TEKs niet aan dezelfde user kunnen worden gelinkt. Een TEK zoeken bij datum/tijd van een RPI gaat dus niet zomaar.
Wat wel kan is "trial and error" door dagelijks van alle via de server geopenbaarde TEKs de RPI opnieuw te genereren voor het 10-minuten-tijdvak (en voor de zekerheid eventueel ook het tijdvak ervoor en erna) van de datum en tijd van de RPI die je had gesnift. Dit kan je een dag of 14 volhouden. Daarna zal je een nieuwe RPI moeten sniffen...
De TEK's zijn gewoon open en bloot te downloaden. De code daarvoor kun je op Github vinden. Daaruit kun je dan weer de RPI's berekenen. En die vergelijk je dan. Dat is precies hetzelfde als wat de officieele CoronaMelder app zelf doet.
Ik weet dat de video het iets te simpel uitlegt, want je upload TEK's ipv RPI, maar ik wilde de uitleg simpel houden. In de praktijk komt het op hetzelfde neer.
Je kunt inderdaad maximaal 14 dagen iemand in de gaten houden. Idealiter scan je iemand elke week. Daarna moet je dan weer een bluetooth signaal opvangen. maar als je bijvoorbeeld je buren in de gaten wilt houden, of collega's, dan is dat heel makkelijk, want die zie je elke dag. Als een bepaalde politicus of BN-er elke week in je sportschool staat, dan is dat zo gepiept.
Je hoeft iemand dus ook niet continue te tracken. Desalnietemis kan Corona Detective ook omgaan met het veranderen van de RPI's. Als er een RPI niet meer wordt uitgezonden, en een nieuwe RPI verschijnt (een kwart seconde later), dan kun je dat enigszins betrouwbaar weer aan elkaar lijmen. Dat is vooral gedaan om optimaal te kunnen uitfilteren welke bluetooth signalen echt nieuw zijn, en welke gewoon een RPI-switch zijn. Omdat de RPI codes maar 1x per kwartier veranderen (hangt een beetje af van je telefoon hoe lang het interval precies is), is het super eenvoudig om dit te filteren. Dit nog bovenop het issue dat de RPI en het roterende mac adres volgens de specificatie van Google niet op hetzelfde moment hoeven te veranderen. Maar goed, dat doet er dus niet enorm toe. Het staat vooral leuk in de interface dat je kan zien hoe lang iemand er al is, en het maakt het ook mogelijk om aan te wijzen wanneer iemand weer naar huis is gegaan, zodat je ook op dat moment de identiteit koppeling kan maken.
De TEK's zijn gewoon open en bloot te downloaden. De code daarvoor kun je op Github vinden. Daaruit kun je dan weer de RPI's berekenen. En die vergelijk je dan. Dat is precies hetzelfde als wat de officieele CoronaMelder app zelf doet.
Ik weet dat de video het iets te simpel uitlegt, want je upload TEK's ipv RPI, maar ik wilde de uitleg simpel houden. In de praktijk komt het op hetzelfde neer.
Je kunt inderdaad maximaal 14 dagen iemand in de gaten houden. Idealiter scan je iemand elke week. Daarna moet je dan weer een bluetooth signaal opvangen. maar als je bijvoorbeeld je buren in de gaten wilt houden, of collega's, dan is dat heel makkelijk, want die zie je elke dag. Als een bepaalde politicus of BN-er elke week in je sportschool staat, dan is dat zo gepiept.
Je hoeft iemand dus ook niet continue te tracken. Desalnietemis kan Corona Detective ook omgaan met het veranderen van de RPI's. Als er een RPI niet meer wordt uitgezonden, en een nieuwe RPI verschijnt (een kwart seconde later), dan kun je dat enigszins betrouwbaar weer aan elkaar lijmen. Dat is vooral gedaan om optimaal te kunnen uitfilteren welke bluetooth signalen echt nieuw zijn, en welke gewoon een RPI-switch zijn. Omdat de RPI codes maar 1x per kwartier veranderen (hangt een beetje af van je telefoon hoe lang het interval precies is), is het super eenvoudig om dit te filteren. Dit nog bovenop het issue dat de RPI en het roterende mac adres volgens de specificatie van Google niet op hetzelfde moment hoeven te veranderen. Maar goed, dat doet er dus niet enorm toe. Het staat vooral leuk in de interface dat je kan zien hoe lang iemand er al is, en het maakt het ook mogelijk om aan te wijzen wanneer iemand weer naar huis is gegaan, zodat je ook op dat moment de identiteit koppeling kan maken.
Dank voor deze bevestiging.
Echter, ik zie niet dat daar de laatste 48 uur iets aan verandert. Ik zou verwachten dat besmettingen ouder dan 14 dagen uit de lijst verdwijnen en nieuw aangemelde besmettingen er bij komen. Kan je aangeven waar in de source code van de originele corona app de lijst wordt opgehaald. Dan kan ik de lijst meteen bij de bron ophalen. Het leek me wel leuk om wat statistiek op die lijst toe te passen: je kan zien hoeveel nieuwe besmettingen zijn aangemeld via de app en die vergelijken met het aantal besmettingen die via de GGD's zijn binnengekomen. Daaruit kan je de penetratiegraad van de corona app afschatten.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Netwerk Security Engineer
Luchtverkeersleiding Nederland
Als Netwerk Security Engineer ontwerp en optimaliseer je onze technische netwerk- en beveiligingsinfrastructuur. Je stuurt tech-nische veranderingen aan op basis van de gestelde architectuur kaders en helpt mee met de uitvoering ervan. Ben jij een gedreven professional met passie voor netwerk-beveiliging? Dan is deze functie als Netwerk Security Engineer bij Luchtverkeersleiding Nederland (LVNL) iets voor jou!
Lead Network Security Engineer
Luchtverkeersleiding Nederland
Word Lead Network Security Engineer bij LVNL. Ontwerp en implementeer security-oplossingen die de luchtverkeersleidings-systemen veilig houden. Solliciteer nu en draag bij aan onze cyberweerbaarheid! Als Lead Network Security Engineer bij LVNL ben je verantwoordelijk voor het ontwerpen, implementeren en optimaliseren van de netwerkbeveiliging die cruciaal is voor de veilige en efficiënte werking van het luchtverkeersleidingssysteem in Nederland.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?