Google en Apple voegen afstandsmeting en encryptie toe aan api voor corona-apps

Google en Apple gaan hun api voor corona-apps aanpassen om de data van gebruikers beter te beschermen. De bedrijven veranderen het encryptiealgoritme en de manier waarop id's worden gegenereerd. Ook worden er manieren toegevoegd om de afstand tussen twee toestellen te meten.

Google en Apple voeren de veranderingen door aan de api die zij twee weken geleden aankondigden. De veranderingen worden doorgevoerd om het makkelijker te maken voor andere partijen om ze te integreren in hun apps. Ook worden er nieuwe functies toegevoegd, en wordt de beveiliging verbeterd.

Eén van de veranderingen is dat de sleutels in de app anders worden gegenereerd. Het aanvankelijke plan was om een id-sleutel te genereren op basis van een privésleutel op het toestel. Dat wordt nu veranderd. De sleutel wordt voortaan willekeurig gegenereerd.

Google en Apple gaan ook de metadata rondom het bluetooth-signaal versleutelen. Het gaat dan bijvoorbeeld over het type telefoon. Ook wordt er een limiet gezet op de tijd waarop apps om bluetooth-informatie kunnen vragen. Dat kan straks in tussenpozen van vijf minuten, met een maximum van een half uur. De bedrijven veranderen ook de encryptiestandaard. In de oude api was dat hmac, maar dat wordt aes. De bedrijven zeggen dat dat de snelheid van de api verbetert.

Er komt daarnaast een belangrijke nieuwe functie voor de api. De signaalsterkte van de bluetoothverbindingen worden eraan toegevoegd. Dat gebeurt door middel van het Received Signal Strength Indication- of rssi-protocol. Op die manier kunnen de apps een inschatting maken vanaf welke afstand twee gebruikers bij elkaar zijn gekomen. Ook kunnen appmakers dat verwerken in hun applicaties door de app bijvoorbeeld alleen een waarschuwing te laten sturen bij contact vanaf een bepaalde tijd en afstand. "Op deze manier kunnen gezondheidsinstanties beter definiëren wat een 'exposure event' precies is", zegt een woordvoerder van Apple.

De mogelijkheid om de definitie van besmettingsgevaar helderder te maken was een groot gemis in het eerste voorstel voor de api. In het aanvankelijke plan kon alleen het bereik van het bluetoothsignaal als uitgangspunt worden genomen. Appbouwers kunnen tot slot ook het aantal dagen vanaf een besmettingsgevaarmoment bepalen. "Op die manier kunnen gezondheidsorganisaties bepalen welke acties een gebruiker daarna moet nemen."

Apple en Google werken sinds twee weken samen aan de api. Gezondheidsorganisaties kunnen hun contacttracingapps daar gebruik van laten maken. Op die manier wordt het bereik van het onderzoek vergroot. Ook lost de api een belangrijk probleem op op iOS. Apps die bluetooth willen gebruiken kunnen dat normaal alleen doen als het scherm aanstaat. Dat maakt contacttracingonderzoek lastig voor derde partijen. Tweakers schreef eerder een achtergrondartikel over de mogelijkheden van de api.

Door Tijs Hofmans

Nieuwscoördinator

24-04-2020 • 18:15

46

Reacties (46)

46
43
20
0
0
19
Wijzig sortering
Vooralsnog gaat men er ook wel weer erg vanuit dat de apos niet misbruikt worden door grappenmakers die aangeven corona te hebben gehad terwijl dat niet zo is. Beetje misselijk makende gedachte maar toch
Het wordt een implementatie per land, en een van de mogelijkheden is dat er bij een positieve Corona test ook een code wordt meegestuurd. Die kan een gebruiker dan invoeren. Het kan overigens niet verplicht gesteld worden.
Daar wordt wel rekening mee gehouden. De erver waarme eje besmet gemeld wordt kan een code van de GGD controleren.
Het is niet het idee dat een gebruiker zomaar zelf kan melden dat hij Corona heeft, hij zou na een positieve test een code kunnen krijgen die je in de uiteindelijke app moet invoeren.
Ok dat wist ik niet
De signaalsterkte van de bluetoothverbindingen worden eraan toegevoegd. Dat gebeurt door middel van het Received Signal Strength Indication- of rssi-protocol. Op die manier kunnen de apps een inschatting maken vanaf welke afstand twee gebruikers bij elkaar zijn gekomen.
Er is veel kritiek op de kwaliteit van de implementaties. In theorie is het leuk bedacht maar in de praktijk is al meerdere keren aangegeven dat het door diverse factoren waar Apple en Google geen invloed op hebben onbetrouwbaar is. Apple lijkt er nog enige controle over te hebben omdat ze zowel over de hardware als de software gaan. Androide heeft alleen invloed op de eigen implementatie en meestal niet de kwaliteit van de hardware. En beide platformen hebben tot nu toe geen invloed op de omgeving om te voorkomen dat metingen verkeer geinterpreteerd worden. Ik ben dus heel benieuwd wat de argumenten van Appel en Google zijn om dit wel aan te gaan bieden.

