Re: Truecrypt et table de caractères

Al wrote on 09/03/2008 11:45:
> 
>> - utiliser des keyfiles [1] qui sont mixés via un calcul de CRC avec
>>   le passphrase (s'il existe).
>> [1] un keyfile peut apporter facilement de l'entropie mais peut souffir
>>  + d'un manque de confidentialité (s'il est visible sur le disque
>>    contenant le container ou la partition chiffré),
>>  + d'un manque de protection physique, si c'est un fichier facilement
>>    effacable
> 
> ca ressemble à un "salt"

oui et non. pas au sens PBE ou PKCS#12, ici les keyfiles participent
à la construction du mot de passe de protection, pas à la clé de
chifrement; toutefois - sauf erreur ou oubli - ce passphrase est
utilisé comme clé pour recouvrer la clé du volume, c'est quasi PBE.

>> autre solution le stocker sur carte à puce qui garantira la sécurité
>> physique (pas d'effacement par mégarde) et logique (protection de la
>> lecture du fichier par PIN/passphrase qui pourra ici être court car
>> associé à un compteur d'essai limité) - j'ai fini il y a peu un tel
>> add-on pour TrueCrypt, j'en reparlerai peut être ici sous peu.
> 
> ca c'est une bonne idée, du multi-facteur.
> associé un "je sais" a un "je possède".
> 
> ajoute une clé biométrique pour le "je suis" et tu as un truc assez solide.

qu'entends-tu par "clé biométrique" ?

un crédential biométrique (à utiliser à la place d'un PIN carte)
pourrait être utilisé ici pour autoriser la lecture du keyfile
stocké dans cette carte en effet, mais pas les données biométriques
elles-mêmes.

lors d'une vérification biométrique - et pour parler d'une empreinte -
les minuties extraites lors d'une capture d'empreintes ne sont jamais
les mêmes, interviennent des rotations (positionnement du doigt), des
dilatations (pression du doigt), des ajouts et manques (des minuties
de référence sont obstruées et n'apparaissent pas, d'autres inconnues
à l'enrolement peuvent être présente).

toutes ces différences sont prises en compte par un algo de matching
bio - et sa qualité vient notamment de cette prise en compte.

ici on a besoin d'un pattern strictement constant (au bit près).

> en plus c'est très bien d'associer des mots de passe à nombre de 
> tentatives fini.

c'est le principe d'une carte à micro-controleur.

> le défaut des trucs chiffrés c'est que tu peux tenter un nombreinfini de 
> fois.

le container chiffré par TrueCrypt est toujours présent sur le disque;
si ce container est dérobé, l'attaque en force brute est toujours
possible, la carte n'ajoute ici qu'un passphrase à très forte entropie
garantissant un temps quasi infini pour cette attaque (toute chose
vulnérable par ailleurs).

> si tu as un dispositif qui s'efface après quelques tentatives, l'attaque 
> massive est impossible. il faut toucher dans le mille.

s'efface ou se bloque.

on pourrait aujourd'hui stocker un container sur carte à puce, mais
dans la limite de 128 ou 256 ko; TrueCrypt est utilisé pour des
volumes bcp plus grand; des clés USB de plusiers Go existent mais
aucune n'intégre un contrôleur apportant les sécurités d'une carte
à puce; tout reste affaire de compromis.

> mais réflexion hors sujet
> tu es à la merci d'une faiblesse du hardware.

du disque contenant le container chiffré ?
un disque reste un élément risqué s'il n'est jamais sauvegardé
ni monté en RAID avec redondance - que les données sont chiffrés
ou non.

concernant la faiblesse de la carte à puce, le(s) keyfile(s)
peuvent (doivent) être sauvegardé / dupliqués par l'utilisateur.

> la faiblesse du truecrypt et de tous les systèmes de chiffrement de 
> disque par ordinateur sans dispositif crypto externe, c'est que l'on 
> sait facilement lire la DRAM 30 minutes après l'arrêt de l'ordinateur 
> (si on refroidit la DRAM, ou quelque minutes à température ambiante).

c'est de l'humour là, non ?
j'ai suivi ce thread, les affirmations les plus fantaisistes y
étaient nombreuses.

un bon logiciel de crypto efface (remet à zéro) toute mémoire
ayant contenu une clé ou un passphrase dès que celui-ci n'est
plus nécessaire - pour TrueCrypt les passphrases sont effacés
dès que les clés de volume sont calculés, ces clés sont
effacés lorsque le volume est démonté.

l'attaque à la bombe cryogénique a juste oublié ce détail.


> le seul truc qui marche c'est le dispositif de chiffrement à clé 100% 
> protégé (carte a puce typiquement, ou équivalent usb). or puisqu'on ne 
> peut plus faire confiance à la DRAM ca veut dire que le dispositif doit 
> TOUT chiffrer en temps réel.

on pourrait l'imaginer, pour des débits non critiques (inf. à 614400bps,
ou à 848000 bps en RF). reste que si tu n'as pas du tout confiance en la
[D]RAM, continuer à y recevoir les données déchiffrées n'est pas
raisonnable !...

> contrairement aux réseaux on ne peut se contenter d'un chiffrement par 
> clé de session.

les clés éphémères peuvent - et sont - utilisées y compris pour des
applications locales, elles prémunisent du risque d'accès à ces clés
sous réserve que le dispositif chiffrant ne permette pas le rejeu
(c'est souvent le cas, sinon la dérivation des clés ne servirait
à rien).

> une alternative que je verrais ce serait la compartimentation des clés, 
> c'est a dire de chiffrer chaque fichier, chaque dossier, par une clé 
> distincte que l'on déchiffrerait avec la clé maitresse stockées dans un 
> dispositif hardware (carte a puce, dongle usb).

j'ai fait un truc comme cela aussi, ça peut apporter une meilleure
sécurité mais, à ne fournir que cela c'est un truc inutilisable
car non intégré - devoir recourir à un soft dédiée pour lire /
réécrire ses fichiers (un truc à la RH) serait inacceptable en
perte d'efficacité.

il faudra donc réécrire un driver disk opérant en liaison avec
la carte à puce, c'est possible mais bcp plus de travail que ma
proposition initiale de renforcement de la passphrase - il serait
possible de patcher la gestion des clés de TrueCrypt mais ces
modifications très profondes changerait alors complètement la
confiance que l'on peut avoir en TrueCrypt tel qu'on le connait.

> ainsi à tout instant on aurait en mémoire que la clé des fichiers 
> ouverts, qui sont probablement de toute façon déjà dans les caches 
> mémoire de l'OS.

ou encore moins si on sauvegarde le nouveau chiffré par une clé symm.
aléatoire générée à chaque sauvegarde et wrappée par la clé publique
de la carte (lue une seule fois et présente sans crainte en RAM).

notez que toute relecture devra recourir à la carte pour recouvrer
cette cle de fichier, or cette opération devra imposer la vérification
du PIN carte pour chaque opération - si la carte se contente d'une
seule vérification par session de travail, un soft pirate pourra
s'intercaler et demander des déchiffrements de clés illégaux.
cela rends également l'usage non convivial pour un usage courant.

> une autre idée ce serait une mémoire type SRAM, rapide, mais qui 
> s'efface vraiment instantanément, et que l'on ai pas à recopier en DRAM.

relativisez ce probléme de rémanance / persistance des données.

> outre le hard ca demanderais une programmation qui véite de recopier des 
> dérivé de la clé hors de la SRAM (genre les différentes BOX des algo 
> dérivées de la clé)

une clé doit bien être utilisée en RAM, ses sbox doievnt bien être
calculés en RAM, de nombreux cas existeront toujours où tout cela
ne peut pas tenir en cache CPU tout en une seule fois.

le problème n'est pas (que) là. si vous avez des raisons de ne
pas faire confiance à la machine que vous utilisez (parce qu'elle
contiendrait mille key-loggers, RAM-loggers, TCP-sniffers, etc)
ne l'utilisez pas.

Sylvain.