Livre blanc sur la sécurité et la confidentialité (présentation)Annexe
Annexe : index des identifiants d'affirmation (source unique de vérité)
Cette annexe est la source unique de vérité pour tous les identifiants d’affirmation du livre blanc. Chaque affirmation possède un identifiant et une ancre uniques et stables, et est présentée sur une seule ligne avec un Énoncé et une Preuve. Les preuves renvoient uniquement à des références faisant autorité, vérifiables de manière reproductible (ancres de chapitre ou points d’entrée de la page d’état ou de rapports tiers), et ne renvoient jamais à des captures d’écran ni à du contenu réhébergé.
Règles de maintenance
- DOIT : les identifiants d’affirmation sont uniques et stables ; une fois publiés, ils ne sont jamais réutilisés.
- DOIT : les preuves de chaque affirmation doivent être vérifiables de manière reproductible (ancres de chapitre ou points d’entrée tiers faisant autorité).
- DOIT : les énoncés doivent affirmer uniquement ce que les preuves étayent ; évitez le langage de « sécurité absolue ».
- DEVRAIT : lorsque des changements de mise en œuvre ou de politique affectent une affirmation, consignez-le dans le journal des modifications et liez les identifiants d’affirmation concernés.
Chapitres 1 à 4 (périmètre, modèle de menace, architecture, autorisation)
SCOPE-01
Énoncé : Le document définit clairement les risques inclus et exclus du périmètre, ainsi que la frontière de sécurité du système. Preuve :1.3， 1.4
THREAT-01
Énoncé : Le modèle de menace couvre les attaques réseau, les téléchargements non autorisés, les tentatives de lecture côté stockage/serveur et les attaquants côté navigateur. Preuve :2.2
BOUNDARY-01
Énoncé : Les frontières de confiance séparent clairement les responsabilités entre le client, le serveur, le stockage d’objets et l’environnement externe ; le serveur NE DOIT PAS obtenir le CEK. Preuve :2.4
FAILCLOSE-01
Énoncé : En cas d’échec d’authentification ou de contexte incohérent, le système doit échouer en mode fermé (fail closed) et ne produire aucun texte en clair partiel. Preuve :2.5
ARCH-01
Énoncé : Les objets de données de base sont clairement séparés : les blocs chiffrés, le manifeste et les données d’audit sont isolés les uns des autres. Preuve :3.2
FLOW-UP-01
Énoncé : Le flux d’envoi comprend la création d’un transferId et l’émission de jetons d’accès de courte durée (jetons de session à consultation côté serveur) avec des contrôles stricts de portée et d’expiration. Preuve :3.3
FLOW-DL-01
Énoncé : Les téléchargements analysent le fragment d’URL pour obtenir le CEK ; les lectures du manifeste et des blocs utilisent des jetons de portées différentes ; les échecs d’authentification échouent en mode fermé. Preuve :3.4， 2.5
AUTH-TOKEN-01
Énoncé : Les jetons d’accès de courte durée sont des jetons de session côté serveur (à consultation) qui expirent et servent au contrôle d’accès au texte chiffré et aux manifestes. Preuve :4.2
AUTH-SCOPE-01
Énoncé : Les jetons sont séparés par des portées telles que read_manifest / read_chunk / upload_chunk et sont strictement validés. Preuve :4.3， 4.4， 3.4
AUTH-PAID-01
Énoncé : Les utilisateurs payants se connectent via un lien magique à usage unique et obtiennent un jeton de longue durée conservé côté client pour les actions de gestion côté expéditeur. Preuve :4.1， 3.5
REVOKE-01
Énoncé : L'expéditeur peut révoquer l'accès : la suppression d’un transfert ou de fichiers invalide les téléchargements avant l’échéance et refuse tout accès ultérieur. Preuve :4.5
AUDIT-01
Énoncé : Les données d'audit telles que le nombre de téléchargements et la progression ne sont visibles que par l'expéditeur et non par le destinataire. Preuve :4.6， 3.5
LOG-01
Énoncé : Les journaux et la télémétrie du client et du serveur n’incluent ni le CEK, ni les fragments d’URL, ni aucun matériel de clé dérivable. Preuve :4.7， 10.2
Chapitre 5 (cryptographie et gestion des clés)
CRYPTO-ZK-01
Énoncé : Le CEK est généré uniquement dans le navigateur et distribué via le fragment d'URL ; le serveur ne génère jamais de lien de téléchargement complet contenant le CEK. Preuve :5.3.1， 5.3.2
CRYPTO-ZK-02
Énoncé : Le serveur ne reçoit, ne stocke ni n’enregistre le CEK ; le stockage d’objets ne conserve que des blocs chiffrés. Preuve :5.0， 5.5.1
CRYPTO-E2EE-01
Énoncé : Les blocs utilisent AES-128-GCM ; un échec d’authentification doit échouer en mode fermé (fail closed) et ne produire aucun texte en clair partiel. Preuve :5.4.2， 5.8.4
CRYPTO-CHUNK-01
Énoncé : chunkSize est fixé à 16 Mo (16777216). Preuve :5.4.1， 5.8.1
CRYPTO-NONCE-01
Énoncé : L’IV est dérivé de noncePrefix(8B)||uint32_be(chunkIndex) et ne doit jamais se répéter avec le même CEK. Preuve :5.4.3， 5.8.1
CRYPTO-AAD-01
Énoncé : L’AAD est lié à transferId + fileId + chunkIndex et encodé via EncodeAAD_v1. Preuve :5.4.4
CRYPTO-CLIENT-01
Énoncé : Les pages de téléchargement/déchiffrement ne chargent aucun script tiers ; les journaux et la télémétrie du client n’incluent ni fragments d’URL ni matériel de clé. Preuve :5.6， 10.2
CRYPTO-TLS-01
Énoncé : HTTPS est imposé sur l’ensemble du site ; la configuration TLS est vérifiable via des rapports publics de tiers. Preuve :5.1.2， /status#tls-configuration
Chapitres 6 à 7 (cycle de vie des données / défense contre les abus)
LIFECYCLE-01
Énoncé : L’expiration et la suppression à l’initiative de l’utilisateur déclenchent le nettoyage ; la révocation est prise en charge pour invalider les téléchargements avant l’échéance. Preuve :6.2， 6.3， 4.5
ABUSE-01
Énoncé : La défense contre les abus repose sur la limitation de débit et des contrôles par paliers, sans franchir la frontière de la connaissance nulle. Preuve :7.2， 7.4
Chapitres 8 à 9 (confidentialité / sécurité Web et isolation)
PRIVACY-01
Énoncé : La définition et les engagements de connaissance nulle sont explicites : le CEK est généré et utilisé uniquement côté client ; le serveur ne peut pas récupérer la clé. Preuve :8.1
PRIVACY-02
Énoncé : Les implications des fragments d’URL pour la confidentialité (copier/coller, fuite du référent, journalisation) sont documentées avec leurs mesures d’atténuation. Preuve :8.2， 10.2
WEB-01
Énoncé : Les pages clés appliquent une CSP stricte et des frontières de ressources pour réduire les risques d’injection et de détournement de clics (clickjacking). Preuve :9.1， 9.3
WEB-HEADERS-01
Énoncé : Le socle d’en-têtes de sécurité est vérifiable via des rapports publics de tiers. Preuve :/status#security-headers
WEB-OBS-01
Énoncé : Le site peut être vérifié via des analyses publiques de bonnes pratiques réalisées par des tiers. Preuve :/status#http-observatory
Chapitres 10 à 12 (journalisation et réponse aux incidents / divulgation des vulnérabilités / preuves)
OBS-01
Énoncé : L’observabilité suit un principe de minimisation : elle ne couvre que les besoins d’exploitation et de sécurité et recourt à des stratégies d’agrégation et d’échantillonnage. Preuve :10.1
IR-01
Énoncé : Un processus de réponse aux incidents de sécurité est défini (gravité, confinement, analyse post-incident, remédiation et avis public). Preuve :10.4
VDP-01
Énoncé : Un processus de divulgation des vulnérabilités existe et traite en priorité les problèmes susceptibles d’affecter la frontière de la connaissance nulle. Preuve :11.2
EV-01
Énoncé : La page d’état regroupe les points d’entrée de preuves tierces ; les preuves renvoient à des sources faisant autorité et précisent les limites d’applicabilité. Preuve :12.2， 12.6