Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]

---

S'abonner au fil RSS global de la revue de presse

---

Présentation : Un lecteur du blog m'a fait suivre un message de la mailing list dm-crypt http permalink.gmane.org gmane.linux.kernel.device-mapper.dm-crypt 5543. L'auteur, Samulis Leopold propose un module noyau et les outils associés proposant un nouveau mode de chiffrement. Ce projet s'appelle DM-steg et la documentation est disponible. Les sources sont composées d'un patch noyau pour le 3.2 et des outils. 1 Quels sont les points positifs de DM-steg Tout d'abord, les performances de DM-steg ont été mesurées en regard d'un RAM disk, et elles sont honorables partie 6 Benchmarks du .pdf de doc . Je ne m'étendrai pas sur les différents modes de chiffrements. L'auteur s'est basé sur de l'existant un openssl récent 1.1 doit être utilisé pour pouvoir compiler le projet . Le point clé du projet réside dans la mobilité des données sur le disque. Le disque est tout d'abord découpé en parties équivalentes, les blocs. Deux blocs vont jouer un rôle particulier. La taille totale de l'espace est amputée de deux blocs le premier sert d'en-tête, le second de zone temporaire.Au cours de l'emploi du disque, les données des blocs vont être déplacées sur l'ensemble de l'espace du disque de manière aléatoire. Le bloc temporaire sert à stocker les données pendant le déplacement. Ainsi, un attaquant qui n'aurait accès qu'a la version chiffrée du disque verrait des réécritures sur tout le disque, ne pouvant ainsi absolument rien déduire sur l'usage de ce disque. Et puis l'auteur indique no crash ce qui est rassurant - Et DM-steg est particulièrement intéressant car il propose par défaut de la plausible deniability. J'ai déjà blogué sur la plausible deniability faite par truecrypt pour en conclure que la méthode n'est pas satisfaisante. Petit résumé Pour truecrypt le disque caché est situé vers la fin du disque. Un attaquant en possession de plusieurs versions du disque au cours du temps et qui verrait des données être modifiées à cet endroit alors qu'elles ne correspondent à aucun fichier sur le disque normal pourrait donc vraisemblablement intuiter qu'un disque caché est présent. 2 La plausible deniability par DM-steg Etudions la partie deniable plausability. Tout d'abord, sur la possession de ce programme, ensuite sur les containers imbriqués, et enfin sur les attaques réalisables par un attaquant. La possession de ce programme est sans doute un piège en soi. Si je suis un attaquant et que je vois un utilisateur avec DM-steg, je vais immédiatement le soupçonner de cacher des données. On peut considérer cela comme un faux problème puisque le jour ou DM-steg sera inclus dans les sources officielles du noyau linux et dans les distributions linux sa possession ne sera plus compromettante. DM-steg permet d'utiliser un disque avec plusieurs mots de passes. Chaque mot de passe donne accès à une vue différente du code déchiffré. Il est possible d'avoir donc un nombre illimité de conteneur cachés si ce n'est la taille du disque , au contraire de Truecrypt qui ne propose qu'un disque normal contenant un disque caché. Après discussion avec l'auteur par mail, il m'indique qu'il préfère la méthode de conteneur imbriqué sans limite. Les arguments sont inversibles avec ceux de Truecrypt. Truecrypt dit qu'en cas de gros problème, il est toujours possible de donner les deux mots de passe, prouvant donc que plus rien n'est caché si on vous tape dessus pour obtenir les mots de passe, cela peut être la solution la moins pire , et DM-steg dit précisément l'inverse, que l'attaquant arrêtera forcément au 'n-ième' mot de passe, à vous de cacher la donnée dans un conteneur n 1. Je n'ai pas d'avis tranché à ce sujet. Le mode de dispersion des données de DM-steg empêche un attaquant de différencier plusieurs versions du disque pour détecter quels sont les octets qui bougent, et si le cas échéant des octets vers la fin du disque bougent sans lien avec les données présentes. Il semble donc que c'est un excellent moyen pour faire de la plausible deniability. Mais il y a encore deux points qui ne sont pas réglés Les données sont éparpillées sur le disque mettons dev sda1 . Donc un attaquant avec plusieurs copies de dev sda1 n'a aucune information. Mais la plausible deniability dit que l'attaquant peut posséder le mot de passe du container principal. Et donc l'attaquant peut monter les disques avec DM-steg. Et il aura accès aux données sous dev mapper steg1. Et là, les données deviennent linéarisées et non plus éparpillées . L'attaquant peut donc étudier les modifications entre deux versions de dev mapper steg1 et ainsi détecter des modifications illégitimes de manire analogue avec l'attaque sur truecrypt. Aucune limitation sur le filesystem employé n'est faite. Ainsi, si un utilisateur crée un container principal formaté en ext3 et un container caché sur les 100 derniers Mo du disque, alors un attaquant à l'aide du mot de passe du premier container pourra consulter tous les superblocks d'ext3 sur le container principal. Les superblocks des 100 derniers Mo seront illisibles puisqu'écrasés par le container caché. Une fois de plus sa présence est révélée. On peut utiliser du FAT, mais l'emploi de FAT dans une distribution linux est suspicieux en soi. Or donc la plausible deniability n'est pas garantie. 3 One more step to infinity Le fait d'éparpiller les données chiffrées sur le disque est donc un premier pas très intéressant. Un attaquant a donc l'obligation impérative d'avoir le premier mot de passe pour attaquer la plausible deniability, ce qui n'était pas le cas auparavant. Nous avons aujourd'hui de plus en plus de disques SSD ou la localisation des données n'a plus aucune importance en terme de performances. L'usage de DM-steg pourrait donc rivaliser avec dm-crypt. Néanmoins, on cherche encore une vraie méthode de plausible deniability pérenne et fiable dans le temps.

Les mots clés de la revue de presse pour cet article : linux
Les videos sur SecuObs pour les mots clés : linux
Les mots clés pour les articles publiés sur SecuObs : linux
Les éléments de la revue Twitter pour les mots clé : linux





Les derniers articles du site "Exploitability" :

- Conférences, Livre Blanc, et autre info
- Bonjour, ton site semble avoir un problème
- 300 Gigabits par seconde, c'est beaucoup pour un DDOS
- TCP IP security is boring Second strike
- Des cookies bien chauds et bien nombreux
- APT High-tech ou Low-tech
- Faisons le Nostradamus
- Et bonne année
- Linux magazine décembre - mysql administration
- Manipulons un peu cryptsetup sans cryptsetup

---

S'abonner au fil RSS global de la revue de presse

---