Bonjour… nal (allez quoi, la tradition).
Je fais un petit journal qui fait écho à celui paru en début de mois et qui annonçait TrueCrypt « relativement sûr ».
Suite aux annonces de 2014 concernant ce dernier, j'avais migré mes backups vers un volume Encfs, au travers de la bien sympathique application Gnome Encfs. Bref ce soir je met à jour ma Ubuntu et paf :
According to a security audit by Taylor Hornby (Defuse Security), the current implementation of Encfs is vulnerable or potentially vulnerable to multiple types of attacks. For example, an attacker with read/write access to encrypted data might lower the decryption complexity for subsequently encrypted data without this being noticed by a legitimate user, or might use timing analysis to deduce information.
Until these issues are resolved, encfs should not be considered a safe home for sensitive data in scenarios where such attacks are possible.
Quelle est la gravité de cette annonce ? Avez vous des infos ? Quel degré de confiance faut-il accorder à nos outils de chiffrement ?
# faut deja un acces aux données
Posté par NeoX . Évalué à -5.
faut deja que la machine soit compromise pour que encfs perde de son interet.
[^] # Re: faut deja un acces aux données
Posté par hervé Couvelard . Évalué à 10.
euh…. je pense que celui qui est capable pour que encfs perde de l'intérêt aura peu de mal à compromettre la machine. On se sert de ce genre de logiciel pour sauvegarder la confidentialité des données LORSQUE la machine est compromise.
Mais je suis peut être à coté de la plaque.
[^] # Re: faut deja un acces aux données
Posté par SChauveau . Évalué à 6.
Il y a compromis et compromis.
Si la machine est compromise alors que EncFS est est cours de fonctionnement alors les données ne sont évidemment pas protégées puisque l'attaquant pourra se faire passer pour toi et accéder à tes fichiers.
Si la machine se fait voler et que l'attaquant n'a accès qu'aux données présentes sur le disque dur alors tout va bien.
Par contre, ce qui semble être décrit ici est que si l'attaquant a accès aux fichiers chiffrés et est capable de les modifier alors il pourra baisser la sécurité des accès ultérieurs.
On peut imaginer le scénario suivant.
A utilise EncFS pour chiffrer des données sur une clef USB.
B parvient à dérober la clef USB dans la poche de A.
B ne peut pas déchiffrer le contenu de la clef mais il peut baisser le niveau de sécurité de EncFS.
B remet la clef USB dans la poche de A.
A utilise EncFS sur sa clef USB et met a jour certains fichiers.
B dérobe de nouveau la clef USB et peut alors facilement déchiffrer les nouveaux fichiers crées par A.
[^] # Re: faut deja un acces aux données
Posté par NeoX . Évalué à 4.
ca suppose quand meme de se faire voler la clef USB 2x…
bon, par contre dans le cas d'un serveur partagé, ou il y a des données EncFS, en effet, on peut se poser la question.
[^] # Re: faut deja un acces aux données
Posté par SChauveau . Évalué à 4.
Malheureusement, les personnes ayant une réelle motivation pour subtiliser votre clef USB sont généralement des proches (famille, collègue, …) ayant un accès relativement facile à la-dite clef.
Il faudrait voir les détails de l'attaque permettant de réduire le niveau de sécurité mais je suppose qu'il s'agit de modifier le fichier de configuration '.encfs.xml' présent à la racine du dossier chiffré. Si c'est le cas, une simple vérification du hash de ce fichier pourrait suffire à détecter un problème. On pourrait aussi faire en sorte que ce fichier ne soit pas stocké sur la clef ou qu'il soit lui même chiffré.
[^] # Re: faut deja un acces aux données
Posté par Vincent14 (site web personnel) . Évalué à 5.
En lisant vos réponses, j'avais envie d'ajouter que ce n'est pas à l'utilisateur de bonne foi de décider comment il se fera attaquer, et que d'une façon ou d'une autre le scénario qui arrivera nous semblera si improbable qu'il sera bien trop tard pour accepter de ne pas avoir su envisager tous les cas possibles.
Que quelqu'un subtilise quelques temps le support de stockage pour l'altérer avant de le remettre à sa place me semble hautement probable, dans la mesure ou on a tendance à utiliser un support unique pour ce rôle et à ne le sortir qu'une fois tous les X jours : le reste du temps il est chez moi sans surveillance. Un divorce, une litige professionnel, quelqu'un qui veut vous nuire pour X raison, l'attaquant saura toujours où et quand travailler pour extraire vos documents, indépendamment de son niveau de compétence (tout est expliqué sur le net, c'est qu'une question de patience).
Dans la mesure où Encfs part quand même du principe qu'il faut monter le volume pour travailler dans l'espace chiffré, le cas d'une machine dont l'OS est corrompu me semble déjà le cas standard, c'est pour cela que l'avertissement que j'ai reçu me semble alerter sur autre chose, comme par exemple ce qu'on évoque dans ce fil, ça me semble cohérent :)
[^] # Re: faut deja un acces aux données
Posté par Misc (site web personnel) . Évalué à 5.
<sarcasme>
Quoi, des exemples réalistes de choses qui arrivent au lieu de ressortir la NSA comme épouvantail passe partout, mais ou va le monde ?</sarcasme>
[^] # Re: faut deja un acces aux données
Posté par jihele . Évalué à 2.
<blague potache>Dans ton cul.</blague potache>
[^] # Re: faut deja un acces aux données
Posté par SChauveau . Évalué à 3.
Pour la plupart des cas d'utilisations classiques où EncFS ne sert qu'a protéger des données en cas de vol de la machine, il me semble en effet qu'il n'y a pas de problèmes.
Par contre il faudra y regarder de plus près si tout ou une partie des fichiers chiffrés est accessible publiquement ou est stockée sur un serveur peu sécurisé (un serveur web mutualisé par exemple). Il faudrait voir ce que signifie exactement "read/write access to encrypted data". Est ce la partie chiffrée ou la partie en clair?
[^] # Re: faut deja un acces aux données
Posté par Jiehong (site web personnel) . Évalué à 5.
Dans le rapport, c'est l'accès aux données lorsqu'elles sont chiffrées…
# L'étude en elle même
Posté par Jiehong (site web personnel) . Évalué à 9.
Voici l'audit en question.
On y apprend que quelques problèmes de sécurités précédemment connus n'ont pas été corrigés, ou que la correction n'a pas réglé le problème.
Je pense que la conclusion est claire, et j'en traduit 2 passages ici :
[^] # Re: L'étude en elle même
Posté par Vincent14 (site web personnel) . Évalué à 2. Dernière modification le 26 avril 2015 à 12:39.
Merci pour ta contribution, à la lumière de ces nouvelles infos, est-ce que TrueCrypt représenterait une meilleure solution ? Ou est-ce qu'il existe des alternatives (dont le niveau de confiance sera à déterminer dans un second temps) dont l'user-story est similaire ?
[^] # Re: L'étude en elle même
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 7.
Comme tu peux voir, l'audit n'est pas tout récent, le problème est connu depuis déjà plus d'un an (et même avant).
eCryptFS semble mieux loti : https://defuse.ca/audits/ecryptfs.htm
Sinon pour les alternatives, dm-crypt/LUKS commence à avoir une solide réputation.
Je t'invite à regarder l'excellent tableau de l'excellent wiki d'Arch: https://wiki.archlinux.org/index.php/Disk_encryption#Comparison_table
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: L'étude en elle même
Posté par Jiehong (site web personnel) . Évalué à 4.
En outre, ces audits de sécurité étaient de 10 heures chacun, ce qui n'est pas énorme non plus. Si en peu de temps de gros bogues sont découverts, il y a fort à parier qu'il y en a beaucoup d'autres.
TrueCrypt a fait l'objet d'un audit de sécurité plus important, et il en est ressorti pas si mal que ça.
crypsetup (dmcrypt) avec LUKS gère également les volumes TrueCrypt, ce qui est pas mal.
Si c'est simplement pour tes backups, une partition dm-crypt/LUKS sera montée automatiquement comme le serait une partition normal d'un disque dur externe, et ça te permet d'utiliser le système de fichier que tu souhaites. Mais n'hésites-pas à regarder les tableaux du lien d'Archlinux donné précédemment, car ça peut te donner des idées.
[^] # Re: L'étude en elle même
Posté par Xavier G. . Évalué à 2.
Apparemment, la mise à jour de EncFS en version 1.8 va corriger une partie des vulnérabilités identifiées par l'audit.
# [FUD] Le FS sous-jacent est probablement pire donc...
Posté par un_brice (site web personnel) . Évalué à 1. Dernière modification le 26 avril 2015 à 16:53.
Je suis pas très convaincu. Au final j'ai pas l'impression que le système de cryptage empilé sur le système de fichier sera le maillon le plus faible. Si tu veux mitiger les risques associés à l'usage d'un matériel modifié par une personne arbitrairement qualifiée il te faut une chaîne de confiance… potentiellement jusqu'au niveau des microgiciels pour BadUSB.
Autres vecteur potentiels: une partition avec un FS kivabien et l'automount (dernière fois que j'en ai entendu parler, HFS+ a mis 3 ans à corriger une faille), un binaire SUID, un .desktop aux petits oignons… Ou même juste un récepteur de clavier logitech dans le boitier, s'il est suffisamment grand.
Bref en étant parano accès physique sans DRM -> game over. En étant plus réaliste j'imagine que les adversaires que tu affrontes seraient suffisamment déroutés par bien moins que de la crypto ;-)
Personnellement j'utilise le chiffrement matériel intégré à mon SSD. Aucun coût en performances, simple à mettre en œuvre, une sécurité modérée mais suffisante par rapport à ce que j'imagine être mes attaquants.
[^] # Re: [FUD] Le FS sous-jacent est probablement pire donc...
Posté par Jiehong (site web personnel) . Évalué à 7.
Tu parles d'une chaîne de confiance, pour finalement faire confiance en l'implémentation du chiffrement intégrée à ton SSD.
Il me semble que cette implémentation n'est :
Quant aux coûts en termes de performances, je viens de lancer un
cryptsetup --benchmark, et je suis à 2400 MiB/s en chiffrement et déchiffrement avecaes-xts/256 bits. Mon SSD ne dépasse pas les 700 MiB/s, c'est donc le facteur limitant. Après, je ne connais pas à ta machine, mais elle me semble vraiment très puissante !De toutes façons, il parlait de partitions chiffrées par ses sauvegardes, ce qui est sûrement sur un module externe, qui n'est pas si rapide il me semble.
# Les fichiers chiffrés et le cloud
Posté par lgmdmdlsr . Évalué à 3.
Si j'ai bien compris, un tiers ayant accès à deux enregistrement successifs d'un fichier pourra le décoder, donc, si je ne m'abuse, tous les répertoires chiffrés avec encfs et synchronisés dans la brume (Dropbox ou autres) deviennent complètement lisibles sans problème par nos amis de la NSA …
(oui, je sais, on ne met pas d'info que ne doit pas lire la NSA "dans les nuages")
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.