La légalité du décret est assise sur un ensemble législatif ancien, porteur, en lui-même, des dangers que ce fichier TES met brutalement en lumière aujourd'hui. L'article 27 de la loi dite « informatique et libertés » de 1978 laisse au gouvernement la faculté d'instituer, par un simple décret, tous traitements de données à caractère personnel pour le compte de l'État, ou touchant à la sécurité nationale. Pire, depuis 2004, les données biométriques sont soumises au même régime, au mépris de leur sensibilité extrême. De cette honteuse manœuvre, notre démocratie devrait tirer toutes conséquences : l'absence de contrôle parlementaire sur la création de fichiers concernant les individus par l'exécutif doit être combattue.

[...]

[...] Entre l'origine d'un fichier et son utilisation ultérieure, il y a systématiquement des dérives : changement de finalité, érosion progressive du contrôle, modification du champ d'application ou de l'étendue des accès à ce fichier... Même suite à des condamnations, y compris par la Cour Européenne des Droits de l'Homme, les fichiers ne sont pas, ou peu et tardivement corrigés. La France a été condamnée en 2013 par la CEDH pour le FAED (Fichier Automatisé des Empreintes Digitales) au motif que « La conservation des empreintes digitales par ce fichier s’analyse en une atteinte disproportionnée, ne peut passer pour nécessaire dans une société démocratique, et ne traduit pas un juste équilibre entre les intérêts publics et privés concurrents en jeu ». Pourtant ce fichier n’a été corrigé à la marge que deux ans après l'arrêt de la CEDH. Quant au FNAEG (Fichier National Automatisé des Empreintes Génétiques) créé pour ficher les auteurs d'infractions sexuelles condamnés par la justice, il est passé en 15 ans d'un fichier sous contrôle judiciaire et limité à un fichier policier recueillant l'ADN de toutes les personnes simplement suspectes dans les enquêtes pour les délits les moins graves, même sans condamnation et dont le refus de prélèvement est susceptible de constituer un délit.

[...]

Le choix de la centralisation du fichier est un choix dangereux : il expose un ensemble massif et précieux de données personnelles à la portée de puissances hostiles ou de criminels expérimentés. Les promesses réitérées de chiffrement robuste et de sécurisation avancée faites par le ministre de l'Intérieur seront évidemment invérifiables, et pourront difficilement compenser l'absence de résilience qu'aurait apportée une décentralisation du fichier, soit au niveau du porteur individuel de titre d'identité, soit au niveau des différentes composantes du fichier. Choisir la centralisation des données d'identification de l'ensemble des Français c'est choisir d'être une cible très alléchante, comme l'ont montré les attaques subies par des bases de données israéliennes, turques ou philippines. La question n'est donc pas : TES sera-t-il attaqué, mais : quand le sera-t-il ?

[...]

Si la volonté d'empêcher techniquement toute falsification peut sembler légitime, l'histoire nous rappelle combien la capacité à résister à des dérives autoritaires passe par la faculté d'échapper au contrôle étatique, notamment sur son identité. Les fichiers centralisés ne font pas les régimes autoritaires, mais tout régime autoritaire s'appuie sur un fichage de sa population. L'ajout de nombreux marqueurs biométriques aux éléments de filiation ou d'état civil renforce l'attachement de l'individu, par son corps, à l'État. Nul ne peut exclure des usages liberticides d'un tel fichier à l'avenir, et toute évolution vers plus d'identification devrait être discutée démocratiquement dans cette perspective.

Bien évidemment, ces agents sont individuellement désignés et habilités et en théorie, leur accès est réduit à un nombre limité de finalité.

En théorie …

Car chacun sait que les premiers abus d’accès à tels traitements, viennent de l’intérieur.

Il est tout à fait humain et tentant, de consulter la fiche de son voisin avec lequel les relations ne sont pas toujours au beau fixe.

On peut aussi s’amuser à consulter des célébrités.

On peut aussi rendre un service … Après tout, ça n'est pas méchant et c’est très valorisant. En réalité, la chose ne paraît pas grave.

