デバイスのMACアドレスが一意であると想定しない理由

ハードウェアのプロビジョニングを制御し、同じハードウェアモデルを持つすべてのデバイスが実際にネットワークインターフェイス用に一意のMACアドレスを持っていると判断できるシナリオでは、その仮定を使用するコードを記述することのマイナス面はありますか？（いくつかの返信に基づく注意：この仮定を使用してネットワーキングコードを書くつもりはありません。前にidを使用してデバイスHDDを手動で生成および更新することなく、デバイスごとにuuidを使用するロータッチ方法を意図しています。フィールドへの展開）

これの裏話は、クライアント用のプライベートハードウェアIOTタイプの実装を調査していることです。ネットワーク機能を備えたハードウェアデバイスのセットをプロビジョニングして、遠隔地にインストールします。これらのデバイスは、メッセージを送信してAPIと通信します。セットアップの複雑さを軽減するために、メッセージでデバイスのネットワークインターフェイスのMACアドレスを送信し、これらのメッセージをAPI側の「device_id」に結び付けたいと考えていました。私の考えでは、使用する前にデバイスにセットアップする必要のないものにすることで、通常の操作中にクエリを実行することができます。各デバイスのMACアドレスが実際に一意であると判断できると仮定しても安全です。

プロビジョニング中に、製造元のMACが作成しているデバイスのネットワーク内で実際に一意であることを確認できるステートメントに基づいて（それ自体は確実ではありません）ただし、次の質問を考慮してください。

• セキュリティチェック（認証、承認）にMACを使用していますか？その場合、MACは十分ではありません。それも考慮しないでください。暗号化構造を使用し、認証要求を安全に送信します。

• 48ビットで十分ですか？それはおそらくありますが、尋ねる価値があります。

• nicを交換してデバイスを修復する必要がありますか？

• デバイス全体を置き換えるか、nicを置き換える場合、展開場所のデータ収集の継続性を確保するために、データベース内の既存のキーに新しいアドレスを関連付けることができる必要がありますか？

• ユーザーが（許可されているかどうかに関係なく）ROM、ドライバー、またはOSレベルでnicを変更するメンテナンスインターフェイスはありますか？攻撃者がMACを変更すると、データに欠陥が生じる可能性があります。

• MACをキーとして使用して、データを他のデータソースと結合することはありますか？

• デバイスが接続されているレイヤー2 LAN（有線または無線）をナビゲートする以外のネットワーキング目的でMACを使用することはありますか？

• デバイスが接続されているLANはプライベートネットワークですか、それとも多数の一時的なクライアント（従業員の携帯電話など）が接続するLANですか？

あなたの答えが

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

あなたの計画に本当の欠陥は考えられません。

これを実現するために、グローバルに一意のMACは必要ありません。APIを呼び出すインターネットデバイスのサブセットが一意であることを確認する必要があります。2つの異なる都市に割り当てられた重複したnicが異なるLAN上にあるために衝突できないように、APIを呼び出さなければ、MACでデータベースキーの衝突を起こすことはできません。

MACアドレスは一意ではありません

存在する可能性があり、MACと重複します。その理由はいくつかありますが、1つは（グローバルに）一意である必要はないということです。

MACはローカルネットワーク上で一意である必要があるため、ARP / NDPはその役割を果たし、スイッチは着信データグラムの送信先を認識します。通常、（必ずしもそうではない）その前提条件が満たされ、物事がうまく機能するのは、同じLAN上に2つの同一のMACが存在する可能性が、たとえそれらが一意でなくても非常に低いためです。

もう1つの理由は、アドレスよりも多くのデバイスが単に存在することです。48ビットアドレスは、数日が終わるまですべての人に十分なアドレスがあるように聞こえますが、そうではありません。

アドレス空間は2つの24ビットの半分に分割されます（少し複雑ですが、ささいな詳細は無視しましょう）。半分はOUIで、IEEEに登録して約2000ドルで会社に割り当てることができます。残りの24ビットは、好きなことをします。もちろん、いくつかのOUIを登録できます。これは、より大きなプレーヤーが行うことです。

例としてIntelを取り上げます。彼らは合計7つのOUIを登録し、合計1億1,600万のアドレスを割り当てました。
私のコンピューターのメインボード（X99チップセットを使用）とラップトップのメインボード、そして過去10〜15年間に所有していたすべての x86ベースのコンピューターのメインボードには、チップセットの一部としてIntelネットワークカードがありました。確かに、世界中に1億1600万台以上のIntelベースのコンピューターがあります。したがって、それらのMAC を一意にすることはできません（グローバルに一意の意味で）。

また、場合によっては、...安く...メーカーは、単に他の誰かのOUIからアドレスを「盗む」という報告もあります。言い換えれば、彼らはランダムなアドレスを使用しただけです。製品の完全な範囲に同じ住所を使用するだけのメーカーも聞いたことがあります。どちらも実際には準拠していないか、あまり意味がありませんが、それについて何ができますか。これらのネットワークカードが存在します。繰り返しますが、アドレスが意図された目的に使用される場合、それが実際的な問題になる可能性はまだ非常に低く、気付くために同じLAN上に 2つ持つ必要があります。

さて、あなたの問題についてどうすればいいですか？

解決策は、おそらくあなたが思っているより簡単です。ほとんどの場合、IoTデバイスには時間の概念が必要になります。通常、時間はNTPを介して自動的に取得されます。NTPの一般的な精度はマイクロ秒の範囲です（はい、ミリではなくマイクロです）。ntpq -c rl確かに走って、2 ^-20と言われました。

