Een technische diepe duik in de NHS COVID-19 app voor contactopsporing

De bètaversie van NHS COVID-19 voor contacttracering is nu open source voor zowel iOS als Android , samen met wat documentatie . Als vervolg op ons bericht ' Staying alive ' hebben we een diepe duik genomen in de broncode. Het is aangenaam verrassend om te zien dat het onder MIT is gelicentieerd, wat wijst op een NHSX-toewijding aan transparantie en kwaliteit.

In de afgelopen twee dagen hebben een aantal ingenieurs de app beoordeeld om te ontdekken of - en hoe! - het kan in leven blijven. Om dit te begrijpen is een dieper begrip van het relevante CoreBluetooth framework CoreBluetooth dan de meeste ontwikkelaars. Het is geen raamwerk waar ingenieurs zich doorgaans in moeten verdiepen.

Vrij vroeg hebben we opgemerkt en gerapporteerd hoe de truc werkte voor Android-apparaten. Vanavond delen we precies wat er gebeurt op iOS. Laten we er doorheen stappen.

Eerste lancering

Bij de eerste lancering doet de app een PUT verzoek aan https://api.svc-covid19.nhs.uk/api/devices/registrations met een activeringscode, een token voor pushmeldingen en de eerste helft van de door de gebruiker ingevoerde postcode. Als reactie antwoordt de server met een linkingId die is opgeslagen in de instellingen van de app. De app vraagt ook om pushmeldingen en Bluetooth-rechten, zoals je zou verwachten. Het vraagt geen locatietoestemmingen en valideert als zodanig de postcode van de gebruiker niet. Alleen de eerste paar cijfers van een postcode zijn vereist.

Er is beweerd dat de Android-app toegang heeft tot locatiegegevens, aangezien de prompt voor Bluetooth API-toegang op Android-apparaten lijkt te vragen om locatietoestemmingen. We hebben dit echter gisteren ontkracht: dit is een gevolg van hoe Android verzoeken om Bluetooth-rechten beheert .

In leven blijven op Android

Voorkomen dat een app op de achtergrond slaapt, is triviaal op Android, omdat de voorraad-API's deze functionaliteit ondersteunen, waardoor ingenieurs op laag niveau toegang hebben tot Bluetooth-hardware.

Op iOS is het verhaal echter niet zo eenvoudig. Wanneer apps op iOS als achtergrond worden gebruikt, wordt hun functionaliteit aanzienlijk verminderd. Dit is ook het geval met CoreBluetooth , het Apple-framework dat ontwikkelaars toegang geeft tot Bluetooth. Afgezien van een slimme oplossing, maakt dit het voor de app aanzienlijk moeilijker om iPhones te detecteren die mogelijk in de achtergrondmodus worden uitgevoerd. We testten met een aantal iOS-apparaten die in de loop van enkele uren met rust werden gelaten, en merkten op dat polling minder vaak voorkwam, maar dat de apparaten nog steeds 's nachts communiceerden.

Android gebruiken om iPhones te wekken

Yesterday we also reported that when backgrounded, iOS apps continue to broadcast Bluetooth advertisements, but in a different way that’s specific to Apple. We believed the NHSX / Pivotal engineers had reverse-engineered this, and added support for it to the Android app. We can confirm that this is the case, and their technical details about it can be found here. What this means is that in addition to iOS devices being able to keep the app backgrounded, Android devices can wake a “sleeping” iOS device up regardless of how long it has been backgrounded for.

Dus wat zijn de implicaties hiervan? Welnu, het betekent dat om de app te laten werken, een iPhone vrij vaak binnen het bereik van een Android-apparaat moet zijn, zodat het keepalives kan sturen om zichzelf op de achtergrond te houden. Dat alleen is misschien geen werkbare oplossing, maar ...

IOS-apparaten gebruiken om te ontwaken ... andere iOS-apparaten

In de post ' Staying alive ' van gisteren meldden we dat we dachten dat de iOS-app 'keepalives' gebruikte om achtergrondbeperkingen te omzeilen. Na onderzoek van de broncode van de iOS-app kwamen we tot de conclusie dat dit inderdaad het geval is. Hoe werken ze precies?

Simpel gezegd, een keepalive - in deze context - is een idee dat de ontwikkelaars van de app bedachten: het is een melding die wordt verzonden tussen twee iOS-apparaten die de app uitvoeren om de verbinding tussen de apparaten levend te houden. Het interessante hiervan is dat het ook tot gevolg heeft dat de app aanzienlijk langer wakker blijft, omdat wanneer een apparaat een keepalive ontvangt, iOS de app wakker laat blijven om wat extra verwerking te doen.

Praktisch gezien betekent dit dat de app in staat zal zijn om zijn status te behouden, aangezien hij zich in de buurt van andere apparaten bevindt. Dit is in zekere zin de grondgedachte van het COVID-19-traceringsproject: zelfs zonder deze technische truc zal een kritische massa van gebruikers de tracing-app moeten gebruiken om een goed resultaat voor de openbare veiligheid te bereiken.

