Se você pode ter o TCP de ponta a ponta, use o TLS de ponta a ponta (por exemplo, com HTTPS).
Não reinvente a roda, especialmente quando se trata de criptografia - a maioria das pessoas entende errado. A menos que o dispositivo tenha recursos muito limitados para oferecer suporte ao TLS, se você atingir o nível de AES, estará fazendo errado . O erro número 1 é criptografar e esquecer de se autenticar - se você possui um canal criptografado entre o servidor e um intermediário, em vez de um canal criptografado entre o servidor e o dispositivo, a criptografia não oferece nenhum benefício . Se você não pode usar o TLS, verifique se o protocolo que você está usando autentica tudo e criptografa o que precisa ser confidencial.
Para usar o TLS com segurança, pense nas garantias que você precisa ter, do ponto de vista de cada participante. Geralmente, o dispositivo precisa saber que está falando com o servidor legítimo. Isso significa que ele deve verificar o certificado do servidor. O dispositivo deve ter o certificado X.509 de uma autoridade de certificação registrado como confiável; isso requer armazenamento que não pode ser modificado por um invasor, mas não exige nenhuma confidencialidade do armazenamento. Observe que você não deve codificar diretamente o certificado do servidor, pois isso não permitirá que você substitua facilmente esse certificado se ele estiver comprometido. Em vez disso, o dispositivo armazena a identidade esperada(nome do host) do servidor e o certificado de uma autoridade de certificação que garante que uma determinada chave pública pertença ao nome do host esperado. Mais uma vez, não reinvente a roda, confie na verificação de certificado fornecida pela sua biblioteca ou aplicativo TLS.
Se o servidor precisar saber que está conversando com um cliente legítimo, cada cliente precisará ter seu próprio certificado de cliente. Isso requer armazenamento confidencial no cliente. Passe o certificado do cliente para a função de abertura da sessão TLS da sua biblioteca TLS ou defina-o na configuração do aplicativo.
Isso cuida da segurança da comunicação entre o servidor e o dispositivo. Se o aplicativo móvel puder conversar diretamente com o dispositivo (por exemplo, para permitir a operação desconectada enquanto estiver na rede Wi-Fi local), é necessário primeiro fazer o emparelhamento entre o comutador inteligente e o telefone celular. Emparelhamento significa uma troca de chaves, preferencialmente uma troca de chaves públicas, se os recursos permitirem, caso contrário, um acordo de chaves secretas. O objetivo desse emparelhamento é garantir que cada dispositivo saiba com quem está falando.
Você também precisará proteger o canal de controle, seja ele diretamente do dispositivo móvel até o comutador inteligente ou via servidor. Pense na autorização: existem diferentes níveis de acesso ao comutador, por exemplo, um nível de controle que permita a reconfiguração e um canal básico que permite a ativação / desativação do comutador? Isso geralmente é tratado por uma etapa de autenticação após o estabelecimento do canal seguro (TLS, se possível).
Outra consideração são as atualizações de firmware. Essa é uma questão complicada: por um lado, não existe segurança absoluta; portanto, você terá patches de segurança para aplicar de vez em quando. Por outro lado, um mecanismo de atualização de firmware é uma coisa complexa e pode ter bugs. No mínimo, verifique se as atualizações de firmware estão assinadas. Depender exclusivamente da segurança do canal de comunicação para atualizações é complicado, porque a base confiável para um canal seguro é maior do que para uma verificação de segurança estática e, às vezes, você pode aplicar atualizações de firmware sem uma conexão de rede. Além de verificar a assinatura, o ideal é você ter alguma proteção contra reversão, para que um adversário possa '