Protocole de messagerie sécurisé

R&D
1

Pour faire suite aux idées développées dans un autre fil, voici un début de protocole permettant de chiffrer les messages. Je le propose au moins pour la messagerie privée. Pour les commentaires de tx ça reste à discuter.

Le dépôt contient la description formelle du protocole et une implémentation Rust.

Il est adapté au stockage en datapod. Il reste à définir les métadonnées nécessaires pour adresser et retrouver un message (e.g. par clé publique de destinataire et identifiant de conversation ou de bloc et d’extrinsic).

Il faut stocker quelque part un état secret (clés privées nécessaires au chiffrement/déchiffrement des futurs messages). Ça peut être chiffré sur un serveur public centralisé ou un datapod, ou en local (dans ce cas la conversation est accessible uniquement sur cet appareil).

Le premier message envoyé entre deux comptes contient obligatoirement pas mal de métadonnées cryptographiques (même si le message est en clair) pour permettre au destinataire de répondre de manière sécurisée, mais les messages suivants n’en contiennent pas s’ils sont en clair.

Côté UI

J’ai essayé de rendre le protocole simple à utiliser et à intégrer dans une UI compréhensible.

Envoyer un premier message

Vous envoyez un message à un compte qui ne vous en a encore jamais envoyé, ou qui ne vous fait pas confiance.

  • Voulez-vous chiffrer le message ? Le destinataire pourra choisir de le rendre public de manière irrécusable.

Recevoir un message

Vous avez reçu un message.

  • Le mode de sécurité de ce message est parmi :
    • Public : Google peut le lire.
    • Privé : seul vous pouvez le lire.
    • Privé irrécusable : seul vous pouvez le lire, mais vous pouvez le signaler publiquement.
  • Bouton “Signaler ce message” (si le mode de sécurité est Privé, un humain doit évaluer la bonne foi du signalement)
  • Bouton “Empêcher ce compte de m’envoyer des messages privés sauf si irrécusables” (il faudrait trouver une meilleure formulation)

Envoyer un message

Vous envoyez un message à un compte qui vous en a déjà envoyé.

  • Voulez-vous chiffrer le message ? Le destinataire pourra choisir de le rendre public de manière irrécusable.
    • Si oui, voulez-vous le rendre irrécusable ?

Pourquoi si compliqué (forward secrecy)

C’est nécessaire si on veut que les messages restent confidentiels même en cas de fuite de la clé privée (c’est la forward secrecy). En supprimant les clés temporaires, on exerce un droit à l’oubli potentiellement inviolable.

Commentaires de transaction

Ce protocole peut aussi servir aux commentaires de transaction, mais l’obligation de messages bidirectionnels pour profiter de la forward secrecy est contraignante. En recevant un commentaire de transaction, il faut pouvoir faire les actions listées ci-dessus.

Il faut voir comment indexer les commentaires pour pouvoir répondre à un commentaire et établir une conversation sécurisée, même si les transactions sont unidirectionnelles.

On peut aussi unifier les commentaires et les messages (un commentaire étant un message indexé à un extrinsic).

Si c’est trop contraignant, on peut abandonner la forward secrecy et garder l’irrécusabilité obligatoire. Ainsi il n’y aurait plus d’état à stocker.

2 Likes
2

Ce protocole permet il les fonctions indispensables pour une messagerie soit:

  • Accusé de réception
  • Accusé de lecture
  • Conversation de groupe
  • réponse à un message cité
  • thread de message
  • réaction emoji

?

3

Il se place entre les couches applicatives (messagerie) et de transport (par exemple datapod). On peut ajouter des métadonnées dans la payload pour les accusés de réception, réactions, enregistrements vocaux, commandes shell… Ça reste à définir.

Par contre c’est du 1v1, ça ne fonctionne pas pour les groupes. Je peux essayer de voir comment faire mais ce sera forcément beaucoup plus compliqué si on veut du chiffrement avec forward secrecy. (regarde Matrix, les groupes chiffrés c’est déjà galère)

En fait ça permet de sécuriser n’importe quel protocole entre deux personnes, un peu comme du TLS à forte latence et à longues sessions, en facilitant la mise en place d’antispam et de signalement/modération.

