Quelle est la résistance des volumes chiffrés VeraCrypt et LUKS contre la corruption des données?

La question a été partiellement répondue, mais ce n'est toujours pas ce que je recherche exactement. Voir la mise à jour 1 en bas

Je prévois de chiffrer certains systèmes de fichiers avec VeraCrypt et LUKS, mais mes craintes sont que si un seul problème se produit, je ne serais pas en mesure de monter à nouveau les partitions, perdant ainsi toutes les données stockées à l'intérieur. (en raison de secteurs / blocs endommagés, d'une panne de courant pendant une opération d'écriture, d'erreurs de système de fichiers, etc.)

De plus, VeraCrypt a peut-être bifurqué les outils de réparation de TrueCrypt, mais je ne compte pas dessus et cherche plus sur des cas réels.

Je connais également 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ésistance des partitions chiffrées elles-mêmes 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, plutôt 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 toute l'archive.

Les partitions chiffrées seront-elles aussi vulnérables? (hors clé principale, métadonnées et en-têtes)

PS: Désolé si je ne réponds pas tout de suite, je travaille et voyage à travers le monde - ce qui rend ce post lié - et je suis souvent confronté à des contraintes de temps. Mais, je vais certainement répondre à coup sûr.

En pratique, il est presque aussi résilient avec le cryptage que sans, tant que vous sauvegardez correctement la clé principale et les métadonnées .

En dehors des métadonnées, la corruption affecterait uniquement le bloc du bit corrompu, dans la plupart des cas, seulement 16 octets.

Pour 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 ajouterait seulement une étape supplémentaire (ouvrir une partition chiffrée) que l'ordinaire. 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ée avec votre mot de passe. Endommager ce (s) secteur (s) entraînerait la perte permanente de données. Cela peut être facilement résolu avec la sauvegarde de la clé principale (quelques kilo-octets), quelque chose de facile à faire avec les deux logiciels, et il est fortement recommandé pour tout le monde.

Détails sur les non métadonnées

Veracrypt et Luks utilisent XTS aujourd'hui. Dans ce mode, il est calculé une clé pour chaque bloc. Dans une simplification, pour chiffrer le bloc, ivous utilisez une clé générée avec les clés principales et le numéro de bloc. Ainsi, le chiffrement d'un bloc est indépendant d'un autre. Si vous corrompez certaines informations, elles seront limitées à ce bloc.

Dans XTS, il casse le bloc en sous-blocs (de 16 octets en général) et crée une clé, et crypte ce sous-bloc avec lui. Cela signifie que si nous changeons un peu dessus, seuls ces 16 octets seraient affectés.

Comme test, en changeant un seul bit dans un volume Luks, il change 16 octets du fichier d'origine en charabia, mais les 496 autres restent inchangés. Dans un fichier 7zip, il utilise une méthode de flux, que tous les octets sont enchaînés, donc un changement d'octet affecterait tous les autres - ce n'est pas le cas ici.

Certains considèrent cela comme un problème, car vous pouvez savoir avec une précision de 16 octets quand et où vous modifiez un texte brut, en comparant uniquement les données chiffrées.

Des informations plus intéressantes à ce sujet peuvent être trouvées sur ces liens:

/crypto/6185/what-is-a-tweakable-block-cipher

/security/39306/how-secure-is-ubuntus-default-full-disk-encryption

https://en.wikipedia.org/wiki/Disk_encryption_theory

Détails sur la clé principale

LUKS

LUKS a quelques secteurs au début de la partition (ou disque) avec des métadonnées, stockant des méthodes de cryptage, d'autres paramètres et 8 emplacements de clé. Pour crypter et décrypter 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 le stocker, il crypte la clé principale avec votre mot de passe, en itérant plusieurs fois une 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 chiffrant 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 crypter la clé principale et de ne pas changer toute la partition.

Ainsi, lorsque ces emplacements et métadonnées sont corrompus, vous ne pouvez pas récupérer la clé principale réellement utilisée pour déchiffrer, perdant toutes les données sur le disque. Il s'agit d'un moyen simple 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 la récupérer.

Vous trouverez ci-dessous une copie de la FAQ LUKS sur la sauvegarde extraite de https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery

Bien que vous puissiez simplement copier le nombre approprié d'octets à partir du début de la partition LUKS, la meilleure façon est d'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 la partition 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, faites d'abord une sauvegarde de celui en cours! 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 celui-ci:

cryptsetup --header <file> luksOpen <device> </dev/mapper/ -name>

Si cela déverrouille votre lot de clés, vous êtes bon. N'oubliez pas de refermer l'appareil.

Dans certaines circonstances (en-tête endommagé), cela échoue. Suivez ensuite les étapes suivantes:

Déterminez d'abord la taille de la clé principale:

cryptsetup luksDump <device>

donne une ligne du formulaire

MK bits:        <bits>

avec des bits égaux à 256 pour les anciens paramètres par défaut et 512 pour les nouveaux paramètres par défaut. 256 bits équivaut à une taille totale d'en-tête de 1'052'672 octets et 512 bits de 2 Mo. (Voir également le point 6.12) Si luksDump échoue, supposez 2 Mo, mais sachez que si vous restaurez cela, vous pouvez également restaurer le premier 1 Mo environ du système de fichiers. Ne changez pas le système de fichiers si vous n'avez pas pu déterminer la taille de l'en-tête! Avec cela, la restauration d'une sauvegarde d'en-tête trop volumineuse est toujours sûre.

Ensuite, videz l'en-tête dans un fichier. Il y a plusieurs façons de le faire, je préfère les suivantes:

