Partez du principe que les serveurs sont compromis

Avant même qu'une entrée n'arrive dans le store, sa charge utile est chiffrée avec une clé symétrique (AES-256-GCM). Ce chiffrement fait partie du modèle de données, pas du transport. Le serveur qui stocke les entrées ne peut pas lire leur contenu — il ne voit que des octets chiffrés.

Quand le serveur répond à une demande de synchronisation, il enveloppe les charges utiles des entrées dans une couche de chiffrement RSA supplémentaire, avec la clé publique de l'utilisateur qui demande. Même en interceptant la réponse HTTP, on ne peut pas la déchiffrer sans la clé RSA privée du destinataire.

Toute la communication passe par TLS. Cela protège les métadonnées (identifiants d'entrées, horodatages, paramètres de requête) que les couches de charge utile ne couvrent pas. Ensemble, les trois couches assurent une protection complète des données : au repos, en transit et sur le réseau.

Tous les documents sont chiffrés avec la clé AES-256 par défaut du tenant, sauf si une autre clé est indiquée. Chaque utilisateur enregistré reçoit cette clé à son intégration. À utiliser pour les données générales du tenant.

Pour les documents sensibles, créez une clé de chiffrement nommée et ne la partagez qu'avec les utilisateurs autorisés. Les clés voyagent hors ligne (la clé chiffrée par e-mail, le mot de passe par téléphone ou en personne) ou à l'aveugle pour l'admin via une politique : un utilisateur qui détient la clé l'encapsule pour chaque destinataire avec sa clé publique (RSA), si bien qu'un admin peut la distribuer sans jamais la lire. Seuls les utilisateurs qui détiennent la clé peuvent déchiffrer.

Une clé spéciale qui ne chiffre que les entrées de contrôle d'accès de l'annuaire (enregistrements d'utilisateurs, révocations, groupes). Les serveurs s'en servent pour vérifier quelles clés de signature sont dignes de confiance — sans voir les noms d'utilisateur ni les données métier. Les noms d'utilisateur sont stockés sous forme de hachages SHA-256 ; les vrais noms sont chiffrés avec la clé RSA de l'admin.

Chaque session de synchronisation commence par une poignée de main défi-réponse :

• Le client envoie sa clé de signature publique au serveur
• Le serveur cherche la clé dans l'annuaire et envoie un défi aléatoire
• Le client signe le défi avec sa clé privée
• Le serveur vérifie la signature, contrôle l'état de révocation et délivre un JWT à courte durée de vie

Aucun mot de passe, aucune base de sessions sur le serveur. Un utilisateur révoqué ne peut même pas entamer le flux d'authentification.

Les nouveaux utilisateurs arrivent par une poignée de main en trois étapes, où les clés privées ne quittent jamais l'appareil :

• Demande d'adhésion — Le nouvel utilisateur génère ses clés en local et crée une demande qui ne contient que des clés publiques. Elle se partage sans risque par n'importe quel canal.
• Approbation par l'admin — L'admin enregistre l'utilisateur dans l'annuaire et chiffre les clés symétriques avec un mot de passe de partage à usage unique.
• Échange par canaux séparés — La réponse d'adhésion part par e-mail ou messagerie ; le mot de passe de partage est transmis à part, par téléphone ou en personne.

• Signature : Ed25519 (sécurité de 128 bits, courbe elliptique)
• Chiffrement de la charge utile : AES-256-GCM (sécurité de 256 bits)
• Chiffrement du transport : RSA-OAEP avec SHA-256 (clés de 3072 bits)
• Dérivation de clés : PBKDF2 avec un sel propre à chaque type de clé
• Signature des tokens : HMAC-SHA256
• Hachage : SHA-256 (adressage par contenu, protection des noms d'utilisateur)

• Confidentialité : chiffrement AES-256-GCM — seuls les détenteurs de la clé peuvent lire
• Authenticité : signatures Ed25519 — prouvent qui a créé chaque modification
• Intégrité : chaînage par empreintes — une manipulation rompt la chaîne et se détecte en tout point
• Non-répudiation : les signatures sont infalsifiables — l'auteur est prouvable
• Vie privée : noms d'utilisateur hachés et chiffrés — le serveur ne peut pas identifier les utilisateurs

• Compromission du serveur — L'attaquant n'obtient que du texte chiffré et des clés publiques. Aucun clair, aucune clé privée, aucun nom d'utilisateur.
• Interception réseau — Trois couches de chiffrement protègent les données même si TLS est compromis.
• Modifications non autorisées — Chaque modification est signée ; celles qui ne le sont pas, ou mal, sont rejetées.
• Manipulation — Le chaînage par empreintes rend toute altération détectable.
• Accès d'un utilisateur révoqué — La révocation s'applique au défi comme à la validation du token ; elle bloque la synchronisation immédiatement.
• Écoute au relais — Les nœuds relais stockent et transmettent des entrées chiffrées qu'ils ne peuvent pas déchiffrer.

Le contenu de la charge utile est toujours chiffré, mais certaines métadonnées sont visibles par le serveur, par conception. C'est un compromis délibéré : le protocole de synchronisation a besoin de métadonnées pour rapprocher les entrées.

• Visible : horodatages des entrées, empreintes de contenu, structure des documents (combien d'entrées par document), habitudes d'accès (quand les utilisateurs se synchronisent)
• Non visible : contenu des documents, noms d'utilisateur, clés de chiffrement, contenu des pièces jointes

Les empreintes de contenu révèlent quand deux entrées contiennent des données chiffrées identiques (pour la déduplication). C'est un compromis accepté au profit de l'efficacité du stockage.

Révoquer un utilisateur bloque toute synchronisation ultérieure et rejette ses futures modifications. En revanche, les données déjà synchronisées sur son appareil restent accessibles — aucun système ne peut garantir la suppression sur un appareil qui ne se reconnecte jamais. Atténuation : utiliser des clés nommées pour les documents sensibles (rayon d'impact plus réduit), faire tourner les clés au départ d'un utilisateur. Haven Enterprise ajoute aux mêmes politiques de gouvernance un effacement à distance signé par l'admin : le tenant est retiré d'un appareil volé ou rendu dès sa prochaine connexion.

Plusieurs clés par utilisateur (signature, chiffrement, clés symétriques nommées) doivent être distribuées en toute sécurité. Atténuation : un seul mot de passe déverrouille toutes les clés, via PBKDF2 avec des sels différents. Le KeyBag offre un stockage de clés unifié. Le flux demande/réponse d'adhésion prend en charge l'échange de clés pour les nouveaux utilisateurs. Haven Enterprise automatise le travail courant : des politiques de distribution de clés signées par l'admin approvisionnent utilisateurs et groupes en clés — et les révoquent à nouveau —, chacune encapsulée par destinataire, et chaque client réconcilie son KeyBag à la synchronisation suivante.

Par défaut, le serveur ne peut pas interroger le contenu des documents, puisqu'il ne voit que du texte chiffré. Toute interrogation se fait côté client, par indexation incrémentale. Si votre cas d'usage demande un traitement côté serveur (un système de réservation en ligne, un site public), vous pouvez donner une clé de déchiffrement au processus serveur ou ne partager avec lui qu'un sous-ensemble des données. C'est un choix d'architecture conscient, propre à chaque déploiement — la confidentialité par défaut, l'accès serveur seulement là où vous l'activez.

Un audit de sécurité complet a identifié des points à durcir : limitation de débit sur les points de terminaison, révocation des tokens JWT et rotation de la clé d'admin. Les modifications antidatées par des utilisateurs révoqués sont désormais empêchées par les reçus de témoin à temps de confiance (voir le modèle de contrôle d'accès). Les fondations cryptographiques (Ed25519, AES-256-GCM, RSA-OAEP) sont solides. Le durcissement opérationnel est en cours.