SevenX Ventures：WebAuthnとPasskeyはどのようにして劣悪な暗号体験を救うのか？

2023.12.21

共有先

TechFlow厳選深潮セレクト

SevenX Ventures：WebAuthnとPasskeyはどのようにして劣悪な暗号体験を救うのか？

取引の安全性を確保するためには、認証されたユーザーに対して必ず本人確認を行う必要がある。

2023.12.21 - 10:09:31

Web3業界の深掘り報道に専念し潮流を洞察

取引の安全性を確保するためには、認証されたユーザーに対して必ず本人確認を行う必要がある。

著者：Rui @Ruisnakes、SevenX Ventures

TL;DR

秘密鍵はイーサリアム上で取引に署名するための鍵ですが、ニーモニックフレーズ（「シードフレーズ」とも呼ばれる）という読みやすい形式で管理しても、ユーザーにとって秘密鍵の管理は悪夢です。ブロックチェーンを複雑なゲームにすることなど、決して本意ではありません。

取引の安全性を確保するには、ユーザー認証が必要です。インターネットセキュリティとユーザーエクスペリエンスの進化に伴い、パスワード認証から顔認証や指紋などの生体認証へと移行しました。この進展において、WebAuthn は重要なマイルストーンです。本稿では次の3つの用語を中心に扱います：

WebAuthn：外部認証器によって生成される公開鍵ベースの資格情報を使用するウェブ認証標準。パスワード不要で安全なユーザー認証を実現します。
Secure Enclave：機密データの保護を目的としたハードウェアベースのセキュアゾーン。iOS、Android、Windows 各デバイスで異なるバージョンが利用可能。WebAuthn を応用すれば、外部認証器としてハードウェアレベルのセキュリティを提供できますが、秘密鍵がローカルに紐づくため、マルチデバイス間での操作が困難になります。
Passkey：OSレベルの WebAuthn 実装で、各デバイス・システムプロバイダーが独自のルールを持っています。たとえば Apple の Passkey は iCloud キーチェーンに保存された鍵を利用してマルチデバイス同期を行いますが、通常特定のプラットフォームやシステムに限定され、クロスプラットフォーム（Apple-Android）対応はできません。

上述の通り、WebAuthn の導入は日常的なブロックチェーンユーザーに対する私たちの目標——高度なフィッシング防御と使いやすい体験——と一致しています。以下は、WebAuthn をブロックチェーンに統合する提案です：

鍵層：顔認証や指紋などのスムーズな方法でユーザー認証が可能。基盤的には、ハードウェアセキュリティプロセッサ（Secure Enclave）やクラウドサービス（iCloud、Google Cloud など）による鍵管理が行われます。後ほどマルチデバイスおよびクロスプラットフォーム問題について詳しく説明します。
アカウント層：スマートコントラクトアカウント（SCA）は任意の署名者（例：SE、Passkey）と閾値メカニズムを割り当てられます。また、モジュラー設計により柔軟性とアップグレード性が高まります。たとえば、取引量、時間、IPアドレスなどの要因に基づき動的に署名要件を調整できます。一方、従来の外部アカウント（EOA）はMPC（マルチパーティ計算）サービスで拡張でき、スマートコントラクトアカウントより高い相互運用性とコスト効率を提供しますが、高度な機能（特に鍵ローテーション）には限界があります。
署名層：イーサリアムはネイティブに k1 曲線をサポートしていますが、WebAuthn の署名検証は r1 曲線を使用するためコストが高くなります。そのため、zkSync などのレイヤー2ソリューションでは、EIP-7212 の r1 曲線をネイティブサポートするプリコンパイルを計画しています。その他にも、サードパーティサービス、Solidity 検証器、ゼロナレッジ（ZK）検証器、分散型鍵管理システムなどが、r1 曲線署名を低コストで実現可能です。

* 免責事項：

技術の進歩が市場成功を保証するわけではありません。すべてのデバイスやプラットフォームがPasskeyを採用しているわけでもありません。スマートコントラクトアカウントの使用は外部アカウントよりも高価になる可能性があります。提示されたソリューションは技術の進化とともに変化し続けます。

