La bêta de l’application de traçage des contacts NHS COVID-19 est désormais open source pour iOS et Android, accompagnée d’une documentation. Dans la continuité de notre article « Rester actif », nous avons plongé dans le code source. C’est une agréable surprise de le trouver sous licence MIT, signe d’un engagement du NHSX en faveur de la transparence et de la qualité.
Au cours des deux derniers jours, plusieurs ingénieurs ont examiné l’application pour savoir si, et comment !, elle parvient à rester active. Le comprendre a exigé une connaissance du framework CoreBluetooth concerné plus approfondie que celle de la plupart des développeurs. Ce n’est pas un framework dans lequel les ingénieurs ont généralement besoin de se plonger.
Assez tôt, nous avons repéré et signalé comment l’astuce fonctionnait sur les appareils Android. Ce soir, nous partageons ce qui se passe exactement sur iOS. Passons-le en revue pas à pas.
Premier lancement
Au premier lancement, l’application envoie une requête PUT à https://api.svc-covid19.nhs.uk/api/devices/registrations avec un code d’activation, un jeton de notification push et la première moitié du code postal saisi par l’utilisateur. En réponse, le serveur renvoie un linkingId qui est stocké dans les réglages de l’application.
L’application demande aussi les autorisations pour les notifications push et le Bluetooth, comme on pouvait s’y attendre. Elle ne demande pas l’autorisation de localisation et ne valide donc pas le code postal de l’utilisateur. Seuls les premiers chiffres d’un code postal sont requis.
Certains ont affirmé que l’application Android accédait aux données de localisation, car l’invite d’accès à l’API Bluetooth sur les appareils Android semble demander l’autorisation de localisation. Nous avons toutefois démenti cela hier : c’est une conséquence de la façon dont Android gère les demandes d’autorisation Bluetooth.
Rester actif sur Android
Empêcher une application de se mettre en veille en arrière-plan est trivial sur Android, car les API standard prennent en charge cette fonctionnalité et donnent aux ingénieurs un accès de bas niveau au matériel Bluetooth.
Sur iOS, en revanche, la situation n’est pas aussi simple. Lorsque les applications passent en arrière-plan sur iOS, leurs fonctionnalités sont considérablement réduites. C’est également le cas de CoreBluetooth, le framework d’Apple qui donne aux développeurs accès au Bluetooth. Sans contournement astucieux, il est nettement plus difficile pour l’application de détecter les iPhone qui fonctionnent peut-être en mode arrière-plan. Nous avons testé plusieurs appareils iOS laissés tranquilles pendant plusieurs heures, et constaté que les interrogations étaient moins fréquentes, mais que les appareils communiquaient quand même pendant la nuit.
Utiliser Android pour réveiller les iPhone
Hier, nous avons aussi indiqué qu’en arrière-plan, les applications iOS continuent de diffuser des annonces Bluetooth, mais d’une manière différente, propre à Apple. Nous pensions que les ingénieurs du NHSX et de Pivotal avaient fait de la rétro-ingénierie à ce sujet et ajouté sa prise en charge à l’application Android. Nous pouvons confirmer que c’est bien le cas, et leurs détails techniques se trouvent ici. Cela signifie qu’en plus de la capacité des appareils iOS à maintenir l’application en arrière-plan, les appareils Android peuvent réveiller un appareil iOS « endormi », quelle que soit la durée pendant laquelle il est resté en arrière-plan.
Quelles en sont donc les implications ? Eh bien, pour que l’application fonctionne, un iPhone doit se trouver assez souvent à portée d’un appareil Android, afin de recevoir des keepalives qui le maintiennent en arrière-plan. Cela ne constitue peut-être pas à soi seul une solution viable, mais...
Utiliser des appareils iOS pour réveiller… d’autres appareils iOS
Dans l’article d’hier « Rester actif », nous indiquions que, selon nous, l’application iOS utilisait des « keepalives » pour contourner les restrictions de l’arrière-plan. Après avoir examiné le code source de l’application iOS, nous avons conclu que c’est bien le cas. Mais comment fonctionnent-ils exactement ?
Pour faire simple, un keepalive, dans ce contexte, est une idée qu’ont eue les développeurs de l’application : c’est une notification envoyée entre deux appareils iOS exécutant l’application afin de maintenir la connexion entre eux. Ce qui est intéressant, c’est que cela permet aussi à l’application de rester active beaucoup plus longtemps : lorsqu’un appareil reçoit un keepalive, iOS autorise l’application à rester éveillée pour effectuer un traitement supplémentaire.
Concrètement, cela signifie que l’application pourra rester active tant qu’elle se trouve à proximité d’autres appareils. C’est, en un sens, la logique même du projet de traçage COVID-19 : même sans cette astuce technique, une masse critique d’utilisateurs devra utiliser l’application de traçage pour obtenir un bon résultat en matière de sécurité publique.
Quoi qu’il en soit, l’application ne s’endort pas immédiatement ni n’entre en état suspendu lorsqu’elle passe en arrière-plan. La question devient donc de savoir si la plupart des utilisateurs se trouveront à proximité d’assez d’appareils iOS ou Android pour que les contournements fonctionnent. Nous pensons que c’est probable, et d’autant plus pour les utilisateurs qui se trouvent plus régulièrement dans des zones peuplées. Le Bluetooth a une portée effective honorable.
Quelques observateurs ont suggéré que la capacité de l’application à recevoir des notifications silencieuses signifiait qu’elle utilisait ces possibilités pour se réveiller à distance. Or ces possibilités servent simplement à indiquer à l’utilisateur s’il a été proche de quelqu’un ayant contracté la COVID-19. L’application utilise aussi des notifications locales qui détectent lorsque l’application est fermée par le système et invitent les utilisateurs à la rouvrir. Une notification similaire est utilisée lorsque l’utilisateur désactive le Bluetooth.
Le PDG de Reincubate, Aidan Fitzpatrick, déclare :
Oui, il est vrai que le futur framework
ExposureNotificationd’Apple dans iOS 13.5 supprime le besoin de ces keepalives. Il convient toutefois de noter que :
- iOS 13.5 n’a pas été publié, et ne le sera peut-être pas avant plusieurs semaines
- Jusqu’à hier, la dernière version bêta d’iOS 13.5 présentait une faille de sécurité majeure, ce qui suggère un gros travail en cours dans les équipes d’ingénierie d’Apple
- Une fois publié, il faudra probablement des mois pour que la majorité des utilisateurs d’iOS l’installent (fait inhabituel, l’adoption équivalente sur Android pourrait être plus rapide)
- Les appareils iOS plus anciens, comme l’iPhone 6, ne peuvent pas exécuter iOS 13 et ne pourront pas utiliser la technique d’Apple
- Rien n’empêche l’application NHS COVID-19 de passer automatiquement à l’avenir au framework d’Apple, ni même de faire fonctionner les deux mécanismes en parallèle
L’application gagnera en efficacité à mesure que davantage de personnes l’utiliseront, et l’intérêt d’une adoption massive créera en ce sens un effet de volant d’inertie. L’application australienne COVIDSafe a peiné car elle ne permettait pas de détecter depuis un appareil Android des appareils iOS en arrière-plan, et ne disposait pas de ce mécanisme astucieux de keepalive entre appareils iOS.
Il est important de réfléchir aux circonstances dans lesquelles l’usage d’une telle technologie est approprié. Si le traçage des contacts réussit à sauver des vies, quels critères faut-il évaluer pour décider de l’appliquer à de futures maladies ? Une fois le précédent établi, peut-on soutenir que cette technologie pourrait servir à combattre des maladies infectieuses préexistantes ? Il est prévisible que des sociétés différentes évalueront les compromis différemment.
Garanties de confidentialité
Rédiger une analyse détaillée des mathématiques du protocole dépasse un peu le cadre de cet article, mais nous avons examiné les garanties de confidentialité. L’application semble respecter scrupuleusement le document publié par le NCSC. Nous pouvons confirmer qu’aucune donnée de clé ne quitte l’appareil de l’utilisateur tant qu’il n’a pas signalé de symptômes, et que ce n’est qu’à ce moment-là que les clés anonymisées des appareils avec lesquels il a été en contact étroit quittent l’appareil. La première moitié du code postal saisi par l’utilisateur est envoyée à l’API dans le cadre du service d’enregistrement.
En définitive, le code suggère que l’utilisation de l’application présente peu de risque technique pour la vie privée, jusqu’à ce qu’un utilisateur signale des symptômes et contacte le NHS pour organiser un test. À ce stade, le résultat de son test est géré par le NHS, ce qui n’est pas différent avec ou sans l’application. Cependant, lorsque plusieurs utilisateurs entrent en contact, signalent des symptômes et organisent des tests en utilisant l’identifiant que l’application leur a fourni, il peut être possible, ou non, de les relier de manière centralisée. C’est une question de back-end, et comme l’indique le NHSX dans son rapport sur la confidentialité de l’application, le code fait foi à cet égard.
Se prémunir contre les faux signalements
Le back-end du système n’ayant pas été publié en open source, il n’est pas possible de le confirmer, mais il semble qu’aucune notification push ne soit envoyée aux autres appareils tant que les citoyens ne sont pas testés positifs à la COVID-19. Dès qu’un utilisateur signale des symptômes, il reçoit un code de référence qui peut servir à réserver un test. (Ce code correspond en fait au linkingId que nous avons décrit dans la section sur l’enregistrement.)
