💡

パスキーの“理論上の安全”と“運用上の課題” — 過渡期に見えてくるリスクと対策

に公開
DX
login
pki
certificate
Passkey (パスキー)
idea

パスワードレス認証の代表格であるパスキー（Passkey）が、各業界で採用段階に入っている。楽天証券では、2025年10月26日頃にパスキー対応を開始しており、導入事例として話題になっている。
https://www.rakuten-sec.co.jp/web/security/passkey/
一方でパスキーについては運用方法によるいくつかの課題点も残っている。
本稿では、パスキーの技術的特長を前提に、実務運用における課題とコスト面の注意点を整理する。

1. パスキーの“理論上の安全性“

パスキーは、FIDO2 / WebAuthnという国際水準に基づく公開鍵暗号方式による認証モデルである。
従来のパスワード認証との違いは明確であり、理論上の安全性も高い。

鍵ペア生成と登録の流れ

  1. 鍵ペア生成
  • ユーザ端末で秘密鍵（Private Key）と公開鍵（Public Key）を生成
  • 秘密鍵は端末内のセキュア領域（Secure Enclave、TPMなど）に保存され、外部には出ない
  1. 公開鍵登録
  • サーバには公開鍵のみを登録
  • サーバ側で秘密情報を保持しないため、大規模漏洩のリスクが構造的に低い
  1. 認証プロセス
  • サーバがチャレンジ値（ランダム）を送信
  • 端末が秘密鍵で署名して返送
  • サーバは公開鍵で署名を検証し、本人認証を完了

技術的強み

  • 共有秘密の排除：パスワード漏洩のリスクを低減
  • フィッシング耐性：鍵ペアはサービスごとに異なり、偽サイトで認証は失敗
  • 利便性：生体認証やPINで簡単に認証完了
  • 理論上の強固さは明確であり、パスワード依存からの脱却として有効である。

2. パスキーの“運用上の課題“

パスキーは、安全性と利便性を両立した技術だが、運用上においては一定のリスクが存在する。具体的には下記の内容が挙げられる。

  1. 公開鍵登録時のリスク
  • パスキー登録や端末追加時に公開鍵をサーバに送信する工程がある。
  • 利用者が慣れないタイミングで操作すると、偽サイトや誘導により鍵ペアが不正登録される可能性がある。
  • これは技術の欠陥ではなく、運用・ユーザ行動に起因するリスクである。
  1. 認証後のセッション管理
  • パスキーは、ログイン時の安全性を担保するが、ログイン後のセッション中の安全性まで保障しない。
  • トークンの不適切管理やブラウザ拡張によるCookie窃取があれば、認証後の操作が乗っ取られる。
  • 導入時はセッション保護・異常検知・再認証設計が重要になる。
  1. 救済ルートの脆弱性
  • 端末紛失や乗り換え時に利用される救済ルート（メール、SMS、絵文字認証）は依然として攻撃対象になりうる。
  • リアルタイム・フィッシングやSIMスワップなど既知の手法で突破される可能性があるため、運用設計での補強が不可欠である。

導入・運用コストの考慮

パスキーの採用は技術的には有効でも、導入・運用に伴う負荷が存在する。

  • 実装コスト：FIDO2サーバ実装、端末・ブラウザ間挙動の検証
  • サポートコスト：端末変更や紛失時の再登録対応
  • 教育コスト：利用者向けフィッシング防止やUI案内
  • 監視コスト：移行初期のアクセス異常監視

特に金融機関では、これらを考慮した計画が不可欠である

導入時に留意すべき点

事業者では導入日を明示することで、顧客に対して安全性のアピールと事前準備の必要性を外部に公表する場合がある。一方で、こういった導入日の公表は、運用上のリスクが一時的に高まる可能性がある点に留意する必要がある。

  • パスキー導入初期においては、新規登録や乗り換えタイミングが集中し、かつユーザは新しい操作に慣れておらず、注意力が分散した状態となる。
  • そのため、攻撃者は、導入日に向けて事前に偽サイトや誘導メールを準備し、顧客にフィッシング詐欺を仕掛け、中間者攻撃によるなりすましを行う危険性が高まる（1.公開鍵登録時のリスク）。
  • また、ユーザ及びパスキー導入事業者は、パスキーの乗り換えに慣れておらず、救済措置を案内するケースが多数発生すると想定される。そのため、救済措置を狙ったフィッシング詐欺が多発する恐れがある（3.救済措置時のリスク）。

3. まとめ

パスキーは理論上、安全で利便性も高い認証技術。
ただし、問題は安全性のボトルネックが技術から運用へ移行したという点にある。特に過渡期における実務的リスクを軽視すると、

  • 利用者が偽サイトにアクセスし、
  • 運用側がリカバリ経路を過信し、
  • 監視体制が後手に回れば、結果的にシステム全体は脆弱になる。

これからの時代、技術上の安全性のみならず、運用の安全性・監視の持続性を統合した一体設計が鍵となる。

4. FPoSの紹介

最後に、当社が提供している“FPoS”技術について紹介する。当技術は、パスキーの利点を活かしつつ、運用面での課題を補完する形で設計されている。
FPoSは、下記の要素を持つ、スマートフォン向けデジタル認証技術である。

  1. JPKIによる身元確認の統一化
  • マイナンバーカードの電子署名（JPKI）によって、身元確認を安全かつ確実に実施。また、ユーザがどの手段で身元確認すべきか迷わず、誤登録・誤操作の減少に寄与。
  • マイナンバーカードの管理局（J-LIS）と常時情報を連携することで、住所変更等が起きても、同一性を確実に確認することが可能
  1. パスキーと同等以上のログイン認証手段
  • パスキー同様にPKIと端末認証を組み合わせてログインを実現。
  • ユーザ毎に電子証明書を発行することで、認証の信頼性を高め、攻撃者による鍵差替えやなりすましを抑止する。
  1. ログイン後も利便性の高い身元確認手段を提供
  • ログイン後、重要な取引を行う度に、スマホ内に格納された署名用証明書（PKI）による身元確認を実施。トークン窃取や長時間セッションによるリスクを低減可能。

また、FPoSはIDaaSサービスであり、認証用のパーツ群（スマホ用SDK、認証用API）を提供。

  • JPKIによる初期設定、ログイン認証、セッション後の身元確認機能及び画面は、スマホ用SDKが全てカバー。
  • FIDOサーバと同様の認証用サーバは、当社が構築・保守運用を委託可能。
    認証用サーバには公開鍵をはじめとしたユーザ情報を保管しないため、情報漏洩のリスク及び運用コストの削減に寄与。

FPoSの基本設計は、国の調査機関による第三者評価を年次で受けており、技術的実装と運用手順の双方がチェックされることで、継続的な安全性担保を図っている。

Discussion