Architettura di calcolo multipartitico

Anteprima

Questo prodotto è soggetto ai "Termini delle Offerte pre-GA" nella sezione Termini di servizio generali dei Termini specifici dei servizi. I prodotti pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

Google Cloud Il calcolo multipartitico fornisce un'infrastruttura di attendibilità crittografica per le operazioni sugli asset digitali istituzionali. Utilizza un'architettura multi-single-tenant: ogni istanza che crei è un ambiente dedicato e isolato con il proprio ingresso di rete, il proprio spazio di archiviazione e il proprio computing isolato dall'hardware per le operazioni di crittografia.

Componenti principali

Ogni istanza di computing multipartitico ha tre componenti principali. La logica di governance, il routing delle richieste e i calcoli crittografici vengono eseguiti in componenti separati.

API MPC

L'API Multi-party Compute gestisce le seguenti risorse:

• Utenti e team: le identità che detengono ruoli nell'istanza e i gruppi di firmatari a cui fanno riferimento le policy delle chiavi.
• KeyRing e KeyPolicy: i KeyRing che raggruppano le chiavi, ciascuno con la policy della chiave che decide quali team e utenti detengono le condivisioni delle chiavi e quanti di loro devono approvare una firma.
• TransactionPolicies: le regole Cedar che consentono o vietano le transazioni e le approvazioni del Policy Author che le attivano o le disattivano.
• KeyLists: gli elenchi di indirizzi denominati a cui possono fare riferimento le policy di transazione.

L'API Multi-party Compute monitora lo stato di ogni transazione e le approvazioni registrate su di essa e chiede al coordinatore di orchestrare la generazione e la firma delle chiavi. Spanner archivia le richieste e le approvazioni firmate. I TEE worker verificano autonomamente le firme di approvazione prima di agire.

Coordinatore

L'API Multi-party Compute connette il controller ai TEE dei partecipanti:

• Rilevamento delle condivisioni di chiavi e routing delle richieste: assegna TEE integri per contenere nuove condivisioni di chiavi durante la generazione delle chiavi e successivamente indirizza la richiesta ai TEE appropriati.
• Integrità: monitora l'integrità dei TEE dei partecipanti e funge da bilanciatore del carico per le richieste firmate.
• Durabilità: gestisce la ricondivisione quando è necessario sostituire una condivisione di chiavi.

Il Coordinator non influisce sulla sicurezza del protocollo. Non contiene condivisioni di chiavi e non verifica le approvazioni o i risultati delle policy; questa verifica avviene all'interno dei TEE dei partecipanti.

TEE worker

Ogni worker è un TEE eseguito su Confidential Space. Un TEE worker esegue due parti:

• Motore di crittografia: contiene le condivisioni delle chiavi ed esegue i protocolli di generazione e firma delle chiavi di soglia sicure con gli altri TEE worker.
• Valutatore delle policy: valuta le transazioni in base all'insieme attivo di policy di transazione.

Flusso di firma delle transazioni

In Multi-party Compute, firmi un payload con una singola chiamata API, CreateTransaction. La valutazione della policy di transazione, le approvazioni dei firmatari e la firma della soglia iniziano tutte con questa chiamata. Ecco il flusso in un ordine fisso:

1. Richiesta. Un firmatario chiama CreateTransaction su una chiave. La richiesta contiene l'approvazione del firmatario, firmata con la sua chiave di autorizzazione. IAM verifica che il chiamante possa chiamare il metodo e la richiesta viene registrata in Cloud Audit Logs.
2. Valutazione delle policy. La transazione viene valutata in base all'insieme attivo di policy sulle transazioni. La valutazione delle policy genera un audit log permanente per ogni esito, APPROVED o REJECTED.
3. Approvazione dell'autore della richiesta. Se l'approvazione dell'iniziatore da sola soddisfa le soglie della policy della chiave, CreateTransaction passa immediatamente al passaggio 5.
4. Approvazioni dei firmatari. Se l'approvazione dell'iniziatore da sola non soddisfa le soglie della policy della chiave, la transazione entra nello stato PENDING_AUTHORIZATION. Gli altri firmatari che detengono quote della chiave approvano o negano la transazione utilizzando la chiamata RecordSignerDecision, ciascuna firmata con la propria chiave di autorizzazione. La transazione attende nello stato PENDING_AUTHORIZATION finché un numero sufficiente di firmatari non approva per soddisfare le soglie della policy della chiave. Se un numero sufficiente di firmatari rifiuta la transazione, in modo che le soglie non possano più essere soddisfatte, la transazione passa allo stato REJECTED. Se non riceve un numero sufficiente di approvazioni prima della scadenza, viene EXPIRED.

5. Firma con soglia. Quando le soglie vengono soddisfatte, i Trusted Execution Environment (TEE) che contengono le condivisioni della chiave eseguono il protocollo di firma della soglia e producono la firma sulla transazione.

   Prima che un TEE partecipante utilizzi la sua condivisione della chiave, verifica che il payload esatto che deve firmare sia stato valutato in base alle tue policy di transazione. Nessun client, operatore o altro componente del servizio può fare in modo che un partecipante firmi un payload che non è stato valutato.

Per le risorse coinvolte, come utenti, team, keyring e policy di transazione, consulta la panoramica del calcolo multipartitico.

Modello di sicurezza

• Le condivisioni delle chiavi sono fissate al TEE. Ogni condivisione di chiavi può essere letta solo dal TEE che l'ha creata. Le condivisioni delle chiavi non lasciano mai il TEE in un formato leggibile da un altro componente, inclusi il Coordinator, il Controller o un operatore Google.
• Custodia delle chiavi del cliente. Il cliente mantiene sempre la piena custodia delle proprie chiavi di crittografia utilizzando Cloud Key Management Service nell'organizzazione Google Cloud del cliente.
• Isolamento hardware. I TEE dei partecipanti vengono eseguiti su Confidential Space, che utilizza la crittografia della memoria hardware per proteggere i dati in uso dall'host e dall'infrastruttura di Google. L'attestazione associa ogni TEE a un'immagine container verificata.
• Crittografia end-to-end. I TEE worker comunicano direttamente tramite gRPC con crittografia end-to-end.
• Approvazioni firmate. I firmatari, gli autori delle policy e gli amministratori firmano le loro approvazioni con una chiave di autorizzazione la cui metà privata non viene mai condivisa. I TEE dei partecipanti verificano queste firme prima di firmare una transazione, accettare una policy di transazione o accettare una modifica del ruolo di amministratore o autore di policy. In questo modo, le transazioni sono a prova di manomissione e lasciano un audit log permanente.
• Quorum di autori delle policy. Una nuova policy di transazione o una richiesta di disattivazione di una policy diventa effettiva solo dopo che il numero richiesto di autori delle policy l'ha approvata.
• Quorum amministrativo. La concessione o la rimozione del ruolo Amministratore o Autore di policy diventa effettiva solo dopo l'approvazione da parte del numero richiesto di amministratori. Per saperne di più, consulta Approvazione da parte dell'amministratore delle modifiche ai ruoli.

Roadmap

Le seguenti funzionalità sono previste per una release futura:

• TEE esterni: condivisioni di chiavi conservate in TEE che i clienti eseguono al di fuori di Google Cloud, ad esempio AWS Nitro Enclaves.
• Condivisioni di chiavi mobile: condivisioni di chiavi conservate sui dispositivi mobili degli utenti.
• Ricondivisione: modifica di chi detiene le condivisioni di una chiave esistente o sostituzione di una condivisione persa, senza modificare la chiave.

Proprietà di sistema

L'infrastruttura di attendibilità del calcolo multipartitico mantiene le seguenti proprietà del sistema.

Sicurezza (solidità in un contesto crittografico)

In nessun caso il sistema deve comportarsi in modo non consentito. Ad esempio, nessun gruppo di meno di k partecipanti, in virtù del protocollo DKLS23, è in grado di falsificare le firme. Le definizioni esatte di sicurezza sono formalizzate nel framework Universal Composable della letteratura.

Quando un sistema crittografico viene incorporato in un'implementazione pratica, è necessario prestare attenzione per evitare di fare affidamento su presupposti che compromettono le proprietà di sicurezza. Ad esempio, ogni parte del protocollo deve essere indipendente: la sua suscettibilità alla compromissione deve essere indipendente.

Per garantire questa proprietà, il calcolo multipartitico esegue ogni partecipante in un TEE attestato e ogni condivisione di chiavi è associata al TEE che l'ha creata. La compromissione di un partecipante al protocollo non influisce sugli altri partecipanti.

La letteratura accademica sul calcolo multipartitico si concentra quasi esclusivamente sulla solidità e presuppone un mondo semplicistico in cui l'insieme delle parti è immutabile, tutte le parti sono sempre disponibili e comunicano utilizzando canali autenticati point-to-point ideali e sempre disponibili. Per un prodotto reale, è necessario affrontare diversi problemi aggiuntivi.

Liveness

Il sistema alla fine progredisce. La proprietà di liveness più comune è l'assenza di deadlock, che è valida nel protocollo DKLS23. Una chiave di soglia può essere utilizzata per la firma, a condizione che siano disponibili un numero sufficiente di TEE che ne detengono le condivisioni per soddisfare le soglie della policy della chiave. Ad esempio, con una chiave 2 su 3, 2 delle 3 condivisioni possono completare una firma.

Durabilità

Le parti che non funzionano in modo permanente devono essere sostituite, altrimenti il sistema finirà per perdere definitivamente il secret condiviso. Ad esempio, in caso di errore dell'hardware, lo stato del partecipante in esecuzione su quell'hardware viene perso. Poiché le condivisioni delle chiavi sono fissate ai relativi TEE, il Coordinator monitora quali TEE contengono le condivisioni di ciascuna chiave. In v1beta, una chiave rimane utilizzabile finché rimane un numero sufficiente di condivisioni per soddisfare le soglie della policy della chiave. La sostituzione di una condivisione persa richiede una nuova condivisione, prevista per una release futura.

Modifiche alla configurazione

Sia i guasti hardware (un TEE perde i dati) sia i cambiamenti organizzativi (un nuovo dipendente si unisce al protocollo con una condivisione della chiave segreta) richiedono la modifica di chi detiene le condivisioni di una chiave. Il calcolo multipartitico prevede di supportare questa funzionalità con un protocollo di ricondivisione sicuro che preservi le proprietà di solidità di DKLS23: una nuova parte dannosa che si impegna nella ricondivisione al massimo divulga una condivisione del segreto, come qualsiasi altra parte dannosa.