aes-xts indisponible après upgrade vers debian buster sur Olinuxino A20

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 :



		


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 :



		


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

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *