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. )
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. )
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. )
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. )
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. )
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. )
Sylvain.
Sylvain.
Sylvain.
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
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.
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
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.
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
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.
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. )
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. )
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 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"
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é)
- 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"
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é)
- 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"
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é)
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?
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.
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
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...
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
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
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.
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...
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 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?
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.
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
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...
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
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
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.
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...
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 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?
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.
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
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...
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
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
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.
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...
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.
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
qu'entends-tu par "clé biométrique" ?
ah oui... je mélange ... ici clé usb à capteur biométrique.
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
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.
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.
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
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?
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...
comme quand on écoutait les écrans vidéo à distance
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
qu'entends-tu par "clé biométrique" ?
ah oui... je mélange ... ici clé usb à capteur biométrique.
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
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.
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.
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
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?
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...
comme quand on écoutait les écrans vidéo à distance
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
qu'entends-tu par "clé biométrique" ?
ah oui... je mélange ... ici clé usb à capteur biométrique.
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
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.
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.
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
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?
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...
comme quand on écoutait les écrans vidéo à distance
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
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
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
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é ?
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
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
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
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
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é ?
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
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
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
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
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é ?
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
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.
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...
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...
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"?)??
8) (ma jeunesse, quand le PC AT était moderne)
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.
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...
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...
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"?)??
8) (ma jeunesse, quand le PC AT était moderne)
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.
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...
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...
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"?)??
8) (ma jeunesse, quand le PC AT était moderne)