Whitepaper sulla Sicurezza

Analisi tecnica approfondita di come RocketShare protegge i tuoi file con la crittografia zero-knowledge

Questo documento fornisce una panoramica tecnica completa di come RocketShare protegge i tuoi dati. È destinato a professionisti della sicurezza, responsabili della conformità e chiunque voglia comprendere esattamente come funziona la nostra crittografia.

1. Sintesi esecutiva

RocketShare è una piattaforma di condivisione file con crittografia zero-knowledge. I file vengono crittografati lato client utilizzando AES-256-GCM prima del caricamento, e la chiave di crittografia è incorporata esclusivamente nel frammento dell'URL—una parte dell'URL che i browser non trasmettono mai ai server. Questa architettura significa che gli operatori di RocketShare non possono accedere, leggere o decrittare i file degli utenti in nessuna circostanza, incluse le richieste di intercettazione legale.

Proprietà chiave:

  • Architettura zero-knowledge — il server non possiede mai le chiavi di decrittazione
  • Crittografia end-to-end — i file vengono crittografati prima di lasciare il dispositivo del mittente e decrittati solo sul dispositivo del destinatario
  • Nessuna memorizzazione delle chiavi lato server — le chiavi esistono solo nel frammento dell'URL del link di condivisione
  • Scadenza e cancellazione automatiche — i file vengono eliminati definitivamente dopo la scadenza

2. Modello di minaccia

Contro cosa ci proteggiamo

  • Compromissione del server — anche se un aggressore ottiene accesso completo ai nostri server, i file archiviati rimangono crittografati e illeggibili senza la chiave specifica per ogni trasferimento
  • Intercettazione di rete — TLS 1.3 protegge i dati in transito; le chiavi di crittografia nei frammenti URL non vengono mai inviate sulla rete
  • Minacce interne — gli operatori di RocketShare hanno zero accesso ai contenuti dei file per progettazione, non per policy
  • Intercettazione legale — non possiamo soddisfare richieste di decrittazione perché non possediamo le chiavi; possiamo fornire solo blob crittografati e metadati

Cosa è al di fuori del nostro modello di minaccia

  • Dispositivo del mittente o destinatario compromesso — se un malware ha accesso al browser dell'utente, potrebbe intercettare chiavi o file in chiaro
  • Intercettazione del link di condivisione — chiunque ottenga il link di condivisione completo (incluso il frammento URL) può decrittare i file; gli utenti devono condividere i link in modo sicuro
  • Vulnerabilità del browser — ci affidiamo alla Web Crypto API fornita dal browser; exploit a livello di browser sono fuori dal nostro controllo

3. Implementazione della crittografia

Algoritmo

Tutta la crittografia dei file utilizza AES-256-GCM (Galois/Counter Mode), un algoritmo di crittografia autenticata simmetrica. GCM fornisce sia riservatezza che integrità, il che significa che qualsiasi manomissione del testo cifrato viene rilevata durante la decrittazione.

Generazione delle chiavi

Le chiavi di crittografia vengono generate lato client utilizzando la Web Crypto API del browser (crypto.subtle.generateKey), che si basa sul generatore di numeri pseudocasuali crittograficamente sicuro (CSPRNG) del sistema operativo.

  • Dimensione della chiave: 256 bit
  • Fonte: Web Crypto API (crypto.subtle.generateKey), basata su CSPRNG a livello di sistema operativo
  • Ambito: una chiave univoca per trasferimento (file o bundle)

