Potresti pensare che la blockchain abbia poco a che fare con l’hardware. Dopotutto, da Bitcoin a Etherum, le blockchain sono tutte costruite essenzialmente su base software. La soluzione basata su hardware è generalmente più centralizzata, tuttavia, nel mondo della blockchain che preserva la privacy, combinando attentamente software e hardware, potremmo progettare soluzioni che offrono il miglior equilibrio tra scalabilità e riservatezza, pur mantenendole trustless.
La riservatezza nelle blockchain basate su TEE
Phala Network implementa smart contract riservati. Si differenzia dai contratti tradizionali perché gli smart contract vengono eseguiti all’interno di una speciale chiave hardware nella CPU, ovvero la Trusted Execution Environment. Il programma in esecuzione all’interno di TEE è altamente isolato dal resto del mondo. Un attacco dannoso non può né leggere i dati nella memoria senza autorizzazione né manipolare il programma per produrre comportamenti involontari.
In Phala Network, chiamiamo il programma di supporto in esecuzione all’interno di TEE “pRuntime”. pRuntime è l’ambiente di runtime che mantiene il miner TEE di base e il protocollo Gatekeeper all’interno del TEE. Gestisce l’attestazione remota TEE, la registrazione on-chain, la gestione delle chiavi e l’esecuzione di contratti riservati.
Ma come convincere un utente che lo smart contract è in esecuzione all’interno di pRuntime, non in un emulatore che non fornisce alcuna sicurezza dei dati? Ecco il concetto centrale: Attestazione remota.
L’attestazione remota
“Un’applicazione che ospita un’enclave può anche chiedere all’enclave di produrre un report e quindi passare questo report a un servizio della piattaforma per produrre un tipo di credenziale che rifletta l’enclave e lo stato della piattaforma. Questa credenziale è nota come citazione. Questa citazione può quindi essere trasmessa a entità fuori dalla piattaforma e verificata … “
L’attestazione remota è la chiave per garantire la sicurezza di un sistema TEE . Citato da Intel, dimostra che un certo codice (misurato dall’hash del codice), opzionalmente con alcuni dati personalizzati generati dal codice, è in esecuzione all’interno di un’enclave Intel SGX originale aggiornata.
Il Secret Provisioning
L’attestazione remota è un elemento fondamentale per i contratti intelligenti riservati, m a non è molto utile se non siamo in grado di stabilire un canale di comunicazione sicuro end-to-end con una parte di TEE. Intel SGX fornisce un protocollo di provisioning segreto per risolvere il problema in modo elegante.
Adottando il protocollo Secret Provisioning, è possibile stabilire una catena di fiducia dall’utente a pRuntime:
- La blockchain ha l’hash del codice canonico pRuntime
- pRuntime esegue il protocollo di attestazione remota, ottiene un report con i dati: hash del codice attestato (pRuntime stesso); e la chiave pubblica di una coppia di chiavi di identità effimera
- Il report RA viene inviato alla blockchain e convalidato on-chain
- La blockchain confronta l’hash dal report RA (implica: il partecipante è un pRuntime canonico in TEE)
- La chiave pubblica di identità è registrata sulla blockchain (implica: solo il pRuntime corrente ha il controllo su questa chiave di identità)
Di conseguenza, finché un messaggio è firmato dalla chiave di identità, deve essere prodotto sempre dal pRuntime registrato. Gli utenti possono inoltre stabilire una connessione simile a TLS ad un pRuntime con la sua chiave pubblica registrata.
Per comunicare con TEE, l’utente può ottenere la chiave pubblica di un determinato pRuntime dalla blockchain (dalla registrazione TEE). Quindi l’utente può utilizzare la chiave pubblica del proprio account substrate per eseguire un protocollo Diffie-Hellman. Da questa azione deriva una chiave segreta per la comunicazione tra l’utente e il pRuntime.
Poiché la catena di fiducia viene stabilita, implica anche che la chiave di identità sia sufficiente per rappresentare in modo univoco l’identità del pRuntime. Quindi una singola Attestazione Remota può proteggere tutte le future comunicazioni con il pRuntime, sempre sotto l’ipotesi che non vi sia nessuna violazione dell’hardware utilizzato per il TEE (che sarà discussa più avanti).
How comportarsi con gli aggiornamenti?
L’aggiornamento della blockchain è un requisito fondamentale in quanto riduce notevolmente i rischi per la sicurezza esposti da un aggiornamento hard-fork. Substrate supporta in modo nativo l’aggiornamento a runtime della blockchain ed è realizzato dal pallet di governance on-chain. Per quanto riguarda TEE, anche il runtime è aggiornabile.
Quando si aggiorna pRuntime, occorre inviare l’hash della nuova versione di pRuntime alla blockchain. Quindi la comunità può rivedere il codice, discutere e votare per l’aggiornamento tramite un processo di governance on-chain simile a Substrate.
Sia i gatekeeper che i miners devono aggiornare pRuntime una volta che una nuova versione è stata accettata sulla catena. Per i miner è più facile perché possono semplicemente interrompere il mining, eseguire l’aggiornamento e riprendere il mining. Questo è possibile perché i miner non devono essere sempre online. I gatekeeper invece hanno requisiti di alta disponibilità. Quindi eseguono un altro client TEE con la versione più recente e attendono un cambio naturale di Gatekeepers nella prossima ERA, oppure eseguono un dump di crittografia di emergenza degli stati e lo ripristinano nel nuovo pRuntime.
Sebbene ci siano rischi nello scaricare e dumpare lo stato, è comunque utile in caso di emergenza. SGX fornisce una funzione “sigillo per enclave”, che può produrre un codice che può essere decrittografato solo dalla stessa enclave.
Per mitigare i rischi per gli exploit di sicurezza hardware, le chiavi nei Gatekeepers sono distribuite da uno schema di condivisione segreta Shamir, il che significa che anche il sigillo è “rotto”, l’host non può ancora ottenere le chiavi originali senza una massiccia collusione.
Attacco e difesa
Il nostro modello di gestione delle minacce presume in parte che ci si possa fidare del produttore di TEE. Questo è ragionevole in quanto in primo luogo, non sanno come verrà utilizzato il loro hardware e quindi possono solo pianificare l’attacco in anticipo, riducendo i rischi.
In secondo luogo, se colpite da attacchi zero-day, le altre applicazioni in esecuzione su questa CPU sono generalmente a rischio.
Nonostante i presupposti di cui sopra, vediamo che exploit hardware effettivi sono accaduti in passato. Fortunatamente, la vulnerabilità può essere generalmente mitigata in diversi modi.
È comune pensare che le vulnerabilità software siano patchabili mentre le vulnerabilità dell’hardware no. Non è sempre così. La CPU può essere patchata con aggiornamenti del microcodice e con la particolarità del design dell’architettura Intel SGX, la maggior parte delle vulnerabilità può essere risolta.
Recentemente ad esempio, c’è stato un attacco chiamato SGAxe, è stato risolto da un aggiornamento del microcodice seguito da una rotazione della chiave di gruppo. Dopo la rotazione e la revoca della chiave, tutti i dispositivi non aggiornati vengono rifiutati dall’attestazione remota.
Ma cosa succede se qualcuno trova ancora vulnerabile l’hardware zero-day?
Supponiamo che la vulnerabilità richieda l’accesso fisico per sfruttarla, in questo caso i minatori saranno in grado di rubare dati dal contratto riservato. In questo caso, è possibile applicare la casualità per mitigare questo rischio.
La blockchain ad esempio può assegnare in modo casuale alcuni minatori ai contratti riservati in un determinato periodo. I minatori si mescolano in ogni periodo del genere. Finché il malintenzionato non ha il controllo su un gran numero di minatori, il costo per eseguire un tale attacco sarà notevolmente alto perché richiede un controllo massiccio in un tempo relativamente lungo.
Nel peggiore dei casi in cui l’enclave è completamente violata, esponendo i dati riservati a disposizione dell’aggressore e consentendo a quest’ultimo di manipolarne arbitrariamente l’esecuzione, non vogliamo comunque rinunciare alla correttezza del contratto riservato. Pertanto, abbiamo definito che i contratti riservati possono richiedere una o più repliche.
Il numero di replica non influisce sulla modalità di esecuzione del contratto perché tutti gli input provengono dalla blockchain e quindi sono per natura deterministici. Tuttavia, se esiste più di una replica, più TEE proveranno a riportare gli stati sulla blockchain. In questo caso, ci sarà un semplice processo di votazione in chain. Abbiamo quindi bisogno di una maggioranza semplice per “finalizzare” gli stati.
Avendo il sistema di replications, non è riuscito a tornare al modello di sicurezza simile a quello di un validatore Polkadot. L’attaccante deve in ogni caso controllare un numero sufficiente di minatori per infrangere la correttezza, anche se il presupposto di sicurezza di SGX è infranto
Riepilogo conclusivo
In passato, le blockchain si sono basate principlamente sul software. La mancanza di riservatezza è diventata a lungo un limite per l’adozione di massa. Con l’aiuto dell’hardware e del protocollo progettato con cura, abbiamo dimostrato che è possibile creare una blockchain sicura, scalabile e che preserva la riservatezza.
Riepilogo su Phala
- In arrivo la campagna Testnet
- 6.28 AMA abbiamo fatto un AMA con un altro famoso progetto
- 7.5–7.6 Presente alla settimana blockchain di Hangzhou tenuta congiuntamente dal governo di Hangzhou e 8bit.
About Phala
La prima piattaforma di smart contract confidenziali basata su Substrate dove puoi sviluppare applicazioni orientate alla segretezza dei dati e alla loro privacy. Membro di Parity Builders Program. Vincitore del Web3 Foundation Grant.