Je suis curieux de savoir comment fonctionne le chiffrement complet du disque d'Ubuntu sous le capot. Voici un exemple:

En considérant la chaîne suivante comme tout le contenu du disque:

hello world

Après avoir appliqué une sorte de méthode de chiffrement, cela ressemblerait à ceci:
(J'ai utilisé le chiffrement César avec un décalage de +1 pour cet exemple, par exemple A → B; B → C ...)

ifmmp xpsme

Si je comprends bien, lorsque l'ordinateur est éteint, le contenu du lecteur serait la chaîne ci-dessus. Mais lorsqu'il est réactivé, Ubuntu a besoin que son contenu soit à nouveau disponible hello worldpour démarrer correctement.

Ce que je ne comprends pas vraiment, c'est que dans le monde réel , le contenu du disque est beaucoup plus et l'algorithme de cryptage beaucoup plus complexe, et je trouve difficile pour l'ordinateur de crypter / décrypter complètement tout cela en quelques secondes (il ne faut pas plus de temps pour démarrer ou pour arrêter).

Comment est-ce possible?

Comment fonctionne le cryptage AES / Rijndael en général?

Cette page contient un amusant guide A Stick Figure de la norme AES (Advanced Encryption Standard) qui semble facile à comprendre, bien qu'il semble s'agir de plus de 50 images, par exemple les deux:

et

C'est beaucoup trop pour tout reproduire ici, mais si vous devez avoir une image tout-en-un, c'est celle-ci:

Ou, il y a une explication plus compacte à http://www.password-depot.com/know-how/blowfish_and_rijndael.htm

La méthode de cryptage Rijndael est basée sur le remplacement, la modification et l'exécution d'opérations xor sur octets. La méthode ressemble à ceci:

• À partir de la clé de 128 bits, Rijndael génère 10 clés de 128 bits chacune.
• Ces clés sont placées dans des tableaux 4x4.
• Le texte brut est également divisé en tableaux 4x4 (128 bits chacun).
• Chacun des éléments en texte brut de 128 bits est traité en 10 tours (10 tours pour les clés de 128 bits, 12 pour 192, 14 pour 256).
• Après le 10e tour, le code est généré.
• Chaque octet unique est substitué dans une case S et remplacé par l'inverse sur GF (2 8).
• Ensuite, une matrice modulo-2 bit par bit est appliquée, suivie d'une opération XOR avec 63.
• Les lignes des matrices sont triées cycliquement.
• Les colonnes de la multiplication matricielle sont échangées sur GF (2 8).
• Les sous-clés de chaque tour sont soumises à une opération XOR.

Le niveau de sécurité de cette méthode de chiffrement augmente si Rijndael est exécuté plusieurs fois avec différentes sous-clés.

Comment fonctionne le Full Disk Encryption d'Ubuntu?

Je pense que cela fonctionne en chiffrant une partition avec LUKS (paramètres par défaut avec AES), puis en y mettant des volumes avec LVM (comme /, swap), et les déchiffre et les monte au démarrage après avoir entré une phrase secrète. Et il existe une partition de démarrage régulière (non chiffrée) qui démarre suffisamment pour demander la phrase secrète.

the_simple_computer's Guide to Full Disk Encryption with Ubuntu (Mis à jour le 28 juin 2015) indique que cela fonctionne sur le fonctionnement du cryptage par défaut de l'installateur, et mentionne que le double démarrage ne fonctionnerait pas (du moins pas prêt à l'emploi ), le lecteur doit utiliser MBR donc " si votre ordinateur a UEFI, la distribution sera installée en mode BIOS hérité donc vous ne pouvez pas utiliser Secure Boot " et " vous donne également une taille de swap égale à celle de votre RAM système (souvent inutile) et vous n'ont pas le choix sur le type de cryptage utilisé. "

Quelle est la vitesse de cryptage?

Si vous l'exécutez, cryptsetup benchmarkil exécutera des tests et vous informera de la vitesse à laquelle le cryptage prend seul, surveillez les lignes aes-xts par défaut (actuellement):

#  Algorithm | Key |  Encryption |  Decryption
     aes-xts   256b    150.0 MiB/s    145.0 MiB/s

La vitesse de lecture moyenne d'un disque dur pourrait être de 80 à 160 Mo / s, vous ne serez donc pas beaucoup plus long qu'une lecture régulière, et il est possible que les secteurs qui viennent d'être lus aient déjà été décryptés pendant que vous attendez toujours le disque dur pour en savoir plus.

Un SSD pourrait éventuellement être plus rapide, peut-être 200-550 Mo / s, donc vous pourriez le remarquer. Mais, les lectures aléatoires pourraient être plus lentes, et j'ai lu que les vitesses des SSD peuvent ralentir après utilisation (peut-être lorsque le lecteur se remplit complètement et qu'il doit commencer à "effacer" les secteurs?)

Comment l'ordinateur peut-il crypter / décrypter complètement tout le lecteur en quelques secondes (le démarrage ou l'arrêt ne prend pas plus de temps)?

