Nicolas SURRIBAS

Développement / Réseau / Sécurité Informatique

cryptographie

Créez une partition cachée sous Linux

Rédigé par devloop - -

Les systèmes d'exploitation les plus utilisés proposent tous à l'heure actuelle des solutions pour chiffrer les partitions ou l'ensemble d'un disque.
L'inconvénient de ces systèmes est que la présence des données chiffrées est généralement bien visible, par exemple par le biais d'un fichier de montage (/etc/crypttab ou /etc/cryptotab sous openSUSE) et de la table des partitions permettant au système de savoir avec quel algorithme il doit déchiffrer les partitions chiffrées et sur quelle partie du disque.

Dans cet article je vais vous expliquer comment mettre en place une partition cachée qui ne sera visible ni dans la table des partitions ni décrite dans un fichier de configuration.
A l'heure actuelle, TrueCrypt propose un système de ce type mais nous utiliserons ici une méthode plus basique en nous servant de la commande losetup pour la gestion des périphériques de boucle (/dev/loop*) et de cryptsetup qui permet créer des volumes dm-crypt.

Le principe est le suivant : sur un disque dur nous allons créer une partition visible qui prendra la moitié de l'espace. Ensuite sur le reste de l'espace (tout l'espace libre restant) nous placerons notre partition chiffrée.

Créer une partition cachée sur un disque dur

Dans l'exemple qui suit le disque fait une taille de 50Mo. La partition visible fera 20Mo, le reste sera pris par notre partition secrète. A vous d'adapter les commandes en fonction de votre disque et des systèmes de fichiers que vous désirez.

On partitionne le disque à l'aide de cfdisk pour créer notre partition de 20Mo. Il est important que cette partition soit placée au début du disque :
cfdisk /dev/hda1

On récupère l'adresse de la fin de cette partition (en octets) à l'aide de la commande parted :
parted /dev/hda unit B print

Dans mon cas, la fin de la partition est à l'offset 16450559. Nous fixerons alors le début de notre partiton cachée à 16450600 (arrondir au supérieur).
On formate la partition visible en ext2, on la monte et on crée un fichier pour tester :
mkfs.ext2 /dev/hda1
mount -t ext2 /dev/hda1 /mnt/hda1
echo abcd > /mnt/hda1/truc

Passons maintenant à notre partition chiffrée. Pour ne pas faire de bétises il faut trouver le nom d'un périphérique loop non utilisé. Ceux en cours d'utilisation peuvent être obtenus par la commande suivante :
losetup -a

Dans mon cas, loop0 est déjà utilisé donc je me rabats sur loop1 :
losetup -o 16450600 /dev/loop1 /dev/hda

On crée ensuite le "mapper" qui se chargera du chiffrement. Dans mon cas il s'appelle "toto" et utilise l'algorithme par défaut (AES128). Pour plus d'infos, lisez la page de manuel de cryptsetup. Le programme vous demandera de saisir le mot de passe pour le chiffrement.
cryptsetup create toto /dev/loop1

On vérifie que notre mapper a bien été créé à l'aide de "dmsetup ls" puis on peut créer et jouer avec notre partition :
mkfs.ext2 /dev/mapper/toto
mount /dev/mapper/toto /mnt/test
echo test > /mnt/test/truc
umount /mnt/test

Quand on a fini on démonte le mapper et le périphérique de boucle :
cryptsetup remove toto
losetup -d /dev/loop1

Si on effectue une recherche sur le disque dur, on trouve une occurence pour "abcd", 0 pour "test" et une seule pour "truc". Notre partition est bien chiffrée et invisible.

Seul problème, pour ne pas à avoir à mémoriser les commandes et l'offset de la partition, il est préférable de créer un script de montage et un autre du démontage. A vous de faire marcher votre imagination pour dissimuler ces scripts.

La vrai fausse backdoor dans le chiffrement des disques durs par PGP

Rédigé par devloop - -

Il y a quelques jours, le blog Securology a publié un article traitant d'une fonctionnalité peu connue du logiciel de chiffrement de disque PGP Whole Disk Encryption (WDE) qui a provoqué quelques réactions "trollesques"...

Avant d'entrer dans le vif du sujet, il est bon de connaître à quoi sert PGP WDE et un résumé simple de son fonctionnement.
PGP Whole Disk Encryption permet, comme son nom l'indique, de chiffrer la totalité d'un disque dûr, c'est à dire : les différentes partitions, le (ou les) système(s) d'exploitation et le secteur de boot (Master Boot Record).
Quand un poste disposant de cette technologie est allumé, il boote d'abord sur du code de PGP qui va demander la saisie d'un mot de passe au clavier par l'utilisateur.
Par une suite de différents calculs cryptographiques, ce mot de passe va permettre au final le déchiffrement des données.

Dans les étapes utilisées pour arriver au lancement du système d'exploitation, la première est la déchiffrement d'une clé qui a été cryptée à l'aide du mot de passe de l'utilisateur.
Cette méthode est très utilisée, notamment pour la cryptographie à clé publique : pour éviter que la clé secrète soit compromise en cas d'intrusion et/ou de vol de données, celle-ci n'est pas stockée en clair sur le disque mais stockée chiffrée par un algorithme de chiffrement symétrique.
Ce procédé est nommé S2K / K2S (string-to-key et vice-versa), il est par exemple documenté dans la RFC 2440 : OpenPGP Message Format (chapitres 3.6.*, c'est dans la même RFC que l'on trouve une explication sur le Radix-64).

On pourrait penser que la clé déchiffrée est celle utilisée pour le déchiffrement, mais il n'en est rien. Il y a une seconde étape qui permet à partir de cette clé d'accèder à la clé maître (master key) avec laquelle le chiffrement a été utilisé.
L'objectif de ce second procédé et de permettre à différents utilisateurs de déchiffrer le disque, chacun utilisant un mot de passe différent (si j'ai bien tout compris)

Maintenant que vous connaissez (vaguement) le fonctionnement du système, il est temps de parler de la fonctionnalité baptisée "Whole Disk Encryption (WDE) Bypass".
Le nom est celui donné par PGP et est suffisament explicite : il permet de passer oûtre la saisie d'un mot de passe pour déchiffrer les données.

A quoi sert exactement cette fonctionnalité ? Elle permet aux administrateurs de faire redémarrer les machines dont le disque est chiffré par WDE.
Partons du principe que vous êtes un administrateur d'un parc réseau avec des machines ultra-sécurisées et que vous avez besoin d'effectuer différentes taches qui seront validées lors du redémarrage de la machine.
Vous lancez l'opération et vous attendez sagement que vos machines redémarrent pour continuer à travailler. Sauf que... les machines ne redémarrent pas !
En effet le système d'exploitation ne s'est pas lancé car personne n'est devant le poste pour saisir le mot de passe de déchiffrement et par conséquent la couche réseau de l'OS n'est pas disponible. Vous voilà obligé de faire le tour des machines et de saisir chaque mot de passe de déchiffrement pour remettre votre réseau en marche.

C'est là qu'intervient la fameuse fonctionnalité "bypass". Quand elle est activée, elle va stocker sur le disque une nouvelle clé de chiffrement dérivée de la master key ainsi qu'un flag disant à WDE d'utiliser cette clé automatiquement au prochain démarrage du poste. Cette clé est cryptée par le procédé S2K par un mot de passe fixe (valeur hexadécimale 0x01).

Donc :
  • l'administrateur lance ses taches sur les machines
  • il active le WDE Bypass
  • il redémarre les postes
  • WDE utilise la clé de bypass pour démarrer les postes
  • WDE supprime les données de bypass qui ont été placées sur le disque
  • les postes sont démarrés et accessibles par le réseau

Sur le principe c'est plutôt bien trouvé et c'est une fonctionnalité qui est semble très appréciée dans les entreprises (on peut comprendre). Le problème c'est que l'on baisse la sécurité du chiffrement à chaque utilisation du mode bypass : il suffit qu'un intrus subtilise une machine entre le moment de l'éteignage et celui du redémarrage pour disposer d'un disque sur lequel sont présentes toutes les informations nécessaires pour déchiffer le disque.

