パスキー完全ガイド：パスワード不要の認証革命。仕組み〜FIDO2まで解説

「パスワードを忘れた方はこちら」— このリンクを、私たちは一体何回クリックしてきたでしょうか？ 毎月のように「新しいパスワードは以前のものと違う必要があります」と言われ、頭を悩ませていませんか。 Password123! や MyPet_2024 のような、推測されやすいパスワードを使い回してはいないでしょうか。

もし「はい」と答えたなら、あなたは一人ではありません。長年、私たちのデジタルライフは「パスワード」という、根本的に脆弱な仕組みの上に成り立っていました。しかし、その時代はついに終わろうとしています。

この記事では、パスワードを過去のものにする新技術「パスキー (Passkey)」について、世界で最も詳しく、そしてわかりやすく解説します。

初級編 なぜ私たちは「パスワード」を捨てるべきなのか？

パスキーを理解する前に、なぜ今使っているパスワードがこれほど問題視されるのかを知る必要があります。

脆弱性の根源：「共有シークレット」モデル

従来の認証は、技術的に「共有シークレット (Shared Secret)」モデルと呼ばれます。

• あなた：「パスワード」という秘密の情報を知っている。
• サービス側（サーバー）：あなたの「パスワード（のハッシュ値）」という秘密の情報を知っている。

ログインとは、このお互いが「共有」している「秘密」を照合する作業です。この「共有」という性質こそが、あらゆるセキュリティインシデントの温床です。

ユーザー側の脆弱性：

• パスワードの使い回し： 記憶の負担を避けるため、多くの人が複数のサイトで同じパスワードを使います。
• リスト型攻撃： その結果、一箇所（例：小規模なECサイト）で漏れたパスワードが、別の大規模なサービス（例：銀行やSNS）で試され、不正アクセスされてしまいます。
• フィッシング： 本物そっくりの偽サイトに誘導し、パスワードを入力させる攻撃に、私たちは本質的に脆弱です。
• 推測攻撃： 辞書にある単語や総当たり（ブルートフォース）でパスワードを試す攻撃も存在します。

これらの問題は、パスワードの「複雑さ」をいくら高めても解決しない、アーキテクチャそのものの問題です。

初級編パスキーとは何か？

パスキー (Passkey) とは、この「共有シークレット」モデルを根本から覆し、「非対称 (Asymmetric)」なモデルに置き換える、認証のパラダイムシフトです。

ユーザーから見た「パスキー体験」

ユーザーにとって、パスキーは「パスワードの入力が不要になる」体験として現れます。

ログイン時、あなたはパスワードの文字列を一切入力しません。その代わりに求められるのは、あなたが普段デバイスのロック解除に使っている、「生体認証（顔や指紋）」または「PINコード」だけです。

この体験は、Google、Microsoft、Appleといったプラットフォーム企業や、LINE、Amazonなどの大手サービスがこぞって導入を進めています。セキュリティと利便性（シームレスなログイン）を両立するからです。

パスキーを構成する2つの「登場人物」

パスキーの仕組みを理解するために、2つの用語を覚えましょう。

• RP (Relying Party)： リライングパーティ。難しく聞こえますが、要は「サービス提供者」（例：Google.com, Amazon.co.jp）のことです。
• 認証器 (Authenticator)： あなたの「鍵」を安全に生成・保持するハードウェアやソフトウェアです。
  • プラットフォーム認証器： デバイス（スマホ、PC）に内蔵された認証器。OSと統合され、生体認証が使え、鍵をクラウド（iCloudなど）で同期できるのが特徴です。
  • ローミング認証器： USB接続の外部セキュリティキー（Yubikeyなど）。

パスキーのすべて ── 導入・UX設計・実装 [ えーじ ] 楽天で購入

中級編 パスキーの心臓部：「公開鍵暗号」の仕組み

パスキーがなぜ安全なのか。その答えは「公開鍵暗号方式 (Public-Key Cryptography, PKC)」という数学的基盤にあります。

ここが最重要ポイントです。「鍵と錠」のデジタルな関係として理解しましょう。

1. 登録（アカウント作成時）の仕組み

あなたがサービス（RP）にパスキーを新規登録する際、あなたのデバイス（認証器）は、2種類の鍵ペアをデバイス上で生成します。

• 秘密鍵 (Private Key)： あなたの「デジタルな鍵」です。
  • これはあなたのデバイス内部の、高度に保護された安全な領域（例：iPhoneのSecure Enclave）に厳重に保存されます。
  • 核心： 秘密鍵は、いかなる理由があってもデバイスの外部に送信されません。これは「Non-exportable（非送信）」原則と呼ばれます。
