パスキーとは？仕組みを図で解説　なぜパスワードより安全なのか

パスキーは、パスワードを別の秘密に置き換えただけではない

パスキーは、パスワードの代わりに使えるログイン方法です。ただし「長いパスワードを端末が覚えてくれる仕組み」ではありません。

仕組みの中心にあるのは公開鍵暗号です。サービスごとに公開鍵と秘密鍵の組を用意し、サービス側には公開鍵を登録します。ログインに必要な秘密鍵そのものはサービスへ渡さず、端末側で本人確認をしたうえで署名に使います。

見た目は「顔や指紋でログインしている」ように見えますが、生体認証はパスキーそのものではありません。ここを理解すると、なぜパスキーがパスワードよりフィッシングに強いのかが分かりやすくなります。

パスワードは秘密を入力する、パスキーは秘密鍵を持つことを証明する

パスワード認証では、利用者が知っている文字列をサービス側が確認します。実際のサービスではパスワードそのものではなくハッシュ値を保存するのが一般的ですが、利用者はログイン時に「秘密の文字列」を入力します。

パスキーでは、登録時に次の2つの鍵を使います。

• 公開鍵：サービス側へ登録する鍵
• 秘密鍵：ログイン時の署名に使う鍵

公開鍵から秘密鍵を現実的に逆算することはできません。そのため、サービス側から公開鍵が漏れても、それだけで利用者になりすまして有効な署名を作ることはできません。

重要なのは、ログインのたびに秘密そのものを相手へ送らないことです。

登録時：公開鍵をサービスに登録し、秘密鍵はサービスへ渡さない

対応サービスでパスキーを作成すると、そのサービス用の認証情報が作られます。サービス側には公開鍵と認証情報を識別するための情報が登録されます。

一方、ログインに使う秘密鍵そのものはサービスへ渡しません。これが、パスワードを入力して照合する方式との大きな違いです。

図の①では、秘密鍵は利用者側、公開鍵はサービス側へ登録という関係が一目で分かるようにしています。端末のPINや顔・指紋などの生体認証は、その秘密鍵を使ってよい本人かを端末側で確認するために使われます。

なお、同期パスキーではパスキープロバイダの保護された仕組みを通じて複数端末で利用できる場合があります。したがって「秘密鍵は必ず1台の端末から一歩も外へ出ない」というわけではなく、Webサービスへ秘密鍵そのものを渡さないと理解する方が正確です。

ログイン時：チャレンジに秘密鍵で署名し、公開鍵で検証する

ログイン時には、パスワードの代わりにチャレンジ・レスポンスの仕組みが使われます。

まずサービスが、そのログイン処理のための一度限りのデータである「チャレンジ」を端末へ送ります。端末側ではPIN、顔認証、指紋認証などで利用者を確認し、パスキーの利用を許可します。

次に、秘密鍵を使ってチャレンジに対する署名を作ります。サービス側は、登録済みの公開鍵でその署名を検証します。正しければ「登録時の秘密鍵を使える相手からの応答だ」と確認できます。

ここでも秘密鍵そのものをサービスへ送る必要はありません。図の②は、チャレンジ → 端末側で署名 → サービス側で公開鍵により検証、という流れを示しています。

PINや生体認証は「パスキーそのもの」ではない

パスキーでログインするときに顔認証や指紋認証が表示されるため、「顔や指紋をサービスへ送って本人確認している」と思われがちです。

実際には、多くの場合、顔・指紋・端末PINなどは端末側でパスキーの秘密鍵を使ってよい本人か確認するための手段です。生体情報そのものをWebサービスへ送って、サービス側で照合しているわけではありません。

役割を分けると、PIN・顔・指紋は端末側の本人確認、秘密鍵は署名の作成、公開鍵はサービス側での署名検証を担当します。生体認証を使わず、端末のPINやパスコードでパスキーを利用できる場合もあります。

同じようにスマホのマイナンバーカードでも、端末の生体認証と、スマホに搭載される電子証明書・属性証明は役割が別です。スマホのマイナンバーカードに何が入っているのかで、端末内の機能とサービス側の情報の違いを図解しています。

なぜフィッシングに強い？　認証情報が利用先のサイトと結び付くから

パスワードは、偽サイトでも入力欄があれば利用者が入力してしまう可能性があります。一方、パスキーは認証情報が利用先のWebサイトやアプリと結び付いています。

WebではWebAuthnの仕組みによって、ブラウザやOSも認証処理に関与し、どのサイト向けの認証かを区別します。そのため、本物とは異なるドメインに作られた偽サイトが、本物のサービス用パスキーをそのまま使わせることはできません。

安全性を「利用者が毎回URLを完璧に見抜けること」だけに頼らず、認証の仕組み自体が相手先を区別する点が、パスワードとの大きな違いです。

複数端末や機種変更では？　同期パスキーという考え方

現在のパスキーには、パスキープロバイダを通じて自分の複数端末で利用できる同期パスキーがあります。図の③は、この場合にPC、スマートフォン、タブレットなどで同じアカウントのパスキーを利用できるイメージを示しています。

また、自分のパスキーが保存されていないPCから、手元のスマートフォンを使ってログインするクロスデバイス認証が利用できる場合もあります。

重要なのは、Webサービスのサーバーが秘密鍵を保管して各端末へ配る構造ではないことです。同期を使う場合は、パスキープロバイダ側の保護された仕組みを通じて利用できるようにします。

機種変更や紛失への備えは、パスキー・多要素認証・復旧手段をまとめて整えるでも整理しています。

証明書認証と少し似ているが、パスキー＝クライアント証明書ではない

公開鍵と秘密鍵を使うため、企業のVPNなどで使われるクライアント証明書を連想する人もいるかもしれません。

「秘密鍵を持つ側だけができる暗号学的な処理を行い、相手側が公開情報で確認する」という大きな考え方には共通点があります。

ただし、一般的なパスキーはX.509のクライアント証明書をWebサイトへ提示する仕組みそのものではありません。WebではFIDO2/WebAuthnの認証資格情報として扱われ、サービスごとの認証情報、チャレンジ、署名、サイトとの結び付きなどを使います。

理解の入口として「公開鍵暗号を使う点は似ている」と考えるのはよいですが、パスキー＝端末証明書と置き換えるのは正確ではありません。

パスキーでもアカウント全体が無敵になるわけではない

パスキーは認証を強くできますが、アカウント全体を無敵にするものではありません。

端末そのものを攻撃者に操作されている、端末のロック解除情報を知られている、ログイン後のセッションを奪われる、弱い本人確認でアカウント復旧を突破される、といった問題は別に対策が必要です。

同期パスキーを利用する場合は、パスキープロバイダのアカウントを安全に保つことも重要です。端末の画面ロック、OS更新、復旧手段、予備端末などは引き続き必要です。

また、パスキーを設定してもパスワードや別の復旧方法が残るサービスでは、最終的な安全性は一番弱い入口にも左右されます。

ポイントは「秘密を渡さず、持っていることを証明する」

パスキーの中心は、顔認証や指紋認証そのものではありません。

• サービスには公開鍵を登録する
• ログイン時は端末側の秘密鍵でチャレンジに署名する
• サービスは登録済みの公開鍵で署名を検証する
• PINや生体認証は端末側でパスキーの利用を許可するために使う
• 同期パスキーなら複数端末で利用できる場合がある

という構造です。

パスキーは「パスワードを入力しなくて済む便利機能」というだけではありません。認証に使う秘密そのものをWebサービスへ渡さない設計に変えることで、フィッシングやパスワード使い回し、認証情報漏えいへの耐性を高めています。