Monday, January 16, 2012

(Fr) Pourquoi il vaut mieux éviter WinZip/AES pour les "échanges sécurisés"



Parfois lorsqu'il est nécessaire d'échanger un fichier de façon « sécurisée », la solution WinZip peut représenter une option facile à utiliser et pratique car présente sur quasiment tous les postes clients.

Cette solution bien que fort pratique est à déconseiller, sauf bien sûr si aucune autre alternative n'existe.

Pourquoi ? Tout simplement parce que WinZip, contrairement à des programmes comme GPG ou Truecrypt, n'a jamais été conçu comme un outil de chiffrement mais comme un outil d'archivage qui propose une option de protection par mot de passe.

La différence est grande et au delà de la robustesse de l'implémentation du système cryptographique, cette différence concerne avant tout son utilisabilité en conditions opérationnelles.

Utiliser des algorithmes de chiffrement forts avec de tailles de clefs très longues est une chose, mais avoir un produit utilisable sur le terrain en cas de stress, fatigue ou personnel non compétant en est une autre.

Un bon logiciel de chiffrement doit laisser aussi peu que possible la possibilité à un utilisateur de se tromper, et pour caricaturer devrait être utilisable par une chèvre stressée et neurasthénique.

Sans parler de l'importance de l'implémentation du système cryptographique - est-il nécessaire de rappeler que la qualité de l'implémentation est aussi importante que la qualité de l'algorithme utilisé et la longueur des clefs - que l'on considérera comme correcte ici (axiome purement arbitraire), les problèmes suivants se posent :

Note : On choisit ici volontairement d'ignorer les problèmes d'implémentations présentés par Tadayoshi Kohno [kohno], les fichiers temporaires, les mots de passe en mémoire, la sécurité du poste, la gestion des clefs, etc.


Fichiers temporaires (7-Zip)

Problème #1 : rétro-compatibilité
Pour des raisons de rétro-compatibilité, WinZip supporte l'ancien système de chiffrement ZipCrypto, qui présente de nombreuses vulnérabilités (un grand nombres d'outils sont disponibles en ligne [elcom] ; en particulier les archives contenant plus de 5 fichiers crées avec WinZip <8 présentent des vulnérabilités permettant de casser le mot de passe en quelques heures).

Le problème est qu'à un moment ou à un autre, soit une personne va se tromper et oublier de sélectionner le chiffrement AES soit elle va être équipée d'un vieille version de WinZip ; au final une archive sera renvoyée chiffrée en ZipCrypto.
Selon les cas, il est beaucoup plus aisé de récupérer le mot de passe, cassant ainsi toute la chaine de confiance sur les messages précédemment échangés, que l'on avait pris la peine de chiffrer avec « AES ».

Problème #2 Affichage, ajout et extension

L’autre problème est que l’interface et l’usage n’a jamais été conçue pour la sécurité. Il n’est pas facile de différencier un fichier chiffré d’un fichier qui ne l’est pas. Ce qui outre les erreurs de manipulation :
  • rend difficile l’identification de fichiers chiffrés par l’expéditeur original
    • Le risque est qu'une tierce personne ajoute un fichier à l'archive et que le destinataire, en l'absence de message d'erreur, ne se rende compte de l'attaque.
  • Rend difficile vérifier si l'archive est chiffrée et si l’algorithme de chiffrement utilisé est ZipCrypto ou AES.
    • Le risque est qu'une personne se trompe et envoie un .zip non chiffré (même extension) et il n'est pas évident de vérifier quel algorithme a été utilisé (pour cela il faudrait déplacer la barre, ce que 90% des utilisateurs ne feront pas)

Par exemple, une archive ouverte avec 7-Zip donne par défaut :

Peu de personnes feront attention au deuxième fichier chiffré en ZipCrypto et au 3ème qui a été ajouté a posteriori par une personne ayant intercepté le message.



Dans la mesure où le logiciel n’émet aucune alerte, le destinataire ne peut savoir si ce fichier est légitime ou non et le considérera avec le même niveau de confiance que le reste.


Bien sûr il ne s’agit là que de quelques vulnérabilités orientées usage.

Conclusion
En conclusion, il est préférable d’utiliser des outils conçus dans le but d'effectuer des échanges sécurisés ; et de préférence conçus, implémentes et certifiés par des personnes compétentes.

Quelques exemples à coût zéro :
  • GPG, de préférence en mode hybride (pub/pric key) ça évitera que l'utilisateur ne chiffre le message avec un mot de passe faible, à défaut en symétrique avec option -c) ou Truecrypt certifiés CSPN par l’ANSSI
  • Dans certains cas où il n’est pas possible d’installer de logiciels sur le poste cible « Encryption Wizard » peut faire l’affaire (un jar) [EW].
    • À noter que ce produit n’a pas été validé par l’ANSSI, mais étant écrit en java, il serait facilement possible de "retrouver" le code source pour l'évaluer.
  • Une autre solution est l’usage d’un serveur d’échange, par exemple un OpenSSH correctement configuré (chrooté via internal-sftp + bonne configuration des algorithmes et protocoles) ; ou via une autre solution de VPN (et au pire chiffrement de la pièce jointe et envoi via le SharePoint Corporate over SSL, au moins cela complique le process d'interception)

  • L'idéal étant bien sûr l'usage de cartes à puce (et de préférence avec un pad externe), au moins l'utilisateur ne pourra ni envoyer le mot de passe ni son keyring GPG par mail (si si déjà vu). Cette solution est malheureusement plus coûteuse. Après se pose tous les problèmes inhérents aux cartes à puce et à l'IGC.

Bien sur il reste toujours le problème de la qualité du mot de passe (12 minimum, 18 de préférence, aléatoire ou passphrase) et l'erreur humaine, mais on atteint ici les limites inhérentes au logiciel et pour le reste « think OPSEC » ;).

Références