Aggiornamenti di agosto bloccano la fuga critica della chiave privata nel portafoglio crypto Vultisig

Vultisig, un portafoglio crypto che utilizza la firma condivisa, ha gestito in modo errato un segnale di arresto critico nella sua implementazione della firma ECDSA, come scoperto dai ricercatori di sicurezza di ChainSecurity.

La divulgazione del 21 ottobre dei ricercatori descrive come continuare dopo l'errore potrebbe consentire a un firmatario già compromesso di recuperare l'intera chiave privata.

Sia i manutentori di Android che di iOS hanno descritto un codice che riprovava dopo che la libreria aveva identificato un partecipante malevolo, quindi hanno aggiunto una gestione per fermare quei ripetuti tentativi e avvisare l'utente. Le modifiche appaiono nelle note di rilascio del repository successivo.

Richiedere diversi dispositivi offre protezione solo se il software mantiene quel requisito quando un partecipante inizia a comportarsi in modo scorretto.

Un portafoglio di calcolo multi-party (MPC wallet) distribuisce l'autorità di firma tra le condivisioni delle chiavi. Abbastanza condivisioni cooperano per produrre una firma standard della blockchain senza assemblare l'intera chiave privata durante il normale funzionamento.

In un accordo a due dispositivi che richiede entrambi i partecipanti, compromettere uno dovrebbe lasciare l'attaccante dipendente dall'approvazione dell'altro dispositivo.

Il difetto divulgato riguardava la firma ECDSA e richiedeva quella compromissione iniziale. Un attaccante potrebbe quindi inviare molti messaggi di firma malevoli e osservare se l'altro firmatario restituisce un errore.

Quelle risposte rivelavano pezzi di un seme di protocollo interno riutilizzabile, consentendo infine il recupero dell'altra condivisione e dell'intera chiave, secondo ChainSecurity.

Quel seme è un segreto di configurazione interno, e la libreria assumeva che ulteriori firme si sarebbero fermate dopo l'errore critico fino a quando il seme non fosse stato ruotato. L'applicazione mostrava un errore generico e non imponeva quella risposta.

Il flusso ECDSA storico di Vultisig potrebbe rivelare materiale chiave attraverso risposte di errore ripetute; gli aggiornamenti di agosto ora fermano i ripetuti tentativi e identificano il dispositivo compromesso.

La conseguenza di sicurezza è che un tentativo di firma fallito può avere importanza anche quando non produce una firma di transazione utilizzabile.

Se continuare lo scambio rivela ulteriori informazioni segrete, rifiutare la transazione da solo non preserva la separazione promessa tra i firmatari. L'applicazione deve rispondere al fallimento del protocollo stesso.

Cosa dimostrano le modifiche di agosto

La modifica di Android (#5658) e la modifica di iOS (#5235) sono state entrambe unite il 21 agosto, due mesi prima della divulgazione pubblica.

Le loro descrizioni dicono che il vecchio codice confrontava i fallimenti di firma con il risultato di successo della libreria senza gestire separatamente gli errori di divieto del partecipante malevolo. Le routine di firma potevano riprovare fino a tre volte, mentre l'utente riceveva un messaggio di errore generico.

Quel conteggio dei ripetuti tentativi non stabilisce quanti messaggi sarebbero stati necessari per recuperare una chiave, o quante sessioni un attaccante avrebbe bisogno.

Le modifiche al codice di Android e le modifiche a iOS riconoscono i codici di errore del partecipante malevolo della libreria di firma DKLS durante la configurazione della sessione, l'elaborazione dei messaggi e il completamento della firma.

Entrambi mappano il partecipante contrassegnato a un identificatore del dispositivo, portano un errore dedicato oltre i ripetuti tentativi automatici e mostrano un avviso localizzato contro l'uso di quel dispositivo di nuovo. Su Android, l'eccezione bypassa anche il recupero del relay.

Insieme, queste modifiche mostrano che le app distinguono un verdetto crittografico su un partecipante da un normale fallimento di firma.

Il comportamento di ripetizione appropriato per un fallimento temporaneo può diventare pericoloso quando la libreria sta dicendo al chiamante di smettere di interagire con un firmatario malevolo.

Le note di GitHub per iOS v1.45.71, datate 21 agosto, elencano #5235. Il rilascio di Android v1.0.118, datato 25 agosto, elenca #5658.

I conteggi del portafoglio e l'ambito dell'audit necessitano di contesto

Le descrizioni del vault di Vultisig distinguono chi controlla i firmatari. Fast Vault utilizza un dispositivo utente con VultiServer che detiene la seconda condivisione e co-firma. Secure Vault utilizza due o più dispositivi detenuti dall'utente senza VultiServer.

Un portafoglio assistito da un fornitore e un portafoglio distribuito tra i dispositivi dell'utente possono entrambi utilizzare la firma distribuita, ma le loro dipendenze operative differiscono. Due partecipanti in uno scambio di firma non devono nemmeno significare che il vault abbia solo due condivisioni in totale.

La divulgazione e i materiali dell'applicazione esaminati non forniscono una matrice completa delle versioni interessate e delle configurazioni del vault.

La documentazione di sicurezza di Vultisig afferma che Trail of Bits ha auditato la libreria DKLS23 di Silence Laboratories nel 2024. Dice che i rapporti di audit delle applicazioni mobili e desktop saranno collegati quando pubblicati.

Al momento della divulgazione, ChainSecurity ha dichiarato di non aver esaminato le correzioni di Vultisig né di aver auditato altre parti del protocollo, quindi le correzioni sono rimaste al di fuori di quella valutazione.

Dettagli utili di rimedio collegherebbero le configurazioni interessate alle versioni spedite e spiegherebbero l'applicazione dopo sia i riavvii automatici che quelli avviati dall'utente. Una revisione che copre quei comportamenti affronterebbe il fallimento a livello di applicazione descritto qui.

I titolari di protezione sono promessi che l'applicazione deve far rispettare la condizione di arresto della libreria durante tutta la firma, incluso quando gli utenti ricominciano dopo un fallimento.