[Reactie gewijzigd door kodak op 28 juli 2024 21:23]

Misschien krijg je van meer apparaten te horen dat ze binnen een bepaalde afstand zijn gekomen, maar zo kan je waarschijnlijk in ieder geval wel de apparaten uitfilteren die zeker weten niet dichtbij zijn gekomen?
Metingen uitwisselen en meer metingen gebruiken geeft niet perse meer betrouwbare resultaten en afhankelijk van de eisen ook extra belemmeringen. En dat klinkt ook niet als onderdeel van rssi. Ik zou dus eerst van Apple en Google willen zien wat hun voorstel voor implementatie is en of ze rekening houden met de onbetrouwbaarheid.
Nice, ik neem aan dat ze zelf intern ook testen wat goed werkt en wat niet.

[Reactie gewijzigd door Xerxes249 op 28 juli 2024 21:23]

En de data openlijk publiceren, uiteraard. Als ze inderdaad zo zeker zijn van de anonimiteit van hun API's. ;)

[Reactie gewijzigd door The Zep Man op 28 juli 2024 21:23]

Ppff ik hoop toch dat ik dit ook uit kan zetten. Ik vond het net zo fijn dat apps m’n Bluetooth op m’n iPhone niet konden gebruiken als t scherm uit staat.
Natuurlijk kan dat! En dan alsnog: het is écht niet zo dat iedere random app bij deze gegevens zouden kunnen.
We hebben het hier over de tweede beste bedrijven ter wereld in de mobile telefonie software. Deze partijen snappen hoe security moet worden toegepast. Als er twee bedrijven zijn die dit het beste kunnen, zijn het Apple en Google samen.
Weinig mensen zullen betwijfelen of Apple en Google dat kunnen. Maar of ze dat willen is een andere vraag. Werknemers van Google hebben jarenlang keihard gewerkt aan het opbouwen van een uiterst belabberde reputatie als het gaat om respect voor andermans privacy. Dat maakt de combinatie van Google-personeel + wereldwijde surveillance van gevoelige medische gegevens verre van ideaal.

Voorbeeld: Google gaat uitmaken welke diensten toegang krijgen tot deze API, en kan daar dus met gemak een paar dochteronderneminkjes onder scharen.
Google heeft altijd respect voor je privacy gehad. Er staat precies geschreven wat met je data gedaan wordt.
Geef eens wat voorbeelden waar werknemers van Google en Apple de directe privacy van hun gebruikers hebben geschonden? Ik kan wel wat voorbeelden opnoemen maar vraag me af of jij dat, met je sterke mening, dat ook kan. Niet gegevens van wifi zenders of zo maar echt personen.

Daarnaast trek je locatiegegevens strak naar medische gegevens. Snap je hoe de app zouden moeten werken? NADAT de gebruikers toestemming hebben gegeven houden ze bij wie met wie in contact is geweest. Als er een verdacht is van een besmetting zal, alweer NADAT de persoon toestemming heeft gegeven, er een alert gaan naar de personen die mogelijk in de buurt geweest zijn en die hebben ingestemd met het krijgen van die informatie.. In de systemen die Google en Apple voorstellen gaat dat niet via hun systemen maar via systemen die de regeringen voorstellen.

En dan nog, het is vrijwel zeker dat over een paar jaar het merendeel van Europeanen positief zal testen voor contact met corana. Wat denk je dat Google, laat staan Apple, met dat gegeven kan doen? Het is niet iets als je lievelingskleur waarmee je meer sokken kan verkopen. En komt niet met verzekeringen aan die mensen weigeren, in feite, als iemand in contact met corona is geweest en niet dood is gegaan zou dat een reden zijn om iemand NIET te weigeren.

