Cloud computing et sécurité Comparaison de sytèmes de chiffrement de données Rokhaya CIE 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 DE MATIÈRE 1 Introduction 2 Principaux systèmes existants 2.1 Luks....................... 2.2 ystè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.......... 3.4.1 Dossier synchronisé : dropbox..... 3.4.2 Accès par cache : webdav....... 4 Analyse comparative de système 4.1 Tests de performance.............. 4.2 ynthèse..................... 5 Analyse de sécurité 5.1 Failles répertoriées............... 5.2 Fuites d informations.............. 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 UB ; ou, via internet, des supports de stockage externalisés proposés par des fournisseurs, 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 Incas-ITec et Inria. 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 approprié. 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 systè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 leurs 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. Une fois que l utilisateur a fourni le mot de passe (passphrase ou clef) pour accéder au répertoire chiffré, il obtient une vue en clair des données du répertoire ; 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é. Organisation du document.. 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 ( 4). Enfin, l analyse de sécurité ( 5.1) puis la conclusion terminent l article. 2. PRINCIPAUX YTÈME EXITANT
2.1 Luks Luks est un système de chiffrement de disque entier (full disk encryption). Il travaille sur un container (disque ou partition d un disque) et agit au niveau du noyau. 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 ystè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 appelons 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 ENCF Encfs utilise un chiffrement symétrique pour chiffrer les fichiers. Il propose au choix AE 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 est 128, 192 ou 256 bits pour AE. 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 FUE (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 configuration. Ainsi, le mode expert permet de choisir la méthode de chiffrement qui sera utilisée (AE ou blowfish), la taille de la clef, la taille des blocs, de demander aussi le chiffrement des noms 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 est 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 ouvert. 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épertoires 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 (AE, blowfish, cast6...), la taille de la clef de chiffrement (128,192 ou 256 bits pour AE), de dire si l écriture de fichiers en clair est autorisée dans le répertoire chiffré et si les noms des fichiers doivent ou non être chiffrés aussi. 3. MÉTHODE D EXPÉRIMENTATION Les mesures sont basées sur l écriture de données en clair dans le répertoire chiffré avec la fonction fprintf. Pour cela, 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].
un programme creation fichiers permettant de générer des fichiers aléatoires d une taille donnée a été utilisé. Les performances sont mesurées avec la fonction gettimeofday pour les mesures de temps. La machine personnelle 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.04LT. Les tests ont été faits avec les configurations suivantes pour les systèmes de fichiers chiffrés : Encfs Ecryptfs Chiffrement AE AE Taille de la clef 256 bits 256 bits Noms des fichiers chiffrés chiffrés Taille des blocs 1024 octets 128 octets (imposé) 3.1 Principe suivi 1. tockage 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 résultats ici. 2. tockage local Les tests en local ont été faits pour mesurer le surcoût arithmétique entrainé par l utilisation du chiffrement en local. 3. tockage 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épertoires 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, nous modélisons le coût de chiffrement par 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 un répertoire quelconque de la clef sans chiffrement reptest et dans un répertoire chiffré sur la clef. 3.4 Plateforme distante : cloud Pour effectuer les tests sur le cloud, il faut un outil permettant l écriture via le réseau. Deux solutions sont possibles : 3.4.1 Dossier synchronisé : dropbox La première est d utiliser un cloud avec une option de synchronisation des données comme dropbox. Dans ce cas il suffit juste de mettre le répertoire chiffré dans le dossier synchronisé de dropbox pour que les données soient ainsi sauvegardées chiffrées sur le cloud. Figure 2 : Accès au cloud via dropbox. Exemple avec encfs : encfs /home/username/dropbox/chiffre /home/username/clair 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 peut donc ne 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.4.2 Accès par cache : webdav La deuxième solution serait d éviter la duplication des données en local, donc de ne pas avoir recours à la synchronisation mais plutôt à un outil permettant de lire/écrire sur le web, comme 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. ous 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. Il est quand même assez rapide lors d un parcours d un fichier car il permet de factoriser les accès plutot que d ecrire octet par octet. Ces deux solutions permettent de sécuriser ses données avant l envoi 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 de l un des utilisateurs (pendant que les
Répertoire pas chiffré vs répertoire chiffré avec encfs en local temps en s 0 5 10 15 20 max encfs moy encfs min encfs max répertoire non chiffré moy répertoire non chiffré min répertoire non chiffré Figure 3 : Ecriture d un fichier local sans et avec encfs. Répertoire pas chiffré vs répertoire chiffré avec ecryptfs en local temps en s 0 10 20 30 40 50 60 Répertoire pas chiffré vs répertoire chiffré avec eencfs sur clef usb max encfs moy encfs min encfs max répertoire non chiffré moy répertoire non chiffré min répertoire non chiffré temps en s 0 2 4 6 8 max ecryptfs moy ecryptfs min ecryptfs max répertoire non chiffré moy répertoire non chiffré min répertoire non chiffré Figure 5 : Ecriture d un fichier sur clef UB sans et avec encfs. Figure 4 : Ecriture d un fichier local sans et avec ecryptfs. 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. ANALYE COMPARATIVE DE YTÈME 4.1 Tests de performance Pour chaque expérience, la mesure a été répétée 5 fois pour chaque taille de fichier donnée. Les fichiers de même taille portent le même nom par défaut pour les 5 mesures. Le fichier est donc écrasé à chaque fois pour une nouvelle mesure pour une taille de fichier donnée. Les écritures dans le fichier sont faites de façon linéaire le long du fichier. Pour une même expérience le temps minimum, le temps maximum et la moyenne des 5 exécutions est reportée. 1. En local : figure 3 et figure 4 On présente ci dessous les résultats des tests effectués sur la plateforme locale en utilisant les différents systèmes de fichiers chiffrés. 2. Périphérique : Clef UB (figure 5 et figure 6) 4.2 ynthèse temps en s 0 10 20 30 40 50 60 Répertoire pas chiffré vs répertoire chiffré avec ecryptfs sur clef usb max ecryptfs moy ecryptfs min ecryptfs max répertoire non chiffré moy répertoire non chiffré min répertoire non chiffré Figure 6 : Ecriture d un fichier sur clef UB sans et avec ecryptfs.
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 (i) en fonction de la taille (i) du fichier. On note T (i) le temps d écriture directe (sans chiffrement) d un fichier de taille i octets sur le support, avec = DD (resp. usb) pour l écriture sur le disque local (resp. la clef UB). De même on note C E (i) le temps d écriture sur un fichier d un répertoire chiffré d un fichier de taille i octets sur le support avec le système de chiffrement E ; dans nos expériences, E {encfs, ecryptfs}. Avec encfs, la figure 3 montre un temps d écriture environ deux fois plus long que le temps d écriture directe. Ce rapport de deux entre temps avec chiffrement et temps sans chiffrement apparait aussi sur clef UB, alors que le temps d écriture sur clef UB (aussi bien sans chiffrement qu avec chiffrement) apparait environ deux fois plus cher que sur disque local. Mon interprétation est la suivante : les deux répertoires (avec ou sans chiffrement) étant sur le même support, l accès lors d un chiffrement coûte deux fois plus cher avec encfs que l accès à un seul fichier. Tout se passe comme si encfs faisait deux écritures sur le même support lors de l écriture sur un répertoire chiffré ; le temps arithmétique du chiffrement lui-même correspondrait alors à la différence C (encfs) (i) 2T (encfs) (i), qui serait alors faible par rapport au temps d accès au support, sur disque local et encore plus négligeable sur clef UB. Par contre, on voit sur la courbe (figure 4) que le temps d écriture avec ecryptfs est proche du temps d écriture directe avec des pentes très proches. Cela peut s expliquer par le fait que ecryptfs, contrairement à encfs n écrit pas sur le disque le clair avant de le chiffrer. En effet comme expliqué sur cet article [9], ecryptfs utilise le cache pour les données en clair et ne fait d accés disque pour écriture que pour les données chiffrées. Le benchmark utilisé (figure 7) généré avec pmbw [8], montre que la vitesse d écriture dans le cache est d environ 10GiB/s pour une taille de 2 10 octets. Le temps moyen d écriture sur le disque observé lors des expériences est environ égal à 48Mbps. Ecryptfs écrit deux fois dans le cache avant d écrire dans le disque, mais ce temps d écriture sur le cache est négligeable (10GiB/s) devant le temps d écriture sur le disque. Ceci explique le coefficient deux entre le temps d écriture chiffré avec encfs et le temps d écriture chiffré avec ecryptfs (figure 3, figure 4), vu que encfs ferait donc deux écritures disque là où ecryptfs n en fait qu une. On s intéresse maintenant à estimer le surcoût de chiffrement pour chacun des systèmes. La figure 8 (resp. 9 ) montre l estimation brutale C encfs (i) T (i) (resp. C ecryptfs (i) T (i) ) du surcôut de chiffrement pour encfs (resp. ecryptfs) par rapport au coût d écriture local (sur l ordinateur ou la clef). Ce temps apparait proche du coût d écriture sans chiffrement pour encfs et négligeable pour ecryptfs. Cela semble étonnant, les surcoûts de chiffrement devant être du même ordre pour les deux systèmes avec le même chiffrement AE 256 bits. Dans la suite, on suppose que le temps de chiffrement C (i) (soit avec encfs, soit avec ecryptfs) est la somme : d un temps arithmétique A (i) dû au chiffrement et d un temps d accès au support (communication et coût du chiffrement en s/mo coût du chiffrement en s/mo 0.010 0.015 0.020 0.025 0.030 0.035 0.040 0.01 0.02 0.03 0.04 0.05 0.06 coût sur usb coût en local Figure 7 : Benchmark coût en local vs coût sur clef usb pour encfs Figure 8 : Courbe C encfs (i) T (i) coût en local vs coût sur clef usb pour ecryptfs coût sur usb coût en local Figure 9 : Courbe C ecryptfs (i) T (i)
rapport du temps d'écriture sans chiffrement (encfs) coût du chiffrement en s/mo 0.01 0.00 0.01 0.02 0.03 0.04 0.05 coût approximatif du chiffrement pour encfs rho(i) 2.0 2.5 3.0 3.5 4.0 4.5 5.0 5.5 Figure 12 : Approximation de ρ(i) = E usb(i) E DD (i) par T usb(i) T DD (i) pour encfs Figure 10 : Estimation de la bande passante de chiffrement pour encfs. écriture) E (i). La différence C (i) E (i) correspond au surcoût de chiffrement ; on définit donc la bande passante de chiffrement A par : A (i) = C (i) E (i). En supposant que A i est indépendant du support, on a les relations suivantes : C usb (i) = A(i) + E usb (i) coût du chiffrement en s/mo 0.02 0.01 0.00 0.01 coût approximatif du chiffrement pour ecryptfs Figure 11 : Estimation de la bande passante de chiffrement pour ecryptfs. oit ρ(i) = E usb(i) E DD (i) C DD i = A(i) + E DD (i). le rapport entre les coûts d écriture sur clef UB et sur disque local ; ce rapport peut être supposé asymptotiquement constant ; dans la suite nous considérons que ρ(i) T usb(i) T DD(i). ous ces hypothèses, on déduit alors la valeur approximative de la bande passante de chiffrement A(i) i = C usb(i) ρ(i) C DD (i). i(1 ρ(i)) La courbe 10 (resp. 11) représente cette estimation de la bande passante à partir des valeurs expérimentales. ur cette courbe, on remarque que cette valeur expérimentale de la bande de chiffrement calculée par cette méthode est souvent négative, ce qui est absurde. Or notre modèle simple devrait être valide pour des tailles au delà de 100 Mo ; On en déduit qu il y a des erreurs qui peuvent provenir : soit de mauvaises expérimentations ou de mauvais reports de valeurs expérimentales ; soit que le temps de chiffrement est trop faible, et est négligeable devant les temps d écriture sur les supports et aux bruits mesurés. En effet, avec un temps de chiffrement négligeable devant le temps d écriture, les variations d une exécution à l autre du temps d écriture rendent erronée l approximation de ρ(i) = E usb (i) E DD (i). La courbe 12 (resp. 13 ) montre l approximation de ρ(i) pour encfs d une part et ecryptfs d autre part. Les courbes ont a peu prés la même allure mais diffèrent quand même. Cela est très supprenant qu il y ait autant de différences entre les deux courbes. En effet, le programme de simulation pour ces deux tests écrivait dans le même répertoire, les mêmes tailles de fichiers mais juste à des instants par T usb(i) T DD (i)
rapport du temps d'écriture sans chiffrement (ecryptfs) rho(i) 2.5 3.0 3.5 4.0 4.5 5.0 Figure 13 : Approximation de ρ(i) = E usb(i) E DD (i) par T usb(i) T DD (i) pour ecryptfs différents. Ces résultats n ont donc rien à voir avec le fait d utiliser Encfs ou ecryptfs. Cette différence peut s expliquer par le fait qu il y ait des variations dans l utilisation du processeur par les autres programmes. Il faudrait donc utiliser une machine dont on connait le plus précisément possible les programmes en cours d execution et qu il n y ait pas de trop fortes variations dans leur utilisation du support. 5. ANALYE DE É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 (AE ou blowfish) en mode CFB. oit 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. i 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 (AE 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. i 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ée pour le mode paranoic et normal. Pour le mode expert, il faudra bien sûr penser à l activer (option : Per-file IV initialization vector) pour éviter d éventuelles fuites d informations. 5.2 Fuites d informations 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) [10]. 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. oit ={1..n}. On effectue les opérations suivantes pour récupérer Fi : On tire au hasard A i i A on pose B = A \ {i} inon on pose B = A {i} On demande A à A et on pose r A = On demande B à B et on pose r B = on récupére F i en faisant F i = r A r B j A F j j B F j 6. CONCLUION 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 sur une machine dont on maitrise parfaitement les applications qui tournent en fond. 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 compromettent 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 et utilise le cache 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 ). [10] Wikipedia. Pir-private information retrieval. http://en.wikipedia.org/wiki/private_ information_retrieval. 7. REMERCIEMENT 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. Un grand merci à eux pour leur patience et leur encouragement tout au long de ce semestre. 8. REFERENCE [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,. Kamara, and R. Ostrovsky. earchable 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. [8] panthema. https: //panthema.net/2013/pmbw/index.html#downloads. [9] L. Wang, Y. Wen, J. Kong, and X. Yi. Optimizing ecryptfs for better performance and security. https: //www.kernel.org/doc/ols/2012/ols2012-wang.pdf.