Reprise du message précédent :

 
Ca met pas de bonne humeur ça !
Question, si j'ai mon systeme C encrypté avec TC et que je réecris le MBR avec des 0 et des 1 aléatoires, le disque sera quand meme détecté comme chiffré ?
 
Subsidiaire :
En quoi le volume caché est il utile dans ce cas ?
 
Reste a attendre la riposte des développeurs de TC

Les devs ont déjà répondus a ça, (j'en parle dans mon article), ils rappelent que rien ne permet de prouver, mais juste de suspecter car seulement le déchiffrement avec la clé est la preuve.
 
hiromi ce qu'il te faut, c'est faire de l'Hidden opperating system et donc du déni plausible au niveau OS et plus seulement des conteneurs. Je vais peut être faire un article sur le sujet tiens.
 
Pour répondre a ta question, si tu réécris ta MBR tu va tué ton amorce de boot et les secteurs chiffré avec truecrypt seront toujours détectable.

Mais non !
On peut le restaurer
 
MBRwizard permet de le faire, j'ai déjà fait des essais y a longtemps et ça a l'air d emarcher
http://mbrwizard.com/
Par contre je comprends pas comment il peut toujours détecter le reste en tant que données chiffrées alors qu'y a plus d'entete ?
 
Y a un gars qui a eu une idée sur le forum officiel de TC
 

 
http://forums.truecrypt.org/viewtopic.php?t=15942

j'ai aussi une question
dans le registre on trouve trace du mountage de trucs sous Truecrypt
 
HKLM\SYSTEME\Mounted diveces
 
est ce on peut suprimer les entrees qui concernent Trcrypt sans risque ?

 
Sans dec! Je n'avais pas compris le sens de ta question car on ne parlait pas de la même chose. Dans mon article je parlais de détection de conteneurs chiffré, toi tu parle de détection d'OS chiffré ce qui n'est pas la même chose.
Cela ne sert a rien d'écrire des données aléatoire dans la MBR si c'est pour après réécrire par dessus avec l'amorce de TC.
 
Pour la détection des fichiers crypté, tout ce joue dans les 512 premiers bytes de chaque volume. Car ce sont dans ces 512 bytes que ce sont stocké toutes les informations les plus importantes (salt, header master key, secondary header key, etc) nécessaire aux déchiffrement des secteurs. Rappel : La MBR fait 512 bytes
 
Les logiciels de détections ne détecte pas la présence de fichier TC au niveau de la MBR. Ce qui a été recherché a démontrer c'est la présence de conteneur chiffré. Car a partir de moment qu'un HDD a dans sa MBR l'amorce de TC cela montre 2 choses : soit les données aléatoire suivantes sont un OS chiffré, soit il y a eu un OS chiffré dans les données aléatoire suivante. Car mettre l'amorce de TC dans sa MBR ne sert qu'a charger une OS en validant la pré-authentification.  
Pas besoin de logiciel de détection pour savoir ça.

 
Oui tu peux. Il y a une a chaque fois que tu démonte un conteneur (de mémoire).  
C'est connus depuis 2004 http://www.truecrypt.org/docs/windows-registry

 
Bon c'est que je suis pas un crac, j'utilise TC en tant que utilisateur lambda  
J'ai effectivemetn enchainé sur l' OS chiffré, pour dire qu'une bonne securité anti-forensic consistait à réecrire le MBR - qui contient le bootloader de TC qui n'est pas chiffré quand à lui - puisqu'il est dans les 512 octets du mbr
Comme ça un soft d'investigation ne voit que des bits aleatoires sur tout le disque dur y compris l'emplacement physique où se situe normalement le MBR
Donc déjà par rapport à ça je comprends pas ta première phrase en bold
 
Après pour ce qui est d'un fichier TC ou alors d'un disque entier chiffré, je crois que je comprends que meme s'il n'y a aucun entete nulle part TChunt et FI-tools peuvent dire qu'il existe probablement des données chiffrées
C'est navrant d'ailleurs  

 
Afin de lancer ta partition chiffré il faut que l'amorce de TC dans la MBR reste en claire pour être appelé par le BIOS. Il suffit donc de lire la MBR pour le savoir que TC est dedans et donc que ce disque est chiffré ou a été chiffré. Pas besoin de logiciel de forensic pour ça, tu prend un editeur hexadecimal et tu as la réponse. A partir du moment ou tu fais de l'OS encryption tu ne peux pas nier qu'il n'y a pas d'os chiffré.
 
Ces logiciels de forensic fonctionnent dans le cas où tu nierais avoir des fichiers chiffré sur ton hdd. Ils permettent d'apporter une très fort doute sur des fichiers présent sur ton hdd.  
 

 
J'en doute, mais comme leurs codes source n'est pas publique c'est impossible à infirmer/affirmer.

Afin de lancer ta partition chiffré il faut que l'amorce de TC dans la MBR reste en claire pour être appelé par le BIOS
 
Pourquoi j'ai l'impression que tu réagis pas à ce que j'écris ?
 
Prends un disque système chiffré avec TC, son MBR est en clair et en l'editant on y constate la précense de TC - preuve que le disque est chiffré
Ensuite prends MBRwizard et fais un effacement securisé du MBR, après avoir fait une sauvegarde sur disquette biensur
Que dira le soft Forensic selon toi ?
Ensuite on te rend le disque et après toi tu restaure le MBR avec la disquette

 
Parce que cela n'a aucun sens, ihmo ?
 
Le FDE avec TC est fait pour protéger les données des accès extérieurs, pas pour masquer le fait qu'il y a des données chiffrées.
 
Exemple : Tu mets ton argent dans un coffre, cela permet de masquer ton argent mais pas le coffre.  
Pour un disque FDE c'est pareil, tu met ton OS dans un FDE, cela permet de la masqué l'OS mais pas le FDE.
 
Si tu veux masquer et chiffrer un OS, il faut faire de l'hidden Operating System (HOS)
 
Si je reprend mon exemple  : Je mets un peu d'argent dans mon coffre, puis tous les biens les plus précieux caché au fond du coffre derrière une porte secrète. je finis par donné mon accés au coffre et l'attaquant accède au coffre et pense avoir trouver ce qu'il chercher. Mais au final il n'a eu accès qu'a la partie visible. Ben le FDE HOS c'est pareil.
 

 
A la base le FDE c'est essentiellement fait pour protéger les DATA d'un vol de portable pour les entreprises.
Je vois mal le commercial supprimer et réinstaller son MBR à chaque fois qu'il veut se servir de son PC et je ne vois pas l'intérêt non plus. Ce qui intéresse le commercial c'est qu'un concurrent ne puisse pas accéder à ses data chiffrés, que le concurrent sache qu'il y a des data chiffré c'est pas bien grave vu qu'il ne pourra pas les lires. Quand bien même se serait grave qu'il sache qu'il y ai des data chiffré (torture pour avoir le mdp par exemple), il suffit de faire de l'hidden operating system.
Je ne comprend pas dans quel cas s'applique ton exemple.
 
EDIT : intéressant ce débat, ça me permet de comprendre plus de chose sur le FDE pour mon mémoire et le grand publique.

C'est quoi le sujet de ton mémoire ?

 
En gros : Du chiffrement de disque appliqué à de l'industrie. C'est juste un mémoire pas une thèse

Pour quel diplome ? (maitrise, master ?)

 
Master, ça existe plus les maîtrise, non ?.
 
Mais bon c'est HS toussa

Ben pour ceux qui ont commencés leurs études avant la mise en place du LMD (comme moi), la maitrise existe toujours
Et pour le HS je m'en fous, c'est mon topic
 
Bonne chance pour ton memoire en tout cas

Merci
 
Sinon je viens de tester Hidden Operating System (en Windows decoy/Windows hidden). C'est vraiment sympa pour au final pas beaucoup d'inconvénient.

Je pense artiflo que tu me prends de très haut
Ensuite tu parles de commerciaux je sais pas pourquoi...
TC est il conçu uniquement pour certains métiers ?? non bien sur
 
Pourquoi tu me dis pas simplement que meme si je réecris le MBR d'un disque syteme chiffré tes softs pourront quand meme soupçonner  la précense d'un coffre ?
 
Et en quoi le hidden OS est il plus securisé ?
Au lieu de me mener en bateau ce serait plus sympa d'expliquer ça à tout le monde au lieu de dire que ce que ce que je dis n'a pas de sens sans le prouver

Si j'ai bien compris, le HOS est plus sécurisé parce que pour booter dessus, il faut modifier le MBR.
De base, tu donne ton mdp au boot et tu arrives sur Windows. Si en plus tu utilises un HOS, he ben il faut modifier le MBR pour qu'il pointe sur le HOS. Et comme il est impossible de savoir qu'il existe un HOS, bah il est impossible de trouver où il est.
En gros c'est pour les cas de parano aigu.

Tiens je devrais peut être réécrire mes articles en anglais moi http://www.forensicfocus.com/index [...] c&start=10 et http://16systems.com/TCHunt/faq.php
 
j'en ai la culotte qui palpite, merci a ceux du topic qui m'ont donner l'idée de faire un billet la dessus.

Quel élitisme putain...
 
En tout cas je retiens une chose, mes propos " n'ont pas de sens "...

C'est quoi qui te pose problème toi ?

Tu réponds à qui/quoi en disant ça ?

On se calme

Je suis calme moi

Moi aussi
 

moi aussi, je bois un petit pastis

Je viens de voir un update v6.2a.
Je tente de comprendre le patchnote (hélas en anglais) pour savoir les nouveautés.

Bien vu !
 
Il n'y aucun nouveauté. Chez Truecrypt une lettre dans la version est synonyme d'amélioration du code ou de correction de bug. Pour avoir une nouveauté il faut un saut de version en chiffre.
 

Oui, c'est ce que j'ai découvert.

Temps que j'y suis j'ai fait un article sur l'utilité de l'hidden operating system dans le cas de rubber-hose cryptanalyse :
 
http://www.artiflo.net/2009/06/rub [...] ng-system/
 
edit : lien corrigé

Intéressant, par contre les fautes d'ortho c'est très très moyen

 
Ouep il y en a plusieurs par ligne. Il se peut même qu'il manque des mots à certaines phrases. C'est ce qu'on appel un brouillon

 
Je profite de relancer cette question sur l'efficacité du mot de passe de container TC.
 
Est-il envisageable qu'un brute force puisse venir à bout rapidement d'un mot de passe de 8 caractères ? (des mots inconnus qui n'existent dans aucun dictionnaire)
 
Je suis tenté d'augmenter la longueur du pass, mais une autre personne utilisera aussi la clé usb, et vu qu'elle n'est pas très fute fute en info, j'hésite à lui compliquer la tâche ^^

Ce qu'il faut comprendre c'est que c'est pas une attaque par force brute classique sur un mdp haché ou la on pourrait même utilisé des rainbow table.  
La ton mot de passe est transformé en clé. Cette clé est issus d'une fonction de dérivation de clé (KDF) qui va haché ton mdp avec de la SALT issus du PRNG et de x millier d'itération pour ralentir la génération de clé.
 
TC utilise PBKDF2 comme fonction de génération de clé, 64octets de SALT, 1000 à 2000 itéations.
 
DK = (SALT * MDP * 1000)
 
En gros pour un attaquant voici ce qu'il va devoir faire :
1 / Récupérer la SALT qui est en claire (facile)
2 / Mixer avec la SALT des caractères (facile)
3 / Haché x millier de fois de le résultat (très long)
4 / Tester le hash pour voir s'il ouvre le volume (facile)
5 / Répéter cette opération jusqu'a trouver la clé (trés trés trés long)
 
Alors oui, plus ton mdp va être long plus il va mettre du temps pour arriver jusqu'à ton mdp. Concernant les données précises il faut que je les retrouves, mais cela ne se compte pas uniquement en milliard d'année mais aussi en puissance à fournir aux calculateurs.

Merci pour cette explication
 
Je vais rajouter des caractères à la con pour augmenter la difficulté.

J'aurais quelques questions concernant cette merveille :

1 - Le backup du header, ok, mais faut-il en faire un après chaque fichier ajouté dans le container? Si j'ai 10 fichiers dedans, que je fais un backup, que je rajoute un fichier (et là je renouvelle pas le backup), et que soudain le header se corrompt et que je restore le backup : il va me rendre 10 ou 11 fichiers?

2 - Apparemment encrypter toute une partition pose le problème de la reconnaissance et du formatage proposé sous Windows : donc moi qui a un HDD d'1To, pouvez-vous me dire si les performances seront ok pour un fichier-container de 999Go (je laisserais 1Go pour faire fonctionner le déni plausible)? Un fichier-container aussi gros, ça se lit/encrypte bien?

3 - Peut-on créer un container d'une certaine taille puis plus tard l'agrandir? Ceci sans passer par la création d'un volume dynamique, car j'imagine que dans ce genre de container les données aléatoires nécessaires au déni plausible sont inexistantes.

4 - Il a été dit dans le topic que l'encryptage et le désencryptage ne produisaient pas de baisses de performances sensibles : a-t-on des chiffres/stats pour illustrer celà?

5 - J'aimerais en savoir plus sur l'encryptage : quel est l'intérêt d'encrypter chaque donnée (à la volée) quand il suffirait d'un simple mot de passe à l'accès du container?

6 - Les données sont "encryptées" à la volée... ça veut dire quoi? Qu'il y a plus de 1 et de 0 (^^) et donc que chaque fichiers pèse plus lourd?

'scusez pour ces questions de newbie  

Hello,
 
Ya pas de questions cons
 
1 - Non le header est independant du contenu du container. Le seul truc a savoir, c'est que si tu fais un backup du header, ensuite tu changes ton mot de passe et tu fais un restore header par la suite, le mot de passe sera l'ancien, celui qui etait actuel lors de la sauvegarde du header. C'est d'ailleurs grace a cette technique qu'un employeur peut utiliser pour ouvrir les fichiers containers de ses employes: Il cree le conteneur, et fait une backup du header. Ensuite, l'employe peut changer le mot de passe a sa guise. Si un jour l'employe ne veut pas donner son mot de passe, l'employeur n'a qu'a restaurer le header d'origine.
 
2 - Il me semble que la taille du container est independante des performances. Perso je prefere aussi un gros container, et sur la place restante tu laisses le fichier d'install de TC, comme ca tu peux l'utiliser partout meme sans le net.
 
3 - Oui, mais ce n'est pas pratique parce que la place doit etre 'reservee' a l'avance. Ce sont les containers dits dynamiques. Plus de details ds le manuel.
 
4 - Ya une fonction de benchmark incluse ds TC, et sinon tu n'as qu'a comparer les temps de copie avec et sans encryption. Ya surement des comparatifs online, mais bon ^^
 
5-6 : Jcomprends pas trop ta question ^^
 
 
 

Avant toute chose le verbe "encrypter" ou "crypter" n'existe pas en français et "encryptage" ou "cryptage" encore moins. Il faut utiliser le verbe chiffrer ou enchiffrer plus d'infos ici. Mais t'en fais pas même des grand site font la faute : ICI.
 
1 : Pas mieux que paradox. C'est vrai car la clé utilisé pour chiffré le volume n'est pas issus de ton mdp. La clé issus de ton mdp ne sert qu'a chiffrer le header qui contient les clés qui permettent de chiffrer le volume. Et donc quand tu change ton mdp, tu change uniquement la clé du header, pas du volume.
 
2 : Il y a plusieurs question par dessus les unes des autres. Pas compris.
 
3 : Oui comme l'a dit paradox, ça existe. Mais celon la doc les perf sont pourris et tu peux le faire qu'en NTFS.
 
4 : Je sais pas qui a dit ça mais c'est faux. En fonction des algorithmes utilisé (l'AES est overoptimisé comparé aux autres), si tu en met en cascade, si tu fait du FDE etc, la différence peut être significative.
 
5 et 6 : pas compris

Ok merci.

Pas compris les questions 5 et 6?

5 - Pourquoi un soft va-t-il "chiffrer" des données, alors qu'il suffirait juste qu'il les copie telles quelles dans le dossier qui lui serait protégé par un mdp?
Je dis ça parce qu'il existe un soft (tout pourri d'ailleurs) qui s'appelle "sarkophage", et qui dans son principe permet celà.

