Logo

Capitolo 1 Panoramica e ambito di sicurezza

Questo capitolo definisce lo scopo del white paper, il linguaggio normativo e la terminologia e stabilisce gli obiettivi di sicurezza e le condizioni limite di FileBolt. La chiara separazione tra rischi interni ed esterni all’ambito di applicazione evita malintesi su ciò che il sistema può garantire.

Metadati del documento

Versione del whitepaper
v1.0
Ultimo aggiornamento
2026-01-14

Torna a: Whitepaper su sicurezza e privacy (panoramica)

1.0 Scopo

  • Descrivere la progettazione della sicurezza di FileBolt e i limiti di attendibilità per utenti e revisori.
  • Spiegare come viene protetta la riservatezza/integrità durante il caricamento, l'archiviazione e il download.
  • Fornire collegamenti a prove verificabili e ID reclamo per la revisione e la riproducibilità.

1.1 Linguaggio e termini normativi

  • Parole chiave normative: MUST / SHOULD / MAY (Utilizzo in stile RFC 2119).
  • CEK: Chiave di crittografia del contenuto; 16 byte (128 bit); uno per fascicolo.
  • E2EE / Conoscenza zero: la crittografia e la decrittografia avvengono sul client; il server gestisce solo testo cifrato e parametri pubblici e NON DEVE ottenere CEK.
  • transferId/fileId/chunkIndex: identificatori per trasferimento, file e indice di blocco.
  • manifest: parametri pubblici necessari per scaricare/assemblare/decrittografare (ad esempio, cryptoVersion, ChunkSize, mappatura); NON DEVE contenere CEK.
  • Token di accesso di breve durata: token di sessione lato server (basato sulla ricerca) utilizzato per autorizzare l'accesso al testo cifrato/manifesto; scade in base alla progettazione.

1.2 Obiettivi di sicurezza

  • Confidentiality: il server NON DEVE essere in grado di decrittografare il contenuto dell'utente secondo il modello a conoscenza zero.
  • Integrity: la manomissione DEVE essere rilevata; L'errore di autenticazione AEAD DEVE essere chiuso con esito negativo.
  • Controllo degli accessi: l'accesso al testo cifrato DEVE essere protetto da token con ambito e scadenza; i mittenti DEVONO essere in grado di revocare.
  • Auditability: fornire prove di consegna minime e visibili al mittente, riducendo al minimo l'esposizione dei dati sensibili.

1.3 Nel campo di applicazione

  • Limite a conoscenza zero/E2EE e gestione delle chiavi (modello di frammento URL).
  • Parametri di crittografia e autenticazione in blocchi (cryptoVersion=v1).
  • Autorizzazione basata su token per caricamento/download e recupero di manifest; semantica della revoca.
  • Base di sicurezza Web per le pagine di download/decrittografia (CSP, senza script di terze parti).

1.4 Fuori campo

  • Endpoint compromessi: malware, estensioni del browser dannose o dispositivi rooted.
  • Perdita di link intenzionale dell'utente, ingegneria sociale o configurazione errata.
  • Scansione dei contenuti lato server (incompatibile con la rigorosa protezione dei contenuti a conoscenza zero).