Motivi per non presumere che l'indirizzo MAC del dispositivo sia univoco

In uno scenario in cui controlli il provisioning dell'hardware e puoi determinare che tutti i dispositivi con lo stesso modello hardware hanno effettivamente indirizzi MAC univoci per le loro interfacce di rete, ci sono degli svantaggi nella scrittura del codice che utilizza tale presupposto? (Nota basata su alcune risposte: non ho intenzione di scrivere codice di rete usando questo presupposto. È solo inteso come un modo low-touch di avere un uuid per dispositivo senza dover generare e aggiornare manualmente l'HDD del dispositivo con un ID prima schierandosi sul campo)

Il retroscena di questo è che sto cercando di implementare un'implementazione di tipo IOT hardware privato per un client. Forniremo una serie di dispositivi hardware con funzionalità di rete da installare in posizioni remote. Questi dispositivi comunicheranno quindi nuovamente a un'API inviando messaggi. Al fine di ridurre la complessità della configurazione, speravo di inviare l'indirizzo MAC dell'interfaccia di rete sul dispositivo nel messaggio, per legare questi messaggi a un "device_id" sul lato API. Il mio pensiero è che, rendendolo qualcosa che non deve essere configurato sul dispositivo prima dell'uso, può essere interrogato durante il normale funzionamento. Posso tranquillamente presumere che possiamo determinare che gli indirizzi MAC di ciascun dispositivo sono in realtà univoci,

In base alle tue dichiarazioni che puoi confermare durante il provisioning che il MAC del produttore è in effetti unico nella rete dei dispositivi che stai creando (che non è di per sé una certezza, anche se dovrebbe essere), probabilmente stai procedendo bene, ma considera le seguenti domande:

• Stai usando il MAC per i controlli di sicurezza (autenticazione, autorizzazione)? In tal caso, un MAC non è sufficiente. Non ci pensare nemmeno. Utilizzare una struttura crittografica e trasmettere in modo sicuro tutte le richieste di autenticazione.

• 48 bit sono abbastanza larghi? Probabilmente lo è, ma vale la pena chiedere.

• Avrai mai bisogno di riparare un dispositivo sostituendo il suo nic?

• Se si sostituisce un dispositivo nella sua interezza o si sostituisce al suo nic, sarà necessario essere in grado di associare il nuovo indirizzo alla chiave esistente nel database al fine di garantire la continuità della raccolta dei dati per la posizione di distribuzione?

• Ci sarà un'interfaccia di manutenzione tramite la quale un utente (autorizzato o meno) potrebbe cambiare la nic a livello di ROM, driver o sistema operativo? Un utente malintenzionato potrebbe introdurre difetti nei dati se dovesse modificare il MAC.

• I tuoi dati verranno mai uniti ad altre origini dati usando MAC come chiave?

• Utilizzerai mai il MAC per scopi di rete diversi dalla semplice navigazione nella LAN layer2 a cui è connesso il dispositivo (cablato o wireless)?

• La LAN a cui i tuoi dispositivi sono connessi, sarà una rete privata o a cui si collegheranno un gran numero di client transitori (come i cellulari dei dipendenti)?

Se le tue risposte lo sono

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

allora non riesco a pensare a nessun vero difetto nel tuo piano.

Tieni presente che non hai bisogno di MAC unici a livello globale per riuscirci; devi solo assicurarti che il sottoinsieme di dispositivi Internet che chiamano la tua API sia unico. Proprio come una nicchia duplicata assegnata in due città diverse non può scontrarsi perché si trovano su LAN diverse, non è possibile avere una collisione delle chiavi del database su un MAC se non chiama mai l'API.

Gli indirizzi MAC non sono univoci

Ci possono essere e saranno duplicati con i MAC. Ci sono diverse ragioni per ciò, una delle quali non deve essere (globalmente) unica.

Il MAC deve essere univoco sulla rete locale, quindi ARP / NDP può fare il suo lavoro e lo switch sa dove inviare i datagrammi in entrata. Di solito (non necessariamente) tale condizione è soddisfatta e le cose funzionano bene, semplicemente perché la probabilità di avere due MAC identici sulla stessa LAN, anche se non sono univoci, è piuttosto bassa.

