Spécifications cryptographiques - TrueCrypt v6.0a

Transcription

SOGETI
Infrastructure Services
6 - 8, Rue Duret
75016 Paris
Evaluation CSPN
TrueCrypt v6.0a
Tél. : +33(0)1.58.44.55.66
Fax : +33(0)1.58.44.26.19
Spécifications
cryptographiques
Référence SOGETI : K08-JBB-CR-672-2008
Version 1.2
Évaluation CSPN
Spécifications cryptographiques – TrueCrypt v6.0a
VALIDITE DU DOCUMENT
Identification
Client
Projet
Evaluation CSPN
Fournisseur
SOGETI IS/ESEC
Validité du document
Action
Rédaction
Date
18/08/2008
Nom
J.-B. BEDRUNE
Fonction
Consultant sécurité
Visa
Historique des modifications
Date
création
18/08/2008
Date
application
V.R.
Évolution
1.0
15/09/2008
1.1
20/10/2008
1.2
Création du document
• Ajout de commentaires sur le mode XTS
• Justification sur l’absence de détection des clés
faibles
Prise en compte des commentaires de la DCSSI
Diffusion (suivie en mise à jour)
Pascal Chour
DCSSI
Diffusion en copie (non suivie)
Édouard JEANSON
SOGETI
ESEC Manager
Référence des documents utilisés
Version
3
Référence
Nom
Documentation TrueCrypt 6.0
Par sa conception et sa réalisation technique originale, ce document est protégé par les dispositions régissant le droit de la propriété intellectuelle. Il est
notamment interdit sous peine de poursuites d'imiter ou de reproduire en tout ou partie cette conception et réalisation technique de ce document. Il est
également interdit de transmettre à des tiers ce document, ou de divulguer tous renseignements et informations contenus dans ce document, ou toute
information permettant l'imitation ou la reproduction totale ou partielle de ce document.
Ce document est l’unique propriété de SOGETI IS, et toute reproduction et/ou divulgation, sans autorisation expresse et préalable de SOGETI IS, est interdite.
 SOGETI I.S.
Division : Consulting Agence : ESEC.
Réf : K08-JBB-CR-672-2008
Page 2 / 26
Évaluation CSPN
TABLE DES MATIERES
VALIDITE DU DOCUMENT ..................................................................................................................................... 2
TABLE DES MATIERES ........................................................................................................................................... 3
IDENTIFICATION DU PRODUIT EVALUE ................................................................................................................. 4
1.
DESCRIPTION DES MECANISMES CRYPTOGRAPHIQUES ............................................................................... 7
1.
2.
3.
4.
5.
6.
2.
CONFORMITE DES MECANISMES CRYPTOGRAPHIQUES ............................................................................. 15
1.
2.
3.
4.
3.
CONFORMITE PAR SEQUENCES ETALONS .................................................................................................................15
CONFORMITE PAR REVUE DE CODE SOURCE .............................................................................................................20
CONFORMITE DU GENERATEUR D’ALEA ...................................................................................................................21
CONFORMITE DES FONCTIONS DE CALCUL D’INTEGRITE ..............................................................................................21
ROBUSTESSE DES MECANISMES CRYPTOGRAPHIQUES .............................................................................. 22
1.
2.
3.
4.
4.
ALGORITHMES DE CHIFFREMENT – MODES DE CHIFFREMENT ........................................................................................7
HACHAGE DES DONNEES ........................................................................................................................................9
INTEGRITE DES DONNEES .......................................................................................................................................9
GENERATION D’ALEA ............................................................................................................................................9
METHODES DE GENERATION DES ELEMENTS SECRETS .................................................................................................13
EFFACEMENT DES ELEMENTS SECRETS .....................................................................................................................15
ROBUSTESSE DES ALGORITHMES DE CHIFFREMENT SYMETRIQUE...................................................................................22
PROCEDURES DE VALIDATION DES ELEMENTS SECRETS................................................................................................23
TRAITEMENT DU MOT DE PASSE UTILISATEUR ...........................................................................................................24
MECANISME DE DERIVATION DE CLE PBKDF2 .........................................................................................................25
BIBLIOGRAPHIE .......................................................................................................................................... 26
FIN DU DOCUMENT ............................................................................................................................................ 26
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 3 / 26
Évaluation CSPN
Identification du produit évalué
Nom de l’éditeur
Nom du produit
Nº de version analysée
Correctifs éventuels appliqués
 SOGETI I.S.