暗号資産のユーザーエクスペリエンスがひどい？鍵管理が最悪だからだ！

ブロックチェーン分野では、資産の真の支配権はユーザーまたはウォレットプロバイダーではなく、秘密鍵にあります。この鍵がイーサリアム上での取引実行の成否を決定します。これを理解するために、外部アカウントの例を見てみましょう：

鍵生成：secp256k1 楕円曲線からランダムな数値を選択し、それが秘密鍵となります。この秘密鍵を曲線上の予め定義された点に乗算することで公開鍵を生成します。イーサリアムアドレスは、公開鍵のハッシュ値の下位20バイトから派生されます。通常、秘密鍵を人間が読める単語列に変換したニーモニックフレーズを使ってバックアップし、そこから秘密鍵と公開鍵を再生成します。
取引署名：nonce（シーケンス番号）、金額、gas価格、受信アドレスなどを含む取引データに秘密鍵で署名します。このプロセスには楕円曲線デジタル署名アルゴリズム（ECDSA）が使用され、secp256k1 曲線を用いて (r, s, v) 値からなる署名を生成し、署名と元の取引データをネットワークにブロードキャストします。
取引検証：取引がイーサリアムノードに到達すると、メモリプール内で検証されます。署名者の正当性を確認するため、ノードは署名とハッシュ化された取引データから送信者の公開鍵を復元し、そのアドレスが送信者アドレスと一致するかを確認します。

前述のように、秘密鍵はオンチェーンにおける重要な存在です。当初のイーサリアムアカウント、すなわち外部アカウントは単一の秘密鍵に完全に依存しており、鍵の紛失はアカウントアクセスの喪失を意味する重大なリスクを伴います。

多くの人はアカウント抽象（AA）がユーザーエクスペリエンス問題の究極解だと考えるかもしれませんが、必ずしもそうではありません。アカウント抽象はイーサリアム上の有効性ルール（validity rule）をプログラマブルなものに変え、スマートコントラクトアカウントがそれを実現します。アカウント抽象は強力で、並列取引送信（抽象nonce）、gasスポンサーシップ、ERC20でgas支払い可能（抽象gas）といった機能を提供します。そして本稿のテーマとも関連する重要な点は、「固定署名検証の打破（抽象ECDSA署名）」です。外部アカウントとは異なり、スマートコントラクトアカウントはマルチシグやセッション鍵など、任意の署名者や署名方式を割り当てられます。しかし、アカウント抽象の柔軟性とアップグレード性が向上しても、依然として取引署名には鍵が必要です。

秘密鍵を12語のニーモニックフレーズに変換しても、鍵管理は依然として大きな課題であり、紛失やフィッシング攻撃のリスクがあります。ユーザーは複雑な非中央集権的ソリューションと中央集権的サービスの間で選択を迫られますが、どちらも理想的とは言えません。

なぜ暗号資産体験がひどいのか？その大きな理由は鍵管理が劣悪だからです。ユーザーは常に使いやすさ、セキュリティ、非中央集権の間で妥協を強いられています。本稿では、鍵管理の最適解を探ります。

鍵管理レイヤー

万能の解決策はありません。鍵保管の最良の方法は特定のユーザーシナリオに応じてカスタマイズされ、ユーザーの種類（機関か個人か）、資金額、取引頻度、インタラクションのタイプなどの要因に左右されます。

あらかじめ断っておきますが、「セルフホスティング、セミホスティング、フルホスティング」といった現在流行の言葉は使いません。私にとって真のセルフホスティングとは、他者に依存せず独立して取引に署名することです。例えば、非中央集権ノードのTEE（Trusted Execution Environment）に保存されていても、伝統的な意味ではホスティングではないかもしれません。しかし、ホスティングの種類だけでソリューションの良し悪しを判断するのは短絡的であり、適用性の違いを無視しています。鍵管理手法をより精緻に評価するため、以下の3つの次元で分析することを提案します。

責任

鍵管理の責任を異なる当事者に分割するかどうか。

個人ユーザーは鍵管理に多くの課題を抱えるため、責任の分散は自然なリスク軽減戦略です。これには複数の鍵による共同署名、マルチシグ（Multi-sig）システム、あるいは秘密分散方式（SSS）やMPC（マルチパーティ計算）による秘密鍵の分割などが含まれます。

