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) et la limite de connaissance nulle de FileBolt, et spécifie cryptoVersion=v1 paramètres, règles de codage, modes de défaillance et contraintes client. Les clés sont générées et utilisées sur le client ; le serveur et le stockage d'objets ne gèrent que les fragments de texte chiffré et les métadonnées requises.

5.0 Résumé

  • Le système NE DOIT PAS recevoir, stocker ou enregistrer les clés de déchiffrement (CEK). Le matériel CEK est transporté uniquement dans le fragment d'URL (# partie), qui n’est pas envoyé au serveur dans les requêtes HTTP.
  • Utilisations du cryptage AES-128-GCM (AEAD). Chaque fichier utilise un CEK indépendant (16 octets). La taille du fragment est fixe (par exemple, 16 Mo).
  • Construction v1 IV : IV = noncePrefix(8B) || uint32_be(chunkIndex)(4B). AAD binds transferId, fileId, et chunkIndex pour empêcher l'échange de contexte et la relecture.
  • Les jetons de serveur contrôlent uniquement l'accès au texte chiffré et expirent ; ils n'accordent pas de capacité de décryptage.

5.1 Chiffrement des transports (TLS)

5.1.1 Objectif de sécurité

  • Empêchez les écoutes clandestines et la falsification des liens de téléchargement/téléchargement/API.
  • Protégez les jetons et le texte chiffré en transit.

5.1.2 Politique de sécurité

  • Le système MUST servir toutes les pages et API via HTTPS uniquement.
  • Le système SHOULD préférez TLS 1.3 et prenez en charge TLS 1.2 si nécessaire ; les protocoles/chiffrements faibles DOIVENT être désactivés.
  • Le système MUST activer HSTS avec un délai raisonnable max-age.

5.2 Chiffrement de fragments (AES-128-GCM)

5.2.1 Notes de conception

  • Les fichiers sont divisés en morceaux de taille fixe ; chaque morceau est chiffré indépendamment pour prendre en charge le transfert parallèle et la possibilité de reprise.
  • L'authentification AEAD protège l'intégrité ; tout échec d'authentification DOIT échouer fermé.

5.2.2 Politique de sécurité

  • Chaque fichier DOIT utiliser un CEK distinct (16 octets).
  • IV DOIT être unique par (fichier, chunkIndex). la v1 utilise noncePrefix + chunkIndex encoding.
  • AAD DOIT inclure (transferId, fileId, chunkIndex) pour lier le texte chiffré à son contexte.

5.3 Modèle de lien sans connaissance

5.3.1 Contraintes clés

  • Le CEK (ou le matériel de dérivation) DOIT être transporté uniquement dans le fragment d'URL et NE DOIT PAS être inclus dans les paramètres ou les en-têtes de requête.
  • Le serveur NE DOIT PAS enregistrer les fragments ; les journaux DOIVENT être désinfectés pour éviter toute capture accidentelle.
  • La politique du référent DEVRAIT empêcher la fuite de fragments via la navigation sortante (voir Chapitre 9).

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

  • Les clés DOIVENT être générées à l’aide d’un RNG cryptographiquement sécurisé (WebCrypto).
  • Les clés DEVRAIENT être conservées en mémoire uniquement et effacées lorsqu’elles ne sont plus nécessaires.
  • Les clients NE DOIVENT PAS conserver la CEK dans des emplacements visibles par le serveur (par exemple, cookies, paramètres de requête).

5.5 Codage et paramètres

  • cryptoVersion=v1 identifie la suite d'algorithmes et les règles IV/AAD.
  • Le manifeste DOIT inclure les paramètres publics requis (taille/nombre de morceaux, noncePrefix, mappage fileId) mais NE DOIT PAS inclure CEK.

5.6 Modes de défaillance (fail fermé)

  • En cas d'échec du déchiffrement ou d'authentification AEAD, les clients DOIVENT abandonner et NE DOIVENT PAS sortir un texte en clair partiel.
  • En cas de non-concordance des paramètres (transferId/fileId/chunkIndex), les clients DOIVENT échouer en fermeture et DEVRAIENT signaler une erreur exploitable.

5.7 ID de réclamation associés