Conformità Tecnica — CalcuLegal

1

Principi fondamentali

Privacy by Design

L'architettura di CalcuLegal è costruita attorno a un principio unico: nessun soggetto, incluso il gestore della piattaforma, deve poter accedere ai dati identificativi degli utenti se non il professionista legale espressamente designato dall'utente stesso.

Questo non è un obiettivo dichiarato nelle policy — è una proprietà tecnica del sistema. La cifratura asimmetrica con chiavi di proprietà esclusiva degli avvocati partner rende l'accesso non autorizzato impossibile per architettura, non solo per regola.

Zero-knowledge per il gestore. CalcuLegal non detiene le chiavi di decifratura. Anche con accesso fisico al database, i dati degli utenti sono inaccessibili.

Minimizzazione strutturale. La fase di simulazione non raccoglie né transita dati identificativi. Il dato non entra nel sistema prima del consenso esplicito.

Segregazione delle chiavi. Ogni avvocato partner ha una propria coppia di chiavi asimmetriche. Nessun dato è decifrabile da un professionista diverso dal destinatario.

Consenso come trigger tecnico. La cifratura e la trasmissione dei dati vengono attivate esclusivamente dall'azione esplicita dell'utente. Nessun dato transita prima del consenso.

2

Fase di simulazione — anonimato totale

GDPR Art. 5.1.c

Durante la compilazione del calcolatore e fino alla visualizzazione del report di stima, nessun dato identificativo viene richiesto, raccolto o memorizzato. I dati inseriti dall'utente (tipo di lesione, grado di invalidità, spese, impatto lavorativo) sono trattati come input anonimi di un calcolo matematico.

Conformità Art. 5.1.c GDPR — Il principio di minimizzazione del dato è soddisfatto in modo strutturale: nella fase di simulazione non esiste un dato personale da minimizzare, perché nessun dato personale entra nel sistema.

Il motore di calcolo opera lato server: gli algoritmi proprietari — inclusa la Formula di Balthazar e i parametri tabellari (Tabelle Milano, TUN, art. 139 C.d.A.) — non sono mai esposti al browser del client. L'utente invia parametri anonimi e riceve in risposta una stima strutturata, senza che nessuna logica di calcolo sia trasferibile o replicabile lato client.

Cosa NON viene mai raccolto nella fase di simulazione Indirizzo IP persistente — Nome e cognome — Email — Numero di telefono — Dati anagrafici — Posizione geografica — Identificativi del dispositivo — Cookie identificativi di terze parti.

3

Architettura di cifratura

AES-GCM 256 + RSA-OAEP 4096

Quando l'utente decide di richiedere il contatto con un avvocato partner e rilascia il consenso esplicito, i dati identificativi vengono immediatamente cifrati secondo uno schema a doppio livello prima di qualsiasi scrittura su database.

Attivazione — Consenso esplicito dell'utente: L'utente completa la doppia spunta di consenso al termine della simulazione. Solo in questo momento il sistema avvia il processo di cifratura. (Trigger irrevocabile, nessuna trasmissione automatica).

Generazione chiave simmetrica — AES-GCM 256 bit: Il server genera una chiave simmetrica casuale univoca per questa pratica specifica. La chiave non viene mai scritta su disco in chiaro. I dati dell'utente vengono cifrati con questa chiave (standard usato nelle comunicazioni bancarie e militari).

Cifratura della chiave simmetrica — RSA-OAEP 4096 bit: La chiave AES appena generata viene a sua volta cifrata con la chiave pubblica RSA dell'avvocato destinatario. Questo garantisce che solo il destinatario possa decifrare i dati.

Scrittura su database — Solo blob cifrati: Il database archivia esclusivamente: il blob cifrato con AES-GCM (i dati), il blob cifrato con RSA-OAEP (la chiave) e i metadati di gestione. Nessun dato in chiaro viene mai scritto su database (Database zero-knowledge).

4

Gestione delle chiavi crittografiche

PKI (Public Key Infrastructure)