[Reactie gewijzigd door Verwijderd op 28 juli 2024 21:23]

Beiden nog nooit gehoord van het ongevraagd bijhouden van levenslange historie aan zoek-opdrachten en locatie-gegevens?
Dat kun je toch gewoon uitzetten als je dat niet wil? Google is juist uitermate transparant wat ze van je weten, je kunt je hele "dossier" downloaden, inclusief opgenomen "OK Google"-spraakopdrachten.

Je haalt mijns inziens privacy en beschikken over gegevens door elkaar. Of schendt mijn arts ook mijn privacy door gevoelige gezondheidsinformatie over mij te hebben? Zolang ze het niet doorverkopen is er niks aan de hand en dat doen ze niet.

[Reactie gewijzigd door Grrrrrene op 28 juli 2024 21:23]

Sinds kort kun je dat uitzetten, als je uberhaupt op de hoogte bent van het feit dat dit allemaal bespioneerd en opgeslagen wordt.

Het gebeurt echter ongevraagd, zonder het duidelijk aan te geven (nee, kleine lettertjes die achter 5 pagina's tekst verstopt zitten zijn niet duidelijk), en dus per definitie zonder nadrukkelijke toestemming. Let wel, dit gaat om gevoelige persoonsgegevens.

Dat de vergelijking met een arts nergens op slaat hoef ik hopelijk niet uit te leggen.

Waarschijnlijk is het wachten tot de database van Google gekraakt wordt (en dat is slechts een kwestie van tijd) en ieders zoek-opdrachten en locatie-geschiedenis op straat liggen, voordat mensen er achter komen hoe ernstig ze in hun persoonlijke levenssfeer bespioneerd zijn.
Sinds kort? Dat kan echt al jaaaaren. Bij mijn vorige werkgever gebruikte ik dat soms als ik vergeten was mijn uren in te vullen, dat was echt jaren geleden en toen was het al optioneel.

Je hebt gelijk dat het min of meer ongevraagd gebeurt, al krijg je de vraag wel gesteld als je een nieuwe Android-telefoon of tablet in gebruik neemt (net een voor mijn oma geïnstalleerd en die vraag kwam expliciet langs). Maar ja, dat lezen mensen niet, die klikken ja, amen om z.s.m. hun nieuwe gadget te kunnen gebruiken.
Zelfs als je overleden bent kunnen de erven alles laten wissen wat bij Google over die persoon bekend is.
De beste? De enige! Dat is toch wel heel wat anders.
Nou niet de enige, er zijn er nog heel wat meer. Dit zijn wel de 2 grootste, wat je ook als criteria van succes kunt beschouwen.
Uiteraard kunnen ze het. Het zijn volgens mij zelfs de besten in data verzamelen en metriseren van data,.... gewild door ons en..... ongewild door ons. Ik word hier echt niet warm van.

Tja, ze hebben hun reputatie niet mee. Dat is niet mijn probleem.
Het gaat hier over een API. Niet een app. Zolang je geen app installeert die van deze API gebruik maakt verandert er niks voor jouw.
Ook hebben Apple en Google gezegd dat alleen apps van officiële gezondheidsorganisaties en overheden van deze API gebruik kunnen maken.
Oh nou gelukkig, als Apple en Google dat zeggen zal het wel zo zijn toch ?
Ja, zo kun je overal iets tegenin brengen. Hoe wapen je je als bedrijf tegen dit soort "alu hoedje" argumenten? Je maakt nu zonder bewijs 2 bedrijven zwart.
Kom op zeg, het verleden heeft toch keer op keer bewezen dat dit soort bedrijven het niet erg nauw neemt met privacy. Achteraf weer sorry zeggen, een boete betalen en weer lekker doorgaan.
Noem dan eens wat voorbeelden in plaats van dit soort ongefundeerde kritiek te uiten. Ja, Apple en Google weten een hoop van je, maar daar geef je zelf toestemming voor. Daarbuiten delen ze je informatie niet met anderen, Google is zelfs uitermate transparant over wat ze van je weten: ik heb mijn eigen dossier wel eens gedownload en dat is best interessant om eens door te kijken. Maar je doet nu net alsof Jan en alleman straks je locatie kan zien 8)7
Je kan ook gewoon de app niet installeren
Het is een API geen app. Je moet eerst een app hebben van een gecertificeerde instantie die de API gebruikt. Het is ook nog decentraal en anoniem dus ik weet niet wat men nog meer zou willen.
Als ik eerlijk ben, heb ik door dit initiatief pas een beetje vertrouwen gekregen dat het zou kunnen gaan werken. Integenstelling tot de een of andere brakke, veel te dure, Capgemini app.

