Ce billet fait suite à un article publié par les confrères du soir, qui sur un titre provocateur sur une eID non sûre, explique de manière plutôt maladroite la manière dont fonctionne une authentification sur Internet.
Avant de revenir sur le fond, un petit disclaimer s'impose, à savoir que même si la réaction ici n'est que pure technique, l'eID est un de mes outils de travail de tous les jours. Ceci étant dit, revenons en aux faits.
Dans l'article du Soir, on indique donc que l'eID pose un problème de sécurité car, si on réouvre la page de TaxOnWeb quelques secondes après l'ouverture, la connexion sera toujours active, même si vous n'avez plus l'eID en place. Non, mais allô?
Pour bien comprendre comment cela fonctionne, il faut savoir comment fonctionne l'eID, et le web. D'un côté, on a une carte qui permet de faire 3 choses: s'identifier (dire qui on est), s'authentifier (dire qui on est, et qu'on en est le propriétaire) et signer une transaction. Typiquement, pour un système critique comme TaxOnWeb, ou un système bancaire, on a besoin de s'authentifier avec le code pin, puis pour certaines actions, typiquement un virement, on doit le signer et donc remettre la carte. Si tant est donc que le système était peu sécurisé sur une réouverture de page, toute action importante devrait demander signature et donc imposer la présence de la carte.
Mais cela n'empêchera pas un accès aux données me direz-vous? Que neni. La technique utilisée par le gouvernement est ce qu'on appelle le "reverse proxy". En gros, lorsque vous vous authentifiez, le certificat SSL est regénéré avec une signature de votre carte, et cette session indique que vous en êtes le "propriétaire". Mais pour que cela fonctionne, il faut également un cookie de session chez l'utilisateur, sinon, chaque personne sur la même IP pourrait se faire passer pour vous. Le cookie est donc indispensable, et c'est grâce à lui que l'on pourra rester connecté pendant un certain temps défini par le serveur. Et c'est ce cookie de session qui semble prendre la foudre des journalistes, essayant par la même, en criant au scandale, de décrédibiliser une autre technologie.
Mais savent-ils réellement de quoi ils parlent, dans le fond? Parce que chaque banque repose sur ce même système, dont certaines ne réclament même pas de signature pour des virements. Les banques seraient donc non sécurisées? ... Vaste débat, mais pour certaines, on peut mieux faire. Et pour la session donc? Généralement, les sites fournissent un cookie avec une durée de vie, courte pour les banques, et certains proposent même de prolonger ce cookie avant qu'il n'expire. Et pourtant, la norme propose tout simplement d'envoyer une durée de vie 0, qui demande explicitement au navigateur d'oublier le cookie une fois la fenêtre fermée, et de rendre ainsi la ré-authentification obligatoire.
Quoi? Mais donc on nous raconte n'importe quoi? ... Joker, mais il faut croire que de disposer d'une technologie en avance sur de nombreux autres pays semble déranger une partie des "bobos gauchistes", qui ne se priveront jamais de critiquer plutôt que d'essayer de valoriser ce que notre pays peut faire. Est-ce réellement ce dont nous avons besoin pour le moment?
Sur ces bonnes paroles, bon weekend à tous!
Avant de revenir sur le fond, un petit disclaimer s'impose, à savoir que même si la réaction ici n'est que pure technique, l'eID est un de mes outils de travail de tous les jours. Ceci étant dit, revenons en aux faits.
Dans l'article du Soir, on indique donc que l'eID pose un problème de sécurité car, si on réouvre la page de TaxOnWeb quelques secondes après l'ouverture, la connexion sera toujours active, même si vous n'avez plus l'eID en place. Non, mais allô?
Pour bien comprendre comment cela fonctionne, il faut savoir comment fonctionne l'eID, et le web. D'un côté, on a une carte qui permet de faire 3 choses: s'identifier (dire qui on est), s'authentifier (dire qui on est, et qu'on en est le propriétaire) et signer une transaction. Typiquement, pour un système critique comme TaxOnWeb, ou un système bancaire, on a besoin de s'authentifier avec le code pin, puis pour certaines actions, typiquement un virement, on doit le signer et donc remettre la carte. Si tant est donc que le système était peu sécurisé sur une réouverture de page, toute action importante devrait demander signature et donc imposer la présence de la carte.
Mais cela n'empêchera pas un accès aux données me direz-vous? Que neni. La technique utilisée par le gouvernement est ce qu'on appelle le "reverse proxy". En gros, lorsque vous vous authentifiez, le certificat SSL est regénéré avec une signature de votre carte, et cette session indique que vous en êtes le "propriétaire". Mais pour que cela fonctionne, il faut également un cookie de session chez l'utilisateur, sinon, chaque personne sur la même IP pourrait se faire passer pour vous. Le cookie est donc indispensable, et c'est grâce à lui que l'on pourra rester connecté pendant un certain temps défini par le serveur. Et c'est ce cookie de session qui semble prendre la foudre des journalistes, essayant par la même, en criant au scandale, de décrédibiliser une autre technologie.
Mais savent-ils réellement de quoi ils parlent, dans le fond? Parce que chaque banque repose sur ce même système, dont certaines ne réclament même pas de signature pour des virements. Les banques seraient donc non sécurisées? ... Vaste débat, mais pour certaines, on peut mieux faire. Et pour la session donc? Généralement, les sites fournissent un cookie avec une durée de vie, courte pour les banques, et certains proposent même de prolonger ce cookie avant qu'il n'expire. Et pourtant, la norme propose tout simplement d'envoyer une durée de vie 0, qui demande explicitement au navigateur d'oublier le cookie une fois la fenêtre fermée, et de rendre ainsi la ré-authentification obligatoire.
Quoi? Mais donc on nous raconte n'importe quoi? ... Joker, mais il faut croire que de disposer d'une technologie en avance sur de nombreux autres pays semble déranger une partie des "bobos gauchistes", qui ne se priveront jamais de critiquer plutôt que d'essayer de valoriser ce que notre pays peut faire. Est-ce réellement ce dont nous avons besoin pour le moment?
Sur ces bonnes paroles, bon weekend à tous!
Liens
L'article sur le site du soir (323 Clics)
Plus d'actualités dans cette catégorie
Commentaires
SHERIF:
L'eID pas sûre? Ou quand le journaliste parle technique
je ne sais toujours pas, à vous lire, quelle est la vérité technique !!!
rfr:
L'eID pas sûre? Ou quand le journaliste parle technique
D'accord. Un "reverse proxy" n'a absolument rien à voir avec SSL. C'est juste un moyen architectural pour fournir des services comme le fail-over, le load-balancing, le caching et ... parfois SSL, sur des services qui ne le supportent pas (ou pas bien). Peut-être que Tax-on-web l'utilise (et je n'en doute pas), mais ça n'a rien avoir avec l'eID.
En ce qui concerne l'eID, c'est relativement simple mais il n'y a pas de régénération de certificats. En fait, la sécurité de Tax-on-web est liée à l'établissement d'une connexion entre deux parties (via SSL) dans laquelle chacune des parties qui entrent en communication peut-être authentifiée. La plupart du temps, c'est juste le serveur qui est authentifié parce que son certificat à été signé par des autorités de certifications qui sont installées dans le browser (Firefox) ou le système (IE et Chrome) et parce qu'il détient la clé privée associée au certificat.
Dans le cas de l'eID, le serveur demande au client (le surfeur, le citoyen) de s'authentifier. Pour cela, le browser envoie le certificat d'authentification contenu dans l'eID au serveur qui commence par valider le fait que le certificat a été signé par une autorité de certification reconnue (ici, Belgium CA, donc la Belgique) et qu'il n'est pas révoqué. Une fois cette vérification faite, le serveur va demander au client de prouver que le certificat envoyé appartient bien à la personne qui se connecte. Pour cela, le serveur va demander au client de signer un message. C'est à ce moment que la sécurité intervient car c'est la puce de l'eID elle-même qui va signer ce message, une fois le code pin du citoyen introduit. Il est en effet "impossible" de lire cette clé privée sur l'eID. Une fois que le serveur aura fait cette ultime vérification, l'établissement d'une connexion SSL/TLS pourra se faire.
Une fois cette connexion établie, il n'y a effectivement plus besoin de l'eID. Après, c'est la mécanique des sessions HTTP classiques qui s'appliquent effectivement.
Mais pendant une connexion, il peut se produire une renégociation de la connexion. Et sans eID, ça pourrait ne pas fonctionner. Mais il faudrait tester.
C'est une matière difficile à vulgariser car sans expliquer les principes de la signature électronique, c'est impossible à comprendre, malheureusement.
Mais dire "le soir/belga", vous êtes trop con et raconter des choses incorrectes (et je n'y vois aucune "vulgarisation", juste des erreurs), c'est un peu se faire un auto-croche-pied.
Leur approche est peut-être naïve, mais d'un coté, je les comprends. Il est vrai que c'est un peu bizarre que quand on enlève une "clé" (ici l'eID), le système continue à fonctionner. Une voiture, si tu enlèves la clé, elle s'arrête. Même avec les système keyless. Si la carte est trop loin, la voiture s'arrête.
Leur erreur est de croire que c'est un problème d'eID alors que c'est liés aux protocoles cryptographiques utilisés. Et que ça ne pose aucun soucis, tant que l'utilisateur comprend bien que pour terminer la session, il doit se déconnecter manuellement via la fonctionnalité prévue et non en enlevant son eID du lecteur. Faire confiance au timeout d'un cookie serait d'ailleurs une erreur. C'est, au plus, un garde fou.
En ce qui concerne l'eID, c'est relativement simple mais il n'y a pas de régénération de certificats. En fait, la sécurité de Tax-on-web est liée à l'établissement d'une connexion entre deux parties (via SSL) dans laquelle chacune des parties qui entrent en communication peut-être authentifiée. La plupart du temps, c'est juste le serveur qui est authentifié parce que son certificat à été signé par des autorités de certifications qui sont installées dans le browser (Firefox) ou le système (IE et Chrome) et parce qu'il détient la clé privée associée au certificat.
Dans le cas de l'eID, le serveur demande au client (le surfeur, le citoyen) de s'authentifier. Pour cela, le browser envoie le certificat d'authentification contenu dans l'eID au serveur qui commence par valider le fait que le certificat a été signé par une autorité de certification reconnue (ici, Belgium CA, donc la Belgique) et qu'il n'est pas révoqué. Une fois cette vérification faite, le serveur va demander au client de prouver que le certificat envoyé appartient bien à la personne qui se connecte. Pour cela, le serveur va demander au client de signer un message. C'est à ce moment que la sécurité intervient car c'est la puce de l'eID elle-même qui va signer ce message, une fois le code pin du citoyen introduit. Il est en effet "impossible" de lire cette clé privée sur l'eID. Une fois que le serveur aura fait cette ultime vérification, l'établissement d'une connexion SSL/TLS pourra se faire.
Une fois cette connexion établie, il n'y a effectivement plus besoin de l'eID. Après, c'est la mécanique des sessions HTTP classiques qui s'appliquent effectivement.
Mais pendant une connexion, il peut se produire une renégociation de la connexion. Et sans eID, ça pourrait ne pas fonctionner. Mais il faudrait tester.
C'est une matière difficile à vulgariser car sans expliquer les principes de la signature électronique, c'est impossible à comprendre, malheureusement.
Mais dire "le soir/belga", vous êtes trop con et raconter des choses incorrectes (et je n'y vois aucune "vulgarisation", juste des erreurs), c'est un peu se faire un auto-croche-pied.
Leur approche est peut-être naïve, mais d'un coté, je les comprends. Il est vrai que c'est un peu bizarre que quand on enlève une "clé" (ici l'eID), le système continue à fonctionner. Une voiture, si tu enlèves la clé, elle s'arrête. Même avec les système keyless. Si la carte est trop loin, la voiture s'arrête.
Leur erreur est de croire que c'est un problème d'eID alors que c'est liés aux protocoles cryptographiques utilisés. Et que ça ne pose aucun soucis, tant que l'utilisateur comprend bien que pour terminer la session, il doit se déconnecter manuellement via la fonctionnalité prévue et non en enlevant son eID du lecteur. Faire confiance au timeout d'un cookie serait d'ailleurs une erreur. C'est, au plus, un garde fou.
rfr:
L'eID pas sûre? Ou quand le journaliste parle technique
Et je pense d'ailleurs que l'article (que je viens de lire) parle d'un autre soucis qui est bien réel.
C'est à dire la possibilité de se reconnecter (même après avoir effecteur une déconnexion) sur tax-on-web alors que l'eID n'est plus présente. C'est théoriquement (et visiblement pratiquement) possible parce que le browser, si on ne ferme pas la fenêtre (et peut-être même si on la ferme) va garder la connexion SSL ouverte pendant un certain temps. Et donc une autre personne pourra se "reconnecter" avec l'identité de la personne précédente car la connexion est en réalité toujours établie (alors que l'utilisateur pense que tout est "fermé").
Et c'est vrai que c'est un soucis. Et même si ce n'est pas lié à l'eID, ça rend son utilisation dans des lieux comme les cybercafés peu sûre.
D'ailleurs, vu comment fonctionne l'eID, je ne recommanderais pas de l'utiliser dans des ordinateurs publics pour s'authentifier ou signer des données.
Bref, l'article de Belga est plutôt correcte ...
C'est à dire la possibilité de se reconnecter (même après avoir effecteur une déconnexion) sur tax-on-web alors que l'eID n'est plus présente. C'est théoriquement (et visiblement pratiquement) possible parce que le browser, si on ne ferme pas la fenêtre (et peut-être même si on la ferme) va garder la connexion SSL ouverte pendant un certain temps. Et donc une autre personne pourra se "reconnecter" avec l'identité de la personne précédente car la connexion est en réalité toujours établie (alors que l'utilisateur pense que tout est "fermé").
Et c'est vrai que c'est un soucis. Et même si ce n'est pas lié à l'eID, ça rend son utilisation dans des lieux comme les cybercafés peu sûre.
D'ailleurs, vu comment fonctionne l'eID, je ne recommanderais pas de l'utiliser dans des ordinateurs publics pour s'authentifier ou signer des données.
Bref, l'article de Belga est plutôt correcte ...
H2G2:
L'eID pas sûre? Ou quand le journaliste parle technique
Sens être parano (j'espère) je dois dire qu'un cybercafé ne me semble de toute façon pas l'endroit idéal pour remplir une déclaration, effectuer une opération PCBanking ou commander sur le web en payant avec une carte de crédit...
zion:
L'eID pas sûre? Ou quand le journaliste parle technique
rfr> Merci pour ta réponse.
Je ne nie pas qu'ils ont raison sur le fond, mais la forme me dérange. Si A implique B, et que B implique C, A n'implique pas forcément C.
Et oui, il y a un soucis sur TaxOnWeb, et oui on y utilise l'eID, mais l'eID n'est en rien en cause, c'est la manière dont on gère la session qui n'est pas complètement idéale, et je me répète, les systèmes de web banking sont quasi tous sur un modèle similaire.
(A propos, oui, il y a toujours renégociation, la clé SSL est toujours modifiée pour une connexion sur TaxOnWeb).
Tout d'abord, cette situation ne peut se produire que si un pirate est dans la même pièce que toi. Je ne laisse pas un russe ou un chinois que je ne connais pas rentrer et jouer sur mon PC. Et si je suis assez con que pour me connecter sur un browser qui n'est pas en mode incognito dans un cyber café, je ne peux pas en vouloir à la technologie.
Pour les solutions, ils peuvent limiter la session à la fenêtre, je ne sais pas comment réagissent les browsers à tab, mais si ils sont bien pensés ils doivent aussi fermer la session quand on ferme la tab. Et tout ce débat est clôturé. Sinon, le mec peut cliquer sur "logout", ça ne me semble pas être surhumain à lui demander...
Et finalement, sur la version applet (non reverse proxy), il y a une fonction qui permet de ne donner accès que si on a toujours l'eID présente à chaque fois (le mode "kiosque" si je me souviens bien). Donc, là encore, une solution technique, qui s'attaque au problème de sécurisation de la session, non pas de la carte qui elle n'est qu'une simple machine à signer.
L'amalgame de la sécurité, que je ne trouve quand même pas si mauvaise au final, des plateformes gouvernementales et de l'eID, ça ne me plaît pas
L'article de base est volontairement provocateur, et toute personne non habituée fera un amalgame évident entre l'eID et le problème sous-jacent.
Pour preuve, depuis cet article, j'ai 2 amis hier soir qui m'ont demandé si tout allait bien, si le Fedict n'allait pas devoir arrêter l'eID, et encore pareil ce midi. Cela crée un climat de méfiance qui est détestable, et ça, le journaliste il s'en cogne, il a fait son titre accrocheur, il a vendu, et les conséquences c'est que ce soir, il est dans sa piscine, et moi on m'emmerde.
Je ne nie pas qu'ils ont raison sur le fond, mais la forme me dérange. Si A implique B, et que B implique C, A n'implique pas forcément C.
Et oui, il y a un soucis sur TaxOnWeb, et oui on y utilise l'eID, mais l'eID n'est en rien en cause, c'est la manière dont on gère la session qui n'est pas complètement idéale, et je me répète, les systèmes de web banking sont quasi tous sur un modèle similaire.
(A propos, oui, il y a toujours renégociation, la clé SSL est toujours modifiée pour une connexion sur TaxOnWeb).
Tout d'abord, cette situation ne peut se produire que si un pirate est dans la même pièce que toi. Je ne laisse pas un russe ou un chinois que je ne connais pas rentrer et jouer sur mon PC. Et si je suis assez con que pour me connecter sur un browser qui n'est pas en mode incognito dans un cyber café, je ne peux pas en vouloir à la technologie.
Pour les solutions, ils peuvent limiter la session à la fenêtre, je ne sais pas comment réagissent les browsers à tab, mais si ils sont bien pensés ils doivent aussi fermer la session quand on ferme la tab. Et tout ce débat est clôturé. Sinon, le mec peut cliquer sur "logout", ça ne me semble pas être surhumain à lui demander...
Et finalement, sur la version applet (non reverse proxy), il y a une fonction qui permet de ne donner accès que si on a toujours l'eID présente à chaque fois (le mode "kiosque" si je me souviens bien). Donc, là encore, une solution technique, qui s'attaque au problème de sécurisation de la session, non pas de la carte qui elle n'est qu'une simple machine à signer.
L'amalgame de la sécurité, que je ne trouve quand même pas si mauvaise au final, des plateformes gouvernementales et de l'eID, ça ne me plaît pas
L'article de base est volontairement provocateur, et toute personne non habituée fera un amalgame évident entre l'eID et le problème sous-jacent.
Pour preuve, depuis cet article, j'ai 2 amis hier soir qui m'ont demandé si tout allait bien, si le Fedict n'allait pas devoir arrêter l'eID, et encore pareil ce midi. Cela crée un climat de méfiance qui est détestable, et ça, le journaliste il s'en cogne, il a fait son titre accrocheur, il a vendu, et les conséquences c'est que ce soir, il est dans sa piscine, et moi on m'emmerde.
SHERIF:
L'eID pas sûre? Ou quand le journaliste parle technique
il est vrai que les journalistes ont parfois tendance à semer le doute. Mais soyons constructifs ils sont aussi à la base d'alertes sérieuses. Bon W-E et désolé de vous avoir emm...
philfr:
L'eID pas sûre? Ou quand le journaliste parle technique
Nic007:
L'eID pas sûre? Ou quand le journaliste parle technique
Faut croire que tous les Sébastien sont énervés après les bobos cette semaine
users_user-179.html:
L'eID pas sûre? Ou quand le journaliste parle technique
Merci rfr et bouh à Zion. Pousser un coup de gueule sur un amalgame, OK. Mais la généralisation de "bobos de gauche", ça casse complètement la crédibilité du reste de l'article. Je suis d'accord que l'article du Soir fait du sensationnel pour rien. Parce que fondamentalement, même si on y a toujours accès après avoir retiré la carte, quel est le risque d'abus ? Minime.
En fait, je pense que le souci du fonctionnement de l'eID dans ce cadre-ci est que le certificat est importé dans le browser quand on s'authentifie et qu'il n'est pas possible pour le site de l'en faire sortir. Mais là, bien sûr, il faudrait que les mécanismes habituels de gestion de session forcent une nouvelle vérification sur l'eID.
Le principe du reverse proxy n'est pas mauvais en soi. Mais j'avais toujours vu ça comme un moyen "transitoire" de déployer de l'eID sur une plateforme pas conçue pour à la base. Le site derrière le RP ne connaît rien à l'eID en-dehors de ce que le RP lui en dit. Et c'est dommage pour tax on web puisque ça le prive de certains contrôles fins. Mais ce ne sont que suppositions de ma part.
Sur l'eID en lui-même, j'ai vu une conférence au BruJUG sur le sujet. L'orateur ne m'a pas du tout convaincu sur les nouveautés de l'eID, a critiqué le fait que le hardware et le software de cette carte sont très séparés et que ceux qui gèrent le hardware sont obtus face à toute demande pour faciliter le software. Il a aussi rejeté toute suggestion d'utilisation sur smartphone "parce que ce sont juste des jouets". Il a craché pas mal de fois sur iOS "parce qu'Apple c'est fermé et c'est de la merde". Il a classé les utilisateurs de Mac comme des emmerdeurs qui demandent de leur part beaucoup de travail alors qu'ils sont minoritaires mais, je cite, "quand un mec a payé 5000€ un PC qui en vaut 2000, il ne veut rien savoir, il a payé cher, il veut que ça marche". Il ignorait aussi qu'il existait des lecteurs de cartes à puce pour iPhone/iPad et a rejeté l'idée "parce qu'Apple c'est fermé"...
Quant à l'innovation, il faut arrêter de se gausser et regarder la réalité: d'autres pays l'ont fait. Et franchement, qui utilise sa carte d'identité pour autre chose que tax-on-web ? J'ai eu un vidéo-club une fois, en contravention totale avec les règles. Ou la carte de fidélité qu'il est hors de question que j'utilise tellement c'est une confusion de genres dangereuse... En fait, j'utilise plus souvent ma carte LuxTrust que mon eID... Je pense que ça vient en grande partie du manque de limpidité des API et du fait que.... bordel de merde, ça ne marche jamais convenablement. Chaque année, je galère et finis par ressortir mon vieux laptop sous XP, 8 ans d'âge. Sur le Mac, ça n'a jamais marché (et mon java marche bien pourtant) et même sur mon PC sous Windows 7, je n'y arrive pas. Alors bon, le clampain moyen...
En fait, je pense que le souci du fonctionnement de l'eID dans ce cadre-ci est que le certificat est importé dans le browser quand on s'authentifie et qu'il n'est pas possible pour le site de l'en faire sortir. Mais là, bien sûr, il faudrait que les mécanismes habituels de gestion de session forcent une nouvelle vérification sur l'eID.
Le principe du reverse proxy n'est pas mauvais en soi. Mais j'avais toujours vu ça comme un moyen "transitoire" de déployer de l'eID sur une plateforme pas conçue pour à la base. Le site derrière le RP ne connaît rien à l'eID en-dehors de ce que le RP lui en dit. Et c'est dommage pour tax on web puisque ça le prive de certains contrôles fins. Mais ce ne sont que suppositions de ma part.
Sur l'eID en lui-même, j'ai vu une conférence au BruJUG sur le sujet. L'orateur ne m'a pas du tout convaincu sur les nouveautés de l'eID, a critiqué le fait que le hardware et le software de cette carte sont très séparés et que ceux qui gèrent le hardware sont obtus face à toute demande pour faciliter le software. Il a aussi rejeté toute suggestion d'utilisation sur smartphone "parce que ce sont juste des jouets". Il a craché pas mal de fois sur iOS "parce qu'Apple c'est fermé et c'est de la merde". Il a classé les utilisateurs de Mac comme des emmerdeurs qui demandent de leur part beaucoup de travail alors qu'ils sont minoritaires mais, je cite, "quand un mec a payé 5000€ un PC qui en vaut 2000, il ne veut rien savoir, il a payé cher, il veut que ça marche". Il ignorait aussi qu'il existait des lecteurs de cartes à puce pour iPhone/iPad et a rejeté l'idée "parce qu'Apple c'est fermé"...
Quant à l'innovation, il faut arrêter de se gausser et regarder la réalité: d'autres pays l'ont fait. Et franchement, qui utilise sa carte d'identité pour autre chose que tax-on-web ? J'ai eu un vidéo-club une fois, en contravention totale avec les règles. Ou la carte de fidélité qu'il est hors de question que j'utilise tellement c'est une confusion de genres dangereuse... En fait, j'utilise plus souvent ma carte LuxTrust que mon eID... Je pense que ça vient en grande partie du manque de limpidité des API et du fait que.... bordel de merde, ça ne marche jamais convenablement. Chaque année, je galère et finis par ressortir mon vieux laptop sous XP, 8 ans d'âge. Sur le Mac, ça n'a jamais marché (et mon java marche bien pourtant) et même sur mon PC sous Windows 7, je n'y arrive pas. Alors bon, le clampain moyen...
Clandestino:
L'eID pas sûre? Ou quand le journaliste parle technique
Merlin > qui utilise son eid ? Oh, juste 670.000 personnes au quotidien...