Il contenuto resta dove deve stare: sotto il controllo del cliente.

Privacy come scelta architetturale

Il modello CertiSigma parte da una distinzione semplice: il contenuto operativo resta sotto il controllo del cliente, mentre la prova crittografica puo' diventare portabile e verificabile.

Questa scelta riduce la superficie di esposizione, ma non trasforma automaticamente ogni workflow in un workflow privato. Hash, metadati, tag e identificativi vanno progettati con attenzione, soprattutto quando gli input sono prevedibili.

Cosa vede CertiSigma

CertiSigma può ricevere digest SHA-256, attestation request, metadati selezionati, riferimenti tecnici e materiali di evidenza necessari al workflow.

Non riceve il file originale nel modello standard. Il calcolo del digest avviene lato cliente (via SDK, Census, integrazione locale o API call client-side). Solo il digest e i metadata scelti dal workflow vengono trasmessi a CertiSigma.

La Privacy Policy pubblica copre sito hub anonimo e Public Verifier. I workflow di clienti API registrati seguono invece Termini e DPA/off-band quando applicabile.

Attenzione agli input prevedibili

SHA-256 non è un meccanismo di privacy quando l'input è prevedibile o enumerabile.

Email, numeri di serie, codici cliente, SKU, order ID, nomi file prevedibili e identificativi interni devono essere gestiti con pattern adeguati, ad esempio HMAC-SHA256 con chiave segreta, o derivazioni con chiave. In assenza di queste protezioni, un attaccante che conosca il dominio di valori può ricostruire l'input dal digest tramite enumerazione.

Questa non è una limitazione di CertiSigma: è una proprietà generale delle funzioni di hash crittografico. Il workflow deve progettare cosa hashare e come.

Principi operativi

Il file originale rimane lato cliente.

Il digest può essere verificabile pubblicamente.

I metadati sensibili non dovrebbero essere inviati in chiaro.

Le derived lists richiedono governance della chiave (chi conosce la chiave HMAC può ricostruire la lista in chiaro).

I tag non devono essere usati per contenere segreti o dati personali in chiaro.

La cifratura client-side va usata quando i metadati contengono informazioni sensibili.

Prova pubblica, contesto operativo privato

Il modello CertiSigma distingue tra prova crittografica e claim operativo. Hash, firme, proof, root e materiali di verifica possono essere resi verificabili da terzi. Metadati organizzativi come source, extra_data, tag e note operative devono invece rimanere scoped al proprietario autenticato, salvo condivisione esplicita e controllata.

Ogni API key può avere un proprio claim su un'attestazione. Questo consente a più sistemi o organizzazioni di riferirsi allo stesso digest senza esporre automaticamente il proprio contesto interno. I tag strutturati possono aiutare a classificare le attestazioni per reparto, progetto, livello documentale o workflow, ma non devono contenere segreti o dati personali in chiaro.

Cifratura client-side dei metadati

Quando i metadati contengono informazioni sensibili, il workflow può prevedere cifratura lato cliente prima dell'invio. In questo modello CertiSigma conserva i metadati cifrati come blob opaco e non può ricostruire il plaintext se il cliente perde la chiave.

Questo è un compromesso esplicito: la riservatezza è massima, ma la ricerca, l'export e il match richiedono che il client decifri localmente. La governance della chiave (rotazione, backup, ACL) resta interamente sotto il controllo del cliente.

API key con scope

Le integrazioni possono usare chiavi API con privilegi minimi: ad esempio attestazione, batch, lettura metadata, scrittura metadata, tag, share, scan, Census o webhook. La separazione degli scope riduce l'impatto di errori di configurazione e rende più chiaro chi può fare cosa dentro il workflow.

Pattern raccomandato: una chiave per use case, non una chiave master per tutta l'organizzazione.

Messaggio essenziale

CertiSigma riduce l'esposizione del contenuto, ma la privacy dipende anche da come hash, metadata e identificativi vengono progettati nel workflow.