Documentazione LOCUS.

1. Manuale operatore v1.0

Questo manuale si rivolge all'operatore: chi installa l'app LOCUS sul proprio dispositivo mobile (Android o iOS) per documentare un sopralluogo forense, una scena del crimine, un'ispezione tecnica o qualsiasi situazione che richieda evidenze digitali a valore probatorio rinforzato.

1.1 Prima dell'acquisizione

• Account: registrarsi su locus.acquisizioniforensi.com con e-mail e password ≥10 caratteri. Confermare l'indirizzo cliccando il link ricevuto via e-mail (validità 24 h).
• Pacchetto slot: acquistare un pacchetto dalla dashboard (1 slot = 1 foto o 1 audio, 2 slot = 1 video; +2 slot opzionali per marca temporale eIDAS qualificata InfoCert). Pagamento via Stripe, accredito istantaneo.
• API key: in dashboard → API key, generare la chiave personale e copiarla nell'app alla prima apertura (schermata Login).
• Installazione app: scaricare il pacchetto dalla pagina Download (Android APK firmato, iOS via TestFlight, desktop dmg/msi/AppImage).
• Permessi sistema: l'app richiede fotocamera, microfono (per video + commento audio), GPS preciso, lettura archivio file. Da Impostazioni → LOCUS verificare che siano tutti attivi.
• Connettività: prevedere copertura dati al momento dell'upload del bundle finale (durante la cattura la connessione non è strettamente necessaria, ma serve la sincronizzazione NTP iniziale e l'upload finale).

1.2 Acquisizione foto

1. Avviare l'app → schermata Home.
2. Inserire case number (codice univoco del caso forense — facoltativo ma raccomandato per organizzare la library).
3. Premere "Scatta foto". L'app esegue automaticamente: sync NTP triplo (Cloudflare / Google / pool.ntp) → cattura fotocamera nativa → watermark burn-in 3 righe (timestamp NTP, UUID acquisizione, GPS + heading) → preservazione EXIF originali della camera + inject LOCUS Software/UserComment → hash MD5+SHA-256+SHA-512 streaming → marca temporale RFC 3161 → firma Ed25519 del manifest → sidecar CASE/UCO 1.3 JSON-LD → report PDF forense → assembly BagIt RFC 8493 → tagmanifest TSA → upload server.
4. Modal Progress 13 step mostra l'avanzamento in tempo reale.
5. Opzionalmente: registrare un commento audio post-scatto (max 15 secondi, AAC m4a) che viene incluso nel bundle e linkato nell'e-mail di conferma.
6. Al termine: e-mail di conferma all'indirizzo dell'account (e PEC se configurata) con link al bundle e al permalink pubblico /verify/<short_code>.

1.3 Acquisizione video

1. Premere "Registra video". Si apre la modal REC fullscreen con preview fotocamera dal vivo (CameraX su Android, AVFoundation su iOS).
2. L'overlay nativo mostra timestamp NTP-sincronizzato, GPS dinamico, UUID e bussola (NESW) — questi dati vengono "burned-in" al momento della registrazione, non aggiunti dopo.
3. Hard cap 20 minuti per file (limite Android Camera2). Per acquisizioni più lunghe usare più segmenti.
4. Stop → pipeline identica alla foto, in più: polyline GPS nel bundle, statistiche velocità/distanza (haversine + Δd/Δt), estrazione di 5 fotogrammi chiave (restano nel bundle: al server vengono trasmessi solo i loro istogrammi, mai i frame reali).
5. Gestione orfani: se l'app crasha durante la pipeline, alla riapertura propone 3 scelte: sigilla incompleto / scarta / lascia.

1.4 Acquisizione audio

