Powody, aby nie zakładać, że adres MAC urządzenia jest unikalny

W scenariuszu, w którym kontrolujesz dostarczanie sprzętu i możesz określić, że wszystkie urządzenia z tym samym modelem sprzętowym rzeczywiście mają unikalne adresy MAC dla swoich interfejsów sieciowych, czy są jakieś wady w pisaniu kodu, który używa tego założenia? (Uwaga oparta na niektórych odpowiedziach: nie zamierzam pisać kodu sieciowego za pomocą tego założenia. Jest to po prostu nisko dotykowy sposób posiadania uuidu na urządzenie bez konieczności ręcznego generowania i aktualizowania dysku twardego urządzenia z identyfikatorem przed wdrażanie w polu)

Podstawą tego jest badanie implementacji implementacji prywatnego sprzętu typu IOT dla klienta. Zapewnimy zestaw urządzeń sprzętowych z funkcjami sieciowymi do zainstalowania w odległych lokalizacjach. Urządzenia te będą następnie komunikować się z API poprzez wysyłanie wiadomości. Aby zmniejszyć złożoność instalacji, miałem nadzieję wysłać adres MAC interfejsu sieciowego urządzenia do wiadomości, aby powiązać te wiadomości z powrotem do „id_urządzenia” po stronie API. Uważam, że dzięki temu, że nie trzeba go ustawiać na urządzeniu przed użyciem, można go po prostu zapytać podczas normalnej pracy. Mogę spokojnie założyć, że możemy ustalić, że adresy MAC każdego urządzenia są w rzeczywistości unikalne,

Na podstawie twoich oświadczeń, które możesz potwierdzić podczas dostarczania, że ​​producent MAC jest w rzeczywistości unikalny w sieci tworzonych urządzeń (co nie jest samo w sobie pewne, nawet jeśli tak powinno być), prawdopodobnie postępujesz dobrze, ale rozważ następujące pytania:

• Czy używasz MAC do kontroli bezpieczeństwa (uwierzytelnianie, autoryzacja)? Jeśli tak, MAC nie jest wystarczający. Nawet o tym nie myśl. Używaj struktury kryptograficznej i bezpiecznie przesyłaj żądania autoryzacji.

• Czy 48 bitów jest wystarczająco szerokich? Prawdopodobnie jest, ale warto zapytać.

• Czy kiedykolwiek będziesz musiał naprawić urządzenie, zastępując jego nic?

• Jeśli zastąpisz całe urządzenie lub zastąpisz jego nic, czy będziesz musiał skojarzyć nowy adres z istniejącym kluczem w bazie danych, aby zapewnić ciągłość zbierania danych dla lokalizacji wdrożenia?

• Czy będzie jakiś interfejs konserwacyjny, za pomocą którego użytkownik (autoryzowany lub nie) może zmienić nic na poziomie ROM, sterownika lub systemu operacyjnego? Osoba atakująca może wprowadzić błędy w danych, jeśli będą modyfikować MAC.

• Czy Twoje dane kiedykolwiek zostaną połączone z innymi źródłami danych wykorzystującymi MAC jako klucz?

• Czy kiedykolwiek użyjesz MAC w jakimkolwiek celu sieciowym innym niż po prostu nawigacja po warstwie 2 LAN, do której jest podłączone urządzenie (przewodowe lub bezprzewodowe)?

• Czy sieć LAN, do której podłączone są Twoje urządzenia, będzie siecią prywatną lub taką, z którą będzie się łączyć duża liczba klientów przejściowych (takich jak telefony komórkowe pracowników)?

Jeśli twoje odpowiedzi są

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

wtedy nie mogę wymyślić żadnej prawdziwej wady w twoim planie.

Pamiętaj, że nie potrzebujesz globalnie unikalnych adresów MAC, aby to zrobić; wystarczy upewnić się, że podzbiór urządzeń internetowych, które wywołują Twój interfejs API, jest unikalny. Tak jak duplikat nic przypisany w dwóch różnych miastach nie może się kolidować, ponieważ znajdują się w różnych sieciach LAN, nie możesz mieć kolizji klucza bazy danych na MAC, jeśli nigdy nie zadzwoni do twojego API.

Adresy MAC nie są unikalne

Mogą istnieć i będą duplikaty z MAC. Istnieje kilka powodów, z których jeden nie musi być (globalnie) wyjątkowy.

MAC musi być unikalny w sieci lokalnej, więc ARP / NDP może wykonywać swoje zadania, a przełącznik wie, gdzie wysyłać przychodzące datagramy. Zwykle (niekoniecznie) ten warunek wstępny jest spełniony i wszystko działa dobrze, po prostu dlatego, że prawdopodobieństwo posiadania dwóch identycznych adresów MAC w tej samej sieci LAN, nawet jeśli nie są one unikalne, jest dość niskie.

Innym powodem jest to, że istnieje po prostu więcej urządzeń niż adresów. Podczas gdy adresy 48-bitowe brzmią tak, jakby każdy miał wystarczającą liczbę adresów do końca dni, tak nie jest.

Przestrzeń adresowa jest podzielona na dwie 24-bitowe połówki (jest nieco bardziej skomplikowana, ale pomińmy drobne szczegóły). Jedna połowa to OUI, które można zarejestrować w IEEE i przypisać do swojej firmy za około 2000 dolarów. Pozostałe 24 bity, robisz co chcesz. Oczywiście możesz zarejestrować kilka OUI, co robią więksi gracze.

Weźmy przykład Intela. Zarejestrowali łącznie 7 OUI, dając im łącznie 116 milionów adresów.
Płyta główna mojego komputera (używająca chipsetu X99) oraz płyta główna mojego laptopa, a także płyta główna każdego komputera z procesorem x86, którego posiadałem w ciągu ostatnich 10-15 lat, posiadała kartę sieciową Intel jako część chipsetu. Z pewnością na świecie jest ponad 116 milionów komputerów z procesorami Intel. Tak więc ich MAC-y nie mogą być unikalne (w sensie unikalności globalnej).

Zgłoszono również przypadki ... tańsze ... producenci po prostu „kradną” adresy z cudzego OUI. Innymi słowy, użyli tylko losowego adresu. Słyszałem o producentach, którzy po prostu używają tego samego adresu, aby uzyskać pełną gamę produktów. Żadna z tych rzeczy nie jest zgodna ani nie ma sensu, ale co możesz z tym zrobić. Te karty sieciowe istnieją. Ponownie: Prawdopodobieństwo, że stanie się to problemem praktycznym, jest nadal bardzo niskie, jeśli adresy są używane do tego, do czego są przeznaczone. Musisz mieć dwie z nich w tej samej sieci LAN, aby nawet zauważyć.

Co teraz zrobić z twoim problemem?

Rozwiązanie może być prostsze niż myślisz. Twoje urządzenia IoT będą najprawdopodobniej potrzebowały trochę czasu, zazwyczaj czas jest uzyskiwany automatycznie przez NTP. Typowa precyzja NTP jest w zakresie mikrosekund (tak, to jest mikro, a nie milli). Po prostu pobiegłem, ntpq -c rlżeby być pewnym i powiedziano mi 2 ^-20 .

Prawdopodobieństwo, że dwa urządzenia zostaną włączone po raz pierwszy z taką samą mikrosekundą, jest bardzo niskie. Zwykle jest to możliwe (szczególnie, jeśli sprzedasz miliony z nich w bardzo krótkim czasie, gratuluję sukcesu!). Ale to mało prawdopodobne - w praktyce tak się nie stanie. Oszczędzaj więc czas po pierwszym uruchomieniu w stałym sklepie.

Czas rozruchu urządzenia IoT będzie taki sam na każdym urządzeniu. Tyle że wcale nie jest to prawdą .
Biorąc pod uwagę zegar o wysokiej rozdzielczości, czasy rozruchu są wymiernie różne nawet na tym samym urządzeniu, za każdym razem. Może tylko kilka taktów zegara różni się (lub kilkaset tysięcy, jeśli czytasz coś takiego jak licznik znaczników czasu procesora), więc zupełnie nie jest to wyjątkowe, ale z pewnością dodaje pewną entropię.
Podobnie czas connectpowrotu do pierwszego dostępu do witryny API będzie nieznacznie, ale wymiernie, za każdym razem inny. Podobnie, getaddrinfopo raz pierwszy zajmiemy się nieco innym, wymiernym czasem dla każdego urządzenia podczas wyszukiwania nazwy hosta API.

Połącz te trzy lub cztery źródła entropii (adres MAC, czas pierwszego włączenia, czas rozruchu po raz pierwszy, czas połączenia) i oblicz z tego hash. W tym celu MD5 będzie dobrze. Tam jesteś wyjątkowy.

Mimo, że nie naprawdę gwarantują wyjątkowość, to „dość dużo” gwarantuje to, ze neglegible przypadek awarii. Musiałbyś mieć dwa urządzenia z identycznymi MAC-ami, które są włączane po raz pierwszy na tej samej mikrosekundie, i potrzebowały dokładnie tego samego czasu na uruchomienie i połączenie się z witryną. To się nie wydarzy. Jeśli tak się stanie, powinieneś natychmiast rozpocząć grę na loterii, ponieważ na wszystkie sposoby masz pewność, że wygrasz.

Jeśli jednak „nie zdarzy się” nie jest wystarczające jako gwarancja, wystarczy przekazać każdemu urządzeniu kolejno rosnącą liczbę (generowaną na serwerze) przy pierwszym dostępie do interfejsu API sieci. Pozwól urządzeniu zapisać ten numer.

Ponieważ problem jest naprawdę problemem XY, zamierzam rozwiązać ten problem: jak uzyskać unikalny identyfikator dla części sprzętu przy pierwszym uruchomieniu bez konieczności wstępnego ładowania identyfikatorów. Wszystkie dobre metody sprowadzają się do jednej rzeczy: posiadania źródła entropii.

Jeśli twój sprzęt ma coś, co ma być sprzętowym źródłem entropii (uwaga: jest to w zasadzie wymóg dla każdej właściwej implementacji urządzenia IoT, ponieważ jest on potrzebny do TLS, więc twój sprzęt powinien być zaprojektowany z myślą o tym), po prostu użyj tego. Jeśli nie, musisz być kreatywny.

Na szczęście prawie każdy komputer, który kiedykolwiek wyprodukowano, ma doskonałe źródło entropii: oscylatory krystaliczne (zegary). Szybkość danego kryształu zależy nie tylko od subtelnych zmian temperatury, ale podlega nawet histerezie temperatury w sposób nieliniowy. Aby jednak zmierzyć entropię, potrzebny jest drugi zegar do czasu pierwszego. Oznacza to, że gdy komputer ma co najmniej dwa zegary, można próbkować, można użyć prędkości jednego mierzonej przez drugie jako źródła entropii o bardzo wysokiej jakości.

Nie chcę bezpośrednio odpowiadać na pytanie, ponieważ istnieją inne bardzo dobre odpowiedzi, ale zamiast tego chciałbym zasugerować inną, bardziej odpowiednią wartość, która może być dostępna jako identyfikator urządzenia.

Jeśli jest obsługiwany przez twój sprzęt, możesz rozważyć użycie UUID SMBIOS. Jest to unikalny identyfikator płyty głównej, a tym samym urządzenia. Pamiętaj, że nawet urządzenia IoT mogą mieć wiele kart sieciowych (LAN i WiFi), więc jeśli wybierzesz trasę MAC, wciąż musisz znaleźć sposób na jej wybranie.

Ponadto, podczas gdy UUID jest unikalny, nie powinien być wykorzystywany do celów bezpieczeństwa, ponieważ jest gwarantowany tylko w unikalnym środowisku.

Nienawidzę zakładania problemu XY, ponieważ często OP ma dobry, choć złożony powód, aby robić rzeczy w taki sposób, w jaki to robi, ale możesz chcieć zajrzeć do innych metod generowania unikalnego identyfikatora dla każdego urządzenia, takiego jak adres MAC , jest „wbudowany” w urządzenie i nie wymaga generowania własnego identyfikatora.

Jeśli wszystkie urządzenia pochodzą od tego samego producenta (lub nawet tego samego modelu), można użyć numeru seryjnego do wygenerowania identyfikatora. Nie działa to jednak tak dobrze na urządzeniach różnych producentów, nawet jeśli połączymy je z nazwą producenta i numerem modelu, ze względu na różne formaty numerów seryjnych i prawdopodobnie różne API do uzyskania numeru seryjnego w przypadku urządzeń wbudowanych / zastrzeżonych . Alternatywą dla numeru seryjnego urządzenia może być numer seryjny płyty głównej, procesora lub dysku twardego (uważam, że licencjonowanie systemu Windows używa ich kombinacji).

Warto również pamiętać, że formatyzatory systemów plików zazwyczaj generują unikalny identyfikator dla każdego systemu plików. O ile nie przygotowujesz wszystkich urządzeń z tego samego obrazu (które zalecałbym robić z innych powodów), każdy dysk twardy będzie miał unikalny identyfikator przechowywany w systemie plików, którego możesz użyć.

Mimo to jednak nie ma powodu, aby nie używać adresów MAC, zwłaszcza jeśli w ramach procesu udostępniania możesz stwierdzić, że są one w rzeczywistości wyjątkowe (chociaż nie powinno to być nawet konieczne, zakładając, że mówimy nie więcej niż kilka tysięcy urządzeń tutaj). Oczywiście pamiętaj, że cokolwiek użyjesz, może zostać sfałszowane przez urządzenie, więc nie polegaj na tym przy uwierzytelnianiu w niezaufanym środowisku (powiedziałeś, że jest to prywatna konfiguracja, więc prawdopodobnie jest to „zaufane” środowisko, w którym nie masz dbaj o to, aby Twój klient podszywał się pod ich własne serwery na własne serwery, ale oczywiście należy o tym pamiętać, jeśli zarządzanie urządzeniami zostanie przekazane osobom trzecim lub użytkownikom końcowym.