Whitepaper Tecnici

Questo whitepaper descrive l'architettura del sistema di Trasferimento Sicuro di PDF Pro, un meccanismo di trasferimento file con crittografia end-to-end in cui i file vengono cifrati lato client tramite AES-256-GCM prima del caricamento. Il server archivia esclusivamente testo cifrato opaco e non è in grado di decifrare, ispezionare o leggere il contenuto dei file in nessun momento. Il sistema supporta due modalità di chiave: una chiave casuale generata automaticamente (trasportata tramite il frammento URL, che non viene mai inviato al server) o una chiave derivata da passphrase tramite PBKDF2. In entrambe le modalità, la chiave di cifratura esiste solo nei browser del mittente e del destinatario. Questo documento dettaglia le primitive crittografiche, il flusso di dati, il modello di minaccia e le limitazioni documentate del sistema. Nota sulla terminologia: questo sistema non utilizza prove a conoscenza zero (ZKP). Quando affermiamo che il server ha "zero conoscenza" dei tuoi file, intendiamo che — come conseguenza della crittografia lato client — il server detiene esclusivamente testo cifrato che non è in grado di decifrare.

Il sistema di Trasferimento Sicuro segue una rigida separazione client-server in cui tutte le operazioni crittografiche avvengono esclusivamente nel browser:

• Client (Browser): Derivazione della chiave, cifratura, decifratura, lettura dei file, ricostruzione dei file.
• Server (Supabase Storage + Funzioni Serverless): Archivia i blob cifrati, gestisce i metadati (scadenza, contatore dei download), applica le policy di accesso.

Il server è progettato intenzionalmente come un "canale passivo" per i dati cifrati. Non dispone di alcuna conoscenza della chiave di cifratura, della passphrase o del contenuto dei file. Questo è garantito architetturalmente, non semplicemente tramite policy.

Tutta la cifratura dei file utilizza l'algoritmo di cifratura autenticata AES-256-GCM, accessibile tramite la Web Crypto API nativa del browser. Questo garantisce sia la riservatezza (i dati non possono essere letti) sia l'integrità (i dati non possono essere modificati senza rilevamento).

1.3.1 Parametri dell'Algoritmo

1.3.2 Implementazione della Cifratura

// Flusso di cifratura semplificato (Web Crypto API)

const iv = crypto.getRandomValues(new Uint8Array(12));
const salt = crypto.getRandomValues(new Uint8Array(16));

// Deriva la chiave dalla passphrase (vedi Sezione 1.4)
const key = await deriveKey(passphrase, salt);

// Cifra il file
const ciphertext = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv: iv },
  key,
  fileArrayBuffer
);

// Pacchetto: [salt (16B)] + [iv (12B)] + [ciphertext + tag]
const blob = concatenate(salt, iv, ciphertext);

Il blob cifrato finale è una concatenazione di tre componenti: il salt di 16 byte (usato per la derivazione della chiave), l'IV di 12 byte (usato per AES-GCM) e il testo cifrato con il tag di autenticazione GCM di 16 byte aggiunto in coda. Questo blob è ciò che il server riceve e archivia.

Il Trasferimento Sicuro supporta due modalità di chiave mutuamente esclusive. La modalità viene selezionata dal mittente al momento della creazione del trasferimento.

1.4.1 Modalità A — Chiave Generata Automaticamente (Predefinita)

Nella modalità predefinita, non è coinvolta alcuna passphrase. Il browser genera direttamente una chiave AES a 256 bit casuale e crittograficamente sicura:

