Agenda - Embedded security

Informações gerais

Agenda detalhada

Dia 1

Apresentação: Introdução sobre o treinamento, agenda e pré-requisitos, apresentação do instrutor, material de estudos e instruções gerais.

Laboratório: Neste exercício, iremos validar o ambiente do treinamento, baseado em uma imagem de distribuição Linux gerada com o Yocto Project e executada em um ambiente emulado com QEMU. Aprenderemos a inicializar o ambiente de build, gerar a imagem do sistema com BitBake e fazer boot no emulador, explorando o sistema em execução e entendendo como limpar e reconstruir a imagem quando necessário. Iremos também utilizar o SDK gerado pelo Yocto em um terminal separado para compilar uma aplicação simples, instalar no target via SSH/SCP e confirmar o fluxo completo de build, boot e deploy.

Apresentação: Introdução aos conceitos de segurança: esta seção contextualiza por que segurança se tornou um requisito central em dispositivos embarcados, especialmente em cenários conectados e críticos, e como normas e regulações recentes (como o Cyber Resilience Act) reforçam a necessidade de security-by-design. O módulo define o “vocabulário” fundamental de segurança - proprietários, ativos, ameaças, agentes, vulnerabilidades e vetores de ataque - e estabelece que segurança é essencialmente gestão de riscos, equilibrando valor do ativo, impacto e custo de proteção. Em seguida, apresenta os objetivos clássicos (confidencialidade, integridade, autenticidade, disponibilidade, privacidade e não repúdio) com exemplos práticos de riscos e mitigações, além de descrever a anatomia típica de um ataque (reconhecimento, varredura, exploração, manutenção de acesso e cobertura de rastros) e os ataques mais comuns em software (injeção, RCE, MITM, DoS, escalada de privilégios, força bruta) e hardware (side-channel, fault injection, bus snooping/injection e tampering). Por fim, introduz o processo de defesa baseado em threat modeling e princípios básicos (defesa em camadas, negar por padrão, menor privilégio, segmentação), detalhando o fluxo de identificação de ativos, classificação/priorização de riscos e definição de mitigações, com uso de frameworks como STRIDE e DREAD e complementação com o catálogo MITRE EMB3D™ voltado a embarcados. A seção fecha conectando threat modeling a compliance, mostrando como padrões e regulações podem alterar o que é risco aceitável e impor controles como atualização segura, gestão de vulnerabilidades, RBAC, SBOM, etc.

Laboratório: Neste exercício, iremos criar um modelo de ameaças de um monitor multiparamétrico conectado (UTI e homecare) usando o MITRE EMB3D™. Iremos identificar ativos e vetores de ataque, selecionar propriedades aplicáveis no Properties Mapper, gerar um relatório CSV como lista de ameaças candidatas e analisar os TIDs relevantes. Ao final, vamos priorizar cinco ameaças com justificativas (impacto operacional, vazamento de dados, integridade e disponibilidade) e propor mitigações, separando o “mínimo viável de segurança” de itens para evolução em roadmap.

Apresentação: Codificação segura I - Explorando vulnerabilidades: nesta seção, os participantes entendem por que falhas de software estão na raiz de incidentes reais e quais são seus impactos (vazamento de dados, execução remota de código e indisponibilidade). Em seguida, analisam as classes mais comuns de vulnerabilidades em sistemas embarcados e aplicações modernas, com foco em erros de memória (buffer overflow, use-after-free, double free, race conditions, format string e integer overflow) e falhas de injeção (command, SQL/NoSQL, XSS e path traversal), discutindo como elas surgem e como são exploradas. O módulo também apresenta o fluxo prático de descoberta e validação de vulnerabilidades: mapeamento da superfície de ataque, identificação de entradas e uso de ferramentas de análise estática (cppcheck, clang-tidy, semgrep, Coverity), instrumentação em tempo de execução com sanitizers (ASan/UBSan/TSan) e análise dinâmica com fuzzing (AFL++/libFuzzer) e Valgrind. Por fim, introduz conceitos essenciais de engenharia reversa e depuração (binwalk, GDB e Ghidra) e demonstra, em exemplos controlados, como vulnerabilidades podem levar a elevação de privilégios e RCE, preparando o terreno para o próximo tópico, que cobre as técnicas de mitigação e hardening.

