Vaulted
更新日

クライアントサイド暗号化がシークレット共有に重要な理由

著者

クライアントサイド暗号化はシークレット共有において重要だ。サーバーが平文データを決して見ないことを保証するからだ。サーバーサイド暗号化では、サービスがシークレットを読める——インフラを侵害した者も同様だ。Vaulted のようなクライアントサイドツールは、何かが送信される前に AES-256-GCM を使ってブラウザ内でデータを暗号化する。

サーバーサイド暗号化の問題

従来のシークレット共有ツールは次のフローに従う:

  1. フォームにシークレットを入力する
  2. ブラウザが平文をサーバーに送信する
  3. サーバーが暗号化して暗号文を保存する
  4. 受信者向けのリンクが生成される

問題はステップ2にある。シークレットは平文のままネットワークを通過する（TLS で保護されているが、サーバーには完全に見える）。たとえ一時的であっても、サービスはデータにアクセスできる。

これが意味すること:

  • 侵害されたサーバーは転送中のすべてのシークレットを露出させる——起きるのを待っているデータ侵害だ
  • サービスの従業員が理論上データにアクセスできる
  • 法執行機関や法的要請によってサービスがシークレットを提供させられる可能性がある
  • サーバーログが意図せず平文データを記録してしまう恐れがある

クライアントサイド暗号化による解決

Vaulted は異なるアプローチを取る。暗号化はすべてブラウザ内で行われる:

  1. フォームにシークレットを入力する
  2. ブラウザが AES-256-GCM 鍵を生成し、シークレットをローカルで暗号化する
  3. 暗号化された**暗号文**のみがサーバーに送信される
  4. 暗号化鍵は URL フラグメント（#）に配置される——ブラウザはこれをサーバーに送信しない

サーバーが見るのは暗号化されたデータのみだ。鍵を持たないため、シークレットを復号できない。

URL フラグメントが重要な理由

URL フラグメント——# 記号以降のすべて——には特別な性質がある: ブラウザは HTTP リクエストにこれを含めない。誰かが Vaulted のリンクを開いたとき、フラグメントはそのブラウザ内にとどまる。サーバーはシークレット ID へのリクエストを受け取るが、復号鍵は決して見ない。

これはカスタムプロトコルでも回避策でもない。RFC 3986 で定められた、ブラウザが常にそう動作してきた仕様だ。

実際にはどういう意味か

クライアントサイド暗号化により、仮に Vaulted のサーバーが完全に侵害されたとしても、攻撃者が得るのは暗号化されたブロブのみだ——共有リンクの中にしか存在しない鍵がなければ無意味だ。これがゼロ知識アーキテクチャの中核原則だ。

信頼は不要だ。暗号技術が語ってくれる。

シークレットを安全に共有する準備ができたら？ Vaulted を試してみよう——無料で使える。

関連