Sommaire :

• 0:00 : Introduction
• 0:54 : Q1 – A quel moment les données sont chiffrées et déchiffrées ?
• 1:20 : Q2 – Sur quelle machine s’effectue le chiffrement ?
• 1:47 : Q3 – Quel composant peut ordonner le déchiffrement ?
• 2:08 : Q4 – Où est stockée la clé de chiffrement ?
• 2:25 : Conclusion

Lors d’une prestation d’analyse des risques"Possibilité qu’un événement redouté survienne et que ses effets impactent les missions de l’objet de l’étude." - Guide officiel de la méthode EBIOS Risk Manager - More, en discutant d’un scénario d’extraction des données par injection SQL, le client me dit qu’il n’y a pas d’inquiétude la dessus, parce que la base de données est chiffrée. Or on sait bien que dans ce scénario les données seront déchiffrées avant d’être rendues à l’attaquant.

Ceci est un exemple parmi tant d’autres où le chiffrement donne un faux sentiment de sécurité. Et c’est très dangereux car on finit par ne pas mettre les mesures réellement nécessaires, en se fiant, à tort, au chiffrement pour assurer la confidentialité.

Pour éviter cette situation, il est important de comprendre l’utilité du chiffrement en question. Il faut connaître les scénarios d’attaques couvert par ce chiffrement et surtout ceux qui ne le sont pas.

Pour ce faire, je vous donne 4 questions auxquelles il faut répondre :

• Question 1e – A quel moment les données sont chiffrées et déchiffrées ?

Pour un scénario d’attaque donné, il faut se demander si ce scénario donne accès aux données déjà en clair.

Par exemple, le chiffrement du disque dur permet de se protéger contre une attaque physique contre la machine. Mais il faut savoir que les données deviennent accessibles en clair si cette machine est démarrée et compromise par l’attaquant.

• Question 2 – Sur quelles machines s’effectuent le chiffrement ?

Il faut savoir qu’un attaquant ayant accès à cette machine peut accéder à la mémoire et récupérer les données en clair ou même la clé de chiffrement.

Par exemple, si l’administrateur est considéré comme source de risqueUne source de risque est une entité à l’origine de menaces considérées contre le système d’information étudié en vue d’atteindre des objectifs visés. D’un point de vue opérationnel, la source de risque considérée peut réaliser elle-même l’attaque comme elle peut mobiliser d’autres acteurs le faire. More, celui-ci pourra accéder aux données en clair. Si le risque"Possibilité qu’un événement redouté survienne et que ses effets impactent les missions de l’objet de l’étude." - Guide officiel de la méthode EBIOS Risk Manager - More n’est pas acceptable, pensez à réaliser le chiffrement côté client sur l’ordinateur de l’utilisateur habilité.

• Question 3 – Quel composant peut ordonner les opérations de déchiffrement ?

Si ce composant est compromis, alors l’attaquant peut aussi déchiffrer. Et là on retrouve l’exemple d’injection SQL de tout à l’heure. L’application attaquée ordonne le déchiffrement par la base de données, ce qui fait que les données sont récupérées en clair.

• Question 4 –  Où est stockée la clé de chiffrement, et comment elle est récupérer ?

Pour un scénario d’attaque donné, vous devez savoir si l’attaquant peut accéder à la clé de chiffrement, ce qui donne lieu à une situation de porte fermée avec la clé sur la porte.

Voilà, sans être exhaustif, je vous ai listé quatre éléments essentiels à considérer dans l’étude d’un mécanisme de chiffrement, pour connaître son efficacité et identifier ses limites.

Pensez-y surtout quand un fournisseur vous affirme qu’il chiffre vos données ! Il faut aller plus en détail et poser à minima ces 4 questions.