Razones para no asumir que la dirección MAC del dispositivo es única

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, ¿existen inconvenientes para escribir código que use ese supuesto? (Nota basada en algunas respuestas: no voy a escribir código de red utilizando esta suposición. Solo pretende ser una forma de bajo contacto de tener un uuid por dispositivo sin tener que generar y actualizar manualmente el HDD del dispositivo con una identificación antes desplegarse en el campo)

La historia de fondo es que estoy investigando la implementación de una implementación de tipo IOT de hardware privado para un cliente. Suministraremos un conjunto de dispositivos de hardware con capacidades de red para instalar en ubicaciones remotas. Estos dispositivos se comunicarán con una API enviando 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 opinión es que al hacer algo que no tiene que configurarse en el dispositivo antes de su uso, solo se puede consultar durante el funcionamiento normal. Puedo suponer con seguridad que podemos determinar que las direcciones MAC de cada dispositivo son de hecho únicas,

Según sus declaraciones de que puede confirmar durante el aprovisionamiento que el MAC del fabricante es de hecho único dentro de la red de dispositivos que está creando (lo cual no es en sí mismo una certeza, aunque debería serlo), probablemente esté procediendo bien, pero considere las siguientes preguntas:

• ¿Está utilizando el MAC para controles de seguridad (autenticación, autorización)? Si es así, un MAC no es suficiente. Ni siquiera lo consideres. Use una estructura criptográfica y transmita cualquier solicitud de autenticación de forma segura.

• ¿Tiene 48 bits de ancho suficiente? Probablemente lo sea, pero vale la pena preguntar.

• ¿Alguna vez necesitará 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 el MAC.

• ¿Se unirán sus datos con otras fuentes de datos utilizando MAC como clave?

• ¿Alguna vez usará el MAC para cualquier propósito de red que no sea simplemente navegar la capa 2 LAN a la que está conectado el dispositivo (con cable o inalámbrico)?

• ¿La LAN a la que están conectados sus dispositivos, será una red privada o una gran cantidad de clientes transitorios (como los teléfonos celulares de los empleados)?

Si tus respuestas son

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

entonces no puedo pensar en ningún defecto real en tu plan.

Tenga en cuenta que no necesita MACs globales únicos para lograr esto; solo necesita asegurarse de que el subconjunto de dispositivos de Internet que llaman a su API sean únicos. Al igual que un nic duplicado asignado en dos ciudades diferentes no puede colisionar porque están en diferentes LAN, no puede tener una colisión de clave de base de datos en un MAC si nunca llama a su API.

Las direcciones MAC no son únicas

Puede haber, y habrá duplicados con MAC. Hay varias razones para eso, una de ellas es que no necesitan ser (globalmente) únicos.

El MAC debe ser único en la red local, por lo que ARP / NDP puede hacer su trabajo, y el conmutador sabe a dónde enviar los datagramas entrantes. Por lo general (no necesariamente) esa condición previa se cumple y las cosas funcionan bien, simplemente porque la probabilidad de tener dos MAC idénticos en la misma LAN, incluso si no son únicos, es bastante baja.

Otra razón es que simplemente existen más dispositivos que direcciones. Si bien las direcciones de 48 bits parecen que hay 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 puede registrar en el IEEE y asignar a su empresa por alrededor de 2000 dólares. Los 24 bits restantes, haces lo que quieras. Por supuesto, puede registrar varias OUI, que es lo que hacen los jugadores más grandes.

Tome 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 conjunto de chips X99), así como la placa base de mi computadora portátil y la placa base de cada computadora basada en x86 que he tenido durante los últimos 10-15 años tenía una tarjeta de red Intel como parte del conjunto de chips. Ciertamente hay más de 116 millones de computadoras basadas en Intel en el mundo. Por lo tanto, sus MAC no pueden ser únicos (en un sentido globalmente único).

Además, se han reportado casos de fabricantes ... más baratos ... simplemente "robando" direcciones de la OUI de otra persona. En otras palabras, solo usaron alguna dirección aleatoria. También he oído hablar de fabricantes que solo usan la misma dirección para una gama completa de productos. Nada de eso es realmente conforme o tiene mucho sentido, pero ¿qué puede hacer al respecto? Estas tarjetas de red existen. Una vez más: la probabilidad de que se convierta en un problema práctico sigue siendo muy baja si las direcciones se utilizan para lo que están destinadas, debe tener dos de ellas en la misma LAN para incluso darse cuenta.

Ahora, ¿qué hacer con tu problema?

