Logo

Capitolo 3 Architettura del sistema e flusso dei dati

Questo capitolo descrive i componenti di alto livello del sistema e il flusso dei dati end-to-end per caricamento, download e gestione da parte del mittente. L'attenzione è su ciò che viene cifrato, su quali metadati sono necessari e su come vengono applicati il controllo degli accessi e la revoca.

Metadati del documento

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

3.1 Componenti

  • Client: suddivide i file in blocchi, li cifra e decifra e gestisce la CEK nel frammento dell'URL.
  • API/Edge: emette e convalida token con ambito limitato; serve il manifest e i blocchi di testo cifrato.
  • Storage a oggetti: conserva blocchi cifrati e manifest; è considerato non attendibile per la riservatezza del testo in chiaro.
  • Archivio di stato: tiene traccia dello stato del trasferimento (avanzamento del caricamento, scadenza, revoca) con metadati minimi.

3.2 Oggetti dati

  • Manifest: parametri pubblici necessari per recuperare e assemblare i blocchi (cryptoVersion, dimensione e numero dei blocchi, mappatura); NON DEVE contenere la CEK.
  • Blocco: porzione di file cifrata (testo cifrato) più metadati minimi (lunghezza/etag), indirizzata da (transferId, fileId, chunkIndex).
  • Stato: record lato server per autorizzazione, TTL, revoca e ripresa.

3.3 Flusso di caricamento

  1. Il client crea un trasferimento e riceve un token di caricamento di breve durata, con ambito limitato e legato a transferId.
  2. Il client genera localmente la CEK di ogni file, suddivide i file in blocchi di dimensione fissa e cifra ogni blocco con AEAD.
  3. Il client carica i blocchi di testo cifrato in parallelo; i nuovi tentativi sono idempotenti per blocco.
  4. Il client carica il manifest (solo parametri pubblici). Il server contrassegna il trasferimento come READY quando sono presenti le parti richieste.

3.4 Flusso di download

  1. Il destinatario apre il link di condivisione. Il frammento dell'URL (materiale della CEK) resta nel browser e non viene inviato al server.
  2. Il client recupera il manifest con un token di download a ambito limitato e determina il piano dei blocchi.
  3. Il client scarica i blocchi di testo cifrato (se vuole, in parallelo), verifica l'autenticazione AEAD e poi assembla il file in chiaro.
  4. In caso di errori, il client riprende richiedendo solo i blocchi mancanti; gli errori di integrità DEVONO causare un fallimento in modalità chiusa (fail closed).

3.5 Gestione da parte del mittente e flusso di audit

  • Per le operazioni di gestione, i mittenti si autenticano con un token di accesso di lunga durata (conservato sul client).
  • Le API di gestione permettono di elencare i trasferimenti, controllare le prove di consegna e revocare o eliminare i trasferimenti.
  • I dati di audit sono pensati per essere visibili solo al mittente; per impostazione predefinita non sono esposti ai destinatari.

3.6 Visibilità e minimizzazione

  • Il server e lo storage gestiscono solo il testo cifrato e i parametri pubblici necessari; senza la CEK non possono decifrare il contenuto.
  • I log e le analisi DOVREBBERO essere ridotti al minimo e NON DEVONO includere frammenti di URL né materiale della CEK.
  • La raccolta dei metadati DOVREBBE essere limitata allo scopo (prove di consegna, prevenzione degli abusi e affidabilità operativa).