Mobile, IoT e ambientes restritos compartilham um mesmo desafio: você precisa aplicar criptografia “correta” sob limitações reais de CPU, memória, energia, conectividade e ciclo de vida do dispositivo. O erro comum é tentar replicar padrões de servidores (pilhas completas, validações pesadas, armazenamento abundante) em dispositivos que não conseguem sustentar isso, ou, no extremo oposto, “simplificar” removendo verificações essenciais. Este capítulo organiza decisões criptográficas por caso de uso, focando no que muda nesses ambientes: onde guardar segredos, como estabelecer confiança, como atualizar com segurança e como lidar com conectividade intermitente.
1) O que muda em mobile, IoT e ambientes restritos
1.1 Restrições típicas e impactos práticos
- CPU e aceleração criptográfica: alguns SoCs têm AES/ChaCha, SHA, curvas elípticas ou TrustZone; outros não. Isso altera o custo de handshake, assinatura e criptografia de dados.
- Memória e armazenamento: validação de cadeias de certificados, CRL/OCSP e bibliotecas completas podem ser inviáveis. Você pode precisar de âncoras de confiança reduzidas, pinning ou validação “enxuta”.
- Energia: operações assimétricas e rádio consomem energia. Às vezes, reduzir round-trips de rede economiza mais do que otimizar algoritmo.
- Conectividade intermitente: dispositivos podem ficar offline por longos períodos. Isso afeta renovação de credenciais, verificação de revogação e sincronização de tempo.
- Superfície física: IoT e embarcados sofrem ataques com acesso físico (debug ports, extração de flash, fault injection). O modelo de proteção precisa considerar extração de chaves.
- Atualizações e longevidade: IoT pode ficar em campo por 5–15 anos. Você precisa de mecanismos de atualização e rotação que sobrevivam a mudanças de algoritmos e CA.
1.2 Princípio orientador: “minimizar segredos persistentes”
Em ambientes restritos, o maior risco prático costuma ser o vazamento de um segredo persistente (chave privada, token de longo prazo) por extração do dispositivo, backup indevido, engenharia reversa ou logs. Sempre que possível, prefira:
- Chaves derivadas e efêmeras para sessões e dados temporários.
- Segredos protegidos por hardware (Secure Enclave/TEE/SE/TPM/elemento seguro) quando disponível.
- Credenciais por dispositivo (identidade individual) em vez de “chave compartilhada do produto”.
2) Mobile (Android/iOS): padrões seguros e armadilhas comuns
2.1 Casos de uso típicos em mobile
- App ↔ API (autenticação do usuário, tokens, dados sensíveis).
- Armazenamento local (cache offline, preferências, banco local).
- Chaves para recursos do dispositivo (assinatura local, autenticação biométrica, chaves para criptografar dados).
- Integração com push e deep links (validação de origem e integridade de payloads).
2.2 Onde guardar segredos no app
Evite armazenar segredos em:
- SharedPreferences/NSUserDefaults sem proteção.
- Arquivos no sandbox sem criptografia e sem proteção de backup.
- Código-fonte, strings do app, “config” embutida, ou ofuscação como “proteção”.
Preferências práticas:
- iOS: Keychain para segredos; quando aplicável, use atributos que exigem desbloqueio do dispositivo e, se fizer sentido, presença do usuário (biometria/passcode). Para chaves assimétricas, prefira gerar e manter no Secure Enclave quando disponível.
- Android: Android Keystore para chaves; use chaves não exportáveis e, se necessário, exija autenticação do usuário para uso da chave. Para dados em repouso, criptografe com uma chave gerenciada pelo Keystore, não com uma chave hardcoded.
2.3 Passo a passo: criptografar um cache offline no mobile
Objetivo: armazenar dados offline (por exemplo, respostas de API) de forma que um atacante com acesso ao filesystem do app não consiga ler o conteúdo.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
- Passo 1 — Defina o que precisa ser offline: minimize o conjunto. Não armazene tokens de longa duração se não for necessário.
- Passo 2 — Gere/obtenha uma chave de dados no cofre do SO: crie uma chave simétrica no Keychain/Keystore (idealmente não exportável). Se o cofre não suportar chave simétrica diretamente, guarde um “wrapping key” e derive/unwrap a chave de dados.
- Passo 3 — Criptografe cada item com nonce/IV único: para cada registro do cache, gere um nonce aleatório e armazene junto com o ciphertext. Não reutilize nonce com a mesma chave.
- Passo 4 — Inclua contexto como AAD: autentique metadados como versão do esquema, userId, endpoint, timestamp lógico. Isso evita troca de registros entre usuários ou endpoints.
- Passo 5 — Rotacione por versão do app: mantenha um campo “key version” no cache. Ao atualizar o app, você pode recriptografar gradualmente ou invalidar cache antigo.
- Passo 6 — Proteja contra backup indevido: marque arquivos para não irem a backup (quando aplicável) e evite exportar segredos. Em iOS, configure classes de proteção adequadas; em Android, avalie regras de backup e armazenamento.
2.4 TLS e pinning no mobile: quando usar e como não quebrar o app
Em mobile, pinning pode reduzir risco de interceptação em redes hostis, mas aumenta risco operacional (expiração/rotação de certificado, migração de CDN, incidentes). Uma abordagem prática é pinning “flexível”:
- Pine a chave pública (SPKI) ou um conjunto de pins (atual e próximo), com janela de transição.
- Tenha um plano de emergência: um mecanismo de atualização de pins via configuração assinada (não via endpoint não autenticado) ou um fallback controlado.
- Não desabilite validação de certificado em builds de produção; evite “trust all certs” e proxies de debug fora do ambiente de desenvolvimento.
2.5 Integridade do app e ambiente comprometido
Mesmo com criptografia correta, mobile pode rodar em dispositivos com root/jailbreak, hooking e instrumentação. Medidas úteis (sem prometer “invulnerabilidade”):
- Reduzir valor de segredos no cliente: tokens curtos, escopos mínimos, refresh com proteção adicional.
- Atestar integridade do dispositivo/app quando o risco justificar (por exemplo, transações de alto valor), e degrade graciosamente (limitar funcionalidades, exigir reautenticação).
- Evitar lógica de autorização no cliente: o cliente pode ser manipulado; o servidor deve validar permissões.
3) IoT: identidade por dispositivo, provisionamento e comunicação segura
3.1 Casos de uso típicos em IoT
- Dispositivo ↔ Nuvem (telemetria, comandos, configuração).
- Dispositivo ↔ Gateway (rede local, protocolos leves).
- Atualização de firmware (OTA) e configuração inicial.
- Rede mesh (nós com recursos mínimos).
3.2 Identidade do dispositivo: evite “chave do produto”
Um erro recorrente em IoT é embarcar a mesma chave/segredo em todos os dispositivos de um modelo. Quando um único dispositivo é extraído, toda a frota fica comprometida. Prefira:
- Identidade única por dispositivo (chave privada/certificado ou credencial equivalente).
- Provisionamento em fábrica com injeção segura de credenciais e registro no backend.
- Armazenamento em hardware seguro (elemento seguro, TPM, TEE) quando houver risco de extração física.
3.3 Provisionamento: do “zero” ao dispositivo confiável
Provisionamento é o processo de colocar o dispositivo em um estado em que ele consegue autenticar o backend e ser autenticado por ele. Em IoT, isso precisa ser repetível, auditável e resistente a clonagem.
Estratégia comum: bootstrap com uma credencial inicial e posterior emissão de credencial operacional.
- Credencial inicial (bootstrap): usada apenas para registrar/ativar o dispositivo. Deve ter escopo limitado e possibilidade de revogação rápida.
- Credencial operacional: usada no dia a dia para comunicação. Pode ser rotacionada e renovada sem voltar à fábrica.
3.4 Passo a passo: provisionamento seguro com QR code + credencial de fábrica
Cenário: dispositivo novo chega ao cliente. Ele precisa ser associado a uma conta/tenant e começar a falar com a nuvem.
- Passo 1 — Em fábrica, grave uma identidade única: gere uma chave no dispositivo (idealmente em hardware seguro) ou injete uma chave/certificado por dispositivo. Registre no backend o identificador e o material público correspondente.
- Passo 2 — Gere um “código de ativação”: associe ao dispositivo um código de uso único (impresso/QR) que não seja a chave em si. Esse código serve para provar posse física no momento da ativação.
- Passo 3 — No app do instalador, escaneie o QR: o app envia o código ao backend autenticado pelo usuário/empresa. O backend valida o código e marca o dispositivo como “atribuído” ao tenant.
- Passo 4 — Dispositivo inicia bootstrap: ao ligar, o dispositivo se conecta ao endpoint de ativação e se autentica com sua credencial de fábrica (ou prova criptográfica equivalente). O backend verifica se o dispositivo foi atribuído.
- Passo 5 — Emissão da credencial operacional: o backend entrega (ou permite que o dispositivo obtenha) uma credencial operacional com escopo e validade definidos. Se possível, faça o dispositivo gerar a chave e enviar apenas o material público para emissão.
- Passo 6 — Bloqueie reutilização do código: o código de ativação deve expirar e ser marcado como consumido. Se o dispositivo for resetado, use um fluxo de reprovisionamento controlado.
- Passo 7 — Registre telemetria de segurança: logue eventos de ativação, mudanças de credencial, falhas de autenticação e tentativas repetidas.
3.5 Protocolos e formatos leves: escolhas práticas
IoT frequentemente usa MQTT, CoAP ou protocolos proprietários. A criptografia aplicada aqui é menos sobre “inventar” e mais sobre encaixar segurança no transporte e no payload com baixo overhead:
- MQTT: normalmente protegido com TLS. Atenção à validação do servidor e à autenticação do cliente (por dispositivo).
- CoAP: pode usar DTLS ou OSCORE (proteção no nível da mensagem). Útil quando há proxies, caches ou topologias onde segurança no payload é vantajosa.
- Payload autenticado: mesmo com canal seguro, autenticar mensagens pode ajudar em cenários store-and-forward, gateways intermediários ou auditoria de integridade ponta a ponta.
3.6 Atualização de firmware (OTA): integridade, anti-rollback e chaves de assinatura
OTA é um dos pontos mais críticos em IoT: se um atacante consegue instalar firmware malicioso, ele contorna qualquer criptografia do canal. Práticas essenciais:
- Verificação de assinatura do firmware no dispositivo antes de instalar.
- Anti-rollback: impedir downgrade para versões vulneráveis. Use contador monotônico, versão assinada e armazenamento protegido.
- Partições A/B e fallback: reduz risco de “brick” e permite atualização segura com verificação antes de bootar.
- Separação de chaves: chave de assinatura de release deve ser altamente protegida; o dispositivo deve embutir apenas a chave pública (ou cadeia mínima) necessária para verificar.
3.7 Passo a passo: pipeline de OTA com verificação no boot
- Passo 1 — Defina formato do pacote: inclua versão, hash do payload, metadados (modelo, região), e assinatura do manifesto.
- Passo 2 — Assine o manifesto, não apenas o binário: o manifesto descreve o que será instalado; o dispositivo valida manifesto e então valida o binário conforme o manifesto.
- Passo 3 — Faça download com retomada: suporte a chunks e verificação incremental para links instáveis.
- Passo 4 — Valide antes de gravar como ativo: grave em partição secundária, valide assinatura e integridade, só então marque como “bootável”.
- Passo 5 — Implemente anti-rollback: compare a versão do manifesto com o valor monotônico armazenado; recuse versões menores.
- Passo 6 — Telemetria e auditoria: reporte sucesso/falha, versão instalada e motivo de recusa (assinatura inválida, versão antiga, modelo incompatível).
4) Ambientes restritos (embedded, sensores, wearables): padrões de design
4.1 Quando você não tem “pilha completa”
Em microcontroladores pequenos, você pode não ter memória para uma biblioteca completa, nem relógio confiável, nem armazenamento seguro robusto. O design precisa ser explícito sobre o que é possível garantir.
- Sem relógio confiável: validação de expiração de certificados e tokens pode falhar. Alternativas incluem janelas de validade baseadas em contador, ou sincronização de tempo autenticada quando conectar.
- Sem armazenamento seguro: trate o dispositivo como potencialmente extraível. Reduza privilégios do que ele pode fazer se clonado.
- Sem conectividade constante: use credenciais com validade adequada e mecanismos de reautorização quando reconectar.
4.2 Design “gateway-first”
Uma arquitetura comum é colocar um gateway mais capaz (com TLS completo, validação de certificados, rotação de credenciais) entre sensores restritos e a nuvem. Isso permite que sensores usem protocolos leves localmente, enquanto o gateway faz a ponte segura.
Pontos de atenção:
- Confiança no gateway: ele vira um ponto crítico. Proteja-o como um servidor (hardening, atualizações, chaves protegidas).
- Autenticidade do sensor no gateway: mesmo local, o gateway precisa autenticar cada sensor para evitar injeção de dados.
- Isolamento por dispositivo: um sensor comprometido não deve permitir falsificar outros.
4.3 Passo a passo: autenticação leve sensor → gateway com rotação
Cenário: sensores com MCU simples enviam leituras a um gateway local. O objetivo é evitar spoofing e replay, com baixo custo.
- Passo 1 — Identidade por sensor: cada sensor tem um identificador e um segredo único (idealmente gravado na fabricação). Evite segredo compartilhado entre sensores.
- Passo 2 — Mensagens com contador: inclua um contador monotônico (ou número de sequência) em cada mensagem. O gateway rejeita contadores repetidos ou regressivos.
- Passo 3 — Autentique payload + contador: o sensor calcula um autenticador sobre (id, contador, payload, contexto). O gateway valida e então aceita.
- Passo 4 — Janela de tolerância: para lidar com perda de pacotes, aceite uma janela de contadores futuros limitada e registre o último contador aceito.
- Passo 5 — Rotação do segredo: periodicamente (ou ao reconectar), o gateway inicia um processo de atualização do segredo do sensor, autenticado pelo segredo atual. Se um sensor for clonado, a rotação ajuda a limitar o tempo de exploração.
- Passo 6 — Quarentena e rate limit: se houver falhas repetidas, o gateway limita tentativas e marca o sensor para inspeção.
5) Checklist por caso de uso
5.1 Mobile
- Segredos no Keychain/Keystore; chaves não exportáveis quando possível.
- Cache offline criptografado com nonce único por item e metadados autenticados.
- Pinning apenas com plano de rotação e fallback controlado.
- Reduzir valor de segredos no cliente; tratar root/jailbreak como risco real.
5.2 IoT
- Identidade única por dispositivo; evitar chaves compartilhadas por produto.
- Provisionamento com bootstrap + credencial operacional; códigos de ativação de uso único.
- OTA com verificação de assinatura no dispositivo e anti-rollback.
- Telemetria de eventos de segurança e inventário de versões em campo.
5.3 Ambientes restritos
- Assumir possibilidade de extração física; limitar impacto de clonagem.
- Gateway-first quando sensores não suportam pilhas completas.
- Mensagens com contador e autenticação; tolerância a perda e replay protection.
- Rotação e recuperação planejadas para conectividade intermitente.
