Architettura a conoscenza zero spiegata

"Non possiamo vedere i vostri dati." È un'affermazione che compare su ogni pagina prodotto orientata alla privacy, ed è anche quella che più spesso risulta falsa. Nella maggior parte dei casi significa in realtà "promettiamo di non guardare" — che è una policy, non una garanzia.

L'architettura a conoscenza zero è ciò che rende quell'affermazione un fatto. È un design tecnico specifico in cui l'operatore del servizio non ha alcuna capacità crittografica di leggere i dati degli utenti — neanche se volesse, neanche se i suoi server venissero sequestrati, neanche se il suo personale fosse compromesso. In questo articolo spieghiamo esattamente cosa significa, come funziona in pratica e come Schweizerform lo implementa per le risposte dei moduli.

Cosa significa realmente "conoscenza zero"

In crittografia, "conoscenza zero" ha una definizione accademica precisa legata alle zero-knowledge proof. Nel mondo dei prodotti di sicurezza, il termine è usato più ampiamente per descrivere un sistema in cui:

• Tutta la crittografia e la decifratura avvengono sul dispositivo dell'utente, mai sul server
• Le chiavi necessarie per decifrare non raggiungono mai il server in forma utilizzabile
• Il server archivia solo testo cifrato e non può derivare, indovinare o recuperare il testo in chiaro
• La fiducia nell'operatore non è richiesta — l'architettura è dimostrabile invece che promessa

L'opposto della conoscenza zero è un sistema basato sulla fiducia in cui il server detiene le chiavi e promette di comportarsi responsabilmente. La maggior parte dei SaaS mainstream è costruita così. Non è cattiva ingegneria — è solo un diverso modello di fiducia. La conoscenza zero è il modello che si sceglie quando i dati sono troppo sensibili perché una promessa sia sufficiente.

Il problema difficile che la conoscenza zero deve risolvere

La domanda ovvia: se il server non detiene chiavi, come fanno gli utenti ad accedere, condividere moduli, decifrare risposte tra dispositivi e recuperare da una password dimenticata? Questa è la vera sfida di progettazione. Chiunque può costruire un sistema sicuro ma inutilizzabile — l'arte sta nel costruirne uno sicuro E utilizzabile.

Ogni sistema a conoscenza zero converge su una manciata di primitive crittografiche fondamentali per risolvere questo:

Come Schweizerform mette tutto insieme

Schweizerform è una piattaforma per moduli, quindi la domanda di progettazione specifica è: come permettiamo a qualcuno di creare un modulo, condividere un link pubblico, accettare risposte crittografate da chiunque su Internet e consentire solo al proprietario del modulo di leggerle — il tutto senza che il server abbia mai una copia decifrabile?

La risposta coinvolge tre livelli di chiavi: una chiave master derivata dal vostro Codice di Accesso, una coppia di chiavi RSA a livello di modulo e una chiave AES monouso per ogni risposta. Esaminiamole.

Livello 1 — La vostra chiave master

Quando vi registrate a Schweizerform, create un Codice di Accesso. Non è una password ordinaria. Non viene mai inviato ai nostri server e non può essere recuperato se perso — perché le garanzie di sicurezza dipendono esattamente da questa proprietà. Nel vostro browser, il Codice di Accesso viene passato a una funzione di derivazione di chiave (PBKDF2 con un alto numero di iterazioni e un salt per utente) per produrre una chiave master AES-256.

La chiave master esiste solo nella memoria del browser. Non tocca mai il disco in chiaro. Non lascia mai il dispositivo. È ciò che sblocca tutto il resto.

Livello 2 — La vostra coppia di chiavi del modulo

Quando create un modulo, il browser genera una coppia di chiavi RSA-OAEP. La chiave pubblica viene caricata sui nostri server e inclusa al rendering del modulo pubblico — così i rispondenti cifreranno i dati verso di voi. La chiave privata viene immediatamente cifrata con la vostra chiave master e archiviata sui nostri server come testo cifrato. Archiviamo la chiave privata cifrata, ma non possiamo decifrarla.

Poiché la chiave pubblica è, beh, pubblica, chiunque apra il modulo può usarla per cifrare una risposta. Ma solo chi possiede il vostro Codice di Accesso può derivare la chiave master, sbloccare la chiave privata e leggere la risposta. Il server è crittograficamente escluso.

Livello 3 — Una chiave unica per ogni risposta

