Rotazione del keyset ECDSA — procedura pubblica
Dieci passi verificabili: annuncio, generazione, ritiro, collaudo, approvazione a due ruoli, sigillo di audit e verifica post-rotazione. Le chiavi ritirate restano pubblicate: la rotazione non deve mai invalidare una prova storica legittima.
staging
- Passo 1
Annuncio e finestra
La rotazione è annunciata come alert persistente in console con ambiente, motivo (scadenza o compromissione sospetta) e finestra prevista.
Verifica: L'alert esiste ed è ispezionabile prima che la nuova chiave sia usata.
- Passo 2
Generazione della nuova chiave di staging
Viene generata una coppia ECDSA P-256 con key_id nuovo e prefisso di ambiente staging. La chiave privata non lascia il server.
Verifica: Il keyset pubblico espone il nuovo key_id con stato attivo e ambiente staging.
- Passo 3
Ritiro della chiave precedente
La chiave precedente passa allo stato ritirata ma resta pubblicata: le prove storiche restano verificabili a tempo indeterminato.
Verifica: Il key_id ritirato è ancora risolvibile nel keyset pubblico.
- Passo 4
Firma di collaudo e verifica offline
Si emette un pacchetto di collaudo firmato con la nuova chiave e lo si verifica con il verificatore offline, senza rete.
Verifica: Verdetto VALID con la sola chiave pubblica nuova.
produzione
- Passo 5
Approvazione a due ruoli
La rotazione in produzione richiede approvazione Admin e Operator distinti; nessuna integrazione esterna può sostituirsi a questa approvazione.
Verifica: Il log di audit riporta due attori distinti con timestamp.
- Passo 6
Rotazione e sigillo di audit
La rotazione emette l'evento certified.key_rotated concatenato alla catena di audit, con key_id uscente ed entrante.
Verifica: L'evento è presente nella catena e la catena resta continua (prev_hash → entry_hash).
post-rotazione
- Passo 7
Verifica dei pacchetti storici
Si riverificano almeno tre pacchetti firmati con la chiave precedente: il verdetto deve restare VALID, perché il verificatore risolve il key_id dichiarato nel manifest.
Verifica: Nessun pacchetto storico regredisce a NOT_VERIFIED dopo la rotazione.
- Passo 8
Gestione dei key_id ritirati
Un key_id ritirato non firma più nulla, resta pubblicato per la verifica e può essere marcato revocato solo in caso di compromissione accertata.
Verifica: Tentare una nuova firma con un key_id ritirato fallisce; la verifica storica no.
- Passo 9
Comportamento su compromissione
Se la chiave è revocata per compromissione, i pacchetti che ha firmato passano a NOT_VERIFIED o REVOKED: nessun verdetto VALID silenzioso.
Verifica: Il verificatore pubblico restituisce un verdetto negativo esplicito, con motivo.
- Passo 10
Pubblicazione dell'evidenza
Il keyset aggiornato e l'evento di rotazione sono pubblicati; il Trust Pack riporta la nuova numerazione documentale e il checksum aggiornato.
Verifica: Il checksum del Trust Pack cambia e la versione precedente resta scaricabile.
Regole del keyset
- Ogni chiave ha un key_id stabile, un ambiente (staging o produzione) e uno stato (attiva o ritirata).
- Ogni firma dichiara il key_id: il verificatore risolve la chiave nel keyset pubblico, non indovina.
- La rotazione crea una nuova chiave attiva e ritira la precedente, che resta pubblicata a tempo indeterminato.
- Età massima consigliata della chiave attiva: 90 giorni, configurabile e visibile in console.
- Dopo una rotazione, i pacchetti storici restano VALID: cambia la chiave usata, non il verdetto.
- Una chiave revocata per compromissione porta i pacchetti che ha firmato a NOT_VERIFIED, non a VALID silenzioso.
Checklist di sicurezza per revisori esterni
- Il keyset pubblico è raggiungibile senza autenticazione e contiene chiavi attive e ritirate.
- Ogni manifest dichiara un key_id risolvibile nel keyset: nessuna chiave implicita.
- La verifica di un pacchetto storico riesce dopo una rotazione, senza contattare il server Bonketiba.
- La chiave privata non appare in nessun payload, log, PDF o risposta API.
- Il gap KM-4 (custodia non HSM) è dichiarato apertamente nelle superfici pubbliche.
- L'evento di rotazione è presente nella catena di audit e la catena resta continua.
- Un key_id ritirato non può firmare nuovi pacchetti.
- Una chiave revocata porta i pacchetti a un verdetto negativo esplicito, non a VALID.
- La rotazione in produzione richiede due approvazioni distinte e tracciate.
- Nessun connettore esterno (Slack, email) può alterare l'esito del Release Gate.