Gibt es in einem Szenario, in dem Sie die Bereitstellung der Hardware steuern und feststellen können, dass alle Geräte mit demselben Hardwaremodell tatsächlich eindeutige MAC-Adressen für ihre Netzwerkschnittstellen haben, irgendwelche Nachteile beim Schreiben von Code, der diese Annahme verwendet? (Hinweis basierend auf einigen Antworten: Ich werde keinen Netzwerkcode schreiben, der diese Annahme verwendet. Es soll nur eine unkomplizierte Möglichkeit sein, eine UUID pro Gerät zu haben, ohne die Gerätefestplatte vor dem Einsatz vor Ort manuell mit einer ID generieren und aktualisieren zu müssen.)
Der Hintergrund ist, dass ich die Implementierung einer privaten Hardware-Implementierung vom Typ IOT für einen Kunden untersuche. Wir werden eine Reihe von Hardwaregeräten mit Netzwerkfunktionen bereitstellen, die an entfernten Standorten installiert werden sollen. Diese Geräte kommunizieren dann mit einer API, indem sie Nachrichten senden. Um die Komplexität der Einrichtung zu verringern, wollte ich die MAC-Adresse der Netzwerkschnittstelle auf dem Gerät in der Nachricht senden, um diese Nachrichten auf der API-Seite mit einer „Geräte-ID“ zu verknüpfen. Mein Gedanke ist, dass es, wenn man es so macht, dass es nicht vor der Verwendung auf dem Gerät eingerichtet werden muss, einfach während des normalen Betriebs abgefragt werden kann. Ich kann davon ausgehen, dass wir feststellen können, dass die MAC-Adressen jedes Geräts tatsächlich eindeutig sind, und wir können steuern, wann/ob das Gerät ersetzt wird, um zu wissen, dass die Nachrichten für diese Geräte-ID jetzt eine andere MAC-Adresse haben.
Antwort1
Basierend auf Ihren Aussagen, dass Sie während der Bereitstellung bestätigen können, dass die Hersteller-MAC tatsächlich innerhalb des von Ihnen erstellten Gerätenetzwerks eindeutig ist (was an und für sich keine Gewissheit ist, es aber sein sollte), können Sie wahrscheinlich problemlos fortfahren. Bedenken Sie jedoch die folgenden Fragen:
Verwenden Sie den MAC für Sicherheitsprüfungen (Authentifizierung, Autorisierung)? Wenn ja, ist ein MAC nicht ausreichend. Denken Sie nicht einmal daran. Verwenden Sie eine kryptografische Struktur und übertragen Sie alle Authentifizierungsanforderungen sicher.
Sind 48 Bit breit genug? Wahrscheinlich schon, aber die Frage ist es wert.
Müssen Sie ein Gerät jemals reparieren, indem Sie seine Netzwerkkarte austauschen?
Wenn Sie ein Gerät komplett ersetzen oder dessen Netzwerkkarte austauschen, müssen Sie dann in der Lage sein, die neue Adresse dem vorhandenen Schlüssel in Ihrer Datenbank zuzuordnen, um die Kontinuität der Datenerfassung für den Bereitstellungsort sicherzustellen?
Wird es eine Wartungsschnittstelle geben, über die ein Benutzer (ob autorisiert oder nicht) die Netzwerkkarte auf ROM-, Treiber- oder Betriebssystemebene ändern könnte? Ein Angreifer könnte Fehler in Ihre Daten einbringen, wenn er die MAC-Adresse ändert.
Werden Ihre Daten jemals mit anderen Datenquellen unter Verwendung von MAC als Schlüssel zusammengeführt?
Werden Sie die MAC-Adresse jemals für andere Netzwerkzwecke als die einfache Navigation im Layer-2-LAN verwenden, mit dem das Gerät verbunden ist (kabelgebunden oder drahtlos)?
Wird das LAN, mit dem Ihre Geräte verbunden sind, ein privates Netzwerk sein oder ein Netzwerk, mit dem sich eine große Anzahl temporärer Clients (wie etwa Mobiltelefone von Mitarbeitern) verbindet?
Wenn Ihre Antworten
NO, yes, no, no, no, no, no, private
dann fällt mir kein wirklicher Fehler in Ihrem Plan ein.
Denken Sie daran, dass Sie hierfür keine global eindeutigen MACs benötigen. Sie müssen lediglich sicherstellen, dass die Teilmenge der Internetgeräte, die Ihre API aufrufen, eindeutig ist. So wie eine doppelte Netzwerkkarte, die in zwei verschiedenen Städten zugewiesen ist, nicht kollidieren kann, weil sie sich in unterschiedlichen LANs befinden, kann es auch nicht zu einer Kollision von Datenbankschlüsseln auf einer MAC kommen, wenn diese Ihre API nie aufruft.
Antwort2
MAC-Adressen sind nicht eindeutig
Es kann und wird Duplikate mit MACs geben. Dafür gibt es mehrere Gründe, einer davon ist, dass siemuss nicht sein(weltweit) einzigartig.
Die MAC muss im lokalen Netzwerk eindeutig sein, damit ARP/NDP seine Aufgabe erfüllen kann und der Switch weiß, wohin eingehende Datagramme gesendet werden müssen. Normalerweise (aber nicht unbedingt) ist diese Voraussetzung erfüllt und alles funktioniert einwandfrei, einfach weil die Wahrscheinlichkeit, dass sich im selben LAN zwei identische MACs befinden, selbst wenn sie nicht eindeutig sind, ziemlich gering ist.
Ein weiterer Grund ist, dass es einfach mehr Geräte als Adressen gibt. 48-Bit-Adressen klingen zwar so, als ob bis ans Ende aller Tage genug Adressen für alle vorhanden wären, aber das ist nicht der Fall.
Der Adressraum ist in zwei 24-Bit-Hälften aufgeteilt (das ist etwas komplizierter, aber lassen wir die kleinen Details außer Acht). Eine Hälfte ist die OUI, die Sie beim IEEE registrieren und Ihrem Unternehmen für rund 2000 Dollar zuweisen können. Mit den restlichen 24 Bits machen Sie, was Sie wollen. Natürlich können Sie mehrere OUIs registrieren, was die größeren Player auch tun.
Nehmen wir Intel als Beispiel. Sie haben insgesamt 7 OUIs registriert, was ihnen insgesamt 116 Millionen Adressen gibt.
Das Mainboard meines Computers (das einen X99-Chipsatz verwendet) sowie das Mainboard meines Laptops und das Mainboard vonjedenx86-basierte Computer, die ich in den letzten 10-15 Jahren besaß, hatten eine Intel-Netzwerkkarte als Teil des Chipsatzes. Sicherlich gibt es weit mehr als 116 Millionen Intel-basierte Computer auf der Welt. Daher sind ihre MACskann unmöglicheindeutig sein (im Sinne von global eindeutig).
Außerdem wurden Fälle gemeldet, in denen äh... billigere... Hersteller einfach Adressen von der OUI eines anderen "stahlen". Mit anderen Worten, sie verwendeten einfach eine beliebige Adresse. Ich habe auch von Herstellern gehört, die einfach dieselbe Adresse für eine komplette Produktpalette verwenden. Beides ist nicht wirklich konform oder macht viel Sinn, aber was kann man dagegen tun? Diese Netzwerkkarten gibt es. Noch einmal: Die Wahrscheinlichkeit, dass es einpraktischProblem ist immer noch sehr gering, wenn Adressen für das verwendet werden, was sie sollen, müssen Sie zwei davon habenim selben LANum es überhaupt zu bemerken.
Was können Sie nun gegen Ihr Problem tun?
Die Lösung ist vielleicht einfacher als Sie denken. Ihre IoT-Geräte benötigen höchstwahrscheinlich eine gewisse Zeitvorstellung, normalerweise wird die Zeit automatisch über NTP abgerufen. Die typische Genauigkeit von NTP liegt im Mikrosekundenbereich (ja, das ist Mikro, nicht Milli). Ich bin nur ntpq -c rlzur Sicherheit nachgelaufen und habe 2 -20 erhalten .
Die Wahrscheinlichkeit, dass zwei Ihrer Geräte genau in derselben Mikrosekunde zum ersten Mal eingeschaltet werden, ist sehr gering. Das kann grundsätzlich passieren (insbesondere, wenn Sie in sehr kurzer Zeit Millionen davon verkaufen, herzlichen Glückwunsch zu Ihrem Erfolg!). Aber es ist nicht sehr wahrscheinlich – in der Praxis wird es nicht passieren. Sparen Sie sich also die Zeit nach dem ersten Booten im permanenten Speicher.
Die Startzeit Ihres IoT-Geräts ist auf jedem Gerät gleich.Aber das stimmt überhaupt nicht.
Bei einem Timer mit hoher Auflösung sind die Bootzeiten jedes Mal messbar unterschiedlich, sogar auf demselben Gerät. Es sind vielleicht nur ein paar Taktschläge unterschiedlich (oder ein paar Hunderttausend, wenn man so etwas wie den Zeitstempelzähler der CPU liest), also insgesamt nicht sehr einzigartig, aber es fügt sicher etwas Entropie hinzu.
Ebenso die Zeit, die es brauchtconnectbeim ersten Zugriff auf Ihre API-Site wird jedes Mal leicht, aber messbar, anders sein. Ebenso getaddrinfowird es für jedes Gerät eine leicht unterschiedliche, messbare Zeit dauern, wenn Sie den Hostnamen Ihrer Web-API zum ersten Mal nachschlagen.
Verketten Sie diese drei oder vier Entropiequellen (MAC-Adresse, Zeitpunkt des ersten Einschaltens, Zeitpunkt des ersten Bootens, Verbindungszeit) und berechnen Sie daraus einen Hash. MD5 ist für diesen Zweck völlig ausreichend. Damit sind Sie eindeutig.
Das bedeutet zwar nichtwirklichEinzigartigkeit garantieren, dann ist sie „ziemlich sicher“, mit einer vernachlässigbaren Wahrscheinlichkeit eines Ausfalls. Sie müssten zwei Geräte mit identischen MACs haben, die zum ersten Mal in derselben Mikrosekunde eingeschaltet werden und genau dieselbe Zeit zum Booten und zum Verbinden mit Ihrer Site benötigen. Das wird nicht passieren. Wenn es passiert, sollten Sie sofort mit dem Lottospielen beginnen, denn allem Anschein nach werden Sie garantiert gewinnen.
Wenn „wird nicht passieren“ jedoch keine ausreichende Garantie ist, geben Sie jedem Gerät beim ersten Zugriff auf Ihre Web-API einfach eine fortlaufend steigende Nummer (die auf dem Server generiert wird) weiter. Lassen Sie das Gerät diese Nummer speichern, fertig.
Antwort3
Da es sich hier eigentlich um ein XY-Problem handelt, werde ich mich mit der Lösung dieses Problems befassen: Wie erhält man beim ersten Booten eine eindeutige Kennung für ein Stück Hardware, ohne dass man Kennungen vorab darauf laden muss? Alle guten Methoden laufen im Grunde auf eines hinaus: eine Entropiequelle zu haben.
Wenn Ihre Hardware über etwas verfügt, das als Hardware-Entropiequelle dient (Hinweis: Dies ist grundsätzlich eine Voraussetzung für jede ordnungsgemäße Implementierung eines IoT-Geräts, da es für TLS benötigt wird, sodass Ihre Hardwaresollensollte mit diesem Gedanken im Hinterkopf entworfen werden), verwenden Sie das einfach. Wenn nicht, müssen Sie kreativ werden.
Glücklicherweise verfügt fast jeder jemals gebaute Computer über eine hervorragende Entropiequelle:Quarzoszillatoren(Uhren). Die Geschwindigkeit eines bestimmten Kristalls hängt nicht nur von geringfügigen Temperaturänderungen ab, sondern unterliegt sogar der TemperaturHystereseauf nichtlineare Weise. Um die Entropie zu messen, benötigen Sie jedoch eine zweite Uhr, um die erste zu messen. Das bedeutet, dass Sie, wenn Ihr Computer mindestens zwei Uhren hat, die Sie abtasten können, die Rate der einen, gemessen von der anderen, als eine sehr hochwertige Entropiequelle verwenden können.
Antwort4
Ich gehe nicht gern von einem XY-Problem aus, da der OP häufig einen guten, wenn auch komplexen Grund dafür hat, die Dinge auf diese Art und Weise zu tun, aber Sie möchten vielleicht andere Methoden in Betracht ziehen, um für jedes Gerät eine eindeutige Kennung zu generieren, die wie die MAC-Adresse in das Gerät „eingebaut“ ist und keine Generierung Ihrer eigenen Kennung erfordert.
Wenn die Geräte alle vom selben Hersteller stammen (oder, noch besser, vom selben Modell), können Sie die Seriennummer zum Generieren der Kennung verwenden. Dies funktioniert jedoch nicht so gut zwischen Geräten verschiedener Hersteller, selbst wenn Sie es mit dem Herstellernamen und der Modellnummer kombinieren, da es unterschiedliche Seriennummernformate und möglicherweise unterschiedliche APIs zum Abrufen der Seriennummer bei eingebetteten/proprietären Geräten gibt. Eine Alternative zur Geräteseriennummer könnte die Seriennummer des Motherboards, der CPU oder der Festplatte sein (ich glaube, die Windows-Lizenzierung verwendet eine Kombination davon).
Denken Sie auch daran, dass Dateisystemformatierer normalerweise eine eindeutige ID für jedes Dateisystem generieren. Sofern Sie nicht alle Geräte aus demselben Image vorbereiten (was ich aus anderen Gründen empfehlen würde), hat jede Festplatte bereits eine eindeutige ID im Dateisystem gespeichert, die Sie verwenden können.
Allerdings gibt es wirklich keinen GrundnichtMAC-Adressen zu verwenden, insbesondere wenn Sie im Rahmen Ihres Bereitstellungsprozesses feststellen können, dass diese tatsächlich eindeutig sind (obwohl dies nicht einmal erforderlich sein sollte, vorausgesetzt, wir sprechen hier von nicht mehr als einigen Tausend Geräten). Bedenken Sie natürlich, dass alles, was Sie verwenden, vom Gerät gefälscht werden kann. Verlassen Sie sich daher bei der Authentifizierung in einer nicht vertrauenswürdigen Umgebung nicht darauf (Sie sagten, es handele sich um eine private Konfiguration, also ist dies vermutlich eine „vertrauenswürdige“ Umgebung, in der es Ihnen egal ist, ob Ihr Client seine eigenen Geräte gegenüber seinen eigenen Servern fälscht, aber er sollte dies natürlich berücksichtigen, wenn die Verwaltung der Geräte an Dritte oder Endbenutzer übergeben wird).