マルチシグ（Multi-sig）：複数の完全な秘密鍵が必要で、異なる署名者がオンチェーンで通信します。トランザクション料金が高く、プライバシーにも影響を与えます（署名者の数がオンチェーンで可視化されるため）。
秘密分散方式（SSS）：単一の場所で秘密鍵を生成し、それを複数の部分に分割して配布します。署名時には完全な鍵を再構築する必要がありますが、その一時的再構築が脆弱性を生む可能性があります。
MPC-TSS（Threshold Signature Scheme）：MPCの一形態であり、参加者が個々の入力を秘匿したまま共同計算を行う暗号技術です。各参加者は独立して鍵の一部を生成し、実際に会わずに取引に署名できます。オフチェーン処理のため費用が低く、SSSのような単一障害点のリスクもありません。

ストレージ

鍵または鍵の一部を保存する方法。セキュリティ、アクセス性、コスト、非中央集権性の要因に影響されます。

AWS、iCloud などの中央集権クラウドサービス。頻繁な取引に便利だが、検閲リスクが高い。
IPFS、Filecoin などの非中央集権ストレージ。
ローカルPC／モバイル端末：ブラウザのセキュアストレージに保存。
ペーパーウォレット：秘密鍵やQRコードを印刷。
信頼できる実行環境（TEE）：メインプロセッサ内にセキュアゾーンを提供し、メインOSとは独立して機密データを実行または保存。
Secure Enclave：現代のデバイスではメインプロセッサから隔離されたSecure Enclaveが追加のセキュリティ層を提供し、アプリケーションプロセッサが侵害されても機密データを守れます。
ハードウェアウォレット：Ledger や Trezor などの物理デバイスで、秘密鍵を安全に保管。
HSM（Hardware Security Module）：企業向けに設計された専用ハードウェアで、高度な鍵管理と暗号処理を提供。

アクセス

保存された鍵へのアクセス時に、どのようにユーザー本人を認証するか。

保存された鍵へのアクセスには認証が必要です。つまり、アクセスしようとする人物が本当に許可されているかを確認する必要があります。過去の方法を振り返ると、以下のカテゴリに分けられます：

「知っているもの」：パスワード、PIN、セキュリティ質問の回答、特定の図形。
「持っているもの」：スマートカード、ハードウェアトークン（TOTP）、ソーシャルアカウント認証、携帯電話に送信されるSMSコードなど。
「その人自身」：指紋、顔認証（AppleのFace IDやWindows Hello）、音声認識、虹彩／網膜スキャンなど、ユーザー固有の身体的特徴。

これらを組み合わせた二要素認証（2FA）や多要素認証（MFA）は、SMSとプッシュ通知など複数の要素を併用してアカウントのセキュリティを強化します。

既存製品分析

MetaMask は、ユーザーがパスワードを使ってローカルブラウザストレージに保存された鍵にアクセスできるようにしています。

Trust Wallet は、パスワードまたはFaceIDでローカルブラウザストレージ内の鍵にアクセスでき、さらにクラウドサービスで秘密鍵をバックアップすることも可能です。

Privy はメールアドレスなど複数のソーシャルログインをサポートし、秘密分散方式で鍵を3つに分割：

デバイスシャード：ブラウザ - iFrame、モバイル - Secure Enclave。
Auth 認証シャード：Privy が保存、Privy ID に関連付け。
Recovery 復旧シャード：ユーザーのパスワード、または Privy が HSM で暗号化して保存。

Particle はソーシャルログインに対応し、MPC-TSS を使って鍵を2つに分割：

デバイスシャード：ブラウザ - iFrame
サーバー鍵部分：Particle のサーバー

新ソリューション

鍵層：WebAuthn、Secure Enclave、Passkey

上述の既存ソリューションは、ユーザーをWeb3へ引き寄せる上で重要な役割を果たしてきました。しかし、新たな課題も浮上しています：パスワードは忘れられたりフィッシングの標的になったりしやすく、2FAは安全でも手順が多く面倒です。また、誰もが第三者に鍵管理を委ねることを望んでいるわけではなく、あるサービスが鍵へのアクセスを制限すれば、ユーザーはそのシステムの可用性と有効性に依存し続けます。

そこで考えられるのは、より効果的なソリューション——ほぼ信頼不要で、高セキュリティかつシームレスなユーザーエクスペリエンスを提供するものです。この探求は最適なWeb2の方法へと導かれます。冒頭でも述べたように、このテーマと深く関連するいくつかの用語があります。WebAuthn は認証規格であり、Secure Enclave と Passkey はその展開または構成要素です。

WebAuthn

WebAuthn は、ウェブアプリケーションにおけるユーザー認証のインターフェースを規定します。ユーザーはパスワードではなく、外部認証器を使ってインターネットアカウントにログインできます。認証器は、YubiKey、Titan Key などのローミング認証器、あるいは Apple デバイスの内蔵キーチェーンなどのプラットフォーム認証器です。

WebAuthn の基盤技術は当初、FIDO（Fast IDentity Online）アライアンスによって開発されました。2019年3月、W3CがWebAuthnを正式なWeb標準として宣言。標準化の進展により、Google Chrome、Mozilla Firefox、Microsoft Edge、Apple Safariなどの主要ブラウザがWebAuthnを採用し、その適用範囲と可用性は大幅に拡大しました。現在では多くの先進デバイスでサポートされています。

WebAuthn の利点：

高いセキュリティ：パスワードに依存しないため、フィッシング、ブルートフォース、リプレイ攻撃のリスクが減少。
優れたユーザーエクスペリエンス：ワンクリックまたは生体認証で簡単に素早くログイン。
プライバシー保護：認証中に共有秘密情報は送信されず、各サイトは個人情報を取得しません。
拡張性と標準化：Web標準であるため、異なるブラウザやプラットフォーム間で一貫性と相互運用性が保証されます。

デバイスベースの WebAuthn（例：Secure Enclave）

現在では、Apple の Secure Enclave、Android の Trustzone、Google Pixel の Strongbox など、ハードウェアプロセッサを認証器として利用できます。

鍵生成：公開鍵暗号を利用し、WebAuthn 標準に従って鍵ペアを生成（通常は P-256 r1 曲線）。公開鍵をサーバーに送信し、秘密鍵は Secure Enclave を絶対に離れません。ユーザーは平文の鍵を扱うことがないため、秘密鍵の安全性が確保されます。
鍵保存：秘密鍵はデバイスの Secure Enclave 内に安全に保存されます。これはメインプロセッサから隔離された強化されたサブシステムで、メインシステムが侵害されてもオリジナルの鍵データにアクセスできません。Secure Enclave を突破するのは非常に難しく、Apple Pay や FaceID のデータなど最も機微なデータがここに保存されています。
認証：ユーザーが顔認証や指紋でアクセス権を得ると、Secure Enclave が秘密鍵を使ってサーバーのチャレンジに署名し、サーバーは公開鍵で検証します。

デバイスベースの WebAuthn の利点：

ハードウェア並みのセキュリティ：Secure Enclave のような独立したハードウェアベースの鍵管理がセキュリティを向上。
フィッシング耐性：脅威のあるデバイスやサイトに何の情報を入力する必要もありません。
使いやすさ：よりユーザーフレンドリーな体験を提供。ユーザーは複数のサイトごとに複雑なパスワードを覚える必要がなくなります。

デバイスベースの WebAuthn の欠点：

デバイス制限：デバイスを紛失または破損した場合、秘密鍵をエクスポートまたは回復できず、マルチデバイス操作ができません。

クラウドベースの WebAuthn、Passkey

マルチデバイス機能の課題を解決するため、テック大手はクラウドベースの WebAuthn 展開として Passkey を導入しました。Apple によって広く知られるようになりました。

Apple の Passkey の例：

鍵生成：macOS、iOS、iPadOS デバイスが認証器として機能し、アカウント作成時に公開鍵と秘密鍵を生成。公開鍵をサーバーに送信し、秘密鍵はデバイスのiCloudキーチェーンに保存。iCloudキーチェーンのデータはハードウェアバインドされた鍵で暗号化され、HSMに保存。Appleはその鍵にアクセスできません。
マルチデバイス同期：iCloudにアクセスするのと同じプロセス。iCloudアカウントを認証し、SMSで受信したコードを入力し、いずれかのデバイスのパスワードを入力。

