Une plongée technique approfondie dans l'application de suivi des contacts NHS COVID-19

La version bêta de suivi des contacts NHS COVID-19 est désormais open source pour iOS et Android , ainsi que de la documentation . Pour faire suite à notre article « Rester en vie », nous avons approfondi le code source. Il est agréablement surprenant de le trouver sous licence MIT, indiquant un engagement du NHSX envers la transparence et la qualité.

Au cours des deux derniers jours, un certain nombre d'ingénieurs ont examiné l'application pour découvrir si - et comment! - il est capable de rester en vie. Comprendre cela a nécessité une compréhension plus approfondie du cadre CoreBluetooth pertinent que la plupart des développeurs. Ce n'est pas un cadre dans lequel les ingénieurs doivent généralement se plonger.

Assez tôt, nous avons repéré et signalé comment l'astuce fonctionnait pour les appareils Android. Ce soir, nous partageons ce qui se passe sur iOS. Passons en revue.

Lancement initial

Lors du premier lancement, l'application fait une demande 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é de l'utilisateur entré code postal. En réponse, le serveur répond avec un linkingId qui est stocké dans les paramètres de l'application. L'application demande également des notifications push et des autorisations Bluetooth, comme on pourrait s'y attendre. Il ne demande pas d'autorisations de localisation et, en tant que tel, ne valide pas le code postal de l'utilisateur. Seuls les premiers chiffres d'un code postal sont requis.

Certains prétendent que l'application Android accède aux données de localisation, car l'invite d'accès à l'API Bluetooth sur les appareils Android semble demander des autorisations de localisation. Cependant, nous avons démystifié cela hier: c'est une conséquence de la façon dont Android gère les demandes d'autorisations Bluetooth .

Rester en vie sur Android

Empêcher une application de dormir en arrière-plan est trivial sur Android, car les API stockées prennent en charge cette fonctionnalité, offrant aux ingénieurs un accès de bas niveau au matériel Bluetooth.

Cependant, sur iOS, l'histoire n'est pas aussi simple. Lorsque les applications sont en arrière-plan sur iOS, leurs fonctionnalités sont considérablement réduites. C'est également le cas avec CoreBluetooth , le framework Apple qui permet aux développeurs d'accéder à Bluetooth. En deçà d'une solution de contournement intelligente, cela rend considérablement plus difficile pour l'application de détecter les iPhones qui pourraient fonctionner en mode arrière-plan. Nous avons testé avec un certain nombre d'appareils iOS laissés seuls au cours de plusieurs heures, et avons noté que l'interrogation avait lieu moins fréquemment, mais que les appareils communiquaient toujours pendant la nuit.

Utiliser Android pour réveiller les iPhones

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.

Quelles sont donc les implications de cela? Eh bien, cela signifie que pour que l'application fonctionne, un iPhone doit être à portée d'un appareil Android assez souvent, afin qu'il puisse envoyer des keepalives pour rester en arrière-plan. En soi, ce n'est peut-être pas une solution viable, mais ...

Utiliser des appareils iOS pour réveiller… d'autres appareils iOS

Dans le post d'hier « Rester en vie », nous avons indiqué que nous pensions que l'application iOS utilisait des «Keepalives» pour contourner les restrictions de mise en arrière-plan. Après avoir examiné le code source de l'application iOS, nous avons conclu que c'était effectivement le cas. Mais comment fonctionnent-ils exactement?

En termes simples, une keepalive - dans ce contexte - est une idée que les développeurs de l'application ont proposée: c'est une notification envoyée entre deux appareils iOS exécutant l'application pour maintenir la connexion entre les appareils. La chose intéressante à ce sujet est que cela a également pour effet de permettre à l'application de rester éveillée beaucoup plus longtemps, car lorsqu'un appareil reçoit un Keepalive, iOS permet à l'application de rester éveillée pour effectuer un traitement supplémentaire.

D'un point de vue pratique, cela signifie que l'application sera en mesure de maintenir son état vivant étant donné qu'elle est à proximité d'autres appareils. C'est, en un sens, la raison d'être du projet de traçage COVID-19: même sans cette astuce technique, une masse critique d'utilisateurs devra exécuter l'application de traçage afin d'obtenir un bon résultat en matière de sécurité publique.

Indépendamment de cela, l'application ne s'endort pas immédiatement et n'entre pas dans un état suspendu lorsqu'elle est en arrière-plan. La question devient donc de savoir si la plupart des utilisateurs seront autour de suffisamment d'appareils iOS ou Android pour rendre les solutions de contournement réalisables. Nous pensons que cela semble probable, et ce d'autant plus pour les utilisateurs qui sont plus régulièrement dans les zones peuplées. Bluetooth a une portée efficace décente.

