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`emes existants
2.1 Luks . . . . 2.2 Syst`eme 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´ethodes d’exp´erimentation
3.1 Principe suivi . . . . 3.2 Plateforme locale . . . . 3.3 Plateforme disque p´eriph´erique . . . . 3.4 Plateforme distante : cloud . . . . 3.4.1 Dossier synchronis´e : dropbox . . . . . 3.4.2 Acc`es par cache : webdav . . . . 4 Analyse comparative de syst`eme
4.1 Tests de performance . . . . 4.2 Synth`ese . . . . 5 Analyse de s´ecurit´e
5.1 Failles r´epertori´ees . . . . 5.2 Fuites d’informations . . . . 6 Conclusion
7 Remerciements 8 References
1. INTRODUCTION Problème et objectif.
L’ordinateur est devenu un ´el´ement central de nos vies.
Que l’on soit jeune ou ˆag´e, travailleur ou chˆomeur, on a souvent recours `a internet, qui, au fil des ann´ees est devenu incontournable.
Certains utilisent leur ordinateur comme espace de sto- ckage pour leurs donn´ees personnelles et/ou professionnelles.
D’autres ayant besoin de plus d’espace ou pour partager leurs donn´ees utilisent des supports de stockage externe : disque dur ; clef USB ; ou, via internet, des supports de sto- ckage externalis´es propos´es par des fournisseurs, que l’on d´esigne par le termecloud.
Que nos donn´ees soient stock´ees sur une partition d’un disque, une clef usb ou encore sur le cloud, elles sont expos´ees
`
a des risques pouvant mettre en danger leur s´ecurit´e. Vic- times de pannes al´eatoires ou d’attaques, elles peuvent ˆetre perdues totalement ou partiellement, modifi´ees ou corrom- pues, rendues publiques alors qu’on voulait qu’elles restent confidentielles. En consid´erant le pire cas qui est celui d’at- taques malicieuses, les solutions pour s´ecuriser les donn´ees sont bas´ees sur la cryptographie et le codage : chiffrement des donn´ees stock´ees sur des supports externes pour garan- tir leur confidentialit´e et restreindre les acc`es ; signature et redondance pour leur int´egrit´e. L’objectif de ce projet est de comparer des syst`emes existants pour le stockage de don- n´ees s´ecuris´ees et de comparer leurs performances en terme de temps et de s´ecurit´e.
Contexte de l’étude.
Ce projet se d´eroule `a Inria dans le cadre d’une colla- boration entre les ´equipes Privatics et Moais et l’entreprise Incas-ITsec qui consiste au d´eveloppement d’un module de s´ecurit´e en rupture (figure 1) qui propose des garanties de s´ecurit´e grˆace au filtrage et au chiffrement syst´ematique des communications entre la machine de l’utilisateur (ordinateur ou t´el´ephone) et le cloud.
Figure 1 : Module en rupture d’Incas-ITSec et Inria.
L’´etude pr´esent´ee ici est motiv´ee par l’application de ce module `a l’externalisation de donn´ees priv´ees sur le cloud.
La solution ´etudi´ee est d’offrir `a l’utilisateur une vue en clair de ses donn´ees, alors qu’elles sont stock´ees de mani`ere chiffr´ees sur internet. Le module en rupture prend en charge l’authentification et les ´echanges de donn´ees ; les donn´ees sont stock´ees par un syst`eme de gestion de fichiers chiffr´es qui permet d’acc´eder `a des zones de stockage chiffr´ees.
Nous allons donc comparer plusieurs syst`emes de fichiers chiffr´es afin de d´eterminer le plus appropri´e.
Principe des systèmes de fichiers chiffrés et critères de comparaison.
Le chiffrement est un proc´ed´e cryptographique permettant de garantir la confidentialit´e des messages transmis. Les sys- t`emes de fichiers chiffr´es (on dit aussi dans la suitesyst`eme de chiffrement, sous entendu pour stockage de donn´ees) uti- lisent des algorithmes de chiffrement, mis `a disposition des utilisateurs afin de leur permettre de prot´eger leurs donn´ees.
Il existe des syst`emes de chiffrement permettant de chiffrer l’ensemble d’un disque dur entier (full disk encryption) ou juste une partie (chiffrement de volume).
Ces syst`emes fonctionnent comme des coffres que l’on peut ouvrir ou fermer pour en autoriser l’acc`es ou pas. Une fois que l’utilisateur a fourni le mot de passe (passphrase ou clef) pour acc´eder au r´epertoire chiffr´e, il obtient une vue en clair des donn´ees du r´epertoire ; on dit alors que le dossier chiffr´e a ´et´emont´e.
Pour comparer ces syst`emes nous avons choisi les crit`eres d’analyse suivants :
• facilit´e d’utilisation ;
• performances (surcoˆut d’acc`es, temps de calcul) ;
• s´ecurit´e.
Organisation du document..
Les principaux syst`emes ´etudi´es (Luks, Enfs et Ecryptfs) sont d’abord introduits (§2). Puis nous d´ecrivons (§3) la m´ethodologie suivie pour l’exp´erimentation et les mesures de performance. Les r´esultats exp´erimentaux et leur analyse sont ensuite pr´esent´es (§4). Enfin, l’analyse de s´ecurit´e (§5.1) puis la conclusion terminent l’article.
2. PRINCIPAUX SYSTÈMES EXISTANTS
2.1 Luks
Luks est un syst`eme 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´e sur le module dm-crypt et permet de chiffrer le home directory ou le swap d’une distribution linux. Il offre la possibilit´e d’avoir un trousseau de clef, ce qui permet `a diff´erents utilisateurs d’avoir acc`es aux mˆemes donn´ees sans avoir la mˆeme clef et de r´evoquer un utilisateur sans avoir `a rechiffrer toutes les donn´ees.
2.2 Système de chiffrement de volume 2.2.1 Encfs
Encfs est un syst`eme de chiffrement permettant de chif- frer le contenu d’un volume. Il travaille sur deux r´epertoires, celui contenant les donn´ees chiffr´ees et un autre permettant
`
a l’utilisateur d’avoir une vue des donn´ees en clair.
Dans la suite nous appelonscoffrele r´epertoire chiffr´e et coffre ouvertle r´epertoire contenant les donn´ees en clair.
Chaque fichier danscoffre ouvertcorrespond `a un fichier chiffr´e danscoffre.
Les r´epertoirescoffreetcoffre ouvertsont mont´es/d´emon- t´es `a la demande de l’utilisateur. Le montage n´ecessite le mot de passe d´efini par l’utilisateur `a la cr´eation des r´epertoires mais le d´emontage se fait sans l’utilisation du mot de passe.
Lorsque les r´epertoires sont mont´es l’utilisateur a acc`es `a tous ses fichiers en clair danscoffre ouvert. Lorsqu’on modi- fie un fichier danscoffre ouvertle fichier est chiffr´e en mˆeme temps et les modifications sont ainsi prises en compte dans coffre.
Le mot de passe d´efini par l’utilisateur `a la cr´eation des r´epertoires est utilis´e pour crypter la clef g´en´er´ee al´eatoire- ment qui doit servir `a chiffrer les donn´ees. La clef permettant de chiffrer les donn´ees est contenue, crypt´ee (avec PBKDF2), dans le fichierencfs6.xml dans le r´epertoire chiffr´e. La paire mot de passe etencfs6.xmlest donc indispensable pour chif- frer et d´echiffrer les donn´ees.
1. Chiffrement utilis´e par ENCFS
Encfs utilise un chiffrement sym´etrique pour chiffrer les fichiers. Il propose au choix AES et blowfish. Tous les deux sont disponibles avec des tailles de blocs allant de 64 `a 4096 octets (avec un pas de 16) et la taille des clefs est 128, 192 ou 256 bits pour AES.
Lecture. A chaque fois qu’un octet doit ˆetre lu, tout le bloc correspondant est d´echiffr´e.
Ecriture. A chaque fois qu’un octet doit ˆetre ´ecrit, tout le bloc correspondant est d´echiffr´e, l’octet est ´ecrit puis on chiffre encore tout le bloc.
2. Information sur l’arborescence des fichiers.
Comme expliqu´e ci dessus, encfs garde la mˆeme arbo- rescence pour les fichiers et r´epertoires. N’importe qui ayant acc`es au r´epertoire chiffr´e peut connaˆıtre l’arbo- rescence du r´epertoire en clair.
3. Information sur les tailles de fichier. Les fichiers ont quasiment la mˆeme taille que dans le r´epertoire clair.
En effet on n’observe qu’un surplus de 8 octets par rapport `a la taille du fichier de base, dˆu au vecteur d’initialisation choisi al´eatoirement pour chaque fichier (option que l’on peut d´esactiver).
2.2.2 Ecryptfs
Ecryptfs est un syst`eme de fichiers chiffr´e similaire `a Encfs.
Ecryptfs permet de chiffrer le contenu de r´epertoires et tra- vaille 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´ecentes d’ubuntu (`a partir de ubuntu 13.10). Pour les autres versions les ´etapes
`
a suivre sont expliqu´es ici [7] .
Nous pouvons ensuite cr´eer une paire de r´epertoire chif- fr´e/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´epertoires.
Exemple : encfs /home/coffre /home/coffre ouvert Il est alors demand´e de choisir certains param`etres pour la configuration du syst`eme de chiffrement. La configuration par d´efaut est le mode ”paranoic” (cf[7]) et c’est celle qui a
´
et´e utilis´ee pour cette ´etude ; un mode ”expert” permet de sp´ecialiser la configuration. Ainsi, le mode expert permet de choisir la m´ethode de chiffrement qui sera utilis´ee (AES 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 ˆetre activ´ees.
Une fois les r´epertoires cr´e´es, il est possible de monter le r´epertoire chiffr´e sur le r´epertoire clair avec la mˆeme com- mande que pour la cr´eation :
”encfs /home/coffre /home/coffre ouvert”.
Le mot de passe est demand´e et on a ainsi acc`es aux don- n´ees en clair dans coffre ouvert.
Pour les d´emonter, et donc ne plus avoir les donn´ees en clair dans coffre ouvert, il faudra faire :
”fusermount -u /home/coffre ouvert”.
2.3.2 Ecryptfs
Ecryptfs est comme Encfs un syst`eme de fichiers chiffr´es qui travaille sur deux r´epertoires (partition,clef,...). L’ins- tallation se fait avec la commande : ”sudo apt-get install ecryptfs-utils”. En reprenant les mˆemes notations pour les noms des r´epertoires la cr´eation d’une paire de r´epertoires se fait avec :
sudo mount -t ecryptfs coffre coffre ouvert.
Contrairement `a Encfs, cryptfs marche avec des chemins relatifs pour l’emplacement des r´epertoires et ne s’utilise par d´efaut qu’avec des droits d’acc`es privil´egi´es (root)1.
Il est d’abord demand´e de d´efinir un mot de passe puis de choisir la m´ethode chiffrement (AES, blowfish, cast6...), la taille de la clef de chiffrement (128,192 ou 256 bits pour AES), de dire si l’´ecriture de fichiers en clair est autoris´ee dans le r´epertoire chiffr´e et si les noms des fichiers doivent ou non ˆetre chiffr´es aussi.
3. MÉTHODES D’EXPÉRIMENTATION
Les mesures sont bas´ees sur l’´ecriture de donn´ees en clair dans le r´epertoire chiffr´e avec la fonctionfprintf. Pour cela, 1. Mˆeme si ecryptfs s’utilise par d´efaut en root vous pou- vez changer cela par la suite en suivant les indications sur ce tutoriel [2].
un programme ”creation fichiers” permettant de g´en´erer des fichiers al´eatoires d’une taille donn´ee a ´et´e utilis´e. Les per- formances sont mesur´ees avec la fonction gettimeofday pour les mesures de temps.
La machine personnelle utilis´ee pour les tests est une ma- chine 4 coeurs avec 4G de RAM et 500G d’espace disque.
La machine est sous ubuntu 14.04LTS.
Les tests ont ´et´e faits avec les configurations suivantes pour les syst`emes de fichiers chiffr´es :
Encfs Ecryptfs
Chiffrement AES AES
Taille de la clef 256 bits 256 bits Noms des fichiers chiffr´es chiffr´es Taille des blocs 1024 octets 128 octets (impos´e)
3.1 Principe suivi
1. Stockage distant via le r´eseau
Les tests effectu´es sur le cloud ont ´et´e r´ealis´es pour
´
etudier la faisabilit´e d’une telle combinaison (chiffre- ment/´ecriture sur le cloud) et avoir une id´ee de l’im- pact sur le temps en upload/download. Cependant, ces exp´eriemntations `a distance via internet sur dropbox ne sont pas reproductibles et nous ne pr´esentons pas les r´esultats ici.
2. Stockage local
Les tests en local ont ´et´e faits pour mesurer le surcoˆut arithm´etique entrain´e par l’utilisation du chiffrement en local.
3. Stockage sur un p´eriph´erique
Les tests sur clef usb ont ´et´e r´ealis´es pour mesurer le surcoˆut syst`eme entrain´e par l’utilisation du chiffre- ment sur un p´eriph´erique.
3.2 Plateforme locale
Pour ´evaluer le coˆut du chiffrement, les tests, dont les r´esultats sont pr´esent´es ci-apr`es, ont ´et´e effectu´es sur la ma- chine personnelle pr´esent´ee ci-dessus.
On cr´ee une paire de r´epertoires encfs (ou ecryptfs) (clair et chiffr´e) dans $Home et on cr´ee en mˆeme temps un r´eper- toire quelconque dans $Home, qu’on appelera ”repTest”.
On utilise le programme, ”creation fichiers”, pour cr´eer les mˆemes fichiers dans ”repTest” et dans ”clair”. Comme encfs (ecryptfs) chiffre `a la vol´ee, nous mod´elisons le coˆut de chiffrement par la diff´erence du temps mis pour ´ecrire dans
”clair” avec le temps mis pour ´ecrire dans ”repTest”.
3.3 Plateforme disque périphérique
Le mˆeme programme pr´esent´e ci dessus a ´et´e utilis´e pour g´en´erer des fichiers dans un r´epertoire quelconque de la clef sans chiffrement ”repTest” et dans un r´epertoire chiffr´e sur la clef.
3.4 Plateforme distante : cloud
Pour effectuer les tests sur le cloud, il faut un outil permet- tant l’´ecriture via le r´eseau. Deux solutions sont possibles :
3.4.1 Dossier synchronisé : dropbox
La premi`ere est d’utiliser un cloud avec une option de synchronisation des donn´ees comme dropbox. Dans ce cas il suffit juste de mettre le r´epertoire chiffr´e dans le dossier synchronis´e de dropbox pour que les donn´ees soient ainsi sauvegard´ees chiffr´ees sur le cloud.
Figure 2 : Acc`es au cloud via dropbox.
Exemple avec encfs :
encfs /home/username/Dropbox/chiffre /home/username/clair On pourra mettre nos donn´ees sur /home/username/clair qui seront ensuite crypt´ees et sauvegard´ees dans
/home/username/Dropbox/chiffre qui est un r´epertoire synchronis´e (donc dropbox s’occupera de la synchronisa- tion).
Cette solution conviendrait `a des personnes, pour qui, avoir leur donn´ees en local (synchronisation) ne pose pas de probl`emes. A noter qu’avec Dropbox on peut choisir les r´epertoires `a synchroniser ; on peut donc ne synchroniser que le r´epertoire chiffr´e /home/username/Dropbox/chiffre qui contient peut-ˆetre des donn´ees 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`eme solution serait d’´eviter la duplication des donn´ees en local, donc de ne pas avoir recours `a la synchro- nisation mais plutˆot `a un outil permettant de lire/´ecrire sur le web, comme webdav.
Webdav fonctionne par montage/d´emontage comme encfs et ecryptfs. Nous pouvons donc grˆace `a ce dernier, demander
`
a monter notre cloud en local pour pouvoir travailler dessus.
A la diff´erence de la synchronisation, le montage nous donne une vue de nos donn´ees stock´ees sur le cloud, on peut ainsi manipuler les donn´ees sans que celles-ci soient stock´ees en local. Sous ubuntu nous pouvons utiliser webdav grˆace `a davfs2 dont le processus d’installation est expliqu´e sur ce site [6].
A noter cependant que webdav lors d’une ´ecriture, ´ecrit d’abord sur le cache avant de proc´eder `a l’´ecriture sur le web, ce qui le rend assez lent. Il est quand mˆeme assez rapide lors d’un parcours d’un fichier car il permet de factoriser les acc`es plutot que d’ecrire octet par octet.
Ces deux solutions permettent de s´ecuriser ses donn´ees avant l’envoi sur le cloud. Le chiffrement se fait sur l’ordi- nateur de l’utilisateur, ce qui peut ˆetre probl´ematique. On peut utiliser le module de s´ecurit´e en rupture afin de centra- liser le chiffrement. D´el´eguer cette tˆache au module permet de n’avoir les donn´ees clair/chiffr´e et les informations de chiffrement que sur ce dernier. L’utilisateur n’aura que les donn´ees en clair quand il communique avec le module et le cloud n’aura que les donn´ees chiffr´ees.
En effet avec cette solution, mˆeme si un attaquant a ac- c`es `a l’ordinateur de l’un des utilisateurs (pendant que les
●●●●●
●
●●●●
●
●
●
●
● ●
● ●● ●
●●
●
●
●
●
●
● ●
●
●
●
● ●
●
●
●
●
●
0 50 100 150 200 250 300
05101520
taille en Mo
temps en s
max encfs moy encfs min encfs max répertoire non chiffré moy répertoire non chiffré min répertoire non chiffré
Répertoire pas chiffré vs répertoire chiffré avec encfs en local
Figure 3 : Ecriture d’un fichier local sans et avec encfs.
●●●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●●
●
●
●
●● ●
●
●
●●
●
●
●
●
●
●●
0 50 100 150 200 250 300
02468
taille en Mo
temps en s
max ecryptfs moy ecryptfs min ecryptfs max répertoire non chiffré moy répertoire non chiffré min répertoire non chiffré
Répertoire pas chiffré vs répertoire chiffré avec ecryptfs en local
Figure 4 : Ecriture d’un fichier local sans et avec ecryptfs.
donn´ees sont mont´ees), il n’aura que les donn´ees en clair pr´e- sentes `a cet instant sur cet ordinateur. L’attaquant n’aura pas acc`es aux donn´ees chiffr´ees correspondantes ni aux in- formations de chiffrement (clef de chiffrement...) qui ne sont que sur le module.
4. ANALYSE COMPARATIVE DE SYSTÈME 4.1 Tests de performance
Pour chaque exp´erience, la mesure a ´et´e r´ep´et´ee 5 fois pour chaque taille de fichier donn´ee. Les fichiers de mˆeme taille portent le mˆeme nom par d´efaut pour les 5 mesures.
Le fichier est donc ´ecras´e `a chaque fois pour une nouvelle mesure pour une taille de fichier donn´ee. Les ´ecritures dans le fichier sont faites de fa¸con lin´eaire le long du fichier.
Pour une mˆeme exp´erience le temps minimum, le temps maximum et la moyenne des 5 ex´ecutions est report´ee.
1. En local : figure 3 et figure 4
On pr´esente ci dessous les r´esultats des tests effectu´es sur la plateforme locale en utilisant les diff´erents sys- t`emes de fichiers chiffr´es.
2. P´eriph´erique : Clef USB (figure 5 et figure 6)
4.2 Synthèse
●● ●●●●●●●●●●
● ●●
● ●●
●
●
●
●
●
●
●
●
●
●
●● ●
●
●
●
●
●
●
●
●
0 50 100 150 200 250 300
0102030405060
taille en Mo
temps en s
max encfs moy encfs min encfs max répertoire non chiffré moy répertoire non chiffré min répertoire non chiffré
Répertoire pas chiffré vs répertoire chiffré avec eencfs sur clef usb
Figure 5 : Ecriture d’un fichier sur clef USB sans et avec encfs.
●●●●●●
●●
●
●
●●
●
●
● ●● ●●
●
●
●
●
●●
●
●
●
●●
●
●
●
●
●
●
●
●
●
0 50 100 150 200 250 300
0102030405060
taille en Mo
temps en s
max ecryptfs moy ecryptfs min ecryptfs max répertoire non chiffré moy répertoire non chiffré min répertoire non chiffré
Répertoire pas chiffré vs répertoire chiffré avec ecryptfs sur clef usb
Figure 6 : Ecriture d’un fichier sur clef USB sans et avec ecryptfs.
A l’issue des tests effectu´es nous avons donc pu comparer le temps mis pour ´ecrire dans un r´epertoire de l’ordinateur avec ou sans chiffrement et le temps mis pour faire la mˆeme chose sur une clef usb. Nous avons exploit´e ces r´esultats pour calculer le coˆut arithm´etique du chiffrement not´e Tarith(i) en fonction de la taille (i) du fichier.
On note TS(i) le temps d’´ecriture directe (sans chiffre- ment) d’un fichier de taillei octets sur le supportS, avec S=DD(resp.usb) pour l’´ecriture sur le disque local (resp.
la clef USB). De mˆeme on note CSE(i) le temps d’´ecriture sur un fichier d’un r´epertoire chiffr´e d’un fichier de taille i octets sur le supportS avec le syst`eme de chiffrement E; dans nos exp´eriences,E∈ {encfs,ecryptfs}.
Avec encfs, la figure 3 montre un temps d’´ecriture envi- ron deux fois plus long que le temps d’´ecriture directe. Ce rapport de deux entre temps avec chiffrement et temps sans chiffrement apparait aussi sur clef USB, alors que le temps d’´ecriture sur clef USB (aussi bien sans chiffrement qu’avec chiffrement) apparait environ deux fois plus cher que sur disque local. Mon interpr´etation est la suivante : les deux r´epertoires (avec ou sans chiffrement) ´etant sur le mˆeme sup- port, l’acc`es lors d’un chiffrement coˆute deux fois plus cher avec encfs que l’acc`es `a un seul fichier. Tout se passe comme si encfs faisait deux ´ecritures sur le mˆeme support lors de l’´ecriture sur un r´epertoire chiffr´e ; le temps arithm´etique du chiffrement lui-mˆeme correspondrait alors `a la diff´erence CS(encf s)(i)−2TS(encf s)(i), qui serait alors faible par rapport au temps d’acc`es au support, sur disque local et encore plus n´egligeable sur clef USB.
Par contre, on voit sur la courbe (figure 4) que le temps d’´ecriture avec ecryptfs est proche du temps d’´ecriture di- recte avec des pentes tr`es proches.
Cela peut s’expliquer par le fait que ecryptfs, contraire- ment `a encfs n’´ecrit pas sur le disque le clair avant de le chiffrer. En effet comme expliqu´e sur cet article [9], ecryptfs utilise le cache pour les donn´ees en clair et ne fait d’acc´es disque pour ´ecriture que pour les donn´ees chiffr´ees.
Le benchmark utilis´e (figure 7) g´en´er´e avec pmbw [8], montre que la vitesse d’´ecriture dans le cache est d’environ 10GiB/s pour une taille de 210 octets.
Le temps moyen d’´ecriture sur le disque observ´e lors des exp´eriences est environ ´egal `a 48Mbps. Ecryptfs ´ecrit deux fois dans le cache avant d’´ecrire dans le disque, mais ce temps d’´ecriture sur le cache est n´egligeable (10GiB/s) devant le temps d’´ecriture sur le disque.
Ceci explique le coefficient deux entre le temps d’´ecriture chiffr´e avec encfs et le temps d’´ecriture chiffr´e avec ecryptfs (figure 3, figure 4), vu que encfs ferait donc deux ´ecritures disque l`a o`u ecryptfs n’en fait qu’une.
On s’int´eresse maintenant `a estimer le surcoˆut de chiffre- ment pour chacun des syst`emes. La figure 8 (resp. 9 ) montre l’estimation brutaleCSencf s(i)−TS(i) (resp.CSecryptf s(i)− TS(i) ) du surcˆout de chiffrement pour encfs (resp. ecryptfs) par rapport au coˆut d’´ecriture local (sur l’ordinateur ou la clef). Ce temps apparait proche du coˆut d’´ecriture sans chif- frement pour encfs et n´egligeable pour ecryptfs. Cela semble
´etonnant, les surcoˆuts de chiffrement devant ˆetre du mˆeme ordre pour les deux syst`emes avec le mˆeme chiffrement AES 256 bits.
Dans la suite, on suppose que le temps de chiffrement CS(i) (soit avec encfs, soit avec ecryptfs) est la somme :
• d’un temps arithm´etiqueAS(i) dˆu au chiffrement
• et d’un temps d’acc`es au support (communication et
Figure 7 : Benchmark
0 50 100 150 200 250 300
0.0100.0150.0200.0250.0300.0350.040
taille en Mo
coût du chiffrement en s/Mo
coût sur usb coût en local
coût en local vs coût sur clef usb pour encfs
Figure 8 : CourbeCSencf s(i)−TS(i)
0 50 100 150 200 250 300
0.010.020.030.040.050.06
taille en Mo
coût du chiffrement en s/Mo
coût sur usb coût en local
coût en local vs coût sur clef usb pour ecryptfs
Figure 9 : CourbeCSecryptf s(i)−TS(i)
0 50 100 150 200 250 300
−0.010.000.010.020.030.040.05
taille en Mo
coût du chiffrement en s/Mo
coût approximatif du chiffrement pour encfs
Figure 10 : Estimation de la bande passante de chif- frement pour encfs.
0 50 100 150 200 250 300
−0.02−0.010.000.01
taille en Mo
coût du chiffrement en s/Mo
coût approximatif du chiffrement pour ecryptfs
Figure 11 : Estimation de la bande passante de chif- frement pour ecryptfs.
0 50 100 150 200 250 300
2.02.53.03.54.04.55.05.5
taille en Mo
rho(i)
rapport du temps d'écriture sans chiffrement (encfs)
Figure 12 : Approximation deρ(i) = EEusb(i)
DD(i) parTTusb(i)
DD(i)
pour encfs
´
ecriture)ES(i).
La diff´erenceCS(i)−ES(i) correspond au surcoˆut de chif- frement ; on d´efinit donc la bande passante de chiffrement AS par : AS(i) = CS(i)−iES(i). En supposant que AS est ind´ependant du supportS, on a les relations suivantes :
Cusb(i) =A(i) +Eusb(i) CDDi=A(i) +EDD(i).
Soitρ(i) = EEusb(i)
DD(i) le rapport entre les coˆuts d’´ecriture sur clef USB et sur disque local ; ce rapport peut ˆetre suppos´e asymptotiquement constant ; dans la suite nous consid´erons que
ρ(i)≃ Tusb(i) TDD(i).
Sous ces hypoth`eses, on d´eduit alors la valeur approximative de la bande passante de chiffrement
A(i)
i = Cusb(i)−ρ(i)×CDD(i) i(1−ρ(i)) .
La courbe 10 (resp. 11) repr´esente cette estimation de la bande passante `a partir des valeurs exp´erimentales. Sur cette courbe, on remarque que cette valeur exp´erimentale de la bande de chiffrement calcul´ee par cette m´ethode est souvent n´egative, ce qui est absurde. Or notre mod`ele simple devrait ˆ
etre valide pour des tailles au del`a de 100 Mo ; On en d´eduit qu’il y a des erreurs qui peuvent provenir :
• soit de mauvaises exp´erimentations ou de mauvais re- ports de valeurs exp´erimentales ;
• soit que le temps de chiffrement est trop faible, et est n´egligeable devant les temps d’´ecriture sur les supports et aux bruits mesur´es.
En effet, avec un temps de chiffrement n´egligeable devant le temps d’´ecriture, les variations d’une ex´ecution `a l’autre du temps d’´ecriture rendent erron´ee l’approximation deρ(i) =
Eusb(i)
EDD(i) par TTusb(i)
DD(i). La courbe 12 (resp. 13 ) montre l’ap- proximation deρ(i) pour encfs d’une part et ecryptfs d’autre part.
Les courbes ont a peu pr´es la mˆeme allure mais diff`erent quand mˆeme. Cela est tr`es supprenant qu’il y ait autant de diff´erences entre les deux courbes. En effet, le programme de simulation pour ces deux tests ´ecrivait dans le mˆeme r´eper- toire, les mˆemes tailles de fichiers mais juste `a des instants
0 50 100 150 200 250 300
2.53.03.54.04.55.0
taille en Mo
rho(i)
rapport du temps d'écriture sans chiffrement (ecryptfs)
Figure 13 : Approximation deρ(i) = EEusb(i)
DD(i) par TTusb(i)
DD(i)
pour ecryptfs
diff´erents. Ces r´esultats n’ont donc rien `a voir avec le fait d’utiliser Encfs ou ecryptfs.
Cette diff´erence peut s’expliquer par le fait qu’il y ait des variations dans l’utilisation du processeur par les autres pro- grammes.
Il faudrait donc utiliser une machine dont on connait le plus pr´ecis´ement possible les programmes en cours d’execu- tion et qu’il n’y ait pas de trop fortes variations dans leur utilisation du support.
5. ANALYSE DE SÉCURITÉ 5.1 Failles répertoriées
Parmi les faiblesses en s´ecurit´e qui sont r´ef´erenc´ees dans les analyses [5] [4] sur Encfs et Ecryptfs figurent :
Encfs.
1. Taille des fichiers
Encfs garde la mˆeme arborescence de fichiers dans le r´epertoire clair que dans le r´epertoire chiffr´e mˆeme si les noms des fichiers sont chiffr´es.
On connait le nombre de fichiers et leur taille dans le r´epertoire clair `a partir du r´epertoire chiffr´e.
2. Remplissage du dernier bloc par des z´eros
Pour chiffrer les donn´ees encfs utilise un syst`eme de chiffrement par bloc (AES ou blowfish) en mode CFB.
SoitPnlen-i`eme bloc clair etCnleni`eme bloc chiffr´e ; alors
Cn= clef(Cn−1)⊕Pn,
avec comme notation clef(i)= r´esulat obtenu en appli- quant la clef de chiffrement `ai.
SiPnest le dernier bloc et n’est pas totalement rem- pli, le bloc est compl´et´e parkz´eros pour atteindre la taille d’un bloc.. Ceci permet donc `a un attaquant de r´ecup´erer lesk derniers bits de clef(Cn−1) et de faire une attaque clair/chiffr´e, pour trouver la clef, comme il connait aussi tous les bits deCn−1.
Dans l’exemple ci-dessus on connaitra ainsi les 2 der- niers bits de clef(C3) (parce qu’on fait un xor avec 00 ) et les 4 bits deC3 (vu que le texte chiffr´e n’est pas secret).
Pour pallier `a ce probl´eme, nous pouvons choisir une grande taille pour la clef (AES 256) pour augmenter le nombre de clefs possibles et r´esister aux attaques clair-chiffr´e.
3. Vecteur d’initialisation commun
Pour configurer encfs parmi les nombreux param`etres `a d´efinir il y a celui concernant le vecteur d’initialisation.
Si on choisit d’utiliser le mˆeme vecteur d’initialisation pour tous les fichiers, cela engendre des failles de s´ecu- rit´e.
En effet dans ce cas, en faisant le xor de deux fichiers chiffr´es nous r´ecup´erons le r´esultat du xor entre les deux fichiers clairs correspondants.
Encfs propose de g´en´erer al´eatoirement un vecteur d’ini- tialisation diff´erent pour chaque fichier. Cette option est activ´ee pour le mode ”paranoic” et ”normal”. Pour le mode expert, il faudra bien sˆur penser `a l’activer (option : Per-file IV initialization vector) pour ´eviter d’´eventuelles fuites d’informations.
5.2 Fuites d’informations
A ces faiblesses r´epertori´ees, pour les deux syst`emes chif- fr´es, on peut rajouter le fait qu’un fichier en clair correspond toujours au mˆeme chiffr´e. Ceci permet `a un attaquant de sa- voir la fr´equence d’acc´es `a un fichier. Pour ´eviter cela, une solution un peu coˆuteuse est de stocker les fichiers chiffr´es 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´ere avoir n fichiers F1..Fn stock´es chiffr´es sur les deux clouds (A et B), et on veut acc´eder au fichier i.
Soit S={1..n}. On effectue les op´erations suivantes pour r´ecup´erer Fi :
•On tire au hasardSA⊂S
•Sii∈SAon poseSB=SA\ {i}
•Sinon on poseSB=SA∪ {i}
•On demandeSA `a A et on poserA= ∑
j∈SA
Fj
•On demandeSB `a B et on poserB= ∑
j∈SB
Fj
•on r´ecup´ereFien faisantFi=rA⊕rB
6. CONCLUSION
En somme, nous pouvons dire que l’approche choisie pour d´eterminer le coˆut effectif du chiffrement n’´etait pas assez
pr´ecise.Il faudrait faire plus de mesures sur plus de supports et sur une machine dont on maitrise parfaitement les appli- cations qui tournent en fond.
Pour la s´ecurit´e mˆeme si encfs a plus de failles r´epertori´ees que ecryptfs [5] [4], ces failles pour encfs sont pour la plupart r´esolvables en activant une option ou ne compromettent pas vraiment l’int´egrit´e des fichiers.
Encfs est plus facile `a prendre en main pour un utilisateur lambda, le mode paranoia (voir man encfs, les options sont bien expliqu´ees) offre `a l’utilisateur assez de s´ecurit´e en lui choissant une taille de clef assez grande et en activant l’op- tion ”Message Authentication Code block headers” (permet de savoir si le fichier chiffr´e a ´et´e corrompu) entre autres.
Il y a moins d’options avec Ecryptfs et il n’y a pas de v´erification du passphrase `a la cr´eation du paire de r´eper- toire avec ecryptfs. On peut donc se tromper sur la pass- phrase `a la cr´eation, ne pas s’en rendre compte et donc ne pas avoir le bon passphrase pour r´ecup´erer nos donn´ees. Une fois la configuration termin´ee, `a chaque fois qu’on veut mon- ter notre r´epertoire on doit par d´efaut donner en ligne de commande tous les param´etres qu’on avait choisi lors de la configuration mˆeme 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 `a prendre en main.
On peut trouver un tableau de comparaison des diff´erents syst`emes pr´esent´es 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´ecurit´e, ainsi que mon co-tuteur M. Levent DEMIR pour sa disponiblit´e et son aide `a la compr´ehension des syst`emes de fichiers chif- fr´es et mon troisi`eme encadrant, M. Amrit KUMAR pour m’avoir initi´ee aux probl`emes de retrait d’informations. Un grand merci `a eux pour leur patience et leur encouragement tout au long de ce semestre.
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.
[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.
[10] Wikipedia. Pir-private information retrieval.
http://en.wikipedia.org/wiki/Private_
information_retrieval.