Il est très difficile voire quasi impossible de prévenir de tels comportements, l’abus venant de l’intérieur c’est-à-dire de ceux connaissant intimement le fonctionnement du système.

A la NSA, cette pratique a même un nom. On l’appelle la LOVEINT par référence à l’usage par lequel on utilise son accès pour son partenaire amoureux, sa compagne ou son compagnon.

Dans son livre « Data and Goliath », Bruce Schneier évoque cette pratique illégale mais qui peut ne pas être sans conséquence pour les personnes concernées.

Citant Edward Snowden et un audit de la NSA réalisé sur 12 mois entre 2011 et 2012, il révèle que cette pratique aurait été relevée durant cette période 2.776 fois.

Il ajoute que le chiffre devrait être bien plus important, car les chiffres venaient de la NSA elle-même …

Bien évidemment, plus le fichier est gros, plus le nombre de personnes autorisées à y accéder est important, plus le risque est grand de voir se développer le LOVEINT.

Il n’y aucune raison que ce type de comportements se limite d’ailleurs aux fichiers publics, et on n’ose imaginer ce qui se passe dans certaines grandes entreprises d’outre Atlantique, aspirateurs de donnée à caractère personnel venant du monde entier et renfermant toutes sortes de renseignements.

Très bon argumentaire. :)

"La CEDH se mêle de plus en plus de questions de société, qui font notre identité. On ne peut pas l'accepter. Je proposerai que la France quitte la CEDH", lance François Fillon au cours d'un meeting, après que la Cour a condamné la France pour avoir refusé de reconnaître la filiation d'enfants nés de mères porteuses à l'étranger.

Oui, les Droits des hommes et des femmes sont une question de société. Il est donc normal que la CEDH s'en préoccupe. Quel scoop !

"Si je suis élu président de la République, je proposerai la modification" de la Convention européenne des droits de l'Homme, sur laquelle veille la CEDH, "parce que j'affirme que rien ne justifie plus qu'on n'expulse pas les terroristes étrangers, les prêcheurs de haine et des délinquants", attaque Nicolas Sarkozy.

Ouiiiii, quand les droits des hommes et des femmes dérangent, on les met de côté ou on les abroge, c'est tellement plus facile.

[...]

La CEDH, qui dépend du Conseil de l'Europe et non de l'Union européenne, est un club de 47 États, dont sont membres la Turquie et la Russie. Son siège est à Strasbourg. Une sortie de la France de la CEDH l'exclurait du Conseil de l'Europe.

C'est ballot.

"On peut modifier la Convention, mais il n'est encore jamais arrivé que les Etats membres soient d'accord pour retirer un droit", souligne-t-il.

Et si un article de la Convention prévoit qu'un État peut formuler une réserve concernant une disposition particulière, il interdit les réserves "de caractère général" qui videraient un article de sa substance.

Il reste que pour les experts de la CEDH, les critiques méconnaissent sa jurisprudence. Sur le regroupement familial et la GPA, cette jurisprudence "est beaucoup plus prudente à l'égard de la souveraineté des États que les candidats veulent le dire", explique Vincent Berger.

Ainsi, l'article protégeant la vie familiale, dénoncé par Nicolas Sarkozy, n'interdit pas à un État d'expulser une personne menaçant la sécurité nationale. La CEDH peut en revanche s'y opposer si cette personne risque la torture dans son pays d'origine.

De même, "l'article qui garantit le droit à la vie permet parfaitement à un policier qui se sent menacé de tirer sur un agresseur", ajoute Vincent Berger.

LALA. Les raccourcis faciles, tout ça.

http://www.lefigaro.fr/politique/le-scan/2016/10/26/25001-20161026ARTFIG00282-lui-president-fillon-pourrait-quitter-la-cour-europeenne-des-droits-de-l-homme.php :

Sur ce point, François Fillon rejoint donc Marine Le Pen. La présidente du Front national appelait dès octobre 2014 «à couper le cordon» avec l'institution, accusée d'aller «contre l'avis des peuples» et d'«imposer aux peuples une vision que celui-ci rejette».

