SMPFR

Plop!

Je documente/partage ici un petit comparatif de softs de chiffrement unitaire de fichiers sous Windows.
Mon but est d'avoir un truc relativement simple et maîtrisé pour chiffrer des répertoires et des fichiers avant de les stocker dans le nuage (hubiC ou autre). Truecrypt n'est pas adapté pour cela.
Comme je souhaite aussi que le mécanisme de chiffrement soit multi-plateforme (ie je veux pouvoir déchiffrer depuis un Linux ou un BSD) je cherchais au départ un client encFS pour Windows.

PC de test : core i7-4790S 4C/8T avec instruction AES-NI + 16Go de RAM // Win7 ultimate x64
Toutes les opérations disques (lecture des fichiers sources et écriture du résultat chiffré) se font sur un SSD PCI-Ex Revodrive X2.

Bien sûr j'ai utilisé le même jeu de données pour faire un comparatif valable. On trouve dedans un album en FLAC, un des MP3, des photos en JPG, des vidéos MKV/MP4/AVI/WMV, des archives ZIP, des exécutables, une sauvegarde MailStore (fichiers DAT), des PDF et des TXT.
Total = 2,72 Go

Passphrase identique pour chaque soft.


*******************************************************************************

[*] EncFS MP x64 0.9.6 // http://encfsmp.sourceforge.net/ // profil Paranoïa AES avec clé 256 bits pour le chiffrement

Je copie mon dataset dans le lecteur virtuel présenté par le soft, le chiffrement se fait à la volée pendant la copie.
Durée de la copie :


Espionnage du process pendant qu'il bosse :


Ce que j'en pense :
[*]Le contenu est bien chiffré, y compris le nom de chaque répertoire et chaque fichier. Les fichiers n'ont pas d'extension. Pas testé la faisabilité du déchiffrement depuis un Linux mais je vois pas ce qui poserai problème.
[*]L'interface est simple et claire, on s'y retrouve très vite. C'est en anglais par contre.
[*]On peut choisir de garder la passphrase en RAM pour monter/démonter un volume chiffré à la volée tant que le soft reste ouvert.
[*]Bref du bon boulot.


*******************************************************************************

[*] Safe v1.4 // http://www.getsafe.org // encFS AES 256 bits

Ce soft fait tourner un serveur WebDAV local pour présenter le volume chiffré au système comme si c'était un lecteur réseau.
Déjà je constate que le montage du volume est sensiblement plus long.
Ensuite je lance la copie de mes fichiers... et là c'est le drame! La copie met beaucoup de temps à démarrer, et reste très lente par la suite... Copie annulée après 6min30 et seulement 6% d'avancement.

Mais que fait le process... :


Ce que j'en pense :
[*]... bah c'est de la m*rde :/
[*] euh et c'est quoi cette activité réseau alors que je suis sur un disque local ?! un rapport avec le fait que le développeur soit employé par Dropbox ..??


*******************************************************************************

[*] Cloudfogger 1.4.2160 // https://www.cloudfogger.com/en/ // AES 256 bits mais le site ne dit pas clairement si c'est du encFS à l'intérieur

Soft similaire à BoxCryptor (payant) signalé par micha.
Bon pas chaud au début avec l'histoire du compte à créer chez eux, sur un mode webservice. Après j'ai vu l'existence du mode "local" à choisir lors de l'installation. Mais c'est pas clair quand même... cf plus bas.

Copie de mon dataset dans le répertoire chiffré par Cloudfogger.
Durée de la copie :


Espionnage du process pendant qu'il bosse :


Ce que j'en pense :
[*]Le mode local va quand même créer une sorte de compte avec un identifiant (6 chiffres) et notre password/passphrase. Il faut s'identifier dans l'appli avec cet id pour lire le volume chiffré. Et l'appli propose d'upgrader son compte vers un compte web qui semble permettre la "sauvegarde" de sa passphrase chez eux... J'ai p'tet mal compris mais pour du chiffrement symétrique leur modèle me pose un problème. :/
[*]Perfs un peu moins bonne que EncFS MP mais ça marche quand même bien.
[*]Le nom des fichiers et des répertoires restent en clair !! Pas terrible
[*]Les fichiers chiffrés récupèrent une extension .cfog
[*]je doute de la possibilité de déchiffrer sous Linux avec commandes encfs // des utilisateurs réclament un client Linux, ça semble indiquer que ce n'est pas le cas ...
[*]Comme Safe, la trace du process indique une petite activité réseau qui n'a pas lieu d'être


*******************************************************************************

[*] CryptSync x64 1.2.1 // http://stefanstools.sourceforge.net/CryptSync.html // AES 256 bits via les options de chiffrement de 7-zip

Un dernier soft avec une approche sympa qui n'est pas du encFS >> les fichiers sont chiffrés et compressés individuellement par 7-zip.
Le résultat est donc un paquet de petites archives 7z qui seront tout à fait manipulables sous un autre OS. Bon ça peut vite devenir galère si tu dois déchiffrer 100 fichiers sous Linux en ligne de commande....

Un peu plus galère de mesurer les perfs ici. J'ai copié le dataset dans le dossier source à l'avance puis j'ai activé le chiffrement en background et j'ai regardé dans les logs du soft l'horodatage des opérations
>> 6min 24sec

Pas tellement possible de tracer un process non plus pcq c'est une flopée de process 7z qui font le taff. L'avantage c'est qu'il est massivement parallélisé. Les 8 threads sont utilisés alors que les autres softs utilisaient seulement les 4 cores physiques. C'est pas plus perf pour autant ....

Ce que j'en pense :
[*]bah déjà que j'ai eu 21 fichiers en erreur et donc non présent dans le répertoire chiffré, à priori à cause d'un nom de fichier ou chemin trop long
[*]les logs contiennent toutes les opérations, avec les noms et chemins des fichiers :/
[*]choix de chiffrer ou non les noms des fichiers et des répertoires
[*]possibilité d'exclure automatiquement certains fichiers (par défaut le masque fourni : *.tmp*|~*.*|thumbs.db|desktop.ini )
[*]possibilité de filtrer certains fichiers pour qu'ils soient copiés mais pas chiffrés


*******************************************************************************

Deux tweaks pas inutiles pour la sécurité des données

*******************************************************************************

Quand la RAM est pleine, le système utilise la mémoire virtuelle (swap) qui est un fichier sur le disque. Son contenu est plus facilement lisible que la RAM. On peut imaginer qu'un exploit cherche des passphrase ou du contenu déchiffré à cet endroit.
Par défaut ce fichier n'est pas chiffré mais on peut demander à Windows de le faire.

Il faut ouvrir un cmd avec les droits admin puis saisir la commande :

> fsutil behavior set EncryptPagingFile 1

*******************************************************************************

De la même manière, la mise en veille prolongée va enregistrer une copie intégrale de la RAM sur le disque. Du coup on la désactive.

Il faut ouvrir un cmd avec les droits admin puis saisir la commande :

> powercfg /hibernate off

nice job!

+1

Coïncidence sympa, j'en parlais vendredi après midi avec un pote.

Petit hs, avec quel soft fais tu la copie ?

L'idée de chiffrer ses trucs pour du backup sensible/perso/privé sur dropbox/hubic/skydrive/gdrive, ça doit titiller un paquet de monde je pense ouais ^^

Sinon la copie de fichiers c'est dans mon gestionnaire de fichiers XYplorer : http://xyplorer.com/index.php

Je suis retourné voir un peu le fonctionnement de Cloudfogger sur le côté "webservice" qui me troublait un peu :

Le mode local va quand même créer une sorte de compte avec un identifiant (6 chiffres) et notre password/passphrase. Il faut s'identifier dans l'appli avec cet id pour lire le volume chiffré. Et l'appli propose d'upgrader son compte vers un compte web qui semble permettre la "sauvegarde" de sa passphrase chez eux... J'ai p'tet mal compris mais pour du chiffrement symétrique leur modèle me pose un problème. :/

Un bon point : le fonctionnement est bien documenté dans la base de connaissances accessible sur leur site.
Les deux pages importantes sont :
[*] How secure is Cloudfogger?
[*] What type of encryption does Cloudfogger use?

En fait le mécanisme utilisé est identique à celui mis en place par OwnCloud pour un chiffrement côté serveur. Ce mécanisme est expliqué dans ce billet ou dans cette doc.

Rapidement : chaque fichier est chiffré [symétrique AES] avec une clé unique. Cette clé est chiffrée avec la ou les clé(s) publique(s) [asymétrique RSA] des utilisateurs qui doivent pouvoir y accéder.
Le seul moyen de retrouver les données est d'avoir la clé privée qui déchiffre la clé AES unique qui déchiffre les data! Ouf!!

Au final le password de l'utilisateur sert seulement à chiffre sa clé privée personnelle, mais pas les données. C'est un peu usine à gaz mais ça permet de partager des documents chiffrés entre plusieurs personnes sans avoir à partager une passphrase. Le principe est bon techniquement, no soucÿ.
Juste une remarque technique : il y a autant de clé unique que d'utilisateurs autorisés qui viennent se greffer au fichier >>> légère augmentation de la taille du fichier. Partager un TXT de 100ko avec 15 potes pourrait bien doubler la taille du résultat crypté.
Bon maintenant là où c'est moins attirant c'est sur ce point :

the encrypted private key is stored on the Cloudfogger server for simplicity reasons - you don't need to move a key file to get Cloudfogger to new/multiple system(s).

Mouais okay... c'est vrai que c'est plus simple pour l'utilisateur que s'il devait promener sa clé privée en plus de se souvenir de son password.
Mais bon ça veut dire que la clé privée est aussi chez eux, sur un webservice. Chiffrée certes.

Et le dernier point à noter, si l'utilisateur qui dispose d'un compte web active l'option de récupération de son password alors :

with password recovery activated, the password hash gets stored on the Cloudfogger servers

Donc la super passphrase qui fait tenir tout votre chiffrement est stockée hashée chez eux. Pas plus de détails techniques sur la nature du hash!



******************************************************************************************

En bref :
1/ perso je n'ai de besoin de partage dans mon cas d'usage >>> je reste sur EncFS MP
2/ pour un besoin ponctuel de partage sécurisé/chiffré >>> une archive 7z chiffré en AES-256 avec le prénom du destinataire fera la blague
3/ si on veut partager un espace chiffré avec un groupe de personnes (travail en équipe par ex.) alors un Cloudfogger sera adapté, ou alors se monte un Owncloud/Pydio avec chiffrement

Un petit nouveau.
=> https://cryptomator.org/

Humm m'a lair bien foutu. Le process de chiffrement est clairement décrit et la liste des fonctions est complète :
Filename Encryption
File Header Encryption
File Size Obfuscation
File Content Encryption
Name Shortening

Clients Win/Linux/OSX fournis. C'est pas de l'encfs donc ça exclu un client "générique" pour Syno/QNAP mais pas très grave au final.

pour l'info!

Encore un autre.

https://www.viivo.com/

Amélioration sympa du côté de EncFSMP avec la 0.10.5 :

[*]Implemented pattern to upgrade from opening a file read-only to read-and-write (should fix bugs with seemingly read-only files)
[*]Updated OpenSSL to 1.0.2h, boost to 1.61.0. OpenSSL is now compiled to use assembly language and AES instructions, if present
[*]Updated PFM to 1.0.0.183, using new API

Du coup gain en performance avec un processeur doté des instructions AES (typiquement AES-NI chez Intel).

Un petit test rapide sur un dataset de 288,15 Mo composé de petits fichiers texte/image/doc/xls/pdf :
[*]51 sec pour copie + chiffrement avec EncFSMP 0.10.4
[*]45 sec pour copie + chiffrement avec EncFSMP 0.10.5

Volumes source et dest identiques, profil Paranoia AES-256 dans les deux cas.


Me reste à testouiller les softs de kali!