Logo

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

Ce chapitre décrit les composants du système à haut niveau et le flux de données de bout en bout pour l’envoi, le téléchargement et la gestion côté expéditeur. L’accent est mis sur ce qui est chiffré, sur les métadonnées nécessaires, ainsi que sur la manière dont le contrôle d’accès et la révocation sont appliqués.

Métadonnées du document

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

3.1 Composants

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

3.2 Objets de données

  • Manifeste : paramètres publics nécessaires pour récupérer et assembler les blocs (cryptoVersion, taille et nombre de blocs, correspondance) ; NE DOIT PAS contenir la CEK.
  • Bloc : fragment de fichier chiffré (texte chiffré) accompagné de métadonnées minimales (longueur/etag), adressé par (transferId, fileId, chunkIndex).
  • État : enregistrement côté serveur pour l’autorisation, la durée de vie (TTL), la révocation et la reprise.

3.3 Flux d’envoi

  1. Le client crée un transfert et reçoit un jeton d’envoi à courte durée de vie et à portée limitée, lié à transferId.
  2. Le client génère localement une CEK par fichier, découpe les fichiers en blocs de taille fixe et chiffre chaque bloc avec AEAD.
  3. Le client envoie les blocs de texte chiffré en parallèle ; les nouvelles tentatives sont idempotentes pour chaque bloc.
  4. Le client envoie le manifeste (paramètres publics uniquement). Le serveur marque le transfert comme READY lorsque les éléments requis sont présents.

3.4 Flux de téléchargement

  1. Le destinataire ouvre le lien de partage. Le fragment de l’URL (matériel de la 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 à portée limitée et détermine le plan de blocs.
  3. Le client télécharge les blocs de texte chiffré (éventuellement en parallèle), vérifie l’authentification AEAD, puis assemble le fichier en clair.
  4. En cas d’échec, le client reprend en ne demandant que les blocs manquants ; les échecs d’intégrité DOIVENT entraîner un échec sécurisé (fail closed).

3.5 Gestion côté expéditeur et flux d’audit

  • Les expéditeurs s’authentifient avec un jeton de connexion de longue durée (stocké sur le client) pour les opérations de gestion.
  • Les API de gestion permettent de lister les transferts, de consulter les preuves de livraison et de révoquer ou supprimer des transferts.
  • Les données d’audit sont conçues pour n’être visibles que par l’expéditeur ; elles ne sont pas exposées aux destinataires par défaut.

3.6 Visibilité et minimisation

  • Le serveur et le stockage ne traitent que du texte chiffré et les paramètres publics nécessaires ; ils ne peuvent pas déchiffrer le contenu sans la CEK.
  • Les journaux et les analyses DEVRAIENT être réduits au minimum et NE DOIVENT PAS contenir de fragments d’URL ni de matériel de CEK.
  • La collecte de métadonnées DEVRAIT être limitée à des finalités précises (preuves de livraison, prévention des abus et fiabilité opérationnelle).