開發者工具 · 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 位，variant 為 2 位，clock_seq 為 14 位，node 為 48 位。時間欄位總共包含 60 位，當組合併解釋為自 1582 年以來的 100 奈秒間隔時，可產生精確到 100 奈秒以內的創建時刻。 48 位元節點欄位通常將 MAC 位址儲存為 48 位元整數。解碼是確定性的：讀取位元組、屏蔽和移動欄位並解釋值。不涉及密碼學； UUID結構使得編碼完全透明且可逆。
警示歷史－如何使用嵌入在檔案中的識別碼來追蹤作者身份，無需猜測即可描述
RFC 9562 承認隱私歷史並建議新應用程式不要使用 v1，因為成本大於效益。該規範包括 v4 隨機和 v7 時間排序替代方案，並記錄了隱私考慮因素。保留版本 1 是為了向後相容已部署的系統，但如果沒有仔細的安全審查和明確的暴露理由，新程式碼不應產生 v1 UUID。該漏洞並非疏忽，而是疏忽造成的。這是 20 世紀 80 年代的一個深思熟慮的設計選擇，當時隱私洩漏不是主要問題，追蹤是分散式系統識別的一個可接受的功能。
工作範例 - 手動將樣本 v1 UUID 解碼為其時間戳記和節點欄位
時間軸對於理解暴露很重要，因為在 1998 中建立的檔案中的 v1 UUID 包含編碼 1998 時代時間的時間戳，這對於取證很有用，但本身就是問題。如果您有帶有 v1 UUID 的歷史文件並稍後共享它們，則時間戳會保留。您無法追溯刪除在某個時間點產生 UUID 的歷史事實；您只能停止產生新的 v1 UUID。一些應用程式試圖透過用隨機假名替換真實 MAC 來緩解 MAC 位址洩漏，但時間戳仍然完全可讀和可解碼。
v4 和 v7 發生了什麼變化——隨機 UUID 不攜帶機器資料； v7 仍然顯示創建時間，這可能可接受也可能不可接受
一個工作範例顯示了使用 RFC 9562 範例向量進行實際解碼。從規範中取得 v1 UUID，例如 f81d4fae-7dec-11d0-a765-00a0c91e6bf6。位元組順序為 f81d4fae 7dec 11d0 a765 00a0c91e6bf6。版本欄位位於第三組：十六進位的 11d0 是二進位的 0001 0001 1101 0000。前 4 位是 0001，即版本 1。時間戳分為第一組、第二組和第三組的一部分：time_low 是十進制 4170404526 中的 f81d4fae，time_mid 是十進制 32236 中的 7dec，time_high 是刪除十進制 464 中的版本半字節後的第三組中的 1d0。將這些組合成 60 位元值給出一個表示的數字自 1582 年以來的 100 奈秒間隔。
這不包括 - 一些 v1 實作提供的隨機節點選項，它可以減輕但不會消除時間戳洩漏
第四組和第五組中的節點欄位是a765 00a0c91e6bf6，如果0位元指示真實性，則它對機器資訊進行編碼。如果節點欄位的第一個八位元組的最低有效位元為零，則表示真實的IEEE位址；如果設定為 1，則表示為隱私而產生的偽隨機值。在這個範例中，十六進位的 a765 是二進位的 10100111 01100101；最低有效位元是 1，所以這是一個隨機偽節點，而不是真正的 MAC。然而，較舊的實作有時會直接儲存真實的 MAC 位址，如果這樣做，48 位元節點欄位將解碼為網路卡標識符。 IEEE 維護 MAC 前綴註冊表；知道網路卡以某個前綴開頭可以縮小製造商的範圍，並可能縮小所用電腦的型號範圍。
重點：了解您的 ID 披露的內容 — ToolAcre 產生器從 CSPRNG 提取每個標識符，因此不會洩露 MAC 位址或時間戳
RFC 9562 版本 4 及更高版本故意透過只使用隨機資料而不是編碼資訊來避免這種洩漏。版本 4 UUID 是 122 位的加密隨機資料，其中 4 位用於版本欄位，2 位用於變數欄位。除了 UUID 有效之外，讀取這些位元不會顯示任何內容；沒有要解碼的時間戳，沒有要提取的機器資料。版本 7 包含一個用於排序好處的時間戳，但該時間戳源自熟悉和標準化的 Unix 紀元，而不是基於晦澀的 1582 值，並規範明確記錄了標識符中存在時間資訊。不同版本之間的隱私屬性存在根本差異。