クラウドベースの WebAuthn の利点：

マルチデバイス：Passkey はユーザーが普段使うすべてのデバイスでアクセス可能にするよう設計されています。ただし現状では Apple デバイスに限定。Android デバイスではハードルが高く、バージョンやハードウェアのばらつきが原因です。
フィッシング耐性：同上。
使いやすさ：同上。

クラウドベースの Passkey の欠点：

クラウドサービスへの依存：デバイスベースの WebAuthn と比べ、クラウドベースの Passkey は Secure Enclave のハードウェアセキュリティから iCloud キーチェーンに移行。これはクラウドホスティングと見なされる可能性があり、懸念点としては、ユーザーの iCloud AppleID アカウントが漏洩するリスク。iCloud キーチェーンはエンドツーエンド暗号化で保護されていますが、操作ミスや脆弱性によりリスクが生じる可能性があります。
プラットフォーム制限：例えば、iCloudベースのパスキーをAndroidデバイスで使うのは非常に難しい。また、従来の方法とは異なり、AppleやGoogleはデバイス固有のアサーション(assertion)を送信しないため、現在のところ生成された鍵のデバイスタイプを検証できません。これが鍵と関連メタデータの信頼性に疑問を投げかけます。

アカウント層：スマートコントラクトアカウントと外部アカウント

ここまでで、マルチデバイス・クロスプラットフォーム互換性を維持しつつハードウェアレベルのセキュリティを確保することは大きな課題であることがわかりました。同様に重要なのがソーシャルリカバリオプション、つまり複数のガーディアン（guardian）を追加してセキュリティを強化する機能です。このような場合、ブロックチェーンが道しるべとなることができます。

注意：Web2のWebAuthnをWeb3に展開しようとすると、明らかな差異があります。Web2では所有権の証明だけで済みますが、Web3では取引の承認も必要です。Passkeyだけでは、開発者が署名メッセージを制御できません。メッセージは通常「sign in」のような汎用的なものになり、潜在的なフロントエンド操作（ユーザーが「盲目」にメッセージに署名してしまう）のリスクがあります。一見些細に見えるこの問題は、実は極めて重要です。

スマートコントラクトアカウント自体がスマートコントラクトであり、オンチェーンの実体として任意の署名者を指定できます。この柔軟性により、Androidスマホ、MacBook、iPhoneなどを署名者として設定できます。また、モジュラー設計によりアップグレード可能で、新しい署名者と交換したり、署名閾値を2/3からより複雑な構成に変更できます。

想像してみてください。状況に応じてセキュリティ要件を柔軟に調整できるウォレットです。ユーザーが馴染みのあるローカルIPアドレスからアクセスしているときは単一署名者で認証し、未知のIPアドレスや一定額以上の取引では複数の署名者を要求します。モジュラー性とプログラマビリティがあれば、思いつく限りのイノベーションが可能です。Safe、Zerodev、Biconomy、Etherspots、Rhinestoneなど多くのスマートコントラクトアカウントサービスプロバイダーがこの領域を積極的に構築しています。Stackup、Plimico、Alchemyなどのインフラのおかげで、これらが可能になっています。

詳細については、以前の研究をご覧ください。

スマートコントラクトアカウントはMPCサービスを通じてソーシャルリカバリやマルチデバイス／マルチプラットフォーム互換性を実現できます。スマートコントラクトアカウントは固定の署名者を持つものの、MPCプロバイダーは鍵を複数に分割することでセキュリティと柔軟性を高めます。この方法はスマートコントラクトアカウントのようなプログラマブル性やアップグレード性（タイムロックリカバリ、鍵の簡単な無効化など）はありません。しかし、特定のブロックチェーンに縛られないため、クロスチェーン能力に優れ、コスト効率も高いです。有名なMPCプロバイダーにはParticle Network、Privy、web3 Auth、OKX Wallet、Binance Walletなどがあります。