Ogni avvocato partner genera o riceve all'onboarding una coppia di chiavi asimmetriche RSA-OAEP 4096 bit univoca. Il sistema è progettato secondo i principi della Public Key Infrastructure (PKI):

Chiave pubblica. Archiviata sul server CalcuLegal. Usata per cifrare le chiavi simmetriche delle pratiche destinate a quell'avvocato. Non è un segreto — può essere letta senza compromettere la sicurezza.

Chiave privata. Non viene mai trasmessa a CalcuLegal né archiviata sui server della piattaforma. Risiede esclusivamente nel vault cifrato dell'avvocato, accessibile solo tramite MFA.

Segregazione completa. Le pratiche destinate all'Avvocato A non sono decifrabili dall'Avvocato B, anche in caso di accesso al database. Ogni chiave pubblica cifra solo per il proprio destinatario.

Rotazione delle chiavi. È previsto un processo di rotazione periodica delle coppie di chiavi, con re-cifratura delle pratiche pendenti, per limitare l'esposizione in caso di compromissione futura.

Conseguenza diretta — CalcuLegal non può recuperare dati di una pratica su richiesta dell'utente o dell'avvocato se la chiave privata dell'avvocato è persa o compromessa. Questo è il prezzo della sicurezza assoluta: nessuna backdoor esiste, nemmeno per chi gestisce la piattaforma.

5

Vault cifrato e autenticazione MFA

Zero-Trust Access Control

La chiave privata RSA dell'avvocato è archiviata in un vault cifrato accessibile esclusivamente tramite autenticazione a più fattori (MFA). Il vault è protetto da un layer aggiuntivo di cifratura simmetrica derivata dalle credenziali MFA dell'avvocato.

Credenziali primarie. L'avvocato si autentica con username e password. Le password sono archiviate come hash irreversibile (bcrypt o equivalente). CalcuLegal non conosce la password in chiaro.

Secondo fattore — MFA obbligatorio. Il TOTP (via app authenticator o equivalente) è obbligatorio per accedere alle pratiche. Senza MFA, il vault rimane inaccessibile anche con credenziali primarie corrette. Non è disabilitabile.

Sblocco vault e decifratura. Solo dopo autenticazione MFA completa il vault viene sbloccato e la chiave privata RSA resa disponibile in memoria — mai su disco — per la sessione corrente. Al logout, la chiave è rimossa dalla memoria (In-memory only).

6

Sicurezza in transito

TLS 1.3 — HSTS

Tutte le comunicazioni tra client e server avvengono esclusivamente su HTTPS con TLS 1.3. I protocolli obsoleti (TLS 1.0, TLS 1.1, SSL) sono disabilitati a livello di configurazione server.

HSTS (HTTP Strict Transport Security). Il browser è istruito a non accettare connessioni non cifrate verso il dominio per un periodo di 12 mesi, con inclusione nella preload list.

Certificate Pinning. I certificati SSL sono verificati e rinnovati automaticamente. Nessun certificato autofirmato è accettato.

Double encryption in transito. I dati viaggiano già cifrati con AES-GCM dentro il tunnel TLS. Anche un'intercettazione del traffico cifrato TLS produrrebbe solo blob AES inutilizzabili.

Content Security Policy (CSP). Header CSP restrittivi limitano le sorgenti di script e risorse caricabili, riducendo drasticamente la superficie di attacco XSS.

7

Metadati e monitoraggio SLA

GDPR Art. 5.1.b — Limitazione Finalità

CalcuLegal raccoglie e tratta un numero minimo di metadati non identificativi esclusivamente per garantire il corretto funzionamento del servizio di orientamento e il rispetto degli SLA (Service Level Agreement) con gli studi partner.

Metadato	Finalità	Durata
ID pratica (UUID anonimo)	Tracciamento interno del flusso pratica	Fino a chiusura pratica
Timestamp di assegnazione	Calcolo SLA 24h — attivazione riassegnazione automatica	90 giorni
Stato pratica (assegnata/risposta/chiusa)	Monitoraggio operativo e reportistica verso studi partner	90 giorni
Identificativo studio destinatario	Routing della pratica al vault corretto	Fino a chiusura pratica