2つのデバイスがまったく同じマイクロ秒で初めてオンになる可能性は非常に低いです。一般的に起こり得ることです（特に、非常に短い時間で数百万個を販売している場合、成功をおめでとうございます！）。しかし、そうなる可能性は非常に低く、実際には起こりません。したがって、永続ストアで最初に起動した後の時間を節約してください。

IoTデバイスの起動時間は、すべてのデバイスで同じです。それがまったく真実でないことを除いて。
高解像度のタイマーを使用すると、同じデバイスであっても毎回起動時間がかなり異なります。CPUのタイムスタンプカウンターのようなものを読んだ場合、それはたぶん数クロックティックだけ異なる（または数十万）ので、完全に一意ではありませんが、確かにいくらかのエントロピーを追加します。
同様に、connectAPIサイトに初めてアクセスしたときに戻るのにかかる時間は、わずかですが、測定可能なほど毎回異なります。同様に、getaddrinfoWeb APIのホスト名を初めて検索する場合、デバイスごとにわずかに異なる測定可能な時間がかかります。

エントロピーの3つまたは4つのソース（MACアドレス、最初の電源投入時、最初の起動時間、接続時間）を連結し、そこからハッシュを計算します。MD5はその目的のためにうまく機能します。そこで、あなたはユニークです。

それは真に一意性を保証するものではありませんが、「ほとんど」それを保証し、失敗する可能性は無視できます。同じマイクロ秒で初めてオンになり、起動とサイトへの接続にまったく同じ時間がかかった同一のMACを持つ2つのデバイスが必要になります。それは起こりません。それが起こった場合、すべての出現に対して、あなたが勝つことが保証されているので、あなたはすぐに宝くじのプレイを開始する必要があります。

ただし、「発生しない」が保証として十分でない場合は、Web APIに初めてアクセスするときに、各デバイスに（サーバーで生成された）連続して増加する番号を渡すだけです。デバイスにその番号を保存させてください。

ここでの問題は本当にXYの問題であるため、それを解決する方法を説明します。最初に起動したときに、識別子をプリロードすることなく、ハードウェアの一意の識別子を取得する方法です。良い方法はすべて、エントロピーの源を持っているということだけです。

ハードウェアにハードウェアエントロピーソースとして設計されたものがある場合（注：これは、TLSに必要なため、基本的に適切なIoTデバイス実装の要件です。したがって、ハードウェアはそれを念頭に置いて設計する必要があります）、それを使用します。そうでない場合は、創造的になる必要があります。

幸いなことに、これまでに製造されたほとんどすべてのコンピューターには、優れたエントロピー源、つまり水晶発振器（クロック）があります。与えられた結晶の速度は、微妙な温度変化に依存するだけでなく、非線形の方法で温度ヒステリシスさえ受けます。ただし、エントロピーを測定するには、最初のクロックを計る2番目のクロックが必要です。これが意味することは、コンピューターに少なくとも2つのクロックをサンプリングできる場合は、もう一方によって測定された1つのレートを非常に高品質のエントロピーソースとして使用できるということです。

他の非常に良い応答があるので、質問に直接答えたくありませんが、代わりに、デバイスIDとして使用できる別のより適切な値を提案したいと思います。

ハードウェアでサポートされている場合、SMBIOS UUIDの使用を検討できます。これは、メインボードとデバイスの一意のIDです。IoTデバイスでも複数のNIC（LANおよびWiFi）を使用できるため、MACルートを選択する場合は、一貫して選択する方法を見つける必要があります。

また、UUIDは一意ですが、フレンドリーな環境でのみ一意であることが保証されているため、セキュリティ目的で使用しないでください。

XYの問題を想定するのは嫌いです。なぜなら、OPには複雑な理由がありますが、そうするのと同じように物事を行う理由がありますが、MACアドレスなど、 、デバイスに「組み込まれている」ため、独自の識別子を生成する必要はありません。

デバイスがすべて同じメーカー（または、さらに良いのは同じモデル）からのものである場合、シリアル番号を使用して識別子を生成できます。ただし、異なるシリアル番号形式と組み込み/専用デバイスの場合はシリアル番号を取得するための異なるAPIのために、メーカー名とモデル番号と組み合わせても、これは異なるメーカーのデバイス間ではあまりうまく機能しません。デバイスのシリアル番号の代わりに、マザーボード、CPU、またはハードディスクのシリアル番号を使用できます（Windowsライセンスではこれらの組み合わせを使用していると思います）。

また、ファイルシステムフォーマッタは通常、各ファイルシステムに対して一意のIDを生成することを覚えておく価値があります。同じイメージからすべてのデバイスを準備している場合を除き（無関係な理由で行うことをお勧めします）、各ハードディスクには使用可能なファイルシステムに一意のIDが既に保存されています。

とはいえ、MACアドレスを使用しない理由は特にありません。特に、プロビジョニングプロセスの一環として、実際に一意であると判断できる場合は（ただし、これは必要以上の話ではありませんが、ここに数千のデバイスがあります）。もちろん、使用するものはすべてデバイスになりすまされる可能性があるので、信頼できない環境での認証にはこれを当てにしないでください（プライベートセットアップであるため、これはおそらく「信頼できる」環境であり、クライアントが自分のデバイスを自分のサーバーに対してスプーフィングすることに注意してください。ただし、デバイスの管理がサードパーティまたはエンドユーザーに引き継がれる場合、クライアントは明らかにこのことに留意する必要があります。