Os programas carregados na placa NodeMCU podem ser extraídos?

13

Estou usando uma placa NodeMCU com recursos WiFi para criar um rastreador de ativos simples. Consegui encontrar alguns esboços do Arduino que permitem conectividade ao Hub IoT do Azure e postar mensagens.

Uma das chaves que eu preciso "carregar" no quadro é a string de Conexão do dispositivo do Azure e, é claro, um SSID e uma senha WiFi.

Meu medo é que alguém possa simplesmente assumir o controle e "baixar" os arquivos para obter acesso às credenciais de segurança.

Meu medo é injustificado ou a perda de credenciais é uma ameaça real que preciso mitigar?

security

— carneiros
fonte

3

Eu acho que as respostas de Mike Ounsworth e Bence Kaulics juntas me dão uma opção decente. Infelizmente, não posso marcar as duas como respostas aceitas.

— ram

12

[aviso: sou um profissional de segurança / criptografia e lido diariamente com questões de arquitetura de segurança.]

Você se deparou com o problema de armazenar credenciais de forma que um processo autônomo possa acessá-las, mas um invasor não. Este é um problema bem conhecido e muito difícil de resolver.

Se o seu dispositivo IoT tiver um keystore de hardware embutido na placa-mãe, como alguns TPMs, ou o equivalente ao Keystore suportado por hardware Android ou ao Apple Secure Enclave, você poderá usá-lo.

Nos servidores tradicionais, você pode usar HSMs ou cartões inteligentes, mas a única solução de software completa que eu conheço é derivar uma chave AES de algum tipo de "impressão digital de hardware" criada combinando números de série de todos os dispositivos de hardware. Em seguida, use essa chave AES para criptografar as credenciais. Um processo em execução no mesmo servidor pode reconstruir a chave AES e descriptografar as credenciais, mas depois que você extrai o arquivo do servidor, é essencialmente descriptografável.

A IoT lança uma chave nisso por dois motivos:

A suposição de que os números de série do hardware são únicos provavelmente não se sustenta e
Ao contrário dos servidores, os atacantes têm acesso físico ao dispositivo, portanto, provavelmente podem obter um shell no dispositivo para executar o programa de descriptografia.

Tanto a criptografia de hardware (TPMs) quanto a criptografia de "impressão digital de hardware" são ofuscação, na melhor das hipóteses, porque, fundamentalmente, se um processo local pode descriptografar os dados, um invasor capaz de executar esse processo local também pode descriptografá-lo.

Portanto, o truque padrão parece que não funciona aqui. A primeira pergunta que você precisa fazer é:

Qual é o meu modelo de ameaça / onde esse projeto se situa Secure <--> Convenient?

Por fim, acho que você precisa decidir isso security > conveniencee solicitar que um humano insira as credenciais após cada inicialização (usando algo como a resposta de @ BenceKaulics ), ou você decide isso security < conveniencee apenas coloca as credenciais no dispositivo, talvez usando alguma ofuscação, se você sinto que faz a diferença.

Esse é um problema difícil, dificultado pela natureza dos dispositivos IoT.

Para ser completo, a solução industrial completa para esse problema é:

Dê a cada dispositivo IoT uma chave pública RSA exclusiva no momento da fabricação. Grave essa chave pública em um banco de dados com o número de série do dispositivo.
Armazene as credenciais confidenciais em um servidor adequado, vamos chamá-lo de "gateway".
Quando um dispositivo IoT se autentica no gateway (usando sua chave RSA), o gateway abre uma sessão para ele usando as credenciais armazenadas e entrega o token da sessão de volta ao dispositivo.
Para melhor segurança, o gateway é um gateway físico (ou VPN), para que todo o tráfego do dispositivo IoT passe pelo gateway e você tenha mais controle sobre as regras e outras coisas do firewall - idealmente impedindo que o dispositivo seja direto (sem VPN) acesso à internet.

Dessa forma, o invasor que compromete um dispositivo pode abrir uma sessão, mas nunca tem acesso direto às credenciais.

— Mike Ounsworth
fonte

2

