Technical documents

Technical compliance.

CalcuLegal's data protection is not a policy — it's an architecture. This document details the technical mechanisms that make unauthorized access to user data structurally impossible, even by the platform manager.

AES-GCM 256 bit RSA-OAEP 4096 bit Vault + MFA Privacy by Design Updated: March 2026
Document summary
1
Fundamental principles
Privacy by Design

CalcuLegal's architecture is built around a single principle: no one, including the platform manager, must be able to access identifying user data except the legal professional explicitly designated by the user themselves.

This is not an objective stated in policies — it's a technical property of the system. Asymmetric encryption with keys exclusively owned by partner lawyers makes unauthorized access structurally impossible, not just forbidden by rules.

Zero-knowledge for the manager. CalcuLegal does not hold the decryption keys. Even with physical access to the database, user data is inaccessible.
Structural minimization. The simulation phase neither collects nor transmits identifying data. Data does not enter the system before explicit consent.
Key segregation. Each partner lawyer has their own pair of asymmetric keys. No data can be decrypted by a professional other than the intended recipient.
Consent as a technical trigger. Data encryption and transmission are activated exclusively by the user's explicit action. No data is transmitted before consent.
2
Simulation phase — total anonymity
GDPR Art. 5.1.c

During the completion of the calculator and until the viewing of the estimate report, no identifying data is requested, collected, or stored. The data entered by the user (type of injury, degree of disability, expenses, impact on work) is treated as anonymous input for a mathematical calculation.

Compliance with Art. 5.1.c GDPR — The principle of data minimization is met structurally: in the simulation phase, there is no personal data to minimize because no personal data enters the system.

The calculation engine operates server-side: proprietary algorithms — including the Balthazar Formula and tabular parameters (Milan Tables, TUN, Art. 139 Insurance Code) — are never exposed to the client browser. The user sends anonymous parameters and receives a structured estimate in response, without any calculation logic being transferable or replicable client-side.

What is NEVER collected in the simulation phase Persistent IP address — First and last name — Email — Phone number — Personal details — Geographical location — Device identifiers — Third-party tracking cookies.
3
Encryption architecture
AES-GCM 256 + RSA-OAEP 4096

When the user decides to request contact with a partner lawyer and gives explicit consent, identifying data is immediately encrypted using a dual-layer scheme before any writing to the database.

Activation — Explicit user consent: The user completes the double opt-in consent at the end of the simulation. Only at this moment does the system initiate the encryption process. (Irrevocable trigger, no automatic transmission).
Symmetric key generation — AES-GCM 256 bit: The server generates a unique random symmetric key specifically for this file. The key is never written to disk in plain text. The user's data is encrypted with this key (standard used in banking and military communications).
Symmetric key encryption — RSA-OAEP 4096 bit: The newly generated AES key is in turn encrypted with the receiving lawyer's RSA public key. This ensures that only the recipient can decrypt the data.
Database writing — Only encrypted blobs: The database exclusively stores: the AES-GCM encrypted blob (the data), the RSA-OAEP encrypted blob (the key), and management metadata. No plain text data is ever written to the database (Zero-knowledge database).
4
Cryptographic key management
PKI (Public Key Infrastructure)

Every partner lawyer generates or receives during onboarding a unique RSA-OAEP 4096-bit asymmetric key pair. The system is designed according to Public Key Infrastructure (PKI) principles:

Public key. Stored on the CalcuLegal server. Used to encrypt the symmetric keys of the files destined for that lawyer. It is not a secret — it can be read without compromising security.
Private key. It is never transmitted to CalcuLegal nor stored on the platform's servers. It resides exclusively in the lawyer's encrypted vault, accessible only via MFA.
Complete segregation. Files intended for Lawyer A cannot be decrypted by Lawyer B, even in the event of database access. Each public key encrypts only for its own recipient.
Key rotation. A process of periodic rotation of key pairs is established, with re-encryption of pending files, to limit exposure in case of future compromise.
Direct consequence — CalcuLegal cannot recover data of a file at the user's or lawyer's request if the lawyer's private key is lost or compromised. This is the price of absolute security: no backdoors exist, not even for those who manage the platform.
5
Encrypted vault and MFA authentication
Zero-Trust Access Control

The lawyer's RSA private key is stored in an encrypted vault accessible exclusively via multi-factor authentication (MFA). The vault is protected by an additional layer of symmetric encryption derived from the lawyer's MFA credentials.

