1. Cryptographie côté client
Les messages sont chiffrés dans le navigateur à l’aide de Web Crypto (AES-GCM). Le serveur stocke le texte chiffré et les métadonnées.
Modèle de sécurité EncSend
Cette page décrit l’implémentation actuelle : quelles données sont chiffrées côté client, comment les liens et les clés sont gérés, quels contrôles d’accès sont actifs et où se situent les limites du modèle.
2. Clés dans les fragments d’URL
Les clés de déchiffrement sont transportées dans des fragments d’URL tels que #k ou #rk et ne sont pas envoyés au serveur.
3. Couche de mot de passe optionnelle
Les liens protégés par mot de passe utilisent des hachages de mot de passe côté serveur ainsi qu’un encapsulage de clé supplémentaire côté client (PBKDF2-SHA-256).
4. Contrôles de durée de vie
L’expiration, les limites de consultation/soumission et les politiques de lecture unique restreignent l’accès aux contenus sensibles.
Flux de données : envoi de secret
- 1. Le navigateur génère un matériel de clé de lien de 256 bits.
- 2. Le message est chiffré avec une clé de charge utile aléatoire via AES-GCM.
- 3. La clé de charge utile est encapsulée avec une clé HKDF-SHA-256 dérivée de la clé de lien.
- 4. En option, cette clé encapsulée est en plus chiffrée avec une couche basée sur un mot de passe (PBKDF2-SHA-256).
- 5. Le serveur stocke uniquement
encrypted_payload,encrypted_key, métadonnées cryptographiques et champs de politique d’accès. - 6. Après un déchiffrement local réussi, le client confirme une consultation ; avec la lecture unique, le secret est ensuite marqué comme détruit.
Flux de données : demande de message sécurisé
- 1. Le propriétaire génère une URL de requête avec un jeton public aléatoire.
- 2. Les expéditeurs externes chiffrent localement dans le navigateur à l’aide du matériel de clé de requête provenant du fragment d’URL.
- 3. Le serveur stocke les soumissions sous forme de texte chiffré et applique les limites de soumission et l’expiration.
- 4. Le propriétaire lit les soumissions par déchiffrement local ; le texte en clair n’est pas traité côté serveur.
- 5. Pour une lecture multi-appareils, la clé de requête peut en outre être stockée comme artefact chiffré par le propriétaire.
Contrôle d’accès et résistance aux abus
Les jetons d’accès public sont générés aléatoirement, stockés uniquement sous forme de hachages SHA-256 dans la base de données et validés via
hash_equals.
Les mots de passe des liens ne sont jamais stockés en clair et sont vérifiés par rapport à des hachages côté serveur. Les sessions par mot de passe pour les liens publics sont limitées dans le temps (120 minutes par défaut).
La limitation de débit est active pour les points d’accès critiques, y compris les vérifications de mot de passe, les soumissions publiques, la connexion et les flux de vérification.
Les opérations côté propriétaire sont protégées par l’authentification, l’état d’e-mail vérifié et des politiques d’autorisation ; les modifications sensibles de récupération nécessitent une confirmation récente du mot de passe.
Récupération du propriétaire et coffre de clés
EncSend fournit des artefacts de récupération chiffrés optionnels pour les scénarios multi-appareils :
- Profil cryptographique du propriétaire : clé maître chiffrée (AES-GCM), basée sur une phrase secrète (PBKDF2-SHA-256).
- Coffre de clés utilisateur : sauvegarde chiffrée des clés de secret/requête détenues localement.
- Clés de requête chiffrées par le propriétaire pour chaque requête, y compris des lots de rotation reprenables avec prise en charge des nouvelles tentatives.
Audit et traçabilité
Les actions pertinentes pour la sécurité sont journalisées (par exemple émission de lien, accès refusé, étapes de vérification du mot de passe, création de soumission et mises à jour de récupération).
- Les tables d’événements d’accès stockent le type d’événement, l’horodatage, l’agent utilisateur et les métadonnées contextuelles.
- Journaux d’audit des événements importants.
- Une migration dédiée supprime les colonnes d'adresse IP des tables liées aux sessions et aux événements.
Limites importantes du modèle
- La sécurité du navigateur reste critique : les clés locales sont mises en cache dans le stockage du navigateur et nécessitent un environnement client renforcé.
- JavaScript et Web Crypto sont obligatoires pour les flux de création sécurisée et de déchiffrement local.
- La sécurité du transport (HTTPS, durcissement du proxy inverse, politique TLS) doit être appliquée au niveau de l'infrastructure.
- Le hachage des mots de passe protège le stockage côté serveur, mais ne remplace pas le choix de mots de passe robustes.