Uma vez que existem muitas empresas chinesas que podem facilmente fazer a engenharia reversa do projeto do PCB e extrair o arquivo .hex dos microcontroladores (mesmo de o flash seguro), os desenvolvedores incorporados precisam adicionar mais proteção aos seus produtos. No meu caso, estou usando um STM32F103 e quero adicionar a criptografia IC ATSHA204A em meu PCB para proteger meu IP. Fazendo isso, espero mesmo se eles conseguirem obter o .hex do MCU e clonar a placa, o arquivo hex se recusará a funcionar se não puder reconhecer o chip criptográfico no PCB.
Este IC criptografado tem um número de série exclusivo que foi escrito durante a fabricação e sempre pode ser lido. Ele também tem alguns recursos, como uma área segura para manter alguns dados secretos, capacidade de gerar números aleatórios e enviá-los ao host via I2C ou um cabo, capacidade de calcular o hash SHA-256 de uma determinada string e assim por diante.
Agora estou tentando entender como devo trabalhar com isso, pois sou meio que um novato no assunto autenticação. Pelo que entendi lendo a folha de dados, o fluxo de trabalho será assim:
Personalização da criptografia IC:
-
A área segura da criptografia o chip será preenchido pelo host (STM32F103 no meu caso) com alguma chave secreta aleatória para cada produto, apenas uma vez.
-
A chave secreta também estará presente no flash do host memória.
Autenticação da placa (meu entendimento, que provavelmente está errado):
-
O host solicita um número aleatório do crypto-IC. Em seguida, o host gera alguma string concatenada com a chave secreta e o número aleatório (nonce?) E calcula o hash SHA-256 dela.
-
Agora o host deve enviar o chave aleatória de volta para o crypto-IC e esperar que ela gere a mesma string com a chave secreta dentro do crypto-IC e calcule o hash SHA-256 dele.
-
Crypto-IC envia o hash calculado de volta ao host e o host compara os hashes.
-
Se os hashes corresponderem, valide. Se não o fizerem, o host se recusa a trabalhar.
O fluxo de trabalho provavelmente está errado, mas a ideia principal deve ser algo próximo a isso. Alguém pode explicar isso?
Resposta
O fluxo de trabalho provavelmente está errado, mas a ideia principal deveria ser algo próximo a isso.
Não, isso é basicamente inútil. Isso seria ótimo se você usasse seu IC criptografado, por exemplo, para validar a autenticidade de um dispositivo adicional (digamos, uma impressora verificando se o cartucho foi feita pela mesma empresa).
Isso não ajuda você , porque " se recusa a trabalhar " não voará se alguém tiver o código de máquina do seu firmware: encontrar o cheque no código de máquina desmontado geralmente não é que difícil. Então, é o mesmo que substituir um " salto para “parar e não fazer nada” " por um " pule para “iniciar de funcionalidade útil “"; normalmente, isso envolve a alteração de um byte.
Você precisa criptografar a parte interessante do seu firmware no armazenamento permanente (normalmente, o flash embutido do MCU). Apenas um carregador de inicialização que usa o chip de criptografia para descriptografar o firmware principal permaneceria descriptografado. Na inicialização, o bootloader descriptografa o firmware em RAM.
Pequeno problema aí: Você precisa ser muito inteligente, em termos de hardware, para que não seja possível basta conectar um analisador lógico entre seu MCU e o crypto IC e farejar os bytes descriptografados.
Existem soluções alternativas que ofuscam as coisas pulando descontroladamente na memória enquanto descriptografa coisas etc. O problema é que não há nada segredo sobre isso, é um pouco mais trabalhoso entender como o salto é feito a partir do código de máquina. (E se você conseguir inserir um único pedaço de código de máquina nesse barramento que faz o MCU transmitir toda a sua RAM por meio de algum pino, então o jogo acabou também; não importa para você se você sabe onde esse pedaço de código acaba na RAM, você o encontrará mais tarde no despejo, é importante apenas que seja executado em algum ponto.)
Em outras palavras, se você realmente acha que seu firmware é isso comercialmente interessante (as pessoas superestimam isso! Para coisas que não são principalmente firmware, como para qualquer dispositivo de consumidor e qualquer controle industrial, geralmente é difícil fornecer todas as peças e construir o dispositivo igual / semelhante mais barato que o original e reescrever completamente o firmware é geralmente fácil em comparação com isso), então sua única chance é integrar a manutenção de segredos, armazenamento criptografado e execução segura (de modo que o despejo de RAM seja impossível).
Existem microcontroladores que fazem isso. Geralmente são um pouco mais caros.Mas, como você pode imaginar, se você está, por exemplo, em um ambiente de defesa em que precisa certificar que o firmware não pode ser adulterado, bem, esse é o seu caminho.
A Nintendo fabrica aparelhos onde o incentivo financeiro para não permitir que ninguém leia seu firmware ou mesmo o modifique é forte:
A incapacidade dos usuários de rodar softwares que não foram licenciados pela Nintendo em seus consoles é crítica para seu modelo de negócios. Portanto, ser incapaz de contornar a verificação das assinaturas do jogo é primordial, e é por isso que um Nintendo Switch oferece várias camadas de proteção. Como você pode imaginar, isso “não é garantia – havia simplesmente hobistas (nem mesmo pessoas com interesses criminosos / comerciais!) Que encontraram uma maneira de contornar isso.
Mas você notará uma coisa: só porque é difícil fazer a perfeição, não significa que não vale a pena tornar mais difícil clonar seu dispositivo. Em minha humilde experiência, os clonadores normalmente capitulam assim que você precisar entender como funciona um dispositivo para copiá-lo – caso contrário, eles estariam na posição de ter engenheiros que poderiam fazer seu trabalho, mais ou menos, e esses engenheiros normalmente trabalham em seu setor, não em algum laboratório falsificado. Portanto, um bom impedimento é colocar o firmware criptografado em flash. Não é perfeito, mas no momento em que eles teriam que pegar o analisador lógico e passar semanas fazendo engenharia reversa em seu protocolo de descriptografia em RAM, apenas para obter algo que eles possam ser capazes de copiar, pode ser o suficiente para que eles considerem o risco financeiro muito alto e partam para alguns outra coisa.
Comentários
- " as pessoas superestimam que ", mas as pessoas superestimam o custo da engenharia reversa da mesma forma.
- Obrigado pela ótima resposta, não posso votar por não ter reputação suficiente. Sim, ' é basicamente impossível torná-lo 100% seguro, mas adicionar uma medida de segurança muito simples com um chip de criptografia de US $ 0,3 pode aumentar o custo da engenharia reversa de cerca de US $ 3 para talvez 5 dígitos, enquanto aumenta o tempo necessário de alguns dias para alguns meses se a segurança for projetada de forma inteligente o suficiente. E poderia repelir os hackers (dependendo do potencial financeiro do produto). Acho que seguirei criptografando a " parte interessante " do firmware principal.
- Eu ' diminuirei sua estimativa para " aumentando o tempo de uma hora para talvez alguns dias ", e o custo é basicamente irrelevante em ambos os casos. O custo seria " essencialmente gratuito " para qualquer pessoa que ' tenha as ferramentas eletrônicas mentindo por aí de qualquer maneira, e mesmo se não, 200 € mais um laptop dá a você um começo razoável.
- Então devo desistir e não usar proteção alguma? 🙂
- @NotReallyaMaster que ' depende de você; Eu ' dediquei todo o último parágrafo da minha resposta a essa pergunta.