Причины не предполагать, что MAC-адрес устройства является уникальным

Question

В сценарии, где вы контролируете предоставление оборудования и можете определить, что все устройства с одинаковой моделью оборудования действительно имеют уникальные MAC-адреса для своих сетевых интерфейсов, есть ли недостатки в написании кода, использующего это предположение? (Примечание, основанное на некоторых ответах: я не собираюсь писать сетевой код, используя это предположение. Предполагается, что это простой способ получения uuid для каждого устройства без необходимости вручную генерировать и обновлять жесткий диск устройства с идентификатором перед его развертыванием в полевых условиях).

Предыстория этого заключается в том, что я исследую реализацию частной аппаратной реализации типа IOT для клиента. Мы предоставим набор аппаратных устройств с сетевыми возможностями для установки в удаленных местах. Затем эти устройства будут связываться с API, отправляя сообщения. Чтобы уменьшить сложность настройки, я надеялся отправить MAC-адрес сетевого интерфейса на устройстве в сообщении, чтобы связать эти сообщения с идентификатором "device_id" на стороне API. Я думаю, что, сделав его чем-то, что не нужно настраивать на устройстве перед использованием, его можно просто запросить во время нормальной работы. Я могу с уверенностью предположить, что мы можем определить, что MAC-адреса каждого устройства на самом деле уникальны, и мы можем контролировать, когда / если устройство будет заменено, чтобы знать, что сообщения для этого device_id теперь будут иметь другой MAC-адрес.

Answer 1

Основываясь на ваших заявлениях, которые вы можете подтвердить во время предоставления, что MAC производителя фактически уникален в сети устройств, которые вы создаете (что само по себе не является определением, даже если так и должно быть), вы, вероятно, продолжаете нормально, но рассмотрим следующие вопросы:

• Используете ли вы MAC для проверки безопасности (аутентификация, авторизация)? Если это так, MAC недостаточно. Даже не думай об этом. Используйте криптографическую структуру и безопасно передавайте любые запросы авторизации.

• Достаточно ли 48 бит? Возможно, но стоит спросить.

• Вам когда-нибудь нужно будет ремонтировать устройство, заменяя его ник?

• Если вы полностью замените устройство или замените его ник, вам нужно будет иметь возможность связать новый адрес с существующим ключом в вашей базе данных, чтобы обеспечить непрерывность сбора данных для места развертывания?

• Будет ли какой-либо интерфейс обслуживания, с помощью которого пользователь (авторизованный или нет) может изменить ник на уровне ПЗУ, драйвера или ОС? Злоумышленник может внести ошибки в ваши данные, если они будут изменять MAC.

• Будут ли ваши данные когда-либо объединяться с другими источниками данных, использующими MAC в качестве ключа?

• Будете ли вы когда-нибудь использовать MAC для каких-либо сетевых целей, кроме простой навигации по локальной сети уровня 2, к которой подключено устройство (проводное или беспроводное)?

• Будет ли локальная сеть, к которой подключены ваши устройства, частной сетью или сетью, к которой будет подключаться большое количество временных клиентов (например, мобильных телефонов сотрудников)?

Если ваши ответы

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

тогда я не могу думать ни о каком реальном недостатке в вашем плане.

Имейте в виду, вам не нужны глобально уникальные MAC для этого; вам просто нужно убедиться, что подмножество интернет-устройств, которые вызывают ваш API, являются уникальными. Подобно тому, как дубликаты имен, назначенные в двух разных городах, не могут столкнуться, потому что они находятся в разных локальных сетях, вы не можете столкнуться с ключом базы данных на MAC, если он никогда не вызывает ваш API.

Answer 2

MAC-адреса не являются уникальными

Могут быть и будут дубликаты с MAC. Для этого есть несколько причин, одна из которых заключается в том, что они не должны быть (глобально) уникальными.

MAC-адрес должен быть уникальным в локальной сети, поэтому ARP/NDP может выполнять свою работу, и коммутатор знает, куда отправлять входящие дейтаграммы. Обычно (не обязательно) это предварительное условие выполняется, и все работает просто отлично, просто потому, что вероятность наличия двух одинаковых MAC-адресов в одной локальной сети, даже если они не уникальны, довольно низкая.

