解鎖本機保管箱，不等於登入雲端

大多數軟體已經把我們訓練成：只要是取得存取權的動作，都叫做「登入」。輸入密碼、按下按鈕，某個東西就會開啟。這個詞很方便，卻掩蓋了本機優先加密保管箱的一項重要差異。

在裝置上開啟保管箱，與向可選的雲端服務驗證身份，並不是同一件事。

第一個動作要回答的是：這台裝置能否將本機密文轉換成可用資料？

第二個動作要回答的是：這個保管箱能否向遠端服務證明，它就是服務原先認識的那個保管箱？

兩個問題牽涉不同的機密、不同的系統，也有不同的失敗模式。把它們視為同一事件，或許能簡化架構圖或登入畫面，卻也會鼓勵伺服器介入解鎖流程。對 NT² Vault 而言，那會在界線最該清楚的地方削弱整體架構。

一個詞背後隱藏的限制

在傳統雲端應用中，「登入」通常代表向伺服器帳號驗證身份。伺服器查找使用者紀錄、驗證密碼或委由身份供應商處理，然後建立工作階段。接著便能存取資料，因為資料原本就由伺服器控制。

本機優先的加密保管箱將這層關係倒轉過來。可實際使用的保管箱副本位於你的裝置上，敏感內容靜態儲存時是密文。裝置需要加密金鑰才能讀取內容，而這把金鑰應由主密碼在本機派生。伺服器不需要核准這項操作，因為開啟保管箱的不是伺服器。

如果把本機解鎖與雲端驗證合併成一個籠統的登入動作，幾項熟悉的假設便會悄悄回來：

• 必須有 email 地址才能找到帳號；
• 伺服器必須知道足以判斷密碼正確與否的資訊；
• 本機資料開啟前，必須先等待網路回應；
• 使用者會期待帳號復原同時恢復加密內容的存取權；
• 有效的雲端工作階段，會被誤認為持有解密金鑰。

這些假設對雲端優先軟體都很正常。然而放在一起，卻重新引入了零知識保管箱原本要移除的信任。

其中最危險的捷徑，是由伺服器持有「解鎖判定依據」：任何能協助判斷猜測的主密碼是否正確的儲存值或遠端端點。即使這個值不是密碼本身，資料外洩後仍可能成為攻擊者離線猜測的目標，也可能讓服務變成本機解鎖不可或缺的參與者。

因此，NT² 把驗證與派生本機存取權所需的材料留在裝置上。你的主密碼不是雲端憑證，不會傳送到伺服器；伺服器也不會保存保管箱在本機使用的鹽值或密碼驗證資料。網路中斷不該阻止你開啟已經位於裝置上的資料。

Email 也帶來類似問題。它適合用於收據或支援聯繫，卻不適合作為加密保管箱的根身份。Email 帳號可能被重新分配、遭到入侵、輸入錯誤，或由另一家供應商控制。如果「誰擁有這個 email 收件匣」等同於「誰擁有這個保管箱」，email 復原流程就可能悄悄變成保管箱復原流程。這項權力遠超過一個帳單地址應該擁有的範圍。

設計一：解鎖就在本機發生

本機解鎖從你在裝置上輸入的主密碼開始。NT² 使用 PBKDF2 搭配 SHA-256 與 100,000 次迭代，派生出 AES-256-GCM 保管箱金鑰。PBKDF2 刻意讓每一次密碼猜測都比快速雜湊耗費更多運算成本。

這項流程使用的鹽值對每個保管箱都是唯一的，並儲存在本機保管箱的中繼資料中。鹽值本身不需要保密；它的作用，是確保同一組密碼用於兩個保管箱時，不會產生相同的派生金鑰。對信任界線而言，重要的是派生發生在哪裡，以及輸入資料去了哪裡：瀏覽器或應用程式執行所有運算，主密碼不需要離開裝置。

保管箱也會保存本機密碼驗證資料。概念上，這是一段由派生金鑰保護的已知資料。密碼錯誤時，裝置會派生出錯誤的金鑰，因而無法成功開啟驗證資料；成功時，同一把金鑰就能用來解開保護保管箱項目的其他金鑰。

這項檢查始終留在本機。沒有任何請求會詢問伺服器：「這組主密碼正確嗎？」檢查結果也不是雲端工作階段，而是目前裝置上、記憶體中的一項加密能力。

這也說明了為何金鑰是暫時存在的。派生金鑰會建立為瀏覽器中不可抽取的 CryptoKey，並只在保管箱解鎖期間保留於記憶體。鎖定保管箱、重新整理或關閉頁面，或到達閒置逾時後，這把可用金鑰就會被清除。加密檔案可能仍留在磁碟上，但解讀它們的能力已經消失。

因此，本機解鎖不需要網路連線，也不需要雲端訂閱。它沒有向任何 NT² 伺服器證明什麼，只是讓正在執行的應用程式取得解密這個本機保管箱的能力。

設計二：由保管箱證明自己

可選的雲端功能需要另一種證明。同步服務必須阻止陌生人讀寫其他保管箱的加密副本，但若要求主密碼，就會跨越剛才建立的界線。

因此，保管箱以一把簽署金鑰建立加密身份。我們將它的公開識別碼稱為「保管箱金鑰 DID」。名稱聽起來或許比實際操作複雜；把它想成一段簡單的挑戰—回應交換即可。

