Journal CryptoFS ?

Posté par Benjamin (site web personnel) le 08 novembre 2004 à 22:05.

Étiquettes :

nov.

2004

Salut mon journal,

Habitué d'utiliser cryptoloop, (losetup) pour créer et monter mes partitions cryptées, un ami, ancien de Linux, m'a dit que cela présentait des dangers importants de corruption de données...

Dans le doute, je cherche quels systèmes alternatifs à cryptoloop, fiables et libre (bien sur) existent pour faire un système de fichiers crypté, si possible root compris ( root = / ) et si possible qui marche avec debian sarge (même s'il faut recompiler un noyau custom ou des packages maison ;) )

Journal, Ô mon journal, aurais-tu une idée ?

PS: Cette recherche fait écho à la saisie des disques durs de Indymedia par le FBI. Le but serait de faire un nouveau service pour un hébergeur mutualisé bien connu : proposer des / cryptés partout ;)

# cryptoloop est mort

Posté par 007 le 08 novembre 2004 à 22:20. Évalué à 3.
vive dm-crypt.

http://www.ibiblio.org/pub/Linux/docs/HOWTO/Cryptoloop-HOWTO(...)
- [^] # Re: cryptoloop est mort
  
  Posté par Benjamin (site web personnel) le 08 novembre 2004 à 23:05. Évalué à 2.
  
  oui, kernel 2.6.8.1 (le 2.6.9 a un trou de mémoire, 2 kernel panic en 2 jours sur une machine de test... )
  
  dm_crypt ? pas d'outils en cli ? bon, c'est l'occasion ou jamais d'aider à avoir un zoli outil propre pour configurer ce bouzin ?
  
  Merci à vous les geeks.
  - [^] # Re: cryptoloop est mort
    
    Posté par 007 le 08 novembre 2004 à 23:19. Évalué à 1.
    > le 2.6.9 a un trou de mémoire, 2 kernel panic en 2 jours sur une machine de test...
    
    Les noyaux vanilla ne sont pas fait pour être exempt de tout défaut car moins testé que les noyaux des distributions.
    FC3 est sorti avec Linux 2.6.9. Le noyau (avec les patchs Fedora) est utilisé depuis le 3/11 sans gros problème (il y a un problème avec les imprimantes réseau lorsqu'on utilise un firewall. Un workaround existe).
    Depuis le passage en 2.6.9 il y a eu plusieurs fix :
    rpm -q --chancelog :
    Comme tu le vois, il y a 15 jours de debuggage. Ici, ça marche nickel.
- [^] # Re: cryptoloop est mort
  
  Posté par djrom le 08 novembre 2004 à 23:44. Évalué à 1.
  
  A noter quand même quelques problèmes de sécurité dans dm-crypt dans l'état actuel, problèmes qui devraient être réglés d'ici quelques temps, néanmoins:
  http://clemens.endorphin.org/LinuxHDEncSettings(...)
# dmcrypt ?

Posté par M le 08 novembre 2004 à 22:21. Évalué à 1.

si tu as un kernel 2.6
# EncFS

Posté par bergamote23 le 08 novembre 2004 à 23:50. Évalué à 2.

http://arg0.net/users/vgough/encfs.html(...)

Il parait que c'est assez costaud en ce qui concerne la méthode de cryptage et que c'est correct niveau vitesse. J'ai pas testé.
# ?

Posté par Marc (site web personnel) le 09 novembre 2004 à 09:26. Évalué à 2.

PS: Cette recherche fait écho à la saisie des disques durs de Indymedia par le FBI. Le but serait de faire un nouveau service pour un hébergeur mutualisé bien connu : proposer des / cryptés partout ;)

