Truecrypt et table de caractères

Le
Gump
Bonjour,

j'utilise Truecrypt, et mon mot de passe ( passphrase ) utilise la table ASCII,
soit les 128 premiers caractères de l'Unicode ( sur 7 bits, donc ) pour chiffrer
des fichiers-containers.
Si je voulais "durcir" ce mot de passe en utilisant la table ASCII étendue ( 256
caractères, 8 bits ) est-ce que je pourrais avoir des ennuis pour ouvrir mes
fichiers-containers depuis un autre OS ? ( Linux, Vista, etc. )

Merci,
Gump
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
mpg
Le #1380567
Le (on) dimanche 09 mars 2008 01:12, Gump a écrit (wrote) :

j'utilise Truecrypt, et mon mot de passe ( passphrase ) utilise la table
ASCII, soit les 128 premiers caractères de l'Unicode ( sur 7 bits, donc )
pour chiffrer des fichiers-containers.
Si je voulais "durcir" ce mot de passe en utilisant la table ASCII étendue
( 256 caractères, 8 bits ) est-ce que je pourrais avoir des ennuis pour
ouvrir mes fichiers-containers depuis un autre OS ? ( Linux, Vista, etc. )



Je ne sais pas répondre à la question initiale, mais j'ai envie de répondre
par une autre question : pourquoi ne pas plutôt durcir le mot de passe en
l'allongeant ? En admettant (ce qui est sans doute faux) que tu passes de 7
à 8 bits d'entropie par caractère, sur un mot de passe de 10 caractères, tu
gagnes 10 bits d'entropie : tu en gagnes 14 en passant à 12 caractères.

Sans compter qu'en plus des problèmes d'encodages, il faut aussi savoir
saisir les trucs au clavier : il m'est arrivé de ne pas pouvoir lire mes
mails parce que je ne savais pas taper mon mot de passe sur un clavier de
Mac.

Au passage, j'ai constaté un truc bizarre il n'y a pas longtemps en ouvrant
la liste des mots de passe stockés par FF (tous sans importance, les vrais
je les mémorise et les tape à chaque fois, on est d'accord) : un mot de
passe que je croyais commencer par une (AltGr_ chez moi) commençait par _
d'après FF. Ça fait réfléchir, aussi.

Manuel.

Sylvain
Le #1380566
Gump wrote on 09/03/2008 01:12:
Bonjour,

j'utilise Truecrypt, et mon mot de passe ( passphrase ) utilise la table ASCII,
soit les 128 premiers caractères de l'Unicode ( sur 7 bits, donc ) pour chiffrer
des fichiers-containers.
Si je voulais "durcir" ce mot de passe en utilisant la table ASCII étendue ( 256
caractères, 8 bits ) est-ce que je pourrais avoir des ennuis pour ouvrir mes
fichiers-containers depuis un autre OS ? ( Linux, Vista, etc. )


utiliser des caractères pouvant avoir des codes différents selon la page
en cours (donc l'OS, sa localisation, ...) est risqué en effet.

les moyens plus surs sont:
- allonger son passphrase,
- 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

on voudra, à tout le moins, stocker son keyfile sur une clé USB.
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.

Sylvain.

+-- SenoN --+
Le #1393833
j'ai fini il y a peu un tel add-on pour TrueCrypt, j'en reparlerai peut
être ici sous peu.

Sylvain.


En effet cela nous intressera ; je suis impatient de voir.

--
+-- SenoN --+
http://senon.free.fr/


Si l’on n’est plus que mille, eh bien, j’en suis ! Si même
Ils ne sont plus que cent, je brave encor Sylla ;
S’il en demeure dix, je serai le dixième ;
Et s’il n’en reste qu’un, je serai celui-là !

Al
Le #1394342
Gump wrote on 09/03/2008 01:12:

- 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"
un intérêt que je vois du keyfile c'est que ca permet d'éviter qu'un
attaquant ne se constitue une fois pour toute une table des clés
associées à un mot de passe donné. des sortes de rainbow-table.
ce genre d'attaque est super effeicace. tu passe 2 ans (ou tu la remplie
en continue) à remplir une table des clés obtenues a partir d'un mot de
passe, et à chaque tentative de déchiffrement tu tente de déchiffrer
avec les clés associées dans l'ordre du plus probable au moins probable...
a note que les mots de passe aléatoires seront alors stockés après les
mots "manuels", mais par ordre de taille... on testera les 8 caractères
avant les 9...

le pire c'est que si tu connais un clair probable (cas utile avec le
header ou si le chiffrement c'est pas en chainage de bloc), tu peux même
faire une attaque de dictionnaire sur le chiffré.

pour chaque clé stockée, associée a un mot de passe probable, to poura
calculer le chiffré de quelques clair probables.

ensuite si tu retrouve un bloc chiffré correspondant, tu peux alors
remonter à la clé et donc au mot de passe.

avec un "salt" ou un keyfile, il faut que tu te refasse une clé à chaque
fois d'après chaque mot de passe. plus long. et il faut que tu te
refasse alors aussi la table des chiffrés de clairs probables.




on voudra, à tout le moins, stocker son keyfile sur une clé USB.
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.

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

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

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

mais réflexion hors sujet

tu es à la merci d'une faiblesse du hardware.


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).

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.

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

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).

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.

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.

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é)

