Vai al contenuto
HexaTransfer
Torna al blog
Crittografia e sicurezza

Architettura zero-knowledge: perché il server non vede i tuoi file

Scopri come l'architettura zero-knowledge garantisce che nemmeno il fornitore possa accedere ai tuoi file. Il modello di privacy definitivo.

L'architettura zero-knowledge significa che il fornitore del servizio non ha alcuna capacità tecnica di leggere i tuoi file — le chiavi di crittografia non raggiungono mai i suoi server, non esiste una chiave master, nessuna porta di servizio, nessun "fidati di noi". Il tuo browser cifra i file con AES-256-GCM prima dell'upload usando una chiave generata localmente, e quella chiave raggiunge il destinatario solo attraverso il frammento URL dopo #, che i browser non trasmettono mai ai server. Anche di fronte a un'ingiunzione legale valida, il fornitore può produrre solo testo cifrato. Questo è il modello usato da Tresorit, Proton, SwissTransfer e HexaTransfer, ed è matematicamente diverso dalla "crittografia a riposo".

La prova sta in ciò che il server può consegnare

Il test più chiaro di zero-knowledge: cosa potrebbe consegnare l'azienda se costretta? Nell'archiviazione cloud tradizionale (Google Drive, Dropbox, OneDrive), la risposta è: i tuoi file, in chiaro. Il rapporto sulla trasparenza di Google del 2023 mostra che ha rispettato l'83% delle richieste di dati del governo statunitense, producendo contenuti degli utenti dove richiesto dalla legge. Non è un fallimento della sicurezza di Google — è il funzionamento dell'architettura.

Con il modello zero-knowledge, l'azienda può produrre:

  • Blob di file cifrati (inutili senza la chiave)
  • Metadati dell'account (email, IP di registrazione)
  • Indirizzi IP di upload e download, timestamp
  • Informazioni di pagamento, se presenti

Non può produrre nomi di file, contenuti, identità del destinatario o chiavi di decrittazione. Non perché si rifiuti — ma perché non li possiede.

Il trucco del frammento URL, spiegato con precisione

La mossa tecnica centrale è usare il frammento URL come canale nascosto per la chiave. Quando un browser richiede https://hexatransfer.com/d/xyz789#k=BASE64KEY, invia al server solo GET /d/xyz789. Il frammento rimane nella barra degli indirizzi del browser. JavaScript poi chiama window.location.hash per leggere la chiave e la passa a crypto.subtle.decrypt().

Questa tecnica è stata pionierata da Mega.nz intorno al 2013 e perfezionata da Firefox Send prima che Mozilla lo chiudesse nel 2020. Lo schema è ora standard. I log lato server, inclusi quelli di nginx o Caddy, non catturano mai il frammento perché l'RFC 3986 HTTP lo definisce come elemento esclusivamente client-side.

Un fornitore potrebbe teoricamente registrare il frammento tramite JavaScript lato client, motivo per cui i servizi zero-knowledge pubblicano il loro codice client per l'ispezione e spesso lo distribuiscono come asset statici firmati serviti da un'origine separata.

Perché questo differisce dalla "crittografia a riposo"

Ogni fornitore cloud cifra i file a riposo — è il minimo indispensabile, spesso richiesto dalle certificazioni SOC 2 Type II e ISO 27001. Ma la "crittografia a riposo" con chiavi detenute dal fornitore significa che la crittografia è invisibile agli aggressori con dischi rubati, ma il fornitore decifra automaticamente su richiesta.

Zero-knowledge capovolge la custodia delle chiavi: tu detieni la chiave, il fornitore detiene il testo cifrato. Il fornitore non guadagna nulla tentando di decifrare perché non può. Questo conta sotto tre specifiche minacce:

  1. Dipendenti disonesti. Un dipendente con accesso al database vede solo testo cifrato.
  2. Richieste governative. Il GDPR Articolo 32 e le richieste del CLOUD Act statunitense possono imporre la divulgazione, ma non puoi divulgare ciò che non possiedi.
  3. Violazioni dei server. La violazione di LastPass del 2021 ha esposto vault cifrati; le password master deboli sono state comunque violate, ma il design zero-knowledge ha impedito l'esposizione massiva di dati in chiaro.

Cosa viene cifrato e cosa resta come metadato

Un'implementazione ingenua cifra i contenuti del file ma lascia visibili nomi, dimensioni e struttura delle cartelle. Il vero zero-knowledge cifra anche il nome del file, tipicamente aggiungendo un header JSON come {"name": "Q4-financiali.pdf", "type": "application/pdf"} ai byte del file prima della cifratura AES-GCM.

