VIII.3. Identification et authentification sur Internet

Problématique

Une fonction essentielle de tout système transactionnel ou collaboratif en réseau (forums, e-commerce, votations libres, ...) est l'identification des utilisateurs/participants.

Deux objectifs possibles de l'identification (il y en a d'autres) sont (i) d'empêcher les doublons (par exemple les votes multiples) et (ii) de responsabiliser les utilisateurs via le risque réputationnel.

On peut distinguer trois niveaux d'identification des individus par une organisation :

	Faible (*)	Forte privée	Forte publique
Médium	pseudonyme	e-carte bancaire	e-carte d'identité
Application	forums, Wikipédia, ...	virements, ...	votations, ...
Avantage (#)	liberté d'expression	?	officiel
Inconvénient (#)	capacité de nuisance (trolls)	non officiel	?

(*) identification sans authentification.
(#) Du point de vue des identifiés. Celui de l'organisation qui identifie peut être différent voire antagoniste.

Nous verrons dans la section consacrée à itsme qu'il est possible de combiner des systèmes d'identification forte publique et forte privée, mais que cela n'est pas sans risques démocratiques.

Étude de cas : analyse de la problématique en amont d'une votation :

1. rédaction de la votation ;
2. processus d'information (Wikipédia, ...) et de débat public (forums, ...) ;
3. mise en votation.

Étapes 1 et 2. D'une part l'anonymat présente l'avantage de faciliter la critique. Mais d'autre part il permet la prise de contrôle d'articles par des groupes organisés. Prenons le cas des patrouilleurs de Wikipédia, c-à-d des utilisateurs agissant notamment pour lutter contre le vandalisme [source1, source2]. Leur travail est manifestement très utile pour garantir un minimum de qualité et de neutralité aux articles. Cependant, il est tout aussi manifeste que leur anonymat (NB : les éventuelles fiches utilisateurs ne sont que des simulations d'identification, et sans authentification) a pour effet que certains articles politiquement sensibles sont sous le contrôle manifeste de groupes de patrouilleurs organisés utilisant Wikipédia à des fins de propagande positive ou négative. Il y a ici un déficit flagrant de transparence.

Il importe donc que des applications anonymes telles que Wikipédia soient concurrencées par des versions également ouvertes mais où la participation est conditionnée à une identification forte, ayant pour avantage de responsabiliser les contributeurs soucieux de préserver leur réputation. À ma connaissance il n'existe pas encore un tel service ouvert complémentaire à Wikipédia.

Étape 3. La plupart des applications de votation libre (sondages, pétitions, ...) actuellement disponibles sur Internet sont facilement manipulables par votes multiples car le procédé utilisé pour "identifier" le votant est généralement bancal :

• ID par l'adresse IP : les personnes dont l'abonnement à Internet est de type "adresse dynamique" n'ont qu'à couper puis rallumer la connexion pour obtenir une nouvelle adresse, et donc un droit de vote supplémentaire, et il est aussi possible de simuler une série d'adresses IP ;
• ID par l'adresse email : en créant un série d'adresses valides sur un seul nom de domaine (utilisateur-1@domaine, utilisateur-2@domaine, ..., utilisateur-n@domaine) ;
• ID par cookie : il suffit, via les options du navigateur, de supprimer les témoins.

Dans chacun de ces cas il n'est pas très compliqué d'écrire un petit programme qui, à partir d'un simple ordinateur portable, va automatiquement voter au nom d'une multitude de "personnes" n'existant pas. Ce type de programme est très difficilement repérable car il peut voter à différents moments définis automatiquement de façon aléatoire, et le faire à partir d'une série d'adresses IP changeant constamment.

Le mythe
du web
anonyme

Enfin les spécialistes du web feront remarquer que l'anonymat sur le web est très probablement un mythe, notamment par rapport aux services de renseignement US.

Trois éléments suggérant la nature mythique du web "anonyme" sont :

• les effets d'émergence résultant de la combinaison d'Internet avec des technologies/techniques connexes : radio-identification, triangulation, bases de données relationnelles, etc ;
• les propriétés technologiques inconnues du grand public : ainsi la plupart des gens croient qu'un smartphone "éteint" et dont on a retiré la carte est nécessairement isolé de tout réseau, ou encore que les données d'un disque dur peuvent être véritablement "effacées" par reformatage ;
• les accords de coopération entre Services du renseignement militaire US, fabricants de matériel de communication et opérateurs télécom de pays membres ou alliés de l'OTAN.

Cependant le présent article traite uniquement des utilisations du web dans le cadre de la loi et en dehors des applications militaires.

La problématique étant décrite, voyons maintenant les technologies disponibles, ou en développement, qui permettent de développer des solutions.

Technologie

 1. Cryptographie symétrique
 2. Cryptographie asymétrique
 3. Décentralisation

Cryptographie symétrique

Jean habite Paris et veut envoyer un message via Internet à Marie qui se trouve à Bruxelles. Pendant sont trajet le message va passer par un certain nombre de routeurs. Or, lors de ce passage, le message pourrait être copié, lu et même modifié par l'administrateur d'un routeur, ou par des hackers qui vont en espionner les entrées et sorties. Pour minimiser les risques de lecture et modification par des tiers non autorisés, une solution consiste à chiffrer (on dit aussi "crypter") le message, au moyen d'un code secret.

Le code secret doit être suffisamment long, de sorte que le coût de découverte du code secret par force brute est suffisamment élevé pour la plupart des hackers. Il s'agit donc bien de minimiser le risque d'intervention non autorisée, relativement au business modèle caractérisant les données échangées et les parties prenantes (expéditeur, destinataires, hackers privés ou publics). Il n'existe pas de risque nul.

Lorsque le même code secret (on dit plutôt "clé de chiffrement") est utilisé par l'expéditeur pour chiffrer, et par le destinataire pour déchiffrer, on parle de cryptographie symétrique. Le problème est ici que Jean et Marie doivent déterminer cette clé de concert, et que cet accord entre les deux parties ne peut être réalisé via le réseau, puisqu'alors la clé pourrait être également interceptée.

C'est ici que la cryptographie (chiffrage) asymétrique intervient, qui permet notamment d'envoyer les données cryptographiques via le réseau, avec un risque acceptable.

Cryptographie asymétrique

 1. Fonctions
 2. Paires de clés
 3. Authentification

Fonctions

La cryptographie asymétrique permet d'assurer trois fonctions de sécurisation d'un système de messagerie :

• confidentialité (le message ne peut être lu par un tiers) ;
• signature :
  • identification et authentification de l'expéditeur (le message a bien été envoyé par l'expéditeur présumé) ;
  • vérification de l'intégrité du message (le message originel n'a pas été modifié par un tiers ou accidentellement).

Symétrique vs asymétrique. La cryptographie symétrique demeure largement utilisée en raison de sa rapidité. Nous verrons plus loin qu'en pratique cryptographies symétrique et asymétrique sont généralement combinées afin de réaliser un bon arbitrage entre rapidité (crypto symétrique) et sécurité (crypto asymétrique). Exemples d'algorithmes de cryptage symétrique : AES ; ARC2 ; Blowfish ; CAST ; DES ; Triple-DES.

