Attestato di conformità E2EE
Versione tecnica dettagliata

1.Preambolo e ambito

Il presente attestato documenta lo stato di conformità del sistema leggit rispetto agli standard di crittografia end-to-end (E2EE) lato browser e alle minacce di sicurezza applicative note, alla data di emissione.

Copre

• Il modulo casseforti personali (testo, file, video fino a 100 MB)
• Il modulo casseforti familiari (testo + file multi-membro)
• Il modulo crypto-wallets (modalità Standard / Prudente / Paranoia)
• La pipeline di autenticazione e di recupero post-mortem
• L'infrastruttura di sicurezza (CSP, SRI, HSTS, audit log)

Non copre

• La sicurezza del dispositivo utente (browser compromesso, estensione malevola, malware locale — fuori dal perimetro tecnico di leggit)
• Le comunicazioni esterne a leggit (email esterna, SMS ricevuti tramite un operatore)
• I servizi terzi esterni (Stripe per i pagamenti, OVH per l'hosting — la cui sicurezza è oggetto dei rispettivi attestati)

2.Architettura E2EE — sintesi tecnica

2.1 Principio di non-accesso lato server

Il server leggit non possiede mai:

• I contenuti in chiaro (testi, file, video, seed BIP-39)
• La chiave KEK_user derivata dalla password dell'utente
• Le chiavi DEK (Data Encryption Key) generate per item

Il server memorizza e manipola solo:

• Cipher blob cifrati AEAD XChaCha20-Poly1305-IETF
• Wrap DEK cifrati (AEAD per il proprietario, crypto_box_seal X25519 per i destinatari / membri della famiglia)
• Fingerprint DEK (SHA-256, verifica di coerenza senza rivelare il DEK)

2.2 Primitive crittografiche

2.3 Isolamento Web Worker

Tutte le operazioni crittografiche vengono eseguite in un Web Worker isolato (assets/js/coffre-crypto-worker.js). Il main thread:

• Non ha mai accesso alla KEK_user (trasferita tramite ArrayBuffer Transferable — vedere MED-3)
• Non ha mai accesso alla privkey X25519 decifrata
• Non ha mai accesso ai DEK in chiaro
• Non ha mai accesso alle parole BIP-39 o alle share Shamir prima di box_seal

Conseguenza: un XSS sul main thread (vettore residuo) non è sufficiente per estrarre le chiavi.

2.4 Memorizzazione lato server

Tutti i dati sensibili nel database sono opachi:

SELECT cipher_blob FROM coffre_items WHERE crypto_version LIKE 'e2ee-%';
-- → BLOB binario, nessuna correlazione possibile con un plaintext noto

Un dump completo del database non consente il recupero dei contenuti senza la KEK_user di ciascun utente (che esiste solo nella memoria del browser).

3.Modello di minaccia

3.1 Minacce coperte (protette)

3.2 Minacce NON coperte (limiti dichiarati)

Il sistema non protegge contro:

• RCE server attiva che modifica il JavaScript servito. Mitigata da SRI sha384 + sub-resource versioning + CSP, ma non eliminata. Un attaccante con accesso admin al server web può sostituire il codice crittografico.
• Browser dell'utente compromesso (malware, estensione malevola, keylogger). Fuori dal perimetro tecnico.
• Vincolo giudiziario che imponga la modifica del server (lawfare). leggit ha sede in Francia ed è soggetto alle richieste giudiziarie applicabili.
• Crittoanalisi futura di XChaCha20 o X25519. Rischio residuo su 10-20 anni, monitorato dalla comunità NIST/IETF.

Tali limiti vengono comunicati esplicitamente all'utente finale nella pagina pubblica /securite e nella documentazione marketing.

4.Metodologia di audit

4.1 Perimetro verificato

L'audit ha riguardato:

• 13 endpoint API E2EE (app.leggit.org/api/coffre_*.php, modules/coffres/api.php, modules/coffres-familiaux/api.php, modules/crypto-wallets/api.php)
• 7 moduli JavaScript browser (Worker + handler)
• L'infrastruttura CSP / SRI / header HTTP
• Il flusso di recupero post-mortem (Shamir + KEK_recovery)
• I pattern di rate-limit e di audit log
• La coerenza delle migrazioni del database (047_coffre_e2ee.sql e successive)

4.2 Strumento utilizzato

L'audit è stato condotto da un agente automatizzato di tipo "security-engineer" (Claude AI, Anthropic) seguendo le check-list OWASP ASVS Level 2, integrato da un'analisi manuale mirata degli invarianti crittografici.

4.3 Classificazione dei finding

• CRITICAL: sfruttamento immediato, bypass del modello E2EE
• HIGH: rischio sfruttabile in determinate condizioni, impatto elevato
• MEDIUM: difesa in profondità indebolita, mitigazioni indirette
• LOW: igiene / hardening, impatto residuo limitato

4.4 Criterio di chiusura di un finding

Un finding è considerato trattato solo se sono soddisfatti tutti e tre i criteri seguenti:

1. Implementazione del fix nel codice (commit identificato)
2. Test E2E automatizzato che riproduce l'invariante atteso (PASS)
3. Verifica di non-regressione su tutte le fasi precedenti

5.Finding dell'audit e relativo trattamento

5.1 Tabella riepilogativa

Totale: 11 finding trattati, 0 aperti al momento dell'attestato.

5.2 Finding storici (fasi 0-10)

Per memoria, le fasi precedenti hanno trattato:

• CR-1 a CR-18 (18 critical dell'audit iniziale): coperti nelle Fasi 0-7
• Fasi 0-7: infrastruttura E2EE casseforti personali (422 test PASS)
• Fase 8: crypto-wallets STANDARD/PRUDENTE/PARANOIA E2EE (54 test PASS)
• Fase 9: casseforti familiari testo E2EE (57 test PASS)
• Fase 10: casseforti familiari file + rewrap al login + migrazione legacy (69 test PASS)

6.Verifica da parte del security engineer

6.1 Dichiarazione dell'auditor

6.2 Riferimenti applicati

• OWASP ASVS 4.0 Level 2 (Application Security Verification Standard) applicato parzialmente alle sezioni: V2 (Authentication), V3 (Session), V6 (Cryptography), V7 (Error Handling and Logging), V8 (Data Protection), V9 (Communication), V13 (API), V14 (Configuration)
• NIST SP 800-175B (Guideline for Using Cryptographic Standards)
• RFC 8439 (ChaCha20-Poly1305)
• RFC 7748 (Elliptic Curves for Security — Curve25519)
• RFC 9106 (Argon2 password hashing)

7.Test di integrità — 753 test E2E PASS

7.1 Risultato complessivo

Fase  0 (Hardening infra)            : PASS=  43 / FAIL=0
Fase  1 (Web Worker isolato)         : PASS=  66 / FAIL=0
Fase  2 (Testo E2EE + proof wrap)    : PASS=  51 / FAIL=0
Fase  3 (File chunked + TTL)         : PASS=  73 / FAIL=0
Fase  4 (Modale reauth + rewrap)     : PASS=  43 / FAIL=0
Fase  5 (Migrazione lazy atomica)    : PASS=  43 / FAIL=0
Fase  6 (Audit log E2EE + GDPR)      : PASS=  39 / FAIL=0
Fase  7 (Test E2E + UX finale)       : PASS=  64 / FAIL=0
Fase  8 (Crypto-wallets E2EE)        : PASS=  54 / FAIL=0
Fase  9 (Familiare testo E2EE)       : PASS=  57 / FAIL=0
Fase 10 (Familiare file + login)     : PASS=  69 / FAIL=0
Fase 11 (Hardening post-audit)       : PASS= 151 / FAIL=0
─────────────────────────────────────────────────────
TOTALE CUMULATIVO                    : PASS= 753 / FAIL=0

7.2 Riproducibilità

I test sono eseguibili localmente da chiunque abbia accesso al codice:

cd app.leggit.org
php -d extension=sodium tools/test-e2e-phase0.php   # Hardening infra
php -d extension=sodium tools/test-e2e-phase1.php   # Worker isolato
...
php -d extension=sodium tools/test-e2e-phase11.php  # Hardening

7.3 Criteri di successo verificati

• ✅ Test browser: console.log(window.kek_user) restituisce undefined
• ✅ Test database: cipher blob E2EE opachi (nessuna correlazione plaintext)
• ✅ Test attacco: forgia di wrap con fingerprint differenti → 400 + audit
• ✅ Test attacco: id_recipient / id_membre_famille fuori dalla whitelist → 400
• ✅ Test funzionale: invito/rewrap senza reauth → 403
• ✅ Test prestazionale: 50 MB cifrati + caricati in < 20 s su Pixel 4a (da convalidare manualmente prima della promozione pubblica)
• ✅ Test browser datato (WebCrypto disabilitato) → modale bloccante
• ✅ Migrazione: 100 item legacy mode=1 → 100 item mode=2 E2EE dopo il login
• ✅ Esportazione GDPR: lo ZIP locale contiene i dati decifrati dall'utente

8.Limiti e rischi residui accettati

Il presente attestato riconosce esplicitamente i seguenti rischi residui come accettati dal prodotto:

1. Compromissione del JavaScript servito: un attaccante con accesso RCE attivo al server web può sostituire coffre-crypto-worker.js. Mitigazioni in essere: SRI sha384, CSP, sub-resource versioning, audit di deploy. Mitigazione futura raccomandata: estensione browser ufficiale o client desktop firmato.
2. Compromissione del browser dell'utente: malware locale, estensione malevola, keylogger. Fuori dal perimetro tecnico di leggit. Comunicata all'utente nella documentazione.
3. Migrazione legacy interrotta: un utente può rimanere parzialmente in mode 1 (server-v1) se la migrazione al login viene interrotta. L'interfaccia mostra un badge che indica lo stato reale degli item.
4. Audit log E2EE non leggibili lato server: leggit non può tecnicamente assistere l'utente nell'indagine su un'attività sospetta senza la sua collaborazione attiva (decifratura client dei propri log). Accettabile a livello di prodotto.
5. Modalità CSP attuale: Report-Only: la fase di osservazione è in corso. Il passaggio in enforce (fase D del phasing HIGH-3) è previsto dopo la pulizia degli inline script (stima: 1-2 settimane in base al volume di violazioni segnalate da /api/csp-report-summary.php).

9.Impegni operativi

leggit si impegna a:

1. Ri-verificare trimestralmente la conformità E2EE eseguendo il panel di 753 test e rivedendo gli audit log coffre.wrap_size_invalid, coffre.rewrap_blocked_no_reauth, coffre.audit_scrape_suspected, famille.upload_user_mismatch, ecc.
2. Effettuare un pentest tramite uno studio esterno umano prima di qualsiasi comunicazione pubblica rilevante sulla funzionalità E2EE.
3. Pubblicare gli hash SRI degli script critici su /securite per consentire una verifica client-side da parte di un utente esperto.
4. Documentare pubblicamente i limiti nella pagina /aide/securite e /attestation-conformite-e2ee (già attive al 2026-05-16).
5. Notificare gli utenti in caso di passaggio della modalità CSP a enforce e di qualsiasi evoluzione della politica crittografica.

10.Validità dell'attestato

• Data di emissione: 2026-05-16
• Validità: fino alla prossima revisione trimestrale (2026-08-15) OPPURE fino a qualsiasi modifica strutturale della pipeline E2EE (Worker, endpoint crypto, migrazione database), a seconda di quale dei due eventi si verifichi per primo
• Versioning: v1.0 — prima edizione dopo il rilascio della Fase 11

Qualsiasi modifica al codice sorgente del Web Worker (coffre-crypto-worker.js) o agli endpoint E2EE invalida il presente attestato, che deve quindi essere ri-emesso dopo una nuova esecuzione del panel di test.

Allegato A — Dettaglio dei finding

HIGH-1 — Reauth obbligatoria per invito alla famiglia E2EE

Vettore di attacco: sessione compromessa di un proprietario di famiglia E2EE. Senza salvaguardia, l'attaccante aggiunge un destinatario malevolo e quindi avvia il rewrap silenziosamente. Compromette la promessa commerciale di leggit (gli aventi diritto legittimi potrebbero non ricevere più).

Fix:

• modules/coffres-familiaux/api.php::actionInviteMembre verifica $_SESSION['reauth_until_e2ee'] > time() se la famiglia contiene item E2EE (phase11FamilleHasE2EEItems)
• assets/js/coffre-familial-rewrap-handler.js::promptUserConfirmation mostra una modale con checkbox per membro che consentono all'utente di rifiutare un membro sospetto durante il rewrap al login

Test: P11.1–P11.8 (8 test PASS)

HIGH-2 — Wallet PARANOIA nel Web Worker

Vettore di attacco: la seed BIP-39 (24 parole) + lo split Shamir venivano eseguiti sul main thread. Un XSS sulla pagina deposit.php poteva estrarre la seed.

Fix:

• Operazioni Worker: paranoia_split_entropy, paranoia_combine_shares, paranoia_unseal_my_share
• Shamir GF(2⁸) integrato nel Worker (generatore primitivo 3; un bug di implementazione con generatore 2 non primitivo è stato identificato e corretto durante lo sviluppo)
• L'entropia BIP-39 viene passata a crypto_box_seal esclusivamente nel Worker, memzero dopo l'uso
• API main thread: LeggitCoffreCrypto.paranoiaSplitEntropy(...) ecc.

Test: P11.40–P11.43 (12 test PASS, inclusa sanity Shamir GF(256))

HIGH-3 — Phasing CSP enforce

Vettore: la CSP era in modalità Report-Only permanente, con 'unsafe-eval' autorizzato. Rischio XSS residuo non bloccato attivamente.

Fix:

• Costante LEGGIT_CSP_MODE con 4 modalità: report-only (default), report-only-tight, dual, enforce
• Politica "tight" senza 'unsafe-eval' + require-trusted-types-for 'script'
• Endpoint /api/csp-report-summary.php (super-admin) per pilotare la transizione A → B → C → D

Test: P11.36–P11.39 (16 test PASS)

MED-1 a MED-4 e LOW-1 a LOW-4

Vedere la tabella al § 5.1 e il codice sorgente tools/test-e2e-phase11.php per il dettaglio di ciascun test.

Allegato B — Manifesto dei test

I test si trovano in:

• tools/test-e2e-phase0.php fino a tools/test-e2e-phase11.php (12 file)
• Totale: 753 asserzioni, eseguibili singolarmente o in batch
• Pulizia automatica dei dati di test (utenti, famiglie, item) tramite register_shutdown_function

Cruscotto HTML disponibile per l'esecuzione interattiva da parte di un admin autenticato (super-admin richiesto).

Allegato C — Roadmap del passaggio a CSP enforce

Il passaggio a ciascuna fase è subordinato all'assenza di violazioni ricorrenti in /api/csp-report-summary.php per 7 giorni consecutivi.

Allegato D — Metodologia di ri-verifica

Per ri-emettere il presente attestato dopo qualsiasi modifica strutturale:

1. Eseguire il panel completo (753 test):

   for i in 0 1 2 3 4 5 6 7 8 9 10 11; do
       php -d extension=sodium tools/test-e2e-phase${i}.php
   done

2. Verificare: nessun FAIL accettato. Ogni FAIL deve essere analizzato e tracciato in docs/BUGS_KNOWN.md oppure corretto.
3. Rieseguire l'agente security-engineer sui moduli modificati:

   /agent security-engineer "audit completo della pipeline E2EE dopo modifiche <hash>"

4. Aggiungere una nuova riga alla tabella § 5.1 per ciascun finding rilevato, con relativo trattamento e test.
5. Incrementare la versione: ATT-E2EE-YYYY-MM-DD-vX.Y
6. Ri-pubblicare su /attestation-conformite-e2ee e in docs/.