• 公開鍵 (Public Key)： あなたの「デジタルな錠」です。
  • これは秘密鍵とペアですが、公開鍵から秘密鍵を計算することは数学的に不可能です。
  • その名の通り「公開」されても安全です。登録時、この「錠（公開鍵）」だけがサービス（RP）のサーバーに送信され、データベースに保存されます。

2. 認証（ログイン時）の仕組み

パスキーによるログインは、「チャレンジ・レスポンス」方式で行われます。サーバーが「お前は秘密を知っているか？」と問う代わりに、「お前が本物の鍵を持っていることを証明しろ」と要求するプロセスです。

(Step 1) チャレンジ
あなたがログインを開始すると、サーバー（RP）は「チャレンジ」と呼ばれる一度きりのランダムなデータ（使い捨ての質問）を生成し、あなたのデバイスに送信します。

(Step 2) ユーザー検証 (UV)
デバイスは「秘密鍵を使う許可」を得るため、あなたに本人確認を要求します。これが、あなたが目にする「顔認証・指紋認証」の画面です。

(Step 3) デジタル署名
あなたが本人確認に成功すると、デバイスは保護領域にある「秘密鍵」を使い、サーバーから送られてきた「チャレンジ」に対してデジタル署名を行います。（※「署名」とは、”このチャレンジ（質問）を見たのは、この秘密鍵の持ち主に間違いありません” という「暗号化された証明書」のようなものです。）

(Step 4) 署名の返送
デバイスは、この「署名されたデータ」だけをサーバーに返送します。この際も、秘密鍵そのものは送信されません。

(Step 5) 署名の検証
サーバーは、保管していたあなたの「公開鍵（錠）」を取り出します。そして、送られてきた「署名」が、ペアである「秘密鍵（鍵）」によって正しく作成されたものかを数学的に検証します。

パスキーが解決する根本的な問題

このアーキテクチャにより、従来のパスワードの脆弱性がすべて解決されます。

• サーバー漏洩への耐性： 仮にサーバーがハッキングされ、全ユーザーの「公開鍵（錠）」が盗まれても、何の危険もありません。攻撃者は「錠」を持っているだけで、「鍵（秘密鍵）」は持っていないため、署名を偽造できず、誰にもなりすませないのです。
• 通信傍受への耐性： 通信を盗聴されても、攻撃者が得られるのは「あるチャレンジに対する一回限りの署名」だけです。チャレンジは毎回ランダムに変わるため、その署名を再利用（リプレイ攻撃）して別のログインをすることはできません。

中級編 パスキーの最強の盾：「フィッシング耐性」の秘密

パスキーの最も強力な利点は、従来の認証方法が絶対に勝てなかった「フィッシング攻撃」を原理的に無効化することです。

メカニズム：「Origin Binding（オリジンバインディング）」

この最強の防御の核となるのが「Origin Binding（オリジンバインディング）」という仕組みです。

「Origin」とは、ウェブサイトのドメイン（例： https://google.com）のことです。 パスキー（クレデンシャル）が作成される際、そのパスキーは「どのサイト（Origin）のためのものか」という情報と、暗号学的に固く紐付けられます。

なぜフィッシングが「原理的に」失敗するのか

パスワードやSMS認証コードがフィッシングに弱いのは、それらが「ユーザーが偽サイトに入力できる」情報であり、かつ「どのサイト用か」という区別がない情報だからです。

パスキーは、このプロセスを根底から変えます。パスキーはユーザーが「入力」するものではなく、「ブラウザ」と「認証器」が機械的に認証プロセスを実行します。Origin Bindingは、この機械的なプロセスに組み込まれています。

攻撃者が、本物のサイト https://service-japan.com にそっくりな偽サイト https://service-japan.security-login.com を作成し、あなたを誘導したとします。

Channel Binding：中間者攻撃への最終防衛線

さらに、FIDOプロトコルは「Channel Binding（チャネルバインディング）」という、より強力な仕組みも備えています。これは、通信を丸ごと中継する高度な中間者攻撃（Man-in-the-Middle, MITM）にも耐性を持ちます。

中間者攻撃では、攻撃者はユーザーと本物のサーバーとの間に割り込み、両者間の暗号化通信（TLS/SSL）さえも中継します。Origin Bindingだけでは、攻撃者がドメインを巧妙に中継した場合、理論上は突破される可能性がゼロではありませんでした。

Channel Bindingは、この問題を解決します。

1. アプリケーション層（ブラウザ）が、「自分が今確立しているTLS通信」に関する固有の識別情報（TLSチャネルIDなど）を取得します。
2. ブラウザは、この「TLSチャネル識別情報」を認証リクエストに含めて、認証器（スマホ）に渡します。
3. 認証器は、デジタル署名を作成する際、この「TLSチャネル識別情報」も署名の対象データに含めます。
4. サーバーは署名を検証する際、「署名されたTLSチャネル識別情報」が、「サーバー自身が（ユーザーと）確立しているTLSチャネル識別情報」と一致するかどうかを確認します。

