jcs a écrit 1188 commentaires

Je confirme le sérieux de la formation de Enix (ce sont également mes anciens collègues)

Je comprends bien ton point de vue mais il faut aussi se dire que ce type d'événement permet d'attirer des personnes qui n'auraient pas participé si le stage avait été mixe ; les préjugés et les phénomènes d'autocensure ou du syndrome de l'imposteur qui ont tendance repousser les jeunes femmes existent bel et bien et sont bien connus.

En outre, en ouvrant ce stage aux lycéennes et collégiennes, je pense qu'on a une plus grande chance de dépasser ces écueils et on augmente la probabilité de retrouver les participantes dans les filières informatiques dans quelques années.

Quand j'ai commencé à lire DLFP fin 1999, chez moi c'était encore modem US Robotics à 56k et abonnement wanadoo :-) Pour l'ADSL il fallait être early adopter.

En effet, soyons précis :-) C'était un 6x86 "compatible Pentium".

J'étais abonné à PCTEAM à l'époque et ça a été ma découverte de Linux et ma première installation un Pentium Cyrix tout neuf \o/.

Oui, le processeur principal était un 68000 mais il y avait aussi un Z80 dans la mégadrive. Il servait de co-processeur dédié au son si ma mémoire est bonne.

Ne voyant pas le Motorola 6809 du TO7/70 de mon enfance j'ai retenu le 680xx. Non pas pour l'Amiga ou l'Atari, qui devait pourtant être des machines du feu de dieu même si à l'époque j'étais trop jeune pour m'en rendre compte, mais bien pour la Sega Mégadrive !

Oui je conseille aussi de vider la liste des CA et ne pas faire confiance aux CA installés dans les navigateurs, qui ne sont souvent absolument pas vérifiés et donnent des certificats à n'importe qui pour n'importe quel domaine. Cf. encore récemment la débâcle de CNNIC, que Mozilla a décidé de virer de Firefox… 5 ans après que le monde entier ait commencé à leur dire que CNNIC n'était pas un CA fiable. Purée.

Faire une telle généralisation c'est aller un peu vite en besogne. Pour modérer un peu je voudrais tout de même préciser que les AC des navigateurs doivent bien être vérifiées. Une certification (et donc un audit) ETSI, CA/Browser Forum ou ISO 21188 est une condition sine qua non de tous les programmes d'inclusion d'AC. Et la plupart des AC font bien leur travail. Mais comme dans tout processus d'audit il peut y avoir des erreurs, des manquements, des attaques et même de la triche, comme par exemple lors des affaires Comodo, Diginotar, ANSSI ou CNNCI. Dans ce cas les différents acteurs (navigateurs, auditeurs, organismes de certifications…) cherchent toujours à améliorer les processus d'inclusion et de contrôle et d'opérations des AC. En outre les initiatives telles que HSTS, Public Key Pinning, Certificate transparency ou encore DANE tentent de réduire l'impact en cas d'émission frauduleuse de certificat.

Merci pour la précision. En effet, en lisant la DPC un peu plus en détails, il est (plus ou moins) clair que les clés et les certificats sont générés et injectés avant l'activation initiale de la carte. Par contre il n'y a pas grand chose sur les conditions de générations des clés et les demandes de certificats (personnel de confiance, dual control, sécurisation des locaux…). Mais il y a peut-être d'autres documents disponibles.

Pour bien comprendre ce qui se passe et donc pouvoir décider si on a confiance ou pas, il peut être utile (et même indispensable à mon avis) de lire la politique de certification de cette Autorité de certification. En fait plus précisément c'est la "Déclaration des pratiques de certification" qui nous intéresse.

Pour ceux qui voudrait tout lire, la version en français est ici : http://repository.eid.belgium.be/downloads/citizen/fr/CPS_CitizenCA.pdf

Et justement dans la partie 4.4 (Acceptation du certificat) il est précisé :

Une fois fabriquée, la carte d’identité électronique possède un statut ‘non activé’. La LRA active la
carte d’identité électronique en présence du citoyen en mettant à jour son statut dans la base de
données d’identité du RA. Le citoyen et la LRA ont tous deux besoin des données d'activation de
la carte qui doit être fournie par l'initialisateur de cartes par un moyen sécurisé. La carte ne peut
être activée qu'au moyen des données d'activation combinées de la LRA et du citoyen.

Donc il semble les clés ne sont générées que sous le contrôle du citoyen. Mais je me demande comment ça se passe exactement en pratique.

A quoi ça sert lfs de nos jours, une fois que l'on a dépassé le cadre pédagogique du configure copier-coller && make && make install, sérieusement ?

Je pense que ça dépend de la façon dont tu l'appréhendes. Si c'est juste pour faire des copier/coller l'intérêt est limité.

Mais moi, par exemple, dans beaucoup de domaines, j'ai besoin de "manipuler" pour aller au fond des choses : je pourrai lire tous les livres possibles sur le fonctionnement du système, j'aurai également besoin d'en monter ou bricoler un pour bien comprendre comment il marche. Il y a quelques années, à l'époque où les distributions Linux sources (Gentoo, Source Mage…) étaient à la mode j'avais monté un petit système embarqué sur une clé USB ; ça m'avais permis de comprendre pas mal de chose sur le fonctionnement du système : initramfs, udev, /proc & /sys… Et j'ai pu confirmer ce que dis l'adage : le diable se cache bien dans les détails.

