最近、銀行、証券会社、ECサイト、会員サービスなどで「パスキーを登録してください」「パスキーでログインできます」という案内を目にする機会が増えました。
しかし、パスキーについて説明すると、多くの方から次のような質問を受けます。
これらは、どれも自然な疑問です。画面上では数秒で認証が終わるため、裏側でどれほど多くの確認が行われているのかが見えにくいからです。
パスキーは、顔認証や指紋認証そのものを指す名称ではありません。
パスキーの本質は、公開鍵と秘密鍵という2つの鍵を使い、パスワードのような秘密情報をWEBサービスへ送らずに、本人であることを証明する仕組みです。
顔認証、指紋認証、PINは、その秘密鍵を使ってよい人物かどうかを、手元の端末が確認するための方法です。
さらにパスキーでは、Chrome、Safari、Edgeなどのブラウザと、Windows、iPhone、Androidなどの端末側が、現在開いているWebサイトのドメインを確認します。正規サイト用に作られたパスキーを、見た目だけを似せた別ドメインの偽サイトから利用することはできません。
パスキーが安全なのは、顔認証の精度が高いからだけではありません。
秘密を送らない、サービスごとに異なる鍵を使う、正しいドメインであることを端末側が確認する、本人確認に成功したときだけ秘密鍵を使う。この複数の仕組みが組み合わされていることが、安全性の本質です。
このページでは、開発者向けの仕様書やプログラムコードではなく、パスキーの仕組みをもう少し深く知りたい方を対象に、普段使っているWindows、iPhone、Android、Chrome、Safari、Edgeなどの具体例と結び付けながら解説します。
パスキーを一言で説明すると、利用者の端末やパスキー管理サービスが保護している鍵を使って、WEBサービスへログインする認証方式です。
パスワード認証では、利用者が覚えている文字列を入力し、その文字列をWEBサービス側で確認します。
一方、パスキーでは、利用者が秘密の文字列を覚えたり、入力したりする必要がありません。利用者側にある秘密鍵を使って、その鍵を正しく持っていることを証明します。
| 方式 | 利用者が行うこと | サービスが確認するもの |
|---|---|---|
| パスワード | 秘密の文字列を入力する | 入力された文字列が正しいか |
| OTP | 届いた一時的な番号を入力する | 番号が正しいか |
| パスキー | 端末上で顔・指紋・PINなどを使って確認する | 登録済みの秘密鍵による正しい署名か |
顔認証や指紋認証は、WEBサービスのサーバが利用者の顔や指紋を照合するためのものではありません。
たとえば銀行サイトへパスキーでログインするとき、銀行側が利用者の顔画像を受け取り、銀行が保有する顔写真と比較しているわけではありません。
実際には、Windows、iPhone、Androidなどの手元の端末が、この端末に保存または連携されているパスキーを使ってよい人物かを確認しています。
確認に成功すると、端末側で秘密鍵を使った署名処理が許可されます。WEBサービスへ送られるのは、顔画像や指紋画像、PINそのものではなく、鍵を使って作られた認証結果です。
パスキーは生体認証そのものではないため、カメラや指紋センサーがないパソコンでも利用できます。
Windowsパソコンを例にすると、利用できる確認方法は環境によって異なります。
つまり、顔認証はパスキーを利用する手段の一つであり、必須条件ではありません。
パスキーの説明で特に多い誤解が、顔や指紋の情報がログイン先のWEBサービスへ送られているというものです。
しかし、顔認証や指紋認証の照合は、原則として利用者の端末側で行われます。
たとえば、iPhoneでFace IDを使って証券会社へログインした場合、証券会社が利用者の顔画像を受信しているわけではありません。iPhoneが端末内で本人確認を行い、その結果としてパスキーを使った署名を作成します。
WEBサービスが知る必要があるのは、顔や指紋の中身ではありません。
登録済みのパスキーを利用し、正しい認証結果が返されたかどうかを確認できればよいのです。
Windowsでは、Windows Helloが顔認証、指紋認証、PINなどを利用して、パソコンを操作している人物を確認します。
ChromeやEdgeでパスキー認証を開始すると、Windowsの本人確認画面が表示されます。そこでWindows Hello PINを入力したり、顔や指紋を認識させたりします。
このとき入力したPINは、ログイン先のWebサイトへ送られません。Microsoftやブラウザへログイン用パスワードとして送信されるものでもありません。あくまで、そのWindows端末上で秘密鍵の利用を許可するための確認です。
Apple製品では、Face ID、Touch ID、端末のパスコードを使ってパスキーの利用を許可します。
パスキーはiCloudキーチェーンやAppleの「パスワード」アプリから確認でき、同じApple Accountを利用する端末間で使える場合があります。
ただし、同期されたパスキーを別のiPhoneやMacで使う場合でも、その端末に登録されているFace ID、Touch ID、パスコードで本人確認します。顔画像や指紋画像がWebサイトへ送信されたり、別端末へコピーされたりするわけではありません。
Androidでは、Googleパスワードマネージャーなどがパスキーの保存や利用を担当します。
認証時には、Android端末の指紋認証、顔認証、PIN、パターンなど、普段の画面ロック解除に使っている方法が表示されます。
ここでも、ログイン先のWEBサービスが指紋やPINを取得するわけではありません。Android端末側で確認が完了した後に、パスキーによる署名処理が行われます。
パスキーは、Apple、Google、Microsoftの仕組みだけに保存されるとは限りません。
1Passwordなどのパスキー対応パスワードマネージャーや、USB・NFC対応のセキュリティキーに保存する構成もあります。
つまり「パスキーはスマートフォンの中にしか存在しない」というわけでもありません。利用するOS、ブラウザ、パスキープロバイダー、セキュリティキーによって、鍵を保護する場所や利用方法が変わります。
「PINは4桁なら1万通りしかないので、簡単に破られるのではないか」という疑問はもっともです。
しかし、Windows Hello PINやスマートフォンのパスコードは、Webサイトへ送るパスワードとは攻撃条件が異なります。
| 比較 | Webサイトのパスワード | 端末のPIN |
|---|---|---|
| 利用場所 | インターネット上のログイン画面 | 登録された特定の端末内 |
| 送信先 | WEBサービスへ送信される | WEBサービスへ送信されない |
| 遠隔試行 | 世界中から試行される可能性がある | 原則として端末を手元に持つ必要がある |
| 失敗制御 | サービス側の設計による | OSによる待ち時間、試行制限、ロック等が使われる |
| 使い回し | 複数サイトで同じ文字列を使い回しやすい | その端末を解除するためだけに使われる |
端末PINを使ってパスキー認証を行うには、通常は次の2つが必要です。
離れた場所にいる攻撃者が、WebサイトへPINを送り続けて総当たりすることはできません。PINの照合は、その端末のOSやセキュリティ機能の中で行われるからです。
Windows、iPhone、Androidなどでは、PINやパスコードを何度も間違えると、入力待ち時間が長くなったり、端末がロックされたり、追加の復旧手続きが必要になったりします。
このような仕組みによって、端末を盗んだ人物が短時間で何千回、何万回と自動試行することを難しくします。
PINは、桁数だけを見て安全性を判断するものではありません。
端末を持っていること、端末内だけで照合されること、失敗回数が制御されること、鍵がOSやハードウェアの保護機能と組み合わされていることを含めて評価する必要があります。
パスキーの安全性を理解するために欠かせないのが、公開鍵暗号方式です。
公開鍵暗号では、次の2つの鍵をペアで利用します。
公開鍵と秘密鍵は数学的に関係していますが、公開鍵から秘密鍵を現実的な時間で割り出すことはできません。
パスワード方式では、WEBサービスは入力されたパスワードが正しいか確認できる情報を保管します。その情報が漏えいすると、解析されたり、別のサービスへの不正ログインに使われたりする危険があります。
パスキーでは、WEBサービス側に登録される中心的な情報は公開鍵です。
公開鍵は秘密情報ではありません。公開鍵だけを取得しても、本人の秘密鍵を使った正しい署名を作ることはできません。
ログイン時に秘密鍵そのものをWEBサービスへ送ることはありません。
秘密鍵は、端末やパスキープロバイダーの管理下で使われ、WEBサービスから届いた一度限りの情報に対する署名を作ります。
WEBサービスへ返るのは署名結果です。WEBサービスは、登録済みの公開鍵を使って、その署名が正しいかを確認します。
完全に同じではありませんが、イメージをつかむために、秘密鍵を金庫の中の特別な印鑑に例えてみます。
パスワードのように、本人しか知らない合言葉を相手へ伝える仕組みではありません。
利用者から見ると、パスキーのログイン操作は非常に簡単です。
しかし、裏側ではWEBサービス、ブラウザ、OS、認証器が連携し、複数の確認を行っています。
ログインが始まると、WEBサービスはランダムな一度限りの情報を生成し、ブラウザへ送ります。
この一度限りの問題を、パスキーの技術用語ではChallenge（チャレンジ）と呼びます。
毎回違うChallengeを使うことで、以前の認証結果を保存しておき、後からそのまま再利用する攻撃を防ぎます。
Chrome、Safari、Edgeなどのブラウザは、WEBサービスから受け取った認証要求を、Windows Hello、iPhone、Android、セキュリティキーなどの認証機能へ橋渡しします。
仕様上、このブラウザ側の役割をWebAuthn Clientと呼びます。ただし、一般の利用者から見れば、普段使っているWebブラウザがこの役割を担当していると考えれば十分です。
端末は顔、指紋、PINなどで、そのパスキーを使ってよい人物かを確認します。
確認に成功すると、秘密鍵を使ってChallengeに対する署名を作ります。秘密鍵そのものはブラウザやWEBサービスへ渡しません。
WEBサービスは、登録時に保存した公開鍵を使って署名を検証します。
単に署名が正しいかを見るだけではなく、今回発行したChallengeへの回答であるか、正しいWebサイト向けの認証であるかなども確認します。
これらの確認にすべて成功した後で、利用者をログイン状態にします。
ここで登場する用語
| パスキー用語 | 具体例 |
|---|---|
| RP | パスキーでログインを受け付ける銀行、証券会社、ECサイト、会員サイトなどのWEBサービス側 |
| WebAuthn Client | Chrome、Safari、Edgeなど、WEBサービスと端末の認証機能を仲介するブラウザ側 |
| Authenticator | Windows Hello、iPhone、Android、セキュリティキーなど、鍵を扱い署名を作る認証器 |
パスワード認証では、利用者がログイン画面を見て、正しいWebサイトかどうかを判断します。
しかし、フィッシングサイトは、ロゴ、色、入力フォーム、文章まで本物に似せて作られます。見た目だけで正規サイトか判断することは簡単ではありません。
一度パスワードを入力すると、入力された文字列を攻撃者が受け取り、正規サイトへ転用できる可能性があります。OTPも人が番号を入力する方式であるため、リアルタイムに盗まれて転送される危険が残ります。
パスキーでは、利用者の注意力だけに頼りません。
Chrome、Safari、Edgeなどのブラウザと、Windows、iPhone、Androidなどの端末側が、現在開いているWebサイトのドメインと、そのパスキーを利用できるWEBサービスの範囲を確認します。
パスキーの仕様では、認証を受け付けるWEBサービス側をRP（Relying Party）と呼びます。また、パスキーを利用できるWebサイトの範囲を示すドメイン情報をRP IDと呼びます。
たとえば、次の2つは人の目には似て見えるかもしれません。
example-bank.co.jpexample-bank-login.comしかし、ブラウザと端末から見ればドメインが異なる別のWebサイトです。
正規サイト用に登録されたパスキーは、別ドメインの偽サイトから利用できません。偽サイトが正規サイトと同じ見た目を作っても、正規サイト用の秘密鍵を呼び出して署名させることはできません。
同じ利用者でも、銀行用、証券会社用、ECサイト用など、それぞれ別のパスキーが作られます。
パスワードのように、利用者が同じ文字列を複数サイトで使い回すことはありません。仕組みとしてサービスごとに認証情報が分かれます。
一つのWEBサービスから公開鍵などの登録情報が漏れたとしても、その情報を別のWEBサービスへのログインに使い回すことはできません。
パスキーは、偽サイトへパスワードやOTPを入力させ、その認証情報を正規サイトへ転用するタイプの攻撃に非常に強い仕組みです。
ただし、偽サイトの表示そのものを防ぐ技術ではありません。また、ログイン後に利用者をだまして送金させる詐欺、端末そのものへのマルウェア感染、ログイン済みセッションの乗っ取りなど、すべての攻撃を自動的に防ぐものではありません。
それでも、パスワードやOTPを盗んで再利用するという、従来の認証で大きな問題となっていた攻撃経路を、仕組みから成立しにくくする点に大きな価値があります。
パスキーでログインする前には、そのWEBサービスにパスキーを登録する必要があります。
登録時には、端末やパスキープロバイダーが、そのWEBサービス用の公開鍵と秘密鍵のペアを新しく作ります。
パスキー登録という言葉から、秘密鍵をWEBサービスへアップロードするように感じるかもしれません。
しかし、WEBサービスへ登録する中心的な情報は公開鍵です。秘密鍵は、端末、セキュリティキー、パスキープロバイダーなど、利用者側の管理範囲で保護されます。
パスキーは登録後のログインを強固にします。しかし、その前提として、正しい人物のパスキーが正しいアカウントへ登録されていなければなりません。
もし攻撃者が他人のアカウントへ自分のパスキーを登録できてしまえば、その後のパスキー認証は正しく動作していても、攻撃者を正しい利用者として扱ってしまいます。
ログインが簡単になるほど、登録時の本人確認が重要になります。
そのため、パスキーの登録前には、サービスの性質に応じて次のような確認が行われます。
安全なパスキー運用は、最初の登録だけで終わりません。
新しいパスキーの追加、不要になったパスキーの削除、スマートフォンの紛失、機種変更、すべてのパスキーを失った場合のアカウント復旧まで考える必要があります。
復旧方法が簡単なメール確認だけなど、パスキーより大幅に弱い仕組みになっていると、攻撃者はパスキーそのものではなく復旧手続きを狙います。
パスキーの説明でApple、Google、Microsoftの名前が頻繁に登場するのは、多くの利用者が使っているOS、ブラウザ、端末、アカウント管理機能を提供しているからです。
これらの企業は、単に顔認証の機能だけを提供しているわけではありません。
こうした複数の仕組みが一体になっているため、利用者には「ボタンを押して顔認証するだけ」に見えます。
Windows環境では、Windows Helloが顔、指紋、PINによる本人確認を担当します。
Webサイトとのやり取りはChromeやEdgeなどのブラウザが仲介し、Windowsのセキュリティ機能と連携してパスキーを利用します。
利用環境によっては、Windows端末内のパスキーだけでなく、Googleパスワードマネージャー、スマートフォン、セキュリティキーなど、別の保存先を選択できる場合もあります。
iPhone、iPad、Macでは、Face ID、Touch ID、端末パスコードが本人確認を担当します。
パスキーはiCloudキーチェーンを通じて保護・同期され、Appleの「パスワード」アプリなどから確認できます。同じApple Accountを使う端末で利用しやすく設計されています。
Androidでは、Googleパスワードマネージャーが代表的なパスキー保存先です。
Android端末の指紋、顔、PIN、パターンなどで本人確認し、Chromeや対応アプリからパスキーを利用します。
AppleのiCloudキーチェーン、Googleパスワードマネージャー、対応するパスワードマネージャーなど、パスキーの保存、利用、同期、復旧を管理する仕組みを、一般にパスキープロバイダーと呼びます。
先に具体例を知ると、パスキープロバイダーという言葉も理解しやすくなります。
パスキーが複数端末で使えると聞くと、顔情報や指紋情報もクラウドに同期されているのではないかと不安になるかもしれません。
しかし、顔画像や指紋画像をWEBサービス間で共有し、同じデータを使って照合しているわけではありません。
各端末は、その端末に登録されているFace ID、Touch ID、Windows Hello、Androidの指紋やPINなどを使って、パスキーを利用してよい人物かを確認します。
パスキーには、パスキープロバイダーを通じて複数端末で使いやすいものと、特定の端末やセキュリティキーに固定されるものがあります。
| 種類 | イメージ | 代表例 |
|---|---|---|
| 同期されるパスキー | 同じアカウントで管理する複数端末から利用しやすい | iCloudキーチェーン、Googleパスワードマネージャーなど |
| 端末・機器に固定されるパスキー | 鍵を保持する特定の端末や機器で利用する | 一部の端末内認証器、USBセキュリティキーなど |
一般利用者向けのサービスでは、機種変更や複数端末での利用がしやすい同期パスキーが便利です。一方、企業の管理者や高い権限を持つ利用者では、会社支給端末や特定のセキュリティキーへ限定する考え方もあります。
自宅や会社のパソコンではなく、別のパソコンからログインするとき、画面にQRコードが表示されることがあります。
これは、スマートフォンに保存されているパスキーを、その場の認証器として利用する仕組みです。クロスデバイス認証と呼ばれます。
クロスデバイス認証では、スマートフォンの秘密鍵をパソコンへ移動させるわけではありません。
秘密鍵はスマートフォン側で使われ、スマートフォン内で署名が作られます。パソコン側へ戻るのは認証結果であり、秘密鍵そのものではありません。
QRコードを読み取れば、遠く離れた第三者でも自由にログインできる構造ではありません。
実際の処理では、QRコードに含まれる一時的な情報、スマートフォン側の本人確認、暗号化された通信、Bluetoothなどを利用した近接性の確認が組み合わされます。
QRコードは秘密鍵そのものでも、ログインを完了させる万能な鍵でもありません。その場のパソコンとスマートフォンを安全に結び付けるための入口です。
パソコン側に顔認証用カメラや指紋センサーがなくても、スマートフォン側で本人確認を行えるため、パスキーを利用できる場合があります。
「自分のパソコンには生体認証装置がないからパスキーは使えない」という誤解は、この仕組みを知ると解消できます。
利用者から見ると、パスキーはボタンを押し、顔や指紋、PINを確認するだけです。
そのため「Webサイトに顔認証ボタンを付ければ簡単に実装できるのではないか」と感じるかもしれません。
しかし、WEBサービス側では、少なくとも次のような処理と運用が必要です。
Windows、iPhone、Android、Chrome、Safari、Edge、セキュリティキー、銀行、証券会社、ECサイトなど、提供会社も製品も異なるものがパスキーで連携できるのは、共通の標準仕様があるからです。
この公開鍵認証の大きな枠組みがFIDO2です。
| FIDO2用語 | 解説 |
|---|---|
| WebAuthn | WEBサービス、ブラウザ、認証器が連携して登録・認証を行うためのWeb標準 |
| CTAP | パソコンとUSBセキュリティキー、またはパソコンとスマートフォンなど、ブラウザ側と外部認証器が連携するための通信仕様 |
一般の利用者がこれらの仕様を覚える必要はありません。
大切なのは、Appleだけ、Googleだけ、Microsoftだけの独自技術ではなく、異なる会社のOS、ブラウザ、端末、WEBサービスが共通ルールで安全に連携できるよう設計されていることです。
パスキーは、特に次の問題を大きく減らす技術です。
一方で、次のような問題を自動的にすべて解決するものではありません。
パスキーの特長と限界を正しく理解し、登録、認証、復旧、セッション管理まで含めて設計することが重要です。
従来のセキュリティ対策では、安全性を高めるほど利用者の操作が増える傾向がありました。
長いパスワード、定期変更、SMS認証、認証アプリ、リカバリーコードなどを組み合わせるほど、利用者にも運営者にも負担が増えます。
パスキーは、利用者の操作を簡単にしながら、次のような効果を期待できます。
安全性と使いやすさを同時に改善できることが、多くのWEBサービスから注目される大きな理由です。
パスキーを画面上の操作だけで見ると、顔認証や指紋認証、PINでログインする便利な機能に見えます。
しかし、その安全性は、次の仕組みが組み合わさることで成立しています。
パスキーが安全なのは、利用者がだまされないよう注意するからではありません。
人が秘密を覚えない、秘密を入力しない、秘密をWEBサービスへ送らない、偽サイトでは正規サイト用の鍵を使えないという構造によって、認証情報を盗んで再利用する攻撃を成立しにくくしています。
一方で、パスキーの登録、追加、削除、紛失、復旧、ログイン後のセッション管理まで自動的に安全になるわけではありません。WEBサービス側には、パスキーの強さを損なわない運用設計が求められます。
利用者から見える操作は簡単でも、裏側では公開鍵暗号、ドメイン確認、ブラウザとOSの連携、署名検証など、多くの技術が働いています。
この仕組みを知ると、パスキーが単なる顔認証の呼び方ではなく、パスワード認証が抱えてきた問題を根本から見直すために設計された技術であることが理解できるのではないでしょうか。
パスキーはWebサイトへのログインだけでなく、重要な操作を実行する直前の再認証、申請や決裁の承認、会員情報変更時の本人確認などにも利用できます。
パスキーの導入には、ブラウザ上の認証画面だけでなく、Challengeの管理、公開鍵と利用者の紐付け、署名検証、登録・削除・復旧、セッション管理、監査ログなどの設計が必要です。
ハネソルでは、既存のWEBサービスや業務システムに合わせたパスキー認証の設計、実装、API連携についてご相談いただけます。
最後までお読みくださり、ありがとうございました。
