La sicurezza della blockchain

La storia ha fatto il giro del mondo. Il massimo della sicurezza si può trasformare nella incertezza più assoluta. Muore il fondatore di un Exchenge, unico possessore delle password di informazioni tutte criptate in un pc, e vanno in fumo 150 milioni di Bitcoin. O ancora scompare uno dei primi minatori di bitcoin e le criptovalute da lui minate scompaiono con lui (leggi qui). Va da sé che tutto questo non ha nulla a che fare con la sicurezza della blockchain.

O forse meglio, come mi suggerisce chi di questi temi si occupa in maniera specifica, la questione in questo caso è che la blockchain è troppo sicura. Se non c’è una copia delle password, un erede indicato in uno smart contract, alla morte della persona è impossibile recuperare le criptovalute. Insomma, la cassaforte è sicurissima, tanto sicura che non si può aprire se non è stato previsto un meccanismo di recupero della password. Mi dicono che esistono smart contract che prevedono la firma di 2 o 3 persone, oppure che se i valori non vengono mossi per due o tre anni una terza persona può attivare un meccanismo per entrarne in possesso.

Certamente il tema sicurezza in tutti i suoi aspetti e con tutte le sue sfumature è quanto mai all’attenzione.

Mi passa tra le mani un documento su minacce, vulnerabilità e rischi della Distributed Ledger Technology (Dlt). Non è un’analisi casuale, ma un approfondimento di chi a questo lavora, con la tassonomia precisa. 

Continuano apparire analisi secondo cui la blockchain non è sicura (vedi qui), ma anche studi che dicono il contrario. E così c’è chi mette l’accento sull’inattaccabilità della blockchain per l’uso di chiavi pubbliche e private e di una criptografia ormai matura (leggi qui).

 Alla sicurezza si lavora. È una costante messa a punto, fatta di approssimazioni, analisi, azioni e reazioni. Insomma, la sicurezza non è statica, ma dinamica, non si può dichiarare certa per definizione. Non è un dogma di fede, ma un processo su cui impegnarsi. Ogni sicurezza può diventare più sicura nei limiti dello scenario, che è come dire rebus sic stantibus. Perché va da sé che l’arrivo dei computer quantistici (leggi qui)  può spazzare via le certezze di anni.

Assodato che siamo tutti mortali, che la sicurezza in assoluto non esiste, che fine e mezzi vanno calibrati, che di assoluto c’è solo Dio su di un piano teologico...è nelle cose che permissioned risponde meglio ai bisogni dei pragmatici. E chi vuole una costruzione perfetta è bene si accontenti della costruzione in sé più che dell’obiettivo concreto di rispondere a bisogni reali...

Il confronto tra massimalisti e pragmatici continua a catalizzare l’attenzione. Ed è un po’ il sale della vita. Lo so che permissioned, con la partecipazione secondo regole precise, non è abbastanza fascinosa, o almeno non quanto permissioless, dove ognuno può entrare e contribuire liberamente. E che i puristi mi faranno a pezzi. Ma ogni volta che c’è da mettere mano a qualcosa di un minimo più delicato la scelta cade su permissioned. È più che altro un dato di fatto, una constatazione di come vanno le cose. E così, per esempio, anche Libra va verso uno schema permissioned.

Proprio per garantire livelli di sicurezza sempre maggiori, ma anche privacy dei dati e scalabilità, Spunta Project, l’iniziativa varata da ABI Lab, il Centro di ricerche e innovazione per la banca dell’ABI, lavora all’applicazione di una Dlt permissioned per il riscontro delle poste dei conti reciproci delle banche. Sicurezza è anche tutela dei propri dati personal. Spunta Project sta sviluppando una funzionalità per archiviare i dati e per eliminarli dal ledger dopo 15 mesi. D’altra parte il Gdpr, la normativa che si occupa di tutela dei dati (vedi qui), prevede la possibile richiesta di cancellare i propri riferimenti. E se un cliente lo chiede la banca deve cancellare i dati, anche dal ledger. Sarà poco aderente ad un’idea fantastica di conservazione eterna di tutti i dati, ma certo più vicina alla concretezza della realtà.