Afgezien hiervan valt de app niet meteen in slaap en komt hij niet op de achtergrond als hij op de achtergrond staat. De vraag wordt dus of de meeste gebruikers genoeg iOS- of Android-apparaten zullen hebben om de oplossing mogelijk te maken. Wij zijn van mening dat dit waarschijnlijk lijkt, en des te meer voor gebruikers die vaker in bevolkte gebieden wonen. Bluetooth heeft een behoorlijk effectief bereik.

Enkele waarnemers hebben gesuggereerd dat het vermogen van de app om stille meldingen te ontvangen, betekende dat hij deze mogelijkheden gebruikte om op afstand wakker te worden. Deze mogelijkheden worden echter alleen gebruikt om de gebruiker te informeren of ze in de buurt zijn geweest van iemand die COVID-19 heeft gecontracteerd. De app maakt ook gebruik van lokale meldingen die detecteren wanneer de app door het systeem wordt gedood, en instrueert gebruikers om de app opnieuw te openen. Een soortgelijke melding wordt gebruikt wanneer de gebruiker Bluetooth uitschakelt.

Aidan Fitzpatrick, CEO van Reincubate, zegt:

Ja, het is zo dat het komende Apple ExposureNotification framework in iOS 13.5 de noodzaak van deze keepalives wegneemt. Het is echter vermeldenswaard dat:

• iOS 13.5 is niet uitgebracht en is mogelijk enkele weken niet beschikbaar
• Vóór gisteren had de laatste iOS 13.5-bèta een grote beveiligingsfout , wat suggereert dat er zwaar wordt opgetild in de technische teams van Apple
• Zodra het is uitgebracht, zal het waarschijnlijk maanden duren voordat een meerderheid van iOS-gebruikers het heeft geïnstalleerd (ongebruikelijk, de equivalente Android-acceptatie kan sneller zijn )
• Oudere iOS-apparaten - zoals de iPhone 6 - kunnen iOS 13 niet uitvoeren en zullen de Apple-techniek niet kunnen gebruiken
• Er is geen reden waarom de NHS COVID-19-app in de toekomst niet automatisch kan overschakelen op het gebruik van Apple's framework - of zelfs op beide mechanismen

De app zal steeds effectiever worden naarmate meer mensen hem gebruiken, en het voordeel van massale acceptatie zal in die zin een vliegwieleffect creëren. De Australische COVIDSafe-app had het moeilijk omdat hij geen ondersteuning bood voor het detecteren van iOS-apparaten op de achtergrond vanaf een Android-apparaat, en hij beschikte niet over dit slimme iOS-naar-iOS keepalive-mechanisme.

Het is belangrijk om na te denken over welke omstandigheden gebruik maken van dergelijke technologie. Als contactopsporing succesvol is in het redden van levens, welke criteria moeten dan worden beoordeeld of het wordt toegepast voor toekomstige ziekten? Is er, zodra het precedent is vastgesteld, een argument dat deze technologie kan worden gebruikt om reeds bestaande infectieziekten te bestrijden? Het is te voorzien dat verschillende samenlevingen de afwegingen verschillend zullen evalueren.

Privacybescherming

Hoewel het schrijven van een gedetailleerde analyse van de wiskunde achter het protocol een beetje buiten het bereik van dit bericht valt, hebben we wel gekeken naar privacywaarborgen. De app lijkt zich strikt te houden aan de paper die de NCSC heeft vrijgegeven . We kunnen bevestigen dat geen belangrijke gegevens het apparaat van de gebruiker verlaten totdat ze symptomen melden, en alleen dan doen de geanonimiseerde sleutels van apparaten in de buurt om het apparaat te verlaten. De eerste helft van de door de gebruiker ingevoerde postcode wordt als onderdeel van de registratiedienst naar de API gestuurd.

Uiteindelijk suggereert de code dat er weinig technisch privacyrisico is bij het gebruik van de app totdat een gebruiker symptomen meldt en contact opneemt met de NHS om een test te regelen. Op dat moment zou hun testresultaat worden beheerd door de NHS, hoewel dit niet anders is met of zonder de app . Echter, op het moment dat meerdere gebruikers in contact komen, symptomen melden en testen regelen met behulp van de ID die de app hen heeft gegeven , is het al dan niet mogelijk om ze centraal met elkaar te verbinden. Dat is een back-end vraag, en zoals NHSX in hun app-privacyrapport vermeldt, is code in dit opzicht de waarheid .

Bescherming tegen valse meldingen

Omdat de back-end van het systeem niet open source is, is het niet mogelijk om dit te bevestigen, maar het lijkt erop dat er geen pushmeldingen naar andere apparaten worden verzonden totdat de burgers positief testen op COVID-19. Zodra een gebruiker symptomen meldt, krijgt hij een referentiecode die kan worden gebruikt om een test te boeken. (Deze code is hetzelfde als de linkingId we beschreven hebben in de registratie sectie.)