Reconstructie

Reconstructie: Hoe de technologie achter de (Belgische) corona-app tot stand kwam.

09.09.2020

Eind september lanceert, als alles volgens plan gaat, de overheid de Belgische app voor contactopsporing. Daarmee is België één van de traagste leerlingen van de klas, maar de corona-app kwam in veel landen met horten en stoten tot stand. Sommige landen gingen overhaast van start, vaak met een focus enkel op de technologie (‘op welke manier kunnen we zien met wie een besmette persoon contact heeft gehad?’), waarbij privacy soms op een tweede plaats kwam. Zo werden er in onder andere Noorwegen en Nederland meerdere apps ontwikkeld en voorgesteld die vaak om privacy redenen afgekeurd werden. Snel werd op Europees niveau een protocol uitgewerkt om de ontwikkeling van de corona-apps te stroomlijnen, en ontstond er ook een uniek samenwerking tussen de techgiganten Google en Apple. Een reconstructie.

Bluetooth als geprefereerde technologie

Bepaalde van de eerste apps gebruikten locatiegegevens om contacten na te gaan. Hoewel deze vorm van contactopsporing valabel lijkt, werd er al snel gewezen op de ontoereikende accuraatheid van locatie-technieken op basis van GPS- en GSM-signalen. Naast deze technische bedenkingen zet het constant volgen van gebruikers van dergelijke app ook de deur open voor potentieel significante privacy-problemen. Men moest dus op zoek naar een andere, accuratere manier om contacten te traceren, die ook conform was met GDPR-regels en verwachtingen van de bevolking.

De oplossing lag bij het gebruik van bluetooth-technologie voor de uitwisseling van geanonimiseerde bluetooth-codes tussen smartphones van gebruikers die een bepaalde tijd in korte afstand van elkaar zijn geweest. Ook hier zijn er vragen over de accuraatheid van bluetooth: de uitvinders zelf verklaarden dat de technologie niet is ontwikkeld om afstanden precies te bepalen. Toch stellen zij vast dat bluetooth te verkiezen is boven het gebruik van privacy-onvriendelijke locatie technologieën.

Om ervoor te zorgen dat deze technologie over de Europese landsgrenzen conform aan de GDPR regelgeving werkt, werd op 1 april 2020 het ‘Pan-European Privacy-Preserving Proximity Tracing’ (PEPP-PT) consortium in het leven geroepen. Al snel groeide het consortium uit tot een samenwerking tussen meer dan 200 technologen, juridische experten, ingenieurs en epidemiologen van verschillende landen en universiteiten. Onder het PEPP-PT consortium werden twee protocollen voor de werking van een contact-tracering app op basis van bluetooth voorgesteld: het ‘Decentralized Privacy-Preserving Proximity Tracing’ (DP-3T) protocol (4 april 2020) en het ‘ROBust and privacy-presERving proximity Tracing’ (ROBERT) protocol (18 april 2020).

Het verschil tussen beide protocollen ligt in de manier waarop de back-end (de server) werkt en welke taak deze opneemt/uitvoert. Om dat in detail te begrijpen, is het belangrijk het onderscheid tussen ‘bluetooth-codes’ en ‘bluetooth contact-codes’ te maken: ‘Bluetooth-codes’ zijn codes die de gebruiker zelf verstuurt naar andere personen. ‘Bluetooth contact-codes’ zijn codes die de gebruiker van andere personen ontvangt als zij gedurende een bepaalde tijd contact hadden.

Gecentraliseerd of gedecentraliseerd?

Gecentraliseerd systeem

ROBERT is een gecentraliseerd systeem waarbij de app de gebruiker met een centrale server verbindt. Deze server wijst de gebruiker een permanente ID (een pseudoniem) toe en stuurt een lijst met tijdelijke ID's (= bluetooth-codes) naar de app op de smartphone. Deze tijdelijke ID’s worden in een logboek op de server bewaard en zijn verbonden met je permanente ID. Vervolgens worden deze tijdelijke ID’s uitgewisseld met mensen waarmee de gebruiker in contact komt.

Wanneer een gebruiker corona-positief is kan die instemmen om de lijst van verzamelde tijdelijke ID’s van andere gebruikers (= bluetooth contact-codes) te delen met de server. De server controleert dan in het logboek aan welke permanente ID de gedeelde tijdelijke ID’s toebehoren. Als het risico op besmetting hoog genoeg wordt geacht door algoritmen op de server, wordt een melding verstuurd naar de app van de risico-contacten met informatie over een mogelijke besmetting.

Voordeel:

  • Er is maar één toegangspoort die moet worden afgesloten en beveiligd, namelijk de server.

Nadelen:

  • Gezien de uitgedeelde en verzamelde bluetooth-codes afgeleid/gelinkt zijn uit/met de permanente ID en beide verzameld worden op de server kan iemand met kennis van de encryptie-sleutel en toegang tot de server technisch gezien de identiteit van gebruikers en hun contacten achterhalen.
  • Een afgesloten server maakt toezicht moeilijk voor externe, onafhankelijke organisaties of privacy-waakhonden. Zij krijgen geen of weinig zicht op de interne werking van het systeem, wat er verzameld wordt en wie toegang krijgt.

Gedecentraliseerd systeem

