La sécurité par l’obscurité ne marche pas

Certification CSPN (ANSSI) d’Uhuru Mobile, french bashing, nouvelles versions de SMS Perseus, deux concours de haking, l’affaire Truecrypt et le lancement de GostCrypt avec des algorithmes russes, backdoors mathématiques… Le point avec le Directeur du laboratoire de virologie et de cryptologie opérationnelles.

 

 

SecuriteOff.com : Disponible sur le PlayStore de Google, Perseus est toujours en version Alpha : cette version 2 est-elle la version définitive ?

Eric Filiol : Non. C’était une version temporaire (d’où sa dénomination de « alpha »). La version « bêta » devrait sortir dans une semaine, le temps de tout vérifier et revérifier. Ce qui est intéressant avec la version « alpha », c’est que nous voulions aussi tester le dépôt d’applications sur le Google Play (leur magasin d’applications). Nous avons maintenant la conviction que Google est loin de tester toutes les applications, en particulier concernant les contraintes règlementaires qu’il impose lors du dépôt.

 

 

SecuriteOff.com : La présentation faite au dernier SSTIC a rencontré des problèmes. Lesquels ?

E.F : Tout d’abord, je suis assez surpris de l’attitude de la personne qui l’a présentée, dont le sens de l’éthique est pour le moins douteux. En tout cas, nous ne devons pas avoir la même conception de ce que les mots Éthique et Correction signifient. D’une part, la correction (ce que nous faisons même pour des logiciels propriétaires) impose d’avertir les auteurs du logiciel, de leur communiquer les éventuelles failles pour correction avant divulgation. Je rappelle que SMS Perseus est un logiciel gratuit et à code source ouvert, que personne n’est obligé de l’utiliser s’il n’en veut pas et qu’à ce titre, on mérite un minimum d’égards et de respect. D’autre part, mes collègues qui sont allés voir cette personne après sa présentation pour lui demander s’il nous avait avertis – je n’ai pu assister à cette présentation de 3 minutes n’ayant pas été prévenu – m’ont rapporté qu’elle avait pris les choses un peu de haut. Nous l’avons nous-mêmes contactée pour avoir plus de détails qui pourraient être éventuellement pris en compte pour la version bêta.

Nous attendons encore une réponse, ce qui ajoute au manque de correction précédemment mentionné. Cette personne a dû rechercher une gloire autant facile qu’éphémère et pitoyable. Je le laisse face à sa conscience, s’il en a une. Pour ma part, si un de mes chercheurs se comportait envers autrui de la sorte, il aurait affaire à moi. Concernant l’attaque elle-même, pour ce qu’on m’en a rapporté, elle semble supposer des conditions d’exploitation particulières et donc sa portée, là aussi opérationnelle, est potentiellement discutable.

SecuriteOff.com : Avec la version alpha, les clés Perseus étaient en clair dans les données de l’application. Cette faille a-t-elle été comblée : les clés sont-elles chiffrées ?
E.F : Tout d’abord, il faut relativiser cette « faiblesse » que nous avions certes identifiée, mais laissée, car, à cette époque-là, nous voulions d’abord valider le code. Il y avait également d’autres choses non optimales (même clef pour chaque SMS d’un même fil de discussion par exemple) qui ne me satisfaisaient pas. Avoir les clefs en clair n’est pas optimal, j’en conviens. Mais pour l’exploiter, il faut accéder au contenu du téléphone, ce qui dans un cas opérationnel, n’est pas aussi facile que cela (contact physique ou déploiement de code malveillant espion). Dans ce cas-là, même si vous sécurisez une application (clefs chiffrées), l’accès au téléphone par ce type d’attaques permettra de voler les clefs en mémoire lorsqu’elles sont en clair. Donc, le plus important est avant tout de garantir la sécurité de l’environnement. Rien ne sert de se polariser sur la porte blindée si le mur est en carton. C’est un principe de base qu’il est important de rappeler. Dans la version actuelle, les clefs sont chiffrées et tout ce que je trouvais non optimal a été modifié, optimisé et vérifié. Là encore, Perseus est assez complexe d’un point de vue algorithmique, l’environnement Androïd n’est pas particulièrement adapté au type de programmation et de primitives dont nous avions besoin. Les erreurs de jeunesse de SMS Perseus devraient maintenant être derrière nous.

