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 realmente possuem endereços MAC exclusivos para suas interfaces de rede, há alguma desvantagem em escrever código que use essa suposição? (Observação com base em algumas respostas: não vou escrever código de rede usando essa suposição. É apenas uma maneira simples de ter um uuid por dispositivo sem ter que gerar e atualizar manualmente o HDD do dispositivo com um ID antes implantando no campo)
A história por trás 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 se comunicarão com uma API enviando mensagens. Para reduzir a complexidade da configuração, eu 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 torná-lo algo que não precisa ser configurado no dispositivo antes do uso, ele pode apenas ser consultado 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 únicos e podemos controlar quando/se o dispositivo será substituído para saber que as mensagens para esse device_id agora terão um endereço MAC diferente.
Responder1
Com base em suas declarações, você pode confirmar durante o provisionamento que o MAC do fabricante é de fato único na rede de dispositivos que você está criando (o que não é por si só uma certeza, embora devesse ser), provavelmente você está bem em prosseguir, mas considere as seguintes questões:
Você está usando o MAC para verificações de segurança (autenticação, autorização)? Nesse caso, um MAC não é suficiente. Nem considere isso. 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 sua placa de rede?
Se você substituir um dispositivo por completo ou sua nic, precisará associar o novo endereço à chave existente em seu 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 a nic no nível da ROM, driver ou sistema operacional? Um invasor pode introduzir falhas em seus dados se modificar o MAC.
Seus dados serão unidos a outras fontes de dados usando MAC como chave?
Você usará o MAC para qualquer finalidade de rede que não seja 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 uma rede à qual um grande número de clientes temporários (como celulares de funcionários) se conectará?
Se suas respostas forem
NO, yes, no, no, no, no, no, private
então não consigo pensar em nenhuma falha real no seu plano.
Tenha em mente que você não precisa de MACs exclusivos globalmente para conseguir isso; você só precisa ter certeza de que o subconjunto de dispositivos da Internet que chamam sua API é exclusivo. Assim como uma nic duplicada atribuída em duas cidades diferentes não pode colidir porque 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.
Responder2
Endereços MAC não são únicos
Pode haver e haverá duplicatas com MACs. Existem várias razões para isso, uma delas é que elesprecisa não ser(globalmente) único.
O MAC deve ser exclusivo na rede local, para que o ARP/NDP possa fazer seu trabalho e o switch saiba para onde enviar os datagramas recebidos. Normalmente (não necessariamente) essa pré-condição é atendida e tudo funciona bem, simplesmente porque a probabilidade de ter dois MACs idênticos na mesma LAN, mesmo que não sejam únicos, é bastante baixa.
Outra razão é que simplesmente existem mais dispositivos do que endereços. Embora os endereços de 48 bits pareçam haver endereços suficientes para todos 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 pequenos detalhes). Metade é o OUI que você pode registrar no IEEE e atribuir à sua empresa por cerca de 2.000 dólares. Os 24 bits restantes, você faz o que quiser. Claro que você pode registrar vários OUIs, que é o que os grandes players fazem.
Veja a Intel como exemplo. Eles registraram um total de 7 OUIs, totalizando 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 dotodoO computador baseado em x86 que possuo nos últimos 10 a 15 anos tinha uma placa de rede Intel como parte do chipset. Certamente existem muito mais de 116 milhões de computadores baseados em Intel no mundo. Assim, seus MACsnão é possívelser único (no sentido de globalmente único).
Além disso, foram relatados casos de uh... mais baratos... fabricantes simplesmente "roubando" 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 linha completa de produtos. Nada disso está realmente em conformidade ou faz muito sentido, mas o que você pode fazer a respeito. Essas placas de rede existem. Novamente: a probabilidade de se tornar umpráticoo problema ainda é muito baixo se os endereços forem usados para o fim a que se destinam, você precisa ter dois delesna mesma LANaté mesmo notar.
Agora, o que fazer com o seu problema?
A solução talvez seja 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 apenas corri ntpq -c rlpara ter certeza e me disseram 2 -20 .
A probabilidade de dois dos seus dispositivos serem ligados pela primeira vez exatamente no mesmo microssegundo é muito baixa. Geralmente é possível que isso aconteça (especialmente se você vender milhões deles em muito pouco tempo, parabéns pelo seu sucesso!), claro. Mas não é muito provável – na prática isso não acontecerá. Assim, economize tempo após a primeira inicialização no armazenamento 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 temporizador de alta resolução, os tempos de inicialização são mensuravelmente diferentes, mesmo no mesmo dispositivo, sempre. Talvez sejam apenas alguns tiques de relógio diferentes (ou algumas centenas de milhares, se você ler algo como o contador de carimbo de data / hora da CPU), portanto não é muito exclusivo, mas com certeza adiciona alguma entropia.
Da mesma forma, o tempo que levaconnectretornar na primeira vez que você acessar seu site API será ligeiramente, mas mensuravelmente, diferente a cada vez. Da mesma forma, getaddrinfolevará um tempo mensurável e ligeiramente diferente para cada dispositivo ao pesquisar o nome de 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 primeira inicialização, tempo de conexão) e calcule um hash a partir disso. MD5 servirá perfeitamente para esse propósito. Pronto, você é único.
Embora isso nãoverdadeiramentegarante exclusividade, "praticamente" a garante, com uma chance insignificante de fracasso. Você teria que ter dois dispositivos com MACs idênticos que fossem ligados pela primeira vez no mesmo microssegundo e levassem 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, ao que tudo indica, você ganhará com certeza.
Se, no entanto, "não acontecerá" não for uma garantia suficiente, simplesmente passe a cada dispositivo um número crescente sequencialmente (gerado no servidor) na primeira vez que eles acessarem sua API web. Deixe o dispositivo armazenar esse número, pronto.
Responder3
Como o problema aqui é realmente um problema XY, abordarei a solução disso: como obter um identificador exclusivo para uma peça de hardware na primeira vez que ele inicializa, sem precisar pré-carregar identificadores nele. Todos os bons métodos 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 de dispositivo IoT, já que é necessário para TLS, então seu hardwaredeveser projetado com isso em mente), apenas use isso. Caso contrário, você precisa ser criativo.
Felizmente, quase todos os computadores já fabricados possuem 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 está sujeita até mesmo à temperatura.histeresede maneiras não lineares. No entanto, para medir a entropia, é necessário um segundo relógio para cronometrar o primeiro. O que isso significa é que, sempre que seu computador tiver pelo menos dois relógios que você possa amostrar, você poderá usar a taxa de um medida pelo outro como uma fonte de entropia de altíssima qualidade.
Responder4
Eu odeio assumir um problema XY porque muitas vezes o OP tem uma razão boa, embora complexa, para fazer as coisas da maneira que estão fazendo, 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 fabricantes diferentes, mesmo se você combiná-lo com o nome do fabricante e o número do modelo, devido aos diferentes formatos de número de série e possivelmente às diferentes APIs para obter o número de série no caso de dispositivos incorporados/proprietários. . 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 usa uma combinação destes).
Também vale lembrar que os formatadores de sistemas de arquivos normalmente geram um ID exclusivo para cada sistema de arquivos. A menos que você esteja preparando todos os dispositivos a partir 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.
Dito isto, não há realmente nenhuma razãonãousar endereços MAC, especialmente se, como parte do seu processo de provisionamento, você puder determinar que eles são de fato únicos (embora isso nem deva ser necessário, supondo que não estejamos falando de mais do que alguns milhares de dispositivos aqui). Claro, tenha em mente que tudo 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 preocupam com o fato de seu cliente falsificar seus próprios dispositivos contra seus próprios servidores, mas obviamente devem ter isso em mente se o gerenciamento dos dispositivos for entregue a terceiros ou usuários finais).