Code Review – L’application Alerte Covid

Encore une nouvelle série 😅 Je sais… ça fait plusieurs, mais il y a tellement de choses à dire… Dans cette nouvelle série, j’aimerais regarder du code fait par d’autres, l’analyser et ressortir les points forts et les points faibles. Bref, faire un code review, mais sans prétention. Le but étant de s’amuser autour d’un morceau de code. Donc aujourd’hui, on commence par l’application Alerte Covid.

Qui en est l’auteur?

À la base, CovidShield est une application développée des bénévoles chez Shopify. Elle a été ensuite forkée et adaptée pour le Canada. L’application Alerte Covid qu’on utilise a été développée par Service Numérique Canada (SNC). Cette compagnie développe des solutions numériques avec le gouvernement fédéral. Les équipes sont mixtes, constituées de membres de l’entreprise et du ministère avec lequel ils font affaires.

Vous pouvez consulter leur page GitHub sur laquelle ils publient leurs sources régulièrement.

Les technologies

L’application est constituée de 3 parties, du moins ce qu’on peut voir sur leur GitHub, soit :

• L’application mobile, qu’on doit installer sur nos téléphones
• Le backend, avec lequel communique l’application mobile
• Le portail, l’application pour ceux qui travaillent en santé

Aujourd’hui, on se concentre sur la première. Commençons par la base, depuis un dossier vide :

Première étape, on constate qu’il y a un package.json à la racine. Un rapide coup d’œil nous permet de voir que l’application s’appelle CovidShield et qu’ils ont choisi React Native comme cadre de développement, qui permet d’écrire un seul code en React pour obtenir un build pour iOS et Android.

Allons donc chercher les précieuses dépendances de l’application :

Les tests unitaires

Bon… « juste » 500 mo de dépendances. On peut voir aussi qu’ils ont jest comme dépendance. Jest étant un framework de tests unitaires, voyons voir leur couverture :

13 suites de tests contenant 155 tests. Pour ceux qui ne seraient pas habitué avec jest, après l’exécution, il est possible de consulter un rapport d’exécution. Pour le voir, ouvrez le fichier  coverage\lcov-report\index.html :

Personnellement, la couverture des tests me semble assez intéressante. Bien sûr, on vise 100 %, mais ce n’est pas toujours possible ou pertinent. Un exemple concret de ça serait le bout de code suivant du BackendService :

En utilisant une expression lambda, on crée une fonction anonyme qui n’est pas testable. Pour la rendre testable, il aurait fallu l’extraire dans une méthode de la classe, mais ça n’aurait pas été pertinent de le tester. Cette unique ligne non testée explique le presque 2 % manquant au niveau de la couverture de cette classe.

Un point qui me titille, c’est le seul test qui n’est pas exécuté. Le voici :

Par curiosité, je l’ai activé et j’ai réexécuté les tests pour voir le résultat. Il passe 😅

Comment ça marche?

À partir d’ici, on va plonger dans le code. J’aimerais comprendre comment ils :

• tracent les rencontres entre 2 personnes
• communiquent avec le backend
• annoncent qu’on doit se faire tester
• valident qu’une personne a vraiment la covid

Le traçage via Bluetooth

Ce qu’on nous explique, c’est que l’application émet un code aléatoire via Bluetooth et que les autres téléphones gardent ce code pour une période de 14 jours. Commençons notre recherche dans le ExposureNotificationService.

On peut voir une méthode start() qui semble intéressante. Par contre, elle ne fait qu’appeler une fonction start() sur un objet injecté via le constructeur :

Ceci m’indique que la partie Bluetooth a été relayée à du code natif, et il y a effectivement un bout de code Kotlin qui définit cette classe :

Puis, on se rend vite compte qu’ils délèguent le tout à une librairie tierce qui est injectée via le contexte applicatif :

On peut trouver cette librairie dans le répertoire lib de l’application Android en Kotlin. Cette librairie est aussi open source. Elle a été développée par Google.

On peut donc ici comprendre qu’ils n’ont pas voulu réinventer la roue au risque de faire des erreurs, ce qui est mature comme mentalité.

