Razões para não assumir que o endereço MAC do dispositivo é único

Question

Em um cenário em que você controla o provisionamento do hardware e pode determinar que todos os dispositivos com o mesmo modelo de hardware possuem endereços MAC exclusivos para suas interfaces de rede, há desvantagens na criação de código que usa essa suposição? (Nota com base em algumas respostas: não vou escrever código de rede usando essa suposição. É apenas para ser uma maneira de baixo toque de ter um uuid por dispositivo sem ter que gerar manualmente e atualizar o HDD do dispositivo com um id antes implantando no campo)

A história de fundo para isso é que estou pesquisando a implementação de uma implementação de tipo IOT de hardware privado para um cliente. Forneceremos um conjunto de dispositivos de hardware com recursos de rede para instalar em locais remotos. Esses dispositivos se comunicarão de volta a uma API enviando mensagens. Para reduzir a complexidade da configuração, esperava enviar o endereço MAC da interface de rede no dispositivo da mensagem, para vincular essas mensagens a um "device_id" no lado da API. Meu pensamento é que, fazendo algo que não precisa ser configurado no dispositivo antes do uso, ele pode ser consultado apenas durante a operação normal. Posso assumir com segurança que podemos determinar que os endereços MAC de cada dispositivo são de fato exclusivos e podemos controlar quando / se o dispositivo for substituído para saber que as mensagens para esse device_id agora terão um endereço MAC diferente.

    

Answer 1

Com base em suas declarações que você pode confirmar durante o provisionamento de que o fabricante MAC é de fato único dentro da rede de dispositivos que você está criando (o que não é em si uma certeza, embora deva ser), provavelmente procedimento bem, mas considere as seguintes questões:

• Você está usando o MAC para verificações de segurança (autenticação, autorização)? Se assim for, um MAC não é suficiente. Nem pense nisso. Use uma estrutura criptográfica e transmita todas as solicitações de autenticação com segurança.

• Os 48 bits são largos o suficiente? Provavelmente é, mas vale a pena perguntar.

• Você precisará reparar um dispositivo substituindo o nic?

• Se você substituir um dispositivo por completo ou substituir seu nic, precisará associar o novo endereço à chave existente no banco de dados para garantir a continuidade da coleta de dados para a implantação localização?

• Haverá alguma interface de manutenção pela qual um usuário (autorizado ou não) possa alterar o nic no nível da ROM, do driver ou do sistema operacional? Um invasor pode introduzir falhas nos seus dados se eles modificarem o MAC.

• Seus dados serão associados a outras origens de dados usando MAC como chave?

• Alguma vez você usará o MAC para qualquer finalidade de rede que não seja simplesmente navegar na LAN de camada2 à qual o dispositivo está conectado (com ou sem fio)?

• A LAN à qual seus dispositivos estão conectados, ser uma rede privada ou um grande número de clientes transitórios (como celulares de funcionários) se conectará?

Se as suas respostas forem

NO, yes, no, no, no, no, no, private

então não consigo pensar em nenhuma falha real em seu plano.

Lembre-se de que você não precisa de MACs exclusivos para obter isso; você só precisa se certificar de que o subconjunto de dispositivos da Internet que chamam sua API seja exclusivo. Assim como um nic duplicado atribuído em duas cidades diferentes não pode colidir porque eles estão em LANs diferentes, você não pode ter uma colisão de chave de banco de dados em um MAC se ele nunca chamar sua API.

    

Answer 2

Os endereços MAC não são exclusivos

Pode haver e será duplicado com MACs. Há várias razões para isso, uma delas é que elas não precisam ser (globalmente) únicas.

O MAC deve ser único na rede local, então o ARP / NDP pode fazer seu trabalho, e o switch sabe para onde enviar os datagramas recebidos. Geralmente (não necessariamente) essa pré-condição é satisfeita e as coisas funcionam bem, simplesmente porque a probabilidade de ter dois MACs idênticos na mesma LAN, mesmo que não sejam exclusivos, é bastante baixa.

