Livre blanc sur la sécurité et la confidentialité (présentation)Appendix
Annexe : Index des identifiants de réclamation (source unique de vérité)
Cette annexe est la source unique de vérité pour tous les ID de réclamation du livre blanc. Chaque revendication possède un identifiant et un ancrage uniques et stables, et est présentée sur une seule ligne avec un Statement and Evidence. 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 rapport de statut/tiers) et ne renvoient pas à des captures d’écran ou à du contenu réhébergé.
Règles d'entretien
- MUST: Les identifiants de réclamation sont uniques et stables ; une fois publiés, ils ne sont jamais réutilisés.
- MUST: Les preuves de chaque réclamation doivent être vérifiables de manière répétée (ancres de chapitre ou points d'entrée tiers faisant autorité).
- MUST: Les déclarations doivent uniquement affirmer ce que les preuves soutiennent ; évitez le langage de « sécurité absolue ».
- SHOULD: Lorsque des modifications de mise en œuvre ou de politique affectent une réclamation, enregistrez-la dans le journal des modifications et associez les ID de réclamation concernés.
Chapitres 1 à 4 (portée, modèle de menace, architecture, AuthZ)
SCOPE-01
Statement: Le document définit clairement les risques entrant dans le champ d'application et ceux hors du champ d'application, ainsi que les limites de sécurité du système. Evidence:1.3， 1.4
THREAT-01
Statement: 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. Evidence:2.2
BOUNDARY-01
Statement: Les limites 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 de CEK. Evidence:2.4
FAILCLOSE-01
Statement: En cas d'échec de l'authentification ou de contexte incohérent, le système doit échouer et ne produire aucun texte en clair partiel. Evidence:2.5
ARCH-01
Statement: Les objets de données de base sont clairement séparés : les morceaux chiffrés, les manifestes et les données d'audit sont isolés les uns des autres. Evidence:3.2
FLOW-UP-01
Statement: Le flux de téléchargement comprend la création d'un transferId et l'émission de jetons d'accès de courte durée (jetons de session basés sur la recherche) avec des contrôles stricts de portée et d'expiration. Evidence:3.3
FLOW-DL-01
Statement: Les téléchargements analysent le fragment d'URL pour obtenir le CEK ; Les lectures de manifeste et de fragments utilisent des jetons de portée différente ; les échecs d'authentification échouent. Evidence:3.4， 2.5
AUTH-TOKEN-01
Statement: Les jetons d'accès de courte durée sont des jetons de session côté serveur (basés sur une recherche) qui expirent et sont utilisés pour le contrôle d'accès au texte chiffré et aux manifestes. Evidence:4.2
AUTH-SCOPE-01
Statement: Les jetons sont séparés par des portées telles que read_manifest / read_chunk / upload_chunk et sont strictement validés. Evidence:4.3， 4.4， 3.4
AUTH-PAID-01
Statement: Les utilisateurs payants se connectent via un lien magique unique et obtiennent un jeton de longue durée détenu par le client pour les actions de gestion côté expéditeur. Evidence:4.1， 3.5
REVOKE-01
Statement: L'expéditeur peut révoquer l'accès : la suppression d'un transfert ou la suppression de fichiers rend les téléchargements invalides de manière anticipée et refuse l'accès ultérieur. Evidence:4.5
AUDIT-01
Statement: 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. Evidence:4.6， 3.5
LOG-01
Statement: Les journaux/télémétrie du client et du serveur n'incluent pas les CEK, les fragments d'URL ou tout autre élément de clé dérivé. Evidence:4.7， 10.2
Chapitre 5 (Cryptographie et gestion des clés)
CRYPTO-ZK-01
Statement: 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 du CEK. Evidence:5.3.1， 5.3.2
CRYPTO-ZK-02
Statement: Le serveur ne reçoit/stocke/enregistre pas les CEK ; le stockage d'objets stocke uniquement des morceaux chiffrés. Evidence:5.0， 5.5.1
CRYPTO-E2EE-01
Statement: Les morceaux utilisent AES-128-GCM ; l'échec de l'authentification doit échouer et ne produire aucun texte en clair partiel. Evidence:5.4.2， 5.8.4
CRYPTO-CHUNK-01
Statement: chunkSize est fixé à 16 Mo (16777216). Evidence:5.4.1， 5.8.1
CRYPTO-NONCE-01
Statement: IV est dérivé de noncePrefix(8B)||uint32_be(chunkIndex) et ne doit pas se répéter sous le même CEK. Evidence:5.4.3， 5.8.1
CRYPTO-AAD-01
Statement: AAD est lié à transferId + fileId + chunkIndex et codé via EncodeAAD_v1. Evidence:5.4.4
CRYPTO-CLIENT-01
Statement: Les pages de téléchargement/déchiffrement ne chargent aucun script tiers ; les journaux/télémétries des clients n'incluent pas de fragments ou de matériel de clé. Evidence:5.6， 10.2
CRYPTO-TLS-01
Statement: HTTPS à l’échelle du site est appliqué ; La configuration TLS est vérifiable via des rapports publics tiers. Evidence:5.1.2， /status#tls-configuration
Chapitres 6 à 7 (Cycle de vie des données / Défense contre les abus)
LIFECYCLE-01
Statement: Nettoyage du déclencheur d’expiration et de suppression initié par l’utilisateur ; la révocation est prise en charge pour invalider les téléchargements plus tôt. Evidence:6.2， 6.3， 4.5
ABUSE-01
Statement: La défense contre les abus utilise une limitation du taux et des contrôles à plusieurs niveaux, fonctionnant sans dépasser la limite de la connaissance nulle. Evidence:7.2， 7.4
Chapitres 8 à 9 (Confidentialité/Sécurité et isolation Web)
PRIVACY-01
Statement: La définition et les engagements de connaissance nulle sont explicites : le CEK est généré et utilisé uniquement sur le client ; le serveur ne peut pas récupérer la clé. Evidence:8.1
PRIVACY-02
Statement: Les implications en matière de confidentialité des fragments d'URL (copier/coller, fuite de référent, journalisation) sont documentées avec des atténuations. Evidence:8.2， 10.2
WEB-01
Statement: Les pages clés imposent des limites strictes en matière de CSP et de ressources pour réduire les risques d'injection et de détournement de clics. Evidence:9.1， 9.3
WEB-HEADERS-01
Statement: La base de référence des en-têtes de sécurité est vérifiable via des rapports publics tiers. Evidence:/status#security-headers
WEB-OBS-01
Statement: Le site peut être vérifié via des analyses publiques des meilleures pratiques par des tiers. Evidence:/status#http-observatory
Chapitres 10 à 12 (Journalisation et IR / Divulgation de vulnérabilité / Preuve)
OBS-01
Statement: L’observabilité suit un principe minimal, couvrant uniquement les besoins opérationnels/sécurité et utilisant des stratégies d’agrégation/échantillonnage. Evidence:10.1
IR-01
Statement: Un processus de réponse aux incidents de sécurité est défini (gravité, confinement, post-mortem, remédiation et avis public). Evidence:10.4
VDP-01
Statement: Un processus de divulgation des vulnérabilités existe et donne la priorité aux problèmes qui pourraient affecter la limite de connaissance zéro. Evidence:11.2
EV-01
Statement: La page d'état regroupe les points d'entrée de preuves tierces ; les preuves sont liées à des sources faisant autorité et clarifient les limites d’applicabilité. Evidence:12.2， 12.6