LOCUS documentation.

1. Operator manual v1.0

This manual is for the operator: anyone who installs the LOCUS app on their mobile device (Android or iOS) to document a forensic site inspection, a crime scene, a technical investigation or any situation requiring digital evidence with reinforced evidentiary value.

1.1 Before the acquisition

• Account: register on locus.acquisizioniforensi.com with e-mail and password ≥10 characters. Confirm the address by clicking the link received by e-mail (24 h validity).
• Slot pack: buy a pack from the dashboard (1 slot = 1 photo or 1 audio, 2 slots = 1 video; +2 optional slots for the eIDAS-qualified InfoCert timestamp). Payment via Stripe, instant credit.
• API key: in dashboard → API key, generate your personal key and copy it into the app at first launch (Login screen).
• App installation: download the package from the Download page (signed Android APK, iOS via TestFlight, desktop dmg/msi/AppImage).
• System permissions: the app requires camera, microphone (for video + audio comment), precise GPS, file storage. From Settings → LOCUS, verify they are all active.
• Connectivity: have data coverage at the moment of the final bundle upload (during capture, the connection is not strictly necessary, but initial NTP sync and final upload do require it).

1.2 Photo acquisition

1. Launch the app → Home screen.
2. Enter the case number (unique forensic case code — optional but recommended for library organization).
3. Press "Take photo". The app automatically runs: triple NTP sync (Cloudflare / Google / pool.ntp) → native camera capture → 3-line burn-in watermark (NTP timestamp, acquisition UUID, GPS + heading) → original camera EXIF preservation + LOCUS Software/ UserComment inject → MD5+SHA-256+SHA-512 streaming hash → RFC 3161 timestamp → Ed25519 manifest signature → CASE/UCO 1.3 JSON-LD sidecar → forensic PDF report → BagIt RFC 8493 assembly → tagmanifest TSA → server upload.
4. The 13-step Progress modal shows progress in real time.
5. Optionally: record an audio comment after the shot (max 15 seconds, AAC m4a) which is included in the bundle and linked in the confirmation e-mail.
6. When finished: confirmation e-mail to the account address (and PEC if configured) with link to the bundle and to the public permalink /verify/<short_code>.

1.3 Video acquisition

1. Press "Record video". The fullscreen REC modal opens with live camera preview (CameraX on Android, AVFoundation on iOS).
2. The native overlay displays NTP-synced timestamp, dynamic GPS, UUID and compass (NESW) — this data is "burned in" at recording time, not added afterwards.
3. Hard cap of 20 minutes per file (Android Camera2 limit). For longer acquisitions use multiple segments.
4. Stop → pipeline identical to photo, plus: GPS polyline in the bundle, speed/distance statistics (haversine + Δd/Δt), 5 key frames extracted (kept in the bundle: only their histograms are uploaded, never the real frames).
5. Orphan handling: if the app crashes during the pipeline, on relaunch it proposes 3 choices: seal incomplete / discard / leave.

1.4 Audio acquisition

1. Press "Audio" on the Home screen. The recorder opens with a timer and a STOP button (native recorder: AudioRecord on Android, AVAudioRecorder on iOS).
2. The track is recorded as lossless 16-bit PCM WAV — no re-encoding, no watermark, no overlay: the file stays byte-for-byte as captured. GPS is sampled at ~1 Hz during recording for the path log.
3. Stop → forensic pipeline identical to photo: NTP sync → MD5+SHA-256+SHA-512 hash → RFC 3161 timestamp → signed Ed25519 manifest → CASE/UCO sidecar → rendered waveform (visual aid only) → PDF report → BagIt RFC 8493 + TSA tagmanifest → upload.
4. Cost: 1 slot (3 with the eIDAS-qualified InfoCert timestamp), same as a photo.
5. The audio chain of custody lives entirely in the signed bundle (manifest + TSA + hashes): authenticity does not depend on any alteration of the track.

1.5 User dashboard

From the reserved area /dashboard the operator can:

