1Passwordが渡していない2つのもの ― マスターパスワードと、チーム共有鍵

1PASSWORD の内側 渡していない 2つのもの マスターパスワードと、チーム共有鍵 ken imoto エンジニア / Propel-lab 1Password Zero-Knowledge kenimoto.dev

| なぜスムーズなのに、強い？ スムーズすぎるサービスは、たいてい怪しい。1Password は例外 です。 新端末で マスターパスワード + QR だけで金庫が復元される。 それでも LastPass のような大規模被害 を起こしていない。 サーバがマスターパスワードで金庫を復号しているだけなら、侵害された瞬間に全ユー ザーが総当たりの標的になるはず。 この違和感が、公式セキュリティホワイトペーパーの入口でした。 1Password Zero-Knowledge 02 kenimoto.dev

| 対照 — LastPass 2022 で起きたこと 「金庫の鍵」ではなく「金庫そのもの」が盗まれると、話は変わ る。 2022-08 侵害を公表 2022-08~09 暗号化された金庫データがバ ックアップから持ち出される 2022-11~12 顧客への続報公表 金庫の暗号化には PBKDF2 が使われ、鍵そのものは盗まれていません。 ただし攻撃者はオフラインで任意のマスターパスワードを試し放題になります。 短い MP を付けていた金庫は、そこで破られる。砦が MP のエントロピーだけになる構造 です。 1Password Zero-Knowledge 03 kenimoto.dev

| 秘密1 — Secret Key で +128 bit 混ぜる サーバが「そもそも知り得ない秘密」を鍵導出に混ぜる。これが 2SKD。 1つ目 マスター パスワード ~60 bit 人間が覚えて運用できる現実的な範囲 + 2つ目 Secret Key 128 bit 初回サインアップ時にクライアントで生成、サーバ に一度も送られない 実質エントロピー 200+ bit 攻撃者は Secret Key を知らないので、探索空間が現実的な計算 資源では踏破できない広さになります。 金庫データを盗んでも、オフライン総当たりが成立しない。 1Password Zero-Knowledge 04 kenimoto.dev

| AUK 派生 — PBKDF2 と HKDF の2レー ン Account Unlock Key は、独立した2つのレーンから作られる。仕様 は §3 / §8。 レーン A マスターパスワード PBKDF2-HMAC-SHA256 × 100,000 salt = メールアドレス + レーン B Secret Key (128 bit) HKDF-HMAC-SHA256 salt = account ID ▼ XOR で合成 ▼ RESULT AUK (Account Unlock Key) サーバは Secret Key を知らない =盗んだデータから AUK は作れない 1Password Zero-Knowledge 05 kenimoto.dev

| 認証 — SRP-6a、見せずに証明する サーバに渡すのは verifier だけ。マスターパスワードそのものは決 してネットワークに乗らない。 クライアン ト MP + Secret Key を持 つ 初回: verifier を計算して送信 --- 保存 --- 認証時: MP を送らずに証明を交換 <--- チャレンジ ---> 同じセッション鍵に到達 → ログイン成立 サーバ verifier だけを持つ サーバは「あなたが正しい MP を知っている」ことを確認するだけ。金庫の中身も鍵も、サー バは知らない。それでもログインは通ります。 1Password Zero-Knowledge 06 kenimoto.dev

| 前半のまとめ — 個人の金庫 2つの秘密は「あなたのデバイスから出ない」。認証は「見せずに 証明する」。 個人の金庫は、本人しか開けない。 2SKD MP と Secret Key、2つの独立した秘密から AUK を 導出。 Secret Key はサーバに一度も送らない。 SRP-6a 認証はチャレンジ・レスポンス。MP そのものはネ ットワークに乗らない。 サーバは verifier だけを保管する。 1Password Zero-Knowledge 07 kenimoto.dev

