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

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,

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.

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.

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é.

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.

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).