Re: Truecrypt et table de caractères

Sylvain a écrit :
> 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...