Trasparenza sull’AI: questo articolo è stato generato con strumenti di intelligenza artificiale (AI).
Copertina: contatore elettronico, fotografia di Rakoon, CC0 1.0. Immagine di contesto: non è un progetto ALCE e non dimostra l’accuratezza delle misure né l’integrità dei file.
Un file CSV con le letture di un contatore viene esportato, inviato a un consulente e usato per costruire un riepilogo. Dopo alcune settimane compare una seconda copia con lo stesso nome. Come possiamo verificare se è davvero identica a quella utilizzata per l’analisi?
Una risposta tecnica è calcolare un hash crittografico: una breve impronta ricavata dal contenuto digitale. È un passaggio utile per avvicinarsi ai registri distribuiti, ma va interpretato con precisione. L’hash può aiutare a rilevare una modifica; non dimostra che la misura sia corretta né identifica da solo chi ha prodotto il file.
Questo articolo prosegue il percorso iniziato con la verifica dei dati energetici prima della blockchain. La nuova competenza è saper definire una prova di integrità ripetibile e riconoscerne i limiti.
Un hash descrive i byte, non il significato
Una funzione hash riceve un messaggio di lunghezza variabile e restituisce un valore di lunghezza fissa, chiamato anche digest. Il Secure Hash Standard FIPS 180-4 del NIST specifica algoritmi progettati per generare digest utili a rilevare se un messaggio è cambiato dopo il calcolo.
In pratica, si calcola l’impronta del file originale e la si conserva separatamente. In seguito si ricalcola l’hash della copia da controllare: se i valori differiscono, i byte non sono gli stessi. Se coincidono, abbiamo una forte evidenza tecnica che il contenuto confrontato è lo stesso rispetto all’algoritmo usato, non una certificazione del fenomeno misurato.
Il NIST distingue tre proprietà di sicurezza: resistenza alle collisioni, alla preimmagine e alla seconda preimmagine. Nella pratica non basta scrivere “hash”: occorre registrare anche l’algoritmo e la sua versione. SHA-256, della famiglia SHA-2, è un esempio corrente; NIST segnala invece la transizione dall’uso di SHA-1. La scelta concreta va inserita nelle regole di sicurezza e manutenzione del sistema.
Che cosa l’impronta non prova
Un hash non corregge un intervallo temporale sbagliato, un’unità errata o una lettura stimata presentata come effettiva. Se il file originale contiene un errore, l’impronta permette di riconoscere quel file, non di trasformarlo in un dato accurato.
Inoltre il digest, da solo, non dice chi abbia generato il file. Chi può sostituire sia il documento sia l’hash conservato nello stesso archivio potrebbe alterare entrambi. Per questo bisogna separare il file, l’evidenza di integrità e i permessi di modifica. Le firme digitali, che collegano un’operazione a una chiave, sono un livello ulteriore e meritano una valutazione distinta.
Neppure la data riportata nel nome del file costituisce automaticamente una data certa. Conviene annotare quando e da quale sistema è stato acquisito, chi ha avuto accesso e dove è conservata l’impronta. Se serve una prova temporale con requisiti legali o contrattuali, occorre progettare e verificare uno specifico servizio di marcatura, senza attribuire quella funzione al solo hash.
Prima di calcolare: stabilire quale file conta
Una procedura ripetibile comincia dalla versione da proteggere. Per ogni esportazione energetica suggerisco di conservare almeno: identificativo del misuratore o del flusso, intervallo e fuso orario, unità, stato dei valori, formato, nome del file, data di acquisizione, algoritmo e digest.
È importante calcolare l’hash sul file originale prima di aprirlo e risalvarlo con un foglio di calcolo. Un programma può cambiare separatori, codifica dei caratteri, ordine delle colonne o terminazioni di riga pur lasciando apparentemente uguali i numeri mostrati. Il nuovo file avrà byte diversi e quindi, correttamente, un’impronta diversa.
Se l’applicazione deve confrontare dati equivalenti prodotti da sistemi diversi, non basta affidarsi al nome o all’aspetto. Serve una regola di normalizzazione condivisa. Per i documenti JSON, la RFC 8785 descrive una canonicalizzazione con ordinamento deterministico delle proprietà e serializzazione invariabile, così che le operazioni crittografiche siano ripetibili. La RFC è informativa e riguarda JSON: non va presentata come regola universale per CSV o altri formati.
Un esempio di verifica e correzione
Esempio ipotetico, non riferito a un edificio reale. Un piccolo edificio esporta ogni mese le letture in CSV. Il responsabile conserva il file originale, calcola SHA-256 e registra algoritmo, digest, intervallo e posizione dell’archivio in un registro con accessi limitati.
Durante una verifica, la copia ricevuta dal manutentore produce un hash diverso. Il confronto mostra che il file è stato risalvato con una colonna aggiuntiva. Non si conclude che i consumi siano falsi: si registra la divergenza, si recupera l’originale e si decide quale versione alimenterà il riepilogo. La nuova versione riceve una propria impronta e un collegamento esplicito alla precedente.
Questo flusso preserva la storia della correzione. Evita due errori opposti: considerare sospetta ogni differenza tecnica oppure ignorare modifiche che possono cambiare l’analisi.
| Passaggio | Azione | Esito |
|---|---|---|
| 1. Originale | Conservare file e metadati | Versione di riferimento |
| 2. Hash | Calcolare SHA-256 | Digest registrato separatamente |
| 3. Copia | Ricalcolare senza risalvare | Digest da confrontare |
| 4. Confronto | Uguale: confermare i byte. Diverso: confrontare le versioni e registrare il motivo | Corrispondenza oppure nuova versione collegata |
Database o blockchain?
Un registro convenzionale con controllo degli accessi, versioni, copie di sicurezza e log può conservare hash e metadati in modo adeguato quando esiste un amministratore riconosciuto. La blockchain diventa una candidata da confrontare quando più soggetti devono verificare evidenze senza affidare a uno solo la riscrittura della storia.
Anche in quel caso, è spesso più prudente registrare l’impronta e i riferimenti, non il file energetico completo: i dati possono essere voluminosi, contenere informazioni riservate o richiedere correzioni e politiche di conservazione. Il NISTIR 8202 sulla blockchain spiega il ruolo degli hash nella concatenazione dei blocchi e ricorda che un sistema resistente alle alterazioni può comunque ricevere dati sbagliati da utenti o sensori.
La domanda utile non è quindi “possiamo mettere questo file su blockchain?”, ma “chi deve verificare quale versione, contro quale rischio e per quanto tempo?”. Se un database governato soddisfa questi requisiti con minore complessità, la soluzione distribuita non è automaticamente migliore.
Una prova pratica in cinque passaggi
- Scegliere un solo file originale e documentarne fonte, periodo, unità e stato dei dati.
- Calcolare l’hash con un algoritmo dichiarato e conservare digest e metadati separatamente dal file.
- Trasferire una copia e ricalcolarne l’impronta senza risalvarla.
- Se i valori differiscono, confrontare le versioni e registrare il motivo; non dedurre automaticamente un errore di misura.
- Definire chi può creare, leggere e aggiornare l’evidenza, poi confrontare un archivio convenzionale con eventuali soluzioni distribuite.
Il risultato non è ancora una blockchain né una firma digitale. È una procedura minima che rende verificabile l’identità tecnica di un file e prepara domande migliori per le scelte successive.
Fonti consultate il 26 ottobre 2026: NIST FIPS 180-4, pagina NIST Hash Functions, RFC 8785 e NISTIR 8202, collegate nei paragrafi pertinenti.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI).
Lascia un commento