Le débat faire rage sur Slashdot entre ceux qui considèrent qu'il s'agit d'une backdoor et ceux qui défendent qu'il s'agit d'une fonctionnalité tout à fait normale.
En réalité quand j'essayais de comprendre le fonctionnement de tout ça, ça n'a pas été évident de trouver les commentaires de ceux qui se posaient les vrais questions sur Slashdot. Il faut dire que tout les articles sur le sujet sont en anglais et que ça ne facilite pas la tâche... heureusement c'est de l'écrit (j'ai eu l'occasion de parler anglais cet après midi et c'était l'enfer, en plus c'était une discussion avec un chinois)

Après avoir pesé le pour et le contre, mon opinion personnelle est que non, ce n'est pas une backdoor.
D'abord, bien que peu expliquée, cette fonctionnalité était citée dans la documentation. De plus PGP affiche une position claire sur cette fonctionnalité et a réagit en postant un commentaire sur le blog de l'auteur de l'article avant de donner des explications publiques.

Cependant cette fonctionnalité baisse considérablement la sécurité générale du chiffrement. Comme toujours en cryptographie, le niveau de sécurité d'un système est équivalent à celui de son mayon le plus faible. Ici on peut imaginer un malware qui active le WDE Bypass en vue d'une prochaine attaque physique, ou encore un code qui modifiera le fonctionnement du WDE... mais là on s'écarte sans doute trop du sujet.

Dans tous les cas pour activer cette fonctionnalité il faut un "cryptographic access" aux données, c'est à dire avoir des droits d'utilisateur sur la machine, c'est à dire... avoir accès aux données en clair.

En fin de compte ce qui gêne c'est que le WDE Bypass pourrait tout aussi bien être utilisé en douce, et q'une clé spéciale soit intégrée à l'installation du logiciel, chiffrée à l'aide d'une passphrase connue seulement par une certaine agence de sécurité nationnale.
Bref on en revient à la confiance que l'on donne aux développeurs des logiciels que l'on utilise. Mais c'est un procédé intéressant et je comptais bien vous faire profiter de ces articles.

Explication (simplifiée) de PGP WDE sur le site officiel (vidéo présente)
Un second article de Securology en réponse aux informations apportées par un représentant de PGP
Le premier article

La prochaine mise à jour de AACS déjà dans les choux

Rédigé par devloop - -

L'AACSLA continue d'utiliser son système de révocation des clés pour empécher la lecture de nouveaux disques haute définition sur des lecteurs dont les clés ont été rendues publiques.
La mise à jour vers ce que l'on appelle l'"AACS version 3" devrait être déployée dans ce but d'ici quelques jours, le 22 mai 2007, et être mise en place sur tous les supports HD-DVD et BluRay qui seront disponibles à la vente.

Mais c'était sans compter sur les développeurs du logiciel de déchiffrement AnyDVD qui proposent une version mise à jour de leur logiciel permettant d'effectuer une copie des médias protégés par AACS v3.
La nouvelle publiée sur Ars Technica nous informe que l'exploit est déjà "visible" par le biais des HD-DVD de Matrix 2 et 3 sortis en avance dans les rayons.

L'article de Ars Technica parle d'une nouvelle clé de volume trouvée par SlySoft, l'éditeur de AnyDVD, mais techniquement ça ne colle pas avec ce que l'on a vu jusqu'à présent.

Pour que SlySoft dévoile sa mise à jour à un tel moment, il fallait, comme le fait remarquer Freedom to Tinker, que l'éditeur ait gardé secrétement cette clé sous la main depuis un bon moment.
Je pense (et je ne suis pas le seul) que la clé en question doit plus correspondre à une Device Key, une clé qui est spécifique à (par exemple) une version d'un logiciel de lecture donnée. Les anciennes versions de AnyDVD se basaient apparemment sur des clés de PowerDVD. Evidemment, AnyDVD ne peut pas explicitement utiliser les clés d'un logiciel tiers. C'est pour cela que les clés qu'il utilise doivent être le résultat d'une opération combinant plusieurs clés à l'un des moment de l'algorithme AACS (l'AACS ce n'est pas seulement le jeu du chat et de la souris, c'est aussi jouer avec le feu sans jamais se bruler).

