Oggi solo chi è pigro non ha scritto sulla tecnologia blockchain, sulle criptovalute e su quanto sia fantastica. Tuttavia, in questo articolo non loderò questa tecnologia, ma parlerò piuttosto dei suoi difetti e dei modi per affrontarli.

Durante il lavoro su uno dei progetti della società Altirix Systems, è emersa la necessità di confermare in modo sicuro e resistente alla censura i dati provenienti da una fonte esterna per la blockchain. Era necessario confermare le modifiche nei registri di un sistema terzo e, sulla base di queste modifiche, eseguire un ramo nella logica del contratto intelligente. A prima vista, il compito sembrava piuttosto banale, ma quando il risultato della sua esecuzione influisce sulla situazione finanziaria di una delle parti coinvolte, sorgono ulteriori requisiti. Prima di tutto, c'è la necessità di una fiducia totale in questo meccanismo di validazione. Ma procediamo con ordine.

Il problema è che la blockchain è di per sé un'entità autonoma e chiusa, quindi i contratti intelligenti all'interno della blockchain non sanno nulla del mondo esterno. Allo stesso tempo, le condizioni dei contratti intelligenti sono spesso legate a informazioni su eventi reali (ritardi dei voli, tassi di cambio, ecc.). Per garantire il corretto funzionamento dei contratti intelligenti, le informazioni provenienti dall'esterno della blockchain devono essere affidabili e verificate. Questo problema viene risolto attraverso l'uso di oracoli come Town Crier e DECO. Questi oracoli consentono ai contratti intelligenti nella rete blockchain di fidarsi delle informazioni da un server web affidabile, potremmo dire che sono fornitori di informazioni sicure.

Oracoli

Immagina che un contratto intelligente esegua un trasferimento di 0.001 btc al tuo wallet bitcoin in caso di vittoria della tua squadra di calcio preferita nella Coppa di Russia. In caso di vittoria reale, il contratto intelligente deve ricevere informazioni su quale squadra ha vinto, e qui sorgono diverse problematiche: dove reperire queste informazioni, come trasmetterle in sicurezza al contratto intelligente e come assicurarsi che le informazioni ricevute nel contratto intelligente corrispondano realmente alla realtà?

Per quanto riguarda la fonte delle informazioni, ci possono essere 2 scenari: collegare il contratto intelligente a un sito web di fiducia, dove le informazioni sui risultati delle partite sono archiviate in modo centralizzato, oppure collegare più siti e successivamente scegliere le informazioni in base a maggioranza di fonti che forniscono dati identici. Per assicurarsi che le informazioni siano corrette, si utilizzano oracoli, come Oraclize, che impiega TLSNotary (una modifica di TLS per dimostrare l'autenticità dei dati). Tuttavia, le informazioni su Oraclize sono facilmente reperibili su Google e ci sono vari articoli su Habr, mentre oggi parlerò di oracoli che utilizzano un approccio diverso alla trasmissione delle informazioni: Town Crier e DECO. Nell'articolo sono descritte le modalità operative di entrambi gli oracoli, oltre a un confronto dettagliato.

Town Crier

Town Crier (TC) è stato presentato dall'IC3 (The Initiative for CryptoCurrencies and Contracts) nel 2016 alla CCS'16. L'idea principale del TC è trasferire informazioni dal sito web al contratto intelligente e assicurarsi che le informazioni fornite dal TC siano le stesse del sito web. Il TC utilizza TEE (Trusted Execution Environment) per garantire l'autenticità delle informazioni. Nell'originale, il TC descrive il funzionamento con Intel SGX.
Town Crier è composto da una parte all'interno della blockchain e una parte all'interno del sistema operativo stesso: TC Server.

Il TC Contract si trova nella blockchain e funge da front end per il TC. Riceve richieste dall'CU (smart contract dell'utente) e restituisce risposte dal TC Server. All'interno del TC Server si trova un Relay che stabilisce una connessione tra l'enclave e la rete internet (traffico bidirezionale) e collega l'enclave alla blockchain. L'enclave contiene progencl, un codice che esegue le richieste provenienti dalla blockchain e restituisce messaggi alla blockchain con una firma digitale; progencl contiene parte del codice del contratto intelligente e svolge di fatto alcune delle sue funzioni.

