Est-ce que dissimuler c'est sécuriser ?
Dans la tête de beaucoup de gens, un système sécurisé est un système caché, un système dont on ne sait rien.
C’est faux.
Comme vous avez pu le voir dans l’épisode de Cryptotrucs sur de vieilles techniques de cryptographie, on ne faisait parfois que cacher le message.
Est-ce que dissimuler c'est sécuriser ?
Dans la tête de beaucoup de gens, un système sécurisé est un système caché, un système dont on ne sait rien.
Cette façon de faire est fortement déconseillée maintenant.
Il est bien plus sûr de connaître parfaitement un système sécurisé que de ne rien en connaître.
Pourquoi ?
Alors, attention ça va « name-dropper ».
Au 19ème siècle, Auguste Kerckhoffs établit des principes pour communiquer de façon sécurisée. Le deuxième principe, dont j’ai déjà parlé dans un épisode de Cryptotrucs, stipule que :
« Il faut que le système n’exige pas le secret, et qu’il puisse sans inconvénient tomber entre les mains de l’ennemi. »
Au 20ème siècle cette fois, Eric Raymond établit la loi de Linus (en l’honneur de Linus Torvalds, le créateur de Linux) :
« Avec suffisamment d’yeux, tous les bugs sont superficiels. »
Bruce Schneier précise le second principe de Kerckhoffs :
« Le principe de Kerckhoffs s’applique au-delà des chiffres et des codes, c’est-à-dire aux systèmes de sécurité en général : tout secret est en fait un point de cassure possible. Par conséquent, le secret est une cause première de fragilité, donc cela même peut amener un système à un effondrement catastrophique. À l’inverse, l’ouverture amène la ductilité. »
Et c’est là le coeur du problème avec le fait de cacher (l’obfuscation). On ne maîtrise pas le risque. Plus le secret est grand, plus il y a de risque de fuite.
Plus un système est caché, moins il est facile de le corriger, de le réparer et même de repérer s’il a été percé. Le fait de rendre le code d’un système public, le rendre opensource, permet de réduire ce déséquilibre entre attaquant (« hackeur ») et défenseur. On espère, en rendant le code public, augmenter le nombre de défenseurs et donc rendre le système plus fiable.
Le secret doit rester le plus petit possible. On utilise, en général, la clé de chiffrement.
Il y a un inconvénient à cette approche. Il faut forger une communauté autour du code. Parfois, des outils cryptographiques utilisés par tout le monde ne bénéficient pas d’une communauté suffisante pour que le code soit suffisamment testé (le « suffisamment d’yeux » de la loi de Linus).
C’était le cas d’OpenSSL. La communauté de développement d’OpenSSL a été trop réduite pendant des années et des failles de sécurité importantes n’ont pas été colmatées assez vite (la faille Heartbleed).
Cacher ou pas son code revient donc à une analyse de risques. Rendre le code public limite le risque de failles à condition qu’une communauté de développeurs se forme autour.