Riepilogo Tecnico: Riconoscimento Facciale Criptato Leggero, Pratico e con Supporto GPU

Definizione del Problema

I sistemi di riconoscimento facciale operano tipicamente secondo un'architettura client-server in cui un client estrae un embedding facciale e un server esegue la ricerca di similarità contro un database. Questo modello solleva significative preoccupazioni sulla privacy, poiché i dati facciali costituiscono informazioni identificative personali (PII) soggette a rigide normative. Sebbene gli approcci crittografici come la Crittografia Completamente Omomorfica (FHE) consentano la ricerca di similarità su dati criptati senza rivelare il testo in chiaro, gli esistenti protocolli basati su FHE (specificamente lo stato dell'arte del protocollo HyDia) affrontano severe limitazioni pratiche.

I principali colli di bottiglia nell'attuale riconoscimento facciale basato su FHE sono:

1. Elevato Overhead di Memoria: I metodi esistenti richiedono grandi set di chiavi di rotazione (spesso $O(\ell)$ dove $\ell$ è la dimensione del vettore) per eseguire moltiplicazioni matrice-vettore diagonali. Ciò comporta un uso eccessivo della RAM sia sul lato client che su quello server (ad esempio, oltre 33 GB per database fino a 1 milione di voci), rendendo l'implementazione su dispositivi edge con risorse limitate impraticabile.
2. Latenza Computazionale: Le operazioni FHE, in particolare le rotazioni dei ciphertext e la riscalatura (rescaling), sono limitate dalla larghezza di banda della memoria su CPU. L'offloading ingenuo di singole operazioni verso le GPU spesso degrada le prestazioni a causa dei costosi trasferimenti di dati host-device e delle ripetute conversioni tra strutture dati CPU (OpenFHE) e GPU (FIDESlib).

Metodologia

Gli autori propongono una strategia di ottimizzazione a doppio livello che mira all'efficienza algoritmica e all'accelerazione hardware a livello di sistema, basandosi sul protocollo HyDia.

1. Miglioramento Algoritmico: BSGS-Diagonal

Per affrontare il collo di bottiglia delle chiavi di rotazione e della memoria, gli autori introducono BSGS-Diagonal, una variante algoritmica della strategia Baby-Step/Giant-Step (BSGS) adattata per contesti di matrici criptate.

• Meccanismo: A differenza del BSGS standard che assume una matrice in chiaro, BSGS-Diagonal opera su matrici di database criptate. Precomputa tutte le rotazioni necessarie del vettore di query criptato una sola volta e le riutilizza attraverso tutti i gruppi di matrici ($G$) nel database.
• Riduzione delle Chiavi: Precomputando le rotazioni della query, il metodo ammortizza il costo delle chiavi di rotazione. Riduce il set di chiavi di rotazione richiesto da $\ell-1$ (in HyDia) a circa $2\sqrt{\ell}$ (specificamente $n_1 + n_2 - 2$ chiavi).
• Efficienza della Memoria: Questo riduce il set di chiavi di rotazione del client del 91%, abbassando i requisiti di memoria del client di circa 14 GB. Impiega inoltre una strategia di accumulazione incrementale con multi-threading per ridurre l'uso di picco della RAM del server.
• Prestazioni: L'approccio migliora il tempo di esecuzione fino a 1,57× per la verifica dell'appartenenza e 1,43× per gli scenari di identificazione rispetto all'originale HyDia.

2. Miglioramento a Livello di Sistema: Architettura Residente in GPU

Per affrontare la latenza computazionale, gli autori progettano una pipeline end-to-end residente in GPU utilizzando FIDESlib (una libreria CKKS accelerata da CUDA) integrata con OpenFHE.

• Principio di Design: Minimizzare i trasferimenti host-device mantenendo l'intera pipeline di elaborazione della query (calcolo della similarità, confronto della soglia e aggregazione) sulla GPU. Viene caricato solo il ciphertext iniziale della query e viene scaricato solo il risultato finale.
• Kernel Personalizzati: L'implementazione include:
  • Valutatore di Chebyshev Nativo per GPU: Un'implementazione personalizzata che utilizza il metodo di Paterson–Stockmeyer per approssimare la funzione segno per il confronto della soglia interamente sulla GPU, evitando i viaggi di andata e ritorno verso la CPU.
  • Variante BSGS-RTX-TBS: Una variante specifica per GPU che utilizza diagonali pre-ruotate (calcolate offline) e rotazioni "giant-step" on-demand. Questo riduce il set di chiavi di rotazione online sulla GPU da circa 516 a circa 36, riducendo significativamente l'uso della VRAM.
  • Relinearizzazione Pigra (Lazy Relinearization): Relinearizzazione differita nell'accumulazione della similarità per ottimizzare l'uso della memoria.
