Suite à l’upgrade de Debian de Stretch vers Buster sur Olinuxino A20, on perd le support de l’algorithme de chiffrement aes-xts dans le kernel. Il a donc fallu re-chiffrer en aes-cbc les périphériques concernés.
Le processeur Allwinner A20 ne propose pas d’accélération matérielle pour l’algorithme aes-xts. J’en parlais dans un article précédent et un autre. Mais, avec Debian Stretch, cet algorithme restait utilisable (en software).
Lors de l’upgrade à Debian Buster, j’ai eu la surprise de constater que cryptsetup n’arrivait plus à ouvrir certains périphériques LUKS : ceux chiffrés en aes-xts.
Et c’est confirmé avec cryptsetup :
$ sudo cryptsetup benchmark
# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1 83379 iterations per second for 256-bit key
PBKDF2-sha256 123886 iterations per second for 256-bit key
PBKDF2-sha512 75676 iterations per second for 256-bit key
PBKDF2-ripemd160 67772 iterations per second for 256-bit key
PBKDF2-whirlpool 14290 iterations per second for 256-bit key
argon2i 4 iterations, 44135 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id 4 iterations, 49964 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
# Algorithm | Key | Encryption | Decryption
aes-cbc 128b 33.6 MiB/s 33.6 MiB/s
serpent-cbc 128b 10.9 MiB/s 11.6 MiB/s
twofish-cbc 128b 16.8 MiB/s 18.2 MiB/s
aes-cbc 256b 26.2 MiB/s 26.3 MiB/s
serpent-cbc 256b 10.9 MiB/s 11.8 MiB/s
twofish-cbc 256b 16.7 MiB/s 18.2 MiB/s
aes-xts 256b N/A N/A
serpent-xts 256b 11.5 MiB/s 11.8 MiB/s
twofish-xts 256b 18.3 MiB/s 18.4 MiB/s
aes-xts 512b N/A N/A
serpent-xts 512b 11.5 MiB/s 11.8 MiB/s
twofish-xts 512b 18.3 MiB/s 18.3 MiB/s
Contournement court terme : revenir sur le kernel 4.9 de Stretch au lieu du 4.19 de Buster (en modifiant les liens symboliques et le boot.src dans /boot)
Je n’ai pas trouvé moyen de refaire fonctionner ce cipher (même sans accélération matérielle) avec le kernel 4.19 de Buster. Cela passerait probablement par une recompilation du kernel, ce que je voudrais éviter (pour continuer d’avoir automatiquement les patchs de sécurité de Debian). J’ai plutôt choisi de re-chiffrer les filesystems en aes-cbc :
sudo cryptsetup-reencrypt --cipher aes-cbc-plain /dev/sda1
Il faut prendre au sérieux l’avertissement sur le risque de perte de données : d’abord tout sauvegarder!
Problème : c’est lent! Surtout sur un Olinuxino A20, qui fait le déchiffrement aes-xts en software. Et ça re-chiffre tout le device (pas uniquement ce qui est utilisé dans le filesystem sous-jacent) : sur un device de 32Go par exemple, il rechiffrera l’intégralité des 32Go. Donc, suivant le cas, il peut être plus judicieux de :
- re-chiffrer depuis un autre appareil plus puissant (un PC, par exemple)
- ou sauvegarder les données, reformater le device avec cryptsetup luksFormat, puis y remettre les données