É uma prática ruim manter certificados na memória externa?

Estamos trabalhando na AWS-IoT usando um microcontrolador STM32.

Até hoje, estávamos escrevendo os certificados no flash e bloqueando o flash da leitura externa. À medida que o código do aplicativo aumenta, estamos recebendo menos espaço no flash, por isso planejamos mover o certificado externamente em um cartão SD / EEPROM e ler sempre que necessário antes de conectar-se à AWS-IoT.

Notas:

• A política criada para a coisa permitirá que apenas dispositivos com nomes específicos se conectem nesse certificado específico.

• A coisa é permitida a publicação em apenas 2 canais (nome e canal de alimentação de dados) conectados a um processador de dados que ignorará todos os pacotes não autorizados que chegam a ele.

• Se a coisa publicar / assinar qualquer outro tópico, a AWS desconectará a coisa imediatamente.

Se eu detectar que um dispositivo é roubado / desonesto, desativamos a chave do servidor.

O que um explorador pode fazer com os certificados (RootCA, chave do servidor, chave do cliente)?

É uma má prática manter certificados para esse caso de usuário em um armazenamento externo que pode ser acessado por um explorador?

Você menciona "certificados", mas, pelo contexto, acho que você está se referindo a duas coisas diferentes.

• O seu dispositivo possui uma chave privada , exclusiva deste dispositivo e desconhecida fora dele. Essa chave identifica seu dispositivo. Qualquer pessoa que possa acessar essa chave pode representar o dispositivo. Isso significa que eles podem, em particular:

  • Publique dados válidos, mas incorretos, nos canais nos quais seu dispositivo está legitimamente autorizado a publicar.
  • Publique dados inválidos que banirão o dispositivo legítimo.
  • Possivelmente, dependendo do caso de uso, exponha algumas informações particulares do proprietário do dispositivo.

  É melhor que essa chave privada permaneça confidencial.

• Seu dispositivo provavelmente possui pelo menos uma chave pública , que permite reconhecer com quais servidores está falando. Tudo bem se alguém puder ler esta chave: é público. Mas um invasor não deve poder modificar a chave. Caso contrário, eles poderiam se comunicar com o dispositivo e representar o servidor. Isso poderia permitir que eles fizessem coisas como:

  • Envie uma atualização de firmware para o dispositivo.
  • Envie uma atualização de configuração para o dispositivo.
  • Faça o dispositivo enviar seus dados para um local diferente.

A boa notícia é que essa análise de ameaças não é realmente muito relevante. Você não precisa sacrificar nenhuma segurança ! (Pelo menos, não as propriedades de confidencialidade e autenticidade - se você armazenar coisas externamente, a disponibilidade será afetada, porque esse é um pedaço do sistema que pode faltar.)

Desde que você tenha pelo menos 128 bits de armazenamento nos quais possa gravar pelo menos uma vez, o que possui e mais, poderá implementar uma solução de armazenamento remoto seguro. Use o armazenamento no dispositivo de espaço limitado para armazenar uma chave secreta. Essa chave secreta deve ser exclusiva por dispositivo; o STM32 possui um RNG de hardware, para que você possa gerá-lo no dispositivo durante a primeira inicialização. Se o seu dispositivo não tiver um RNG de hardware, você poderá gerar a chave em um local seguro fora do dispositivo e injetá-la no dispositivo.

Com essa chave, use criptografia autenticada para itens armazenados no dispositivo. Quando você quiser ler alguns dados do armazenamento externo, carregue-os, decifre-e-verifique-os. Quando você quiser gravar alguns dados no armazenamento externo, criptografe e assine. Isso garante que os dados sejam tão confidenciais e autênticos quanto os dados no armazenamento interno.

A criptografia autenticada é suficiente para garantir a confidencialidade e autenticidade dos dados, mas não garante sua integridade .

• Se houver mais de um pedaço de dados, quando o dispositivo voltar a ler um pedaço de dados, não será possível ter certeza de que esse é o pedaço correto. Solução: incluir um identificador único no conteúdo de cada pedaço (por exemplo, começar cada pedaço com um dos "AWS-IoT private key.", "configuration CA certificate.", "publishing server CA certificate.", "user personal data.", ...).
• Se você atualizar os dados em algum momento, quando voltar a lê-los, não poderá ter certeza de que está obtendo a versão mais recente desses dados. Se alguém puder modificar o armazenamento externo, não poderá colocar dados falsos porque isso falharia na verificação de autenticidade, mas poderá restaurar dados antigos, porque o que costumava ser autêntico ainda é autêntico. Solução: em cada pedaço de dados armazenado externamente, inclua um contador que você incrementa cada vez que escreve uma nova versão desse pedaço. Ao ler um pedaço, verifique se é a versão esperada.

Para evitar o bloqueio de um dispositivo no caso de o armazenamento externo ser danificado ou perdido, no espaço limitado em que você tem espaço no armazenamento interno, você deve dar prioridade ao que for necessário para redefinir o dispositivo para um estado "bom", por exemplo, uma redefinição de fábrica . A segunda prioridade serão as considerações de desempenho.

Um pouco de contexto

Como você usa o MQTT com o AWS IoT, espera-se que você use certificados X.509 para autenticação e segurança. A Amazon tem um pouco de orientação sobre como você deve proteger seus certificados, então cito aqui:

Os certificados permitem que chaves assimétricas sejam usadas com dispositivos. Isso significa que você pode gravar chaves privadas no armazenamento seguro em um dispositivo sem permitir que o material criptográfico sensível saia do dispositivo.