L'enclave Intel SGX può essere vista come una libreria generale con API, funzionante tramite ecall. L'ecall trasferisce il controllo all'enclave. Quest'ultima esegue il proprio codice fino al termine o fino a quando non si verifica un'eccezione. Per invocare funzioni definite al di fuori dell'enclave, si utilizzano ocall. L'ocall viene eseguito al di fuori dell'enclave e trattato come una chiamata non sicura. Dopo l'esecuzione dell'ocall, il controllo torna all'enclave.

Nella parte di Enclave, viene configurato un canale sicuro con il server web, l'enclave esegue il handshake TLS con il server di destinazione e gestisce tutte le operazioni crittografiche internamente. La libreria TLS (mbedTLS) e il codice HTTP in una versione ridotta sono stati esportati nell'ambiente SGX. Inoltre, l'Enclave contiene certificati root CA (una raccolta di certificati) per verificare i certificati dei server remoti. Il Request Handler riceve una richiesta datagram nel formato fornito da Ethereum, la decripta e la analizza. Successivamente, genera una transazione Ethereum contenente il datagram richiesto, lo firma con skTC e lo invia al Relay.

La parte Relay include l'Interfaccia Client, TCP e l'Interfaccia Blockchain. L'Interfaccia Client è necessaria per l'attestazione del codice dell'enclave e la comunicazione con il cliente. Il cliente invia una richiesta di attestazione tramite ecall e riceve un timestamp firmato con skTC insieme ad att (firma di attestazione); successivamente att viene convalidato tramite Intel Attestation Service (IAS) e il timestamp viene verificato da un trusted time service. L'Interfaccia Blockchain verifica le richieste in entrata e registra le transazioni nella blockchain per la consegna dei datagram.

Lavorando con TEE, TC permette di avviare più enclave in parallelo, aumentando così la velocità di elaborazione delle informazioni di tre volte. Se con un'enclave funzionante la velocità era di 15 tx/sec, con 20 enclave avviate in parallelo, la velocità aumenta fino a 65 tx/sec; a titolo di confronto, la massima velocità nella blockchain di Bitcoin è di 26 tx/sec.

DECO

DECO (Decentralized Oracles for TLS) è stato presentato al CCS’20 e funziona con siti che supportano connessioni TLS. Garantisce la riservatezza e l'integrità dei dati.
DECO con TLS utilizza la crittografia simmetrica, quindi il cliente e il server web possiedono chiavi di crittografia, e il cliente può, se desidera, falsificare i dati della sessione TLS. Per risolvere questo problema, DECO utilizza un protocollo di handshake a tre vie tra prover (smart contract), verifier (oracolo) e web-server (fonte dei dati).

Il principio di funzionamento di DECO consiste nel fatto che il verificatore (prover) ottiene una parte dei dati D e conferma al verificatore (verifier) che D proviene dal server TLS S. Un'altra problematica è che TLS non firma i dati e il client TLS ha difficoltà a dimostrare che i dati provengono effettivamente da quel server (difficoltà di provenienza).

Nel protocollo DECO vengono utilizzate chiavi di crittografia KEnc e KMac. Il cliente invia una richiesta Q al server web, la risposta dal server R arriva in forma crittografata, ma il cliente e il server possiedono gli stessi KMac, e il cliente può falsificare il messaggio TLS. La soluzione di DECO consiste nel "nascondere" KMac dal cliente (prover) fino a quando non risponde alla richiesta. Ora KMac è suddiviso tra prover e verifier — KpMac e KvMac. Il server riceve KMac per crittografare la risposta utilizzando l'operazione sulle porzioni della chiave KpMac ⊕ KvMac = KMac.

Configurando uno handshake a tre vie, lo scambio di dati tra il cliente e il server avverrà con garanzia di sicurezza.

