ウェブ認証

Web認証（WebAuthn）は、ワールドワイドウェブコンソーシアム（W3C）が公開したウェブ標準です。^{[1] [2] [3] WebAuthnは、} FIDOアライアンスの指導の下でFIDO2プロジェクトの中核コンポーネントです。^{[4]このプロジェクトの目標は、}公開鍵暗号を使用して、Webベースのアプリケーションやサービスに対してユーザーを認証するためのインターフェースを標準化することです。複数のデバイスで利用できるWebAuthn資格情報（それ自体がFIDO資格情報です）は、一般的にパスキーと呼ばれます。^[5]

クライアント側では、WebAuthn のサポートはさまざまな方法で実装できます。基盤となる暗号化操作は、キー マテリアルの管理方法にほとんど依存しない抽象的な機能モデルである認証子によって実行されます。これにより、プロセッサの信頼できる実行環境またはTrusted Platform Module (TPM) を利用して、WebAuthn のサポートを純粋にソフトウェアで実装できます。機密性の高い暗号化操作は、 USB、Bluetooth Low Energy、または近距離無線通信(NFC)を介してアクセスできるローミング ハードウェア認証子にオフロードすることもできます。ローミング ハードウェア認証子は、FIDO Client to Authenticator Protocol (CTAP) ^{[6]に準拠しているため、WebAuthn は FIDO} Universal 2nd Factor (U2F) 標準と実質的に下位互換性があります。^[7]

従来のU2Fと同様に、Web認証は検証者のなりすましに対して耐性があります。つまり、フィッシング攻撃に対して耐性があります。^[8]しかし、U2Fとは異なり、WebAuthnは従来のパスワードを必要としません。 ^[9]さらに、ローミングハードウェア認証子は、ホストマシンで実行されているソフトウェアが秘密鍵マテリアルにアクセスできないため、マルウェアに対して耐性があります。

WebAuthnレベル1および2の標準は、それぞれ2019年3月4日と2021年4月8日にW3C勧告として公開されました。 ^{[1] [10] [11]}レベル3の仕様は現在、ファーストパブリックワーキングドラフト（FPWD）です。^[12]

FIDO2はFIDO Universal 2nd Factor (U2F)の後継です。U2Fは既存のユーザー名/パスワードベースのログインフローを強化するために設計されたため、多要素モードのみをサポートしていますが、FIDO2は単一要素モードのサポートを追加します。多要素モードでは、認証子はユーザーの存在のテストによってアクティブ化されます。これは通常、単純なボタンを押すだけで、パスワードは必要ありません。単一要素モードでは、認証子（something you have）がユーザー検証を実行します。^[13]認証子の機能に応じて、これは次のようになります。^[14]

• あなたが知っていること：PIN、パスコード、スワイプパターンなどの秘密
• あなた自身の特徴:指紋、虹彩、声などの生体認証

モードに関係なく、認証者はその秘密や生体認証データをウェブサイトと共有することはありません。^[15]さらに、認証者は、ユーザー検証が正常に完了した後、認証を要求するサービスに使用する正しい暗号化キーマテリアルを選択するため、1人のユーザーの秘密または生体認証はすべてのウェブサイトで機能します。

認証デバイスの秘密情報と生体認証は、スマートフォンで使用されるのと同様に、一緒に使用できます。たとえば、指紋はスマートフォンへの便利なアクセスを提供するために使用されますが、指紋アクセスが失敗する場合もあります。その場合は PIN を使用できます。

WebAuthn は、従来のパスワードベースの認証に固有の多くの問題を設計的に解決します。

• 安全な資格情報の生成と保存: WebAuthn は、堅牢なアルゴリズムを使用して各 Web サイトに固有の資格情報を生成し、信頼できる認証システムに安全に保存します。これにより、次のような一般的な脆弱性が排除されます。
  • 長さが不十分なため、簡単にブルートフォース攻撃を受けてしまう弱いパスワード。
  • 辞書攻撃に対して脆弱な予測可能なパスワード (例: "password"、"12345678")。
  • 個人情報（生年月日、住所など）に基づいた推測可能なパスワード。
  • クライアント側のパスワード保存が不十分です (例: 書き留めたり、電話の連絡先に保存したり)。
  • WebAuthn 認証情報は設計上、個々の Web サイトに固有であるため、複数の Web サイトでパスワードを再利用できます。
  • サーバーが義務付けたパスワード要件が不十分です (例: 過度に緩いまたは制限的な基準、恣意的な最大長制限、制限された文字セット)。
  • パスワード マネージャーの自動入力機能を妨げる制限。
• サーバー側での資格情報の保存なし: 資格情報のプライベート部分はサーバー上に保存されないため、次のようなリスクや脆弱性が排除されます。
  • データベース内の安全でないパスワードの保存 (例: プレーンテキスト、または弱いハッシュベースのアルゴリズム/構造に依存)。
  • データベースが漏洩し、パスワードが露出します。
  • 必須だが効果のない定期的なパスワード変更。
• 各 Web サイトの固有の認証情報: WebAuthn は、認証情報が Web サイトごとに固有であることを保証し、次のリスクと脆弱性を排除します。
  • クレデンシャル スタッフィング攻撃。攻撃者は、1 つのデータ侵害からの資格情報を複数のサイトで使用します。
  • 資格情報は再利用できないため、または別の Web サイトに誤って適用されないため、フィッシング攻撃が発生します。

前身のFIDO U2Fと同様に、W3C Web認証（WebAuthn）には、Webサイト、Webブラウザ、認証子が含まれます。^[1]

• ウェブサイトはWebAuthn準拠のRelying Partyです
• ブラウザはWebAuthnクライアントに準拠しています
• 認証子はFIDO2認証子であり、WebAuthnクライアントと互換性があると想定されています。

WebAuthn は、WebAuthn 依存パーティと呼ばれる検証者に対して、申請者が FIDO2 認証子の所有と制御を証明する方法を指定します。認証プロセスは、WebAuthn クライアントと呼ばれるエンティティによって仲介されます。これは、準拠した Web ブラウザに過ぎません。

説明のため、認証子はローミング ハードウェア認証子であると想定します (他のオプションについては以下を参照)。いずれの場合も、認証子は、WebAuthn 依存パーティを対象とした認証アサーションに署名するために公開鍵暗号化を使用する多要素暗号化認証子です。認証子がユーザー検証にPIN を使用すると仮定すると、認証子自体はユーザーが所有するものですが、PIN はユーザーが知っているものになります。

WebAuthn認証フローを開始するには、^{[16] WebAuthn Relying Partyが}JavaScriptを介してWebAuthnクライアント（つまりブラウザ）にその意図を示します。WebAuthnクライアントはブラウザに実装されたJavaScript APIを使用して認証装置と通信します。ローミング認証装置はFIDOクライアントから認証装​​置へのプロトコルに準拠しています。

WebAuthnは厳密にはローミングハードウェア認証子を必要としません。代わりに、ソフトウェア認証子（例：スマートフォンに実装）またはプラットフォーム認証子（つまり、WebAuthnクライアントデバイスに直接実装された認証子）を使用することもできます。プラットフォーム認証子の関連例としては、Windows Hello ^[17]やAndroidオペレーティングシステム^[18]などがあります。

図に示したフローはPINベースのユーザー認証に依存しており、使いやすさの点では、通常のパスワード認証に比べてわずかな改善に過ぎません。実際には、ユーザー認証に生体認証を使用すると、WebAuthnの使いやすさが向上します。^{[引用が必要]}ただし、生体認証の背後にあるロジスティクスはまだ十分に理解されていません。ユーザーの間では、生体認証データがパスワードと同じようにネットワーク経由で送信されるという誤解が残っていますが、これは事実ではありません。^{[19] [20]}

WebAuthn 依存パーティがブラウザから署名された認証アサーションを受信すると、アサーションのデジタル署名はユーザーの信頼できる公開キーを使用して検証されます。

ユーザーの公開鍵を取得するために、WebAuthn の依存当事者は、上に示した認証フローに似た WebAuthn 登録フロー^[21]を開始します。主な違いは、認証者が認証秘密鍵を使用して認証ステートメントに署名するようになったことです。署名された認証ステートメントには、WebAuthn の依存当事者が署名された認証アサーションを検証するために最終的に使用する公開鍵のコピーが含まれています。認証ステートメントには、認証者自体を説明するメタデータも含まれています。^{[引用が必要]}

認証ステートメントのデジタル署名は、その特定の認証モデルの信頼できる認証公開鍵で検証されます。WebAuthn Relying Partyが信頼できる認証公開鍵のストアを取得する方法は指定されていません。1つのオプションは、FIDOメタデータサービスを使用することです。^[22]

JavaScript で指定された認証タイプによって、信頼モデルが決まります。たとえば、信頼モデルが基本的に初回使用時の信頼である self-attestation と呼ばれる認証タイプが必要な場合があります。

WebAuthnレベル1標準は、 2019年3月4日にWeb認証ワーキンググループによってW3C勧告として公開されました。 ^{[1] [10] [23]} WebAuthnは、 Google Chrome、Mozilla Firefox、Microsoft Edge、Apple Safari ^[10]、Operaでサポートされています。^[24]

Google Chromeのデスクトップ版はバージョン67からWebAuthnをサポートしています。^[25]以前のFIDO U2F標準を完全にサポートしていなかったFirefoxは、2018年5月9日にリリースされたFirefoxバージョン60でWebAuthnを組み込み、有効化しました。^[26] Microsoft Edgeの初期のWindows Insiderリリース（ビルド17682）では、 Windows Helloと外部セキュリティキーの両方で動作するWebAuthnのバージョンが実装されました。 ^[27]

既存のFIDO U2FセキュリティキーはWebAuthn標準とほぼ互換性がありますが、WebAuthnではアカウントごとに固有の「ユーザーハンドル」識別子を参照する機能が追加されており、これは古い認証システムでは保存できません。^[1]

最初のFIDO2互換認証デバイスの1つは、2018年4月10日に発表されたYubicoの第2世代セキュリティキーでした。 ^[28]ディスプレイを備えた最初のFIDO2互換認証デバイスは、2019年11月6日に発表されたSatoshiLabsのTrezor Model Tでした。^[29] Trezor Model Tは、ユーザーがデバイス上で直接使用するFIDO2常駐認証情報を選択できる最初の認証デバイスでもありました。

最初のセキュリティレベル2認定FIDO2キー「Goldengate」は、1年後の2019年4月8日にeWBMによって発表されました。^{[30] [31]}

Dropboxは2018年5月8日にWebAuthnログイン（第2要素として）のサポートを発表しました。^[32]

Appleは2020年6月24日に、Face IDまたはTouch IDをSafariのWebAuthnプラットフォーム認証子として使用できると発表した。^[33]

WebAuthnは、W3Cのより一般的な資格情報管理 APIの拡張を実装しています。これは、ユーザー資格情報を交換する際にWebサイトとWebブラウザー間のやり取りを形式化する試みです。Web認証API ^{[34] [35]}は、資格情報管理メソッドnavigator.credentials.create()とnavigator.credentials.get() JavaScriptメソッドを拡張して、パラメーターを受け入れるようにしますpublicKey。このメソッドは、公開鍵認証子をcreate()ユーザーアカウントに関連付ける一環として登録するために使用されます（最初のアカウント作成時かもしれませんが、新しいセキュリティデバイスを既存のアカウントに追加するときに行われる可能性が高いです）。一方、このメソッドは認証（ログイン時など）に使用されます。 get()

ブラウザが WebAuthn をサポートしているかどうかを確認するには、スクリプトでwindow.PublicKeyCredentialインターフェースが定義されているかどうかを確認する必要があります。 に加えてPublicKeyCredential、この標準ではAuthenticatorResponse、AuthenticatorAttestationResponse、AuthenticatorAssertionResponseインターフェースのほか、さまざまな辞書やその他のデータ型も定義されています。

API では、秘密鍵の初期作成のリクエスト以外、秘密鍵への直接アクセスや操作は許可されません。

2018年8月、Paragon Initiative EnterprisesはWebAuthn標準のセキュリティ監査を実施しました。特定の脆弱性は発見できませんでしたが、基盤となる暗号化の使用方法と標準で義務付けられている方法に重大な弱点があることが明らかになりました。^[36]

批判の主なポイントは、過去に他の暗号化システムで問題となった 2 つの潜在的な問題を中心に展開されており、同じ種類の攻撃の被害に遭わないために回避する必要があります。

• COSE (RFC 8152) の必須使用により、WebAuthn はPKCS1v1.5 パディングを使用したRSAもサポートします。この特定のパディング スキームは、少なくとも 20 年間、特定の攻撃に対して脆弱であることが知られており、過去には RSA 暗号システムの他のプロトコルや実装で攻撃に成功しています。WebAuthn のコンテキストでは、与えられた条件下ではこれを悪用することは困難ですが、より安全な暗号化プリミティブやパディング スキームがあることを考えると、これは依然として悪い選択であり、暗号学者の間ではもはやベスト プラクティスとは見なされていません。
• FIDOアライアンスは、非対称暗号化方式ECDAAを標準化しました。^[37]これは、楕円曲線に基づく直接匿名認証のバージョンであり、WebAuthnの場合は、ハンドルのグローバルな相関を許可しないため、ユーザーのプライバシーを保護しながら、認証子の整合性を検証するために使用されることを目的としています。ただし、ECDAAには、楕円曲線暗号化の分野における過去数十年の研究で得られた教訓の一部が組み込まれていません。選択された曲線には、このタイプの曲線に固有のセキュリティ上の欠陥があり、セキュリティの保証が大幅に低下するためです。さらに、ECDAA標準には、過去にすでに問題となっていたランダムで非決定的な署名が含まれています。

パラゴン・イニシアティブ・エンタープライズはまた、この標準が最初に開発された方法についても批判した。提案は事前に公表されず、経験豊富な暗号学者に提案やフィードバックを求めなかったため、この標準は学術界からの広範な暗号研究の対象とならなかった。

これらの欠点にもかかわらず、Paragon Initiative Enterprises は、ユーザーに WebAuthn の使用を継続するよう奨励していますが、標準が確定する前に実装できることを期待して、標準の潜在的な実装者と開発者向けにいくつかの推奨事項を作成しました。このような間違いをできるだけ早く回避することで、標準の不備や下位互換性の必要性によってもたらされるあらゆる課題から業界を守ることができます。

ECDAA は、デバイス認証と組み合わせて使用​​するようにのみ設計されました。WebAuthn のこの特定の機能は、認証が機能するために必ずしも必要ではありません。現在の実装では、登録セレモニー中に認証ステートメントを送信するかどうかをユーザーが決定できます。独立して、依存当事者は認証を要求するかどうかを選択できます。ECDAA は、ブラウザーや依存当事者によって実装されなかったため、WebAuthn レベル 2 から削除されました。^[38]

• FIDOアライアンス

• Web認証: 公開鍵認証情報にアクセスするためのAPI
• Web認証ワーキンググループ
• MDN の Web 認証 API
• WebAuthn 素晴らしい