デバイスバウンド・パスキー vs. 同期パスキー (SCAとパスキー 第1部)

概要: パスキーによる強力な顧客認証#

• PSD2およびSCA要件の分析
• SCA要件がパスキーに意味するもの
• パスキーに対するPSD3 / PSRの影響

1. はじめに: デバイスバウンド・パスキー vs. 同期パスキー#

以前のパスキーとPSD2に関するブログ記事で、RevolutやFinomといったフィンテック企業がすでにパスキーを使用しており、それが銀行業務のデジタルセキュリティをいかに向上させているかについて議論しました。

パスキーには大きく2つの形態があります。**同期パスキー（synced passkeys）とデバイスバウンド・パスキー（device-bound passkeys）**です。同期パスキーがユーザーに複数のデバイス間でのシームレスな認証を可能にする一方で、デバイスバウンド・パスキーは、ハードウェア・セキュリティキーやローカルのオーセンティケーターといったパスキーデバイスに厳格に紐付いています。

この全4回のブログ記事シリーズでは、異なるタイプのパスキー（デバイスバウンド vs. 同期）が、SCAおよびPSD2要件にどのように準拠しているかを深く分析します。

シリーズの第1部では、デバイスバウンド・パスキーと同期パスキーの違いを理解することに焦点を当てます。

第2部では、PSD2と強力な顧客認証（SCA: Strong Customer Authentication）が何を意味するのかを、その歴史的な発展も踏まえながら分かりやすく説明します。

シリーズの第3部では、異なるタイプのパスキーがSCAにどのように準拠しているか、そしてこれがパスキーの導入を検討している銀行、フィンテック、金融機関にとって何を意味するのかを示します。

シリーズの第4部（最終回）では、PSD3およびPSRが将来のSCAとパスキーにとってどのような意味を持つのかを結論づけます。

2. 強力な顧客認証、PSD2、そしてパスキー#

前回のブログ記事の公開後、PSD2フレームワーク下のSCAに関連した、パスキーに対する当社の見解について多くの追加質問を受けました。パスキーの適用だけでなく、それらが**規制技術基準（RTS: Regulatory Technical Standards）**にどのように適合しているかを理解することへの明確な関心が存在します。さらに、関係者はパスキーの使用に関する、**欧州銀行間取引所（EBA: European Banking Authority）**を含む規制当局からの潜在的な解釈やガイダンスにも興味を持っています。

これを認識し、私たちはパスキーがPSD2指令およびSCAに関するRTSにどのように統合できるかをさらに深く掘り下げ、このテクノロジーの使用に関する当社の立場を明確にすることを目指しています。また、既存のEBAのQ&Aを調査することで、規制当局やEBAがパスキーをどのように捉える可能性があるかを明らかにします。この考察では、同期パスキーとデバイスバウンド・パスキーの違いだけでなく、セキュリティとユーザー体験の両方を向上させる上での実用的なアプリケーションについても取り上げます。

ニュアンスを理解することで、関係者はPSD2の厳しい要件に準拠するだけでなく、最新の認証技術を活用してデジタルトランザクションを保護するための情報に基づいた意思決定を下すことができます。私たちの議論は、セキュリティ対策が進化するデジタル環境に確実に対応できるよう、認証プロセスへのパスキー統合の道筋をさらに照らすことを目的としています。

もちろん、各実装には独自の複雑さがあるため、PSD2の対象となるすべての規制対象企業は、規制目標をどのように満たすかについて独自の決定を下す必要があります。この個別のアプローチは、規制フレームワークが統一された基準を提供する一方で、独自の運用環境、技術力、ユーザーベースのために、これらの基準の実際の適用は組織によって大きく異なるという事実を認識するものです。

したがって、私たちの洞察は指針を提供し情報を提供することを目的としていますが、規定するものではありません。各事業体は、セキュリティおよび認証プロトコルにパスキーを統合する際の具体的な状況と課題を考慮する必要があります。

3. デバイスバウンド・パスキーから同期パスキーへ#

デバイスバウンド・パスキーと同期パスキーの違いを理解するために、エコシステムがどのように発展してきたかを簡単に探ってみましょう。