Metadati difficili da nascondere:

  • Dimensione del file — la lunghezza del testo cifrato approssima quella del testo in chiaro. Il riempimento a bucket fissi (1 MB, 10 MB, 100 MB, 1 GB) lo oscura ma spreca larghezza di banda.
  • Tempistica dell'upload — correlare i timestamp con altri dati può comunque rivelare informazioni.
  • Indirizzi IP — il fornitore vede chi ha caricato e scaricato. Abbinalo a Tor o una VPN affidabile se questo è rilevante per te.

Proton e Tresorit pubblicano matrici dettagliate di esposizione dei metadati. SwissTransfer e HexaTransfer adottano un approccio più semplice: metadati minimi, conservazione breve (da 24 ore a 7 giorni) e nessun collegamento ad account per i trasferimenti gratuiti.

Il problema dell'autenticazione

Zero-knowledge crea una sfida: se il server non può decifrare i tuoi file, come autentica l'utente per impedire a estranei di scaricare? Tre schemi comuni:

  • Autenticazione tramite link. Il possesso dell'URL (e del frammento) è l'autorizzazione. Usato da SwissTransfer, HexaTransfer, Tresorit Send. Semplice, funziona senza account.
  • Link protetti da password. Il frammento URL contiene un salt; la chiave effettiva è derivata con PBKDF2 dalla password. Il server memorizza un verificatore (hash della chiave) per rifiutare rapidamente i tentativi errati.
  • Zero-knowledge legato all'account. Proton e Tresorit derivano la chiave master dalla password di accesso tramite Argon2id, poi la usano per sbloccare le chiavi per file memorizzate cifrate sul server.

Ogni approccio ha i suoi compromessi. Il link-based è il più semplice ma espone la chiave a chiunque ottenga l'URL. La protezione tramite password aggiunge un secondo fattore. Il legame all'account richiede fiducia che il codice client non esfilri la chiave master.

Errori di implementazione che compromettono lo zero-knowledge

Alcuni fallimenti reali degni di nota:

  • Anteprime di file lato server. Se il fornitore genera miniature o estrae testo per la ricerca, ha bisogno del testo in chiaro. I servizi zero-knowledge non possono offrire queste funzionalità su contenuti cifrati.
  • Risoluzione dei conflitti di sincronizzazione. Confrontare i contenuti dei file tra dispositivi normalmente richiede il testo in chiaro. Syncthing e Cryptomator gestiscono questo con diff lato client.
  • SDK di analisi. Script di terze parti da Google Analytics o Segment possono leggere window.location.hash nel codice client. I servizi zero-knowledge usano analisi self-hosted o eliminano l'accesso al frammento.
  • Reimpostazione della password. Se il fornitore può reimpostare la tua password e darti ancora accesso ai vecchi file, deve detenere una chiave di recupero — il che rompe lo zero-knowledge. Proton avverte esplicitamente che la reimpostazione della password comporta la perdita dei dati cifrati.

Chi implementa davvero lo zero-knowledge

Un breve elenco di servizi con credibili claim zero-knowledge, verificati da audit di terze parti (Cure53, NCC Group, Trail of Bits):

  • Tresorit — svizzero, SOC 2 Type II, sincronizzazione file e Send zero-knowledge.
  • Proton Drive — svizzero, basato sul modello crittografico di Proton Mail.
  • SwissTransfer — livello gratuito con E2EE opzionale, gestito da Infomaniak.
  • Mega.nz — Nuova Zelanda, white paper crittografico pubblicato.
  • HexaTransfer — basato su browser, senza account, 10 GB per trasferimento.

Servizi cifrati ma non zero-knowledge: Google Drive, Dropbox, OneDrive, Box, iCloud (eccetto il livello Advanced Data Protection) e WeTransfer livello standard.

Come verificare prima di fidarsi

Prima di affidare a un servizio i tuoi file sensibili, esegui questa checklist:

  • L'informativa sulla privacy dichiara che il fornitore non può leggere i tuoi file?
  • Esiste un white paper di sicurezza pubblicato che cita AES-256-GCM e il KDF?
  • L'URL di condivisione contiene un frammento (testo dopo #)?
  • Ci sono report di audit di terze parti degli ultimi 24 mesi?
  • Il codice client è open source o almeno verificabile?

Quattro sì significa che hai trovato un servizio zero-knowledge. Tre o meno significa che il fornitore può vedere i tuoi file.

Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.

Invia file di grandi dimensioni in modo sicuro con crittografia end-to-end

Trasferisci file fino a 10 GB gratuitamente con crittografia end-to-end. Nessun account necessario. I tuoi file vengono crittografati nel browser prima del caricamento — nessun altro può leggerli.

Invia un file