В сценарии, где вы контролируете подготовку оборудования и можете определить, что все устройства с одинаковой моделью оборудования действительно имеют уникальные MAC-адреса для своих сетевых интерфейсов, есть ли какие-либо недостатки в написании кода, использующего это предположение? (Примечание, основанное на некоторых ответах: я не собираюсь писать сетевой код, используя это предположение. Это просто подразумевается как способ с минимальным вмешательством в работу иметь UUID для каждого устройства без необходимости вручную генерировать и обновлять идентификатор жесткого диска устройства перед развертыванием в полевых условиях)
Предыстория этого такова: я исследую реализацию частной аппаратной реализации типа IoT для клиента. Мы предоставим набор аппаратных устройств с сетевыми возможностями для установки в удаленных местах. Затем эти устройства будут связываться с API, отправляя сообщения. Чтобы уменьшить сложность настройки, я надеялся отправлять MAC-адрес сетевого интерфейса на устройстве в сообщении, чтобы связать эти сообщения с «device_id» на стороне API. Я думаю, что, сделав это чем-то, что не нужно настраивать на устройстве перед использованием, его можно будет просто запросить во время нормальной работы. Я могу с уверенностью предположить, что мы можем определить, что MAC-адреса каждого устройства на самом деле уникальны, и мы можем контролировать, когда/если устройство заменяется, чтобы знать, что сообщения для этого device_id теперь будут иметь другой MAC-адрес.
решение1
На основании ваших заявлений о том, что вы можете подтвердить во время подготовки, что MAC-адрес производителя на самом деле уникален в пределах сети создаваемых вами устройств (что само по себе не является гарантией, хотя должно быть таковой), вы, вероятно, можете продолжать работу, но рассмотрите следующие вопросы:
Используете ли вы MAC для проверки безопасности (аутентификация, авторизация)? Если да, то MAC недостаточно. Даже не думайте об этом. Используйте криптографическую структуру и передавайте любые запросы аутентификации безопасно.
Достаточно ли 48 бит? Вероятно, да, но стоит спросить.
Придется ли вам когда-нибудь ремонтировать устройство, заменяя его сетевую карту?
Если вы полностью замените устройство или замените его сетевую карту, нужно ли вам будет связать новый адрес с существующим ключом в вашей базе данных, чтобы обеспечить непрерывность сбора данных для места развертывания?
Будет ли какой-либо интерфейс обслуживания, с помощью которого пользователь (авторизованный или нет) может изменить NIC на уровне ПЗУ, драйвера или ОС? Злоумышленник может внести уязвимости в ваши данные, если он изменит MAC.
Будут ли ваши данные когда-либо объединены с другими источниками данных с использованием MAC в качестве ключа?
Будете ли вы когда-либо использовать MAC для каких-либо сетевых целей, кроме простой навигации по локальной сети второго уровня, к которой подключено устройство (проводное или беспроводное)?
Будет ли локальная сеть, к которой подключены ваши устройства, частной сетью или сетью, к которой будет подключаться большое количество временных клиентов (например, мобильные телефоны сотрудников)?
Если ваши ответы
NO, yes, no, no, no, no, no, private
то я не могу вспомнить ни одного реального недостатка в вашем плане.
Помните, что вам не нужны глобально уникальные MAC-адреса, чтобы это осуществить; вам просто нужно убедиться, что подмножество интернет-устройств, которые вызывают ваш API, являются уникальными. Так же, как дублирующий NIC, назначенный в двух разных городах, не может конфликтовать, поскольку они находятся в разных локальных сетях, у вас не может быть конфликта ключей базы данных на MAC, если он никогда не вызывает ваш API.
решение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 будет немного, но измеримо, отличаться каждый раз. Аналогично, getaddrinfoзаймет немного разное, измеримое количество времени для каждого устройства при поиске имени хоста вашего веб-API в первый раз.
Объедините эти три или четыре источника энтропии (MAC-адрес, время первого включения, время первой загрузки, время подключения) и вычислите хэш из этого. MD5 прекрасно подойдет для этой цели. Вот вы и уникальны.
Хотя это не такдействительногарантирует уникальность, он "почти" гарантирует ее, с пренебрежимо малым шансом отказа. Вам нужно будет иметь два устройства с идентичными MAC-адресами, которые включаются в первый раз в одну и ту же микросекунду и загружаются в одно и то же время и подключаются к вашему сайту. Этого не произойдет. Если это произойдет, вам следует немедленно начать играть в лотерею, потому что, судя по всему, вы гарантированно выиграете.
Однако, если "не произойдет" недостаточно для гарантии, просто передайте каждому устройству последовательно увеличивающееся число (генерируемое на сервере) при первом доступе к вашему веб-API. Пусть устройство сохранит это число, готово.
решение3
Поскольку проблема здесь на самом деле является проблемой XY, я собираюсь заняться ее решением: как получить уникальный идентификатор для части оборудования при первой загрузке без необходимости предварительной загрузки идентификаторов на них. Все хорошие методы на самом деле сводятся к одному: иметь источник энтропии.
Если на вашем оборудовании есть что-то, предназначенное для использования в качестве источника аппаратной энтропии (примечание: это, по сути, требование для любой надлежащей реализации устройства IoT, поскольку оно необходимо для TLS, поэтому ваше оборудованиедолженбыть разработаны с учетом этого), просто используйте это. Если нет, вам придется проявить креативность.
К счастью, почти каждый когда-либо созданный компьютер имеет превосходный источник энтропии:кварцевые генераторы(часы). Скорость данного кристалла зависит не только от незначительных изменений температуры, но и подвержена даже температурегистерезиснелинейными способами. Однако для измерения энтропии вам нужны вторые часы для измерения первых. Это означает, что всякий раз, когда у вашего компьютера есть по крайней мере двое часов, которые вы можете оцифровать, вы можете использовать скорость одних, измеренную другими, как очень высококачественный источник энтропии.
решение4
Я ненавижу предполагать наличие проблемы XY, потому что часто у OP есть веская, хотя и сложная причина делать что-то именно так, а не иначе. Но вам, возможно, стоит рассмотреть другие методы генерации уникального идентификатора для каждого устройства, который, как и MAC-адрес, «встроен» в устройство и не требует генерации собственного идентификатора.
Если все устройства одного производителя (или, что еще лучше, одной модели), вы можете использовать серийный номер для генерации идентификатора. Однако это не работает так хорошо для устройств разных производителей, даже если вы объединяете его с именем производителя и номером модели, из-за разных форматов серийных номеров и, возможно, разных API для получения серийного номера в случае встроенных/фирменных устройств. Альтернативой серийному номеру устройства может быть серийный номер материнской платы, процессора или жесткого диска (я считаю, что лицензирование Windows использует комбинацию этих номеров).
Также стоит помнить, что форматировщики файловых систем обычно генерируют уникальный идентификатор для каждой файловой системы. Если вы не готовите все устройства из одного и того же образа (что я бы рекомендовал делать по несвязанным причинам), каждый жесткий диск уже будет иметь уникальный идентификатор, сохраненный в файловой системе, который вы можете использовать.
Но, сказав это, на самом деле нет никаких причиннетиспользовать MAC-адреса, особенно если в процессе подготовки вы можете определить, что они на самом деле уникальны (хотя это даже не обязательно, если мы говорим не о нескольких тысячах устройств). Конечно, имейте в виду, что все, что вы используете, может быть подделано устройством, поэтому не полагайтесь на это для аутентификации в ненадежной среде (вы сказали, что это частная настройка, так что, по-видимому, это «доверенная» среда, в которой вас не волнует, что ваш клиент подделывает свои собственные устройства против своих собственных серверов, но им, очевидно, следует иметь это в виду, если управление устройствами передается третьим лицам или конечным пользователям).