14.3.4. Uma observação sobre a proteção de leitura da flash¶

Por padrão, o firmware de uma OpenMV cam enviada de fábrica é legível por qualquer pessoa com acesso físico ao dispositivo. Um atacante com a cam em mãos pode conectar uma sonda SWD ao cabeçalho de depuração, comunicar-se com a interface de depuração do MCU e fazer um dump da flash – o que inclui todos os módulos Python congelados e o conteúdo da partição ROMFS. O firmware padrão da OpenMV não habilita a proteção de leitura da flash por padrão.

Esta página documenta isso explicitamente para que uma equipe que esteja lançando um produto saiba onde está a responsabilidade.

14.3.4.1. O que a cam faz por padrão¶

O bootloader e o runtime da cam não ativam nenhum recurso de proteção de leitura do MCU subjacente. A interface de depuração permanece aberta, a flash permanece legível e o build roda da mesma forma que roda na bancada de um desenvolvedor. Esse é o padrão correto para o público deste tutorial – uma cam que sai de fábrica com a proteção de leitura ativada é uma cam que não pode ser reprogramada pelo IDE, não pode ser reimaginada após uma implantação malsucedida e não pode ser recuperada por ninguém além da equipe de build.

O compromisso muda quando a cam deixa de ser um “dispositivo de desenvolvimento” para se tornar um “produto”. Um produto cujo valor depende de o código da aplicação permanecer privado precisa habilitar a proteção por conta própria; o firmware da OpenMV não faz isso.

14.3.4.2. O que a equipe de produto faz¶

Todo fabricante de MCU oferece um mecanismo de proteção de leitura. Os detalhes diferem – fusíveis em nível de bit, transições de ciclo de vida de uso único, imagens de flash assinadas – mas o formato comum é o seguinte:

Um bit específico do fabricante (ou conjunto de bits) é gravado no silício, geralmente por meio de uma ferramenta do fabricante que se comunica com a porta de depuração do MCU uma última vez.
Após a gravação, a porta de depuração se recusa a ler a flash. A cam ainda inicializa e executa a aplicação; ela apenas deixa de expor seu conteúdo a uma sonda.
A gravação é irreversível. Não há maneira de trazer a cam de volta a um estado depurável sem destruí-la.

Configurar isso é específico de cada MCU, e os passos dependem do componente da cam que está sendo protegido. O manual de referência do fabricante é a fonte da verdade; o suporte do fabricante é o canal para acertar isso em uma linha de produção.

Essa é a parte fácil.

A parte difícil é fechar todos os outros caminhos que um atacante tem para executar código na cam ou ler o que a aplicação está fazendo. A proteção de leitura apenas impede que uma sonda de depuração faça um dump da flash. A cam ainda precisa fechar:

O REPL do MicroPython. Um REPL conectado por USB aceita Python arbitrário. A proteção de leitura não muda isso. Uma sessão de REPL pode ler a RAM, chamar funções, exfiltrar tudo o que a aplicação em execução consegue ver – na prática, um REPL acessível contorna tudo o que a proteção de leitura oferece. Desabilitar o acesso ao REPL é uma mudança de build de firmware que pertence à equipe de produto.
Upload de scripts pelo IDE. O caminho do IDE de “executar este script na cam” usa a mesma superfície do protocolo USB que o REPL usa. Fechar o REPL fecha isso junto; deixar qualquer um dos dois aberto deixa um canal de execução de código arbitrário na cam.
Sequestro do ponto de entrada a partir do sistema de arquivos. Já fechado quando a aplicação é enviada por meio de Congelando scripts no firmware – o runtime resolve os arquivos congelados boot.py e main.py antes de qualquer cópia do sistema de arquivos, então nada colocado na flash ou no cartão SD pode sobrescrevê-los. Essa proteção é gratuita assim que a aplicação está no build.
Flash externa em cams mais recentes. Cams que armazenam a imagem da aplicação em flash externa colocam essa imagem em um chip que fica à vista em cima da PCB; o chip pode ser dessoldado e lido diretamente com ferramentas de prateleira, ou lido no lugar sondando o barramento. Protegê-lo exige ativar o hardware on-chip que descriptografa o conteúdo da flash durante as leituras, gerar a chave de criptografia, provisionar essa chave na cam e gravá-la de forma irreversível no armazenamento programável uma única vez do MCU. Cada uma dessas etapas é uma operação separada de uso único, e qualquer uma delas feita errada em uma unidade de produção inutiliza essa unidade.

Cada item desta lista é sua própria pilha de trabalho de build de firmware, etapas de linha de produção e gravações irreversíveis. Um produto realmente blindado é um build de firmware customizado, um bootloader customizado, um fluxo de fabricação que provisiona chaves por unidade e um conjunto de testes que comprovam que a trava está de fato fechada antes de a unidade sair da linha. Isso é trabalho de meses, não de dias, e a irreversibilidade significa que erros custam unidades.

Por que o padrão é aberto

Esta lista também é o motivo pelo qual o firmware padrão da OpenMV sai de fábrica sem a proteção de leitura habilitada. Uma cam com o REPL fechado, o upload de scripts pelo IDE desabilitado e o firmware travado é uma cam na qual não se pode desenvolver de jeito nenhum – o fluxo de trabalho que torna as OpenMV cams utilizáveis em primeiro lugar simplesmente deixaria de existir. O padrão deixa tudo aberto; a equipe de produto escolhe quais peças fechar no caminho até uma unidade pronta para envio.

14.3.4.3. O que o acesso físico ainda permite¶

Mesmo com a proteção de leitura ativada, um atacante que esteja com a cam pode fazer bastante coisa:

Reproduzir o tráfego de rede da cam farejando suas saídas.
Observar seu comportamento visível e inferir como ela reage a entradas.
Em alguns casos, recuperar segredos por meio de ataques de injeção de falhas ou de canal lateral especializados contra o MCU protegido.

A proteção de leitura aumenta o custo de chegar até o código-fonte da aplicação. Ela não elimina esse custo. “Acesso físico = comprometimento” é a suposição de trabalho da qual uma revisão de segurança deveria partir; o mecanismo de proteção apenas decide quanto esse comprometimento custa em tempo e equipamento.

14.3.4.4. Com o que o firmware da OpenMV é entregue¶

Um resumo, para que isso fique concreto:

Nenhuma proteção de leitura habilitada por padrão.
Nenhuma flag de build no firmware padrão que a ative.
Nenhuma API em nível de aplicação para chamar a partir do MicroPython.

Um produto que precisa da proteção é entregue com firmware customizado. Essa customização reside no bootloader da placa e no fluxo de fabricação, e está fora da base de código da OpenMV. Equipes que fazem isso pela primeira vez devem planejá-lo no cronograma de desenvolvimento como uma peça de trabalho distinta, e não como algo a adicionar no final – a irreversibilidade torna “adicionar depois” caro.