Riepilogo Tecnico: Accordo di Gruppo Sicuro per Chiavi su Bus di Sistemi Ciber-Fisici

1. Definizione del Problema

I moderni Sistemi Ciber-Fisici (CPS), come i macchinari industriali, i treni e le reti automobilistiche, si affidano pesantemente ad architetture di bus broadcast (ad esempio, CAN, PROFIBUS, Industrial Ethernet) per interconnettere dispositivi embedded. Garantire l'integrità e l'autenticità dei messaggi su questi bus richiede tipicamente l'uso di Codici di Autenticazione del Messaggio (MAC) derivati da una chiave di gruppo condivisa. Tuttavia, stabilire questa chiave in modo sicuro presenta sfide significative:

• Default Insicuri: Le attuali implementazioni si affidano spesso a chiavi pre-condivise fisse e insicure o a concetti di "trust-on-first-use", che mancano di adattabilità dinamica.
• Problemi di Scalabilità: I protocolli pairwise convenzionali (ad esempio, gli handshake TLS) non scalano bene in contesti di gruppo, risultando in una complessità di stato e di messaggi esponenziale che confligge con la comunicazione orientata al broadcast.
• Vincoli dei CPS: I protocolli di Group Key Agreement (GKA) esistenti provenienti dal contesto IT o IoT non riescono ad affrontare i vincoli specifici dei bus CPS, tra cui:
  • Limitazioni di Risorse: I dispositivi hanno budget stretti per computazione, memoria e larghezza di banda (ad esempio, payload CAN limitati a 64 byte).
  • Vincoli di Comunicazione: I link sono spesso solo broadcast o half-duplex.
  • Appartenenza Dinamica: I dispositivi possono unirsi o lasciare il gruppo bruscamente (ad esempio, per riavvio elettrico, hot-swapping) senza preavviso, e le uscite non annunciate devono essere gestite senza interrompere il protocollo.
  • Cicli di Vita Lunghi: I sistemi richiedono agilità crittografica per adattarsi alle vulnerabilità future e alla Crittografia Post-Quantistica (PQC).
  • Modello Avversario: Un avversario Dolev–Yao forte, capace di leggere, modificare, riprodurre, iniettare, scartare e riordinare messaggi, inclusa la capacità di partizionare il bus.

Il problema centrale è la mancanza di un protocollo GKA completamente distribuito e autenticato che soddisfi questi specifici vincoli industriali fornendo al contempo forti garanzie di sicurezza come la Forward Secrecy (FS) e la Post-Compromise Security (PCS).

2. Metodologia

Gli autori impiegano un approccio sistematico per derivare i requisiti, analizzare le soluzioni esistenti e progettare un protocollo personalizzato.

Modello di Sistema e Derivazione dei Requisiti

Gli autori definiscono un modello di sistema bus generalizzato in cui più dispositivi comunicano su un canale broadcast. Assumono un modello di avversario Dolev–Yao e derivano 12 requisiti concreti (R01–R12) per un GKA sicuro sui bus CPS:

• Autenticità (R01): Solo i partecipanti autenticati possono inviare messaggi validi.
• Completamente Distribuito (R02) & Indipendenza (R03): Nessun leader centrale o servizio esterno; qualsiasi nodo può eseguire operazioni.
• Indipendente dal Bus (R04): Indipendente da specifiche caratteristiche di indirizzamento o ordinamento del bus.
• Dinamico (R05): Supporta l'ingresso e l'uscita dei membri durante l'esecuzione, incluse le rimozioni di nodi inattivi.
• Scalabile (R06): Efficiente per gruppi di oltre 100 dispositivi.
• Robustezza (R07): Resiliente contro attacchi Dolev–Yao.
• Garanzie di Sicurezza (R08–R10): Post-Compromise Security (PCS), Forward Secrecy (FS) e Agilità Crittografica.
• Vincoli di Risorse (R11): Overhead minimo in termini di computazione, memoria e larghezza di banda.
• Merge/Split (R12): Capacità di fondere e dividere sottogruppi (notato come obiettivo futuro).

Analisi del Protocollo

Gli autori sistematizzano i protocolli GKA esistenti (facendo riferimento alle tassonomie di Prandtl et al. e Xiong et al.) e li valutano rispetto ai requisiti derivati.

• Esclusioni: I protocolli centralizzati, decentralizzati, sbilanciati e basati su cluster sono esclusi a causa di conflitti con il requisito di "Completamente Distribuito". I protocolli che generano chiavi condivise asimmetriche sono esclusi a causa dei vincoli di risorse.
• Selezione: Tra i protocolli dinamici, TreeKEM (il protocollo principale di Messaging Layer Security, MLS) è identificato come la base più adatta grazie al suo overhead computazionale e di messaggi ottimale ($O(\log_2 n)$).
• Analisi del Gap: L'uso diretto di MLS è impossibile perché richiede servizi di Autenticazione e Delivery centralizzati, violando i requisiti di distribuzione e indipendenza dei bus CPS. Inoltre, la specifica standard di TreeKEM manca di garanzie di autenticità esplicite e di formati di messaggio dettagliati per ambienti broadcast.

3. Contributi Chiave: Il Protocollo GRACYBUS

Il documento presenta GRACYBUS (GRoup key Agreement on Cyber-phYsical system BUSes), un protocollo personalizzato progettato per adattare TreeKEM per i bus CPS.

Caratteristiche di Design

• Struttura ad Albero: Organizza i membri in un albero binario perfetto. Ogni foglia rappresenta un dispositivo. I segreti non foglia sono derivati tramite l'hashing dei segreti figli.
• Key Schedule: Utilizza uno schema di chiavi basato su epoch. La chiave del traffico di gruppo è derivata tramite una funzione di derivazione delle chiavi (KDF) dal segreto della root corrente e dalla chiave dell'epoch precedente. Le chiavi passate vengono eliminate per garantire la Forward Secrecy.
• Operazioni:
  • UPDATE: Un membro ruota il proprio segreto foglia, propaga i segreti hash lungo il percorso e trasmette le chiavi pubbliche aggiornate. I segreti del sottobbero sono criptati verso le chiavi pubbliche del co-path.
  • JOIN: Un handshake autenticato (utilizzando firme PKI) tra un nuovo membro e uno sponsor. Lo sponsor inserisce la foglia, calcola i segreti e distribuisce la nuova chiave dell'epoch.
  • LEAVE: Eseguito da un altro membro. Nuovi segreti vengono impostati sul percorso del membro uscente e criptati solo verso le chiavi che il membro uscente non può decriptare. Le uscite non annunciate vengono rilevate tramite una finestra di aggiornamento.
• Messaggistica: I messaggi sono strutturati per il broadcast. I segreti sono criptati con le chiavi pubbche del sottobbero (permettendo a più destinatari di decriptare un singolo broadcast), mentre le chiavi pubbliche sono condivise in chiaro (con protezione dell'integrità). Tutti i messaggi che cambiano lo stato sono protetti da MAC con la chiave dell'epoch corrente.
• Autenticità: Si affida a un'ancora di fiducia comune (PKI Industriale) per il bootstrapping iniziale. All'interno del gruppo, l'integrità è mantenuta tramite MAC derivati dalla chiave dell'epoch.

Dettagli di Implementazione

• Storage: Richiede $O(\log n)$ chiavi private e $O(n)$ chiavi pubbliche (per ridondanza per gestire le uscite non annunciate).
• Complessità: L'overhead computazionale e di messaggi scala logaritmicamente con la dimensione del gruppo ($O(\log_2 n)$).
• Agilità: Tutte le interfacce crittografiche (hash, KDF, MAC, firma, cifratura) sono agnostiche rispetto all'algoritmo, facilitando l'adozione futura della PQC.

4. Risultati e Valutazione

Il documento valuta GRACYBUS rispetto ai 12 requisiti derivati:

• Performance: Il protocollo raggiunge una complessità $O(\log_2 n)$ per le operazioni di gruppo, adattandosi ai vincoli di risorse di dispositivi come quelli sui bus CAN. I requisiti di storage per le chiavi private sono leggeri, con un compromesso di $O(n)$ per lo storage delle chiavi pubbliche per la robustezza.
• Garanzie di Sicurezza:
  • Autenticità e Integrità: Ottenute tramite firme PKI per i join e MAC per gli aggiornamenti del gruppo.
  • Forward Secrecy (FS) e Post-Compromise Security (PCS): Ottenute attraverso lo schema delle chiavi dell'epoch e la sovrascrittura delle chiavi del percorso. Se un nodo viene compromesso, il sistema si "ripristina" dopo un aggiornamento riuscito senza l'interferenza dell'avversario.
  • Agilità Crittografica: Il design consente la sostituzione delle primitive crittografiche per affrontare vulnerabilità future o minacce quantistiche.
• Limitazioni: Il protocollo non soddisfa completamente il requisito di robustezza contro un avversario Dolev–Yao che partiziona il bus. Se l'avversario scarta i messaggi per dividere la rete, diverse partizioni potrebbero derivare alberi di chiavi differenti, compromettendo la disponibilità complessiva. Tuttavia, gli autori notano che questa è un'implicazione intrinseca di qualsiasi protocollo di accordo di chiave sotto tale modello di avversario.

5. Significato e Rivendicazioni

Il documento sostiene che GRACYBUS dimostra la fattibilità della progettazione di meccanismi di stabilimento delle chiavi specificamente adattati per contesti di sistemi CPS orientati ai bus senza indebolire le garanzie di sicurezza.

• Colmare il Divario: Integra con successo i principi di sicurezza contemporanei (FS, PCS, prontezza PQC) in sistemi multi-party con risorse limitate, dove tali caratteristiche sono tradizionalmente difficili da realizzare.
• Approccio Centrato sul Bus: Rimuovendo la necessità di servizi centralizzati e adattando TreeKEM ai vincoli di broadcast/half-duplex, il protocollo offre una soluzione pratica per le implementazioni industriali con cicli di vita lunghi.
• Prontezza per il Futuro: Il protocollo fornisce una base per proteggere la comunicazione CPS tramite cifratura e protezione dell'integrità, allineandosi agli standard di sicurezza moderni pur rispettando i vincoli fisici e operativi dei bus di campo.

Gli autori concludono che, sebbene il protocollo sia robusto, sono necessari futuri lavori per affrontare le operazioni di merge/split del gruppo (R12), ottimizzare la troncatura dell'albero per evitare la complessità lineare nei casi peggiori e esplorare le operazioni parallelizzate per migliorarne l'efficienza.