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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, будет немного, но измеримо, отличаться каждый раз. Аналогичным образом, getaddrinfoпри первом поиске имени хоста вашего веб-API для каждого устройства потребуется немного другое, измеримое количество времени.

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

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

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

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

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

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

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

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

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

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

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

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

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