パスキーとは ― パスワード不要のログインの仕組み

スマホに「パスキーを保存しますか」と表示されることがあります。これは、パスワードの代わりに端末の中の鍵でログインするかどうかの確認です。パスキー（passkey）は、公開鍵暗号を使い、パスワードを入力せずに本人を確かめる仕組みです。ログインするときは、指紋や顔、PINで端末のロックを解除するだけで済みます。

パスワードより安全と言われるのは、サイトに渡すものが違うからです。サイトが保存するのは公開鍵だけなので、サイトから情報が漏れても、それだけではログインされません。鍵は作ったサイト専用で、偽サイトでは使われないため、フィッシングにも強くなります。

顔や指紋の情報はサイトに送られません。機種変更しても、鍵を同期する種類なら新しい端末でそのまま使えます。どちらも、鍵がどこにあり、何が通信に乗るのかを追うと理由が分かります。

パスワードは、利用者とサイトが同じ秘密を共有する方式です。ログインのたびに秘密そのものを送るので、途中で盗まれる機会がいくつもあります。パスキーでは、秘密鍵をサイトへ送りません。

パスワードの弱点は、長く複雑にしても消えません。別のサービスから漏れたパスワードを試すパスワードリスト攻撃は、使い回しを狙います。サイトがハッシュ値で保存していても、漏れた値から解読を試みられます。アメリカの国立標準技術研究所（NIST）の指針は、長さや複雑さの限界も書いています。入力を記録するソフトやフィッシングには、長さも複雑さも効きません。

パスワードにワンタイムパスワードを足しても、偽サイトに入力した6桁は、攻撃者が本物のサイトへ中継できます。パスキーは、人が値を入力する手順そのものをなくします。

パスキーは、公開鍵暗号の鍵ペアを使います。秘密鍵で作った署名は、対になる公開鍵で確かめられます。公開鍵から秘密鍵は求められないので、公開鍵は人に見られてもかまいません。

登録：サイトに渡すのは公開鍵だけ

端末は、そのサイト専用の鍵ペアを作ります。秘密鍵を端末に残し、公開鍵だけをサイトへ送ります。サイトは公開鍵をアカウントに結び付けて保存します。すでにアカウントがあるサービスでは、いつもの方法でログインしたあとに、パスキーを作るのが一般的な流れです。

ログイン：毎回違う乱数に署名する

サイトは、毎回違う乱数を端末へ送ります。この乱数をチャレンジと呼びます。端末は、利用者のロック解除を確かめます。そのあと、チャレンジを含むデータに秘密鍵で署名し、サイトへ返します。

サイトは、登録済みの公開鍵で署名を検証します。正しければ、秘密鍵を持つ端末からの応答だと分かります。仕組みはデジタル署名と同じです。チャレンジが毎回変わるので、過去の署名を盗んで送り直しても通りません。

顔認証でログインできると、顔のデータがサイトへ送られているように感じます。実際には、指紋や顔は端末のロックを解除するためだけに使い、照合は端末の中で終わります。サイトに伝わるのは、端末が本人確認を済ませたという印だけです。そのため、サイトから情報が漏れても、生体情報は漏れません。

生体認証を使わない端末では、PINやパターンでも同じように解除できます。端末を持っていることと、顔やPINの組み合わせになります。そのため、パスワードが無くても多要素認証として扱えます。顔や指紋の照合で誤りが起こる理由は、生体認証の記事で説明しています。

サイトが確かめているのは、登録した鍵を持つ端末で本人確認が済んだことです。端末のPINを知る人や、端末に顔を登録した家族も、同じようにログインできます。端末の解除に使うPINや登録した顔が、そのままパスキーの安全性を左右します。

フィッシングは、本物そっくりの偽サイトに誘導し、パスワードを入力させる手口です。パスワードの場合、偽サイトかどうかを見抜くのは人の仕事です。パスキーでは、この判断をブラウザとOSが引き受けます。NISTは、利用者の注意に頼らず偽の相手に秘密を渡さない性質を、フィッシング耐性と説明しています。

鍵は、作ったときのドメインに結び付いています。ブラウザは、開いているページのドメインと鍵のドメインを比べ、合わなければ鍵を使わせません。見た目がどれだけ似ていても、鍵のドメインかそのサブドメインのページでなければ署名は作られません。

偽サイトが、本物のサイトのチャレンジを取り寄せて端末に署名させようとしても通りません。署名するデータには、開いているページのドメインが入ります。本物のサイトは検証のときにこの値も比べるので、偽サイトを経由した署名を拒否します。

ドメインが違っても鍵を使える例外が1つあります。運営者が、自分の別ドメインを本物のサイト上の一覧であらかじめ認めている場合です。一覧は本物のドメインに置くので、偽サイトの運営者が勝手に追加することはできません。

