Segurança e Arquitetura
AeroMais — Sistema de Medição

1. Resumo Executivo

O AeroMais é um sistema embarcado de medição de combustível composto por: um servidor Python/Flask rodando em Raspberry Pi, um aplicativo Android (Flutter) com WebView, um display embarcado e integração com a plataforma Automais.IO via WireGuard VPN.

Durante o processo de desenvolvimento, foram identificadas e tratadas 16 pendências de segurança (referenciadas como PTRZN-XXXX). Cada pendência foi documentada, analisada e resolvida com código rastreável nos comentários do fonte.

Este relatório apresenta: (1) a arquitetura do sistema, (2) os fluxos de autenticação e WiFi, (3) o detalhamento de cada PTRZN com o problema original e a solução implementada, e (4) a demonstração de que os objetivos de segurança máxima foram atingidos.

3. Contexto Técnico e Progresso

3.1 Principal Ponto de Atenção — Enlace Tablet ↔ CPMais

O maior desafio contínuo do projeto é garantir que a comunicação entre o tablet Android (AeromaisApp) e o CPMais (dispositivo Linux embarcado) seja estabelecida sobre HTTPS com certificados seguros — e que essa comunicação se mantenha estável ao longo do tempo, independente das condições de campo.

3.2 Decisão Arquitetural — CPMais como Hotspot (AP)

Durante os testes observamos um comportamento de instabilidade quando o CPMais atuava como cliente WiFi (STA) e o tablet como ponto de acesso: o tablet por vezes derrubava o roteador interno, e o CPMais não se reconectava de forma confiável. O caminho inverso se mostrou muito mais estável.

3.3 Desafio Derivado — CPMais sem Acesso à Internet

Com o CPMais em modo AP, ele deixa de ser um cliente de rede — portanto não tem acesso direto à internet. Isso levantou um problema: como fazer manutenção remota e sincronizar certificados sem expô-los?

Solução: Relay UDP via AeromaisApp

O app Android atua como relay de pacotes UDP da VPN do CPMais para o servidor VPN da plataforma.

Desafio de Roteamento Android — WiFi vs. 4G

Um obstáculo crítico surgiu durante os testes: ao conectar ao AP do CPMais, o Android detecta que o WiFi não tem internet e exibe o diálogo "rede sem internet, conectar mesmo assim?". Em vários dispositivos/OEMs, ao confirmar, o Android passa a rotear todo o tráfego pelo WiFi — incluindo os pacotes do relay UDP. Como o CPMais não tem saída para a internet, esses pacotes eram descartados no RPi e o relay nunca conseguia completar o handshake WireGuard.

Um segundo problema era o DNS: o dnsmasq do AP está configurado com address=/#/10.254.254.1, fazendo todos os domínios resolverem para o IP do CPMais. Com isso, automais.io também resolvia para 10.254.254.1, e o relay tratava os pacotes do CPMais como respostas do servidor remoto, descartando-os silenciosamente.

Solução: Dual-Socket + DNS Celular + Captive Portal 302

Três correções complementares foram implementadas:

O fluxo completo do relay com dual-socket:

sequenceDiagram
    participant C as CPMais (AP · 10.254.254.1)
    participant WL as _socketLocal (WiFi 10.254.254.x:51821)
    participant WR as _socketRemote (IP Celular:efêmero)
    participant V as automais.io:51820

    Note over C,WL: Enlace local WiFi AP (sem internet)
    Note over WR,V: Enlace celular 4G (internet)

    C->>WL: Handshake WireGuard UDP
    WL->>WR: relay (memória interna)
    WR->>V: Reencaminha via 4G
    V-->>WR: Resposta WireGuard
    WR->>WL: relay
    WL-->>C: Entrega ao CPMais

    Note over C,V: Túnel WireGuard estabelecido via relay
    C->>V: Tráfego de manutenção / PKI (via túnel)
    V-->>C: Configuração remota / PKI enrollment
      

3.4 Resultado Final — HTTPS Seguro sem Exposição de Certificados

Com o túnel VPN viabilizado pelo relay do AeromaisApp, o CPMais consegue:

