Bonjour,
Dans le but de recycler quelques matériels ancien (et aussi de m'amuser), je me suis monté un serveur. Il tourne avec Archlinux et sa première utilisation est le partage de fichier via NFS. Toutes les partitions sont chiffrées avec Luks.
Un objectif est d'avoir un chiffrage des données sur le partages NFS, mais sans que le serveur lui même en possède la clé (un peu comme un nextcloud chiffré, mais sans synchro). Pour le moment, j'ai mis en place le chiffrement par les clients avec EncFS sur le partage. Cela fonctionne, mais évidemment cela coûte (un peu) en performance coté client.
Puis une idée m'est venu pour me passer d'EncFS, mais je ne sais pas si elle est bonne. Ce pourquoi je fais appel à vos avis.
Sur le serveur, j'ai fait un script qui démarre/arrête le service NFS; monte/démonte le système de fichier sur lequel sont les données et déchiffre/ferme la partition luks correspondante. Pour le montage, le client ,via ssh, copie une clé sur le serveur et démarre le script. La clé est effacée du serveur dès que la partition luks est déchiffrée. Il faut relancer le script lors de la déconnexion du client.
Cela fonctionne et donc le serveur ne possède pas la clé de déchiffrement des données, mais je vois deux inconvénients. Les données sont déchiffrées sur le serveur (mais seulement lorsqu'on y accède). Si le client se déconnecte sans relancer le script, les données restent déchiffrées (pour ce point j'imaginai créer un timer scrutant l’activité des clients, si pas de client pendant un temps, on ferme tout.)
Voilà, l'idée est-elle bonne? Y a-t-il d'autres solution?
# Non ?
Posté par Cyril Brulebois (site web personnel) . Évalué à 1.
Si la clé est copiée sur le serveur une seule fois, c'est perdu, non ?
Debian Consultant @ DEBAMAX
[^] # Re: Non ?
Posté par bertile . Évalué à 1.
La clé est copiée en ram au moment du déchiffrement et supprimée dès l'opération terminée. C'est peut-être pas top mais bon normalement les risques sont réduits.
# Ça dépend
Posté par ted (site web personnel) . Évalué à 3.
Tu souhaites te protéger de quoi? Je pense que le seul intérêt avec ce système c'est en cas de vol du serveur, tes données seraient alors inaccessibles.
Cela ne protège pas de:
- quelqu'un connecté sur ton réseau
- un utilisateur connecté sur le serveur
Un LUG en Lorraine : https://enunclic-cappel.fr
[^] # Re: Ça dépend
Posté par bertile . Évalué à 1.
C'est exactement ça, c'est surtout en cas de vol du serveur. Celui-ci n'est exposé qu'au réseau local sur lequel les risques sont minimum.
# une autre approche ...
Posté par totof2000 . Évalué à 2.
utiliser un gros fichier sur le partage nfs, que tu montes en loopback sur le client. La clé et le chiffrage/déchiffrage se font sur ce dernier. Le serveur ne voit qu'un gros fichier chiffré.
Mais cette approche me parait un peu douteuse, a mon avis NFS n'est pas vraiment fait pour ça …
[^] # Re: une autre approche ...
Posté par bertile . Évalué à 1.
Avec du déchiffrement sur le client, le couple NFS/EncFS fonctionne bien. Je souhaite tester une solution où c'est le serveur qui déchiffre, mais uniquement à la demande.
J'utilise NFS pour mes autres partages sur NAS et autre et j'en suis satisfait. C'est pourquoi je me base sur ça. Après, ce n'est peut-être pas une bonne idée. Mais, bon, n'étant pas pro, je ne vois pas quelle autre solution me conviendrait.
[^] # Re: une autre approche ...
Posté par totof2000 . Évalué à 2.
Quel est l'intéret ? Si le serveur déchiffre, tu vas devoir de toute façon rechiffrer lors de la transmission réseau (sinon ça n'a pas de sens), pour redéchiffrer sur le client.
[^] # Re: une autre approche ...
Posté par bertile . Évalué à 1.
Le serveur étant costaud, j'imaginais alléger les processeurs des clients. Par exemple la lecture d'une video actuellement nécessite le décodage de la video + le déchiffrement du fichier. Sur des "netbook" un peu anciens (oui, je recycle), ça fait beaucoup.
Pour la transmission sur le réseau, c'est un réseau local distinct de celui de la box, donc j'avoue que j'ai plus peur du vol de matériel que d'une intrusion sur le réseau.
Bon, après, oui, ça n'a pas vraiment de sens, c'est juste une lubie de confinement, histoire de faire tourner les méninges et d'apprendre (la nation apprenante…)
[^] # Re: une autre approche ...
Posté par flan (site web personnel) . Évalué à 2.
Le chiffrement est généralement de l'AES128 ou 256, autrement dit quelque chose que la plupart des processeurs modernes savent faire en matériel depuis longtemps, avec des instructions dédiées. Autrement dit, ça ne doit pas coûter grand-chose.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.