挑戰－回應，而非以 email 作為持有憑證

主張：保管箱以簽章證明自己

當 NT² Vault 使用可選的雲端功能時，邊緣必須回答一個單純的授權問題：這個請求者是否控制已為此保管箱註冊的加密身份？

答案不是「這個人是否仍控制某個 email 收件匣？」也不是「這個瀏覽器是否仍持有某個曾代表登入的長效持有憑證？」而是圍繞保管箱金鑰 DID——綁定保管箱簽署金鑰的公開識別符——進行的挑戰－回應交換。

裝置簽署伺服器發出的短效挑戰。伺服器以已與該保管箱關聯的公開材料驗證簽章。有效簽章會授權有限的雲端工作階段，用於傳輸工作：註冊帳號、搬運加密複本、附加不透明 blob，以及類似的盲操作。它不會開啟保管箱，不會揭露主密碼，也不會讓密文變得可讀。

這個主張比「登入雲端」更窄，而且是刻意為之。本機解鎖與雲端驗證是不同事件，使用不同機密。本文談的是第二件事：保管箱如何在不把 email 變成所有權的前提下，向服務證明延續性。

限制：Email 與持有憑證會累積錯誤的權力

多數消費端帳號從 email 地址開始。地址用來定位紀錄；密碼或魔術連結證明收件匣控制權。密碼重設、支援升級與裝置切換，都圍繞同一個信箱運轉。這種模型之所以熟悉，是因為提供者本來就儲存權威資料。誰能收回收件匣，通常就能收回帳號；收回帳號，也就恢復資料存取。

加密、本機優先的保管箱把依賴關係倒過來。真正可用的副本在使用者的裝置上；敏感內容靜態儲存時是密文。開啟它們需要本機加密材料。可選的雲端是盲中繼與權益層，不是密文變得可讀的地方。若 email 仍是雲端身份的根，幾種危險的等價關係就會出現：

• 收件匣遭到接管，等於保管箱帳號遭到接管。 郵件供應商遭入侵、地址被回收、釣魚重設成功，或支援覆寫，都可能在從未觸及保管箱簽署金鑰的情況下，重新指派「這個帳號是誰」。
• 「忘記密碼」的語言滲進保管箱復原。 人們期待提供者能恢復存取。對伺服器擁有的資料，這個期待常常成立。對零知識保管箱而言，那會要求提供者持有或重建它本不該擁有的解鎖權力。
• 長效持有工作階段變成「在場」證明的替代品。 能在鎖定、重新整理與關閉分頁後仍存活的權杖，開始看起來像所有權，而不只是短效的傳輸授權。被竊的工作階段材料便能在沒有新鮮加密證明的情況下獲得雲端權利。
• 顯示名稱與帳單聯絡被誤認為權威。 裝置選擇器上的標籤與收據地址都很有用。兩者都不該授權同步、註冊或共用中繼操作。

Email 在邊緣仍有用。NT² 可為商家收據儲存可選的帳單 email。該欄位是通訊地址，不是加密根。若把它當成身份，就會悄悄恢復產品原本要避開的帳號模型。

以 email 作為持有憑證的系統，也會模糊解鎖界線。若雲端「登入」與開啟保管箱是同一個心智事件，產品流程就開始問伺服器主密碼是否正確，或把雲端工作階段當成可以顯示本機密文的證明。兩種做法都把提供者拉進解鎖路徑。我們把這些路徑分開，理由與把可驗證密碼的材料留在帳號資料庫之外相同：有幫助的集中化，在錯誤問題變得可回答時，就會變成判定依據。

因此這項限制既是正面也是負面的。雲端驗證必須證明此刻控制保管箱的簽署身份。它不得在收件匣、支援櫃台，或比解鎖工作階段活得更久的持久 cookie 中，再發明第二個所有權根。

設計：挑戰、簽署、驗證，然後是短工作階段

保管箱金鑰 DID 是保管箱簽署金鑰對的公開面貌。用 分散式識別符（DID） 的語言來說，它是一種可解析到驗證材料、持有者能證明控制權的識別符。NT² 把這個模式用於保管箱形狀的雲端身份，而不是通用身份錢包。私有簽署金鑰留在用戶端。本機解鎖後，裝置可在解鎖工作階段期間將其解開至記憶體。伺服器永遠不會收到它。

因此雲端註冊與受保護的 API 遵循一個小協定：

1. 用戶端向邊緣請求綁定其保管箱金鑰 DID 的挑戰。
2. 邊緣回傳新鮮、短效的 nonce。
3. 裝置以保管箱的私有簽署金鑰在本機簽署該 nonce，使用平台的 Web Cryptography API。
4. 邊緣以已註冊的公開金鑰驗證簽章。
5. 成功後，邊緣核發不透明的工作階段權杖，用於已授權的雲端呼叫。
6. 後續請求攜帶工作階段權杖與保管箱金鑰 DID 標頭，讓服務知道工作階段屬於哪個身份。

sequenceDiagram
  participant Device as 已解鎖裝置
  participant Edge as NT² 邊緣
  Device->>Edge: 為保管箱金鑰 DID 請求挑戰
  Edge-->>Device: 新鮮短效 nonce
  Device->>Device: 以私有簽署金鑰簽署 nonce
  Device->>Edge: 回傳 DID + 簽章
  Edge->>Edge: 以已註冊公開金鑰驗證
  Edge-->>Device: 有限的雲端工作階段權杖
  Device->>Edge: 已驗證的傳輸呼叫（僅密文）

