De bèta van de contactonderzoeksapp NHS COVID-19 is nu opensource voor zowel iOS als Android, samen met wat documentatie. Als vervolg op ons artikel “Staying alive” hebben we de broncode grondig bekeken. Het is een aangename verrassing dat die onder de MIT-licentie valt, wat wijst op een toewijding van NHSX aan transparantie en kwaliteit.
De afgelopen twee dagen hebben een aantal engineers de app onderzocht om te ontdekken of, en hoe, hij in staat is om actief te blijven. Om dit te begrijpen was een dieper begrip van het betreffende framework CoreBluetooth nodig dan de meeste ontwikkelaars hebben. Het is geen framework waar engineers zich doorgaans in hoeven te verdiepen.
Vrij snel hebben we ontdekt en gemeld hoe de truc voor Android-apparaten werkte. Vanavond delen we wat er precies op iOS gebeurt. We lopen het stap voor stap door.
Eerste start
Bij de eerste start doet de app een PUT-verzoek naar https://api.svc-covid19.nhs.uk/api/devices/registrations met een activatiecode, een pushmeldingstoken en de eerste helft van de door de gebruiker ingevoerde postcode. Als antwoord stuurt de server een linkingId terug die in de instellingen van de app wordt opgeslagen.
De app vraagt ook, zoals je zou verwachten, toestemming voor pushmeldingen en Bluetooth. Hij vraagt geen locatietoestemming en valideert de postcode van de gebruiker dus niet. Alleen de eerste cijfers van een postcode zijn vereist.
Er zijn beweringen dat de Android-app toegang heeft tot locatiegegevens, omdat de vraag om toegang tot de Bluetooth-API op Android-apparaten lijkt te vragen om locatietoestemming. Dat hebben we gisteren echter ontkracht: dit is een gevolg van hoe Android verzoeken om Bluetooth-toestemming beheert.
Actief blijven op Android
Voorkomen dat een app op de achtergrond in slaap valt is op Android triviaal, omdat de standaard-API’s deze functionaliteit ondersteunen en engineers laagdrempelige toegang tot de Bluetooth-hardware geven.
Op iOS ligt dat echter niet zo eenvoudig. Wanneer apps op iOS naar de achtergrond gaan, wordt hun functionaliteit sterk beperkt. Dat is ook het geval met CoreBluetooth, het framework van Apple dat ontwikkelaars toegang geeft tot Bluetooth. Zonder een slimme omweg maakt dit het aanzienlijk moeilijker voor de app om iPhones te detecteren die mogelijk in de achtergrondmodus draaien. We hebben getest met een aantal iOS-apparaten die enkele uren met rust werden gelaten, en merkten dat het peilen minder vaak gebeurde, maar dat de apparaten ’s nachts nog steeds communiceerden.
Android gebruiken om iPhones wakker te maken
Gisteren meldden we ook dat iOS-apps op de achtergrond Bluetooth-advertenties blijven uitzenden, maar op een andere manier die specifiek is voor Apple. We dachten dat de engineers van NHSX en Pivotal dit hadden gereverse-engineerd en er ondersteuning voor hadden toegevoegd aan de Android-app. We kunnen bevestigen dat dit zo is, en hun technische details hierover zijn hier te vinden. Dit betekent dat iOS-apparaten de app niet alleen op de achtergrond actief kunnen houden, maar dat Android-apparaten ook een “slapend” iOS-apparaat wakker kunnen maken, ongeacht hoe lang het al op de achtergrond staat.
Wat zijn hiervan de gevolgen? Het betekent dat een iPhone, om de app te laten werken, vrij vaak binnen bereik van een Android-apparaat moet zijn, zodat die keepalives kan sturen om zichzelf op de achtergrond actief te houden. Dat is op zichzelf misschien geen werkbare oplossing, maar…
iOS-apparaten gebruiken om… andere iOS-apparaten wakker te maken
In het artikel “Staying alive” van gisteren meldden we dat we dachten dat de iOS-app “keepalives” gebruikte om de beperkingen van het draaien op de achtergrond te omzeilen. Na het bestuderen van de broncode van de iOS-app concludeerden we dat dit inderdaad zo is. Maar hoe werken ze precies?
Simpel gezegd is een keepalive in deze context een idee dat de ontwikkelaars van de app hebben bedacht: het is een melding die wordt verstuurd tussen twee iOS-apparaten waarop de app draait om de verbinding tussen de apparaten in stand te houden. Het interessante hieraan is dat het ook als effect heeft dat de app aanzienlijk langer wakker kan blijven, want wanneer een apparaat een keepalive ontvangt, staat iOS toe dat de app wakker blijft om extra verwerking uit te voeren.
In de praktijk betekent dit dat de app zijn actieve toestand kan behouden zolang hij zich in de buurt van andere apparaten bevindt. Dit is in zekere zin de redenering achter het COVID-19-contactonderzoeksproject: zelfs zonder deze technische truc moet een kritische massa gebruikers de tracingapp draaien om een goed resultaat voor de openbare veiligheid te bereiken.
Los daarvan valt de app niet direct in slaap en gaat hij niet in een opgeschorte toestand wanneer hij naar de achtergrond gaat. De vraag wordt dus of de meeste gebruikers zich vaak genoeg in de buurt van iOS- of Android-apparaten bevinden om de omwegen werkbaar te maken. Wij denken dat dit waarschijnlijk is, en des te meer voor gebruikers die vaker in bevolkte gebieden komen. Bluetooth heeft een behoorlijk effectief bereik.
Een paar waarnemers hebben gesuggereerd dat het vermogen van de app om stille meldingen te ontvangen betekende dat hij deze mogelijkheden gebruikte om zichzelf op afstand wakker te maken. Deze mogelijkheden worden echter gewoon gebruikt om de gebruiker te laten weten of hij in de buurt is geweest van iemand die COVID-19 heeft gekregen. De app gebruikt ook lokale meldingen die detecteren wanneer de app door het systeem wordt beëindigd, en die gebruikers vragen de app opnieuw te openen. Een vergelijkbare melding wordt gebruikt wanneer de gebruiker Bluetooth uitschakelt.
Aidan Fitzpatrick, de CEO van Reincubate, zegt:
Ja, het klopt dat het aankomende Apple-framework
ExposureNotificationin iOS 13.5 deze keepalives overbodig maakt. Het is echter goed om op te merken dat:
- iOS 13.5 nog niet is uitgebracht en dat mogelijk nog enkele weken niet wordt
- De laatste iOS 13.5-bèta tot gisteren een ernstige beveiligingsfout had, wat erop wijst dat er bij de engineeringteams van Apple hard wordt gewerkt
- Zodra het is uitgebracht, het waarschijnlijk maanden duurt voordat een meerderheid van de iOS-gebruikers het heeft geïnstalleerd (ongebruikelijk genoeg kan de acceptatie op Android sneller gaan)
- Oudere iOS-apparaten, zoals de iPhone 6, iOS 13 niet kunnen draaien en de techniek van Apple dus niet kunnen gebruiken
- Er is geen reden waarom de NHS COVID-19-app in de toekomst niet automatisch kan overstappen op het framework van Apple, of zelfs beide mechanismen naast elkaar kan laten draaien
De app wordt steeds effectiever naarmate meer mensen hem gebruiken, en het voordeel van massale acceptatie zorgt in die zin voor een vliegwieleffect. De Australische COVIDSafe-app had het moeilijk omdat hij het detecteren van iOS-apparaten op de achtergrond vanaf een Android-apparaat niet ondersteunde en dit slimme keepalive-mechanisme van iOS naar iOS niet had.
Het is belangrijk om na te denken over onder welke omstandigheden het gepast is om dit soort technologie te gebruiken. Als contactonderzoek succesvol is in het redden van levens, aan welke criteria moet dan worden getoetst of het wordt toegepast bij toekomstige ziekten? Is er, zodra het precedent is geschapen, een argument dat deze technologie zou kunnen worden ingezet tegen bestaande infectieziekten? Het is voorstelbaar dat verschillende samenlevingen de afwegingen anders zullen beoordelen.
Privacywaarborgen
Een gedetailleerde analyse van de wiskunde achter het protocol valt buiten het bestek van dit artikel, maar we hebben wel naar de privacywaarborgen gekeken. De app lijkt zich strikt te houden aan het paper dat de NCSC publiceerde. We kunnen bevestigen dat er geen sleutelgegevens het apparaat van de gebruiker verlaten totdat die symptomen meldt, en dat pas dan de geanonimiseerde sleutels van apparaten waarmee het in de directe omgeving is geweest het apparaat verlaten. De eerste helft van de door de gebruiker ingevoerde postcode wordt als onderdeel van de registratieservice naar de API gestuurd.
Uiteindelijk wijst de code erop dat het gebruik van de app technisch weinig privacyrisico oplevert, totdat een gebruiker symptomen meldt en contact opneemt met de NHS om een test te regelen. Op dat moment wordt het testresultaat beheerd door de NHS, al is dat niet anders met of zonder de app. Zodra echter meerdere gebruikers met elkaar in contact komen, symptomen melden en tests regelen met de identifier die de app hun heeft gegeven, kan het al dan niet mogelijk zijn om ze centraal aan elkaar te koppelen. Dat is een vraag voor de back-end, en zoals NHSX in hun privacyrapport over de app stelt, is code de waarheid in dit opzicht.
Beveiliging tegen valse meldingen
Omdat de back-end van het systeem niet als opensource is vrijgegeven, kunnen we dit niet bevestigen, maar het lijkt erop dat er geen pushmeldingen naar andere apparaten worden gestuurd totdat burgers positief testen op COVID-19. Zodra een gebruiker symptomen meldt, krijgt hij een referentiecode waarmee een test kan worden geboekt. (Deze code is toevallig dezelfde als de linkingId die we in de sectie over registratie hebben beschreven.)
