Chiavi, wallet e signer remoto#
CertiExch separa tre famiglie di chiavi: chiave applicativa per integrità interna, chiave del registro per firma degli export di continuità e chiave del wallet EVM per le transazioni sul rail. La separazione evita che una compromissione o una funzione tecnica attribuiscano poteri non necessari.
Wallet del rail#
Il wallet EVM firma deployment, allowlist, mint, burn e hold secondo il contratto. L’indirizzo non coincide con un conto di registrazione e la chiave privata non deve entrare nel processo PHP. RemoteLedgerWalletProvider invia al signer una richiesta deterministica contenente operazione, chain ID, contract, nonce, payload e idempotency key.
Requisiti del signer#
Il signer deve:
- essere raggiunto esclusivamente via HTTPS autenticato;
- verificare l’identità del chiamante;
- applicare policy per chiave e operazione;
- impedire firma arbitraria di payload non autorizzati;
- gestire nonce e sostituzione delle transazioni;
- conservare audit della richiesta e della risposta;
- restituire transaction hash e ricevuta correlabili;
- proteggere la chiave in HSM/KMS o ambiente equivalente.
Un “signer remoto” che accetta qualsiasi raw transaction firmabile non realizza una vera segregazione: sposta soltanto la chiave su un altro server.
Owner e operator#
Il contratto può distinguere owner, operator e indirizzi autorizzati. L’owner non dovrebbe essere usato per le operazioni quotidiane. La governance deve prevedere rotazione, revoca, recupero e, quando necessario, multisignature o approvazione fuori banda.
Nonce e retry#
Una transazione non confermata non va semplicemente reinviata con un nuovo nonce, perché potrebbe produrre doppia esecuzione. Il provider deve correlare wallet, nonce, transaction hash e intento. La sostituzione della stessa transazione richiede la policy EVM di fee bump e conserva il riferimento al tentativo precedente.
Sostituzione wallet cliente#
Il workflow di sostituzione del wallet nel registro è diverso dalla rotazione della chiave del signer del rail. Nel primo caso si mantiene la continuità della posizione del cliente; nel secondo si cambia l’infrastruttura che firma operazioni tecniche. Entrambi richiedono maker-checker, ma producono effetti differenti.
Test minimi#
La qualificazione deve includere firma autorizzata, operazione vietata, nonce duplicato, timeout, risposta malformata, transaction hash non valido, rotazione della chiave, indisponibilità HSM e tentativo di replay.