Le fonctionnement de AnyDVD est encore un mystère à l'heure actuelle mais déjà discuté sur Doom9. On en saura peut-être plus d'ici peu.

Quoiqu'il en soit, les pirates sont tellement en avance sur l'AACSLA qu'ils en sont à attendre les révocations pour pouvoir publier aussitôt les clés toujours fonctionnelles.
L'AACSLA quand à lui continue inlassablement de révoquer ses clés et à menacer de poursuites judicaires puisqu'il n'a plus que ce moyen pour essayer de garder la "machine" en fonctionnement (et ses clients par la même occasion).

Autres articles relatifs à l'AACS :
devloop :: AACS cassé
devloop :: Informatique en vrac
devloop :: AACS de nouveau ridiculisé
devloop :: 09F911029D74E35BD84156C5635688C0

Certains ont trouvé une façon de réprésenter graphiquement la Processing Key en RGB :
http://en.wikipedia.org/wiki/Image:Free-speech-flag.svg
09 f9: A Legal Primer (EFF)
AnyDVD method of operation (date un peu)

AACS de nouveau ridiculisé

Rédigé par devloop - -

En février dernier, un certain ATARI Vampire du forum Doom9 est parvenu à récupérer une (sub) Device Key du logiciel WinDVD.
C'est aussi par ce logiciel que plusieurs bidouilleurs se sont fait les dents sur la protection AACS et sont parvenus à la casser à plusieurs reprises.

Comme on pouvait s'y attendre, le groupe AACS Licensing Administrator a finalement eu recours au système de révocation de AACS en obligeant l'éditeur de WinDVD (InterVideo, filiale de Corel) à mettre à jour son logiciel qui incluera de nouvelles clés ainsi que de nouvelles protections anti rétro-ingénierie.