Il n'a pas besoin de tout décrypter en premier. Le cryptage (LUKS) fonctionne sur des blocs de données , peut décrypter n'importe quel bloc de manière aléatoire et agit comme une couche entre les données cryptées du lecteur et ce que le système de fichiers voit.

Lorsque le système de fichiers souhaite voir un bloc de données, LUKS déchiffre ce bloc en premier, puis remet les données déchiffrées au système de fichiers. Vous attendez d'abord que le lecteur lise le bloc de données (tout comme sans utiliser le cryptage), et vous ne disposez que d'un délai supplémentaire pour le décryptage de ce bloc unique (ou de quelques blocs) de données - et si le décryptage est plus rapide que le lecteur peut lire, le déchiffrement pourrait être terminé avant que le lecteur ne lise le bloc de données suivant.

Donc, tout comme un système de fichiers normal n'a pas besoin de lire tout le lecteur pour lire un fichier, lorsque le cryptage est ajouté, il n'a pas besoin de lire tout le lecteur non plus, et cela ne ralentit pas beaucoup les choses .

Les données sur le disque dur sont toujours cryptées , il n'y a donc rien à faire à l'arrêt sauf oublier la clé.

• Il y a plus de détails sur la théorie du chiffrement de disque sur Wikipedia

Ce sera un peu une simplification, mais je vais essayer de passer par le processus d'accès à un fichier sur un système de fichiers crypté.

Par exemple, disons qu'au début du système de fichiers crypté, il y a une table de fichiers; disons que nous voulons lire /foo.bar. Donc, la première chose que nous faisons est de lire le début de la partition, de la décrypter et de la parcourir pour trouver le fichier que nous voulons; disons que le fichier commence à 0x10000000 octets. Donc, pour lire, nous commençons à lire à partir du disque à cet emplacement et à le déchiffrer; de même, pour écrire, nous pouvons crypter le nouveau contenu et les écrire à ce nouvel emplacement.

Espérons que cela aide à dissiper toute confusion sur le processus.

Le processeur utilise un jeu d'instructions dédié. C'est possible à cause de cela, AES-NI . Il permet un chiffrement et un déchiffrement rapides ou vous pouvez dire qu'il réduit les frais généraux. C'est rapide car c'est une implémentation matérielle, comme expliqué ici .

Vous pouvez vérifier les impacts sur les performances ici et ils en valent la peine pour plus de sécurité.

Les ordinateurs modernes peuvent effectuer des milliards d'opérations par seconde, il n'est donc pas surprenant que le chiffrement et le déchiffrement soient rapides.

Voici comment je classerais intuitivement la vitesse à laquelle les ordinateurs font les choses:

1. Faire des calculs dans la mémoire (en particulier la mémoire L1 et L2), extrêmement rapide
2. Lecture à partir du stockage local, moins rapide (les disques SSD sont plus rapides que les disques durs)
3. Lire depuis le réseau, encore moins vite.

L'autre élément clé à comprendre est que le fonctionnement n'a pas besoin de déchiffrer l'intégralité du disque dur pour démarrer le système. Au contraire, le système d'exploitation sait comment décrypter uniquement les parties du disque dur dont il a besoin à la volée, et il en va de même pour l'écriture.

Donc, intuitivement, je ne suis pas surpris que le chiffrement complet du disque n'ait pas beaucoup d'impact sur les performances, car j'imagine que le goulot d'étranglement est le disque.

Bien sûr, ces intuitions ne correspondent pas toujours à la réalité. Par exemple, en réalité, il y a eu des cas où le chiffrement intégral du disque a provoqué une baisse sensible des performances. Mais généralement, ces problèmes sont résolus après que les développeurs ont effectué quelques cycles d'optimisation de développement.