Cloud computing et sécurité Comparaison de sytèmes de chiffrement de données Rokhaya CISSE Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Copyright 20XX ACM X-XXXXX-XX-X/XX/XX...$15.00.
TABLE DES MATIÈRES 1 Introduction 2 principaux systèmes existant 2.1 Luks....................... 2.2 Système de chiffrement de volume...... 2.2.1 Encfs.................. 2.2.2 Ecryptfs................ 2.3 Installation et utilisation............ 2.3.1 Encfs.................. 2.3.2 Ecryptfs................. 3 Méthodes d expérimentation 3.1 Principe suivi................. 3.2 Plateforme locale............... 3.3 Plateforme disque périphérique........ 3.4 Plateforme distante : cloud.......... 4 Analyse comparative de système 4.1 Tests de performance.............. 4.2 Synthése..................... 5 Analyse de sécurité 5.1 Failles répertoriées............... 5.2 Fuites d informations [3]............ 6 Conclusion 7 Remerciements 8 References
1. INTRODUCTION Probléme et objectif. L ordinateur est devenu un élèment central de nos vies. Que l on soit jeune ou âgé, travailleur ou chômeur, on a souvent recours à internet, qui, au fil des années est devenu incontournable. Certains utilisent leur ordinateur comme espace de stockage pour leurs données personnelles et/ou professionnelles. D autres ayant besoin de plus d espace ou pour partager leurs données utilisent des supports de stockage externe : disque dur ; clef USB ; ou, via internet, des supports de stokage externalisés proposés par des founisseurs, que l on d ésigne par le terme cloud. Que nos données soient stockées sur une partition d un disque, une clef usb ou encore sur le cloud, elles sont exposées à des risques pouvant mettre en danger leur sécurité. Victimes de pannes aléatoires ou d attaques, elles peuvent être perdues totalement ou partiellement, modifiées ou corrompues, rendues publiques alors qu on voulait qu elles restent confidentielles. En considérant le pire cas qui est celui d attaques malicieuses, les solutions pour sécuriser les données sont basées sur la cryptographie et le codage : chiffrement des données stockées sur des supports externes pour garantir leur confidentialité et restreindre les accès ; signature et redondance pour leur intégrité. L objectif de ce projet est de comparer des systèmes existants pour le stockage de données sécurisées et de comparer leurs performances en terme de temps et de sécurité. Contexte de l étude. Ce projet se déroule à Inria dans le cadre d une collaboration entre les équipes Privatics et Moais et l entreprise Incas-ITsec qui consiste au développement d un module de sécurité en rupture (figure 1) qui propose des garanties de sécurité grâce au filtrage et au chiffrement systématique des communications entre la machine de l utilisateur (ordinateur ou téléphone) et le cloud. Figure 1 : Module en rupture développé par Inria et Incas-ITSec L étude présentée ici est motivée par l application de ce module à l externalisation de données privées sur le cloud. La solution étudiée est d offrir à l utilisateur une vue en clair de ses données, alors qu elles sont stockées de manière chiffrées sur internet. Le module en rupture prend en charge l authentification et les échanges de données ; les données sont stockées par un système de gestion de fichiers chiffrés qui permet d accéder à des zones de stockage chiffrées. Nous allons donc comparer plusieurs systèmes de fichiers chiffrés afin de déterminer le plus appropié. Principe des systèmes de fichiers chiffrés et critères de comparaison. Le chiffrement est un procédé cryptographique permettant de garantir la confidentialité des messages transmis. Les sytèmes de fichiers chiffrés (on dit aussi dans la suite système de chiffrement, sous entendu pour stockage de données) utilisent des algorithmes de chiffrement, mis à disposition des utilisateurs afin de leur permettre de protéger leur données. Il existe des systèmes de chiffrement permettant de chiffrer l ensemble d un disque dur entier (full disk encryption) ou juste une partie (chiffrement de volume). Ces systèmes fonctionnent comme des coffres que l on peut ouvrir ou fermer pour en autoriser l accès ou pas.i ls offrent une vue des données en clair à l utilisateur lorsque ce dernier fournit son mot de passe ( passphrase ou clef), on dit alors que le dossier chiffré a été monté. Pour comparer ces systèmes nous avons choisi les critéres d analyse suivants : Facilité d utilisation ; Performances (surcoût d accès, temps de calcul) ; Sécurité. L organisation de ce document est la suivante. Les principaux systèmes étudiés (Luks, Enfs et Ecryptfs) sont d abord introduits ( 2). Puis nous décrivons ( 3) la méthodologie suivie pour l expérimentation et les mesures de performance. Les résultats expérimentaux et leur analyse sont ensuite présentés (??). Enfin, l analyse de sécurité ( 5.1) puios la conclusion terminent l article. 2. PRINCIPAUX SYSTÈMES EXISTANT 2.1 Luks
Luks est un système chiffré de disque entier (full disk encryption). Il travaille sur un container (disque ou partition d un disque) et agit au niveau du noyau.luks Luks est basé sur le module dm-crypt et permet de chiffrer le home directory ou le swap d une distribution linux. Il offre la possibilité d avoir un trousseau de clef, ce qui permet à différents utilisateurs d avoir accès aux mêmes données sans avoir la même clef et de révoquer un utilisateur sans avoir à rechiffrer toutes les données. 2.2 Système de chiffrement de volume 2.2.1 Encfs Encfs est un système de chiffrement permettant de chiffrer le contenu d un volume. Il travaille sur deux répertoires, celui contenant les données chiffrées et un autre permettant à l utilisateur d avoir une vue des données en clair. Dans la suite nous appellons coffre le répertoire chiffré et coffre ouvert le répertoire contenant les données en clair. Chaque fichier dans coffre ouvert correspond à un fichier chiffré dans coffre. Les répertoires coffre et coffre ouvert sont montés/démontés à la demande de l utilisateur. Le montage nécessite le mot de passe défini par l utilisateur à la création des répertoires mais le démontage se fait sans l utilisation du mot de passe. Lorsque les répertoires sont montés l utilisateur a accés à tous ses fichiers en clair dans coffre ouvert. Lorsqu on modifie un fichier dans coffre ouvert le fichier est chiffré en même temps et les modifications sont ainsi prises en compte dans coffre. Le mot de passe défini par l utilisateur à la création des répertoires est utilisé pour crypter la clef générée aléatoirement qui doit servir à chiffrer les données. La clef permettant de chiffrer les données est contenue, cryptée (avec PBKDF2), dans le fichier encfs6.xml dans le répertoire chiffré. La paire mot de passe et encfs6.xml est donc indispensable pour chiffrer et déchiffrer les données. 1. Chiffrement utilisé par ENCFS Encfs utilise un chiffrement symétrique pour chiffrer les fichiers. Il propose au choix AES et blowfish. Tous les deux sont disponibles avec des tailles de blocs allant de 64 à 4096 octets (avec un pas de 16) et la taille des clefs varie entre 128 et 256 (pas de 64) pour AES. Lecture. A chaque fois qu un octet doit être lu, tout le bloc correspondant est déchiffré. Ecriture. A chaque fois qu un octet doit être écrit, tout le bloc correspondant est déchiffré, l octet est écrit puis on chiffre encore tout le bloc. 2. Information sur l arborescence des fichiers. Comme expliqué ci dessus, encfs garde la même arborescence pour les fichiers et répertoires. N importe qui ayant accés au répertoire chiffré peut connaître l arborescence du répertoire en clair. 3. Information sur les tailles de fichier. Les fichiers ont quasiment la même taille que dans le répertoire clair. En effet on n observe qu un surplus de 8 octets par rapport à la taille du fichier de base, dû au vecteur d initialisation choisi aléatoirement pour chaque fichier (option que l on peut désactiver). 2.2.2 Ecryptfs Ecryptfs est un système de fichiers chiffré similaire à Encfs. Ecryptfs permet de chiffrer le contenu de répertoires et travaille au niveau du noyau ce qui le rend plus rapide que Encfs qui est un module de FUSE (Filesystem in userspace). 2.3 Installation et utilisation 2.3.1 Encfs Pour installer encfs il suffit de faire la commande sudo apt-get install encfs pour les versions récentes d ubuntu (à partir de ubuntu 13.10). Pour les autres versions les étapes à suivre sont expliqués ici [7]. Nous pouvons ensuite créer une paire de répertoire chiffré/clair que nous appelons coffre et coffre ouvert en faisant encfs coffre coffre ouvert. A noter que encfs ne travaille qu avec des chemins absolus pour les noms des répertoires. Exemple : encfs /home/coffre /home/coffre ouvert Il est alors demandé de choisir certains paramétres pour la configuration du système de chiffrement. La configuration par défaut est le mode paranoic (cf[7]) et c est celle qui a été utilisée pour cette étude ; un mode expert permet de spécialiser la ocnfiguration. Ainis, le mode expert permet de choisir la méthode de chiffrement qui sera utilisée (AES ou blowfish), la taille de la clef, la taille des blocs, de demander aussu le chiffrement des nom des fichiers ; de nombreuses autres options peuvent être activées. Une fois les répertoires créés, il est possible de monter le répertoire chiffré sur le répertoire clair avec la même commande que pour la création : encfs /home/coffre /home/coffre ouvert. Le mot de passe esta demandé et on a ainsi accès aux données en clair dans coffre ouvert. Pour les démonter, et donc ne plus avoir les données en clair dans coffre ouvert, il faudra faire fusermount -u /home/coffre ouv 2.3.2 Ecryptfs Ecryptfs est comme Encfs un système de fichiers chiffrés qui travaille sur deux répertoires (partition,clef,...). L installation se fait avec la commande : sudo apt-get install ecryptfs-utils. En reprenant les mêmes notations pour les noms des répertoires la création d une paire de répertoire se fait avec : sudo mount -t ecryptfs coffre coffre ouvert. Contrairement à Encfs, cryptfs marche avec des chemins relatifs pour l emplacement des répertoires et ne s utilise par défaut qu avec des droits d accès privilégiés (root) 1. Il est d abord demandé de définir un mot de passe puis de choisir la méthode chiffrement (AES, blowfish, cast6...), la taille de la clef de chiffrement (128,192 ou 256 pour AES), de dire si l écriture de fichiers en clair est autorisée dans le répertoire chiffré et le nom des fichiers doit ou non ête chiffré aussi. 3. MÉTHODES D EXPÉRIMENTATION Les mesures sont basées sur l écriture de données en clair dans dans le répertoire chiffrer avec la fonction fprintf. Pour cela, un programme creation fichiers permettant de générer des fichiers aléatoires d une taille donnée a été uti- 1. Même si ecryptfs s utilise par défaut en root vous pouvez changer cela par la suite en suivant les indications sur ce tutoriel [2].
lisé. Les performances sont mesurées avec la fonction gettimeofday pour les mesures de temps. La machine personelle utilisée pour les tests est une machine 4 coeurs avec 4G de RAM et 500G d espace disque. La machine est sous ubuntu 14.04LTS. Les tests ont été faits avec les configurations suivantes pour les systèmes de fichiers chiffrés : Encfs Ecryptfs Chiffrement AES AES Taille de la clef 256 256 Noms des fichiers chiffrés chiffrés Taille des blocs 1024 128 (imposé) On pourra mettre nos données sur /home/username/clair qui seront ensuite cryptées et sauvegardées dans /home/username/dropbox/chiffre qui est un répertoire synchronisé (donc dropbox s occupera de la synchronisation). Cette solution conviendrait à des personnes, pour qui, avoir leur données en local (synchronisation) ne pose pas de problèmes. A noter qu avec Dropbox on peut choisir les répertoires à synchroniser ; on ne peut donc synchroniser que le répertoire chiffré /home/username/dropbox/chiffre qui contient peut-être des données sensibles, si l on veut pas avoir tout le contenu de son cloud en local. 3.1 Principe suivi 1. Stockage distant via le réseau Les tests effectués sur le cloud ont été réalisés pour étudier la faisabilité d une telle combinaison (chiffrement/écriture sur le cloud) et avoir une idée de l impact sur le temps en upload/download. Cependant, ces expériemntations à distance via internet sur dropbox ne sont pas reproductibles et nous ne présentons pas les érsultats ici. 2. Stockage local Les tests en local ont été faits pour mesurer le surcoût arithmétique entrainé par l utilisation du chiffrement en local. 3. Stockage sur un périphérique Les tests sur clef usb ont été réalisés pour mesurer le surcoût système entrainé par l utilisation du chiffrement sur un périphérique. 3.2 Plateforme locale Pour évaluer le coût du chiffrement, les tests, dont les résultats sont présentés ci après, ont été effectués sur la machine personnelle présentée ci dessus. On crée une paire de répertoire encfs (ou ecryptfs) (clair et chiffré) dans $Home et on crée en même temps un répertoire quelconque dans $Home, qu on appelera reptest. On utilise le programme, creation fichiers, pour créer les mêmes fichiers dans reptest et dans clair. Comme encfs (ecryptfs) chiffre à la volée, on obtient le coût du chiffrement en faisant la différence du temps mis pour écrire dans clair avec le temps mis pour écrire dans reptest. 3.3 Plateforme disque périphérique Le même programme présenté ci dessus a été utilisé pour générer des fichiers dans le répertoire $Home de l ordinateur et dans un répertoire dont le contenu est stocké chiffré sur la clef. Ceci a été fait pour savoir si le fait de stocker les données chiffrées sur un périphérique entrainait un surcoût comparé au chiffrement en local. 3.4 Plateforme distante : cloud Pour effectuer les tests sur le cloud, il faut un outil permettant décrire sur le web. Deux solutions sont possibles : La première, plus simple, serait d utiliser un cloud avec une option de synchronisation des données comme dropbox. Dans ce cas il suffit juste de mettre notre répertoire chiffré dans le dossier synchronisé de dropbox pour que nos données soient ainsi sauvegardées illisibles sur le cloud. Exemple avec encfs : encfs /home/username/dropbox/chiffre /home/username/clair La deuxième solution serait d éviter la duplication des données en local, donc de ne pas avoir recours à la synchronisation mais plûtot à un outil permettant de lire/écrire sur le web, webdav. Webdav fonctionne par montage/démontage comme encfs et ecryptfs. Nous pouvons donc grâce à ce dernier, demander à monter notre cloud en local pour pouvoir travailler dessus. A la différence de la synchronisation, le montage nous donne une vue de nos données stockées sur le cloud, on peut ainsi manipuler les données sans que celles ci soient stockées en local. Sous ubuntu nous pouvons utiliser webdav grâce à davfs2 dont le processus d installation est expliqué sur ce site [6]. A noter cependant que webdav lors d une écriture, écrit d abord sur le cache avant de procéder à l écriture sur le web, ce qui le rend assez lent. Ces deux solutions permettent de sécuriser ses données avant l envoie sur le cloud. Le chiffrement se fait sur l ordinateur de l utilisateur, ce qui peut être problématique. On peut utiliser le module de sécurité en rupture afin de centraliser le chiffrement. Déléguer cette tâche au module permet de n avoir les données clair/chiffré et les informations de chiffrement que sur ce dernier. L utilisateur n aura que les données en clair quand il communique avec le module et le cloud n aura que les données chiffrées. En effet avec cette solution, même si un attaquant a accés à l ordinateur d un des utilisateurs (pendant que les données sont montées), il n aura que les données en clair présentes à cet instant sur cet ordinateur. L attaquant n aura pas accés aux données chiffrées correspondantes ni aux informations de chiffrement (clef de chiffrement...) qui ne sont que sur le module. 4. ANALYSE COMPARATIVE DE SYSTÈME 4.1 Tests de performance 1. En local
On présente ci dessous les résultats des tests effectués sur la plateforme locale en utilisant les différents sytèmes de fichiers chiffrés. temps en s 0 2 4 6 8 10 12 14 Répertoire pas chiffré vs répertoire chiffré avec encfs en local max encfs moy encfs min encfs max répertoire non chiffré moy répertoire non chiffré min répertoire non chiffré 0 50 100 150 200 On en déduit alors la valeur approximative de T arith et la courbe représentative de sa valeur est présentée ci dessous : coût du chiffrement en s/mo 0.5 0.4 0.3 0.2 0.1 0.0 T arith = (C usb i ρ i C DD i) (t i (1 ρ i )) coût approximatif du chiffrement temps en s 0 2 4 6 8 10 12 Répertoire pas chiffré vs répertoire chiffré avec ecryptfs max ecryptfs moy ecryptfs min ecryptfs max répertoire non chiffré moy répertoire non chiffré min répertoire non chiffré 0 50 100 150 200 250 2. Périphérique : Clef USB temps en s 0 5 10 15 20 Répertoire pas chiffré vs répertoire chiffré avec encfs sur clef usb max encfs moy encfs min encfs max répertoire non chiffré moy répertoire non chiffré min répertoire non chiffré 50 100 150 Sur cette courbe (générée avec les mesures sur encfs), on remarque que la valeur approchée du coût de chiffrement calculée par cette méthode est toujours négative (elle augmente avec la taille des fichiers). T usb i et T DD i ne sont donc pas une bonne approximation du temps d écriture sans chiffrement. Il faudrait donc trouver un autre moyen de calculer le coût du chiffrement. On peut essayer de faire simplement la différence des temps (C ji T ji) t i avec (j {usb, DD}) pour avoir une idée du coût en local et sur clef. coût du chiffrement en s/mo 0.05 0.10 0.15 0.20 0.25 0.30 0.35 coût sur usb coût en local coût en local vs coût sur clef usb 50 100 150 0 50 100 150 4.2 Synthése A l issue des tests effectués nous avons donc pu comparer le temps mis pour écrire dans un répertoire de l ordinateur avec ou sans chiffrement et le temps mis pour faire la même chose sur une clef usb. Nous avons exploité ces résultats pour calculer le coût arithmétique du chiffrement noté T arith. On note C usb i le temps d écriture avec chiffrement sur clef C DDi le temps d écriture avec chiffrement en local, T usb i le temps d écriture sans chiffrement sur la clef et T DD i le temps d écriture sans chiffrement en local. t i est la taille du fichier i et on pose ρ i = T usb i T DD i. On a les relations suivantes : C usb i = t i T arith + T usb i C DD i = t i T arith + T DD i 5. ANALYSE DE SÉCURITÉ 5.1 Failles répertoriées Parmi les faiblesses en sécurité qui sont référencées dans les analyses [5] [4] sur Encfs et Ecryptfs figurent : Encfs. 1. Taille des fichiers Encfs garde la même arborescence de fichiers dans le répertoire clair que dans le répertoire chiffré même si les noms des fichiers sont chiffrés. On connait le nombre de fichiers et leur taille dans le répertoire clair à partir du répertoire chiffré. 2. Remplissage du dernier bloc par des zéros Pour chiffrer les données encfs utilise un système de chiffrement par bloc (AES ou blowfish) en mode CFB.
Soit P n le n-ième bloc clair et C n le nième bloc chiffré ; alors C n = clef(c n 1) P n, avec comme notation clef(i)= résulat obtenu en appliquant la clef de chiffrement à i. Si P n est le dernier bloc et n est pas totalement rempli, le bloc est complété par k zéros pour atteindre la taille d un bloc.. Ceci permet donc à un attaquant de récupérer les k derniers bits de clef(c n 1 ) et de faire une attaque clair/chiffré, pour trouver la clef, comme il connait aussi tous les bits de C n 1. Dans l exemple ci dessus on connaitra ainsi les 2 derniers bits de clef(c 3 ) (parce qu on fait un xor avec 00 ) et les 4 bits de C3 (vu que le texte chiffré n est pas secret). Pour pallier à ce probléme, nous pouvons choisir une grande taille pour la clef (AES 256) pour augmenter le nombre de clefs possibles et résister aux attaques clair-chiffré. 3. Vecteur d initialisation commun Pour configurer encfs parmi les nombreux paramètres à définir il y a celui concernant le vecteur d initialisation. Si on choisit d utiliser le même vecteur d initialisation pour tous les fichiers, cela engendre des failles de sécurité. En effet dans ce cas, en faisant le xor de deux fichiers chiffrés nous récupèrons le résultat du xor entre les deux fichiers clairs correspondants. Encfs propose de générer aléatoirement un vecteur d initialisation différent pour chaque fichier. Cette option est activé pour le mode paranoic et normal. Pour le mode expert, il faudra bien sûr penser à l activer(option :Perfile IV initialization vector) pour éviter d éventuelles fuites d informations. 5.2 Fuites d informations [3] A ces faiblesses répertoriées, pour les deux systèmes chiffrés, on peut rajouter le fait qu un fichier en clair correspond toujours au même chiffré. Ceci permet à un attaquant de savoir la fréquence d accés à un fichier. Pour éviter cela, une solution un peu coûteuse est de stocker les fichiers chiffrés sur deux supports de stockage qui ne sont pas en collisions (ne communiquent pas). On peut imaginer prendre google drive et dropbox pour le cas d application de stockage sur le cloud. On considére avoir n fichiers F1..Fn stockés chiffrés sur les deux clouds (A et B), et on veut accéder au fichier i. Soit S={1..n}. On effectue les opérations suivantes pour récupérer Fi : On tire au hasard S A S Si i S A on pose S B = S A \ {i} Sinon on pose S B = S A {i} On demande S A à A et on pose r A = On demande S B à B et on pose r B = on récupére F i en faisant F i = r A r B j S A F j j S B F j 6. CONCLUSION En somme, nous pouvons dire que l approche choisie pour déterminer le coût effectif du chiffrement n était pas assez précise.il faudrait faire plus de mesures sur plus de supports et tenir compte du système de fichier du support (inode,superblock...). Pour la sécurité même si encfs a plus de failles répertoriées que ecryptfs [5] [4], ces failles pour encfs sont pour la plupart résolvables en activant une option ou ne compromette pas vraiment l intégrité des fichiers. Encfs est plus facile à prendre en main pour un utilisateur lambda, le mode paranoia (voir man encfs, les options sont bien expliquées ) offre à l utilisateur assez de sécurité en lui choissant une taille de clef assez grande et en activant l option Message Authentication Code block headers (permet de savoir si le fichier chiffré a été corrompu) entre autres. Il y a moins d options avec Ecryptfs et il n y a pas de vérification du passphrase à la création du paire de répertoire avec ecryptfs. On peut donc se tromper sur la passphrase à la création, ne pas s en rendre compte et donc ne pas avoir le bon passphrase pour récupérer nos données. Une fois la configuration terminée, à chaque fois qu on veut monter notre répertoire on doit par défaut donner en ligne de commande tous les paramétres qu on avait choisi lors de la configuration même si on peut l automatiser ([2] section montage). Ecryptfs est beaucoup plus rapide que encfs comme il agit au niveau du noyau mais plus difficile à prendre en main. On peut trouver un tableau de comparaison des différents systèmes présentés ici [1] (section Comparison table ). 7. REMERCIEMENTS Je voudrais remercier mon encadrant principal M. Jean Louis ROCH pour ses conseils d expert sur la sécurité, ainsi que mon co-tuteur M. Levent DEMIR pour sa disponiblité et son aide à la compréhension des systèmes de fichiers chiffrés et mon troisième encadrant, M. Amrit KUMAR pour m avoir initiée aux problèmes de retrait d informations. 8. REFERENCES [1] archlinux. Disk encryption. https: //wiki.archlinux.org/index.php/disk_encryption. [2] ArchLinux. Encryption avec ecryptfs. https: //wiki.archlinux.fr/encryption_avec_ecryptfs. [3] R. Curtmola, J. Garay, S. Kamara, and R. Ostrovsky. Searchable symmetric encryption :improved definitions and efficient constructions. https://eprint.iacr.org/2006/210.pdf, 2006. [4] Defuse. audit Ecryptfs. https://defuse.ca/audits/ecryptfs.htm. [5] Defuse. audit Encfs. https://defuse.ca/audits/encfs.htm. [6] C. francophone d utilisateurs d Ubuntu. davfs2. http://doc.ubuntu-fr.org/davfs2.
[7] C. francophone d utilisateurs d Ubuntu. Encfs. http://doc.ubuntu-fr.org/encfs.