Logo

Whitepaper su sicurezza e privacy (panoramica)Capitolo 4

Capitolo 4 Autenticazione, autorizzazione e controllo dell'accesso

Questo capitolo definisce il modello di identità di FileBolt, i livelli di token e i limiti del controllo di accesso. Il caricamento e il download utilizzano token di accesso di breve durata (sessioni lato server, basate sulla ricerca, con scadenza, con ambito) per controllare l'accesso al testo cifrato e al manifest. Le azioni di gestione del mittente utilizzano token di accesso di lunga durata archiviati nel client. Il sistema DEVE supportare la revoca e i dati di audit DEVONO essere visibili solo al mittente.

4.0 Riepilogo

  • Token di accesso di breve durata: porte di accesso al testo cifrato/manifesto; sessione lato server (ricerca); DEVE associarsi a transferId; DEVE avere un ambito; DEVE scadere.
  • Token di accesso di lunga durata: utilizzato per la gestione del mittente (cancella/revoca/verifica); memorizzati sul client; NON DEVE essere utilizzato dai destinatari per accedere al testo cifrato.
  • Separazione delle chiavi e autorizzazione: i token controllano solo l'accesso al testo cifrato; la capacità di decrittazione proviene da CEK nel frammento URL (vedere Capitolo 5).

4.1 Modello di identità

  • Il sistema supporta un modello di identità dell'utente a pagamento per la gestione del mittente.
  • L'accesso del mittente PUÒ utilizzare un collegamento magico una tantum; il client memorizza un token di accesso di lunga durata dopo l'autenticazione riuscita.
  • I destinatari non sono tenuti ad avere un account per i download predefiniti (vedi documenti UX); l'accesso è controllato da collegamento/token.

4.2 Modello di autorizzazione e livelli di token

Vengono utilizzati due tipi di token con una rigorosa separazione delle responsabilità:

  1. Token di accesso di breve durata (sessione/ricerca): per upload/download di testo cifrato e lettura manifest; DEVE associarsi a transferId; DEVE scadere; DEVE essere ambito dall'operazione.
  2. Token di accesso di lunga durata: per azioni di gestione del mittente; NON DEVE garantire la capacità di decrittazione.

4.2.2 Esempi di ambito

  • upload_chunk: carica pezzi di testo cifrato per uno specifico transferId.
  • read_manifest: legge manifest per un transferId specifico.
  • download_chunk: scarica pezzi di testo cifrato per uno specifico transferId.

4.3 Autorizzazione al caricamento

  • Le API di caricamento DEVONO convalidare l'ambito del token e l'associazione transferId prima di accettare il testo cifrato.
  • I caricamenti di blocchi DOVREBBERO essere idempotenti per (transferId, fileId, ChunkIndex).
  • In caso di token non valido o mancata corrispondenza, il sistema DEVE fallire la chiusura.

4.4 Scarica l'autorizzazione

  • L'accesso al manifesto e al testo cifrato DEVE richiedere un token valido e con ambito; i token DEVONO essere limitati nel tempo.
  • I destinatari NON DEVONO essere in grado di enumerare altri trasferimenti o accedere a blocchi al di fuori del transferId associato.
  • La limitazione della velocità PUÒ essere applicata per la prevenzione degli abusi (vedere Capitolo 7) senza interrompere la ripristinabilità.

4.5 Revoca e invalidazione anticipata

  • I mittenti DEVONO essere in grado di revocare un trasferimento; la revoca DEVE rendere i token inutilizzabili per gli accessi successivi.
  • La revoca DOVREBBE innescare la pulizia/accelerazione TTL per il testo cifrato, ove possibile.
  • La UX del destinatario DEVE indicare chiaramente lo stato revocato/scaduto e il passaggio successivo (contattare il mittente).

4.6 Controllo e isolamento dei permessi

  • Le prove di consegna (download, conteggi) DEVONO essere visibili solo al mittente per impostazione predefinita.
  • Le API di controllo DEVONO richiedere l'autenticazione del mittente e DEVONO essere isolate dai token di accesso del destinatario.

4.7 Registrazione e minimizzazione dei dati sensibili

  • I log NON DEVONO contenere frammenti di URL, CEK o materiale chiave derivabile.
  • I registri DOVREBBERO ridurre al minimo i dati personali e concentrarsi sugli eventi rilevanti per la sicurezza (errori dei token, revoche, limiti di velocità).
  • I messaggi di errore DEVONO essere utilizzabili ma non devono divulgare segreti.

4.8 ID di reclamo correlati