Raisons de ne pas supposer que l'adresse MAC du périphérique est unique

18

Dans un scénario où vous contrôlez l'approvisionnement du matériel et pouvez déterminer que tous les appareils avec le même modèle matériel ont en effet des adresses MAC uniques pour leurs interfaces réseau, y a-t-il des inconvénients à écrire du code qui utilise cette hypothèse? (Remarque basée sur certaines réponses: je ne vais pas écrire de code de réseau en utilisant cette hypothèse. Il s'agit simplement d'un moyen simple d'avoir un uuid par appareil sans avoir à générer et à mettre à jour manuellement le disque dur de l'appareil avec un identifiant avant déploiement sur le terrain)

La trame de fond à cela est que je recherche l'implémentation d'une implémentation de type IOT de matériel privé pour un client. Nous fournirons un ensemble de périphériques matériels avec des capacités de mise en réseau à installer dans des emplacements distants. Ces appareils communiqueront ensuite avec une API en envoyant des messages. Afin de réduire la complexité de la configuration, j'espérais envoyer l'adresse MAC de l'interface réseau sur le périphérique dans le message, pour lier ces messages à un "device_id" du côté API. Ma pensée est qu'en faisant quelque chose qui ne doit pas être configuré sur l'appareil avant utilisation, il peut simplement être interrogé pendant le fonctionnement normal. Je peux supposer en toute sécurité que nous pouvons déterminer que les adresses MAC de chaque appareil sont en fait uniques,

Matt Phillips
la source
4
Les périphériques virtuels ont généré des adresses MAC, qui ne sont uniques que le domaine de diffusion local. Il existe d'autres cas où un Mac peut entrer en collision avec un autre - certains appareils vous permettent de mettre à jour le Mac dans le micrologiciel. Les appareils HA ont un mac virtuel dans certains cas. Ce sont des exemples, ils peuvent ne pas être pertinents pour votre scénario.
Paul
9
Les gens sont très confus quant à l'unicité des adresses MAC. La particularité d'une adresse MAC est l'OUI attribuée à une organisation. Les adresses individuelles au sein de l'OUI ne sont pas garanties d'être uniques, et l'IEEE dit que l'attribution des adresses au sein de l'OUI est entièrement à la discrétion du propriétaire de l'OUI.
Ron Maupin
2
De plus, il est très facile pour un individu de modifier l'adresse MAC d'un appareil. Cela signifie que les adresses MAC peuvent être clonées ou attribuées de manière à créer des doublons. Un individu attribuant une adresse MAC est censé définir le bit U / L, mais cela se produit rarement.
Ron Maupin
5
Il y a, il doit y avoir des adresses MAC identiques dans la nature. Par exemple, Intel a enregistré 7 OUI, chacune ayant 16,7 millions d'adresses sous leur préfixe respectif. C'est un total de 116 millions d'adresses. Heck, il y a une carte réseau Intel sur presque toutes les cartes mères. Allez-vous me dire qu'il y a moins de 116 millions d'ordinateurs dans le monde? Non bien sûr que non. Mais la conséquence logique est: bien sûr, les MAC ne sont en aucun cas uniques. C'est juste que la probabilité d'avoir deux MAC identiques sur le même LAN est plutôt faible, donc ce n'est pas un problème.
Damon
7
Je me suis retrouvé avec deux adresses MAC identiques dans le même réseau par pur hasard - C'était l'enfer de déboguer.
Christian

Réponses:

34

