ExistBefore

ExistBefore Verify Pro

Esegui una verifica forense strutturata in 10 passaggi su un file, un PDF di certificato, un hash SHA-256, un id di attestazione o un estratto di testo. La pipeline produce un Verification Report deterministico e byte-identico (PDF + JSON) adatto a uso legale, di audit e forense.

Il tuo input non lascia mai il browser. I file sono hashati localmente con WebCrypto; solo lo SHA-256 risultante (32 byte) transita via proxy verso il registro pubblico ExistBefore.

Fornisci l'input da verificare

Risultato della verifica

Checklist forense

In cosa Verify Pro differisce da Verify

La pagina pubblica Verify è pensata per un compito solo: dire all'utente, in pochi secondi, se un file o un certificato è riconosciuto dal registro ExistBefore. Verify Pro è pensato per un'altra audience — professionisti legali, di audit e forensi che hanno bisogno di una traccia di verifica strutturata e riproducibile.

• Stessa crittografia, più trasparenza. Verify Pro esegue la stessa verifica ECDSA offline e gli stessi cross-check del registro del flusso Verify base, ma espone ogni passaggio intermedio (10 voci, codici VR01–VR10) con stato per passaggio, evidenza e codice di motivazione.
• Verification Report deterministico. Il report è byte-identico tra esecuzioni, browser e fusi orari per lo stesso input + la stessa risposta del registro. PDF e JSON includono un self-hash, così qualsiasi modifica successiva al file è rilevabile.
• Catalogo congelato. Il catalogo dei 10 passaggi è versionato (existbefore-verifyreport-v1) e fissato da un test di stabilità inline. Aggiungere, rinominare o riordinare un passaggio richiede un bump di versione — il report resta mappabile anche a distanza di anni.
• Invariante di privacy preservata. File e testo non lasciano mai il browser. Solo lo SHA-256 transita via proxy verso il registro pubblico, esattamente come nel flusso Verify base.

Cosa garantisce questo report — e cosa no

La verifica forense è una catena di affermazioni fatte sotto condizioni specifiche. Verify Pro è esplicito su quali affermazioni può fare e quali no.

Cosa stabilisce un verdetto Authentic

• La firma crittografica incorporata nel certificato è valida rispetto alla chiave pubblica che il certificato stesso incorpora.
• L'impronta della chiave incorporata corrisponde all'impronta dichiarata all'interno del certificato (nessuno scambio di chiave).
• Il registro pubblico ExistBefore riconosce l'hash e restituisce lo stesso id di attestazione e la stessa impronta della chiave di firma incorporati nel certificato.
• Nessun indicatore di manomissione è stato sollevato da alcun passaggio della pipeline.

Cosa nessun report Verify Pro afferma mai

• Non afferma che l'input sia stato creato, posseduto o controllato da una persona o organizzazione specifica. L'integrità crittografica non è attribuzione.
• Non afferma che l'input sia unico, originale o il primo del suo genere. Le collisioni SHA-256 sono infattibili, ma due parti possono legittimamente attestare lo stesso contenuto.
• Non conferisce alcun diritto di proprietà intellettuale. ExistBefore è un livello di prova di esistenza, non un registro di diritti.

Come si svolge la pipeline in 10 passaggi

1. VR01 — Input interpretato. L'input viene riconosciuto e instradato sul percorso corretto (file, PDF di certificato, hash, id di attestazione o testo).
2. VR02 — Hash calcolato. Per file e testo, lo SHA-256 viene calcolato localmente con WebCrypto. Per hash e id di attestazione già forniti, questo passaggio non è applicabile.
3. VR03 — Hash corrisponde a quello incorporato. Per l'input PDF di certificato, l'hash di lookup è lo stesso valore incorporato nel certificato. Una divergenza interna sarebbe già un indicatore di manomissione.
4. VR04 — Impronta incorporata corrisponde alla chiave incorporata. Lo SHA-256 dello SPKI incorporato deve corrispondere all'impronta dichiarata nel certificato, altrimenti la chiave incorporata è stata sostituita.
5. VR05 — Firma incorporata valida. La firma ECDSA incorporata viene verificata rispetto alla chiave pubblica incorporata sul payload firmato canonico.
6. VR06 — Il registro riconosce l'hash. Il proxy inoltra l'hash al registro pubblico ExistBefore; un hash non riconosciuto significa che non esiste alcuna attestazione.
7. VR07 — L'id di attestazione del registro corrisponde a quello incorporato. Il certificato non deve essere stato ripuntato a un'attestazione diversa.
8. VR08 — L'impronta della chiave di firma del registro corrisponde a quella incorporata. La stessa chiave deve aver firmato il certificato e registrato l'attestazione.
9. VR09 — Livello attuale del registro vs livello di generazione. L'attestazione potrebbe essere stata aggiornata (T0 → T1 → T2) dal momento dell'emissione del certificato; questo passaggio segnala il livello attuale.
10. VR10 — Risultanze forensi incorporate. La snapshot lato producer delle risultanze forensi incorporata nel certificato viene riprodotta verbatim e mai ricalcolata in fase di verifica.