Logo

Whitepaper su sicurezza e privacy (panoramica)Capitolo 5

Capitolo 5 Crittografia e gestione delle chiavi

Questo capitolo descrive la crittografia end-to-end (E2EE) di FileBolt e il limite a conoscenza zero e specifica cryptoVersion=v1 parametri, regole di codifica, modalità di errore e vincoli del client. Le chiavi vengono generate e utilizzate sul client; il server e l'archiviazione degli oggetti gestiscono solo blocchi di testo cifrato e metadati richiesti.

5.0 Riepilogo

  • Il sistema NON DEVE ricevere, archiviare o registrare le chiavi di decrittazione (CEK). Il materiale CEK è contenuto solo nel frammento URL (# parte), che non viene inviato al server nelle richieste HTTP.
  • Usi di crittografia AES-128-GCM (AEAD). Ogni file utilizza una CEK indipendente (16 byte). La dimensione del blocco è fissa (ad esempio, 16 MB).
  • Costruzione v1 IV: IV = noncePrefix(8B) || uint32_be(chunkIndex)(4B). AAD binds transferId, fileId, e chunkIndex per impedire lo scambio e la riproduzione del contesto.
  • I token del server controllano solo l'accesso al testo cifrato e scadono; non garantiscono la capacità di decrittazione.

5.1 Crittografia del trasporto (TLS)

5.1.1 Obiettivo di sicurezza

  • Previeni l'intercettazione e la manomissione dei collegamenti di caricamento/download/API.
  • Proteggi token e testo cifrato in transito.

5.1.2 Politica di sicurezza

  • Il sistema MUST servire tutte le pagine e le API solo tramite HTTPS.
  • Il sistema SHOULD preferire TLS 1.3 e supportare TLS 1.2 secondo necessità; i protocolli/cifrature deboli DEVONO essere disabilitati.
  • Il sistema MUST abilitare HSTS con un ragionevole max-age.

5.2 Crittografia a blocchi (AES-128-GCM)

5.2.1 Note di progettazione

  • I file vengono suddivisi in blocchi di dimensione fissa; ogni blocco viene crittografato in modo indipendente per supportare il trasferimento parallelo e la ripristinabilità.
  • L'autenticazione AEAD protegge l'integrità; qualsiasi errore di autenticazione DEVE fallire chiuso.

5.2.2 Politica di sicurezza

  • Ogni file DEVE utilizzare un CEK distinto (16 byte).
  • IV DEVE essere univoco per (file, ChunkIndex). v1 utilizza noncePrefix + chunkIndex encoding.
  • AAD DEVE includere (transferId, fileId, ChunkIndex) per associare il testo cifrato al relativo contesto.

5.3 Modello di collegamento a conoscenza zero

5.3.1 Vincoli principali

  • CEK (o materiale di derivazione) DEVE essere riportato solo nel frammento dell'URL e NON DEVE essere incluso nei parametri o nelle intestazioni della query.
  • Il server NON DEVE registrare frammenti; i tronchi DEVONO essere disinfettati per evitare la cattura accidentale.
  • La politica di riferimento DOVREBBE prevenire la perdita di frammenti tramite la navigazione in uscita (vedere Capitolo 9).

5.4 Generazione e gestione delle chiavi

  • Le chiavi DEVONO essere generate utilizzando un RNG crittograficamente sicuro (WebCrypto).
  • Le chiavi DEVONO essere mantenute solo in memoria e cancellate quando non sono più necessarie.
  • I client NON DEVONO persistere CEK in posizioni visibili dal server (ad esempio, cookie, parametri di query).

5.5 Codifica e parametri

  • cryptoVersion=v1 identifica la suite di algoritmi e le regole IV/AAD.
  • Il manifest DEVE includere i parametri pubblici richiesti (dimensione/conteggio dei blocchi, noncePrefix, mappatura fileId) ma NON DEVE includere CEK.

5.6 Modalità di guasto (fail chiuso)

  • In caso di errore di decrittografia o di autenticazione AEAD, i client DEVONO interrompere e NON DEVONO restituire testo in chiaro parziale.
  • In caso di mancata corrispondenza dei parametri (transferId/fileId/chunkIndex), i client DEVONO fallire la chiusura e DOVREBBERO segnalare un errore che può essere risolto.

5.7 ID di reclamo correlati