Marcatura temporale OpenTimestamps
Ogni blocco è ancorato nella blockchain Bitcoin tramite OpenTimestamps: una prova, indipendente dalla piattaforma, che i suoi byte esatti esistevano al più tardi a una data determinata.
La blockchain è il sovra-protocollo che rende l’integrità e l’immutabilità del registro pubblico verificabili da chiunque; l’ancoraggio OpenTimestamps ne è la parte che prova quando ogni blocco esisteva. Non richiede alcuna fiducia nella piattaforma né nelle sue chiavi: il file .ots si verifica contro il blocco con gli strumenti OpenTimestamps standard.
Protocollo v1
Una data che la piattaforma non può retrodatare.
La firma della piattaforma prova che un blocco proviene da essa; non prova che la storia non sia stata riscritta. Un ancoraggio esterno, fuori dalla portata delle sue chiavi, colma una parte di questo divario.
- Una firma non è l’immutabilità. La piattaforma detiene la propria chiave di firma: potrebbe rifirmare una catena riscritta, i cui blocchi si verificherebbero ancora tutti.
- La data di una firma è un’affermazione. Il signed_at è la data di creazione che il firmatario stesso iscrive nella firma: una chiave trafugata può retrodatare una firma all’interno della propria finestra di validità.
- Un blocco Bitcoin non si retrodata. Un’attestazione Bitcoin non è un’affermazione della piattaforma: prova che i byte esatti del blocco esistevano al più tardi al blocco Bitcoin attestato, indipendentemente dalle chiavi della piattaforma. Delimita così la finestra di retrodatazione di una chiave trafugata.
- Un rafforzamento delle copie indipendenti. L’immutabilità poggia in pratica sulle copie dei blocchi pubblicati che chiunque può conservare. L’ancoraggio vi aggiunge una prova di esistenza di terza parte: una storia riscritta non può ottenere attestazioni retrodatate.
Lo SHA-256 del file, così come è pubblicato.
Ogni blocco, qualunque sia il suo tipo (configuration, rings, votes, closure), riceve la propria prova. Viene sottoposto ai calendari OpenTimestamps al momento della sigillatura, subito dopo la registrazione della sua riga di ancoraggio nel database. L’impegno riguarda il file pubblicato stesso: la prova si verifica contro il blocco scaricato, senza nient’altro.
-
sha256({n}.json)SHA-256 · impegno - Lo SHA-256 semplice dei byte del file di blocco: i byte esatti che vengono archiviati, serviti, sottoposti a hash e firmati.
-
nonceassente - Sottoposto deliberatamente senza il consueto nonce di riservatezza di OpenTimestamps, poiché i byte sono pubblici per progettazione: l’impegno presso i calendari è uguale a sha256({n}.json), e qualsiasi strumento OpenTimestamps standard verifica la prova senza fiducia nella piattaforma.
-
SHA3-512impronta di concatenamento - Da non confondere: l’impronta di un blocco nella catena (content_hash, previous_hash del blocco successivo) resta lo SHA3-512 del file. Lo SHA-256 è soltanto l’impegno OpenTimestamps.
Da pending a completed.
Una prova OpenTimestamps si completa in due tempi: i calendari si impegnano subito, Bitcoin conferma in seguito, tipicamente in poche ore. Lo stato della prova è l’unico dato modificabile di un blocco, e cambia una sola volta, in un solo senso.
-
1
Invio alla sigillatura.
La piattaforma invia l’impegno ai server di calendario OpenTimestamps pubblici e archivia la prova ricevuta accanto al blocco. L’invio è a miglior sforzo: un’interruzione dei calendari non ritarda né fa fallire la pubblicazione del blocco, il cui file .ots manca allora fino alla riconciliazione successiva.
-
2
pending: i calendari si sono impegnati.
La prova porta gli impegni dei calendari, non ancora un’attestazione Bitcoin. È già scaricabile, ma non prova ancora alcuna data in Bitcoin.
-
3
Una riconciliazione ogni ora.
Ogni ora, ciascun blocco ancora pending viene ripreso. Una prova mancante viene reinviata a partire dai byte archiviati: l’ancoraggio parte allora da questo nuovo invio. Per un blocco pubblicato da più di 4 ore, il tempo tipico di una conferma Bitcoin, i calendari vengono interrogati. Questa cadenza oraria funge da politica di ritentativo.
-
4
completed: Bitcoin ha confermato.
Non appena i calendari forniscono l’attestazione Bitcoin, la prova arricchita sostituisce il file .ots archiviato e lo stato del blocco passa a completed. Non torna mai a pending.
Un terzo file, accanto al blocco e alla sua firma.
La prova è servita con il blocco {n}.json e la sua firma {n}.json.sig, qualunque sia il suo stato, e il suo stato figura nel manifesto dell’elezione. Questi file esistono finché l’elezione ha un registro pubblico, dall’apertura all’archiviazione; un’elezione annullata li ritira.
-
/elections/{election}/chain/{n}.json.otsRotta pubblica - Reindirizza al file archiviato. Servita in attesa come completata: una prova pending porta già gli impegni dei calendari.
-
{election}/{election}_{n}.json.otsFile archiviato - Archiviato accanto al blocco e denominato con l’identificativo dell’elezione: una copia staccata dal suo URL resta identificabile.
-
ots_url · ots_statusManifesto - Per ogni blocco, il manifesto (/elections/{election}/chain) indica l’URL diretto della prova e il suo stato, pending o completed. La pagina del registro mostra lo stesso stato su ogni download .ots: «in attesa di ancoraggio Bitcoin» o «ancorato in Bitcoin».
-
pending → completedSostituito una volta - Il file .ots non è immutabile: la prova arricchita sostituisce quella in attesa, affinché download e mirror ottengano sempre la più completa. Il blocco, invece, non cambia mai; nel database, lo stato è l’unica colonna che la tabella dei blocchi, a sola aggiunta, consente di modificare, e soltanto in quel senso.
-
{n}.json.otsAccesso - Le prove .ots, come il manifesto e i blocchi JSON, restano scaricabili per tutte le elezioni, qualunque sia l’offerta. Soltanto il download delle firme .sig è riservato alle elezioni Ufficiali, e soltanto nell’interfaccia.
ots verify, contro il file scaricato.
La piattaforma riferisce lo stato della prova, ma non effettua essa stessa alcuna verifica sulla blockchain Bitcoin: spetta al verificatore farlo, con gli strumenti OpenTimestamps standard. Nella procedura di verifica completa, questo controllo è facoltativo.
-
1
Recuperare il blocco e la sua prova.
Il file {n}.json e la sua prova {n}.json.ots, dal registro pubblico dell’elezione o dagli URL del manifesto. Lo stato indicato dal manifesto è una dichiarazione della piattaforma; fa fede soltanto la verifica.
-
2
Verificare la prova contro il file.
ots verify -f {n}.json {n}.json.ots. Poiché l’impegno è lo SHA-256 semplice del file, nessun dato della piattaforma interviene: un file modificato anche di un solo byte non corrisponde più alla prova.
-
3
Riprendere una prova in attesa.
Una prova pending non indica ancora un blocco Bitcoin. Poiché il file archiviato viene sostituito dalla prova completata, basta scaricarlo di nuovo una volta che lo stato è passato a completed, in genere poche ore dopo la pubblicazione del blocco.
Che cosa dimostra: Una prova completata che si verifica stabilisce che il blocco esisteva, byte per byte, al più tardi al blocco Bitcoin attestato, indipendentemente dalle chiavi della piattaforma.
La procedura di verifica completa# lo stato di ogni prova (ots_status), nel manifesto
curl -s https://admin.stg.condorcet.vote/elections/{election}/chain
# il blocco n e la sua prova (le rotte reindirizzano ai file archiviati)
curl -sL -o {n}.json https://admin.stg.condorcet.vote/elections/{election}/chain/{n}.json
curl -sL -o {n}.json.ots https://admin.stg.condorcet.vote/elections/{election}/chain/{n}.json.ots
# l'impegno: lo SHA-256 semplice del file
openssl dgst -sha256 {n}.json
# la prova contro il file
ots verify -f {n}.json {n}.json.ots
Ciò che l’ancoraggio non dimostra.
L’ancoraggio prova quando dei byte esistevano. Si aggiunge agli altri controlli, non li sostituisce.
- Un limite superiore, non una data esatta. Una prova completata stabilisce che il blocco esisteva al più tardi al blocco Bitcoin attestato. Una prova ancora pending non prova, invece, alcuna data in Bitcoin.
- Non l’esattezza del contenuto. L’ancoraggio riguarda dei byte, quali che siano: la validità delle schede, dei limiti di partecipazione e del risultato si controlla con la procedura di verifica.
- Non l’autenticità. La prova è indipendente dalle chiavi della piattaforma, e dunque non dice nulla sull’autore del blocco. Questo ruolo spetta alla firma OpenPGP, da verificare con le chiavi di verifica pubblicate.
- Non l’unicità della storia. Una storia riscritta non può ottenere attestazioni retrodatate, ma l’ancoraggio da solo non prova che una data storia sia l’unica pubblicata: le copie indipendenti restano la difesa contro la riscrittura.
- Non una marcatura temporale qualificata. Una marcatura temporale RFC 3161 rilasciata da un’autorità di marcatura temporale, con valore probatorio eIDAS, resta un complemento possibile; oggi non è offerta.
Vedi anche
- Blockchain Il sovra-protocollo che sigilla il registro: busta, quattro tipi di blocco, serializzazione, concatenamento, firma, marcatura temporale.
- Chiavi della piattaforma I certificati OpenPGP v6 che firmano i blocchi, la loro rotazione e il loro punto di accesso per le macchine.
- Procedura di verifica Verificare un'elezione da cima a fondo: dal solo registro, oppure con la blockchain.