PFS sans connexion

La confidentialité persistante (Perfect Forward Secrecy – PFS pour les intimes) permet lors d’échanges entre personnes via un support protégé d’oublier le contenu des échanges précédents. Lorsqu’elle est bien implémentée, il est impossible de pouvoir reconstituer les échanges précédents d’une « conversation », y compris pour les personnes concernées.

Lors de la compromission du moyen de communication, seules les conversations en cours sont accessibles. Les précédentes conversations sont définitivement inaccessibles y compris pour un adversaire qui aurait enregistré tous les échanges chiffrés et obtiendrait par la force le compte d’un utilisateur.

La meilleur méthode pour arriver à ce résultat est d’utiliser un secret de session partagé entre les personnes qui communiques, négocié en début de conversation et volontairement oublié en fin de conversation. La négociation peut être faite notamment via un échange de type Diffie-Hellman (DH).

La PFS a donc principalement deux contraintes. Il faut échanger un secret temporaire avec ses correspondants. Et il faut que ce secret soient privés, c’est à dire stockés uniquement en interne sur les machines destinataires.

De par sa conception acentrée et potentiellement non directement inter-connecté, nebule ne permet pas la mise en place directe d’une forme de PFS. Fondamentalement, nebule permet de gérer de l’information et non des connexions. La non connexion directe entre les correspondants empêche une négociation préalable instantanée d’un secret partagé type DH. Ensuite, toute la protection de la partie privée des entités repose sur le chiffrement des objets et l’offuscation des liens, mais tous les liens et objets ainsi protégés sont partagés publiquement et donc enregistrables. Il n’est pas possible de se baser sur ces mécanismes de protection pour la PFS.

Il existe peut-être un moyen d’implémenter une PFS sûr dans nebule mais au prix d’un grand nombre d’objets à synchroniser, à voir…

Entit̩ multi-r̫les Рsuite

Suite de l’article sur les Entité multi-rôles.

La gestion de multiples clés cryptographiques asymétriques dépendantes d’une seule clé principale impose des contraintes lors de la synchronisation d’entité mais il n’est pas difficile à mettre en place.

La première idée serait de protéger les mots de passe des clés secondaires avec la clé primaire. Mais cette clé primaire a avant tout le rôle d’authentification, elle ne doit donc pas servir à faire du chiffrement.

La seconde idée consiste à dériver (PBKDF) les mots de passe des clé secondaires du mot de passe de déverrouillage de la clé primaire. Ainsi la clé primaire ne sert qu’à l’authentification. Cela implique aussi que la modification du mot de passe de la clé primaire force le changement de mot de passe de toutes les clés secondaires associées.

La dérivation des mots de passe peut prendre en compte la partie publique de la clé primaire et de la clé secondaire concernée. Elle peut aussi prendre en compte, en plus, l’ID dans nebule du rôle associé. Une implémentation complète devra être proposée.