Oggi, solo i pigri non hanno scritto sulla tecnologia blockchain, sulle criptovalute e su quanto sia interessante. Ma questo articolo non elogerà questa tecnologia, parleremo dei suoi difetti e dei modi per eliminarli.

Mentre lavoravo su uno dei progetti di Altirix Systems, si è posto il compito di confermare in modo sicuro e resistente alla censura i dati provenienti da una fonte esterna alla blockchain. Era necessario confermare le modifiche nei record del terzo sistema e, sulla base di queste modifiche, eseguire l'uno o l'altro ramo nella logica del contratto intelligente. A prima vista, il compito è piuttosto banale, ma quando la condizione finanziaria di una delle parti coinvolte nel processo dipende dal risultato della sua attuazione, compaiono requisiti aggiuntivi. Innanzitutto si tratta di una fiducia totale in tale meccanismo di convalida. Ma prima le cose principali.

Il problema è che la blockchain stessa è un’entità autonoma e chiusa, quindi i contratti intelligenti all’interno della blockchain non sanno nulla del mondo esterno. Allo stesso tempo, i termini dei contratti intelligenti sono spesso legati a informazioni su cose reali (ritardo del volo, tassi di cambio, ecc.). Affinché i contratti intelligenti funzionino correttamente, le informazioni ricevute dall’esterno della blockchain devono essere affidabili e verificate. Questo problema viene risolto utilizzando oracoli come Town Crier e DECO. Questi oracoli consentono ad uno smart contract sulla rete blockchain di fidarsi delle informazioni provenienti da un server web fidato; possiamo dire che si tratta di fornitori di informazioni affidabili.

Oracoli

Immagina che un contratto intelligente trasferisca 0.001 btc sul tuo portafoglio bitcoin se la tua squadra di calcio preferita vince la Coppa di Russia. In caso di vera vittoria, il contratto intelligente deve trasferire informazioni su quale club ha vinto, e qui sorgono una serie di problemi: dove trovare queste informazioni, come trasferirle in modo sicuro al contratto intelligente e come garantire che le informazioni ricevuto nello smart contract è valido e coincide effettivamente con la realtà?

Quando si tratta della fonte delle informazioni, ci possono essere 2 scenari: connettere uno smart contract a un sito web affidabile in cui le informazioni sui risultati delle partite sono archiviate centralmente e la seconda opzione è connettere più siti contemporaneamente e quindi selezionare le informazioni dalla maggior parte delle fonti che forniscono gli stessi dati. Per verificare la correttezza delle informazioni vengono utilizzati oracoli, ad esempio Oraclize, che utilizza TLSNotary (TLS Notary Modification to Prove the Authenticity of Data). Ma su Google ci sono abbastanza informazioni su Oraclize e ci sono diversi articoli su Habré. Oggi parlerò di oracoli che utilizzano un approccio leggermente diverso per trasmettere le informazioni: Town Crier e DECO. L'articolo fornisce una descrizione dei principi di funzionamento di entrambi gli oracoli, nonché un confronto dettagliato.

Banditore cittadino

Town Crier (TC) è stato introdotto da IC3 (The Initiative for CryptoCurrencies and Contracts) nel 2016 al CCS'16. L'idea principale di TC: trasferire le informazioni da un sito Web a uno smart contract e assicurarsi che le informazioni fornite da TC siano le stesse del sito Web. TC utilizza TEE (Trusted Execution Environment) per autenticare la proprietà dei dati. La versione originale di TC descrive come lavorare con Intel SGX.
Town Crier è costituito da una parte all'interno della blockchain e da una parte all'interno del sistema operativo stesso: TC Server.

TC Contract è sulla blockchain e funge da front-end per TC. Accetta richieste dal CU (contratto intelligente dell'utente) e restituisce una risposta dal TC Server. All'interno del TC Server è presente un Relay, che stabilisce una connessione tra l'enclave e Internet (traffico bidirezionale) e collega l'enclave con la blockchain. Enclave contiene progencl, che è un codice che effettua richieste dalla blockchain e restituisce messaggi alla blockchain con una firma digitale, progencl contiene parte del codice del contratto intelligente e svolge essenzialmente alcune delle sue funzioni.

L'enclave Intel SGX può essere pensata come una libreria condivisa con un'API in esecuzione tramite ecall. Ecall trasferisce il controllo all'enclave. L'enclave esegue il suo codice finché non esce o finché non si verifica un'eccezione. ocall viene utilizzato per chiamare funzioni definite all'esterno dell'enclave. Ocall viene eseguito all'esterno dell'enclave e viene trattato come una chiamata non attendibile. Dopo l'esecuzione di ocall, il controllo viene restituito all'enclave.

Nella parte Enclave viene configurato un canale sicuro con un server web, l'enclave stessa esegue un handshake TLS con il server di destinazione ed esegue internamente tutte le operazioni crittografiche. La libreria TLS (mbedTLS) e il codice HTTP ridotto sono stati esportati nell'ambiente SGX. Inoltre, Enclave contiene certificati CA radice (una raccolta di certificati) per verificare i certificati dei server remoti. Il gestore delle richieste accetta una richiesta di datagramma nel formato fornito da Ethereum, la decrittografa e la analizza. Quindi genera una transazione Ethereum contenente il datagramma richiesto, la firma con skTC e la trasmette a Relay.

La parte Relay include l'interfaccia client, TCP, l'interfaccia Blockchain. L'interfaccia client è necessaria per certificare il codice dell'enclave e comunicare con il client. Il client invia una richiesta di attestazione utilizzando ecall e riceve un timestamp firmato da skTC insieme ad att (firma di attestazione), quindi att viene verificato utilizzando Intel Attestation Service (IAS) e il timestamp viene verificato da un servizio temporale attendibile. Blockchain Interface verifica le richieste in entrata e inserisce le transazioni sulla blockchain per la consegna dei datagrammi. Geth è un client ufficiale di Ethereum e consente a Relay di interagire con la blockchain tramite chiamate RPC.

Lavorando con TEE, TC consente di eseguire più enclavi in ​​parallelo, aumentando così di 3 volte la velocità di elaborazione delle informazioni. Se con un'enclave in esecuzione la velocità era di 15 tx/sec, con 20 enclave in esecuzione parallela la velocità aumenta a 65 tx/sec; per fare un confronto, la velocità operativa massima nella blockchain di Bitcoin è 26 tx/sec.

DECORAZIONI

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

Il modo in cui funziona DECO è che il verificatore riceve un dato D e conferma al verificatore che D proviene dal server TLS S. Un altro problema è che TLS non firma i dati ed è difficile per il client TLS dimostrare che il i dati sono stati ricevuti esattamente dal server giusto (difficoltà di provenienza).

Il protocollo DECO utilizza le chiavi di crittografia KEnc e KMac. Il client invia una richiesta Q al server web, la risposta dal server R arriva in forma crittografata, ma il client e il server possiedono lo stesso KMac e il client può falsificare il messaggio TLS. La soluzione di DECO è "nascondere" KMac al client (prover) finché non risponde alla richiesta. Ora KMac è diviso tra dimostratore e verificatore: KpMac e KvMac. Il server riceve KMac per crittografare la risposta utilizzando l'operazione della parte chiave KpMac ⊕ KvMac = KMac.

Impostando un handshake a tre vie, lo scambio di dati tra client e server verrà effettuato con garanzia di sicurezza.

Quando si parla di sistema oracolo decentralizzato non si può non citare Chainlink, che mira a creare una rete decentralizzata di nodi oracolo compatibili con Ethereum, Bitcoin e Hyperledger, tenendo conto della modularità: ogni parte del sistema può essere aggiornata. Allo stesso tempo, per garantire la sicurezza, Chainlink offre a ciascun oracolo che partecipa all'attività di emettere una combinazione di chiavi (pubblica e privata). La chiave privata viene utilizzata per generare una firma parziale che contiene la decisione relativa alla richiesta di dati. Per ottenere una risposta è necessario combinare tutte le firme parziali degli oracoli della rete.

Chainlink prevede di condurre un PoC DECO iniziale concentrandosi su applicazioni finanziarie decentralizzate come Mixicles. Nel momento in cui scrivo, su Forbes è uscita la notizia che Chainlink ha acquisito DECO dalla Cornell University.

Attacchi agli oracoli

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

1. Iniezione di codice smart-contact non autorizzato sui nodi TEE.
   L'essenza dell'attacco: trasmettere un codice di contratto intelligente deliberatamente errato a TEE, quindi un utente malintenzionato che ha ottenuto l'accesso al nodo sarà in grado di eseguire il proprio contratto intelligente (fraudolento) sui dati decrittografati. Tuttavia, i valori restituiti verranno crittografati con una chiave privata e l'unico modo per accedere a tali dati è far trapelare il testo cifrato al momento del ritorno/output.
   La protezione contro questo attacco consiste nel controllo da parte dell'enclave della correttezza del codice situato all'indirizzo attuale. Ciò può essere ottenuto utilizzando uno schema di indirizzamento in cui l'indirizzo del contratto viene determinato eseguendo l'hashing del codice contratto.

2. Perdita di modifiche al testo cifrato dello stato del contratto.
   L'essenza dell'attacco: i proprietari dei nodi su cui vengono eseguiti i contratti intelligenti hanno accesso allo stato del contratto in forma crittografata al di fuori dell'enclave. Un utente malintenzionato, dopo aver acquisito il controllo di un nodo, può confrontare lo stato del contatto prima e dopo la transazione e può determinare quali argomenti sono stati inseriti e quale metodo di contratto intelligente è stato utilizzato, poiché il codice del contratto intelligente stesso e le sue specifiche tecniche sono disponibili pubblicamente.
   Protezione nel garantire l'affidabilità del nodo stesso.

3. Attacchi dal canale laterale.
   Un tipo speciale di attacco che utilizza il monitoraggio della memoria dell'enclave e l'accesso alla cache in vari scenari. Un esempio di tale attacco è Prime e Probe.
   
   Ordine di attacco:

   • t0: l'aggressore riempie l'intera cache di dati del processo vittima.
   • t1: La vittima esegue codice con accessi alla memoria che dipendono dai dati sensibili della vittima (chiavi crittografiche). La riga della cache viene selezionata in base al valore keybit. Nell'esempio in figura viene letto keybit = 0 e viene letto l'indirizzo X nella riga 2 della cache. I dati memorizzati in X vengono caricati nella cache, sostituendo i dati che c'erano prima.
   • t2: L'attaccante controlla quali delle sue linee cache sono state sfrattate (linee utilizzate dalla vittima). Questo viene fatto misurando il tempo di accesso. Ripetendo questa operazione per ogni keybit, l'attaccante ottiene l'intera chiave.

Protezione dagli attacchi: Intel SGX dispone di una protezione contro gli attacchi del canale laterale che impedisce il monitoraggio degli eventi relativi alla cache, ma un attacco Prime e Probe funzionerà comunque perché l'aggressore monitora gli eventi della cache del suo processo e condivide la cache con la vittima.

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

Sono noti anche attacchi come Spectre e Foreshadow (L1TF), simili a Prime e Probe. Consentono di leggere i dati dalla memoria cache attraverso un canale di terze parti. Viene fornita protezione contro la vulnerabilità Spectre-v2, che funziona contro due di questi attacchi.

In relazione alla DECO, l’handshake a tre costituisce una garanzia di sicurezza:

1. Integrità del prover: un prover compromesso non può falsificare le informazioni sull'origine del server e non può far sì che il server accetti richieste non valide o risponda in modo errato a richieste valide. Questo viene fatto attraverso modelli di richiesta tra server e prover.
2. Integrità del verificatore: un verificatore violato non può far sì che il dimostratore riceva risposte errate.
3. Privacy: il verificatore compromesso esamina solo le informazioni pubbliche (richiesta, nome del server).

In DECO sono possibili solo vulnerabilità legate all'iniezione di traffico. Innanzitutto, con un handshake a tre vie, il verificatore può stabilire l'identità del server utilizzando un nuovo nonce. Tuttavia, dopo l'handshake, il verificatore deve fare affidamento sugli indicatori del livello di rete (indirizzi IP). Pertanto, la comunicazione tra il verificatore e il server deve essere protetta dall'iniezione di traffico. Ciò si ottiene utilizzando Proxy.

Confronto di oracoli

Town Crier si basa sul lavoro con un'enclave nella parte server, mentre DECO consente di verificare l'autenticità dell'origine dei dati utilizzando un handshake a tre vie e la crittografia dei dati con chiavi crittografiche. Il confronto di questi oracoli è stato effettuato secondo i seguenti criteri: prestazioni, sicurezza, costo e praticità.

Banditore cittadino
DECORAZIONI

prestazione
Più veloce (0.6 secondi per finire)
Più lento (10.50 secondi per completare il protocollo)

sicurezza
Meno sicuro
Più sicuro

costo
Più costoso
Più economico

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

Prestazioni di velocità: Per funzionare con DECO è necessario un handshake a tre vie, durante la configurazione tramite LAN sono necessari 0.37 secondi, per l'interazione dopo aver stabilito la connessione è efficace 2PC-HMAC (0,13 s per scrittura). Le prestazioni di DECO dipendono dalle suite di crittografia TLS disponibili, dalla dimensione dei dati privati ​​e dalla complessità delle prove per una particolare applicazione. Prendiamo ad esempio l'applicazione per le opzioni binarie di IC3: la conclusione del protocollo tramite LAN dura circa 10,50 secondi. In confronto, Town Crier impiega circa 0,6 secondi per completare un'applicazione simile, ovvero circa 20 volte più veloce di DECO. A parità di condizioni, TC sarà più veloce.

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

costo: Il costo delle apparecchiature che supportano Intel SGX è superiore al costo di impostazione del protocollo in DECO. Ecco perché TC è più costoso.

praticità: Per lavorare con Town Crier, è necessaria un'attrezzatura speciale che supporti TEE. Ad esempio, Intel SGX è supportato sulla famiglia di processori Intel Core di sesta generazione e versioni successive. DECO consente di lavorare con qualsiasi attrezzatura, sebbene sia presente un'impostazione DECO utilizzando TEE. Secondo il processo di installazione, l'handshake a tre vie di DECO potrebbe richiedere del tempo, ma questo non è nulla in confronto alla limitazione hardware di TC, quindi DECO è più pratico.

conclusione

Considerando i due oracoli separatamente e confrontandoli su quattro criteri, è chiaro che Town Crier è inferiore a DECO in tre punti su quattro. DECO è più affidabile dal punto di vista della sicurezza informatica, più economico e più pratico, anche se l'impostazione di un protocollo a tre può richiedere del tempo e presenta i suoi svantaggi, ad esempio operazioni aggiuntive con chiavi di crittografia. TC è più veloce di DECO, ma le vulnerabilità legate agli attacchi del canale laterale lo rendono suscettibile alla perdita di riservatezza. Bisogna tenere conto che la DECO è stata introdotta nel gennaio 2020 e non è trascorso abbastanza tempo per considerarla sicura. Town Crier è sotto attacco da 4 anni ed è stato sottoposto a numerosi test, quindi il suo utilizzo in molti progetti è giustificato.

Fonte: habr.com