| じゃあ、チーム共有は？ 「相手のパスワードや鍵の平文はやり取りしない」原則は、共有で も崩れない。 同じ Vault を開けているのに、 誰も相手のパスワードを知らない。 素朴な仮説 Vault の鍵をメンバー全員に配って、みんな同じ 鍵で金庫を開ける。 でもそれだとどこかで平文の鍵が誰の手を渡 る。 1PASSWORD の答え 前半とは別の暗号を使い分ける。 認証層は対称鍵、共有層は非対称鍵 (RSA)。 1Password Zero-Knowledge 08 kenimoto.dev

| 答え1 — 各ユーザーは RSA キーペアを持 つ サインアップ時、クライアントが自分専用の鍵ペアを1組生成す る。 公開鍵 サーバ・他のユーザーに公開 他のメンバーが「あなた宛」の暗号文を作るときに使う。 誰でも取得できる。 秘密鍵 サーバに置くが暗号化されている サーバは復号できない。 あなたが SRP でログインし、AUK を作れたときだけ復号で きる。 秘密鍵を復号できるのは → AUK を作れる人 → MP + Secret Key を持つ人 → あなただけ 1Password Zero-Knowledge 09 kenimoto.dev

| 答え2 — Vault Key の鍵束モデル アイテム本体は Vault Key (対称鍵) で暗号化。鍵束は「N人分ぶん コピー」で作る。 Vault Key (AES) アイテム本体を暗号化する対称鍵。1つだけ。 これを鍵束に入れてメンバーへ配る。 桜井さん向け enc(VK, pub_桜井) 桜井さんの秘密鍵でしか開かない 相葉さん向け enc(VK, pub_相葉) 相葉さんの秘密鍵でしか開かない 松本さん向け enc(VK, pub_松本) 松本さんの秘密鍵でしか開かない サーバは鍵束を保管するだけ。各エントリは公開鍵暗号で守られていて、対応する秘密鍵を持つ本人しか 復号できない。 1Password Zero-Knowledge 10 kenimoto.dev

| 招待シーケンス — 桜井 → 相葉 桜井は「自分の秘密鍵」と「相葉の公開鍵」だけを触る。相葉の秘 密鍵は誰にも見せない。 桜井 Vault Key + 自分の秘密鍵 ① 相葉の公開鍵をサーバから取得 ← ② Vault Key を相葉の公開鍵で暗号化 enc(VK, pub_相葉) ③ 暗号化 Vault Key を鍵束へ登録 → ④ 相葉が自分の秘密鍵で復号 → Vault Key 入手 相葉 自分の秘密鍵 (招待受領後) サーバは中身が読めない小包を運ぶ配達員。桜井の秘密鍵も、相葉の秘密鍵も、サーバは見ない。 1Password Zero-Knowledge 11 kenimoto.dev

| 正直な限界 — サーバ運用への信頼 サーバが「相葉の公開鍵」を差し替えたら、桜井は誤ってサーバの 鍵で暗号化する。 この経路の MITM 耐性は、1Password のサーバ運用を信頼しているところに依 存します。 緩和策 A Trust Hierarchy 信頼の階層で公開鍵の真正性を検証する仕組み。 ホワイトペーパー Appendix C に記載、ただし未実装。 緩和策 B User-to-User Verification ユーザー同士が公開鍵の指紋を突き合わせる方式。 Signal 等で見る仕組み、これも未実装。 「完全 zero-knowledge」ではなく、サーバ運用への信頼を最小化した設計。 ホワイトペーパーが正直に書いている点を読むのが大事。 1Password Zero-Knowledge 12 kenimoto.dev

全文は、この2記事に。 Qiita ① qiita.com/kenimo49/items/d1151389d17e50ad5564 Qiita ② qiita.com/kenimo49/items/a8f63236077a06fd51bb 著者 kenimoto.dev ① 「1Password は、あなたのマスターパスワードを一度も受信していません」 ② 「1Password はチームメンバーに、パスワードを一度も渡していません」 ken imoto / Propel-lab 1Password Zero-Knowledge 13 kenimoto.dev