Sim. Uma grande parte do problema é que o que está tentando ser protegido aqui é o segredo compartilhado que é uma senha wifi. Segredos compartilhados são uma má idéia quando um dispositivo pode ser dissecado fisicamente. Um design melhor segregaria cada instância do dispositivo (ou outro computador) em seu próprio ambiente de segurança, com um canal exclusivamente seguro entre cada dispositivo individual e os sistemas com os quais eles precisam se comunicar. De qualquer forma, o wifi pode não ser muito adequado para o aplicativo, em comparação com algum esquema ponto a ponto de 2,4 GHz ou mesmo o protocolo "Esp Now".

— 22817 Chris Stratton

1

Bom ponto. Você pode corrigir o problema secreto compartilhado usando certificados de cliente corporativo WPA2 em vez de uma senha SSID (se o dispositivo IoT for grande o suficiente para ter uma pilha TLS, muitos não o serão). Não sei nada sobre o Hub IoT do Azure, mas presumo que essas strings da Conexão de Dispositivo do Azure já sejam exclusivas por dispositivo. Infelizmente, isso parece ser um preto e branco bastante limpo entre "DIY sem segurança" e "segurança em escala industrial", com pouco tempo entre elas.

— Mike Ounsworth 13/09/17

2

Pergunto-me, se posso abrir uma sessão à vontade, por que precisaria das credenciais?

— Andrew Savinykh

1

@AndrewSavinykh Depende de quais são as credenciais. Talvez tudo o que eles façam seja abrir uma sessão; nesse caso, sim, não há muito motivo. Mas talvez elas sejam credenciais de domínio AD do Windows ou dêem acesso a APIs adicionais normalmente não usadas / acessíveis no dispositivo IoT. Talvez você esteja bem com sessões provenientes de dispositivos comprometidos, mas não com sessões provenientes de laptops de invasores. Sim, torna-se específico do caso de uso rapidamente.

— Mike Ounsworth

3

Números de série ??? Encontrar um número de série único não deve ser um problema, mas os números de série não são secretos. Eles são inúteis para formar uma chave. Onde diabos está usando números de série para formar uma chave como um "truque padrão"?

— Gilles 'SO- stop be evil'

6

A ameaça é real, mas, felizmente, você não é o primeiro ou o único com esse tipo de preocupação de segurança.

O que você precisa é o ESP WiFi Manager é o que você precisa aqui.

Com esta biblioteca, o ESP que não possui uma sessão salva alternará para o modo AP e hospedará um portal da web. Se você se conectar a este ponto de acesso com um PC ou smartphone, poderá configurar as credenciais de WiFi por meio de uma página da web.

Você não precisa codificar as informações críticas e pode usar o dispositivo em qualquer rede Wi-Fi que desejar, sem a necessidade de atualizar novamente.

Como funciona

Quando o ESP é inicializado, ele é configurado no modo Estação e tenta se conectar a um Ponto de Acesso salvo anteriormente.

se não tiver êxito (ou nenhuma rede anterior salva), ele move o ESP para o modo de ponto de acesso e gera um DNS e um servidor da Web (ip padrão 192.168.4.1)

usando qualquer dispositivo habilitado para wifi com um navegador (computador, telefone, tablet) conectado ao ponto de acesso recém-criado

por causa do Captive Portal e do servidor DNS, você receberá um tipo de pop-up 'Ingressar na rede' ou qualquer domínio que tentar acessar redirecionado para o portal de configuração

escolha um dos pontos de acesso digitalizados, digite a senha, clique em salvar

O ESP tentará se conectar. Se for bem-sucedido, ele renuncia ao controle de volta ao seu aplicativo. Caso contrário, reconecte-se ao AP e reconfigure.

(Documentação do ESP WiFi Manager)

— Bence Kaulics
fonte

1

Ou apenas faça o download dos registros ou o que quer que esteja enquanto estiver no modo AP. Espero que o pôster não esteja tentando usar o próprio wifi para rastreamento de ativos.

— 22817 Chris Stratton

1

@ ChrisStratton :-) Na verdade, estou tentando usar o Wi-Fi para rastreamento de ativos. Felizmente, a rede WiFI usada é pública e aberta, mas estou preocupada com as implicações quando preciso usar outra que precise de uma senha. Além disso, o fato de a cadeia de conexão do Hub AzureIoT estar no dispositivo.

— ram

2

@rams Certamente, ler a EEPROM do dispositivo não seria uma grande tarefa.

— Bence Kaulics

3

