コンテンツにスキップ
Zcashでサインイン
中級 - 7分
TL;DR
- パスワードの代わりに、Zcashアドレスを自分が管理していることを証明してログインする
- 現在使われている設計は2つある: チャレンジへの署名、またはメモにコードを入れたシールド支払いの送信
- シールドアドレスは残高や履歴を隠すため、管理を証明しても自分の資産状況は露出しない
- この仕組みはまだ初期段階です。標準はまだ正式承認されておらず、実装同士の相互運用性もありません
これは誰向け？
- 個人データを収集せずにパスワードレスログインを実現したい開発者
- どのサイトにもメールアドレスを渡したくないユーザー
- 金融履歴をアカウントに結びつけずにログインしたい人
問題点
ほとんどのログイン方法は、何かしらの情報を漏らします:
- パスワードとメールは、あなたの身元にひもづくアカウントを作り出し、そのどちらも情報漏えいデータに載ってしまいます
- ソーシャルサインインでは、アイデンティティプロバイダーに、あなたがどこにいつログインしたかがすべて伝わります
- 透明なチェーンでのウォレットサインインは、見た目以上に問題があります。ウォレットを接続すると、サイトにあなたの残高全体と取引履歴すべてを永久に渡してしまうことがあります
多くの場合、利便性と情報開示のどちらかを選ばされます。
なぜZcashなのか？
Zcashは、管理していることの証明と資産情報の開示を切り分けます:
- シールドアドレスは残高と取引履歴を非公開に保つため、それを保有していることを証明しても、何をどれだけ持っているかは分かりません
- 暗号化メモには、ワンタイムのログインコードをトランザクション内に非公開で載せられます
- Viewing keysにより選択的開示が可能になるため、アプリには必要なものだけの読み取り権限を与え、それ以上は何も渡さずに済みます
仕組み
2つのアプローチが登場しています。どちらも、最終的にはアプリがあなたの安定した識別子を保持し、パスワードは不要になります。
アプローチ1: チャレンジに署名する
- アプリがランダムな使い捨てチャレンジを生成する
- あなたのウォレットが、そのアドレスの裏にある鍵でそのチャレンジに署名する
- アプリが署名を検証し、ログインさせる
何もブロードキャストされないため、手数料はかからず、ブロックを待つ必要もありません。関連する仕様はZIP 304, Sapling Address Signaturesですが、まだドラフト段階なので、メッセージ署名へのウォレット対応はまちまちです。
アプローチ2: シールド支払いで証明する
- アプリがワンタイムコードを生成し、支払いリクエストを表示する
- あなたが、そのコードをメモに入れた少額のシールドトランザクションを送る
- アプリがメモを監視し、コードを照合して、ログインさせる
これは、現在すでにメモをサポートしているウォレットで使えます。たいていのウォレットが該当します。トレードオフとして、ネットワーク手数料がかかり、承認を待つ必要があります。
アドレスを非公開に保つ
アプリは、あなたを識別するために必ずしもあなたのアドレスを保存する必要はありません。実装によっては、アドレスをアプリケーション固有の値と一緒にハッシュ化し、同じユーザーでもサイトごとに異なる安定した識別子が見えるようにします。これにより、サイト同士が情報を突き合わせてあなたのアカウントをひもづけるのを防げます。
トレードオフ
これを構築に使ったり、依存したりする前に理解しておく価値があります。
| 署名付きチャレンジ | シールド支払い |
|---|
| コスト | 無料 | ログインごとにネットワーク手数料 |
| 速度 | 即時 | 承認待ち |
| ウォレット対応 | 限定的、ZIP 304はドラフト | 広い、必要なのはメモだけ |
| チェーン上の記録が残るか | いいえ | はい、トランザクションが存在する |
共通の制約:
- デフォルトではアカウント復旧がない。 鍵を失うと、そのアプリが復旧経路を設計していない限り、アカウントも失います
- アドレスの再利用はあなたを結びつけうる。 同じアドレスを多くのサイトで使うと追跡の問題が再現されるため、アプリケーション固有の識別子が重要になります
- 正式承認された標準がない。 各プロジェクトが独自方式を持っているため、ある1つ向けに作られたログインは別のものでは機能しません
- これ単体で匿名性になるわけではない。 アプリからあなたの資産情報は隠せますが、アプリはログイン後の行動を依然としてプロファイリングできます
避けるべきよくあるミス
- チャレンジコードを再利用すること。すべてのコードは使い捨てで、すぐ失効するべきです。そうでないと、取得されたコードが再送攻撃に使われる可能性があります
- ユーザーに、ログインのために意味のある金額を送るよう求めること。支払いは証明手段なので、金額はごくわずかであるべきです
- アプリケーション固有の識別子で同じ役割を果たせるのに、生のアドレスを保存すること
- メッセージ署名がどこでも動くと思い込むこと。実際にユーザーが持っているウォレットを確認してください
- 後からメモを秘密として扱うこと。それは送信者が行動した証明にはなりますが、パスワードではありません
この分野を探っているプロジェクト
これらはZecHub Hackathon 3.0のZcash Loginトラック向けに作られました。完成品というより実験であり、同じアイデアでもどれだけ異なる実装になりうるかを示しています。
- ZecAuth - 他のエコシステムでWalletConnectが果たしている役割に近い、Zcash向けのウォレット接続プロトコルです。アプリは、サインイン、支払いリクエスト、閲覧アクセスなど、要求する権限とチャレンジを含んだQRコードまたは
zecauth://リンクを表示します。トランザクション不要、手数料不要、チェーンとの相互作用もありません。コードに加えて、文書化されたプロトコル仕様も提供しています
- ZShield - シールドアドレスをW3C DIDとOpenID Connectアイデンティティに変換します。ブラウザが鍵ペアを生成し、サーバーがZIP 304風のインターフェースでnonceを発行し、ウォレットがそれに署名し、サーバーがJWTを返します。結果はOIDC互換なので、既存のアプリが専用統合なしで利用できます
- ZecPass - 署名付きメモによって所有権を証明し、しかもアプリがユーザーのアドレスをまったく知ることがないよう設計されています。安定した識別子として使うためのアプリケーションスコープのハッシュを導出し、チャレンジを使い捨てかつ時間制限付きに保ち、React用の差し替え可能なボタンとノード検証ライブラリを提供しています
- Portal - メモにワンタイムコードを入れたシールドトランザクションを送ることでログインし、mainnet上で稼働しています。同じフローを、有料コンテンツのアンロックや、リンク経由での送金・受け取りにも再利用しています
- ZcashMe - 本人確認の証明としてシールド支払いを使い、ラップトップでのサインインにブラウザ拡張機能を必要としないよう、デスクトップとモバイルのギャップに注力しています
- ZBooks - Zcashによるサインインを製品そのものではなく再利用可能な認証プリミティブとして扱う会計・支払いツールであり、Unified Full Viewing Keyを通じて財務データを読み取ります
関連ページ