當保管箱要驗證身份時，伺服器會傳送一個全新、不可預測的挑戰，意思近似於：「請簽署這則一次性訊息，讓我知道你現在確實在場。」裝置使用保管箱的私密簽署金鑰簽署挑戰，伺服器再以已經與該保管箱關聯的對應公開金鑰驗證簽章。

私密簽署金鑰不需要上傳。有效簽章能證明裝置此刻控制著那把金鑰，而全新的挑戰則防止攻擊者日後重播先前截取的回應。

整段交換流程如下：

1. 保管箱要求開始雲端身份驗證。
2. 伺服器回傳一個短效、隨機的挑戰。
3. 裝置在本機簽署挑戰。
4. 伺服器依照保管箱的公開身份驗證簽章。
5. 伺服器核發權限受限的雲端工作階段，用於已獲授權的傳輸操作。

理解這條界線不需要先上一堂身份技術理論課。這就像你用特定印章在一張全新、限用一次的卡片上蓋印，藉此證明自己持有那枚印章。驗證者可以認出印記，卻不需要取得製造印記的工具。

這個雲端工作階段可以授權上傳或取回加密副本資料等操作，卻不會揭露主密碼、不會派生保管箱金鑰，也不會解密內容。雲端辨識的是一個由密碼學建立的保管箱身份，而不是 email 收件匣，也不是方便人類閱讀的顯示名稱。

本機顯示名稱是給裝置使用者看的；可選的帳單 email 則用來收取收據。兩者都不是雲端權限的根。讓保管箱向服務證明其延續性的，是簽署金鑰。

取捨：兩套心智模型

這種分離並非毫無代價。使用者與開發者現在需要理解兩種狀態：

• 本機已鎖定或已解鎖，描述能否存取保管箱的解密內容；
• 雲端已登出或已驗證，描述能否使用可選的遠端服務。

兩種狀態可以獨立變化。保管箱可能在裝置離線時仍保持解鎖，也可能在雲端驗證過期後繼續保持解鎖。背景同步程序可能有權移動密文，卻無法讓使用者介面顯示明文。雲端帳號發生問題時，同步可能中斷，但本機搜尋與編輯仍可繼續。

只顯示一個「已登入」標記會更簡單，卻不準確。好的介面設計應該說明兩種狀態，而不強迫使用者學習密碼學詞彙。「保管箱已鎖定」與「雲端同步需要處理」，都比一個模糊的身份驗證錯誤更清楚。

實作上也有更多邊界情況需要處理。系統必須分開管理本機金鑰與雲端工作階段的生命週期，避免意外把主密碼送進帳號表單，並確保重新連線同步不會被誤解為解鎖。測試也必須涵蓋多種狀態組合，而不是只驗證一條順利流程。

我們接受這些複雜度，因為它讓威脅界線變得可見。伺服器遭入侵時，遠端可用性、帳號中繼資料與加密副本可能受到威脅，但不該因此自動產生能開啟本機保管箱的金鑰。有人拿到已解鎖的裝置，是一場本機安全事件，但不該讓伺服器因此得知主密碼。Email 遭接管可能影響訊息或帳務，卻不該重新定義保管箱的擁有權。

清楚的界線無法消除所有風險，卻能避免不相關的權力集中到同一組憑證與同一套後端。

我們拒絕畫上等號的兩件事

兩句話引導著這套設計。

雲端工作階段不等於已解密的保管箱。

伺服器可以接受簽章，並授權存取加密資料。這只代表請求方控制著保管箱的簽署身份，不代表對方已在這台裝置輸入主密碼、派生本機 AES 金鑰，或開啟任何項目。身份驗證可以授予傳輸權限，而不授予明文存取權。

Email 不等於保管箱身份。

Email 地址在產品邊緣仍可能有用途，卻不會成為保管箱的加密根身份。我們不希望收件匣重設流程、客服覆寫，或身份供應商的決定，取代原本定義保管箱控制權的金鑰。

這些拒絕讓部分傳統便利性不再可行。NT² 無法承諾使用者忘記主密碼後，客服仍能恢復所有機密；也不該假裝登入網站就能讀取本機密文。代價是一套要求使用者妥善保存備份與核准復原方式的復原模型。

具體的好處則是：雲端可以提供協助，卻不必成為替你開鎖的人。

讓界線保持誠實

本機優先架構不只是儲存 API 的選擇，更是對權限歸屬的決定。裝置能開啟保管箱，是因為裝置派生了金鑰；雲端能提供可選功能，是因為保管箱以簽章證明了身份。兩項操作都不需要假扮成另一項。

這確實帶來兩套心智模型，但也提供兩個清楚答案。誰能讀取本機資料？能在裝置上解鎖的人。誰能為這個保管箱使用可選的雲端服務？能以其簽署金鑰回答全新挑戰的一方。

只要兩個答案保持分離，「登入」就不再是連接主密碼與伺服器帳號的隱藏通道，而是兩項範圍明確的動作，各自只揭露完成任務所需的資訊。

如果想從更完整的角度理解 NT² 為何將裝置置於中心，可以繼續閱讀為什麼 PWA 能成為本機優先、零伺服器的保管箱。