攻撃者が中間に割り込んでいる場合、ユーザーと攻撃者の間のTLSチャネルと、攻撃者とサーバーの間のTLSチャネルは、必ず異なるものになります。そのため、認証器が署名したチャネル情報と、サーバーが期待するチャネル情報が一致せず、サーバーは攻撃を検知して認証を拒否します。

このように、パスキーは「Origin Binding」と「Channel Binding」という2つの強力なメカニズムによって、フィッシングや中間者攻撃に対して、従来の認証方法とは比較にならないレベルの耐性を実現しています。

上級編 他の認証方法との徹底比較

パスキーがいかに優れているかを、他の認証方法（特にMFA：多要素認証）と比較してみましょう。

比較対象1：SMS認証（所持情報）

一時的なコード（OTP）をSMSで送信する方式です。

比較対象2：TOTP（時間ベースのワンタイムパスワード）

Google Authenticatorなどの認証アプリが、30秒ごとにコードを生成する方式です。

比較対象3：MFAプッシュ通知

ログイン試行時、スマホアプリに「承認/拒否」の通知を送る方式です。

セキュリティレベル比較表

各認証方式の耐性を一覧化します。

出典： の情報を基に作成

パスキー実践ガイド [ 小林勝 ] 楽天で購入

応用編 パスキーを支える技術

ここからは、パスキーが技術的にどのように実装されているのか解説します。

FIDO2、WebAuthn、CTAPの関係

「パスキー」という用語は、FIDOアライアンスという業界団体が策定した「FIDO2」という技術フレームワークに基づいています。FIDO2は、主に2つの技術標準で構成されています。

• WebAuthn (Web Authentication)
  W3C（Webの標準化団体）によって標準化された、WebブラウザのためのJavaScript APIです。 これにより、ウェブ開発者は navigator.credentials.create()（登録）や navigator.credentials.get()（認証）といった標準化された関数を呼び出すだけで、自身のサイトにパスキー機能を実装できます。
• CTAP (Client to Authenticator Protocol)
  ブラウザやOS（クライアント）が、具体的な認証器（Authenticator）と通信するためのプロトコルです。 例えば、PCのブラウザがUSBセキュリティキーと通信したり、PCがBluetoothやQRコード経由で近くのスマートフォンと通信する際に使われます。

「ユーザー名さえ不要」にするResident Key (RK)

FIDO2（パスキー）には、2種類の鍵の保存方法があります。

• Non-Resident Key (非常駐鍵)： 古いFIDO U2F規格で主流だったモデルです。認証器は「秘密鍵」を保存しますが、「どのサイトの鍵か」という情報は管理しません。そのため、ログイン時にはまず「ユーザー名」を入力し、サーバーが「このユーザーのこの鍵で署名しろ」と認証器に指示する必要がありました。主に二要素認証（2FA）として使われます。
• Resident Key (RK) / Discoverable Credential (常駐鍵)： これこそが現代の「パスキー」の核です。認証器は、秘密鍵だけでなく、「ユーザー情報」と「RP情報（サービスドメイン）」も自身のストレージ内に保存します。

Resident Keyの登場により、ユーザーは「ユーザー名」の入力すら不要になりました。 「パスキーでログイン」ボタンを押すと、認証器が「今開いているサイト（Origin）は google.com だな。よし、google.com 用の鍵はこれだ」と能動的に鍵を提示（Discoverable）し、署名を行うのです。

応用編 同期パスキー：「鍵はデバイスから出ない」は本当か？

FIDOの初期仕様（USBキーなど）は、鍵が単一のデバイスに固定されていました。これは安全ですが、そのデバイスを紛失すると、すべてのアカウントにアクセスできなくなるという致命的な問題を抱えていました。

この問題を解決したのが、AppleやGoogleが主導する「同期可能なパスキー (Synced Passkeys)」です。

しかし、ここで大きな矛盾が生じます。

• FIDOの原則： 「秘密鍵はデバイスから絶対に出ない (Non-exportable)」
• パスキーの現実： 「iCloudキーチェーンやGoogleパスワードマネージャーで同期される」

この技術的な矛盾は、暗号化のレイヤーによって解決されています。

AppleのiCloudキーチェーンの実装を例に見てみましょう。

1. パスキー（秘密鍵を含む）は、iPhoneの Secure Enclave (SE) という安全な専用ハードウェア内で生成されます。
2. この秘密鍵は、iCloudにアップロードされる前に、SE内部で強力に暗号化されます。
3. この暗号化に使う「鍵」は、デバイス固有の鍵やユーザーのパスコードなどから導出されます。
4. この「暗号化されたパスキーの塊（ブロブ）」が、iCloudキーチェーンを経由して、ユーザーの他のデバイス（例：MacBook）に同期されます。
5. 新しいMacBookのSecure Enclaveは、この「暗号化ブロブ」をダウンロードし、SEの内部で安全に復号します。