3.1 デバイスバウンド・パスキー（単一デバイス・パスキー）とは何か？#

まず、デバイスバウンド・パスキーの歴史と進化を振り返り、その後で技術的な詳細を深く見ていきます。

3.1.1 デバイスバウンド・パスキーの歴史#

歴史的に、WebAuthn（パスキーの基礎となる標準）内の認証メカニズムは、物理デバイス、つまりセキュリティキー（例: YubiKey）に強く結びついていました。パスキーが広く普及する前は、単一のオーセンティケーターに紐付くFIDO2クレデンシャルがセキュリティのゴールドスタンダードを象徴していました。これらのクレデンシャルは、それらが保存されているデバイスにリンクされています。この紐付けの意味合いは重要で、クレデンシャルは元のハードウェアを超えて転送したり利用したりすることはできませんでした。

このアプローチは、認証プロセスを単一のデバイスに局所化することでセキュリティを強化する一方で、特に一般的な非技術者の消費者の間での広範な普及に影響を与える実用上の制限に必然的に直面しました。ユーザーはログイン試行のたびに認証用デバイスを手元に用意する必要があり、これはユーザーの機動性を制限するだけでなく、デバイスの紛失、破損、またはすぐにアクセスできないシナリオでの懸念を引き起こしました。

さらに、消費者が追加のハードウェアに投資することへの抵抗感もありました。歴史的に、専用のセキュリティキーの所有と使用は、一般消費者の間では非常に低いものでした。認証目的で専用ハードウェアを購入するという展望は、強化されたセキュリティ上の利点にもかかわらず、大多数のB2Cユーザーにはあまり響きませんでした。同時に、彼らは通常、広範なフィッシングキャンペーンやクレデンシャルスタッフィング攻撃の標的となっています。

3.1.2 デバイスバウンド・パスキーの技術的詳細#

デバイスバウンド・パスキーは、発見可能（discoverable）なクレデンシャルと発見不可能（non-discoverable）なクレデンシャルへの特定の分類を特徴としており、この区別は主にそれらの発見可能性を定義しています。しかし、デバイスバウンド・キーを区別する重要な要因は、WebAuthnクレデンシャルのプロパティ、特にisBackupEligibleとisBackupSynchronizedフラグにカプセル化されています。デバイスバウンド・パスキーの場合、これらのフィールドは両方ともゼロに設定されており、クレデンシャルがバックアップやデバイス間での同期の対象ではないことを示しています。これらの特性は、それらが作成された物理デバイスとの本質的なリンクを強調し、クレデンシャルが特定のハードウェアに関連付けられ、そのハードウェアでのみ使用可能であることを保証します。

実際のデバイスバウンド・クレデンシャルの注目すべき例は、Windowsエコシステム内に見られます。Windows 10およびWindows 11でのWindows Helloクレデンシャルはデバイスバウンドのままです。Windows Hello自体はまだデバイス間でパスキーを同期しません。しかし、MicrosoftはMicrosoft Edgeでのパスキーの保存と同期の導入（Edge 142から開始）により、重要な第一歩を踏み出しました。このMicrosoftパスワードマネージャーを介したブラウザレベルの同期により、GoogleパスワードマネージャーがWindows上のChromeブラウザでパスキーの同期を可能にするのと同様に、Edgeを使用する際にWindowsデバイス間でパスキーを同期できます。これはWindowsのパスキー機能における重要な進歩を表していますが、Windows Helloプラットフォームのオーセンティケーターではなく、Edgeブラウザに固有のものです。Windows Helloパスキーはデバイスバウンドのままですが、プラットフォームのオーセンティケーター自体が将来的に同期をサポートするように進化する可能性がある一方で、このEdgeの統合はWindows上での同期パスキーへの実用的な道を提供します。

一方でGoogleは、発見不可能なパスキーに関する明確なスタンスを表明しており、既存の発見不可能なパスキーは将来の実装においても同期されないままであり得ると示唆しています。この決定は、発見不可能なクレデンシャルが厳密にデバイスバウンドのまま留まることで特定のセキュリティコンテキストにおいて重要な役割を果たし、発見可能ではないためパスキーとして使用できないという、より広い原則に沿ったものです。

