Logo

Capitolo 1 Panoramica e ambito di sicurezza

Questo capitolo definisce lo scopo del whitepaper, il linguaggio normativo e la terminologia, ed espone gli obiettivi di sicurezza e le condizioni limite di FileBolt. Separare con chiarezza i rischi inclusi da quelli esclusi dall'ambito evita fraintendimenti 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 il design di sicurezza di FileBolt e i confini di fiducia per utenti e auditor.
  • Spiegare come riservatezza e integrità sono protette durante caricamento, archiviazione e download.
  • Fornire link a prove verificabili e ID delle affermazioni (Claim ID) per la revisione e la riproducibilità.

1.1 Linguaggio e termini normativi

  • Parole chiave normative: MUST / SHOULD / MAY (in italiano DEVE / DOVREBBE / PUÒ; uso in stile RFC 2119).
  • CEK: Content Encryption Key, la chiave di crittografia del contenuto; 16 byte (128 bit); una per file.
  • E2EE / zero-knowledge: la crittografia e la decrittografia avvengono sul client; il server gestisce solo testo cifrato e parametri pubblici e NON DEVE ottenere la CEK.
  • transferId / fileId / chunkIndex: identificatori del trasferimento, del file e dell'indice del blocco.
  • manifest: parametri pubblici necessari per scaricare, assemblare e decrittografare (ad es. cryptoVersion, chunkSize, mappatura); NON DEVE contenere la CEK.
  • Token di accesso di breve durata: token di sessione lato server (basato su lookup) usato per autorizzare l'accesso a testo cifrato e manifest; scade per progettazione.

1.2 Obiettivi di sicurezza

  • Riservatezza: secondo il modello zero-knowledge, il server NON DEVE essere in grado di decrittografare i contenuti degli utenti.
  • Integrità: ogni manomissione DEVE essere rilevata; un errore di autenticazione AEAD DEVE far fallire l'operazione (fail closed).
  • Controllo degli accessi: l'accesso al testo cifrato DEVE essere protetto da token con ambito limitato e scadenza; i mittenti DEVONO poter revocare l'accesso.
  • Verificabilità: fornire prove di consegna minime, visibili al mittente, riducendo al minimo l'esposizione di dati sensibili.

1.3 Nell'ambito

  • Confine zero-knowledge/E2EE e gestione delle chiavi (modello del frammento dell'URL).
  • Parametri di crittografia e autenticazione a blocchi (cryptoVersion=v1).
  • Autorizzazione basata su token per caricamento, download e recupero del manifest; semantica della revoca.
  • Baseline di sicurezza web per le pagine di download e decrittografia (CSP, nessuno script di terze parti).

1.4 Fuori ambito

  • Endpoint compromessi: malware, estensioni del browser dannose o dispositivi con root.
  • Divulgazione intenzionale del link da parte dell'utente, social engineering o errori di configurazione.
  • Scansione dei contenuti lato server (incompatibile con una rigorosa protezione zero-knowledge dei contenuti).