Un altro motivo è che esistono semplicemente più dispositivi di quanti siano gli indirizzi. Mentre gli indirizzi a 48 bit sembrano avere abbastanza indirizzi per tutti fino alla fine dei giorni, non è così.

Lo spazio degli indirizzi è diviso in due metà a 24 bit (è leggermente più complicato, ma ignoriamo i piccoli dettagli). La metà è l'OUI che puoi registrare presso l'IEEE e assegnare alla tua azienda per circa 2000 dollari. I restanti 24 bit, fai quello che vuoi. Ovviamente puoi registrare diversi OUI, che è quello che fanno i giocatori più grandi.

Prendi Intel come esempio. Hanno registrato un totale di 7 OUI, dando loro un totale di 116 milioni di indirizzi.
La scheda madre del mio computer (che utilizza un chipset X99), nonché la scheda madre del mio laptop e la scheda madre di ogni computer basato su x86 di mia proprietà negli ultimi 10-15 anni, avevano una scheda di rete Intel come parte del chipset. Certamente ci sono più di 116 milioni di computer basati su Intel nel mondo. Pertanto, i loro MAC non possono essere unici (nel senso di globalmente unici).

Inoltre, sono stati segnalati casi di ... più economici ... produttori che semplicemente "rubano" indirizzi dall'OUI di qualcun altro. In altre parole, hanno appena usato un indirizzo casuale. Ho sentito parlare di produttori che usano lo stesso indirizzo anche per una gamma completa di prodotti. Niente di tutto ciò è veramente conforme o ha molto senso, ma cosa puoi fare al riguardo. Queste schede di rete esistono. Ancora una volta: la probabilità che diventi un problema pratico è ancora molto bassa se gli indirizzi vengono utilizzati per quello che sono destinati, è necessario averne due sulla stessa LAN per notarlo.

Ora, cosa fare del tuo problema?

La soluzione è forse più semplice di quanto pensi. Molto probabilmente i tuoi dispositivi IoT avranno bisogno di un po 'di tempo, di solito il tempo viene automaticamente ottenuto tramite NTP. La precisione tipica di NTP è nell'intervallo dei microsecondi (sì, è micro, non milli). Ho appena corso ntpq -c rlper essere sicuro e mi è stato detto ^2-20 .

La probabilità che due dei tuoi dispositivi vengano accesi per la prima volta nello stesso preciso microsecondo è molto bassa. In genere è possibile che accada (soprattutto se ne vendi milioni in poco tempo, congratulazioni per il tuo successo!), Certo. Ma non è molto probabile - in pratica non accadrà. Pertanto, risparmia tempo dopo il primo avvio nel negozio permanente.

Il tempo di avvio del dispositivo IoT sarà lo stesso su tutti i dispositivi. Solo che non è affatto vero .
Dato un timer ad alta risoluzione, i tempi di avvio sono misurabili in modo diverso anche sullo stesso dispositivo, ogni volta. Forse è solo qualche segno di spunta diverso (o qualche centinaio di migliaia, se leggi qualcosa come il contatore del timestamp della CPU), quindi non del tutto univoco, ma aggiunge sicuramente un po 'di entropia.
Allo stesso modo, il tempo necessario connectper tornare la prima volta che accedi al tuo sito API sarà leggermente, ma misurabile, diverso ogni volta. Allo stesso modo, getaddrinfoci vorrà un tempo leggermente diverso e misurabile per ogni dispositivo quando si cerca per la prima volta il nome host dell'API Web.

Concatena queste tre o quattro fonti di entropia (indirizzo MAC, ora della prima accensione, tempo di avvio per la prima volta, tempo di connessione) e calcola un hash da quello. MD5 farà proprio bene a tale scopo. Ecco, sei unico.

Sebbene ciò non garantisca veramente l' unicità, "praticamente" lo garantisce, con una trascurabile possibilità di fallimento. Dovresti avere due dispositivi con MAC identici che vengono accesi per la prima volta nello stesso microsecondo e che richiedono lo stesso tempo per l'avvio e la connessione al tuo sito. Non succederà. Se ciò dovesse accadere, dovresti immediatamente iniziare a giocare alla lotteria perché, in tutte le apparenze, sei sicuro di vincere.