Sur la base de vos déclarations que vous pouvez confirmer lors de l'approvisionnement que le MAC du fabricant est en fait unique au sein du réseau d'appareils que vous créez (ce qui n'est pas en soi une certitude, même s'il devrait l'être), vous allez probablement bien, 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. N'y pensez même pas. Utilisez une structure cryptographique et transmettez toutes les demandes d'authentification en toute sécurité.

  • La largeur de 48 bits est-elle suffisante? C'est probablement le cas, mais cela vaut la peine d'être demandé.

  • Aurez-vous un jour besoin de réparer un appareil en remplaçant son NIC?

  • Si vous remplacez un appareil dans son intégralité ou remplacez son NIC, devrez-vous être en mesure d'associer la nouvelle adresse à la clé existante dans votre base de données afin d'assurer la continuité de la collecte de données pour l'emplacement de déploiement?

  • Y aura-t-il une interface de maintenance par laquelle un utilisateur (autorisé ou non) pourrait changer 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 venait à modifier le MAC.

  • Vos données seront-elles jamais jointes à d'autres sources de données en utilisant MAC comme clé?

  • Utiliserez-vous jamais le MAC à des fins de mise en réseau autres que la simple navigation sur le LAN layer2 auquel l'appareil est connecté (filaire ou sans fil)?

  • Le réseau local auquel vos appareils sont connectés sera-t-il un réseau privé ou celui auquel un grand nombre de clients transitoires (comme les téléphones portables des employés) se connecteront?

Si vos réponses sont

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

alors je ne peux penser à aucun vrai défaut dans votre plan.

Gardez à l'esprit que vous n'avez pas besoin de MAC uniques au monde pour y parvenir; il vous suffit de vous assurer que le sous-ensemble d'appareils Internet qui appellent votre API est unique. Tout comme un nic en double attribué 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 de collision de clé de base de données sur un MAC s'il n'appelle jamais votre API.

Frank Thomas
la source
2
Juste un côté, au milieu des années 90, un ami administrateur système m'a dit qu'il venait de recevoir une boîte de Nics d'un fabricant qui avait tous la même carte réseau. Je n'ai aucune idée de la véracité de cette histoire, mais c'est à peu près la seule du genre que j'ai entendue, au-delà des allégations générales selon lesquelles certains fabricants ont "abusé" de leur allocation à un moment ou à un autre.
Frank Thomas
Merci pour la réponse détaillée. Je pense que la seule réponse qui ne correspond pas est # 3. Mais si nous devons réparer un appareil avec un nic cassé, nous remplacerions probablement tout l'appareil. Le client contrôle à la fois l'API et le matériel, et des contrôles physiques seront en place pour empêcher tout accès physique non autorisé aux périphériques. En outre, je pense qu'il est important de noter que beaucoup de commentaires / points ici sont liés à l'utilisation du MAC à des fins de mise en réseau, ce qui, je crois, peut être problématique à supposer unique. Ceci est purement pour un uuid / appareil qui ne nécessite pas de génération
Matt Phillips
cont: que je comprends sera spécifique au fabricant de périphérique / nic.
Matt Phillips
7
@FrankThomas: Cela arrive . Je suis allé à certaines conventions informatiques où un groupe de quelques dizaines de professionnels, pour la plupart, avait quelques personnes qui ont dit avoir rencontré cela. Apparemment, les départements de rénovation des grands fabricants ont été particulièrement enclins à le faire.
TOOGAM
@FrankThomas vient de recevoir une boîte de Nics ... tous avaient le même NIC
Dmitry Kudriavtsev
9

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 n'ont pas besoin d'être (globalement) uniques.

Le MAC doit être unique sur le réseau local, afin que l'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 les choses fonctionnent très bien, simplement parce que la probabilité d'avoir deux MAC identiques sur le même LAN, même si elles ne sont pas uniques, est assez faible.

Une autre raison est qu'il existe simplement plus d'appareils que d'adresses. Bien que les adresses 48 bits semblent avoir suffisamment 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). La moitié est l'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 Intel comme exemple. Ils ont enregistré un total de 7 OUI, 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 chaque ordinateur x86 que j'ai possédé au cours des 10-15 dernières années avaient une carte réseau Intel dans le chipset. Il y a certainement plus de 116 millions d'ordinateurs Intel dans le monde. Ainsi, leurs MAC ne peuvent être uniques (dans un sens unique au monde).

En outre, des cas ont été signalés euh ... moins chers ... les fabricants "volaient" simplement les adresses de l'OUI de quelqu'un d'autre. En d'autres termes, ils ont simplement utilisé une adresse aléatoire. J'ai entendu parler de fabricants qui n'utilisent que 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 LAN. pour même le remarquer.

Maintenant, que faire de votre problème?

La solution est peut-être plus simple que vous ne le pensez. Vos appareils IoT auront très probablement besoin d'une certaine notion de temps, généralement le temps est automatiquement obtenu via NTP. La précision typique du NTP est de l'ordre de la microseconde (oui, c'est micro, pas milli). J'ai juste couru ntpq -c rlpour ê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 à la même microseconde précise 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 - en pratique, cela ne se produira 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 chaque appareil. Sauf que ce n'est pas vrai du tout .
Compte tenu d'une minuterie haute résolution, les temps de démarrage sont mesurablement différents, même sur le même appareil, à chaque fois. Ce n'est peut-être que quelques horloges différentes (ou quelques centaines de milliers, si vous lisez quelque chose comme le compteur d'horodatage du processeur), donc pas très unique, mais cela ajoute certainement de l'entropie.
De même, le temps nécessaire connectpour revenir la première fois que vous accédez à votre site API sera légèrement, mais mesurablement, différent à chaque fois. De même, getaddrinfocela prendra un temps légèrement différent et mesurable pour chaque appareil 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 la première mise sous tension, heure de démarrage pour la première fois, heure de connexion) et calculez un hachage à partir de cela. MD5 fera très bien à cet effet. Là, tu es unique.

Bien que cela ne garantisse pas vraiment l' unicité, il le garantit "à peu près", avec une chance ineffaçable d'échec. Vous devriez avoir deux appareils avec des MAC identiques qui sont allumés pour la première fois sur la même microseconde, et ont pris exactement le même temps pour démarrer et pour se connecter à votre site. Cela ne va pas arriver. Si cela se produit, vous devriez 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, passez simplement à chaque appareil un nombre croissant séquentiellement (généré sur le serveur) la première fois qu'ils accèdent à votre API Web. Laissez l'appareil stocker ce numéro, c'est fait.

Damon
la source
était la commande censée êtrentpq -c rl?
Tom
1
@Tom: Oui, je ne sais pas pourquoi il se lit "r1" dans ma réponse, doit certainement être "rl" !? Corrige ça :)
Damon
Je gérais un LAN il y a environ 30 ans et nous avions des MAC en double. Le fournisseur a utilisé le numéro de série de la carte d'E / S pour générer le MAC, mais il a oublié d'inclure le numéro de modèle, et nous avions deux modèles différents avec le même numéro de série. Heureusement, ils ont fourni un moyen de définir le MAC manuellement, nous l'avons donc remplacé sur l'un des appareils.
Barmar
Les adresses MAC sont généralement attribuées par le vendeur de cartes et non par le vendeur de puces. Intel aurait donc seulement besoin d'acquérir des adresses pour les cartes Intel et non les puces Intel.
plugwash
Nous allons probablement emprunter une voie similaire à votre dernier paragraphe. Merci pour les idées!
Matt Phillips
2

Puisque le problème ici est vraiment un problème XY, je vais résoudre ce problème: comment obtenir un identifiant unique pour un morceau de matériel la première fois qu'il démarre sans avoir à précharger les identifiants sur eux. Toutes les bonnes méthodes se résument vraiment à une chose: avoir une source d'entropie.

Si votre matériel a quelque chose conçu pour être une source d'entropie matérielle (remarque: il s'agit essentiellement d'une exigence pour toute implémentation de périphérique IoT appropriée car elle est nécessaire pour TLS, donc votre matériel doit être conçu avec cela à l'esprit), utilisez simplement cela. Sinon, vous devez faire preuve de créativité.

Heureusement, presque tous les ordinateurs fabriqués ont une excellente source d'entropie: les oscillateurs à cristal (horloges). La vitesse d'un cristal donné ne dépend pas seulement de subtils changements de température, mais est même soumise à une hystérésis de température de manière non linéaire. Cependant, pour mesurer l'entropie, vous avez besoin d'une deuxième horloge pour chronométrer la première. Cela signifie que, chaque fois que votre ordinateur possède au moins deux horloges que vous pouvez échantillonner, vous pouvez utiliser le taux de l'une tel que mesuré par l'autre comme source d'entropie de très haute qualité.

R .. GitHub ARRÊTEZ D'AIDER LA GLACE
la source
1
C'est une bonne idée, à condition que l'op puisse fonctionner avec une valeur entièrement non déterministe. La question est de savoir si le périphérique est réinitialisé et la valeur redéfinie, répondra-t-il à leurs besoins de gestion et de continuité.
Frank Thomas
0

Je ne veux pas répondre directement à la question car il existe d'autres très bonnes réponses, mais à la place, je voudrais 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. Il s'agit d'un identifiant unique pour la carte mère et donc l'appareil. Gardez à l'esprit que même les appareils IoT peuvent avoir plusieurs cartes réseau (LAN et WiFi), donc 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 est uniquement garanti d'être unique dans un environnement convivial.

Robert
la source
0

Je déteste assumer un problème XY parce que souvent l'OP a une bonne raison, bien que complexe, de faire les choses comme ils le font, mais vous voudrez peut-être examiner 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 appareils sont 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. Cela ne fonctionne pas si bien entre les appareils de différents fabricants, même si vous les combinez avec le nom du fabricant et le numéro de modèle, en raison de différents formats de numéro de série et éventuellement de différentes API pour obtenir le numéro de série dans le cas d'appareils embarqués / propriétaires . Une alternative au numéro de série de l'appareil peut être le numéro de série de la carte mère, du processeur ou du disque dur (je pense que les licences Windows utilisent une combinaison de ces derniers).

Il convient également de se rappeler que les formateurs de système de fichiers génèrent généralement un ID unique pour chaque système de fichiers. Sauf si vous préparez tous les périphériques à partir de la même image (ce que je recommanderais de faire, pour des raisons indépendantes), chaque disque dur aura déjà un ID unique stocké dans le système de fichiers que vous pouvez utiliser.

Cela dit, il n'y a vraiment aucune raison de ne pas utiliser les adresses MAC, surtout si dans le cadre de votre processus d'approvisionnement, vous pouvez déterminer qu'elles sont en fait uniques (bien que cela ne devrait même pas être nécessaire, en supposant que nous ne parlons pas plus de quelques milliers d'appareils ici). Bien sûr, gardez à l'esprit que tout ce que vous utilisez peut être usurpé par l'appareil, alors ne vous fiez pas à cela pour l'authentification dans un environnement non fiable (vous avez dit que c'est une configuration privée, donc c'est probablement un environnement "de confiance" où vous ne le faites pas) se soucient que votre client usurpe ses propres appareils contre ses propres serveurs, mais il doit évidemment en tenir compte si la gestion des appareils est confiée à des tiers ou à des utilisateurs finaux).

Micheal Johnson
la source
Je ne suis pas vraiment certain qu'il s'agit en fait d'un problème XY, du moins pas pour notre public. Il est clair et sans ambiguïté que l'OP a besoin d'un mécanisme permettant à son logiciel d'identifier de manière persistante un périphérique, puis de lui associer logiquement des valeurs. Le PO ne pose pas la mauvaise question; s'ils avaient demandé quel mécanisme ils pouvaient utiliser pour identifier les appareils, cette question aurait été classée comme hors sujet pour avoir un lien avec la programmation et pour ne pas exprimer un problème spécifique avec le matériel informatique ou les logiciels. Demander l'examen par les pairs d'une décision technique n'est pas XY.
Frank Thomas
@FrankThomas Comme je l'ai dit, je déteste assumer un problème XY. Je ne suppose pas un problème XY ici. Je conviens qu'il est parfaitement acceptable de demander la révision d'une solution particulière à un problème même s'il existe d'autres solutions. Mais les gens accusent souvent ce genre de questions d'être des problèmes XY.
Micheal Johnson