Capitolo 2 Modello di minaccia e confini di fiducia

Metadati del documento

Versione del whitepaper

v1.0

Ultimo aggiornamento

2026-01-14

2.1 Inventario delle risorse

• Riservatezza dei contenuti: i byte dei file in chiaro e le chiavi di decifratura (CEK) DEVONO essere protetti.
• Integrità dei contenuti: i dati cifrati e i metadati DEVONO rendere evidente ogni manomissione (autenticazione AEAD).
• Controllo degli accessi: token di accesso di breve durata, token di accesso del mittente e stato di revoca.
• Disponibilità: possibilità di caricare, scaricare e riprendere i trasferimenti in normali condizioni di rete.

2.2 Modello dell'attaccante

• Attaccante di rete: può osservare, ritardare, scartare e riprodurre il traffico; non può violare la crittografia moderna TLS/AEAD.
• Attaccante web: può creare link dannosi, tentare attacchi XSS/CSRF e provare l'iniezione nell'interfaccia o la prompt injection.
• Autore di abusi: può automatizzare caricamenti e download per esaurire le quote, fare scraping dei contenuti o amplificare il traffico.
• Si presume che l'avversario lato server non possieda la CEK; se la CEK viene divulgata (ad esempio condividendo il link), la riservatezza va persa per come è progettato il sistema.

2.3 Presupposti di sicurezza

• I client eseguono codice attendibile (nessuna estensione dannosa né malware); in caso contrario lo zero-knowledge non può proteggere l'endpoint.
• I frammenti degli URL (#...) non vengono trasmessi al server nelle richieste HTTP, secondo il comportamento standard dei browser.
• Le primitive crittografiche (AES-GCM, SHA-256, TLS) sono usate correttamente e non sono state violate.

2.4 Confini di fiducia

• Confine del client: la cifratura/decifratura e la gestione della CEK avvengono solo nel client.
• Confine edge/API: il server convalida i token e serve i dati cifrati e il manifest; NON DEVE venire a conoscenza della CEK.
• Confine dell'archiviazione di oggetti: conserva blocchi cifrati e manifest; è trattata come non attendibile per quanto riguarda la riservatezza.

2.5 Principio fail-closed

• In caso di errore del token, parametri non corrispondenti o errore di autenticazione AEAD, il sistema DEVE bloccarsi in modo sicuro (fail closed).
• NON DEVE restituire testo in chiaro parziale quando i controlli di integrità falliscono.
• I messaggi di errore e i log DOVREBBERO ridurre al minimo i dati sensibili e NON DEVONO includere frammenti di URL, CEK o materiali da cui sia possibile derivarle.