Se, tuttavia, "non accadrà" non è abbastanza valido come garanzia, è sufficiente passare ogni dispositivo un numero progressivamente crescente (generato sul server) la prima volta che accedono all'API Web. Lascia che il dispositivo memorizzi quel numero, fatto.

Poiché il problema qui è davvero un problema XY, mi occuperò di risolverlo: come ottenere un identificatore univoco per un componente hardware la prima volta che si avvia senza dover precaricare gli identificatori su di essi. Tutti i buoni metodi si riducono davvero a una cosa: avere una fonte di entropia.

Se il tuo hardware ha qualcosa progettato per essere una fonte di entropia hardware (nota: questo è fondamentalmente un requisito per qualsiasi corretta implementazione del dispositivo IoT poiché è necessario per TLS, quindi il tuo hardware dovrebbe essere progettato tenendo presente questo), basta usare quello. In caso contrario, devi essere creativo.

Fortunatamente, quasi ogni computer mai realizzato ha un'eccellente fonte di entropia: oscillatori a cristallo (orologi). La velocità di un dato cristallo non dipende solo da lievi variazioni di temperatura, ma è soggetta anche all'isteresi della temperatura in modi non lineari. Tuttavia, per misurare l'entropia, è necessario un secondo orologio per cronometrare il primo. Ciò significa che, ogni volta che il tuo computer ha almeno due orologi che puoi campionare, puoi usare il tasso di uno misurato dall'altro come fonte di entropia di altissima qualità.

Non voglio rispondere direttamente alla domanda in quanto vi sono altre risposte molto valide, ma vorrei suggerire un altro valore più adatto che potrebbe essere disponibile da utilizzare come ID dispositivo.

Se supportato dal tuo hardware, potresti prendere in considerazione l'utilizzo dell'UUID SMBIOS. Questo è un ID univoco per la scheda madre e quindi il dispositivo. Tieni presente che anche i dispositivi IoT possono avere più schede di rete (LAN e WiFi), quindi se scegli la route MAC devi comunque trovare un metodo per sceglierne una in modo coerente.

Inoltre, sebbene l'UUID sia unico, non deve essere utilizzato per motivi di sicurezza in quanto è garantito per essere unico in un ambiente amichevole.

Odio assumere un problema XY perché spesso l'OP ha una buona ragione, sebbene complessa, per fare le cose nel modo in cui le sta facendo, ma potresti voler esaminare altri metodi per generare un identificatore univoco per ogni dispositivo che, come l'indirizzo MAC , è "integrato" nel dispositivo e non richiede la generazione del proprio identificatore.

Se i dispositivi appartengono tutti allo stesso produttore (o, meglio ancora, allo stesso modello), è possibile utilizzare il numero seriale per generare l'identificatore. Questo non funziona così bene su dispositivi di produttori diversi, anche se lo si combina con il nome del produttore e il numero del modello, a causa dei diversi formati di numero di serie e possibilmente diverse API per ottenere il numero di serie nel caso di dispositivi incorporati / proprietari . Un'alternativa al numero seriale del dispositivo potrebbe essere il numero seriale della scheda madre, della CPU o del disco rigido (credo che le licenze Windows utilizzino una combinazione di questi).

Vale anche la pena ricordare che i formattatori del filesystem in genere generano un ID univoco per ciascun filesystem. A meno che tu non stia preparando tutti i dispositivi dalla stessa immagine (cosa che consiglierei di fare, per motivi non correlati), ogni disco rigido avrà già un ID univoco memorizzato nel filesystem che puoi usare.

Detto questo, tuttavia, non c'è davvero alcun motivo per non utilizzare gli indirizzi MAC, soprattutto se durante il processo di provisioning è possibile determinare che sono effettivamente unici (anche se questo non dovrebbe nemmeno essere necessario, supponendo che stiamo parlando non più di qualche migliaio di dispositivi qui). Naturalmente, tieni presente che qualsiasi cosa tu possa utilizzare potrebbe essere falsificata dal dispositivo, quindi non fare affidamento su questo per l'autenticazione in un ambiente non attendibile (hai detto che si tratta di una configurazione privata, quindi presumibilmente si tratta di un ambiente "affidabile" in cui non lo fai preoccuparsi che il proprio client falsifichi i propri dispositivi contro i propri server, ma dovrebbero ovviamente tenerne conto se la gestione dei dispositivi viene affidata a terzi o utenti finali).