Analisi tecnica del perché Phala non è impattata dalle vulnerabilità su SGX dei chip Intel

Published in

Phala Italia

9 min readDec 2, 2022

Autore: Dr. Shunfan(Shelven) Zhou, principale ricercatore di Phala Network, uno degli autori del whitepaper Phala, si occupa di ricerca sulla sicurezza da 7 anni. È l’autore principale di An Ever-evolving Game: Evaluation of Real-world Attacks and Defenses in Ethereum Ecosystem, USENIX Security Symposium 2020 e di altri articoli sull’analisi dei programmi.

Astratto

Il 30 novembre, l’esperto di sicurezza Andrew Miller ha sottolineato che le vulnerabilità di Intel SGX comporteranno grandi rischi per la sicurezza di progetti come Secret Network, suscitando ampie discussioni nella comunità. Intel SGX, in quanto implementazione più diffusa di TEE, è utilizzato anche dai lavoratori off-chain di Phala. Pur con un diverso design del sistema che riduce la superficie di attacco e ne attenua le conseguenze, il nostro team di sviluppo ritiene controllabile l’impatto di tali vulnerabilità su Phala.

Questo articolo spiegherà ai lettori:

Perché le vulnerabilità ÆPIC Leak e MMIO possono causare una vulnerabilità della Secret Network
Le motivazioni per cui Phala utilizza Secure Enclave (TEE)
Come si garantisce che Phala non venga compromessa da tali vulnerabilità SGX
Futuri meccanismi di sicurezza

Sintesi della vulnerabilità di Secret Network

1. Come nasce la vulnerabilità?

L’hardware con vulnerabilità non patchate (vulnerabilità ÆPIC Leak e MMIO annunciate da Intel il 9 agosto 2022) consente di unirsi a Secret Network diventando suoi nodi. Il team di Secret blocca la registrazione dopo che il white hat ha segnalato il problema;
La stessa chiave principale di decrittazione di Secret Network è condivisa tra tutti i nodi.

Combinando questi due elementi, la segretezza della rete dipende totalmente dai nodi meno sicuri della rete. Una volta che uno di essi viene compromesso, la chiave segreta viene trafugata così come la privacy dell’utente.

2. Cosa ottengono gli attaccanti?

Come cito da https://sgx.fail: “Queste vulnerabilità potrebbero essere utilizzate per estrarre il consensus seed, una chiave principale di decrittazione per le transazioni private su Secret Network. L’esposizione del consensus seed consentirebbe la completa divulgazione retroattiva di tutte le transazioni private di Secret-4 dall’inizio della catena”.

3. Phala Network è colpito dalle stesse vulnerabilità?

No. Phala adotta un controllo degli accessi sulla registrazione dei nodi (chiamati “worker” in Phala) e sulla gestione della gerarchia delle chiavi, che spiegherò più avanti.

Risorse:

Design di Phala Trustless Cloud

Perché Phala ha bisogno del Secure Enclave (TEE)

Phala è un cloud di calcolo permission-less che consente a qualsiasi computer di unirsi come worker, quindi il nostro threat model è che qualsiasi worker non è attendibile di default, ma potrebbero tentare di:

dare un’occhiata ai dati degli utenti;
fornire risultati di esecuzione errati o non eseguire nessun calcolo;
fornire servizi di bassa qualità, come la riduzione delle prestazioni della CPU o il blocco dell’accesso alla rete.

Tra questi, il Quality-of-Service (il terzo problema) è incentivato dal nostro Supply-end Tokenomic. Inoltre, ci affidiamo alle caratteristiche di Secure Enclave (alias Trusted Execution Environment, come Intel SGX) e al nostro meccanismo di gestione delle chiavi per garantire l’affidabilità dell’intero sistema.

Il Secure Enclave mette a disposizione importanti promesse di sicurezza basate sull’hardware, compreso:

Confidentiality: tutti i valori di memoria sono criptati;
Execution integrity: nessuno può corrompere la correttezza dell’esecuzione anche se controlla il sistema operativo e il computer fisico;
Remote Attestation: gli utenti possono verificare da remoto l’hardware e il software in esecuzione all’interno della Secure Enclave.

Puoi leggere questo articolo per imparare maggiori dettagli su SGX.

Queste caratteristiche servono come base di fiducia per “prendere in prestito” potenza computazionale dalle persone. Vale la pena notare che, in quanto cloud di calcolo, i valori fondamentali di Phala sono la corretta esecuzione dei programmi degli utenti e la privacy dei dati degli utenti. Questo è diverso da altri progetti che si concentrano esclusivamente sulla riservatezza.

Phala può utilizzare la Zero-Knowledge Proof, il Multi-Party Computation, o la Fully Homomorphic Encryption come i suoi workers?

La risposta è no, sì, e sì poiché queste soluzioni funzionano in modi diversi.

Nel caso di ZKP, l’utente fa la propria esecuzione e fornisce solo la proof of chain per dimostrare che l’ha realmente eseguita. Questo non è il caso del cloud computing, in cui l’utente delega il calcolo ad altri;
MPC divide un lavoro in diverse parti, quindi uno qualsiasi degli esecutori non può conoscere l’input originale o l’output finale;
FHE consente agli esecutori di eseguire direttamente il calcolo sul testo cifrato, quindi non possono conoscere i dati degli utenti.

Sfortunatamente, le attuali soluzioni MPC e FHE hanno tutte limitazioni sulla capacità di calcolo e sulle prestazioni, quindi le soluzioni basate su hardware rimangono la scelte più pratiche. Stiamo esplorando la possibilità di supportare soluzioni TEE di altri produttori come AMD e ARM. Grazie alla corretta astrazione delle interfacce, Phala potrà utilizzare worker basati su MPC e FHE quando saranno pronti.

Access Control sulla registrazione dei Worker

Per entrare a far parte di Phala i worker necessitano di due prerequisiti:

Hardware con supporto Secure Enclave. Per ora supportiamo solo Intel SGX, ma le analisi effettuate su AMD-SEV dimostrano che è compatibile anche con il sistema attuale;
Esecuzione di programmi non modificati rilasciati da Phala, compresi il nodo Phala e l’off-chain pRuntime (abbreviazione di Phala Runtime).

Phala segue il principio “Don’t Trust, Verify” e applica il processo di Remote Attestation durante la registrazione dei worker. In altre parole, al pRuntime viene richiesto di generare delle RA Quotes che sono fornite direttamente dall’hardware fidato e certificate dal produttore stesso (in questo caso, Intel). Questo rapporto contiene informazioni importanti sull’hardware e sul software:

Informazioni Hardware
Se pRuntime è in esecuzione all’interno di SGX;
Le vulnerabilità note in base alla versione attuale dell’hardware e del firmware. In base a ciò, la blockchain Phala rifiuterà l’hardware con le vulnerabilità inserite nella blacklist e assegnerà a ciascun lavoratore un Confidence Level.
Informazioni Software
L’hash del binario del programma, che aiuta a garantire che pRuntime non sia stato modificato;
La disposizione iniziale della memoria del programma, in modo da determinare il suo stato iniziale.

Con tutte le informazioni possiamo verificare che sia l’hardware che il programma in esecuzione siano fidati, inoltre le RA Quotes e il Confidence Level ci permettono di misurare il livello di sicurezza dei worker e di personalizzare la nostra politica di sicurezza su quale hardware è autorizzato a entrare nella rete.

Inoltre, abbiamo il nostro Supply-end Tokenomic per incentivare un servizio di alta qualità da parte dei worker. Tutto ciò non rientra nello scopo di questo articolo, quindi consultatelo se siete interessati.

Gestione della gerarchia delle chiavi

La prima gerarchia di chiavi al mondo per il sistema ibrido blockchain-TEE è stata proposta nel 2019 nel Ekiden paper e funge da base per il progetto Oasis. Come cloud di calcolo, Phala migliora questo progetto renderndelo applicabile a una rete di ~100k nodi. Inoltre, introduciamo un nuovo meccanismo come la rotazione delle chiavi per migliorare ulteriormente la robustezza del cloud.

Prima di addentrarci nei dettagli della gestione delle chiavi del nostro contratto è importante sapere che ogni entità del sistema ha la propria chiave di identità, cioè ogni utente ha il proprio account, e ogni worker e gatekeeper (che viene eletto dai worker) ha la propria coppia di WorkerKey sr25519. La coppia di WorkerKey viene generata all’interno di pRuntime (quindi in SGX) e la chiave privata non lascia mai SGX. La chiave di identità è utilizzata per:

Identificare il messaggio di un’entità con la firma;
Stabilire un canale di comunicazione cifrato tra utenti, worker e gatekeeper con chiave ECDH. Di default in Phala qualsiasi comunicazione tra le entità è cifrata.

La MasterKey è la radice di fiducia dell’intera rete. Tutte le chiavi relative ai contratti, comprese le ClusterKey e le ContractKey, derivano da essa. La MasterKey è generata e condivisa da tutti i gatekeeper (attraverso il canale di comunicazione cifrato di cui sopra). La sicurezza della MasterKey dipende totalmente dalla sicurezza dei gatekeeper, per questo sono distinti tra tutti i worker:

I gatekeeper sono i worker con il massimo livello di fiducia: sono immuni a tutte le vulnerabilità SGX conosciute;
A differenza dei normali worker, gli endpoint dei gatekeeper non sono pubblici e non è possibile distribuire contratti ad essi. Questo riduce l’accesso remoto ai gatekeeper;
Per i gatekeeper è necessario uno staking supplementare per scoraggiare comportamenti scorretti da parte dei loro operatori.

In Phala i worker sono raggruppati in cluster per fornire servizi senza server. Una ClusterKey unica viene generata per ogni cluster usando la MasterKey (attraverso la derivazione della chiave), ma non è possibile invertire questo processo per dedurre la MasterKey dalla ClusterKey. La ClusterKey è condivisa con tutti i worker del cluster.

Infine, quando un contratto viene distribuito a un cluster, viene distribuito a tutti i worker di quel cluster. Questi worker seguiranno il processo deterministico e deriveranno la ClusterKey per ottenere la stessa ContractKey. Le ContractKey sono diverse per i vari contratti.

Cosa succede se alcune chiavi sono trafugate?

Se una WorkerKey è trafugata, gli attaccanti possono decifrare tutti i messaggi inviati con essa, come la ClusterKey del suo cluster e quindi le ContractKey di quel cluster, o addirittura impersonarla per fornire risultati falsi agli utenti. Questi comportamenti scorretti possono essere rilevati confrontando i risultati di più worker e quindi la chain può fare slash del cluster confiscando il suo staking;
Se una ContractKey è trafugata, gli attaccanti possono decifrare gli stati e tutti gli input storici di quel contratto;
Se viene trafugata una ClusterKey, gli attaccanti possono conoscere le informazioni di cui sopra di tutti i contratti di quel cluster;
Se è la MasterKey ad essere trafugata, tutti i dati storici lo sono a loro volta.

Cosa possiamo fare nel caso si verificasse il peggiore dei casi?

Phala ha implementato la rotazione delle chiavi nei gatekeeper, il che significa che, con l’autorizzazione del Consiglio, i gatekeeper possono aggiornare la MasterKey e conseguentemente le ClusterKey e le ContractKey.
Quindi nel caso peggiore saranno prima registrati i nuovi gatekeeper con l’hardware più recente, quelli più vecchi saranno cancellati (poiché è molto probabile che siano vulnerabili) e si passerà alla nuova MasterKey.

Meccanismi di sicurezza futuri

Utilizzo della computazione Multi-Party per gestire la MasterKey

Ora la stessa MasterKey è condivisa tra tutti i gatekeeper, per cui viene persa se uno qualsiasi di essi viene compromesso. Trasformando questo sistema in MPC, gli attaccanti dovranno compromettere la maggior parte dei gatekeeper.

2. Attivazione dell’aggiornamento delle RA Quotes

Poiché il Phat Contract non è ancora supportato nella mainnet, i worker devono inviare le RA Quotes solo una volta durante la loro registrazione. Quando il Phat Contract verrà rilasciato abiliteremo l’aggiornamento regolare delle RA Quotes, in modo che i worker vulnerabili vengano tagliati se non applicheranno le patch quando ci saranno segnalazioni di nuove vulnerabilità.

Infine, vorrei ringraziare Andrew Miller e il team di ricerca per il loro contributo al settore della sicurezza. Come ha detto Andrew, l’obiettivo del suo team è contribuire a migliorare la sicurezza riducendo il verificarsi di incidenti. Sono impaziente di avere discussioni future più approfondite con i ricercatori sulla sicurezza per consolidare l’infrastruttura trustless per il mondo Web3.

A proposito di Phala

Phala Network si prefigge di risolvere il problema della fiducia nel cloud computazionale.

Organizzando una rete mondiale decentralizzata di nodi per il calcolo, offre servizi performanti senza appoggiarsi su nessun grande cloud provider. I worker Phala fanno girare i programmi in un Secure Enclaves, una tecnologia votata alla privacy presente in alcuni moderni processori, rendendo possibile l’esecuzione confidenziale e versatile di codice. Insieme, questo crea l’infrastruttura per un cloud computing potente, sicuro e scalabile, senza riporre la propria fiducia in soggetti terzi.

🍽 — Subscribe | Website | Twitter | Github