Logo

Livre blanc sur la sécurité et la confidentialité (présentation)Chapitre 5

Chapitre 5 Cryptographie et gestion des clés

Ce chapitre décrit le chiffrement de bout en bout (E2EE) de FileBolt et la limite de la connaissance nulle, et précise les paramètres de cryptoVersion=v1, les règles d’encodage, les modes de défaillance et les contraintes côté client. Les clés sont générées et utilisées côté client ; le serveur et le stockage d’objets ne traitent que des blocs de texte chiffré et les métadonnées nécessaires.

5.0 Résumé

  • Le système NE DOIT PAS recevoir, stocker ni journaliser les clés de déchiffrement (CEK). Le matériel de la CEK n’est transporté que dans le fragment de l’URL (la partie après #), qui n’est pas envoyé au serveur dans les requêtes HTTP.
  • Le chiffrement utilise AES-128-GCM (AEAD). Chaque fichier utilise une CEK indépendante (16 octets). La taille des blocs est fixe (par ex. 16 Mo).
  • Construction de l’IV en v1 : IV = noncePrefix(8 o) || uint32_be(chunkIndex)(4 o). L’AAD lie transferId, fileId et chunkIndex afin d’empêcher la permutation de contexte et le rejeu.
  • Les jetons du serveur ne contrôlent que l’accès au texte chiffré et expirent ; ils ne donnent aucune capacité de déchiffrement.

5.1 Chiffrement du transport (TLS)

5.1.1 Objectif de sécurité

  • Empêcher l’écoute et la falsification sur les liaisons d’envoi, de téléchargement et d’API.
  • Protéger les jetons et le texte chiffré en transit.

5.1.2 Politique de sécurité

  • Le système DOIT servir toutes les pages et API exclusivement en HTTPS.
  • Le système DEVRAIT privilégier TLS 1.3 et prendre en charge TLS 1.2 si nécessaire ; les protocoles et chiffrements faibles DOIVENT être désactivés.
  • Le système DOIT activer HSTS avec une valeur max-age raisonnable.

5.2 Chiffrement par blocs (AES-128-GCM)

5.2.1 Notes de conception

  • Les fichiers sont découpés en blocs de taille fixe ; chaque bloc est chiffré indépendamment pour permettre le transfert parallèle et la reprise.
  • L’authentification AEAD protège l’intégrité ; tout échec d’authentification DOIT entraîner un échec sécurisé (fail closed).

5.2.2 Politique de sécurité

  • Chaque fichier DOIT utiliser une CEK distincte (16 octets).
  • L’IV DOIT être unique pour chaque couple (fichier, chunkIndex). La v1 utilise l’encodage noncePrefix + chunkIndex.
  • L’AAD DOIT inclure (transferId, fileId, chunkIndex) pour lier le texte chiffré à son contexte.

5.3 Modèle de lien à connaissance nulle

5.3.1 Contraintes clés

  • La CEK (ou le matériel de dérivation) DOIT être transportée uniquement dans le fragment de l’URL et NE DOIT PAS figurer dans les paramètres de requête ni dans les en-têtes.
  • Le serveur NE DOIT PAS journaliser les fragments ; les journaux DOIVENT être assainis pour éviter toute capture accidentelle.
  • La politique de référent DEVRAIT empêcher la fuite du fragment lors d’une navigation sortante (voir le chapitre 9).

5.4 Génération et gestion des clés

  • Les clés DOIVENT être générées avec un générateur de nombres aléatoires cryptographiquement sûr (WebCrypto).
  • Les clés DEVRAIENT être conservées uniquement en mémoire et effacées dès qu’elles ne sont plus nécessaires.
  • Les clients NE DOIVENT PAS conserver la CEK dans des emplacements visibles par le serveur (par ex. cookies, paramètres de requête).

5.5 Encodage et paramètres

  • cryptoVersion=v1 identifie la suite d’algorithmes ainsi que les règles d’IV et d’AAD.
  • Le manifeste DOIT inclure les paramètres publics nécessaires (taille et nombre de blocs, noncePrefix, correspondance des fileId) mais NE DOIT PAS inclure la CEK.

5.6 Modes de défaillance (échec sécurisé)

  • En cas d’échec du déchiffrement ou de l’authentification AEAD, les clients DOIVENT interrompre l’opération et NE DOIVENT PAS produire de texte en clair partiel.
  • En cas d’incohérence de paramètres (transferId/fileId/chunkIndex), les clients DOIVENT échouer de façon sécurisée et DEVRAIENT signaler une erreur exploitable.

5.7 Identifiants d'affirmation associés