Re: Truecrypt et table de caractères

Sylvain a écrit :
> Al wrote on 11/03/2008 00:28:

>> 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.
une attaque (j'appelle ca abusivement rainbowtable) c'est que si on 
connais un clair fréquent dans les données (genre un entête, des zéros), 
on pourrait se faire un table de tout les chiffrement de ces clairs 
fréquents par des mots de passes fréquent.
on stoque ca pendant quelques années avec une batterie d'ordinateurs, et 
on se fait une belle base de donnée.
puis quand on scanne un disque chiffré on recherche un bloc connu dans 
la base. la on regarde si le mot de passe déchiffre bien tout.

mais ici ca ne marche pas car le mot de passe chiffre un truc aléatoire 
imprévisible (la clé maitresse)

mon point était que si ce mot depasse produisait  directement une clé, y 
ajouter de l'entropie, empéchait de se constituer ce fameuse table.



> 
> 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é.
la sécurité est très bonne si le keyfile est protégé... elle redevient 
attaquable intelligement au niveau du mot de passe sinon.

mais pas de table une fois pour toute. à chaque fois il faut tout retester.

> 
>>> 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.
le dispositif du portable chez fnac qu'un inconnu a déverrouillé doit 
pas être aussi solide... 10-6 c'est super bon...

mais ma réflexion était de savoir si on pouvait constituer une clé a 
partir de l'empreinte, et je crois que entre reconnaitre une empreinte 
parmis plusieurs, et générer une série de bits stables a partir de 
n'importe quelle empreinte.

rien que sur les minuties, ici par exemple l'idée , ce serait que deux 
empreinte ayant 60% de minuties en commun devraient avoir la même 
"signature" au bit près. cest pour ca que je pensait à des codes 
correcteurs d'erreur...

c'est comme la différence entre un diff entre fichier et un hash de 
fichier, avec des données analogiques(regardez le bordel qu'a été la 
signature XML ou il a fallut tout canoniser).

> 
> 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 ....
désolé...



>>> 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.
on en vois l'utilité

>>     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.
je suis d'accord, a commencer par demander.

>>>> 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.
je parlais des dérivations de clé ?

générer une clé et la faire chiffrer par la précédente (pour pas trop 
"l'user"?)??

> 
>> 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.
a voir si ca se banalise ou se dégonfle.

>> comme quand on écoutait les écrans vidéo à distance
> pourquoi "on" a arrété ??
moi oui. (on écoutait pas que ca d'ailleurs... histoire de convaincre 
les industriels de faire gaffe)
8) (ma jeunesse, quand le PC AT était moderne)