La solución es quizás más simple de lo que piensas. Sus dispositivos IoT probablemente necesitarán alguna noción de tiempo, generalmente 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 en el mismo microsegundo preciso es muy baja. En general, es posible que suceda (especialmente si vende millones de ellos en muy poco tiempo, ¡felicidades por su éxito!), Claro. Pero no es muy probable, en la práctica no sucederá. Por lo tanto, ahorre tiempo después del primer arranque en la tienda permanente.

El tiempo de arranque de su dispositivo IoT será el mismo en todos los dispositivos. Excepto que eso no es cierto en absoluto .
Dado 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 pocos cientos de miles, si lees algo como el contador de sello de tiempo de la CPU), por lo que no es muy único en absoluto, pero seguro agrega algo de entropía.
Del mismo modo, el tiempo que lleva connectregresar la primera vez que accede a su sitio API será leve, pero mensurable, diferente cada vez. Del mismo modo, getaddrinfotomará una cantidad de tiempo medible ligeramente diferente para cada dispositivo cuando busque 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 arrancar 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 no garantiza realmente la unicidad, "prácticamente" lo garantiza, con una posibilidad insignificante de fracaso. Tendría que tener dos dispositivos con MAC idénticos que se enciendan por primera vez en el mismo microsegundo, y que se hayan tomado exactamente el mismo tiempo para arrancar y conectarse a su sitio. Eso no va a suceder. Si sucede, inmediatamente debe comenzar a jugar a la lotería porque, según todas las apariencias, tiene la garantía de ganar.

Sin embargo, si "no va a suceder" no es lo suficientemente bueno como garantía, simplemente transfiera a cada dispositivo un número creciente secuencial (generado en el servidor) la primera vez que acceda a su API web. Deje que el dispositivo almacene ese número, listo.

Dado que el problema aquí es realmente un problema XY, voy a abordar la resolución de eso: cómo obtener un identificador único para una pieza de hardware la primera vez que se inicia sin tener que precargar los identificadores en ellos. Todos los buenos métodos realmente se reducen a una sola 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 del dispositivo IoT, ya que es necesario para TLS, por lo que su hardware debe diseñarse con eso en mente), solo úselo. Si no, tienes que ser creativo.

Afortunadamente, casi todas las computadoras fabricadas tienen una excelente fuente de entropía: osciladores de cristal (relojes). La velocidad de un cristal dado no solo depende de cambios sutiles de temperatura, sino que está sujeta incluso a histéresis de temperatura de manera no lineal. Sin embargo, para medir la entropía, necesita un segundo reloj para cronometrar el primero. Lo que esto significa es que, siempre que su computadora tenga al menos dos relojes que pueda muestrear, puede usar la tasa de uno medida por el otro como una fuente de entropía de muy alta calidad.

No quiero responder directamente a la pregunta, ya que hay otras respuestas muy buenas, pero en cambio me gustaría sugerir otro valor más adecuado que podría estar disponible para usar como identificación del dispositivo.

Si su hardware lo admite, podría considerar usar el UUID SMBIOS. Esta es una identificación única para la placa base y, por lo tanto, para el dispositivo. Tenga en cuenta que incluso los dispositivos IoT pueden tener múltiples NIC (LAN y WiFi), por lo que si elige la ruta MAC, aún necesita encontrar un método para elegir una de manera consistente.

Además, aunque el UUID es único, no debe utilizarse con fines de seguridad, ya que solo se garantiza que sea único en un entorno amigable.

Odio asumir un problema XY porque a menudo el OP tiene una buena aunque compleja razón para hacer las cosas de la manera en que las hacen, pero es posible que desee 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 usar 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 diferentes formatos de número 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 usan una combinación de estos).

También vale la pena recordar que los formateadores del sistema de archivos generalmente generan una ID única para cada sistema de archivos. A menos que esté preparando todos los dispositivos a partir de la misma imagen (lo que recomendaría hacer, por razones no relacionadas), cada disco duro ya tendrá una ID única almacenada en el sistema de archivos que puede usar.

Sin embargo, una vez dicho esto, en realidad no hay razón para no usar direcciones MAC, especialmente si como parte de su proceso de aprovisionamiento puede determinar que en realidad son únicas (aunque esto no debería ser necesario, suponiendo que no estamos hablando más de unos pocos miles de dispositivos aquí). Por supuesto, tenga en cuenta que cualquier cosa que use puede ser falsificada por el dispositivo, así que no confíe en esto para la autenticación en un entorno no confiable (usted dijo que es una configuración privada, por lo que presumiblemente este es un entorno "confiable" donde no se preocupan de que su cliente falsifique sus propios dispositivos contra sus propios servidores, pero obviamente deben tener esto en cuenta si la administración de los dispositivos se transfiere a terceros o usuarios finales).