対照的に、AppleがmacOSやiOSで採用しているアプローチは大きく異なります。WindowsやGoogleの発見不可能なキーに見られる固定されたデバイスバウンドの戦略とは異なり、Appleのエコシステムは、特にiOSで同期パスキーのみを許可する方向に強く傾いており、そのためWebAuthn経由でデバイスバウンド・パスキーを作成することは不可能です。

主要プラットフォーム間でのこうした戦略の細分化は、特にセキュリティ、利便性、ユーザーのアクセシビリティのバランスを考慮した場合の、WebAuthnクレデンシャル管理に対する多様なアプローチを説明しています。デバイスバウンド・パスキーは、クレデンシャルが意図されたデバイス以外に移動されたり悪用されたりしないことを保証することで高レベルのセキュリティを提供しますが、業界は進化を続け、ユーザー体験と機動性を損なうことなくセキュリティ基準を維持するソリューションを模索しています。

3.2 同期パスキー（マルチデバイス・パスキー）とは何か？#

ここでも、技術的な詳細を分析する前に、同期パスキーの歴史的な発展を見ていきます。同期パスキーは、**同期可能パスキー（syncable passkeys）**と呼ばれることもあります。

3.2.1 同期パスキーの歴史#

2021年中頃から後半にかけてのWebAuthn Level 2とCTAP 2.1仕様の公開に続き、WebAuthnワーキンググループは、パスワードを置き換え、普及を促進する上でのWebAuthn標準の能力を妨げている主な障害を克服することを目的とした重要な業界イニシアチブを立ち上げました。このイニシアチブは、既存の標準との完全な下位互換性を保ちながら、追加のハードウェア・セキュリティデバイスの要件を排除すること、およびオーセンティケーターの紛失に関連するリスクを軽減することの2つの重要な領域に焦点を当てていました。

3.2.1.1 セキュアハードウェアモジュールとしてのプラットフォーム・オーセンティケーターの利用#

第一の課題である「新しいハードウェアの必要性の排除」は、最新の消費者向けデバイスに組み込まれたプラットフォーム・オーセンティケーター（例: Touch ID、Face ID、Windows Hello）の利用によって解決されました。

最新のデバイスは、Android上のTrusted Execution Environment（TEE）、iOSおよびmacOS上のSecure Enclave、Windowsデバイス上のTrusted Platform Module（TPM）など、特化したセキュリティ・モジュールをますます搭載するようになっています。これらの不可欠なセキュリティ・キーストアは、パスキーの堅牢な基盤として機能し、効果的に組み込みの「セキュリティキー」として機能します。このアプローチにより、以前は外部のハードウェア・セキュリティキー（例: YubiKey）を通じてのみ達成可能で、テクノロジーに精通した個人や高度に規制された業界内の組織に大部分が制限されていたレベルのセキュリティである公開鍵暗号の広範な採用が可能になります。

TEE、Secure Enclave、またはTPMの機能を活用することで、WebAuthnプロトコルは強力で暗号学的なユーザー認証メカニズムを提供する力を得ます。今や、追加の専用ハードウェアを必要とせず、洗練された認証方法が一般の人々にとってユーザーフレンドリーでアクセスしやすいものになっています。

この進化は、デジタルセキュリティのアプローチにおける非常に強力な改善であり、ユーザー中心のセキュリティソリューションが広範な採用を促進する上で果たす重要な役割を強調しています。同期パスキーを最適化されたパスキーの作成やパスキーでのログインフローと組み合わせている組織は、最も高い採用率を示しています。最新デバイスのセキュリティ機能を使用することで、業界の取り組みは外部ハードウェアの必要性を排除するという初期のハードルを見事に解決しました。

この発展はデジタル認証エコシステムの新しい時代における重要なステップであり、そこでは公開鍵暗号の幅広い適用が幅広いユースケースに直接適用可能になると同時に、ユーザーの認証が簡素化されます。

3.2.1.2 パスキーのクラウドへの同期#