RSA è potente ma lento, e la lunghezza del suo testo cifrato è limitata dalla dimensione della chiave. Quindi non cifriamo direttamente le risposte del modulo con RSA. Invece, quando un rispondente invia:

1. Il browser genera una nuova chiave AES-256-GCM — unica per questa risposta
2. Tutte le risposte (e gli allegati) vengono cifrate con quella chiave AES, lato client
3. La chiave AES stessa viene poi cifrata con la chiave RSA pubblica del modulo
4. Sia le risposte cifrate sia la chiave AES cifrata vengono inviate al server

Questo schema — una chiave simmetrica protetta da una chiave asimmetrica — è il modello standard di crittografia ibrida ed è usato da TLS, PGP e praticamente ogni sistema serio. Combina la velocità di AES con le proprietà di scambio di chiavi di RSA.

Il ruolo dei dati autenticati aggiuntivi (AAD)

AES-GCM non è solo crittografia — è crittografia autenticata. Produce un tag che il decifratore controlla per confermare che il testo cifrato non sia stato modificato. GCM supporta anche i Additional Authenticated Data: contesto aggiuntivo non cifrato ma legato al testo cifrato. Se quel contesto cambia, la decifratura fallisce.

Schweizerform usa l'AAD per legare ogni risposta al modulo e all'ID risposta specifici. Il formato AAD è:

submission_payload:{formId}:{submissionId}

Questo chiude una classe sottile di attacchi: anche se un aggressore in qualche modo ottenesse un blob di risposta cifrato, non potrebbe riprodurlo contro un altro modulo, né scambiare record di risposta nel database, senza che la decifratura fallisca dal lato del proprietario. Il testo cifrato è saldato al suo contesto.

Il ciclo completo, dall'inizio alla fine

In ogni passo in cui esiste testo in chiaro, esiste in un browser. In ogni passo in cui il server tocca i dati, i dati sono testo cifrato. Questa è l'intera definizione di conoscenza zero per questo caso d'uso.

Da cosa protegge — concretamente

Essere onesti su ciò che la conoscenza zero non risolve

La conoscenza zero è uno strato potente — ma non è una bacchetta magica. Un lettore ben informato merita un resoconto onesto dei suoi limiti:

• Non protegge il dispositivo del rispondente — se il browser è compromesso, il testo in chiaro è esposto alla fonte
• Non protegge da un push malevolo del codice lato client — per questo contano integrità del codice, CSP e subresource integrity
• Non cifra metadati come timestamp, conteggi delle risposte o struttura delle domande — sono necessari al funzionamento dell'app
• Non sopravvive alla perdita del Codice di Accesso — il recupero richiede una chiave di recupero condivisa detenuta da una parte fidata, che supportiamo ma dovete configurare in anticipo
• Non sostituisce una forte sicurezza di trasporto, un'autenticazione corretta o operazioni server sicure — le completa

La conoscenza zero non è un sostituto della buona ingegneria di sicurezza — è ciò che la buona ingegneria di sicurezza produce quando il modello di minaccia include l'operatore stesso.

Come verificare da soli le affermazioni di conoscenza zero

Non dovete crederci sulla parola. Aprite gli strumenti di sviluppo del browser su una pagina di risposta Schweizerform. Osservate la scheda di rete mentre inviate. Guardate il payload che lascia il vostro dispositivo. Vedrete:

• Un blob cifrato codificato in esadecimale per il payload delle risposte — nessun valore di campo leggibile
• Una chiave AES avvolta — più corta, anch'essa testo cifrato
• Un IV e un binding AAD — metadati necessari per decifrare, ma non i dati stessi

Non vedrete da nessuna parte le risposte in chiaro nella richiesta. Questo è il test. Un sistema che fallisce questo test non è a conoscenza zero, indipendentemente dalle sue affermazioni di marketing.

La conclusione

La conoscenza zero non è un punto di funzionalità — è un principio di progettazione che impone scelte ingegneristiche difficili. Tutto ciò che sembra "facile" in un SaaS classico (accesso admin ai dati, recupero password che ripristina i dati, ricerca full-text lato server sui contenuti utente) deve essere ripensato o ricostruito su basi diverse.

Ma per dati di moduli sensibili — anamnesi di pazienti, presa in carico legale, segnalazioni di whistleblower, divulgazioni finanziarie — quello sforzo è l'intero senso. L'obiettivo non è essere degni di fiducia con i dati; l'obiettivo è rendere irrilevante la questione della fiducia. Quando il server non può fisicamente leggere ciò che archivia, l'intera categoria di minacce lato operatore scompare.