12 juin 2019

Retours sur le SSTIC – 17e édition – Jour 3

SSTIC

Le quantique, c’est fantastique !

Par Xavier Bonnetain (Inria)

Le chercheur à l’Inria, Xavier Bonnetain, a présenté dans cette conférence les conséquences de l’apparition d’ordinateurs quantiques pour le domaine de la cryptographie. En effet, le domaine de l’informatique quantique est déjà depuis quelque temps un sujet d’actualité. De nombreux états et grandes entreprises n’hésitent pas à investir des sommes conséquentes à ce sujet. Ainsi, les conséquences sur les parties de cryptographie symétriques, asymétriques ainsi que sur les protocoles de communication ont été étudiées.

Xavier explique que l’idée d’ordinateurs quantiques ne sert pas à simuler la nature, mais bien à optimiser la puissance de calcul des ordinateurs actuels. Les ordinateurs classiques actuels permettent de représenter des 0 et des 1 (via la tension par exemple), alors que les ordinateurs quantiques permettront d’encoder un état quantique (via la position d’une particule, i.e. un observable). Il est important de noter que cet observable n’a pas nécessairement une valeur fixée.

Il a été rappelé que la sécurité des chiffrements asymétriques repose en partie sur la difficulté de factoriser des grands nombres (ou calculer des logarithmes discrets). Or l’algorithme de Shor permet justement, sur un ordinateur quantique, de factoriser et calculer des logarithmes discrets en temps polynomial. Ces ordinateurs affaiblissent donc considérablement la sécurité de la cryptographie asymétrique.

Concernant les conséquences sur la cryptographie symétrique, elle reste moins impactée. En effet, il est possible de réaliser une recherche exhaustive de la clef secrète en un temps de N^1/2 (N étant le nombre de clefs – cf. algorithme de Grover). Ainsi, en doublant la taille des clefs des algorithmes symétriques actuels, nous retrouverons la même difficulté sur la recherche exhaustive de clefs présente sur les ordinateurs actuels.

Enfin, le chercheur a conclu sa présentation en mettant en avant qu’il était nécessaire de renouveler les standards de cryptographie asymétrique actuels. Pour la cryptographie symétrique, il suffirait d’augmenter la taille des clefs. Il termine par dire qu’il serait également intéressant de commencer à réfléchir à des protocoles de communications quantiques (envoi d’états quantiques).

Russian Style (Lack of) Randomness

Par Xavier Bonnetain (Inria)

Introduction

Enchaînant sur une deuxième conférence, Xavier a présenté son étude sur une des manières dont les Russes peuvent concevoir des méthodes de chiffrement. De manière générale, un nouveau design est dévoilé publiquement avec son cahier des charges, ses spécifications et une analyse de sécurité. Dans un premier temps, cet article montrera comment standardiser un algorithme cryptographique. Après, nous étudierons deux méthodes de chiffrement qui sont « Kuznyechik » et « Streebog » pour savoir s’ils sont crédibles.

Standardisation d’un algorithme cryptographique

Il est crucial pour standardiser une méthode de chiffrement que sa conception doit être assez développé et compréhensible. Par la suite, des analystes, extérieurs au design, vont l’étudier et essayer de la « casser » afin de s’assurer de sa fiabilité pour le déployer au public. Si le nouveau standard n’est pas assez sécurisé, il est alors rendu inutilisable. Cependant, il existe quelques gouvernements qui publient des standards sans fournir d’informations approfondies. Ces méthodes, dont certaines parties complexes ne sont pas expliquées, sont donc exploitées par les développeurs. Ce manque d’information perturbe ainsi les analystes qui essaient d’obtenir la clé de chiffrement afin de lire les messages et tester la solidité de la solution.

Le design russe

Tout d’abord, les deux algorithmes étudiés sont « Kuznyechik » et « Streebog ». Ce sont des chiffrements par bloc ou réseaux de substitution-permutation. Ils contiennent 3 différents éléments pour créer une construction standard; « Kuznyechik » ou « Streebog », une couche linéaire L qui est la diffusion et une boîte-S qui est responsable de la confusion.

C’est la boîte-S π qui sera traité dans cet article, car elle est utilisée par les deux méthodes de chiffrement. Cette boîte peut être représentée par un tableau de 256 valeurs :

