開発者ツール · UUID ジェネレーター
バージョン 1 UUID から MAC アドレスと作成時間が漏洩する可能性がある
· なぜそれが重要なのか
uuid 暗号化 ブラウザ API
時間ベースの UUID には、60 ビットのタイムスタンプと、実際のネットワーク カード アドレスであることが多い 48 ビットのノード識別子が埋め込まれています。この記事では、部外者がそこから何を読み取ることができるのか、そしてなぜランダム生成によって問題が回避されるのかを示します。
ラップトップに名前を付ける識別子 — エクスポートされたドキュメント内の ID が単なる ID を超えている理由
バージョン 1 UUID は、タイムスタンプ、MAC アドレス、およびクロック シーケンス値から構築されます。 60 ビットのタイムスタンプは、グレゴリオ暦改革の日である 15 10 月 1582 からの 100 ナノ秒間隔の数を表します。 48 ビットのノード フィールドには、伝統的に、UUID を生成したネットワーク インターフェイスの IEEE 802 MAC アドレスが含まれています。ドキュメントをエクスポートするか、ツールを実行するか、バージョン 1 UUID を埋め込むファイルを保存すると、後でその UUID をデコードする人は誰でも、それがいつ作成されたか、またノード フィールドが実際の MAC アドレスの場合はどのマシンがそれを作成したかを読み取ることができます。この情報は、不透明な識別子のように見えるものから静かに漏洩します。
v1 UUID の構造 - タイムスタンプ フィールド、クロック シーケンス、ノード フィールド、およびそれぞれが 36 文字のどこに位置するか
情報漏洩は微妙ですが、プライバシーと帰属に関して重大な影響を及ぼします。ドキュメントの共著者と共同作業していて、ネットワーク カードの MAC アドレスが埋め込み v1 UUID に含まれている場合、オブザーバーは特定の機関または場所で使用されているハードウェアを学習します。特定の時刻にドキュメントをエクスポートする場合、各 v1 UUID のタイムスタンプは、作業が発生した時点を境界とします。匿名性を維持しようとする著者は、UUID タイムスタンプを既知の出版日または文書作成イベントと関連付けることによって匿名化を解除できます。識別子は、不透明な 36 文字列としてフォーマットされているため無害に見えますが、v1 フォーマットを知っていてデコードしようとする人にとってはまったく不透明ではありません。
オブザーバーが知ること — レコードがいつ作成されたか、ノードがハードウェア アドレスの場合はどのマシンまたはベンダーがそれを作成したか
v1 UUID の構造は、構造が決定的であり、公的に文書化されているため、何が抽出できるかを明確にしています。 RFC 9562 はレイアウトを定義します: time_low の場合は 32 ビット、time_mid の場合は 16 ビット、1 に設定されたバージョンの場合は 4 ビット、time_high の場合は 12 ビット、バリアントの場合は 2 ビット、 Clock_seq には 14 ビット、ノードには 48 ビット。時間フィールドは合計 60 ビットで構成され、これを組み合わせて 1582 以降の 100 ナノ秒間隔として解釈すると、正確な作成瞬間が 100 ナノ秒以内になります。 48 ビットのノード フィールドは通常、MAC アドレスを 48 ビットの整数として保持します。デコードは決定的です。バイトを読み取り、フィールドをマスクしてシフトし、値を解釈します。暗号化は関係しません。 UUID 構造により、エンコードが完全に透過的かつ可逆的になります。
警告の歴史 - ドキュメントに埋め込まれた識別子が著者を追跡するためにどのように使用されてきたかを憶測なしに説明
RFC 9562 はプライバシーの歴史を認めており、コストが利点を上回るため、新しいアプリケーションには v1 を推奨しません。この仕様には、プライバシーに関する考慮事項が文書化された v4 ランダムおよび v7 時間順の代替案が含まれています。バージョン 1 は、展開されたシステムとの下位互換性のために保持されていますが、慎重なセキュリティ レビューと公開の明示的な正当化がなければ、新しいコードは v1 UUID を生成すべきではありません。この脆弱性は見落としではありませんでした。これは、プライバシー漏洩が主要な懸念事項ではなく、追跡が分散システムの識別に許容される機能であった 1980 年代における意図的な設計上の選択でした。
動作する例 — サンプル v1 UUID を手動でタイムスタンプ フィールドとノード フィールドにデコードする
1998 で作成されたドキュメント内の v1 UUID には 1998 時代の時刻をエンコードしたタイムスタンプが含まれているため、タイムラインは暴露を理解する上で重要です。これはフォレンジックには役立ちますが、それ自体が問題です。 v1 UUID を持つ履歴ドキュメントがあり、後でそれを共有すると、タイムスタンプが保持されます。 UUID が特定の時点で生成されたという歴史的事実を遡って削除することはできません。新しい v1 UUID の生成を停止することのみ可能です。一部のアプリケーションは、実際の MAC をランダムな仮名に置き換えることで MAC アドレスの漏洩を軽減しようとしましたが、タイムスタンプは完全に読み取り可能でデコード可能なままです。
v4 と v7 の変更点 — ランダムな UUID にはマシン データが含まれません。 v7 では依然として作成時間が明らかになりますが、これは許容される場合と許容できない場合があります。
動作する例では、RFC 9562 サンプル ベクトルを使用して実際にデコードする方法を示します。仕様から f81d4fae-7dec-11d0-a765-00a0c91e6bf6 のような v1 UUID を取得します。バイトの順序は f81d4fae 7dec 11d0 a765 00a0c91e6bf6 です。バージョン フィールドは 3 番目のグループにあります。16 進数の 11d0 は、バイナリでは 0001 0001 1101 0000 です。最初の 4 ビットは 0001、つまりバージョン 1 です。タイムスタンプは、最初、2 番目、および 3 番目のグループの一部に分割されます。time_low は 10 進数 4170404526 の f81d4fae、time_mid は 10 進数 32236 の 7dec、time_high は、10 進数 464 のバージョン ニブルを削除した後の 3 番目のグループの 1d0 です。これらを 60 ビット値に結合すると、1582 からの 100 ナノ秒間隔を表す数値が得られます。
これでカバーされないもの — 一部の v1 実装が提供するランダム化ノード オプション。タイムスタンプ リークは軽減されますが、削除されません。
4 番目と 5 番目のグループのノード フィールドは a765 00a0c91e6bf6 で、ビット 0 が信頼性を示している場合にマシン情報をエンコードします。ノードフィールドの最初のオクテットの最下位ビットがゼロの場合、それは実際の IEEE アドレスを示します。 1 に設定すると、プライバシーのために生成された擬似乱数値を示します。この例では、16 進数の a765 は 2 進数では 10100111 01100101 です。最下位ビットは 1 であるため、これはランダムな擬似ノードであり、実際の MAC ではありません。ただし、古い実装では実際の MAC アドレスが直接保存される場合があり、その場合、48 ビットのノード フィールドがネットワーク カード識別子にデコードされます。 IEEE は MAC プレフィックスのレジストリを維持しています。ネットワーク カードが特定のプレフィックスで始まっていることがわかれば、使用しているコンピュータの製造元やモデルが絞り込まれる可能性があります。
要点: ID が何を開示しているのかを知る — ToolAcre ジェネレーターは CSPRNG からすべての識別子を取得するため、MAC アドレスやタイムスタンプが漏洩することはありません
RFC 9562 バージョン 4 以降では、エンコードされた情報ではなくランダム データのみを使用することで、この漏洩を意図的に回避しています。バージョン 4 UUID は、バージョン フィールドに 4 ビット、バリアント フィールドに 2 ビットを含む、暗号化ランダム データの 122 ビットです。ビットを読んでも、UUID が有効であること以外は何もわかりません。デコードするタイムスタンプや抽出するマシンデータはありません。バージョン 7 には並べ替えの利点のためのタイムスタンプが含まれていますが、そのタイムスタンプは、あいまいな 1582 ベースの値ではなく、馴染みのある標準化された Unix エポックから派生しており、仕様には識別子に時間情報が存在することが明示的に文書化されています。プライバシーのプロパティはバージョン間で根本的に異なります。