Laboratório: Neste exercício, vamos explorar vulnerabilidades de software por análise e exploração prática. Primeiro, estudaremos o Heartbleed (CVE-2014-0160) para entender tipo de falha, impacto, por que foi severa, onde estava no código e quais práticas poderiam ter evitado o problema. Depois, analisaremos um servidor TCP em C com falha no tratamento de entrada que permite desviar o fluxo de execução e acionar uma função “secreta”, utilizando ferramentas como GDB. Por fim, vamos investigar um CGI vulnerável a command injection em uma página de diagnóstico de rede, criando requisições legítimas e maliciosas e discutindo possíveis mitigações.

Apresentação: Codificação segura II - Técnicas de mitigação: nesta seção, os participantes aprendem como reduzir drasticamente a probabilidade de vulnerabilidades e limitar seu impacto por meio de uma abordagem em camadas que combina escolhas de projeto, validação contínua e hardening. O módulo discute como a seleção de linguagem e disciplina de engenharia influenciam a segurança, contrastando C/C++ (alto risco de bugs de memória) com alternativas “memory-safe” como Rust (ownership, borrowing e lifetimes), além do papel de padrões de codificação e revisão de código para restringir construções perigosas e aumentar a robustez. Em seguida, o foco passa para medidas práticas no toolchain e processo de desenvolvimento: uso de padrões como MISRA C e CERT C, e aplicação de análise estática (Clang-Tidy, splint, Flawfinder, Coverity/LDRA) para detectar falhas recorrentes ainda na fase de desenvolvimento. O módulo cobre também hardening de build e do binário, incluindo FORTIFY, proteção contra stack smashing (stack canaries/SSP), memória não executável (NX/noexecstack), RELRO, Pointer Authentication (PAC) em ARM e ASLR com PIE, mostrando como cada mecanismo eleva o custo de exploração e reduz a confiabilidade de exploits. Por fim, são apresentados mecanismos de detecção e validação em tempo de execução e testes: sanitizers (ASan/UBSan/TSan/MSan/LeakSanitizer), ferramentas como Electric Fence e Valgrind, e fuzzing automatizado. A seção fecha com práticas recomendadas para sistemas embarcados, incluindo redução de superfície de ataque, validação sistemática de entradas, automação em CI para aplicar hardening e testes continuamente, além de uma visão de hardening em kernel space (KSPP), usando ferramentas como checksec e kernel-hardening-checker para auditar se as mitigações estão efetivamente habilitadas.

Laboratório: Neste exercício, iremos mitigar vulnerabilidades através de diferentes técnicas de hardening. Iremos usar o flawfinder para identificar problemas clássicos em um programa C (uso de funções inseguras, estou de buffer, etc) e refatorar o código, mantendo seu comportamento original. Em seguida, vamos trabalhar no hardening via flags de compilação: iremos usar o checksec para identificar e ajustar as flags e habilitar o AddressSanitizer para capturar acessos inválidos à memória. Por fim, avaliaremos o hardening do kernel em runtime com a ferramenta kernel-hardening-checker, analisando os problemas reportados e fazendo os ajustes necessários para melhorar a segurança do kernel.

Dia 2

Apresentação: Introdução à criptografia: esta seção apresenta a criptografia como a base técnica para confidencialidade, integridade, autenticidade e não repúdio, contextualizando sua evolução histórica e sua relevância prática na proteção de dados e comunicações em sistemas embarcados. Os participantes entendem como cifras transformam plaintext em ciphertext por meio de algoritmos e chaves, e por que o gerenciamento correto dessas chaves é tão crítico quanto a escolha do algoritmo. O módulo compara criptografia simétrica e assimétrica, destacando seus trade-offs de desempenho e casos de uso típicos. Em simétrica, cobre cifras de bloco e de fluxo, com foco em AES e ChaCha20, explicando modos de operação (ECB, CBC, CTR, GCM) e recomendações de uso, incluindo boas práticas com IV/nonce, escolha de tamanhos de chave e preferência por esquemas autenticados (AEAD), além do papel de aceleração criptográfica em hardware e bibliotecas consolidadas. Em assimétrica, a seção discute RSA e ECC, mostrando por que algoritmos de chave pública são usados principalmente para troca/proteção de segredos e assinaturas digitais, e não para cifrar grandes volumes de dados. São introduzidos conceitos de criptografia híbrida (ex.: RSA/ECDH para proteger a chave e AES para os dados) e exemplos práticos com OpenSSL, conectando o tema a cenários reais como TLS, SSH, atualização segura e proteção de firmware. Por fim, o conteúdo cobre primitivas essenciais de integridade e confiança: funções de hash, HMAC para autenticação simétrica, assinaturas digitais (RSA-PSS, Ed25519) e o papel de certificados X.509 e PKI para vincular chaves públicas a identidades. A seção fecha com fundamentos de gerenciamento de chaves (geração com RNG seguro, armazenamento em HSM/TPM/TEE/KMS, rotação e revogação), uma visão introdutória de criptografia pós-quântica e um panorama das principais entidades e padrões (NIST/FIPS, IETF e ISO/IEC) que orientam escolhas e compliance.

Laboratório: Neste exercício, iremos consolidar os conceitos de criptografia na prática. Vamos quebrar uma cifra de César por força bruta implementando um script/programa que teste todas as chaves, permitindo identificar a chave e o plaintext. Depois, vamos simular uma troca de mensagens com confidencialidade em uma aplicação de telemetria: vamos gerar a chave simétrica e IV no host, provisionar esses segredos no target, cifrar dados no target com AES-CBC e transferir o ciphertext de volta para o host para decifrar e validar o resultado. Por fim, iremos adicionar integridade e autenticidade com assinatura digital: vamos gerar um par de chaves no target, exportar a chave pública para o host, assinar o arquivo cifrado e demonstrar que qualquer alteração no ciphertext invalida a verificação.

Apresentação: Encriptação de dados: esta seção discute como a encriptação atende ao requisito de confidencialidade em dispositivos embarcados, com foco em data-at-rest (código e dados persistentes, como configurações, logs e bancos). São apresentados os principais motivadores - proteção de IP e antifalsificação, privacidade, mitigação de roubo/perda e atendimento a normas - e os custos envolvidos, como impacto em desempenho/energia, maior complexidade no boot e o risco operacional de perda de dados caso a chave seja perdida. Em seguida, comparamos as abordagens de criptografia no Linux: por bloco e por arquivo. Para criptografia por bloco, cobrimos o dm-crypt (via cryptsetup) como solução padrão, incluindo os modos plain e o uso recomendado de LUKS2, com seus metadados, keyslots e boas práticas de gerenciamento (por exemplo, backup do cabeçalho). Para criptografia por arquivo, apresentamos opções como ferramentas de encriptação direta (GnuPG/OpenSSL), soluções baseadas em FUSE (gocryptfs/CryFS) e o fscrypt como infraestrutura nativa do kernel para criptografia por diretório em ext4/F2FS/UBIFS. O módulo também enfatiza o gerenciamento seguro de chaves em sistemas autônomos: por que passphrases e arquivos são insuficientes, e como usar suporte de hardware e do kernel para proteger segredos. São introduzidos mecanismos como wrapping com CAAM (i.MX), TEEs (ex. OP-TEE) e hardware externo (Secure Element/TPM). Complementamos com o Kernel Key Retention Service e os tipos trusted/encrypted keys, além de ferramentas de integração no sistema (systemd-cryptsetup/cryptenroll, Clevis) e uma visão de como medir o impacto de performance (fio, ioping, hdparm, cryptsetup benchmark).

Laboratório: Neste exercício, vamos explorar a proteção de dados em repouso em sistemas baseados no kernel Linux. Iremos criar uma partição de dados encriptada com LUKS2, montar após fornecer passphrase, gravar dados e depois desmontar/fechar o volume para observar que o conteúdo bruto não é legível e não pode ser montado como ext4 diretamente. Em seguida, implementaremos um plano de recuperação, fazendo backup do cabeçalho LUKS e simulando corrupção e recuperação dos dados. Por fim, iremos construir um “cofre” com fscrypt utilizando uma chave aleatória protegida por TPM via wrapping/unwrapping, demonstrando que, sem recuperar a chave via TPM, o diretório permanecerá inacessível mesmo com acesso ao armazenamento.

Apresentação: Boot seguro (Secure Boot): esta seção apresenta boot seguro como o mecanismo fundamental para garantir a integridade do software durante a inicialização, prevenindo a execução de firmware não autorizado e reduzindo a superfície de ataque (incluindo mitigação de adulteração e rollback), além de habilitar um processo confiável de atualização remota. O módulo diferencia verified boot e measured boot, explicando como medições (hashes) podem ser registradas em registradores protegidos, como PCRs de um TPM, para auditoria local e atestação remota. Em seguida, consolida os conceitos de chain-of-trust e root-of-trust, mostrando como cada estágio (ROM → bootloader → kernel → rootfs) valida criptograficamente o próximo por meio de assinaturas digitais, e como o ponto de ancoragem depende fortemente do hardware e do fluxo de boot da plataforma. O conteúdo explora implementações reais de root-of-trust em arquiteturas distintas. Em x86, cobre a cadeia baseada em UEFI (PK/KEK/db/dbx), incluindo o papel de OEMs e da Microsoft na distribuição e revogação de confiança. Em ARM, detalha o modelo da NXP i.MX, comparando HAB (i.MX5/6/7/8M) e AHAB (i.MX8/8X/8ULP/9). Na sequência, a seção aborda a validação de componentes do boot do Linux com FIT images no U-Boot, explicando como o formato FIT empacota kernel, device tree, initramfs e metadados (hashes/assinaturas) e como o processo de assinatura e verificação é integrado ao bootloader e automatizado em pipelines (por exemplo, via classes do Yocto). Para fechar a cadeia de confiança, são apresentados mecanismos de integridade/autenticidade para o rootfs e para arquivos, incluindo dm-verity, fs-verity, dm-integrity e IMA/EVM. Por fim, cobrimos kernel module signing como medida para impedir carregamento de módulos não autorizados em espaço de kernel, incluindo o fluxo de assinatura no build, validação em tempo de carga e uso de keyrings do kernel. A seção encerra com boas práticas de gerenciamento de chaves para boot seguro, incluindo a hierarquia de chaves (raiz/intermediárias/operacionais), separação entre ambientes de desenvolvimento e produção e proteção de chaves privadas (HSM/smartcard/ambiente isolado).

Laboratório: Neste exercício, exploraremos a verificação de integridade e autenticidade de software no Linux. Primeiro, iremos compilar e executar uma imagem com boot seguro, identificando nos logs as checagens de assinatura e validando a implementação de chain-of-trust. Depois, simularemos uma adulteração offline da imagem, editando manualmente o arquivo do rootfs e observando a falha de boot causada pela verificação do dm-verity. Por fim, iremos proteger um binário crítico com fs-verity, assinando o arquivo executável e garantindo que o kernel só irá executar o programa se a assinatura estiver correta.

Dia 3

Apresentação: Controle de acesso: esta seção apresenta como aplicar o princípio do menor privilégio em sistemas embarcados, reduzindo o uso de root e minimizando a superfície de ataque. O módulo diferencia autenticação de autorização e descreve o fluxo típico de login no Linux, cobrindo bases de usuários/senhas, NSS e o uso do PAM para políticas flexíveis (MFA, lockout, qualidade de senha, restrições por horário e limites de sessão), com exemplos práticos em SSH. Na parte de autorização, o conteúdo detalha o modelo clássico DAC (permissões rwx, semântica em arquivos/diretórios, bits especiais setuid/setgid/sticky), além de umask e opções de montagem (nosuid, noexec, nodev, ro) como controles adicionais. Em seguida, aborda extensões do DAC, incluindo ACLs (permissões por múltiplos usuários/grupos via xattrs) e o papel do root, discutindo riscos e alternativas como sudo e redução de privilégios em daemons. O módulo introduz Linux capabilities como forma de “fatiar” privilégios de root e conceder apenas o necessário (por processo ou por binário). Para limitações mais profundas do DAC, apresenta o modelo MAC via LSM, com foco em SELinux: conceitos de sujeitos/objetos/operações, security contexts, type enforcement, modos (enforcing/permissive), integração no Yocto e ferramentas de diagnóstico/gestão (sestatus, sesearch, audit2why/audit2allow, semodule), incluindo análise de AVCs e criação de módulos de política. Por fim, a seção cobre auditoria com auditd (regras, coleta e relatórios com auditctl/aureport) e a integração com MAC, além de ferramentas de varredura e hardening como Lynis e OpenSCAP para uso em desenvolvimento/CI. O tópico fecha com recomendações práticas para autenticação segura, redução de privilégios, configuração correta de permissões e monitoramento contínuo em produção.

Laboratório: Neste exercício, aprenderemos a aplicar controle de acesso e permissões em sistemas baseados no kernel Linux. Vamos definir uma política de senha forte via PAM e testar a rejeição de senhas fracas. Depois, iremos estudar o problema de serviços que precisam fazer bind em portas privilegiadas, comparando a execução como root, setuid, capabilities e o modelo “start as root, drop privileges”, e avaliando o impacto e a aderência ao princípio de menor privilégio. Por fim, iremos depurar falhas de inicialização do lighttpd causadas pelo SELinux, interpretando os logs e fazendo os ajustes necessários para garantir o funcionamento do serviço sem desabilitar o MAC.

Apresentação: Isolamento de aplicações: esta seção introduz o sandboxing como uma estratégia para executar aplicações em um ambiente restrito, reduzindo a superfície de ataque de código não confiável (terceiros) e serviços expostos (por exemplo, servidores web). O módulo também ressalta limitações importantes: sandboxing não corrige falhas lógicas da aplicação e pode ser contornado por vulnerabilidades no kernel ou em ferramentas de isolamento, sendo portanto mais uma camada de mitigação, e não um substituto para outras práticas de segurança. O conteúdo apresenta o espectro de mecanismos de isolamento, desde abordagens mais “pesadas” (VMs e hypervisors, com kernel próprio) até alternativas mais leves baseadas em recursos do próprio Linux. Em seguida, aprofunda as principais tecnologias do kernel usadas por containers e ferramentas de sandbox: chroot, namespaces, seccomp, capabilities e cgroups. A seção também discute ferramentas práticas que combinam esses mecanismos para isolar aplicações. Como ferramentas de sandbox, são apresentadas a Firejail, Bubblewrap e o sandboxing nativo do systemd. O módulo também explica o conceito de containers como empacotamento e execução de ambientes isolados compartilhando o mesmo kernel, introduzindo o ecossistema do Docker, cobrindo fluxo de imagens (Dockerfile e registries), o papel do dockerd, containerd e runc na configuração de namespaces/cgroups/seccomp, e exemplos básicos de execução e inspeção de containers. O tópico fecha reforçando quando usar sandboxing, como combinar camadas de isolamento e quais trade-offs considerar em sistemas embarcados.

Laboratório: Neste exercício, exploraremos sandboxing como técnica para reduzir a superfície de ataque e isolar a execução de serviços no Linux. Iremos executar um gateway de plugins (proto-runner), criando manualmente um isolamento com namespaces, chroot e seccomp, limitando a visibilidade e os privilégios do programa. Em seguida, repetiremos o isolamento usando Bubblewrap para padronizar a criação do sandbox com menor complexidade operacional. Por fim, iremos confinar um painel web de manutenção usando o Docker, executando o servidor web (nginx) em um container, com o objetivo de minimizar privilégios e recursos expostos ao processo.

Apresentação: Trusted Execution Environment: neste módulo, introduzimos o conceito de Trusted Execution Environment (TEE) como uma forma de reduzir riscos ao executar código e manipular dados sensíveis em um ambiente isolado por hardware, mesmo quando o Linux (REE/Normal World) pode ser comprometido. Discutimos os principais casos de uso, como armazenamento seguro e gerenciamento de chaves com base em HUK, além da execução de operações críticas (criptografia, autenticação, DRM) dentro do Secure World. Em seguida, cobrimos as tecnologias de enclave usadas para viabilizar TEEs, com foco no ARM TrustZone: modos de execução no ARMv8, separação Normal World vs Secure World e a transição via SMC, incluindo o papel do secure monitor (por exemplo, TF-A/BL31) no encaminhamento de chamadas entre os dois mundos. A parte prática do módulo explora o OP-TEE: visão geral do projeto e padrões da GlobalPlatform, seus componentes (OP-TEE OS, driver no kernel e subsistema TEE, libteec, tee-supplicant e Trusted Applications), requisitos de configuração no kernel/device tree e o processo de boot e inicialização do Secure World. Por fim, detalhamos armazenamento seguro no OP-TEE (REE FS e RPMB, com trade-offs como portabilidade vs proteção contra replay), o modelo de gerenciamento/derivação de chaves (SSK/TSK/FEK), ferramentas de validação (xtest e exemplos), e encerramos com o threat model típico de TEE, limitações e classes de vulnerabilidades conhecidas em implementações reais.

Laboratório: Neste exercício, utilizaremos o OP-TEE para proteger segredos e isolar a execução de uma aplicação. Começaremos verificando se o OP-TEE está ativo, executando a ferramenta xtest e observando como uma aplicação cliente interage com o OP-TEE via libteec usando as ferramentas strace e ltrace. Depois, vamos explorar o armazenamento seguro com o backend REE FS: iremos executar uma aplicação de exemplo, inspecionar o diretório de armazenamento do OP-TEE (/var/lib/tee), verificar que os blobs não revelam conteúdo em claro, e testar corrupção do blob para observar falhas e garantias de integridade/confidencialidade. Por fim, iremos trabalhar numa TA de “cofre de PIN”, resisando e ajustando a lógica da aplicação, e testando seu funcionamento no target.

Dia 4

Apresentação: Segurança em redes: neste módulo, cobrimos os fundamentos de segurança em redes aplicados a sistemas embarcados, com foco em proteger dados em trânsito garantindo confidencialidade, integridade e autenticidade, e discutindo desafios típicos do cenário embarcado (recursos limitados, longa vida útil e exposição a redes hostis). Apresentamos as principais superfícies de ataque e tipos de ataques em redes TCP/IP, incluindo sniffing, spoofing, man-in-the-middle, denial of service, replay, brute force e exploração remota, relacionando cada ameaça às estratégias de mitigação (redução de superfície de ataque, autenticação forte, criptografia e hardening de serviços). Estudamos como aplicar criptografia em diferentes camadas da pilha TCP/IP, destacando VPNs (IPsec, OpenVPN e WireGuard) e o uso de TLS/DTLS para proteção em nível de aplicação, incluindo autenticação mútua (mTLS) para cenários em que o servidor também precisa validar o dispositivo. Por fim, abordamos controles e ferramentas operacionais: firewall no Linux via Netfilter (nftables/iptables e front-ends como firewalld/ufw), boas práticas de hardening de SSH (incluindo port forwarding), além de detecção e resposta com IDS/IPS (Snort/Suricata) e ferramentas de scan e avaliação (nmap/masscan e scanners de vulnerabilidade), fechando com um checklist mínimo de segurança para comunicação em produção.

Laboratório: Neste exercício, exploraremos mecanismos de proteção de comunicação em rede. Primeiro, iremos demonstrar que HTTP puro expõe credenciais em claro, capturando o tráfego com tcpdump/wireshark e mitigando o problema com o recurso de port forwarding do SSH. Depois, configuraremos uma VPN com WireGuard, validando a conectividade do host com o target, e testando o acesso ao servidor web pela VPN. Por fim, iremos configurar um firewall com política padrão de bloqueio, liberando apenas o tráfego HTTP pela interface de VPN.

Apresentação: Mecanismos de atualização: neste módulo, discutimos por que mecanismos de atualização são um requisito de segurança em sistemas embarcados, já que vulnerabilidades e falhas são inevitáveis ao longo do ciclo de vida do produto. Também conectamos o tema a exigências regulatórias recentes, como a Cyber Resilience Act (CRA), que reforça a obrigação de tratar vulnerabilidades continuamente. Apresentamos os principais requisitos funcionais de um sistema de update, incluindo atualização remota e local, robustez contra falhas (atomicidade, tolerância a quedas de energia, rollback), gestão de versões e observabilidade (status, progresso e logs). Em seguida, comparamos modelos comuns de atualização (imagem A/B, aplicação/containers, pacotes e arquivos) e os trade-offs de confiabilidade, consumo de banda, complexidade e capacidade de recuperação. Do ponto de vista de segurança, cobrimos proteção do artefato de atualização com criptografia e, principalmente, assinatura digital para integridade e autenticidade, além de mecanismos de anti-rollback para impedir downgrade para versões vulneráveis. Também destacamos hardening dos serviços de update e a importância de um bom gerenciamento de chaves e processos de revogação/rotação. Por fim, apresentamos frameworks open source para Linux embarcado (RAUC, SWUpdate, Mender e integrações como hawkBit), com foco no RAUC: bundles assinados, slots A/B, integração com Yocto Project/Buildroot e uma abordagem de PKI para gestão de chaves. Encerramos com o processo de gerenciamento de CVEs ao longo do ciclo de vida do produto, incluindo verificação no build (classe cve-check do Yocto Project) e uso de SBOMs para monitoramento contínuo.

Laboratório: Neste exercício, estudaremos práticas de atualização de firmware e gestão de vulnerabilidades de software. Primeiro, iremos tratar um cenário de correção emergencial em produção, explorando todo o processo de atualização do sistema operacional para corrigir um bug crítico, utilizando o RAUC como ferramenta de update. Em seguida, vamos habilitar a verificação de CVE no Yocto e analisar o relatório gerado, se aprofundamento no CVE-2025-59375: iremos identificar componente e versão, classificar a natureza do problema, avaliar o impacto, buscar evidências no site do NIST e propor uma estratégia de correção (upgrade, backport ou mitigação).

Apresentação: Hardware security: Neste módulo, abordamos como o modelo de ameaça muda quando o atacante tem acesso físico ao dispositivo, tornando insuficientes várias defesas que funcionam bem contra ataques remotos. Discutimos riscos típicos de campo, como abertura do equipamento, acesso a interfaces de debug, extração do armazenamento para análise offline, inspeção de barramentos internos e injeção de falhas elétricas para desviar o fluxo de execução. Em seguida, mapeamos os principais vetores de ataque físicos: acesso a jumpers e conectores de serviço, exploração de UART como console serial, uso de JTAG/SWD para depuração com acesso amplo à CPU e memória, e comprometimento de memórias não-voláteis (eMMC/NAND/SD) tanto por leitura externa quanto por sniffing do barramento. Também cobrimos ataques por mídia/periféricos maliciosos (boot por USB/SD) e o risco de replay/injeção em barramentos de comunicação. O módulo apresenta estratégias de mitigação em camadas, com ênfase em anti-tamper (resistência, detecção e resposta), encapsulamento e blindagens, redução de superfícies expostas em produção e uso de recursos do SoC para restringir ou desabilitar debug (incluindo JTAG autenticado). Complementamos com medidas de integridade e confidencialidade: secure boot e cadeia de confiança, criptografia e autenticação de dados em repouso, e uso de raízes de confiança (TPM, secure element, TEE) para proteger chaves. Por fim, exploramos ataques mais sofisticados, como side-channel (tempo, consumo de energia, emissões eletromagnéticas) e fault injection (glitches de tensão/clock, EMFI, etc), ilustrando como eles podem levar a bypass de verificações críticas e extração de segredos. Encerramos com contramedidas práticas em hardware e software, incluindo técnicas de execução constante, randomização, supervisão de alimentação/clock, redundância de checagens e estratégias de detecção e resposta a anomalias.

Apresentação: Encerramento: concluímos o treinamento reforçando os princípios de defesa em profundidade e security-by-design, conectando-os aos tópicos vistos ao longo do curso. Em seguida, abrimos espaço para dúvidas e comentários finais e discutimos próximos passos para continuar se aprofundando no assunto.