Architecture, cryptographie, modèle de menace

Architecture générale

Séparation stricte des rôles pour minimiser la surface d'attaque et isoler les secrets :

• Front statique — Astro + Tailwind CSS, build-time, servi via Traefik en France.
• API applicative — TypeScript / Node.js, TLS 1.3 strict, HSTS, CSP stricte.
• Stockage objet — Cloudflare R2 (région UE), upload en chunks, URLs signées avec expiration courte.
• Base de données — MongoDB Atlas (région UE), métadonnées de compte, carnet d'adresses, journaux.
• Compute — Scaleway (France).
• Identité — LoginWith pour l'auth, SSO SAML/OIDC pour l'offre Professionnel.
• Canaux de notification — Twilio (SMS + SendGrid pour l'email transactionnel), UE.
• Observabilité — Sentry pour les erreurs techniques (anonymisé), Matomo auto-hébergé (cookieless) pour l'usage agrégé.

Cryptographie

Schéma hybride classique : chaque document est chiffré avec sa propre clé symétrique, elle-même wrappée sous la clé publique RSA du ou des destinataires. Le serveur ne manipule jamais que des octets chiffrés.

Clés côté endpoint

• À la création du compte, le navigateur génère une paire de clés RSA-4096 (OAEP, SHA-256) via l'API Web Crypto.
• La clé privée reste sur l'appareil, stockée chiffrée dans IndexedDB et liée à la session authentifiée. Elle n'est jamais transmise au serveur.
• Seule la clé publique est enregistrée côté serveur (annuaire des clés publiques de la structure).

Chiffrement d'un document (envoi)

1. Le navigateur génère une clé symétrique aléatoire AES-256 propre au document — la KEK (Key Encryption Key).
2. Le document est découpé en chunks de 4 Mo, chacun chiffré en AES-256-GCM (nonce aléatoire 96 bits, tag 128 bits).
3. Un HMAC-SHA256 global sur l'ordre + les hashes des chunks scelle l'intégrité du document entier.
4. Pour chaque destinataire autorisé dont la clé publique est déjà connue, la KEK est wrappée en RSA-OAEP avec cette clé publique. Une KEK wrappée par destinataire est stockée à côté du document chiffré. Voir la section « Protocole d'échange » pour le cas d'un destinataire qui n'a pas encore de clé publique (première remise externe).
5. Les chunks chiffrés partent vers Cloudflare R2 ; le serveur ne voit que des octets opaques et la liste des clés wrappées.

Déchiffrement (réception)

1. Le destinataire passe la double vérification email + SMS (voir section suivante).
2. Le serveur lui envoie les chunks chiffrés et la clé wrappée qui lui est destinée.
3. Son navigateur unwrappe la KEK avec sa clé privée RSA locale.
4. Les chunks sont déchiffrés côté client en AES-256-GCM.

Transport

TLS 1.3 uniquement, HSTS strict, CSP stricte. Les octets en vol sont doublement protégés : TLS sur le réseau, AES-256-GCM au niveau applicatif. Compromettre TLS ne donne accès qu'au contenu déjà chiffré.

Conséquence opérationnelle : perdre l'accès à l'endpoint (device wipe, désinstallation sans export) signifie perdre l'accès aux documents chiffrés dessus, puisque le serveur ne connaît pas la clé privée. Les fichiers originaux sur l'appareil de l'expéditeur ne sont pas affectés — seul le transfert serveur-stocké devient illisible. Le design zero-knowledge est à ce prix ; c'est aussi ce qui rend une réquisition serveur inutile.

Protocole d'échange

La distribution de la clé du document (ou KEK) dépend de l'état du destinataire. Deux scénarios.

Scénario A — Destinataire déjà dans votre carnet

Sa clé publique est présente dans l'annuaire de la structure :

1. Votre client récupère la clé publique du destinataire depuis l'annuaire.
2. Il wrappe la KEK directement en RSA-OAEP sous cette clé publique.
3. Le destinataire unwrappe avec sa clé privée locale, déchiffre le document. Fin.

Scénario B — Premier échange avec un destinataire externe

Il n'a pas encore de compte : aucune clé publique disponible. Le protocole introduit un temps de latence et requiert l'expéditeur ponctuellement en ligne pour un re-wrap.

1. Votre client génère la KEK, chiffre le document. La KEK est provisoirement wrappée sous votre propre clé publique (vous préservez l'accès).
2. Le serveur envoie une invitation par email au destinataire (lien signé).
3. Le destinataire ouvre le lien et passe la double vérification email + SMS (voir section suivante) — ce qui prouve qu'il contrôle bien les deux canaux.
4. Son navigateur génère sa paire de clés RSA-4096 via Web Crypto ; la clé privée reste sur son appareil.
5. Sa clé publique est poussée au serveur, qui notifie votre client (webhook côté session active, ou dès votre prochaine connexion).
6. Votre client unwrappe la KEK avec votre clé privée, la re-wrappe en RSA-OAEP sous la nouvelle clé publique du destinataire, uploade cette nouvelle clé wrappée.
7. Le destinataire récupère la KEK re-wrappée, la unwrappe avec sa clé privée locale, déchiffre les chunks.

Contrainte : le scénario B exige que l'expéditeur soit ponctuellement en ligne pour le re-wrap (étape 6). Le serveur ne peut pas s'en charger : il ne possède aucune clé privée. Pour les cas où cette latence est problématique (échange automatisé asynchrone), une délégation contrôlée via HSM chez un tiers de confiance est sur la feuille de route.

Protocole de double vérification

À chaque remise, deux canaux indépendants doivent être validés. La double vérification s'interpose aussi bien dans le scénario A (avant déchiffrement) que dans le scénario B (avant génération de la paire de clés destinataire).

1. Le destinataire reçoit le lien par email.
2. Il saisit l'email et le téléphone renseignés par l'expéditeur.
3. Le serveur génère deux codes à 6 chiffres distincts, chacun lié à un canal.
4. Le code A est envoyé par email, le code B par SMS.
5. Le destinataire saisit les deux codes dans l'interface. Vérification atomique ; expiration 10 minutes.
6. En cas de succès, soit il déchiffre immédiatement (scénario A), soit il entre dans la phase de génération de clés + re-wrap (scénario B).

La valeur du double canal : compromettre un seul (email OU téléphone) ne suffit pas. L'attaquant doit compromettre les deux simultanément.

Traçabilité (offre Professionnel)

Chaque événement d'accès génère une ligne de journal structurée :

timestamp      : 2026-04-23T10:14:37.412Z (UTC, nanoseconde)
event          : upload | download | view | failed-verify | revoke
actor          : user_id (expéditeur) ou external_id (destinataire)
network        : sha256(ip + salt), sha256(user_agent + salt)
document       : document_id, chunk_id, byte_range
outcome        : success | failure (reason)
attestation    : signature HMAC-SHA256 de la ligne, scellée par la
                 clé de journal de la structure

Conservation : 12 mois par défaut, export CSV / JSON signé à la demande du client, révocation d'une URL propagée sous 500 ms.

Modèle de menace

Conformité

• RGPD (Règlement UE 2016/679) — responsable et sous-traitant identifiés, DPO désigné (dpo@documents-securises.fr). DPA signé automatiquement avec tout client payant (voir /dpa).
• LCEN (loi 2004-575, article 6) — éditeur et hébergeur publics (voir mentions légales).
• Code civil (articles 1365-1368) — les éléments de preuve (journal horodaté, accusés de réception) sont recevables comme commencement de preuve par écrit.
• CNIL — mesure d'audience cookieless via Matomo auto-hébergé ; aucun transfert extra-UE hors clauses contractuelles types.

Non-certifié, volontairement

documents-securises.fr ne poursuit pas les qualifications lourdes (SecNumCloud, NF Z42-013, HDS) à ce stade. La cible est la structure à taille humaine qui veut du concret — E2E, double vérification, hébergement FR — sans le prix et les délais d'intégration d'une plateforme enterprise. Les clients qui requièrent une certification spécifique sont orientés, dans notre comparateur, vers Oodrive, NetExplorer ou Docaposte selon le besoin.

Disponibilité et opérations

• Objectif de disponibilité : 99,9 % (pas d'engagement contractuel à ce jour hors Enterprise sur devis).
• Sauvegardes chiffrées quotidiennes, rétention 30 jours, restauration testée trimestriellement.
• Procédure de réponse aux incidents documentée ; notification clients sous 72 h en cas d'incident de sécurité (article 33 RGPD).
• Rotation des secrets d'infrastructure gérée via Mozilla SOPS et clés KMS.

Feuille de route sécurité

• Horodatage qualifié eIDAS via un prestataire de services de confiance qualifié, pour les clients qui le demandent (en option).
• SCIM pour le provisioning automatisé Enterprise.
• Intégration Yousign pour les workflows impliquant une signature.
• Publication du premier rapport d'audit de sécurité externe (prévu dans les 12 mois).