近年、金融機関など狙うフィッシング攻撃が高度化しており、特に「リアルタイム・フィッシング（real-time phishing）」と呼ばれる手法が深刻な脅威となっています。このタイプの攻撃は、従来フィッシング攻撃対策として有効とされてきたワンタイムパスワード（OTP）すら無効化することが知られており、金融機関の本人確認基盤に抜本的な再設計を迫っています。
本稿では、リアルタイムフィッシングの技術的構造と、これに対抗可能な「パスキー（passkey）」の本質的な優位性を解説し、今後の政策的検討課題を提示します。
リアルタイムフィッシングとは何か
リアルタイムフィッシングは、攻撃者が「ユーザーと本物のサービスの間に割って入る（man-in-the-middle）」形で通信を中継し、ユーザーが入力した認証情報（ユーザ名、パスワード、４から６桁のワンタイムパスワード(OTP) 等）を即時に使って本人になりすます攻撃手法です。特に、OTPがSMSやアプリで配信されても、ユーザーがそれをフィッシングサイトに入力した瞬間に、攻撃者はそれを本物のサービスのWebサイトに転送してなりすましてログインができます。
この種の攻撃はman-in-the-middle(MitM)以外にも adversary-in-the-middle（AitM） や verifier impersonation とも呼ばれ、「一見本物に見える」フィッシングサイトと、本物の認証サーバーを技術的に中継する点に特徴があります。
中継サーバーによる完全な偽装
最新のリアルタイムフィッシング攻撃では、中継サーバーを使用して、以下のような巧妙な手口でユーザを騙します：
- 完全なサイト複製：本物のWebサイト（例：金融機関のWebサイト）のソースコードをリアルタイムで読み込み、視覚的に区別不可能な偽サイトを生成（なお、検査プログラムなどが来たときには全く別のものを返すように偽装して検査をすり抜ける例もあります）
- それっぽいSSL証明書の取得：正規に見えるHTTPS接続を提供
- 動的コンテンツ対応：ログイン後の個人情報表示なども完全に再現
Adversary-in-the-Middle (AitM)攻撃の仕組み
AitM攻撃は以下の技術的プロセスで実行されます：
- 中継サーバー設置：攻撃者が本物のサイトとユーザーの間に中継サーバーを配置
- 動的レスポンス生成：本物のサイトのサーバーからの応答を改ざんしてユーザーに送信
- 認証情報収集：ID、パスワード、OTP、追加の個人情報をリアルタイムで収集
- 正規アクセス実行：収集した情報で即座に本物のWebサイトにアクセス
この攻撃では、攻撃者が以下の2つの役割を同時に演じます：
- ユーザーに対しては：本物の銀行サーバーのように振る舞う（検証者偽装）
- 銀行に対しては：本物のユーザーのように振る舞う
この二重の偽装により、従来のWebサイト（認証サーバー）側とユーザー間での「共有秘密」ベースの認証方式（パスワード、OTP）は完全に無効化されます。図表1はこの関係を示しています。
（図表1）AitMの模式図
例：
- ユーザーがID・パスワード・OTPを入力
- 偽サイトがその情報を本物の認証サーバーに転送
- 認証成功、セッション乗っ取り
なぜOTPは無効になるのか
OTP（ワンタイムパスワード）は、再利用が困難なコードであることから、従来は「安全な第二要素」と見なされてきました。しかし、リアルタイムフィッシングのような「中継攻撃」においては、一度限りであっても攻撃者が本物のユーザーの代わりに使えれば攻撃が成立するため、「使い捨て」であることが無効化されてしまいます。
また、従来のOTPベースの多要素認証（MFA）は、チャレンジ・レスポンスの整合性検証（後述）やWebサイトのアドレス（ドメイン）などの検証を行わないため、入力された情報が誰に送られようとしているかをユーザー側では識別できません。これがOTPが本質的に中継攻撃に弱い理由です。
パスキー（passkey）とは何か
パスキーは、FIDO2/WebAuthn規格に基づく認証技術であり、アクセス先のWebサイトのアドレス（ドメイン）を検証してユーザー認証に必要な情報を送信する1という特性を持ちます。主な特徴は図表2の通りです。
（図表2）パスキーの特徴
| 特徴 | 説明 |
|---|---|
| 非対称鍵暗号ベース | 認証は公開鍵による署名検証で行われる。秘密鍵はアクセス先には送られない。 |
| オリジンバインディング | 認証要求は特定のドメインと結びついており、中継や偽装が困難。（オリジンチェックとRPIDチェック〜下記参照） |
| 生体認証やPINでローカル認証 | ユーザー認証はデバイス内で完結する。生体情報やPINなど、複製の恐れのある要素を利用した認証情報の外部送信なし。 |
| フィッシング耐性 | 偽サイトからのリクエストには署名しない。 |
つまり、ユーザーが誤って偽サイトにアクセスしても、認証器はそのサイトに本物のWebサイト用の署名を返さないため、攻撃者は認証に使う情報を一切取得できません。これはOTPと決定的に異なる点です。
なぜパスキーはフィッシングに強いのか？
パスキー (FIDO2/WebAuthn)が中継型フィッシング（AitM）やドメイン偽装に対して構造的な耐性を持つのは、次の3つのチェックが行われているためです：
(1) オリジンチェック（Origin Validation）
- クライアント（ブラウザ）が認証要求を発行するWebサイトのオリジン（サイトのドメイン／アドレス）を自動的に検出
- このオリジンは、https:// + ドメイン名 + ポート番号 から構成される
- Webサイトからブラウザへのパスキーによる認証要求には、サイトのドメイン（RPID（後述））が含まれるが、このドメインがオリジンと異なる場合（例: フィッシングサイト）、ブラウザは認証要求を拒否し、認証処理が行われない（サブドメインなど例外もあり）
- さらに、オリジンはパスキー認証結果に含まれ、Webサーバにも送られるため、Webサーバ側でもパスキーによる認証が正しいWebサイト上で実施されたことが検証されます。
(2) Relying Party ID（RPID）チェック
- RPIDは公開鍵登録時にサーバーが指定するドメイン識別子
- 認証器（パスキーを保持するデバイス側）が、受け取ったRPIDに紐づく鍵が自身に保存されているかを検索
- RPIDが異なれば秘密鍵は見つからず、署名が返されない
(3) チャレンジ・レスポンス
- パスキーでの認証時には、Webサーバーから「チャレンジ」と呼ばれるランダムなデータを送信
- 認証器が、チャレンジを含むデータに対して秘密鍵で署名し、パスキー認証レスポンスとしてブラウザを経由してWebサーバーに返却
- Webサーバーは、レスポンスに含まれるチャレンジが、Webサーバーから当該セッションに対して発行されたものであることを検証
- 攻撃者が任意に作成したチャレンジや、過去に利用されたことがあるチャレンジの場合には、Webサーバーは認証を拒否する
なぜこの3つが必要か？
図3はこの関係をまとめたものになります。
（図3）フィッシング耐性に必要な3要素
| 項目 | 役割 |
|---|---|
| オリジンチェック | ブラウザが実行元のWebサイトの正当性を担保。偽サイトを拒否 |
| RPIDチェック | 認証器がどのドメイン向けに登録された鍵かを確認し、誤用を防止 |
| チャレンジ・レスポンス | パスキーによる認証が現在のセッションで実施されたことを担保。認証結果の再利用を防止 |
どれか１つだけでは不十分で、 すべてが揃って初めて「完全なフィッシング耐性」が成立します。
しかしパスキーは銀の弾丸ではない
～登録フローを悪用したフィッシング攻撃のリスク～
一方、パスキーも銀の弾丸ではありません。FIDO2/WebAuthnベースのパスキー（passkey）は、従来のOTPやパスワードに比べて格段に高いフィッシング耐性を持ち、ユーザーの認証安全性を大幅に向上させる手段として評価されています。
しかしながら、「登録フロー（credential registration）」に対する攻撃耐性は、ユーザー側の判断やUX設計に依存する面があり、攻撃者が自らのパスキーを“登録”させてしまうという新たなリスクが存在します。
想定される攻撃シナリオ：攻撃者によるパスキー“なりすまし登録”
攻撃フロー例
- 攻撃者がフィッシングサイトを構築（https://bank-login.example.org）
- ユーザーに「認証が失効しました。再登録してください」などと誘導
- ユーザーがフィッシングサイトで従来の認証手段（パスワードやOTP）で認証し、パスキー登録フローを開始
- 実際には攻撃者の認証器（デバイス）が登録される
- 本物のWebサイトに「攻撃者のパスキー」が登録された状態に
- 攻撃者はそのパスキーで本物のWebサイトにログイン可能に
技術的には「正当な登録」
- 中継攻撃においては、WebAuthnの登録（navigator.credentials.create()）は、攻撃者の環境上で実施できるため、その内容は攻撃者が自由に改変可能です。そのため、Webサーバー目線では、登録自体が正当なものと区別がつきません。
- 中継攻撃においては、仮に被害者のブラウザがオリジンとしてフィッシングサイトのドメインを含めた形でパスキーの作成を実施したとしても、攻撃者はその結果を破棄し、攻撃者の環境下で正規のドメインを含めたパスキーを生成しなおせば良いので、被害者のブラウザにおけるオリジンのチェックは効果がありません。
対策
図表4は考えられる代表的な対策をまとめたものです。網羅的ではありません。
図表４ 考えられるなりすまし対策
| 対策 | 内容 |
|---|---|
| 登録前の本人確認ステップの強化 | 公的個人認証やリモートバイオメトリクス（可能なら）による本人確認や、過去に設定済みのパスキーでの再認証などを求めることで防止 |
| 異常登録の検知・通知 | 新しいパスキーが追加された際に即時通知・確認（例：ログイン履歴通知） |
想定される攻撃シナリオ：パスキー認証後のセッション乗っ取り
また、近年の事例においてはインフォスティーラーなどと総称されるようなマルウェアによるパスワードなどの窃盗が報告されています。これらは同様にセッションクッキーの取得も可能です。パスキーはユーザー認証をしてセッションを確立するまでの間の保護手段です。セッションが確立されたあとは守りません。
対策
セッション乗っ取りに対する対策としては、端末のセキュアな領域などで生成した非対称鍵を活用するDevice Bound Session Credentials (DBSC) などが提案されています。また、こうした文脈で、Continuous Access Evaluation （継続的アクセス評価）も注目を浴びるようになってきています。
Continuous Access Evaluationは、従来の一度きりの認証を超えて、ユーザーのアクセス権限をリアルタイムで継続的に監視・評価するセキュリティ手法です。ユーザーがログイン後も、位置情報、デバイス状態、行動パターン、リスクレベルなどを常時チェックし続けます。異常な活動や高リスクな状況を検知すると、自動的に追加認証を要求したり、アクセスを制限・遮断したりします。
例えば、普段と違う国からのアクセスや、異常なデータダウンロード行為があった場合に即座に対応できます。「一度認証されたら安全」という前提を捨て、常に検証し続けることでセキュリティを強化します。
想定される攻撃シナリオ：残存しているパスワード認証の口を狙う
パスキーの特徴であるフィッシング耐性の恩恵を得るためには、フィッシング耐性の無い認証方法を廃止し、パスキーのようなフィッシング耐性がある認証手段だけを利用してもらうことが必要です。たとえパスキーが導入されても、従来のフィッシング耐性の無いユーザー認証が残っていれば、ユーザーは依然としてフィッシングの標的となります。
対策
対応する対策は、こうした旧来型のユーザー認証手段を廃止してパスキーのみに切り替えるというようなことになります。
ただし、様々な要因から、パスキーを使いにくいユーザーが残っていることは留意しなければなりません。その状況のもとでパスキーを強制することは、ユーザーにサービスが忌避される理由にもなります。そのため、既存の認証方法も残した上で、そのセッションを高リスクセッションとしてAIなどで監視し続けて、異常検知で取引を止めるなどの代替策を取ることも考えられます。パスキーが利用できない環境でのログインのために一定時間（15分とか）だけパスワードによるログインを許可するようなオプションの提供や、認証強度に応じて取引限度額や権限(読み取り専用など）を設定するというのも選択肢です。こうした観点からも、上記のContinuous Access Evaluationは重要な技術として着目されています。
結論：パスキーも“設計”しなければ破られる
パスキーは認証フローにおいては非常に高い安全性を持ちますが、登録フローを悪用された場合は、逆に攻撃者に強固な鍵を登録されてしまうという本末転倒なリスクが存在します。
そのため、金融機関や政府機関がパスキーを導入する際には：
- 認証だけでなく、登録フローのセキュリティ設計
- 異常検知・復元フロー（リカバリー）設計
- フィッシングを前提としたUXデザインと警告設計
が不可欠です。したがって、採用する際にはこのようなことまで考えて設計する必要があります。
政策的含意：なぜ今、パスキーが必要か
1. OTPに依存した規制・ガイドラインの限界
多くの国・地域では、いまだにOTPを第二要素として多要素認証MFAをSCA (Secure Customer Authentication: 安全な顧客認証）要件に明記している場合があります。しかし、上記の通りOTPを使った多要素認証はフィッシング耐性を保証しません。これを前提としたセキュリティ規制は、すでに攻撃者の技術に追いついていない可能性があります。「2要素認証」などと指定するのではなく、どの「脅威」に対応すべきかを考えるべきです。実際、 ISO/IEC 29115 Entity authentication assurance framework などでは2011年2からそのようになっています。
2. 登録フェーズの脅威にも対応する必要
一方で、パスキーは認証手段の利用フェーズを強化するものであることに留意する必要があります。認証手段の登録フェーズの脅威にも対応する必要があります。
3. 多層防御の一貫
パスキーは非常に有効なユーザー認証手段ですが、ユーザー認証が成功したあとのセッション乗っ取りには無効です。したがって、セッションのデバイスへのバインディング（紐付け）や、異常取引の検知などとも組み合わせて使うことが必要です。
4. 消費者保護の観点からの普及促進
パスキーはユーザーに「セキュリティの知識」や「注意深さ」を要求せず、端末側で透明に安全性を確保できます。これは、セキュリティ教育に頼らない持続可能な対策であり、消費者保護政策と親和性が高いものです。
金融政策の観点からは、単に技術導入の可否を議論するだけではなく、何を「安全なユーザー認証」と見なすかという基準そのものを更新していくことが必要です。今後の制度設計においては、パスキーのようなフィッシング耐性を持つ手段を「基準」として据えることが、金融消費者の安全と信頼性確保の鍵となるでしょう。3
【謝辞】
本稿の執筆にあたっては、技術評論社出版になる『パスキーのすべて』の共著者で、米国OpenID Foundationの理事でもある小岩井 航介氏(X: @kocko)、野村総合研究所所属で情報処理学会 情報規格調査会SC27/WG5小委員会幹事でFIDO Alliance からISO/IEC JTC 1/SC 27/WG 5へのリエゾンオフィサーでもある古川 英明氏、『Software Design 2025年1月号』の「第1特集 認証技術の最前線パスワードレス認証「パスキー」のしくみと実装」の前半など積極的にパスキーに関して発信しておられる、いとう りょう氏（X: @ritou) に大変なご協力をいただきました。篤く御礼申し上げます。