Nessun metadato identificativo — Nessuno dei metadati elencati contiene o permette di risalire all'identità dell'utente. L'UUID di pratica è generato casualmente e non è derivato da alcun dato personale.

8

Analisi scenario data breach

GDPR Art. 32 — Sicurezza Trattamento

Un data breach è la compromissione non autorizzata del database o dei server della piattaforma. L'architettura di CalcuLegal è progettata in modo che un data breach non produca un danno significativo per gli utenti, indipendentemente dall'entità della compromissione.

Scenario di attacco	Cosa ottiene l'attaccante	Impatto utente
Accesso al database	Blob AES-GCM cifrati + blob RSA cifrati + metadati anonimi	Nullo — i dati sono inutilizzabili senza la chiave privata RSA
Accesso al server applicativo	Codice sorgente, chiavi pubbliche RSA, log di sistema	Nullo — le chiavi pubbliche non permettono decifratura
Compromissione credenziali (senza MFA)	Accesso al pannello, ma non al vault	Nullo — il vault rimane bloccato senza il secondo fattore
Compromissione completa (credenziali + MFA) di un avvocato	Accesso alle pratiche di QUEL solo avvocato	Limitato alle pratiche del professionista compromesso
Accesso fisico ai server	Blob cifrati su disco — chiavi private mai persistite	Nullo — le chiavi private non sono mai scritte su disco

Conclusione — In tutti gli scenari di attacco ragionevolmente ipotizzabili, l'impatto sui dati degli utenti è nullo o strettamente limitato alle pratiche del singolo professionista compromesso. Il database in sé — anche ottenuto integralmente — non contiene informazioni leggibili.

9

Conformità GDPR — Art. 25

Privacy by Design e by Default

L'art. 25 del Regolamento UE 2016/679 impone che il titolare del trattamento metta in atto misure tecniche e organizzative adeguate per attuare i principi di protezione dei dati fin dalla progettazione (by design) e per impostazione predefinita (by default).

By design. La cifratura AES-GCM 256 + RSA-OAEP 4096, il vault MFA e la segregazione delle chiavi sono parte integrante dell'architettura — non aggiunta successiva.

By default. Per impostazione predefinita il sistema non raccoglie dati identificativi. L'utente deve compiere un'azione positiva (consenso esplicito) per avviare il trattamento.

Minimizzazione. Vengono trattati solo i dati strettamente necessari allo scopo dichiarato. Nessun dato aggiuntivo è raccolto "per futura utilità".

Limitazione della finalità. I dati di contatto sono usati esclusivamente per trasmettere la pratica al destinatario. Non sono usati per marketing, profilazione, analytics o cessione a terzi.

Integrità e riservatezza. La doppia cifratura e il controllo di accesso MFA garantiscono che solo il soggetto autorizzato possa accedere ai dati in chiaro.

10

Riepilogo tecnico

Sintesi

Componente	Standard adottato	Stato
Cifratura dati a riposo	AES-GCM 256 bit	✓ Attivo
Cifratura chiave simmetrica	RSA-OAEP 4096 bit	✓ Attivo
Autenticazione avvocato	Credenziali + MFA obbligatorio (TOTP)	✓ Attivo
Persistenza chiave privata	In-memory only — zero persistenza su disco	✓ Attivo
Protocollo di trasporto	HTTPS + TLS 1.3 — HSTS 12 mesi	✓ Attivo
Accesso gestore ai dati	Impossibile per architettura — zero-knowledge	✓ Strutturale
Raccolta dati simulazione	Zero dati identificativi	✓ Strutturale
Trasmissione senza consenso	Impossibile — consenso è trigger tecnico	✓ Strutturale
Cookie profilazione terzi	Assenti — zero tracciamento esterno	✓ Conforme
Font e risorse esterne	Self-hosted — nessuna chiamata a CDN esterni	✓ Conforme

Documento redatto in data marzo 2026. Artur Arkadiusz Woszczyk — P.IVA 05247450967
Per informazioni: info@calculegal.it — Privacy Policy — Conformità deontologica

Conformità tecnica.