• Il browser genera una chiave AES-GCM casuale a 256 bit tramite crypto.getRandomValues() e crypto.subtle.generateKey().
• La chiave viene esportata come byte grezzi e inserita nel frammento URL (#).
• Secondo la specifica HTTP, il frammento URL non viene mai inviato al server — viene elaborato esclusivamente dal browser.
• Il mittente condivide l'URL completo (incluso il frammento) con il destinatario tramite il canale preferito (es. app di messaggistica, email).
• Il browser del destinatario estrae la chiave dal frammento URL e la utilizza per decifrare il file.

1.4.2 Modalità B — Trasferimento Protetto da Passphrase

Quando il mittente sceglie di impostare una passphrase, la chiave viene derivata da essa tramite PBKDF2:

• L'utente fornisce una passphrase.
• La passphrase viene utilizzata per derivare una chiave AES-256 tramite PBKDF2-SHA256.
• Parametri: 600.000 iterazioni, salt casuale di 16 byte.
• La chiave derivata cifra il file.
• Il salt viene archiviato insieme al testo cifrato (anteposto al blob cifrato).
• La passphrase viene condivisa fuori banda (separatamente dal collegamento).
• Non è possibile recuperare la passphrase — né il server né PDF Pro possono recuperare una passphrase dimenticata.

1.4.3 Parametri PBKDF2 (Modalità B)

1.4.4 Implementazione della Derivazione della Chiave (Modalità B)

async function deriveKey(passphrase, salt) {
  // Importa la passphrase come materiale grezzo della chiave
  const keyMaterial = await crypto.subtle.importKey(
    "raw",
    new TextEncoder().encode(passphrase),
    { name: "PBKDF2" },
    false,
    ["deriveKey"]
  );

  // Deriva la chiave AES-256-GCM
  return crypto.subtle.deriveKey(
    {
      name: "PBKDF2",
      salt: salt,
      iterations: 600000,
      hash: "SHA-256"
    },
    keyMaterial,
    { name: "AES-GCM", length: 256 },
    false,
    ["encrypt", "decrypt"]
  );
}

Il ciclo di vita completo di un trasferimento sicuro segue questo percorso:

1.5.1 Invio (Caricamento) — Modalità A (Chiave Generata Automaticamente)

1. Il mittente seleziona un file nel browser.
2. Il browser genera una chiave AES-GCM casuale a 256 bit e un IV casuale di 12 byte tramite crypto.getRandomValues().
3. Il browser cifra il file usando AES-256-GCM, producendo testo cifrato + tag di autenticazione.
4. Il browser concatena [IV | testo cifrato+tag] in un unico blob.
5. Il browser carica il blob cifrato sul server tramite HTTPS.
6. Il server archivia il blob in Supabase Storage e crea un record di metadati (ID trasferimento, scadenza, limite di download, nome file, dimensione file).
7. Il server restituisce un URL di trasferimento. Il browser aggiunge la chiave esportata al frammento URL (#).
8. Il mittente condivide l'URL completo (con frammento) con il destinatario.

1.5.2 Invio (Caricamento) — Modalità B (Passphrase)

1. Il mittente seleziona un file e inserisce una passphrase nel browser.
2. Il browser genera un salt casuale di 16 byte e un IV di 12 byte tramite crypto.getRandomValues().
3. Il browser deriva una chiave AES-256 dalla passphrase usando PBKDF2 (600K iterazioni).
4. Il browser cifra il file usando AES-256-GCM, producendo testo cifrato + tag di autenticazione.
5. Il browser concatena [salt | IV | testo cifrato+tag] in un unico blob.
6. Il browser carica il blob cifrato sul server tramite HTTPS.
7. Il server archivia il blob in Supabase Storage e crea un record di metadati (ID trasferimento, scadenza, limite di download, nome file, dimensione file).
8. Il server restituisce un URL di trasferimento contenente l'ID del trasferimento.
9. Il mittente condivide l'URL di trasferimento e la passphrase con il destinatario attraverso canali separati.

1.5.3 Ricezione (Download) — Modalità A

1. Il destinatario apre l'URL di trasferimento completo (con la chiave nel frammento).
2. Il browser estrae la chiave AES dal frammento URL (non viene mai inviata al server).
3. Il browser scarica il blob cifrato dal server tramite HTTPS.
4. Il browser estrae l'IV (primi 12 byte) dal blob.
5. Il browser decifra il testo cifrato usando AES-256-GCM con la chiave e l'IV estratti.
6. Se la decifratura ha esito positivo (il tag GCM è valido), il file in chiaro viene presentato all'utente.
7. Il server aggiorna il contatore dei download e, se è abilitata la modalità burn-on-read, elimina il blob.

1.5.4 Ricezione (Download) — Modalità B

1. Il destinatario apre l'URL di trasferimento e inserisce la passphrase nel browser.
2. Il browser scarica il blob cifrato dal server tramite HTTPS.
3. Il browser estrae il salt (primi 16 byte) e l'IV (successivi 12 byte) dal blob.
4. Il browser deriva la chiave AES-256 dalla passphrase + salt usando PBKDF2 (600K iterazioni).
5. Il browser decifra il testo cifrato usando AES-256-GCM con la chiave derivata e l'IV.
6. Se la decifratura ha esito positivo (il tag GCM è valido), il file in chiaro viene presentato all'utente.
7. Se la decifratura fallisce (passphrase errata = chiave errata = tag GCM non valido), viene mostrato un errore.
8. Il server aggiorna il contatore dei download e, se è abilitata la modalità burn-on-read, elimina il blob.

Tutti i trasferimenti sicuri sono effimeri per design. Non è disponibile alcuna opzione di archiviazione permanente.

1.7.1 Opzioni di Scadenza

1.7.2 Garanzia di Eliminazione

Quando un trasferimento scade o viene bruciato alla lettura, il blob cifrato viene eliminato definitivamente da Supabase Storage. Il record dei metadati viene conservato per 30 giorni in uno stato di eliminazione temporanea (per indagini su abusi) prima di essere eliminato definitivamente. Il record dei metadati non contiene la chiave di cifratura, la passphrase né alcuna informazione che possa essere utilizzata per ricostruire il file.

1.8.1 Assunzioni

• Runtime del browser affidabile (nessuna estensione malevola)
• Canale sicuro per la condivisione del collegamento/passphrase
• La terminazione HTTPS è affidabile
• Il dispositivo del destinatario non è compromesso
• Nessuna prevenzione della cattura dello schermo

1.8.2 Fuori Ambito

• Malware sui dispositivi endpoint
• Attacchi di ingegneria sociale / phishing
• Cattura dello schermo da parte dei destinatari
• Estensioni del browser compromesse
• Attacchi di calcolo quantistico (considerazione futura)

• La robustezza della passphrase è controllata dall'utente. Possiamo applicare una lunghezza minima nell'interfaccia utente, ma non possiamo impedire agli utenti di scegliere passphrase deboli. La sicurezza della cifratura è direttamente proporzionale all'entropia della passphrase.
• La trasmissione della passphrase avviene fuori banda. Non forniamo un canale sicuro per la condivisione della passphrase. Se la passphrase viene condivisa su un canale non sicuro (ad es. email non cifrata insieme all'URL di trasferimento), il modello di sicurezza viene indebolito.
• I metadati del file non sono cifrati. Il nome del file originale e la dimensione del file vengono archiviati in chiaro sul server. Questo rivela il tipo e la natura approssimativa del file trasferito, anche se il suo contenuto rimane cifrato.
• Fiducia nel codice lato client. Gli utenti devono fidarsi che il JavaScript servito dalla nostra CDN sia il codice corretto e non modificato. Una CDN compromessa o un dirottamento DNS potrebbe servire JavaScript malevolo. Questa è una limitazione fondamentale di tutta la crittografia basata sul web.
• Nessuna segretezza in avanti. Se la passphrase viene compromessa in qualsiasi momento prima dell'eliminazione del blob cifrato, una copia archiviata del blob può essere decifrata. La modalità burn-on-read e i brevi tempi di scadenza mitigano questo rischio.
• Dipendenza dal modello di sicurezza del browser. La sicurezza del sistema dipende dall'implementazione della Web Crypto API del browser e dal suo isolamento della memoria. Un browser compromesso o un'estensione del browser malevola potrebbe compromettere tutte le protezioni lato client.
• Calcolo quantistico. AES-256 è considerato resistente ai computer quantistici (l'algoritmo di Grover riduce la sicurezza effettiva a 128 bit, che rimane non fattibile). Tuttavia, PBKDF2 con SHA-256 non è specificamente progettato per la resistenza post-quantistica. Non si tratta di una preoccupazione immediata, ma viene menzionata per completezza.

Questo whitepaper descrive l'architettura del sistema di Firma Privacy di PDF Pro, un meccanismo di firma crittografica dei documenti in cui il documento PDF non lascia mai il browser del firmatario. Il sistema utilizza ECDSA con la curva P-256 e l'hashing SHA-256 per produrre firme digitali distaccate. Solo l'hash del documento, la firma crittografica e la chiave pubblica vengono trasmessi al server. Le chiavi private vengono generate, cifrate e archiviate esclusivamente nel browser dell'utente tramite IndexedDB, protette dalla derivazione della chiave PBKDF2 (600.000 iterazioni) e dalla cifratura AES-256-GCM. Questo documento dettaglia l'architettura completa di firma e verifica, il modello di gestione delle chiavi, lo schema del payload firmato, il design della catena di audit, il modello di minaccia e le limitazioni documentate.

Il sistema di Firma Privacy è progettato attorno a un vincolo fondamentale: il documento PDF non deve mai essere trasmesso al server. Questo è garantito architetturalmente tramite un modello di firma distaccata.

• Client (Browser): Generazione delle chiavi, archiviazione delle chiavi (cifrate in IndexedDB), hashing del documento (SHA-256), generazione della firma (ECDSA P-256), verifica della firma.
• Server (Supabase): Archivia chiavi pubbliche, record di firma (hash + firma + metadati), eventi della catena di audit. Non riceve mai il documento PDF, le chiavi private o le passphrase delle chiavi.

2.3.1 Parametri dell'Algoritmo

2.3.2 Flusso di Firma

// 1. Hash del documento PDF (lato client)
const fileBuffer = await file.arrayBuffer();
const hashBuffer = await crypto.subtle.digest("SHA-256", fileBuffer);
const hashHex = Array.from(new Uint8Array(hashBuffer))
  .map(b => b.toString(16).padStart(2, '0')).join('');

// 2. Firma l'hash con la chiave privata (lato client)
const signature = await crypto.subtle.sign(
  { name: "ECDSA", hash: "SHA-256" },
  privateKey,   // CryptoKey da IndexedDB (decifrata)
  hashBuffer
);

// 3. Invia al server: hash + firma + chiave pubblica (NON il PDF)
await submitSignature({
  documentHash: hashHex,
  signature: base64Encode(signature),
  publicKey: exportedPublicKeyJWK
});

2.4.1 Generazione della Chiave

// Genera coppia di chiavi ECDSA P-256 (Web Crypto API)
const keyPair = await crypto.subtle.generateKey(
  {
    name: "ECDSA",
    namedCurve: "P-256"
  },
  true,   // estraibile (necessario per cifratura + archiviazione)
  ["sign", "verify"]
);

// Esporta la chiave pubblica come JWK per la registrazione sul server
const publicKeyJWK = await crypto.subtle.exportKey("jwk", keyPair.publicKey);

// Esporta la chiave privata come JWK per l'archiviazione cifrata
const privateKeyJWK = await crypto.subtle.exportKey("jwk", keyPair.privateKey);

Le chiavi private persistenti non vengono mai archiviate in chiaro. Prima di essere scritte su IndexedDB, la chiave privata (esportata come JSON JWK) viene cifrata usando lo stesso schema del Trasferimento Sicuro:

2.5.1 Parametri di Protezione

2.5.2 Schema di Archiviazione

// Struttura del record IndexedDB per una chiave di firma cifrata
{
  "keyId":       "uuid-v4-unique-identifier",
  "publicKey":   { /* formato JWK, non cifrato */ },
  "encryptedPrivateKey": {
    "salt":       "base64-encoded-16-bytes",
    "iv":         "base64-encoded-12-bytes",
    "ciphertext": "base64-encoded-aes-gcm-ciphertext"
  },
  "algorithm":   "ECDSA",
  "curve":       "P-256",
  "createdAt":   "2026-04-16T00:00:00.000Z",
  "userId":      "supabase-auth-user-id"
}

PDF Pro utilizza un modello di firma distaccata, il che significa che la firma viene archiviata separatamente dal documento. Questo è il meccanismo critico per la privacy: il documento non lascia mai il dispositivo del firmatario.

2.6.1 Cosa Viene Inviato al Server

• Hash SHA-256 del PDF (32 byte, codificato in esadecimale in 64 caratteri).
• Firma ECDSA sull'hash (64 byte, codificata in base64).
• Chiave pubblica del firmatario (formato JWK).
• Metadati: nome visualizzato del firmatario, email del firmatario (se autenticato), timestamp, ID firma.

2.6.2 Cosa NON Viene Inviato al Server

• Il documento PDF stesso — non viene mai trasmesso.
• La chiave privata — non lascia mai il browser.
• La passphrase di firma — non lascia mai il browser.
• Qualsiasi contenuto di pagina, testo o immagine del PDF.

Il seguente schema JSON definisce il record di firma completo archiviato sul server:

{
  "schemaVersion":  "1.0",
  "signatureId":    "uuid-v4",
  "documentHash":   "sha256-hex-64-chars",
  "hashAlgorithm":  "SHA-256",
  "signature":      "base64-encoded-ecdsa-signature",
  "signatureAlgorithm": "ECDSA",
  "curve":          "P-256",
  "publicKey": {
    "kty": "EC",
    "crv": "P-256",
    "x":   "base64url-encoded-x-coordinate",
    "y":   "base64url-encoded-y-coordinate"
  },
  "signer": {
    "identityLevel": "authenticated | self-asserted",
    "displayName":   "string or null",
    "email":         "string or null",
    "userId":        "supabase-uid or null"
  },
  "timestamp":      "ISO-8601-UTC",
  "metadata": {
    "fileName":     "original-file-name.pdf",
    "fileSize":     123456,
    "pageCount":    12,
    "clientVersion": "2.0.0",
    "userAgent":    "browser-user-agent-string"
  },
  "auditChain": {
    "previousEventHash": "sha256-of-previous-audit-event or null",
    "eventHash":         "sha256-of-this-record"
  }
}

La verifica della firma è un processo in due fasi: verifica crittografica lato client seguita da una verifica incrociata lato server.

2.8.1 Fase 1: Verifica Crittografica Lato Client

1. L'utente carica un PDF nel browser.
2. Il browser calcola l'hash SHA-256 del PDF caricato.
3. Il browser interroga il server per eventuali record di firma corrispondenti a questo hash.
4. Per ogni record di firma restituito, il browser esegue la verifica ECDSA:

   const isValid = await crypto.subtle.verify(
     { name: "ECDSA", hash: "SHA-256" },
     importedPublicKey,
     signatureBuffer,
     hashBuffer
   );

5. Se isValid === true, la firma è crittograficamente valida: il documento non è stato modificato dalla firma e la firma è stata prodotta dal titolare della chiave privata corrispondente.

2.8.2 Fase 2: Verifica Incrociata Lato Server

1. Il server conferma che la chiave pubblica nel record di firma è registrata a un utente noto (per le firme autenticate).
2. Il server conferma che il record di firma non è stato revocato.
3. Il server conferma l'integrità della catena di audit (validazione della catena hash).
4. Il server restituisce il livello di identità del firmatario e lo stato di registrazione.

2.8.3 Risultati della Verifica

Ogni evento di firma e verifica viene registrato in una catena di audit a prova di manomissione. Gli eventi sono concatenati tramite hash: ogni evento include l'hash SHA-256 dell'evento precedente, formando una catena solo-aggiunta simile a una blockchain.

2.9.1 Tipi di Evento di Audit

2.9.2 Struttura della Catena Hash

// Ogni evento di audit include:
{
  "eventId":            "uuid-v4",
  "eventType":          "DOCUMENT_SIGNED",
  "timestamp":          "ISO-8601-UTC",
  "data":               { /* payload specifico dell'evento */ },
  "previousEventHash": "sha256-of-previous-event-json",
  "eventHash":          "sha256-of-this-event-json-without-eventHash"
}

// Rilevamento delle manomissioni: per verificare la catena, calcolare:
// SHA-256(JSON.stringify(evento senza campo eventHash))
// e confermare che corrisponda a eventHash.
// Poi confermare che previousEventHash corrisponda all'eventHash dell'evento precedente.

Se viene modificato qualsiasi evento nella catena, tutti i collegamenti hash successivi si romperanno, rendendo immediatamente rilevabile la manomissione. Questo fornisce una solida garanzia di integrità della catena di audit.

Nota: Nell'interfaccia del prodotto, 'self_asserted' può essere visualizzato come 'Identità Auto-dichiarata' o 'Firma Ospite'. 'authenticated' può essere visualizzato come 'Account Autenticato'. Queste sono etichette di visualizzazione per gli stessi livelli di identità sottostanti.

2.11.1 Assunzioni

• Runtime del browser affidabile
• L'implementazione della Web Crypto API è corretta
• IndexedDB non è accessibile ad altre origini
• L'utente protegge la propria passphrase
• Il codice del server corrisponde al comportamento dichiarato

2.11.2 Fuori Ambito

• Malware sui dispositivi endpoint
• Attacchi di ingegneria sociale / phishing
• Cattura dello schermo da parte dei destinatari
• Estensioni del browser compromesse
• Attacchi di calcolo quantistico (considerazione futura)

• Non è una Firma Elettronica Qualificata (FEQ). Le firme PDF Pro non soddisfano i requisiti del Regolamento UE 910/2014 (eIDAS) per le Firme Elettroniche Qualificate. Non siamo un Prestatore di Servizi Fiduciari Qualificati (QTSP) e le nostre chiavi di firma non vengono generate su un Dispositivo per la Creazione di Firma Qualificata (QSCD).
• Non qualificata ai sensi di eIDAS. Ai sensi di eIDAS, solo le Firme Elettroniche Qualificate hanno l'equivalente giuridico delle firme autografe in tutti gli Stati membri dell'UE. Le firme PDF Pro sono al meglio firme elettroniche avanzate e il loro valore legale dipende dalla giurisdizione specifica e dal caso d'uso.
• Non approvata da Adobe. Le firme PDF Pro non compaiono nell'Adobe Approved Trust List (AATL). Quando si apre un documento firmato con PDF Pro in Adobe Acrobat, la firma non verrà visualizzata come "attendibile" nell'interfaccia di Adobe. La verifica deve essere eseguita tramite il sistema di verifica di PDF Pro.
• Non è un'autorità di certificazione. Non emettiamo certificati X.509. La nostra infrastruttura a chiave pubblica è proprietaria di PDF Pro e non è interoperabile con i sistemi PKI utilizzati da agenzie governative o autorità di certificazione.
• Non è una notarizzazione. Le firme PDF Pro non costituiscono una notarizzazione, un'apostille o alcuna forma di autenticazione documentale certificata dal governo.
• Nessuna verifica dell'identità reale. Verifichiamo gli indirizzi email tramite Supabase Auth, ma non eseguiamo la verifica del documento d'identità governativo, la verifica biometrica né la prova dell'identità di persona.

2.12.1 Per Cosa SONO Adatte le Firme PDF Pro

• Flussi di lavoro aziendali — Approvazioni di documenti interni, autorizzazioni del team, autorizzazioni agli acquisti in cui le parti si fidano del modello di identità di PDF Pro.
• Verifica dell'integrità — Dimostrare che un documento non è stato modificato da un momento specifico nel tempo.
• Non ripudio (limitato) — Dimostrare che il titolare di una specifica chiave privata ha firmato un documento specifico in un momento specifico. La solidità del non ripudio dipende da quanto bene è protetta la chiave privata e da come la chiave pubblica è associata a un'identità.
• Conformità agli audit — Fornire una catena di audit a prova di manomissione degli eventi di firma dei documenti per i requisiti di conformità interni.
• Firma di contratti — In molte giurisdizioni, le firme elettroniche (incluse quelle non qualificate) sono giuridicamente valide per la maggior parte dei contratti commerciali ai sensi di leggi come ESIGN (USA), UETA (USA) e eIDAS articolo 25(1) (UE).