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.

22 commentaires

    1. Je pense que c’est une spécificité d’Android et non de l’application.
      Certains protocoles bluetooth permettent une certaine localisation des utilisateurs: si votre téléphone émet ou reçoit une balise qui ne change pas, il est possible de vous localiser. (Egalement avec l’adresse MAC).
      De ma comprehension l’activation du service de localisation informe l’utilisateur de ces risques potentiels.

      Mais dans le cas de Coronalert on sait deux choses:
      – la balise change toutes les 20 minutes, au même rythme que l’adresse MAC. On ne peut donc pas savoir si vous êtes venus deux fois au même endroit.
      (Correction 14/10/2020: 24h, apparemment)
      – le téléphone n’envoie pas de coordonnées GPS aux serveurs de Sciensano.

      Explication plus détaillée ici (en anglais):
      https://www.polidea.com/blog/a-curious-relationship-android-ble-and-location/

      J'aime

      Réponse

  1. Dans le cas ou une personne (ayant l’application bien sur) est détectée positive, qui entre les données dans l’application pour le signaler positif ? Vu que tout est anonyme seule la personne concernée peux l’introduire donc risque que des petits « idiots » vont se mettre comme infectés alors qu’ils ne le sont pas ou la personne infectée ne le signalera pas et donc on retombe case départ ? Si maintenant c’est une tierce personne qui doit entrer les données comme de quoi telle personne est infectée, il faudra lier à un moment son nom à son code de l’application donc du coup l’anonymat n’est plus garanti ?

    J'aime

    Réponse

    1. C’est une question à laquelle les responsables du projet répondraient mieux que moi, mais de ce que j’ai compris, nous sommes anonymes tant que nous ne sommes pas dans une phase de test PCR. Si vous recevez une alerte d’avoir été exposé à une personne contaminée, vous restez anonyme.

      A partir du moment où vous passez un test, cela se passe en deux étapes:
      1) Vous pouvez demander à l’app la génération d’un numéro unique que vous donnez à votre médecin/labo de test
      2) Si et seulement si l’application reçoit un résultat positif, alors elle vous alertera et vous autorisera à signaler votre contagion, ce qui éviterait les faux positifs que des petits malins pourraient déclencher.

      Evidemment, puisque le centre de tracing peut recontacter votre application avec le numéro généré, ce n’est plus, pour moi, de l’anonymisation mais de la pseudonymisation. Je ne dis pas qu’il y a un risque majeur, mais ce n’est plus de l’anonymisation stricto sensu. Un recoupement serait théoriquement possible si on a accès aux différents serveurs et aux données du médecin qui connait votre identité et qui sait que vous avez utilisé l’application.

      Je vous invite à consulter l’émission Questions en Prime du 29/9/2020 qui offre un face à face entre une avocate représentante de la ligue des droits humains et un des responsables du projet:
      https://www.rtbf.be/auvio/detail_questions-en-prime?id=2685849

      J'aime

      Réponse

    1. Je pense que c’est une spécificité d’Android et non de l’application.
      Certains protocoles bluetooth permettent une certaine localisation des utilisateurs: si votre téléphone émet ou reçoit une balise qui ne change pas, il est possible de vous localiser. (Egalement avec l’adresse MAC).
      De ma comprehension l’activation du service de localisation informe l’utilisateur de ces risques potentiels.

      Mais dans le cas de Coronalert on sait deux choses:
      – la balise change toutes les -20- minutes, au même rythme que l’adresse MAC. On ne peut donc pas savoir si vous êtes venus deux fois au même endroit.
      (Correction 14/10/2020: le renovuellement se fait toutes les 24h, apparemment)
      – le téléphone n’envoie pas de coordonnées GPS aux serveurs de Sciensano.

      Explication plus détaillée ici (en anglais):
      https://www.polidea.com/blog/a-curious-relationship-android-ble-and-location/

      J'aime

      Réponse

  2. Question (1) : faut-il que le smartphone soit en permanence sur wifi ou branché « données mobiles » pour que l’appli fonctionne (comme p. ex. pour waze !)? ou suffit-il que la fonction téléphonie de la carte Sim soit active ?
    Question (2) le samsung de ma femme est en android 5. …. Est-ce la raison pour laquelle l’application ne s’installe pas chez elle, avec une mention genre « votre appareil ne supporte pas cette application » ? Ou il y a-t-il une autre raison possible ?
    Merci

    J'aime

    Réponse

  3. Sur mon android 10 (Oneplus 8pro) l’application n’a pas l’air de fonctionner en arrière plan. Dans les options de batterie j’ai « 0 min » d’activité en arrière plan. Pensez vous que ce soit normal?

    Je n’ai probablement pas croisé de personnes avec l’application installée, l’application n’est elle réveillée que si il y a d’autres beacon dans le voisinage?

    Dans les options batterie j’ai 3 niveau de conservation d’énergie (« contrôle intelligent », « Optimiser » et « Ne pas optimiser ») l’application n’a pas l’air de changer le niveau et il est mis sur le premier.

    J'aime

    Réponse

    1. C’est un peu hors du cadre de ma revue, mais ce sont les Google play Services (Exposure Notification Service) qui gèrent l’échange des beacons et non l’application.
      L’application configure les critères de risque dans l’Exposure Notification Service de Google et lui se charge du suivi et du filtrage des beacons.
      J’ai l’impression que c’est l’ENS qui gère également la comparaison avec les clés téléchargées depuis les serveurs, et non l’application en soi.

      Donc, si je comprends bien, il ne serait pas indispensable que l’application tourne en permanence.
      A côté de cela, il me semble avoir lu quelque part qu’il fallait de temps en temps ouvrir l’app pour vérifier notre statut de risque. Peut-être si elle est mise en veille, effectivement.
      Le fonctionnement de l’exposure notification service est expliqué ici:
      https://developers.google.com/android/exposure-notifications/exposure-notifications-api (en anglais)
      Et un guide d’implémentation: https://developers.google.com/android/exposure-notifications/implementation-guide#authorize-exposure-notifications

      J'aime

      Réponse

      1. Le fait que c’est la partie de Google fait tout le boulot (inclus le stockage et comparaison des ID’s) n’était pas clair pour moi.
        Merci pour la réponse et la review!

        Aimé par 1 personne

  4. « 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. »
    Quand on utilise ce même smartphone pour un contacte avec l’ONSS, par exemple student@work, checkinatwork, dimona etc, le lien entre votre nom et votre adresse IP est déjà présent dans le « Government cloud ».

    Cacher son adresse IP par Tor VPN ne marche pas: les serveurs Coronalert n’acceptent pas de connexions hors UE.

    J'aime

    Réponse

    1. Oui bien sûr, avec des recoupements venant d’endroits différents, tout est possible, mais c’est illégal.
      De ce que j’ai compris, le backend ne tourne pas chez Sciensano.
      (c’est ce que les co-concepteurs ont confirmé à Question en Prime sur la rtbf).

      De toute façon, quand vous allez chez le médecin, et que vous passez un test vous serez identifié avec votre numéro de registre national. On saura que vous êtes positif. L’app pourrait-elle apporter une fuite supplémentaire ? Je ne vois pas, à ce stade.

      Pour revenir aux serveurs, je pense que tous les serveurs de l’état ne sont pas localisés au même endroit et gérés par les mêmes personnes/entreprises contractuelles.
      Avez vous des infos sur ce government cloud, ou est-ce une représentation imaginaire pour illustrer vos propos ?

      Votre fournisseur d’accès, les centres 101 et 112 peuvent aussi savoir où vous vous trouvez avec votre GSM (localisation LBS).
      Google peut vous localiser si vous avez laissé activés les services d’archivage de votre localisation.

      Au sujet de Tor, même si cela marchait avec un node européen, je ne conseillerais pas de l’utiliser: pour le problème inverse.
      Ca permettrait peut-être d’identifier votre session Tor… Théoriquement, en creusant énormément.
      Donc, parfois le mieux est l’ennemi du bien 😉

      Notez que c’est une bonne chose, ce blocage hors EU.

      Si tous ces recoupements informatiques sont théoriquement possibles, il faudrait déployer pas mal de moyens pour les mettre en œuvre.
      Et au final, on saura que… Vous êtes positif, grosso modo. (tant que vous n’êtes pas positif on saurait juste que vous utilisez l’app).
      Je ne sais pas si c’est la fin du monde. A chacun d’évaluer le problème qu’il a avec cela. (le fait de savoir si vous avez été malade poserait plus de problèmes si ça devait tomber dans les mains d’une assurance hospitalisation, par exemple. Mais comme pour n’importe quel dossier médical informatisé. )

      Il y a beaucoup plus de problèmes avec Facebook, par exemple.

      Aujourd’hui, j’ai été plus inquiet lorsque j’ai commandé mon chèque train corona: il suffit d’entrer mon numero de registre national pour qu’ils envoient le courrier à mon adresse. Ça m’a choqué qu’une entreprise privée puisse avoir mon adresse comme cela.

      Une note au passage, grâce au GDPR Européen, les entreprises sont toutefois condamnables en cas de fuites. Et ce sont des amendes énormes qui se comptent en pourcentage du chiffre d’affaires.

      J'aime

      Réponse

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l’aide de votre compte WordPress.com. Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s