• Library: chronological list of all acquisitions with type / case number / date range filter; bundle detail with histogram preview, link to PDF and public permalink, hashes and signature.
• Devices: manage registered devices (Trust-On-First-Use binding of Ed25519 pubkey). Remote revocation in case of loss.
• Slots: remaining balance + pack purchase + detailed slot statement.
• Orders: history of invoices and PDF receipts.
• Tickets: technical support via integrated ticketing system.

1.6 Forensic best practices

• Image consent: if recognisable faces of natural persons are filmed, verify the legal basis of the processing (consent, public interest, legal obligation). The app does not perform automatic pseudonymisation.
• Device pre-check: battery > 30%, free space > 1 GB for long videos, GPS fix acquired (green icon), no system update in progress.
• Desktop validator: download the Locus Validator on your laptop to verify the bundle independently after returning to the office, before delivering it to the client or to the magistrate.

2. Validation manual v1.0

This manual is for anyone who receives a LOCUS bundle and needs to verify its integrity independently: opposing party's consultant, magistrate, prosecutor, judicial police, judge or private counterparty. There are three verification modes, from the simplest to the most granular.

2.1 Verification via public permalink

Each acquisition has a 6-character short code (e.g. X3K9PM) printed in the PDF report and in confirmation e-mails. Opening https://locus.acquisizioniforensi.com/verify/<short_code> shows a public page with:

• Histogram of the media (photo) or per-frame histograms (video) — for confidentiality the real image is not published; the signed perceptual hashes bind it to the histogram.
• GPS position shown as present in the bundle but not disclosed (confidentiality): coordinates, map and track remain in the sealed bundle.
• Server-recomputed RFC 3161 timestamp timeline (authority, instant, status).
• Complete MD5 + SHA-256 + SHA-512 hashes of the media.
• Verified Ed25519 signature + identity of the sealing device.
• Full chain of custody (operator, slots consumed, TSA type, standard conformance).

Suitable for a quick verification of a single acquisition. Browser only.

2.2 Verification with Locus Validator (desktop, offline)

The Locus Validator is a standalone desktop app (Windows / macOS / Linux) that performs all the technical bundle checks without upload, without account, without connection. Designed specifically for court-appointed experts / prosecutors / judges who want to verify in total independence from the Provider.

1. Download the app from the Download page.
2. Drag the bundle's .zip file into the app window.
3. The app automatically performs the 10 checks of § 2.4 and produces an on-screen report (green/yellow/red for each step) and a downloadable forensic PDF.

All logic is in Rust + verifiable from source code (GitHub repository, AGPL-3.0). No telemetry, no tracking.

2.3 Verification included in the bundle (zero installs)

Every LOCUS bundle is self-verifying: it carries the tools to check it with nothing to download or install. In the package root you will find:

• verify.sh (macOS/Linux) and verify.bat (Windows) — scripts that recompute all hashes (manifest-sha256.txt + tagmanifest-sha256.txt) and verify the two RFC 3161 timestamps with openssl. Run them from the bundle root: they print BUNDLE VALIDO or the list of failed checks.
• tsa-ca.pem — the TSA root CA bundle (Sectigo, DigiCert, GlobalSign, InfoCert): timestamp verification runs fully offline, with no certificate download.
• data/interactive.html — an interactive report you open by double-click in any browser (no connection): it exposes all the evidence data (acquisition, device, GPS, camera/audio, chain of custody, signature) and includes two in-browser validation tools — (a) drop the media file to recompute its SHA-256 and compare it with the signed one; (b) select the bundle folder to re-hash every file against manifest-sha256.txt (OK/Modified/Missing table).

The scripts and CA bundle are included in tagmanifest-sha256.txt, the HTML in manifest-sha256.txt: the verification tools themselves are therefore sealed by the timestamp.

2.4 Manual command-line verification

All Validator checks are reproducible by hand with standard tools unzip, shasum, openssl, python3. Summary of the 10 checks (full manual with line-by-line code examples in the Validator repository):

