Revue rapide de l’application mobile Coronalert.be

Le but de l’application Coronalert (covid-be-app) est de couper la chaîne de propagation du Covid19 en vous signalant un contact que vous auriez eu avec une personne contaminée au cours des deux dernières semaines.

Ceci est réalisé par l’enregistrement des contacts rapprochés (+/- <1.5m) grâce à la technologie Bluetooth Low Energy (BLE). Chaque téléphone possédant l’application va émettre un signal de balise, tout en écoutant les balises émises par les autres téléphones.

L’application sur le smartphone est censée enregistrer des identifiants anonymes et uniques contenu dans ces balises émises par les autres téléphones. Seul l’identifiant de balise est censé être transmis et non des informations personnelles.

Quotidiennement, l’application va télécharger une liste d’identifiants secrets qui correspondent à des personnes contaminées. L’application va alors comparer ces identifiants avec ceux qu’elle a croisé dans la vie réelle au cours des 14 derniers jours.

Coronalert est en réalité une modification d’une application créée en Allemagne par le Robert Koch Institut. Celle-là étant en licence Open Source, un groupe de développeurs belges l’a reprise pour le compte de Sciensano et l’a adaptée à la Belgique (traductions dans les langues nationales, adaptation aux protocoles de santé belges, communication avec les serveurs belges de Sciensano, etc.)

Dans cet article, je passerai en revue les points qui, à mes yeux, pourraient poser un problème de vie privée.

Ressources

[1] Page de développement: https://devside.atlassian.net/wiki/spaces/CD/overview

[2] Code source de l’application Android (24/09/2020): https://github.com/covid-be-app/cwa-app-android

[3] Exposure notification API:
https://www.google.com/covid19/exposurenotifications/

[4] Nomenclature des variables: https://devside.atlassian.net/wiki/spaces/CD/pages/34704/Naming+conventions

[5] Différences entre la version allemande et la version belge:
https://devside.atlassian.net/wiki/spaces/CD/pages/4161588/BE+-+DE+differences

[6] Protocole de l’Exposure Notification Service (Avril 2020):
https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf?1

Objectifs

Mon but n’est pas de réaliser une revue complète du code, ni de faire un audit de sécurité de l’application, ni de détecter du code caché.

Je me limiterai à l’application Android, car le développement d’applications iOS est hors de mon domaine de compétence.

Je souhaite ici connaître:

• Quelles sont les permissions requises sur Android et si l’application a accès aux contacts du téléphone
• Quelles données seront envoyées à l’extérieur, c’est à dire sur des serveurs distants pour lesquels je n’ai pas de regard sur la conservation des données.
• Qu’est ce qui est communiqué par Bluetooth, puisque c’est ainsi que les téléphones vont détecter les rapprochements.

Méthode

Je vais donc aller récupérer le code source de l’application Android et analyser certains points bien précis.

Après l’importation du code source dans l’éditeur de code « IntelliJ IDEA », nous nous trouvons face à cet écran.

Grâce à IntelliJ et au système de partage de code source (appelé Git), on peut également consulter l’historique de modification de l’application et voir qui a modifié quoi dans l’application:

Permissions demandées par l’application

Avant de démarrer, l’application Android doit fournir un manifeste déclarant quelles permissions elle compte demander au téléphone. Cela peut être l’utilisation de la caméra, l’envoi de SMS, la demande de localisation GPS, etc.

En ouvrant le manifeste AndroidManifest.xml, nous obtenons la liste de tous les accès que l’application pourrait obtenir:

<uses-permission
    android:name="android.permission.CAMERA"
    tools:node="remove" />

<uses-feature
    android:name="android.hardware.bluetooth_le"
    android:required="true" />
<uses-feature android:name="android.hardware.bluetooth" />

<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission
    android:name="android.permission.BLUETOOTH"
    android:required="true" />
<uses-permission
    android:name="android.permission.INTERNET"
    android:required="true" />

<uses-permission android:name="android.permission.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS" />

<uses-permission android:name="android.permission.WAKE_LOCK" />