Другая причина в том, что просто существует больше устройств, чем есть адресов. В то время как 48-битные адреса звучат так, что адресов для всех достаточно до конца дней, это не так.

Адресное пространство разделено на две 24-битные половины (это немного сложнее, но давайте проигнорируем мелкие детали). Одна половина - это OUI, который вы можете зарегистрировать в IEEE и присвоить своей компании примерно за 2000 долларов. Оставшиеся 24 бита, вы делаете все, что хотите. Конечно, вы можете зарегистрировать несколько OUI, что делают крупные игроки.

Возьмите Intel в качестве примера. Они зарегистрировали в общей сложности 7 OUI, что дало им в общей сложности 116 миллионов адресов.
На материнской плате моего компьютера (которая использует чипсет X99), а также на материнской плате моего ноутбука, а также на материнской плате каждого компьютера на базе x86, которым я владел в течение последних 10–15 лет, в составе чипсета была сетевая карта Intel. Конечно, в мире насчитывается более 116 миллионов компьютеров на базе Intel. Таким образом, их MAC не могут быть уникальными (в некотором смысле глобально уникальными).

Также сообщалось о случаях, когда ... дешевле ... производители просто "крадут" адреса у чужого OUI. Другими словами, они просто использовали какой-то случайный адрес. Я слышал о производителях, которые просто используют один и тот же адрес для полного ассортимента продукции. Ничего из этого не соответствует действительности и не имеет большого смысла, но что вы можете с этим поделать. Эти сетевые карты существуют. Опять же: вероятность того, что это станет практической проблемой, все еще очень мала, если адреса используются для того, для чего они предназначены, вам нужно иметь два из них в одной локальной сети, чтобы даже заметить.

Теперь, что делать с вашей проблемой?

Решение может быть проще, чем вы думаете. Вашим IoT-устройствам, скорее всего, понадобится определенное время, обычно время автоматически определяется через NTP. Типичная точность NTP находится в микросекундном диапазоне (да, это микро, а не милли). Я просто запустил ntpq -c rl чтобы быть уверенным, и мне сказали 2 ^-20.

Вероятность того, что два ваших устройства будут включены впервые в одну и ту же микросекунду, очень мала. Это обычно возможно (особенно, если вы продаете миллионы из них в очень короткие сроки, поздравляю вас с успехом!), Конечно. Но это не очень вероятно - на практике этого не произойдет. Таким образом, сэкономьте время после первой загрузки в постоянном магазине.

Время загрузки вашего устройства IoT будет одинаковым на всех устройствах. За исключением того, что это совсем не так.
Учитывая таймер высокого разрешения, время загрузки измеримо различается даже на одном устройстве, каждый раз. Это может быть только несколько разных тактов (или несколько сотен тысяч, если вы читаете что-то вроде счетчика меток времени процессора), поэтому не совсем уникально, но это, безусловно, добавляет энтропии.
Точно так же время, необходимое для connect при первом обращении к вашему сайту API, будет немного, но в разной степени отличаться каждый раз. Аналогично, при первом поиске имени хоста вашего веб-API getaddrinfo займет немного другое, измеримое количество времени для каждого устройства.

Объедините эти три или четыре источника энтропии (MAC-адрес, время первого включения, время первой загрузки, время подключения) и вычислите из этого хеш. MD5 отлично подойдет для этой цели. Там ты уникален.

Хотя это на самом деле не гарантирует уникальность, это "в значительной степени" гарантирует это с незначительной вероятностью провала. Вам потребуется два устройства с одинаковыми MAC-адресами, которые впервые включаются в одну и ту же микросекунду и требуют одинакового времени для загрузки и подключения к вашему сайту. Этого не произойдет. Если это произойдет, вы должны немедленно начать играть в лотерею, потому что, по всей видимости, вы гарантированно выиграете.

