SDB:Changements des partitions et des fichiers de chiffrement sous SUSE LINUX Professional 9.3

Version: 9.3

Changements des partitions et des fichiers de chiffrement sous SUSE Linux Professional 9.3

Arrière-plan technique

Avec SUSE LINUX 9.3, nous sommes passés du module de chiffrement loop_fish2 à twofish. twofish, associé à cryptoloop, est dorénavant la méthode standard en matière de partitions chiffrées. Nous l'avons adopté parce que « twofish » associé à « cryptoloop » est plus sécurisé (« cryptoloop » utilise le numéro de bloc comme vecteur d'initialisation, alors que « loop_fish2 » emploie toujours zéro) et qu'il est la solution standard pour les partitions chiffrées.

ATTENTION : N'EXÉCUTEZ PAS FSCK

Le format sur disque des deux modules est différent et, si vous y accédez via le mauvais module, les scripts d'amorçage automatique reconnaîtront le système de fichiers (du fait que le premier bloc est très semblable), mais remarqueront que le reste semble incorrect et proposeront une vérification du système de fichiers. Ne lancez pas cette vérification du système de fichiers - à la place, répondez simplement « Non » et vérifiez que le bon module est actif. Si vous ignorez cet avertissement, la vérification du système de fichiers entraînera une perte totale des données.

SUSE Linux utilise maintenant ces différentes implémentations du système de fichiers cryptographique :

Version de SUSE	Nom du chiffrement	Longueur de la clé	Modules de noyau	Vecteur d'initialisation (VI)
Antérieure à 9.1	twofish	160 bits	loop_fish2	constant
9.1 et 9.2	twofish256	256 bits	loop_fish2	constant
9.2	twofish256	256 bits	twofish, cryptoloop	numéro de bloc

Comme vous le voyez, le nom de chiffrement twofish256 est identique, qu'il s'agisse de SUSE LINUX 9.1/9.2 et 9.3, mais il fait appel à des modules de noyau différents. Malheureusement, le format sur disque qu'emploient ces modules est différent et ils sont par conséquent incompatibles. Naturellement, le format sur disque ne peut pas non plus être détecté, parce que cela signifierait que vous pourriez deviner le type de chiffrement d'après les données cryptées, ce qui serait une faille de sécurité du système d'exploitation.

Ces limitations engendrent certains problèmes que nous ne pouvons pas traiter techniquement. Cela signifie que vous devez intervenir manuellement dans le cas suivant :

Nouvelle installation et accès à une ancienne partition chiffrée

Si vous procédez à une nouvelle installation de SUSE LINUX 9.3 et que vous vous en servez pour accéder à des partitions chiffrées existantes à partir de SUSE LINUX 9.1 ou 9.2, vous devez indiquer le nom du chiffrement correct dans vos fichiers de configuration. Ce sera soit /etc/cryptotab, soit /etc/fstab. Comme vous le savez, nous avons trois niveaux d'implémentation différents, dont deux font appel au même nom de chiffrement. Pour différencier ces derniers, nous avons mis en place le nom de chiffrement twofishSL92, qui est un alias pour twofish256 avec loop_fish2. Donc, dans vos fichiers de configuration, changez :

twofish256 en twofishSL92

Exemple :

Ancien fichier cryptotab de SUSE LINUX 9.2 :

/dev/loop0  /dev/hda3  /secret  reiserfs  twofish256 noatime

Nouveau fichier de SUSE LINUX 9.3 :

/dev/loop0  /dev/hda3  /secret  reiserfs  twofishSL92 noatime

Les aspects que nous avons abordés du fait qu'ils sont techniquement possibles sont :

Mise à jour à partir de distributions antérieures

Pendant une mise à jour du système, les fichiers /etc/fstab et /etc/cryptotab sont modifiés par l'installeur YaST.

Installation d'une nouvelle distribution

Une nouvelle installation utilise exclusivement le nouveau module « cryptoloop ». <keyword>chiffrement,loop,mount,fsck,twofish</keyword>