Forum Linux.général Cryptage disque dur

Posté par .
3
20
sept.
2012

Bonjour,

Je suis en train de réfléchir à un système de serveur web et je butte sur le cryptage du disque dur (au moins la partie qui contient les données du serveur web, pas forcément tout le disque).

Ok, on crypte la partition avec LVM, c'est facile. Sauf que je ne serai pas devant ma machine si elle redémarre et je ne peux donc pas taper la passphrase au démarrage.

J'ai vu qu'il y avait une histoire de clé USB contenant la clé de décryptage. Donc imaginons que le pc contienne une clé USB et à chaque démarrage il décrypte le disque sans intervention humaine.
1/ Est-ce qu'une personne sera capable de retrouver le contenu du disque s'il vole le pc, le disque et la clé USB ?

2/ Est-ce qu'il est possible d'une manière ou d'une autre que le disque soit "déverrouillé" via une clé sur internet ?

Désolé pour mon incompétence dans ce domaine…

  • # oui

    Posté par . Évalué à 4.

    J'ai vu qu'il y avait une histoire de clé USB contenant la clé de décryptage. Donc imaginons que le pc contienne une clé USB et à chaque démarrage il décrypte le disque sans intervention humaine.
    1/ Est-ce qu'une personne sera capable de retrouver le contenu du disque s'il vole le pc, le disque et la clé USB ?

    ca tombe sous le sens du moment qu'il n'y a pas d'intervention humaine necessaire et que la personne a acces à la machine, son disque et sa clef de cryptage, oui elle pourra acceder au contenu du disque dur, simplement en demarrant la machine.

    2/ Est-ce qu'il est possible d'une manière ou d'une autre que le disque soit "déverrouillé" via une clé sur internet ?

    OUI, tu peux tres bien ajouter des options dans le script de demarrage pour par exemple :
    - aller chercher un fichier (qui contient la cle) sur un autre serveur
    - lire le contenu de ce fichier pour deverrouiller le montage du dossier crypté
    - monter le disque
    - lancer le service web.

    si on te vole ta machine, tu supprimes/deplaces le fichier de cle, si la personne cherche juste à lancer le serveur, il n'y aura plus acces.

    • [^] # Re: oui

      Posté par . Évalué à 0.

      ca tombe sous le sens du moment qu'il n'y a pas d'intervention humaine necessaire et que la personne a acces à la machine, son disque et sa clef de cryptage, oui elle pourra acceder au contenu du disque dur, simplement en demarrant la machine.

      Pas forcément, s'il n'a pas le mot de passe de la machine. Il ne pourra rien faire sur la machine même, ni via le réseau s'il n'y a pas de partage.

      Par contre je vais creuser cette idée de fichier sur un serveur distant, ça me parait être une solution parfaite pour moi.

      Merci

      • [^] # Re: oui

        Posté par . Évalué à 2.

        Pas forcément, s'il n'a pas le mot de passe de la machine. Il ne pourra rien faire sur la machine même, ni via le réseau s'il n'y a pas de partage.

        S'il a la clé USB qui permet le déchiffrage de la partition et un accès physique à la machine il peut booter sur un système live et faire sauter le mot de passe root sans problème.

        Enfin du coup j'ai un doute. Est-ce que le système live va être en mesure d'utiliser la clé USB pour déchiffrer la partoche ou est-ce que l'on peut récupérer le mot de passe de déchiffrement depuis la clé (manuellement en branchant la clé ailleurs, pour ensuite l'entrer au prompt LVM) ? Je ne l'ai jamais fait en fait :)

        • [^] # Re: oui

          Posté par . Évalué à -1.

          Oui on reprend un peu la question de base. Si une personne compétente se retrouve avec la clé et le disque, peut-elle accéder aux fichiers ?

      • [^] # Re: oui

        Posté par . Évalué à 1.

        Avec un accés physique à la machine, pas besoin de password pour se connecter…

        • [^] # Re: oui

          Posté par . Évalué à 0.

          oui en branchant le disque en esclave sur un autre pc, mais s'il est crypté, comment le rendre impossible à décrypter

        • [^] # Re: oui

          Posté par . Évalué à 3.

          Pourrais-tu être plus précis ?

          Dans le cas d'un disque non crypté c'est facile, boot sur un système live, on fait sauter le mot de passe root. Ou bien on branche le disque en esclave sur une autre machine. OK.

          Dans le cas d'un disque crypté avec LVM configuré pour aller chercher le mot de passe de déchiffrage sur une clé USB comment fait-on ?

          Si tu avais la gentillesse d'exposer ta méthode…

          • [^] # Re: oui

            Posté par . Évalué à 3.

            J'imagine qu'il suffit de récupérer la clé sur la clé usb…

            • [^] # Re: oui

              Posté par . Évalué à 1.

              Je me demandais justement si la passphrase se trouvait en clair dans un bête fichier texte sur la clé USB ou bien si LVM utilisait un mécanisme à base de hachage, c'est à dire que la clé USB ne contient qu'un hash et ne peut donc déchiffrer la partition seulement si le noyau boot avec cette partition comme partition racine.

              Si on utilise le système live pour booter on va pouvoir (grâce à la clé USB) déchiffrer et monter la partition comme racine, et là et bien le mot de passe root protège encore le système. Si on boot sur la racine du système live on ne pourra pas (après coup) déchiffrer et monter la partition chiffrée à l'aide de la clé USB ?

          • [^] # Re: oui

            Posté par . Évalué à 3.

            Vu qu'il parle d'une clé resté sur le PC ça change pas grand-chose.

            Pour moi son problème se rapproche plus de celui d'un DRM que d'un système de chiffrement, la machine a la clé pour booter, mais n'a pas la clé pour les méchants, ça ressemble vachement à de l'informatique de confiance, ou plutôt, comme j'aime l’appeler, rendre schizophrène une machine de Turing (ça donne une idée plus claire des chances d'y arriver…)

            Pour moi la meilleure solution est d'utiliser une clé distante, pour plus de sécurité tu peut la mettre sur un serveur avec contrôle de l'IP source de la demande et même ne la rendre disponible que quand tu reboot ton serveur (comme ça pas de vol), dans ce dernier cas pas de reboot automatique, mais de toute façon le reboot automatique d'un serveur sans analyse des causes du crash c’est le M4L !

            • [^] # Re: oui

              Posté par . Évalué à 1.

              Le serveur web hébergera des données sensibles, il n'est pas question que quelqu'un puisse accéder aux données en cas de vol du serveur.

              L'idée d'une clé distante disponible via un contrôle IP lors d'un redémarrage me plait beaucoup.

              • [^] # Re: oui

                Posté par . Évalué à 1.

                Si on a accès (physique ou non) au serveur pendant qu'il tourne, la partition est déjà montée, et on faire ce que l'on veut.
                Chiffrer le disque empêche juste que l'on essaye de lire le disque après l'avoir volé.

                La solution avec lecture de la clé sur un serveur distant est intéressante, mais il ne faut pas oublier d'utiliser une connexion chiffrée avec celui-ci, bien entendu.

                • [^] # Re: oui

                  Posté par . Évalué à 2.

                  Si on a accès (physique ou non) au serveur pendant qu'il tourne

                  Je me plaçais justement dans le cas où le serveur est débranché, embarqué, et redémarré plus tard. S'il est en train de tourner, aucune session ouverte, le mot de passe root (pour ouvrir un session) n'est pas récupérable.

                • [^] # Re: oui

                  Posté par . Évalué à 0.

                  Comme dit Marotte, le serveur est démarré mais aucune session n'est ouverte donc impossible d'aller fouiller les fichiers sans mot de passe.

                  Evidemment une connexion SSL serait mise en place pour aller chercher la clé.

                  Je créerai une maquette dans les semaines à venir. Il faut que je trouve maintenant comment déverrouiller un disque via une clé distante

                  • [^] # Re: oui

                    Posté par . Évalué à 2.

                    Je créerai une maquette dans les semaines à venir. Il faut que je trouve maintenant comment déverrouiller un disque via une clé distante

                    de la meme maniere qu'en automatique en local
                    simplement il faut aller chercher la clef sur une machine distante au lieu de la prendre dans un fichier local

                    • [^] # Re: oui

                      Posté par . Évalué à 0.

                      simplement il faut aller chercher la clef sur une machine distante au lieu de la prendre dans un fichier local

                      C'est justement ça qui me pose problème ;)

                      • [^] # Re: oui

                        Posté par . Évalué à 2.

                        tu sais faire un scp ?

                        1°) à faire une seule fois :
                        tu echanges les clefs entre tes deux machines

                        2°) juste avant le montage du dossier crypter tu fais ton scp pour recuperer la clef

                        scp serveur-distant:/chemin/vers/la/clef /chemin/local/vers/la/clef

                        ensuite c'est la procedure normal de montage automatique par clef sans mot de passe.

                        • [^] # Re: oui

                          Posté par . Évalué à 2.

                          juste avant le montage du dossier crypter tu fais ton scp pour recuperer la clef

                          Comment tu fais un scp si le rootfs du système cible, crypté, n'est pas monté ?

                          Oui, j'ai peut-être rien compris.

                          • [^] # Re: oui

                            Posté par . Évalué à 2. Dernière modification le 21/09/12 à 21:19.

                            Il parle de chiffrer "au moins le dossier de la DB du site" si j'ai bien lu, pas obligatoirement tout le système. Et puis un rootfs chiffré a de toute façon besoin d'un gros initrd, en clair lui, pour booter (lvm, luks… et bien-sur un noyau)

                            • [^] # Re: oui

                              Posté par . Évalué à 2. Dernière modification le 21/09/12 à 21:21.

                              Il parle de chiffrer "au moins le dossier de la DB du site"

                              Bien vu.

                          • [^] # Re: oui

                            Posté par . Évalué à 3.

                            oui je parlais de ne crypter que la partie "site web, base de données" et pas l'integralité du rootfs.

                            et meme si c'etait le cas, il faut alors jouer sur les scripts de l'initrd pour lui faire faire le scp dans le rootfs temporaire avant qu'il ne monte le vrai rootfs et qu'il ne fasse le pivot.

                            • [^] # Re: oui

                              Posté par . Évalué à 0.

                              Il n'y aura rien d'extraordinaire sur le serveur mise à part une appli web. Je ferai une partition cryptée contenant les fichiers nécessaires. Après si le mec arrive à voir les fichiers qui sont dans etc ou autre, m'en fout, y'a rien de confidentiel.

                              Je ne connais pas encore SCP, mais bon, tout s'apprend ;)

                              Je chercherai un tuto

                              • [^] # Re: oui

                                Posté par . Évalué à 2.

                                Je ne connais pas encore SCP, mais bon, tout s'apprend ;)

                                scp, c'est la meme chose que cp mais au travers de ssh

                                il faut donc commencer par te renseigner sur l'echange de clef pour une connexion ssh entre deux machines.
                                ca doit deja te permettre de te connecter depuis ton serveur vers la machine distante sans demande de mot de passe

                                ensuite seulement le scp pourra faire ca copie à partir du serveur web en allant chercher sur le serveur distant

  • # Un truc important à savoir

    Posté par . Évalué à 2.

    L'accès physique à la machine est critique. Pour pouvoir lire et écrire sur un volume chiffré, le noyau a besoin de connaitre la clé de chiffrement, laquelle se trouve dans la mémoire vive. Il faut avoir conscience du fait qu'une barrette de RAM ne perd pas ses données instantanément quand on la débranche, elles restent lisibles au moins plusieurs secondes, voir plusieurs minutes si on les passe à la bombe à froid.

    Il est tout à fait possible d'avoir le serveur le plus sûr du monde, avec les disques über-chiffrés. Il suffit alors de l'ouvrir, de refroidir les barrettes de RAM, d'éteindre la machine et de les lire avec un autre ordinateur, tout simplement. Bon, c'est pas forcement facile de retrouver la clé dans ce bordel, mais ça se fait.

    Il faut en plus prévoir la possibilité d'effacer en urgence la RAM si jamais on tente d'ouvrir la machine.

    Please do not feed the trolls

    • [^] # Re: Un truc important à savoir

      Posté par . Évalué à 2.

      Je veux bien être un brin parano, m'enfin bon le coup d'aller chercher la clé dans la mémoire vive n'est pas donné à tout le monde.

      Je souhaite protéger les données contre la copie, bon si après un gars rentre dans l'entreprise, trouve le serveur, sait qu'il y a des infos confidentielles et sait que le disque est crypté et qu'il ne faut pas arrêter le pc avant de décoder la clé qui se trouve dans la RAM. Je pense qu'il aura bien mérité l'accès aux données

  • # Débloquer à distance

    Posté par (page perso) . Évalué à 1.

    Outre le fait de récupérer la clé sur un serveur distant, je vois deux autres moyens de redémarrer le service à distance :
    - cryptsetup propose de faire tourner un serveur SSH minimal avant le boot ce qui permet de saisir un mot de passe sans accès physique à la machine, voir http://blog.neutrino.es/2011/unlocking-a-luks-encrypted-root-partition-remotely-via-ssh/
    - j'ai personnellement opté à la lecture de http://linuxfr.org/users/tchetch/journaux/netbook-et-niveau-d-execution pour enlever du runlevel par défaut (le 2 dans mon cas) tout ce qui dépendait de ma partition cryptée, et débloquer comme ceci :

    $ ssh unlock@server telinit 3
    
    

Suivre le flux des commentaires

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