Hardware-Assisted Zero-Knowledge Authentication Scheme for Resource-Constrained IoT Terminals: USBKEY Implementation and Evaluation Based on GSVOLE-2DLC

Sintesi Tecnica: Autenticazione Zero-Knowledge Assistita da Hardware per l'IoT con Risorse Limitate

Definizione del Problema
La diffusione di terminali Internet of Things (IoT) con risorse limitate in ambienti di controllo industriale, sensoristica e edge computing rende necessari meccanismi di autenticazione che bilancino un basso overhead computazionale, la privacy delle credenziali e l'adattabilità cross-platform. I metodi tradizionali, come le password statiche e le chiavi USB basate su certificati, soffrono di vulnerabilità agli attacchi di intercettazione (eavesdropping), replay e falsificazione. Inoltre, spesso si affidano alla trasmissione esplicita dell'identità o a operazioni di crittografia a chiave pubblica complesse, poco adatte a dispositivi con scarse risorse. Le alternative leggere esistenti (ad esempio, schemi basati su PUF, blockchain o ECC) spesso non riescono a risolvere simultaneamente i rischi di malware a livello software, gli elevati costi computazionali e la fuga di privacy inerente al collegamento dei messaggi di autenticazione alle credenziali di identità.

Metodologia
Il documento propone uno schema di autenticazione zero-knowledge assistito da hardware, progettato per terminali IoT con risorse limitate. La metodologia centrale integra un dispositivo USBKEY come carrier hardware fidato locale (che agisce come Prover, $P$) con un protocollo di prova a conoscenza zero basato sul framework Generalized Subspace Vector Oblivious Linear Evaluation (GSVOLE-2DLC).

• Architettura del Sistema: Il sistema comprende una USBKEY lato utente, un client host (non fidato, responsabile solo del inoltro dei messaggi), un server di autenticazione (che agisce come Verifier, $V$) e un database sicuro. La USBKEY memorizza localmente le informazioni sulla "witness" derivate dalle credenziali dell'utente, garantendo che le credenziali originali non lascino mai il dispositivo.
• Meccanismo del Protocollo: Il processo di autenticazione segue un modello in quattro fasi:
  1. Registrazione: Il server genera i parametri del protocollo (dimensioni del codice lineare, matrici generatrici, equazioni di vincolo) e li lega alle credenziali dell'utente, scrivendoli nella USBKEY.
  2. Generazione della Sfida (Challenge): Il server genera un nuovo vettore di sfida casuale e matrici di codifica per ogni sessione.
  3. Generazione della Prova: La USBKEY utilizza le informazioni locali sulla witness e la sfida ricevuta per calcolare i parametri temporanei della prova ($\tilde{a}, \tilde{b}, S, \tilde{v}$) tramite il protocollo GSVOLE-2DLC. Ciò comporta addizioni in campi finiti, moltiplicazioni e operazioni matriciali, evitando la crittografia a chiave pubblica pesante.
  4. Verifica: Il server verifica la prova attraverso due controlli: la coerenza del vincolo e la coerenza GSVOLE. Una verifica riuscita conferma l'identità senza che il server acceda mai alla password originale o al vettore witness.
• Adattabilità: Per adattarsi a diverse capacità hardware, il sistema dispone di parametri di campo finito configurabili e interfacce di aritmetica modulare, implementati su un prototipo di USBKEY con architettura PowerPC.

Contributi Chiave

1. Framework Assistito da Hardware: Gli autori propongono un framework che combina l'isolamento hardware locale delle USBKEY con le capacità zero-knowledge di GSVOLE-2DLC. Ciò consente al server di autenticare i dispositivi senza accedere alle credenziali di identità originali, mitigando efficacemente la fuga di privacy.
2. Prova Dinamica Legata alla Sessione: Viene costruito un meccanismo dinamico in cui il server emette una sfida casuale unica per ogni sessione. La USBKEY genera parametri di prova validi solo per quella specifica sessione. Questa doppia verifica (coerenza del vincolo e coerenza GSVOLE) previene attacchi di replay, manomissione e falsificazione.
3. Implementazione del Prototipo e Valutazione: È stato sviluppato e valutato un prototipo reale di USBKEY basato su architettura PowerPC. Lo studio fornisce un'analisi dettagliata di come specifici parametri (ampiezza dei bit del campo finito, lunghezza del codeword, bit di informazione, numero di vincoli e grado di parallelismo) influenzino la latenza di autenticazione, offrendo una base per la selezione dei parametri in scenari con risorse limitate.

Risultati Sperimentali
Il prototipo è stato testato utilizzando una USBKEY PowerPC (180 MHz) come prover e un Intel Core i5-13600KF come verifier.

• Prestazioni: Sotto una specifica configurazione (campo primo a 64 bit, $n_C=4, k_C=3, d_C=3, \ell=2, t=7$), il tempo totale di autenticazione del sistema è stato di circa 0,5476 secondi, con il tempo di verifica del server trascurabile a 0,0031 secondi.
• Sensibilità ai Parametri:
  • Il grado di parallelismo ($\ell$) e il numero di equazioni di vincolo ($t$) sono stati identificati come i fattori più significativi che influenzano la latenza.
  • L'ampiezza dei bit del campo finito ha mostrato una correlazione positiva con il tempo di esecuzione, con un aumento netto osservato tra l'intervallo 32-bit e 256-bit.
  • La distanza minima ($d_C$) ha avuto un impatto minimo sulle prestazioni.
• Analisi Comparativa: Rispetto agli schemi esistenti che utilizzano accoppiamenti bilineari o ECC su piattaforme embedded simili o leggermente più potenti (ad esempio, Intel Edison, Cortex-M3), lo schema proposto ha dimostrato prestazioni competitive (0,5476 s) utilizzando al contempo una piattaforma hardware a minor costo (PowerPC 180 MHz).
• Correttezza: I test funzionali hanno confermato che il sistema esegue correttamente i processi di registrazione, generazione della sfida, generazione della prova e doppia verifica senza violare le informazioni sulla witness.

Significatività e Rivendicazioni
Il documento afferma che lo schema proposto affronta con successo il compromesso tra sicurezza, privacy ed efficienza nell'autenticazione IoT. Confinando i calcoli sensibili all'interno di una USBKEY protetta dall'hardware e utilizzando un protocollo zero-knowledge leggero, il sistema ottiene:

• Privacy delle Credenziali: Le password originali e i vettori witness non vengono mai trasmessi sulla rete.
• Resistenza a Replay e Falsificazione: Le sfide legate alla sessione garantiscono che le prove storiche siano non valide per le nuove sessioni.
• Adattabilità Leggera: L'affidamento all'aritmetica di campo finito piuttosto che a complesse operazioni a chiave pubblica rende lo schema adatto a dispositivi edge con risorse limitate.

Gli autori concludono che lo schema è particolarmente adatto per la sensoristica intelligente e i nodi edge industriali che richiedono isolamento hardware. Notano con moderazione che per scenari che comportano attacchi fisici forti, compromissione totale del verifier o autenticazione cloud ad alta concorrenza, sarebbero necessari meccanismi aggiuntivi (come l'individuazione delle intrusioni e una protezione hardware potenziata). Il lavoro futuro prevede l'inclusione dell'analisi dei canali laterali, della valutazione del consumo energetico e di confronti più estesi con baseline su piattaforme identiche.