Le 13 mars 2015, Open Crypto Audit Project a rendu son rapport concernant l'audit de sécurité démarré sur Truecrypt 7.1a, en version Windows..
Trois ingénieurs ont travaillé sur ce projet, en regardant la majeur partie du code source, et ils ont trouvé 4 vulnérabilités, dont 2 de haute sévérité. La revue de sécurité a également utilisé des exemples, et en déboguant de manière spécifique.
Je vous encourage à lire le rapport qui ne fait que 21 pages pour plus de détails, mais globalement, la création et l'utilisation d'un volume Truecrypt dans des conditions normales fonctionne bien, et aucune des 4 failles ne permet de complètement outrepasser la sécurité de Truecrypt.
Les recommandations pour la suite sont les suivantes :
- continuer les revues de code ;
- simplifier la logique (la prise en charge de pleins de formats rend la vérification plus difficile) ;
- être beaucoup plus stricte sur la gestion des erreurs et des logs (ne jamais faillir silencieusement par exemple), car l'exactitude est plus importante que la résilience pour ce type de logiciel.
Les deux principales branches créées à partir de la version 7.1a de Truecrypt sont CipherShed réfléchissante à passer à une licence LGPL ou BSD , et Veracrypt qui publie sont code sous la Microsoft Public License qui n'est pas considéré libre par la FSF.
Ciphershed a également reçu l'aide gracieuse de l'Open Crypto Audit Project, et travaille à intégrer ces changements.
Pour finir, n'oublie que chiffrer, c'est bien.
# Pour finir, n'oublie que chiffrer, c'est bien.
Posté par arnaudus . Évalué à -9.
refnec.
[^] # Re: Pour finir, n'oublie que chiffrer, c'est bien.
Posté par arnaudus . Évalué à -2. Dernière modification le 03 avril 2015 à 14:03.
Vous pouvez moinsser si vous voulez, mais le chiffrage a un coût et représente un risque. Dans la plupart des situations de la vie quotidienne et professionnelle, le coût et le risque sont supérieurs aux bénéfices du chiffrage*. Je trouve donc profondément crétin de balancer des assertions comme "chiffrer, c'est bien" sans les remettre dans leur contexte (c'est à dire, dans quelles situations le chiffrage est bénéfique).
(*) Je parle évidemment du chiffrage des fichiers. Chiffrer les transferts d'information ne pose pas du tout les mêmes problèmes.
[^] # Re: Pour finir, n'oublie que chiffrer, c'est bien.
Posté par Jiehong (site web personnel) . Évalué à 10.
[référence nécessaire]
[^] # Re: Pour finir, n'oublie que chiffrer, c'est bien.
Posté par Adrien . Évalué à 4.
Toi, tu ne travailles par pour l'ANSSI au moins ;-)
[^] # Re: Pour finir, n'oublie que chiffrer, c'est bien.
Posté par chdorb . Évalué à 4.
s/chiffrage/chiffrement/g
[^] # Re: Pour finir, n'oublie que chiffrer, c'est bien.
Posté par aurel (site web personnel, Mastodon) . Évalué à 2.
Pour ne pas faire que moinsser je tente de répondre ^
Je vois 3 coûts potentiels au chiffrement:
- l'utilisation CPU qui augmente
- les performances disque qui baissent
- l'ergonomie
Dans les 2 premiers cas, le jeu d'instruction AES-NI des processeurs récents permet de répondre à la problématique dès lors que tu chiffres avec de l'AES. Même si ce n'est pas de l'AES ou si ton CPU ne dispose pas de ces instructions - ce qui est mon cas -, c'est franchement indolore au quotidien.
Concernant l'ergonomie, le plus simple est d'opter pour un chiffrement complet du disque, ou au moins de ton home. Tout est déverrouillé une bonne fois pour toute, et tant que ta machine tourne, tu n'as même pas besoin d'y penser.
je te la fais très courte intentionnellement, on est beaucoup ici à pouvoir étayer et je ne suis pas sûr que ce soit la peine.
Ensuite, tu parles du risque de chiffrer. Là, ça m'intrigue. Quel est ce risque ? Moi je vois bien celui de ne pas chiffrer, par exemple en cas de vol. Mais le risque de chiffrer, sincèrement, je ne vois pas. Explique ?
[^] # Re: Pour finir, n'oublie que chiffrer, c'est bien.
Posté par flan (site web personnel) . Évalué à 5.
Il y a un risque : tu perds le mot de passe ou la clef et tes données sont irrécupérables. En entreprise, tu perds la personne (et donc son mot de passe) et ses données sont irrécupérables (sauf si tu as fait les choses bien, avec des clefs de recouvrement).
[^] # Re: Pour finir, n'oublie que chiffrer, c'est bien.
Posté par aurel (site web personnel, Mastodon) . Évalué à 3.
Très juste. Dans ce cas là, le risque ne me semble pas tant lié au chiffrement en lui-même qu'à une mauvaise mise en œuvre. Ça rejoint donc le commentaire du dessous qui mentionne la nécessité - et donc le coût - de faire les choses proprement.
[^] # Re: Pour finir, n'oublie que chiffrer, c'est bien.
Posté par arnaudus . Évalué à 5.
Le coût, je pensais plutôt au coût de payer des gens qui mettent en place le système, de la veille technologique et des mises à jour, le coût de la formation des utilisateurs, de la mise en place d'un système fiable de stockage des clés, voire d'un coffre fort pour y stocker les clés imprimées sur papier. Le risque est évidemment très concret, c'est celui de perdre les données : perte de la clé ou de la personne qui a mis en place le système, données irrécupérables suite à une erreur dans le système de fichiers, etc. Une simple fausse manip ou une modification anodine du système peut faire perdre du temps et/ou des données. Il est déja suffisamment courant de perdre des données, le fait qu'elles soient chiffrées ne va pas améliorer les choses.
Bref, le coût réel de ce genre de choses est énorme, surtout dans les petites structures qui ne peuvent pas se permettre d'embaucher quelqu'un de suffisamment compétent pour mettre en place un système sans risque et pour récupérer les données en cas de pépin : PME, particulier, association. Quand il n'y a pas de risque particulier (par exemple, pas de données particulièrement sensibles, pas de secrets industriel, pas d'ordinateurs portables), chiffrer les disques des machines qui restent sur place est une pratique que je trouve assez ridicule, voire franchement dangereuse.
Évidemment, ça n'a absolument rien à voir avec les pratiques dans un datacenter ou une grande entreprise. Mais les salaires, encore moins ceux des personnes compétentes dans le domaine, ne sont pas gratuits : c'est terriblement cher, il faut que les données et le contexte économique en vallent la peine. Les geeks paranoïaques peuvent aussi faire ça chez eux, mais ça, c'est dans le domaine ludique. Pour les gens "normaux", il faudrait qu'ils commencent à ne pas balancer leurs fichiers confidentiels sur Facebook avant de se poser la question de la sécurité du stockage ; même la plupart des utilisateurs avancés partagent des fichiers de données (fichiers client ou fournisseur, devis, rapports internes, projets, brouillons de brevets…) par email, qu'ils lisent depuis leur téléphone ou leur tablette via le wifi gratuit d'un hotel en Bulgarie.
Accessoirement, se passer d'ingénieurs compétents en crytographie permet aussi de se passer des trolls hypercorrecteurs sur cryptage/chiffrement, et ça, c'est aussi un gros bénéfice :-)
[^] # Re: Pour finir, n'oublie que chiffrer, c'est bien.
Posté par aurel (site web personnel, Mastodon) . Évalué à 3.
Chiffrement ou pas ce risque existe. Un chiffrement mal mis en place peut l'entraîner, tout comme une serrure mal mise en place chez toi risque de te laisser coincé à l'extérieur. La métaphore s'arrête là car les données, chiffrées ou pas, peuvent et doivent être sauvegardées. Comme tu le dis bien, ça a un coût de faire les choses proprement, mais ne pas les faire proprement - ou ne pas les faire du tout - a aussi un coût.
Il ne s'agit pas de se perdre en cherchant une sécurité ultime inatteignable, mais de prendre conscience que des règles simples dont le coût est modique permettent d'améliorer parfois considérablement une situation initiale dont le risque est souvent mal évalué. Les solutions de chiffrement de disque les plus courantes me semble répondre à cette problématique d'une façon plutôt efficace (j'utilise cryptsetup/LUKS, TrueCrypt et FileVault sous OSX, mais j'avoue ne pas avoir d'expérience avec BitLocker).
Pour ma part, c'est simple et ça n'engage que moi: en l'absence de sécurisation physique adéquate, le chiffrement est obligatoire. La sauvegarde aussi.
La transmission de fichiers confidentiels, c'est effectivement un gros souci. C'est avant tout un problème de formation, parfois aussi d'infrastructure inadaptée. C'est toutefois orthogonal avec le chiffrement de disque et dans les deux cas, l'idée selon laquelle le système est déjà assez troué comme ça pour ne pas prendre de risque supplémentaire en omettant le chiffrement des disques me semble toute à fait défendable, sauf à penser que l'incurie des uns ne justifie pas celle des autres.
[^] # Re: Pour finir, n'oublie que chiffrer, c'est bien.
Posté par aurel (site web personnel, Mastodon) . Évalué à 1.
s/sauf à penser que l'incurie des uns ne justifie pas celle des autres/sauf à penser que l'incurie des uns justifie celle des autres/
Auto-flagellation.
[^] # Re: Pour finir, n'oublie que chiffrer, c'est bien.
Posté par arnaudus . Évalué à 5.
Je pense que je n'ai jamais dit le contraire. C'est juste que le coût de ne pas chiffrer ses données est, pour la plupart des applications, négligeable. Et quand le coût de se faire piquer ses données n'est pas négligeable (par exemple, identifiants bancaires), le risque que ce problème arrive en se faisant pomper un disque dur est en général minime par rapport aux autres facteurs de risque.
Ma réaction initiale portait sur l'assertion "chiffrer c'est bien", qui pourrait induire en erreur beaucoup de gens. Je pense qu'un bon conseil, c'est justement de ne pas chiffrer son disque si on ne connait pas sur le bout des doigts les algos de chiffrement et la mise en oeuvre pratique. Chiffrer sans comprendre ce qu'on fait, c'est bien pire que de ne pas chiffrer.
Là, paf, partage d'expérience personnelle : à un moment (je ne sais pas si c'est toujours le cas), Ubuntu proposait de chiffrer par défaut le répertoire /home. Bercé de conseils du type "chiffrer c'est bien", je me mets à chiffrer toutes mes nouvelles installations. Sauf que le système adopté (je ne sais même pas quel algorithme était utilisé) se basait sur un triplet uid / login / password pour déchiffrer (je ne sais pas si c'est courant). Du coup, le jour où il a fallu bricoler les uid pour un partage nfs -> blam. Si c'est la première fois que le gag t'arrive, tu n'as évidemment pas noté les anciens uid. Évidemment qu'il fallait faire autrement, qu'il y avait certainement des manières de faire qui fonctionnent, mais ce que je veux dire, c'est que chiffrer les disques n'est pas du tout une opération transparente, même pour le bricolage de base. On peut aussi citer évidemment la récupération des données d'un disque sur une machine cassée, qui nécessite 2 journées de Googleage et tests quand on ne l'a jamais fait. Certaines fonctionnalités du système ne fonctionnent plus (par exemple, updatedb et locate quand les /home sont chiffrés). Bref, encore une fois, je vois l'intérêt de chiffrer un disque quand il existe des risques substantiels de se faire piquer des données critiques (et que le vol du disque est le moyen le plus pratique de piquer les données), mais ça concerne, quoi? quelques petits pourcents de la population? Le reste a 1000 fois plus de chances de se faire emm*der par des effets secondaires du chiffrage que de se faire piquer des données.
Honnêtement, si je perds mon portable, quelle est la probabilité que le petit malin qui le récupère ait la volonté de regarder mes données, plutôt que de le refourguer reformatté le plus vite possible? Quelle est la probabilité qu'il ait la volonté de booter la machine sur une clé USB avec un système qui sait lire ext4? Quelle est la probabilité qu'il passe plusieurs heures, voire plusieurs jours, à aller chercher à la main dans les répertoires critiques (profile Firefox? mailbox?) des informations confidentielles, sans avoir aucune idée de ce qu'il va trouver et de comment il pourrait les valoriser? Il va essyer de revendre quoi? Le contenu des centaines de fichiers qui s'appellent data.txt? Divulguer le code source de "launchscript.sh"? Mes cookies linuxfr? Je me trompe peut-être, mais j'estime que la probabilité que ça arrive dans la vraie vie est inférieure de plusieurs ordres de grandeur à, par exemple, être victime d'une usurpation d'identité par voie "classique" (sans ordinateur) ou d'une arnaque bancaire. Bien sûr, on peut jouer à chiffrer ses données, et c'est probablement très formatteur, mais il ne faut pas croire que c'est réellement utile.
[^] # Re: Pour finir, n'oublie que chiffrer, c'est bien.
Posté par aurel (site web personnel, Mastodon) . Évalué à 3.
J'ai l'impression qu'on pose en gros le même regard sur le chiffrement, mais qu'on s'adresse à des personnes différentes, d'où un désaccord qui n'est je crois qu'apparent.
Pour ma part, je m'adresse aux personnes qui sont novices/naïves/désinvoltes, et à qui je suggère de prendre conscience des risques et des coûts potentiels entraînés par leurs approches, voyant le chiffrement des disques comme une pratique qui peut répondre à certains de leurs besoins de façon efficace. Je vois souvent en club des pratiques invraisemblables, un besoin criant de formation sur des trucs simples: la gestion des mots de passes, le chiffrement de disque (puisque presque tout le monde a un portable), etc.
J'ai l'impression que de ton côté, tu t'adresses plutôt aux personnes qui sont déjà un peu familiarisées avec la sécurité: assez pour être devenues quasi paranoïaques mais pas assez pour mettre en place une approche rationnelle: identification des menaces, gestion du risque, évaluer la complexité et le coût associés à un choix, etc.
Du coup, nos phrases se croisent. Reste plus qu'à espérer que les lecteurs sauront identifier la partie qui leur apportera le plus :)
# Est pour la/les version Linux
Posté par Jean-François Huck (site web personnel) . Évalué à 3.
Warning - Questions de non-informaticien ahead
Rapport intéressant mais hélas trop ardu pour moi. Je me pose la question de savoir si certaines des vulnérabilités trouvées sont également valables pour la/les versions GNU/Linux ?
La trouvaille principale - « The most severe finding » - fait référence à une API Windows, donc pour celle-ci ce ne doit pas être le cas.
Les trois autres font référence à des choses plus obscures pour moi (traduction maison, pas taper !):
- le déchiffrement des en-têtes de volumes qui se base sur des tests d'intégrité impropres à détecter des effractions
- la méthode de mélange de l'entropie des fichiers-clefs qui ne serait [cryptographiquement] pas solide.
- plusieurs implémentations d'AES qui pourraient être vulnérables à des attaques de type « cache-timing »
Ces trois-là semblent, pour moi, se rapporter au fonctionnement même de Truecrypt et pas à l'OS dans lequel on l'exécute. Cependant je me figure que l'OS a son importance, sans parler de la manière dont l'application a été compilée ?
Y a-t-il quelqu'un dans la salle qui puisse jeter un peu de lumière sur ce rapport et ses éventuelles conséquences pour les amateurs d'OS à manchots ?
Ad hoc et ab hac
[^] # Re: Est pour la/les version Linux
Posté par Jiehong (site web personnel) . Évalué à 5.
Le code est divisé en parties communes, et en parties propres pour chaque plate-forme (par exemple chez CipherShed)
Je dirais que ton analyse se tient, et que les 3 dernières trouvailles sont communes.
D'ailleurs, la manière dont c'est compilé a été pointé du doigt pour CipherShed, et il est prévu de moderniser la chaîne de compilation.
Pour moi, les points noirs dans tout ça, c'est surtout de savoir quelle branche va survivre, et sa licence. Par exemple, Veracrypt semble plus actif que CipherShed, probablement car une entreprise aide par derrière, mais la licence de Veracrypt ne m'intéresse absolument pas.
J'espère que la communauté derrière CipherShed va s’étoffer, et que sa licence sera plus pérenne que celle de TrueCrypt.
# GostCrypt
Posté par Ms-Mac . Évalué à 1.
Que pensez vous de gostcrypt avec une license GPL ??
Tout le monde a un cerveau. Mais peu de gens le savent.
[^] # Re: GostCrypt
Posté par Jiehong (site web personnel) . Évalué à 3.
Je ne suis pas si sûr :
Et il me semble qu'ils veulent utiliser différents algorithmes, mais j'ai pas trouvé de dépôt de toutes façons.
[^] # Re: GostCrypt
Posté par Ms-Mac . Évalué à 0.
Pourtant pour les sources de janvier 2015 il y a bien la licence GPL ou j'ai loupé un épisode ..
Code source gostcrypt
Tout le monde a un cerveau. Mais peu de gens le savent.
[^] # Re: GostCrypt
Posté par Jiehong (site web personnel) . Évalué à 3.
Uniquement sur tous les nouveaux fichiers. Si tu regardes un fichier source, la licence est celle de TrueCrypt.
# OpenBSD, notre sauveur?
Posté par Le Gab . Évalué à -1.
N'y a-t-il pas un projet de chiffrement de volume chez OpenBSD et qui soit portable à l'aune d'OpenSSH?
# SSD avec chiffrage matériel
Posté par SaintGermain . Évalué à 1.
Je voulais chiffrer mon SSD et j'ai appris qu'il disposait déjà d'un chiffrement intégré (AES).
C'est apparemment le cas de beaucoup de SSDs.
Dans mon BIOS, il y a un mot de passe pour démarrer et un mot de passe pour déverrouiller le SSD.
On peut mettre le même mot de passe dans les deux et le système le reconnaît et l'utilisateur n'a besoin d'entrer le mot de passe qu'une seule fois au démarrage. Pratique !
Par contre l'implémentation n'est pas toujours bien réalisée :
SSDs with usable built-in hardware-based full disk encryption
J'ai essayé d'en savoir plus mais peine perdue. J'ai quand même essayé de lire le SSD sur un autre ordinateur et j'ai pu constater que ce n'était pas possible facilement.
C'est peut-être un moyen simple et efficace de protéger sa vie privée contre les vols d'« amateurs ».
Par contre tant que je n'aurais pas compris à quel point c'est fiable, je ne pourrai pas recommander cette méthode face à Truecrypt comme vraie protection des données.
Quelqu'un a-t-il un avis éclairé sur la question du chiffrage intégré des SSDs ?
[^] # Re: SSD avec chiffrage matériel
Posté par Sufflope (site web personnel) . Évalué à 3.
De rien.
[^] # Re: SSD avec chiffrage matériel
Posté par SaintGermain . Évalué à 1.
Quel est le problème si la clé est stockée en dur mais chiffrée ?
[^] # Re: SSD avec chiffrage matériel
Posté par Le Gab . Évalué à 1.
Ben oui, tu proposeras LUKS pour *Linux ou Bitlocker™ pour windows, parce qu'on parle de chiffrement de disque, n'est-ce pas?
Cela étant tu peux créer des volumes loopback ou virtuelles chiffrés avec ces 2 méthodes mais lisibles que sur les systèmes d'exploitation respectifs.
[^] # Re: SSD avec chiffrage matériel
Posté par SaintGermain . Évalué à 1.
L'avantage du chiffrage intégré dans le SSD, c'est que c'est transparent pour l'utilisateur.
Pas besoin d'installer/configurer de logiciels (en plus d'être indépendant du système d'exploitation) et cela marche immédiatement. En plus le déverrouillage est relativement simple (mot de passe qui peut être couplé au mot de passe pour booter).
Il y a bien sûr des inconvénients (j'ai l'impression qu'il est lié à un BIOS et que beaucoup d'implémentations ne sont pas correctes).
Mais je pense qu'il peut répondre au besoin dans certains cas d'utilisation. En tout cas j'ai l'impression que c'est pas trop mal pour un premier niveau de protection.
Personnellement j'utilise en plus dm-crypt sur les données sensibles.
Je trouvais juste étonnant que l'on en parle pas plus (surtout que le sujet du chiffrement revient régulièrement sur linuxfr). Peut-être justement parce que c'est complètement bancal, mais comme je n'ai pas réussi à trouver beaucoup d'informations sur le sujet, je pose la question.
[^] # Re: SSD avec chiffrage matériel
Posté par Le Gab . Évalué à 1.
On est d'accord mais 1) c'est une solution souvent proprio, 2) on a peu de détail voire pas du tout sur l'implémentation.
On pourrait régler ce problème au niveau distro/OS en attendant d'avoir du matériel libre à ce niveau, par exemple en chiffrant par défaut le disque à l'installation au lieu de poser bêtement la question comme c'est souvent le cas.
Apple chiffre de base ses iPhone/iPad.
[^] # Re: SSD avec chiffrage matériel
Posté par SaintGermain . Évalué à 2.
Oui j'avais pensé à Apple (et aussi Android) et le chiffrage des smartphones, mais dès que l'on parte d'Apple les esprits se braquent et donc j'ai préféré évité.
Typiquement j'ai l'impression que c'est pareil que le chiffrage des SSDs (closed-source) mais que tout le monde s'accorde à dire que c'est un progrès. Encore un coup de l'effet Apple ?
Pour les SSDs, je ne me souviens pas avoir jamais vu cette fonctionnalité mise en avant.
Sinon je réfléchi depuis un moment si c'est une bonne idée de chiffrer tout le disque par défaut à l'installation mais je n'ai pas encore fait le tour de tous les arguments pour/contre.
[^] # Re: SSD avec chiffrage matériel
Posté par gouttegd (site web personnel) . Évalué à 4.
Tout le problème est là : avec ce genre de matériel, tu ne peux pas savoir si on n’est pas en train de te refourguer un truc complètement bidon. Comme lorsqu’on te vend 130 € une clef USB prétendument « sécurisée » et « approuvée par les services de renseignements français »… dont la sécurité ne vaut pas un clou.
Pourquoi se casser la tête à créer des solutions réellement sécurisées, alors qu’il suffit de faire croire aux acheteurs qu’elles le sont ?
[^] # Re: SSD avec chiffrage matériel
Posté par SaintGermain . Évalué à 1.
Oui je suis familier de l'argument "c'est closed-source/propriétaire donc c'est de facto non digne de confiance".
Même si je suis en partie d'accord, cela fait un peu FUD (comme les arguments des logiciels propriétaires contre les logiciels libres à une époque pas si lointaine).
Pour aller un peu plus loin que le FUD qui est un peu trop facile à mon goût, j'ai cherché des arguments factuels contre l'utilisation de ce chiffrage intégré des SSDs (cf. le lien que j'ai donné).
Apparemment ce genre de SSD est assez répandu (en tout cas certainement plus que la clé USB que tu cites), donc j'étais un peu étonné de ne pas trouver plus d'information à ce sujet, ou de tentative de démonter sa sécurité.
Bon si j'ai un peu de temps je vais continuer à chercher…
[^] # Re: SSD avec chiffrage matériel
Posté par gouttegd (site web personnel) . Évalué à 5.
Pas d’accord. Ce serait du FUD si on n’avait rien pour l’étayer, mais en l’espèce, les fournisseurs de solutions de sécurité closed-source ont largement démontré qu’ils n’hésitaient pas à refiler de la poudre de perlimpinpin.
Il y a peut-être des fournisseurs vertueux, mais c’est à eux de montrer que leurs solutions valent réellement quelque chose, il ne peut pas y avoir de présomption de qualité quand il s’agit de sécurité. Et qu’ils ne viennent pas dire qu’ils ne le font pas pour ne pas compromettre la sécurité de leurs produits : si leur sécurité dépend du fait que personne ne sait comment ils fonctionnent, c’est qu’ils ne fournissent aucune sécurité digne de ce nom (comme RSA et ses tokens SecurID, qu’il faut remplacer après un vol d’information chez RSA).
On sait au moins depuis Kerckhoffs, soit bien avant qu’on invente les logiciels libres, que la sécurité par l’obscurité ne fonctionne pas.
[^] # Re: SSD avec chiffrage matériel
Posté par SaintGermain . Évalué à 1.
Attention à ne pas faire d'amalgame entre toutes les sociétés.
Si on part du principe qu'ils veulent rester closed-source (quelle que soit la raison) mais qu'ils souhaitent vraiment offrir un travail sérieux, quelles sont les options pour prouver que la solution marche ?
Dans le lien que j'ai donné, ils parlent par exemple d'une certification FIPS-197 pour Intel 520. Est-ce que cela ne serait pas un début de preuve du sérieux ? (je pose la question car je n'y connais rien)
Si on me dit que toutes les certifications/audits c'est du bidon, c'est en gros l'argument qu'on ne peut jamais faire confiance à du logiciel proprio et on peut arrêter la discussion là (parce que le sujet à été maintes fois débattu).
[^] # Re: SSD avec chiffrage matériel
Posté par gouttegd (site web personnel) . Évalué à 4.
Non. « Intel 520 is compliant with FIPS-197 », ça veut juste dire que ce modèle utilise l’algorithme AES. C’est un bon début (c’est beaucoup mieux que d’utiliser un algorithme maison sorti du chapeau — AES a la confiance unanime des cryptographes), mais ça ne dit rien de la qualité de l’implémentation.
Un produit peut tout-à-fait utiliser les meilleurs algorithmes (et être « certifié » pour ça) et quand même ne rien valoir du tout.
C’est surtout que les certifications dont on parle ici ne disent pas ce que les commerciaux qui vendent ce genre de produits voudraient faire croire. Un produit « certifié FIPS-197 » n’est pas nécessairement un produit de qualité, c’est un produit qui utilise un algorithme de qualité, ce qui est très différent — et surtout, ce n’est pas suffisant pour justifier les promesses de sécurité que ces commerciaux font miroiter à leurs clients.
[^] # Re: SSD avec chiffrage matériel
Posté par oinkoink_daotter . Évalué à 3.
FIPS 197, c'est le standard AES. C'est pas lui qui va te dire que tu utilises l'algo correctement implémenté n'importe comment.
[^] # Re: SSD avec chiffrage matériel
Posté par Jiehong (site web personnel) . Évalué à 2.
Avec un projet libre d'implémentation de chiffrement AES de SSD, tu évites de ré-inventer la roue, concentre les efforts, évite d'avoir des portes dérobées pour les services secrets, tu peux vérifier ta confiance en l'implémentation toi-même…
Bref, de manière générale, si tu n'as pas accès à un système, alors il est sain de supposer qu'il n'est pas sûr.
[^] # Re: SSD avec chiffrage matériel
Posté par oinkoink_daotter . Évalué à 3.
Oui, mais ça ça n'existe pas aujourd'hui… De plus l'implémentation libre d'AES ne te garantit pas du tout qu'elle est correctement utilisée, ni même qu'elle est utilisée tout court. Ni encore que le contrôleur ne va pas te donner la clef (ou du mot de passe qui aura été stocké gentiment dans la nvram du contrôleur) si tu lis le contenu du secteur LBA 0xDEADBEEF suivi de 0xBEBECACA. Du coup, il faut faire aussi le design du contrôleur et tant qu'à faire de tout le PCB.
Bref, aujourd'hui, ça reste malheureusement très théorique.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.