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 suo confine zero-knowledge, e specifica i parametri di cryptoVersion=v1, le regole di codifica, le modalità di errore e i vincoli per il client. Le chiavi vengono generate e usate sul client; il server e lo storage a oggetti gestiscono solo blocchi di testo cifrato e i metadati necessari.

5.0 Riepilogo

  • Il sistema NON DEVE ricevere, archiviare né registrare nei log le chiavi di decifratura (CEK). Il materiale della CEK viaggia solo nel frammento dell'URL (la parte dopo #), che non viene inviato al server nelle richieste HTTP.
  • La cifratura usa AES-128-GCM (AEAD). Ogni file usa una CEK indipendente (16 byte). La dimensione dei blocchi è fissa (ad esempio 16MB).
  • Costruzione dell'IV nella v1: IV = noncePrefix(8B) || uint32_be(chunkIndex)(4B). Le AAD legano transferId, fileId e chunkIndex per impedire lo scambio di contesto e gli attacchi di replay.
  • I token del server controllano solo l'accesso al testo cifrato e scadono; non conferiscono alcuna capacità di decifratura.

5.1 Crittografia del trasporto (TLS)

5.1.1 Obiettivo di sicurezza

  • Impedire intercettazioni e manomissioni sui collegamenti di caricamento, download e API.
  • Proteggere token e testo cifrato in transito.

5.1.2 Politica di sicurezza

  • Il sistema DEVE servire tutte le pagine e le API solo tramite HTTPS.
  • Il sistema DOVREBBE preferire TLS 1.3 e supportare TLS 1.2 se necessario; i protocolli e le suite di cifratura deboli DEVONO essere disabilitati.
  • Il sistema DEVE abilitare HSTS con un valore ragionevole di 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 cifrato in modo indipendente per consentire il trasferimento parallelo e la ripresa.
  • L'autenticazione AEAD protegge l'integrità; qualsiasi errore di autenticazione DEVE causare un fallimento in modalità chiusa (fail closed).

5.2.2 Politica di sicurezza

  • Ogni file DEVE usare una CEK distinta (16 byte).
  • L'IV DEVE essere univoco per ogni coppia (file, chunkIndex). La v1 usa la codifica noncePrefix + chunkIndex.
  • Le AAD DEVONO includere (transferId, fileId, chunkIndex) per legare il testo cifrato al proprio contesto.

5.3 Modello di link zero-knowledge

5.3.1 Vincoli principali

  • La CEK (o il materiale di derivazione) DEVE viaggiare solo nel frammento dell'URL e NON DEVE essere inclusa nei parametri di query né negli header.
  • Il server NON DEVE registrare i frammenti nei log; i log DEVONO essere ripuliti per evitare acquisizioni accidentali.
  • La politica sul referrer DOVREBBE impedire la fuga del frammento tramite la navigazione verso l'esterno (vedi il Capitolo 9).

5.4 Generazione e gestione delle chiavi

  • Le chiavi DEVONO essere generate con un generatore di numeri casuali crittograficamente sicuro (WebCrypto).
  • Le chiavi DOVREBBERO essere tenute solo in memoria e cancellate quando non servono più.
  • I client NON DEVONO conservare la CEK in posizioni visibili al server (ad esempio cookie, parametri di query).

5.5 Codifica e parametri

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

5.6 Modalità di errore (fail closed)

  • In caso di errore di decifratura o di autenticazione AEAD, i client DEVONO interrompere l'operazione e NON DEVONO produrre testo in chiaro parziale.
  • In caso di mancata corrispondenza dei parametri (transferId/fileId/chunkIndex), i client DEVONO fallire in modalità chiusa e DOVREBBERO segnalare un errore su cui si possa intervenire.

5.7 ID delle affermazioni correlati