1. Premere "Audio" dalla Home. Si apre il recorder con timer e tasto STOP (recorder nativo: AudioRecord su Android, AVAudioRecorder su iOS).
2. La traccia è registrata in WAV PCM 16-bit lossless — nessuna ricompressione, nessun watermark, nessun overlay: il file resta byte-per-byte quello catturato. Durante la registrazione il GPS viene campionato a ~1 Hz per il log del percorso.
3. Stop → pipeline forense identica alla foto: sync NTP → hash MD5+SHA-256+SHA-512 → marca temporale RFC 3161 → manifest firmato Ed25519 → sidecar CASE/UCO → waveform renderizzata (solo ausilio visivo) → report PDF → BagIt RFC 8493 + tagmanifest TSA → upload.
4. Costo: 1 slot (3 con marca eIDAS qualificata InfoCert), come la foto.
5. La catena di custodia dell'audio vive interamente nel bundle firmato (manifest + TSA + hash): l'autenticità non dipende da alcuna alterazione della traccia.

1.5 Dashboard utente

Dall'area riservata /dashboard l'operatore può:

• Library: lista cronologica di tutte le acquisizioni con filtro tipo / case number / range data; dettaglio bundle con anteprima istogramma, link al PDF e al permalink pubblico, hash e firma.
• Devices: gestire i dispositivi registrati (binding Trust-On-First-Use della pubkey Ed25519). Revoca remota in caso di smarrimento.
• Slot: saldo residuo + acquisto pacchetti + estratto conto dettagliato.
• Ordini: storico fatture e ricevute PDF.
• Ticket: supporto tecnico via sistema di ticketing integrato.

1.6 Buone pratiche forensi

• Consenso al ritratto: se sono ripresi volti riconoscibili di persone fisiche, verificare il fondamento giuridico del trattamento (consenso, interesse pubblico, esecuzione di un obbligo legale). L'app non fa pseudonimizzazione automatica.
• Pre-check dispositivo: batteria > 30%, spazio libero > 1 GB per video lunghi, GPS fix acquisito (icona verde), nessun aggiornamento di sistema in corso.
• Validator desktop: scaricare il Locus Validator sul portatile per verificare in autonomia il bundle al rientro in studio, prima di consegnarlo al cliente o al magistrato.

2. Manuale di verifica v1.0

Questo manuale si rivolge a chi riceve un bundle LOCUS e deve verificarne l'integrità in autonomia: consulente di parte avversa, magistrato, pubblico ministero, polizia giudiziaria, giudice o controparte privata. Esistono tre modalità di verifica, dalla più semplice alla più granulare.

2.1 Verifica via permalink pubblico

Ogni acquisizione ha un short code a 6 caratteri (es. X3K9PM) inserito nel report PDF e nelle e-mail di conferma. Aprire https://locus.acquisizioniforensi.com/verify/<short_code> mostra una pagina pubblica con:

• Istogramma del media (foto) o istogrammi per-fotogramma (video) — per riservatezza l'immagine reale non è pubblicata; gli hash percettivi firmati la legano all'istogramma.
• Posizione GPS indicata come presente nel bundle ma non divulgata (riservatezza): coordinate, mappa e percorso restano nel bundle sigillato.
• Timeline marche temporali RFC 3161 ricalcolate lato server (autorità, istante, status).
• Hash completi MD5 + SHA-256 + SHA-512 del media.
• Firma Ed25519 verificata + identità del device che ha sigillato.
• Catena di custody completa (operatore, slot consumati, tipo TSA, conformance standard).

Adatta a una verifica rapida di una singola acquisizione. Richiede solo un browser.

2.2 Verifica con Locus Validator (desktop, offline)

L'Locus Validator è un'app desktop standalone (Windows / macOS / Linux) che esegue tutte le verifiche tecniche del bundle senza upload, senza account, senza connessione. Pensata specificamente per CT/PM/giudici che vogliono verificare in totale indipendenza dal Fornitore.

1. Scaricare l'app dalla pagina Download.
2. Trascinare il file .zip del bundle nella finestra dell'app.
3. L'app esegue automaticamente i 10 controlli del § 2.4 e produce un report a schermo (verde/giallo/rosso per ogni passaggio) e un PDF forense scaricabile.

