
ハードウェアのプロビジョニングを制御し、同じハードウェア モデルのすべてのデバイスがネットワーク インターフェイスに固有の MAC アドレスを持っていることを判断できるシナリオでは、その前提を使用するコードを作成することに欠点はありますか? (いくつかの回答に基づく注記: この前提を使用してネットワーク コードを作成するつもりはありません。これは、フィールドに展開する前に手動でデバイス HDD を ID で生成して更新することなく、デバイスごとに UUID を持つための低タッチの方法であるだけです)
この背景は、クライアント向けのプライベート ハードウェア IOT タイプの実装を研究しているからです。ネットワーク機能を備えたハードウェア デバイスのセットをプロビジョニングし、リモート ロケーションにインストールします。これらのデバイスは、メッセージを送信して API に通信を返します。セットアップの複雑さを軽減するために、デバイスのネットワーク インターフェイスの MAC アドレスをメッセージで送信し、これらのメッセージを API 側の「device_id」に結び付けたいと考えていました。使用前にデバイスでセットアップする必要がないようにすることで、通常の操作中にクエリするだけで済むのではないかと考えています。各デバイスの MAC アドレスが実際に一意であることを判断でき、デバイスが交換されるタイミングを制御して、その device_id のメッセージに異なる MAC アドレスが含まれるようになると確信できます。
答え1
プロビジョニング中に、製造元の MAC が、作成しているデバイスのネットワーク内で実際に一意であることを確認できるというあなたの発言に基づくと (それ自体は確実ではありませんが、そうあるべきです)、おそらく問題なく続行できますが、次の質問を考慮してください。
セキュリティ チェック (認証、承認) に MAC を使用していますか? その場合、MAC だけでは不十分です。検討すらしないでください。暗号化構造を使用して、認証要求を安全に送信してください。
48 ビットの幅は十分でしょうか? おそらく十分でしょうが、尋ねる価値はあります。
NIC を交換してデバイスを修理する必要があることはありますか?
デバイス全体を交換したり、NIC を交換したりする場合、展開場所のデータ収集の継続性を確保するために、新しいアドレスをデータベース内の既存のキーに関連付ける必要がありますか?
ユーザー (承認されているかどうかに関係なく) が ROM、ドライバー、または OS レベルで NIC を変更できるメンテナンス インターフェイスはありますか? 攻撃者が MAC を変更すると、データに欠陥が生じる可能性があります。
MAC をキーとして使用して、データが他のデータソースと結合されることはありますか?
デバイスが接続されているレイヤー 2 LAN (有線または無線) を単にナビゲートする以外のネットワーク目的で MAC を使用する予定はありますか?
デバイスが接続されている LAN は、プライベート ネットワークですか、それとも多数の一時的なクライアント (従業員の携帯電話など) が接続するネットワークですか?
もしあなたの答えが
NO, yes, no, no, no, no, no, private
そうすれば、あなたの計画に本当の欠陥があるとは思えません。
これを実現するために、グローバルに一意の MAC は必要ないことに注意してください。API を呼び出すインターネット デバイスのサブセットが一意であることを確認するだけで済みます。2 つの異なる都市で割り当てられた重複した NIC は、異なる LAN 上にあるため衝突しないのと同様に、MAC が API を呼び出さなければ、データベース キーの衝突は発生しません。
答え2
MACアドレスは一意ではない
MACアドレスには重複が存在する可能性があり、また、重複することもあります。これにはいくつかの理由がありますが、その1つは必要はない(世界的に)ユニーク。
MAC はローカル ネットワーク上で一意である必要があります。そうすることで、ARP/NDP が機能し、スイッチが着信データグラムの送信先を認識できるようになります。通常 (必ずしもそうとは限りませんが)、この前提条件は満たされ、問題なく動作します。これは、同じ LAN 上に 2 つの同一の MAC が存在する可能性は、一意でなくても非常に低いためです。
もう 1 つの理由は、アドレスの数よりもデバイスの数の方が多いことです。48 ビットのアドレスは、終末まですべての人にとって十分なアドレスであるように思われますが、実際はそうではありません。
アドレス空間は 24 ビットの半分に分かれています (少し複雑ですが、細かいことは無視しましょう)。半分は OUI で、IEEE に登録して約 2,000 ドルで会社に割り当てることができます。残りの 24 ビットは、自由に使用できます。もちろん、大手企業が行っているように、複数の OUI を登録することもできます。
インテルを例に挙げてみましょう。インテルは合計7つのOUIを登録しており、合計1億1600万のアドレスを持っています。
私のコンピューターのメインボード(X99チップセットを使用)とラップトップのメインボード、そして毎私が過去10~15年間所有していたx86ベースのコンピュータには、チップセットの一部としてIntelネットワークカードが搭載されていました。確かに、世界には1億1600万台以上のIntelベースのコンピュータがあります。したがって、それらのMACはありえないユニークであること(世界的にユニークという意味で)。
また、安価なメーカーが他社の OUI からアドレスを「盗む」というケースも報告されています。言い換えれば、ランダムなアドレスを使用しているだけです。製品ライン全体に同じアドレスを使用するメーカーもあると聞きました。どちらもあまり適合していないし、あまり意味がありませんが、どうすればよいのでしょうか。このようなネットワーク カードは存在します。繰り返しますが、これが問題になる可能性は実用的問題は依然として非常に少ない。アドレスが本来の目的で使用される場合、2つのアドレスが必要になる。同じLAN上気づくことさえできない。
さて、あなたの問題に対して何をすべきでしょうか?
解決策は、あなたが思っているよりも簡単かもしれません。IoT デバイスには、おそらく何らかの時間の概念が必要ですが、通常、時間は NTP によって自動的に取得されます。NTP の一般的な精度はマイクロ秒の範囲です (そうです、マイクロです。ミリ秒ではありません)。ntpq -c rl
念のため実行したところ、2 -20 と表示されました。
2 台のデバイスがまったく同じマイクロ秒で初めてオンになる可能性は非常に低いです。もちろん、一般的には発生する可能性があります (特に、非常に短期間で何百万台も販売した場合、成功おめでとうございます!)。しかし、可能性は高くなく、実際には発生しません。したがって、最初に起動した後は、永続的なストアで時間を節約してください。
IoT デバイスの起動時間はどのデバイスでも同じになります。しかし、それは全く真実ではない
高解像度のタイマーがあれば、同じデバイスであっても起動時間は毎回測定可能なほど異なります。おそらく数クロックの違い(CPUのタイムスタンプカウンターのようなものを読み取れば数十万の違い)なので、全体としてそれほどユニークではありませんが、確かにエントロピーが追加されます。同様
に、connect
API サイトに初めてアクセスしたときに戻る時間は、毎回わずかに異なりますが、測定可能なgetaddrinfo
程度に異なります。同様に、Web API のホスト名を初めて検索するときには、デバイスごとにわずかに異なる測定可能な時間がかかります。
3 つまたは 4 つのエントロピー ソース (MAC アドレス、最初の電源投入時刻、最初の起動時刻、接続時刻) を連結し、そこからハッシュを計算します。この目的には MD5 が適しています。これで、あなたはユニークになります。
それはそうではないが本当に一意性を保証するとしたら、それは「ほぼ」それを保証し、失敗する可能性は無視できるほどです。 同じマイクロ秒で初めて電源がオンになり、起動にまったく同じ時間がかかり、サイトに接続する、同一の MAC を持つ 2 つのデバイスが必要になります。 そんなことは起こりません。 もしそうなったら、すぐに宝くじを買ってください。なぜなら、どう見ても当選が保証されているからです。
ただし、「発生しない」という保証が不十分な場合は、各デバイスが Web API に初めてアクセスしたときに、順番に増加する番号 (サーバーで生成) を各デバイスに渡すだけです。デバイスにその番号を保存させれば完了です。
答え3
ここでの問題は実際には XY 問題なので、その解決方法、つまりハードウェアに識別子を事前にロードせずに、ハードウェアを初めて起動したときにその一意の識別子を取得する方法について取り上げます。すべての優れた方法は、結局のところ、エントロピーのソースを持つことに集約されます。
ハードウェアにハードウェアエントロピーソースとして設計されたものがある場合(注:これはTLSに必要なため、適切なIoTデバイスの実装には基本的に必須です。そのため、ハードウェアすべきそれを念頭に置いて設計されている場合は、それを使用してください。そうでない場合は、創造性を発揮する必要があります。
幸いなことに、これまでに作られたほぼすべてのコンピューターには、優れたエントロピー源が備わっています。水晶発振器(時計)結晶の速度は、微妙な温度変化だけでなく、温度にも左右される。ヒステリシス非線形的に。ただし、エントロピーを測定するには、最初のクロックの時間を計るための 2 番目のクロックが必要です。つまり、コンピューターにサンプリングできるクロックが少なくとも 2 つある場合は、1 つのクロックで測定されたレートを、非常に高品質のエントロピー ソースとして使用できます。
答え4
私は XY 問題を想定するのは嫌いです。なぜなら、多くの場合、OP は物事をそのように行うのに、複雑ではあっても正当な理由を持っているからです。しかし、MAC アドレスのようにデバイスに「組み込まれ」ていて、独自の識別子を生成する必要がない、各デバイスの一意の識別子を生成する他の方法を検討することもできます。
デバイスがすべて同じメーカーのもの (または、さらに良いことに同じモデルのもの) であれば、シリアル番号を使用して識別子を生成できます。ただし、組み込み/独自仕様のデバイスの場合、シリアル番号の形式が異なり、シリアル番号を取得するための API も異なる可能性があるため、メーカー名とモデル番号と組み合わせても、異なるメーカーのデバイス間ではうまく機能しません。デバイスのシリアル番号の代わりに、マザーボード、CPU、またはハード ディスクのシリアル番号を使用できます (Windows ライセンスでは、これらの組み合わせが使用されていると思います)。
また、ファイルシステムフォーマッタは通常、ファイルシステムごとに一意の ID を生成するということも覚えておく価値があります。すべてのデバイスを同じイメージから準備しない限り (無関係な理由から、そうすることをお勧めします)、各ハードディスクには、使用可能な一意の ID がファイルシステムに既に保存されています。
そうは言っても、本当に理由はありませんないMAC アドレスを使用するには、特にプロビジョニング プロセスの一環として、それらが実際に一意であることを判断できる場合 (ただし、数千台以下のデバイスについて話しているのであれば、これは必要ないはずです) は、使用するものはすべてデバイスによって偽装される可能性があることに留意してください。したがって、信頼できない環境での認証にはこれに依存しないでください (プライベート設定であるとおっしゃったので、これはおそらく「信頼できる」環境であり、クライアントが自分のサーバーに対して自分のデバイスを偽装してもかまいませんが、デバイスの管理がサードパーティまたはエンド ユーザーに引き渡される場合は、当然これを念頭に置く必要があります)。