Outra razão é que simplesmente existem mais dispositivos do que endereços. Embora os endereços de 48 bits pareçam ter endereços suficientes para todos até o final dos dias, esse não é o caso.

O espaço de endereço é dividido em duas metades de 24 bits (é um pouco mais complicado, mas vamos ignorar os detalhes mesquinhos). Uma metade é a OUI que você pode registrar no IEEE e atribuir à sua empresa por cerca de 2000 dólares. Os 24 bits restantes, você faz o que quiser. Claro que você pode registrar vários OUIs, que é o que os jogadores maiores fazem.

Considere a Intel como um exemplo. Eles registraram um total de 7 OUIs, dando a eles um total de 116 milhões de endereços. A placa-mãe do meu computador (que usa um chipset X99), bem como a placa-mãe do meu laptop, bem como a placa-mãe de todo computador x86 que possuí durante os últimos 10 a 15 anos, tinham uma placa de rede Intel como parte do chipset. Certamente há mais de 116 milhões de computadores baseados em Intel no mundo. Assim, seus MACs não podem possivelmente ser únicos (em um sentido globalmente único).

Além disso, casos foram relatados de uh ... mais barato ... fabricantes simplesmente "roubando" endereços de outra pessoa OUI. Em outras palavras, eles apenas usaram algum endereço aleatório. Já ouvi falar de fabricantes que usam o mesmo endereço para uma gama completa de produtos também. Nenhum dos dois é realmente conforme ou faz muito sentido, mas o que você pode fazer a respeito. Essas placas de rede existem. Novamente: A probabilidade de que se torne um problema prático ainda é muito baixa se os endereços forem usados para o que eles pretendem, você precisa ter dois deles na mesma LAN até notar.

Agora, o que fazer com o seu problema?

A solução é talvez mais simples do que você pensa. Seus dispositivos de IoT provavelmente precisarão de alguma noção de tempo, geralmente o tempo é obtido automaticamente via NTP. A precisão típica do NTP está na faixa de microssegundos (sim, isso é micro, não milli). Acabei de executar ntpq -c rl para ter certeza e foi-me dito 2 ^-20 .

A probabilidade de dois dispositivos serem ligados pela primeira vez no mesmo microssegundo é muito baixa. Geralmente é possível acontecer (especialmente se você vender milhões deles em um tempo muito curto, parabéns pelo seu sucesso!), Com certeza. Mas não é muito provável - na prática isso não acontecerá. Assim, salve o tempo após a primeira inicialização em armazenamento permanente.

O tempo de inicialização do seu dispositivo IoT será o mesmo em todos os dispositivos. Exceto que isso não é verdade em tudo .
Dado um temporizador de alta resolução, os tempos de inicialização são consideravelmente diferentes, mesmo no mesmo dispositivo, sempre. É talvez apenas alguns ticks de clock diferentes (ou algumas centenas de milhares, se você ler algo como o contador de tempo da CPU), então não é muito original, mas com certeza adiciona alguma entropia. Da mesma forma, o tempo que leva connect para retornar na primeira vez que você acessa sua API site será um pouco, mas mensurável, diferente a cada vez. Da mesma forma, getaddrinfo terá uma quantidade de tempo um pouco diferente e mensurável para cada dispositivo ao procurar o nome do host da sua API da Web pela primeira vez.

Concatene essas três ou quatro fontes de entropia (endereço MAC, hora da primeira inicialização, tempo para inicializar pela primeira vez, tempo de conexão) e calcule um hash a partir disso. O MD5 se sairá bem para esse propósito. Lá você é único.

Embora isso não realmente garanta exclusividade, "praticamente" garante isso, com uma chance neglegível de falha. Você teria que ter dois dispositivos com MACs idênticos que são ativados pela primeira vez no mesmo microssegundo e levava exatamente o mesmo tempo para inicializar e se conectar ao seu site. Isso não vai acontecer. Se isso acontecer, você deve começar imediatamente a jogar na loteria, porque, com todas as aparências, você tem a garantia de ganhar.