Tutta la logica è in Rust + verificabile dal codice sorgente (repository GitHub, AGPL-3.0). Nessuna telemetria, nessun tracciamento.

2.3 Verifica inclusa nel bundle (zero installazioni)

Ogni bundle LOCUS è auto-verificante: contiene gli strumenti per controllarlo senza scaricare né installare nulla. Nella radice del pacchetto trovi:

• verify.sh (macOS/Linux) e verify.bat (Windows) — script che ricalcolano tutti gli hash (manifest-sha256.txt + tagmanifest-sha256.txt) e verificano le due marche temporali RFC 3161 con openssl. Si lanciano dalla radice del bundle e stampano BUNDLE VALIDO oppure l'elenco dei controlli falliti.
• tsa-ca.pem — bundle dei root CA delle TSA (Sectigo, DigiCert, GlobalSign, InfoCert): la verifica della marca temporale gira completamente offline, senza scaricare certificati.
• data/interactive.html — un report interattivo apribile con doppio clic in qualunque browser (nessuna connessione): espone tutti i dati del reperto (acquisizione, dispositivo, GPS, camera/audio, catena di custodia, firma) e include due strumenti di validazione in-browser — (a) trascini il file media e ne ricalcola lo SHA-256 confrontandolo con quello firmato; (b) selezioni la cartella del bundle e ri-hasha tutti i file contro manifest-sha256.txt (tabella OK/Modificato/Mancante).

Gli script e il CA bundle sono inclusi in tagmanifest-sha256.txt, l'HTML in manifest-sha256.txt: anche gli strumenti di verifica sono quindi sigillati dalla marca temporale.

2.4 Verifica manuale a riga di comando

Tutte le verifiche del Validator sono riproducibili a mano con strumenti standard unzip, shasum, openssl, python3. Sintesi dei 10 controlli (manuale completo con esempi di codice riga per riga nel repository del Validator):

1. Struttura BagIt RFC 8493 — scompattare lo zip e verificare la presenza di bagit.txt (versione 1.0), bag-info.txt, manifest-sha256.txt, tagmanifest-sha256.txt, cartella data/.
2. Integrità manifest — shasum -a 256 -c manifest-sha256.txt: ogni file dichiarato deve restituire OK. Una sola riga FAILED = bundle modificato dopo la sigillatura.
3. Integrità tagmanifest — idem su tagmanifest-sha256.txt: chiude la catena di custody includendo l'hash del manifest stesso.
4. Hash multipli media — MD5+SHA-256+SHA-512 dichiarati in manifest.json devono coincidere col file data/media.{jpg|mp4}.
5. TSA RFC 3161 sul media — openssl ts -verify -data data/media.* -in data/tsa.tsr -CAfile <chain>. Deve dare Verification: OK. Verifica l'imprint: Message data nel TSR == SHA-256 del media.
6. TSA sul tagmanifest — stessa verifica applicata a tagmanifest-sha256.txt.tsr: certifica che l'INTERO bundle esisteva con quella forma all'istante della marca.
7. Firma Ed25519 — il manifest.json contiene pubkey e signature. Rimuovere il campo signature, ri-serializzare in JSON canonico (chiavi ordinate, no spazi), verificare con la pubkey dichiarata. La pubkey identifica univocamente il device che ha sigillato.
8. Provenance LOCUS-PROV (ispirata a C2PA, non standard) — il media incorpora un'asserzione con action: c2pa.created e digitalSourceType: digitalCapture (cattura sensore originale, NON sintesi AI). L'hash dichiarato nell'asserzione deve coincidere coi byte del media prima dell'inserimento del box.
9. Coerenza temporale — i timestamp devono essere monotonicamente crescenti: ntp.utc_iso ≤ created_at ≤ C2PA when ≤ sealed_at ≤ TSA media ≤ TSA tagmanifest. Offset NTP > 30 secondi suggerisce un clock device manipolato.
10. Impronte percettive + istogramma (privacy by design) — il Validator ricalcola dal media presente nel bundle l'istogramma (luminanza + RGB) e gli hash percettivi (aHash/dHash/pHash) e li confronta con i valori firmati nel manifest. Conferma che l'anteprima pubblicata sul server (istogramma) corrisponde davvero al media sigillato. Complementari agli hash crittografici, non sostitutivi.

