002 · O protótipo encontra o regulamento: auditámos o nosso próprio firmware

Nota de atualização (23 out 2026). Corrigimos a passagem sobre a palavra-passe de fábrica: ao contrário do que escrevemos, o texto do CRA não menciona palavras-passe de fábrica.

Na entrada 001 escrevemos que não recomendamos aos clientes o que não fazemos connosco. Esta entrada põe isso à prova. Fizemos ao nosso próprio protótipo a análise que fazemos aos produtos dos outros, e publicamos o resultado inteiro, incluindo a parte que nos é desfavorável.

O produto, agora com nome

O que temos vindo a chamar apenas “o nosso produto agro-IoT” chama-se Aeromate. É um ecossistema de controlo ambiental para secagem e maturação: vinho, ervas aromáticas, queijo, charcutaria, charutos. O módulo mais maduro chama-se Aerodry e tem uma função única: lê temperatura e humidade, calcula o ponto de orvalho e o défice de pressão de vapor, e comanda um desumidificador dentro de uma câmara com temperatura controlada, seja ela uma adega, um frigorífico adaptado ou uma câmara de cura.

O Aerodry tem dois anos de funcionamento contínuo em ambiente real. Deteta os ciclos do compressor do frigorífico, para não confundir os picos de humidade que eles provocam com eventos reais. Avisa quando a toalha de cura seca. Corta o desumidificador se a temperatura sobe de mais. É um protótipo de que nos orgulhamos, e é por isso mesmo que serve para este exercício. A distância entre “funciona há dois anos” e “pode ser vendido na Europa em 2027” é quase exatamente a lista de requisitos do Anexo I do CRA, e vale a pena medir essa distância num caso em que a podemos contar toda.

Como fizemos a análise

Pegámos no firmware tal como está no repositório, sem o limpar primeiro, e percorremos os requisitos essenciais das duas partes do Anexo I: as propriedades de segurança do produto e o tratamento de vulnerabilidades. Para cada requisito registámos uma de três respostas: cumpre, não cumpre, ou não se aplica. Sem arredondar a nosso favor.

O que o protótipo já faz bem

Começamos pelo lado positivo, que também existe.

A capacidade de atualização está lá. O Aerodry atualiza o firmware por OTA desde o primeiro dia. O CRA exige que um produto possa receber atualizações de segurança durante todo o período de suporte, e muitos protótipos nem sequer têm o mecanismo. Nós temos. O problema, como se verá já a seguir, é a segurança desse mecanismo, mas o mecanismo existe.

As credenciais de Wi-Fi não estão no código. O primeiro arranque cria um ponto de acesso temporário onde o utilizador configura a rede de casa, e essas credenciais nunca passam pelo repositório. Foi uma boa decisão em 2024 e continua boa hoje.

Há lógica de segurança operacional a funcionar: o corte por temperatura máxima, a deteção dos ciclos do compressor, os alertas de manutenção. Não é cibersegurança, mas revela a atitude certa, porque o sistema já foi escrito a contar que as coisas correm mal.

E a superfície de ataque é pequena. Dois serviços de rede, um sensor, um relé. O CRA pede que se minimize a superfície de ataque, e aqui a simplicidade do protótipo trabalha a favor sem esforço nenhum.

O que falha, e porque ia sempre falhar

Descrevemos aqui as nove falhas com consequência direta para quem usa o produto. Estas são as quatro mais graves.

A atualização OTA aceita firmware de qualquer origem. O endereço de atualização está em HTTP simples, na porta 80, sem autenticação e sem verificação de assinatura. Qualquer aparelho na mesma rede pode substituir o firmware inteiro. Numa rede nossa, de laboratório, isto é uma comodidade. Em casa de um cliente passa a ser a vulnerabilidade mais séria do produto, porque o mecanismo que devia servir para corrigir problemas torna-se a porta de entrada. É o primeiro item do plano de trabalho, porque é por esse canal que as outras correções de firmware vão chegar ao aparelho.

Toda a comunicação viaja em claro. As leituras, o estado do relé e os registos saem por HTTP sem cifra, com os próprios dados metidos no endereço, para um servidor que não pede autenticação. O CRA exige que os dados em trânsito estejam protegidos na confidencialidade e na integridade. A correção técnica é bem conhecida, com TLS e autenticação mútua no MQTT. O difícil é fazê-la caber num microcontrolador e gerir os certificados ao longo de cinco anos de suporte. Vai ser o tema de uma entrada técnica própria.

A palavra-passe de fábrica é a mesma em todos os aparelhos. O ponto de acesso de configuração usa uma palavra-passe fixa, fraca e igual em todas as unidades, e ainda por cima está publicada no README. O texto do CRA não fala de palavras-passe de fábrica, mas uma palavra-passe assim dificilmente se defende perante o Anexo I, Parte I, ponto 2, alíneas b) (configuração segura por definição) e d) (proteção contra acessos não autorizados). Quem trata expressamente das palavras-passe de fábrica é a EN 18031, norma harmonizada ao abrigo da diretiva de equipamentos de rádio (RED); os requisitos de cibersegurança da RED já se aplicam a um aparelho com Wi-Fi ligado à internet que seja colocado no mercado (ver o artigo 05). A correção passa por gerar uma palavra-passe diferente por unidade, na produção, impressa na etiqueta do aparelho. Isto leva o problema para a linha de montagem. Foi a descoberta mais útil de toda a auditoria, e voltamos a ela no fim.

Havia um segredo de integração no repositório público. O identificador de um aparelho numa integração com uma plataforma na nuvem estava escrito no código, num repositório aberto. Já foi revogado. Fica registado aqui porque é o erro mais comum que encontramos no firmware dos outros, e connosco não foi diferente.

Os outros cinco, em resumo. Não há SBOM, o inventário de componentes: as dependências estão copiadas para dentro do repositório com versões congeladas em datas diferentes. Não há verificação de integridade no arranque. Não há registo de eventos de segurança nem deteção de acessos indevidos. Não há forma de apagar os dados no fim de vida, e este ponto é menos abstrato do que parece, porque o aparelho guarda a palavra-passe de Wi-Fi da casa em memória sem cifra: um Aerodry revendido em segunda mão leva a rede do dono anterior consigo. E falta ainda estender ao produto a política de divulgação de vulnerabilidades, que no site já tem um embrião mas ainda não tem chave PGP nem canal próprio.

A conclusão que interessa

Nove falhas com consequência direta, num quadro de vinte e um requisitos aplicáveis, são o resultado normal de qualquer protótipo, incluindo os bons, incluindo os que já funcionam há dois anos. Nenhuma destas falhas veio de desleixo. Vieram de prioridades que estavam certas para a fase de protótipo e deixam de estar quando o objetivo passa a ser entregar o aparelho a desconhecidos. Um protótipo serve para provar que o controlo de humidade funciona. Um produto tem de aguentar estar na casa de alguém que não o construiu.

O CRA é, no fundo, a lista de trabalho entre uma coisa e a outra. E o exercício revelou uma coisa que só se vê fazendo-o: cerca de metade das correções não é software. É processo de fabrico, como a palavra-passe por unidade. É infraestrutura, como a autoridade de chaves que assina o firmware e tem de se manter de pé cinco anos. É documentação, como a SBOM e o processo técnico. E é organização, como o canal de divulgação e a equipa que responde. Por isso é que deixar a conformidade para a véspera da marcação CE sai caro: a essa altura o custo já está todo desenhado para dentro do produto, e mexer nele já implica reabrir tudo.

A entrada 003 pega nesta auditoria e transforma-a num plano, com a sequência do protótipo até ao produto e uma ideia do que cada fase custa. Se alguma decisão do plano se revelar errada pelo caminho, fica aqui registada, como combinámos.

---

A análise completa, requisito a requisito, está no anexo a esta entrada. É o mesmo formato de relatório que entregamos a fabricantes.