よく似たURLでも、ブラウザの判定ははっきり分かれます。例に使うドメインは、どれも架空のものです。

親のドメインの鍵はサブドメインでも使えますが、逆はできません。login.bank.example のページで、親のドメインを指定せずに作った鍵は、そのページのドメイン専用になります。この鍵は bank.example では使えません。

パスキーには、鍵を複数の端末で使える同期パスキーと、1つの機器から出ない端末固有のパスキーがあります。スマホやPCに「保存しますか」と聞かれて作る鍵は、たいてい同期パスキーです。セキュリティキーの鍵は、端末固有のものが多くなります。

同期パスキーの鍵は、暗号化した状態でクラウドに置きます。解説サイトのpasskeys.devによると、同期を手伝うサーバも秘密鍵を見たり使ったりはできません。署名を作るのは、いつも手元の端末です。

便利な分、同期先のアカウントは鍵の保管庫になります。NISTの指針は、同期先へのアクセスを多要素認証で守るよう求めています。同期先のアカウントの回復手続きが弱点になりうることも指摘しています。

同期する鍵は取り出せる鍵なので、NISTの最も高い保証レベルの要件は満たしません。高い保証が求められる業務では、取り出せないセキュリティキーの鍵を選びます。

機種変更しても同じAppleやGoogleのアカウントを使うなら、同期パスキーが使えます。新しい端末で、そのアカウントに入ります。iPhoneからAndroidのように標準の同期先が変わる機種変更では、自動では移りません。鍵を別の管理サービスへ移す仕組みは標準化が進んでいますが、対応はサービスごとに違います。

鍵が手元にない端末でも、別の端末の鍵でログインできます。PCの画面に出たQRコードをスマホで読み取ると、スマホのパスキーでPCのログインを承認できます。このとき、Bluetoothで2台が近くにあることを確かめます。そのため、離れた場所の攻撃者のPCを承認させる手口は通りにくくなります。ログインできたら、その端末用のパスキーを作っておくと次から楽です。

端末をなくしたときに困らないよう、次の準備をしておきます。NISTも、認証の手段を2つ以上持つことを勧めています。

• 大事なサービスには、パスキーを2つ以上登録する。スマホとセキュリティキーのように、同期でつながっていない機器に分ける
• サービスが発行する回復コードを、紙などに書いて端末とは別の場所に保管する
• 同期先のアカウントに、多要素認証を設定する

端末固有のパスキーをなくしたら、ほかの手段でサービスにログインし、登録済みのパスキーの一覧から削除します。サイトが公開鍵を消すと、その鍵の署名は受け付けられなくなります。

同期パスキーは、同じ鍵を複数の端末で使っています。一覧から消すと手元の端末でも使えなくなるので、まず同期先のアカウントからなくした端末を外します。すべての手段を失った場合は、サービスごとの回復手続きが必要です。本人確認のやり直しに時間がかかることもあります。

FIDO2やWebAuthnは、パスキーを動かす規格の名前です。ふだんパスキーを使うだけなら、細かく覚える必要はありません。

「Googleでログイン」のようなボタンは、パスキーとは別の仕組みです。このボタンは、別のサービスにログインを任せるOAuthとOpenID Connectの連携です。パスキーは、そのサービス自身へのログインのしかたです。そのため、ログインを任せる先のアカウントをパスキーで守ることもできます。

パスキーを作っても、パスワードが消えるとは限りません。次のような場面では、今もパスワードなどの従来の方法を使います。

• パスキーを作る前の最初のログイン
• パスキーに対応していないサイトや端末でのログイン
• パスキーが手元の端末になく、ほかの手段もないときのログイン
• パスキーを失ったときのアカウント回復

アカウントにパスワードが残っていれば、攻撃者はそちらを狙えます。パスキーを作ったあとも、残っているパスワードは長く、使い回しのないものにしておきます。サービスがパスワードの削除を認めているなら、回復の手段を確かめてから消す方法もあります。

パスキーが守るのはログインの瞬間です。ログイン後のセッションCookieを盗まれたときや、端末そのものをマルウェアに乗っ取られたときは防げません。端末のOSを更新し、ロックを設定しておくことは、パスキーを使っても変わらず必要です。

• FIDO Alliance Passkeys（パスキーの定義、生体情報、同期と端末固有・別の端末からのログイン、WebAuthnとCTAP）
• W3C Web Authentication Level 3（登録と認証の流れ、ドメインの扱い、チャレンジ）
• NIST SP 800-63B-4 Authentication and Authenticator Management（フィッシング耐性、同期する鍵、回復）
• passkeys.dev What are passkeys?（秘密鍵の扱い）
• passkeys.dev Terms（同期パスキーと端末固有のパスキーの用語）