Logo

Chapitre 3 Architecture du système et flux de données

Ce chapitre décrit les composants système de haut niveau et le flux de données de bout en bout pour le téléchargement, le téléchargement et la gestion des expéditeurs. L'accent est mis sur ce qui est chiffré, quelles métadonnées sont requises et comment le contrôle d'accès et la révocation sont appliqués.

Métadonnées du document

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

3.1 Composants

  • Client: fragmente les fichiers, crypte/déchiffre et gère le CEK dans le fragment d'URL.
  • API/Edge: émet et valide les jetons de portée ; sert des morceaux de manifeste et de texte chiffré.
  • Stockage d'objets : stocke les morceaux et les manifestes cryptés ; traité comme non fiable pour la confidentialité du texte en clair.
  • Magasin d'État : suit l’état du transfert (progression du téléchargement, expiration, révocation) avec un minimum de métadonnées.

3.2 Objets de données

  • Manifest: paramètres publics requis pour récupérer et assembler des fragments (cryptoVersion, taille/nombre de fragments, mappage) ; NE DOIT PAS contenir de CEK.
  • Chunk: morceau de fichier crypté (texte chiffré) plus métadonnées minimales (longueur/etag), adressé par (transferId, fileId, chunkIndex).
  • State: Enregistrement côté serveur pour l’autorisation, la durée de vie, la révocation et la possibilité de reprise.

3.3 Flux de téléchargement

  1. Le client crée un transfert et reçoit un jeton de téléchargement de courte durée et limité à transferId.
  2. Le client génère localement du CEK par fichier, divise les fichiers en morceaux de taille fixe et chiffre chaque morceau avec AEAD.
  3. Le client télécharge des morceaux de texte chiffré en parallèle ; les tentatives sont idempotentes par morceau.
  4. Le client télécharge le manifeste (paramètres publics uniquement). Le serveur marque le transfert PRÊT lorsque les pièces requises sont présentes.

3.4 Flux de téléchargement

  1. Le destinataire ouvre le lien de partage. Le fragment d'URL (matériel CEK) reste dans le navigateur et n'est pas envoyé au serveur.
  2. Le client récupère le manifeste à l'aide d'un jeton de téléchargement étendu et détermine le plan de fragmentation.
  3. Le client télécharge des morceaux de texte chiffré (éventuellement en parallèle), vérifie l'authentification AEAD, puis assemble le fichier de texte brut.
  4. En cas d'échec, le client reprend en demandant uniquement les morceaux manquants ; les échecs d’intégrité DOIVENT échouer fermés.

3.5 Gestion des expéditeurs et flux d'audit

  • Les expéditeurs s'authentifient à l'aide d'un jeton de connexion de longue durée (stocké sur le client) pour les opérations de gestion.
  • Les API de gestion permettent de répertorier les transferts, de vérifier les preuves de livraison et de révoquer/supprimer les transferts.
  • Les données d'audit sont conçues pour être visibles uniquement par l'expéditeur ; il n'est pas exposé aux destinataires par défaut.

3.6 Visibilité et minimisation

  • Le serveur et le stockage ne gèrent que le texte chiffré et les paramètres publics nécessaires ; ils ne peuvent pas décrypter le contenu sans CEK.
  • Les journaux et les analyses DEVRAIENT être minimisés et NE DOIVENT PAS inclure de fragments d'URL ou de matériel CEK.
  • La collecte de métadonnées DEVRAIT être limitée à des objectifs précis (preuves de livraison, prévention des abus et fiabilité opérationnelle).