挑戰的新鮮度很重要。舊的、被截獲的回應不得授權新工作階段。綁定到特定保管箱金鑰 DID 很重要。為一個保管箱產生的簽章不得授權另一個。工作階段的有限生命週期也很重要。雲端權利應會過期；保管箱鎖定、切換、刪除或離開頁面時應清除權杖，以免已鎖定的瀏覽器仍保留可用的雲端憑證。

註冊是身份綁定，不是託管。邊緣儲存保管箱金鑰 DID，以及檢查未來簽章所需的公開驗證材料。它可以記錄帳號是否停用，以及 Premium 權益是否允許同步。它不會收到主密碼、本機 KDF 鹽值、密碼驗證資料，或已解開的私有金鑰。那些材料屬於本機保管箱副本旁邊。

由此產生的工作階段能做的事也有界線。它可以授權搬運不透明的複本批次與附件密文。它可以讓服務在已透過使用者控制的交接分享解鎖材料的裝置之間，辨識同一個保管箱。它不能解密項目、派生保管箱 AES 金鑰，或回答猜測的主密碼是否正確。驗證授予傳輸權利；解鎖授予明文。混淆兩者，就是零知識行銷塌成普通帳號軟體的方式。

本機顯示名稱永遠不會成為雲端主鍵。人們需要裝置上的人類可讀標籤；邊緣需要穩定的加密識別符。分開這些關注點，能讓選擇器 UI 可讀，又不會把可復原的人類識別符教給伺服器當權威根。

取捨：兩種證明，較少熟悉的復原路徑

挑戰－回應身份是誠實的，而誠實有代價。

使用者與營運者必須推理兩種證明。本機解鎖回答這台裝置能否派生或重建保管箱金鑰。雲端驗證回答這個已解鎖的保管箱能否以已註冊身份簽署。這些狀態可以獨立變化。保管箱可以在離線且沒有雲端工作階段時解鎖。雲端工作階段可以在保管箱仍解鎖時過期。同步可能因工作階段需要更新而失敗，即使本機搜尋仍可用。產品必須說明「雲端需要處理」而不暗示保管箱已鎖定，也必須說明「保管箱已鎖定」而不暗示邊緣上的加密複本已消失。

熟悉的復原故事在設計上不可用。NT² 不能寄出魔術連結，把保管箱所有權改指派給控制某個收件匣的人。支援不能檢查帳單紀錄，再鑄造一把仍能開啟舊密文的新簽署身份。更改 email 必須只是收據路由變更，而不是身份遷移。延續性依賴使用者持有的路徑：可攜備份、已核准的復原因子，以及明確的裝置交接。對擁有機密的人來說，這是更多工作；卻也是唯一不會暗中任命提供者為鎖匠的復原模型。

實作者繼承邊角案例。工作階段清除必須與鎖定與卸載同步，以免重新整理留下可用權杖。挑戰重用必須被拒絕。若日後引入公開金鑰輪替，也不得與密碼重設混淆。測試必須涵蓋鎖定／解鎖與已驗證／已過期的組合，而不是單一快樂路徑的「已登入」旗標。

我們接受這份複雜度，因為它避免權力累積在同一個憑證裡。郵件遭入侵應威脅訊息，也許還有帳單通訊——而不是重新定義誰可以推送或拉取這個保管箱的密文。被竊的雲端工作階段應是有時間界線的傳輸濫用——而不是有人知道主密碼的證明。伺服器外洩應暴露公開識別符與加密 blob——而不是密碼測試套件，或以收件匣為根基的所有權覆寫。

我們拒絕什麼

我們拒絕把 email 當成保管箱身份。 可選的帳單 email 可以收到收據。它不定位加密帳號、不授權同步，也不重設保管箱控制權。

我們拒絕以 email 持有憑證式的「登入」取代金鑰控制證明。 擁有收件匣不等於擁有簽署金鑰。魔術連結與收件匣重設，是加密保管箱雲端表面錯誤的權威來源。

我們拒絕把雲端工作階段當成已解密的保管箱。 經驗證的簽章授權盲傳輸。它不表示這台裝置已輸入主密碼，也不表示任何項目可讀。

我們拒絕比鎖定活得更久的長效雲端憑證。 保管箱鎖定或頁面離開時，工作階段權杖必須一併消失。解鎖後的雲端呼叫必須能要求新鮮的挑戰－回應，而不是默默重用昨天的證明。

我們拒絕為了「讓驗證更容易」而上傳私有簽署金鑰或主密碼材料。 邊緣驗證公開簽章。它不會成為證明手段的保管人。

我們拒絕重新引入以收件匣為根的所有權的支援工具。 只因有人證明 email 控制權就改指派保管箱的私有管理流程，仍是身份覆寫。限制誰能按按鈕，弱於根本不創造這個按鈕。

這些拒絕關閉了一些傳統產品承諾。它們讓雲端保持有用，卻不讓雲端任命自己為保管箱的擁有者。

結語：證明印章，把收件匣留在邊緣

圍繞保管箱金鑰 DID 的挑戰－回應是小協定、大界線。保管箱在一次性卡片上蓋章。邊緣辨認印章。若有收件匣，它留在收據該在的地方。

這個設計與 NT² 其餘信任故事並列。本機解鎖不是雲端登入——見解鎖本機保管箱，不等於登入雲端。盲同步搬運密文而不讀取——見在邊緣進行盲目 replica 同步。帳號資料庫不得變成密碼神諭——見帳號資料庫不能成為密碼神諭。更廣的身份模型見多控保管箱與保管箱金鑰 DID：不用交出鑰匙的身份管理，拒絕背後的命名承諾見Null Trust² — 名稱代表什麼。

若你想要可選的雲端功能以簽章而非收件匣辨認保管箱，請探索 NT² Vault。