4

Signal passe au post-quantique ! Pour plus tard ce sera intéressant à ajouter au protocole.

Signal >> Blog >> Quantum Resistance and the Signal Protocol

1 Like
5

J’ai beaucoup repensé à la question de la messagerie sécurisée. À la fois je suis enthousiaste pour ce super protocole de chiffrement, à la fois je pense que c’est inadapté à une infrastructure publique, notamment à cause de la question des métadonnées.

Personnellement je suis gêné par l’aspect métadonnées publiques. Je trouve que savoir publiquement quelle clé a communiqué avec quelle autre à quel moment révèle déjà trop d’information. On pourrait mitiger ça avec des clés plus difficiles à associer à l’identité, mais ça nécessite une réflexion supplémentaire, et ça ne protège pas contre des attaques par dés-anonymisation ciblées. Je pense que le cas de la messagerie sécurisée nécessite des tiers de confiance qui soient les seuls à accéder aux métadonnées.

1 Like
6

Je suis d’accord. Je vais voir si on peut améliorer ça cryptographiquement (peut-être voir comment les hidden services de Tor, Tox et Ricochet fonctionnent), sinon dans IPFS en ajoutant de l’authentification (le nœud auquel est soumis le message ne le relaie qu’au destinataire).

Seul le premier message est difficile à transmettre anonymement (le destinataire doit trouver le message facilement, et le datapod doit pouvoir appliquer son antispam). Pour la suite de la conversation on a des secrets partagés qui peuvent servir de “point de rendez-vous” dans IPFS, et les métadonnées peuvent être chiffrées.

Mais c’est déjà beaucoup mieux que tout en clair, et si on veut de l’anonymat on peut utiliser des comptes dérivés (ce qui obligerait à adapter le protocole pour que la signature interne soit faite par la clé membre et non la clé dérivée).

1 Like
7

Pour la question des metadata il peut être intéressant de regarder comment cwtch adresse ce problème. (Cwtch Security Handbook | Cwtch)

Pour l’antispam il doit y avoir moyen d’implémenter une PoW pour limiter l’envoie en masse de message dont la difficulté pourrais progressivement augmenté avec le nombre de message envoyée sur une courte période.

2 Likes
8

Le but étant d’ajouter le moins de couches possible, j’aimerais éviter de devoir ajouter un protocole en oignons (autre que Tor ou autre solution générique clé-en-main pour wrapper les connexions vers les datapods). D’après Tor Project | How do Onion Services work?, les hidden services n’utilisent pas de crypto magique pour l’adresse de rendez-vous, c’est juste l’utilisation de relais en masse.

Pour envoyer un message depuis une clé anonyme tout en gardant la possibilité d’un antispam basé sur les identités, on pourrait créer des clés déléguées opaques grâce aux signatures en anneau, en étendant le mécanisme de transactions anonymes.

Ainsi quand une clé veut envoyer un message, on peut vérifier qu’elle appartient bien à une identité (sans savoir laquelle), et le taux de création de clés déléguées opaques par identité peut être limité.

Le premier message peut être envoyé sur une adresse publiquement associée au destinataire. Le scan des messages reçus est alors simple. On sait juste qui a reçu un message, mais pas de qui.

Le double-ratchet utilisant déjà des secrets partagés, dès le deuxième message on peut dériver de ces secrets une adresse de rendez-vous, qui changera à chaque échange dans la conversation.

Si on veut empêcher un observateur extérieur de savoir que plusieurs messages sont dans une même conversation, on peut changer de clé déléguée opaque à chaque échange, mais le processus de signature en anneau risque de devenir un facteur limitant (c’est très coûteux à signer et à vérifier, et il faut beaucoup de participants pour avoir un bon anonymat).

Si on veut pouvoir utiliser moins de clés déléguées onchain, on peut ajouter aux datapods une sorte d’authentification fédérée : un datapod qui accepte de pinner des messages provenant de clés qu’il connaît offchain. Soit on fait confiance en l’admin de son datapod, soit le datapod a ses propres rounds de signature en anneau offchain.