Impedir que a partição criptografada seja executada em outro PC

2

Pergunta concisa : É possível de alguma forma ligar a criptografia de partições ao hardware, então é impossível (muito difícil) copiar o sistema para outro PC e rodá-lo lá?

História completa : temos um pequeno PC incorporado com Linux rodando dentro de um dispositivo, desenvolvemos. Quando o dispositivo é ligado, o PC embutido é executado, mostrando os dados para os usuários até o desligamento.

O software neste PC é a nossa vantagem competitiva comercial, por isso gostaríamos de impedir o acesso a ele o máximo possível (ver P.S.).

Então a ideia é criptografar o flash do sistema ou pelo menos uma parte dele. Mas então é possível apenas copiar o flash inteiro. Então, a próxima ideia é vincular a criptografia ao hardware. Mas como?

P.S. Eu sei que tudo é um assunto para engenharia reversa, mas não é a razão para deixar a engenharia reversa do seu produto plana e incontestável.

P.P.S Eu não sou paranóico sobre copiar. Infelizmente, conhecemos concorrentes que tentarão roubar a tecnologia por nomes =)

    
por MajesticRa 03.04.2015 / 03:29

5 respostas

4

Você pode vincular dados criptografados a um dispositivo específico usando um Trusted Platform Module (TPM). Eles se tornaram bastante comuns em laptops x86 nos últimos anos e podem ser instalados em muitos servidores também.

Usando um TPM, você pode gerar uma chave de criptografia que só existe no módulo e criptografar dados usando isso; Se você gerar uma chave que não pode ser salva em backup, pode ter certeza de que os dados só podem ser criptografados com o TPM correspondente. Copiar o dispositivo de armazenamento bruto é inútil então. No Linux você pode usar o TrouSerS para gerenciar isso.

Nas plataformas ARM, você pode fazer algo semelhante com uma chave armazenada usando TrustZone , mas eu não sei os detalhes.

    
por 07.04.2015 / 13:56
2

Use um microprocessador que tenha flash incorporado e que não possa ser lido externamente. Muitos chips ARM modernos possuem essa capacidade. Nesse flash, você coloca seu código e as chaves de criptografia necessárias para acessar qualquer armazenamento externo.

    
por 03.04.2015 / 04:36
1

Você não pode realmente confiar em segredos criptográficos neste caso, porque o seu PC incorporado precisará conhecer esses segredos para funcionar, e assim o invasor também os conhecerá.

Uma solução seria encontrar ou fazer um segredo que seja ilegível de fora (de maneira similar ao sugerido pelo @psusi). É difícil sugerir algo sem saber que tipo de hardware você tem exatamente. Talvez um número de série do processador seja uma boa opção, embora eu me pergunte se você pode lê-lo via JTAG também.

Outra maneira de resolver isso é ofuscação. Em vez de um código que começa com um procedimento de decodificação (e torna óbvio de onde vem o segredo), você deve desenvolver um código que use o segredo várias vezes em partes aleatórias do programa. Por exemplo, em vez de codificar um tamanho de buffer em algum lugar, você pode usar o n-ésimo número de série do seu processador multiplicado por 1000. Isso fará com que o código trava em uma configuração de hardware diferente e exigirá muita depuração antes que o adversário encontre qual segredo é usado e como.

Se você precisar de uma resposta mais detalhada, é necessário fornecer detalhes também. Qual é o modelo de ameaça (cópia ilegal para hardware similar, desmontagem de seus algoritmos proprietários, algo mais)? Qual é o seu hardware? Quais são as restrições relevantes (você disse que não pode cortar os pinos do JTAG, por quê?)

    
por 07.04.2015 / 13:44
1

Eu usei um cartão seguro interno GPG para um propósito semelhante em um sistema dedicado que é até 24 * 7, com software que:

  1. descriptografa as partes protegidas do software antes de serem carregadas na memória
  2. que o software e o software protegido carregado verificam a espionagem na memória (ou seja, o processo no sistema não é tolerado por nós), bem como as modificações não assinadas no software
  3. Se o sistema for reinicializado, nosso site é verificado com dados exclusivamente provenientes do cartão e dados enviados de volta, o que permite mais descriptografia (contanto que o sistema esteja ativo).
  4. Caso o software decida que está sendo feita uma tentativa de fazer engenharia reversa, ele grava um log criptografado (que podemos revisar) e bloqueia o funcionamento do cartão seguro.

Quando você substitui a parte normal legível do software, ainda é muito improvável que você tenha acesso à peça criptografada. Isso não é infalível e requer uma conexão com a Internet no momento da inicialização, mas salva no sistema, quando roubado, podendo inicializar e revelar software descriptografado (a menos que seja roubado sem remover a energia).

    
por 09.04.2015 / 13:36
1

Meu servidor produz sua chave de criptografia com base em dados de hardware como tipo de CPU, memória disponível, endereço MAC de rede, ... que permite que a máquina seja reinicializada sem supervisão e, se você remover o disco e colocá-lo em outro servidor , não poderia decifrar-se.

Mas é um ponto discutível em um sistema embarcado ou, na verdade, em qualquer lugar em que você tenha acesso root, já que você pode consultar a chave usando dmsetup table --showkeys .

Então, parece-me que sua melhor aposta seria colocar criptografia no hardware.

E a segunda melhor aposta, para corrigir seu kernel de alguma forma, então o comando dmsetup acima não poderá consultar as chaves de criptografia usadas, e talvez assar a geração de chaves no próprio kernel, então não pode ser agarrado do Initramfs também.

Ele ainda pode ser obtido de um despejo de memória, mas ainda é o melhor que você pode fazer ...

É claro que é um ponto discutível se o sistema em execução vir todos os dados não criptografados e alguém obter acesso e puder copiar apenas a visualização não criptografada.

    
por 09.04.2015 / 13:48