• ✅ Relay UDP estável — dual-socket — o relay usa dois sockets separados: um vinculado ao IP WiFi AP (para o CPMais) e outro ao IP celular (para automais.io). Isso garante que o tráfego de relay saia obrigatoriamente pelo 4G, independente de como o Android roteou o tráfego ao conectar no AP. O DNS de automais.io é resolvido via ConnectivityManager da rede celular, contornando o dnsmasq do AP (que retornaria 10.254.254.1 para todos os domínios).
• ✅ 4G mantido para outros apps e sistema — o captive portal do AP responde com 302 (redirect) em vez de 204 ao probe /generate_204 do Android. Com 204, o Android consideraria o WiFi como "rede com internet" e rotearia tudo pelo CPMais. Com 302, o Android marca a rede como "captive portal" e mantém o 4G como rota padrão de internet para todos os apps e o sistema operacional.
• ✅ Enrollment de certificados via PKI Service — o CPMais gera o par de chaves localmente, envia apenas o CSR (nunca a chave privada) e recebe o certificado assinado pela plataforma, tudo pelo canal VPN.
• ✅ Manutenção e configuração remota — acesso seguro ao CPMais via túnel VPN sem expor nenhuma porta diretamente à internet.
• ✅ HTTPS entre tablet e CPMais — após o enrollment, toda a comunicação entre o AeromaisApp e o CPMais ocorre sobre HTTPS/mTLS com certificados emitidos pela CA privada da plataforma. Nenhum certificado é transferido manualmente ou exposto durante o processo.
• ✅ Renovação automática — o CPMais verifica diariamente se o certificado precisa ser renovado e executa o processo automaticamente via o mesmo canal VPN, sem intervenção humana.

2. Topologia do Sistema

O AeroMais é composto por quatro camadas físicas que se comunicam de forma segura. A segurança não reside em um único componente mas na composição das camadas.

graph TB
    subgraph cloud["☁️  Plataforma Automais.IO"]
        WGS["WireGuard\nVPN Server"]
        PKI["PKI Service"]
        KV["🔐 Automais.IO\nCA RSA-4096\n(chave gerenciada internamente)"]
        PG[("Audit log\ncertificados e tokens")]
        KV-->|Sign| PKI
        PKI---PG
        WGS---PKI
    end

    subgraph rpi["🖥️  Raspberry Pi — AeroMaisServer"]
        NGINX["Nginx\nmTLS · porta 443"]
        FLASK["Flask\n127.0.0.1\n(não exposto)"]
        DB[("MariaDB")]
        WIFI["WiFiMaisManager\nhostapd · dnsmasq · iptables"]
        NGINX-->FLASK
        FLASK---DB
    end

    subgraph app["📱  AeromaisApp — Android"]
        WV["WebView\nInterface Flask"]
        WGC["WireGuard Client\nwg-automais"]
        RM["RouterMonitor\nrelay UDP"]
        WV---WGC
        RM---WGC
    end

    DISPLAY["⚙️  AeromaisDisplay\nC++ · RoxProtocol"]

    WGS-->|"VPN wg-automais"| WGC
    WGS-->|"VPN wg-automais"| NGINX
    app<-->|"WiFi AP · 10.254.254.x"| rpi
    FLASK-->|"Serial UART"| DISPLAY
      

Componentes e responsabilidades

3. Fluxo de Autenticação

A autenticação do AeroMais opera em duas camadas independentes e complementares: a camada TLS mútua (mTLS) resolvida no Nginx antes de qualquer HTTP, e a camada de sessão de aplicação gerenciada pelo Flask.

3.1 Camada 1 — mTLS (Mutual TLS) via Nginx

Toda requisição ao servidor Flask passa obrigatoriamente pelo Nginx. O Nginx está configurado com ssl_verify_client on — qualquer conexão sem certificado de cliente válido assinado pela CA privada é rejeitada na camada TLS, antes de qualquer código Python ser executado.

sequenceDiagram
    autonumber
    participant App as AeromaisApp
    participant N as Nginx (porta 443)
    participant F as Flask (127.0.0.1)

    App->>N: TLS ClientHello
    N-->>App: ServerHello + server.crt
    App->>N: client.crt (mTLS)
    N->>N: Verifica client.crt vs ca.crt ✓
    N->>F: proxy_pass + X-SSL-Client-Cert header
    F-->>N: HTTP Response
    N-->>App: HTTP Response

    Note over App,N: Cenário sem certificado de cliente
    App->>N: TLS ClientHello (sem client.crt)
    N-->>App: 400 No required SSL certificate sent
    Note right of F: Flask nunca é alcançado
      

3.2 Camada 2 — Sessão Flask (para operadores humanos)

A interface web (acessada via WebView do app) usa sessão Flask baseada em cookies assinados. O fluxo completo de login com todas as proteções PTRZN aplicadas:

3.3 Camada 3 — Proteções do App Android

Antes de qualquer requisição ser enviada ao servidor, o app verifica o ambiente de execução:

4. WiFiMaisManager — Topologia e Fluxo