Primary credentials. The lawyer authenticates with username and password. Passwords are stored as irreversible hashes (bcrypt or equivalent). CalcuLegal does not know the plain text password.
Second factor — Mandatory MFA. TOTP (via authenticator app or equivalent) is mandatory to access the files. Without MFA, the vault remains inaccessible even with correct primary credentials. It cannot be disabled.
Vault unlocking and decryption. Only after successful MFA authentication is the vault unlocked and the RSA private key made available in memory — never on disk — for the current session. Upon logout, the key is removed from memory (In-memory only).
6
Security in transit
TLS 1.3 — HSTS

All client-server communications occur exclusively over HTTPS with TLS 1.3. Obsolete protocols (TLS 1.0, TLS 1.1, SSL) are disabled at the server configuration level.

HSTS (HTTP Strict Transport Security). The browser is instructed not to accept unencrypted connections to the domain for a period of 12 months, with inclusion in the preload list.
Certificate Pinning. SSL certificates are automatically verified and renewed. No self-signed certificates are accepted.
Double encryption in transit. The data travels already encrypted with AES-GCM inside the TLS tunnel. Even an interception of the TLS encrypted traffic would only yield unusable AES blobs.
Content Security Policy (CSP). Restrictive CSP headers limit the sources of loadable scripts and resources, drastically reducing the XSS attack surface.
7
Metadata and SLA monitoring
GDPR Art. 5.1.b — Purpose Limitation

CalcuLegal collects and processes a minimum number of non-identifying metadata exclusively to ensure the proper functioning of the orientation service and compliance with SLAs (Service Level Agreements) with partner firms.

Metadata Purpose Duration
File ID (anonymous UUID) Internal tracking of the file flow Until file closure
Assignment timestamp 24h SLA calculation — automatic reassignment trigger 90 days
File status (assigned/replied/closed) Operational monitoring and reporting for partner firms 90 days
Recipient firm identifier Routing the file to the correct vault Until file closure
No identifying metadata — None of the listed metadata contains or allows tracing back to the user's identity. The file UUID is randomly generated and is not derived from any personal data.
8
Data breach scenario analysis
GDPR Art. 32 — Security of Processing

A data breach is the unauthorized compromise of the database or platform servers. CalcuLegal's architecture is designed so that a data breach does not produce significant harm to users, regardless of the extent of the compromise.

Attack scenario What the attacker gets User impact
Database access Encrypted AES-GCM blobs + encrypted RSA blobs + anonymous metadata Null — data is unusable without the RSA private key
Application server access Source code, RSA public keys, system logs Null — public keys do not allow decryption
Credential compromise (no MFA) Panel access, but not to the vault Null — the vault remains locked without the second factor
Full compromise (credentials + MFA) of a lawyer Access to the files of THAT single lawyer Limited to the files of the compromised professional
Physical access to servers Encrypted blobs on disk — private keys never persisted Null — private keys are never written to disk
Conclusion — In all reasonably foreseeable attack scenarios, the impact on user data is null or strictly limited to the files of the single compromised professional. The database itself — even if obtained entirely — contains no readable information.
9
GDPR Compliance — Art. 25
Privacy by Design and by Default

Art. 25 of EU Regulation 2016/679 requires the data controller to implement appropriate technical and organizational measures to implement data protection principles by design and by default.

By design. AES-GCM 256 + RSA-OAEP 4096 encryption, the MFA vault, and key segregation are an integral part of the architecture — not an afterthought.
By default. By default, the system collects no identifying data. The user must take a positive action (explicit consent) to initiate processing.
Minimization. Only data strictly necessary for the stated purpose is processed. No additional data is collected "for future utility".
Purpose limitation. Contact data is used exclusively to transmit the file to the recipient. It is not used for marketing, profiling, analytics, or sold to third parties.
Integrity and confidentiality. Dual encryption and MFA access control ensure that only the authorized subject can access the plain text data.
10
Technical summary
Synthesis
Component Adopted Standard Status
Data at rest encryption AES-GCM 256 bit ✓ Active
Symmetric key encryption RSA-OAEP 4096 bit ✓ Active
Lawyer authentication Credentials + mandatory MFA (TOTP) ✓ Active
Private key persistence In-memory only — zero disk persistence ✓ Active
Transport protocol HTTPS + TLS 1.3 — HSTS 12 months ✓ Active
Manager access to data Structurally impossible — zero-knowledge ✓ Structural
Simulation data collection Zero identifying data ✓ Structural
Transmission without consent Impossible — consent is technical trigger ✓ Structural
Third-party profiling cookies Absent — zero external tracking ✓ Compliant
External fonts and resources Self-hosted — no calls to external CDNs ✓ Compliant
Document drafted in March 2026. Artur Arkadiusz Woszczyk — VAT 05247450967
For information: info@calculegal.it — Privacy Policy — Deontological compliance