2.5 Interpretazione esiti

3. White paper tecnico

Documento tecnico per ricercatori, magistrati e periti che vogliono comprendere il modello di catena di custody adottato da LOCUS, gli standard internazionali implementati e i limiti dichiarati.

3.1 Problema affrontato

La fotografia e il video catturati da uno smartphone, presi così come sono, hanno scarso valore probatorio in un procedimento giudiziario: l'autore può facilmente alterare le immagini con uno qualsiasi degli editor disponibili, modificare i metadati EXIF, manipolare la data del file con un comando di sistema, o produrre direttamente una sintesi AI fotorealistica indistinguibile da una cattura reale.

Una prova digitale tecnicamente affidabile deve poter dimostrare in modo verificabile da terzi:

1. Quando è stata catturata (tempo autoritativo, non manipolabile dall'utente).
2. Dove è stata catturata (posizione geografica con margine d'errore dichiarato).
3. Con cosa è stata catturata (identità del dispositivo).
4. Da chi è stata sigillata (firma del device che ha eseguito la pipeline).
5. Che non è stata alterata dopo la cattura (sigillo crittografico end-to-end).

3.2 Modello di minaccia

LOCUS è progettata assumendo che l'avversario:

• Possa modificare il media dopo la cattura con editor standard (Photoshop, ffmpeg, ecc.).
• Possa modificare l'app tramite reverse engineering (riconfigurando hash, signature, ecc.).
• Possa alterare il clock del device per simulare un'acquisizione passata.
• Possa intercettare il traffico di rete tra app e server backend.
• NON possa compromettere le Time Stamping Authority pubbliche (Sectigo, DigiCert, GlobalSign, InfoCert) né l'infrastruttura PKI mondiale.

Le difese tecniche sono progettate per rendere visibile qualunque manipolazione, non per impedirla a un avversario fisicamente in possesso del bundle prima della sigillatura.

3.3 Catena di custody crittografica

Ogni acquisizione produce un bundle BagIt RFC 8493 v1.0 che incatena 7 sigilli crittografici in modo monotono:

NTP sync (3 server)
   → Cattura media (sensore camera)
      → Watermark burn-in (timestamp NTP + GPS + UUID burned in pixel)
         → EXIF preservation + LOCUS UserComment inject
            → Hash triplo (MD5 + SHA-256 + SHA-512) streaming a una passata
               → Manifest JSON (campi tutti gli output sopra) firmato Ed25519
                  → CASE/UCO 1.3 JSON-LD sidecar (interoperabilità)
                     → provenance LOCUS-PROV: APP11 (JPEG) o BMFF uuid box (MP4) con asserzione "digitalCapture" (ispirata a C2PA, non standard)
                        → BagIt assembly (tag-files + payload + manifest-sha256.txt)
                           → tagmanifest-sha256.txt (chiude il manifest stesso)
                              → RFC 3161 TSA sul tagmanifest (sigillo finale temporale)

Ogni anello della catena dipende dal precedente in modo verificabile: se anche un solo byte del media viene modificato, l'hash cambia → il manifest non corrisponde → la firma Ed25519 fallisce → shasum -c sul manifest fallisce → la TSA sul tagmanifest non corrisponde più.

3.3-bis Privacy by design — il server non conserva la prova

Il contenuto reale dell'acquisizione (foto, fotogrammi, video, audio) non viene mai trasmesso né conservato sui server LOCUS: resta unicamente nel bundle BagIt sigillato in possesso dell'operatore. Al server arriva soltanto una rappresentazione che non rivela il contenuto:

• un'immagine dell'istogramma (luminanza + canali RGB) del media — per il video uno per fotogramma, per l'audio sulla waveform;
• una terna di hash percettivi — aHash, dHash e pHash (DCT) — calcolati a bordo dispositivo e firmati nel manifest insieme al resto della catena di custodia.

Gli hash percettivi sono robusti alla ricompressione ma non sono l'àncora di integrità (che resta MD5/SHA-256/SHA-512 + firma Ed25519): servono a confermare che l'anteprima pubblicata corrisponde al media sigillato e a riconoscere copie ri-esportate. La pagina di verifica pubblica mostra l'istogramma, mai l'immagine reale, e non divulga la posizione GPS (presente e firmata nel bundle, accessibile a chi lo detiene). Il Locus Validator ricalcola istogramma e hash percettivi dal media nel bundle e ne conferma la corrispondenza, offline. La scelta minimizza i dati personali trattati lato server (minimizzazione GDPR, art. 5(1)(c)) ed elimina l'esposizione pubblica di contenuti sensibili.

3.4 Standard internazionali adottati

3.5 Time Stamping Authority utilizzate

La marca temporale RFC 3161 è applicata due volte per ogni bundle (sul media e sul tagmanifest) con cascade di fallback enterprise-grade. Provider supportati:

• Sectigo — fallback primario, free non-qualified, certificato di lungo periodo.
• DigiCert — fallback secondario.
• GlobalSign — fallback terziario.
• InfoCert — opt-in dell'utente, marca qualificata eIDAS ai sensi dell'art. 42 Reg. 910/2014 — efficacia probatoria piena in UE.

3.6 Limiti dichiarati

LOCUS garantisce la conformità tecnica agli standard sopra, ma esplicitamente NON garantisce:

• L'ammissibilità in giudizio del singolo bundle. La decisione è del giudice nel caso specifico, valutando: catena di custodia procedurale, qualifica dell'operatore, rispetto della normativa processuale applicabile, eventuali eccezioni di parte.
• La liceità d'uso: la responsabilità del consenso al ritratto, della finalità dell'acquisizione e del rispetto della privacy di terzi resta interamente dell'operatore (vedi termini di servizio § 6).
• La resistenza ad attacchi fisici: un avversario che ha accesso al device prima della sigillatura può catturare media fasulli che verranno sigillati come veri (LOCUS certifica che quei byte sono stati sigillati a quell'istante, non che il contenuto rappresenta la realtà).

3.7 Disponibilità e indipendenza della verifica

Per garantire l'indipendenza della verifica rispetto al Fornitore, LOCUS distribuisce gratuitamente il Locus Validator (desktop Win/Mac/Linux, open source AGPL-3.0). Il Validator esegue tutti i 9 controlli di integrità del § 2.4 offline, senza necessità di account, server o connessione: chiunque (giudice, controparte, perito indipendente) può verificare un bundle in totale autonomia anche dopo anni dalla sigillatura.

La stessa logica è descritta in dettaglio nel Manuale di validazione manuale distribuito insieme al Validator: ogni verifica è replicabile con strumenti standard (openssl, shasum, python3) senza dover credere al codice del Validator stesso.

3.8 Architettura del servizio

Frontend mobile: app Tauri 2 (Rust core + WebView vanilla JS) su Android, iOS, macOS, Linux, Windows. Il core forense (TSA, signature, hash, BagIt) è scritto in Rust per portabilità e performance; la UI in WebView per coerenza cross-platform.

Backend: PHP + MySQL su infrastruttura Hostinger (Unione Europea). Endpoint dedicati /app-locus/ per certificazione e locus.acquisizioniforensi.com/verify/ per la verifica pubblica permalink.

Validator desktop: app Tauri 2 standalone Rust per verifica offline, distribuita gratuitamente.

3.9 Roadmap

• Stronghold migration — keypair Ed25519 migrato da SQLite a vault hardware (Stronghold / Android KeyStore / iOS Secure Enclave) per binding non estraibile.
• Decentralized timestamping — esplorazione integrazione OpenTimestamps (Bitcoin blockchain anchor) come additional witness oltre RFC 3161.
• Multi-operatore — gestione team con ruoli e supervisione condivisa.