Serge Paccalin
Le #1395932
Le dimanche 9 mars 2008 à 01:12:25, Gump a écrit dans
fr.misc.cryptologie :

j'utilise Truecrypt, et mon mot de passe ( passphrase ) utilise la table ASCII,
soit les 128 premiers caractères de l'Unicode ( sur 7 bits, donc ) pour chiffrer
des fichiers-containers.
Si je voulais "durcir" ce mot de passe en utilisant la table ASCII étendue ( 256
caractères, 8 bits ) est-ce que je pourrais avoir des ennuis pour ouvrir mes
fichiers-containers depuis un autre OS ? ( Linux, Vista, etc. )


Il me semble que TrueCrypt refuse les caractères accentués. J'ai eu le
problème avec la version 4.2, je crois, en voulant reprendre une phrase
pour un nouveau conteneur.

--
___________
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Il faut donc que les hommes commencent
-'(__) par n'être pas fanatiques pour mériter
_/___(_) la tolérance. -- Voltaire, 1763

Sylvain
Le #1465526
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.


Al
Le #1472906
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).
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.
je connais pas PBE?


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)

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


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" ?
ah oui... je mélange ... ici clé usb à capteur biométrique.

pas parfait (je me souvient du gars de la FNAC qui racontait quand un
client avait déverrouillé un portable à biométrie, par hazard) mais ca
demande de la chance ou du travail.

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




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).
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.

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



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.
non, va voir sur le blog de bruceschneier, qui cite une news...

assez logique quand on connais comment marche les dram.



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.
l'idée c'est de récupérer un système en fonction, verrouillé par

exemple. 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.

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 !...
oui mais c'est de la compartimentation. tu limite le risque a ce qui est

en cours de lecture, or typiquement si il y a "attaque physique" les
opérateurs ont des chances de ne plus travailler...

ca limite la casse.


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



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


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
pour l'attaque à la DRAM, ca ne résoud pas le problème.


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...
c'est une attaque contre volume monté, mais assez imparable.

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.
bien vu...


il faudrait alors bien choisir ce que l'on chiffre. mais c'est vrai que
les fichiers importants sont rares, mais il est vrai que si on oublis un
fichier secondaire (backup, temp...) on peut tout faire fuiter...

la sécu c'est pas un truc d'amateur.

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.



a voir ce que ca devient, si ca s'eteint comme beaucoup de news, ou si
ca commence à se populariser


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.


oui, comme d'habitue...
et la secrétaire, et la femme,...

déjà la DRAM ca rappelle qu'il ne fait pas oublier le substrat sur
lequel l'informatique fonctionne...

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


Sylvain.


la crypto ca rend modeste...



Sylvain
Le #1506390
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:
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.



Al
Le #1506388
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:
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)




Sylvain
Le #1506387
Al wrote on 11/03/2008 22:37:

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.


ici les données sont XORés [1] avant chiffrement, un dictionnaire
clair / chiffré n'set pas utilisable.
([1] il me semble en CTR)

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...


sans vouloir être "précis" sur les noms, certains fabriquants sont
moins fiables que d'autres - ici je ne sais pas de quel matériel
on parle, encore moins si la personne a déactivé un contrôle post
boot ou non.

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...


on peut penser la comparaison biométrique comme analogique
plutôt que numérique - c'est même quasiment de la géométrie.

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



le fait de calculer une clé symmétrique de session depuis une clé
symmétrique maître.
en parlant de "clé de session sur réseaux", tu évoquais j'imagine
de la crypto SSL ou des échanges serveurs-serveurs basés sur
Kerberos, ceux-là initie l'échange par de la crypto assymétrique
et utilise donc des randoms comme clés de session.
quand la crypto. asymm. n'est pas dispo, on doit reposer sur le
fait que les deux parties disposent d'une clé symm. commune et
on calcule les clés de session en chiffrant un aléa avec cette
clé maître (on la dérive) (d'autres schémas / nuances existent).

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


pour éviter que sa compromission ne casse tout le système, au
pire seul l'échange en cours est compromis.

8) (ma jeunesse, quand le PC AT était moderne)


il l'était... par rapport à ce XT pas foutu de savoir l'heure.

Sylvain.





Publicité
Poster une réponse
Anonyme