Однако если "не произойдет" недостаточно для гарантии, просто передайте каждому устройству последовательно увеличивающееся число (генерируемое на сервере) при первом обращении к вашему веб-API. Пусть устройство запомнит этот номер, готово.

Answer 3

Поскольку проблема здесь действительно является проблемой XY, я собираюсь решить ее: как получить уникальный идентификатор для части оборудования при первой загрузке, без предварительной загрузки идентификаторов на них. Все хорошие методы действительно сводятся к одному: иметь источник энтропии.

Если в вашем оборудовании есть что-то, предназначенное для аппаратного источника энтропии (обратите внимание: это в основном требование для любой правильной реализации устройства IoT, поскольку оно необходимо для TLS, поэтому ваше оборудование должно быть спроектировано с учетом этого), просто используйте это. Если нет, вы должны проявить творческий подход.

К счастью, почти у каждого когда-либо созданного компьютера был отличный источник энтропии: кварцевые генераторы (часы). Скорость данного кристалла не только зависит от тонких изменений температуры, но и подвергается даже температурному гистерезису нелинейными способами. Однако, чтобы измерить энтропию, вам нужны вторые часы, чтобы отсчитать первые. Это означает, что всякий раз, когда у вашего компьютера есть по крайней мере две тактовые частоты, которые вы можете сэмплировать, вы можете использовать частоту одного, измеренную другим, как источник энтропии очень высокого качества.

Answer 4

Я не хочу прямо отвечать на вопрос, поскольку есть и другие очень хорошие ответы, но вместо этого я хотел бы предложить другое более подходящее значение, которое может быть доступно для использования в качестве идентификатора устройства.

Если поддерживается вашим оборудованием, вы можете рассмотреть возможность использования UBID SMBIOS. Это уникальный идентификатор для материнской платы и, следовательно, устройства. Имейте в виду, что даже устройства IoT могут иметь несколько сетевых адаптеров (LAN & WiFi), поэтому, если вы выбираете маршрут MAC, вам все равно нужно найти способ выбора одного из них.

Кроме того, хотя UUID уникален, его не следует использовать в целях безопасности, поскольку он гарантированно будет уникальным только в дружественной среде.

Answer 5

Я ненавижу предполагать проблему XY, потому что часто у OP есть хорошая, хотя и сложная причина для того, чтобы делать вещи так, как они это делают, но вам может понадобиться поискать другие методы для генерации уникального идентификатора для каждого устройства, такого как MAC-адрес , "встроен" в устройство и не требует генерации собственного идентификатора.

Если все устройства от одного производителя (или, что еще лучше, от одной модели), вы можете использовать серийный номер для генерации идентификатора. Однако это не очень хорошо работает на устройствах разных производителей, даже если вы комбинируете его с именем производителя и номером модели из-за разных форматов серийных номеров и, возможно, разных API для получения серийного номера в случае встроенных / проприетарных устройств , Альтернативой серийному номеру устройства может быть серийный номер материнской платы, процессора или жесткого диска (я полагаю, что лицензирование Windows использует их комбинацию).

Также стоит помнить, что форматеры файловой системы обычно генерируют уникальный идентификатор для каждой файловой системы. Если вы не подготавливаете все устройства из одного образа (что я бы порекомендовал сделать по несвязанным причинам), каждый жесткий диск уже будет иметь уникальный идентификатор, хранящийся в файловой системе, которую вы можете использовать.

Тем не менее, на самом деле нет никаких причин не использовать MAC-адреса, особенно если в процессе инициализации вы можете определить, что они на самом деле уникальны (хотя это даже не нужно, если мы говорим не более, чем несколько тысяч устройств здесь). Конечно, имейте в виду, что все, что вы используете, может быть подделано устройством, поэтому не полагайтесь на это для аутентификации в ненадежной среде (вы сказали, что это частная установка, так что, вероятно, это "доверенная" среда, где вы не позаботьтесь о том, чтобы ваш клиент подделывал свои собственные устройства на своих собственных серверах, но он, очевидно, должен помнить об этом, если управление устройствами передается третьим лицам или конечным пользователям).