En un escenario en el que usted controla el aprovisionamiento del hardware y puede determinar que todos los dispositivos con el mismo modelo de hardware tienen direcciones MAC únicas para sus interfaces de red, ¿existe alguna desventaja en escribir código que utilice esa suposición? (Nota basada en algunas respuestas: no voy a escribir código de red usando esta suposición. Solo pretende ser una forma sencilla de tener un uuid por dispositivo sin tener que generar y actualizar manualmente el disco duro del dispositivo con una identificación antes desplegando al campo)
La historia de fondo de esto es que estoy investigando la implementación de una implementación de tipo IOT de hardware privado para un cliente. Proporcionaremos un conjunto de dispositivos de hardware con capacidades de red para instalar en ubicaciones remotas. Estos dispositivos luego se comunicarán con una API mediante el envío de mensajes. Para reducir la complejidad de la configuración, esperaba enviar la dirección MAC de la interfaz de red en el dispositivo en el mensaje, para vincular estos mensajes a un "device_id" en el lado de la API. Mi idea es que al convertirlo en algo que no tenga que configurarse en el dispositivo antes de su uso, simplemente se puede consultar durante el funcionamiento normal. Puedo asumir con seguridad que podemos determinar que las direcciones MAC de cada dispositivo son, de hecho, únicas, y podemos controlar cuándo/si se reemplaza el dispositivo para saber que los mensajes para ese dispositivo_id ahora tendrán una dirección MAC diferente.
Respuesta1
Según sus declaraciones de que puede confirmar durante el aprovisionamiento que la MAC del fabricante es de hecho única dentro de la red de dispositivos que está creando (lo cual no es en sí mismo una certeza, aunque debería serlo), probablemente esté bien continuar. pero considere las siguientes preguntas:
¿Está utilizando la MAC para controles de seguridad (autenticación, autorización)? Si es así, una MAC no es suficiente. Ni siquiera lo consideres. Utilice una estructura criptográfica y transmita cualquier solicitud de autenticación de forma segura.
¿48 bits son lo suficientemente anchos? Probablemente lo sea, pero vale la pena preguntarlo.
¿Alguna vez necesitarás reparar un dispositivo reemplazando su NIC?
Si reemplaza un dispositivo en su totalidad, o reemplaza su NIC, ¿necesitará poder asociar la nueva dirección a la clave existente en su base de datos para garantizar la continuidad de la recopilación de datos para la ubicación de implementación?
¿Habrá alguna interfaz de mantenimiento mediante la cual un usuario (autorizado o no) pueda cambiar la NIC a nivel de ROM, controlador o sistema operativo? Un atacante podría introducir fallas en sus datos si modificara la MAC.
¿Alguna vez sus datos se unirán a otras fuentes de datos utilizando MAC como clave?
¿Usará alguna vez la MAC para algún propósito de red que no sea simplemente navegar por la LAN de capa 2 a la que está conectado el dispositivo (cableado o inalámbrico)?
¿La LAN a la que están conectados sus dispositivos será una red privada o una a la que se conectarán una gran cantidad de clientes transitorios (como los teléfonos móviles de los empleados)?
Si tus respuestas son
NO, yes, no, no, no, no, no, private
Entonces no se me ocurre ningún defecto real en tu plan.
Tenga en cuenta que no necesita MAC globalmente únicas para lograr esto; sólo necesita asegurarse de que el subconjunto de dispositivos de Internet que llaman a su API sea único. Al igual que una NIC duplicada asignada en dos ciudades diferentes no puede colisionar porque están en LAN diferentes, no puede tener una colisión de claves de base de datos en una MAC si nunca llama a su API.
Respuesta2
Las direcciones MAC no son únicas
Puede haber y habrá duplicados con MAC. Hay varias razones para ello, una es queNecesita no ser(globalmente) único.
La MAC debe ser única en la red local, para que ARP/NDP pueda hacer su trabajo y el conmutador sepa a dónde enviar los datagramas entrantes. Por lo general (no necesariamente) esa condición previa se cumple y todo funciona bien, simplemente porque la probabilidad de tener dos MAC idénticas en la misma LAN, incluso si no son únicas, es bastante baja.
Otra razón es que simplemente existen más dispositivos que direcciones. Si bien las direcciones de 48 bits suenan como si hubiera suficientes direcciones para todos hasta el final de los días, ese no es el caso.
El espacio de direcciones se divide en dos mitades de 24 bits (es un poco más complicado, pero ignoremos los pequeños detalles). La mitad es el OUI que puedes registrar en el IEEE y asignar a tu empresa por unos 2000 dólares. Los 24 bits restantes, haces lo que quieras. Por supuesto, puedes registrar varios OUI, que es lo que hacen los jugadores más importantes.
Tomemos a Intel como ejemplo. Han registrado un total de 7 OUI, lo que les da un total de 116 millones de direcciones.
La placa base de mi computadora (que usa un chipset X99), así como la placa base de mi computadora portátil y la placa base decadaLa computadora basada en x86 que he tenido durante los últimos 10 a 15 años tenía una tarjeta de red Intel como parte del chipset. Ciertamente hay más de 116 millones de computadoras basadas en Intel en el mundo. Por lo tanto, sus MACno es posibleser único (en el sentido de globalmente único).
Además, se han informado casos de fabricantes más baratos que simplemente "roban" direcciones del OUI de otra persona. En otras palabras, simplemente usaron una dirección aleatoria. He oído hablar de fabricantes que también utilizan la misma dirección para una gama completa de productos. Nada de eso es realmente conforme ni tiene mucho sentido, pero ¿qué puedes hacer al respecto? Estas tarjetas de red existen. Nuevamente: la probabilidad de que se convierta en unprácticoEl problema sigue siendo muy bajo si las direcciones se utilizan para lo que están destinadas, es necesario tener dos de ellas.en la misma LANsiquiera darse cuenta.
Ahora, ¿qué hacer con tu problema?
La solución quizá sea más sencilla de lo que crees. Lo más probable es que sus dispositivos IoT necesiten cierta noción del tiempo; normalmente el tiempo se obtiene automáticamente a través de NTP. La precisión típica de NTP está en el rango de microsegundos (sí, eso es micro, no mili). Simplemente corrí ntpq -c rlpara estar seguro y me dijeron 2 -20 .
La probabilidad de que dos de sus dispositivos se enciendan por primera vez exactamente en el mismo microsegundo es muy baja. Generalmente es posible que suceda (especialmente si vendes millones de ellos en muy poco tiempo, ¡felicidades por tu éxito!), claro. Pero no es muy probable: en la práctica no sucederá. Por lo tanto, ahorre tiempo después del primer inicio en la tienda permanente.
El tiempo de inicio de su dispositivo IoT será el mismo en todos los dispositivos.Excepto que eso no es cierto en absoluto..
Con un temporizador de alta resolución, los tiempos de arranque son considerablemente diferentes incluso en el mismo dispositivo, cada vez. Tal vez solo sean unos pocos tics de reloj diferentes (o unos cientos de miles, si lees algo como el contador de marca de tiempo de la CPU), por lo que no es del todo único, pero seguro que agrega algo de entropía.
Del mismo modo, el tiempo que tardaconnectpara regresar la primera vez que acceda a su sitio API será ligeramente, pero mensurable, diferente cada vez. De manera similar, getaddrinfotomará una cantidad de tiempo ligeramente diferente y mensurable para cada dispositivo al buscar el nombre de host de su API web por primera vez.
Concatene esas tres o cuatro fuentes de entropía (dirección MAC, hora del primer encendido, hora de inicio por primera vez, hora de conexión) y calcule un hash a partir de eso. MD5 funcionará bien para ese propósito. Ahí eres único.
Si bien eso norealmentegarantiza la unicidad, "prácticamente" la garantiza, con una posibilidad insignificante de fracaso. Tendría que tener dos dispositivos con MAC idénticas que se enciendan por primera vez en el mismo microsegundo y que tardaron exactamente el mismo tiempo en arrancar y conectarse a su sitio. Eso no va a pasar. Si esto sucede, deberías empezar a jugar a la lotería inmediatamente porque, según todas las apariencias, tienes la garantía de ganar.
Sin embargo, si "no sucederá" no es una garantía suficiente, simplemente pase a cada dispositivo un número creciente secuencial (generado en el servidor) la primera vez que acceda a su API web. Deja que el dispositivo almacene ese número, listo.
Respuesta3
Dado que el problema aquí es realmente un problema XY, voy a abordar su solución: cómo obtener un identificador único para una pieza de hardware la primera vez que arranca sin tener que precargar identificadores en ella. Todos los buenos métodos realmente se reducen a una cosa: tener una fuente de entropía.
Si su hardware tiene algo diseñado para ser una fuente de entropía de hardware (nota: esto es básicamente un requisito para cualquier implementación adecuada de dispositivo IoT, ya que es necesario para TLS, entonces su hardwaredeberíadiseñarse con eso en mente), simplemente úselo. Si no, hay que ser creativo.
Afortunadamente, casi todas las computadoras jamás fabricadas tienen una excelente fuente de entropía:osciladores de cristal(relojes). La velocidad de un cristal determinado no sólo depende de cambios sutiles de temperatura, sino que está sujeta incluso a la temperatura.histéresisde manera no lineal. Sin embargo, para medir la entropía, se necesita un segundo reloj para medir el tiempo del primero. Lo que esto significa es que, siempre que su computadora tenga al menos dos relojes que pueda muestrear, puede usar la velocidad de uno medida por el otro como una fuente de entropía de muy alta calidad.
Respuesta4
Odio asumir un problema XY porque a menudo el OP tiene una razón buena, aunque compleja, para hacer las cosas de la forma en que las hace, pero es posible que desees buscar otros métodos para generar un identificador único para cada dispositivo que, como la dirección MAC. , está "integrado" en el dispositivo y no requiere generar su propio identificador.
Si todos los dispositivos son del mismo fabricante (o, mejor aún, del mismo modelo), puede utilizar el número de serie para generar el identificador. Sin embargo, esto no funciona tan bien en dispositivos de diferentes fabricantes, incluso si lo combina con el nombre del fabricante y el número de modelo, debido a los diferentes formatos de números de serie y posiblemente diferentes API para obtener el número de serie en el caso de dispositivos integrados/propietarios. . Una alternativa al número de serie del dispositivo podría ser el número de serie de la placa base, la CPU o el disco duro (creo que las licencias de Windows utilizan una combinación de estos).
También vale la pena recordar que los formateadores de sistemas de archivos generalmente generan una identificación única para cada sistema de archivos. A menos que esté preparando todos los dispositivos a partir de la misma imagen (lo cual recomendaría hacer, por razones no relacionadas), cada disco duro ya tendrá una identificación única almacenada en el sistema de archivos que puede usar.
Dicho esto, no hay realmente ninguna razónnousar direcciones MAC, especialmente si como parte de su proceso de aprovisionamiento puede determinar que de hecho son únicas (aunque esto ni siquiera debería ser necesario, asumiendo que no estamos hablando de más de unos pocos miles de dispositivos). Por supuesto, tenga en cuenta que cualquier cosa que utilice puede ser falsificada por el dispositivo, así que no confíe en esto para la autenticación en un entorno que no es de confianza (usted dijo que es una configuración privada, por lo que presumiblemente se trata de un entorno "confiable" en el que no preocuparse de que su cliente suplante sus propios dispositivos contra sus propios servidores, pero obviamente deben tener esto en cuenta si la gestión de los dispositivos se entrega a terceros o usuarios finales).