Chiffrement cote client d abord
Les messages sont chiffres dans le navigateur avec Web Crypto (AES-GCM). Le serveur ne stocke que le texte chiffre et les metadonnees.
Modele de securite EncSend
Cette page decrit l implementation actuelle : quelles donnees sont chiffrees cote client, comment les liens et les cles sont traites, quels controles d acces sont actifs et ou se situent les limites du modele.
Cles dans les fragments d URL
Les cles de dechiffrement sont transportees dans des fragments d URL comme #k ou #rk et ne sont pas envoyees au serveur.
Couche de mot de passe facultative
Les liens proteges par mot de passe utilisent des hachages cote serveur plus un wrapping de cle cote client base sur PBKDF2-SHA-256.
Controles de duree de vie
Les expirations, limites d ouverture ou de soumission et politiques de lecture unique limitent l acces aux contenus sensibles.
Flux de donnees : envoi d un secret
- Le navigateur genere un materiel de cle de lien sur 256 bits.
- Le message est chiffre avec une cle de charge utile aleatoire via AES-GCM.
- La cle de charge utile est wrappee avec une cle derivee de la cle de lien via HKDF-SHA-256.
- En option, cette cle wrappee est de nouveau chiffree par une couche basee sur mot de passe (PBKDF2-SHA-256).
- Le serveur ne stocke que
encrypted_payload,encrypted_key, les metadonnees cryptographiques et les champs de politique d acces. - Apres dechiffrement local reussi, le client confirme la lecture ; avec la lecture unique, le secret est ensuite marque comme detruit.
Flux de donnees : demande de message securise
- Le proprietaire genere une URL de demande avec un jeton public aleatoire.
- Les expediteurs externes chiffrent localement dans le navigateur avec le materiel de cle fourni par le fragment d URL.
- Le serveur stocke les soumissions comme texte chiffre et applique les limites de soumission et les expirations.
- Le proprietaire lit les soumissions via un dechiffrement local ; le texte en clair n est pas traite cote serveur.
- Pour une lecture multi-appareils, la cle de demande peut en plus etre stockee comme artefact owner-wrapped.
Controle d acces et resistance aux abus
Les jetons d acces publics sont generes aleatoirement, stockes uniquement sous forme de hachages SHA-256 en base de donnees et verifies via hash_equals.
Les mots de passe de lien ne sont jamais stockes en clair et sont verifies contre des hachages cote serveur. Les sessions de mot de passe des liens publics sont limitees dans le temps et configurables.
Des limitations de debit sont actives sur les points critiques, notamment les verifications de mot de passe, les soumissions publiques, la connexion et les flux de verification.
Les operations cote proprietaire sont protegees par l authentification, l etat d e-mail verifie et des politiques d autorisation ; les modifications sensibles de recuperation exigent une confirmation recente du mot de passe.
Recuperation proprietaire et coffre de cles
EncSend fournit des artefacts de recuperation chiffres optionnels pour les scenarios multi-appareils :
- Profil crypto proprietaire : cle maitre chiffree (AES-GCM), basee sur une phrase secrete avec PBKDF2-SHA-256.
- Coffre de cles utilisateur : sauvegarde chiffree des cles de secret et de demande detenues localement.
- Cles de demande owner-wrapped par demande et cles de secret owner-wrapped par secret ; les lots de rotation de cles de demande prennent en charge les tentatives de reprise.
Audit et tracabilite
Les actions liees a la securite sont journalisees, par exemple l emission de lien, les acces refuses, les etapes de challenge par mot de passe, la creation de soumission et les mises a jour de recuperation.
- Les tables d evenements d acces conservent le type d evenement, l horodatage, l agent utilisateur et les metadonnees de contexte.
- Les journaux d audit sont consultables par les utilisateurs finaux (leurs propres evenements) et par les administrateurs (vue globale).
- Une migration dediee supprime les colonnes d adresse IP des tables de session et d evenements.
Limites importantes du modele
- La securite du navigateur reste critique : les cles locales sont mises en cache dans le stockage du navigateur et exigent un environnement client durci.
- JavaScript et Web Crypto sont obligatoires pour les flux de creation et de dechiffrement local securises.
- La securite du transport (HTTPS, durcissement du reverse proxy, politique TLS) doit etre appliquee au niveau de l infrastructure.
- Le hachage des mots de passe protege le stockage cote serveur mais ne remplace pas des mots de passe robustes.