SecuriteOff.com : Cette version bénéficie-t-elle d’une nouvelle version de la librairie qui permet de « maquiller » un SMS pour qu’il apparaisse comme une image ou un PDF ?

E.F : En fait, pour le moment nous avons sorti la version 1.4 de la librairie Perseus. Il fallait rendre le code plus portable : 32 et 64 bits, en particulier pour la partie génération d’aléa utilisée pour générer les codeurs et initialiser le générateur de bruit. L’algorithmique derrière Perseus est assez complexe et produire un code parfait dès le début est un objectif assez ardu. Nous allons effectivement travailler maintenant sur une surcouche de cette librairie qui permette de simuler n’importe quel type de contenu pour contourner l’analyse statistique et par entropie des filtres automatiques. Nous allons également ajouter des leurres pour simuler sémantiquement (en-têtes/trailer spécifiques aux formats, fonctions et primitives leurres…) ces contenus.
SecuriteOff.com : Une version matérielle pour la protection des flux à la volée est en cours de développement. Où en est-elle ?

E.F : Nous sommes en phase de validation de la preuve de concept et allons passer courant juillet en phase de test. Nous avons dû faire un certain nombre de choix et de tests – ce qui a pris du temps – et concevoir un tunnel TCP Perseus (ce qui n’est pas facile et a nécessité de considérer des buffers de taille variable et donc au final d’écrire un protocole ad hoc simple de transfert). En septembre, nous allons intégrer la version polynomiale du décodeur et ensuite travailler avec ARX Arcéo pour la partie industrialisation. Nous avons eu la chance d’avoir un excellent étudiant, Jonathan Thieuleux, qui a travaillé avec nous sur ce projet.
SecuriteOff.com : Cela signifie que la société ARX Arcéo pourrait proposer des applications commerciales intégrant la librairie Perseus ?

E.F : Ce projet a bien avancé. ARX Arcéo est en phase d’industrialisation de la librairie. Nous avons travaillé ensemble sur le décodage des codes convolutifs en complexité polynomiale qui ne sera disponible que pour les versions commerciales proposées cette entreprise. Cette dernière aura pour charge de valoriser la technologie Perseus via différentes applications. Avec la Thaïlande (université KMUTT), la protection de la voix sur IP à l’aide de cette technologie a été validée (publication en mai 2014). Cette application, avec la version commerciale de SMS Perseus, figurera parmi les premiers produits.

SecuriteOff.com : Dans quelques jours, l’équipe du projet DAVFI profite de la Nuit du hack (28/29 juin) pour défier les hackers en leur fournissant des smartphones fonctionnant sous Uhuru Mobile. Ce même challenge sera organisé en octobre lors de la conférence No Such Con (NSC). En quoi consistent ces 2 concours ?

E.F : Le concours consiste à faire auditer des téléphones en conditions réelles, c’est-à-dire tels qu’ils seront vendus et utilisés, en configuration de sécurité standard (mot de passe, chiffrement activé, données réelles présentes sur le téléphone, carte SIM et numéro actifs…). Le but est d’évaluer la sécurité réelle et en situation favorable et/ou hypothétique. Les concurrents disposeront de 3 jours, les téléphones étant envoyés quelques jours avant. S’il y a des faiblesses, en général la durée moyenne pour les trouver est de deux à trois jours.

SecuriteOff.com : Pourquoi organisez-vous de tels concours ?

E.F : Je suis convaincu que lorsqu’on prétend proposer un produit de sécurité, on doit être humble et il n’est pas acceptable de dire « mon produit est sécurisé, faites-moi confiance ». La sécurité par l’obscurité ne fonctionne pas. Il faut descendre dans l’arène et accepter la critique, les retours, les commentaires, bref avoir un regard ouvert, constructif sur ce que l’on fait, susciter un débat. Certes, sur le moment cela peut faire mal, surtout en France où les critiques de « trolleurs » professionnels, souvent peu courageux, car sous couvert d’anonymat, se font fréquemment ad hominem. C’est comme cela que les projets des plus grands (Apache, OpenOffice, TrueCrypt, GNU/Linux…) au plus humbles fonctionnent et progressent. Il n’y a pas de honte à faire des erreurs (sauf en France), il y en a à ne pas être courageux et honnête.

