armazenamento e uso seguros de chaves em um sistema incorporado

Estou usando um microprocessador - PIC32MZ2048efm144 MCU que recebe comandos criptografados com uma chave específica , descriptografa-os e executa o comando. Os comandos criptografados são armazenados offline , portanto, não posso alterar a chave sempre que quiser. A chave está CORRIGIDA . Os comandos são criptografados por um servidor e carregados por um telefone . O telefone envia os comandos criptografados para o MCU posteriormente, quando não está online . Os comandos são criptografados antes que o telefone os comunique ao MCU, portanto, uma chave de sessão não é possível.

Tenho permissão para conectar um módulo externo de criptografia / descriptografia ao PIC, mas os dados passarão descriptografados em pelo menos uma direção.

A solução apresentada aqui: Armazenando uma chave segura na memória de um dispositivo incorporado

usa chaves de uso único para criptografar, mas preciso armazenar uma única chave super secreta

O que meu empregador exige é que as chaves não sejam acessíveis, portanto, a proteção física além da oferecida pelos módulos de memória segura e pelo MCU não é considerada.

Supondo que nenhum equipamento de nível militar seja usado, existem soluções conhecidas que vocês conhecem e podem recomendar?

Desde já, obrigado!

— Sonja
fonte

Você pode explicar mais sobre o que você está tentando impedir? O que o microprocessador faz? Você acha que o uso de uma chave pública / privada pode funcionar? Se você armazenou a chave privada no microprocessador? Em seguida, os dispositivos que enviam comandos criariam uma chave de sessão, criptografariam usando a chave pública e a enviariam para você. Depois disso, os dois lados usam a chave da sessão. O que aconteceria se um invasor tivesse a chave pública (que, mesmo sendo chamada "pública", na verdade não precisa ser pública)?

— mkeith

@mkeith Eu atualizei a questão, espero que ajude :)

— Sonja

Desde que você escolheu esse PIC, por que não usar o "Armazenamento de Chaves Programaticamente Seguro" que ele fornece? Ele possui seu próprio módulo de criptografia embutido!

— Pjc50

Não acho que você tenha quantificado claramente o valor do seu segredo. Parece que você quer um método barato e confiável (que eu acho que é desconhecido). Peça esclarecimentos sobre o que precisa ser possível depois que uma vulnerabilidade for encontrada nesta primeira solução. Atualizações de firmware over-the-air assinadas seriam meu primeiro recurso inegociável ... É um problema do sistema - sempre.

— Sean Houlihane

Bem, se a memória do PIC está protegida (e ainda possui um módulo de armazenamento de chaves), por que não usar uma criptografia AES simples? Eu sei que é simétrico, mas se o servidor é seguro (o que nós meio que temos que assumir), então não há risco aqui - ou existe?

— Jan Dorniak

Respostas:

Lamento que esta resposta não resolva o seu problema. Mas é muito longo para caber em um comentário e permitirá que você repense seu problema da maneira correta (porque, como é, acho que é defeituoso).

Esse tipo de problema deve ser resolvido levando em consideração todos os componentes do sistema e fazendo suposições razoáveis sobre o que um hacker em potencial pode ou não fazer.

Por exemplo:

Você diz: "o PIC32MZ2048efm144 (MCU) recebe comandos criptografados com uma chave específica, descriptografa-os e executa o comando". Suponho que o resultado da execução do comando esteja alternando alguns GPIOs para acionar coisas.

Então, por que você tem medo de que, potencialmente, alguns dados sejam descriptografados entre o MCU e um módulo de criptografia / descriptografia? Um hacker que tenha acesso ao hardware para ver os comandos descriptografados seria capaz de agir diretamente nos GPIOs do MCU e "atuar o material" com a mesma facilidade.

Segundo exemplo:

Usar as teclas de pontualidade é uma ideia. Mas como você diz, onde você armazena a chave principal principal usada para gerar as chaves únicas? Você enfrentará exatamente as mesmas perguntas do seu problema original.

Na verdade, não há como proteger seu sistema se você supuser que um hacker pode entrar em qualquer local do sistema (que é o que me parece que você está assumindo).

O que torna um sistema seguro, então?

Um cartão inteligente é protegido porque não é razoável supor que um hacker possa investigar as rotas internas no IC, entre a memória e o bloco da CPU.

Uma trava elétrica de porta é protegida porque não é razoável supor que um hacker possa alcançar os fios que acionam a trava.