On voit donc que l’application va demander:

• Un accès au bluetooth, pour obtenir l’état du Bluetooth. C’est également le coeur de l’application: détecter d’autres smarpthones à proximité, utilisant la même application
• Un accès à la vérification de présence d’internet (wifi ou cellulaire)
• Un accès à internet, pour envoyer et recevoir des données
• Une demande pour ignorer les optimisations de la batterie, peut-être pour que l’application ne soit pas mise en veille, et continue ainsi à détecter la proximité d’autres télépones.
• Une demande pour gérer l’énergie du téléphone également (CPU,etc.)

Par contre, l’application ne demande pas l’accès à la camera, en effet, le code de l’application allemande en avait besoin pour scanner des QR code, mais pas la belge. La permission requise dans l’application allemande est explicitement supprimée par la présence de l’élément ‘tools:node= »remove »‘. (Merci à Bart pour son explication)

Comme ils ne sont pas listés, l’application ne demande pas:

• La localisation précise par GPS
• L’accès au répertoire téléphonique

Echanges de données par Internet

Nous allons vérifier quelles données sont échangées par l’application et où ces données vont être envoyées.

Récupération des destinataires

Voulant connaître quels serveurs vont être contactés, je vais donc rechercher toute chaîne de caractères (texte) contenant http:// ou https://.

Ce qui m’intéresse, ce sont les adresses URL vers lesquelles des données personnelles peuvent être envoyées, par exemple avec le protocole REST, qui se base sur http(s).

J’ai donc exclu les liens à cliquer dans des pages html embarquées ou des références à des licences logicielles.

Exemple de lien ignoré:

<string name="main_about_link">https://coronalert.be/nl/faq-nl/</string>

J’ai également exclu les fichiers de test unitaires de l’application. Ces fichiers permettent d’automatiser les tests de l’application en simulant une utilisation correcte ou erronnée de l’application. Ils ne sont normalement pas intégrés dans l’application finale déployée sur le téléphone.

Sonar étant une application connue des développeurs servant à l’analyse statique de code, j’ai exclu l’url contenue dans sonar-project.properties : sonar.host.url=https://sonarcloud.io

Autres URL trouvées dans le code, que je ne regarderai pas beaucoup plus loin: l’adresse permettant à l’application de rechercher des mises à jour:

 const val STORE_PREFIX = "https://play.google.com/store/apps/details?id="

Dans le fichier gradle.properties, je découvre des adresses HTTP de différents serveurs, liées à des constantes (On peut voir cela comme des aliases)

SUBMISSION_CDN_URL=https://c19-submission-stg.ixor.be DOWNLOAD_CDN_URL=https://c19distcdn-stg.ixor.be VERIFICATION_CDN_URL=https://c19-verification-stg.ixor.be STATISTICS_CDN_URL=https://c19statcdn-stg.ixor.be

Ixor est une boîte de consultance en informatique basée à Mechelen, en Belgique. Je ne sais pas si ces adresses resteront dans la version définitive de l’application.

Utilisation de ces URLs

Ceci n’était que la première étape. Nous connaissons les destinataires, mais nous ne connaissons pas le contenu.

Après avoir trouvé ces 4 adresses, je vais maintenant relancer une recherche sur ces constantes associées, pour trouver où elles sont utilisées dans le code. En effet, le programme mentionnant une constante telle que SUBMISSION_CDN_URL va en réalité la remplacer par https://c19-submission-stg.ixor.be lorsque l’application s’exécutera.

De fils en aiguilles, je vais remonter l’arbre utilisant ces URLs. Tel bout de code appelle tel bout de code, qui appelle un autre bout de code qui utilise cette URL représentée par la constante en question. Je pars donc de la fin (l’adresse) et je remonte jusqu’au code utilisant cette adresse.

URL de submission de données (SUBMISSION_CDN_URL)

Cette constante est mélangée à d’autres pour former l’URL complète, sauvée dans une nouvelle constante DIAGNOSIS_KEYS_SUBMISSION_URL.

