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


18

Em um cenário em que você controla o aprovisionamento do hardware e pode determinar que todos os dispositivos com o mesmo modelo de hardware têm realmente endereços MAC exclusivos para suas interfaces de rede, existem desvantagens em escrever código que use essa suposição? (Observe com base em algumas respostas: eu não vou escrever código de rede usando essa suposição. É apenas uma maneira discreta de ter um uuid por dispositivo sem ter que gerar e atualizar manualmente o disco rígido do dispositivo com um ID antes implantando no campo)

A história de fundo disso é que estou pesquisando a implementação de uma implementação do tipo IOT de hardware privado para um cliente. Forneceremos um conjunto de dispositivos de hardware com recursos de rede para instalação em locais remotos. Esses dispositivos serão comunicados novamente a uma API enviando mensagens. Para reduzir a complexidade da instalação, esperava enviar o endereço MAC da interface de rede no dispositivo na mensagem, para vincular essas mensagens a um "device_id" no lado da API. Meu pensamento é que, ao criar 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,


4
Os dispositivos virtuais geraram endereços MAC, que são únicos apenas no domínio de transmissão local. Há outros casos em que um mac pode colidir com outro - alguns dispositivos permitem atualizar o mac no firmware. Os dispositivos de alta disponibilidade têm um mac virtual em alguns casos. Estes são exemplos, eles podem não ser relevantes para o seu cenário.
Paul

9
As pessoas estão muito confusas sobre a singularidade dos endereços MAC. O que é único em um endereço MAC é a OUI atribuída a uma organização. Não é garantido que os endereços individuais dentro da OUI sejam exclusivos, e o IEEE diz que a atribuição dos endereços dentro da OUI fica completamente a critério do proprietário da OUI.
precisa

2
Além disso, é muito fácil para um indivíduo modificar o endereço MAC de um dispositivo. Isso significa que os endereços MAC podem ser clonados ou atribuídos de maneira a criar duplicatas. Um indivíduo que atribui um endereço MAC deve definir o bit U / L, mas isso raramente acontece.
precisa

5
Existem, deve haver endereços MAC idênticos na natureza. Por exemplo, a Intel registrou 7 OUIs, cada uma com 16,7 milhões de endereços em seu respectivo prefixo. São 116 milhões de endereços. Caramba, há uma placa de rede Intel em quase todas as placas - mãe. Você vai me dizer que há menos de 116 milhões de computadores no mundo? Não, claro que não. Mas a consequência lógica é: é claro que os MACs não são de forma alguma exclusivos. É apenas que a probabilidade de ter dois MACs idênticos na mesma LAN é bastante baixa, então isso não é um problema.
Damon

7
Acabei com dois endereços MAC idênticos na mesma rede por puro acaso - era um inferno depurar.
Christian

Respostas:


34

Com base nas suas declarações de que você pode confirmar durante o aprovisionamento que o MAC do fabricante é realmente único na rede de dispositivos que você está criando (o que não é, por si só, uma certeza, mesmo que deva ser), você provavelmente está bem, mas considere as seguintes perguntas:

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

  • 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 completamente ou substituir seu nic, será necessário associar o novo endereço à chave existente no banco de dados para garantir a continuidade da coleta de dados para o local de implantação?

  • Haverá alguma interface de manutenção pela qual um usuário (autorizado ou não) possa alterar o nicho no nível de ROM, driver ou SO? Um invasor pode apresentar falhas nos seus dados se modificar o MAC.

  • Seus dados serão unidos a outras fontes de dados usando o MAC como chave?

  • Você usará o MAC para qualquer finalidade de rede, além de simplesmente navegar na LAN da camada 2 à qual o dispositivo está conectado (com ou sem fio)?

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

Se suas respostas são

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

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

Lembre-se de que você não precisa de MACs globalmente exclusivos para fazer isso; você só precisa garantir 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 estão em LANs diferentes, você não pode ter uma chave de banco de dados em um MAC se ele nunca chamar sua API.


2
Apenas um aparte, em meados dos anos 90, um amigo de administrador de sistemas me disse que acabara de receber uma caixa de placas de rede de um fabricante com todas as mesmas placas de rede. Não tenho idéia de quão verdadeira é essa história, mas é a única do tipo que ouvi, além das alegações gerais de que alguns fabricantes "abusaram" de sua alocação uma vez ou outra.
Frank Thomas

