web-dev-qa-db-fra.com

"Aucune clé disponible avec cette phrase secrète" avec une partition DM-CRYPT / LUKS nouvellement créée

En faisant des recherches, il semble que d'autres ont des problèmes plus complexes à cause des paramètres de chiffrement, mais mon problème est de faire quelque chose de simple.

En utilisant une installation principalement fraîche de Lubuntu 18.10 32 bits (le noyau a été mis à jour), je peux ainsi créer une partition chiffrée:

cryptsetup  --verbose  --verify-passphrase  luksFormat  /dev/mmcblk0    

WARNING: Device /dev/mmcblk0 already contains a 'crypto_LUKS' superblock signature.

WARNING!
========
This will overwrite data on /dev/mmcblk0 irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase for /dev/mmcblk0: 
Verify passphrase: 
Existing 'crypto_LUKS' superblock signature on device /dev/mmcblk0 will be wiped.
Key slot 0 created.
Command successful.

Si le mot de passe donné est la lettre a, je ne peux pas le déverrouiller ainsi:

cryptsetup  --verbose  luksOpen  /dev/mmcblk0 crypt

Enter passphrase for /dev/mmcblk0:
No key available with this passphrase.
Enter passphrase for /dev/mmcblk0:

(J'ai aussi essayé zulucrypt avec le même résultat)

Depuis que j'ai installé Lubuntu en utilisant la fonctionnalité de chiffrement de son installateur, je peux faire une comparaison entre ce que mon système utilise nativement et ce que cryptsetup a fait sur mon lecteur mmc.

cryptsetup luksDump /dev/sda1

La partie pertinente semble être:

Version:        1
Cipher name:    aes
Cipher mode:    xts-plain64
Hash spec:      sha256
Payload offset: 4096
MK bits:        512

La seule différence que je vois entre les deux vidages est que pour mon disque local, les "bits MK" inférieurs sont 512, mais pour le mmc, il est 256.

Je ne sais pas si c'est pertinent, mais je vois aussi que mon lecteur local a deux emplacements de clé et le mmc n'en a qu'un. (Le fait que mon disque local ait deux emplacements de clé me ​​fait espérer/me demander si l'installateur a mis une clé en double au cas où la première serait corrompue.)

Un intervenant m'a demandé d'essayer de fournir une phrase secrète de cette façon:

echo -n 'a' | cryptsetup  --verbose  luksOpen  /dev/mmcblk0 crypt

Can't do passphrase verification on non-tty inputs.
No key available with this passphrase.
Command failed with code -2 (no permission or bad passphrase).

Une autre façon de fournir un mot de passe:

echo 'a' > interactive_pass         
cat interactive_pass | cryptsetup luksAddKey /dev/mmcblk0

No key available with this passphrase.

Utilisation d'un fichier clé.

Je ne peux pas comprendre ça. J'ai tâtonné pendant un moment, mais je me suis arrêté parce que je ne peux pas faire la différence entre l'utiliser mal et avoir ses propres problèmes.

zulucrypt a un moyen de créer un fichier de clés, mais il dit simplement Failed To Generate Key. C'est simple, donc je suis certain de l'utiliser correctement (exécuté en tant que root, j'ai des autorisations d'écriture sur le fichier que je voudrais créer)

encryptionlukscryptsetup
1
spiralofhope

TL; DR - Vérifiez si le support est fiable; luksFormat et luksOpen pas.

Le problème pourrait être envisagé de plusieurs manières au moins:

  • La mauvaise phrase de passe est fournie
  • La phrase secrète est donnée dans le mauvais sens
  • Quelque chose ne va pas avec les logiciels essentiels, comme cryptsetup lui-même.

Par curiosité, j'ai décidé de faire un formatage complet du lecteur mmc (pour "repartir de zéro"), mais en vérifiant:

Sudo mkfs.ext4 /dev/mmcblk0 -cc   

mke2fs 1.44.4 (18-Aug-2018)
/dev/mmcblk0 contains a ext4 file system
        last mounted on Tue Mar  5 11:30:02 2019
Proceed anyway? (y,N) y
Discarding device blocks: done                            
Creating filesystem with 15591936 4k blocks and 3899392 inodes
Filesystem UUID: 0ab72f40-d2a2-408d-b4ca-d5e8fcc27ec7
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
        4096000, 7962624, 11239424

Testing with pattern 0xaa: done                                                 
Reading and comparing: done                                                 
Testing with pattern 0x55: done                                                 rs)
Reading and comparing: done                                                 rs)
Testing with pattern 0xff: done                                                 rs)
Reading and comparing: done                                                 rs)
Testing with pattern 0x00: done                                                 rs)
Reading and comparing: done                                                 rs)
Block 0 in primary superblock/group descriptor area bad.
Blocks 0 through 9 must be good in order to build a filesystem.
Aborting....

Je pouvais déjà voir où cela allait ..

Comme je n'ai jamais formaté comme ça auparavant, j'ai formaté un deuxième périphérique de stockage (une clé USB) avec vérification, et son format s'est terminé avec succès. En passant par le même processus cryptsetup pour formater et ouvrir cette clé USB a fonctionné . Cela révèle un autre problème qui se produisait:

  • La phrase secrète est reçue de la mauvaise façon

Je soupçonne que luksFormat ne fait aucune vérification de bon sens pour voir que ses données peuvent en fait être lues.

À titre de suivi, j'avais déjà fait un format non rapide sous Windows et cela fonctionnait bien. J'ai également effectué un test complet d'écriture-lecture-comparaison et ce fut également un succès. J'ai d'autres tests à effectuer, juste par curiosité, mais cela peut être (en quelque sorte) un problème spécifique à Linux. Je ne dépannerai pas ce trou de lapin, mais je conclurai qu'il est important de faire tout le formatage et les tests sur la plate-forme spécifique sur laquelle le problème est vu.

1
spiralofhope