携帯電話の紛失、ひいてはその中に保存されたパスキーの紛失に関連するリスクに対処するために、業界イニシアチブは発見可能なクレデンシャルのクラウドへの同期を可能にすることに焦点を当てました。このアプローチは事実上、クレデンシャルを厳密なデバイスバウンドからマルチデバイスへ、より正確には、Appleデバイス用のiCloudやAndroidデバイス用のGoogleといったユーザーのクラウドプロバイダーアカウントにバインドされたものへと変貌させました。

この実用的な解決策は、ユーザーが携帯電話を紛失したり交換したりしても、以前に確立されたクレデンシャルが永久に失われるわけではないことを意味しました。代わりに、これらのクレデンシャルはユーザーのクラウド・アカウントから取得され、新しいデバイスに同期されるようになりました。この移行により、物理的なオーセンティケーターの紛失に以前は関連していた不便さとセキュリティリスクが大幅に軽減されました。

クラウド同期を活用することで、パスキーはユーザーのデバイス間でシームレスに移行できるようになり、使用中の特定のデバイスに関係なく、その完全性とセキュリティが維持されます。例えば、ユーザーが新しいデバイスからWebサイトにログインする際、クラウドアカウントで利用可能なクレデンシャルが認証のために自動提案されるようになりました。必要に応じて、これらのクレデンシャルは新しいデバイスに送信でき、異なるプラットフォームやデバイス間で一貫した安全な認証体験を維持します。

このクラウド同期されたアカウント・バウンドのクレデンシャルへの移行は、デジタルセキュリティに対する実用的なアプローチを表しています。これは最新のデバイス使用の現実と、紛失、破損、またはアップグレードによるデバイスの交換が日常的に発生することを認識しています。クレデンシャルをユーザーのクラウド・アカウント（AppleのiCloudであれGoogleのクラウドサービスであれ）に紐付けることで、このソリューションはデバイスの紛失に伴うリスクを軽減するだけでなく、複数のデバイスにわたってデジタルアイデンティティを管理・復元するユーザーの能力を向上させます。

この発展は実質的に、WebAuthnの強力な暗号化認証メカニズムの適用範囲を広げ、現実世界のユーザーのシナリオにさらに適応できるようにします。また、強力な認証が、技術的背景を持つ人や高度に規制された業界の人だけでなく、複数のデバイスでデジタル世界をナビゲートする一般ユーザーにとってもアクセスしやすく管理可能であることを保証します。

3.2.2 同期パスキーの技術的詳細#

同期パスキーは、発見可能なクレデンシャル（discoverable credentials）またはレジデントキー（resident keys）としても知られています。これらは、2つの重要なプロパティisBackupEligibleとisBackedUpが異なる値を持つことで、デバイスバウンド・キーと区別されます。同期パスキーの場合、isBackupEligibleフラグは1に設定され、これらのクレデンシャルがバックアップの対象であることを示します。クラウドへの同期が成功すると、isBackedUpフラグも1に設定され、クレデンシャルが適切に同期されたことが確認されます。同期のステータスは、デバイスの使用や管理の動的な性質を反映して、時間の経過とともに変化する可能性があることに注意することが重要です。

プラットフォームがレジデントキーを要求する際、"requireResidentKey"パラメーターをrequiredまたはpreferredに設定することにより、クラウドサービスをサポートするプラットフォームは自動的に同期パスキーを作成します。このプロセスは、ユーザーが様々なデバイス間でクレデンシャルにアクセスできることを保証します。Windowsでは、同期パスキーは現在Microsoft Edge/Microsoftパスワードマネージャー（ブラウザレベルの同期）を通じて利用可能ですが、Windows Helloプラットフォーム・オーセンティケーターのクレデンシャルはデバイスバウンドのままです。パスキー管理機能を備えたサードパーティ製パスワードマネージャー（例: Dashlane、KeePassXC、1Password）もプラットフォーム間での同期を提供しています。同期パスキーが使用されるシナリオでは、isBackupEligibleとisBackedUpのフラグは1に設定され、バックアップの適格性と成功した同期を示します。

さらに、パスキーが保存されている特定のオーセンティケーターを特定することは現在でも可能ですが、これらのクレデンシャルの大部分に対するアテステーションがないことは、その出所を暗号学的に検証できないことを意味します。この側面は、WebAuthnの標準メカニズムのみを通じて同期パスキーのセキュリティ系統を保証する際の潜在的な制限を浮き彫りにしています。

