Причини не вважати MAC-адресу пристрою унікальною

У сценарії, коли ви керуєте забезпеченням обладнанням і можете визначити, що всі пристрої з однаковою апаратною моделлю дійсно мають унікальні MAC адреси для своїх мережевих інтерфейсів, чи є недоліки в написанні коду, який використовує це припущення? (Примітка на основі деяких відповідей: Я не збираюся писати мережевий код, використовуючи це припущення. Це мається на увазі як спосіб низького дотику, щоб мати uuid на пристрій без ручного генерування та оновлення жорсткого диска пристрою з ідентифікатором раніше розгортання в поле)

Попередженням цього є те, що я досліджую реалізацію приватної апаратної реалізації типу IOT для клієнта. Ми надамо набір апаратних пристроїв з мережевими можливостями для встановлення у віддалених місцях. Потім ці пристрої будуть передавати назад API, надсилаючи повідомлення. Щоб зменшити складність налаштування, я сподівався надіслати MAC-адресу мережевого інтерфейсу на пристрої у повідомленні, щоб прив’язати ці повідомлення назад до "device_id" на стороні API. Думаю, що зробивши це щось, що не потрібно встановлювати на пристрої перед використанням, його можна просто запитати під час нормальної роботи. Я сміливо можу припустити, що ми можемо визначити, що MAC-адреси кожного пристрою насправді є унікальними,

Виходячи з ваших тверджень, які ви можете підтвердити під час надання умови, що виробник MAC насправді є унікальним у мережі створених вами пристроїв (що саме по собі не є певним, хоч і повинно бути), ви, ймовірно, добре продовжуєте процес, але врахуйте наступні питання:

• Чи використовуєте ви MAC для перевірок безпеки (автентифікація, авторизація)? Якщо так, MAC недостатньо. Навіть не зважайте на це. Використовуйте криптографічну структуру та надійно передайте будь-які аутентивні запити.

• Чи 48 біт досить широкий? Мабуть, так і є, але варто запитати.

• Чи вам коли-небудь знадобиться відремонтувати пристрій, замінивши його нік?

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

• Чи буде інтерфейс технічного обслуговування, за допомогою якого користувач (авторизований чи ні) може змінити нік на рівні ROM, драйвера або ОС? Зловмисник може ввести вади у ваші дані, якби вони змінили MAC.

• Чи будуть коли-небудь ваші дані з'єднуватися з іншими джерелами даних, використовуючи MAC як ключ?

• Чи будете ви коли-небудь використовувати MAC для будь-яких мережевих цілей, крім простої навігації по шару2 LAN, до якого приєднано пристрій (дротовий або бездротовий)?

• Чи буде локальна мережа, до якої підключені ваші пристрої, приватна мережа чи така мережа, до якої підключиться велика кількість перехідних клієнтів (наприклад, мобільні телефони співробітників)?

Якщо ваші відповіді є

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

то я не можу придумати жодної реальної вади у вашому плані.

Майте на увазі, що вам не потрібні глобально унікальні MAC, щоб зняти це; вам просто потрібно переконатися, що підмножина Інтернет-пристроїв, які викликають ваш API, унікальна. Так само як і дублікат nic, призначений у двох різних містах, не може зіткнутися, оскільки вони знаходяться в різних локальних мережах, ви не можете зіткнути ключ бази даних на 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 буде чудово. Там ти унікальний.

Хоча це і справді не гарантує унікальності, воно "в значній мірі" гарантує це, маючи незначний шанс на провал. Вам потрібно було б мати два пристрої з однаковими МАС-кодами, які вперше вмикаються на одній мікросекунді, і для того, щоб завантажитися та підключитися до вашого сайту, потрібно було точно такий же час. Це не відбудеться. Якщо це все-таки трапиться, вам слід негайно почати грати в лотерею, оскільки, на всі виступи, ви гарантовано виграєте.

Якщо, однак, "не відбудеться" недостатньо гарної гарантії, просто передайте кожен пристрій послідовно збільшуючий номер (генерується на сервері) під час першого доступу до вашого веб-API. Нехай пристрій зберігає цей номер.

Оскільки проблема тут справді проблема XY, я вирішу вирішити це: як отримати унікальний ідентифікатор для обладнання, коли він вперше завантажується без попереднього завантаження ідентифікаторів на них. Усі хороші методи дійсно зводяться до одного: наявності джерела ентропії.

Якщо у вашому обладнання є щось, що призначене для джерела апаратної ентропії (зверніть увагу: це в основному вимога для будь-якої належної реалізації пристроїв IoT, оскільки це потрібно для TLS, тому ваше обладнання повинно бути розроблено з урахуванням цього), просто використовуйте це. Якщо ні, то треба проявляти творчість.

На щастя, майже кожен комп'ютер, який коли-небудь виготовляв, має чудове джерело ентропії: кристалічні осцилятори (годинники). Швидкість даного кристала не просто залежить від тонких змін температури, але піддається навіть температурному гістерезису нелінійними способами. Однак, щоб виміряти ентропію, вам потрібен другий годинник, щоб передати перший. Це означає, що щоразу, коли на вашому комп'ютері є щонайменше два годинники, ви можете зробити вибірку, ви можете використовувати швидкість одного, виміряну іншим, як дуже якісне джерело ентропії.

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

Якщо це підтримується вашим обладнанням, ви можете розглянути можливість використання UBID SMBIOS. Це унікальний ідентифікатор для материнської плати і, отже, пристрою. Майте на увазі, що навіть пристрої IoT можуть мати декілька NIC (LAN та WiFi), тому якщо ви виберете маршрут MAC, вам все одно потрібно знайти спосіб вибору одного з послідовних.

Крім того, хоча UUID є унікальним, його не слід використовувати з метою безпеки, оскільки він гарантований, щоб бути унікальним лише в доброзичливих умовах.

Я ненавиджу вважати проблему XY, оскільки часто в ОП є вагомі, хоча і складні причини для того, щоб робити речі так, як вони роблять, але ви, можливо, захочете розглянути інші методи для створення унікального ідентифікатора для кожного пристрою, який, як і MAC-адреса , "вбудований" у пристрій і не потребує генерації власного ідентифікатора.

Якщо пристрої від одного виробника (або, ще краще, тієї ж моделі), ви можете використовувати серійний номер для створення ідентифікатора. Це не дуже добре працює на пристроях різних виробників, навіть якщо ви поєднуєте його з назвою виробника та номером моделі, через різні формати серійних номерів та, можливо, різні API для отримання серійного номера у випадку вбудованих / фірмових пристроїв . Альтернативою серійному номеру пристрою може бути серійний номер материнської плати, процесора чи жорсткого диска (я вважаю, що в ліцензуванні Windows використовується комбінація цих даних).

Варто також пам’ятати, що формати форматів файлової системи зазвичай генерують унікальний ідентифікатор для кожної файлової системи. Якщо ви не готуєте всі пристрої з одного зображення (що я рекомендував би зробити з незв'язаних причин), кожен жорсткий диск вже матиме унікальний ідентифікатор, який зберігається у файловій системі, яку ви можете використовувати.

Сказавши, що хоча насправді немає причин не використовувати MAC-адреси, особливо якщо в рамках вашого процесу резервування ви можете визначити, що вони насправді унікальні (хоча це навіть не повинно бути необхідним, якщо вважати, що ми говоримо не більше ніж кілька тисяч пристроїв тут). Звичайно, майте на увазі, що все, що ви використовуєте, може бути підроблене пристроєм, тому не покладайтеся на це для автентифікації в ненадійному середовищі (ви сказали, що це приватне налаштування, імовірно, це середовище "довірених", де ви цього не робите дбайте про те, щоб ваш клієнт підробляв свої власні пристрої проти власних серверів, але, очевидно, слід пам’ятати про це, якщо управління пристроями передається третім сторонам або кінцевим користувачам).