Les designers ont signalé publiquement que cette génération de nombres était aléatoire, que les propriétés cryptographiques sont sous-optimales et qu’il n’y a pas de structures mathématiques fortes. Ce sont des paramètres habituellement utilisés dans les années 1990. Cependant, en janvier 2019, des chercheurs réussissent à décomposer π. L’algorithme « Kuznyechik » qui est toujours en période de validation est donc remis en cause pour la prochaine réunion qui sera en septembre 2019. Quant à « Streeborg », il a déjà été validé en octobre 2018.

Les propriétés

La fonction π prend 256 valeurs en entrée et en renvoie 256. Après quelques recherches, les résultats montrent que cette fonction envoie des classes multiplicatives sur des classes additives d’où un lien logarithmique. D’ailleurs, l’auteur a réussi à trouver une fonction en C afin de représenter la boîte-S π:

Pour rappel, les concepteurs ont insisté que ces valeurs étaient engendrées accidentellement pour éviter les structures mathématiques fortes.

Cette structure est inhabituelle et difficile à déchiffrer. De plus, il a été démontré qu’il interagit avec d’autres blocs principaux liés à « Streeborg » via une potentielle « backdoor » (une faille implémentée volontairement), mais aucune faille l’exploitant n’a été recensée à ce jour.

Conclusion

Pour conclure, l’auteur encourage à ne pas déployer les algorithmes de « Kuznyechik » et «Streebog », car ils ne sont pas sûrs. Les deux derniers algorithmes cryptographiques qui ont été standardisés en Russie, ont été publiés avec seulement ses spécifications. Après des études menées par Xavier et son équipe, ils ont découvert que ces 2 standards ont caché une structure mathématique de manière volontaire via la boîte-S π. Contrairement à leur publication, les concepteurs ont créé cette structure délibérément, ce qui rend ces standards suspects. Au final, Xavier insiste que si un algorithme est standard, cela ne veut pas forcément dire qu’il est fiable.

SourceFu, utilisation de l’interprétation partielle pour la « deobfuscation » de sources

Par Nicolas Zilio

Nicolas présente un de ses projets personnels nommés SourceFu, un outil de “ deobfuscation” de code source. Il explique que l’idée de ce projet a émergé après qu’il ait supprimé les fichiers sources non offusqués d’un code dont il venait de créer les fichiers sources offusqués. Son objectif était de trouver une solution pour “deobfusquer” ces fichiers afin de pouvoir restaurer son code source.

Pour répondre à son problème, il a commencé à chercher parmi les outils existants. Cependant les seuls outils qu’il a trouvés avaient un des deux fonctionnements suivants :

  1. Utilisation des expressions régulière et formatage : Ceci n’était pas compliqué à mettre en place, cependant cette solution n’était pas très performante.
  2. Utilisation d’outils de type sandbox : l’accès aux sources est toutefois perdu bien qu’il soit possible d’en comprendre le fonctionnement.

Toutefois, il est également possible de le faire manuellement bien que cela demande énormément de temps et d’efforts. Pour s’éviter tous ces efforts, Nicolas a développé une solution qui utilise à la fois les expressions régulières et également les principes du sandboxing sans aller jusqu’à l’exécution du code.

Son outil dispose d’une API utilisable depuis la ligne de commande, depuis un programme ou encore depuis une interface web :

Le fonctionnement de SourceFu se décline selon les étapes suivantes :

  1. Optimisation 1-passe : suppression des commentaires et remplacement des constantes
  2. Optimisation multi-passes : boucle sur des optimisations 1-passe jusqu’à ce qu’il n’y ait plus d’optimisation possible
  3. Interprétation des expressions (et sous-expressions) séparées par des opérateurs
  4. Simplification de code : supprimer les blocs IF ou ELSE vérifiant systématiquement FAUX
  5. Renommage des variables : Afin d’éviter les noms illisibles, identification de toutes les variables d’une portée spécifique et renommage avec un mot clé suivi d’un index

Cet outil peut être utilisé pour :

  • Des investigations au sein d’un SOC/CERT : lors de plusieurs attaques menées à partir d’un même programme dont le code est obfusqué de différentes façons, cet outil pourrait mettre en évidence qu’il s’agit du même programme
  • L’amélioration de la capacité des IDE et outils de traitement de sources : SourceFu pourrait être intégré en tant que plugin au sein d’IDE
  • Du fuzzing basé sur des grammaires
  • Recherches dans un cadre académique

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *