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

Por predefinição, o firmware de uma OpenMV cam enviada é legível por qualquer pessoa com acesso físico ao dispositivo. Um atacante que tenha a câmara em mãos pode ligar uma sonda SWD ao conector de depuração, comunicar com a interface de depuração do MCU e fazer 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 ativa a proteção de leitura da flash por predefinição.

Esta página documenta isso explicitamente para que uma equipa a enviar um produto saiba onde recai a responsabilidade.

14.3.4.1. O que a câmara faz por predefinição¶

O bootloader e o runtime da câmara não ativam qualquer funcionalidade de proteção de leitura do MCU subjacente. A interface de depuração permanece aberta, a flash permanece legível e a compilação corre tal como num banco de desenvolvimento. Esse é o padrão correto para o público dos tutoriais – uma câmara que seja enviada com a proteção de leitura ativada é uma câmara que não pode ser reprogramada através do IDE, não pode ser restaurada após uma implementação falhada, e não pode ser recuperada por ninguém além da equipa de compilação.

O compromisso muda quando a câmara passa de «dispositivo de desenvolvimento» para «produto». Um produto cujo valor depende do código da aplicação permanecer privado tem de ativar a proteção por si próprio; o firmware da OpenMV não o faz.

14.3.4.2. O que a equipa de produto faz¶

Todos os fornecedores de MCU oferecem um mecanismo de proteção de leitura. Os detalhes diferem – fusíveis ao nível de bits, transições de ciclo de vida de uso único, imagens de flash assinadas – mas a forma comum é:

Um bit específico do fornecedor (ou conjunto de bits) é gravado no silício, normalmente através de uma ferramenta do fornecedor que comunica com a porta de depuração do MCU pela última vez.
Após a gravação, a porta de depuração recusa a leitura da flash. A câmara ainda arranca e executa a aplicação; simplesmente deixa de expor o seu conteúdo a uma sonda.
A gravação é irreversível. Não há forma de colocar a câmara novamente num estado depurável sem a destruir.

A configuração deste processo é específica de cada MCU, e os passos dependem do componente da câmara a ser protegida. O manual de referência do fornecedor é a fonte de verdade; o suporte do fornecedor é o canal para acertar numa linha de produção.

Esta é a parte fácil.

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

O REPL do MicroPython. Um REPL ligado por USB aceita Python arbitrário. A proteção de leitura não altera isso. Uma sessão 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. Desativar o acesso ao REPL é uma alteração de compilação de firmware da responsabilidade da equipa de produto.
Carregamento de scripts pelo IDE. O caminho «executar este script na câmara» do IDE utiliza a mesma superfície de protocolo USB que o REPL. Fechar o REPL fecha isto também; deixar qualquer um dos dois aberto deixa um canal de execução arbitrária de código na câmara.
Sequestro do ponto de entrada a partir do sistema de ficheiros. Já fechado quando a aplicação é enviada através de Incorporar scripts no firmware – o runtime resolve os ficheiros boot.py e main.py congelados antes de qualquer cópia do sistema de ficheiros, pelo que nada colocado na flash ou no SD os pode substituir. Esta proteção é gratuita assim que a aplicação está na compilação.
Flash externa em câmaras mais recentes. Câmaras que armazenam a imagem da aplicação em flash externa colocam essa imagem num chip visível na PCB; o chip pode ser dessoldado e lido diretamente com ferramentas de prateleira, ou lido no local através de sondagem do barramento. Protegê-lo requer ativar o hardware integrado que desencripta o conteúdo da flash durante as leituras, gerar a chave de encriptação, provisionar essa chave na câmara e gravá-la irreversivelmente no armazenamento de programação única do MCU. Cada uma dessas operações é uma operação de uso único separada, e qualquer uma executada incorretamente numa unidade de produção inutiliza-a.

Cada item desta lista é a sua própria pilha de trabalho de compilação de firmware, passos na linha de produção e gravações irreversíveis. Um produto verdadeiramente bloqueado é uma compilação de firmware personalizada, um bootloader personalizado, um fluxo de produção que provisiona chaves por unidade e um conjunto de testes que provam que o bloqueio está realmente fechado antes de a unidade sair da linha. Isso representa meses de trabalho, não dias, e a irreversibilidade significa que os erros têm custos em unidades.

Por que a predefinição é aberta

Esta lista também explica por que o firmware padrão da OpenMV é enviado sem a proteção de leitura ativada. Uma câmara com o REPL fechado, o carregamento de scripts pelo IDE desativado e o firmware bloqueado é uma câmara em que não se pode desenvolver de todo – o fluxo de trabalho que torna as câmaras OpenMV utilizáveis desapareceria. A predefinição deixa tudo aberto; a equipa de produto escolhe que partes fechar no caminho para uma unidade enviada.

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

Mesmo com a proteção de leitura ativada, um atacante que segura a câmara pode fazer bastante:

Reproduzir o tráfego de rede da câmara por sniffing das suas saídas.
Observar o seu comportamento visível e inferir como reage às entradas.
Em alguns casos, recuperar segredos através 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 aceder ao código-fonte da aplicação. Não elimina esse custo. «Acesso físico = comprometimento» é o pressuposto de trabalho com que uma revisão de segurança deve começar; o mecanismo de proteção apenas decide quanto esse comprometimento custa em tempo e equipamento.

14.3.4.4. O que o firmware da OpenMV inclui por predefinição¶

Um resumo, para que seja concreto:

Nenhuma proteção de leitura ativada por predefinição.
Nenhum indicador de compilação no firmware padrão que a ative.
Nenhuma API ao nível da aplicação para chamar a partir do MicroPython.

Um produto que necessita de proteção é enviado com firmware personalizado. Essa personalização reside no bootloader da placa e no fluxo de produção, e está fora do código base da OpenMV. As equipas que fazem isto pela primeira vez devem planear como um trabalho discreto na linha de tempo de desenvolvimento, e não como algo a acrescentar no final – a irreversibilidade torna «acrescentar mais tarde» dispendioso.