Faire tourner un noeud membre sur un serveur hébergé chiffré sans dévoiler sa clef privée !

Je suis tombé sur cet article qui semble montrer que l’on peut chiffrer le disque d’un serveur distant, puis y accéder via une clef privée ssh, sans que l’hébergeur puisse avoir accès aux données.

https://blog.tetsumaki.net/articles/2019/02/installation-de-void-linux-chiffre-sur-un-serveur-distant.html

Le but est de pouvoir faire tourner un nœud Duniter avec sa clef privée de membre sur un serveur hébergé.

Il semble que la partition est déchiffrée au moment de l’accès ssh et seulement pour les services lancés…

Dites-moi ce que vous en pensez et si vous voyez une faille.

Dans tous les cas, puisque la machine appartient à l’hébergeur, même si seul le processus de Duniter peut déchiffrer la partition, c’est avec une clé qui est stockée en mémoire. Et la lecture de la mémoire d’un processus est possible en root ou si la machine est une VM, avec des outils de debug…

Et puis si je comprends bien, la clé privée SSH doit être en clair, non ? Du coup l’hébergeur peut intercepter et déchiffrer les communications.

1 Like

Mais pour que l’hébergeur se connecte root, il doit redémarrer sur un autre système.

Je ne vois pas l’histoire de la clé privée en clair. c’est à quel endroit ?

Ou installer un rootkit et ainsi avoir le contrôle complet de la mémoire.

Un serveur acceptant des connexions SSH sécurisées doit avoir une clé privée en clair. Si on ne veut pas stocker cette clé en clair, on peut la chiffrer. Cependant pour l’utiliser on doit la déchiffrer, donc son propriétaire doit entrer la clé de déchiffrement et à un moment ou à un autre, la mémoire contient la clé privée en clair.

En une phrase : celui qui détient physiquement un ordinateur a tous les pouvoirs dessus. Un mot de passe utilisateur peut empêcher un collègue d’installer un virus sur l’ordi pendant la pause café, mais pas un voleur d’accéder aux fichiers.

2 Likes

Je ne comprends pas pourquoi le ssh aurait sa clef privée sur le serveur, la clef publique suffit…

C’est vrai ! Il est donc actuellement impossible ou inconscient de faire héberger un nœud membre par un tiers.
Ce qui est une limitation à laquelle on peut réfléchir pour le futur (clef privée dérivée temporaire, renouvelée régulièrement comme avec Let’s encrypt par exemple).

1 Like

Il faut bien que le client puisse chiffrer les données qu’il envoie au serveur, donc que le serveur aie une clé privée à lui ?

Pour l’authentification, une clef publique sur le serveur suffit, pour le chiffrement symétrique de la connexion, je ne connais pas en détails le protocole ssh, je te fais confiance… :wink:

1 Like

En fait je ne connais pas le protocole, je pensais que la communication était chiffrée en asymétrique. Même si c’est symétrique, la clé symétrique peut être connue par l’hébergeur en fouillant dans la mémoire ou en contrôlant les sources physiques de hasard.

1 Like