Re: Truecrypt et table de caractères

Al wrote on 11/03/2008 00:28:
> 
>> 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.
> je connais pas PBE?

"password-based encryption" définit notamment dans PKCS#8 et 12.

> donc, la clé de chiffrement n'est pas lié au mot de passe. elle doit 
> être aléatoire?. la clé doit être chiffrée par le mot de passe ? (sinon 
> elle serait en clair sur le disque)

la clé de chiffrement [1] est aléatoire.
ensuite, sous réserve que j'ai correctement lu la logique, cette clé
est wrappé par la passphrase utilisé comme clé.
lors de la présentation du passphrase, la clé de chiffrement est
récupéré et, j'imagine, un bloc de contrôle est traité pour vérifier
que la clé obtenue est correcte.

[1] il faudrait dire la clé maître de chiffrement ...
Cf les specs TrueCrypt pour plus de certitude, je n'ai que survolé
le code du driver disk qui implémente cette gestion.

> donc ici comme la clé n'a pas de redondance, on ne peut pas faire 
> d'attaque a clair connu (la clé c'est le clair ici)...
> donc le keyfile n'apporte rien de plus pour luter contre les rainbowtables

pas sur de comprendre votre point.

il y a basiquement une clé d'un coté, un mot de passe de l'autre.
soit on pète la clé - mais pas de chance ce sera spurement de l'AES
256 bits, un peu long à force-bruter; soit on pète le mot de passe.

avec un keyfile généré par le générateur (certifié FIPS) d'une carte
j'injecte 1024 bits d'entropie dans ce mot de passe, donc re-pas de
chance, il faudra aussi pas mal d'eesai pour le casser.

pas plus, pas moins, juste augmenter la sécurité du passphrase pour
qu'elle ne soit pas ridicule devant celle de la clé.

>> qu'entends-tu par "clé biométrique" ?
> ah oui... je mélange ... ici clé usb à capteur biométrique.

à part 2 ou 3 modèles sur le marché, aucune clé n'intègre de puce
si les empreintes (de références) sont stockées dans un clé ordi-
naire c'est une erreur.

>> 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).
> effectivement les données biométriques sont trop imprécises et variables 
> pour constituer une clé stable. hum... peut être avec des codes 
> correcteurs d'erreur... sujet de recherche , mais vu que ca marche déjà 
> avec quelques % d'erreurs (faux positifs et faux rejets), j'y crois pas.

crois pas en quoi ??
les algos du marché supportent des rotations de + ou - 15° du doigt,
acceptent des écarts de +/- 30% sur le nombre de minuties (30% en plus
ou en moins entre la référence et le candidat) et peuvent tourner avec
des FAR, FRR de 10^-6.

des organismes comme le NIST font des campagnes rigoureuses de tests
des algos dispo - leurs résultats sont publiques en ligne, voir par
exemple: <http://fingerprint.nist.gov/minexII/>

> 1-2% d'erreur ca n'est que 6-7 bits d'entropie... mauvaise idée 
> effectivement. le verrouilage du dongle reste le mieux

d'un template biométrique à un autre, il y a au moins 80% d'écart!

>> c'est de l'humour là, non ?
>> j'ai suivi ce thread, les affirmations les plus fantaisistes y
>> étaient nombreuses.
> non, va voir sur le blog de bruceschneier, qui cite une news...
> assez logique quand on connais comment marche les dram.

j'ai bien dit "j'ai suivi le thread" - et bien lu les mecs qui
citent les mecs qui leur semblent qu'on leur a dit ....

>> l'attaque à la bombe cryogénique a juste oublié ce détail.
> l'idée c'est de récupérer un système en fonction, verrouillé par 
> exemple.

un bon soft de crypto annule tous les crédentails et bloque tous
les accès lorsqu'une station est vérrouillée.

> 	tu gèle sa DRAM, tu couple le jus brutalement, et tu remet les 
> chip DRAM dans un PC spécial  avec un bios qui ne teste pas la ram mais 
> la copie.

oui, oui, la fiction commencerait comme cela.
dans certains cas très particulier c'est vaguement applicable, mais
là où c'est possible il existera toujours mille façons mille fois
plus simple de voler les mêmes infos.

>>> 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).
> c'est quoi ca

clé éphémère = clé de session.

>> 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é.
> RH?

un canadien qui a inventé un clicodrome soit-disant chiffrant.
(il n'a pas compris que le chiffrement, la signature, ..., à
travers un mailer ou un file system, doivent être transparent
pour l'utilisateur).

>> 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.
> 
> très très profonde je suis d'accord, mais l'attaque a la dram est une 
> belle surprise...

ou un bel effet d'annonce, c'est à suivre.

> comme quand on écoutait les écrans vidéo à distance

pourquoi "on" a arrété ??

Sylvain.