Logo

Capitolo 3 Architettura del sistema e flusso di dati

Questo capitolo descrive i componenti del sistema di alto livello e il flusso di dati end-to-end per il caricamento, il download e la gestione dei mittenti. L'attenzione si concentra su cosa viene crittografato, quali metadati sono richiesti e come vengono applicati il ​​controllo e la revoca dell'accesso.

Metadati del documento

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

3.1 Componenti

  • Client: suddivide i file in blocchi, crittografa/decrittografa e gestisce la CEK nel frammento dell'URL.
  • API/Edge: emette e convalida token con ambito; serve pezzi manifest e testo cifrato.
  • Archiviazione oggetti: memorizza blocchi e manifest crittografati; trattati come non attendibili per la riservatezza del testo in chiaro.
  • Negozio statale: tiene traccia dello stato del trasferimento (avanzamento del caricamento, scadenza, revoca) con metadati minimi.

3.2 Oggetti dati

  • Manifest: parametri pubblici richiesti per recuperare e assemblare blocchi (cryptoVersion, dimensione/conteggio dei blocchi, mappatura); NON DEVE contenere CEK.
  • Chunk: pezzo di file crittografato (testo cifrato) più metadati minimi (lunghezza/etag), indirizzato da (transferId, fileId, ChunkIndex).
  • State: record lato server per autorizzazione, TTL, revoca e ripristinabilità.

3.3 Flusso di caricamento

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

3.4 Scarica il flusso

  1. Il destinatario apre il collegamento di condivisione. Il frammento URL (materiale CEK) rimane nel browser e non viene inviato al server.
  2. Il client recupera il manifesto utilizzando un token di download con ambito e determina il piano dei blocchi.
  3. Il client scarica blocchi di testo cifrato (facoltativamente in parallelo), verifica l'autenticazione AEAD, quindi assembla il file di testo normale.
  4. In caso di errori, il client riprende richiedendo solo i blocchi mancanti; i fallimenti di integrità DEVONO fallire chiusi.

3.5 Gestione del mittente e flusso di audit

  • I mittenti si autenticano utilizzando un token di accesso di lunga durata (memorizzato sul client) per le operazioni di gestione.
  • Le API di gestione consentono di elencare i trasferimenti, controllare le prove di consegna e revocare/eliminare i trasferimenti.
  • I dati di controllo sono progettati per essere visibili solo al mittente; per impostazione predefinita non è esposto ai destinatari.

3.6 Visibilità e minimizzazione

  • Il server e l'archiviazione gestiscono solo il testo cifrato e i parametri pubblici necessari; non possono decrittografare il contenuto senza CEK.
  • I registri e le analisi DEVONO essere ridotti al minimo e NON DEVONO includere frammenti di URL o materiale CEK.
  • La raccolta dei metadati DOVREBBE essere limitata allo scopo (prove di consegna, prevenzione degli abusi e affidabilità operativa).