Resumo Técnico: MobiShield

Definição do Problema

A detecção de malware em Android enfrenta três desafios convergentes que os frameworks de Aprendizado Federado (FL) existentes não conseguem resolver simultaneamente:

1. Heterogeneidade de Clientes (Dados Não-IID): Dispositivos móveis encontram diversas famílias de malware (ex: adware corporativo vs. cavalos de Troia bancários), levando a distribuições de dados não-IID que degradam esquemas de agregação padrão como o FedAvg.
2. Drift de Conceito (Concept Drift): O cenário de malware é não estacionário; atacantes continuamente reempacotam e ofuscam códigos, causando mudanças na distribuição conjunta $P(x,y)$ ao longo do tempo. Modelos treinados em snapshots estáticos degradam rapidamente em implementações do mundo real.
3. Vazamento de Privacidade: Embora o FL evite o compartilhamento de dados brutos, as atualizações de gradiente podem vazar assinaturas comportamentais sensíveis. A Privacidade Diferencial (DP) é necessária para mitigar isso, mas cronogramas de ruído DP estáticos criam uma tensão: períodos de alto drift exigem atualizações de modelo maiores (aumentando a sensibilidade), o que necessita de maior ruído para manter a privacidade, degradando assim a utilidade do modelo.

Frameworks existentes tipicamente abordam apenas um ou dois desses problemas isoladamente. Por exemplo, o FL-MALDRIFT lida com heterogeneidade e drift, mas carece de garantias formais de privacidade, enquanto abordagens DP-FL fornecem privacidade, mas são cegas ao drift de conceito e à heterogeneidade de características.

Metodologia: O Framework MobiShield

O MobiShield é um framework de FL modular projetado para resolver conjuntamente a heterogeneidade de clientes, o drift de conceito e a privacidade diferencial. Ele opera através de quatro módulos fortemente acoplados executados em cada rodada de comunicação:

1. Seleção de Características Adaptativa e Consciente da Heterogeneidade (AHFS)

Para abordar dados não-IID, o AHFS emprega um mecanismo de atenção multi-cabeça (4 cabeças) no lado do cliente.

• Entrada: Um vetor de características híbrido de 256 dimensões composto por características estáticas (permissões, chamadas de API, opcodes) e características dinâmicas (n-gramas de chamadas de sistema).
• Mecanismo: O módulo computa uma máscara de atenção por cliente que repondera o vetor de características antes do treinamento local.
• Privacidade: Os pesos de atenção são aprendidos e mantidos localmente; eles não são transmitidos ao servidor, prevenindo o vazamento de informações distributivas.

2. Detector de Drift Federado Distribuído (DFDD)

O DFDD monitora mudanças distributivas de forma assíncrona entre os clientes e as agrega no servidor.

• Lado do Cliente: Cada cliente executa um detector HDDM (Método de Detecção de Drift baseado em Hoeffding) na sequência de erros de lote locais para gerar um score de drift bruto $z_k$.
• Lado do Servidor: O servidor agrega esses scores usando uma Média Móvel Exponencialmente Ponderada (EWMA) ponderada por divergência KL para produzir um score de severidade de drift global $\hat{Z}(t)$. Este score serve como o sinal primário para os outros módulos.

3. Aprendiz Federado Diferencialmente Privado (DPFL)

Este módulo implementa DP-SGD com um cronograma de ruído adaptável ao drift, formando a inovação central do artigo.

• Acoplamento Adaptativo: O score de drift global $\hat{Z}(t)$ controla diretamente os parâmetros de DP:
  • Raio de Clipping $C(t)$: $C(t) = C_{min} + (C_{max} - C_{min}) \cdot \hat{Z}(t-1)$
  • Multiplicador de Ruído $\sigma(t)$: $\sigma(t) = \sigma_{min} + (\sigma_{max} - \sigma_{min}) \cdot \hat{Z}(t-1)$
• Lógica: Quando o drift é alto, o sistema intensifica a privacidade (maior ruído e limites de clipping) para proteger atualizações voláteis. Quando a distribuição está estável, ele relaxa essas restrições para maximizar a utilidade.
• Contabilidade: A perda de privacidade é rastreada usando o contador de momentos de Privacidade Diferencial de Rényi (RDP) para garantir uma garantia $(\epsilon, \delta)$ provável.

4. Agregação e Portão de Clientes Adaptativo (ACAG)