Obrigado pela resposta detalhada. Eu acho que a única resposta que não corresponde é a # 3. Mas se precisarmos consertar um dispositivo com um nic quebrado, provavelmente substituiremos o dispositivo inteiro. O cliente controla a API e o hardware, e haverá controles físicos para impedir o acesso físico não autorizado aos dispositivos. Além disso, acho importante observar que muitos dos comentários / pontos aqui estão relacionados à tentativa de usar o MAC para fins de rede, que eu entendo que pode ser problemático assumir que é único. Isto é puramente para um uuid / dispositivo que não requer geradora
Matt Phillips

cont: o que eu entendo será específico do fabricante do dispositivo / nic.
Matt Phillips

7
@FrankThomas: Isso acontece . Estive em algumas convenções de computador em que um grupo de algumas dezenas de profissionais, na maioria, tinha poucas pessoas que disseram ter encontrado isso. Aparentemente, os departamentos de reforma de grandes fabricantes têm sido particularmente propensos a fazê-lo.
TOOGAM

@FrankThomas acabou de receber uma caixa de Nics ... todos tinham o mesmo NIC #
Dmitry Kudriavtsev

9

Endereços MAC não são exclusivos

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

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

Outro motivo é que simplesmente existem mais dispositivos do que endereços. Embora os endereços de 48 bits pareçam endereços suficientes para todo mundo até o fim 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). 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árias OUIs, que é o que os grandes players fazem.

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

Além disso, foram relatados casos de ... mais baratos ... fabricantes simplesmente "roubam" endereços da OUI de outra pessoa. Em outras palavras, eles apenas usaram algum endereço aleatório. Já ouvi falar de fabricantes que também usam o mesmo endereço para uma gama completa de produtos. Nada disso está realmente em conformidade ou faz muito sentido, mas o que você pode fazer sobre isso. Essas placas de rede existem. Novamente: A probabilidade de se tornar um problema prático ainda é muito baixa se os endereços forem usados ​​para o que eles se destinam, você precisará de dois na mesma LAN para notar.

Agora, o que fazer com seu problema?

A solução é talvez mais simples do que você pensa. Seus dispositivos 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 mili). Eu só corri ntpq -c rlpara ter certeza e me disseram 2 -20 .

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

O tempo de inicialização do seu dispositivo IoT será o mesmo em todos os dispositivos. Exceto que isso não é verdade .
Dado um timer de alta resolução, os tempos de inicialização são mensuráveis ​​diferentes mesmo no mesmo dispositivo, sempre. Talvez seja apenas alguns cliques do relógio diferentes (ou algumas centenas de milhares, se você ler algo como o contador de data e hora da CPU), portanto, não muito único, mas com certeza adiciona alguma entropia.
Da mesma forma, o tempo necessário connectpara retornar na primeira vez em que você acessa o site da API será um pouco, mas mensurável, diferente a cada vez. Da mesma forma, getaddrinfolevará um tempo mensurável ligeiramente diferente para cada dispositivo ao pesquisar 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, hora da inicialização pela primeira vez, hora da conexão) e calcule um hash a partir disso. O MD5 funcionará bem para esse propósito. Lá, você é único.

Embora isso não garanta verdadeiramente a singularidade, "praticamente" garante, com uma chance negligenciável de falha. Você precisaria ter dois dispositivos com MACs idênticos que foram ativados pela primeira vez no mesmo microssegundo e levaram exatamente o mesmo tempo para inicializar e conectar-se ao seu site. Isso não vai acontecer. Se isso acontecer, você deve começar a jogar imediatamente na loteria, porque, para todas as aparências, você está garantido para ganhar.

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


foi o comando deveria serntpq -c rl?
Tom

1
@ Tom: Sim, não sei por que lê "r1" na minha resposta, certamente tem que ser "rl" !? Corrigir isso:) #
1315 Damon

Eu estava gerenciando uma LAN há cerca de 30 anos e tínhamos MACs duplicados. O fornecedor usou o número de série da placa de E / S para gerar o MAC, mas esqueceu de incluir o número do modelo, e tínhamos dois modelos diferentes com o mesmo número de série. Felizmente, eles forneceram uma maneira de definir o MAC manualmente, então o substituímos em um dos dispositivos.
Barmar 13/10