Au final, tout le monde est gagnant, le concepteur qui bénéficie d’un retour et a progressé, les contributeurs qui ont pu faire œuvre utile et participer à un projet et l’éventuel utilisateur final qui pourra s’appuyer sur une évaluation de fait du produit. A ce jour, un certain nombre de sociétés proposent des téléphones sécurisés, mais à part Uhuru/DAVFI, combien ont le courage de faire comme nous ? Aucune. Est-ce acceptable, est-ce sérieux et ne prend t-on pas les utilisateurs pour des idiots ? Cela ne tient que parce que ces sociétés bénéficient de marchés réservés et de contrats assurés. Ils n’ont donc pas besoin de faire leurs preuves. Autrement dit, les dés sont pipés dès le départ. Livrer un produit à l’analyse externe, ouverte et constructive devrait être la règle. Elle le devient de fait et de plus en plus dans la plupart des pays anglo-saxons et dans d’autres pays.

En France, il est de bon ton de critiquer un produit français, de le descendre en flèche, de le suspecter de tous les maux… Le directeur technique de Microsoft France nous avait prévenus que le principal défaut de DAVFI était d’être français. C’est devenu un sport national que de critiquer l’innovation française ou ceux qui essaient d’être innovants… Cela explique notre retard dans bien des domaines. Critiquer est facile, faire un produit de sécurité – surtout lorsqu’il y a de la crypto délicate à implémenter – cela n’est jamais facile. Ce n’est jamais parfait du premier coup. Créer a toujours été beaucoup plus facile que détruire. En France, il n’est pas facile de proposer des solutions de sécurité surtout libres. Nous n’obligeons personne à utiliser ce que l’on peut développer contrairement à d’autres produits qui s’imposent à nous et avec lesquels la communauté IT est beaucoup plus complaisante. Mais en fait, une fois que l’on a le cuir tanné comme je peux l’avoir maintenant, toutes ces attaques gratuites deviennent un peu vaines.

Je les compare à ces « critiques » de films ou de roman à qui on a envie de dire : « prends une caméra ou prends la plume et montres-nous ce que tu es capable de faire ». Je préfère pour ma part prendre en compte les retours des gens qui eux essaient d’être utiles, constructifs et veulent faire avancer les choses (dans notre cas la SSI). Et moi-même, j’ai pu aider d’autres projets par des retours constructifs sans prendre la terre entière à témoin. La création et le développement c’est à la fois un flambeau à transmettre, un partage permanent et une communauté d’esprit.

SecuriteOff.com : Pour apporter une crédibilité à la solution Uhuru Mobile vous pourriez faire appel à un cabinet d’experts ?

E.F : Cela sera fait dans un deuxième temps, en particulier avec la certification CSPN qui sera assurée par le passage par un CESTI, sous le contrôle de l’ANSSI. C’est important, et je tiens à cette vision contributive et collaborative préalable. Les expertises classiques souffrent souvent d’une certaine orthodoxie dans les approches et la vision. Avoir une vision alternative, ouverte et sans complexe est une richesse dont je ne voudrais pas me passer. Les deux visions sont complémentaires. C’est un peu comme le contrôle technique d’une automobile qui ne peut être délivré que par des sociétés agréées. Mais rien n’empêche d’organiser une visite préalable par le garagiste. C’est tout l’esprit de notre démarche. Tout le monde doit pouvoir contribuer, mais au final le cachet officiel revient à l‘État et à ses prestataires techniques.

SecuriteOff.com : Un audit indépendant présente, peut-être, aussi des limites. Les experts qui réalisent cet audit ne sont peut-être pas assez compétents pour dénicher une backdoor ou une faille volontaire ? Ce qui pourrait d’ailleurs être l’une des causes de la décision surprenante des développeurs anonymes de Truecrypt ?

E.F : Tout d’abord, je voudrais réagir à l’idée que l’on puisse nous soupçonner de mettre une backdoor ou une faille volontaire. C’est assez navrant de voir que s’agissant de produits nationaux, la méfiance est de mise alors que tout le monde accepte sans se poser de questions des produits, services et technologies étrangères pour lesquelles on sait pertinemment qu’il y a des soucis.

Concernant la compétence, je ne sais pas trop ce que cela signifie : avoir fait une grande école, travailler obligatoirement dans une entité ou société reconnue ? Reconnue par qui ? Quand on voit que des experts ne sont pas capables de s’entendre sur la largeur de rails et des wagons, qu’un logiciel de gestion de paie des militaires a mis dans la difficulté des milliers de militaires et leur famille… alors que ces projets avaient été « audités » par des gens compétents, je ne sais plus quoi penser. La compétence est partout et elle repose avant tout sur la motivation. Beaucoup de nos experts « officiels » n’ont plus « faim » et ont été institutionnalisés par le système. Tout le monde doit pouvoir contribuer, de manière ouverte et constructive, surtout pour des produits que nous utilisons tous.

