Disons que j'ai un dossier, dans mon dossier Documents, qui contient des fichiers auxquels je veux que personne n'ait accès sans mot de passe.
Existe-t-il un moyen de verrouiller ce dossier afin qu'il soit protégé par un mot de passe / crypté ?
En fait, est-il possible de protéger un dossier individuel par un mot de passe ?
Vous pouvez utiliser CryFS :
cryfs basedir mountdirIl est utilisé par défaut dans les coffres-forts KDE et est particulièrement intéressant si vous synchronisez le contenu crypté via Dropbox, Freefilesync, rsync ou un logiciel similaire, car il conserve ses données dans de petits blocs cryptés et la modification d'un petit fichier n'entraîne qu'une petite quantité de données à recharger.
Le cryptage au niveau du répertoire est risqué, préférez le cryptage au niveau du dispositif de bloc chaque fois que possible.
Je pense que Giles a mis le doigt sur plusieurs points essentiels aquí que je vais reproduire :
Utilisez le cryptage au niveau du périphérique de bloc. Linux fournit cela avec dm-crypt. Vous pouvez chiffrer soit l'ensemble du disque (à l'exception d'une petite zone pour le chargeur de démarrage), soit chiffrer
/homeou une autre partition. Si vous ne chiffrez pas l'ensemble du disque, gardez à l'esprit que des informations confidentielles peuvent se retrouver ailleurs, notamment dans l'espace d'échange (si vous avez des données chiffrées quelque part, vous devez chiffrer votre espace d'échange). Notez que si vous optez pour le chiffrement du disque entier, votre ordinateur ne pourra pas démarrer sans surveillance, vous devrez taper votre phrase de passe au clavier.Comme l'ensemble du dispositif de blocs est crypté, l'emplacement du contenu du fichier et des métadonnées ne peut pas être détecté par un attaquant qui vole le disque. À l'exception d'un en-tête au début de la zone cryptée, le contenu est indiscernable d'un bruit aléatoire. Un attaquant pourrait obtenir certaines informations en voyant plusieurs instantanés des données cryptées et en étudiant l'évolution des différents secteurs dans le temps, mais même avec cela, il serait difficile de trouver quelque chose d'intéressant, et cela ne s'applique pas si vous arrêtez de modifier les données après que l'attaquant a vu le texte chiffré (comme dans le cas d'un vol de disque).
Notez également que si vous cryptez quelque chose à l'intérieur de votre maison et non l'ensemble de la maison elle-même, plusieurs programmes courants peuvent entraîner des fuites de données, à moins que vous ne soyez extrêmement prudent. Par exemple : .bash_history les sessions d'édition et l'historique des annulations, etc.
Quelques conseils sur la manière de procéder :
fscrypt après une installation non cryptée (le programme d'installation dispose d'une option permettant de crypter le répertoire personnel)
Configuration manuelle d'eCryptfs
Cette réponse a décrit les aides d'Ubuntu pour cela (par ex. ecryptfs-setup-private ), mais vous pouvez obtenir plus de contrôle (par exemple, des répertoires de montage différents et séparés) et de compréhension en le montant vous-même.
eCryptfs fait déjà partie du noyau Linux et déjà activé par défaut sur Ubuntu via CONFIG_ECRYPT_FS=y donc vous pouvez simplement le monter. Faire partie du noyau est aussi généralement un indicateur positif de qualité et de stabilité.
Je dispose des aides suivantes :
export ECRYPTFS_DIR="$HOME/ecryptfs"
export ECRYPTFS_DATA_DIR="$HOME/.ecryptfs-data"
ecry() (
# Mount ecryptfs.
if ! mountpoint -q "$ECRYPTFS_DIR"; then
sudo mount -t ecryptfs \
-o key=passphrase,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_passthrough=no,ecryptfs_enable_filename_crypto=yes \
"$ECRYPTFS_DATA_DIR" \
"$ECRYPTFS_DIR"
fi
)
ecryu() (
# Unmount ecryptfs.
sudo umount "$ECRYPTFS_DIR"
)L'utilisation est la suivante.
Montez d'abord le répertoire crypté :
ecryIl vous sera alors demandé de saisir une phrase de passe :
Passphrase:Supposons que nous choisissions imprudemment :
asdfpour qu'il s'imprime maintenant :
Filename Encryption Key (FNEK) Signature [87d04721f6b4fff1]:87d04721f6b4fff1 est un type de hachage dérivé de notre asdf mot de passe. Vous pouvez maintenant appuyer sur la touche entrée, et il dira :
Attempting to mount with the following options:
ecryptfs_unlink_sigs
ecryptfs_fnek_sig=87d04721f6b4fff1
ecryptfs_key_bytes=16
ecryptfs_cipher=aes
ecryptfs_sig=87d04721f6b4fff1
Mounted eCryptfsce qui signifie que le montage a réussi.
Maintenant, faisons quelques fichiers cryptés de test :
echo AAAA > ~/ecryptfs/aaaa
echo BBBB > ~/ecryptfs/bbbb
dd if=/dev/zero bs=1k count=1k > ~/ecryptfs/zzzzSi on le démonte :
ecrycomme prévu le répertoire est vide :
ls -l ~/ecryptfsLes données eCryptfs elles-mêmes sont contenues dans le fichier ~/.ecryptfs-dat que nous avons passé à la commande mount.
Quel que soit le point de montage, tant que nous utilisons ce répertoire comme répertoire de données, le contenu du point de montage non crypté sera le même.
Observons son contenu :
ls -lh ~/.ecryptfs-dataCela montre trois fichiers cryptés :
-rw-rw-r-- 1 ciro ciro 12K Nov 11 17:15 ECRYPTFS_FNEK_ENCRYPTED.FWa5o2QVxfHzwEQ-GALjie5YM3J8aETCQqcZB.pJ2KyM4SRZWVvHGnAYi---
-rw-rw-r-- 1 ciro ciro 12K Nov 11 17:15 ECRYPTFS_FNEK_ENCRYPTED.FWa5o2QVxfHzwEQ-GALjie5YM3J8aETCQqcZMnVJY0WbH6bqRaee1cD5xU--
-rw-rw-r-- 1 ciro ciro 1.1M Nov 11 17:15 ECRYPTFS_FNEK_ENCRYPTED.FWa5o2QVxfHzwEQ-GALjie5YM3J8aETCQqcZf.vz0tLUzh41PwVFAnHc5k--C'est ce que nous observons :
Nous pouvons maintenant vérifier si ces fichiers sont réellement cryptés :
grep aaaa ~/.ecryptfs-data/*
grep AAAA ~/.ecryptfs-data/*qui ne donne aucune correspondance, donc ils sont probablement cryptés.
L'avantage de la méthode de stockage de ces fichiers cryptés est que vous pouvez facilement les sauvegarder n'importe où en les copiant sur un support non crypté à l'aide d'une clé USB. rsync et seuls les fichiers périmés seront copiés. Dans ce cas, il n'est même pas nécessaire d'entrer d'abord votre mot de passe !
Ce qui n'est pas cool, c'est qu'un attaquant qui tente de prouver que vous détenez un élément d'information connu pourrait le prouver en comparant la taille des fichiers et la structure des répertoires. comme mentionné par Giles .
Maintenant, on remonte :
ecryUne fois de plus, il vous demande le mot de passe.
Supposons que vous entrez un mauvais mot de passe :
asdfqweril s'imprimera maintenant :
Filename Encryption Key (FNEK) Signature [c55c6f13e73332d3]:
Attempting to mount with the following options:
ecryptfs_unlink_sigs
ecryptfs_fnek_sig=c55c6f13e73332d3
ecryptfs_key_bytes=16
ecryptfs_cipher=aes
ecryptfs_sig=c55c6f13e73332d3
WARNING: Based on the contents of [/root/.ecryptfs/sig-cache.txt],
it looks like you have never mounted with this key
before. This could mean that you have typed your
passphrase wrong.
Would you like to proceed with the mount (yes/no)? :Nous observons donc que la FNEK pour asdfqwer est différent de celui de la bonne asdf mot de passe : c55c6f13e73332d3 .
Si nous décidons de monter quand même avec yes il demande ensuite :
Would you like to append sig [c55c6f13e73332d3] to
[/root/.ecryptfs/sig-cache.txt]
in order to avoid this warning in the future (yes/no)? :et si nous entrons yes il ajouterait, comme promis, le FNEK à la liste de l'UE. /root/.ecryptfs/sig-cache.txt . Disons que non pour l'instant. Nous pouvons vérifier ce que contient ce fichier :
sudo cat /root/.ecryptfs/sig-cache.txtil ne contient actuellement que le asdf FNEK :
87d04721f6b4fff1donc nous comprenons que c'est juste une liste blanche de bons mots de passe connus.
Maintenant, voyons ce que nous obtenons avec le mauvais mot de passe :
ls -l ~/ecryptfset nous voyons que le répertoire est vide, comme vous pouvez vous y attendre. Il semble que chaque fichier du répertoire de données doive contenir une sorte de données de vérification du mot de passe, et qu'il ne soit pas monté.
Si nous umount et revenir au mot de passe correct asdf il demandera à nouveau la confirmation de FNEK, ce qui est un peu ennuyeux.
Filename Encryption Key (FNEK) Signature [87d04721f6b4fff1]:Nous pouvons éviter que cela se produise à chaque fois, comme indiqué à l'adresse suivante Comment spécifier automatiquement la clé de cryptage du nom de fichier avec ecryptfs ? en ajoutant :
-o ecryptfs_fnek_sig=à la commande mount. TODO : le fait de connaître le FNEK aiderait-il les attaquants à craquer le mot de passe ?
Enfin, lorsque le répertoire ecryptfs est monté, nous pouvons le voir sous :
grep ecryptfs /proc/mounts qui contient une ligne de type :
/home/ciro/.ecryptfs-data /home/ciro/ecryptfs ecryptfs rw,relatime,ecryptfs_fnek_sig=d066f6dcf72ad65a,ecryptfs_sig=d066f6dcf72ad65a,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0Testé sur Ubuntu 20.04, noyau Linux 5.4.
ecryptfs vs CryFS vs EncFS
Ce sont toutes des méthodes au niveau de la direction, il serait donc bon de comprendre leurs compromis, certaines comparaisons :
https://wiki.archlinux.org/index.php/EncFS#Comparison_to_eCryptFS
eCryptFS est implémenté dans l'espace noyau et est donc un peu plus difficile à configurer. Vous devez vous souvenir de diverses options de cryptage (cyphers utilisés, type de clé, etc...). Avec EncFS ce n'est pas le cas, car il stocke les informations de métadonnées de cryptage dans un fichier de configuration par répertoire (.encfs6.xml). Vous n'avez donc rien à retenir (sauf la phrase de passe).
Les performances des deux dépendent du type d'activité du disque. Alors qu'eCryptFS peut être plus rapide dans certains cas parce qu'il y a moins de surcharge due au changement de contexte (entre le noyau et l'espace utilisateur), EncFS a des avantages dans d'autres cas parce que les métadonnées de cryptage sont centralisées et ne sont pas stockées dans les en-têtes des fichiers individuels. Pour plus d'informations, des exemples de benchmark sont fournis par le projet EncFS.
Cryptage complet du disque au moment de l'installation (sauf /boot )
Je n'arrive pas à trouver "la question" pour cela, alors voici une expérience basée sur QEMU aquí avec Ubuntu 20.04.1.
Vous cliquez :
Il vous demande ensuite un mot de passe à l'étape suivante :
Maintenant, à chaque fois que vous démarrez, la toute première chose que vous voyez, (TODO avant ou après le bootloader ?), est une demande de mot de passe :
Et après ça, si vous entrez le bon mot de passe, il y a un démarrage normal.
Après s'être connecté, à partir de l'intérieur d'un Shell on fait :
lsblket ça donne :
sda 8:0 0 1T 0 disk
sda1 8:1 0 512M 0 part /boot/efi
sda2 8:2 0 1K 0 part
sda5 8:5 0 731M 0 part /boot
sda6 8:6 0 1022.8G 0 part
sda6_crypt 253:0 0 1022.8G 0 crypt
vgubuntu-root 253:1 0 1021.8G 0 lvm /
vgubuntu-swap_1 253:2 0 976M 0 lvm [SWAP]donc il semble que la deuxième étape du bootloader sous /boot lui-même n'est pas crypté, mais le répertoire racine et le swap le sont.
Comme mentionné à : https://help.ubuntu.com/community/Full_Disk_Encryption_Howto_2019 Cela vous expose au risque qu'un attaquant puisse compromettre votre machine en manipulant le dossier de démarrage, à votre insu, et l'utiliser pour extraire ultérieurement vos clés de décryptage si vous continuez à utiliser la machine.
Cryptage complet du disque au moment de l'installation (y compris /boot )
Il ne semble pas y avoir de moyen automatisé de le faire à partir de la version 20.04, mais nous espérons que cela sera implémenté tôt ou tard, par des guides manuels :
La sécurité du cryptage des ordinateurs portables est mise hors service.
OK, nous arrivons maintenant à un niveau de paranoïa opsec de type CIA/Silk Road : comment s'assurer rapidement que vos données ne pourront pas être décryptées si vous êtes pris avec l'ordinateur allumé et que vous avez une seconde pour agir.
Tout d'abord, la suspension vers la RAM ne semble pas être suffisante, l'hibernation sera plus judicieuse :
L'hibernation semble sauvegarder les données dans la partition swap, donc tant que votre swap est crypté (ce qu'il devrait évidemment être dans un paramètre de cryptage, sinon votre RAM va fuir), il devrait être en sécurité.
Maintenant, sur un ordinateur portable, la meilleure méthode est probablement une action de fermeture du couvercle, par ex. ce poste mentionne que :
HandleLidSwitch=hibernatesur /etc/systemd/logind.conf devrait fonctionner
Vous pouvez également configurer un raccourci clavier ou une action sur le bouton d'alimentation. Comment mettre en hibernation à partir du CLI : Comment mettre en hibernation sur Ubuntu 16.04 ? mentions :
sudo systemctl hibernateVous pouvez également utiliser gocryptfs . D'après mon expérience, il est nettement plus rapide que cryfs avec de gros partages chiffrés, mais ne cache pas la structure (taille des fichiers et nombre de fichiers). Selon votre modèle de menace, cela peut ou non être un problème.
Pour installer
apt install gocryptfsPour initialiser le répertoire de base (une fois)
gocryptfs -init basedirPour monter basedir (la version chiffrée) sur mountdir (la version non chiffrée)
gocryptfs basedir mountdirSystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.