Parlando di un sistema di oracoli decentralizzati, non si può non menzionare Chainlink, che mira a creare una rete decentralizzata di nodi oracolo, compatibile con Ethereum, Bitcoin e Hyperledger, tenendo conto della modularità: ogni parte del sistema può essere aggiornata. Per garantire la sicurezza, Chainlink richiede a ogni oracolo coinvolto in un incarico di rilasciare una combinazione di chiavi (pubblica e privata). La chiave privata è utilizzata per generare una firma parziale, che contiene la loro soluzione alla richiesta di dati. Per ottenere una risposta, è necessario combinare tutte le firme parziali degli oracoli della rete.

Chainlink prevede di condurre un primo PoC DECO con un focus su applicazioni finanziarie decentralizzate, come i Mixicles. Al momento della scrittura dell'articolo, è stata pubblicata una notizia su Forbes riguardo all'acquisizione di DECO da parte di Chainlink dall'Università di Cornell.

Attacchi agli oracoli

Dal punto di vista della sicurezza informatica, sono stati considerati i seguenti attacchi a Town Crier:

1. Iniezione di codice smart contract malevolo sui nodi TEE.
   L'essenza dell'attacco: inviare al TEE un codice di smart contract intenzionalmente errato; in questo modo, un aggressore che ha accesso al nodo sarà in grado di eseguire il proprio smart contract (fraudolento) sui dati decrittografati. Tuttavia, i valori restituiti verranno crittografati con la chiave privata, e l'unico modo per accedere a tali dati sarebbe la fuga del testo crittografato durante il ritorno/output.
   La protezione contro questo attacco consiste nel verificare da parte dell'enclave la correttezza del codice all'indirizzo attuale. Questo può essere realizzato tramite uno schema di indirizzamento, in cui l'indirizzo del contratto è definito attraverso l'hashing del codice del contratto.

2. Le modifiche al ciphertext dello stato del contratto rivelano la fuga.
   Essenza dell'attacco: I proprietari dei nodi sui quali vengono eseguiti smart contract hanno accesso allo stato del contract in forma crittografata al di fuori dell'enclave. Un aggressore, ottenendo il controllo del nodo, può confrontare lo stato del contract prima e dopo l'esecuzione della transazione e può determinare quali argomenti sono stati forniti e quale metodo dello smart contract è stato utilizzato, poiché il codice stesso dello smart contract e le sue specifiche tecniche sono pubblicamente disponibili.
   Protezione per garantire l'affidabilità del nodo stesso.

3. Attacchi side-channel.
   Un tipo particolare di attacchi che utilizza il monitoraggio dell'accesso alla memoria e alla cache dell'enclave in diversi scenari. Un esempio di tale attacco è Prime and Probe.
   
   Procedura per condurre l'attacco:

   • t0: L'aggressore riempie l'intera cache dati del processo della vittima.
   • t1: La vittima esegue codice con accessi alla memoria che dipendono da dati riservati (chiavi crittografiche). La scelta della cache line avviene in base al valore di keybit. Nell'esempio mostrato, keybit = 0 e l'indirizzo X è stato letto nella cache line 2. I dati contenuti in X vengono caricati nella cache, sostituendo quelli precedentemente memorizzati.
   • t2: L'aggressore verifica quali delle sue righe di cache sono state sostituite — righe utilizzate dalla vittima. Questo avviene misurando il tempo di accesso. Ripetendo questa operazione per ciascun keybit, l'aggressore ottiene l'intera chiave.

Protezione contro l'attacco: In Intel SGX esiste una protezione contro gli attacchi side-channel, che proibisce il monitoraggio degli eventi legati alla cache, ma l'attacco Prime and Probe può comunque avvenire, poiché l'aggressore osserva gli eventi della cache del proprio processo e condivide la cache con la vittima.

Pertanto, al momento non esiste una protezione affidabile contro questo attacco.

Esistono anche attacchi di tipo Spectre e Foreshadow (L1TF), simili a Prime and Probe. Questi permettono di leggere dati dalla memoria cache attraverso un canale esterno. È prevista una protezione contro la vulnerabilità Spectre-v2, attiva contro questi due attacchi.

Relativamente a DECO, il handshake tripartito fornisce garanzie di sicurezza:

1. Prover Integrity: un prover compromesso non può falsificare informazioni sulla provenienza del server e non può costringere il server ad accettare richieste non valide o a rispondere in modo errato a richieste valide. Questo è realizzabile tramite modelli di richiesta tra server e prover.
2. Verifier Integrity: un verifier compromesso non può costringere il prover a ricevere risposte errate.
3. Riservatezza: un verifier compromesso esamina solo informazioni pubbliche (richiesta, nome del server).

In DECO sono possibili solo vulnerabilità legate all'iniezione di traffico. All'inizio, durante il handshake tripartito, il verifier può stabilire l'identità del server tramite un nonce fresco. Tuttavia, dopo il handshake, il verifier deve affidarsi agli indicatori a livello di rete (Indirizzi IP). Pertanto, la connessione tra verifier e server deve essere protetta da iniezioni di traffico. Questo viene raggiunto utilizzando un Proxy.

Confronto degli oracoli

Town Crier si basa sul lavoro con l'enclave sul lato del server, mentre DECO consente di verificare l'autenticità delle origini dei dati tramite un handshake tripartito e la crittografia dei dati con chiavi crittografiche. Il confronto dei dati degli oracoli è avvenuto in base ai seguenti criteri: prestazioni, sicurezza, costo e praticità.

Town Crier
DECO

prestazioni
Più veloce (0,6s per completare)
Più lento (10,50s per completare il protocollo)

sicurezza
Meno sicuro
Più sicuro

costo
Più costoso
Più economico

praticità
Richiede hardware specifico
Funziona con qualsiasi server che supporti TLS

Prestazioni: Per lavorare con DECO è necessaria una configurazione del handshake tripartito, attraverso LAN richiede 0,37 secondi, per interazioni successive all'instaurazione della connessione è efficace 2PC-HMAC (0,13 s per la scrittura). Le prestazioni di DECO dipendono dai set di ciphers TLS disponibili, dalla dimensione dei dati personali e dalla complessità delle prove per l'applicazione specifica. Nell'esempio dell'applicazione di opzioni binarie di IC3: il completamento del protocollo tramite LAN richiede circa 10,50 s. In confronto, Town Crier richiede circa 0,6 secondi per eseguire un'applicazione analoga, ovvero circa 20 volte più veloce rispetto a DECO. In condizioni equivalenti, TC sarà più veloce.

Sicurezza: Gli attacchi all'enclave Intel SGX (attacchi side-channel) funzionano e possono causare danni reali ai partecipanti dello smart contract. Per quanto riguarda DECO, sono possibili attacchi legati all'iniezione di traffico, ma l'uso di un proxy neutralizza tali attacchi. Pertanto, DECO è più sicuro.

Costo: Il costo dell'hardware che supporta l'operatività con Intel SGX è superiore al costo della configurazione del protocollo in DECO. Pertanto, TC è più costoso.

Praticità: Per lavorare con Town Crier è necessario un hardware specifico che supporti TEE. Ad esempio, Intel SGX è supportato sui processori della famiglia Intel Core di sesta generazione e successivi. DECO, invece, consente di lavorare con qualsiasi hardware, anche se c'è una configurazione di DECO che utilizza TEE. Durante il processo di configurazione, il handshake tripartito di DECO può richiedere del tempo, ma questo non si confronta affatto con le limitazioni hardware di TC, rendendo quindi DECO più pratico.

Conclusione

Analizzando i due oracoli separatamente e confrontandoli su quattro criteri, emerge che Town Crier è inferiore a DECO in tre dei quattro aspetti. DECO è più affidabile in termini di sicurezza delle informazioni, è più economico e più pratico, anche se la configurazione del protocollo tripartito può richiedere del tempo e presenta alcuni svantaggi, come operazioni aggiuntive con le chiavi di crittografia. TC funziona più velocemente di DECO, ma la vulnerabilità legata agli attacchi side-channel lo espone al rischio di perdita di riservatezza. Va considerato che DECO è stato introdotto a gennaio 2020 e non è ancora passato abbastanza tempo per considerarne la sicurezza. Town Crier ha già subito attacchi per 4 anni ed ha superato numerosi controlli, quindi il suo utilizzo in molti progetti è giustificato.

Fonte: habr.com