Etc ... Basicamente, você deve começar identificando coisas que um hacker não poderá fazer e elaborar toda a sua solução a partir daí. Por exemplo, é possível colocar todo o sistema em uma caixa segura e resistente a violações? Nesse caso, você pode livremente ter decriptografado comandos passando por um barramento interno.

Você não pode construir um sistema seguro sem saber o que é que o hacker não pode razoavelmente fazer. Você não nos disse isso. Portanto, não podemos propor uma solução completa.

— escuro
fonte

Antes de tudo, obrigado pela resposta elaborada! Eu atualizei a questão de uma forma eu acredito que vai responder-lhe :)

— Sonja

O que entendo da edição da sua postagem é que apenas as chaves precisam ser protegidas. Os resultados reais dos comandos não precisam ser protegidos. Nesse caso, coloque as chaves em um módulo seguro externo, como você sugeriu, e aceite que os comandos descriptografados possam ser vistos com clareza. Se minha sugestão for inválida por algum motivo, explique em detalhes o que é aceitável e o que não é . Não é apenas mais uma frase em sua postagem que precisamos. Precisamos de toda a imagem da coisa. Realmente.

— dim

Além disso, sinto que a criptografia dos comandos não é realmente o que você deseja fazer. Normalmente, precisamos criptografar dados (algumas informações sobre algo ou um documento ...). Mas raramente precisamos criptografar comandos enviados para um dispositivo. O que geralmente é necessário nos comandos é assiná-los , para garantir que eles venham da parte autorizada. Mas o conteúdo deles raramente é sensível, na verdade. Então você deve confirmar isso também.

— dim

Parece um caso clássico em que a criptografia de chave assimétrica seria útil. Na criptografia de chave assimétrica, você tem duas chaves, uma privada e uma pública. Você deseja proteger totalmente a chave privada, mas a chave pública pode ser tornada pública e não precisa de proteção. você poderá manter a chave privada no sistema seguro e a chave pública no dispositivo incorporado.

— hildred
fonte

A descriptografia de dados é feita com a chave privada (e a criptografia com a chave pública). Caso contrário, isso significa que todos podem descriptografar (como todos têm acesso à chave pública), o que seria um problema. Portanto, você precisa da chave privada para estar no dispositivo. Então, agora, como colocar a chave privada no dispositivo? Bem, voltando ao problema inicial ...

— dim

ser capaz de descriptografar os comandos não permite que criar novos do zero assim que ter o público acessível chave de alguma forma que não é muito de um problema

— masterX244

Isso geralmente é o mesmo que assinatura criptográfica; que tem a desvantagem de que, se alguém tiver a chave pública (na verdade não precisa ser pública, pode ser armazenada com tanta segurança quanto a chave simétrica), pode descriptografar tudo; mas, como diz o masterX244, geralmente você não pode criar / assinar novos comandos. Eu acho que essa é uma boa solução.

— CoderTao

Você não explica por que deseja que os comandos sejam criptografados (em outras palavras, qual é o seu modelo de ameaça). Seu objetivo é impedir que um adversário em posse do dispositivo baseado em PIC determine quais são os comandos enviados a ele? Ou você está tentando impedir que o dispositivo baseado em PIC execute um conjunto de comandos substituídos por um adversário e permita apenas executar comandos originários do seu servidor?

No primeiro caso, você enfrenta uma tarefa quase impossível: seu dispositivo deve descriptografar os comandos para executá-los - posse do dispositivo PIC significa posse da chave de descriptografia. Um adversário pode extrair a chave (armazenada no dispositivo PIC que ele possui) ou simplesmente esperar até o firmware descriptografar os comandos e capturá-los da memória.

Se, por outro lado, você está apenas tentando garantir que seu dispositivo execute apenas comandos originários do servidor, você está com sorte. Nesse caso, você pode usar a criptografia de chave pública (por exemplo, RSA) ou um esquema de assinatura digital de chave pública (por exemplo, DSS). Nestas, o dispositivo armazena apenas a chave pública: é suficiente para descriptografar os comandos (ou verificar a assinatura digital), mas não pode ser usado para criptografar comandos (ou gerar uma assinatura digital) que o dispositivo aceitará. Isso requer a chave privada, usada para criptografar (ou assinar) os comandos antes de enviá-los. A chave privada nunca precisa sair do servidor. Melhor ainda, criptografar para assinar os comandos em uma máquina que não se comunica externamente e apenas copiá-los para o servidor para que a chave privada nunca seja encontrada em um servidor acessível externamente.

— Stephen C. Steel
fonte