Se, no entanto, "não acontecer" não for suficiente como garantia, basta passar a cada dispositivo um número sequencialmente crescente (gerado no servidor) na primeira vez que acessar sua API da web. Deixe o dispositivo armazenar esse número, pronto.

    

Answer 3

Como o problema aqui é realmente um problema XY, resolverei resolver isso: como obter um identificador exclusivo para uma peça de hardware na primeira vez que ele é inicializado sem precisar pré-carregar identificadores neles. Todos os bons métodos realmente se resumem a uma coisa: ter uma fonte de entropia.

Se o seu hardware tiver algo projetado para ser uma fonte de entropia de hardware (nota: isso é basicamente um requisito para qualquer implementação de dispositivo de IoT adequada, já que é necessário para TLS, então seu hardware deve ser projetado com esse em mente), apenas use isso. Se não, você precisa ser criativo.

Felizmente, quase todos os computadores já feitos têm uma excelente fonte de entropia: osciladores de cristal (relógios). A taxa de um dado cristal não é apenas dependente de mudanças sutis de temperatura, mas está sujeita mesmo à temperatura de forma não-linear. No entanto, para medir a entropia, você precisa de um segundo relógio para marcar o primeiro. O que isto significa é que, sempre que o seu computador tiver pelo menos dois relógios que você possa provar, você pode usar a taxa de um medida pelo outro como uma fonte de entropia de alta qualidade.

    

Answer 4

Não quero responder diretamente à pergunta, pois há outras respostas muito boas, mas, em vez disso, gostaria de sugerir outro valor mais adequado que possa estar disponível para uso como o ID do dispositivo.

Se suportado pelo seu hardware, você pode considerar o uso do UUID do SMBIOS. Este é um id único para a placa principal e, portanto, o dispositivo. Lembre-se de que até os dispositivos IoT podem ter várias NICs (LAN e WiFi), por isso, se você escolher a rota MAC, ainda precisará encontrar um método para escolher uma consistentemente.

Além disso, embora o UUID seja único, ele não deve ser usado para fins de segurança, pois é garantido que ele é único em um ambiente amigável.

    

Answer 5

Eu odeio assumir um problema XY porque muitas vezes o OP tem uma razão boa, embora complexa, de fazer as coisas do jeito que estão fazendo, mas você pode querer procurar outros métodos para gerar um identificador único para cada dispositivo que, como o endereço MAC, é "incorporado" ao dispositivo e não requer a geração de seu próprio identificador.

Se os dispositivos forem todos do mesmo fabricante (ou, melhor ainda, do mesmo modelo), você poderá usar o número de série para gerar o identificador. No entanto, isso não funciona tão bem em dispositivos de fabricantes diferentes, mesmo se você combinar o nome do fabricante e o número do modelo, devido a diferentes formatos de número de série e APIs possivelmente diferentes para obter o número de série no caso de dispositivos incorporados / proprietários . Uma alternativa para o número de série do dispositivo pode ser o número de série da placa-mãe, CPU ou disco rígido (acredito que o licenciamento do Windows usa uma combinação destes).

Vale lembrar também que os formatadores de sistemas de arquivos geralmente geram um ID exclusivo para cada sistema de arquivos. A menos que você esteja preparando todos os dispositivos da mesma imagem (o que eu recomendaria fazer, por motivos não relacionados), cada disco rígido já terá um ID exclusivo armazenado no sistema de arquivos que você pode usar.

Tendo dito isso, não há realmente nenhuma razão para usar endereços MAC, especialmente se, como parte de seu processo de provisionamento, você puder determinar que eles são de fato únicos (embora isso não deva ser necessário, assumindo que estamos falando não mais do que alguns milhares de dispositivos aqui). Claro, tenha em mente que o que você usa pode ser falsificado pelo dispositivo, então não confie nisso para autenticação em um ambiente não confiável (você disse que é uma configuração privada, então presumivelmente este é um ambiente "confiável" onde você não se preocupe com seu cliente falsificando seus próprios dispositivos contra seus próprios servidores, mas eles devem, obviamente, ter isso em mente se o gerenciamento dos dispositivos for entregue a terceiros ou usuários finais).