Paires de clés

Dans la cryptographie asymétrique l'expéditeur et le destinataire d'un message disposent chacun d'une paire de clés : l'une publique (c-à-d connue de tous), et l'autre privée (c-à-d connue seulement par son propriétaire). Les deux clés d'une même paire sont telles que ce qui est encrypté avec l'une ne peut être décrypté qu'avec l'autre, de sorte qu'il est possible de réaliser deux types de fonctions :

• confidentialité d'un message : l'expéditeur d'un message peut le crypter avec la clé publique du destinataire, de sorte que seul celui-ci pourra décrypter le message (au moyen de sa clé privée) ;
• identification de l'auteur (signature) : l'expéditeur d'un message peut le crypter avec sa clé privée, de sorte que le destinataire aura la garantie que l'expéditeur du message qu'il vient de décrypter est bien le détenteur de la clé privée correspondante.

La fonction de signature est réalisée en combinaison avec une fonction de hachage, qui permet de garantir l'intégrité du message. Pour ce faire la fonction produit une suite de caractères à partir du message – appelée "hash" en anglais, ou "condensat" en français – et ayant trois propriétés :

• irréversible : impossible de reproduire le message à partir de son condensat (c-à-d de décrypter) ;
• unique : aucun autre message ne peut donner le même condensat (pas de "collision" entre différents condensats) ;

  Il est même "chaotique" : une modification même minime modifie complètement le condensat.

• constant : à un message correspond toujours le même condensat (celui-ci est dit "déterministe");

  Notamment le condensat calculé par la clé privée est identique à celui calculé par la clé publique (à vérifier).

Cette suite de caractères est la forme que prend la signature électronique. Il suffit au destinataire (en fait son logiciel de communication) de comparer la signature au condensat recalculé au moyen de la clé publique de l'expéditeur --> si les deux sont identiques le destinataire à la garantie (i) que l'expéditeur est bien celui correspondant à la clé publique utilisée ; mais aussi (ii) que le message n'a pas été modifié pendant le transfert.

Jamais infaillible. Déduire la clé privée à partir de la clé publique sera d'autant plus difficile (en temps et capacités de calcul) que la taille des clés sera longue.

Authentification

Mais encore faut-il que chacun ait la garantie que l'autre (destinataire ou expéditeur) dont il connaît la clé publique est effectivement la personne qu'il prétend être. Autrement dit les processus ci-dessus se limitent à identifier autrui ("Qui êtes-vous ?"), mais il reste à l'authentifier ("Prouvez qui vous êtes !"). C'est là qu'interviennent les autorités de certification (AC).

Pour ce faire le propriétaire d'une clé publique peut demander à une AC de délivrer un certificat électronique (généralement contre paiement ...) par lequel l'AC – par exemple un organisme agréé par l'État – certifie que son client est bien la personne qu'il prétend être. Le certificat comprend notamment la clé publique en question, des données sur son titulaire (nom de la société, adresse postale, pays, e-mail de contact, ...) et la signature de l'AC.

L'ensemble constitué par les AC et les fabricants de matériels et logiciels requis forme une infrastructure à clés publiques (PKI en anglais), fondée sur des normes internationales (cf. infra notamment les types de certificats).

Des questions fondamentales concernant les PKI sont : (i) Estimez-vous que l'AC de la personne dont vous utilisez la clé publique est crédible ? ; (ii) Cette AC est-elle certifiée par votre État ? ; (iii) Dans quelles conditions une organisation privée est-elle en mesure d'exercer la fonction d'AC de façon aussi crédible que l'État ? ; (iv) Qu'en est-il lorsque les parties habitent des pays différents ?

Sécurité vs
opérabilité

Plus une clé de chiffrement est longue plus le déchiffrement par des personnes non autorisées est difficile (c-à-d exige beaucoup de temps et de capacité de calcul), mais aussi plus l'opération de chiffrement est longue (100 à 1000 fois plus lente), ce qui peut rendre le système pratiquement inopérant si la fréquence et la taille des transactions sont trop élevées. Il y a donc un arbitrage à opérer entre sécurisation et opérabilité.

Idéal théorique. Abstraction faite de cet arbitrage, l'algorithme de chiffrement le plus sécurisé (voire théoriquement incassable) est la technique du masque jetable, fondée sur seulement trois conditions à vérifier par la clé de chiffrement : suite de caractères aléatoire, longueur supérieure ou égale à celle du message, utilisation unique.

Cryptographie mixte. Un arbitrage possible entre sécurité et rapidité consiste à utiliser le chiffrement asymétrique pour la seule phase d'échange de la clef symétrique, puis d'utiliser cette dernière pour tout le reste de l'échange. C'est le cas du protocole de sécurisation des échanges sur Internet TLS (qui remplace SSL) :

1. Le navigateur du client envoie au serveur une demande de mise en place de connexion sécurisée par TLS. Navigateur et serveur conviennent d'une suite cryptographique (pour le chiffrement et la signature).
2. Le serveur envoie son certificat au client (le certificat comprend notamment le nom du serveur, sa clé publique et la signature de son autorité de certification).
3. Le navigateur du client tente de vérifier la signature numérique du certificat en utilisant les clés publiques contenues dans les certificats des autorités de certifications (AC) intégrés par défaut dans le navigateur : si le hash ainsi calculé du certificat serveur correspond à la signature, le navigateur web en déduit le nom de l'autorité de certification qui a signé le certificat. Il vérifie que celui-ci n'est pas expiré puis envoie une demande OCSP à cette autorité pour vérifier que le certificat du serveur n'a pas été révoqué.
4. Le navigateur du client :
   • génère un nombre aléatoire, qu'il chiffre à l'aide de la clé publique contenue dans le certificat du serveur puis le transmet au serveur qui le décrypte avec sa clé privée ; à partir de ce nombre le navigateur et le serveur créent alors une même clé privée symétrique (appelée "clé de session") qu'ils utiliseront pour les opérations ultérieures de chiffrement et déchiffrement (PS : une possible méthode alternative pour établir la clé de session est celle de Diffie-Hellman) ;

     Ces opérations sont réalisées au moyen d'algorithmes contenues dans la suite crytpographique convenue à l'étape 1.

   • transmet éventuellement son propre certificat au serveur, qui le vérifiera comme dans le point 3.
