Logo

Chapitre 2 Modèle de menace et limites de confiance

Ce chapitre établit un modèle de menace partagé et un vocabulaire de limites de confiance : quels actifs nous protégeons, ce que les attaquants peuvent faire, quelles hypothèses doivent être vérifiées et comment le système DOIT échouer en cas d'authentification ou de non-concordance de paramètres.

Métadonnées du document

Version livre blanc
v1.0
Dernière mise à jour
2026-01-14

2.1 Inventaire des actifs

  • Confidentialité du contenu : les octets du fichier en texte clair 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 être inviolables (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.
  • Availability: possibilité de télécharger et de reprendre les transferts dans des conditions de réseau courantes.

2.2 Modèle d'attaquant

  • Attaquant de réseau : peut observer, retarder, abandonner et rejouer le trafic ; ne peut pas briser la cryptographie TLS/AEAD moderne.
  • Attaquant Web : peut créer des liens malveillants, essayer XSS/CSRF et tenter une injection d'interface utilisateur/d'invite.
  • Acteur d'abus : peut automatiser les téléchargements/téléchargements pour épuiser les quotas, supprimer le contenu ou amplifier le trafic.
  • L'adversaire côté serveur est supposé ne pas avoir le CEK ; si le CEK est divulgué (par exemple, lien partagé), la confidentialité est perdue de par sa conception.

2.3 Hypothèses de sécurité

  • Les clients exécutent du code fiable (pas d'extensions/logiciels malveillants) ; sinon, la connaissance nulle ne peut pas protéger le point final.
  • Fragments d'URL (#...) ne sont pas transmis au serveur via des requêtes HTTP dans le comportement standard du navigateur.
  • Les primitives cryptographiques (AES-GCM, SHA-256, TLS) sont utilisées correctement et ne sont pas cassées.

2.4 Limites de confiance

  • Limite du client : le cryptage/déchiffrement et la gestion des CEK se produisent uniquement dans le client.
  • Limite Edge/API : le serveur valide les jetons et sert le texte chiffré/manifeste ; NE DOIT PAS apprendre le CEK.
  • Limite de stockage d'objets : stocke des morceaux de texte chiffré et des manifestes ; traité comme non fiable pour des raisons de confidentialité.

2.5 Principe de fermeture en cas de panne

  • En cas d'échec du jeton, de non-concordance des paramètres ou d'échec de l'authentification AEAD, le système DOIT échouer en fermeture.
  • NE DOIT PAS afficher un texte en clair partiel lorsque les contrôles d'intégrité échouent.
  • Les messages d'erreur et les journaux DEVRAIENT minimiser les données sensibles et NE DOIVENT PAS inclure de fragments d'URL, de CEK ou de matériaux dérivés.