Et je pense que c'est clairement sur ce point que LFS est utile : c'est un bon support d'apprentissage pour celui qui veut un peu mieux comprendre le système autour du kernel mais qui ne sait pas comment commencer.

Pour information il existe le projet bridj qui fait un peu la même chose que JNA tout en corrigeant ou améliorant certains points :
- plus efficace que JNA
- API plus "propre" (annotations, generics)
- support pour C++, objective-C
- etc

Après, effectivement, je ne connais pas d'exemple, mais je ne me suis jamais intéressé au problème non plus.

Quelques exemples utilisant JNI (le plus souvent il s'agit de wrapper pour s'interfacer avec des DLL) :
- accès aux cartes à puce compatibles avec le standard ISO 7816
- accès à la CryptoAPI sous Windows
- cryptographie sur les courbes elliptiques (Java 7)
- accès à la configuration système (par exemple pour obtenir la config du proxy)

Par exemple, pour SHA-3, ça fait des années qu'il y a un concours pour vérifier qu'il n'y a pas de failles dans l'algorithme, et ça avait été pareil pour MD5, SHA-1, SHA-2... Alors qu'aujourd'hui on a trouvé des failles.

Petites précisions : à ma connaissance il n'y a pas eu de concours pour MD5, SHA-1 ou la famille SHA-2. Pour SHA-1 et les SHA-2, la NSA les a sortis de son grand chapeau (ainsi qu'un algo nommé SHA-0 rapidement retiré). MD5 est une création de Ron Rivest et n'est pas un standard au sens du NIST. Bien sûr depuis leurs publications, ces algos ont été étudiés et régulièrement attaqués.

Aujourd'hui il est facile de générer des collisions pour MD5 et il existe des attaques théoriques sur SHA-1 dont l'usage est déconseillé. Les algos de la famille SHA-2 sont pour le moment encore considérés comme sûrs. le nouveau standard SHA-3 est attendu pour la fin de l'année.

Savez-vous s'il existe un tel système de tiers de confiance reconnu par l'État permettant d'authentifier un émetteur de courriel (et qui ferait double emploi avec GPG) ?

Oui ça existe mais pour cela il te faut signer des courriels et utiliser un certificat qualifié, c'est à dire un certificat émis une autorité de certification qualifiée (c'est à dire ayant été auditée), remis en main propre, normalement sur présentation d'une pièce d'identité et dont la clé se trouve sur un dispositif sécurisé de création de signature (type carte à puce... on parle souvent de SSCD pour Secure Siganture Creation Device). Les signatures réalisées avec un tel certificat sont présumées fiables.

Une liste des prestataires pouvant émettre ces certificats qualifiés (La Trust-service Status List ou TSL) est maintenue dans chaque pays de l'Union Européenne. La liste française est ici : http://references.modernisation.gouv.fr/fr-0

la signature étant une application particulière du chiffrement

Dans le cas général, non. À la limite dans le cas particulier de RSA et encore avec beaucoup de réserves. RSA est d'abord est une primitive cryptographique. Il existe des fonctions "signature RSA" et "chiffrement RSA" qui utilisent la même primitive mais :

• La primitive est utilisée de façons différentes dans les deux fonctions : on produit une signature en utilisant sa clé privée, alors qu'on chiffre avec la clé publique du destinataire du message, le padding est différent...
• Les services rendus sont différents : confidentialité dans le cas du chiffrement, authenticité et intégrité dans le cas de la signature.

Le standard PCSK#1 décrit comment on peut utiliser RSA pour chiffrer ou signer.

Toutes les attaques ne se valent pas, toutes ne sont pas applicables à tous les "mode opératoires". Par exemple pour MD5 je peux te sortir une collision en une dizaine de seconde sur mon PC, par contre trouver un autre fichier qui a une empreinte données, c'est beaucoup plus difficile. Si en plus je veux pirater un repository debian et que ce fichier doit être un tarball valide, là c'est carrément mission impossible.

Dans le même esprit, la spécification TLS utilise MD5 et SHA-1 ensemble, mais pour le moment il n'a pas été montré que les attaques sur ces deux algorithmes ont un impact sur la sécurité de TLS. Des attaques type Comodo (sur les PKI) sont à mon avis bien plus facile à monter et donc plus probables.

Bon sang je ne retrouve plus les liens!

En voilà déjà un, sur la mise à jour de la Mozilla CA Certificate Policy :
http://groups.google.com/group/mozilla.dev.security.policy/browse_frm/thread/426b771c7236fe27/6edabc01f8611862?tvc=1#6edabc01f8611862

Malheureusement je crains que ton schéma ne fasse pas la différence entre signature et chiffrement.

il faut s'y connaitre en maths, se former à des libs quoi qu'on en disent assez compliquées comme OpenGL