DP-3T is een gedecentraliseerd systeem waarbij de tijdelijke ID’s niet door een centrale server maar door je smartphone gecreëerd worden. Je smartphone houdt zelf een logboek bij van al de codes die de laatste 14 dagen zijn aangemaakt en uitgestuurd, en de codes die je van personen met wie je in contact kwam, hebt ontvangen.

De app controleert op eventuele besmetting door minstens één keer per dag de bluetooth-codes van besmette mensen te downloaden en deze lijst te vergelijken met de lijst van bluetooth contact-codes op je smartphone. Als er overeenkomstige codes in beide lijsten voorkomen, brengt de app je op de hoogte van een mogelijke besmetting. Als je later positief test voor corona, kan je kiezen om jouw persoonlijke bluetooth-codes door te geven. De server ontvangt dus jouw eigen bluetooth-codes die je de afgelopen 14 dagen naar andere gebruikers gestuurd hebt.

Voordeel:

  • Het versleutelen van de verstuurde bluetooth-codes en het opslaan van de ontvangen bluetooth contact-codes gebeurt op je persoonlijke smartphone. Er is bijgevolg geen logboek op een centrale server nodig.

Nadeel:

  • Omdat elke individueel geïnstalleerde corona-app verantwoordelijk is voor het versleutelen en opslaan van de bluetooth-codes, is elke download van de app een potentiële toegangspoort waarlangs een hacker informatie kan inwinnen.

Gedecentraliseerd wint, voornamelijk toch.

De oprichters van PEPP-PT gaven de voorkeur aan het ROBERT protocol en besloten om dit gecentraliseerde systeem te promoten in de media en bij overheden. Dit was niet naar de zin van meer dan 300 onderzoekers uit tientallen landen, waaronder velen die lid waren van PEPP-PT. Om deze reden brachten ze op 19 april 2020 een publiek statement naar buiten . Hoewel PEPP-PT en ROBERT niet bij naam vernoemd worden, waarschuwden de ondergetekenden voor gecentraliseerde oplossingen die een ongekend toezicht op de samenleving mogelijk maken. Met andere woorden, ze waarschuwden voor het risico op het mechanisme van de ‘function creep’, waarbij de app voor verregaandere doeleinden zou worden aangewend dan aanvankelijk beoogd. Op 20 april 2020 publiceerde CISPA een persbericht dat ze zich terugtrokken uit het PEPP-PT consortium. Dit veroorzaakte een domino-effect waardoor het merendeel van de overige leden van het consortium ook besloten zich terug te trekken uit PEPP-PT en zich vanaf dan enkel te richten op de verdere ontwikkeling van het DP-3T protocol.

Toch was ook het DP-3T protocol niet optimaal qua beveiliging: er moest een oplossing komen voor het geval de app zelf gehackt werd. Door in te breken in de app kon een hacker namelijk toegang krijgen tot het versleutelingsalgoritme van de app. Hierdoor kan iemand, met voldoende vastberadenheid en technisch inzicht, de versleutelde bluetooth-codes ontcijferen en op die manier de contacten van de gehackte persoon te weten komen. Om hier een doorbraak mogelijk te maken, moest men een beroep kunnen doen op het besturingssysteem van de smartphone.

DP-3T + Apple/Google = ENS

Op 10 april 2020 stelde Apple en Google, in een uitzonderlijke samenwerking tussen de twee techgiganten, gezamenlijk ‘Exposure Notification System’ (ENS) voor. ENS is geïnspireerd en beïnvloed door het DP-3T protocol. Net zoals DP-3T, is ENS een gedecentraliseerd systeem waarbij bluetooth-codes uitgewisseld worden tussen de smartphone van gebruikers. Waar de twee in verschillen is in de manier waarop de encryptie van deze bluetooth-codes gebeurt. Bij DP-3T wordt de encryptie gedaan door de app. ENS voert de encryptie van de bluetooth-codes uit in het besturingssysteem zelf.

ENS is veiliger want om toegang te krijgen tot deze gegevens, moet een hacker inbreken in het besturingssysteem (iOS of Android) zelf. Gezien de knowhow en investeringen van Apple en Google op vlak van beveiliging, is dat voor hackers een veel moeilijkere, bijna onmogelijke opdracht. Een bijkomend voordeel van ENS is dat het gaat om een universeel systeem dat op alle ondersteunde iPhones en Android toestellen op dezelfde manier zorgt voor de versleuteling, uitwisseling en opslag van bluetooth-codes. Op deze manier kunnen de verschillende apps van de landen die het systeem gebruiken met elkaar communiceren.

Documentatie over ENS kan je op deze website van Apple vinden

Deze website van Google geeft een helder overzicht van wat het ENS wel en niet doet, net als dit filmpje (beide in het Engels).

De Belgische app: CoronAlert

De Belgische app zal ‘CoronAlert’ heten en vermoedelijk eind september beschikbaar zijn. De ontwikkeling van de app gebeurt door Devside uit Brussel. Naar aanleiding van de ontwikkeling van de app is een publieke consultatie uitgevoerd rond de concrete eigenschappen van de app en het bijbehorende beleid.

België heeft, zoals het merendeel van de Europese landen, gekozen om gebruik te maken van ENS voor het ontwikkelen van hun corona-app. Dit informatiefilmpje van de Zwitserse ‘SwissCovid’-app geeft meer informatie over de werking van een corona-app die ENS gebruikt.

Tot slot geven we ook onderstaande cartoon nog mee, die op een ludieke manier toont hoe de Belgische CoronAlert-app zal werken.