1. BagIt RFC 8493 structure — unzip the archive and check the presence of bagit.txt (version 1.0), bag-info.txt, manifest-sha256.txt, tagmanifest-sha256.txt, the data/ folder.
2. Manifest integrity — shasum -a 256 -c manifest-sha256.txt: every declared file must return OK. A single FAILED line = bundle modified after sealing.
3. Tagmanifest integrity — same on tagmanifest-sha256.txt: closes the chain of custody by including the hash of the manifest itself.
4. Multi-algorithm media hash — MD5+SHA-256+SHA-512 declared in manifest.json must match the file data/media.{jpg|mp4}.
5. RFC 3161 TSA on media — openssl ts -verify -data data/media.* -in data/tsa.tsr -CAfile <chain>. Must return Verification: OK. Verify the imprint: Message data in the TSR == SHA-256 of the media.
6. TSA on tagmanifest — same verification on tagmanifest-sha256.txt.tsr: certifies that the ENTIRE bundle existed in that form at the moment of the timestamp.
7. Ed25519 signature — manifest.json contains pubkey and signature. Remove the signature field, re-serialize in canonical JSON (sorted keys, no whitespace), verify with the declared pubkey. The pubkey uniquely identifies the device that sealed.
8. LOCUS-PROV provenance (C2PA-inspired, not standard) — the media embeds an assertion with action: c2pa.created and digitalSourceType: digitalCapture (original sensor capture, NOT AI synthesis). The hash declared in the assertion must match the media bytes before box insertion.
9. Temporal consistency — timestamps must be monotonically increasing: ntp.utc_iso ≤ created_at ≤ C2PA when ≤ sealed_at ≤ TSA media ≤ TSA tagmanifest. NTP offset > 30 seconds suggests a manipulated device clock.
10. Perceptual hashes + histogram (privacy by design) — the Validator recomputes, from the media in the bundle, the histogram (luminance + RGB) and the perceptual hashes (aHash/dHash/pHash) and compares them with the values signed in the manifest. It confirms that the preview published on the server (histogram) genuinely corresponds to the sealed media. Complementary to the cryptographic hashes, not a substitute.

2.5 Outcome interpretation

3. White paper technical

Technical document for researchers, magistrates and experts who want to understand the chain-of- custody model adopted by LOCUS, the international standards implemented and the declared limits.

3.1 Problem addressed

Photos and videos captured by a smartphone, taken as-is, have little evidentiary value in a judicial proceeding: the author can easily alter the images with any of the available editors, modify the EXIF metadata, manipulate the file date with a system command, or directly produce a photorealistic AI synthesis indistinguishable from a real capture.

A technically reliable digital evidence must be able to demonstrate verifiably by third parties:

1. When it was captured (authoritative time, not user-manipulable).
2. Where it was captured (geographic position with declared error margin).
3. With what it was captured (device identity).
4. By whom it was sealed (signature of the device that executed the pipeline).
5. That it has not been altered after capture (end-to-end cryptographic seal).

3.2 Threat model

LOCUS is designed assuming the adversary:

• Can modify the media after capture with standard editors (Photoshop, ffmpeg, etc.).
• Can modify the app via reverse engineering (reconfiguring hashes, signatures, etc.).
• Can alter the device clock to simulate a past acquisition.
• Can intercept the network traffic between app and backend server.
• CANNOT compromise public Time Stamping Authorities (Sectigo, DigiCert, GlobalSign, InfoCert) nor the global PKI infrastructure.

Technical defences are designed to make visible any manipulation, not to prevent it against an adversary who physically possesses the bundle before sealing.

3.3 Cryptographic chain of custody

Each acquisition produces a BagIt RFC 8493 v1.0 bundle that chains 7 cryptographic seals monotonically:

NTP sync (3 servers)
   → Media capture (camera sensor)
      → Watermark burn-in (NTP timestamp + GPS + UUID burned in pixels)
         → EXIF preservation + LOCUS UserComment inject
            → Triple hash (MD5 + SHA-256 + SHA-512) one-pass streaming
               → Manifest JSON (all outputs above) Ed25519-signed
                  → CASE/UCO 1.3 JSON-LD sidecar (interoperability)
                     → LOCUS-PROV provenance: APP11 (JPEG) or BMFF uuid box (MP4) with "digitalCapture" assertion (C2PA-inspired, not standard)
                        → BagIt assembly (tag-files + payload + manifest-sha256.txt)
                           → tagmanifest-sha256.txt (closes the manifest itself)
                              → RFC 3161 TSA on tagmanifest (final temporal seal)