Os endereços MAC geralmente são alocados pelo fornecedor da placa e não pelo fornecedor do chip. Portanto, a Intel só precisaria adquirir endereços para placas intel e não para chips intel.
Plug

Provavelmente vamos seguir um caminho semelhante ao seu último parágrafo. Obrigado pelas idéias!
Matt Phillips

2

Como o problema aqui é realmente um problema XY, abordarei a solução: como obter um identificador exclusivo para uma peça de hardware na primeira vez em que é inicializado sem ter que 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 adequada do dispositivo IoT, pois é necessário para o TLS, portanto, seu hardware deve ser projetado com isso em mente), basta usá-lo. Caso contrário, você precisa ser criativo.

Felizmente, quase todos os computadores já fabricados têm uma excelente fonte de entropia: osciladores de cristal (relógios). A taxa de um determinado cristal não depende apenas de mudanças sutis de temperatura, mas também está sujeita a histerese de temperatura de maneiras não lineares. No entanto, para medir a entropia, você precisa de um segundo relógio para cronometrar o primeiro. O que isto significa é que, sempre que seu computador tiver pelo menos dois relógios, você poderá experimentar a taxa de um, medida pelo outro, como uma fonte de entropia de alta qualidade.


1
É uma boa ideia, desde que a operação possa funcionar com um valor totalmente não determinístico. A questão é: se o dispositivo for reinicializado e o valor rederido, ele atenderá às necessidades de gerenciamento e continuidade.
Frank Thomas

0

Não quero responder diretamente à pergunta, pois há outras respostas muito boas, mas 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 SMBIOS UUID. Esse é um ID exclusivo para a placa principal e, portanto, o dispositivo. Lembre-se de que mesmo os dispositivos IoT podem ter várias NICs (LAN e WiFi); portanto, 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 seja único em um ambiente amigável.


0

Eu odeio assumir um problema XY porque, muitas vezes, o OP tem um bom motivo, embora complexo, para fazer as coisas da maneira que as faz, mas você pode querer procurar outros métodos para gerar um identificador exclusivo 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. Porém, isso não funciona tão bem em dispositivos de diferentes fabricantes, mesmo que você o combine com o nome e o número do modelo do fabricante, devido a diferentes formatos de número de série e possivelmente APIs diferentes para obter o número de série no caso de dispositivos proprietários / incorporados . Uma alternativa ao 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 use uma combinação destes).

Também vale lembrar que os formatadores de sistema 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, por razões não relacionadas), cada disco rígido já terá um ID exclusivo armazenado no sistema de arquivos que você pode usar.

No entanto, não há realmente nenhuma razão para não usar endereços MAC, especialmente se, como parte do processo de provisionamento, você puder determinar que eles são de fato exclusivos (embora isso nem sequer seja necessário, supondo que não falemos mais do que alguns milhares de dispositivos aqui). Obviamente, lembre-se de que tudo o que você usa pode ser falsificado pelo dispositivo, portanto não confie nisto para autenticação em um ambiente não confiável (você disse que é uma configuração privada, presumivelmente esse é um ambiente "confiável" onde você não preocupe-se com o seu cliente falsificando seus próprios dispositivos contra seus próprios servidores, mas obviamente eles devem ter isso em mente se o gerenciamento dos dispositivos for entregue a terceiros ou usuários finais).


Na verdade, não tenho certeza de que esse seja um problema XY, pelo menos não para o nosso público. O fato de o OP precisar de um mecanismo para o seu software identificar persistentemente um dispositivo e depois vincular valores logicamente a ele é claro e inequívoco. O OP não está fazendo a pergunta errada; se tivessem perguntado qual mecanismo poderiam usar para identificar os dispositivos, essa pergunta seria encerrada como offtopic por ter alguma relação com a programação e por não expressar um problema específico com o hardware ou software do computador. Pedir revisão por pares de uma decisão técnica não é XY.
19317 Frank Thomas

@FrankThomas Como eu disse, odeio assumir um problema XY. Não estou assumindo um problema XY aqui. Concordo que é perfeitamente aceitável solicitar a revisão de uma solução específica para um problema, mesmo que haja outras soluções. Mas as pessoas frequentemente acusam esse tipo de pergunta de ser um problema XY.
Micheal Johnson
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.