TrueCrypt Foundation
TrueCrypt
6.0a
Réf : K08-JBB-CR-672-2008
Page 4 / 26
Évaluation CSPN
Sommaire
VALIDITE DU DOCUMENT ..................................................................................................................................... 2
TABLE DES MATIERES ........................................................................................................................................... 3
IDENTIFICATION DU PRODUIT EVALUE ................................................................................................................. 4
1.
DESCRIPTION DES MECANISMES CRYPTOGRAPHIQUES ............................................................................... 7
1.
2.
3.
4.
5.
6.
2.
ALGORITHMES DE CHIFFREMENT – MODES DE CHIFFREMENT ........................................................................................7
Algorithmes de chiffrement implémentés ...........................................................................................................7
Séquences d’algorithmes de chiffrement utilisées ..............................................................................................7
Modes de chiffrement .........................................................................................................................................7
HACHAGE DES DONNEES ........................................................................................................................................9
INTEGRITE DES DONNEES .......................................................................................................................................9
GENERATION D’ALEA ............................................................................................................................................9
Description générale............................................................................................................................................9
Éléments extérieurs ...........................................................................................................................................10
Alimentation du tableau d’aléa ......................................................................................................................... 11
Fonction de mélange .........................................................................................................................................11
Obtention d’aléa................................................................................................................................................12
METHODES DE GENERATION DES ELEMENTS SECRETS .................................................................................................13
Génération de la clé maitresse et de la clé secondaire......................................................................................13
Génération des clés d’en-tête ............................................................................................................................13
Génération des fichiers clés ...............................................................................................................................15
EFFACEMENT DES ELEMENTS SECRETS .....................................................................................................................15
CONFORMITE DES MECANISMES CRYPTOGRAPHIQUES ............................................................................. 15
1.
CONFORMITE PAR SEQUENCES ETALONS .................................................................................................................15
Conformité de l’implémentation d’AES .............................................................................................................15
Conformité de l’implémentation de Twofish .....................................................................................................16
Conformité de l’implémentation de Serpent .....................................................................................................16
Conformité de l’implémentation de SHA-512 ....................................................................................................16
Conformité de l’implémentation de Whirlpool ..................................................................................................18
Conformité de l’implémentation de RIPEMD-160 .............................................................................................19
Conformité de l’implémentation de PBKDF2 .....................................................................................................19
Conformité de l’implémentation du mode XTS ..................................................................................................20
2. CONFORMITE PAR REVUE DE CODE SOURCE .............................................................................................................20
Effacement des données sensibles ....................................................................................................................20
Algorithme de dérivation de clé PBKDF2 ...........................................................................................................21
3. CONFORMITE DU GENERATEUR D’ALEA ...................................................................................................................21
4. CONFORMITE DES FONCTIONS DE CALCUL D’INTEGRITE ..............................................................................................21
3.
ROBUSTESSE DES MECANISMES CRYPTOGRAPHIQUES .............................................................................. 22
1.
ROBUSTESSE DES ALGORITHMES DE CHIFFREMENT SYMETRIQUE...................................................................................22
Twofish ..............................................................................................................................................................22
AES.....................................................................................................................................................................22
Serpent ..............................................................................................................................................................22
Mode opératoire XTS pour le chiffrement par blocs ..........................................................................................23
2. PROCEDURES DE VALIDATION DES ELEMENTS SECRETS................................................................................................23
3. TRAITEMENT DU MOT DE PASSE UTILISATEUR ...........................................................................................................24
Description générale..........................................................................................................................................24
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 5 / 26
Évaluation CSPN
Manipulation des fichiers clés ...........................................................................................................................24
4. MECANISME DE DERIVATION DE CLE PBKDF2 .........................................................................................................25
4.
BIBLIOGRAPHIE .......................................................................................................................................... 26
FIN DU DOCUMENT ............................................................................................................................................ 26
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 6 / 26
Évaluation CSPN
Ce document présente les mécanismes cryptographiques mis en œuvre dans TrueCrypt 6.0. Il recense
en particulier les différences existantes entre cette version et la version 4.2 précédemment évaluée.
1. Description des mécanismes cryptographiques
1. Algorithmes de chiffrement – Modes de chiffrement
Algorithmes de chiffrement implémentés
Les volumes TrueCrypt peuvent être chiffrés avec les fonctions suivantes :
Algorithme
Taille de clé (bits)
Taille de bloc (bits)
Mode opératoire
AES
256
128
XTS, LRW, CBC
Serpent
256
128
XTS, LRW, CBC
Twofish
256
128
XTS, LRW, CBC
Blowfish
448
64
LRW, CBC
CAST5
128
64
LRW, CBC
3DES
192 (168 utilisés)
64
LRW, CBC
Seuls les algorithmes AES, Serpent et Twofish utilisant le mode opératoire XTS peuvent être utilisés lors
de la création d’un volume TrueCrypt avec la version 6.0. Les autres algorithmes et modes opératoires
sont présents pour des raisons de compatibilité avec les anciens volumes.
Séquences d’algorithmes de chiffrement utilisées
Les séquences de chiffrement correspondent à deux cas :
• Au sein d’un mode de chiffrement, l’opération de chiffrement est réalisée à l’aide d’algorithmes
de chiffrement en cascade.
• La séquence de chiffrement est une suite de modes de chiffrements successifs. Chaque bloc est
chiffré en mode CBC avec une fonction de chiffrement, puis chiffré de nouveau en mode CBC
avec une fonction de chiffrement différente.
Séquence
AES-Twofish
AES-Twofish-Serpent
Serpent-AES
Serpent-Twofish-AES
Twofish-Serpent
AES-Blowfish
AES-Blowfish-Serpent
Taille de clé (bits)
256, 256
256, 256, 256
256, 256
256, 256, 256
256, 256
256, 448
256, 448, 256
Taille de bloc (bits)
128
128
128
128
128
128, 64
128, 64, 128
Mode opératoire
XTS, LRW, outer CBC
XTS, LRW, outer CBC
XTS, LRW, outer CBC
XTS, LRW, outer CBC
XTS, LRW, outer CBC
Inner CBC
Inner CBC
Seules les 4 premières séquences sont utilisables lors de la création d’un nouveau volume, en utilisant
le mode XTS. Le chiffrement se fait en cascade.
Toutes les autres séquences sont présentes pour des raisons de compatibilité avec les anciens volumes.
Modes de chiffrement
Trois modes de chiffrement sont implémentés. Le mode XTS est le seul utilisable lors de la création
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 7 / 26
Évaluation CSPN
d’un volume. Les modes CBC et LRW sont présents pour
pour des raisons de compatibilité.
Le mode XTS mis en œuvre est celui décrit dans IEEE 1619 (1).
Modes inner CBC, outer CBC et LRW
Ces modes sont détaillés dans laa spécification cryptographique de la version 4.2.
4.2
Mode XTS
Le mode XTS est défini comme suit :
où :
•
•
•
•
•
•
est la multiplication de deux polynômes sur le corps binaire GF(2) modulo ! 1;
1 est la clé de chiffrement (256 bits pour chaque algorithme supporté, soient AES, Serpent et
Twofish ;
2 est la clé secondaire (256 bits pour chaque algorithme supporté, soient AES, Serpent et
Twofish ;
est l’indice du bloc à l’intérieur d’une unité de
d données ; l’indice du premier bloc est 0 ;
est l’indice de l’unité de données pour ; l’indice du premier bloc est 0 ;
est un élément premier de 2 qui correspond au polynôme (i.e., 2).
Dans le cas de TrueCrypt, la taille de chaque unité de données est toujours de 512 octets, quelle que
soit la taille des secteurs.
Figure 1 - Chiffrement AES-XTS
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 8 / 26
Évaluation CSPN
2. Hachage des données
Une fonction de hachage spécifiée par l’utilisateur est utilisée par le générateur d’aléa de TrueCrypt
comme fonction de « mélange » pseudo-aléatoire, et lors de la dérivation des clés de l’en-tête de
volume (HMAC reposant sur une fonction de hachage, comme spécifié dans PKCS #5 v2.0). Lors de la
création d’un nouveau volume, le générateur d’aléa génère une clé maîtresse, une clé secondaire (en
mode XTS), et un sel.
Les fonctions de hachage utilisées sont :
- RIPEMD-160 (taille du condensat : 160 bits) ;
- SHA-512 (taille du condensat : 160 bits) ;
- Whirlpool (taille du condensat : 512 bits) ;
- SHA-1 (taille du condensat : 160 bits).
Les fonctions de hachage SHA-256 et SHA-384 sont également présentes dans les sources de TrueCrypt,
mais ne sont pas utilisés.
Il n’est pas possible d’utiliser SHA-1 lors de la création d’un nouveau volume. Cette primitive n’est
présente que pour des raisons de compatibilité avec les anciens volumes.
3. Intégrité des données
Lors du déchiffrement de l’en-tête du volume avec le mot de passe utilisateur, des vérifications
d’intégrité sont effectuées sur les données de l’en-tête, afin de s’assurer que le mot de passe entré est
correct.
L’intégrité de chaque en-tête d’un volume déchiffré est vérifiée par deux CRC-32 : le premier, situé à
l’adresse 72, est le CRC-32 des octets 256 à 511. Le second, à l’adresse 252, est celui des octets 64 à
251. Une autre vérification est effectuée lors de la vérification du déchiffrement de l’en-tête : les 4
octets à l’adresse 4 doivent être égaux à la chaine « TRUE » en ASCII.
4. Génération d’aléa
Description générale
Les seules différences entre le générateur d’aléa de la version 4.2 et celui de la version 6.0a sont :
• l’utilisation d’un tableau d’aléa de 640 octets. La version 4.2 travaillait sur un tableau de 320
octets ;
• la fonction de mélange est appelée chaque fois que 16 octets sont ajoutés dans le tableau, et
non plus 8 ;
• les fonctions de hachage utilisées : SHA-1 a été remplacé par SHA-512 ;
Le générateur d’aléa est utilisé pour générer la clé de chiffrement maitresse, la clé secondaire (pour le
mode XTS), le sel de l’en-tête du volume, les fichiers de clés et les données aléatoires remplissant un
nouveau volume.
La fonction de génération d’aléa ne repose pas sur un standard. Sa conception repose sur les travaux
présentés dans(2) et (3).
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 9 / 26
Évaluation CSPN
Cette fonction utilise un tableau d’aléa " alimenté par des données fournies par le système
d’exploitation, le générateur cryptographique fourni par le système d’exploitation, les frappes clavier et
le mouvement de la souris.
Une fonction de mélange est appelée dès que 16 nouveaux octets ont été ajoutés dans le tableau.
Éléments extérieurs
Les différents types de sources utilisées sont :
• les mouvements de la souris hookés à l’aide de SetWindowsHookEx ;
• les frappes clavier hookés à l’aide de SetWindowsHookEx ;
• des valeurs retournées par le(s) générateur(s) d’aléa du système :
o CryptoAPI : 640 octets retournés par la fonction CryptGenRandom ;
• les statistiques des interfaces réseau ;
o Tampon alloué par la fonction NetStatisticsGet. Les informations sont récupérées sur
les services « Server » et « Workstation » ;
• des données statistiques sur les disques
o Tampon retourné par DeviceIoControl avec le code IOCTL_DISK_PERFORMANCE sur
chaque disque ;
• Des valeurs diverses retournées par plusieurs API, récoltées à 500ms d’intervalle.
o Fonctions renvoyant un entier de 4 octets :
GetActiveWindow
GetCapture
GetClipboardOwner
GetClipboardViewer
GetCurrentProcess
GetCurrentProcessId
GetCurrentThread
GetCurrentThreadId
GetCurrentTime
GetDesktopWindow
GetFocus
GetInputState
GetMessagePos
GetMessageTime
GetOpenClipboardWindow
GetProcessHeap
GetProcessWindowStation
GetQueueStatus
o Fonctions remplissant un tableau d’octets :
GetCaretPos
GetCursorPos
GlobalMemoryStatus
GetThreadTimes (tous les tampons retournés sont utilisés)
GetProcessTimes (tous les tampons retournés sont utilisés)
GetProcessWorkingSetSize (tous les tampons retournés sont utilisés)
GetStartupInfo
QueryPerformanceCounter, ou GetTickCount en cas d’échec
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 10 / 26
Évaluation CSPN
Contrairement
aux
autres
fonctions,
les
fonctions
GetStartupInfo
et
QueryPerformanceCounter ne peuvent être appelées qu’une seule fois.
Les fonctions utilisant ces sources sont :
• KeyboardProc : le hook sur les frappes clavier ;
• MouseProc : le hook sur les mouvements de la souris ;
• FastPoll : la fonction d’alimentation rapide. Cette fonction est appelée toutes les 500ms
par un thread d’alimentation, ThreadSafeThreadFunction, ainsi que par la fonction
RandGetBytes, qui retourne des séquences d’octets aléatoires.
Alimentation du tableau d’aléa
Les fonctions précédentes écrivent toutes des données dans le tableau d’aléa. L’ajout d’une valeur dans
le tableau d’aléa " se fait avec la fonction RandaddByte. Avant qu’une valeur ne soit écrite dans ce
tableau, elle est préalablement convertie en suite d’octets (par exemple, un nombre de 32 bits est
converti en 4 octets).
Les octets sont ensuite écrits dans le tableau avec une addition module 28 (et non pas en remplaçant
les anciennes valeurs du tableau) à l’endroit où est positionné le curseur dans le tableau.
Après qu’un octet a été écrit, le curseur, appelé nRandIndex, est décalé d’un octet. Une fois le
curseur arrivé à la fin du tableau, il est repositionné au début du tableau.
Quand 16 octets ont été ajoutés au tableau, une fonction de « mélange » RandMix est appliquée sur
l’intégralité du tableau.
Algorithme : RandaddByte
Entrée : un octet v
Sortie : pas de sortie
1. "#$#% "#$#% &'# 640
2. "+,-+./+.01 2 "+,-+./+.01 &'# 2
3. Si "#$#% &'# 16 0 Faire:
a. Mélanger " avec RandMix
4. Fin Si
5. "#$#% "#$#% 1
Fonction de mélange
Le rôle de cette fonction est de disperser au maximum l’entropie de chaque octet ajouté sur la totalité
du tableau d’aléa. Cette fonction est appelée sur la totalité du tableau chaque fois que 16 octets ont
été écrits sur celui-ci.
Algorithme : RandMix
Entrée : pas de valeur d’entrée
Sortie : pas de valeur de sortie
1. Soit " le tableau d’aléa
2. Soit H la fonction de hachage sélectionnée par l’utilisateur (SHA-512, RIPEMD-160 ou Whirlpool)
3. l est la longueur en octets du condensat retourné par la fonction H. Si H est RIPEMD-160, l = 20 ; si
H est SHA-512 ou Whirlpool, l = 64
4. z est la longueur en octets du tableau d’aléa (640 octets)
5. q z / l – 1 (par exemple, si H est Whirlpool, alors q = 9)
6. " est divisé en blocs de l octets : B0… Bq
Pour 0 ; ; < faire :
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 11 / 26
Évaluation CSPN
a. = > ?B@ A ?B A ?… ABC [le tableau d’aléa est haché par la fonction H, qui retourne le
condensat M]
b. BD BD =
7. " ?B@ A ?B A ?… ABC
1.
2.
3.
4.
Par exemple, si q = 1, le tableau d’aléa sera mélangé comme suit :
?B@ AB "
B@ B@ >B@ AB ?
B B >B@ AB ?
" B@ AB ?
Obtention d’aléa
Deux fonctions retournent des suites d’octets aléatoires :
• RandpeekBytes retourne une partie de tableau d’aléa.
• RandgetBytes retourne une partie du tableau d’aléa, et met à jour ce dernier en appelant
les fonctions d’alimentation du tableau et la fonction de mélange.
La taille des données retournées lors de chaque appel à une de ces fonctions est inférieure ou égale à la
taille du tableau d’aléa, soit 640 octets.
RandpeekBytes
Cette fonction retourne directement des valeurs contenues dans le tableau d’aléa. Elle est appelée
pour afficher l’état du tableau d’aléa lors de la génération des clés de chiffrement du volume, dans
l’interface utilisateur de TrueCrypt Format. L’état complet du tableau n’est jamais affiché.
La fonction est également utilisée lors du formatage des volumes, si l’option de formatage rapide n’est
pas activée : le volume est rempli de données aléatoires retournées par cette fonction. Les données ne
sont pas écrites en clair : elles sont chiffrées avec deux clés temporaires E1, E2 en mode XTS, avec
l’algorithme de chiffrement utilisé pour le chiffrement du volume. Ces clés sont générées avec
randgetBytes.
Algorithme : randpeekBytes
Entrée : un tableau G de taille H octets
Sortie : le tableau G rempli avec H octets aléatoires
1. Si H I 640 Alors :
a. Retourner une erreur
2. Fin Si
3. Soit " "@ , " , … "JKL le tableau d’aléa
4. Copier "@ , " , … "MN dans G
RandgetBytes
randgetBytes retourne une suite d’octets aléatoires. Elle remet à jour le tableau d’aléa,
contrairement à randpeekBytes. Un paramètre d’entrée spécifie si la fonction d’alimentation lente
doit être appelée avant de retourner des données.
Algorithme : randgetBytes
Entrée : un tableau G de taille H octets, un booléen forceSlowPoll
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 12 / 26
Évaluation CSPN
Sortie : le tableau G rempli avec H octets aléatoires
1. Si forceSlowPoll est VRAI ou que SlowPoll n’a jamais été appelé Faire :
a. Appeler SlowPoll
2. Fin Si
3. Appeler FastPoll
4. Si H I 640 Alors :
a. Retourner une erreur
5. Fin Si
6. Pour 0 ; O H Faire :
a. GD "D
b. 1 &'# 640
7. Fin Pour
8. Pour 0 ; 640 O H Faire :
a. "D ~"D en notant ~ l’opérateur complément à 2
9. Fin Pour
10. Appeler FastPoll
11. Pour 0 ; O H Faire :
a. GD GD "D
b. 1 &'# 640
12. Fin Pour
Les données aléatoires obtenues par l’intermédiaire de cette fonction sont les clés de chiffrement du
volume, le sel de l’en-tête de volume, l’en-tête du volume caché s’il n’y a pas de volume caché (l’entête est alors rempli de données aléatoires), les fichiers clés, la génération des clés temporaires de
chiffrement lors du remplissage des volumes nouvellement formatés, et l’identifiant de volume pour les
partitions FAT.
5. Méthodes de génération des éléments secrets
Génération de la clé maitresse et de la clé secondaire
Les clés maitresse et secondaire sont retournées par la fonction randgetBytes.
Leur taille dépend des algorithmes utilisés. Par exemple, en utilisant AES, Serpent ou Twofish, la clé
primaire et la clé secondaire auront toutes deux une longueur de 256 bits. Ces tailles seront trois fois
plus grandes si les 3 algorithmes de chiffrement symétrique disponibles sont utilisés en cascade.
Génération des clés d’en-tête
Principe de fonctionnement
La clé d’en-tête est utilisée pour chiffrer et déchiffrer la zone chiffrée de l’en-tête d’un volume
TrueCrypt. Cet en-tête contient la clé maître utilisée pour chiffrer le volume. TrueCrypt utilise PBKDF2,
décrit dans PKCS #5 v2.0, pour générer la clé d’en-tête et la clé secondaire d’en-tête (en mode XTS).
Un sel de 512 bits est utilisé. Il est généré par la fonction randgetBytes lors de la création du
volume.
La fonction de dérivation de la clé maitresse repose sur un HMAC-SHA-512, un HMAC-RIPEMD-160 ou
un HMAC-Whirlpool selon la fonction de hachage choisie par l’utilisateur. La longueur des clés dérivées
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 13 / 26
Évaluation CSPN
n’est pas dépendante de la fonction de hachage. Par exemple, la clé d’en-tête d’un volume chiffré avec
AES-256 sera toujours 256 bits, même si un HMAC-RIPEMD-160 est utilisé (le mode XTS nécessite en
fait une clé secondaire. Ce sont donc deux clés de 256 bits qui doivent être générées).
La fonction de dérivation effectue 1000 itérations (ou 2000 si la fonction de hachage utilisée est
RIPEMD-160) lors de la dérivation de la clé maitresse, conformément aux préconisations de PBKDF2.
Les clés d’en-tête pour les modes en cascade sont toutes mutuellement indépendantes, bien que
dérivées d’un même mot de passe. Par exemple, pour la cascade AES-Twofish-Serpent, la fonction de
dérivation de la clé d’en-tête dérive du mot de passe une clé de 768 bits (et, en mode XTS, une clé
secondaire d’elle aussi 768 bits). La clé générée est ensuite divisée en 3 clés de 256 bits (en mode XTS,
la clé secondaire est également divisée, et on obtient au final 6 clés de 256 bits). La première clé est
utilisée par Serpent, la seconde par Twofish et la dernière par AES.
Traitement du mot de passe utilisateur
Mot de passe utilisateur
Le traitement du mot de passe utilisateur est le même que dans la version 4.2. Une fonction est
appliquée aux fichiers clé, et au mot de passe s’il est présent, pour obtenir un mot de passe modifié de
64 octets. Dans le cas où il n’y a pas de fichiers clés, le mot de passe utilisateur n’est pas modifié.
Fichiers clés
Le mécanisme de traitement des fichiers clés est identique à celui de la version 4.2. Un traitement est
appliqué au contenu de chaque fichier clé pour obtenir l’équivalent d’un mot de passe de 64
caractères.
TrueCrypt recommande l’utilisation de fichiers clés d’au moins 30 caractères, contre 16 dans la version
4.2.
Le paramètre preserveTimestamp des fonctions KeyFilesApply et KeyFileProcess a été
supprimé. Il indiquait si l’empreinte de temps des fichiers clés devait être préservée, afin de masquer
les accès en lecture faits par TrueCrypt. La préservation de l’empreinte est maintenant forcée.
Dérivation selon PKCS #5 v2.0
La fonction de dérivation est identique à celle de la version 4.2. Seule une fonction de hachage a été
remplacée.
Cette fonction dérive les clés d’en-tête à partir du mot de passe modifié et de la graine du disque
chiffré. Elle remplit un tableau d’octets, dont la taille dépend des algorithmes de chiffrement utilisés.
Deux clés par algorithme utilisé sont générées en mode XTS. Pour un chiffrement AES, cette fonction
retournera donc un tableau de 512 bits, qui sera ensuite coupée en deux clés de 256 bits.
Cas de SHA-1 :
La fonction de hachage SHA-1 est remplacée par SHA-512. Les modifications par rapport à la version
précédente sont les suivantes :
• L’appel à la fonction derive_key_sha1 est remplacé par l’appel à derive_key_sha512.
• La fonction de génération d’aléa hmac-SHA-1 est remplacée par hmac-SHA-512.
• Le nombre d’itérations est fixé à 1000 et non à 2000.
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 14 / 26
Évaluation CSPN
Génération des fichiers clés
Les fichiers clés sont remplis par les données retournées par la fonction randgetBytes du
générateur d’aléa.
6. Effacement des éléments secrets
Les méthodes d’effacement des éléments secrets sont les mêmes que celles utilisées dans la version
4.2.
2. Conformité des mécanismes cryptographiques
1. Conformité par séquences étalons
Des fonctions de tests des fonctions cryptographiques sont mises en œuvre dans TrueCrypt. Ces
vérifications se font par séquences étalons, et sont exécutées au lancement du programme et à la
demande de l’utilisateur. Les tests sont très basiques, en grande partie à cause des contraintes de
temps d’exécution. Ces tests n’ont pas été pris en compte pour l’évaluation de la conformité des
algorithmes.
Les tests ont été réalisés à partir de séquences étalons. Les fonctions de chiffrement sont toutes des
candidates pour AES. Ce sont les séquences générées par l’implémentation de référence qui ont été
utilisées.
Les séquences étalons des fonctions de hachage proviennent de sources diverses.
Conformité de l’implémentation d’AES
Les suites étalon utilisées sont celles du NIST :
http://csrc.nist.gov/archive/aes/rijndael/rijndael-vals.zip.
Les tests ont été réalisés sur :
• Chiffrement AES en mode ECB avec des clés de 256 bits
• Déchiffrement AES en mode CBC avec des clés de 256 bits
Il s’agit de tests de Monte Carlo. L’algorithme utilisé pour le chiffrement est le suivant :
Algorithme : AESMonteEncryptECB
Entrées : Une clé K1 de 256 bits, un message m1
Sortie : VRAI si le test est correct, FAUX sinon
1. Initialiser E@ et &@
2. Pour 0 ; O 400 Faire :
a. Pour 0 ; Q O 10000 Faire :
i. Calculer RS %T &S ii. &SU RS
b. Fin Pour
c. Vérifier que Ci est conforme. Sinon retourner FAUX
d. Générer ki+1
3. Fin Pour
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 15 / 26
Évaluation CSPN
4. Retourner VRAI
Le test est analogue pour le déchiffrement, en utilisant la fonction de déchiffrement dk au lieu de ek.
La conformité du chiffrement et du déchiffrement en mode CBC n’a pas été étudiée, ce mode n’étant
plus disponible dans la version 6.
Les résultats en mode ECB sont positifs.
Algorithme
Test
Résultat
AES
AESMonteEncryptECB
OK
AES
AESMonteDecryptECB
OK
Conformité de l’implémentation de Twofish
Les tests sont identiques à ceux réalisés sur AES. Les séquences étalon sont ceux fournis au NIST lors de
la soumission pour AES :
http://www.schneier.com/code/twofish-kat.zip
Algorithme
Test
Résultat
Twofish
TwofishMonteEncryptECB
OK
Twofish
TwofishMonteDecryptECB
OK
Conformité de l’implémentation de Serpent
Les tests sont identiques à ceux réalisés sur AES. Les séquences étalon sont ceux fournis au NIST lors de
la soumission pour AES :
http://www.cl.cam.ac.uk/~rja14/Papers/serpent.tar.gz
Serpent
SerpentMonteEncryptECB
Résultat
Serpent
SerpentMonteEncryptECB
OK
Serpent
SerpentMonteDecryptECB
OK
Conformité de l’implémentation de SHA-512
Les tests réalisés sur SHA-512 utilisent les séquences étalon du NIST (« SHA Test Vectors for Hashing
Byte-Oriented Messages »). Ils sont disponibles à l’adresse :
http://csrc.nist.gov/groups/STM/cavp/documents/shs/shabytetestvectors.zip
La méthodologie utilisée est fondée sur celle du NIST détaillée dans (4). Il s’agit d’effectuer trois tests :
un avec des messages courts, un avec des messages longs et un dernier avec des messages pseudoaléatoires.
Messages courts
Une mise en œuvre de SHA doit générer correctement des empreintes pour des messages de longueur
arbitraire. Le test suivant porte sur la génération d’empreintes sur plusieurs messages courts, c'est-àdire dont la longueur est inférieure à l’espace de travail utilisé par l’algorithme. Les empreintes sont
calculées sur une série de messages de taille 0 à 1024 bits, par échelon de 8 bits.
Algorithme : SHA512ShortMsg
Entrée : une liste de 129 éléments (mi, hi), avec mi des messages de longueur 0 à 1024 bits
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 16 / 26
Évaluation CSPN
Sortie : VRAI si le test a réussi, FAUX sinon.
1. Pour 0 ; ; 128 Faire :
a. Calculer WDX >&D b. Si WDX Y WD :
i. Retourner FAUX
c. Fin Si
2. Fin Pour
3. Retourner VRAI
Messages longs
Une mise en œuvre de SHA doit générer correctement des empreintes pour des messages dépassant la
longueur de l’espace de travail de SHA. La taille m des messages vérifiés varie de & 99 ; H ; & [
100 avec l taille de l’espace de travail (ici 1024 bits), soit ici :
1024 8 [ 99 [ , 1 ; ; 128.
Algorithme : SHA512LongMsg
Entrée : une liste de 128 éléments (mi, hi) avec mi des messages de longueur 1816 à 102400 bits
Sortie : VRAI si le test a réussi, FAUX sinon
1. Pour i de 1 à 129 Faire :
a. Calculer WDX >&D b. Si WDX Y WD Alors :
i. Retourner FAUX
c. Fin Si
2. Fin Pour
3. Retourner VRAI
Messages pseudo-aléatoires
Il s’agit d’un test de Monte Carlo. Les messages sont générés à partir d’une graine de 512 bits. La
graine est utilisée par un générateur d’aléa pour créer 100000 empreintes. Une empreinte sur 1000 est
enregistrée et vérifiée.
Algorithme : SHA512Monte
Entrée : une graine s, une liste de messages WS , 0 ; Q O 100
1. Pour 0 ; Q O 100 Faire :
a. & & &@ \
b. Pour i de 3 à 1003 Faire :
i. Calculer &D >&DNK |&DN |&DN c. Fin Pour
d. &S \ &@@
e. Si &S Y WS :
i. Retourner FAUX
f. Fin Si
2. Fin Pour
3. Retourner VRAI
Les trois tests sont positifs.
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 17 / 26
Évaluation CSPN
Algorithme
SHA-512
SHA-512
SHA-512
Test
SHA512ShortMsg
SHA512LongMsg
SHA512Monte
Résultat
OK
OK
OK
Remarque : des tests identiques ont également été réalisés avec SHA-1, même si celui-ci n’est plus
disponible dans la version 6. Les tests s’adaptaient facilement, cette fonction a donc également été
testée. Les résultats sont également tous positifs.
Conformité de l’implémentation de Whirlpool
Les séquences étalon utilisées sont celles de la soumission de l’algorithme pour le projet NESSIE. La
mise en œuvre utilisée par TrueCrypt est l’implémentation NESSIE de référence, légèrement modifiée.
Les tests ont tout de même été réalisés.
Les séquences étalon sont disponibles ici :
http://planeta.terra.com.br/informatica/paulobarreto/whirlpool.zip
Trois tests ont été effectués :
• un test sur des messages de taille variable ayant tous leurs bits à zéro ;
• un autre sur des messages de 512 bits contenant un seul bit à 1 ;
• un dernier sur un message de 512 bits à 0, et dont l’empreinte est ré-hachée 100 000 000 de
fois.
Messages de longueur variable
Ce test calcule l’empreinte de messages de taille allant de 0 à 1023 bits. Tous les bits de chaque
message sont à zéro. Les résultats obtenus sont comparés à la séquence de référence.
Algorithme : NESSIELength
Entrée : une liste d’empreintes WD , 0 ; O 1024
1. Pour 0 ; O 1024 Faire :
a. Générer un message M de longueur i bits, avec tous ses bits à 0
b. Calculer WDX >=
c. Si WDX Y WD :
i. Retourner FAUX
d. Fin Si
2. Fin Pour
3. Retourner VRAI
Message de 512 bits contenant un seul bit à 1
Ce test calcule l’empreinte de 512 messages mi de 512 bits. Le ième bit,0 ; O 512, est mis à 1 pour
chacun des messages. Les résultats obtenus sont comparés à la séquence de référence.
Algorithme : NESSIEOneBit
Entrée : une liste d’empreintes WD , 0 ; O 512
1. Pour 0 ; O 512 Faire :
a. Générer un message M de 512 bits dont seul le ième bit est mis à 1
b. Calculer WDX >=
c. Si WDX Y WD :
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 18 / 26
Évaluation CSPN
i. Retourner FAUX
d. Fin Si
2. Fin Pour
3. Retourner VRAI
Calcul d’une empreinte sur 100 millions d’itérations
Ce test calcule l’empreinte d’un message de 512 bits tous à zéro. L’empreinte résultante est ensuite
hachée, ceci 100 millions de fois.
Algorithme : NESSIEHundredMillion
Entrée : une empreinte h
Sortie : VRAI si le test à réussi, FAUX sinon
1. Générer m la chaine de 512 bits tous à 0
2. Pour 0 ; O 100000000 Faire :
a. Calculer h’ = H(M)
b. M = h’
3. Fin Pour
4. Si h = h’ retourner VRAI, sinon retourner FAUX
Les trois tests sont positifs.
Algorithme
Whirlpool
Whirlpool
Whirlpool
Test
NESSIELength
NESSIEOneBit
NESSIEHundredMillion
Résultat
OK
OK
OK
Conformité de l’implémentation de RIPEMD-160
Les tests sur RIPEMD-160 ont été effectués à partir des séquences disponibles ici :
http://homes.esat.kuleuven.be/~bosselae/ripemd160.html
Seules 9 séquences sont disponibles. Les résultats sont tous positifs.
Algorithme
RIPEMD-160
Test
RIPEMDTestVectors
Résultat
OK
Conformité de l’implémentation de PBKDF2
La fonction de dérivation de clés PBKDF2 a été testée à partir des séquences étalons disponibles dans la
RFC 3962 (« Advanced Encryption Standard (AES) Encryption for Kerberos 5 »). La fonction sous-jacente
utilisée est un HMAC-SHA1.
Peu de séquences étalons utilisant d’autres fonctions de hachage sont disponibles. La mise en œuvre
de PBKDF2 avec les fonctions de hachage utilisées par TrueCrypt 6 a été vérifiée par revue du code
source. Les différences trouvées portent uniquement sur l’appel de fonctions de hachage différentes
pour chaque HMAC.
La graine, le mot de passe et leurs longueurs, ainsi que le nombre d’itérations sont variables dans les
différentes séquences.
Les résultats obtenus sont positifs.
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 19 / 26
Évaluation CSPN
Algorithme
PBKDF2
Test
PBKDF2-HMAC-SHA1TestVectors
Résultat
OK
Conformité de l’implémentation du mode XTS
La mise en œuvre du mode XTS a été vérifiée à partir des séquences étalon spécifiées dans IIIE 1619(1).
N’ayant pas accès à la version complète de ce document, les vecteurs ont été récupérés depuis les
sources d’OpenBSD à l’adresse :
http://www.openbsd.org/cgi-bin/cvsweb/src/regress/sys/crypto/aesxts/
Les séquences disponibles utilisent AES comme fonction de chiffrement, avec des clés de 128 ou 256
bits. Les tests ont porté sur les 5 séquences avec des clés de 256 bits. TrueCrypt utilise les mêmes
séquences lors de son lancement pour vérifier la conformité de la mise en œuvre. Des tests
indépendants ont toutefois été réécrits.
Les résultats obtenus sont positifs.
Algorithme
Test
Résultat
XTS-AES
XTS-AES256TestVectors
OK
Les mêmes fonctions sont utilisées l’utilisation du mode XTS avec les autres fonctions de chiffrement
disponibles. Nous considérons donc que la mise en œuvre de ce mode est correcte.
2. Conformité par revue de code source
Effacement des données sensibles
L’effacement des données sensibles se fait toujours en appelant la fonction burn, définie dans le
fichier Tcdefs.h. Cette macro-fonction est définie comme suit :
1. #define burn(mem, size)
2. do {
3.
volatile char *burnm = (volatile char *) (mem);
4.
int burnc = size;
5.
RtlSecureZeroMemory (mem, size);
6.
while (burnc--) *burnm++ = 0;
7. } while (0)
Deux procédures d’effacement sont donc appelées : la seconde remet tous les octets de la mémoire à
zéro. La première, définie dans WinNT.h, fait exactement la même chose : elle n’a pas d’utilité réelle
si le programme est compilé avec Visual Studio 2008.
Contexte des algorithmes de chiffrement
Les fonctions de chiffrement sont toujours utilisées à l’aide d’un wrapper sur les fonctions de bas
niveau. En particulier, un contexte de chiffrement est manipulé par 3 fonctions : crypto_open,
crypto_loadkey et crypto_close.
crypto_open alloue une structure de type KEY_INFO, contenant entre autres des clés de
chiffrement et les contextes de chiffrement associés. Elle est initialisée à 0 et verrouillée en mémoire à
l’aide de VirtualLock si elle est appelée en mode utilisateur.
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 20 / 26
Évaluation CSPN
crypto_close détruit les données du contexte en appelant la fonction burn, puis déverrouille la
structure avec VirtualUnlock. Enfin, la mémoire précédemment allouée est libérée.
Il y a donc un mécanisme de sécurité empêchant la copie des clés sur le disque. Les contextes de
chiffrement, et donc les variables intermédiaires utilisées par les fonctions de chiffrement, sont
correctement effacés si la fonction crypto_close est appelée quand les clés de chiffrement ne sont
plus nécessaires. Une revue du code source semble montrer que cette fonction est toujours appelée.
Algorithme de dérivation de clé PBKDF2
La fonction de dérivation de clé PBKDF2 présente un problème de mise en œuvre : les fonctions
derive_u_whirlpool, derive_u_sha512 et derive_u_ripemd160 ne convertissent pas
correctement l’index de bloc en notation big endian. Seul l’octet de poids faible est pris en compte, les
trois autres étant considérés nuls.
Le mécanisme mis en œuvre présente alors des cycles de longueur 256 fois la taille des condensats
générés :
• 5120 octets pour RIPEMD-160 ;
• 16384 pour SHA-512 et Whirlpool.
Ce problème n’a aucun impact sur la sécurité du produit : les appels à cette demandent au maximum
des données de 1536 octets (soient 6 clés de 256 bits).
Enfin, toutes les variables intermédiaires sensibles sont correctement effacées, quelle que soit la
fonction de hachage utilisée.
La fonction de dérivation de clé PBKDF2 telle que mise en œuvre dans TrueCrypt n’est pas de niveau
standard. Le problème de mise en œuvre identifié, déjà présent dans la version 4.2, ne crée toutefois,
tel qu’il est utilisé, aucun affaiblissement de nature cryptographique.
3. Conformité du générateur d’aléa
Le générateur d’aléa est le même que celui mis en œuvre dans la version 4.2, à ceci près que le tableau
d’aléa utilisé est deux fois plus grand. Les conclusions sont donc les mêmes que celles de la version 4.2.
La règle suivante n’est pas respectée :
• RègleSArchiGDA-2 : Un générateur physique d’aléa ou des éléments secrets combinés avec une
mémoire non volatile doivent être employés.
Le générateur est formé d’un état perturbé par des éléments extérieurs ne constituant pas une
véritable source physique d’aléa, retraités par une fonction de hachage cryptographique de niveau
standard. Cette composition n’est pas reconnue de niveau standard pour la génération d’aléa selon le
référentiel de la DCSSI.
4. Conformité des fonctions de calcul d’intégrité
L’intégrité de l’en-tête de volume déchiffré est assurée par deux CRC-32 et une chaine de 4 octets. Le
CRC-32 n’est pas un mécanisme cryptographique, tout comme la comparaison d’une partie de l’en-tête
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 21 / 26
Évaluation CSPN
avec 4 octets fixés.
Ces informations, en particulier la valeur « TRUE », donnent des informations sur les données présentes
dans l’en-tête. Toutefois, l’en-tête est chiffré avec les mêmes algorithmes que ceux utilisés pour le
chiffrement du volume. Une attaque à texte clair partiellement connu ne paraît pas envisageable.
Le mécanisme de vérification de l’intégrité des données n’est pas de niveau standard. Il faut
cependant noter qu’il est principalement utilisé pour authentifier l’utilisateur plus que pour vérifier
l’intégrité des données de l’en-tête.
3. Robustesse des mécanismes cryptographiques
1. Robustesse des algorithmes de chiffrement symétrique
Twofish
Twofish est une fonction de chiffrement par blocs, utilisant des blocs de 128 bits. TrueCrypt utilise
Twofish avec des clés de 256 bits.
Aucune attaque n’a été publiée sur Twofish depuis l’évaluation de la version 4.2 de TrueCrypt.
L’algorithme Twofish est un algorithme de chiffrement par bloc de niveau standard.
AES
TrueCrypt utilise AES avec des clés de 256 bits.
L’AES, tel qu’il est spécifié dans le FIPS-197, est un mécanisme de chiffrement par blocs de niveau
standard (5).
Serpent
Serpent est un algorithme de chiffrement par blocs utilisant des blocs de 128 bits. TrueCrypt utilise
Serpent avec des clés de 256 bits.
Il n’existe actuellement pour la version non réduite de Serpent aucune attaque théorique plus efficace
qu’une recherche exhaustive.
La meilleure attaque contre Serpent est une attaque par cryptanalyse différentielle linéaire. Elle
attaque 11 tours (Serpent possède 32 tours) avec une complexité en temps de 2139,2 et 2125,3 textes
clairs choisis (6). Cette attaque est donc totalement théorique.
L’algorithme Serpent est un algorithme de chiffrement par bloc de niveau standard.
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 22 / 26
Évaluation CSPN
Mode opératoire XTS pour le chiffrement par blocs
Le mode opératoire LRW était utilisé dans la version 4.2 de TrueCrypt. Des problèmes de sécurité sont
apparus sur ce mode (7). C’est pourquoi le mode XTS est maintenant utilisé. Il s’agit d’une variante du
mode XEX, justement utilisé pour pallier les problèmes rencontrés avec le mode LRW. Le mode XTS
introduit l’utilisation d’une clé secondaire, appelée « clé de torsion », et permet le vol de texte chiffré
(« Ciphertext stealing »). Le mode XTS utilisé avec AES a été standardisé par l’IEEE P1619 (Standard for
Cryptographic Protection of Data on Block-Oriented Storage Device)(8).
Le mode XTS est en cours de standardisation par le NIST, en tant que mode opératoire pour l’AES. Le
NIST a lancé un appel à commentaires, qui s’est terminé le 3 septembre 2008. Les commentaires ont
été publiés sur le site du NIST le 12 septembre 2008 (9). Les critiques portent essentiellement sur
l’utilisation d’une clé secondaire pour le mode XTS : la taille des clés est doublée. Certains jugeant
l’utilisation du mode XEX, qui n’utilise qu’une seule clé, plus pertinente. TrueCrypt n’utilise pas le vol de
texte chiffré : le mode XEX aurait également pu être utilisé. Aucun problème de sécurité n’a été relevé
dans les commentaires. Un commentaire apporte une preuve de sécurité du mode XTS (10).
La DCSSI recommande (5) l’emploi d’un mode opératoire de chiffrement non déterministe, ce qui est le
cas du mode XTS. À ce jour, aucune attaque n’est publiée sur ce mode. Des critiques ont été faites
quant à l’abandon du mode LRW pour IEEE P1619 : elles insistaient sur le fait que ce mode était soumis
à études depuis des années, ce qui n’était pas le cas des autres modes proposés, comme XTS.
Une attention particulière a été portée sur les conséquences de l’écriture d’une des clés de chiffrement
sur le disque, un problème de ce type ayant entrainé l’abandon du mode LRW par l’IEEE 1619. Nous
n’avons trouvé aucune attaque de ce type avec le mode XTS.
La règle et la recommandation suivantes sont respectées :
• RègleSModeChiff-1 : Au sein du modèle de sécurité correspondant à l’usage du mode de
chiffrement, il ne doit exister aucune attaque de complexité inférieure à2+ , où est la taille en
bits du bloc.
• RecomSModeChiff-1 : L’emploi d’un mode opératoire de chiffrement non déterministe est
recommandé.
L’algorithme XTS utilisé avec AES, Serpent ou Twofish est un mécanisme de chiffrement symétrique de
niveau standard.
2. Procédures de validation des éléments secrets
Il n’est plus possible de créer des volumes chiffrés avec le mode LRW. La fonction
DetectWeakSecondaryKey, testant la faiblesse des clés secondaires pour ce mode, a donc été
supprimée. Son utilisation n’était pas fondée d’un point de vue cryptographique (9).
TrueCrypt ne vérifie pas si une clé faible est utilisée pour le mode XTS. Les développeurs considèrent
que la probabilité d’utiliser une clé faible est nulle :
/* Note: XTS mode could potentially
all blocks in one data unit on the
(i.e. 512 bytes of the volume would
create a TrueCrypt volume with such
 SOGETI I.S.
be initialized with a weak key causing
volume to be tweaked with zero tweaks
be encrypted in ECB mode). However, to
a weak key, each human being on Earth
Réf : K08-JBB-CR-672-2008
Page 23 / 26
Évaluation CSPN
would have to create approximately 11,378,125,361,078,862 (about eleven
quadrillion) TrueCrypt volumes (provided that the size of each of the
volumes is 1024 terabytes). */
Le chiffrement effectué par la clé secondaire (clé de « torsion ») peut donner produire une valeur de
« torsion » nulle pour une unité de données :
On note _ .
Si = 0 pour une unité de donnée d’indice donnée, alors _ 0 pour chaque bloc d’indice cette unité de donnée.
Tout bloc de cette unité de donnée sera alors chiffré en mode ECB :
La sécurité à l’intérieur de cette unité de donnée sera celle du mode opératoire ECB. La probabilité
d’utiliser une telle clé faible sur une unité de données fixée est d’environ 1/2 . Cette probabilité est
négligeable et le risque introduit est en accord avec les recommandations de la DCSSI.
3. Traitement du mot de passe utilisateur
Description générale
Un volume peut être monté avec un mot de passe et/ou des fichiers clés. Le mot de passe est stocké
dans une structure Password contenant sa longueur, d’au plus 64 caractères, et sa valeur. Des
opérations sur les fichiers clés sont effectuées afin d’obtenir également une structure Password pour
l’ensemble des fichiers clés.
Enfin, les deux structures obtenues sont fusionnées, avec une addition octet par octet modulo 2 .
Le mot de passe n’est pas modifié, et les clés de chiffrement sont directement dérivées de sa valeur.
Les opérations effectuées sur les fichiers clés sont détaillées dans la partie suivante.
Manipulation des fichiers clés
Les données des fichiers clés sont traitées afin d’obtenir un « mot de passe aléatoire » pour le volume,
d’une taille fixe de 64 octets. On peut donc la considérer comme une fonction de hachage. L’algorithme
de traitement KeyFileProcess pour chaque fichier clé est le suivant :
Algorithme : KeyFileProcess
Entrée : un tableau # #@ , # , … , #M de longueur H octets, contenu du fichier clé, un tableau d’aléa
@ , , … , J` de 64 octets
Sortie : le tableau d’aléa modifié
1. RbR 0
2. Q 0
3. Pour 1 ; ; H Faire :
a. RbR cdef32#D , RbR
b. S S RbR h 24 &'# 2
c. SU SU RbR h 16 &'# 2
d. SU SU RbR h 8 &'# 2
e. SUK SUK RbR &'# 2
f. Q Q 3&'# 64
4. Retourner  SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 24 / 26
Évaluation CSPN
UPDC32 est la fonction de mise à jour de CRC-32. Elle prend en paramètre un octet à traiter, et le haché
courant. Elle retourne la nouvelle valeur du haché.
est utilisé pour l’ensemble des fichiers clés. Sa valeur est mise à jour chaque fois qu’un nouveau
fichier clé est traité.
Il est trivial de trouver des collisions dans cette fonction.
Exemple : Prenons une chaine de 13 caractères, contenant les données « TrueCrypt 6.0 ». Le CRC
de ces données est 0x9392B2F1. Lors de l’appel de la fonction KeyFileProcess, 52 octets vont
être écrits dans .
Ajoutons maintenant 4 autres caractères à cette chaine, formés de façon à ce que le CRC-32 de la
chaine complète soit nul. Pour cela, on rajoute les octets 0xF1, 0xB2, 0x92 et 0x93.
Après l’ajout du 16e octet, Q va valoir 0. Le 17e et dernier octet sera donc écrit au début de . Le haché
ayant une valeur nulle, les valeurs de ne seront pas modifiées.
On crée un fichier conteneur de test, protégé par un fichier clé contenant les données « TrueCrypt
6.0\xF1\xB2\x92\x93 ».
Le volume peut alors être monté avec le fichier clé suivant : « TrueCrypt 6.0\xF1\xB2\x92 ».
Il est possible de monter un volume TrueCrypt avec plusieurs fichiers clés différents.
Le mécanisme utilisé pour traiter les fichiers clés n’atteint pas le niveau standard.
4. Mécanisme de dérivation de clé PBKDF2
Le mécanisme de dérivation de clé est le même que celui de la version 4.2.
Dans la version 4.2, il était possible d’entrer des mots de passe de plus de 64 caractères ; seuls les 64
premiers caractères étaient alors utilisés. Ce n’est plus possible dans cette version.
Lorsqu’un mot de passe court est entré, un message d’avertissement est affiché, préconisant d’utiliser
des mots de passe d’au moins 20 caractères. Dans la version 4.2, ce message s’affichait si le mot de
passe entré par l’utilisateur faisait moins de 12 caractères. La version 6 n’affiche ce message que si le
mot de passe fait moins de 20 caractères.
Le nombre d’itérations pour PBKDF2 n’est plus 2000 pour chaque fonction de hachage : 1000 itérations
sont utilisées pour SHA-512 et Whirlpool, en raison de la lenteur de ces algorithmes par rapport aux
précédents algorithmes utilisés (RIPEMD-160 et SHA-1). Ceci ne pose toutefois pas de problème de
sécurité, et suit la recommandation de PKCS#5 d’utiliser au moins 1000 itérations.
Aucune attaque n’a été publiée sur PBKDF2 depuis la version 4.2 de TrueCrypt.
Le mécanisme de dérivation des clés PBKDF2, utilisé comme spécifié dans PKCS#5, est un mécanisme
cryptographique de niveau standard.
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 25 / 26
Évaluation CSPN
4. Bibliographie
1. IEEE. IEEE Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices. 2008.
978-0-7381-5363-6.
2. Gutmann, Peter. Software Generation of Practically Strong Random Numbers. 1998.
3. Ellison, Carl. Cryptographic Random Numbers. Carl Ellison's home page. [Online] Novembre 11, 1995.
http://world.std.com/~cme/P1363/ranno.html.
4. NIST. The Secure Hash Algorithm Validation System (SHAVS). 2004.
5. DCSSI. Règles et recommandations concernant le choix et le dimensionnement des mécanismes
cryptographiques de niveau de robustesse standard. 2006.
6. Eli Biham, Orr Dunkelman, Nathan Keller. Differential-Linear Cryptanalysis of Serpent. Lecture notes
in computer science. 2003.
7. Hars, Laszlo. P1619: how serious is the leak of K2? IEEE Standards Working Group Areas. [Online] Juin
2, 2006. http://grouper.ieee.org/groups/1619/email/msg00962.html.
8. IEEE 1619. The XTS-AES Tweakable Block Cipher. 2008.
9. NIST. Comments on the proposal to approve XTS-AES. NIST.gov. [Online] Septembre 12, 2008.
http://csrc.nist.gov/groups/ST/toolkit/BCM/comments.html.
10. Moses Liskov, Kazuhiko Minematsu. Comments on XTS-AES. 2008.
11. DCSSI. Cotation cryptographique des mécanismes cryptographiques du projet TRUECRYPT. Paris :
s.n., 2008.
12. Jonathan Brossard, Iviz Technosolutions Pvt. Ltd. Bypassing pre-boot authentication passwords by
instrumenting the BIOS keyboard buffer (practical low level attacks against x86 pre-boot authentication
softwares). Calcutta : s.n., 2008.
13. ntldr. Critical vulnerabilities in TrueCrypt 5.1. openPGP in Russia. [Online] Mars 11, 2008.
http://www.pgpru.com/novosti/2008/kriticheskajaujazvimostjvtruecrypt51.
14. Alexei Czeskis, David J. St. Hilaire, Karl Koscher, Steven D. Gribble, Tadayoshi Kohno, Bruce
Schneier. Defeating Encrypted and Deniable File Systems: TrueCrypt v5.1a and the Case of the Tattling
OS and Applications. s.l. : 3rd Usenix Workshop on Hot Topics in Secuirty, 2008.
FIN DU DOCUMENT
 SOGETI I.S.
Réf : K08-JBB-CR-672-2008
Page 26 / 26

Spécifications cryptographiques - TrueCrypt v6.0a

Transcription

Documents pareils

Forum: Dépannage

Modalités de fourniture des supports chiffrés contenant les

Fiche TrueCrypt en PDF

Installation des E-boards DGT

Cours 2: Cryptographie - Ensiwiki

Diapositive 1 - heurtebise.free.fr

Comment savoir quelle version de windows 7 est installée sur mon

Chiffrement matériel ordinateurs DELL