Via http://sebsauvage.net/links/?cVTeIQ

[...] Il en découle logiquement que, si un nœud de l'arbre n'existe pas, les nœuds situés en dessous n'existent pas non plus. C'est évident ? Hélas, non. En pratique, bien des résolveurs DNS sont prudents et, lorsqu'ils reçoivent une réponse négative pour un nom, mettons foo.example, ils n'enregistrent pas pour autant le fait que les sous-domaines comme bar.foo.example n'existent pas non plus, et, si un client leur demande des informations sur ce sous-domaine, ils vont relayer la question aux serveurs faisant autorité, alors qu'ils auraient parfaitement pu répondre à partir de leur cache. Ce nouveau RFC remet les choses en place : les noms de domaine sont organisés en arbre, ce comportement traditionnel est donc bel et bien erroné, et un résolveur devrait, lorsqu'il reçoit une réponse négative, mémoriser le fait qu'il n'y a pas non plus de sous-domaines de ce nom. [...]

[...]

Pourquoi le résolveur est-il si prudent, et pose-t-il au serveur faisant autorité une question dont il aurait déjà dû connaitre la réponse ? Il y a plusieurs raisons mais la principale est que le RFC originel sur le DNS, le RFC 1034, est ambigu. Il ne décrivait pas de manière parfaitement claire ce qu'il faut faire lorsqu'un nom de domaine est un ENT, un Empty Non-Terminal, c'est-à-dire un nom de domaine qui n'a pas d'enregistrements mais qui a des sous-domaines. Certains ont pensé que cela autorisait à répondre NXDOMAIN lorsque le nom demandé est un ENT. Ce comportement a été clairement noté comme incorrect dans les RFC ultérieurs (section 7.16 du RFC 2136 et sections 2.2.2 et 2.2.3 du RFC 4592) mais tout le monde n'en avait pas forcément tiré les conséquences. Autre RFC qui contribuait au comportement erroné, le RFC 2308 (dans sa section 5) faisait l'erreur de dire qu'un résolveur ne pouvait renvoyer un NXDOMAIN que si la question portait sur exactement le même nom que celui qui avait été mis en cache. Notre nouveau RFC 8020 corrige cette erreur : un résolveur doit également renvoyer NXDOMAIN si la question est un sous-domaine d'un domaine inexistant.

[...]

La section 4 de notre RFC détaille les bénéfices attendus du NXDOMAIN cut. Le principal est la diminution de la latence des réponses, et celle de la charge des serveurs faisant autorité. On aura moins de requêtes, donc un bénéfice pour tout l'écosystème. Cela sera encore plus efficace avec la QNAME minimisation du RFC 7816, puisque le résolveur pourra arrêter son traitement dès qu'il y aura un domaine absent.