6 - Et en partant du principe qu'elles sont chiffrées (comme c'est le cas apparemment dans TC, à la différence de mon idée en 5-), celà signifie-t-il que plus de données binaires se trouvent au final pour un fichier? (ex : j'ai un fichier de 10ko, une fois chiffré pèse-t-il 10ko ou plus?)

Et je rajouterais, en rapport à la question 4 :

4bis - vous avez déjà installé une appli lourde ou un jeu dans un volume TC? Ca tourne bien? En fait je me pose la question des perfs quand il s'agit pour windows d'accéder à des données chiffrées, et que ça soit pas une copie ou lecture bête (comme on fait un ctrl+v ou on lit un fichier multiimédia), mais une utilisation complexe comme celle d'un software qui tente de s'executer dessus.

edit :

Alors ça fait dans les 33000 secondes pour 900Go, soit une douzaine d'heures??? !!!
On peut mettre sur pause le chiffrement et mettre son PC en hibernation la nuit ? Parce que 12h, 'tin quand même...

+

=

• Donc on est obligé de choisir FAT32 pour le formatage du container, si on veut créer un container caché après?
• On ne peut pas stocker un fichier supérieur à 4Gb dans un container en FAT32?
• Donc si mon HDD 1To est partitionné en FAT32, je ne pourrais créer des container que de 4Go.

→ Donc en gros mon HDD je le met en NTFS
→ et je crée un container FAT32 de 999Go
→ dans lequel je crée un container caché de 998Go

Question :
▫ Ce container caché peut-il être NTFS? Peut-on créer un container NTFS caché dans un container FAT32?
▫ Si oui, donc je pourrais mettre des fichiers de plus de 4Go ou pas? (dans le container caché NTFS qui est dans un FAT32?).