Chapitre 2 Modèle de menace et limites de confiance

Métadonnées du document

Version du livre blanc

v1.0

Dernière mise à jour

2026-01-14

2.1 Inventaire des actifs

• Confidentialité du contenu : les octets en clair des fichiers et les clés de déchiffrement (CEK) DOIVENT être protégés.
• Intégrité du contenu : le texte chiffré et les métadonnées DOIVENT permettre de détecter toute altération (authentification AEAD).
• Contrôle d'accès : jetons d’accès de courte durée, jetons de connexion de l’expéditeur et état de révocation.
• Disponibilité : possibilité d’envoyer, de télécharger et de reprendre des transferts dans des conditions réseau courantes.

2.2 Modèle d'attaquant

• Attaquant de réseau : peut observer, retarder, abandonner et rejouer le trafic ; ne peut pas casser la cryptographie moderne TLS/AEAD.
• Attaquant Web : peut fabriquer des liens malveillants, tenter des attaques XSS/CSRF et essayer une injection dans l’interface ou une injection de prompt.
• Acteur malveillant (abus) : peut automatiser les envois et les téléchargements pour épuiser les quotas, aspirer le contenu (scraping) ou amplifier le trafic.
• L’adversaire côté serveur est supposé ne pas disposer de la CEK ; si la CEK est divulguée (par exemple, parce que le lien est partagé), la confidentialité est perdue par conception.

2.3 Hypothèses de sécurité

• Les clients exécutent du code de confiance (ni extensions malveillantes ni logiciels malveillants) ; sinon, la connaissance nulle ne peut pas protéger le poste client.
• Les fragments d’URL (#...) ne sont pas transmis au serveur dans les requêtes HTTP, selon le comportement standard des navigateurs.
• Les primitives cryptographiques (AES-GCM, SHA-256, TLS) sont utilisées correctement et ne sont pas compromises.

2.4 Limites de confiance

• Limite du client : le chiffrement, le déchiffrement et la gestion de la CEK ont lieu uniquement dans le client.
• Limite Edge/API : le serveur valide les jetons et sert le texte chiffré et le manifeste ; NE DOIT PAS connaître la CEK.
• Limite de stockage d'objets : stocke des blocs de texte chiffré et des manifestes ; considéré comme non fiable en matière de confidentialité.

2.5 Principe d’échec en mode fermé (fail-closed)

• En cas d’échec de validation du jeton, de paramètres non concordants ou d’échec de l’authentification AEAD, le système DOIT échouer en mode fermé.
• NE DOIT PAS produire de texte en clair partiel lorsque les contrôles d’intégrité échouent.
• Les messages d'erreur et les journaux DEVRAIENT limiter au minimum les données sensibles et NE DOIVENT PAS inclure de fragments d’URL, de CEK ni d’éléments permettant de la dériver.