Whitepaper su sicurezza e privacy (panoramica)Appendice
Appendice: indice degli ID delle affermazioni (unica fonte di verità)
Questa appendice è l'unica fonte di verità per tutti gli ID delle affermazioni del whitepaper. Ogni affermazione ha un identificatore e un'ancora univoci e stabili ed è presentata su un'unica riga con una Dichiarazione e le relative Prove. Le prove rimandano solo a riferimenti autorevoli verificabili in modo ripetibile (ancore dei capitoli o punti di accesso a report di stato/di terze parti) e non rimandano a screenshot né a contenuti ospitati altrove.
Regole di manutenzione
- DEVE: gli ID delle affermazioni sono univoci e stabili; una volta pubblicati, non vengono mai riutilizzati.
- DEVE: le prove di ciascuna affermazione devono essere verificabili in modo ripetibile (ancore dei capitoli o punti di accesso autorevoli di terze parti).
- DEVE: le dichiarazioni devono asserire solo ciò che le prove supportano; evita un linguaggio da «sicurezza assoluta».
- DOVREBBE: quando modifiche all'implementazione o alle policy incidono su un'affermazione, registrale nel changelog e collega gli ID delle affermazioni interessate.
Capitoli 1–4 (ambito, modello delle minacce, architettura, autorizzazione)
SCOPE-01
Dichiarazione: Il documento definisce con chiarezza i rischi inclusi e quelli esclusi dall'ambito e il perimetro di sicurezza del sistema. Prove:1.3， 1.4
THREAT-01
Dichiarazione: Il modello delle minacce copre gli attacchi di rete, i download non autorizzati, i tentativi di lettura lato server o dello storage e gli attaccanti lato browser. Prove:2.2
BOUNDARY-01
Dichiarazione: I confini di fiducia separano con chiarezza le responsabilità tra client, server, object storage e ambiente esterno; il server NON DEVE ottenere la CEK. Prove:2.4
FAILCLOSE-01
Dichiarazione: In caso di errore di autenticazione o di contesto incoerente, il sistema deve bloccarsi in modo sicuro (fail closed) e non restituire alcun testo in chiaro parziale. Prove:2.5
ARCH-01
Dichiarazione: Gli oggetti dati principali sono chiaramente separati: chunk crittografati, manifest e dati di audit sono isolati tra loro. Prove:3.2
FLOW-UP-01
Dichiarazione: Il flusso di caricamento prevede la creazione di un transferId e l'emissione di token di accesso di breve durata (token di sessione basati su lookup) con controlli rigorosi su ambito e scadenza. Prove:3.3
FLOW-DL-01
Dichiarazione: I download leggono il frammento dell'URL per ottenere la CEK; le letture di manifest e chunk usano token con ambiti diversi; gli errori di autenticazione bloccano l'operazione in modo sicuro (fail closed). Prove:3.4， 2.5
AUTH-TOKEN-01
Dichiarazione: I token di accesso di breve durata sono token di sessione lato server (basati su lookup) che scadono e servono a controllare l'accesso al testo cifrato e ai manifest. Prove:4.2
AUTH-SCOPE-01
Dichiarazione: I token sono separati per ambiti come read_manifest / read_chunk / upload_chunk e vengono convalidati in modo rigoroso. Prove:4.3， 4.4， 3.4
AUTH-PAID-01
Dichiarazione: Gli utenti a pagamento accedono con un link magico monouso e ottengono un token di lunga durata, conservato sul client, per le azioni di gestione lato mittente. Prove:4.1， 3.5
REVOKE-01
Dichiarazione: Il mittente può revocare l'accesso: eliminare un trasferimento o rimuovere file invalida in anticipo i download e nega gli accessi successivi. Prove:4.5
AUDIT-01
Dichiarazione: I dati di audit, come il numero di download e l'avanzamento, sono visibili solo al mittente e non al destinatario. Prove:4.6， 3.5
LOG-01
Dichiarazione: I log e la telemetria di client e server non includono la CEK, i frammenti degli URL né alcun materiale da cui si possa derivare una chiave. Prove:4.7， 10.2
Capitolo 5 (crittografia e gestione delle chiavi)
CRYPTO-ZK-01
Dichiarazione: La CEK viene generata solo nel browser e distribuita tramite il frammento dell'URL; il server non genera mai un link di download completo che contenga la CEK. Prove:5.3.1， 5.3.2
CRYPTO-ZK-02
Dichiarazione: Il server non riceve, non memorizza e non registra nei log la CEK; l'object storage conserva solo chunk crittografati. Prove:5.0， 5.5.1
CRYPTO-E2EE-01
Dichiarazione: I chunk usano AES-128-GCM; un errore di autenticazione deve bloccare l'operazione in modo sicuro (fail closed) e non restituire alcun testo in chiaro parziale. Prove:5.4.2， 5.8.4
CRYPTO-CHUNK-01
Dichiarazione: chunkSize è fissato a 16 MB (16777216). Prove:5.4.1， 5.8.1
CRYPTO-NONCE-01
Dichiarazione: L'IV è derivato come noncePrefix(8B)||uint32_be(chunkIndex) e non deve ripetersi con la stessa CEK. Prove:5.4.3， 5.8.1
CRYPTO-AAD-01
Dichiarazione: L'AAD è legato a transferId + fileId + chunkIndex e codificato con EncodeAAD_v1. Prove:5.4.4
CRYPTO-CLIENT-01
Dichiarazione: Le pagine di download e decrittazione non caricano script di terze parti; i log e la telemetria del client non includono frammenti né materiale di chiave. Prove:5.6， 10.2
CRYPTO-TLS-01
Dichiarazione: HTTPS è imposto su tutto il sito; la configurazione TLS è verificabile tramite report pubblici di terze parti. Prove:5.1.2， /status#tls-configuration
Capitoli 6–7 (ciclo di vita dei dati / difesa dagli abusi)
LIFECYCLE-01
Dichiarazione: La scadenza e l'eliminazione avviata dall'utente attivano la pulizia; è supportata la revoca per invalidare i download in anticipo. Prove:6.2， 6.3， 4.5
ABUSE-01
Dichiarazione: La difesa dagli abusi usa limiti di frequenza e controlli a livelli, senza violare il confine zero-knowledge. Prove:7.2， 7.4
Capitoli 8–9 (privacy / sicurezza web e isolamento)
PRIVACY-01
Dichiarazione: La definizione e gli impegni zero-knowledge sono espliciti: la CEK viene generata e usata solo sul client; il server non può recuperare la chiave. Prove:8.1
PRIVACY-02
Dichiarazione: Le implicazioni sulla privacy dei frammenti degli URL (copia/incolla, fuga tramite referrer, logging) sono documentate insieme alle misure di mitigazione. Prove:8.2， 10.2
WEB-01
Dichiarazione: Le pagine chiave applicano una CSP rigorosa e confini precisi alle risorse per ridurre il rischio di injection e clickjacking. Prove:9.1， 9.3
WEB-HEADERS-01
Dichiarazione: Il livello di base delle intestazioni di sicurezza è verificabile tramite report pubblici di terze parti. Prove:/status#security-headers
WEB-OBS-01
Dichiarazione: Il sito può essere controllato con scansioni pubbliche di terze parti sulle best practice. Prove:/status#http-observatory
Capitoli 10–12 (logging e risposta agli incidenti / divulgazione delle vulnerabilità / prove)
OBS-01
Dichiarazione: L'osservabilità segue il principio del minimo indispensabile: copre solo le esigenze operative e di sicurezza e usa strategie di aggregazione e campionamento. Prove:10.1
IR-01
Dichiarazione: È definito un processo di risposta agli incidenti di sicurezza (gravità, contenimento, post mortem, rimedio e comunicazione pubblica). Prove:10.4
VDP-01
Dichiarazione: Esiste un processo di divulgazione delle vulnerabilità che dà priorità ai problemi che potrebbero incidere sul confine zero-knowledge. Prove:11.2
EV-01
Dichiarazione: La pagina di stato raccoglie i punti di accesso alle prove di terze parti; le prove rimandano a fonti autorevoli e chiariscono i limiti di applicabilità. Prove:12.2， 12.6