Processo di crittografia

  1. L'utente seleziona i file da caricare
  2. Viene generata una chiave AES a 256 bit utilizzando crypto.subtle.generateKey()
  3. Viene generato un vettore di inizializzazione (IV) univoco a 96 bit per ogni operazione di crittografia
  4. I file vengono crittografati nel browser utilizzando AES-256-GCM tramite la Web Crypto API
  5. Il testo cifrato crittografato viene caricato sul server
  6. Il materiale della chiave grezza viene codificato in Base64url e inserito nel frammento URL (#<chiave-base64url>)

Crittografia in streaming

Per file di grandi dimensioni, RocketShare utilizza un approccio di crittografia in streaming. I file vengono elaborati in blocchi per ridurre al minimo l'utilizzo della memoria, consentendo la crittografia e il caricamento di file che superano la RAM disponibile.

Ogni blocco viene crittografato con un proprio IV a 96 bit generato casualmente (crypto.getRandomValues), garantendo un testo cifrato univoco per ogni blocco anche se il contenuto del file si ripete.

4. Gestione delle chiavi

Approccio basato sul frammento URL

La chiave di decrittazione è incorporata nel frammento URL (la porzione dopo #). Questa è la proprietà di sicurezza critica del sistema:

  • I browser non trasmettono mai i frammenti URL ai server nelle richieste HTTP (RFC 3986, Sezione 3.5)
  • Il frammento rimane interamente lato client — nella barra degli indirizzi del browser, nella cronologia e quando condiviso dall'utente
  • Il server riceve solo il percorso e i parametri di query, mai la porzione della chiave #...

Ciclo di vita delle chiavi

  1. Generazione — creata nel browser del mittente utilizzando CSPRNG
  2. Utilizzo — utilizzata immediatamente per la crittografia lato client
  3. Incorporazione — inserita nel frammento URL del link di condivisione
  4. Trasmissione — l'utente condivide il link tramite il canale sicuro preferito (email, messenger, ecc.)
  5. Decrittazione — il browser del destinatario legge il frammento e decrittografa il file
  6. Nessuna memorizzazione — le chiavi non vengono mai archiviate sul server; esistono solo nel link di condivisione

Cosa memorizza il server

Il server memorizza solo:

  • Blob di file crittografati (testo cifrato)
  • Metadati di trasferimento: nome file, dimensione file, tipo MIME, data di scadenza
  • Impostazioni di trasferimento: limite di download, hash di protezione password (se abilitato)
  • Dati a livello di account: email, token di autenticazione (non correlati alla crittografia dei file)

Il server non memorizza mai: chiavi di crittografia, contenuti dei file in chiaro o qualsiasi dato che possa essere utilizzato per derivare la chiave.

5. Ciclo di vita dei file

Caricamento

  1. L'utente seleziona i file → chiave di crittografia generata lato client
  2. File crittografati con AES-256-GCM nel browser
  3. Blob crittografati caricati sul server tramite TLS 1.3
  4. Il server memorizza il testo cifrato + metadati, restituisce l'ID del trasferimento
  5. Link di condivisione costruito: https://rocketshare.app/d/{id}#{chiave-base64url}

Archiviazione

  • I file crittografati vengono archiviati su object storage compatibile S3 ospitato nell'UE (Amsterdam)
  • I file vengono archiviati come blob crittografati opachi — il fornitore di archiviazione non può leggerli
  • I metadati vengono archiviati in PostgreSQL con crittografia a riposo sul volume del database

Download

  1. Il destinatario apre il link di condivisione
  2. Il browser estrae la chiave dal frammento URL (mai inviata al server)
  3. Il blob crittografato viene scaricato dal server
  4. La decrittazione avviene interamente nel browser del destinatario
  5. Il file in chiaro viene presentato all'utente per il download

Scadenza e cancellazione

  • I trasferimenti hanno una scadenza configurabile (da 3 a 90 giorni a seconda del piano)
  • Dopo la scadenza, un'attività di pulizia pianificata elimina definitivamente i blob crittografati dall'object storage e i record dei file dal database
  • Il record dei metadati del trasferimento (nomi dei file, dimensioni, timestamp) viene conservato in uno stato scaduto per scopi contabili e di audit, ma tutti i dati crittografati dei file vengono rimossi in modo irreversibile
  • Non vengono conservati backup dei dati dei file scaduti

6. Infrastruttura

Hosting

  • Applicazione: distribuita su Cloudflare Workers (edge compute)
  • Database: PostgreSQL, ospitato nell'UE
  • Object storage: compatibile S3, regione UE (Amsterdam)
  • Cache: Cloudflare KV (archivio chiave-valore), solo per dati di sessione e rate-limiting — mai utilizzato per contenuti di file
  • CDN: rete globale Cloudflare per asset statici e routing edge

Residenza dei dati

Tutti i server di archiviazione file e database si trovano all'interno dell'Unione Europea. Non replichiamo i dati dei file al di fuori dell'UE.

Sicurezza di rete

  • TLS 1.3 applicato su tutte le connessioni (HTTP e database)
  • HSTS con preloading — i browser ricevono istruzioni di utilizzare sempre HTTPS
  • Header di sicurezza HTTP — CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy
  • Nessun contenuto misto — tutte le risorse caricate tramite HTTPS

7. Autenticazione e controllo degli accessi

Autenticazione utente

  • Email/password — password sottoposte ad hash con scrypt (N=16384, r=16, p=1), lunghezza minima di 8 caratteri applicata
  • OAuth — SSO Google e Microsoft tramite OAuth 2.0 / OpenID Connect standard del settore
  • Gestione delle sessioni — cookie HTTP-only sicuri con attributi SameSite appropriati

Controlli di accesso ai trasferimenti

  • Accesso basato su link — chiunque abbia il link di condivisione completo può decrittare (la chiave è nell'URL)
  • Protezione con password opzionale — i trasferimenti possono richiedere una password aggiuntiva; l'hash della password viene verificato lato server prima di consegnare il blob crittografato
  • Limiti di download — numero massimo configurabile di download prima che il link venga disabilitato
  • Scadenza — scadenza automatica basata sul tempo dopo la quale i dati crittografati dei file vengono eliminati definitivamente

8. Minimizzazione e conservazione dei dati

Principio dei dati minimi

Raccogliamo solo ciò che è necessario per operare il servizio:

  • Dati dell'account: indirizzo email, nome (se fornito tramite OAuth), password sottoposta ad hash
  • Metadati del trasferimento: nomi dei file, dimensioni, tipi MIME, timestamp, date di scadenza
  • Dati di utilizzo: conteggi dei trasferimenti e archiviazione utilizzata (per l'applicazione del piano)
  • Analytics: modelli di utilizzo anonimi tramite PostHog (ospitato nell'UE, configurazione orientata alla privacy)

Cosa non raccogliamo

  • Contenuti dei file (non possiamo accedere ai blob crittografati)
  • Chiavi di crittografia
  • Indirizzi IP nell'archiviazione a lungo termine (i log di accesso sono effimeri)
  • Cronologia di navigazione o dati di tracciamento cross-site

Conservazione

  • Trasferimenti: dati crittografati dei file eliminati automaticamente alla scadenza; metadati del trasferimento conservati in stato scaduto
  • Dati dell'account: conservati finché l'account è attivo; eliminati su richiesta di cancellazione dell'account
  • Log di accesso: effimeri, non persistenti oltre il ciclo di vita della richiesta

9. Risposta agli incidenti

In caso di incidente di sicurezza:

  1. Contenimento — isolare immediatamente i sistemi interessati
  2. Valutazione — determinare l'ambito e l'impatto; grazie all'architettura zero-knowledge, una violazione del server non espone i contenuti dei file
  3. Notifica — gli utenti interessati vengono notificati entro 72 ore come richiesto dal GDPR
  4. Risoluzione — correggere la causa principale, migliorare le difese
  5. Divulgazione — divulgazione pubblica dell'incidente e della nostra risposta

I problemi di sicurezza possono essere segnalati tramite la nostra policy di Divulgazione Responsabile.

10. Limitazioni e trasparenza

Crediamo nell'essere trasparenti su cosa la nostra architettura di sicurezza protegge e cosa no:

  • Non possiamo recuperare link persi — se un utente perde il link di condivisione (incluso il frammento URL), i file crittografati non possono essere decrittati. Non abbiamo la chiave.
  • La sicurezza del link è responsabilità dell'utente — il link di condivisione è l'unica credenziale di accesso. Se viene intercettato (ad esempio, inviato tramite un canale non sicuro), l'intercettatore può decrittare i file.
  • CSP con policy di script basata su nonce — utilizziamo Content Security Policy con strict-dynamic e sorgenti di script basate su nonce, che è l'approccio raccomandato per applicazioni SSR. Gli stili inline richiedono ancora unsafe-inline a causa di Tailwind CSS.
  • Fiducia nel browser — la nostra crittografia si basa sulla Web Crypto API. Se il browser è compromesso, tutto è a rischio.
  • Visibilità dei metadati — mentre i contenuti dei file sono crittografati, i nomi dei file, le dimensioni e i timestamp sono visibili al server per scopi operativi.

Questo whitepaper è aggiornato a febbraio 2026. Aggiorniamo questo documento quando la nostra architettura di sicurezza cambia. Per domande, contattaci.