Dépôt zero-knowledge par QR code et échange éphémère

2.1 Objectifs de sécurité

• Confidentialité : seul le destinataire peut déchiffrer les fichiers.
• Intégrité : toute altération est détectable.
• Authenticité : le client chiffre effectivement vers le destinataire prévu.
• Isolation : chaque soumission est cryptographiquement indépendante des autres.
• Confidentialité persistante (optionnelle) : une compromission future des clés ne révèle pas les dépôts passés.

2.2 Objectifs d'ergonomie

• aucune création de compte ;
• parcours en un seul scan de QR code ;
• dépôts multi-fichiers au sein d'une session ;
• serveur stateless ou à état minimal.

3.1 Acteurs

• Destinataire (p. ex. avocat, notaire) : détenteur d'une clé d'identité à long terme.
• Client (déposant) : expéditeur anonyme, non authentifié.
• Serveur : couche de stockage et de routage, supposée zero-knowledge.

3.2 Modèle de confiance

• Serveur : honnête-mais-curieux.
• Réseau : non fiable.
• Distribution du QR code : de confiance ou vérifiable.

5.1 Initialisation (destinataire)

Le destinataire génère une paire de clés d'identité à long terme :

IK_sign_sk, IK_sign_pk   // Ed25519

Pour chaque session, il génère une paire de clés de chiffrement éphémère, un identifiant de session aléatoire et signe les métadonnées :

EK_sk, EK_pk             // X25519, éphémère
session_id               // 128 bits aléatoires
{
  "session_id": "...",
  "ek_pk": "...",
  "expires_at": "...",
  "signature": Sign(IK_sign_sk, ek_pk || session_id || expires_at)
}

Cette charge utile est servie via HTTPS ou encodée dans le QR code affiché au cabinet.

5.2 Flux côté client

Après lecture du QR code, le navigateur du client exécute les étapes suivantes.

Étape 1 — Vérification

• vérifier la signature avec IK_sign_pk ;
• vérifier l'expiration.

Étape 2 — Chiffrement du fichier

DEK = random(32 bytes)
ciphertext = AEAD(DEK, file)

Étape 3 — Encapsulation de la DEK

es_sk, es_pk = keygen(X25519)             // clé éphémère de l'expéditeur
ss = X25519(es_sk, EK_pk)                 // secret partagé
wrap_key = HKDF(ss, info="file-dek-wrap")
wrapped_dek = AEAD(wrap_key, DEK)

Étape 4 — Téléversement

{
  "session_id": "...",
  "es_pk": "...",
  "file_ciphertext": "...",
  "wrapped_dek": "...",
  "nonces": { ... },
  "aad":    { ... }
}

5.3 Flux côté destinataire

Pour chaque dépôt :

ss = X25519(EK_sk, es_pk)
wrap_key = HKDF(ss, info="file-dek-wrap")
DEK = AEAD_open(wrap_key, wrapped_dek)
plaintext = AEAD_open(DEK, file_ciphertext)

6.1 Identifiant de session

• valeur aléatoire sur 128 bits ;
• incluse dans la charge signée ;
• sert de clé de regroupement des dépôts.

6.2 Propriétés

• non secrète ;
• doit être authentifiée (signature ou associated data de l'AEAD) ;
• permet un regroupement UI sans compromettre la confidentialité des dépôts.

Annexe A — Terminologie

• DEK — Data Encryption Key.
• AEAD — Authenticated Encryption with Associated Data.
• E2EE — End-to-End Encryption.
• Tous les termes sont également définis dans le glossaire.

Annexe B — Stack de référence

• X25519 pour l'échange de clés.
• Ed25519 pour les signatures.
• HKDF-SHA256 pour la dérivation.
• AES-256-GCM ou ChaCha20-Poly1305 pour le chiffrement authentifié.