Communication avec le backend

Il y a quelques points intéressants à valider au niveau de la sécurité dans un appel entre une front et un backend. Premièrement, on s’attend à ce que cette communication soit chiffrée afin d’éviter que quelqu’un puisse intercepter un message pour le lire. Ce qui est le cas ici.

D’ailleurs, si une personne a la possibilité d’intercepter un message, elle pourrait aussi potentiellement modifier la requête et / ou la réponse afin de générer des comportements inattendus. Il faut donc une protection à ce niveau.

Revenons au BackendService. Perso, le nom 😅 mais bon. En regardant son API, on peut voir qu’il y a plusieurs méthodes pour communiquer avec le backend.  Une première méthode  retrieveDiagnosisKeys() permet d’obtenir la liste des codes positifs dans la région. Nous y reviendrons dans la prochaine section.

Une autre méthode attire mon attention. Elle permet d’obtenir les configurations d’exposition, qui sont disponibles ici. Ce qui donne :

Ces configurations servent à mesurer le risque associé à une rencontre avec une autre personne.

Si vous êtes infectés et que vous avez saisi le code de Santé Canada dans l’application, vous recevrez une notification pour transmettre les codes que vous avez croisés, advenant le cas où vous deviez sortir. Ceci est géré par la variable needsSubmission de ExposureStatus. On peut donc comprendre que l’application fonctionne aussi pour les rencontres post-diagnostique.

Avant de traiter la fonction de récupération des cas positifs, traitons la soumissions des numéros aléatoires croisés dans le cas où on serait positif. Encore une fois, ils font preuve d’extrême prudence en implémentant un HMAC sur le corps de la requête avant l’envoi. Ceci permet au serveur de valider que le contenu de la requête n’a pas changé entre l’envoi depuis le téléphone de la personne infectée jusqu’aux serveurs de Santé Canada. De plus, cet encodage du payload utilise un nonce, qui permet d’ajouter un facteur aléatoire afin de complexifier encore plus le processus de décodage.

Annonce qu’on doit se faire tester

Au départ, je pensais à un push du serveur vers notre appareil. J’étais un peu inquiet puisque ça signifierait que le serveur connait notre appareil. Mais ce n’est pas le cas 😛

Par soucis de performance, on récupère uniquement les nouvelles clés. On peut constater ici que l’application fait un GET au serveur, contrairement à ce que je pensais initialement. Non seulement ça, mais ils ont aussi mis un HMAC à la fin de l’URL en chiffrant les paramètres de l’URL. Vous ne pourriez donc pas appeler cette URL sans avoir la clé HMAC qui est évidemment tenue secrète :

Et zut 😛

Validation qu’une personne a réellement la covid

Pour éviter que n’importe qui se déclare positif et sème la zizanie, Santé Canada va créer un code aléatoire à usage unique et vous le remettre. Vous avez la responsabilité de saisir ce code dans l’application, qui va faire un GET au serveur pour valider que ce code est valide.

Si le code est valide, le serveur va retourner des clés de soumission afin d’encrypter le payload. L’utilisation de clés spéciales provenant du serveur pour la soumission me fait penser que les clés sont à usage unique et surtout aléatoire, donc générées à la demande. On pourra valider le tout quand on regardera le code du backend.

Une fois les clés reçues, un ExposureStatus de type ExposureStatusType.Diagnosed est transmis au backend, de la même façon que les autres codes d’exposition sont envoyés (voir plus haut).

Conclusion

Est-ce qu’on peut dire que cette application est sécuritaire? Well… je pense sincèrement qu’il n’y a pas moyen de faire mieux en terme de sécurité pour ce cas d’utilisation précis. Ils ont pris toutes les précautions pour éviter les faux positifs, le spoofing, le man-in-the-middle et probablement bien d’autres qui m’échappent.

Je l’ai installée. Et toi?

Si t’as aimé cet article, je t’invite à t’abonner au blogue pour recevoir les nouveaux articles par courriel. Je t’invite aussi à le partager dans tes réseaux sociaux 🙂