@rams No seu hardware, a EPROM pode ser lida. Os dispositivos mais recentes podem ter algumas regiões seguras do flash, melhor protegidas. Certamente, esse é um problema conhecido que precisa de suporte no chip para tentar e funcionar corretamente.

— Sean Houlihane

2

@SeanHoulihane - o ESP8266 não possui EEPROM. O flash SPI usado para tudo (inclusive para simular a funcionalidade do Arduino) é externo ao ESP8266. Mesmo no módulo com vários chips, é um dado distinto que pode ser analisado em um laboratório decente.

— Chris Stratton

3

Sim, eles podem acessar sua senha se você a deixar como texto sem formatação.

O ponto positivo é que muitas interfaces de conexão wifi aceitam senhas com hash. Embora os que eu usei hash MD5 aceitos e o MD5 não sejam super seguros, ainda é um desafio muito difícil para o Joe comum. Dependendo do seu arquivo de configuração, você indica o nome do seu algoritmo de hash e depois escreve sua senha ou usa o padrão usado pela interface wifi.

— atakanyenel
fonte

3

Se eles podem extrair uma senha com hash que funcione enquanto estiver com hash, o que os impede de usá-la sem nunca revertê-la?

— Chris Stratton

1

@ChrisStratton, você está certo. As maneiras de como evitá-lo é para o Information Security SE, essa pergunta pede para evitar a perda de credenciais. No entanto, as senhas com hash ainda não podem ser usadas pelos celulares para conectar-se à rede sem software adicional.

— atakanyenel 12/09

1

Sim, na verdade, ofereceria alguma proteção no caso de reutilização da senha do wifi em outro sistema, mas não muito contra a conexão não autorizada a esse ponto de acesso wifi.

— Chris Stratton

1

@ChrisStratton sim, por exemplo, a lista branca de MAC é muito mais segura do que simplesmente ter uma senha e hash, mas essas etapas são para segurança de wifi em geral, não para a privacidade de credenciais em dispositivos públicos.

— atakanyenel 12/09

2

Não, a lista de permissões do MAC é uma piada - não há segredo algum. E é claro que o MAC é facilmente extraído do ESP8266 roubado ou do seu flash SPI. O único lugar em que a lista de permissões de MAC ajudaria seria contra pessoas que usam uma GUI para ingressar em redes wifi ou se um ponto de acesso estava lá esperando uma conexão de um cliente que poderia aparecer algum dia, mas nunca havia se conectado a ela - ou seja, , espada no material tipo pedra.

— Chris Stratton

1

Resposta simples - SIM. Pode ser feito. Você deve, pelo menos, executar algum tipo de ofuscação para fornecer proteção mínima.

— Amit Vujic
fonte

1

A ofuscação torna mais difícil descobrir como o dispositivo faz as coisas, mas é inútil proteger contra a clonagem do dispositivo. É inútil proteger contra a extração de credenciais: tudo o que você precisa fazer é executar o firmware em um emulador.

— Gilles 'SO- stop be evil'

Concordo plenamente. Minha motivação para dar essa resposta foi observar que <a segurança da rede IoT deve ser considerada>. @Mike Ounsworth deu uma resposta detalhada, sugerindo soluções usando a infraestrutura AES e / ou RSA. Estou pensando em dar mais uma resposta, mas não tenho certeza de como mergulhar na criptografia (também tenho muitos anos em soluções bancárias e de pagamento). Meu pensamento é que precisamos fornecer conselhos práticos / equilibrados, porque geralmente as pessoas evitam se aprofundar na criptografia para proteger os dispositivos IoT em seu quintal.

— Amit Vujic 14/09/17

1

Se as pessoas querem criar dispositivos inseguros porque não podem se incomodar em descobrir como criar dispositivos seguros, não vejo razão para habilitá-los.

— Gilles 'SO- stop be evil'

Minha experiência é que as pessoas querem aprender, mas, novamente, deve haver equilíbrio entre o nível de segurança e a complexidade. Há uma história famosa no setor de pagamentos referente ao SET ( en.wikipedia.org/wiki/Secure_Electronic_Transaction ) que é / era muito seguro, mas complexo de implementar e por causa disso falhou na prática.

— Amit Vujic

2

A ofuscação adiciona complexidade sem melhorar a segurança. Isso não é equilíbrio.

— Gilles 'SO- stop be evil'