La page changera de place demain pour devenir la page finale. Les descriptions des sous-ensembles ne sont pas finales donc ne pas traduire pour l'instant.
Je sais pas d"où tu sors les problèmes de sécurité. Il est au contraire très facile de gérer la sécurité programme par programme, ou groupe de programme par groupe de programme avec une architecture Gobolinux.
Tu tous-entends aussi que tout serait simple sous une distribution normale à condition d'utiliser le gestionnaire de paquet. Dans la pratique, entre /bin, /usr/bin, /usr/lib, /usr/local/lib, /opt, on est loin d'avoir un système propre.
Mon expérience est que le gestionnaire de paquet se casse régulièrement les dents. Et si tu as le malheur de vouloir gérer un ou deux programme toi-même, ça devient vite ingérable.
Un aspect intéressant, c'est que c'est une des distribution les plus LFS compliant. Comme la partie LFS est entièrement "émulée", ils ne s'embêtent pas avec tout l'historique qu'ont les autres distributions et peuvent être 100% compatible :-)
Voilà. C'est la logique de stow poussée au niveau système.
Je mets mon programme/ma lib dans un répertoire et j'ajoute un lien / une entrée dans un index / un fichier .desktop dans une location centrale pour donner les infos.
A noter que c'est une logique utilisée dans d'autres situations. C'est comme ça que les plugins eclipse se listent auprès du système, que les .desktop sont gérés, etc.
Ils ont le code source mais il s'en servent uniquement pour faire un audit de code, vérifier qu'on n'a pas fait de connerie. Si on fait une grosse connerie, ils se jetteront dedans mais en général, ce n'est pas le cas :-)
Pour les attaques, le code source ne leur sert à rien tellement ils arrivent à récupérer d'infos par ailleurs. Ils connaissent la spécification, donc ils savent ce qu'ils cherchent. Et ils sont capables de dire à peu près ce qu'on fait à chaque instruction assembleur : manipulation d'un registre, chargement d'une donnée dans la RAM, dans l'EEPROM, dans le coprocesseur crypto, copie de buffer en RAM, etc. Quand tu sais tout ça, le code source ne sert à rien.
4 semaines, c'est peut-être court pour toi, mais quand tu payes un labo à la journée, je peux te dire que ca fait long :-)
Vu leur niveau d'expertise, on peut estimer qu'en quatre semaines, ils font un travail qui prendrait plusieurs mois à quelqu'un de moins expérimenté.
Des lib partagées entre plusieurs appli, il y en a des centaines, cf "ls /lib /usr/lib" sur ton système.
Elles sont installées dans leur propre repertoire et des liens symboliques sont mis dans /usr/lib vers lesdites librairies.
Ca permet par exemple en un tour de main de passer de la version X à la version Y : juste une mise a jour des liens à faire dans /usr/lib, je suis sur qu'il y a le petit programme qu'il faut pour faire ca bien.
C'est un peu la philosophie de je-sais-plus-quel-outil qui installait un grand jeu de lien symbolique.
Pour ma part, je trouve ca super propre et intuitif : un programme est isolé dans son repertoire, donc on n'a pas la question de savoir si il a installé des saloperies ailleurs.
Le mélange se fait uniquement au niveau système, via le jeu de lien, et pas au niveau du programme lui-même.
> C'est pour relativiser ceux qui pense que la carte à puce est inviolable...
Je pense que c'est la meilleure approximation de l'inviolable qu'on peut avoir. Pour notre dernier OS cartes, après 4 semaines d'attaque chez un labo qui est expert dans le domaine et dispose du matériel adéquat, qui a accès à toutes les specs techniques et le code source, la carte est ressortie indemne. Ca veut dire qu'avec équipement illimité, connaissances "illimitées" et temps limité à quatre semaines, des experts n'ont pas réussi à craquer cette carte. Et notre carte est en dessous (tout au moins en théorie) du niveau de sécurité exigé pour les cartes bancaires françaises.
Donc je pense vraiment que "inviolable", c'est quand même le mot qui décrit le mieux la sécurité de ces cartes à puces.
<< tous les efforts d'innovation sont dirigés vers les versions pour KDE4... qui elles mêmes ne seront pas prêtes avant KDE 4.1 pour la plupart >>.
Il est pas exclue que des applications migrent à KDE 4 et soient prêt avant la sorite de KDE 4.1 . Koffice a par exemple un cycle de sortie de version différent de celui de KDE. Après, ce serait mentir que de dire que ce sera le cas pour la majorité des applications. Il y a de fortes chances en effet qu'il faille encore patienter. Un changement aussi majeur, ça prend du temps à être réaliser.
Les attaques au laser appelées communément "attaques flash" (parce qu'un bricoleur du dimanche peut en réaliser une avec un flash d'appareil photo) consistent à changer un bit, soit en RAM, soit dans un registre, soit à faire avancer le pointeur d'instruction de plusieurs pas sans que le processeur execute lesdites instructions.
Les conséquences possibles :
- lire à une mauvaise adresse en EEPROM et retourner des données secrètes au lieu de données banales
- sauter le "if (code is incorrect) exit" pour sauter les tests de vérification
- faire faire des calculs erronés au DES et en déduire la clé
- faire du bit flipping sur les clé DES et en déduire des choses
Les contre-mesures sont assez simples : puisque tu ne peux pas faire confiance à ta RAM ou au déroulement de ton programme à un instant t, il suffit d'ajouter de la redondance et de vérifier qu'elle est toujours là :
- les valeurs en EEPROM sont lues, relues et parfois encore relues. Les adresses sources et destination sont stockées à deux endroits différents et comparées en permanence.
- les valeurs écrites en EEPROM sont écrites puis relues puis encore relues. Idem, double copie des adresses.
- les copies de RAM à RAM sont vérifiées avant, pendant la boucle puis après avec encore une double-vérification.
- les chemins d'exécution du code comportent des sémaphores qu'on incrémente à côté de chaque instruction sensible et qu'on vérifie régulièrement
Il y a aussi des petites protections matérielles, comme une grille au dessus de la puce pour détecter si la puce est mise à nue. Mais ça ne fait perdre que quelques heures à l'attaquant, le temps qu'il reroute les courant ailleurs et qu'il gratte la grille.
La sécurité vient donc de la combinaison des protections physiques et logicielles.
Etant donné un équipement illimité et un temps illimité, c'est toujours le craqueur qui va gagner. Quand une carte passe trois semaines dans un labo, ils sont capables de dire exactement quelle instruction est executée à quel moment, synchroniser une attaque laser dessus et voir si le programme pète.
Avec un peu plus de temps, ils peuvent carrément modifier le silicium et rerouter des chemins électroniques, donc concrètement, reprogrammer le hardware de la puce. Tiens, si je mettait un random nul ? Face à ça, il y a bien sur des protections logicielles, mais étant donné qu'ils comprennent tout ce qui est fait au niveau logiciel, ils peuvent prendre le temps de les contourner.
Au final, une carte obtient une note de résistance, qui correspond à la quantité de moyen qu'il faut pour la craquer, et à la disponibilité de ces moyens pour le grand public.
C'est marrant cette idée que la 3D va améliorer l'ergonomie de l'interface utilisateur. Ca sort d'où ?
Vous pensez vraiment que ça va être plus simple parce que c'est en 3D. Les gens ont déjà du mal avec la représentations d'un "bureau" en deux dimensions et la notion de "fenêtre".
Pour ma part, je pense plutôt que la 3D va compliquer encore plus l'interaction. Il y a plein de gens qui ne voient pas du tout en 3D, sont incapables de se projeter en relief dans une surface plane. Il y a aussi la fatigue oculaire engendrée par ce type de visualisation.
Autre truc sympatique, le guichet disparait et les deux automates de distribution des billets qui ne marchent pas, et la gare voisine qui est fermée.
Je me souviens d'un dimanche 30 où j'ai voulu acheter ma carte orange de mois suivant. Environ une quarantaine de personne à faire la queue devant les deux pauvres automates. L'un des automates ne gérait pas les passes navigo. Ces automates plantaient souvent. Il a planté juste devant moi donc la dame SNCF l'a rebooté devant mes yeux. Un bon vieux windows. Il a du mettre environ 7 minutes entre le moment du reboot et le moment où il fut prêt à me distribuer mon billet. Sachant qu'elle le rebootait environ tous les 3 clients, ça fait un super débit !
Et encore, j'habite à Enghien, une gare plutôt bien pourvue vu le fric que possède la municipalité. J'ose pas imaginer comment ça doit être dans des villes un peu moins favorisées.
La politique de la SNCF, c'est donc de virer les guichetiers mais surtout pas de rajouter des bornes automatiques. Ou bien l'idée d'ajouter les veilles de 1er et le 1er lui-même une personne exceptionnelle pour faire face à la charge supplémentaire prévisible, annoncée et connue, ce serait trop leur demander.
Il reste encore 6 jours pour laisser le temps aux packageurs de préparer des paquets et éventuellement pour corriger un bug bloquant de dernière minute.
Concernant les paquets debian, il faut demander à Debian si ça arrivera et où.
Oui, il est tout à fait possible de lancer des applications KDE3 dans un environnement KDE4 et vice-versa. A noter que certaines applications KDE3 matures ne sont pas dispo dans KDE4, c'est donc non seulement possible, mais aussi reconnu comme une nécessité.
Les applications KDE4 seront disponible sous windows plus probablement aux alentours de KDE 4.1 . Le portage sous windows est long et pénible, il faut lui laisser le temps de se faire.
Je doute qu'il soit possible de supprimer le window manager, bureau, panneau de contrôle et lanceur de windows en les remplaçant par KDE4. D'une part, c'est loin d'être simple à faire (même si c'est possible), d'autre part, seules les applications sont portées sous windows. Typiquement, KDM n'est pas porté.
Philips / NXP a senti le vent venir depuis plusieurs années. C'est signe d'une boite mature, ils ont beau avoir un produit référence, ils préparent quand même la suite.
La Mifare DESFire n'a plus de Mifare que le nom commercial. C'est en fait un OS qui supporte du triple DES classique et un protocole de communication standardisé ISO. Elle contient aussi la compatibilité Mifare, donc c'est une carte qui permet de faire la transition vers un peu plus d'interopérabilité et un peu moins de verrouillage client. Sauf que en fait, la DESFire ne supporte presqu'aucune des commandes ISO de carte à puce, uniquement des commandes propriétaires disponibles après avoir signé un gros NDA avec NXP.
On peut donc dire que la DESFire permet de s'affranchir du gouffre de sécurité de la Mifare classique, mais en aucun cas n'ouvre vers plus d'interopérabilité ou sort du verrouillage client.
Et la carte qui est déployée en millards d'exemplaires dans le monde, c'est pas la DESFire, c'est de la mifare classique.
Sur le jeu de commande de la DESFire, une petite anecdote qui donne une idée du pouvoir de lobbying de NXP : le département de la défense américain a sorti il y a deux-trois ans une spécification pour toutes les cartes des employés des administrations américaines, suite à la course sécuritaire post-11 septembre. Les administrations ont obligation à partir d'une certaine date que tous les fonctionnaires ou contractuels bossant pour le gouvernement aient une telle carte. Autant dire, beaucoup de monde, un marché bien juteux pour les fabricants de cartes. Ces naïfs d'informaticiens avaient spécifié une carte supportant uniquement des commandes ISO, donc la DESFire était exclu, ne supportant que des commandes propriétaires. Quelques mois plus tard, le gouvernement américain a révisé sa spécification en diminuant le nombre de commande ISO à supporter à 3. Dans le même temps la spécification de la DESFire a été modifiée pour supporter 3 commandes ISO (les seules !). Intéressant hein ?
Ca donne une idée de l'ouverture de ce genre de marché. Autant dire qu'il faut plus qu'un produit répondant aux spécifications officielles pour rentrer dans ce type business.
> A quand une carte où on peut mettre plusieurs banques dessus et choisir son code?
A priori jamais.
D'un point de vue commercial, ça n'a aucun sens. C'est un peu comme si tu demandais une carte de fidélité qui marche à la fois chez Leclerc et chez Carrefour.
Le problème de fond des langages de haut niveau est qu'ils sont difficiles à appréhender par le commun des mortels. Aussi bien soient-ils, ils demandent de penser différemment. Au final, un langage impératif est quelque chose de vraiment facile à assimiler. Donc bien que ce soit une source d'erreurs, comme c'est _vraiment_ facile à comprendre, c'est ce que les gens apprennent.
Les gens qui se posent un peu la questions d'approches différentes de la programmation, notamment avec des langages utilisant des concepts différents sont en général ceux qui déjà dans leur pratique de la programmation sont très rigoureux.
Quand on propose à un étudiant qui vient de faire trois années pour apprendre péniblement le java de faire du lisp, ça lui sort par les yeux.
Pour reprendre ton exemple du sous-marin, tu peux dire que le sous-marin a trois états et que décider de plonger, c'est faire un changement d'état global qui entraine des mises à jour automatiques en cascade, pour le commun des mortels, c'est plus simple de dire qu'on donne l'ordre au sous-marin de plonger et qu'il faut faire des trucs pour ça. La description impérative est tout simplement beaucoup plus simple à appréhender, même si elle est beaucoup plus sujette à une erreur lors de la mise en oeuvre.
Les problèmes détéctés par Humpich correspondait à des vieilles vielles versions de la norme de paiement, qui était moins sécurisée ( B0' il me semble). La nouvelle norme, c'est EMV et c'est super carré. Sur certains lecteurs de paiement, c'est affiché. Si il te dit CB EMV, c'est tout bon. Si il te dit B0' c'est moins bon. J'ai noté que ma carte bleue est passée en EMV lors de mon renouvellement il y a un an.
Comme les terminaux restent déployés jusqu'à 10 ou 15 ans sans être changés, beaucoup de cartes fonctionnent soit avec la nouvelle norme méga-sécurisée, soit avec l'ancienne beaucoup moins sécurisée. Un choix est fait au moment du paiement. Tant que EMV n'est pas déployé partout, le système comporte donc des failles facile à exploiter. Il suffit de dire au lecteur "je suis une vieille carte, soit gentil avec moi et n'utilise pas de sécurité" et il obéira gentiment.
C'est le problème de la sécurité théorique versus la mise en place pratique. Il est difficile de demander aux commerçants de jeter leur terminal à la poubelle tous les 5 ans, sachant qu'ils payent le terminal et qu'ils payent aussi pour les transactions.
Si je me souviens bien (mais je ne suis pas expert dans le marché du paiement français), le problème mis en avant par Humpich était que pour des automates hors-ligne, le système de vérification était léger et il l'avait cassé. C'est pas un gros exploit, ce qu'on fait les mecs que je cite est quand même déjà plus impressionnant : reverse engineering de circuit, c'est fun bien que ce soit quand même une pratique courante dans l'industrie.
Ce qu'a fait Serge Humpich n'est pas possible de façon généralisée avec des cartes EMV. Pour des cartes EMV, la vérification hors-ligne se fait soit avec un certificat RSA, soit ne se fait pas mais il y a un montant maximum hors-ligne qui peut être dépensé. Si c'est en ligne, la vérification est systématique. J'imagine que Humpich arriverait à se faire de la presse en montrant que dans certains cas, il n'y a pas de vérification hors ligne des transactions. Ca impressionnerait toujours les journalistes, bien que cela soit une information publique.
Ce qui a changé depuis Humpich, outre le passage bien amorçé à l'EMV, c'est que c'est beaucoup beaucoup plus facile de faire des terminaux en ligne maintenant. Par exemple, pas mal de terminaux sont GPRS aujourd'hui ( == utilisent le réseau GSM). Ca laisse beaucoup moins de marge aux frauderus.
Je tiens à ajouter que Humpich n'a pas du tout remis en questions la sécurité de la carte. Une carte à puce correctement implémentée (et la grande majorité le sont) est une coffre fort inviolable. Personne n'est en mesure d'aller lire votre PIN dans votre carte ou de trouver la clé privée des certificats de la carte. Par contre si le code PIN est écrit sur un autocollant au dos de la carte, le fait que la carte soit un coffre fort ne change rien au fait qu'on pourra dépenser tous vos sous.
A chaque fois que tu passes un portique, l'heure et le nom du portique sont stockes sur la carte. Si ils verifient ton passe navigo, ils verront que la derniere entree est trop vieille par rapport à ton voyage actuel.
Cela dit, dans bien des cas, le passe navigo est juste regardé, pas vérifié.
Les autres algos qu'on trouve sur les cartes à puces sont soit du triple-DES (cartes pas trop cher), soit du RSA pour les cartes de compétition. Faut voir que dans l'industrie, on se base sur des standards qui tournent depuis longtemps. Ceux deux-là (DES et RSA) sont pas prêt de disparaître.
Pour les passeports, ils utilisent aussi de l'AES et de l'ECC mais ça reste une utilisation exceptionnelle. Poussée par les allemands et les français d'ailleurs.
Pour ta carte bleue, c'est du RSA par exemple.
Pour élaborer un peu plus sur la crypto, quand un nouvel algo est introduit, il ne suffit pas de l'implémenter pour qu'il apparaisse sur les cartes à puces. Il faut aussi :
- qu'il aille suffisamment vite
- qu'il ne consomme pas trop de courant
- qu'on puisse le sécuriser contre tout un tas d''attaques tordues dites "attaques par des canaux cachées" et attaques au laser
- que les fabricants de silicium l'intègre à leur offre
- que les clients le demande
- que tous les outils actuels de test qui fonctionnent allègrement avec du DES ou du RSA s'adaptent
- que les développeurs se forment
Bref, dans quelques années, si RSA et 3DES montrent vraiment leurs limites, on passera à autre chose.
Pour les réseau de revente à l'unité, c'est pas simple. Le mieux est de contacter une intégrateur comme ABC Smartcard ou ProActive qui peuvent probablement te faire ça. Il y a pas vraiment de place sur le marché pour la carte du bricoleur, donc c'est difficile à obtenir à l'unité. A partir de 10000 en revanche, je peux te donner plein d'adresses, dont ma boite.
Il y a des parties de Qt qui sont optimisées comme du difficilement imaginable. Avec des problématiques complexes.
Ca me parait pas choquant que ce code soit illisible. Souvent mon code optimisé devient illisible parce que certains raccourcis sont effectivement illisibles.
Je peux pas dire que un switch touffu résulte nécessairement de ce type d'optimisation mais ca semble quand même probable, surtout quand tu parles de dessin de widget noù la vitesse doit être la priorité.
Note qu'un gros switch s'optimise en général pas mal par le compilateur, en générant (horreur) des goto.
D'ailleurs, j'ai pas vu de goto dans Qt, preuve qu'ils codent proprement :-) Je suis même prêt à soutenir un troll qu'on code avec un goto peut être plus propre et plus lisible *dans certaines conditions* qu'un code sans goto (ou sans switch touffu puisqu'on y est).
Ca me fait penser à un userfriendly où le dialogue ressemblait à cela :
- nous demandons 5 années d'expérience avec Windows XP
- mais Windows XP n'est sorti que depuis 3 ans !
- dommage. Vous pourrez repostuler dans deux ans si vous voulez...
- bah, d'ici là vous demanderez 7 ans d'expérience avec Windows XP.
Dans les sources de la lib, j'ai jamais vu de gros immondices.
Par contre, niveau design des outils, je pense qu'ils peuvent mieux faire. Je m'explique. Quand Qt Designer est sorti, tout ceux qui ont voulu l'intégrer ont constate que l'architecture interne du bousin ne permettait pas une integration exterieure. Il a fallu attendre quelques années et une reecriture partielle pour que ça soit possible. même histoire avec qmake. Encore même histoire avec Qt/Help.
Je révere trolltech mais je suis quand même surpris que leurs outils ne soient plus pensés pour une intégration extérieure.
Espérons que QtHelp + QtDesigner + qmake leur aura fait comprendre cela.
[^] # Re: Début de news....
Posté par Philippe F (site web personnel) . En réponse au journal KDE4. Évalué à 2.
http://www.kde.org/announcements/visual-guide_4.0/index.php
La page changera de place demain pour devenir la page finale. Les descriptions des sous-ensembles ne sont pas finales donc ne pas traduire pour l'instant.
Tout ceci doit rester non publié pour l'instant.
[^] # Re: Fausse bonne idée
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Gobolinux 014. Évalué à 1.
Tu tous-entends aussi que tout serait simple sous une distribution normale à condition d'utiliser le gestionnaire de paquet. Dans la pratique, entre /bin, /usr/bin, /usr/lib, /usr/local/lib, /opt, on est loin d'avoir un système propre.
Mon expérience est que le gestionnaire de paquet se casse régulièrement les dents. Et si tu as le malheur de vouloir gérer un ou deux programme toi-même, ça devient vite ingérable.
[^] # Re: Plus de sens ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Gobolinux 014. Évalué à 4.
[^] # Re: Bibliothèques partagées ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Gobolinux 014. Évalué à 1.
Je mets mon programme/ma lib dans un répertoire et j'ajoute un lien / une entrée dans un index / un fichier .desktop dans une location centrale pour donner les infos.
A noter que c'est une logique utilisée dans d'autres situations. C'est comme ça que les plugins eclipse se listent auprès du système, que les .desktop sont gérés, etc.
[^] # Re: étonnant
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Gobolinux 014. Évalué à 1.
[^] # Re: FreeRunner et vitesse CPU
Posté par Philippe F (site web personnel) . En réponse à la dépêche LiPS 1.0, Bazaar 1.0 et OpenMoko Neo FreeRunner. Évalué à 0.
[^] # Re: DES?
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 2.
Pour les attaques, le code source ne leur sert à rien tellement ils arrivent à récupérer d'infos par ailleurs. Ils connaissent la spécification, donc ils savent ce qu'ils cherchent. Et ils sont capables de dire à peu près ce qu'on fait à chaque instruction assembleur : manipulation d'un registre, chargement d'une donnée dans la RAM, dans l'EEPROM, dans le coprocesseur crypto, copie de buffer en RAM, etc. Quand tu sais tout ça, le code source ne sert à rien.
4 semaines, c'est peut-être court pour toi, mais quand tu payes un labo à la journée, je peux te dire que ca fait long :-)
Vu leur niveau d'expertise, on peut estimer qu'en quatre semaines, ils font un travail qui prendrait plusieurs mois à quelqu'un de moins expérimenté.
[^] # Re: Bibliothèques partagées ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Sortie de Gobolinux 014. Évalué à 4.
Elles sont installées dans leur propre repertoire et des liens symboliques sont mis dans /usr/lib vers lesdites librairies.
Ca permet par exemple en un tour de main de passer de la version X à la version Y : juste une mise a jour des liens à faire dans /usr/lib, je suis sur qu'il y a le petit programme qu'il faut pour faire ca bien.
C'est un peu la philosophie de je-sais-plus-quel-outil qui installait un grand jeu de lien symbolique.
Pour ma part, je trouve ca super propre et intuitif : un programme est isolé dans son repertoire, donc on n'a pas la question de savoir si il a installé des saloperies ailleurs.
Le mélange se fait uniquement au niveau système, via le jeu de lien, et pas au niveau du programme lui-même.
[^] # Re: DES?
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 1.
Je pense que c'est la meilleure approximation de l'inviolable qu'on peut avoir. Pour notre dernier OS cartes, après 4 semaines d'attaque chez un labo qui est expert dans le domaine et dispose du matériel adéquat, qui a accès à toutes les specs techniques et le code source, la carte est ressortie indemne. Ca veut dire qu'avec équipement illimité, connaissances "illimitées" et temps limité à quatre semaines, des experts n'ont pas réussi à craquer cette carte. Et notre carte est en dessous (tout au moins en théorie) du niveau de sécurité exigé pour les cartes bancaires françaises.
Donc je pense vraiment que "inviolable", c'est quand même le mot qui décrit le mieux la sécurité de ces cartes à puces.
[^] # Re: Concrètement
Posté par Philippe F (site web personnel) . En réponse au journal KDE 4.0.0 is out \o/. Évalué à 1.
Il est pas exclue que des applications migrent à KDE 4 et soient prêt avant la sorite de KDE 4.1 . Koffice a par exemple un cycle de sortie de version différent de celui de KDE. Après, ce serait mentir que de dire que ce sera le cas pour la majorité des applications. Il y a de fortes chances en effet qu'il faille encore patienter. Un changement aussi majeur, ça prend du temps à être réaliser.
[^] # Re: DES?
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 1.
Les conséquences possibles :
- lire à une mauvaise adresse en EEPROM et retourner des données secrètes au lieu de données banales
- sauter le "if (code is incorrect) exit" pour sauter les tests de vérification
- faire faire des calculs erronés au DES et en déduire la clé
- faire du bit flipping sur les clé DES et en déduire des choses
Les contre-mesures sont assez simples : puisque tu ne peux pas faire confiance à ta RAM ou au déroulement de ton programme à un instant t, il suffit d'ajouter de la redondance et de vérifier qu'elle est toujours là :
- les valeurs en EEPROM sont lues, relues et parfois encore relues. Les adresses sources et destination sont stockées à deux endroits différents et comparées en permanence.
- les valeurs écrites en EEPROM sont écrites puis relues puis encore relues. Idem, double copie des adresses.
- les copies de RAM à RAM sont vérifiées avant, pendant la boucle puis après avec encore une double-vérification.
- les chemins d'exécution du code comportent des sémaphores qu'on incrémente à côté de chaque instruction sensible et qu'on vérifie régulièrement
Il y a aussi des petites protections matérielles, comme une grille au dessus de la puce pour détecter si la puce est mise à nue. Mais ça ne fait perdre que quelques heures à l'attaquant, le temps qu'il reroute les courant ailleurs et qu'il gratte la grille.
La sécurité vient donc de la combinaison des protections physiques et logicielles.
Etant donné un équipement illimité et un temps illimité, c'est toujours le craqueur qui va gagner. Quand une carte passe trois semaines dans un labo, ils sont capables de dire exactement quelle instruction est executée à quel moment, synchroniser une attaque laser dessus et voir si le programme pète.
Avec un peu plus de temps, ils peuvent carrément modifier le silicium et rerouter des chemins électroniques, donc concrètement, reprogrammer le hardware de la puce. Tiens, si je mettait un random nul ? Face à ça, il y a bien sur des protections logicielles, mais étant donné qu'ils comprennent tout ce qui est fait au niveau logiciel, ils peuvent prendre le temps de les contourner.
Au final, une carte obtient une note de résistance, qui correspond à la quantité de moyen qu'il faut pour la craquer, et à la disponibilité de ces moyens pour le grand public.
# Amélioration ?
Posté par Philippe F (site web personnel) . En réponse au journal Une véritable interface en 3 dimensions. Évalué à 1.
Vous pensez vraiment que ça va être plus simple parce que c'est en 3D. Les gens ont déjà du mal avec la représentations d'un "bureau" en deux dimensions et la notion de "fenêtre".
Pour ma part, je pense plutôt que la 3D va compliquer encore plus l'interaction. Il y a plein de gens qui ne voient pas du tout en 3D, sont incapables de se projeter en relief dans une surface plane. Il y a aussi la fatigue oculaire engendrée par ce type de visualisation.
Côté innovation en terme d'interface, il faut plutôt regarder de ce côté :
http://rchi.raskincenter.org/index.php?title=Home
Sauf que ce propose de tels changements d'interaction que c'est déroutant, pour tous les humains intoxiqués aux interfaces actuelles notamment.
[^] # Re: Navigo
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 1.
Je me souviens d'un dimanche 30 où j'ai voulu acheter ma carte orange de mois suivant. Environ une quarantaine de personne à faire la queue devant les deux pauvres automates. L'un des automates ne gérait pas les passes navigo. Ces automates plantaient souvent. Il a planté juste devant moi donc la dame SNCF l'a rebooté devant mes yeux. Un bon vieux windows. Il a du mettre environ 7 minutes entre le moment du reboot et le moment où il fut prêt à me distribuer mon billet. Sachant qu'elle le rebootait environ tous les 3 clients, ça fait un super débit !
Et encore, j'habite à Enghien, une gare plutôt bien pourvue vu le fric que possède la municipalité. J'ose pas imaginer comment ça doit être dans des villes un peu moins favorisées.
La politique de la SNCF, c'est donc de virer les guichetiers mais surtout pas de rajouter des bornes automatiques. Ou bien l'idée d'ajouter les veilles de 1er et le 1er lui-même une personne exceptionnelle pour faire face à la charge supplémentaire prévisible, annoncée et connue, ce serait trop leur demander.
[^] # Re: une dépèche !!!
Posté par Philippe F (site web personnel) . En réponse au journal KDE 4.0.0 is out \o/. Évalué à 1.
Concernant les paquets debian, il faut demander à Debian si ça arrivera et où.
Oui, il est tout à fait possible de lancer des applications KDE3 dans un environnement KDE4 et vice-versa. A noter que certaines applications KDE3 matures ne sont pas dispo dans KDE4, c'est donc non seulement possible, mais aussi reconnu comme une nécessité.
Les applications KDE4 seront disponible sous windows plus probablement aux alentours de KDE 4.1 . Le portage sous windows est long et pénible, il faut lui laisser le temps de se faire.
Je doute qu'il soit possible de supprimer le window manager, bureau, panneau de contrôle et lanceur de windows en les remplaçant par KDE4. D'une part, c'est loin d'être simple à faire (même si c'est possible), d'autre part, seules les applications sont portées sous windows. Typiquement, KDM n'est pas porté.
[^] # Re: je ne comprend pas ??
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 1.
La Mifare DESFire n'a plus de Mifare que le nom commercial. C'est en fait un OS qui supporte du triple DES classique et un protocole de communication standardisé ISO. Elle contient aussi la compatibilité Mifare, donc c'est une carte qui permet de faire la transition vers un peu plus d'interopérabilité et un peu moins de verrouillage client. Sauf que en fait, la DESFire ne supporte presqu'aucune des commandes ISO de carte à puce, uniquement des commandes propriétaires disponibles après avoir signé un gros NDA avec NXP.
On peut donc dire que la DESFire permet de s'affranchir du gouffre de sécurité de la Mifare classique, mais en aucun cas n'ouvre vers plus d'interopérabilité ou sort du verrouillage client.
Et la carte qui est déployée en millards d'exemplaires dans le monde, c'est pas la DESFire, c'est de la mifare classique.
Sur le jeu de commande de la DESFire, une petite anecdote qui donne une idée du pouvoir de lobbying de NXP : le département de la défense américain a sorti il y a deux-trois ans une spécification pour toutes les cartes des employés des administrations américaines, suite à la course sécuritaire post-11 septembre. Les administrations ont obligation à partir d'une certaine date que tous les fonctionnaires ou contractuels bossant pour le gouvernement aient une telle carte. Autant dire, beaucoup de monde, un marché bien juteux pour les fabricants de cartes. Ces naïfs d'informaticiens avaient spécifié une carte supportant uniquement des commandes ISO, donc la DESFire était exclu, ne supportant que des commandes propriétaires. Quelques mois plus tard, le gouvernement américain a révisé sa spécification en diminuant le nombre de commande ISO à supporter à 3. Dans le même temps la spécification de la DESFire a été modifiée pour supporter 3 commandes ISO (les seules !). Intéressant hein ?
Ca donne une idée de l'ouverture de ce genre de marché. Autant dire qu'il faut plus qu'un produit répondant aux spécifications officielles pour rentrer dans ce type business.
[^] # Re: ...
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 1.
A priori jamais.
D'un point de vue commercial, ça n'a aucun sens. C'est un peu comme si tu demandais une carte de fidélité qui marche à la fois chez Leclerc et chez Carrefour.
# C'est trop compliqué !
Posté par Philippe F (site web personnel) . En réponse au journal Des langages de haut niveau. Évalué à 1.
Les gens qui se posent un peu la questions d'approches différentes de la programmation, notamment avec des langages utilisant des concepts différents sont en général ceux qui déjà dans leur pratique de la programmation sont très rigoureux.
Quand on propose à un étudiant qui vient de faire trois années pour apprendre péniblement le java de faire du lisp, ça lui sort par les yeux.
Pour reprendre ton exemple du sous-marin, tu peux dire que le sous-marin a trois états et que décider de plonger, c'est faire un changement d'état global qui entraine des mises à jour automatiques en cascade, pour le commun des mortels, c'est plus simple de dire qu'on donne l'ordre au sous-marin de plonger et qu'il faut faire des trucs pour ça. La description impérative est tout simplement beaucoup plus simple à appréhender, même si elle est beaucoup plus sujette à une erreur lors de la mise en oeuvre.
[^] # Re: ...
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 2.
Comme les terminaux restent déployés jusqu'à 10 ou 15 ans sans être changés, beaucoup de cartes fonctionnent soit avec la nouvelle norme méga-sécurisée, soit avec l'ancienne beaucoup moins sécurisée. Un choix est fait au moment du paiement. Tant que EMV n'est pas déployé partout, le système comporte donc des failles facile à exploiter. Il suffit de dire au lecteur "je suis une vieille carte, soit gentil avec moi et n'utilise pas de sécurité" et il obéira gentiment.
C'est le problème de la sécurité théorique versus la mise en place pratique. Il est difficile de demander aux commerçants de jeter leur terminal à la poubelle tous les 5 ans, sachant qu'ils payent le terminal et qu'ils payent aussi pour les transactions.
Si je me souviens bien (mais je ne suis pas expert dans le marché du paiement français), le problème mis en avant par Humpich était que pour des automates hors-ligne, le système de vérification était léger et il l'avait cassé. C'est pas un gros exploit, ce qu'on fait les mecs que je cite est quand même déjà plus impressionnant : reverse engineering de circuit, c'est fun bien que ce soit quand même une pratique courante dans l'industrie.
Ce qu'a fait Serge Humpich n'est pas possible de façon généralisée avec des cartes EMV. Pour des cartes EMV, la vérification hors-ligne se fait soit avec un certificat RSA, soit ne se fait pas mais il y a un montant maximum hors-ligne qui peut être dépensé. Si c'est en ligne, la vérification est systématique. J'imagine que Humpich arriverait à se faire de la presse en montrant que dans certains cas, il n'y a pas de vérification hors ligne des transactions. Ca impressionnerait toujours les journalistes, bien que cela soit une information publique.
Au fait, les specifications EMV sont publiques et librement téléchargeable : http://www.emvco.com/specifications.asp?show=3
Ce qui a changé depuis Humpich, outre le passage bien amorçé à l'EMV, c'est que c'est beaucoup beaucoup plus facile de faire des terminaux en ligne maintenant. Par exemple, pas mal de terminaux sont GPRS aujourd'hui ( == utilisent le réseau GSM). Ca laisse beaucoup moins de marge aux frauderus.
Je tiens à ajouter que Humpich n'a pas du tout remis en questions la sécurité de la carte. Une carte à puce correctement implémentée (et la grande majorité le sont) est une coffre fort inviolable. Personne n'est en mesure d'aller lire votre PIN dans votre carte ou de trouver la clé privée des certificats de la carte. Par contre si le code PIN est écrit sur un autocollant au dos de la carte, le fait que la carte soit un coffre fort ne change rien au fait qu'on pourra dépenser tous vos sous.
[^] # Re: Navigo
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 1.
A chaque fois que tu passes un portique, l'heure et le nom du portique sont stockes sur la carte. Si ils verifient ton passe navigo, ils verront que la derniere entree est trop vieille par rapport à ton voyage actuel.
Cela dit, dans bien des cas, le passe navigo est juste regardé, pas vérifié.
[^] # Re: DES?
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 2.
http://en.wikipedia.org/wiki/DESX
Les autres algos qu'on trouve sur les cartes à puces sont soit du triple-DES (cartes pas trop cher), soit du RSA pour les cartes de compétition. Faut voir que dans l'industrie, on se base sur des standards qui tournent depuis longtemps. Ceux deux-là (DES et RSA) sont pas prêt de disparaître.
Pour les passeports, ils utilisent aussi de l'AES et de l'ECC mais ça reste une utilisation exceptionnelle. Poussée par les allemands et les français d'ailleurs.
Pour ta carte bleue, c'est du RSA par exemple.
Pour élaborer un peu plus sur la crypto, quand un nouvel algo est introduit, il ne suffit pas de l'implémenter pour qu'il apparaisse sur les cartes à puces. Il faut aussi :
- qu'il aille suffisamment vite
- qu'il ne consomme pas trop de courant
- qu'on puisse le sécuriser contre tout un tas d''attaques tordues dites "attaques par des canaux cachées" et attaques au laser
- que les fabricants de silicium l'intègre à leur offre
- que les clients le demande
- que tous les outils actuels de test qui fonctionnent allègrement avec du DES ou du RSA s'adaptent
- que les développeurs se forment
Bref, dans quelques années, si RSA et 3DES montrent vraiment leurs limites, on passera à autre chose.
[^] # Re: Question
Posté par Philippe F (site web personnel) . En réponse au journal Bye bye les tags mifare. Évalué à 1.
[^] # Re: Phonon
Posté par Philippe F (site web personnel) . En réponse au journal Qt 4.4 : Version de démonstration. Évalué à 1.
Ca me parait pas choquant que ce code soit illisible. Souvent mon code optimisé devient illisible parce que certains raccourcis sont effectivement illisibles.
Je peux pas dire que un switch touffu résulte nécessairement de ce type d'optimisation mais ca semble quand même probable, surtout quand tu parles de dessin de widget noù la vitesse doit être la priorité.
Note qu'un gros switch s'optimise en général pas mal par le compilateur, en générant (horreur) des goto.
D'ailleurs, j'ai pas vu de goto dans Qt, preuve qu'ils codent proprement :-) Je suis même prêt à soutenir un troll qu'on code avec un goto peut être plus propre et plus lisible *dans certaines conditions* qu'un code sans goto (ou sans switch touffu puisqu'on y est).
[^] # Re: troll de noel
Posté par Philippe F (site web personnel) . En réponse à la dépêche Ruby 1.9.0 est sorti pour Noël. Évalué à 1.
_ la création de wrapper de bibliothèques C est franchement pas dur. (je sais pas ce qu'il en est en python?)
En Python tu peux utiliser Pyrex, ou bien ctypes, ou bien swig, ou bien tout faire à la main.
ou boost.
[^] # Re: un technicien linux ?
Posté par Philippe F (site web personnel) . En réponse à la dépêche Nouveau serveur LinuxFr.org mis en production. Évalué à 1.
- nous demandons 5 années d'expérience avec Windows XP
- mais Windows XP n'est sorti que depuis 3 ans !
- dommage. Vous pourrez repostuler dans deux ans si vous voulez...
- bah, d'ici là vous demanderez 7 ans d'expérience avec Windows XP.
[^] # Re: Phonon
Posté par Philippe F (site web personnel) . En réponse au journal Qt 4.4 : Version de démonstration. Évalué à 1.
Par contre, niveau design des outils, je pense qu'ils peuvent mieux faire. Je m'explique. Quand Qt Designer est sorti, tout ceux qui ont voulu l'intégrer ont constate que l'architecture interne du bousin ne permettait pas une integration exterieure. Il a fallu attendre quelques années et une reecriture partielle pour que ça soit possible. même histoire avec qmake. Encore même histoire avec Qt/Help.
Je révere trolltech mais je suis quand même surpris que leurs outils ne soient plus pensés pour une intégration extérieure.
Espérons que QtHelp + QtDesigner + qmake leur aura fait comprendre cela.
Sinon, Qt, c'est bon mangez-en !