介紹 Signal 自動金鑰驗證¶
翻譯備註：Signal 在 2026 年 8 月 11 日推出「自動金鑰驗證」（automatic key verification），底層技術是金鑰透明度（key transparency）。既有的安全碼（safety number）要當面或透過另一條可信管道核對，自動金鑰驗證改由 App 自己去比對，省掉約時間見面的步驟。技術在通訊軟體上還算新，Signal 這篇是少數把設計動機與運作方式一次說完的公開文件，因此先完整翻譯，文末再附上編輯註解，說明它擋得住什麼、擋不住什麼。
以下內容原文翻譯來自以下文章，主詞角色為 Signal：
文末有編輯註解：譯文結束後接著編輯註解，內容是 anoni.net 社群的補充，包含三條給非技術讀者的結論、十三則說明、一節發布後的後續補充，最後是常見問題與延伸閱讀。想先看社群觀點的讀者可以直接跳到那一節。
Signal 現在提供一項名為「自動金鑰驗證」的功能，用來補強既有的安全碼機制。Signal 的通訊一律採端對端加密，自動金鑰驗證多提供一條簡便的途徑，讓你確認端對端加密工作階段的兩端之間沒有非預期的第三方介入。
運作方式是由你、你的 Signal 聯絡人，以及第三方稽核者各自執行一組驗證，合起來提供與手動核對安全碼相同的保證。與安全碼相比，各項驗證都是獨立完成的，不需要當面見面，也不需要第二條通訊管道。
整套驗證機制確保電話號碼或使用者名稱與其公開加密金鑰之間的對應關係，在 Signal 生態系的所有參與者眼中都一致而且透明。可以防範的情境是金鑰在擁有者不知情的狀況下被抽換，例如惡意方入侵 Signal，把另一把金鑰掛到你聯絡人的電話號碼上。
要實際操作，請進入某位 Signal 聯絡人的個人資料頁，點「檢視安全碼」，再點「自動金鑰驗證」標題底下的「自動驗證」按鈕。功能可用而且驗證成功時，按鈕會顯示綠色勾號與「已完成加密驗證」。隨著時間累積，你這一次的驗證，加上聯絡人與第三方稽核者持續執行的驗證，共同確保該位聯絡人的金鑰在整個 Signal 生態系中保持一致。
功能背後的概念稱為「金鑰透明度」（key transparency），後文都會使用這個詞，說明我們為什麼要建一套金鑰透明度系統，並概述運作方式。
公開金鑰與私密金鑰入門¶
非對稱式密碼學讓你能傳訊息給朋友，而且只有朋友讀得到。它牽涉到一對數學上相互關聯的金鑰，稱為公開金鑰與私密金鑰，可以用在許多場合，收發訊息是其中之一。
想像你有一個上鎖的信箱，上面開了投遞口。公開金鑰像信箱的地址，可以給任何想寄信給你的人。私密金鑰像信箱的鑰匙，只有你持有，用它才讀得到寄來的訊息。任何人都可以把信投進你的信箱（用你的公開金鑰加密），只有你能打開來讀（用你的私密金鑰解密）。信箱地址必須公開，沒有人知道要寄到哪裡，你就收不到信。
你註冊 Signal 時，Signal App 會在註冊流程中替你產生一組公開金鑰與私密金鑰1。私密金鑰留在你的裝置上，只有你能存取，Signal 不行，其他人也不行。公開金鑰會送到 Signal，Signal 扮演所有使用者公開金鑰的中央目錄。你要傳訊息給另一位 Signal 使用者時，會向 Signal 索取對方的公開金鑰，再用 Signal 回傳的金鑰與你的私密金鑰把訊息加密。
中間人 Mallory 攻擊¶
傳訊息要先取得收件人的公開金鑰，取得公開金鑰就需依賴中央目錄。理論上，惡意的目錄營運者可以發動所謂的「中間人 Mallory」攻擊，不過要辦到，需要外部人士繞過主要雲端供應商的安全防護，或由握有權限的內部人士刻意鎖定特定帳號。手法極為進階，發生機率也很低，我們仍然想防住。以下沿用信箱的比喻，說明攻擊在假設情況下如何進行。
假設 Bob 想寄一張喝咖啡的邀請給朋友 Alice，於是他到中央目錄查她的信箱地址。目錄若被對手（Mallory）攻陷，可能把 Bob 導向 Mallory 的信箱。Bob 把信寄到他以為是 Alice 的信箱，信實際上進了 Mallory 的信箱。Mallory 接著用自己的信箱鑰匙取出 Bob 的信，讀過內容，需要的話改寫幾句，換一個信封，再轉寄到 Alice 的信箱。
Mallory 改寫的內容可以是咖啡店的地點或碰面時間，讓 Alice 前往錯誤的地點，或在錯誤的時間出現。Alice 看不出訊息被攔截或竄改過，在她眼中，訊息就是 Bob 直接寄來的。同一時間，Bob 會白等一場。就算 Mallory 選擇不動 Bob 的內容，光是讀得到，就已經構成通訊隱私的嚴重破口。
約咖啡出錯的代價相對低，同樣的攻擊放到其他情境，造成的傷害會大得多。
攻擊能成立，是因為 Bob 從來沒有真的驗證過 Alice 的地址。他只是相信目錄上列的信箱就是她的，而信任目錄是個合理的假設。
Bob 若想格外謹慎，可以當面向 Alice 問地址，或透過另一條可信的通訊管道問2。若 Alice 與 Bob 純粹是筆友，這條路走不通。
那麼，在無法見面、也沒有第二條管道的情況下，Bob 要如何驗證 Alice 的地址？
本文接下來會說明我們如何設計出一套系統，讓 Bob 不必直接聯絡 Alice，也能自動驗證中央目錄裡的資料。
用比喻設計一套金鑰透明度系統¶
要幫 Bob 確認目錄裡 Alice 的地址正確，一種做法是把目錄的每一次變更都記錄下來。有人改動目錄裡 Alice 的地址，就會留在按時間排序的日誌裡，因而可以被察覺。以下把信箱的比喻延伸下去，說得具體一點。
假設市立郵局裡有一位職員，把每個人的地址變更都記在一本公開帳本上。任何人換了新地址或更新既有地址，職員就在不斷變厚的帳本最後面加一頁，把地址變更記在那裡。職員用的是永久性的麥克筆，寫下去之後，沒有人能翻回那一頁撕掉或改內容。任何人都可以到郵局翻帳本查地址，包括查自己的。
使用帳本¶
對任何一筆地址，郵局的客戶有兩種方式跟帳本互動：
- 像 Bob 這樣的客戶，可以查別人（例如 Alice）的地址。
- 像 Alice 這樣的客戶，可以查自己的地址，確認帳本記得正確。
Bob 要找到 Alice 目前的地址，需從帳本的最後一頁開始，一頁一頁往前翻，翻到出現 Alice 的那一頁為止。他從尾端倒著翻，是因為他要的是 Alice 最新的地址，而地址可能隨時間變動過。帳本頁數越加越多，Bob 的工作量就越大，尤其在 Alice 有一陣子沒更新地址、中間又夾著大量別人的地址變更需要一頁頁過濾的時候。
帳本讓 Alice 能驗證自己的地址記得對不對，代價是她需把上次來訪之後新增的每一頁都看過，確認沒有一頁把她的地址寫錯。跟 Bob 一樣，頁數越多，工作量越重。
若 Alice 與 Bob 住在人口流動頻繁的城市，大家常換地址，一頁一頁翻的工作量會大到不切實際。兩人需要一種更有效率的方式來使用帳本。
引入索引本¶
現實中的書常附一份按字母排序的索引，讓讀者快速找到要的內容。同樣的想法可以套到帳本上，做法是替帳本至今收錄過地址的所有人名，另外做一本按字母排序的索引本。
帳本每加一頁反映新地址或地址變更，索引本也要跟著更新，所以職員每往帳本加一頁，就發行一版新的索引本，內容涵蓋截至那一頁為止已被帳本收錄地址的所有人。長久下來，就形成一座對外開放的索引本館藏。
先假設對帳本的任一頁，Alice 與 Bob 看到的一定是同一本索引本。下一節會談到系統裡的另一個元件，讓兩人能驗證這項假設。
有了上述結構，Bob 可以改用「二分搜尋」的策略在帳本裡查 Alice 的地址，輕鬆許多，用具體例子最好說明。
假設一段時間內有 100 筆新增或更新的地址，帳本因此有 100 頁，職員也發行了 100 個不同版本的索引本。為了簡化，假設 Alice 的地址只在帳本裡出現過一次，就是她剛搬來的時候。
Bob 先翻到帳本的中間，接著查對應那一頁的索引本。索引本按字母排序，找人名很快。若 Alice 的名字在那本索引本裡，代表兩種可能，它或許就是第一本收錄 Alice 的索引本，也或許第一次出現在更早的版本，也就是帳本更前面的某一頁。
兩種可能都讓 Bob 可以忽略帳本的後半段，改在前半段重複同樣的步驟，直到找出 Alice 地址變更所在的那一頁為止。更精確地說，Bob 的搜尋會在找到相鄰的兩本索引本時結束，前一本沒有 Alice 的地址，後一本有。
搜尋流程有幾個好處，第一個是有效率。帳本若有十億頁，最壞的情況原本要倒著翻完十億頁，現在 Bob 最多只需要檢視 30 頁就能找到 Alice 的地址，工作量比先前輕鬆太多。
Alice 仍然想確認職員沒有新增任何把她地址寫錯的頁面，不過她不必檢查每一頁帳本與每一本索引本。她只需要檢查 Bob 為了找她地址而查過的那幾頁，如此就能確保 Bob 查到的 Alice 地址經過 Alice 本人驗證。
由此帶出搜尋流程的第二個好處：Alice 與 Bob 面對頁數相同的帳本時，流程是確定性的。職員若在 Bob 與 Alice 兩次搜尋之間又加了頁，情況會複雜一些，主要的概念不變。帳本有十億頁時，Alice 可以照著 Bob 的搜尋流程走一遍，查 Bob 查過的同一批頁面，確認裡面沒有任何一頁把她的地址寫錯。
藉由對搜尋流程取得共識，Alice 與 Bob 建立起一套使用帳本的方式，讓各自的目標在實務上可行。帳本持續變厚，Bob 仍然有有效率的方法找到 Alice 的地址，Alice 也有有效率的方法確保 Bob 找到的地址正確。
為了說明清楚，上面的比喻做了簡化。實務上 Alice 可以多次更新地址，要支援這種搜尋，索引本裡要存的資料也不只有人名。我們已經把同樣的想法實作到 Signal 的訊息服務上，做成開源的金鑰透明度伺服器。
職員本身呢¶
到目前為止，搜尋流程的描述都假設 Alice 與 Bob 親自翻帳本、查索引本。實務上並不可行，帳本與索引本的體積遠超過兩人能直接處理的範圍。實際做法是 Alice 與 Bob 請職員代為搜尋，再回報結果。
但郵局可能已經被 Mallory 這類對手攻陷，由她假扮職員，最終目的是讓 Bob 誤以為 Alice 的地址實際上是 Mallory 家。所以 Alice 與 Bob 無法單純信任職員，必須有辦法自己獨立驗證搜尋流程。
做法是請職員把搜尋過程中查過的那些帳本頁面與索引本資料全部交回來，兩人自己再核對一次。
核對要有意義，前提是職員交回來的資料可信，於是浮現一個明顯的問題：假扮職員的 Mallory 若對記錄內容說謊怎麼辦？舉例來說，Mallory 可以私下另外維護一本帳本，裡面把 Alice 的地址記錯，或者對帳本的同一頁發行兩個不同版本的索引本。Mallory 可以把其中一套資料給 Alice，另一套給 Bob，讓兩人各自驗證手上的資料，卻察覺不到 Mallory 的把戲。
Alice 與 Bob 需要一位獨立的見證者，讓職員不敢造假。
第三方稽核者¶
要阻止 Mallory 給 Alice 與 Bob 不同的資料，兩人需仰賴第三方稽核者。稽核者的角色像公證人，在職員一頁一頁往帳本加、一版一版發行對應索引本的時候，就站在旁邊盯著看。
稽核者會檢查每一版索引本是否與前一版包含完全相同的資料，只差在多出的那一筆，以及職員沒有移除或偷偷改動帳本裡先前的任何一頁4。條件都成立時，稽核者就替那一頁帳本與那一版索引本簽名3，表示記錄新增正確。
稽核者對每一頁與每一本索引本只會簽名一次，所以職員若想把第 50 版索引本的不同版本分別展示給 Alice 與 Bob，只有其中一個版本拿得出有效的稽核者簽名。透過檢查與驗證稽核者簽名，Alice 與 Bob 可以確信職員只維護一本帳本與一套對應的索引本，兩人看到的是同一批記錄。
在 Signal 的金鑰透明度實作中，由 Cloudflare 與 Trail of Bits 擔任受信任的第三方稽核者。
監測¶
第三方稽核者確保職員給 Alice 與 Bob 的是同一批資料，卻無法驗證記錄內容本身正確。舉例來說，Mallory 可以試著往帳本加一頁，列上一筆假造的 Alice 地址變更。從稽核者的角度看，只要 Mallory 正確地新增帳本頁面、也發行了新版索引本，就算一次合法的變更。可是 Bob 到帳本查 Alice 地址的時候，會找到那筆假記錄，並且相信它是 Alice 的真實地址。
監測的作用就在補上這一塊，回想客戶跟帳本互動有兩種方式，查別人的地址，以及查自己的地址。監測要求 Alice 與 Bob 定期做這兩件事，各自能偵測到一種不同的竄改。
Alice 監測自己在帳本裡的資料，做法是定期查閱並驗證自己最新的地址記錄。若查到預期外的地址，她應該透過另一條可信管道通知 Bob，說他收到的地址不可信。
Bob 也必須定期查 Alice 最新的地址，確認與先前收到的一致。之所以重要，是因為 Mallory 塞進一筆假的地址變更之後，可能再補一筆把 Alice 的正確地址還原，藉此掩蓋痕跡。
從 Bob 的角度，查到 Alice 換了地址跟一次合法的搬家看起來一模一樣，而合法搬家是常見得多的解釋。即使如此，他仍然應該透過第二條管道向 Alice 確認她真的搬家了。若沒有，先前那個地址就應當成不可信。
Alice 按固定節奏做自我檢查，Bob 依自己的步調查帳本，兩人都無法保證在 Mallory 介入的當下就抓到。但兩種監測加上第三方稽核，構成一套完整的偵測機制：稽核保證 Alice 與 Bob 看到的是同一份資料，監測保證兩人都定期檢查資料的正確性。合起來，Mallory 的竄改終究會被發現。
回到 Signal 本身¶
那麼，以上種種跟 Signal 的金鑰透明度如何對應？
在 Signal 裡，你可以選擇讓別人用電話號碼找到你，也可以建立使用者名稱，讓別人用名稱找到你。決定開放電話號碼或使用者名稱之後，別人就能在 Signal 輸入你的號碼或名稱，發起訊息邀請。Signal 保有一份中央目錄，最終把這些公開識別碼對應到使用者的公開金鑰，就像信箱比喻裡的「姓名」與「地址」。
Signal 使用者註冊、變更電話號碼或使用者名稱、重新建立帳號時，Signal 會把變更記在一棵日誌樹（也就是「帳本」）裡，並用前綴樹（也就是「索引本」）協助在日誌樹中搜尋。Cloudflare 與 Trail of Bits 各自擔任兩種樹的獨立稽核者，兩種樹合起來構成金鑰透明度日誌。
日誌裡所有的使用者資料都經過密碼學處理而無法辨識，公開識別碼會先通過可驗證隨機函數，識別碼對應到的值則由帶金鑰的雜湊函數保護，因此稽核者從來看不到任何明文的使用者資料。
你的 Signal App 會自動、定期檢查日誌裡屬於你自己的公開識別碼，要驗證聯絡人的識別碼則必須從「檢視安全碼」畫面發起。所有向日誌查詢識別碼的請求都不帶身分驗證，因此不會跟特定使用者帳號綁在一起。
本文不深入實作細節，有興趣的讀者可以到我們的開源儲存庫查看。實作依據的是 IETF 金鑰透明度協定的早期草案，並針對 Signal 的使用情境做了調整。
金鑰透明度目前的實際樣貌¶
金鑰透明度顯示，Signal 生態系裡所有裝置對「識別碼與其公開加密金鑰的對應關係」抱持同一份視角。它不驗證掌控某個電話號碼或使用者名稱的人究竟是誰。具體來說，Alice 與 Bob 可以透過金鑰透明度檢查，確保各自持有某個帳號正確的公開金鑰，若 Mallory 已經完全接管 Alice 的帳號，要察覺仍需仰賴額外的驗證，例如在安全碼變動後主動追問。
目前你的 Signal App 會自動驗證日誌裡屬於你自己的電話號碼與使用者名稱資料。要替別人做同樣的驗證，你必須有對方的電話號碼。也就是說，你若是透過使用者名稱在 Signal 上與某人建立聯繫，彼此沒有交換電話號碼，也無從得知對方的號碼，就無法驗證對方。
符合以下任一條件，你手上大概就有 Signal 聯絡人的電話號碼：
- 你當初是用「以電話號碼尋找」的選項，在 Signal 上開啟與對方的對話。
- 你的手機通訊錄裡存有對方的聯絡資訊（而且對方在 Signal 選擇開放以電話號碼被找到）。
- 對方選擇了讓所有人都能看到自己電話號碼的設定（預設是沒有人看得到）。
請記得，只有在對方存在你的手機通訊錄裡，或對方把電話號碼的能見度設成所有人時，Signal 才會在 App 內顯示對方的電話號碼。
另一種情況是你手上的電話號碼過期了，因為 Signal 上的聯絡人換了號碼。換號碼對聯絡人的公開加密金鑰與底層的加密訊息工作階段沒有任何安全影響，卻會讓你無法對該位聯絡人使用自動金鑰驗證，原因是你手機裡留著對方的舊號碼，與帳本中最新的電話號碼記錄對不上。情況類似監測那一節提到的，Bob 查到的 Alice 地址與先前收到的不同。極可能是一次合法的變更，你的裝置卻分辨不出它與伺服器干擾的差別，所以你應該透過另一條可信管道向聯絡人確認。
基於隱私優先的預設，上述情況我們一律讓自動金鑰驗證無法使用，並建議使用者改用既有的安全碼機制，透過掃描 QR code 或比對一長串驗證號碼，手動確認自己與特定聯絡人持有同一組加密金鑰。使用者若傾向不依賴任何第三方，包含 Signal 與稽核者在內，可以依序打開設定的「隱私權」、「進階」、「自動金鑰驗證」關閉功能，繼續使用手動的安全碼驗證。
結語¶
金鑰透明度提供一種容易上手的方式，讓使用者確認訊息安全中重要的一環，補足既有的安全碼機制。
這項工作集合了 Signal 內部與外部的大量協作，我們特別感謝 Cloudflare 與 Trail of Bits 擔任獨立稽核者。感謝他們，也感謝生態系裡許多讓工作得以成真的人。
編輯註解¶
以下為 anoni.net 社群補充，非 Signal 原文內容
原文的比喻寫得完整，技術脈絡與取捨留在文外。以下先給三條結論，接著十三則補充，再一節發布後的後續補充，最後是常見問題與延伸閱讀。
只想知道結論的話¶
以下三條不需要理解背後的機制，轉述給沒有技術背景的人也不會失真：
- 綠色勾號代表號碼對應到的金鑰在整個 Signal 生態系裡一致，代表不了對方是本人。
- 收到「安全碼已變更」的通知就停下來，換一條管道確認過再繼續談敏感的事。
- 每隔一段時間打開設定裡的「已連結裝置」，看清單上有沒有你不認得的項目。
日常使用看完上面三條，再看接下來四則就夠。需要保護消息來源、在組織裡管對外帳號、經常跨境或裝置可能離開視線、加害者可能就在身邊的讀者，往後幾則是為你們寫的。最後三則談金鑰透明度怎麼設計出來，不影響操作。發布之後另外補了一節，談稽核鏈的形狀、勾號會被讀成什麼、匿名查詢的雙向性，以及可驗證性到哪裡為止。
綠色勾號保證什麼，不保證什麼¶
原文在「金鑰透明度目前的實際樣貌」一節已經劃出界線，換個說法再說明一次會更清楚。自動金鑰驗證只確認一件事，同一個識別碼在整個生態系裡對應到同一把金鑰。握著那個電話號碼或使用者名稱的人究竟是誰，功能本身管不到。
常見的幾個問題逐項對照。
| 你想確認的事 | 自動金鑰驗證 | 該看哪裡 |
|---|---|---|
| 伺服器有沒有偷換某個號碼對應的金鑰 | 可以 | 綠色勾號 |
| 對方是不是本人 | 不行 | 安全碼變動通知，另一條管道追問 |
| 有沒有陌生裝置掛在你的帳號上 | 不行 | 設定裡的「已連結裝置」 |
| 群組成員的金鑰有沒有被換過 | 不行 | 對每個人各做一次一對一驗證 |
| 手機本身有沒有被動過手腳 | 不行 | 屬於裝置安全，不在功能範圍 |
| 門號的控制權在誰手上 | 不行 | 註冊鎖 PIN，必要時撥 113 |
帳號被接管的情境下，界線會變得很尖銳。攻擊者若攔截到簡訊驗證碼、完成 SIM 卡調包，或取得對方已解鎖的手機，可以用同一個電話號碼重新註冊 Signal。重新註冊會產生新的身分金鑰，而新金鑰由伺服器循正常流程寫進日誌，算一次合法變更，稽核者不會有意見，日誌前後也一致。此時你對那位聯絡人執行自動驗證，畫面仍會顯示綠色勾號與「已完成加密驗證」，只是驗證通過的對象已經換人。
對方的身分金鑰改變時，Signal 會在對話中以安全碼變動通知標示出來，真正的警訊留在那一條。自動金鑰驗證不取代安全碼變動通知，兩件事回答不同的問題。
只作用在一對一，群組沒有自動驗證的入口¶
原文的操作說明是進入某位聯絡人的個人資料頁，Signal 設定裡的說明寫得更直接：「啟用時，Signal 會嘗試自動驗證 1 對 1 聊天的加密。」群組聊天沒有對應的入口。
限制來自金鑰透明度的設計，日誌記錄一個識別碼對應到哪一把金鑰，而群組不是一個識別碼，它是一群各自持有金鑰的人。要確認一個二十人群組裡每個人的金鑰都沒被換過，等於對二十個人各做一次一對一驗證，每一次都需要你握有對方的電話號碼。
把 Signal 群組當成協作骨幹的社群，務實的做法是分層。核心決策的少數幾人值得逐一驗證，人數多、流動快的執行層改用社會性的確認，由信任的人親自介紹、當面拉進群組。站上的社運行動者的數位準備有更完整的分層設計。
查證來源（2026-08）：values-zh-rTW/strings.xml - Signal-Android，字串 preferences_automatic_key_verification_body。
連結裝置是它看不到的地方¶
Signal 的連結裝置（linked device），也就是桌面版與 iPad 版，與手機共用同一把身分金鑰。攻擊者若誘使你掃過一次惡意的連結 QR code，他的裝置會掛進你的帳號、同步收到後續訊息，而你的身分金鑰完全沒有改變。安全碼不變，日誌裡不會多出任何一頁，金鑰透明度從頭到尾看不到，綠色勾號會一直亮著。
2025 年 2 月 Google Threat Intelligence Group 記錄了實際的攻擊。針對烏克蘭軍方人員、政治人物與記者的攻擊者，把裝置連結用的 QR code 偽裝成 Signal 群組邀請頁面，或烏克蘭軍方使用的應用程式頁面，誘導目標把攻擊者的裝置連上自己的 Signal 帳號。報告的說法是，攻擊成功之後訊息會即時同步給受害者與攻擊者雙方，形成持續竊聽的管道，過程中不需要完整攻陷裝置。
對應的操作是定期打開設定裡的「已連結裝置」，確認清單上每一項你都認得。金鑰透明度不會替你看已連結裝置。至於要不要解除不認得的連結、什麼時候解除，在加害者可能就在身邊的情況下需要先想過後果，後面「對方就在你身邊時」那一則會談到。
查證來源（2026-08）：Provisioning.proto - Signal-Android，ProvisionMessage 帶有 aciIdentityKeyPrivate，連結新裝置時主裝置會交出帳號的身分私鑰。
查證來源（2026-08）：Signals of Trouble: Multiple Russia-Aligned Threat Actors Actively Targeting Signal Messenger - Google Threat Intelligence Group，2025-02-20。
在台灣與周邊的脈絡¶
台灣的手機門號採實名制，號碼與身分證件綁在一起，補辦 SIM 卡並同時取得簡訊驗證碼的攻擊路徑比想像中短。帳號被完整接管時自動金鑰驗證會照常顯示綠色勾號，所以更該優先打開 Signal 的註冊鎖，設一組只有你知道的 PIN 碼，讓別人光有門號無法重新註冊你的帳號。註冊鎖的優先順序排在逐一驗證聯絡人之前。整體的防護順序見站上的一般人平常該做到什麼，自動金鑰驗證算是錦上添花的一層，密碼管理器與兩步驟驗證仍然排在更前面。
在 Signal 被封鎖的地區，第一個問題是功能能不能用。金鑰透明度的查詢跟其他 Signal 功能一樣需要連得上 Signal 的伺服器，連線被擋住或不穩定的時候查詢完成不了，驗證就不會成功。Signal 沒有說明「連不上」與「驗證失敗」在畫面上如何區分，可行的判斷方式是先看整個 App 收發訊息正不正常，正常的話問題比較可能出在驗證本身。查詢不帶身分驗證，日誌看不出是誰在查，走代理或審查規避工具時，通道的營運者仍然看得到你在跟 Signal 通訊，各種通道把可見度換到誰手上，見站上的VPN 的風險與選擇。
原文提到你手上留著聯絡人的舊號碼時，自動金鑰驗證會直接無法使用，反過來，你換了號碼之後，聯絡人的通訊錄裡留著你的舊號碼，他們同樣驗證不了你，影響往兩個方向都成立。跨境移動、常換預付卡或 eSIM 的人，兩個方向都會頻繁遇到，算是常態。退路仍然是安全碼，當面掃 QR code 最快，只能透過語音核對那串數字時，前提是你認得對方的聲音。維持多組門號與多個帳號的人，每個帳號的自我檢查各自獨立，站上的怎麼維持多個網路身分談到相關的取捨。
竄改終究會被發現，但不會當場被擋下¶
原文的監測一節寫得含蓄，金鑰透明度能偵測竄改，沒有即時阻擋的能力。Mallory 在帳本裡塞一筆假記錄的當下，Bob 的查詢仍然會取得假金鑰，訊息仍然會被讀走。真正的保障來自 Alice 下一次自我檢查時會發現對不上，而稽核者的簽名讓 Mallory 無法對 Alice 與 Bob 各說一套。攻擊窗口因此落在「從竄改到下一次監測之間」，代價則是必然留下可稽核的證據。對長期監控來說，會留下證據往往就足以嚇阻。
你打開自動驗證之前送出的內容，期間若發生過金鑰置換，那些內容已經走在錯的通道上，功能不會回頭修補，保護的方向只有往後。發現異常之後只能評估損害範圍，判斷哪些內容可能已經外流，以及對方是否還是本人在操作。
你的 App 自己檢查，驗證聯絡人要手動¶
原文提到你的 Signal App 會自動、定期檢查日誌裡屬於你自己的電話號碼與使用者名稱，驗證聯絡人的識別碼則必須從「檢視安全碼」畫面手動發起。兩件事的節奏差很多。
原文寫「隨著時間累積，你這一次的驗證，加上聯絡人與第三方稽核者持續執行的驗證，共同確保該位聯絡人的金鑰在整個 Signal 生態系中保持一致」，容易被讀成關係要夠久才有保障。拆開來看，稽核者稽核整份日誌，跟你們認識多久無關。你與對方各自的自我檢查綁在自己的帳號上，也跟關係新舊無關。只有「你對某位聯絡人的驗證」是一次性動作，而它按下去當場就生效。
臨時組成的團隊因此不必擔心用不上，第一次見面交換到電話號碼就能驗，比安全碼更適合陌生人快速建立聯繫，因為不需要另約時間。限制在別的地方，那一次驗證只反映按下按鈕那一刻的狀態，不會自動延伸。任務型的使用者若只在組隊當天驗過，等於把確認鎖在風險最低的階段，真正高風險的那幾天沒有覆蓋到。做法是至少驗兩次，組隊時一次，高風險窗口開始前再一次。
日常的使用者可以把節奏改成事件驅動，收到安全碼變動通知、對方換手機或換號碼、對話內容出現反常的時候，回去看一眼。
要驗證別人，需先有對方的電話號碼¶
對匿名網路社群的讀者而言，電話號碼的要求是最需要留意的取捨。Signal 過去幾年一直在降低電話號碼的角色，使用者名稱、預設不公開號碼都朝同一個方向走。自動金鑰驗證目前的設計卻要求你握有對方的電話號碼才能驗證對方，於是最在意隱私、只用使用者名稱交換聯繫方式的那群人，恰好是暫時用不到新功能的一群。
站上的記者保護消息來源與匿名通訊工具比較都建議用使用者名稱交換聯繫方式，讓消息來源不必先交出電話號碼。照站上的建議建立起來的關係，記者手上通常沒有對方的號碼，自動金鑰驗證從一開始就用不上。取捨很明確，來源的身分保護排在前面，驗證的便利性往後排。
功能也製造了一個誘因，讓人為了讓那顆勾號出現，反過來去跟聯絡人要電話號碼，屬於要特別避免的誤用。對方選擇只給使用者名稱，通常正是不想留下號碼，為了驗證去追問，等於把功能的便利性凌駕在對方自己的選擇之上。驗不了就接受驗不了，高風險的個案改走當面或另一條管道核對安全碼。倡議組織面對捐款人與服務對象時尤其要守住，脈絡見站上的倡議組織的匿名捐款管道。
原文的敘事是 Bob 去驗證 Alice，實際的信任鏈常常反過來。公開身分的人，例如記者、組織的對外窗口，被鎖定的機率比多數聯絡人高，而看著綠色勾號決定要不要信任的，是來找你的那一方。你自己的帳號沒有守好，所有信任那顆勾號的人會一起被誤導。註冊鎖與已連結裝置的檢查，優先順序排在逐一驗證每個聯絡人之前。
Signal 遇到限制時直接讓功能不可用，選擇是對的，寧可讓按鈕消失，也不要給出一個看起來成功、實際上沒有意義的綠色勾號。純使用者名稱的聯絡人目前仍請沿用安全碼，掃 QR code 那條路一直都在。只是當面核對本身也有代價，被看到跟某個人有聯繫，對還沒出櫃的伴侶或需要保護的消息來源就是一次額外的曝光。當面核對留給真正需要的時刻，例如收到安全碼變動通知之後，不必變成常態。
帳號背後換了人，金鑰不會變¶
金鑰透明度綁定識別碼與金鑰的對應，不綁定識別碼背後是哪一個人。前面談帳號接管時，落差表現成攻擊，在組織裡則是日常運作的一部分。
對外窗口、客服、專案聯絡人等角色帳號，操作的人會換。交接若做得規矩，沿用同一台裝置，或用註冊鎖的 PIN 重新註冊，金鑰完全不會變動，安全碼也不會變。一年前驗證過那個帳號的人，不會收到任何技術訊號告訴他們操作的人換了。金鑰透明度本來就沒有要回答帳號背後是誰在操作的問題。
角色帳號還有兩件事跟個人帳號不同。第一，「已連結裝置清單上每一項你都認得」那條建議假定只有一個人在管帳號，多人輪值時要改成比對一份內部名冊，靠記憶不可行。第二，組織門號的簡訊驗證碼可能不只一個人收得到，辦公室轉接線、IT 管理的 eSIM、帳單持有人都可能在鏈上，註冊鎖的 PIN 要當成組織的共用機敏憑證管理，存放與輪替的做法見站上的密碼管理器入門。
交接時要做的是換掉 PIN、盤點並清理已連結裝置、記錄目前誰握有管理權。若交接的情況不歡而散，處理順序比照後面「對方就在你身邊時」那一則。
裝置離開你的視線之後¶
出入境查驗、臨檢、裝置被扣留一段時間再歸還，三種情況有一個共同點，對手有過實體接觸的機會。金鑰透明度查伺服器上的紀錄，與你的裝置有沒有被動過是兩件獨立的事，所以自動驗證仍然會顯示綠色勾號。
拿回裝置之後要主動檢查已連結裝置清單，以及重要聯絡人的安全碼有沒有變動。清單乾淨只說明沒有新的裝置掛進你的帳號，不足以推論裝置本身沒被動過手腳，那屬於裝置安全的範圍。
被要求當場解鎖交出，風險又高一層，對手取得你配合之下的完整存取。保守的做法是把裝置視為已暴露，重新評估帳號的 PIN 碼與重要聯絡人的驗證狀態。事前準備與事後處理的清單，站上的出差與研討會的數位準備（東亞與東南亞）與社運行動者的數位準備寫得比較完整。任務型的通訊還要處理收尾，任務用的門號註銷之前提醒還留著號碼的人清掉，借用的裝置歸還之前先手動解除連結，別假設對方會自己發現，選務場景的整體準備見選舉觀察員的自保。
對方就在你身邊時¶
前面幾則假定的攻擊者都在遠端，需要攔截簡訊驗證碼，或誘你掃一張惡意的 QR code。加害者若是同住的人、知道你的解鎖方式，或本來就是門號的登記人與帳單付款人，連前置動作都不必，因為對方看到的是你本人已經解開的畫面，前面所有機制都繞不過去。
門號那一層要分開看，註冊鎖擋得住「用你的號碼重新註冊 Signal」，擋不住對方對門號本身的行政控制權。對方若是合法的門號持有人，走電信商的正常管道就能處理你的號碼，過程中不需要偽造任何身分。設 PIN 碼的時候也要留意，只有在對方不在場、不知情的狀況下設定才有意義，並且不要與手機解鎖碼相同。未成年而使用家庭方案的人還要多想一層，門號、帳單與裝置管理往往在同一個人手上，設好 PIN 擋得住重新註冊，擋不住對方看到你裝了什麼 App，裝置層的痕跡管理見站上的 LGBTQ+ 與性少數的匿名社交。
檢查連結裝置的建議，在同住的情境下要先想過後果。前面說看到不認得的項目就解除連結，那條建議假定對手是陌生人，解除之後不會再出現。加害者是同住者的時候前提不成立，被解除的那台裝置會立刻失去存取權，對方下次打開就會發現，而「你發現了」本身可能升高風險。比較安全的順序是先確認人身安全與手邊可用的支持資源，需要時先保留畫面記錄，再決定要不要解除、什麼時候解除。
原文反覆建議的「透過另一條可信管道確認」也有同樣的前提問題，長期被監控的人不一定有一條對方接觸不到的管道。台灣可以撥 113 保護專線做匿名諮詢，由社工協助判斷風險等級。更完整的準備見站上的家暴受害者的數位準備與緊急求救。
稽核者本身也是一種信任¶
功能引進了兩個新的外部角色，Cloudflare 與 Trail of Bits。兩家都無法讀到明文資料，公開識別碼經過可驗證隨機函數處理，對應值由帶金鑰的雜湊函數保護。稽核者能確認日誌前後一致、沒有被回頭改寫，看不到日誌裡究竟是誰。
多一位獨立稽核者通常讓信任假設變弱，從「必須相信 Signal 沒有作惡」放寬成「至少要有一位稽核者是誠實的」，方向要說清楚。用戶端實際要求三份簽章，Signal 自己營運一份，Cloudflare 與 Trail of Bits 各一份，缺任何一份都會跳警告、讓自動金鑰驗證失敗。每份簽章有七天效期，全惡意的伺服器因此最多維持一週的分岔視圖。原文只寫了 Cloudflare 與 Trail of Bits 兩家，第三份自簽要看 Trail of Bits 自己的說明才知道，後面「後續補充」那一節接著談。
完全不接受第三方假設的使用者，Signal 留了關閉開關，設定路徑在隱私權、進階、自動金鑰驗證。關閉之後回到手動的安全碼驗證。
為什麼識別碼要先過一層可驗證隨機函數¶
原文提到公開識別碼會先通過可驗證隨機函數（Verifiable Random Function），一句話帶過，背後的取捨可以再說明。
日誌必須公開才有辦法被稽核，公開的日誌若直接列出電話號碼，任何人都可以整份取回，做成一份「哪些號碼註冊過 Signal」的名單。換成一般的雜湊函數也擋不住，電話號碼的可能組合數量太少，逐一算過一遍就能還原。
可驗證隨機函數讓伺服器用一把只有自己知道的金鑰，把識別碼映射到日誌裡一個看起來隨機的位置，同時附上一份任何人都能檢查的證明，說明映射確實照規則產生。外人少了那把金鑰就無法自行還原名單，稽核者仍然驗證得了日誌的一致性。
「不帶身分驗證」的意思也要看清楚。原文說所有向日誌查詢識別碼的請求都不帶身分驗證，因此不會跟特定使用者帳號綁在一起。不帶身分驗證只保證查詢不會被綁到你的帳號，不保證伺服器不知道你查了誰。可驗證隨機函數的金鑰在伺服器手上，你要查某個識別碼，就得把它送過去讓伺服器算出對應的位置與證明，被查的識別碼本身伺服器看得到，稽核者讀不到明文則是另一層設計。
金鑰透明度不是 Signal 首創¶
概念上金鑰透明度延伸自憑證透明度（Certificate Transparency），把 HTTPS 憑證的公開日誌與稽核機制搬到即時通訊的公開金鑰上。學術脈絡可以再往前拉，2015 年的 CONIKS 提出讓使用者自行監測目錄的設計，2019 年的 SEEMless 補上隱私與效率，Meta 在 2021 年把相關想法做成開源的 Auditable Key Directory（AKD）程式庫。
通訊軟體的第一個大規模部署來自 WhatsApp，2023 年 4 月上線，底層用的就是 AKD，當時的定位是讓任何人都能自行驗證。Cloudflare 接手擔任第三方稽核者，是一年五個月之後的 2024 年 9 月，兩件事常被壓成同一件。Apple 的 iMessage Contact Key Verification 在 2023 年底推出，走另一條路線，由使用者裝置自己驗證一致性證明。
IETF 的 KeyTrans 架構草案把部署方式分成三種模式，聯絡人監測（contact monitoring）、第三方管理（third-party management）與第三方稽核（third-party auditing），差別在於由誰負責察覺日誌分岔。草案本身只定義模式，沒有點名哪一家系統落在哪一格，常見的對照表出自工作組簡報與各家自己的說明。Signal 這次以第三方稽核為主，同時要求用戶端對自己的識別碼做監測，互補的理由在原文的「監測」一節說得很清楚。
查證來源（2026-08）：CONIKS: Bringing Key Transparency to End Users - USENIX Security 2015。
查證來源（2026-08）：SEEMless: Secure End-to-End Encrypted Messaging with less trust - Chase、Deshpande、Ghosh、Malvai，ACM CCS 2019。
查證來源（2026-08）：Deploying key transparency at WhatsApp - Meta Engineering，2023-04-13。AKD 程式庫見 facebook/akd，儲存庫 2021 年 6 月建立。
查證來源（2026-08）：Cloudflare helps verify the security of end-to-end encrypted messages by auditing key transparency for WhatsApp - Cloudflare，2024-09-24。
查證來源（2026-08）：Advancing iMessage security: iMessage Contact Key Verification - Apple Security Research，2023-10-27。
後續補充（2026-08-13）¶
文章發布當天，Trail of Bits 也貼出自己那一側的說明，裡面有 Signal 原文沒寫的稽核細節。以下四則按幾位不同專業背景的讀者的提問整理，查證日期都在 2026-08。
稽核的獨立性建立在跨組織，不在跨法律管轄¶
用戶端要求的三份簽章，分別由 Signal、Cloudflare 與 Trail of Bits 營運，三家都是美國實體。跨組織的分散做到了，跨法律管轄沒有。一份強制令同時觸及三個簽章者，在美國境內是可以想像的路徑，對身處與美國沒有對等司法互助機制地區的使用者，保證的實際強度目前沒有先例可查。
Trail of Bits 照規格從頭寫了一套稽核器，沒有沿用 Signal 的參考實作，理由是獨立實作才抓得到共病的錯誤，程式碼開源在 trailofbits/signal-auditor。他們也寫明不向 Signal 或任何一方收費，兩項選擇讓第三方稽核不只是掛名。
現行設計把察覺日誌分岔的責任交給少數幾個稽核者，學界對此有意見。2026 年的 MINGLE 提出讓用戶端在通訊時順便交換彼此看到的日誌狀態，論文摘要直接點名現行部署把偵測委託給少數第三方稽核者，形成可被施壓、被攻陷或無法持續稽核的中心化瓶頸。Signal 目前沒有用戶端之間的交叉比對。
綠色勾號會被讀成什麼，空白又會被讀成什麼¶
安全指示器的既有研究顯示，正面圖示長期被讀得比技術定義寬。工程團隊寫的是「識別碼與金鑰在日誌裡一致」，使用者看到的是「這個人安全」。
2007 年一項針對網路銀行的研究把使用者原本設定的個人化安全圖片拿掉，用自己帳號操作的二十五人裡有二十三人仍然輸入了密碼。預期中的正面提示消失，多數人不會提高警覺，多半根本沒注意到。
自動金鑰驗證因為對方只有使用者名稱或號碼過期而不可用時，比較可能發生的是使用者直接略過。空白不會自己變成警訊。
自動化研究反覆觀察到，手邊有低成本管道可以依賴時，需要主動投入的人工檢查會系統性減少。驗證變便宜之後，願意約時間當面掃 QR code 的人只會愈來愈少，而當面核對正好涵蓋自動驗證覆蓋不到的那一塊，帳號被完整接管的情境。
匿名查詢的保護是雙向的¶
查詢日誌的請求不帶身分驗證，設計目的是讓伺服器無法把查詢綁回你的帳號。同一個設計讓查詢你的人也享有一樣的匿名。只要對方原本就知道你的電話號碼，就能反覆查詢你的識別碼在日誌裡的紀錄，觀察你何時換機、換號或重新註冊。過程不必碰你的裝置，你也不會收到任何通知，原文沒有描述任何會告知被查詢者的機制。
前面「對方就在你身邊時」那一則要再加一層：離開一段有控制關係的關係之後，對方手上通常還留著你的號碼。換號碼本身會在日誌裡留下一筆可被觀察的變更，時間點對盯著看的人是有意義的訊號。
可驗證性到你的手機就斷了¶
稽核者簽的是伺服器上那份日誌的結構，簽章不涵蓋你手機裡的 App 有沒有誠實執行驗證、畫面上那顆勾號有沒有如實反映結果。那是另一條信任鏈。要核對手上的 App 與公開原始碼一致，Android 版有可重現建置的流程與自動化檢查，社群也有人持續重現 Play Store 的版本。iOS 版沒有對應的建置說明，限制來自 App Store 的簽署流程。
Cloudflare 在 2024 年為 WhatsApp 的稽核做了一套任何人都能執行的複驗工具，目前收錄的仍是 WhatsApp 那組，沒有 Signal 的對應項目。想自己複驗 Signal 稽核結果的研究者，現階段需要從頭做起。
查證來源（2026-08）：How Trail of Bits helps verify the integrity of your Signal chats - Trail of Bits，2026-08-11。三份簽章、七天效期、稽核器開源與不收費均出自此文。
查證來源（2026-08）：Signal and Ready to MINGLE: In-Band Gossip for Key Transparency Split-View Detection in E2EE Messengers - IACR ePrint 2026/1010。
查證來源（2026-08）：The Emperor's New Security Indicators - Schechter、Dhamija、Ozment、Fischer，IEEE Symposium on Security and Privacy 2007，論文摘要記為 25 人中 23 人。
查證來源（2026-08）：trailofbits/signal-auditor 與 cloudflare/plexi，後者的說明文件目前只列 WhatsApp 的 namespace。
查證來源（2026-08）：Signal-Android 的 reproducible-builds 說明，Signal-iOS 儲存庫無對應目錄。
常見問題¶
自動金鑰驗證要我自己去打開嗎
不用。原文的寫法是不想依賴任何第三方的人「可以在設定中關閉」，也就是預設就是開啟的。開關在隱私權、進階、自動金鑰驗證，是全域設定，不能逐一聯絡人控制。你自己識別碼的檢查由 App 在背景執行，不需要你操作。要驗證某位聯絡人則要自己進去按，位置在對方個人資料頁的「檢視安全碼」畫面。原文沒有提到最低版本需求，看不到按鈕時先更新 App 再看一次。
打開自動金鑰驗證之後，還需要核對安全碼嗎
看對象。日常聯絡人可以只靠自動驗證。面對高風險的對象，例如消息來源、律師、跨組織的敏感協作，當面掃 QR code 仍然是最強的一層，因為它不依賴 Signal 的伺服器，也不依賴任何稽核者。兩種做法可以並存，自動驗證負責日常的持續比對，手動核對負責一次性的高強度確認。
顯示綠色勾號，代表對方一定是本人嗎
不代表。綠色勾號說明你手上的識別碼對應到的金鑰，跟整個 Signal 生態系看到的一致。對方的帳號若已經被完整接管，攻擊者用同一個號碼重新註冊產生的新金鑰，同樣會通過驗證。判斷對方是不是本人，仍要靠安全碼變動通知、對話內容的異常，以及另一條可信管道的追問。
群組聊天裡的成員，可以用自動金鑰驗證嗎
不行。Signal 設定裡的說明寫著「自動驗證 1 對 1 聊天的加密」，群組沒有對應的入口。要確認群組成員的金鑰，只能對每個人各自執行一次一對一驗證，而且同樣需要你握有對方的電話號碼。人數多的群組不容易逐一做完，實務上建議只在核心的少數幾人身上落實。
自動驗證的按鈕沒有出現，是我操作錯誤嗎
多半不是操作問題。最常見的原因是你手上沒有對方的電話號碼，例如你們是透過使用者名稱建立聯繫的。另一種是你存的號碼過期了，對方已經換號。Signal 在兩種情況下一律讓功能不可用，改請你使用安全碼。
我驗證了某位聯絡人，對方會知道嗎
原文說所有向日誌查詢識別碼的請求都不帶身分驗證，不會跟特定使用者帳號綁在一起。保證的範圍到這裡為止，查詢不會被綁到你的帳號，連線來源與時序仍然握在伺服器手上，推不出伺服器完全無從關聯。原文也沒有描述任何會通知對方的機制，同樣沒有正面交代，處境對此特別敏感的人，保守假設比較安全。
我換了新號碼，為什麼舊聯絡人驗證不了我
因為對方的通訊錄裡留著你的舊號碼，與日誌中最新的號碼記錄對不上。限制是雙向的，你驗證不了持舊號碼的人，持你舊號碼的人也驗證不了你。做法是透過另一條可信管道告知新號碼，等對方更新通訊錄，或直接約時間掃 QR code 核對安全碼。
我們是臨時成軍的團隊，來得及用上嗎
來得及。原文那句「隨著時間累積」容易被讀成關係要夠久才有保障，但稽核者稽核整份日誌，你與對方的自我檢查各自綁在自己的帳號上，都跟你們認識多久無關。第一次見面交換到電話號碼就能驗，比安全碼更適合陌生人快速建立聯繫，因為不必另約時間。單次驗證只是當下的快照，高風險窗口開始前記得再驗一次。
時間有限，我該先驗證誰
用影響範圍排序。問自己「對方的帳號若被接管，錯誤資訊會擴散多遠、敏感內容會外流多少」。指揮與協調窗口優先於一般成員，會轉發現場回報的節點優先於只接收的人，跨組織的單一聯繫窗口優先於同組織內已有其他確認管道的人。排在所有人之前的仍然是你自己的帳號，理由見「要驗證別人，需先有對方的電話號碼」那一則。
手機被查扣過再拿回來，看得出發生了什麼事嗎
看不出來。只要沒有人用你的號碼重新註冊，身分金鑰沒換，畫面就會照常顯示綠色勾號。拿回裝置之後要主動檢查已連結裝置清單與重要聯絡人的安全碼變動。清單乾淨也只代表沒有新裝置掛進帳號，不代表裝置本身沒被動過手腳。
門號是對方申請的、帳單也是對方在繳，我還受保護嗎
功能保護不到那一層。自動金鑰驗證確認金鑰有沒有被換掉，管不到門號的行政控制權在誰手上。對方若是合法的門號持有人，走電信商的正常管道就能處理你的號碼。門號的歸屬要另外處理，必要時先聯繫 113 保護專線評估風險，站上的家暴受害者的數位準備有進一步的準備方向。
驗證聯絡人的時候，Signal 自己會不會知道我在查誰
原文說查詢不帶身分驗證，不會跟特定使用者帳號綁在一起，只保證查詢不會被綁到你的帳號。伺服器持有可驗證隨機函數的金鑰，你要查某個識別碼就得把它送過去，被查的識別碼本身伺服器看得到，稽核者讀不到明文則是另一層設計。
關掉自動金鑰驗證會有什麼影響
你會回到原本的手動安全碼流程，訊息加密本身不受影響。關閉的理由通常是不想把任何信任放在 Signal 以外的第三方稽核者身上。設定路徑在隱私權、進階、自動金鑰驗證。
Signal 的伺服器被入侵，我會收到通知嗎
不會有一則寫著「伺服器被入侵」的通知。你會看到安全碼變動的提示，或是自動驗證失敗。金鑰透明度的設計目標是讓竄改留下無法抹除的證據，做不到即時警報。發現的時間點落在你或對方下一次檢查的時候。
跟 WhatsApp、iMessage 的同類功能差在哪
三家處理同一個問題，選擇的信任結構不同。WhatsApp 走第三方稽核，由 Cloudflare 在外部盯著日誌。Apple 的 iMessage Contact Key Verification 讓使用者的裝置之間自行驗證一致性。Signal 兼採兩種做法，外部稽核加上用戶端對自己識別碼的定期監測。使用門檻上，Signal 只有在你握有對方電話號碼時才驗證得了對方，純使用者名稱的聯絡人暫時用不到，WhatsApp 的帳號本身就是電話號碼，不會遇到同樣的狀況。
我該多久檢查一次
沒有標準答案，可以用事件驅動取代固定週期。收到安全碼變動通知、對方換手機或換號碼、你自己重新安裝 Signal，以及任何一次感覺不對勁的對話，都是回去看一眼的時機。你自己的識別碼由 App 定期檢查，不需要你介入。
延伸閱讀¶
站內：
- 一般人平常該做到什麼，沒有特殊威脅模型的話，先把那裡的順序做完再回頭看自動金鑰驗證。
- 端對端加密如何運作，Double Ratchet、前向保密與多裝置同步的工程取捨。
- 匿名通訊工具比較，Signal 與其他工具在身分模型與 Metadata 上的差別。
- 威脅模型如何建立，判斷自己需要哪一層驗證的起點。
- 匿名、隱私、假名、機密性的差別，自動金鑰驗證保證識別碼與金鑰一致，跟保證匿名是不同的事。
- Metadata 是什麼，為什麼重要，識別碼為什麼本身就是一條線索。
站外：
- Signal 的金鑰透明度伺服器原始碼，Signal 的實作依據 IETF 草案並做了調整。
- Cloudflare 談與 Signal 合作稽核金鑰透明度，兩位稽核者之一對這次合作的說明。
- Trail of Bits 談如何驗證 Signal 對話的完整性，另一位稽核者的技術說明。
- IETF KeyTrans 協定草案與架構草案，標準化工作仍在進行。
- CONIKS: Bringing Key Transparency to End Users，2015 年提出讓使用者自行監測目錄的設計。
- SEEMless: Secure End-to-End Encrypted Messaging with less trust，後續在隱私與效率上的改進。
- Deploying key transparency at WhatsApp，通訊軟體第一個大規模部署的工程說明。
- Cloudflare 說明如何稽核 WhatsApp 的金鑰透明度，從稽核方的角度描述同一套機制。
- Advancing iMessage security: iMessage Contact Key Verification，Apple 採用的另一種部署模式。