BitLocker - Sstic

8 BitLocker
3 Architecture de BitLocker
Cette partie décrit l’intégration de BitLocker au sein d’un système et l’architecture
des divers composants. S’il existe de nombreux articles de Microsoft sur ce sujet,
le document [17] (partie Full volume encryption) présente une vision complète et
technique sur le sujet.
3.1 Intégration au sein du système d’exploitation
Sous Windows, toute la gestion des périphériques (dont les disques) est sous la
responsabilité du gestionnaire d’entrées/sorties du noyau (IO manager) qui s’appuie
sur des pilotes (drivers) pour la gestion de périphériques (devices). Lorsque qu’un
pilote détecte un périphérique qu’il prend en charge, il crée généralement un objet
noyau nommé de type Device dans l’espace des objets du noyau (par convention dans
le chemin \Device\).
Les volumes de disques sont gérés par le gestionnaire de volumes (volmgr). Lors
du démarrage du système, celui-ci crée pour chaque partition reconnue un volume
représenté par un objet Device nommé HarddiskVolumeX (où X commence à 1).
Ces objets étant créés dans le répertoire \Device\ de l’espace des objets du noyau
et ne sont, théoriquement, accessibles qu’au noyau. Afin de les rendre accessibles
aux applications en espace utilisateur, des liens symboliques sont créés dans l’espace
\GLOBAL??\. Les volumes sont alors accessibles au moyen d’une lettre de lecteur (par
exemple le lien \GLOBAL??\C: redirige vers \Device\HarddiskVolume2).
Sur un système avec trois partitions (démarrage, système et données) l’organisation
est la suivante : le pilote (DRV) volmgr créé trois périphériques (DEV), un pour
chaque partition, auxquels s’ajoute un périphérique destiné à la gestion des partitions
(VolMgrControl). L’organisation hiérarchique est la suivante :
DRV - \Driver\volmgr
DEV - \Device\HarddiskVolume3
DEV - \Device\HarddiskVolume2
DEV - \Device\HarddiskVolume1
DEV - \Device\VolMgrControl
Le composant noyau principal de BitLocker est un pilote de périphérique dénommé
fvevol.sys. Ce pilote est de type filter driver [5] [6]. Ce type de pilote vient se
positionner ¡¡ au-dessus ¿¿ d’un périphérique ce qui lui permet d’intercepter toutes les
demandes adressées au périphérique inférieur (ouverture, fermeture, lecture, écriture
et IOControls). Il est d’ailleurs possible d’avoir plusieurs filter drivers chaînés en
série au-dessus d’un même périphérique, chacun interceptant séquentiellement les
demandes.