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.crt
que 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.