Oggi solo i pigri non hanno scritto sulla tecnologia blockchain, le criptovalute e quanto sia incredibile. Ma in questo articolo non ci sarà alcun elogio per tale tecnologia, si parlerà proprio dei suoi svantaggi e dei modi per affrontarli.

Durante il lavoro su uno dei progetti dell'azienda Altyrix Systems, è emersa la necessità di una conferma sicura e resistente alla censura dei dati da una fonte esterna per la blockchain. Era necessario convalidare le modifiche nei registri di un terzo sistema e, sulla base di queste modifiche, eseguire un ramo logico nel contratto intelligente. A prima vista, questo compito può sembrare piuttosto banale, ma quando il risultato della sua esecuzione influisce sulla situazione finanziaria di una delle parti coinvolte nel processo, sorgono requisiti aggiuntivi. Prima di tutto, c'è bisogno di una fiducia totale in questo tipo di meccanismo di validazione. Ma andiamo con ordine.

Il problema sta nel fatto che la blockchain è autonomo e un oggetto chiuso, 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 (ritardo di volo, tasso di cambio, ecc.). Per un corretto funzionamento dei contratti intelligenti, le informazioni ottenute 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 permettono al contratto intelligente nella rete blockchain di fidarsi delle informazioni provenienti da un server web verificato, si potrebbe dire che sono fornitori di informazioni affidabili.

Oracoli

Immaginate che un contratto intelligente effettui un trasferimento di 0.001 btc nel vostro portafoglio bitcoin in caso di vittoria della vostra squadra di calcio preferita nella Coppa di Russia. In caso di vittoria effettiva, al contratto intelligente sarà necessario fornire informazioni su quale squadra ha vinto, e qui sorgono una serie di problemi: dove ottenere queste informazioni, come trasmetterle in sicurezza al contratto intelligente e come assicurarsi che le informazioni fornite al contratto intelligente corrispondano effettivamente alla realtà?