Pour TrueCrypt, il faut arrêter également de gamberger trop. Le code source est connu, tout le monde (la DGA et l’ANSSI en particulier lui ont attribué un CSPN, et dans ces organismes il y a d’excellents experts dont on ne peut remettre la compétence en question) a essayé d’y trouver quelque chose. En vain, excepté quelques problèmes mineurs. La communauté hacker le scrute depuis des années et là aussi il y a des gens très forts et surtout très inventifs, lesquels ne manqueront pas une occasion de se faire un nom en exhibant une faiblesse majeure. Si backdoor il y a, elle ne peut être qu’au niveau mathématique (les algorithmes de chiffrement ou de hachage). Mais alors cela va poser un sacré problème (peut-être Snowden va-t-il faire prochainement des révélations ?), car les algorithmes de chiffrement présents dans TrueCrypt sont également utilisés partout (en particulier l’AES).

SecuriteOff.com : Pourquoi proposez-vous GostCrypt ?

E.F : GostCrypt correspond au produit que je voulais déjà pour mon usage personnel. C’est en fait un projet lancé fin décembre 2013 qui me tenait à cœur depuis longtemps. Si Truecrypt est/était pour moi un superbe outil son principal défaut est de ne proposer que des algorithmes UK/USA-compliant, autrement dit des algorithmes proposés pour ne pas dire imposés – par le jeu des standards, du lobbying… – par les USA et dont on peut suspecter à raison (a minima du fait du principe de précaution) qu’ils contiennent des backdoors mathématiques. Je souhaitais donc proposer un fork de TrueCrypt reposant sur un algorithme non UK/USA, dont la sécurité cryptologique réelleest élevée en particulier en conditions opérationnelles. J’ai choisi les algorithmes russes (chiffrement et hachage) GOST comme candidats idéaux, et ce en dépit de quelques publications prétendant le contraire dont la qualité scientifique (et surtout le caractère reproductible) est plus que contestée.

Ces articles ont été réfutés encore récemment (Babenko & Maro, 2014). On peut avec l’éternité, une quantité irréaliste de couples clair/crypto (en général dépassant l’ensemble des informations jamais produites dans le monde depuis la naissance d’Internet) et une puissance de calcul infinie, briser tout et n’importe quoi, mais en pratique il faut redescendre sur terre. Les articles écrits ces dernières années ressemblent plus à des discussions sur le sexe des anges qu’a un véritable débat scientifique et opérationnel. Sauf qu’il est très probable ces quelques publications ont été instrumentalisées (commandées ?) à un moment opportun où, pour la première fois, un algorithme non UK/USA allait être standardisé par l’ISO comme alternative à l’AES (2012). Outre une sécurité réelle qui n’a strictement rien à envier à l’AES, GOST n’a jamais eu de prétention hégémonique comme l’AES et a été fait par les Russes pour les Russes. Pour toutes ces raisons, GOST est une famille d’algorithmes particulièrement intéressante.

SecuriteOff.com : Qui a développé GostCrypt ?

E.F : Pour le moment, nous sommes trois, Sebastian Groot de l’Amsterdam University of Applied Sciences (implémentation), Baptiste David (sécurité de l’application relativement à l’OS en particulier Windows, implémentation) et moi-même (aspects mathématiques et cryptologie, gestion du projet) tous deux du laboratoire CVO, ESIEA Laval. Mais nous espérons avoir de nombreux contributeurs pour disposer d’une équipe solide et surtout favoriser les critiques et les échanges en interne.

SecuriteOff.com : Revenons à Gost (qui provient de GOsudarstvennyi STandard et qui signifie « standard gouvernemental »), ce système de chiffrement russe. Pourquoi l’avoir retenu et pas un autre algorithme propriétaire ou Open source ?