Quelques observateurs ont suggéré que la capacité de l'application à recevoir des notifications silencieuses signifiait qu'elle utilisait ces capacités pour se réveiller à distance. Cependant, ces capacités sont simplement utilisées pour informer l'utilisateur si elles ont été proches de toute personne ayant contracté COVID-19. L'application utilise également des notifications locales qui détectent le moment où l'application est tuée par le système, demandant aux utilisateurs de rouvrir l'application. Une notification similaire est utilisée lorsque l'utilisateur désactive Bluetooth.

Le PDG de Reincubate, Aidan Fitzpatrick, a déclaré:

Oui, il est vrai que le ExposureNotification framework Apple ExposureNotification dans iOS 13.5 élimine le besoin de ces keepalives. Cependant, il convient de noter que:

• iOS 13.5 n'est pas sorti, et ne le sera peut-être pas avant quelques semaines
• Avant hier, la dernière version bêta d'iOS 13.5 comportait une faille de sécurité majeure , suggérant que des efforts importants étaient en cours dans les équipes d'ingénierie d'Apple.
• Une fois qu'il est sorti, il faudra probablement des mois à une majorité d'utilisateurs iOS pour l'installer (exceptionnellement, l'adoption équivalente d'Android peut être plus rapide )
• Les appareils iOS plus anciens - tels que l'iPhone 6 - ne peuvent pas exécuter iOS 13 et ne pourront pas utiliser la technique Apple
• Il n'y a aucune raison pour que l'application NHS COVID-19 ne soit pas en mesure de passer automatiquement à l'avenir à l'utilisation du cadre d'Apple - ou même de double exécuter les deux mécanismes

L'application deviendra de plus en plus efficace à mesure que de plus en plus de personnes l'utiliseront, et l'avantage d'une adoption massive créera un effet de volant dans ce sens. L'application australienne COVIDSafe a connu des difficultés car elle ne prenait pas en charge la détection des appareils iOS en arrière-plan à partir d'un appareil Android, et elle ne disposait pas de ce mécanisme persistant intelligent d'iOS à iOS.

Il est important de réfléchir aux circonstances dans lesquelles une telle technologie est appropriée. Si la recherche des contacts réussit à sauver des vies, quels critères faut-il évaluer pour savoir si elle est appliquée à de futures maladies? Une fois le précédent établi, existe-t-il un argument selon lequel cette technologie pourrait être utilisée pour lutter contre les maladies infectieuses préexistantes ? Il est prévisible que différentes sociétés évalueront les compromis différemment.

Garanties de confidentialité

Bien que la rédaction d'une analyse détaillée des mathématiques derrière le protocole soit un peu hors de portée pour ce post, nous avons examiné les garanties de confidentialité. L'application semble respecter strictement le document publié par le NCSC . Nous pouvons confirmer qu'aucune donnée clé ne quitte l'appareil de l'utilisateur jusqu'à ce qu'ils signalent des symptômes, et ce n'est qu'alors que les clés anonymisées des appareils se trouvent à proximité pour quitter l'appareil. La première moitié du code postal entré par l'utilisateur est envoyée à l'API dans le cadre du service d'enregistrement.

En fin de compte, le code suggère qu'il y a peu de risques techniques de confidentialité liés à l'utilisation de l'application jusqu'à ce qu'un utilisateur signale des symptômes et contacte le NHS pour organiser un test. À ce stade, le résultat de leur test serait géré par le NHS, bien que ce ne soit pas différent avec ou sans l'application . Cependant, au moment où plusieurs utilisateurs entrent en contact, signalent des symptômes et organisent des tests à l'aide de l'identifiant que l'application leur a fourni , il peut ou non être possible de les lier de manière centralisée. C'est une question de fond, et comme le NHSX l'indique dans son rapport sur la confidentialité des applications, le code est vrai à cet égard.

Se prémunir contre les faux rapports

Comme le back-end du système n'a pas été open source, il n'est pas possible de le confirmer, mais il semble qu'aucune notification push ne soit envoyée à d'autres appareils jusqu'à ce que les citoyens soient positifs pour COVID-19. Une fois qu'un utilisateur signale des symptômes, il reçoit un code de référence qui peut être utilisé pour réserver un test. (Ce code se trouve être le même que l' linkingId nous avons décrit dans la section d'inscription.)