Nel caso della fonte di informazione possono esserci 2 scenari: collegare un contratto intelligente a un sito web fidato, dove le informazioni sui risultati delle partite sono conservate in modo centralizzato, e la seconda opzione è collegare più siti e poi selezionare le informazioni dalla maggior parte delle fonti che forniscono dati identici. Per assicurarsi della correttezza delle informazioni, si utilizzano oracle, ad esempio Oraclize, che utilizza TLSNotary (modifica del TLS per la verifica dell'autenticità dei dati). Ma su Oraclize ci sono sufficienti informazioni su Google, e ci sono diversi articoli su Habr, io vi parlerò oggi degli oracle che utilizzano un approccio leggermente diverso alla trasmissione delle informazioni: Town Crier e DECO. L'articolo descrive i principi di funzionamento di entrambi gli oracle e un confronto dettagliato.

Town Crier

Town Crier (TC) è stato presentato da IC3 (The Initiative for CryptoCurrencies and Contracts) nel 2016 a CCS'16. L'idea principale di TC: trasmettere informazioni dal sito web al contratto intelligente e assicurarsi che le informazioni fornite da TC siano le stesse di quelle sul sito web. TC utilizza TEE (Trusted Execution Environment) per l'autenticità della proprietà dei dati. Nella versione originale di TC, è descritto il funzionamento con Intel SGX.
Town Crier è composto da una parte all'interno della blockchain e da una parte all'interno del sistema operativo stesso — TC Server.

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

L'enclave Intel SGX può essere considerata come una libreria generale con API, che funziona attraverso ecall. L'ecall trasferisce il controllo all'enclave. L'enclave esegue il proprio codice fino al termine o fino a quando non si verifica un'eccezione. Per chiamare le funzioni definite al di fuori dell'enclave, si utilizzano ocall. L'ocall viene eseguito al di fuori dell'enclave e viene gestito come una chiamata non fidata. Dopo l'esecuzione dell'ocall, il controllo ritorna all'enclave.

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

La parte Relay comprende 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 all'att (firma di attestazione), poi att viene confermata tramite Intel Attestation Service (IAS) e il timestamp viene verificato da un trusted time service. L'interfaccia Blockchain controlla le richieste in arrivo e inserisce le transazioni nella blockchain per la consegna dei datagram. Geth è il client ufficiale di Ethereum e consente a Relay di interagire con la blockchain tramite chiamate RPC.

Lavorando con TEE, TC consente di avviare più enclave in parallelo, aumentando così la velocità di elaborazione delle informazioni di 3 volte. Se con un'enclave funzionante la velocità era di 15 tx/sec, con 20 enclave avviate in parallelo la velocità sale a 65 tx/sec; per confronto, la velocità massima operativa della blockchain di Bitcoin è di 26 tx/sec.

DECO

DECO (Decentralized Oracles for TLS) è stato presentato a CCS'20 e funziona con siti che supportano la connessione TLS. Garantisce la riservatezza e l'integrità dei dati.
DECO con TLS utilizza la crittografia simmetrica, in modo che il cliente e il server web condividano le chiavi di crittografia e il cliente, se desidera, può 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 di 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 quindi il cliente TLS ha difficoltà a dimostrare che i dati sono stati ricevuti specificamente da quel server (difficoltà di provenienza).

Nel protocollo DECO vengono utilizzate le chiavi di crittografia KEnc e KMac. Il cliente invia una richiesta Q a server web, la risposta del 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 attraverso l'operazione sulle parti della chiave KpMac ⊕ KvMac = KMac.

Impostando un handshake trilaterale, lo scambio di dati tra cliente e server avverrà con garanzia di sicurezza.

Parlando di un sistema di oracle decentralizzati, non si può non menzionare Chainlink, che mira a creare una rete decentralizzata di nodi oracle compatibili con Ethereum, Bitcoin e Hyperledger, tenendo conto della modularità: ogni parte del sistema può essere aggiornata. Per garantire la sicurezza, Chainlink propone a ciascun oracle coinvolto nel compito di emettere una combinazione di chiavi (pubblica e privata). La chiave privata viene utilizzata per generare una firma parziale che contiene la loro soluzione alla richiesta di dati. Per ottenere la risposta è necessaria la combinazione di tutte le firme parziali degli oracle della rete.

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

Attacchi agli oracle

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

1. Iniezione di codice di smart contract malevolo sui nodi TEE.
   La natura dell'attacco: invio a TEE di codice di smart contract volutamente errato, in modo che un aggressore che accede al nodo sarà in grado di eseguire il proprio smart contract (fraudolento) sui dati decrittografati. Tuttavia, i valori restituiti saranno crittografati con la chiave privata, e l'unica opzione per accedere a tali dati è la fuga del testo crittografato durante il ritorno/uscita.
   La protezione contro questo attacco consiste nella verifica da parte dell'enclave della correttezza del codice presente all'indirizzo attuale. Ciò può essere ottenuto tramite uno schema di indirizzamento, dove l'indirizzo del contratto viene definito tramite l'hashing del codice del contratto.

2. Le modifiche al testo crittografato dello stato del contratto rivelano perdite.
   La natura dell'attacco: I proprietari dei nodi su cui vengono eseguiti i contratti intelligenti hanno accesso allo stato del contratto in forma criptata al di fuori dell'enclave. Un malintenzionato che ottiene il controllo di un nodo può confrontare lo stato del contratto prima e dopo l'esecuzione della transazione e può determinare quali argomenti sono stati forniti e quale metodo del contratto intelligente è stato utilizzato, poiché il codice stesso del contratto intelligente e le sue specifiche tecniche sono di pubblico dominio.
   Protezione nella garanzia dell'affidabilità del nodo stesso.

3. Attacchi side-channel.
   Un tipo speciale 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 dell'attacco:

   • t0: Il malintenzionato riempie tutta la cache dei dati del processo vittima.
   • t1: La vittima esegue codice con accessi alla memoria che dipendono da dati riservati della vittima (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 memorizzati in X vengono caricati nella cache, espellendo i dati che erano lì prima.
   • t2: Il malintenzionato verifica quali delle sue righe di cache sono state espulse — le righe utilizzate dalla vittima. Questo si realizza misurando il tempo di accesso. Ripetendo questa operazione per ciascun keybit, il malintenzionato ottiene l'intera chiave.

Protezione contro l'attacco: In Intel SGX esiste una protezione dagli attacchi side-channel, che vieta il monitoraggio degli eventi legati alla cache, ma l'attacco Prime and Probe passerà comunque, poiché il malintenzionato 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 laterale. È prevista una protezione contro la vulnerabilità Spectre-v2, efficace contro questi due attacchi.

In relazione a DECO, il handshake a tre vie fornisce una garanzia di sicurezza:

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

In DECO possono verificarsi solo vulnerabilità legate all'iniezione di traffico. Inizialmente, durante il handshake a tre vie, il verifier può stabilire l'identità del server utilizzando un fresh nonce. Tuttavia, dopo l'handshake, il verifier deve fare affidamento su indicatori di rete (Indirizzi IP). Pertanto, la connessione tra il verifier e il server deve essere protetta da attacchi di iniezione di traffico. Ciò viene raggiunto utilizzando un Proxy.

Confronto degli oracle

Town Crier si basa sul lavoro con un enclave sul lato server, mentre DECO consente di autenticare l'origine dei dati mediante un handshake a tre vie e la crittografia dei dati con chiavi crittografiche. Il confronto dei dati degli oracle è stato effettuato secondo i seguenti criteri: prestazioni, sicurezza, costo e praticità.

Town Crier
DECO

prestazioni
Più veloce (0.6s per terminare)
Più lento (10.50s per completare il protocollo)

sicurezza
Meno sicuro
Più sicuro

costo
Più costoso
Meno costoso

praticità
Richiede hardware speciale
Funziona con qualsiasi server che supporta TLS

Velocità: Per lavorare con DECO è necessaria la configurazione del handshake a tre vie; la configurazione tramite LAN richiede 0.37 secondi, mentre per l'interazione dopo l'instaurazione della connessione, 2PC-HMAC è efficace (0.13 s per scrivere). Le prestazioni di DECO dipendono dai set di cifratura TLS disponibili, dalle dimensioni dei dati personali e dalla complessità delle prove per una specifica applicazione. Ad esempio, per l'applicazione delle 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 simile, cioè circa 20 volte più veloce di DECO. A parità di condizioni, TC sarà più veloce.

Sicurezza: Gli attacchi sull'enclave Intel SGX (attacchi side-channel) funzionano e possono causare danni reali ai partecipanti al contratto intelligente. Relativamente a DECO, possono verificarsi attacchi legati all'iniezione di traffico, ma l'uso di proxy mitiga tali attacchi. Pertanto, DECO è più sicuro.

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

Praticità: Per lavorare con Town Crier è necessario un equipaggiamento speciale che supporti TEE. Ad esempio, Intel SGX è supportato sui processori della famiglia Intel Core di sesta generazione e versioni successive. DECO, invece, può funzionare con qualsiasi equipaggiamento, anche se ci sono impostazioni di DECO che utilizzano TEE. Il processo di configurazione del handshake a tre vie di DECO può richiedere del tempo, ma non si può paragonare alla limitazione hardware di TC, quindi DECO è più pratico.

Conclusione

Analizzando i due oracoli singolarmente e confrontandoli su quattro criteri, si osserva che Town Crier è inferiore a DECO su tre dei quattro punti. DECO è più affidabile in termini di sicurezza delle informazioni, più conveniente e più pratico, sebbene la configurazione del protocollo a tre vie possa richiedere tempo e presentare alcuni svantaggi, come operazioni aggiuntive con le chiavi di crittografia. TC è più veloce di DECO, ma la vulnerabilità legata agli attacchi di tipo side-channel lo espone al rischio di perdita di riservatezza. È importante notare che DECO è stato introdotto a gennaio 2020 e non è ancora trascorso un tempo sufficiente per considerarne la sicurezza. Town Crier è stato attaccato per 4 anni e ha subito numerosi controlli, quindi il suo utilizzo in molti progetti è giustificato.

Fonte: habr.com