La loi ne t'obligerait pas a fournir les clé de chiffrement avec la saisie des disques?
- [^] # Re: ?
  
  Posté par calandoa le 09 novembre 2004 à 10:01. Évalué à 2.
  
  Dans ce cas il faut utiliser BestCrypt... (http://linuxfr.org/~calandoa/15270.html(...)).
  C'est pas libre, mais les sources sont fournis.
  
  Par ailleurs, comment est il possible d'avoir un fs chiffré à partir de la racine? Comment le boot loader peut il alors charger le noyau? En passant par une première partition claire, puis en en remontant une chiffrée à la racine?
  - [^] # Re: pivot_root / initrd & co
    
    Posté par Benjamin (site web personnel) le 09 novembre 2004 à 12:29. Évalué à 2.
    
    Oui, en utilisant une partition de 20 Mo contenant juste le noyau, point, qui montera ensuite le / encrypté.
    
    On peut aussi utiliser un / temporaire contenant juste les outils de montage de partition crypté puis utilise pivot_root pour remonter / sur la partition cryptée.
    
    Je ne sais pas encore ce dont aura besoin dm-crypt pour pouvoir monter / encrypté. (juste le noyau ou un / minimal avec des binaires de montage comme cryptsetup)
    - [^] # Re: pivot_root / initrd & co
      
      Posté par Krunch (site web personnel) le 11 novembre 2004 à 18:56. Évalué à 2.
      
      L'utilisation d'un initrd est probablement plus aproprié (cf /usr/src/linux/Documentation/initrd.txt ou un truc comme ça).
      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
- [^] # Re: ?
  
  Posté par philz le 09 novembre 2004 à 10:25. Évalué à 3.
  
  La loi ne t'obligerait pas a fournir les clé de chiffrement avec la saisie des disques?
  
  Seulement sur demande d'un juge d'instruction.
  
  Dans le cas d'Indymedia, les disques auraient plus ou moins été "empruntés" par le FBI sans qu'un motif réel d'infraction ne soit établi, ou en tout cas sans que les propriétaires des disques n'en soient clairement informés.
  
  C'est contre ce genre d'abus qu'un FS chiffré te protège.
  - [^] # Re: ?
    
    Posté par Anonyme le 09 novembre 2004 à 13:45. Évalué à 0.
    
    Dans le cas d'Indymedia, les disques auraient plus ou moins été "empruntés" par le FBI sans qu'un motif réel d'infraction ne soit établi, ou en tout cas sans que les propriétaires des disques n'en soient clairement informés.
    C'est contre ce genre d'abus qu'un FS chiffré te protège.
    
    Sans vouloir vous démoraliser, si le FBI a vraiment besoin d'accéder à vos données, qu'elles soient chiffrées ou non, ils ont à leur disposition de quoi casser rapidement n'importe quel système de chiffrement.
    
    Bref, mis à part que les données seront "secrètes" quelques heures de plus (le temps de transiter vers le centre adéquat), je ne vois pas l'avantage, si ce n'est que la garde à vue risque d'être un peu plus longue (je serais tenté de dire proportionnellement plus longue au temps nécessaire pour accéder aux données).
    
    Pour moi le chiffrement des données, c'est surtout pour éviter de perdre des secrets personnels et/ou industriels lors d'un cambriolage ou d'un piratage, voire de la perte d'une machine ou d'un média.
    - [^] # Re: ?
      
      Posté par cedric le 09 novembre 2004 à 14:21. Évalué à 2.
      
      Sans vouloir vous démoraliser, si le FBI a vraiment besoin d'accéder à vos données, qu'elles soient chiffrées ou non, ils ont à leur disposition de quoi casser rapidement n'importe quel système de chiffrement.
      
      Enorme :-D
      
      Sans rire tu penses vraiment que le FBI a les moyens de casser du chiffrement 256 bits ? J'ai l'impression que tu n'as aucune idee de l'ordre de grandeur. Avec l'integralite de toutes les machines construite jusqu'a aujourd'hui et mise en parallele, tu mettrais plusieurs centaines (milliers ?) d'annees avant de pouvoir acceder a leur contenu. Sans compter un autre effet interressant, faire de l'analyse statistique sur un systeme de fichiers, c'est loin d'etre la meme chose que de le faire sur du texte. Il y a de grande chance que tu es enormement de faux positif. Franchement, je ne me fais pas de soucis pour la securite des donnees.
      
      PS: Il y a que dans les films que l'on sait casser un chiffrement de 1024 bits de tete...
      
      PS2: L'ordre de grandeur pourrait peut-etre etre diminuer un peu avec un ordinateur quantique. Mais on en est encore tres loin.
      - [^] # Re: casser de la crypto 256Bits AES
        
        Posté par Benjamin (site web personnel) le 09 novembre 2004 à 15:14. Évalué à 2.
        
        Salut,
        
        J'ajoute à cela que si le FBI à envie de casser mon FS crypté en AES256, on va se retrouver dans une position "niveau de besoin" vs. "moyens mis en oeuvre".
        
        En effet, dans le cas d'indymedia, je ne sais pas s'ils auraient été jusqu'à un bruteforce d'une partition cryptée si celle-ci avait été cryptée ? En gros, le besoin d'information qu'ils avaient était-il suffisemment important pour justifier de mettre X millions d'heures CPU sur cette affaire ? et oui, ... La seule chose à craindre en fait dans cette situation est que le type qui a la passphrase se fasse enlever et qu'on lui fasse cracher le morceau ;( ...
        
        Je pense donc être suffisemment bien protégé avec AES256 ... reste à couper la clé en 2 ou 3 :)
      - [^] # Re: ?
        
        Posté par Snark_Boojum le 09 novembre 2004 à 15:19. Évalué à 2.
        
        Euh... ces ordres de grandeur c'est pour la force brute. S'ils connaissent une faille de la méthode de crypto, il n'est pas impossible qu'ils n'aient besoin que de quelques secondes même sur une petite machine. "Si".
        
        Ceci dit il est intéressant de regarder leurs contributions aux mises au point des standard de crypto. Si je me souviens bien, il y a quelques années, ils ont demandé une petite modification sur un truc proposé ; un peu après on a découvert une nouvelle méthode d'attaque des systèmes de crypto, contre laquelle la modification était une très bonne protection.
        
        Snark
      - [^] # test
        
        Posté par Anonyme le 09 novembre 2004 à 15:56. Évalué à 2.
        
        C'est bizarre, ça fait 2 fois que j'essaye de répondre à ce commentaire, et ma réponse n'apparaît toujours pas. Je suis pourtant certain (en tout cas pour le deuxième post) d'avoir vérifier-valider mon commentaire.
        
        Ce message n'est qu'un test pour vérifier, il n'a aucun intérêt, c'est potentiellement ma 3ème réponse au commentaire au dessus.
# hébergement distant et chiffrement = pas bon ménage

Posté par philz le 09 novembre 2004 à 10:45. Évalué à 2.

PS: Cette recherche fait écho à la saisie des disques durs de Indymedia par le FBI. Le but serait de faire un nouveau service pour un hébergeur mutualisé bien connu : proposer des / cryptés partout ;)

