Riepilogo Tecnico: MobiShield

Definizione del Problema

Il rilevamento di malware su Android affronta tre sfide convergenti che gli attuali framework di Apprendimento Federato (FL) non riescono ad affrontare simultaneamente:

1. Eterogeneità dei Client (Dati Non-IID): I dispositivi mobili incontrano diverse famiglie di malware (ad esempio, adware aziendale rispetto a Trojan bancari), portando a distribuzioni di dati non-IID che degradano gli schemi di aggregazione standard come FedAvg.
2. Concept Drift (Deriva del Concetto): Il panorama dei malware è non stazionario; gli attaccanti impacchettano e offuscano continuamente il codice, causando uno spostamento della distribuzione congiunta $P(x,y)$ nel tempo. I modelli addestrati su snapshot statici degradano rapidamente nelle implementazioni reali.
3. Leakage della Privacy: Sebbene l'FL eviti la condivisione di dati grezzi, gli aggiornamenti del gradiente possono rivelare firme comportamentali sensibili. La Privacy Differenziale (DP) è necessaria per mitigare questo problema, ma i programmi di rumore DP statici creano una tensione: i periodi di alto drift richiedono aggiornamenti del modello più ampi (aumentando la sensibilità), il che richiede un rumore maggiore per mantenere la privacy, degradando così l'utilità del modello.

I framework esistenti affrontano tipicamente solo uno o due di questi problemi in isolamento. Ad esempio, FL-MALDRIFT gestisce l'eterogeneità e il drift ma manca di garanzie formali di privacy, mentre gli approcci DP-FL forniscono la privacy ma sono ciechi rispetto al concept drift e all'eterogeneità delle caratteristiche.

Metodologia: Il Framework MobiShield

MobiShield è un framework FL modulare progettato per risolvere congiuntamente l'eterogeneità dei client, il concept drift e la privacy differenziale. Opera attraverso quattro moduli strettamente accoppiati eseguiti in ogni round di comunicazione:

1. Selezione delle Caratteristiche Adattiva e Sensibile all'Eterogeneità (AHFS)

Per affrontare i dati non-IID, AHFS impiega un meccanismo di attenzione multi-testa (4 teste) sul lato client.

• Input: Un vettore di caratteristiche ibrido a 256 dimensioni composto da caratteristiche statiche (permessi, chiamate API, opcode) e caratteristiche dinamiche (n-grammi di chiamate di sistema).
• Meccanismo: Il modulo calcola una maschera di attenzione per client che ricalibra il vettore delle caratteristiche prima dell'addestramento locale.
• Privacy: I pesi dell'attenzione sono appresi e mantenuti localmente; non vengono trasmessi al server, prevenendo la fuga di informazioni distributive.

2. Rilevatore di Drift Federato Distribuito (DFDD)

DFDD monitora gli spostamenti distribuzionali in modo asincrono tra i client e li aggrega al server.

• Lato Client: Ogni client esegue un rilevatore HDDM (Hoeffding-based Drift Detection Method) sulla sequenza di errori dei batch locali per generare un punteggio di drift grezzo $z_k$.
• Lato Server: Il server aggrega questi punteggi utilizzando una Media Mobile Esponenzialmente Pesata (EWMA) ponderata dalla divergenza KL per produrre un punteggio globale di severità del drift $\hat{Z}(t)$. Questo punteggio funge da segnale primario per gli altri moduli.

3. Apprendimento Federato Differenzialmente Privato (DPFL)

Questo modulo implementa DP-SGD con un programma di rumore adattivo al drift, costituendo l'innovazione centrale del paper.

• Accoppiamento Adattivo: Il punteggio di drift globale $\hat{Z}(t)$ controlla direttamente i parametri DP:
  • Raggio di Clipping $C(t)$: $C(t) = C_{min} + (C_{max} - C_{min}) \cdot \hat{Z}(t-1)$
  • Moltiplicatore del Rumore $\sigma(t)$: $\sigma(t) = \sigma_{min} + (\sigma_{max} - \sigma_{min}) \cdot \hat{Z}(t-1)$
• Logica: Quando il drift è elevato, il sistema stringe la privacy (rumore e limiti di clipping maggiori) per proteggere gli aggiornamenti volatili. Quando la distribuzione è stabile, allenta questi vincoli per massimizzare l'utilità.
• Contabilità: La perdita di privacy è tracciata utilizzando l'accountant dei momenti della Differential Privacy di Rényi (RDP) per garantire una garanzia $(\epsilon, \delta)$ provabile.

4. Aggregazione e Gating Adattivo dei Client (ACAG)