Cela sera aussi utile dans le cas de certaines attaques par déni de service, notamment les attaques random QNAMEs avec un suffixe un peu long (comme dans le cas de l'attaque dafa888).

[...]

Un petit mot de sécurité, maintenant qu'on approche de la fin. Si un résolveur accepte un NXDOMAIN mensonger (attaque par empoisonnement), les conséquences risquent d'être sérieuses puisque c'est un sous-arbre entier qui serait « détruit ». C'est pour cela que le RFC autorise un résolveur prudent à ne pratiquer le NXDOMAIN cut que si le NXDOMAIN a été validé avec DNSSEC. C'est ce que fait Unbound, cité plus haut. Notez que, si on a DNSSEC, une technique encore plus puissante consiste à synthétiser des réponses NXDOMAIN en utilisant les enregistrements NSEC. Elle est décrite dans un Internet-Draft actuellement en cours de discussion.

Un problème classique du système de cryptographie OpenPGP, normalisé dans le RFC 4880 est de vérifier les clés publiques des correspondants. Les trouver, c'est relativement facile : le correspondant pense à vous les envoyer ou bien on se sert tout simplement d'un serveur de clés. Mais ceux-ci ne garantissent rien sur la clé. N'importe qui peut créer une clé marquée flotus@whitehouse.gov et la mettre sur les serveurs de clé, même si cette clé n'a rien à voir avec la Maison-Blanche. [...] Que propose ce RFC ? De mettre les clés dans le DNS (nouveau type d'enregistrement OPENPGPKEY), dans le domaine de la partie droite de l'adresse de courrier, sécurisée par DNSSEC. En gros, il s'agit de faire pour le courrier et PGP ce que fait déjà DANE (RFC 6698) pour le Web/TLS.

Les serveurs de clés utilisent le protocole HKP (jamais décrit dans un RFC). Ils fournissent un service très utile en permettant de chercher une clé, par son identificateur, ou par l'adresse de courrier associé. [...]

Ces serveurs n'offrent aucune garantie : n'importe qui peut y publier une clé, avec n'importe quelle adresse et certaines clés sont clairement mensongères. L'usage normal est de récupérer la clé et ses signatures, puis de vérifier les signatures. Si elles sont faites par des gens qu'on a validés (directement, ou bien transitivement, jusqu'à une certaine profondeur), on estime la clé correcte (c'est ce qu'on nomme le web of trust). Autrement, la clé ne vaut rien. En outre, le seul système de révocation est de signer une révocation avec sa clé privée : si on l'a perdue, on ne pourra jamais retirer la clé des serveurs de clé. Pour ces deux raisons (fausses clés, et clés devenues inutilisables), il est donc difficile d'utiliser automatiquement, depuis un MUA ou un MTA, ces serveurs.

Mouiiii… en pratique la toile de confiance est plutôt décriée car elle rend vulnérable aux vérifications effectuées par les relations en commun : comment ces personnes ont-elles signé les clés ? Selon quels critères ? Peut-on avoir confiance en leur processus ? La méthode préférée reste la signature lors d'une rencontre AFK ou lors d'une signing party.

La solution proposée dans ce RFC est, comme souvent aujourd'hui, d'utiliser le DNS, qui a montré sa fiabilité et son ubiquité. Tout le monde peut faire des requêtes DNS, même coincé derrière un pare-feu, et tout le monde peut les valider, grâce à DNSSEC (RFC 4035).

[...]

La solution de ce RFC rend envisageable de récupérer et de vérifier automatiquement une clé avant l'envoi d'un message. Mais le RFC note bien qu'elle ne remplace pas complètement le web of trust, qui reste nécessaire si on veut une vérification sérieuse.

La section 2 de notre RFC décrit le format du nouveau type d'enregistrement DNS. Chaque enregistrement contient une et une seule clé. Si un utilisateur a plusieurs clés, il doit créer plusieurs enregistrements. Le type est 61 (et enregistré à l'IANA depuis août 2014). La partie droite de l'enregistrement (les données) contient la clé et au moins un ID et une auto-signature. Les clés PGP complètes, avec des tas de signatures, peuvent être grosses, trop pour le DNS ; le RFC recommande de ne publier que des clés minimales (pas trop de signatures, par exemple, et évidemment pas les photos qu'on peut inclure dans un attribut de la clé, cf. RFC 4880, section 5.12.1). [...] gpg --export --export-options export-minimal,no-export-attributes

Le format utilisé est celui du RFC 4880, section 11.1. C'est donc du binaire qui circule sur le réseau (rappelez-vous bien que, dans le DNS, le format de présentation, celui des fichiers de zone, et de la sortie de dig, n'a rien à voir avec le format binaire utilisé sur le réseau.) [...]

Et la partie gauche de l'enregistrement DNS ? Quel est le nom de domaine utilisé ? La section 3 du RFC fixe les règles :

