ID・パスワードの漏えいや使い回しによる不正ログインが後を絶たない中、パスワードに代わる認証方式として「パスキー」への関心が高まっています。Apple、Google、Microsoft の3社が OS や Web ブラウザでパスキーを標準サポートし、国内でも通信大手や主要 IT サービスでの採用を皮切りに金融機関へも導入が広がっています。一方で、「便利なのは分かるが、なぜ安全なのか」「パスワードはなくなるのか」といった疑問を持つ人は少なくありません。この記事では、パスキーの基本と安全性の仕組みを解説します。
● パスワードに代わって端末の認証鍵で署名ログイン
パスキーは、パスワードの代わりに使う認証情報です。ユーザーが覚えて入力する文字列ではなく、「サービスごとに作成される暗号鍵を始めとする認証情報」が実態です。秘密鍵はユーザーの端末の安全な領域に保管され、サーバー側には漏えいして悪用されるような秘密情報は保管されません。
ログイン時には、まずサーバーから認証要求がユーザーの端末に送られます。端末は、生体認証などの端末機能でユーザー本人を確認できた時だけ端末の鍵を使って認証要求に署名し、その結果をサーバーに返します。サーバーは返された署名が正しいかを検証します。この要求と署名はログインごとに毎回異なるため、攻撃者が過去の通信内容を盗み取っても、別のログインに悪用することはできません。
従来のパスワード認証では、サーバー側に認証のための情報（パスワードやそれを照合するためのデータ）が保管されているため、漏えいすると不正ログインに悪用される恐れがあります。一方、パスキーでは、サーバー側に悪用できる秘密情報は保管されないため、漏えいしても悪用できる情報はありません。また、パスキーはサービスごとに別の鍵を作るので、使い回しも起こりません。
● 接続先を確認してフィッシングに対抗
パスキーは、フィッシング詐欺にも強い認証方式です。サイトごとにパスキーを作り、ログインのたびに、接続先のサイト（実質的にはドメイン名）を確認する仕組みを持つからです。この仕組みを「オリジンバインディング」と呼びます。
パスキーを登録する時は、サイトのサーバーが、自社のドメインを「この鍵の管理ドメイン（RP ID）」として端末に伝え、端末は秘密鍵と RP ID をセットで保管します。
ログインする時は、基本的な仕組みに加え、Web ブラウザが今接続しているサイトの接続先を確認します。Web ブラウザは、サーバーからの認証要求（チャレンジ）と現在の接続先をまとめたデータを準備し、端末の認証器がその秘密鍵を使って署名します。一方サーバーは、署名が正しいかを確認することに加え、署名に含まれる接続先が自社のものかを検証します。
つまり、Web ブラウザは「パスキーを登録したサイトと、今の接続先が一致するか」を確認します。サーバーは「署名に含まれる接続先が、自社のものか」を確認します。この2段階の確認があるため、ユーザーが偽サイトを見抜けなくても、偽サイトではログインが成立しません。
例えば、ユーザーが偽サイトの fake.com を開いても、端末には fake.com 用のパスキーがありません。パスキーの選択画面すら出ず、ログインできません。
巧妙な攻撃として、攻撃者が、ユーザーと正規サイトの bank.com の間に入って通信を中継する中間者攻撃があります。攻撃者は、ユーザーの操作をリアルタイムで bank.com に転送し、ログインを試みます。この攻撃も、2段階の確認で止まります。1段階目は Web ブラウザです。ユーザーは fake.com に接続しているので、Web ブラウザは、bank.com 用のパスキーを使わせません。2段階目はサーバーです。仮に署名を作れても、署名には fake.com が含まれているため、bank.com のサーバーは認証を拒否します。
● 端末ごとにパスキーを保有、複数端末間での同期も可能
パスキーは、端末ごとに持つ必要があります。秘密鍵は端末の安全な領域に保管し、端末の外には出さないのが基本だからです。新しい端末にはパスキーがないので、そのままではログインできません。つまり、端末ごとにパスキーを登録する必要があります。
ただ、端末を買い替えるたびに、すべてのサービスで登録し直すのは負担になります。そこで、パスキーをクラウド経由で、同じアカウントを使う他の端末にコピーし、どの端末でも使えるようにする仕組みがあります。この仕組みで複製するパスキーを「同期パスキー」と呼びます。
同期パスキーは、Apple、Google、Microsoft の3社が、それぞれ OS の標準機能として提供しています。1Password のようなパスワード管理ツールも、異なる OS 間でパスキーを同期できます。一般的な Web サイト（コンシューマー向けサービス等）側からは、どのクラウドやツールで同期されているかを厳密に区別・制限することは難しいため、どの環境の同期パスキーでも受け入れられるのが基本です。
一方、「デバイス固定型パスキー」は、秘密鍵を端末の外に出せない仕組みです。複数の端末にコピーできないため利便性は下がりますが、クラウドから鍵が漏れるリスクがなく、セキュリティは高くなります。セキュリティキーと呼ぶ専用のハードウェアに鍵を保管する方法もあります。
一般的に、消費者向けのサービスでは同期パスキーを使うケースが多くなっています。これに対し、社員が仕事のために使う業務システムなどは、企業が端末を管理でき、セキュリティキーも配布できることから、デバイス固定型パスキーが主流です。
パスキーを運用するうえでのベストプラクティスは、1つのサービスに複数の端末からパスキーを登録しておくことです。例えば、スマートフォンとパソコンの両方で登録しておけば、スマートフォンを紛失しても、パソコンでログインできます。
● パスキーが認証の中心へ
パスキーは、今後の認証方法の中心になると考えられます。Apple、Google、Microsoft の3社が普及を牽引し、主要な OS や Web ブラウザが標準でサポートしています。現時点では、セキュリティと利便性を両立する最も優れた認証方法の一つです。
国内では、通信大手や EC、ポータルサイトといった主要 IT サービスがいち早く導入を進めてきましたが、近年は金融分野への広がりも加速しています。金融庁が証券会社や銀行などの金融機関に対し、ログインなどの重要操作においてパスキーをはじめとするフィッシング耐性のある多要素認証の実装を求めていることも、この流れを後押ししています。
もちろん、パスキーにもリスクは存在します。攻撃者がクラウドのアカウントを乗っ取れば同期パスキーが悪用される恐れがあります。実際、パスキー自体は突破されずとも、Apple や Google のアカウントがフィッシング詐欺等で乗っ取られたことで、同期されていたパスキーを悪用されて不正アクセスを受けるといった被害も報告されています。
そのため、パスキーを利用するサービスだけでなく、パスキーを同期・管理している Google や Apple といった大元のクラウド側のアカウントにもパスキーを設定しておくことが極めて重要です。あわせて、アカウント復旧時に使われるバックアップ用コードや端末のパスコードを厳重に管理・退避しておくなど、土台となるプラットフォーム自体の防御力を高めておく必要があります。
また、パスキーが守るのは認証の瞬間だけであり、ユーザーを騙して生体認証を行わせるソーシャルエンジニアリングや、端末へのマルウェア感染、ログイン成功後のセッション情報（Cookie など）を盗み出す攻撃等によって、アカウントを不正利用されるリスクが残ります。
認証のその瞬間だけでなく、登録時の本人確認、認証後のセッション保護、検知の仕組みの検討等、パスキーを導入して終わりではなく認証のライフサイクルを通じた対策が必要になってきます。
さらに現在は、従来のパスワードとパスキーが併存する過渡期である点も課題です。パスワードでもログインできる状態が残っていると、攻撃者はフィッシング詐欺などで盗んだパスワードを悪用してログインし、勝手に攻撃者自身のパスキーを追加・登録してしまいます。こうなると、ユーザーが後からパスワードを変更しても攻撃者のアクセスを遮断できません。そのため、最終的にはパスワードを廃止し、パスキー1本に絞る方向で議論が進んでいます。
こうした過渡期のアカウント乗っ取りや不正登録への対策として、業務システムであれば、会社が管理する端末やセキュリティキーからの登録のみに限定する手法等が取られます。また、一般向けのサービスでは、新規登録や復旧の際にオンラインで公的身分証等を確認する eKYC を組み合わせるなど、多層的な防御が求められています。
● 課題はユーザーの理解とアカウント復旧方法
パスキー普及の最大の壁となるのは、使い勝手とユーザーの受容性です。従来の「パスワードを記憶して入力する」体験に慣れたユーザーに対して、「パスワードをなくす」という新しい概念を理解してもらえなければ、「仕組みがよく分からない」と導入を敬遠されてしまう恐れがあります。
もう1つの大きな壁は、端末の紛失や機種変更時のアカウント復旧（リカバリー）です。同じエコシステム内であればクラウド経由で自動同期されますが、異なる OS へ乗り換えた場合や、1台のデバイス固定型キーしか持っていない状態で端末を紛失した場合は、パスキー以外の手段でアカウントを復旧せざるを得ません。
アカウント復旧時の本人確認手段としては、マイナンバーカード等を活用した公的身元確認（eKYC）や、通信キャリアが保有する契約者確認済みの回線情報を API 経由で照合する仕組みなど、各社で自社のユースケースに合わせた多様な手法が検討されています。
また、メールを使った復旧ではワンタイムパスワードの盗聴や手入力の煩雑さが課題となりますが、現在は「Email Verification Protocol（EVP）」のように、ブラウザとメールサービスが連携して安全にアドレスの所有権を検証し、コード入力を不要にする次世代プロトコルの標準化検証も進められています。
パスキーは、接続先を検証してフィッシングを防ぐ極めて強力な認証方式です。今後の普及と完全なパスワードレス化の実現に向けては、既存の認証手段をどう段階的に廃止していくか、そして万が一の復旧手段をいかに安全かつ分かりやすく設計できるかという運用面の課題解決が鍵となります。
