Cet article fait suite à : Own crypto app Improvement

Parlons dans cet article un peu d’intégrité et d’authentification dans le cas d’un chiffrement de fichier sur disque.

Intégrité

La vérification de l’intégrité d’un fichier, revient à appliquer une fonction de hash. Si un ou plusieurs octets sont modifiés, le résultat du hash, l’empreinte, est complètement différente. Nous écartons le phénomène de collision inhérent à ces fonctions dans la suite. Posons- nous les bonnes questions :

  • Que veut on vérifier ?
    • L’intégrité du fichier en clair ?
    • L’intégrité du fichier chiffré sans la partie contenant la clé ?
    • L’intégrité du fichier chiffré avec la partie contenant la clé ?
  • Comment stocker cette valeur ?
    • En clair ?
    • Chiffré avec la clé ?

Le but premier de l’intégrité est d’avoir une preuve irréfutable que le fichier que nous avons est le bon avant d’effectuer la moindre action. De ce fait, on veut garantir l’intégrité du fichier chiffré plutôt que celle en clair.

Si l’empreinte est en clair, un attaquant, qui aurait accès au fichier, pourrait modifier celui-ci.

  1. Un attaquant peut modifier le fichier et remplacer l’empreinte par une nouvelle conforme aux modifications qu’il a apportées.
    • De notre coté, la vérification sera un succès.
  2. Un attaquant peut modifier l’empreinte uniquement.
    • De notre coté, la vérification sera un échec.
  3. Un attaquant peut modifier le fichier uniquement.
    • De notre coté, la vérification sera un échec.

On s’aperçoit que cette protection est peu efficace (1)(3) et peut aussi servir à engendrer un déni de service (2).

Et si l’empreinte du fichier était chiffrée avec la clé de chiffrement ?

  1. Un attaquant peut modifier le fichier.
    • De notre coté, la vérification sera un échec.
  2. L’attaquant peut se servir du hash comme preuve mathématique pour tester des mots de passe.
    • De notre coté, on a facilité son travail.

Dans ce cas, expliquons le (2), le (1) étant identique au cas précédent, le hash du fichier est chiffré avec le mot de passe. L’attaquant qui a le fichier, peut régénérer ce hash. Ensuite il lui suffit de faire une recherche exhaustive de mot de passe sur la partie chiffrée avec la clé ( 48 octets pour la clé et l’iv, 32 ou 64 octets en plus suivant le hash utilisé). Pour vérifier son résultat, il fait simplement une comparaison avec le hash généré précédemment.

CQFD, si vous voulez utiliser un hash pour l’intégrité, il est préférable de le communiquer via un autre canal.

Authentification

MAC, Message Authentification Code, est une famille de fonctions taillées pour répondre à ce besoin. La grosse différence par rapport à une fonction de hash, est dans l’utilisation d’une clé pour produire l’empreinte. Parfait ? Non.

L’attaquant a toujours le moyen de faire un déni de service et, avec une mauvaise implémentation du MAC, on lui facilite encore le travail. Si on utilise le même mot de passe pour chiffrer la clé et pour faire le HMAC du fichier chiffré, on se retrouve dans le cas précédent. Il faudrait utiliser une autre clé. Demander à l’utilisateur de fournir deux mots de passe pour un fichier n’est pas une bonne solution. Il peut donner deux fois le même mais surtout ça deviendrait pénible d’utiliser notre application. On peut mixer l’intégrité avec l’authentification, en utilisant un MAC sur une empreinte. Cela ne change rien au problème.

CQFD, si vous voulez utiliser un HMAC, il faut utiliser une autre clé que celle du chiffrement.

Mon avis

Dans le cadre d’un chiffrement symétrique pur, la clé est déjà un secret et vous savez à qui vous la donner ou pas. Je pense que l’authentification et l’intégrité doivent être gérées par un autre moyen. Plus précisément, on ne stockera pas des informations d’authentification et d’intégrité avec les données confidentielles. Dans notre cas, nous pourrons utiliser un fichier propre au programme, contenant ces informations.

Bilan

Au vu des problématiques soulevées dans cet article, nous faisons le choix de nous concentrer sur la confidentialité des données dans un premier temps. Ca nous permettra de nous donner plus de temps afin d’élaborer une bonne stratégie concernant la gestion de l’intégrité et de l’authentification. Avant de poursuivre la réalisation de notre Application, nous allons procéder pour le prochain article, à une pause ludique. J’illustrerai mes propos précédents avec des exercices de code / force brute.