O ACAG atua como um portão de qualidade, admitindo atualizações de clientes apenas se satisfizerem um critério duplo:

1. Qualidade Local: A acurácia de validação $q_k$ deve estar acima de um limiar ajustado pelo score de drift global ($q_k \geq \bar{q} - \kappa \hat{Z}$).
2. Tolerância ao Drift: O score de drift local do cliente $z_k$ deve estar dentro de um limite dinâmico ($z_k \leq \tau_{gate} + \mu \hat{Z}$).
   Isso evita que gradientes obsoletos ou corrompidos contaminem o modelo global, particularmente durante períodos de alto drift.

Principais Contribuições

O artigo reivindica cinco contribuições primárias:

1. Framework Unificado: O MobiShield é o primeiro framework de FL para detecção de malware em Android a integrar simultaneamente adaptação de características consciente da heterogeneidade, detecção de drift distribuída e privacidade diferencial formalmente provada.
2. Acoplamento Bidirecional Drift-Privacidade: Um mecanismo de feedback inovador onde o nível estimado de severidade de drift global recalibra dinamicamente o orçamento de ruído DP, alcançando um tradeoff automático entre privacidade e utilidade.
3. Seleção de Características Adaptativa: O uso de máscaras de atenção por cliente para mitigar os efeitos adversos das distribuições não-IID na acurácia de classificação.
4. Portão Duplo Qualidade-Drift: Um portão de agregação inovador que filtra atualizações baseando-se tanto na qualidade do modelo local quanto nos scores de drift em tempo real.
5. Avaliação Abrangente: Validação empírica extensa em quatro datasets (Drebin, CICMalDroid 2020, AndroZoo cronológico e um benchmark de drift sintético) com testes de significância estatística.

Resultados Experimentais

O framework foi avaliado contra nove baselines, incluindo FedAvg, FedProx, FL-MALDRIFT e DP-FL.

• Acurácia: O MobiShield alcançou desempenho de estado da arte em todos os datasets:
  • Drebin: 96,8% (vs. 94,7% para FL-MALDRIFT)
  • CICMalDroid 2020: 97,6% (vs. 96,8% para FL-MALDRIFT)
  • AndroZoo (Temporal): 94,7% (vs. 92,4% para FL-MALDRIFT)
  • Drift Sintético: 93,5%
• Garantia de Privacidade: O sistema opera sob uma garantia de privacidade diferencial provável de $\epsilon \leq 8$ e $\delta = 10^{-5}$.
• Estudo de Ablação: A remoção de módulos individuais resultou em quedas significativas de desempenho:
  • Remover o DFDD causou uma queda de 6,8% na acurácia.
  • Remover o ACAG causou uma queda de 5,2%.
  • Remover o AHFS causou uma queda de 4,5%.
  • Substituir o cronograma de ruído adaptativo por um fixo causou uma queda de 3,3%, confirmando o valor do acoplamento drift-privacidade.
• Significância Estatística: Todas as comparações par a par contra os baselines foram estatisticamente significativas ($p < 0,01$) via testes t pareados e ANOVA de uma via.
• Overhead: O MobiShield incorre em um aumento de 18,4% no tempo de computação por rodada em comparação ao FL-MALDRIFT (aprox. 84,7ms vs. 71,4ms) e um aumento negligível no overhead de comunicação (1,4 MB vs. 1,2 MB por rodada).

Significância e Alegações

O artigo posiciona o MobiShield como uma resolução para o "conflito técnico genuíno" entre resiliência ao drift e preservação da privacidade. Os autores afirmam que:

• Drift e privacidade não são independentes: O nível apropriado de injeção de ruído muda conforme a distribuição de malware se desloca.
• Tradeoff Utilidade-Privacidade: Ao tornar o orçamento de privacidade uma função dinâmica da severidade do drift, o MobiShield demonstra que a privacidade diferencial rigorosa e a alta acurácia na detecção de malware não são objetivos mutuamente exclusivos.
• Implementação Prática: O framework fornece um caminho principista para implantar detecção de malware preservando a privacidade e resiliente ao drift em ambientes móveis do mundo real, onde os dados são heterogêneos e as ameaças evoluem continuamente.

Os autores reconhecem limitações, observando que o design atual assume um servidor "honesto-mas-curioso" e não fornece garantias formais contra ataques bizantinos ou de envenenamento (poisoning), o que sugerem como uma direção para trabalhos futuros.