Como você está atualmente usando o RDP ( Read Out Protection ) do STM32 , todos os invasores, exceto os mais determinados, terão problemas para acessar seus certificados no seu esquema atual:

A proteção de leitura global permite que o código de firmware incorporado (pré-carregado na memória Flash) proteja contra engenharia reversa, despejo usando ferramentas de depuração ou outros meios de ataque intrusivo.

• Nível 0 - Sem proteção (padrão)
• Nível 1 - A memória flash é protegida contra a leitura por depuração ou despejo de código pelo código carregado da RAM
• Nível 2 - Todos os recursos de depuração estão desativados

O armazenamento externo será seguro?

Provavelmente não é tão seguro . Se a chave privada do seu cliente for roubada, um invasor poderá enviar dados que parecem ser do seu dispositivo, quando na verdade não são. Embora não esteja claro quais dados você está enviando, quaisquer dados não confiáveis ​​podem ser um risco à segurança.

Quais bits eu preciso para manter em sigilo?

Ao criar um certificado de dispositivo no AWS IoT, você verá uma imagem como esta:

^{Imagem da página Criar e ativar um certificado de dispositivo da documentação do AWS IoT.}

A chave privada é o que você realmente precisa manter ... privada e, definitivamente, deve ser armazenada na memória protegida contra leitura, se possível. A chave pública e o certificado foram projetados para serem compartilhados; portanto, se você estiver ficando sem espaço, poderá movê-los com segurança para o armazenamento externo. Você pode ter um pouco mais de contexto na página Como funciona o SSL / TLS? em Troca de pilha de segurança da informação e criptografia de chave pública na Wikipedia. Acho que faria um desserviço a você se não incluísse esta imagem para explicar por que a chave privada precisa ser secreta:

.

^{Imagem da Wikipedia , lançada em domínio público.}

A chave pública do seu dispositivo é o que a AWS IoT usa para assinar mensagens para enviar ao seu dispositivo (mas não prova quem está enviando a mensagem ). Então, realmente, não é um grande desastre se alguém roubar a chave pública, porque não é para ser um segredo.

A chave privada é o que o seu dispositivo usa para descriptografar as mensagens, por isso é um problema um pouco maior se um invasor roubar isso.

Você também perguntou o que aconteceria se o invasor roubasse o certificado RootCA. Se alguém roubasse a chave privada da AWS IoT , seria desastroso, mas o certificado RootCA no seu dispositivo não é esse . O RootCA.crtque a Amazon fornece é totalmente público , e o objetivo é verificar se você não está sendo atacado de forma alguma (provavelmente um homem do meio fingindo ser o servidor da AWS IoT).

Que dano um dispositivo invadido poderia causar?

Seu dispositivo roubado pode executar apenas as ações listadas na política . Tente seguir o princípio do menor privilégio ; conceda ao seu dispositivo apenas os privilégios absolutamente necessários , portanto, se o pior acontecer, ele não poderá causar estragos demais. Para o seu caso específico:

A coisa é permitida a publicação em apenas 2 canais (seu nome e um canal de alimentação de dados) que está conectado a um processador de dados que ignorará todos os pacotes não autorizados que chegam a ela.

Isso é bom. Qualquer ataque deve ser isolado apenas para os dois tópicos do MQTT nos quais o dispositivo pode publicar, para não causar danos em larga escala.

Idealmente, você deseja que seu sistema geral tenha um design tal que dissecar uma única unidade quebre apenas essa unidade e não o sistema em geral.

Especialmente se você estiver armazenando chaves em uma memória distinta, de modo que elas cruzem uma interface elétrica padrão entre chips, elas devem ser apenas chaves que já sejam seguras para publicação ou exclusivas dessa instância física específica do dispositivo.

Se uma chave individual for extraída de um único dispositivo e começar a ser abusada ou aparecer em um volume de tráfego que deve ser de vários clones não autorizados, você poderá banir essa chave no lado do servidor.

É claro que suas chaves devem ter a propriedade de não serem algo que uma parte não autorizada pode adivinhar a partir de alguns exemplos extraídos ou gerar suas próprias instâncias compatíveis originais de - ou seja, você precisa de um registro das chaves que gerou onde são válidas. apenas uma parte pequena e imprevisível de um enorme espaço de possibilidades; caso contrário, você precisa assinar as chaves geradas e fazer com que seu sistema aceite apenas uma chave em combinação com sua prova de assinatura.

Você deve tentar manter em segredo a chave do cliente (mas entenda a implicação de perdê-la (1), conforme descrito nas outras respostas). A chave pública do servidor e o certificado público da AWS são importantes para proteger no final do dispositivo, não porque você deseja mantê-lo em segredo, mas porque, ao substituir o certificado da AWS (em um dispositivo comprometido), um invasor pode convencer o dispositivo a executar uma troque com o host do invasor ou para manter suas comunicações com a AWS.

Ao fazer isso (2), um invasor pode remover a segurança do TLS, o que pode resultar em uma redução suficiente na segurança para que ele possa fazer engenharia reversa da chave do cliente.

Por esse raciocínio, a única chave que é segura expor em um dispositivo de memória externo é a chave pública do servidor. Alterar isso (3) só permitiria que seu dispositivo fosse forçado a conectar-se a um serviço não autorizado da AWS, que é presumivelmente difícil de projetar. Mesmo o vazamento dessa chave pode permitir que alguém espie ou falsifique algumas transmissões (por exemplo, se a camada TLS puder ser de alguma forma desatualizada).

Portanto, em resumo, o risco não é simplesmente o vazamento de informações, existe o risco de o firmware (supostamente confiável) poder ser fornecido com informações seguras não confiáveis.