Ten eerste worden hierdoor de kosten voor het ontwikkelen van apps die gebruik maken van de API lager, maar ook de garantie dat iPhones en Androids op een verwachte manier samenwerken kan nu gegeven worden.

Dat neemt niet weg dat ik nog steeds mijn twijfels heb en heel wat vragen. Zowel op technisch gebied, als op maatschappelijk en privacy gebied.
Denk dat we meer hebben aan BTpower modulation bv 100% 50% 10% BTpower. Als je dat signaal nog ontvang bij 10% weet je dat dichtbij bent. Dit in relatie met RSSI geef misschien ook nog of er een muur tussen zit of niet....
Iemand link naar de nieuwe API Exposure Notification ?
AuteurTijsZonderH Nieuwscoördinator @01--Rolf--0124 april 2020 21:25
Ik heb em in m'n mail maar weet niet of ik die al openbaar mag maken. Ik ga even zoeken en update het artikel als ik het ergens publiek kan vinden!
Thx.... mmm hun eigen opmerking ( Note) over RSSI is eigenlijk het hele probleem als we BT gebruiken...
"@property uint8_t attenuationThreshold;
This property holds the largest amount of signal attenuation allowable when detecting matches. A value of 0 means there’s no limit.
Attenuation is calculated by subtracting the measured RSSI from the reported transmit power. Values larger than the attenuation limit aren’t checked for exposure matches.
Note: The attenuation value may be misleading because more attenuation doesn't necessarily mean the device is farther away. For example, two people could be physically very close and facing each other with
their phones in their back pockets. In this case, a higher attenuation (a weaker signal) may be reported
even though the individuals are very close together"
Wat ik me afvraag is of het wel zo handig is om via een app publiekelijk te vertellen dat je corona hebt. Best kans dat je later geweigerd wordt in OV en op Schiphol.
Als al die systemen doorgeven dat je weer herstelt bent dan wel ok, alleen dan..

Ik zie dat u in de app aangegeven hebt dat u corona hebt?
Ja dat was, ik ben nu hersteld
Oh, maar dat heb ik hier niet staan. Komt u later nog eens terug.

Zoiets.

[Reactie gewijzigd door Boomfok op 28 juli 2024 21:23]

Hierom is het ook belangerijk dat het anoniem is.
Google en Apple gaan ook de metadata rondom het bluetooth-signaal versleutelen. Het gaat dan bijvoorbeeld over het type telefoon.
Ik kom dit echt nergens in de nieuwe specificaties tegen. Ik vraag me ook af waarom dit nodig zou zijn?!?
De signaalsterkte van de bluetoothverbindingen worden eraan toegevoegd. Dat gebeurt door middel van het Received Signal Strength Indication- of rssi-protocol. Op die manier kunnen de apps een inschatting maken vanaf welke afstand twee gebruikers bij elkaar zijn gekomen.
Er is geen RSSI-protocol. Het is gewoon een indicatie van de sterkte van het ontvangen signaal. Dat werd al gebruikt. Maar nieuw is dat de verzender nu ook meestuurt hoe hard hij het heeft uitgezonden. Dit geeft betrouwbaardere informatie over hoeveel signaalverlies er heeft opgetreden en dus mogelijk een betere schatting van de afstand.
Jawel.
De bedrijven veranderen ook de encryptiestandaard. In de oude api was dat hmac, maar dat wordt aes.
Ik gok dat het Poly1305-AES betreft.
Dan staat het er raar want HMAC is geen encryptie standaard maar puur een hash om de integriteit en authenticiteit van een waarde te kunnen verifiëren.

Als er wat er in het artikel staat klopt kon de data net zo goed plain-text zijn en niet versleuteld.
Vraagje. Wat gebruik je dan wel? Ik probeer hier nog een paar jaar door te gaan met mijn Lumia 950, maar voorlopig zie ik geen enkele ander valabele optie.
ik gebruik inmiddels Ubuntu Touch op mijn Nexus 5: https://ubports.com/

Op dit item kan niet meer gereageerd worden.