Le système de révocation est tel que les nouveaux disques HD-DVD ou BluRay seront illisibles sur l'ancienne version du logiciel WinDVD. Les utilisateurs se voient donc obligés d'effectuer une mise à jour de leur logiciels s'ils souhaitent continuer à regarder des films.
On se demande qui est le plus à plaindre dans cette histoire. Ce qui est sûr c'est que malgré toutes les protections qui pourront être ajoutées, ce ne sera qu'une question de temps avant que les nouvelles clés soient trouvées.
Ca n'a pas forcément d'utilité mais si les clés sont divulguées puis mises à jour sans cesse, les consommateurs vont probablement aller voir ailleurs et la société perdra vite sa crédibilité. Les pirates ont par conséquent en bon moyen de pression sur les éditeurs de logiciels.
Sans compter (et j'y reviens juste après) que les clés révoquées doivent être stockées sur les nouveaux disques et risqueraient de s'entasser, augmentant ainsi l'espace disque nécessaire pour placer un média protégé.

Bref c'est le jeu du chat et de la souris mais on se garde bien de la dire sur le site du AACSLA.

Quelques petites 24 heures plus tard, c'est le système de révocation en question qui est mis à mal par Geremia et arnezami sur le forum Doom9 et XBoxHacker BBS.

Geremia a effectué ses tests sur le lecteur HD-DVD de la Xbox. Il a d'abord cherché à identifier le firmware utilisé en comparant le chipset avec ceux existant puis en le désassemblant.
Après quelques heures d'analyse de code assembleur bizarre (FR30, kezako ?), il est parvenu à patcher le firmware pour retirer la procédure de vérification des clés révoquées.

Un peu plus tard, un certain xt5 a mis à disposition un programme qui va modifier le code en mémoire pour bypasser la vérification, ce qui évite la désagréable tâche d'avoir à flasher le disque.

Difficile de savoir qu'elle va être la réponse de l'AACSLA et de Microsoft. S'il faut obliger les utilisateurs à mettre à jour leur firmware ça peut être problématique.

Clubic : Une nouvelle protection HD-DVD contournée
RegHardware : Hack exposes AACS 'hole'

AACS cassé

Rédigé par devloop - -

Il y a quelques jours, un certain Arnezami a cassé la protection AACS qui protège le contenu des disques HD-DVD et Blu-Ray en rendant publique la "Processing Key" utilisée dans le procédé de déchiffrement de tous les disques commercialisés jusqu'à présent.

Ce qu'il faut comprendre dans cette histoire c'est que tôt ou tard cette protection aurait été cassé comme l'ont été de nombreux systèmes de DRM.
La protection AACS se base sur un ensemble de clés qui permet de rendre impossible (en réalité l'objectif est seulement de rendre plus difficile) l'exportation du contenu vers des supports jugés indésirables par les grandes sociétés de distribution (derrière AACS se cache Disney, Intel, Microsoft, Matsushita (Panasonic), Warner Brothers, IBM, Toshiba, et Sony) ou d'empécher la lecture sur des lecteurs considérés comme pirates.

Mais AACS ne demande pas à l'utilisateur d'effectuer une connexion à un serveur sur Internet pour effectuer une validation comme le fait Windows... Par conséquent où sont situées les clés permettant de déchiffrer le contenu protégé ? Tout simplement sur le même disque !
Ca peut sembler stupide mais c'est la technique généralement utilisée par les systèmes de DRM. Bien sûr ce n'est pas (sensé être) aussi simple : la protection se base sur tout un tas d'algorithmes cryptographiques pour que les curieux ne tombent pas trop rapidement sur ces fameuses clés.
Ajouté à ça les constructeurs de lecteurs (qui je le rappelle sont derrière AACS) ne vont pas hésiter à rajouter des protections supplémentaires sur leur matériel ou sur les logiciels de lecture de média qu'ils développent.

Mais les développeurs savent bien qu'ils ne peuvent pas dissimuler continuellement des données dans le flux d'exécution de leur programme. Il y aura forcemment un moment où ces données seront en clair. Bien sûr ils s'arangent pour que ces données soient aussitôt effacées de la mémoire mais le mal est fait.

Sur le célèbre forum du site Doom9, Arnezami a posté un schéma très pratique représentant l'algorithme de chiffrement utilisé par AACS :


La partie gauche réprésente les données présentes sur le disque acheté dans le commerce. La partie de droite représente les données présentes sur le lecteur ainsi que les calculs éffectués pour traiter les données.
Notez bien le code graphique utilisé : les données sont représentés dans des rectangles blancs aux bords arrondis. Les fonctions sont représentées par des rectangles gris qui recoivent des arguments symbolisés par les flèches.

Les premières attaques réalisées se sont concentrées sur la dernière partie de l'algorithme à savoir le déchiffrement du contenu. Pour cela il fallait seulement récupérer la "Title Key" (Kt).
Muslix64 a ouvert la danse en annonçant sur le forum Doom9 la disponibilité de son logiciel BackupHDDVD qui permet de déchiffrer le contenu. Additionnelement il expliquait dans une interview être parvenu à retrouver les Title Key de plusieurs HD-DVD en analysant la mémoire de logiciels de lecture de disques HD-DVD durant leur utilisation. D'après bon nombre de posts, il s'agirait de PowerDVD ou InterVideo WinDVD 8.

BackupHDDVD ne fait rien d'illégal. Il ne déchiffre pas les HD-DVD en un seul click. Pour déchiffrer un disque il faut lui fournir la Title Key. Or cette clé est spécifique au support et non au film !! Il faut donc avoir quelques compétences en débogage voire en reverse engineering pour retrouver la fameuse clé.
Cela a tout de même permis de voir débarquer le premier HD-DVD pirate disponible sur BitTorrent... D'autres ont suivi.

La solution pour permettre à tout le monde de déchiffrer les données consiste à remonter un peu dans l'algorithme. La Title Key est générée à partir de clés chiffrées stockées sur le disque et à partir d'une clé de volume (Kvu).
Bingo ! Cette clé de volume est spécifique au film, car créée à partir d'un identifiant unique (Volume ID).
A partir de là AACS est fortement chamboulé. Différents sites comme HDKeys et AACS Keys donnent des listes de clés de volume.
Muslix64 sort une nouvelle version de son logiciel qui se base non plus sur les Title Keys mais sur ces clés de volume. L'annonce est une fois de plus faite sur Doom9.

Ce n'est que quelques temps plus tard que Muslix64 réitérera son exploit avec Blu-Ray et un nouveau logiciel (BackupBluRay).

Vous vous demandez peut-être en regardant le schéma pourquoi les bidouilleurs ne sont pas montés directement à la source et n'ont pas publié les clés de périphériques (Device Keys) et les clés de séquences (Sequence Keys) pour les mettre dans une base de donnée.
La raison c'est que le standard AACS intègre un procédé de révocation permettant de rendre inutilisable un lecteur...
Si quelqu'un publiait des clés correspondant à un lecteur, les ingénieurs chez AACS modifieraient les clés présentes sur les prochains disques commercialisées de façon à ce que le lecteur piraté ne puisse plus rien lire de nouveau. Vous trouverez plus d'explications chez Freedom to Tinker ici et ici.

La dernière étape a été achevée par Arnezami. Il a débuté une magnifique discussion sur Doom9 en annonçant avoir trouvé le Volume ID du film KingKong.

Ce Volume ID est une structure de données qui pourrait être définie de la façon suivante en C :
struct VolumeID {
  uchar MediaType; // 0x40
  uchar Reserved;
  uchar UniqueNumber[12];
  uchar Reserved[2];
};

Dans cette structure, le premier octet est toujours fixé à 0x40. Les octets réservés sont par convention fixés à un octet nul.
Il reste alors l'ID (UniqueNumber) qui après plusieurs observations semble être prévisible.
Par exemple pour KingKong, cet ID a pour valeur :
09 18 20 06 08 41 00 20 20 20 20 20

Les permiers octets correspondent à la date de production : le 09/18/2006 à 8h41. Vient ensuite un octet nul et des espace pour remplir l'espace restant.
Cela a été validé à l'aide d'autres disques pris comme exemple.
Mais tous les disques ne se basent pas sur le principe de la date. Ainsi l'ID utilisé pour le film Serenity commence par "53 45 52 45 4e 49 54 59", ce qui se révèle être le code héxadécimal de... "SERENITY".

Mais l'objectif d'Arnezami est de remonter jusqu'à la Media Key (Km). Avec la Km et le Volume ID on pourra facilement générer les clés de volume.
Pourquoi c'est si important ? J'avoue que j'ai eu beaucoup de mal à comprendre au début...

Dans la discussion un certain noclip prétendait que le même Media Key Block (MKB) était utilisé pour tous les disques utilisés jusqu'à présent... information vite réfutée par evdberg qui possède des disques avec des MKB différents.
C'est à ce moment qu'Arnezami a évoqué la "Processing Key". Lui qui a beaucoup fouillé dans les spécifications d'AACS a relevé l'information suivante :

Once the device has the correct Device Key D, it calculates a Processing Key K using AES-G3 as described above.
Using that Processing Key K and the appropriate 16 bytes of encrypted key data C, the device calculates the 128-bit Media Key Km as follows:
Km = AES-128D(K, C) XOR (00000000000000000000000016 || uv)
The appropriate encrypted key data C is found in the Media Key Data Record in the Media Key Block.


Effectivement on peut remonter à ce niveau puisque le fameux C est lisible sur le disque dans le Media Key Block. Seul problème : comment est généré la Processing Key ?
Tout le monde (même Arnezami) s'accordent sur l'hypothèse que cette clé soit générée à partir des Device Keys.

Quelques temps après il nous faisait part de ses avancés en publiant la Media Key (Km) de KingKong.
Il est ensuite revenu en révélant la fameuse Processing Key qui à la surprise générale semble être indépendante de tous calculs et peut être utilisée pour déchiffrer tous les disques commercialisés jusqu'à présent.

Le plus drôle dans tout ça c'est qu'à aucun moment il n'a utilisé d'outils de reverse engineering... juste des logiciels d'analyse de la mémoire.
Le changement de cette clé par les personnes derrière l'AACS n'aurait pas d'effet : la nouvelle clé serait aussitôt trouvée et publiée sur Internet.