O WiFiMaisManager é o módulo do AeroMaisServer responsável pelo gerenciamento inteligente da interface WiFi wlan0 do RPi. Ele opera como uma máquina de dois estados persistidos em /var/lib/aeromais/wifi_state.json.

stateDiagram-v2
    direction TB
    [*] --> UNCONFIGURED : Boot · sem wifi_state.json

    state UNCONFIGURED {
        direction TB
        s1 : wlan0 modo STA
        s2 : Conecta SSID AutomaisIO
        s3 : DHCP client · obtém IP
        s4 : Verifica handshake WireGuard a cada 30s
        s5 : Plataforma Automais.IO configura WG remotamente
        s1 --> s2
        s2 --> s3
        s3 --> s4
        s4 --> s5
    }

    UNCONFIGURED --> CONFIGURED : 1º handshake WG OK\n→ persiste wifi_state.json\n(transição permanente)

    state CONFIGURED {
        direction TB
        ap : wlan0 modo AP\nSSID AeroMais-XXYYZZ\nIP 10.254.254.1/24\niptables DROP ALL (wlan0)
        relay : Sub-loop · Relay WireGuard\nvia AeromaisApp\nWhitelist dinâmica por IP
        ap --> relay : Tablet conecta ao AP
        relay --> ap : Relay encerra
    }
      

Por que o AP é aberto (sem senha WPA)?

Captive Portal — 302 intencional (não 204)

Arquivos gerados em runtime

5. PKI e mTLS — Arquitetura de Certificados

O uso de IP fixo local inviabiliza Let's Encrypt (que não emite para IPs). A solução adotada é uma CA privada com emissão dinâmica via PKI Service da plataforma Automais.IO, com a chave privada da CA armazenada e gerenciada internamente pela plataforma Automais.IO.

flowchart LR
    KV["🔐 Automais.IO\nCA RSA-4096\n(gerenciada internamente)"]

    subgraph api["Plataforma Automais.IO · PKI Service"]
        CA["CA pública\n(pinning Flutter + RPi)"]
        ENR["Enrollment\nCSR + token OTP → Certificado"]
        REN["Renovação\nmTLS → Cert renovado"]
        REV["Revogação\n→ Atualiza CRL"]
        CRL["CRL\n(Certificate Revocation List)"]
    end

    PG[("Audit log\ncertificados emitidos\ntokens de enrollment")]

    KV-->|"assina"| ENR
    KV-->|"assina"| REN
    KV-->|"assina"| REV
    ENR---PG
    REN---PG
    REV---PG
      

Fluxo de Enrollment do RPi

Problemas resolvidos pela arquitetura PKI

6. Pendências PTRZN — Visão Geral

Cada item PTRZN representa uma pendência de segurança identificada durante o desenvolvimento. As seções a seguir detalham o problema original, a solução implementada e como validar a correção.

7. Objetivos de Segurança — Demonstração para Pentest

Checklist de controles implementados

• ✅ mTLS: Toda conexão ao servidor exige certificado de cliente válido (RPi/App). Conexão sem cert = 400 na camada TLS, Flask nunca é alcançado.
• ✅ PKI dinâmica: Chave privada gerada no dispositivo. Enrollment token OTP (TTL 15min, uso único). CA key gerenciada internamente pela plataforma Automais.IO.
• ✅ bcrypt: Senhas armazenadas com bcrypt. MD5 eliminado.
• ✅ Secrets em variáveis de ambiente: JWT_SECRET, FLASK_SECRET_KEY, DB_PASSWORD — nunca hardcoded.
• ✅ Session invalidation: Logout revoga sessão server-side. Cookie antigo é inválido imediatamente.
• ✅ Cookie flags: Secure + HttpOnly + SameSite=Lax em produção.
• ✅ Security headers: CSP, HSTS, X-Frame-Options, CORP, COEP, COOP em dupla camada (Flask + Nginx).
• ✅ Rate limiting: Brute force bloqueado no login.
• ✅ XSS: innerHTML → textContent; regex no campo nome; maxlength em 3 camadas (DOM, backend, banco).
• ✅ Error handling: Stack traces nunca expostos ao cliente. Detalhes logados apenas no servidor.
• ✅ Input validation: Centralizada, com tipo, comprimento, padrão e Content-Type validation.
• ✅ Server fingerprinting: Headers Server e X-Powered-By removidos. server_tokens off no Nginx.
• ✅ Root/emulator detection: 5+4 estratégias independentes; bloqueio total antes de qualquer código sensível.
• ✅ APK integrity: Anti-tamper verificado na inicialização.
• ✅ Renovação de certificados: Automática no RPi (cron) e no app Flutter (na abertura).
• ✅ CRL: Nginx verifica CRL a cada request. CRL atualizada imediatamente após revogação.
• ✅ Relay UDP estável — dual-socket: _socketLocal (WiFi AP) recebe do CPMais; _socketRemote (IP celular) fala com automais.io. Handshake WireGuard completa mesmo quando o Android rotearia o tráfego via WiFi.
• ✅ 4G mantido para sistema e outros apps: Captive portal retorna 302 ao probe /generate_204. Android mantém celular como rota padrão de internet — outros apps e o SO não perdem conectividade ao conectar no AP do CPMais.
• ⚠️ IDOR (PTRZN-1528): RefManager implementado — integração em andamento.

