- Cos'\u00e8 una Signature Chain<\/a>
- Architettura e funzionamento<\/a>
- Esempio di record nella tabella<\/a>
- Blocco 1 (Genesi – Firmatario: Antonio)<\/a>
- Blocco 2 (Firmatario: Marianna)<\/a><\/li><\/ul><\/li>
- Schema della catena delle firme<\/a>
- Meccanismi di Sicurezza in PostgreSQL per la Signature Chain<\/a>
- 1. Principio del Privilegio Minimo (Least Privilege Principle)<\/a>
- 2. Sicurezza a Livello di Riga (Row Level Security – RLS)<\/a>
- 3. Revoca Esplicita dei Permessi<\/a><\/li><\/ul><\/li><\/ul><\/li>
- Verifica dell'integrit\u00e0 del documento originale (considerazioni esterne)<\/a>
- Caratteristiche chiave della catena<\/a>
- Come avviare la PoC<\/a>
- 1. Requisiti<\/a>
- 2. Configurazione variabili d'ambiente (opzionale)<\/a>
- 3. Avvio del database PostgreSQL<\/a>
- 4. Esegui lo script di firma e verifica<\/a>
- 5. Verifica della Catena<\/a><\/li><\/ul><\/li><\/ul><\/li><\/ul>
- Output atteso (estratto)<\/a><\/li>
- Appendice: considerazioni sugli algoritmi crittografici<\/a>
- Alternative per l'Hashing<\/a>
- Alternative per la Firma Digitale<\/a>
- Fattori da Considerare per la Scelta<\/a><\/li><\/ul><\/li>
- Conclusioni<\/a><\/ul><\/ol>\t\t\t\t\t<\/div>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\n\n\n
Cos’\u00e8 una Signature Chain<\/h2>\n\n\n\n
La Signature Chain \u00e8 un meccanismo crittografico che crea una sequenza immutabile di firme digitali su un documento, garantendone autenticit\u00e0, integrit\u00e0 e sequenzialit\u00e0. Questo concetto \u00e8 stato dimostrato in questa Proof of Concept (POC)<\/a> che utilizza PostgreSQL e Python<\/a>, impiegando chiavi RSA generate in memoria per illustrare il funzionamento. Per un ambiente di produzione reale, si raccomanda l’uso di Hardware Security Modules (HSM) o i key vault (sistemi di custodia certificati per chiavi crittografiche), una Timestamp Authority (TSA) per la certificazione temporale esatta (assicurando l’esatta data e ora di ogni sottoscrizione, fino al millisecondo, eliminando contestazioni temporali), e certificati digitali qualificati, rilasciati da enti certificatori riconosciuti. Pertanto, si sottolinea la natura non sperimentale ma robusta e legalmente valida di tale sistema per applicazioni reali.<\/p>\n\n\n\n
Architettura e funzionamento<\/h2>\n\n\n\n
Il sistema di Signature Chain, implementato dalla PoC, si basa su un\u2019applicazione realizzata in Python che interagisce con un database per la memorizzazione e la verifica delle firme. Ogni firma apposta su un documento viene registrata come un “blocco”<\/strong> in una tabella del database, ad esempio
signature_chain<\/code>. Tale interazione \u00e8 assimilabile all’operato di un segretario altamente preciso e incorruttibile, il quale registra ogni singola sottoscrizione con meticolosit\u00e0, senza omissioni o possibilit\u00e0 di corruzione.<\/p>\n\n\n\nIl diagramma a seguire illustra l’architettura del sistema implementata da questa PoC.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2025\/05\/architettura-1024x123.png\")
<\/figure>\n\n\n\nLa struttura di ogni blocco \u00e8 progettata per garantire l\u2019integrit\u00e0 e la tracciabilit\u00e0. Ecco il design di ogni blocco che corrisponde al modello della tabella
signature_chain<\/code>.<\/p>\n\n\n\n- \n
id<\/code><\/strong> (SERIAL PRIMARY KEY): Un identificativo progressivo unico per il blocco.<\/li>\n\n\n\ndocument_id<\/code><\/strong> (UUID): Un identificativo UUID che lega la catena di firme a uno specifico documento. Questo permette di avere catene separate per documenti diversi.<\/li>\n\n\n\nsigner<\/code><\/strong> (VARCHAR(255)): Il nome o l’identificativo del firmatario.<\/li>\n\n\n\ndocument_hash<\/code><\/strong> (VARCHAR(64)): L’hash SHA-256 del contenuto originale del documento. Questo hash rimane costante per tutte le firme all’interno della stessa catena e dello stesso documento.<\/li>\n\n\n\nprev_hash<\/code><\/strong> (VARCHAR(128), NULLABLE): L’hash della firma (signature<\/code>) del blocco precedente nella catena. Per il primo blocco, noto come “blocco genesi”<\/strong>, questo valore \u00e8NULL<\/code>.<\/li>\n\n\n\nchain_hash<\/strong><\/code> (TEXT, GENERATED ALWAYS AS STORED): Colonna Calcolata Automaticamente.<\/strong> Questa colonna contiene l’hash SHA-256 della concatenazione diprev_hash<\/code> (o una stringa vuota seprev_hash<\/code> \u00e8NULL<\/code>) edocument_hash<\/code> del blocco corrente. In pratica, rappresenta l’hash dei dati che vengono effettivamente firmati digitalmente per produrre il camposignature<\/code>. Viene calcolata e memorizzata automaticamente dal database (encode(digest(coalesce(prev_hash, '') || document_hash, 'sha256'), 'hex')<\/code>). Sebbene non sia utilizzata attivamente dallo script Python per la logica di costruzione o verifica della catena (che ricalcola questi dati in memoria), pu\u00f2 essere utile per query dirette al database, per debug, o per meccanismi di verifica alternativi a livello di database.<\/li>\n\n\n\nsignature<\/code><\/strong> (VARCHAR(128)): La firma digitale RSA vera e propria. Viene calcolata firmando la concatenazione diprev_hash<\/code> edocument_hash<\/code> del blocco corrente. Questo campo funge da hash crittografico del blocco corrente e diventa ilprev_hash<\/code> per il blocco successivo.<\/li>\n\n\n\ncreated_at<\/code><\/strong> (TIMESTAMP DEFAULT CURRENT_TIMESTAMP): Il timestamp di creazione del blocco.<\/li>\n<\/ul>\n\n\n\nEsempio di record nella tabella<\/h2>\n\n\n\n
Di seguito \u00e8 presentata un’illustrazione dei record all’interno della tabella
signature_chain<\/code>, con esempi concreti che dimostrano la correlazione tra i campi e la formazione della catena:<\/p>\n\n\n\nBlocco 1 (Genesi – Firmatario: Antonio)<\/h4>\n\n\n\n
Campo<\/strong><\/td> Valore<\/strong><\/td> Descrizione<\/strong><\/td><\/tr> id<\/td> 1<\/td> L’identificativo del blocco, il primo in questa catena. Un semplice contatore, ma essenziale per l’ordinamento.<\/td><\/tr> document_id<\/td> c4a7a134-8a02-4bad-bc9f-395f7f0f1a33<\/td> L’identificativo universale univoco del documento oggetto di firma. Questo UUID (Universally Unique Identifier) assicura la distinzione di questo documento da qualsiasi altro nel sistema.<\/td><\/tr> signer<\/td> Antonio<\/td> L’identit\u00e0 del primo firmatario, chiaramente registrata.<\/td><\/tr> document_hash<\/td> f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2<\/td> L’hash SHA-256 del documento originale. Questo valore rappresenta il “DNA” crittografico del documento, una stringa di 64 caratteri esadecimali che lo identifica in modo univoco. Qualsiasi modifica al documento comporterebbe un hash differente.<\/td><\/tr> prev_hash<\/td> NULL<\/td> Poich\u00e9 si tratta del primo blocco, non esiste alcuna firma precedente a cui collegarsi, pertanto il valore \u00e8 nullo. Ci\u00f2 segnala l’inizio della catena.<\/td><\/tr> signature<\/td> a3f5b1\u2026c72e<\/td> Firma RSA: concatenazione di una stringa vuota (prev_hash nullo) e hash documento, firmata da Antonio. Risultato: stringa esadecimale di 128 caratteri.<\/td><\/tr> created_at<\/td> 2025-05-21 14:30:00.123456+00<\/td> La data e l’ora precise di apposizione della firma da parte di Antonio, inclusi i microsecondi e il fuso orario UTC. Questo timestamp \u00e8 cruciale per la cronologia.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Blocco 2 (Firmatario: Marianna)<\/h4>\n\n\n\n
Campo<\/strong><\/td> Valore<\/strong><\/td> Descrizione<\/strong><\/td><\/tr> id<\/td> 2<\/td> L’identificativo del blocco, il secondo in questa catena.<\/td><\/tr> document_id<\/td> c4a7a134-8a02-4bad-bc9f-395f7f0f1a33<\/td> L’identificativo del documento rimane invariato, poich\u00e9 la firma si riferisce al medesimo file. Questo \u00e8 fondamentale per raggruppare tutte le firme relative a un unico documento.<\/td><\/tr> signer<\/td> Marianna<\/td> L’identit\u00e0 del firmatario di questo blocco.<\/td><\/tr> document_hash<\/td> f2ca1bb6c7e907d06dafe4687e579fce76b37e4e93b7605022da52e6ccc26fd2<\/td> L’hash del documento rimane lo stesso, a riprova che il documento non ha subito modifiche tra la firma di Antonio e quella di Marianna. Una discrepanza in questo hash invaliderebbe la catena.<\/td><\/tr> prev_hash<\/td> a3f5b1\u2026c72e<\/td> Questo valore corrisponde alla signature<\/code> di Antonio dal Blocco 1. Costituisce il legame crittografico al blocco precedente, garantendo la sequenzialit\u00e0. Questo \u00e8 l’elemento chiave della concatenazione.<\/td><\/tr>signature<\/td> b8e0d9\u2026f4a1<\/td> Questa firma, calcolata sulla concatenazione della signature di Antonio e l\u2019hash del documento, \u00e8 unica per questo blocco e sequenza.<\/td><\/tr> created_at<\/td> 2025-05-21 14:35:00.654321+00<\/td> La data e l’ora precise di apposizione della firma da parte di Marianna. Si noti che \u00e8 successiva a quella di Antonio, confermando l’ordine cronologico.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Schema della catena delle firme<\/h2>\n\n\n\n
Il diagramma seguente illustra come i blocchi sono concatenati:<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2025\/05\/schema_catena_firme-1024x704.png\")
<\/figure>\n\n\n\nQuesto schema garantisce che ogni blocco sia inscindibilmente legato al precedente, formando una catena di integrit\u00e0.<\/p>\n\n\n\n
Meccanismi di Sicurezza in PostgreSQL per la Signature Chain<\/h2>\n\n\n\n
PostgreSQL, come database relazionale robusto, offre diversi meccanismi di sicurezza che sono fondamentali per implementare e mantenere l’integrit\u00e0 e l’immutabilit\u00e0 dei dati in una Signature Chain. L’esempio fornito nello script
init.sql<\/code> illustra l’applicazione di alcuni di questi principi chiave:<\/p>\n\n\n\n1. Principio del Privilegio Minimo (Least Privilege Principle)<\/h4>\n\n\n\n
Questo principio di sicurezza fondamentale suggerisce che a un utente o a un’applicazione dovrebbero essere concessi solo i privilegi minimi necessari per svolgere le proprie funzioni. Nello script
init.sql<\/code>, questo \u00e8 implementato attraverso:<\/p>\n\n\n\nCreazione di un utente applicativo dedicato:<\/strong> <\/p>\n\n\n
<code>CREATE<\/span> ROLE<\/span> app_user WITH<\/span> LOGIN PASSWORD<\/span> 'app_password'<\/span>;<\/code><\/code><\/span>Code language:<\/span> SQL (Structured Query Language)<\/span> (<\/span>sql<\/span>)<\/span><\/small><\/pre>\n\n\nViene creato un ruolo specifico (
app_user<\/code>) per l’applicazione, separato dall’utente amministratore del database.<\/p>\n\n\n\nConcessione di privilegi limitati:<\/strong> <\/p>\n\n\n
<code>GRANT<\/span> CONNECT<\/span> ON<\/span> DATABASE<\/span> signature_demo TO<\/span> app_user;GRANT<\/span> USAGE<\/span> ON<\/span> SCHEMA<\/span> public<\/span> TO<\/span> app_user;GRANT<\/span> SELECT<\/span>, INSERT<\/span> ON<\/span> signature_chain TO<\/span> app_user;GRANT<\/span> USAGE<\/span> ON<\/span> SEQUENCE<\/span> signature_chain_id_seq TO<\/span> app_user;<\/code><\/code><\/span>Code language:<\/span> SQL (Structured Query Language)<\/span> (<\/span>sql<\/span>)<\/span><\/small><\/pre>\n\n\nA
app_user<\/code> vengono concessi solo i permessi di connessione al database, uso dello schema pubblico, e specificamenteSELECT<\/code> eINSERT<\/code> sulla tabellasignature_chain<\/code>, oltre all’uso della sequenza ID. Notare l’assenza di permessi diUPDATE<\/code> oDELETE<\/code>, che \u00e8 cruciale per l’immutabilit\u00e0.<\/p>\n\n\n\n2. Sicurezza a Livello di Riga (Row Level Security – RLS)<\/h4>\n\n\n\n
La RLS in PostgreSQL permette di definire policy di sicurezza che controllano quali righe possono essere visualizzate o modificate da specifici utenti o ruoli, anche se questi utenti hanno permessi a livello di tabella. Questo aggiunge un ulteriore strato di controllo granulare. Nello script:<\/p>\n\n\n\n
Abilitazione e forzatura di RLS:<\/strong><\/p>\n\n\n
ALTER<\/span> TABLE<\/span> signature_chain ENABLE<\/span> ROW<\/span> LEVEL<\/span> SECURITY<\/span>;\nALTER<\/span> TABLE<\/span> signature_chain FORCE<\/span> ROW<\/span> LEVEL<\/span> SECURITY<\/span>;<\/code><\/span>Code language:<\/span> SQL (Structured Query Language)<\/span> (<\/span>sql<\/span>)<\/span><\/small><\/pre>\n\n\nQuesti comandi attivano la RLS per la tabella
signature_chain<\/code> e la forzano anche per il proprietario della tabella, garantendo che le policy siano sempre applicate.<\/p>\n\n\n\nDefinizione delle policy di immutabilit\u00e0:<\/strong><\/p>\n\n\n
CREATE POLICY allow_inserts_for_public ON signature_chain \nFOR<\/span> INSERT TO PUBLIC<\/span> WITH CHECK (true<\/span>);<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\nQuesta policy permette le operazioni di inserimento, essenziali per aggiungere nuove firme alla catena.<\/p>\n\n\n
CREATE POLICY allow_select_for_public ON signature_chain \nFOR<\/span> SELECT TO PUBLIC<\/span> USING (true<\/span>);<\/code><\/span>Code language:<\/span> PHP<\/span> (<\/span>php<\/span>)<\/span><\/small><\/pre>\n\n\nQuesta policy consente la lettura di tutte le righe, necessaria per la verifica della catena.<\/p>\n\n\n
- Alternative per la Firma Digitale<\/a>
- 2. Configurazione variabili d'ambiente (opzionale)<\/a>
- 2. Sicurezza a Livello di Riga (Row Level Security – RLS)<\/a>
- Blocco 2 (Firmatario: Marianna)<\/a><\/li><\/ul><\/li>
- Architettura e funzionamento<\/a>