DIAGNOSIS_KEYS_SUBMISSION_URL est ensuite utilisée dans le code suivant:

val submissionPayload = KeyExportFormat.SubmissionPayload.newBuilder()
    .addAllKeys(keyList.map { it.first })
    .addAllCountries(keyList.map { it.second })
    .setPadding(getPadding(keyList.size))
    .build()

beSubmissionService.submitKeys(
    BeDiagnosisKeyConstants.DIAGNOSIS_KEYS_SUBMISSION_URL,
    k, r0, t0, t3, resultChannel,
    submissionPayload
)

Le submissionPayload est le contenu, tandis que beSubmissionService.submitKeys() envoie le contenu à l’adresse retenue derrière DIAGNOSIS_KEYS_SUBMISSION_URL

Qu’est-ce qui est donc envoyé dans ce premier Payload?

@Url url: String,
@Header("Secret-Key") k: String,
@Header("Random-String") r0: String,
@Header("Date-Patient-Infectious") t0: String,
@Header("Date-Test-Communicated") t3: String,
@Header("Result-Channel") channel: Int,
@Body requestBody: KeyExportFormat.SubmissionPayload

Le contenu principal est celui portant le libellé @Body (SubmissionPayload), mais nous voyons également que l’on envoie quelques données supplémentaires, comme une clé secrète, une chaîne de caractère aléatoire, deux dates et un numéro de canal pour le résultat.

En remontant le code (tel une rivière), j’ai trouvé que le contenu principal de cet envoi (contenu dans « requestBody ») était liste de paires « temporaryExposureKey » (TEK) et « Country ».

Que ce sont les temporaryExposure Keys (TEK) ?
Ces clés sont une suite de nombres ou de caractères permettant d’identifier un téléphone lorsqu’il croise un autre téléphone à un distance suffisamment courte pour être un contact à risque, susceptible de transmettre le virus. Mais, à des fins de protection de la vie privée, ces clés sont régulièrement renouvellées. Cette technologie de clé a été développée par Google dans un but de pseudonymisation, voir d’anonymisation. Vous trouverez plus d’information sur cette technologie logicielle dans le lien [3] situé plus haut.

Il restait alors à vérifier que les autres variables @Header ne contiennent pas d’informations privées ou uniques et répétitives qui permettraient d’identifier le propriétaire du téléphone. Ces données font partie d’un groupe de données identifiés par MobileTestId

Le mobileTestId contient:

• Le k qui est une clé AES sur 128 bits
• Le t0 qui est effectivement une date (censée être la date de visite chez le médecin)
• Le t3 qui est également une date (censée être la date du résultat du test)
• Le R0 qui est une chaîne de caractères aléatoire
• Le R1 qui est également un élément aléatoire

Plus d’informations sont disponibles dans la ressource documentaire [4].

L’envoi de données à c19-submission-stg.ixor.be ne semble donc pas contenir d’informations discriminantes ou personnelles.

URL de téléchargement de données (DOWNLOAD_CDN_URL)

En utilisant la même technique que pour la première adresse internet, je suis remonté à ces utilisations:

• getApplicationConfiguration: Obtention d’informations de configuration de l’application depuis le serveur.
• getKeyFiles: Obtention d’un fichier zip contenant des clés TemporaryExposureKeyExport (contenant probablement les clés des personnes testées positives)
• getHourIndex: Obtention d’un index d’heure (?)
• getDateIndex: Obtention d’un index de date (?)

URL de vérification (VERIFICATION_CDN_URL)

Pour cette adresse, les services proposés et utilisés par l’application sont les suivants, liés à l’obtention des résultats de test covid (ex: PCR)