応用編 アテステーション：「信頼できる認証器」の証明

パスキーの登録時、サービス（RP）は「そのパスキーが、信頼できるハードウェア（例：FIDO認定品）で作られたか」を知りたい場合があります。

アテステーション (Attestation) とは、認証器がRPに対し、「自身の出自や特性（真正性）を暗号学的に証明する」プロセスです。

登録時、認証器は「アテステーションオブジェクト」というデータを返します。これには、新しく作られたユーザーの「公開鍵」のほかに、以下の2つが含まれます。

• AAGUID (Authenticator Attestation Global Unique Identifier)： 認証器の「モデル番号」に相当するIDです。RPは、FIDOアライアンスが提供するメタデータ（MDS）とこのAAGUIDを照合し、「この認証器は生体認証をサポートしているか？」などのセキュリティ特性を確認できます。
• attStmt (Attestation Statement)： 認証器の製造元によって組み込まれた「アテステーション秘密鍵」による署名です。RPはこれを検証することで、「この公開鍵は、信頼できる製造元の、改竄されていない認証器によって生成された」と確認できます。

（ただし、プライバシー保護のため、AppleのiCloud同期パスキーのように、AAGUIDを意図的に匿名化（ゼロ値）する場合もあります。）

未来編 パスキー最大の課題：「アカウントリカバリー」

パスキーは技術的にほぼ完璧ですが、普及と運用には大きな課題が残されています。その最大の問題が「アカウントリカバリー」です。

「全デバイス紛失」という悪夢

パスキーのセキュリティは、鍵がデバイスに紐づいていることに依存します。では、もし「スマートフォンを紛失し、PCも故障し、持っている認証器をすべて失ったら」どうなるでしょうか？

現代のリカバリー戦略

この問題は「エコシステム全体で最も弱いリンク」と認識されており、複数のアプローチが併用されています。

• 複数の認証器の登録（FIDO推奨）
  最も基本的で堅牢な方法です。メインのスマホ（プラットフォーム認証器）に加え、予備のUSBキー（ローミング認証器）や、職場のPCも登録しておきます。万が一スマホを紛失しても、USBキーでログインし、紛失したスマホのパスキー登録を削除（失効）できます。
• エコシステムによる復旧（主流）
  AppleやGoogleは、この問題を自社の「エコシステムアカウント（Apple ID, Google Account）のリカバリー機能」と統合して解決しようとしています。 例えば、すべてのAppleデバイスを失っても、新しいiPhoneで「Apple IDのアカウントリカバリー」（信頼できる電話番号へのSMS送信など）に成功すれば、iCloudキーチェーン（暗号化されたパスキーを含む）が安全に復元されます。
• サービス提供者（RP）による復旧（最終手段）
  ユーザーがエコシステムの復旧にも失敗した場合、RP（サービス側）は、従来の本人確認（例：登録メールアドレスへのリンク送信、身分証のアップロード）にフォールバック（後退）し、古いパスキー登録を削除し、新しいデバイスでの再登録を許可します。

新たな脅威モデル：「最も弱いリンク」の移行

パスキーの同期機能（上記2）は、デバイス紛失のリスクを劇的に改善しました。

しかし、これはセキュリティのトレードオフを生み出します。セキュリティの脅威モデルが、「単一デバイスの物理的な盗難」から、「エコシステムアカウント（Apple ID, Google Account）のセキュリティとリカバリープロセス」へと移行するからです。

パスキーの普及は、プラットフォームアカウント自体のセキュリティを、以前にも増して重要にしています。

結論 パスワードのない未来へ

パスキーは、単なる「より強力なパスワード」ではありません。それは、インターネット認証のパラダイムを、脆弱な「共有シークレット（知識）」から、検証可能な「暗号学的証明（所持＋生体/知識）」へと根本的に転換する技術です。

そのアーキテクチャ（秘密鍵の非送信、Origin Binding、Channel Binding）は、従来の認証方法が抱えていたシステム的な脆弱性（サーバー漏洩、フィッシング、SIMスワップ、MFA疲労）を、プロトコルレベルでほぼすべて解決します。

しかし、パスキーが真のスタンダードとなるためには、技術的な課題ではなく、運用的な課題、すなわち「安全で、利便性が高く、標準化されたアカウントリカバリー戦略」の確立が不可欠です。

デバイスの紛失は避けられない事象であり、その際の復旧プロセスが「エコシステム全体で最も弱いリンク」とならないよう、業界全体の取り組みが求められています。

パスワードの呪縛から解放される日は、もうすぐそこまで来ているかもしれません。