ACAG agisce come un gate di qualità, ammettendo gli aggiornamenti dei client solo se soddisfano un doppio criterio:

1. Qualità Locale: L'accuratezza di validazione $q_k$ deve essere superiore a una soglia regolata dal punteggio di drift globale ($q_k \geq \bar{q} - \kappa \hat{Z}$).
2. Tolleranza al Drift: Il punteggio di drift locale del client $z_k$ deve rientrare in un limite dinamico ($z_k \leq \tau_{gate} + \mu \hat{Z}$).
   Questo evita che gradienti obsoleti o corrotti contaminino il modello globale, particolarmente durante i periodi di alto drift.

Contributi Chiave

Il paper rivendica cinque contributi primari:

1. Framework Unificato: MobiShield è il primo framework FL per il rilevamento di malware su Android che integra simultaneamente l'adattamento delle caratteristiche consapevole dell'eterogeneità, il rilevamento del drift distribuito e la privacy differenziale formalmente provata.
2. Accoppiamento Bidirezionale Drift-Privacy: Un nuovo meccanismo di feedback in cui la severità stimata del drift globale ricalibra dinamicamente il budget di rumore DP, ottenendo un bilanciamento automatico tra privacy e utilità.
3. Selezione delle Caratteristiche Adattiva: L'uso di maschere di attenzione per client per mitigare gli effetti avversi delle distribuzioni non-IID sull'accuratezza della classificazione.
4. Doppio Gate Qualità-Drift: Un gate di aggregazione innovativo che filtra gli aggiornamenti basandosi sia sulla qualità del modello locale che sui punteggi di drift in tempo reale.
5. Valutazione Esaustiva: Validazione empirica estesa su quattro dataset (Drebin, CICMalDroid 2020, AndroZoo cronologico e un benchmark di drift sintetico) con test di significatività statistica.

Risultati Sperimentali

Il framework è stato valutato contro nove baseline, tra cui FedAvg, FedProx, FL-MALDRIFT e DP-FL.

• Accuratezza: MobiShield ha raggiunto prestazioni allo stato dell'arte in tutti i dataset:
  • Drebin: 96,8% (vs 94,7% per FL-MALDRIFT)
  • CICMalDroid 2020: 97,6% (vs 96,8% per FL-MALDRIFT)
  • AndroZoo (Temporale): 94,7% (vs 92,4% per FL-MALDRIFT)
  • Drift Sintetico: 93,5%
• Garanzia di Privacy: Il sistema opera sotto una garanzia di privacy differenziale provabile di $\epsilon \leq 8$ e $\delta = 10^{-5}$.
• Studio di Ablazione: La rimozione dei singoli moduli ha causato cali significativi nelle prestazioni:
  • La rimozione di DFDD ha causato un calo dell'accuratezza del 6,8%.
  • La rimozione di ACAG ha causato un calo del 5,2%.
  • La rimozione di AHFS ha causato un calo del 4,5%.
  • Sostituire lo schema di rumore adattivo con uno fisso ha causato un calo del 3,3%, confermando il valore dell'accoppiamento drift-privacy.
• Significatività Statistica: Tutti i confronti a coppie contro le baseline sono stati statisticamente significativi ($p < 0,01$) tramite t-test accoppiati e ANOVA a una via.
• Overhead: MobiShield comporta un aumento del 18,4% del tempo di calcolo per round rispetto a FL-MALDRIFT (circa 84,7 ms rispetto a 71,4 ms) e un aumento trascurabile dell'overhead di comunicazione (1,4 MB rispetto a 1,2 MB per round).

Significato e Rivendicazioni

Il paper posiziona MobiShield come una risoluzione del "vero conflitto tecnico" tra resilienza al drift e preservazione della privacy. Gli autori affermano che:

• Il drift e la privacy non sono indipendenti: Il livello appropriato di iniezione di rumore cambia man mano che la distribuzione dei malware muta.
• Tradeoff Utilità-Privacy: Rendendo il budget di privacy una funzione dinamica della severità del drift, MobiShield dimostra che la privacy differenziale rigorosa e l'alto rilevamento di malware non sono obiettivi mutuamente esclusivi.
• Implementazione Pratica: Il framework fornisce una via fondata per il dispiegamento di un rilevamento di malware che preservi la privacy e sia resiliente al drift in ambienti di sicurezza mobile reali, dove i dati sono eterogenei e le minacce evolvono continuamente.

Gli autori riconoscono i limiti, notando che l'attuale design assume un server "honest-but-curious" (onesto ma curioso) e non fornisce garanzie formali contro attacchi Byzantine o di avvelenamento (poisoning), che suggeriscono come direzione per il lavoro futuro.