• getRegistrationToken: Obtention d’un jeton d’inscription (token) unique. Une fois que l’application l’a reçu, je pense que vous pouvez donner ce jeton en allant passer un test PCR, et ainsi obtenir le résultat par l’application.
• getTestResult: Probablement utilisé pour obtenir en ligne le résultat de votre test de positivité. Pour l’obtenir, l’application envoie la clé d’inscription (token) et obtient en retour le résultat de test. Sans le jeton, on ne peut donc pas connaître le résultat de test.
• getTAN: Obtention du Transaction Authentication Number. Un numéro d’authentification qui offre une protection supplémentaire dans une communication. Il doit accompagner les TEK des 14 derniers jours pour signaler que vous êtes légitime d’envoyer ces données et ainsi éviter que des personnes mal intentionnées envoient des faux positifs. (merci à Laurent pour m’avoir lancé sur la piste.)

L’application contient en effet la possibilité (acte volontaire du patient) de générer un code à donner lors du passage du test PCR et permet d’obtenir le résultat plus rapidement.

URL de statistiques (STATISTICS_CDN_URL)

Un seul service proposé, l’obtention de données de statistiques, qui ressemblent fortement aux chiffres quotidiens de Sciensano:

val averageInfected: Int,
val averageInfectedChangePercentage: Int,
val averageHospitalised: Int,
val averageHospitalisedChangePercentage: Int,
val averageDeceased: Int,
val averageDeceasedChangePercentage: Int,
val startDate: String,
val endDate: String

Nous avons terminé le tour des données échangées en http. Nous savons maintenant que l’application ne transmet pas de données personnelles par ce canal.

Echange de données par Bluetooth

Pour capturer l’identifiant des téléphones croisés à moins d’un mètre cinquante, l’application utilise des balises (beacons) Bluetooth.

A quoi ressemble une balise Bluetooth (beacon)? Il s’agit d’un petit packet de données émis par Bluetooth à intervalles réguliers (par exemple toutes les 200ms ou 1 seconde…). Beaucoup d’appareils émettent déjà des beacons, comme les ordinateurs portables. Un beacon pourrait par exemple servir à envoyer du contenu publicitaire sur le téléphone, lorsque vous vous approchez d’un magasin.

Ce principe de balise a été inventé il y a plusieurs années avec l’apparition du nouveau standard BLE (Bluetooth Low Energy). Lorsqu’une balise est reçue, le téléphone lit son contenu (appelé payload ou message) ainsi qu’une indication de la puissance du signal reçu (RSSI). Ce RSSI permet de calculer une distance approximative de la source de la balise, et donc de la distance entre les deux téléphones.

En 2020, Apple et Google ont spécifié un nouveau type de message beacon échangeable entre smartphones: l’Exposure Notification. Il a été développé spécifiquement dans la lutte contre la pandémie de Covid19.
Le protocole Bluetooth Exposure Notification permet de mémoriser les smartphones que vous avez croisé durant les deux dernières semaines, sans toutefois révéler l’identité de ces personnes croisées.

L’application Coronalert ne gère pas l’échange de balises Bluetooth, mais elle demande l’activation de celui-là à Android (ou iOS). En pratique, elle appelle les Google Play Services fournis avec le système Android. Les « Google Play Services » proposent des fonctionalités supplémentaires au téléphone et sont mis à jour automatiquement. C’est pour cela que votre smartphone est capable de gérer le nouveau protocole Exposure Notification.

Comment savoir ce qui est émis par Bluetooth? Comme nous savons que l’application ne va pas transmettre de données personnelles, je vais maintenant l’installer sans avoir peur que mes données personnelles soient envoyées. Ensuite, je capturerai les balises (beacons) transmises par le téléphone et j’en vérifierai le contenu.

Grâce à une application appelée nRF Connect et exécutée sur un autre smartphone qui ne dispose pas de l’application Coronalert, je peux vérifier quelles balises Bluetooth sont émises autour de moi. Grâce au chapitre Advertising Payload du document [6], je sais que l’identifiant du service est 0xFD6. Dans nRF Connect, parmis toutes les balises détectées, je vais chercher celle(s) dont le service est 0xFD6F.

Advertising Payload: le contenu de la balise bluetooth

Contenu de la balise émise par le téléphone « Coronalert », vue sur un deuxième téléphone exécutant nRF Connect

Quel est le contenu? Dans « Data », nous voyons qu’il s’agit d’une suite de caractères hexadécimaux: 5D BD …

