Salut,

Dans la perspective d'y installer Fedora 21, j'ai acheté un nouveau SSD Crucial MX100 de 256 Go.

Ce périphérique a la particularité de posséder un système d'encodage matériel AES 256 bits (conformes aux normes d'encodage TCG Opal 2.0, IEEE 1667 et Microsoft eDrive).

Ne trouvant pas de solution sur la Toile, j'ai envoyé un courriel à Crucial leur demandant de m'expliquer la marche à suivre pour bénéficier de cette fonctionnalité sous Linux.

La réponse semblait ne pas tenir compte de ma demande puisqu'il m'était résumé les moyens de mettre en place l'encodage matériel en utilisant conjointement BitLocker et Windows 8.

Après un nouvel email, leur rappelant que Fedora était une distribution (dite, pour simplifier) Linux, il m'a été suggéré de « mettre à jour votre système d’exploitation avec Windows et essayer les étapes fournies. »

Bon ! Du côté de Crucial, je ne nourris guère d'espoir, si ce n'est celui d'alimenter un troll (ce que je ne souhaite pas faire ici, la citation ne visant qu'à écarter la recommandation, pourtant judicieuse, de me tourner vers le fournisseur).

La question est donc de savoir si quelqu'un s'est déjà penché (avec succès) sur le chiffrement de disque (en utilisant une des normes énoncées ci-dessus), sachant que j'ai lu un certain nombre d'échanges, y compris sur le forum de Crucial, qui indiquaient, à l'époque de leur rédaction, qu'il n'était pas possible de faire fonctionner le chiffrement matériel, d'un SED (Self-encrypting Drives, http://tinyurl.com/c7pzn6e), avec une distribution GNU/Linux (ni avec OS X, me semble-t-il).

Merci,
J'essaye de déchiffrer ton message mais LUKS sert à chiffrer et Anaconda (c'est l'installateur) permet de chiffrer une installation toute neuve de Fedora.
Mon message n'était pas chiffré, abscons peut-être, mais guère plus...

LUKS est un chiffrement logiciel que j'envisage effectivement d'utiliser, mais ce qui m'intéresse (et la raison pour laquelle j'ai initié une discussion), c'est la possibilité d'effectuer un chiffrement matériel.

Ce serait effectivement intéressant de savoir si LUKS est capable de créer un volume s'appuyant sur la technologie SED (Self-encrypting Drives) ou de pouvoir créer par un autre moyen un volume dm-crypt utilisant le chiffrement matériel, mais j'ai cherché et suis rentré bredouille...

Merci anche.
Non c'était très clair comme question, pour peu que l'on connaisse les rudiments de l'informatique et de la cryptographie.