• Le domaine de l'adresse de courrier (partie droite de l'adresse de courrier) est celui où on met les enregistrements DNS OPENPGPKEY. La clé pour l'adresse stephane+chose@trucmachin.example sera donc dans la zone trucmachin.example.
  
  
• Le nom de domaine sera la concaténation d'un condensat de la partie gauche de l'adresse de courrier (stephane+chose, dans l'exemple ci-dessus), et du composant _openpgpkey, avec le domaine de l'adresse de courrier (trucmachin.example dans l'exemple ci-dessus). Le condensat est tronqué à 28 octets. (Le nom de domaine n'est pas utilisé dans le condensat, pour faciliter la vie des opérateurs qui proposent la même adresse dans différents domaines.)
  
  
• En fait, la règle est plus compliquée en raison des équivalences entre certains caractères (voir les exemples plus loin). Une correspondance est donc faite pour certains caractères. (Ce fut l'un des points les plus discutés dans le groupe de travail à l'IETF.)
  
  
• Par exemple, les guillemets (oui, "jipoune le meilleur"@example.com est une adresse de courrier légale) sont retirés.
  
  
• La condensation de la partie gauche de l'adresse de courrier est faite en SHA-256 (RFC 5754). Cela permet une protection limitée (cf. section 7.4) de la vie privée : même si un méchant met la main sur tout le fichier de zone, il ne trouvera pas facilement toutes les adresses (qui sont des données personnelles). Mais le but principal de cette condensation est de résoudre le problème de certains caractères qui sont permis dans la partie locale d'une adresse de courrier, mais qui posent des problèmes dans le DNS.

YOLO ! \o/

[...]

Une des difficultés pour trouver le bon nom de domaine est que les applications doivent traiter la partie gauche des adresses de courrier comme opaque (pas le droit d'analyser sa structure) et qu'elles ne connaissent pas les règles de canonicalisation qu'appliquera le domaine de destination, comme d'ignorer la casse de la partie locale (ce qui est souvent fait, mais pas toujours). Par exemple, Gmail ignore les points dans les adresses (donc foobar@gmail.com et foo.bar@gmail.com arrivent dans la même boîte aux lettres). L'émetteur qui ne connait pas cette règle va chercher la clé dans un domaine qui ne sera pas le bon. Idem avec les sous-adresses utilisées par certains domaines (en général avec le séparateur plus, comme stephane+blog, stephane+ietf, etc). Le RFC rappelle que l'émetteur ne peut pas se permettre de deviner ces règles locales, et qu'elles peuvent changer à tout moment. C'est au destinataire de se débrouiller, en publiant la clé à plusieurs noms, et en faisant attention aux variantes qu'il publie.

[...]

Autre problème de sécurité, cette fois lié à la vie privée : les requêtes DNS révèlent avec qui on veut communiquer de manière sécurisée par courrier (RFC 7626). Le fait que le nom de domaine utilisé soit un condensat de la partie locale de l'adresse de courrier limite un peu les risques, mais pas suffisamment (si on soupçonne qu'Alice écrit à bob@example.com mais qu'on n'en est pas sûr, il suffit de construire le nom où se trouve l'enregistrement OPENPGPKEY et de vérifier que ce nom est demandé, cf. section 7.4). C'est d'autant plus grave que les clients DNS actuels envoient en général le nom de domaine complet à tous les serveurs, même ceux qui n'en ont pas besoin. La minimisation de la requête (RFC 7816) limite ce problème. Le chiffrement des requêtes DNS (RFC 7858) peut faire le reste. Le cache du DNS limite un peu les risques et il est donc essentiel de ne pas faire une requête DNS externe à chaque fois qu'on envoie un message PGP à quelqu'un, cela ferait fuiter bien trop d'informations (section 7.5).

Pour limiter les risques qu'un attaquant récolte toutes les adresses de courrier du domaine, le RFC recommande de signer la zone en utilisant NSEC3 (RFC 5155).

[...]

Où en sont les mises en œuvre de ce RFC ? GnuPG contient le code pour gèrer ces clés dans le DNS depuis la version 2.1.9. Même chose pour openpgp-milter. L'outil hash-slinger permet quant à lui de générer et de vérifier des enregistrements OPENPGPKEY .