head -c 1052672 <device>  >  header_backup.dmp

ou

head -c 2M <device>  >  header_backup.dmp

pour un en-tête de 2 Mo. Vérifiez la taille du fichier de vidage pour être sûr. Pour restaurer une telle sauvegarde, vous pouvez essayer luksHeaderRestore ou faire une opération plus basique

cat header_backup.dmp  >  <device>

Veracrypt

Veracrypt est similaire à LUKS. Je n'y suis pas habitué comme je l'étais avec Truecrypt, mais l'idée générale tient.

Veracrypt n'a qu'un seul emplacement de clé, vous ne pouvez donc pas avoir plus d'un mot de passe en même temps. Mais vous pouvez avoir un volume caché: il stocke les métadonnées à la fin de la partition (ou disque ou 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 devez sauvegarder est la même. Cela peut être fait avec Tools -> Backup Volume Headeret Tools -> Restore Volume Header. Avec le chiffrement du système, il créait un disque amorçable avec une sauvegarde de clé qui récupère le chargeur et les clés Truecrypt en cas de dommage. C'est fait avant de crypter quoi que ce soit, et pour autant que je sache, Veracrypt continue de faire de même.

Pour plus de détails, consultez ce lien https://veracrypt.codeplex.com/wikipage?title=Program%20Menu

Considérations de sécurité sur les clés de sauvegarde

Par exemple, si vous avez un mot de passe divulgué et que vous changez le mot de passe du volume en un nouveau, fort et sécurisé, une personne ayant accès à la sauvegarde pourra toujours décrypter les fichiers avec l'ancien mot de passe. La sauvegarde est essentiellement la clé principale chiffrée avec (l'ancien) mot de passe. Ainsi, lors du changement de mots de passe, il est également nécessaire de faire une nouvelle sauvegarde et de détruire les plus anciens. Et détruire des données de façon permanente peut être très difficile.

Pour chaque sauvegarde que vous avez avec ce mot de passe, est un moyen possible de décrypter les 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 changeant pour un autre mot de passe. Donc, le département informatique. pourrait récupérer l'accès à ce volume même si quelqu'un a perdu le mot de passe (pensez comme un mot de passe principal, mais ne confondez pas avec la clé principale antérieure).

Réflexions finales (TL; DR)

La probabilité d'endommager le secteur spécifique avec la clé principale est moins probable que vous ayez une panne de disque complète. Donc, si ces données sont importantes, vous devriez en avoir une copie de sauvegarde à la place des en-têtes de volume (clé principale).

Et la corruption des données s'est peu répandue (16 octets), ce qui est acceptable pour la plupart des utilisations.

Ainsi, un mauvais bloc au milieu de la partition ou du disque n'affecterait 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 plus d'informations sur la base des commentaires OP.

J'ai compilé ci-dessous quelques informations sur la résilience des conteneurs VeraCrypt / TrueCrypt.

De la corruption des données Veracrypt :

TC / VC stocke l'en-tête du 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 les dommages se produisent au début et à la fin du lecteur, le lecteur est presque certainement mort.

Veuillez noter qu'en cas de lecteur endommagé ou corrompu, vous aurez la même perte de données que lorsque vous n'utilisez pas le cryptage. Cela signifie que même si vous pouvez monter le volume, les données lues peuvent être corrompues. Alors, pensez toujours à la sauvegarde des données car le chiffrement ne protège pas de la corruption des données.

De la FAQ VeraCrypt :

Que se passera-t-il lorsqu'une partie d'un volume VeraCrypt sera corrompue?

Dans les données chiffré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 (soit 128 bits). Le mode de fonctionnement utilisé par VeraCrypt garantit que si la corruption des données se produit 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 du système de fichiers fournis avec votre système d'exploitation pour y remédier. Sous Windows, c'est l'outil «chkdsk». VeraCrypt fournit un moyen simple d'utiliser cet outil sur un volume VeraCrypt: cliquez avec le bouton droit sur le volume monté dans la fenêtre principale de VeraCrypt (dans la liste des lecteurs) et dans le menu contextuel, sélectionnez «Réparer le système de fichiers».

La corruption de petites données ne devrait alors avoir qu'un effet local et ne détruirait pas le conteneur entier. Cependant, je déconseille de crypter un volume / partition entier et en particulier le lecteur système, car la récupération peut alors être plus compliquée. Faites de bonnes sauvegardes, en particulier pour l'en-tête du volume. Et rappelez-vous que, tout comme pour un disque ou un dossier réel, la corruption des en-têtes de disque / fichier peut rendre la récupération des données difficile et 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 faire encore plus attention à la sauvegarde.

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 modifier ma "propre" réponse plus tard. Étant donné que toutes les réponses que les gens ont données ici sont complètement utiles, ce ne sera qu'un récapitulatif de ce qu'ils ont dit, ainsi que mes conclusions.

Quoi qu'il en soit, voici une de mes conclusions qui dissipera beaucoup de confusion que j'ai rencontrée, et elle concernait principalement ... ce que signifie le bloc, car c'est un terme qui est utilisé de manière excessive et erronée:

https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/

De plus, vous trouverez ici un moyen "standard" de parler des choses et évitez la confusion "bloquante":

/superuser/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 chiffrée au niveau du bloc est complètement non solide, au lieu de croire que "cela agira comme un système de fichiers normal" (c.-à-d. FAQ Veracrypt).

De plus, j'aurais dû tomber sur ce lien il y a deux mois:

/unix/321488/full-image-of-internal-hdd-drive-dd-dd-rescue-with-truecrypt-bad-sectors/

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.