• Varianti: Il documento valuta tre configurazioni GPU:
  • HyDia-RTX-DG: Porting diretto su GPU del protocollo HyDia originale.
  • BSGS-RTX-TBS: Porting su GPU con BSGS e pre-rotazione omomorfica lato server.
  • BSGS-RTX-TBE: Porting su GPU con BSGS e pre-rotazione in chiaro lato enroller (eliminando le chiavi di rotazione negative).

Contributi Principali

Il documento rivendica tre contributi primari:

1. Riduzione Significativa della Memoria: L'algoritmo BSGS-Diagonal riduce drasticamente i requisiti delle chiavi di rotazione (riduzione del 91%), abbassando la memoria del client di circa 14 GB e l'uso di picco della RAM del server fino a 4,5× per database fino a $2^{20}$ voci, rendendo possibile l'implementazione edge.
2. Primo Protocollo End-to-End Accelerato da GPU: Gli autori presentano la prima implementazione accelerata da GPU di un protocollo di riconoscimento facciale criptato che supporta sia l'appartenenza che l'identificazione. Ciò consente tempi di esecuzione inferiori al secondo per database fino a $2^{15}$ voci (e fino a $2^{16}$ con la variante BSGS) riducendo l'uso della RAM host.
3. Implementazione Open-Source: Viene fornita un'implementazione completa e open-source basata su OpenFHE e FIDESlib, testata su database che vanno da $2^{10}$ a $10^6$ voci (CPU) e fino a $2^{16}$ voci (GPU).

Risultati Sperimentali

Gli esperimenti sono stati condotti su un Intel Xeon Platinum 8260 (CPU) e NVIDIA Quadro RTX 8000 / H200 (GPU).

• Prestazioni CPU (BSGS-Diagonal vs. HyDia):

  • Accelerazione: Fino a 1,57× più veloce per l'appartenenza e 1,43× per l'identificazione.
  • Memoria: La RAM di picco è ridotta da >33 GB (HyDia) a <11 GB (BSGS-Diagonal) per 1M di voci. Le chiavi di rotazione del client sono ridotte da 511 a 44.
  • Utilizzo su Disco: Ridotto fino a 5×.

• Prestazioni GPU:

  • Accelerazione: Le implementazioni GPU hanno ottenuto un'accelerazione fino a 9× per HyDia e fino a 21× per la variante BSGS rispetto ai baseline della CPU.
  • Latenza: Ha raggiunto il riconoscimento facciale criptato in meno di un secondo per database fino a $2^{15}$ voci.
  • Memoria: La variante BSGS-RTX-TBS ha ridotto l'uso di memoria di picco della GPU da ~27 GB (HyDia-RTX-DG) a ~9 GB per 8.192 vettori, permettendo l'implementazione su GPU con 12 GB di VRAM.
  • Scalabilità: La GPU H200 (141 GB di VRAM) ha esteso il supporto a database di dimensione $2^{17}$.

• Accuratezza:

  • La valutazione sul dataset FRGC 2.0 (44.228 embedding) ha confermato che la pipeline criptata preserva la qualità del riconoscimento.
  • Precisione > 99,95%, Recall ≈ 99,40% e Accuratezza > 99,998%.
  • Ridurre la profondità del confronto di Chebyshev da $\kappa=10$ a $\kappa=8$ ha prodotto accelerazioni senza perdite misurabili di accuratezza.

Significato e Rivendicazioni

Il documento posiziona il proprio lavoro come un passo verso l'implementazione pratica del riconoscimento facciale preservante la privacy in ambienti reali con risorse limitate.

• Fattibilità: Riducendo l'impronta di memoria e la latenza computazionale, gli autori sostengono che il riconoscimento facciale basato su FHE non sia più limitato ad alti server, ma possa essere vitale per i client edge e le normali GPU server.
• Privacy: Il sistema fornisce garanzie crittografiche (basate sul problema Ring Learning with Errors) piuttosto che obfuscazione empirica, proteggendo dagli attacchi di ricostruzione.
• Scienza Aperta: Gli autori sottolineano il valore della loro implementazione open-source, che integra librerie all'avanguardia (OpenFHE, FIDESlib) per fornire un baseline riproducibile per la ricerca futura nella ricerca criptata.

Gli autori rimangono modesti, osservando che, sebbene la loro implementazione GPU raggiunga prestazioni sub-secondarie per database fino a $2^{15}$, i database più grandi affrontano ancora vincoli di memoria sull'hardware attuale, e i compromessi tra tempo di configurazione (enrollment) e latenza di query rimangono un fattore nelle scelte di deployment.