デバイスのMACアドレスが一意であると想定しない理由
ハードウェアのプロビジョニングを制御し、同じハードウェアモデルのすべてのデバイスが実際にネットワークインターフェイスに一意のMACアドレスを持っていると判断できるシナリオで、その仮定を使用するコードを作成することの欠点はありますか？ （一部の返信に基づくメモ：この仮定を使用してネットワークコードを記述するつもりはありません。これは、前にIDを使用してデバイスのHDDを手動で生成および更新する必要がなく、デバイスごとにUUIDを使用する簡単な方法を意図したものですフィールドへの展開）
これの裏話は、クライアントにプライベートハードウェアIOTタイプの実装を実装することを研究しています。遠隔地にインストールするためのネットワーク機能を備えたハードウェアデバイスのセットをプロビジョニングします。これらのデバイスは、メッセージを送信することでAPIと通信します。セットアップの複雑さを軽減するために、メッセージでデバイスのネットワークインターフェイスのMACアドレスを送信し、これらのメッセージをAPI側の「device_id」に関連付けることを望んでいました。私の考えでは、使用する前にデバイスで設定する必要がないものにすることで、通常の操作中にクエリを実行できると思います。各デバイスのMACアドレスが実際に一意であると判断でき、デバイスを交換するかどうかを制御して、そのdevice_idのメッセージに別のMACアドレスが含まれるようになることを確認できます。
プロビジョニング中に、製造元のMACが作成しているデバイスのネットワーク内で実際に一意であることを確認できるという記述に基づいて（実際にはそうである必要はありませんが、それ自体は確実ではありません）、おそらく順調に進んでいます。ただし、次の質問を検討してください。
セキュリティー検査（認証、許可）にMACを使用していますか？その場合、MACでは不十分です。それさえ考慮しないでください。暗号化構造を使用し、認証リクエストを安全に送信します。
48ビットで十分ですか？それはおそらくですが、尋ねる価値があります。
NICを交換してデバイスを修復する必要がありますか？
デバイス全体を交換する場合、またはデバイスのNICを交換する場合、展開場所のデータ収集の継続性を保証するために、データベースの既存のキーに新しいアドレスを関連付けることができる必要がありますか？
ユーザー（許可されているかどうかに関係なく）がNIC、ROM、ドライバー、またはOSレベルで変更できるメンテナンスインターフェイスはありますか？攻撃者が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に同じMACが2つある可能性が非常に低いからです。
もう1つの理由は、アドレスよりも多くのデバイスが存在することです。 48ビットのアドレスは、一日の終わりまでにすべての人に十分なアドレスがあるように思えますが、そうではありません。
アドレス空間は2つの24ビットの半分に分割されています（少し複雑ですが、細かい部分は無視しましょう）。半分は、IEEEに登録して約2000ドルで会社に割り当てることができるOUIです。残りの24ビットは、好きなようにします。もちろん、いくつかのOUIを登録することができます。これは、大手プレイヤーが行うことです。
例としてIntelを取り上げます。彼らは合計7つのOUIを登録し、合計1億1600万のアドレスを提供しています。
私のコンピューターのメインボード（X99チップセットを使用）と私のラップトップのメインボードおよびeveryx86ベースのコンピューターのメインボード過去10〜15年間所有していたチップセットの一部としてIntelネットワークカードがありました。確かに、世界には1億1,600万台を超えるIntelベースのコンピューターがあります。したがって、それらのMACは一意ではありません（グローバルに一意の意味で）。
また、他の誰かのOUIからアドレスを「盗む」だけの製造業者もいます。つまり、ランダムなアドレスを使用しただけです。完全な製品範囲で同じアドレスを使用するメーカーについても聞いたことがあります。どちらも実際には順応していないか、意味がありませんが、それに対して何ができますか。これらのネットワークカードは存在します。繰り返しますが、実用的な問題になる可能性は、意図したとおりにアドレスが使用されている場合でも非常に低く、2つ必要です同じLANで気づくことさえあります。
さて、あなたの問題について何をしますか？
ソリューションは、おそらくあなたが考えるよりも簡単です。あなたのIoTデバイスはおそらく時間の概念を必要とするでしょう。通常、時間はNTPを介して自動的に取得されます。 NTPの典型的な精度はマイクロ秒の範囲です（はい、それはマイクロであり、ミリではありません）。私はntpq -c rl確かに言われました2-20。
2台のデバイスがまったく同じマイクロ秒で初めてオンになる可能性は非常に低いです。それは一般的に起こり得ることです（特に、非常に短い時間で数百万個を売った場合、成功をおめでとうございます！）、確かに。しかし、その可能性はそれほど高くありません。実際には起こりません。したがって、永久ストアで最初に起動した後の時間を節約できます。
IoTデバイスの起動時間は、すべてのデバイスで同じです。 それはまったく真実ではありません。
高解像度タイマーを考えると、起動時間は、同じデバイス上でも毎回かなり異なります。それは多分ほんのわずかなクロック刻み（またはCPUのタイムスタンプカウンターのようなものを読んだ場合は数十万）だけなので、まったくユニークではありませんが、確かにいくらかのエントロピーを追加します。
同様に、APIサイトに初めてアクセスしたときに connect が返るのにかかる時間はわずかですが、測定可能な限り毎回異なります。同様に、getaddrinfoは、Web APIのホスト名を初めて検索するときに、すべてのデバイスで測定可能なわずかに異なる時間を費やします。
エントロピーの3つまたは4つのソース（MACアドレス、最初の電源投入時間、最初の起動時間、接続時間）を連結し、それからハッシュを計算します。 MD5はその目的のためにうまく動作します。そこに、あなたはユニークです。
これは一意性を保証しませんが真に、一意性は「かなり」保証され、失敗の可能性は無視できます。同じマイクロ秒で初めてオンになり、起動してサイトに接続するのにまったく同じ時間をかけた、同じMACを持つ2つのデバイスが必要になります。それは起こりません。それが起こった場合、あなたはすぐに宝くじのプレイを開始する必要があります。
ただし、「発生しない」という保証が十分でない場合は、Web APIに初めてアクセスするときに、各デバイスに連続して増加する数（サーバー上で生成される）を渡すだけです。デバイスにその数を保存させてください。
ここでの問題は実際にはXY問題なので、私はそれを解決することに取り組みます。ハードウェアの最初の起動時に一意の識別子を取得する方法で、識別子をプリロードする必要はありません。すべての優れた方法は、エントロピーのソースを持つという1つのことに要約されます。
ハードウェアにハードウェアエントロピーソースとして設計されたものがある場合（注：これは、TLSに必要なため、基本的には適切なIoTデバイス実装の要件であり、ハードウェアが必要ですそれを念頭に置いて設計してください）、それを使用してください。そうでない場合は、創造的になる必要があります。
幸いなことに、これまでに作成されたほとんどすべてのコンピューターに、エントロピーの優れたソースがあります。 水晶発振器 （クロック）。与えられた水晶の速度は、微妙な温度変化に依存するだけでなく、非線形な方法で温度 ヒステリシス の影響を受けます。ただし、エントロピーを測定するには、最初の時間を計測するために2番目のクロックが必要です。つまり、コンピュータに2つ以上のクロックをサンプリングできる場合は、一方のレートを他方で測定したレートを非常に高品質のエントロピーソースとして使用できます。
他の非常に良い応答があるので、質問に直接答えたくありませんが、代わりに、デバイスIDとして使用できる別のより適切な値を提案したいと思います。
ハードウェアでサポートされている場合は、SMBIOS UUIDの使用を検討できます。これは、メインボード、つまりデバイスの一意のIDです。 IoTデバイスでも複数のNIC（LANおよびWiFi）を使用できるため、MACルートを選択する場合でも、一貫して1つを選択する方法を見つける必要があります。
また、UUIDは一意ですが、フレンドリーな環境でのみ一意であることが保証されているため、セキュリティ目的で使用しないでください。
XY問題を想定するのは嫌いです。なぜなら、OPは、彼らがしている方法で物事を行うための複雑な理由であるにもかかわらず、MACアドレスのように、各デバイスに一意の識別子を生成する他の方法を検討したい場合があるためです、はデバイスに「組み込まれている」ため、独自の識別子を生成する必要はありません。
すべてのデバイスが同じ製造元（またはさらに良いのは同じモデル）のデバイスである場合は、シリアル番号を使用して識別子を生成できます。これは、製造元名やモデル番号と組み合わせても、異なる製造元のデバイスではうまく機能しません。組み込み/専用デバイスの場合、シリアル番号の形式が異なり、シリアル番号を取得するためのAPIが異なる可能性があります。 。デバイスのシリアル番号の代わりに、マザーボード、CPU、またはハードディスクのシリアル番号を使用できます（Windowsライセンスではこれらの組み合わせを使用していると思います）。
また、ファイルシステムフォーマッタは通常、各ファイルシステムに対して一意のIDを生成することを覚えておく価値もあります。同じイメージからすべてのデバイスを準備しているのでない限り（無関係な理由でこれを行うことをお勧めします）、各ハードディスクには、使用できるファイルシステムに格納された一意のIDが既にあります。
とは言っても、MACアドレスを使用する理由は実際にはありませんnot特にプロビジョニングプロセスの一部として、それらが実際に一意であると判断できる場合（ただし、これは必要ないはずですが、ここでは数千のデバイスしか話していません）。もちろん、使用するものはすべてデバイスによって偽装される可能性があることに注意してください。信頼されていない環境では、認証にこれを当てにしないでください（これはプライベートセットアップであるため、おそらくこれは「信頼された」環境ではありません。クライアントが独自のサーバーに対して独自のデバイスをスプーフィングすることに注意してください。ただし、デバイスの管理がサードパーティまたはエンドユーザーに引き渡される場合は、クライアントが明らかにこれに留意する必要があります）。