同期パスキーのこの発展は、本質的に、発見可能なクレデンシャルをクラウドベースの同期フレームワークに統合することによって、その範囲を広げます。これらのキーをバックアップ適格にし、ユーザーのデバイス間での同期を保証することで、WebAuthnはデジタル認証における2つの主な課題、すなわちデバイス紛失によるアクセス喪失のリスクと、複数のデバイスバウンド・クレデンシャルを管理する不便さに対処しています。

3.3 より大きな利益のために犠牲になったWebAuthnクレデンシャルの単一デバイス・バインディング#

デバイスバウンド・パスキーから同期パスキーへの移行は、WebAuthnワーキンググループ内で、高度なセキュリティ対策の必要性、関連する法的な問題、そして消費者にとって使いやすく安全な妥協点に焦点を当てた重要な対話を開始させました。

同期パスキーの採用は、クラウド同期やシームレスなマルチデバイス機能といった機能を通じてユーザーの利便性とセキュリティを向上させるという約束のもと称賛されました。しかし、それは一部のリライング・パーティ（RP）の間で、特に要件の厳しい環境におけるセキュリティやコンプライアンスへの影響に関して、ある種の不安をもたらしました。議論の本質は、同期パスキーでさえも特定のデバイスへの接続を保持することを保証するメカニズムの必要性でした。これは、機密性の高いトランザクションを扱ったり、厳格な規制基準の下で運用したりするリライング・パーティにとって不可欠な概念です。

パスキーを採用できない、または採用する意志のないRPにとって、重要なアプリケーションでこれらのクレデンシャルを特定のデバイスにバインドするための信頼できる方法がないことは、重大な課題となりました。このようなメカニズムは一部のRPによって非常に重要視されていました。このデバイス・バインディング機能の欠如は、おそらく明示的には述べられていなかったものの確実に期待されていたものであり、彼らの視点からは深刻な驚きと信頼の裏切りを意味していました。

議論は、利益の調和が図られるべきであるが、最初はパスキーを普及させるというより大きな利益が優先されるべきである、と結論づけられました。議論の中で、devicePubKey拡張機能はそうした懸念に対処するための一つの方法と見なされていましたが、後に、現在のWebAuthn Level 3ドラフトへのより広範なアプローチを取るsupplementalPubKeysに置き換えられました。残念ながら、このアプローチも2024年8月に中止されました。

3.4 2つの世界の長所: パスキーとsupplementalPubKeys拡張機能 [2024年8月をもって非推奨]#

supplementalPubKeys拡張機能による妥協がどのように形成されたか、そしてそれが技術的に何を意味するのかを分析しましょう。

3.4.1 devicePubKeyからsupplementalPubKeys拡張機能へ#

devicePubKey拡張機能からsupplementalPubKeys拡張機能への移行をめぐる議論は、WebAuthn仕様の動的な性質を強調しています。当初、devicePubKeyはデバイスバウンドの公開鍵によるセキュリティ向上に役立っていましたが、後にWebAuthn Level 3 エディターズ・ワーキング・ドラフトにおけるsupplementalPubKeysの提案に置き換えられました。この新しい拡張機能は、認証プロセスを強化するための複数の鍵を許可することで、より包括的なソリューションを提供します。

議論の核心は、強化されたセキュリティ対策と、様々なデバイスやプラットフォーム間でのパスキーの広範な採用および実用的な有用性とのバランスを取ることに集中しました。supplementalPubKeys拡張機能はこれらの優先順位の組み合わせを表しており、より厳密な認証を可能にします。例えば、アテステーション・ステートメントを持つ追加の「サブキー」を許可することで、特定の認証基準を要求する規制に対応します。これらの鍵は認証要件への準拠を示すことができ、（パスキーであっても）特定の条件下での追加のサインイン・チャレンジの必要性を潜在的に減らすことができます。

WebAuthnのドラフトからの直接の例:

「あるWebサイトに、このユーザーアカウントで以前に見られたことのないジオロケーションシグナルと共にサインイン要求が現れ、それがアカウントで観察される通常の利用時間外であるとします。マルチデバイス・クレデンシャルによるアサーションだけでは、その要求を許可するにはリスクが高すぎるとみなされるかもしれません。しかし、デバイスバウンドであり、かつこのユーザーについて十分に確立されている補完的なキーからの署名も提示されれば、それが状況を有利に傾けるかもしれません。」

議論の中で、これらはセキュリティ要件が極めて高いRP（例: 公共部門のコンテキスト）のみを対象としていることが強調されました。

フィードバックを取り入れ、特定のユースケース（規制された金融取引やマルチデバイス・クレデンシャル環境におけるデバイスバウンドのシグナルの必要性も含む）に対処することで、WebAuthnコミュニティはセキュリティと相互運用性の両方の懸念に対処することを目指しました。したがって、supplementalPubKeys拡張機能は、堅牢なセキュリティ機能を提供すると同時に、パスキーの広範な普及に不可欠なシームレスなユーザー体験と幅広い互換性をサポートしようとするアプローチです。これは完全にオプションの拡張機能であり、過去2年間にすでに見られたパスキーの実装を妨げるものではありません。

より包括的で柔軟なフレームワークへのこの進化は、より厳しいユースケースであってもWeb認証方法を改善するというWebAuthnコミュニティのコミットメントを強調しています。

3.4.2 supplementalPubKeysの技術的詳細#

WebAuthnで導入されたsupplementalPubKeys拡張機能により、プライマリのクレデンシャルと並行して追加のキーペアを使用することができます。

元のGitHubイシューより引用

画像は元のGitHubイシューからのsupplementalPubKeyの概念を示しています（pk = パスキー、pspk = プロバイダー・サプリメンタルキー、dspk = デバイス・サプリメンタルキー）。

その仕組みと意図された用途の内訳は以下の通りです:

supplementalPubKeyの目的と機能

• 一つの中心的なパスキークレデンシャルが残る: ユーザー認証の主な方法としては依然として一つの中心的なパスキーのみが残り、追加の鍵がセキュリティと保証の追加レイヤーを提供することを覚えておくことが重要です。この構造は、複数のデバイス間での認証に単一のコアなパスキーを使用するシンプルさと効率性を維持し、シームレスなユーザー体験を保証します。一方、補完的な鍵は認証コンテキストを強化する役割を果たし、リライング・パーティ（RP）にセキュリティ環境や特定の認証基準への準拠に関する追加のシグナルを提供します。これらの補完的な鍵は独立した認証方法ではなく、プライマリのパスキーを補強し、デバイスの完全性の証拠によってその信頼性を高めます。
• デバイスバウンド・キー: これらは特定の1つのデバイスに特有に紐付いています。これらは、認証要求が以前に認証された信頼できるデバイスから来ているという保証を提供できます。いかなる状況下でも同期されることはありません。
• プロバイダーバウンド・キー: これらの鍵は「プロバイダー」スコープを持ち、認証プロバイダーのポリシーやプロバイダーの特定のアテステーションに基づく追加の保証を提供できることを意味します。例えば、プロバイダーは、ユーザーがより高いレベルの認証（2FAなど）を完了した後にのみ、そのような鍵を発行するかもしれません。
• 複数の公開鍵: 1つのデバイスバウンド公開鍵のみを許可していた前身のdevicePubKey拡張機能とは異なり、supplementalPubKeysは1つまたは2つの補完的なキータイプの包含を可能にします。これらの鍵は、デバイスバウンドおよびプロバイダーバウンドのスコープという、異なる目的とスコープに役立つことができます。

supplementalPubKeyのユースケースと例

1. 強化されたセキュリティ: Webサイト（リライング・パーティ）が認証の特定の強化されたセキュリティ基準を遵守しなければならない状況では、これらの要件を満たすために補完的な鍵を使用できます。この補完的な鍵が過去にサイトによって確認・検証されていれば、デバイスの連続性が過去のシグナルによって確認できるため、ユーザーは追加のサインイン・チャレンジをバイパスできる可能性があります。
2. リスク管理: リスクが高いと思われるサインイン要求（例: 新しい位置情報からのアクセスや通常と異なる時間帯）に対して、ユーザーのアカウントで使用された履歴を持つデバイスバウンドの補完的な鍵が存在することで、認識されるリスクが軽減され、他の方法ではブロックされていたかもしれない要求を続行させることができます。

supplementalPubKeyの技術的側面

• 独自のクレデンシャルIDがない: 補完的な鍵はユーザー・クレデンシャルではなく、独自のクレデンシャルIDを持ちません。
• アテステーション・ステートメント: 補完的な鍵はオプションでアテステーションを持つことができます。これらは、補完的な鍵のスコープとセキュリティレベルを理解する上で不可欠です。アテステーションは、ハードウェアバウンドの鍵が享受する保護レベル、または他のタイプの補完的な鍵のポリシーを示すことができます。
• リライング・パーティ向けの実装: リライング・パーティは、認証プロセスの一環としてこれらの補完的な鍵を要求できます。しかし、複数の鍵とアテステーション・ステートメントを扱う複雑さは、この拡張機能が銀行や厳格な規制要件の下で運営されるサービスなど、特定のセキュリティニーズを持つ事業体に最適であることを意味します。

2024年4月現在、supplementalPubKeys拡張機能はいかなる主要ブラウザにも採用されておらず、WebAuthn Level 3仕様は依然として開発中であり、変更される可能性があることに注意することが重要です。この機能が仕様の最終バージョンに含まれるかどうか、およびその潜在的な将来の実装と採用については、現在エディターズ・ドラフトの段階にすぎないため、不確実なままです。

3.4.3 2024年8月のsupplementalPubKeysの非推奨化#

2024年8月の時点で、supplementalPubKeys拡張機能は公式に中止されました。WebAuthnワーキンググループは、サポートが不十分であることを理由にこの機能の削除を決定しました。この拡張機能の非推奨化はまた、新しい方向性を浮き彫りにしています。現在、FIDOアライアンスは、セキュリティ要件の高いリライング・パーティをサポートするための異なるアプローチの開発に取り組んでいます。この今後予定されているソリューションは、supplementalPubKeysの中止によって残されたギャップに対処し、厳格なセキュリティ基準が重要となるシナリオで認証プロセスを強化する新しい方法を提供することが期待されています。

非推奨化に関する詳細については、公式のWebAuthn GitHub プルリクエストを参照してください。

4. Corbadoがデバイスバウンド vs. 同期パスキーの違いを実践でどのように扱うか#

デバイスバウンド・パスキーと同期パスキーの違いを理解することは不可欠ですが、銀行にはこれらの違いを大規模に運用するためのツールも必要です。Corbadoのプラットフォームは、パスキーの種類を自動的に分類し、それぞれに適切なSCA処理を適用するデバイス・トラスト・インテリジェンスを提供します。

パスキーの種類をまたいだデバイストラストの可視性#

Corbadoのデバイス・トラスト・ダッシュボードは、デバイスバウンド・パスキーと同期パスキーが本番環境でどのように異なるパフォーマンスを示すかを示しています。デバイスバウンド・パスキーは、ステップアップ要件ゼロでより高い成功率（99.1%）を達成する一方、デバイス・トラスト・シグナルを持つ同期パスキーは、新しいデバイスに対するわずかなステップアップ率で98.4%に達します。

ダッシュボードはデバイスの分類も追跡し、単一のユーザー専用のデバイス（典型的な銀行業務の展開で92%）、2人のユーザー間で共有されているデバイス（7%）、および共有/キオスク・デバイス（0.8%）を特定します。この分類は、SCAコンプライアンスの意思決定に直接反映されます。

異なるパスキーシナリオに対するポリシーベースの制御#

すべてのパスキーを同じように扱うのではなく、Corbadoのトラストポリシーにより、銀行はパスキーの種類、デバイスのステータス、および信頼レベルに基づいて異なるルールを適用できます。既知のデバイス上のデバイスバウンド・パスキーは摩擦のない認証を得る一方で、新しいデバイス上の同期パスキーはステップアップ検証をトリガーします。これはまさに、PSD2のSCAフレームワークが要求するニュアンスのあるアプローチです。

つまり、高セキュリティシナリオ向けにデバイスバウンド・パスキーが提供する厳密なデバイス制御を維持しながら、ユーザー体験を向上させるために銀行は同期パスキーを自信を持って展開できるということです。そして、これらはすべて、別々の認証フローではなく、ポリシー構成を通じて管理されます。

Corbadoについて

Corbadoは、大規模なconsumer認証を運用するCIAMチームのためのPasskey Intelligence Platformです。IDPのログや一般的なanalyticsツールでは見えないものを可視化します。どのデバイス、OSバージョン、ブラウザ、credential managerがpasskeyに対応しているか、なぜ登録がログインにつながらないのか、WebAuthnフローのどこで失敗するか、OSやブラウザのアップデートがいつ静かにログインを壊すか — Okta、Auth0、Ping、Cognito、あるいは自社IDPを置き換えることなく、すべてを把握できます。2つのプロダクト：Corbado Observeは passkeyとその他あらゆるログイン方式のobservabilityを提供します。Corbado Connectは analytics内蔵のmanaged passkeyを追加します（既存のIDPと併用）。VicRoadsはCorbadoで500万人超のユーザーにpasskeyを提供しています（passkey有効化率+80%）。 Passkeyエキスパートに相談する →

よくある質問#

デバイスバウンド・パスキーはどのようにセキュリティを強化しますか？#

デバイスバウンド・パスキーは、作成されたデバイスに厳格に紐付くWebAuthnクレデンシャルです。同期パスキーとは異なり、単一のデバイスに留まるため、特定のユースケースにおいて本質的に高い安全性を持ちます。

• クレデンシャル盗難の防止: 秘密鍵がデバイスから離れることはないため、攻撃者がクレデンシャルを傍受することはできません。
• 不正アクセスの防止: パスキーが作成された特定のデバイスからのみ認証が行われます。
• クラウドへの依存なし: クラウドのデータ漏洩やアカウント乗っ取りに関連するリスクを排除します。
• 高度なセキュリティ・コンプライアンス: 金融サービスのような規制産業における、厳格なデバイスバウンド認証要件（AAL3）を満たします。

主な欠点は、ポータビリティが限られていることです。デバイスを紛失した場合、別のデバイスで新しいパスキーを登録しない限り、パスキーを復元することはできません。

同期パスキーが導入された理由とその利点は何ですか？#

同期パスキー（マルチデバイス・パスキー）は、デバイスバウンド・パスキーのユーザビリティの課題、特にポータビリティの欠如やデバイス紛失時のアカウントからの締め出し（ロックアウト）の可能性を解決するために導入されました。主な利点は以下の通りです:

• マルチデバイス認証: デバイスごとに新しいパスキーを手動で登録することなく、複数のデバイスからアカウントにアクセスできます。
• アクセス喪失リスクの排除: クレデンシャルはクラウド（例: iCloudキーチェーン、Googleパスワードマネージャー）にバックアップされるため、デバイス紛失時でも復元が保証されます。
• UXの向上: クレデンシャルの手動転送や再作成の必要性を排除し、摩擦をなくします。
• 追加ハードウェア不要: ハードウェア・セキュリティキーとは異なり、同期パスキーは内蔵のデバイス・セキュリティモジュールを利用します。
• クラウドの利便性と強力なセキュリティ: エンドツーエンド暗号化により、秘密鍵が暗号化されていない形式でデバイスから離れることは決してありません。

5. 結論#

全4回のシリーズの第1部では、デバイスバウンド・パスキーと同期パスキーの歴史的および技術的な違いについて分析しました。これらの違いを理解することは、PSD2とSCAの要件を適切に適用するのに役立ちます。また、進化を続けるWebAuthn Level 3標準の最新の変更点を考察することで、将来何がもたらされる可能性があるかについても見てきました。

シリーズの他のパートへのリンクはこちらです:

• 第2部「PSD2およびSCA要件の分析 (SCAとパスキー 第2部)」
• 第3部「SCA要件がパスキーに意味するもの (SCAとパスキー 第3部)」
• 第4部「パスキーに対するPSD3 / PSRの影響 (SCAとパスキー 第4部)」