E.F : Pour compléter le propos précédent, la quasi-totalité des produits de chiffrement qui sont « reconnus » utilisent des algorithmes UK/USA-compliant. Pour les autres, il n’y a pas eu assez d’études détaillées sur leur force réelle. De plus, derrière GOST il y a la Fédération de Russie qui maintient les recherches sur cet algorithme, assure un soutien étatique pour son propre usage (afin de ne pas dépendre de standards occidentaux, lesquels sont tous d’inspiration UK/USA) et offre une pérennité intéressante. Ainsi fin 2014, la Fédération de Russie devrait sortir le nouveau standard de chiffrement Gost (512 bits de clef) lequel sera intégré directement dans GostCrypt. Enfin, il était inenvisageable de recourir à des algorithmes propriétaires (code fermé et problème de licence). La sécurité doit reposer sur l’ouverture de l’algorithme et du code source.

SecuriteOff.com : Y-aura-t ‘il différentes versions ? Pour Windows, GNU/Linux, gratuite, payante ? Version grand public et professionnelle ?

E.F : Tout sera gratuit et ouvert (code source) et placé sous licence GPLv3. GostCrypt sera disponible pour Windows (32 et 64 bits) et GNU/Linux. Nous appelons la communauté des hackers et toute bonne volonté à analyser le code, nous faire remonter les bugs (il est quasi impossible d’avoir un produit parfait dès le départ), rejoindre l’équipe de développement. Certaines étapes (en particulier la certification CSPN, qui est pour moi incontournable, ainsi que celle de l’Opencrypto Audit Project) seront financées par les dons et du financement participatif. Le moteur de recherche Qwant est notre premier sponsor.

SecuriteOff.com : Quel hébergeur avez-vous retenu et selon quels critères ?

E.F : Nous avons choisi, pour la France, Gandi pour son engagement en faveur de valeurs qui nous sont chères : liberté, attachement au libre…. Il soutient activement plusieurs projets libres et est lui-même soutenu par l’EFF. Une marque de reconnaissance cruciale. Le site sera hébergé également (sous d’autres extensions) prochainement dans d’autres pays comme l’Islande, Taiwan… La liste n’est pas encore figée.

 

SecuriteOff.com : Que vous inspire l’arrêt de TrueCrypt ?

E.F : Compte tenu de ce que je suppose concernant les raisons de cet arrêt brusque, beaucoup de tristesse et une certaine inquiétude pour l’avenir surtout à la lecture d’article comme [1] qui nous rappelle le contexte actuel dans lequel tout cela se situe et en particulier celui d’un accroissement de la surveillance généralisée des populations, une montée des extrémismes de toutes natures. Nos libertés et nos valeurs n’ont jamais été autant menacées que maintenant et il est fondamental de (re)développer un esprit de résistance. Le chiffrement est un des outils incontournables de cette résistance. Des projets comme TrueCrypt, GostCrypt, mais aussi Veracrypt, truecrypt.ch… sont vitaux et j’espère qu’il en naitra beaucoup d’autres. La variété est la garantie contre toute forme de contrôle. Personne ne sait pourquoi TrueCrypt a soudainement disparu. J’ai bien mon idée. Mais peu importe. Si 100 projets similaires voient le jour, il sera difficile pour ne pas dire impossible de les faire fermer tous et 100 nouveaux naitront.

On peut objecter que l’on fait le jeu des acteurs nauséabonds de la société en développant l’usage du chiffrement. C’est un faux débat en même temps qu’un argument contestable. Les juges d’instruction ont déjà un arsenal suffisant pour agir (par exemple l’article 132-79 du Code pénal). Il faut juste conforter les juges d’instruction et les magistrats dans leur fonction et leurs pouvoirs et non les amoindrir en donnant des pouvoirs d’écoute préalable, qui transforment le citoyen normal en coupable par défaut, aux forces de police, sans passer par le contrôle des juges. Les vrais nuisibles de la société savent de plus en plus passer sous les radars. Un État fort est avant tout respectueux de ses citoyens. Pour conclure, la phrase célèbre de Benjamin Franklin (citoyen américain à une époque où les USA n’avaient pas encore sombré dans leur délire sécuritaire et policier) reste encore plus d’actualité : “Un peuple prêt à sacrifier un peu de liberté pour un peu de sécurité ne mérite ni l’une ni l’autre et finit par perdre les deux”.

 

 

[1] http://emergingtruth.wordpress.com/2013/06/16/is-this-the-early-signs-of-fascism-nsa-cia-fbi-have-secret-agreements-with-private-companies-such-as-microsoft-and-mcafee/

[2] GostCrypt Project http://www.gostcrypt.org (ouverture du site fin juin 2014)