Quelle est la résistance des volumes chiffrés VeraCrypt et LUKS contre la corruption de données?
La question a été en partie résolue, mais ce n'est toujours pas ce que je recherche exactement. Voir pour la mise à jour 1 bas bere
Je prévois de chiffrer certains systèmes de fichiers avec VeraCrypt et LUKS, mais je crains que si un seul problème se produisait, je ne pourrais plus monter les partitions et perdre ainsi toutes les données stockées en leur sein. (dus à des secteurs/blocs endommagés, une panne de courant pendant une opération d'écriture, des erreurs de système de fichiers, etc.)
En outre, VeraCrypt a peut-être créé les outils de réparation de TrueCrypt, mais je ne compte pas sur cela et je ne cherche pas davantage sur des cas réels.
Je connais aussi le RAID et les sauvegardes/coffres-forts, mais ce n'est pas ce que je recherche.
La question est donc la suivante: quelle est la résilience des partitions chiffrées avec VeraCrypt et LUKS?
Mise à jour 1 :
Ma question porte davantage sur la résilience de la partition chiffrée et de ses données que sur la sauvegarde de la clé principale, des métadonnées ou des en-têtes. Le problème est similaire à une archive 7Zip solide: si un seul bit est endommagé au milieu, vous perdez l’archive entière.
Les partitions chiffrées seront-elles aussi vulnérables? (à l'exclusion de la clé principale, des métadonnées et des en-têtes)
PS: Désolé si je ne réponds pas tout de suite, je travaille et je fais le tour du monde - maintenant, je poste ce poste de manière reliée - et je suis souvent confronté à une affaire pressante. Mais, je vais certainement répondre à coup sûr.
Grâce à toutes les réponses fournies, la réponse définitive est complète à 100%.
Je n'ai pas beaucoup de temps ces jours-ci, je vais donc éditer ma "propre" réponse plus tard. Étant donné que toutes les réponses que les gens ont données ici sont tout à fait utiles, nous ne ferons que récapituler ce qu’ils ont dit, ainsi que mes conclusions.
Quoi qu'il en soit, voici l'une de mes constatations qui dissipera beaucoup de confusion que j'ai rencontrée, et elle concernait principalement ... ce que signifie "bloc", car il s'agit d'un terme trop utilisé à tort:
https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/
En outre, vous trouverez ici un moyen "standard" de parler de choses et d'éviter la confusion qui règne entre les blocs:
https://superuser.com/questions/1176839/what-are-every-possible-names-of-hard-drives-structure-parts
En bref, vous pouvez changer un bloc chiffré contenant le mot "400" en "800". Cela signifie que la couche cryptée au niveau du bloc est complètement non solide, au lieu de penser que "cela agira comme un système de fichiers normal" (c'est-à-dire la FAQ de Veracrypt).
De plus, j'aurais dû tomber sur ce lien il y a deux mois:
Puisque VeraCrypt est un fork de TrueCrypt, il fonctionnera certainement de la même manière.
PS:
Toute réponse supplémentaire est toujours la bienvenue et sera ajoutée à ma "propre" réponse.
En pratique, le chiffrement est presque aussi résistant que sans le chiffrement, tant que vous sauvegardez correctement la clé principale et les métadonnées .
Outre les métadonnées, la corruption affecterait uniquement le bloc du bit corrompu, dans la plupart des cas, 16 octets seulement.
Dans la plupart des situations de corruption de données, avec la clé et les outils (comme votre mot de passe et Veracrypt/LUKS), vous avez le même accès qu'un disque non crypté, comme vous le faites normalement avec l'utilisation quotidienne d'un disque crypté. Le chiffrement ne ferait qu'ajouter une étape supplémentaire (ouvrir une partition chiffrée) à celle habituelle. Donc, dans ce cas, il se comporte comme des données non chiffrées.
Avec Veracrypt ou Luks, vous devez stocker la clé principale sur le disque, qui est crypté avec votre mot de passe. Endommager ce (s) secteur (s) provoquerait une perte de données permanente Ce problème peut être facilement résolu avec une sauvegarde de clé principale (de quelques kilo-octets), quelque chose de facile à faire avec les deux logiciels, hautement recommandée à tous.
Détails sur les métadonnées non
Veracrypt et Luks utilisent tous deux XTS aujourd'hui. Dans ce mode, une clé est calculée pour chaque bloc. Dans une simplification, pour chiffrer le bloc i, vous utilisez une clé générée avec les clés principales et le numéro de bloc. Ainsi, le cryptage d'un bloc est indépendant d'un autre. Si vous corrompez des informations, il sera limité à ce bloc.
Dans XTS, le bloc est divisé en sous-blocs (généralement de 16 octets), il crée une clé et le chiffre avec ce sous-bloc. Cela signifie que si nous changeons un peu, seuls ces 16 octets seront affectés.
En tant que test, en changeant un bit dans un volume Luks, il modifie 16 octets du fichier d'origine en charabia, mais les 496 autres restent immobiles. Dans un fichier 7Zip, il utilise une méthode de flux, c'est-à-dire que tous les octets sont chaînés. Un changement d'octet aurait donc une incidence sur tous les autres. Ce n'est pas le cas ici.
Certains considèrent cela comme un problème, comme vous pouvez le savoir avec une précision de 16 octets quand et où vous modifiez un texte brut, en comparant uniquement les données cryptées.
Des informations plus intéressantes à ce sujet peuvent être trouvées sur ces liens:
https://crypto.stackexchange.com/questions/6185/what-is-a-tweakable-block-cipher
https://en.wikipedia.org/wiki/Disk_encryption_theory
Détails sur la clé maîtresse
LUKS
LUKS ont quelques secteurs au début de la partition (ou du disque) avec des métadonnées, stockant des méthodes de cryptage, d'autres paramètres et 8 emplacements de clé. Pour chiffrer et déchiffrer le disque, il utilise une clé principale , un grand nombre aléatoire généré lors de la création d'un conteneur LUKS. Pour la stocker, la clé principale est chiffrée avec votre mot de passe, en répétant plusieurs fois la fonction de hachage cryptographique sur le mot de passe et en générant une clé spécifique pour cet emplacement. Vous pouvez avoir 8 mots de passe différents pour le même disque, chacun cryptant la clé principale avec un mot de passe différent dans un emplacement. Lorsque vous changez le mot de passe, c’est aussi simple que de chiffrer la clé principale et non de changer toute la partition.
Ainsi, lorsque ces emplacements et métadonnées sont corrompus, vous ne pouvez pas récupérer la clé principale qui est réellement utilisée pour décrypter, perdant ainsi toutes les données sur le disque. C'est un moyen facile de détruire rapidement toutes vos données. Mais si vous avez une sauvegarde de l'en-tête de volume, il est assez facile de le récupérer.
Vous trouverez ci-dessous une copie de LUKS FAQ à propos de la sauvegarde extraite de https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentAskedQuestions#6-backup-and-data- récupération
Bien que vous puissiez simplement copier le nombre d'octets approprié à partir du début de la partition LUKS, le meilleur moyen consiste à utiliser l'option de commande "luksHeaderBackup" de cryptsetup. Cela protège également contre les erreurs lorsque des paramètres non standard ont été utilisés dans la création de partitions LUKS. Exemple:
cryptsetup luksHeaderBackup --header-backup-file <file> <device>
Pour restaurer, utilisez la commande inverse, c.-à-d.
cryptsetup luksHeaderRestore --header-backup-file <file> <device>
Si vous n'êtes pas sûr d'un en-tête à restaurer, effectuez d'abord une sauvegarde de l'en-tête actuel! Vous pouvez également tester le fichier d'en-tête sans le restaurer en utilisant l'option --header pour un en-tête détaché comme ceci:
cryptsetup --header <file> luksOpen <device> </dev/mapper/ -name>
Si cela déverrouille vos clés, vous êtes bon. N'oubliez pas de refermer l'appareil.
Dans certaines circonstances (en-tête endommagé), cela échoue. Ensuite, utilisez les étapes suivantes:
Déterminez d'abord la taille de la clé principale:
cryptsetup luksDump <device>
donne une ligne de la forme
MK bits: <bits>
avec des bits égaux à 256 pour les anciennes valeurs par défaut et à 512 pour les nouvelles valeurs par défaut. 256 bits correspondent à une taille totale d'en-tête de 1'052'672 octets et à 512 bits, l'un de 2 Mo. (Voir aussi la rubrique 6.12) Si luksDump échoue, supposons 2MiB, mais sachez que si vous restaurez cela, vous pouvez également restaurer environ 1M du système de fichiers. Ne changez pas le système de fichiers si vous ne parveniez pas à déterminer la taille de l'en-tête! Avec cela, la restauration d'une sauvegarde d'en-tête trop grande est toujours sûre.
Deuxièmement, videz l'en-tête dans le fichier. Il y a plusieurs façons de le faire, je préfère ce qui suit:
head -c 1052672 <device> > header_backup.dmp
ou
head -c 2M <device> > header_backup.dmp
pour un en-tête 2MiB. Vérifiez la taille du fichier de vidage pour en être sûr. Pour restaurer une telle sauvegarde, vous pouvez essayer luksHeaderRestore ou effectuer une analyse plus basique.
cat header_backup.dmp > <device>
Veracrypt
Veracrypt est similaire à LUKS. Je ne suis pas habitué à cela, contrairement à Truecrypt, mais l’idée générale est valable.
Veracrypt n'a qu'un seul emplacement de clé, vous ne pouvez donc pas avoir plus d'un mot de passe à la fois. Mais vous pouvez avoir un volume caché: il stocke les métadonnées à la fin de la partition (ou du disque ou du fichier). Le volume caché a une clé principale différente et utilisera la fin de la partition comme espace superposé. L'idée que vous devriez sauvegarder est la même. Cela peut être fait avec Tools -> Backup Volume Header et Tools -> Restore Volume Header. Avec le chiffrement du système, il était utilisé pour créer un disque amorçable avec une sauvegarde de clé qui récupère le chargeur Truecrypt et les clés en cas de dommage. Cela est fait avant de chiffrer quoi que ce soit et, autant que je sache, Veracrypt continue à faire de même.
Pour plus de détails voir ce lien https://veracrypt.codeplex.com/wikipage?title=Program%20Menu
Considérations de sécurité sur les clés de sauvegarde
Si vous avez un mot de passe divulgué, par exemple, et que vous modifiez le mot de passe du volume en un nouveau, fort et sécurisé, une personne ayant accès à la sauvegarde sera toujours en mesure de déchiffrer les fichiers avec l'ancien mot de passe. La sauvegarde est essentiellement la clé principale cryptée avec le mot de passe (ancien). Ainsi, lors du changement de mots de passe, il est également nécessaire de créer une nouvelle sauvegarde et de détruire les anciens. Et détruire des données en permanence peut être très compliqué.
Pour chaque sauvegarde que vous avez avec ce mot de passe, il est possible de décrypter des données avec ce mot de passe. Cela peut être utilisé dans Veracrypt par exemple, en utilisant un "mot de passe universel" (comme dans une entreprise), en le sauvegardant et en le remplaçant par un autre mot de passe. Donc, le département informatique. peut récupérer l'accès à ce volume même si quelqu'un perd le mot de passe (pensez en tant que mot de passe principal, mais ne confondez pas avec la clé principale précédente).
Pensées finales (TL; DR)
La probabilité d'endommager le secteur spécifique avec la clé principale est moins probable qu'une défaillance totale du disque. Par conséquent, si ces données sont importantes, vous devez en faire une copie de sauvegarde uniquement à partir des en-têtes de volume (clé principale).
Et la corruption des données s'est peu étendue (16 octets), ce qui est acceptable pour la plupart des utilisations.
Ainsi, un bloc défectueux au milieu de la partition ou du disque n'affectera que ce bloc. Et quelques erreurs de bits dans un secteur sont limitées à ce secteur et n’affecteront même pas totalement un secteur de 512 octets.
Mise à jour (23/01/2017): ajoutez des informations supplémentaires en fonction des commentaires de l'OP.
J'ai compilé ci-dessous des informations sur la résilience des conteneurs VeraCrypt/TrueCrypt.
De corruption de données Veracrypt :
TC/VC stocke l'en-tête de volume à deux endroits: au début et à la fin du volume. Celui au début est le principal et celui à la fin est pour la sauvegarde. Ce mécanisme est généralement suffisant pour permettre l'accès lorsqu'une partie du lecteur est endommagée ou corrompue car les dommages sont souvent locaux. si le début et la fin du disque sont endommagés, le lecteur est presque certainement mort.
Veuillez noter qu'en cas de disque endommagé ou corrompu, vous subissez la même perte de données que lorsque vous n'utilisez pas le cryptage. Cela signifie que même si vous êtes capable de monter le volume, il est possible que les données lues soient corrompues. Alors, pensez toujours à la sauvegarde des données car le cryptage ne protège pas contre la corruption des données.
À partir de la FAQ VeraCrypt :
Que se passera-t-il lorsqu'une partie d'un volume VeraCrypt est corrompue?
Dans les données cryptées, un bit corrompu corrompt généralement tout le bloc de texte chiffré dans lequel il s'est produit. La taille de bloc de texte chiffré utilisée par VeraCrypt est de 16 octets (c'est-à-dire 128 bits). Le mode de fonctionnement utilisé par VeraCrypt garantit que si une corruption de données survient dans un bloc, les blocs restants ne sont pas affectés.
Que dois-je faire lorsque le système de fichiers crypté sur mon volume VeraCrypt est corrompu?
Le système de fichiers d'un volume VeraCrypt peut être corrompu de la même manière que tout système de fichiers non crypté normal. Lorsque cela se produit, vous pouvez utiliser les outils de réparation de système de fichiers fournis avec votre système d'exploitation pour le réparer. Sous Windows, c'est l'outil 'chkdsk'. VeraCrypt offre un moyen simple d'utiliser cet outil sur un volume VeraCrypt: Cliquez avec le bouton droit de la souris sur le volume monté dans la fenêtre principale de VeraCrypt (dans la liste des lecteurs) et sélectionnez "Réparer le système de fichiers" dans le menu contextuel.
Une petite corruption de données ne devrait alors avoir qu'un effet local et ne détruira pas tout le conteneur. Cependant, je déconseille de chiffrer tout un volume/partition et en particulier le lecteur système, car la récupération peut alors être plus compliquée. Effectuez de bonnes sauvegardes, en particulier pour l'en-tête de volume. Et rappelez-vous que, tout comme pour un disque ou un dossier réel, une corruption dans les en-têtes de disque/fichier peut rendre la récupération de données difficile et peut nécessiter des utilitaires avancés.
Je crois que LUKS n’a pas de deuxième en-tête sur le disque, vous devez donc être encore plus prudent lors de la sauvegarde.