À priori, tu n'as pas besoin de faire quoi que ce soit, le disque, par défaut, va chiffrer tout ce qu'il stocke avec une clé qu'il possède.
Si maintenant tu veux totalement sécuriser ton système, tu dois fournir au disque un mot de passe avec lequel il va chiffrer cette clé (elle sera donc illisible pour un éventuel hacker, tout autant que les données sur le disque). En revanche, étant donné que le chiffrement se fait au niveau physique, ta machine doit connaître le mot de passe de la clé avant même de pouvoir booter (sinon il ne peut pas déchiffrer ce qu'il doit booter...). Cette configuration se fait dans le BIOS/UEFI, l'OS n'intervient à aucun moment dans le process.
Il est possible que tous les BIOS/UEFI ne supportent pas cette fonctionnalité, notamment ceux intégrés dans le matériel grand public.

Plus d'infos ici.

Ceci dit, même si ton disque est totalement chiffré, il suffit qu'un virus ait accès à ta machine pour pouvoir récupérer toutes les données du disque (une fois l'OS lancé, le disque est vu comme non chiffré - de la même manière qu'un chiffrement de type LUKS).

Quel est le besoin ?
Au départ, le besoin est celui de la connaissance et la motivation est celle de l'entêtement (d'un gamin qui tape des pieds et se roule par terre dans un magasin car il ne cromprend pas pourquoi il n'aurai pas le droit d'avoir des bonbons alors qu'ils sont devant ses yeux et à portée de main dans le caddy).

Je tiens à profiter d'une nouvelle installation pour essayer différentes solutions que j'ai rarement l'occasion de tester. Les résultats me permettant d'envisager, pour de prochaines acquisitions, un matériel dont je cerne mieux les possibilités et les limites (ultra-portable pouvant facilement se perdre ou être volé et contenant des données sensibles).

La mise en place d'un chiffrement matériel d'un SDD facilite aussi grandement la tâche et évite, en autre, de se soucier des problèmes de TRIM (http://tinyurl.com/cxptkh8).

La mise en application, à travers le BIOS/UEFI, n'est qu'un aspect du problème.

En effet, si cette caractéristique est nécessaire à la communication avec le SED (accès à la partie cachée du disque renfermant le hachage de la clé d'encryptage), elle n'est pas suffisante puisque la saisie de la clé d'accès (KEK, Key Encryption Key, ou DEK) s'effectue par l'entremise d'un logiciel (installé en lecture seule) se trouvant lui aussi sur le disque caché monté par le BIOS/UEFI, afin que l'utilisateur entre la clé d'accès lors du démarrage du système ; la main étant ensuite redonnée au BIOS/UEFI qui sollicite alors le disque chiffré, ce dernier utilisant la clé de cryptage de médias définie en usine (MEK, Media Encryption Key).
http://tinyurl.com/kq8yk4n

Même si cela y ressemble, initrd ne me semble pas correspondre, pour l'heure, à ce fonctionnement (impliquant le matériel et ladite clé de cryptage de médias).

Merci à Valdes, anche et aux autres lecteurs de ce fil de discussion.
@anche : tu confonds chiffrement logiciel et chiffrement matériel. Avec du chiffrement logiciel (LUKS), ton noyau boote, te demande la clé pour déchiffrer les partitions chiffrées, les déchiffre et continue l'amorçage. Avec du chiffrement matériel, ton OS n'est même pas au courant qu'il est sur un disque chiffré. L'intégralité du disque est chiffré, le disque est déchiffré au moment du démarrage (donc avant même de pouvoir ne serait-ce que lire la table d'allocation). Ton BIOS/UEFI doit donc être en mesure de demander au disque de se déchiffrer avant de pouvoir lancer quoi que ce soit dessus.

@eric L. : soit j'ai mal lu l'article, soit il n'est à aucun moment question de l'inutilité du TRIM avec un disque chiffré (logiciellement ou matériellement). Dans tous les cas ton FS doit faire savoir à ton disque qu'il n'utilise plus certains blocs du SSD afin qu'il puisse les flusher.
Concernant le "logiciel installé en lecture seule qui se trouve sur le disque caché monté blabla", je vois pas de quoi tu parles. À moins que tu parles d'un chiffrement logiciel de type LUKS, auquel cas ce "logiciel", c'est le noyau. Mais il me semblait que tu t'intéressais davantage au chiffrement matériel.
- TRIM n'est pas inutile, au contraire, mais les problèmes qui pouvaient survenir en utilisant LUKS (raison pour laquelle j'avais placé un lien vers l'article How to properly activate TRIM for your SSD on Linux: fstrim, lvm and dm-crypt, http://tinyurl.com/cxptkh8) n'existent plus lorsque le chiffrement est matériel.

- l'article vers lequel tu renvoyais explicitait ledit blabla (voir aussi le paragraphe How is the access to the drive secured to allow only the Authorized user to access it? Is there a boot- up password that is entered via a BIOS dialog?, vers lequel renvoyais le lien placé dans mon premier message, http://tinyurl.com/c7pzn6e).

- la raison pour laquelle Crucial demande d'utiliser BitLocker Windows 8, c'est que c'est l'OS qui active le chiffrement matériel des données (mode de sécurité) et qui gère la clé d'accès (voir ce fil de discussion sur le forum Crucial : http://tinyurl.com/o8u5eto), pas le BIOS/UEFI.

De nombreux textes (dont l'échange du forum Crucial cité ci-dessus) confirment l'incapacité de pouvoir utiliser conjointement GNU/Linux et le chiffrement matériel (SED).

Mais je n'ai pas trouvé de publications, postérieures à avril 2014, confirmant cette impossibilité .

Sachant que Red Hat (enfin « David Howells, un développeur de Red Hat qui travaille sur le noyau Linux ») s'était déjà attiré les foudres de Linus Torvald pour avoir été le premier à proposer « d’intégrer un patch au Kernel permettant d’ajouter des clés dynamiquement afin que toutes les distributions Linux puissent prendre en charge le Secure Boot » (http://tinyurl.com/bro8v3v), j'avais l'espoir que des solutions existent, dont Fedora 21 aurait pu bénéficier.

En même temps, s'il se confirme que les technologies de sécurité (UEFI, chiffrement matériel) ferment la porte à GNU/Linux en obligeant l'utilisation de solutions propriétaires mais que certaines distributions s'engouffrent dans la brèche pour répondre aux besoins exprimés (ici et ailleurs)... cela confirmerait les craintes exprimées par Linux Torvald, il y a plus d'un an et demi (https://lkml.org/lkml/2013/2/21/196).
Non mais là tu confonds tout. Ceci est ma dernière tentative, après j'abandonne.
Eric L. wrote:- TRIM n'est pas inutile, au contraire, mais les problèmes qui pouvaient survenir en utilisant LUKS (raison pour laquelle j'avais placé un lien vers l'article How to properly activate TRIM for your SSD on Linux: fstrim, lvm and dm-crypt, http://tinyurl.com/cxptkh8) n'existent plus lorsque le chiffrement est matériel.
Oui, pour la n-ième fois, lorsque le chiffrement est matériel, l'OS n'a même pas conscience du chiffrement sous-jacent. Par conséquent, il n'y a aucun paramètre spécial à préciser (que ce soit pour le TRIM ou pour autre chose) justement parce que le disque se comporte exactement comme un disque normal du point de vue OS / système de fichiers.
Eric L. wrote:- l'article vers lequel tu renvoyais explicitait ledit blabla (voir aussi le paragraphe How is the access to the drive secured to allow only the Authorized user to access it? Is there a boot- up password that is entered via a BIOS dialog?, vers lequel renvoyais le lien placé dans mon premier message, http://tinyurl.com/c7pzn6e).
Oui, le disque demande à l'utilisateur de s'identifier pour pouvoir y accéder. Je vois pas le rapport avec un "logiciel installé en lecture-seule". La première chose que le disque répond au BIOS / UEFI, c'est "Identifie-toi". Ton "logiciel en lecture-seule", c'est le BIOS / UEFI.
Eric L. wrote:- la raison pour laquelle Crucial demande d'utiliser BitLocker Windows 8, c'est que c'est l'OS qui active le chiffrement matériel des données (mode de sécurité) et qui gère la clé d'accès (voir ce fil de discussion sur le forum Crucial : http://tinyurl.com/o8u5eto), pas le BIOS/UEFI.
Oui, BitLocker (ou n'importe quel soft de chiffrement) est capable de stocker de manière chiffré des datas même si le disque est déjà chiffré en dessous. L'avantage de BitLocker sous Windows, à priori, c'est qu'il est capable de savoir si le disque est chiffré matériellement en dessous et de ne pas re-chiffrer logiciellement par dessus. Comme l'auteur explique, pour avoir son boot sur une partition chiffrée, il faut que le BIOS / UEFI soit compatible. Sinon, il est toujours possible de faire une partition chiffrée matériellement et faire en sorte que BitLocker la débloque au démarrage (mais pour cela il faut que l'OS soit démarré ; la partition en question est donc une partition de données standard - comprendre : pas l'OS).
Eric L. wrote:De nombreux textes (dont l'échange du forum Crucial cité ci-dessus) confirment l'incapacité de pouvoir utiliser conjointement GNU/Linux et le chiffrement matériel (SED).

Mais je n'ai pas trouvé de publications, postérieures à avril 2014, confirmant cette impossibilité .
Pas du tout, mon Vertex 3 est chiffré matériellement depuis mon BIOS. Au boot, mon BIOS me demande le mot de passe, sinon je ne peux pas y accéder. C'est juste que Linux n'a aucun moyen de savoir si le disque est chiffré matériellement ou pas.
Eric L. wrote:Sachant que Red Hat (enfin « David Howells, un développeur de Red Hat qui travaille sur le noyau Linux ») s'était déjà attiré les foudres de Linus Torvald pour avoir été le premier à proposer « d’intégrer un patch au Kernel permettant d’ajouter des clés dynamiquement afin que toutes les distributions Linux puissent prendre en charge le Secure Boot » (http://tinyurl.com/bro8v3v), j'avais l'espoir que des solutions existent, dont Fedora 21 aurait pu bénéficier.
Alors ça, ça n'a strictement rien à voir avec le chiffrement du disque. Le principe du Secure Boot, c'est juste de signer la partition de boot afin qu'un malware ne puisse pas la modifier discrètement. Ça ne garantit rien d'autre.
Eric L. wrote:En même temps, s'il se confirme que les technologies de sécurité (UEFI, chiffrement matériel) ferment la porte à GNU/Linux en obligeant l'utilisation de solutions propriétaires mais que certaines distributions s'engouffrent dans la brèche pour répondre aux besoins exprimés (ici et ailleurs)... cela confirmerait les craintes exprimées par Linux Torvald, il y a plus d'un an et demi (https://lkml.org/lkml/2013/2/21/196).
Pareil, rien à voir avec le chiffrement du disque, ça parle de Secure Boot.
Un article (avril 2014) concernant l'activation et la mise en place du chiffrement matériel (SED) via Linux :

http://tinyurl.com/l4eprdu

Note : lire la mésaventure de openoliv, car il y un risque de se retrouver avec un SED inutilisable.