5. La connexion TLS est alors établie entre client et serveur qui peuvent alors s'échanger des données en chiffrant celles-ci avec la clé de session qu'ils ont en commun.
6. Une fois la connexion terminée (déconnexion volontaire de l'utilisateur ou si durée d’inactivité trop élevée), le serveur révoquera la clé de session.

Authentification
forte vs faible

Dans l'exemple précédent de la connexion TLS, l'authentification est dite "faible". Par contre, si l'utilisateur dispose d'une carte d'identité électronique dont il connaît le code PIN il est alors possible de réaliser une authentification "forte".

Maintenant que l'identité de l'utilisateur est authentifiée de façon "forte" par le site XYZ, il peut par exemple participer à une votation organisée par ce site. Pour réaliser des votations via Internet, un façon de faire consiste à reproduire le principe de la double enveloppe, utilisé pour le vote postal.

Lecture du schéma. Le votant encrypte son vote avec la clé publique du système de votation puis insère cette première enveloppe (rose dans le schéma) dans une seconde (bleue dans le schéma) qu'il signe au moyen de sa clé privée. Le tout est envoyé au système de votation via Internet. Le système de votation "ouvre l'enveloppe bleue" (c-à-d vérifie la signature) à l'aide de la clé publique du votant, enregistre l'identité des ayants-voté dans une base de données, puis stocke les votes ainsi anonymisés (enveloppes roses) dans une autre base de donnée. Pour compter les votes anonymisé ceux-ci sont d'abord décryptés ("ouverture des enveloppes roses") à l'aide de la clé privée du système de votation.

Décentralisation

 1. Toile de confiance
 2. Chaîne de blocs

Les cartes d'identité électroniques actuelles (Belgique, Estonie, ...) sont des systèmes centralisés : le certificat installé sur la carte est signé électroniquement par l'État, qui garantit ainsi que le titulaire de la carte est bien inscrit au registre national (cf. RN belge).

Un système d'authentification aussi performant pourrait-il être décentralisé ? Pour répondre à cette question voyons de plus près les deux techniques les plus répandues : la toile de confiance et la bloc-chain.

NB : ne pas confondre décentralisation et sous-traitance (approfondir : /reseau-decentralise#cloud).

Toile de confiance

Au sein de petites communautés où la plupart des gens se connaissent (quartiers, villages, associations locales, PME) l'on peut très bien concevoir des systèmes d'identification électronique dont le certificat électronique n'est pas signé par l'État mais par un nombre suffisant d'autres membres de la communauté. Pour cela l'utilisateur doit prendre l'initiative d'acquérir un certificat électronique, et inciter d'autres membres de sa communauté à le signer électroniquement. C'est la toile de confiance.

Types de certificats. En général dans une PKI les certificats sont de type X-509, tandis que dans une toile de confiance ils sont de type OpenPGP.

La toile de confiance est donc soumise à certaines limites, liées à la capacité inégale des utilisateurs :

• à gérer leur clés : certains sont moins familiers que d'autres avec les technologies du web ;
• à obtenir suffisamment de signatures : certains ont des réseaux relationnels qui peuvent être insuffisants pour trouver suffisamment de signataires (PS : cf. la monnaie libre June).

La décentralisation est donc difficilement compatible avec le traitement égalitaire des utilisateurs. Cette limitation sociale est en outre accentuée par une limitation à caractère logique, formulée par le théorème CAP qui stipule que toute application en réseau pair à pair est confrontée à des contraintes logiques induisant d'inévitables arbitrages entre critères de performance des fonctionnalités de l'application.

	centralisé	décentralisé
Communauté	globale (tout le monde ne se connaît pas)	locale (tout le monde se connaît)
Identification	par carte eID	par certificat numérique
Validation	par un prestataire de service eID	par signatures numériques d'une toile de confiance

On peut enfin étendre la décentralisation jusqu'au stockage et au traitement des données (dont celles de la toile de confiance), grâce à la technique des chaînes de blocs.

On notera qu'avec les imprimante 3D, le concept de décentralisation pourrait s'étendre, dans un futur peut-être pas très éloigné, jusqu'à la production de leurs matériels par les utilisateurs (cartes à puce, lecteurs, smartphones, ...).

Chaîne de blocs

Voir : /reseau-decentralise.php#chaine-de-blocs

Les technologies disponibles ayant été passées en revue, analysons maintenant leur application concrète.

Aspects juridiques

Nous reprenons ici essentiellement la réglementation européenne sur l’identification électronique et les services de confiance pour les transactions électroniques au sein du marché intérieur [source].

Personnes
physiques

Lorsqu’elle satisfait à certaines exigences, une signature électronique peut être « avancée » ou « qualifiée » [source].

Pour être avancée, elle doit :

• être liée au signataire de manière univoque ;
• permettre l’identification du signataire ;
• être créée à l’aide de données de création de signature électronique que le signataire peut, avec un niveau de confiance élevé, utiliser sous son contrôle exclusif et
• être liée aux données auxquelles elle se rapporte de telle sorte que toute modification ultérieure des données soit détectée. (art. 26 du règlement eIDAS).

Elle sera qualifiée si en plus d’être avancée, elle est créée à l’aide d’un dispositif de création de signature électronique qualifié, et repose sur un certificat qualifié de signature électronique (art. 3 § 12 du règlement eIDAS).

Le règlement stipule bien qu’une signature électronique (quels que soient la technologie employée et le niveau) ne peut être refusée comme preuve en justice au seul motif qu’elle est électronique ou qu’elle n’est pas qualifiée. Néanmoins, seule la signature dite qualifiée est assimilée à une signature manuscrite.

Personnes
morales

Pour les personnes morales on ne parle pas de signature mais de cachet électronique. Celui-ci sert à prouver qu'un document électronique a été délivré par une personne morale en garantissant l'origine et l'intégrité du document. La différence avec la signature électronique n'est pas d'ordre technique mais purement juridique. Ainsi dans certains pays il existe une discrimination à l'avantage des personnes morales, que leur cachet électronique n'engagent pas juridiquement (PS : ce n'est pas le cas en Belgique), le cachet ayant alors pour seule fonction de garantir l'origine et l'intégrité des données électroniques cachetées.

Authentification

La réglementation européenne définit l'authentification comme suit : « un processus électronique qui permet de confirmer l’identification électronique d’une personne physique ou morale, ou l’origine et l’intégrité d’une donnée sous forme électronique » [source : art. 3 § 5].

En matière d'authentification nous n'avons trouvé de documents juridiques que pour « l'authentification de sites Internet » et « l’authentification pour un service en ligne », mais pas pour l'authentification entre personnes physiques sans site web. Faut-il s'en étonner de la part de l'UE, dont le business modèle n'est pas vraiment fondé sur la décentralisation ... ?

Le certificat d’authentification de site internet est une attestation qui permet d’authentifier un site internet et associe celui-ci à la personne physique ou morale à laquelle le certificat est délivré [source : art. 1 § 38].

Accessibilité du service d'authentification. La réglementation européenne vise notamment à permettre « au secteur privé de s’appuyer sur des fonctions d’identification et d’authentification électroniques déjà largement utilisées dans de nombreux États membres, au moins pour les services publics, et de faciliter l’accès des entreprises et des particuliers à leurs services en ligne transfrontaliers. Afin de faciliter l’utilisation transfrontalière de tels moyens d’identification électronique par le secteur privé, la possibilité d’authentification prévue par un État membre devrait être accessible aux parties utilisatrices du secteur privé établies en dehors du territoire de cet État membre aux mêmes conditions que celles qui sont appliquées aux parties utilisatrices du secteur privé établies sur le territoire dudit État membre. Dès lors, en ce qui concerne les parties utilisatrices du secteur privé, l’État membre notifiant peut définir des conditions d’accès aux moyens d’authentification. Ces conditions d’accès peuvent indiquer si le moyen d’authentification relatif au schéma notifié est actuellement accessible aux parties utilisatrices du secteur privé » [source : art. 1 § 17].

Fonction
régalienne

Fait grave, la réglementation européenne n'interdit pas expressément que la gestion des systèmes d'identité électronique soit confiée à des entreprises privées (ce qui n'est pas étonnant puisque l'UE est une organisation d'inspiration néolibérale). On notera à cet égard qu'en mars 2021, les Suisses ont rejeté par référendum le projet d'identité électronique, parce que le projet confiait sa gestion à des entreprises privées [source]. Le contraste est énorme entre le cas de la Suisse (qui n'est pas membre de l'UE) et celui de la Belgique (membre et siège de l'UE), qui sera développé dans la dernière section.

Carte eID

 1. Principes
 2. Procédure de création
 3. Contenu de la carte eID
 4. Client
 5. Serveur

Principes

La carte eID est une carte d'identité électronique, de même type qu'une carte bancaire. Il n'existe pas encore de carte d'identité électronique en France, mais déjà en Autriche, Belgique, Espagne, Estonie, Finlande, Italie, Pays-Bas, Suède, ... La Belgique ayant été parmi les premiers pays au monde à remplacer la carte d'identité papier par une carte électronique (2002), la maîtrise de cette technologie y est particulièrement avancée. La Belgique est probablement le leader mondial en la matière.

La carte eID repose sur la cryptographie asymétrique (cf. section précédente) : un certificat numérique signé par l'autorité publique et stocké dans la mémoire de la puce permet de prouver son identité et de signer des documents.

Commençons par décrire la procédure de création de la carte eID, ainsi que son contenu.

Procédure de création

Cinq personnes physique ou morales interviennent dans cette procédure :

• le citoyen ;
• la municipalité (État local) ;
• le registre national (État central) ;
• le fabriquant de la carte (entreprise privée) ;
• l'autorité de certification (entreprise privée agréée).

1. le citoyen reçoit une lettre de convocation ;
2. le citoyen se présente au bureau municipal avec une photo d'identité et son ancienne carte d'identité ;
3. la municipalité envoie une demande de carte au registre national ;
4. le registre nationale commande la fabrication de la nouvelle carte ;
5. le fabriquant génère une paire de clé et inscrit la clé privée dans le processeur cryptographique de la nouvelle carte ;
6. le fabriquant envoie une partie du code PUK de la carte au registre national ;
7. le fabriquant introduit une demande de certificat pour la carte à l'autorité de certification.
8. l'AC envoie les deux certificats et met à jour sa base de données des certificats ;
9. le fabriquant copie les deux certificat dans la mémoire EEPROM de la puce ;
10. le fabriquant écrit les données d'identification (nom, adresse, ...) dans la mémoire EEPROM de la puce, puis envoie la carte désactivée au bureau municipal ;
11. le fabriquant envoie une lettre au citoyen contenant le code PIN, l'autre partie du code d'activation PUK, et une invitation à se rendre avec au bureau municipal ;
12. au bureau municipal, activation de la carte au moyen du code PUK reconstitué --> CA met à jour sa base de données des certificats.

La puce de la carte eID comprend cinq unités physiques :

• processeur de données non cryptographiques (CPU) ;
• processeur de données cryptographiques ;
• unité de stockage du système d'exploitation (ROM) ;
• unité de stockage des applications et données (EEPROM) ;
• unité de mémoire vive (RAM).

Contenu de la carte eID

La carte eID belge contient par défaut [sources : données , fichiers] :

• des informations visibles :
  1. nationalité du titulaire ;
  2. numéro de carte d'identité ;
  3. nom et prénoms ;
  4. photo de passeport ;
  5. date et lieu de naissance ;
  6. sexe ;
  7. numéro d'identification au registre national ;
  8. lieu de délivrance et signature de l' autorité de délivrance ;
  9. date d'expiration ;
  10. signature du titulaire ;
  11. titre de noblesse possible (roi, prince, comte, baron, etc.).
• des informations non visibles :
  • adresse ;
  • deux certificats numériques (type X.509) pour :
    1. une paire de clés RSA pour l'authentification (preuve d'identité au moyen d'une signature électronique) ;
    2. une paire de clés RSA pour une signature électronique juridiquement valide.

       Les clés privées sont enregistrées dans la puce tandis que les clés publiques le sont dans un certificat [source].

  • trois certificats numériques X.509 des autorités publiques :
    1. l'autorité citoyenne (?) signant les deux certificats de liaison clés ci-dessus ;
    2. le service du registre national qui signe la photo, l'identité et le fichier d'adresses ;
    3. l'État belge.

Ne pas confondre le code PIN , qui lie la carte à son titulaire, et le le code de la carte (parfois appelé "code logique").

Mais ce n'est pas tout ... La carte eID belge permet également aux professionnels du secteur de la santé disposant de votre carte eID (médecin, pharmacien, etc), d'accéder aux données médicales stockées dans les bases de données des organismes assureurs (il semblerait que pour ce faire, les données de la carte non visibles par son titulaire contiendraient des données administratives de la mutuelle du titulaire).

Ainsi, dès lors qu'une carte eID (ou votre ordinateur ...) est connectée à un réseau, la problématique de la localisation physique des données ("où se trouvent-elles") tend à s'évaporer et à être supplantée par celle de l'accès à ces données ("qui peut accéder à quelles données").

Approfondissons maintenant le fonctionnement de la carte eID, d'abord du côté "client" (c-à-d de l'utilisateur, du détenteur de la carte), ensuite du côté "serveur" (c-à-d le site web où l'utilisateur veut s'identifier).

