Logo

Capitolo 2 Modello di minaccia e limiti di fiducia

Questo capitolo stabilisce un modello di minaccia condiviso e un vocabolario dei confini di fiducia: quali risorse proteggiamo, cosa possono fare gli aggressori, quali presupposti devono essere validi e in che modo il sistema DEVE fallire in caso di autenticazione o mancata corrispondenza dei parametri.

Metadati del documento

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

2.1 Inventario dei beni

  • Riservatezza dei contenuti: I byte del file di testo in chiaro e le chiavi di decrittazione (CEK) DEVONO essere protetti.
  • Integrità dei contenuti: il testo cifrato e i metadati DEVONO essere anti-manomissione (autenticazione AEAD).
  • Controllo degli accessi: token di accesso di breve durata, token di accesso del mittente e stato di revoca.
  • Availability: possibilità di caricare, scaricare e riprendere i trasferimenti in condizioni di rete comuni.

2.2 Modello dell'attaccante

  • Aggressore di rete: può osservare, ritardare, interrompere e riprodurre il traffico; non può violare la moderna crittografia TLS/AEAD.
  • Aggressore web: può creare collegamenti dannosi, provare XSS/CSRF e tentare l'iniezione di UI/prompt injection.
  • Attore di abusi: può automatizzare caricamenti/download per esaurire le quote, raschiare contenuti o amplificare il traffico.
  • Si presuppone che l'avversario lato server non abbia la CEK; se la CEK viene divulgata (ad esempio, collegamento condiviso), la riservatezza viene persa in base alla progettazione.

2.3 Presupposti di sicurezza

  • I client eseguono codice affidabile (nessuna estensione/malware dannoso); altrimenti la conoscenza zero non può proteggere l'endpoint.
  • Frammenti di URL (#...) non vengono trasmessi al server tramite richieste HTTP in base al comportamento standard del browser.
  • Le primitive crittografiche (AES-GCM, SHA-256, TLS) vengono utilizzate correttamente e non sono interrotte.

2.4 Confini di fiducia

  • Confine del cliente: la crittografia/decrittografia e la gestione della CEK avvengono solo nel client.
  • Limite Edge/API: il server convalida i token e fornisce testo cifrato/manifesto; NON DEVE imparare il CEK.
  • Limite di archiviazione degli oggetti: memorizza blocchi e manifest di testo cifrato; trattati come non affidabili per motivi di riservatezza.

2.5 Principio di chiusura in caso di guasto

  • In caso di errore del token, mancata corrispondenza dei parametri o errore di autenticazione AEAD, il sistema DEVE essere chiuso con esito negativo.
  • NON DEVE produrre 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 derivabili.