Il y a un truc que je ne comprends pas : pour avoir un / chiffré, il faut bien fournir la clé au boot, donc :

- soit elle est stocké en clair sur le serveur (disquette, clé usb ...),
- soit un opérateur tape le mot de passe sur la console.

Dans le premier cas ça ne sert à rien de chiffrer : celui qui saisit les serveurs saisit aussi les clés et il a accès à tout.

Dans le second cas ça suppose que le client puisse taper son mot de passe au démarrage, donc qu'il se déplace dans les locaux de l'hébergeur après chaque reboot, programmé ou pas !

Est ce que ça ne risque pas d'être un chouïa lourd à gérer ?
- [^] # Re: hébergement distant et chiffrement = pas bon ménage
  
  Posté par Benjamin (site web personnel) le 09 novembre 2004 à 11:57. Évalué à 2.
  
  non, pas lourd à gérer car :
  
  - nous avons un KVM-IP pour accéder aux console à distance ( http://cuc.fr/transdonnees/kvm/067160.jpg(...) )
  - oui, on tape le mot de passe à chaque reboot, mais
  * sous linux, on ne reboote pas souvent (sauf faille majeure de noyau, mais là on planifie le reboot ;) )
  * l'architecture load-balancée de cet hébergeur permet de rebooter les serveurs un par un sans interrompre le service ;)
  
  Donc, oui, / crypté (sauf le noyau lui-même dans une petite partition non cryptée) et saisie des mots de passes de partitions au démarrage.
  
  Pour les aspects juridiques, c'est en effet contre les abus de pouvoir de gens comme rackspace que nous nous prémunissons (nous ne sommes pas chez eux, mais c'est chez rackspace UK que les serveurs d'indymedia ont été saisis, à la demande du FBI (cherchez l'erreur ...) )
  - [^] # Re: hébergement distant et chiffrement = pas bon ménage
    
    Posté par philz le 09 novembre 2004 à 15:50. Évalué à 1.
    
    nous avons un KVM-IP pour accéder aux console à distance ( http://cuc.fr/transdonnees/kvm/067160.jpg(...(...)) )
    - oui, on tape le mot de passe à chaque reboot,
    
    La première fois, les flics se feront avoir et embarqueront un disque indéchiffrable.
    
    La seconde fois, ils se pointeront avec une machine espion à 2 balles qu'ils brancheront entre le KVM et le serveur puis vous obligeront à envoyer le mail automatique "Cher client, suite à un probème d'onduleur votre serveur s'est arrêté, merci de vous logguer bla bla bla ...". Ils attendront ensuite tranquillement une heure, un jour ou une semaine que le client se connecte et remonte la partition, puis ils repartiront avec les disques et le mot de passe en clair.
    
    Sans un contrôle physique de l'intégrité du serveur *avant* de saisir le moindre mot de passe, le client ne peut jamais être sûr de ne pas s'être connecté sur un leurre.
    
    Pour les aspects juridiques, c'est en effet contre les abus de pouvoir de gens comme rackspace que nous nous prémunissons
    
    On est bien d'accord, mais si l'hébergeur est de mauvaise foi le client l'aura dans l'os.
    - [^] # Re: hébergement distant et chiffrement = pas bon ménage
      
      Posté par fleny68 le 09 novembre 2004 à 18:24. Évalué à 2.
      
      Il faudrait un système genre ssh et échange de clef pour pouvoir se logguer sur la console et monter les partitions.
      - [^] # Re: hébergement distant et chiffrement = pas bon ménage
        
        Posté par philz le 09 novembre 2004 à 21:58. Évalué à 1.
        
        Pas suffisant.
        
        La clé ssh sera présenté par le "serveur de consoles" au client, mais comment peut il vérifier que le serveur de console n'est pas monitoré ?
        
        Non en fait la seule solution c'est un système cryptographique hardware qui authentifie chaque élément matériel du serveur avant de démarrer un mini serveur ssh qui permet au client de fournir la clé lui permettant de continuer son boot.
        
        Tiens, finalement TCPA pourrait avoir des applications utiles !
        
        [^] # Re: hébergement distant et chiffrement = pas bon ménage
        
        Posté par earxtacy le 10 novembre 2004 à 12:55. Évalué à 1.
        
        Ton client ssh te dira que c'est pas la bonne clé.
# Les partitions de données seules?

Posté par fleny68 le 09 novembre 2004 à 12:14. Évalué à 4.

Je vais sûrement dire une çonnerie, mais quel est l'intérêt de chiffrer tout y compris /, /usr/, etc..) au lieu de chiffrer juste le swap et les partitions de données (/home, /var et swap) ?
- [^] # Re: Les partitions de données seules?
  
  Posté par Benjamin (site web personnel) le 09 novembre 2004 à 12:27. Évalué à 2.
  
  La garantie qu'il ne sortiront RIEN de la machine, ni même la petite requete qui trainerait sur /root/.mysql_history ou encore le fait que l'on utilise un binaire du logiciel "toto" ayant telle ou telle faille, bref, non-disclosure totale pour ces gens là tant qu'ils n'ont pas notre accord.
  
  De toute manière, ca ne coute pas plus cher car les binaires / conf sont en cache en ram rapidement sur nos serveurs (1Go de ram mini) et ne sont jamais relus sur le disque.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.