Each link in the chain depends verifiably on the previous one: if even a single byte of the media is modified, the hash changes → the manifest no longer matches → the Ed25519 signature fails → shasum -c on the manifest fails → the TSA on the tagmanifest no longer matches.

3.3-bis Privacy by design — the server never holds the evidence

The actual acquisition content (photos, frames, video, audio) is never transmitted or stored on LOCUS servers: it stays only in the sealed BagIt bundle held by the operator. The server receives only a representation that does not reveal the content:

• a histogram image (luminance + RGB channels) of the media — one per frame for video, on the waveform for audio;
• a triple of perceptual hashes — aHash, dHash and pHash (DCT) — computed on-device and signed in the manifest together with the rest of the chain of custody.

The perceptual hashes are robust to recompression but are not the integrity anchor (which remains MD5/SHA-256/SHA-512 + Ed25519 signature): they confirm that the published preview matches the sealed media and help recognise re-exported copies. The public verification page shows the histogram, never the real image, and does not disclose the GPS position (present and signed in the bundle, accessible to whoever holds it). The Locus Validator recomputes the histogram and perceptual hashes from the media in the bundle and confirms they match, offline. This minimises the personal data processed server-side (GDPR data minimisation, art. 5(1)(c)) and removes public exposure of sensitive content.

3.4 International standards adopted

3.5 Time Stamping Authorities used

The RFC 3161 timestamp is applied twice for each bundle (on the media and on the tagmanifest) with an enterprise-grade fallback cascade. Supported providers:

• Sectigo — primary fallback, free non-qualified, long-term certificate.
• DigiCert — secondary fallback.
• GlobalSign — tertiary fallback.
• InfoCert — user opt-in, eIDAS-qualified stamp under art. 42 EU Reg. 910/2014 — full evidentiary efficacy in EU.

3.6 Declared limits

LOCUS guarantees technical conformity to the standards above, but explicitly DOES NOT guarantee:

• The courtroom admissibility of any individual bundle. The decision is made by the judge in the specific case, evaluating: procedural chain of custody, operator qualification, compliance with applicable procedural law, possible counterparty exceptions.
• The lawfulness of use: responsibility for image consent, the purpose of the acquisition and respect for third-party privacy remains entirely with the operator (see terms of service § 6).
• Resistance to physical attacks: an adversary with access to the device before sealing can capture fake media that will be sealed as real (LOCUS certifies that those bytes were sealed at that instant, not that the content represents reality).

3.7 Verification availability and independence

To guarantee verification independence from the Provider, LOCUS distributes the Locus Validator for free (desktop Win/Mac/Linux, open source AGPL-3.0). The Validator performs all 9 integrity checks of § 2.4 offline, with no need for an account, server or connection: anyone (judge, counterparty, independent expert) can verify a bundle in total autonomy even years after sealing.

The same logic is described in detail in the Manual validation manual distributed with the Validator: every check is replicable with standard tools (openssl, shasum, python3) without having to trust the Validator's own code.

3.8 Service architecture

Mobile frontend: Tauri 2 app (Rust core + vanilla JS WebView) on Android, iOS, macOS, Linux, Windows. The forensic core (TSA, signature, hash, BagIt) is written in Rust for portability and performance; the UI in WebView for cross-platform consistency.

Backend: PHP + MySQL on Hostinger infrastructure (European Union). Dedicated endpoints /app-locus/ for certification and locus.acquisizioniforensi.com/verify/ for public permalink verification.

Desktop validator: standalone Tauri 2 Rust app for offline verification, distributed free of charge.

3.9 Roadmap

• Stronghold migration — Ed25519 keypair migrated from SQLite to hardware vault (Stronghold / Android KeyStore / iOS Secure Enclave) for non-extractable binding.
• Decentralized timestamping — exploring integration with OpenTimestamps (Bitcoin blockchain anchor) as additional witness beyond RFC 3161.
• Multi-operator — team management with roles and shared supervision.