Raisons pour ne pas supposer que l'adresse MAC du périphérique est unique
Dans un scénario où vous contrôlez le provisionnement du matériel et pouvez déterminer que tous les périphériques avec le même modèle matériel ont effectivement des adresses MAC uniques pour leurs interfaces réseau, existe-t-il des inconvénients à l'écriture de code qui utilise cette hypothèse? (Remarque basée sur certaines réponses: je ne vais pas écrire de code de réseau à l'aide de cette hypothèse. Il s'agit simplement d'un moyen simple de générer un uuid par périphérique sans avoir à générer et mettre à jour manuellement le disque dur du périphérique avec un identifiant déploiement sur le terrain)
L’historique de cette affaire est que je suis à la recherche d’une implémentation de type IOT de matériel privé pour un client. Nous fournirons un ensemble de périphériques matériels dotés de fonctionnalités réseau à installer dans des sites distants. Ces périphériques communiqueront ensuite à une API en envoyant des messages. Afin de réduire la complexité de l’installation, j’espérais envoyer l’adresse MAC de l’interface réseau de l’appareil dans le message afin de relier ces messages à un "ID_appareil" du côté de l’API. Mon idée est qu’en faisant quelque chose qui n’a pas besoin d’être configuré sur l’appareil avant de l’utiliser, on peut l’interroger lors d’un fonctionnement normal. Je peux sans risque supposer que nous pouvons déterminer que les adresses MAC de chaque périphérique sont en fait uniques et que nous pouvons contrôler le moment/le remplacement du périphérique pour savoir que les messages pour ce périphérique_id auront désormais une adresse MAC différente.
Sur la base de vos déclarations selon lesquelles vous pouvez confirmer lors de la configuration que le code MAC du fabricant est en fait unique dans le réseau de périphériques que vous créez (ce qui en soi n’est pas une certitude, même si cela devrait être le cas), vous êtes probablement en bonne voie, mais considérez les questions suivantes:
Utilisez-vous le MAC pour les contrôles de sécurité (authentification, autorisation)? Si c'est le cas, un MAC n'est pas suffisant. Ne même pas y penser. Utilisez une structure cryptographique et transmettez les demandes d'authentification en toute sécurité.
La largeur de 48 bits est-elle suffisante? C'est probablement, mais mérite d'être demandé.
Aurez-vous besoin de réparer un appareil en remplaçant son NIC?
Si vous remplacez un périphérique dans son intégralité ou remplacez son NIC, devrez-vous pouvoir associer la nouvelle adresse à la clé existante de votre base de données afin de garantir la continuité de la collecte de données pour l'emplacement de déploiement?
Y aura-t-il une interface de maintenance permettant à un utilisateur (autorisé ou non) de modifier le NIC au niveau de la ROM, du pilote ou du système d'exploitation? Un attaquant pourrait introduire des failles dans vos données s’il modifiait le MAC.
Vos données seront-elles un jour reliées à d'autres sources de données utilisant MAC comme clé?
Utiliserez-vous jamais le MAC à des fins de mise en réseau autres que la simple navigation dans le LAN de couche 2 auquel le périphérique est connecté (filaire ou sans fil)?
Le réseau local auquel vos appareils sont connectés, sera-t-il un réseau privé ou un grand nombre de clients temporaires (tels que les téléphones portables des employés) se connecteront-ils?
Si vos réponses sont
NO, yes, no, no, no, no, no, private
alors je ne peux penser à aucune faille réelle dans votre plan.
N'oubliez pas que vous n'avez pas besoin de MAC uniques au monde pour réussir cela. vous devez simplement vous assurer que le sous-ensemble de périphériques Internet qui appelle votre API est unique. Tout comme un duplicata assigné dans deux villes différentes ne peut pas entrer en collision car ils se trouvent sur des réseaux locaux différents, vous ne pouvez pas avoir une collission de clé de base de données sur un MAC sans appeler votre API.
Les adresses MAC ne sont pas uniques
Il peut y avoir et il y aura des doublons avec les MAC. Il y a plusieurs raisons à cela, l'une étant qu'elles ne doivent pas nécessairement être (globalement) uniques.
Le MAC doit être unique sur le réseau local pour qu'ARP/NDP puisse faire son travail et que le commutateur sache où envoyer les datagrammes entrants. Habituellement (pas nécessairement), cette condition préalable est remplie et tout se passe bien, tout simplement parce que la probabilité d'avoir deux MAC identiques sur le même réseau local, même si elles ne sont pas uniques, est assez faible.
Une autre raison est qu'il existe tout simplement plus de périphériques qu'il n'y a d'adresses. Bien que les adresses 48 bits sonnent comme s'il y avait assez d'adresses pour tout le monde jusqu'à la fin des jours, ce n'est pas le cas.
L'espace d'adressage est divisé en deux moitiés de 24 bits (c'est un peu plus compliqué, mais ignorons les petits détails). Une moitié correspond au OUI que vous pouvez enregistrer auprès de l'IEEE et attribuer à votre entreprise pour environ 2000 dollars. Les 24 bits restants, vous faites ce que vous voulez. Bien sûr, vous pouvez enregistrer plusieurs OUI, ce que font les plus gros joueurs.
Prenons par exemple Intel. Ils ont enregistré 7 OUI au total, ce qui leur donne un total de 116 millions d'adresses.
La carte mère de mon ordinateur (qui utilise un chipset X99) ainsi que la carte mère de mon ordinateur portable ainsi que la carte mère de tous les ordinateurs basés sur x86 que j'ai possédés au cours des 10 dernières -15 ans avaient une carte réseau Intel dans le chipset. Certes, il y a plus de 116 millions d'ordinateurs Intel dans le monde. Ainsi, leurs MAC ne peuvent pas être uniques (au sens de globalement uniques).
De plus, des cas ont été rapportés de euh ... moins chers ... les fabricants "volent" simplement les adresses à quelqu'un d'autre. En d'autres termes, ils ont juste utilisé une adresse aléatoire. J'ai entendu parler de fabricants qui utilisent simplement la même adresse pour une gamme complète de produits. Rien de tout cela n'est vraiment conforme ou n'a beaucoup de sens, mais que pouvez-vous faire à ce sujet? Ces cartes réseau existent. Encore une fois: la probabilité que cela devienne un problème pratique est encore très faible si les adresses sont utilisées pour ce à quoi elles sont destinées, vous devez en avoir deux sur le même réseau local à remarquer.
Maintenant, que faire de votre problème?
La solution est peut-être plus simple que vous ne le pensez. Vos appareils IoT auront probablement besoin d'une certaine notion de temps, généralement le temps est automatiquement obtenu via NTP. La précision typique de NTP est dans la plage des microsecondes (oui, c'est micro, pas milli). Je viens de courir ntpq -c rl pour être sûr et on m'a dit 2-20.
La probabilité que deux de vos appareils soient allumés pour la première fois exactement au même microseconde est très faible. Il est généralement possible que cela se produise (surtout si vous en vendez des millions en très peu de temps, félicitations pour votre succès!), Bien sûr. Mais ce n'est pas très probable - dans la pratique, cela n'arrivera pas. Ainsi, gagnez du temps après le premier démarrage sur le magasin permanent.
Le temps de démarrage de votre appareil IoT sera le même sur tous les appareils. Sauf que ce n'est pas vrai du tout .
Avec un minuteur à haute résolution, les temps de démarrage sont considérablement différents, même sur le même périphérique, à chaque fois. Ce n'est peut-être que quelques coups d'horloge différents (ou quelques centaines de milliers, si vous lisez quelque chose comme le compteur d'horodatage du processeur), donc pas vraiment unique, mais cela ajoute certainement un peu d'entropie.
De même, le temps qu'il faut connect pour revenir au premier accès à votre site API est légèrement, mais mesurable, différent à chaque fois. . De même, getaddrinfo prendra un temps légèrement différent et mesurable pour chaque périphérique lors de la première recherche du nom d'hôte de votre API Web.
Concaténez ces trois ou quatre sources d'entropie (adresse MAC, heure de première mise sous tension, heure de démarrage pour la première fois, temps de connexion) et calculez un hachage à partir de cela. MD5 fera très bien pour cela. Là, tu es unique.
Bien que cela ne garantisse pas véritablement l'unicité, il le garantit "à peu près", avec une possibilité infranchissable d'échec. Vous devez disposer de deux périphériques dotés de MAC identiques, activés pour la première fois sur la même microseconde, et prenant exactement le même temps pour démarrer et se connecter à votre site. Cela ne va pas arriver. Si cela se produit, vous devez immédiatement commencer à jouer à la loterie car, à toutes les apparences, vous êtes assuré de gagner.
Si, toutefois, "ne se produira pas" n'est pas une garantie suffisante, transmettez simplement à chaque périphérique un nombre croissant (généré sur le serveur) la première fois qu'il accède à votre API Web. Laissez l’appareil stocker ce numéro, c’est fait.
Comme le problème ici est vraiment un problème XY, je vais vous expliquer comment résoudre le problème: comment obtenir un identifiant unique pour un matériel dès le premier démarrage sans avoir à précharger les identifiants sur eux. Toutes les bonnes méthodes se résument en une chose: avoir une source d'entropie.
Si votre matériel a été conçu pour être une source d'entropie matérielle (remarque: il s'agit en fait d'une exigence pour toute implémentation de périphérique IoT appropriée, car elle est nécessaire pour TLS. Votre matériel doit donc être conçu . dans cet esprit), utilisez-le. Sinon, vous devez faire preuve de créativité.
Heureusement, presque tous les ordinateurs jamais construits ont une excellente source d'entropie: oscillateurs à cristal (horloges). La vitesse d'un cristal donné ne dépend pas seulement de changements de température subtils, elle est même soumise à une hystérésis de la température de manière non linéaire. Cependant, pour mesurer l'entropie, vous avez besoin d'une seconde horloge pour chronométrer la première. Cela signifie que, chaque fois que votre ordinateur dispose d'au moins deux horloges que vous pouvez échantillonner, vous pouvez utiliser le taux de l'une, mesuré par l'autre, comme source d'entropie de très haute qualité.
Je ne veux pas répondre directement à la question car il y a d'autres très bonnes réponses mais je voudrais plutôt suggérer une autre valeur plus appropriée qui pourrait être disponible comme identifiant de périphérique.
Si votre matériel le prend en charge, vous pouvez envisager d'utiliser l'UUID SMBIOS. C'est un identifiant unique pour la carte mère et donc pour l'appareil. N'oubliez pas que même les appareils IoT peuvent avoir plusieurs cartes réseau (LAN & WiFi). Par conséquent, si vous choisissez la route MAC, vous devez toujours trouver une méthode pour en choisir une de manière cohérente.
De plus, bien que l’UUID soit unique, il ne doit pas être utilisé à des fins de sécurité, car il n’est garanti que dans un environnement convivial.
Je déteste assumer un problème XY car souvent, le terminal opérateur a une bonne raison, bien que complexe, de faire les choses comme ils le font, mais vous pouvez envisager d'autres méthodes pour générer un identifiant unique pour chaque périphérique qui, comme l'adresse MAC , est "intégré" à l'appareil et ne nécessite pas de générer votre propre identifiant.
Si les périphériques proviennent tous du même fabricant (ou, mieux encore, du même modèle), vous pouvez utiliser le numéro de série pour générer l'identifiant. Toutefois, cela ne fonctionne pas si bien sur des appareils de fabricants différents, même si vous le combinez avec le nom du fabricant et le numéro de modèle, en raison de formats de numéro de série différents et éventuellement d’API différentes pour obtenir le numéro de série dans le cas d’appareils propriétaires/intégrés . Une alternative au numéro de série du périphérique pourrait être le numéro de série de la carte mère, du processeur ou du disque dur (je pense que la licence Windows utilise une combinaison de ceux-ci).
Il convient également de noter que les formateurs de systèmes de fichiers génèrent généralement un identifiant unique pour chaque système de fichiers. À moins que vous ne prépariez tous les périphériques à partir de la même image (ce que je recommanderais, pour des raisons indépendantes), chaque disque dur aura déjà un identifiant unique stocké dans le système de fichiers que vous pouvez utiliser.
Cela dit, il n’ya aucune raison de ne pas utiliser des adresses MAC, en particulier si, dans le cadre de votre processus de provisionnement, vous pouvez déterminer qu’elles sont uniques. (Bien que cela ne devrait même pas être nécessaire, en supposant que nous ne parlions pas ici de quelques milliers d'appareils). Bien sûr, gardez à l'esprit que tout ce que vous utilisez peut être usurpé par le périphérique, ne vous fiez donc pas à cette authentification dans un environnement non fiable (vous avez dit qu'il s'agissait d'une configuration privée; veillez à ce que vos clients usent de leurs propres périphériques contre leurs propres serveurs, mais ils doivent évidemment en tenir compte si la gestion des périphériques est confiée à des tiers ou à des utilisateurs finaux).