8. Dificuldades Encontradas no Processo de Segurança

8.1 Ambiente de Desenvolvimento vs. Produção

Um dos maiores desafios foi garantir que controles como SESSION_COOKIE_SECURE=True e HSTS ficassem ativados apenas em produção — em desenvolvimento local com HTTP puro, essas flags quebram o fluxo. A solução foi lógica condicional em config.py: detectar automaticamente se NGINX_DOMAIN está definido (indicador de produção) sem precisar setar ENVIRONMENT=production manualmente.

8.2 Cobertura Total de Error Handling

A primeira rodada do PTRZN-1522 corrigiu os blocos mais óbvios. Somente uma varredura manual completa (revisão 2) revelou pontos adicionais que retornavam str(e): em reiniciar_abastecimento, no emulador SPI, nas rotas do encoder e no WiFiManager. Isso ilustra a dificuldade de garantir cobertura total sem uma política de "proibido usar str(e) em responses" testada por lint.

8.3 Falso Positivo em Detecção de Emulador

A lista inicial de fabricantes de emuladores incluía "google", causando bloqueio em dispositivos Pixel físicos durante testes. A correção (remover "google" da lista) exigiu análise cuidadosa de quais estratégias de detecção alternativas cobriam o AVD sem afetar hardware real.

8.4 Garantir que mTLS se aplica a TODOS os endpoints

O Nginx com ssl_verify_client on garante mTLS globalmente. O risco estava em endpoints Flask que poderiam ser alcançados diretamente (se o Flask escutasse em 0.0.0.0). A correção (PTRZN-1515) foi garantir que Flask escuta apenas em 127.0.0.1, tornando o Nginx o único ponto de entrada.

8.5 AP WiFi sem senha como vetor de ataque percebido

A decisão de manter o AP sem senha WPA é contraintuitiva e provavelmente será questionada pela equipe de pentest. A justificativa técnica — iptables DROP ALL é superior a uma senha WPA estática em ambiente industrial — precisa ser demonstrada com evidências das regras de firewall ativas, não apenas documentada.

8.6 IDOR com IDs auto-incrementais

A solução RefManager (PTRZN-1528) exigiu refatoração do frontend e do backend em paralelo. O desafio foi garantir que a camada de resolução de refs fosse transparente para o WebView (que roda JavaScript servido pelo backend) sem quebrar a funcionalidade existente. Esta é a única pendência ainda em desenvolvimento.

8.7 Roteamento Android — WiFi vs. 4G no AP do CPMais

Um comportamento OEM não-padronizado causou instabilidade no relay por semanas: alguns dispositivos Android, ao se conectar a um AP sem internet e confirmar "conectar mesmo assim", passam a rotear todo o tráfego pelo WiFi — incluindo os pacotes UDP do relay. Como o CPMais não tem saída para a internet, os pacotes eram silenciosamente descartados no RPi.

O problema se manifestava como: relay conecta → conta 1 pacote recebido + 1 enviado → para → status cai para "aguardando" → tenta novamente após 60 s. Esse ciclo repetia indefinidamente sem nunca completar o handshake WireGuard.

A causa raiz era dupla: (1) roteamento pelo WiFi, e (2) o dnsmasq com address=/#/10.254.254.1 fazia automais.io resolver para 10.254.254.1, tornando o relay incapaz de distinguir pacotes do CPMais de respostas do servidor remoto.

8.8 Dificuldade de demonstrar segurança "máxima" para pentest

Demonstrar que objetivos de segurança foram atingidos não é trivial porque:

• Segurança negativa — provar que algo não acontece é mais difícil que provar que algo acontece
• Profundidade de camadas — mTLS + sessão + rate limiting + bcrypt + cookie flags são interdependentes; testar uma camada isoladamente não simula o ataque real
• Ambiente embarcado — certificados para IPs locais, WireGuard, AP sem senha — cada elemento é justificável mas incomum, podendo ser marcado como "finding" antes de entender o contexto

9. Evidências para o Relatório de Pentest

9.1 mTLS — rejeição de conexão sem certificado

# Deve retornar erro SSL (400 no Nginx)
curl -v https://<IP_RPI>/api/configuracoes
# Esperado: SSL handshake error — 400 No required SSL certificate was sent

# Com certificado de cliente — deve funcionar
curl -v \
  --cacert certs/ca.crt \
  --cert certs/client.crt \
  --key certs/client.key \
  https://<IP_RPI>/api/configuracoes

9.2 Enrollment token de uso único

# A plataforma Automais.IO valida que cada token só pode ser usado uma vez.
# Um segundo uso do mesmo token deve retornar 401 — verificável no log do RPi:
# install.py: "Enrollment falhou: 401 — token inválido, expirado ou já usado"

# Evidência indireta no RPi:
sudo cat /etc/aeromais/certs/.renewal_info.json
# Deve conter issued_at e expires_at do certificado emitido com sucesso

9.3 Stack trace não exposto

# Content-Type JSON com body form-encoded
curl -X POST https://<IP_RPI>/api/auth/login \
  -H 'Content-Type: application/json' \
  --data-binary 'username=Administrador&password=admin'
# Esperado: HTTP 400 {"error": "Dados inválidos"}
# NÃO deve aparecer: Traceback, File ", Exception, str(e)

9.4 Cookie com flags de segurança

# Verificar header Set-Cookie no login
curl -v -X POST https://<IP_RPI>/api/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"username":"admin","password":"..."}'
# Esperado: Set-Cookie: aeromais_session=...; Secure; HttpOnly; SameSite=Lax

9.5 Sessão invalidada após logout

# 1. Fazer login e guardar o cookie
# 2. Fazer logout
# 3. Tentar usar o cookie antigo em qualquer endpoint protegido
# Esperado: HTTP 401 {"authenticated": false}

9.6 Rate limiting no login

# Tentar login com senha errada repetidamente
for i in {1..10}; do
  curl -X POST https://<IP_RPI>/api/auth/login \
    -H 'Content-Type: application/json' \
    -d '{"username":"admin","password":"errada"}'
done
# Após N tentativas: HTTP 429 Too Many Requests
# Header Retry-After presente na resposta

9.7 Ausência de chave privada no APK

apktool d aeromais.apk -o apk_extracted
grep -r "BEGIN PRIVATE KEY" apk_extracted/
grep -r "BEGIN RSA PRIVATE KEY" apk_extracted/
# Resultado esperado: sem saída (vazio)

9.8 Headers de segurança presentes

curl -I https://<IP_RPI>/
# Devem aparecer:
# X-Frame-Options: SAMEORIGIN
# X-Content-Type-Options: nosniff
# Strict-Transport-Security: max-age=31536000...
# Content-Security-Policy: default-src 'self'...
# Cross-Origin-Embedder-Policy: require-corp
# Cross-Origin-Resource-Policy: same-origin
# Cross-Origin-Opener-Policy: same-origin
# NÃO deve aparecer: Server: (com versão)

9.9 Firewall iptables no AP WiFi

# No RPi em modo AP, verificar regras ativas
sudo iptables -L INPUT -n -v | grep wlan0
# Esperado: policy DROP para wlan0
# Verificar que somente IPs whitelistados têm ACCEPT
sudo iptables -L INPUT -n -v | grep ACCEPT

9.10 Relay UDP — dual-socket e 4G isolado

# 1. Conectar tablet ao AP AeroMais-XXYYZZ
# 2. Confirmar "conectar sem internet" se solicitado
# 3. No AeromaisApp, abrir tela do relay UDP
#
# Verificar que o relay ativou dual-socket:
#   - "dual-socket: WiFi 10.254.254.x:51821 → automais.io(IP_REAL):51820 via IP_CELULAR"
#
# 4. Em outro app do tablet (ex: browser), acessar qualquer site
#    → deve carregar normalmente (internet via 4G ativa)
#
# 5. Aguardar handshake WireGuard no log do RPi:
#    sudo journalctl -u wifimaismanager -f
#    → "Relay ativo: 10.254.254.X — rota padrão e whitelist aplicadas"
#    → "Handshake wg-automais-ap confirmado via 10.254.254.X"

# Verificar que 302 é retornado pelo captive portal (não 204):
curl -v http://10.254.254.1/generate_204
# Esperado: HTTP/1.1 302 Found
# Location: http://10.254.254.1/
# (NÃO deve retornar 204 — 204 causaria roteamento via WiFi)

10. Pendências Abertas e Próximos Passos