Cryptographie!

La cryptographie en boîte blanche

  En cryptographie, les failles peuvent venir de tous les côtés. Si Alice fait fonctionner un algorithme de cryptographie sur son ordinateur, il est possible que cet ordinateur soit infesté par un virus qui peut surveiller tout ce qui s'y passe. En particulier, le virus peut avoir accès complètement au fichier binaire de l'algorithme, il peut le modifier à loisir. Bref, il est nécessaire de cacher des clés à quelqu'un qui a une vue complète : on appelle ceci la cryptographie en boîte blanche.

  Il est souvent difficile, même avec un désassembleur, de comprendre comment fonctionne un programme à partir de son fichier binaire. Cela dit, même dans ce cas, les attaques en boite blanche peuvent être très efficaces. Imaginons en effet que notre programme implémente le DES ou l'AES à partir d'une clé K cachée dans le fichier binaire. Difficile de la retrouver sans avoir d'informations complémentaires. Mais les algorithmes DES et AES fonctionnent à partir de tables de permutation, connues et publiques. Il est facile de retrouver ces tables dans le fichier binaire. On peut alors les modifier (puisqu'on a accès au binaire) de sorte qu'elles ne font plus rien… ou plus précisément que le résultat à la sortie du programme soit exactement la clé secrète. Il suffit alors de faire fonctionner l'algorithme modifié pour retrouver la clé.

  Lorsque le programme est écrit en java, langage très utilisé pour les applications multi-plateformes ou sur les smartphones, la situation devient alors beaucoup plus facile. Un programme java est en effet transformé, à la compilation, en bytecode (et non en fichier binaire) destiné à être exécuté par une machine virtuelle java. Ce bytecode contient toutes les informations du code initial : nom des classes, variables, instructions… Il est très facile, à partir de ce bytecode, de retrouver le programme initial (à part ses éventuels commentaires), et donc de comprendre ce qu'il fait. La seule solution, ici, est l'offuscation de code. Elle consiste à transformer le code avant sa compilation de sorte de le rendre illisible. Ceci passe par le changement des noms des variables et des classes (par exemple, la variable Motdepasse s'appellera désormais xY8ui4e), et par l'ajout d'instructions qui en réalité ne servent à rien, si ce n'est à compliquer la lecture du code. Bien sûr, ceci nuit à la rapidité de l'exécution de l'algorithme et si l'offuscation de code peut ralentir la compréhension d'un code source, elle ne l'interdit pas.