Client

Pour s'identifier sur un site web de l'État au moyen de sa carte eID l'utilisateur doit connecter sur son ordinateur un lecteur de carte eID agréé, et mentionner le code PIN de sa carte (voir la page d'accès pour la Belgique).

Le code PIN donne accès aux clés secrètes de la carte. En cas de perte ou d'oubli du code PIN le titulaire de la carte doit se rendre auprès de son administration communale et mentionner son code PUK. Les deux codes figurent sur la lettre qui est envoyée par l'administration communale lors de l'initialisation d'une carte eID (par exemple lorsque le code PUK a été perdu).

Installation sur Linux Debian :

1. télécharger le logiciel eID : eid.belgium.be/fr/installation-du-logiciel-eid-sous-linux ;

2. dans la console passer en root : su - (NB : seulement su ne nettoie pas les variables d'environnement --> l'installation peut ne pas fonctionner) ;

3. installer l'archive eID : # dpkg -i eid-archive_*_all.deb (remplacez * par les caractères exacts) ;

4. installer eid-mw (middleware eid) et eid-viewer (permet, au détenteur de la carte, notamment de lire son contenu, modifier son code PIN, et gérer les certificats installés sur sa puce) :

   1. # apt-get update
   2. # apt-get install eid-mw eid-viewer

5. pour le navigateur Firefox ajouter le module belgium-eid : addons.mozilla.org/firefox/addon/belgium-eid.

6. redémarrez votre ordinateur puis testez une identification.

L'utilisation locale de la carte est rendue possible par eid-viewer, et l'accès à distance (s'identifier à distance via une page web) par eid-mw (+ addon/belgium-eid pour le navigateur Firefox). Chacun de ces deux composants du logiciel eID repose sur l'API PKCS#11 de openSC [source].

openSC, qui est inclus dans la distribution Debian [infos], suffit pour s'identifier en ligne, mais n'installe pas le eID-viewer.

Problèmes

Il semble que la technologie n'a pas encore atteint le degré de maturité requis pour une utilisation grand public :

• L'installation des logiciels peut poser problème sur les ordinateurs dont le système d'exploitation n'a plus été mis à jour depuis un certain temps. Il y a en outre le cas des personnes pour qui l'installation de logiciels est une opération ardue.
• Sur certains ordinateur la connexion au serveur d'identification n'est possible que si le navigateur a été ouvert après le branchement du lecteur et l'introduction de la carte.

  NB : après avoir introduit la carte, n'ouvrir le navigateur qu'après le retour à la vitesse lente de l'indicateur clignotant du lecteur... (ce qui peut prendre une dizaine de secondes) ...

• La présentation du système entretient malheureusement une confusion entre le lecteur physique de la carte (qui suffit pour sa lecture automatique par le système d'identification en ligne) et le lecteur logiciel (qui ne sert que pour la lecture visuelle du contenu de la carte et l'éventuel changement de code PIN).

La procédure côté utilisateur ("client" en terme informatique) étant décrite, voyons maintenant le fonctionnement du système côté site web ("serveur" en terme informatique).

Serveur

 1. Modèles d'affaire
 2. Prestataire eID
 3. Développer une appli serveur

Le système eID étant basé sur la cryptographie asymétrique, il est donc de type "Public Key Infrastructure" (PKI), que nous avons présenté dans la section consacrée aux technologies de base. Cette structure PKI implique un prestataire (public ou privé) de services d'identification et d'authentification.

Modèles d'affaire

Différents modèles techniques, et partant différents modèles d'affaire, sont possibles. Il s'agit de trouver un arbitrage optimal entre des objectifs parfois antagonistes :

• sécurité : notamment empêcher l'usurpation d'identité, et les identités multiples (notamment pour les votations) ;
• confidentialité : notamment empêcher l'exploitation abusive des données de la carte eID par les prestataires d'authentification eID et les entreprises ;
• facilité d'utilisation par le titulaire de carte : notamment éviter à celui-ci de devoir installer des logiciels sur son terminal ;
• coût : déterminé notamment par les trois points précédents et la mise à jour technologique.

Prestataire eID

Le site eid.belgium.be ne fournit aucune information à destination du grand public concernant le schéma de fonctionnement côté serveur du système eID. Nous avons cependant pu trouver le "Reference manuel Belpic eID card" à destination des développeurs, où figure à la section 5.2 une description technique du processus d'authentification auprès des sites du service public belge (ou « d'entreprises ou personnes chargées d'une mission pour le compte de l'Administration » - source). Le graphique suivant présente une illustration plus explicite que celle du manuel.

Un point essentiel de la problématique du système eID est la vérification de la validité des certificats (cf. le protocole OCSP de vérification de certificat, à l'étape 6 du graphique ci-dessus). La puce de la carte comprend en effet (notamment) l'identité du détenteur, son numéro national et un certificat signé par l'État attestant que le numéro national correspond bien aux données d'identité, tels que mentionnés dans le registre national.

Nous avons ici la réponse à la question "pourquoi le système eID requiert-il un lecteur de carte connecté ?" : parce qu'il faut pouvoir vérifier, à chaque transaction, la validité des certificats contenus sur la puce de la carte eID.

Développer une appli serveur

N.B. La validité de cette section est sujette à caution.

Si vous avez votre propre site web et que vous souhaitez identifier et authentifier vos visiteurs (ayant installé le logiciel eID – eID-mw et eID viewer – sur leur ordinateur), il n'est pas nécessaire de passer par un prestataire eID si vous développez une application serveur pour collecter les données de la carte d'identité. Pour ce faire on peut distinguer trois solutions, de la plus simple à la plus complexe :

1. Identification : glisser-copier. Si vous souhaitez seulement obtenir les données de la carte d'identité la façon la plus simple est de demander au visiteur de lire sa carte avec le eID viewer et de glisser-copier sa photo dans le formulaire que vous lui présenterez sur votre site. Il suffira alors que votre programme aille chercher les infos (pour voir le résultat copiez-collez dans un simple fichier texte). Notez que vous êtes dans l'incapacité de vérifier si les données envoyées par l'utilisateur sont effectivement celles de la carte (pour cela il faut procéder à leur authentification).

2. Identification + authentification : SSL mutuel. Si vous souhaitez authentifier les données votre programme doit demander à l'utilisateur de s'authentifier à l'aide de son eID, puis collecter les données du certificat avec lequel il s'authentifie. Le serveur apache peut fournir directement ces données sous forme de variables en PHP (pour tester les variables fournies par votre serveur, utilisez une page php contenant juste phpinfo();). Un façon de faire est d'utiliser OpenSSL, qui depuis sa version 0.4.0 comprend le moteur pkcs11 (tandis que le module pkcs11 est compris dans le logiciel eID).

3. Plus. Si vous avez d'autres besoins il vous faudra probablement implémenter votre propre module complémentaire (add-on) pour les navigateurs, qui utilise la messagerie native pour communiquer avec une application locale, qui lit ensuite les données requises et les transmet à la page Web. Ce module devra parler avec le eID-mw (cf. supra). Vous devrez également manipuler le DOM, ce qui nécessite l'autorisation "Read all data for website <URL>" [Chrome ; Firefox].

Plus d'infos :

• Développement : github.com/Fedict/eid-mw/wiki/Development
• Tout savoir sur la carte eID : ithub.com/Fedict/eid-mw/tree/master/doc/sdk/documentation

Service public d'authentification

Le schéma de la section précédente correspond au cas d'une identification en ligne auprès de sites web d'organisations publiques. D'autre part, la carte eID pourrait également être utilisée comme moyen d'identification globale, c-à-d non seulement auprès des sites web de l'État, mais également auprès des sites d'organisations privées :

• employés, clients et fournisseurs d'une entreprise ;
• membres d'une association formelle ou informelle (par exemple pour organiser de façon crédible des votations via Internet) ; ...

Une entreprise publique pourrait ainsi proposer aux entreprises privées, association et individus un service public non seulement d'identification (ce que les entreprises privées sont également capables de faire) mais aussi d'authentification officielle (ce que les entreprises privées ne sont pas en mesure de faire sans accès au registre national). Gratuit pour les citoyens et associations mais payant pour les entreprises, ce services d'authentification pourrait ainsi générer d'important revenus pour l'État tout en offrant aux citoyens des services en ligne protégeant les données privées, publiques et commerciales liées aux individus.

Malheureusement, nous allons voir dans la section suivante que les décideurs politiques ne se sont pas engagés dans cette voie, mais on plutôt choisi un modèle technique et d'affaire privilégiant les intérêts de grandes entreprises privées du secteur bancaire et des télécoms :

• seules les entreprises privées peuvent en bénéficier ;
• la gestion de ce système a été confiée à des entreprises privées [prestataires de services de confiance établis en Belgique – source1, source2], et à des conditions qui spolient l'État et les citoyens, au bénéfice des ces entreprises privées.

itsme : privatisation du registre national belge ?

 1. Consortium
 2. Principe
 3. Utilisation
 4. Activation
 5. Données collectées et transférées à des tiers
 6. Sécurité
 7. Cadre légal
 8. Conclusion

Consortium

En 2002 la Belgique fut le premier pays au monde à instaurer la carte d'identité électronique. Quinze ans plus tard (2017), la Belgique maintient ce leadership technologique en proposant Itsme, un service d'identification officielle par téléphone mobile, fruit de la collaboration entre le fonds souverain de l'État belge (SFPIM) et un consortium privé composé de quatre grandes banques (ING, BNP Paribas Fortis, Belfius et KBC) et des trois principaux opérateurs de réseaux mobiles du pays (Proximus, Base/Telenet et Orange), le tout réuni sous le label itsme (dénomination commerciale) ou "Belgian Mobile ID" (dénomination juridique).

Opacité. Le site itsme.be ne mentionne aucune information concernant les membres du CD et du CA, les actionnaires majoritaires, ou encore les résultats financiers. En outre, le site ne mentionne aucun numéro de téléphone ni adresse email de contact, et le formulaire de contact n'est utilisable que par les clients [vérifier]. J'ai demandé au Customer Support de itsme de me communiquer l'URL de la page où se trouvent ces informations. On s'est borné à me répondre « Tous les renseignement dont vous aurez besoin se trouve sur notre site » (N.d.A. sic, faute d'orthographe comprise). Le principe de transparence est donc foulé au pied, et remplacé par celui d'opacité, ainsi que par des comportements relevant du charlatanisme et de l'amateurisme.

Principe

itsme est une combinaison de systèmes d'identification forte publique et privée (cf. section 1), permettant l'identification, l'authentification et la signature électronique (*) entre un téléphone mobile et un site web, ou entre téléphones mobiles. Il suffit dorénavant à l'utilisateur de mentionner le même code secret (cinq chiffres) chaque fois qu'il s'identifie (se connecte) aux applications en ligne de toute organisation privée ou publique permettant aux utilisateurs de s'identifier au moyen du service itsme. La carte d'identité ou la carte bancaire ne doivent plus être utilisées que pour l'activation du code secret (c'est donc la seule fois ou le lecteur de carte est requis).

(*) Pour la fonction de signature le smartphone doit contenir une certificat qualifié, que l'utilisateur doit se procurer via l'application itsme auprès d'un fournisseur de certificat qualifié. La clé privée est gérée par l'appli itsme lors de l'installation de l'application itsme sur le smartphone de l'utilisateur [source].

Techniquement, une fois l'activation opérée, le smartphone et sa carte SIM se substituent donc à la carte d'identité et à la carte bancaire, ainsi qu'à leur lecteur dédié.

La contrepartie de la facilité supposée d'un code d'identification unique consiste en une forte régression en matière de sécurité, en raison :

• du remplacement de la carte d'identité par un smartphone – c-à-d un appareil de télécommunication, et dans lequel toutes sortes d'applications peuvent être installées – ce qui accroît considérablement les risques de hacking ;
• le renoncement à des codes d'identifications longs et variés, et alors que des logiciels libres tels que keepassx.org permettent pourtant de les utiliser aussi facilement qu'un code court et unique ;
• le renoncement à un matériel dédié (ce qui, contrairement aux affirmations du consortium, réduit la sécurité de tout système informatique) ;

La supposée "utilité" d'itsme pour les citoyens est donc hautement discutable. Par contre il est incontestable que le bénéfice pour les entreprises privées du consortium est énorme : un accès quasiment illimité aux données officielles et privées des utilisateurs. La législation belge a d'ailleurs du être modifiée pour ce faire ! Nous allons voir qu'Itsme pose de lourdes questions quant à l'indépendance des décideurs politiques qui ont permis ce partenariat public-privé. Pour le démontrer commençons par décrire le mode d'utilisation du "service" itsme.

Utilisation

L'application itsme, une fois installée sur le smartphone de l'utilisateur, permet à celui-ci de s'identifier pour accéder à des services en ligne (sites internet), de confirmer des transactions en ligne, d’introduire une demande de documents officiels et de les signer en ligne.

Pour s'identifier sur un site XYZ à l'aide de itsme l'utilisateur doit :

1. mentionner son numéro de téléphone sur la page d'identification du site XYZ ;
2. sur son mobile l'utilisateur ouvre alors son application itsme et confirme sa demande d'accès au site XYZ ;
3. toujours dans l'application itsme de son mobile l'utilisateur mentionne son code itsme (5 chiffres) ou fait reconnaître son empreinte digitale (si le mobile est équipé pour) ; l'utilisateur est alors identifié par le site XYZ.

Activation

L'abonnement au service Itsme se fait soit via la carte bancaire, soit via la carte d'identité électronique, ce qui requiert leur lecteur dédié. Une fois l'activation réalisée les cartes (et donc leur lecteur) ne sont plus nécessaires pour utiliser itsme et donc pour accéder aux services en ligne compatibles itsme.

La procédure d'inscription à itsme est la suivante :

1. téléchargez l'application itsme sur votre mobile ;
2. mentionnez votre numéro de téléphone dans l'appli itsme ;
3. dans l'appli choisissez de vous inscrire à itsme via votre carte de banque ou votre carte d'identité électronique ;
4. vous êtes alors redirigé vers une page du site web de l'État ou de votre banque, où vous devrez suivre la procédure d'identification au moyen de votre lecteur de carte [détail : État ; banque] ;
5. vous recevez alors sur votre gsm un code de vérification ;
6. tapez ce code dans l'appli itsme de votre mobile ;
7. tapez puis confirmer sur le clavier de votre mobile un code à cinq chiffres de votre choix ; c'est votre code itsme, qu'il vous faudra mentionner à chaque identification sur une site web proposant l'identification itsme.

   Alternativement au code à cinq chiffre, vous pouvez utiliser votre empreinte digitale (si votre smartphone le permet). Le fabriquant du smartphone et celui du lecteur d'empreinte (par exemple touchID d'Apple) sont donc en mesure d'enregistrer votre empreinte digitale dans leur base de données. Même dans le cas où la loi leur interdirait de le faire, il est pratiquement impossible à l'État de vérifier que ces entreprises privées, ou des applications pirates ne le feront pas.

Données collectées et transférées à des tiers

Itsme collecte des données se trouvant sur, ou transitant par la carte d'identité électronique, le téléphone mobile et la carte SIM de l'utilisateur. Certaines de ces données peuvent être transférées à des tiers. Voici une liste non exhaustive des données collectées :

N.B. Les éléments inscrit en gris étaient mentionnés dans les conditions contractuelles de 2018 (V 1.1) [source], mais on été retirés des éléments cités en exemples dans la version de 2022 (V 3.1) [source].

• Données "d'Identité" : nom complet, sexe, adresse légale, nationalité, date et lieu de naissance, numéro de carte d'identité, photo d'identité électronique, adresse de livraison, employeur, fonction dans votre entreprise, numéro d'identification national, e-mail, numéro de téléphone portable, données concernant le mobile, statut de l'inscription auprès de l'opérateur de téléphonie mobile, pays dans lequel se trouve le téléphone mobile, ...

• Données "de sécurité" : marque, version, et type d'appareil, marque et version du système d'exploitation, état de l'abonnement avec l'opérateur mobile , identifiant de l'appareil (IMEI), carte SIM (IMSI ou ICCID), identifiant de l'opérateur du réseau mobile, ...

  On notera que toutes les références à la carte SIM et aux opérateurs de télécommunication ont été retirées ...

• Données transactionnelles : à quelle entité les informations sont envoyées, objet de la transactions, centres d'intérêt de l'utilisateur, ...

• Données de signature : toutes les informations, y compris les données personnelles, qui en vertu du droit national sont nécessaires pour fournir les services de validation de signature électronique.

Traitement des données [source] :

1. les Contrôleurs d'identité (l'État, votre banque, ...) peuvent, périodiquement, communiquer à Itsme les éléments mis à jour à de vos données d'identité ;

2. ces données peuvent être communiquées à toutes les parties avec qui vous traitez via Itsme ! : « en fonction de l'interface technique choisie par les Fournisseurs de Services, les Données d'Identité pourraient leur être communiquées lorsque vous vous connectez auprès de leurs applications ou sites web, ou lors d'une approbation d'une transaction », en outre ces parties ne sont liées que par leur propres conditions concernant le traitement de vos données ! ;

3. ces données peuvent être transmises à Google ! : « Afin d'entreprendre une analyse des Données d'Utilisation et de l'Appareil récoltées via notre App, nous pouvons faire appel à des fournisseurs de service tiers tels que Google Analytics – Firebase. Ces Données d'Utilisation et de l'Appareil sont fournies à ces fournisseurs de service tiers tels que Google afin de leur permettre d'effectuer une analyse de données. Toute information fournie à ces fournisseurs de service tiers sera soumise à la politique de protection de la vie privée de ces fournisseurs de service » ;

4. en fait Itsme peut transmettre vos données à pratiquement n'importe qui !!! : « Nous transférons des données à des tiers qui traitent ces données dans le cadre de l'exécution des Services de itsme en notre nom (sous-traitants ou revendeurs, qui ont intégré nos services dans leur plateformes ou applications et les offrent à leurs clients ou marchands avec lesquels nous n'avons pas de relation contractuelle) » ;

5. même si vous exercez votre droit à l'effacement des données Belgian Mobile ID « continuera à conserver les données personnelles passées qu'à des fins de preuve pendant une période de dix ans » ; Belgian Mobile ID informera tous les Fournisseurs de Services auxquels vos données ont été transmises, mais c'est le fournisseur de service qui « décidera indépendamment de continuer à utiliser les données ultérieurement ou non ».

6. « Nous nous réservons également le droit de transférer les données personnelles que nous avons à votre sujet dans l'hypothèse où nous vendons ou transférons tout ou partie de notre entreprise ou des actifs affectant l'App itsme » ;

Conclusion

La Politique de Confidentialité de Itsme – que l'utilisateur crédule pense être un document légal qui protège ses données contre l'exploitation commerciale – est en réalité un document par lequel il concède au contraire à Belgian Mobile ID le droit d'exploiter commercialement ses données quasiment sans limites !

Sécurité

Nous avons souligné supra que le remplacement de la carte d'identité par un smartphone – c-à-d un appareil de télécommunication, et dans lequel toutes sortes d'applications peuvent être installées – accroît considérablement les risques de hacking.

Ainsi, voici la liste des recommandations mentionnées dans les conditions générales de itsme [source] :

• Ne laissez pas Votre Appareil mobile sans supervision ;
• N'autorisez jamais un tiers à utiliser votre Appareil ;
• Utilisez un logiciel anti-virus et un pare-feu, et ne téléchargez jamais de logiciel piraté ou craqué ("cracked") ;
• Utilisez une connexion internet sécurisée (wifi ou données mobiles);
• Gardez Votre système d’exploitation et votre logiciel actualisés ;
• N’utilisez pas d’Appareils débridés (« jailbroken or rooted devices ») ;
• Ne cliquez pas sur les fenêtres pop-up ou sur les hyperliens qui Vous disent que Votre Appareil est infecté par un virus ;
• Soyez vigilant avec les annexes qui sont jointes aux emails que Vous recevez ;
• Utilisez des mots de passe forts (un mot de passe fort comprend des lettres minuscules et majuscules ainsi que un/des chiffre(s) et un/des symbole(s)) ;
• Soyez attentif au type d’informations que Vous partagez sur les médias sociaux ;
• Avertissez Belgian Mobile ID dès que Vous avez connaissance de la perte ou du vol de Votre Appareil ou du risque de l’utilisation frauduleuse de celui-ci.

Cadre légal

La législation belge a du être modifiée afin de permettre aux acteurs privés « de participer au processus d’identification là où auparavant seul un acteur public y était autorisé » [source]. Mais si seul l'État y était autorisé n'était-ce pas pour de bonnes raisons ? Quelles sont-elles ?

La nouvelle législation marque clairement une renoncement de l'État à ses prérogatives, au bénéfice d'entreprises privées :

• il s'agit notamment d'intégrer des services d'identification privés dans le service d'authentification de l'État via un système d'agrément de services d'identification électroniques privés (dont itsme), ce qui selon le ministre libéral qui a favorisé le projet, permettrait « de maîtriser les coûts, de stimuler l'innovation et d'avoir la garantie d'obtenir les moyens les plus évolués disponibles sur le marché » [source, § 11.04] ;

• les services d'identification privés agréés par l'État (dont itsme) ont accès au numéro de registre national des utilisateurs ! [source, § 11.04]

• les services d'identification privés agréés par l'État (dont itsme) ne sont pas tenus de donner accès au code source ! [source, § 11.04].

• les pouvoirs publics devront désormais accepter tous les moyens d’identification en ligne au niveau de sécurité qu’ils ont prévu pour un service donné, indépendamment du concepteur, qu’il soit privé ou public ! [source, p. 5] ;

• le Roi se voit conférer le pouvoir discrétionnaire de fixer toutes les conditions que doivent remplir les entreprises pour avoir accès aux données à caractère personnel [source, p. 8];

• inquiétante naïveté du ministre qui a favorisé le projet : « Les données à caractère personnel ne peuvent pas être utilisées à des fins commerciales, parce que la loi l’interdit » [source, p. 9] ; ainsi donc les crimes ne peuvent être commis parce que la loi les interdit ! ; mais surtout les affirmations du ministres sont fausses dans la mesure où, si l'exploitation commerciale directe des données n'est certes pas autorisée (NB : le ministre ne mentionne cependant aucune information permettant de vérifier son affirmation), ces données sont cependant la source "indirecte" d'une exploitation commerciale, comme montré supra.

Il serait utile de dresser une liste exhaustive des modifications et ajouts qui ont été apportés aux cadre légal pour rendre itsme licite ...

Des conditions générales abusives ? :

• « Vous pourrez être tenu responsable de tout dommage subi par Belgian Mobile ID ou ses sous-traitants ou un tiers en raison de l’utilisation de Votre Compte itsme, Votre nom d’utilisateur, Votre adresse e-mail ou Code itsme par un tiers. (N.d.A. : souligné par nous) » ! [source].

• Belgian Mobile ID peut-il s'approprier toutes vos données passant par itsme ? : « Tous les droits d'auteur, droits relatifs à la base de données et droits relatifs au software contenus dans, sur, ou disponibles par le biais de l'App itsme, en ce inclus toute information, donnée, texte, musique, son, photographie, graphique et messages vidéos, et tout code source, compilation de software et autre matériel, sont détenus par Belgian Mobile ID ou ses titulaires de licence [source].

• « en aucun cas Belgian Mobile ID ou ses sous-traitants ne seront responsables pour : tout dommage indirect, incident ou consécutif, en ce compris mais non limité à la perte de ou le dommage à la clientèle, la perte de données, le manque à gagner, la perte de profits, l’interruption des activités, les réclamations provenant de tiers, l’atteinte à la réputation ou la non-réalisation d’économies attendues, et ce même si Belgian Mobile ID connaissait ou aurait dû connaître la possibilité ou la probabilité de telles pertes et peu importe (i) si l’action en cause est fondée sur une responsabilité contractuelle ou extracontractuelle (en ce compris la négligence) ou autrement (...). Dans la mesure permise par la loi et nonobstant toute clause contraire figurant dans la présente Convention, la responsabilité totale de Belgian Mobile ID en vertu de cette Convention pour tout dommage subi par Vous n’excèdera pas 200€ » [source] .

• « Le fait pour Belgian Mobile ID de ne pas faire appliquer une disposition de la présente Convention ou de toutes conditions complémentaires ne sera en aucun cas considéré comme une renonciation par Belgian Mobile ID à ces dispositions ou à ses droits de faire valoir cette disposition » [source].

Et concernant le site web itsme-id.com [source]:

• « Ces cookies sont utilisés pour suivre votre activité en ligne et particulièrement de suivre les différents sites web que vous visitez. Ils rassemblent les types de données suivants : nombre et durée des visites sur le Site Web, et données de campagne afférentes aux visites. » .

• « des tiers peuvent placer des cookies sur votre navigateur lorsque vous visitez l’espace entreprise du site internet (...). Ces cookies de tiers sont gérés par notre fournisseur Numberly pour tout ce qui est marketing et par nos fournisseurs At Internet et Commanders Act pour tout ce qui est analytique et tagging. En effet, le site internet contient également des tags qui permettent de collecter des informations relatives à la navigation des utilisateurs. Ces informations comprennent les horaires de navigations, les cookies, l’adresse IP ainsi que l’agent de l’utilisateur. Les tags du site internet sont gérés via l’outil TagCommander de notre fournisseur Commanders Act. » .

• « Les cookies de tiers strictement nécessaires sont placés sur votre appareil dès que vous accédez au site internet alors que les cookies fonctionnels ne sont placés qu'après qu'un choix aura été effectué concernant le placement des autres types de cookies ».
• « Les données collectées à partir des cookies et pixels sont utilisées en accord avec notre politique de protection des données (...). Nous partageons uniquement vos données avec des tiers qui traitent les données à caractère personnel pour notre compte et en accord avec nos politiques (en matière de cookies et de protection de la vie privée). Par ailleurs, nous utilisons ces données à caractère personnel afin d’étudier le comportement d’achat et les préférences des Visiteurs pour notre étude de marché générale

Documents légaux de itsme :

• itsme-id.com/fr-BE/legal/terms-of-use
• itsme-id.com/fr-BE/legal/privacy-statement
• itsme-id.com/fr-BE/legal/cookie-policy

Législation belge concernant le registre national :

• ibz.rrn.fgov.be/fr/registre-national/reglementation/lois-et-reglementation/

Conclusion

Le projet itsme est l'illustration du renoncement de l'État à se maintenir à la pointe des nouveautés via des entreprises publiques (Ministre : « le rôle des pouvoirs publics n'est pas d'être à la pointe de toutes les nouveautés » !!! [source, § 11.01] ), ce qui a pour effet d'entretenir une asymétrie d'information entre État et entreprises privées (Ministre : « cette initiative émanant du secteur privé, mon administration ne dispose que de réponses propres aux choix commerciaux du consortium de développement itsme » !!! [source, § 11.04] ).

Du point de vue de l'État, itsme illustre le renoncement à un savoir faire public en matière d'utilisation commerciale ou non commerciale de données privées et officielles, qui aurait pu être la source de revenus considérables.

Du point de vue des citoyens, itsme c'est un risque très élevé d'être harcelé par des appels et messages téléphoniques pour des offres ou enquêtes commerciales.

Force est de constater qu'Itsme est un énorme cadeau fait par les décideurs politiques belges (*) aux entreprises du consortium privé [liste], et pose de graves questions concernant la compétence et l'indépendance des premiers.

(*) Le Ministre qui a soutenu le projet, mais aussi les parlementaires qui ont voté les adaptations de la loi qui furent nécessaires pour supprimer les mesures de protections contre l'exploitation commerciale des données du registre national.

Nos propositions.

• le pouvoir judiciaire devrait (i) vérifier la constitutionnalité de ce qui constitue manifestement une forme de commercialisation du registre national, et (ii) enquêter sur d'éventuels faits de corruption impliquant d'une part les pouvoirs législatif et exécutif et d'autre part les fondateurs privés du consortium itsme.

• l'État belge pourrait transformer Smals en entreprise(s) publique(s), nationaliser Itsme, et confier son développement à Smals.

  Si nécessaire, l'État ne doit pas hésiter à nationaliser les entreprises du consortium itsme.

• l'État belge devrait également créer un site web dédié à la publication de spécifications, à l'attention des développeurs de logiciels libres et de plans libres. L'État propose alors aux développeurs des solutions choisies de les implémenter et de les gérer dans le cadre de coopératives publiques.