Difficile d’en comprendre le contenu à première vue, mais on voit que la longueur de la data émise par la balise correspond à la longueur de la spécification, à savoir 16 octets pour le Rolling Proximity Identifier et 4 octets pour l’associated encrypted metadata. Un octet étant représenté par 2 caractères hexadécimaux. (Il faut ignorer le 0x, car c’est une convention d’affichage, signifiant simplement que la suite est du code hexadécimal, et ne fait pas partie des données transmises).

Comme un caractère d’un jeu de donnée, telle une lettre d’un email ou le chiffre d’un numéro de téléphone, prend au minimum un octet, on voit donc qu’il n’y a quasiment pas de place pour intégrer des données personnelles en plus des clés tournantes. Le téléphone ne transmet donc pas de données privées aux autres téléphones environnants.

Conclusion

Sur base de cette analyse, nous avons vu que le code Open Source de l’application Coronalert ne communique pas plus d’informations qu’annoncé. Seuls des identifiants générés aléatoirement sont échangés entre les téléphones disposant de Coranalert et les serveurs de Sciensano ou Ixor.

Le Google Play Service est un peu plus obscur car le code source n’est pas exposé (edit: dans le code de l’application principale. On peut trouver le code de Exposure Notification ici – merci Frederik pour son commentaire). Mais nous avons pu voir que le téléphone ne faisait qu’échanger une courte donnée par Bluetooth, qui n’est pas suffisamment grande pour envoyer des données personnelles autres que des clés anonymes.
Il est toujours possible que les Google Play Services envoient des informations à Google par internet, mais ceci est déjà le cas pour sauver l’historique de vos positions GPS, par exemple. Il n’y a pas de nouveauté en terme de vie privée par rapport à ce que vous autorisiez avant.

Il est important de noter que les Google Play Services gèrent seulement la communication de balises entre les téléphones, et non les résultats de test de positivité au Covid19. (UPDATE: Un petite nuance: après relecture de l’API Exposure Notification, l’application doit fournir les TEKs positifs reçus des serveurs Coronalert au système Android/Play Services qui procède à la comparaison.)

C’est l’application Coronalert qui gère les informations concernant les clés temporaires des personnes contaminées. Mais nous savons maintenant que Sciensano, Ixor.be ou l’état belge ne vont pas recevoir de données personnelles depuis l’application Coronalert. Les identifiants aléatoires et secrets (TEK) de personnes contaminées sont envoyés des serveurs vers votre téléphone qui les compare aux identifiants TEK aperçus autour de vous lors des 14 derniers jours. C’est bien votre téléphone et non un organisme distant qui effectue le boulot de savoir si vous êtes à risque.

Les serveurs peuvent toutefois connaître votre adresse IP lorsque votre application s’y connecte. Cependant, sans injonction d’un juge et les informations fournies par votre fournisseur d’accès à internet, il n’est pas possible de vous localiser avec précision. En général, la précision de localisation obtenue par une adresse IP est de la taille d’une province. Vous pouvez le vérifier par vous même avec un site comme Whatismyipaddress.

Nous avons également vu que l’application Android n’avait pas la permission d’accéder au répertoire téléphonique ou à d’autres données personnelles.

Ainsi, l’application semble relativement sûre à utiliser, si vous vous souciez des informations concernant votre vie privée.

Je souhaiterais rajouter que l’application Coronalert est excessivement bien documentée d’un point de vue technique. On sent que les développeurs ont voulu faire toute la transparence sur son contenu.

Il existe encore une possibilité de différence entre le code source que j’ai analysé et l’application disponible sur le Google Play Store. S’il n’a pas confiance en l’application disponible sur le Google Play Store, un developpeur reste libre de recompiler l’application lui-même et d’installer celle-ci à la place de celle téléchargée du Play Store. Pour tous les autres utilisateurs, je recommande toutefois d’intaller l’application du Play Store plutôt qu’une copie trouvée ailleurs sur internet.

Si vous avez aimé cet article, n’hésitez pas à me soutenir en m’offrant un petit café: