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

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 não nos deixa bem na fotografia.

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 faz uma coisa só, mas fá-la bem: 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 arranjar primeiro para a fotografia, 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, pela razão simples de que um canal de atualização inseguro é mais perigoso do que não ter canal nenhum.

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 custo real não está em saber o que fazer, está em fazê-lo caber num microcontrolador e em 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. Este é dos poucos pontos em que o CRA aponta o dedo a uma má prática concreta pelo nome: nada de palavras-passe universais de fábrica. A correção passa por gerar uma palavra-passe diferente por unidade, na produção, impressa na etiqueta do aparelho. Repare-se onde isto nos leva: deixa de ser um problema de firmware e passa a ser um problema da 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, o que é mais arqueologia do que inventário. 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, não é um mau resultado. É 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.