Il y a 10-15 ans probablement, mais aujourd'hui il existe pas mal de bibliothèques dédiées, comme Ogre, UnrealEngine ou Havok, qui proposent des modules de toutes sortes pour aider au développement des jeux : import de scènes 3D depuis les modeleurs, animation, effets spéciaux, gestion de la physique... Je ne crois pas les développeurs sur ces jeux voient beaucoup de multiplications de matrices dans leur code.

Ensuite une utilisation efficace de ces libs doit demander un peu d'effort, mais à mon avis guère plus que dans n'importe quelle bibliothèque utilisée dans un domaine un peu spécialisé.

J'ironise, mais la norme dit seulement qu'il faut vérifier la CRL avant de faire une opération sur les certificats. Mais comment gérer la CRL, ou aller la chercher, qu'en faire, etc.. pas un mot!

Où chercher la CRL : Commencer par l'extension CRLDistributionPoints dans le certificat X.509, elle est presque toujours présente ; on y trouve des URL où la CRL peut être téléchargée. La CRL c'est une des parties les plus critiques d'une PKI, et c'est le service à remettre en route le plus rapidement possible en cas de sinistre de l'infrastructure. Il est clairement dans l'intérêt de la CA d'indiquer où la trouver :)

Comment utiliser la CRL : l'algorithme de validation X.509 est décrit en détail dans la RFC 5280 (section 6). Le traitement des CRL y est également précisé. Par contre on ne peut pas nier que c'est un algorithme complexe et il faut bien comprendre X509 qui l'implémenter correctement. En outre cette implémentation doit être assez souple pour s’accommoder de l'existant (certificats/CRL/réponses OCSP émis par des PKI qui respectent mal les normes et standards, on plus souvent qui ont foiré leur configuration).

Pas tout à fait, même s'il est vrai que certains audits ne se font que sur base documentaire.

Cependant la plupart du temps les auditeurs viennent sur site s'assurer que les procédures mises en place sont bien appliquées : interview des personnes impliquées, vérification d'éléments de preuves (monsieur Machin est responsable de la salle X, montrez moi le document où il s'y engage... Montrez moi le coffre où sont stockés les clés de séquestre, montrez-moi que vous seul y avez accès...)

Ensuite les certifications obtenues ont une validité limitée dans le temps. Régulièrement (tous les ans par exemple) l'auditeur revient. Il vérifie également que les points de non-conformités qu'il a pu relever lors du précédent audit on été corrigés.

Bien sûr, entre deux audits tu peux faire n'importe quoi ; Mais si tu as fait les efforts pour mettre en place une politique de sécurité, c'est souvent beaucoup plus simple de la respecter (et d'expérience j'en sais quelque chose). D'autant plus que l'auditeur n'est pas con, il flaire souvent les procédures qui ne peuvent être appliquées en pratique.

C'est d'ailleurs probablement une des plus grosses difficultés de cet exercice : écrire des procédures qui permettent d'atteindre le niveau de sécurité désiré sans les rendre ni trop contraignantes (ce qui inciterait les acteurs de la politique à les contourner, ce qui serait contre-productif), ni trop compliquées (car il ne faut pas oublier de former les gens, sinon ça ne sert à rien de mettre en place quoi que ce soit)

C'est pour ça que des zingénieurs ont inventés OCSP, mais que pas grand monde semble utiliser et c'est bien dommage :(

Ça commence à changer, on rencontre de plus en plus de déclaration de répondeurs OCSP dans les certificats (même les certificats SSL qui ne sont pas chers). Mais je me rends compte que Firefox par exemple considère valide par défaut un certificat dont le statut de révocation est inconnu (ou quand il n'arrive pas à se connecter au répondeur OCSP). Et ça c'est un comportement très discutable.

Et le jour ou tous les navigateurs du monde iront chercher toutes les x minutes les CRL, là c'est verisign qui va pleurer.

Les CRLs sont valides pendant un certain temps (entre 1 jour et 1 semaine d'habitude), donc on ne les télécharge pas toutes les x minutes, mais plutôt tous les jours/semaines et elles sont mises en cache. Les proxies ça peut aussi aider. Après c'est sûr que 7 Mo tous les jours à travers un modem 56K, c'est rude :)

Malheureusement pour les entreprises de certification SSL, ça serait trop contraignant d'avoir une vraie politique de sécurité.

Je ne peux pas laisse dire ça. Les autorités de certification ont de vraies politiques : Politiques de Certification (CP, ici par exemple) et Pratiques des Politiques de Certifications (DPC), ce sont des documents nécessaires à l'obtention de certifications et/ou qualifications (par exemple type référentiel général de sécurité). Ce sont les étapes obligées pour avoir sa CA dans les autorités racines des browsers.

La vraie question c'est n'y a-t-il pas trop d'autorités racines dans les browsers web ?

Cela dit, je ne nie pas qu'il semble bien y avoir quelques problème chez Comodo ; même si finalement les certificats frauduleusement obtenus ont été révoqués rapidement.

ma femme est actuellement grosse

Je pensais que ça ne se disait que pour les animaux et plus pour les humains.