パスキー認証入門: 次世代の安全なログイン方法を理解する
この記事は生成AIで作成されたものをベースに、投稿者が加筆修正をしたものになります。
はじめに
パスワードを使った認証は、私たちがインターネットを使う上で長年当たり前のものでした。しかし近年、「パスキー認証」という新しい認証方法が注目を集めています。
この記事では、認証技術に詳しくない方でも理解できるよう、パスキー認証とは何か、なぜ安全なのか、従来の認証方法とどう違うのかを、基礎から丁寧に解説します。
1. パスキー認証とは何か
パスキー認証とは、パスワードを使わずに、あなたのスマートフォンやパソコンを使ってログインする新しい方法です。
従来のログイン
- ユーザー名を入力
- パスワードを入力
- SMS認証コードを入力（多要素認証の場合）
パスキー認証でのログイン
- ログインボタンをタップ
- 指紋認証または顔認証
- 完了！
パスワードを覚える必要も、入力する必要もありません。それでいて、従来の方法よりはるかに安全なのです。
2. 従来の認証方法の問題点
なぜ新しい認証方法が必要なのでしょうか？従来の方法には、いくつもの問題がありました。
パスワード認証の弱点
覚えられない・管理できない
- 安全なパスワードは複雑で覚えにくい
- 複数のサービスで異なるパスワードを使うべき
- 結果として、簡単なパスワードを使い回してしまう
盗まれる・漏れる
- フィッシングサイトで入力してしまう
- サービス側のデータベースから漏洩する
- キーロガー（入力を記録するマルウェア）で盗まれる
多要素認証（MFA）でも不十分
パスワードに加えて、SMS認証コードやワンタイムパスワード（TOTP）を使う多要素認証も、完璧ではありません。
SMS認証の問題
- SIMスワップ攻撃（電話番号の乗っ取り）
- SMSの傍受
- フィッシングサイトで入力してしまう
TOTP（Google Authenticatorなど）の問題
- フィッシングサイトでコードを入力してしまう
- リアルタイム攻撃で中継される
- デバイス紛失時の復旧が困難
これらの問題を根本的に解決するのが、パスキー認証です。
3. 公開鍵暗号の基礎知識
パスキー認証を理解するには、「公開鍵暗号」という仕組みを知る必要があります。難しく聞こえるかもしれませんが、概念はシンプルです。
鍵のペア
公開鍵暗号では、2つで1組の鍵を使います。
秘密鍵（Private Key）
- 自分だけが持つ
- 絶対に他人に見せない
- 「署名」を作るために使う
公開鍵（Public Key）
- 誰に見せても良い
- サービス側に登録する
- 「署名」を確認するために使う
鍵と錠前の例え
従来のパスワード = 合鍵を共有
あなた: 「パスワードは"abc123"です」
サービス: 「わかりました。保管しておきます」
問題点:
- サービスが侵害されると、パスワードが漏れる
- フィッシングサイトにパスワードを教えてしまう
公開鍵暗号 = 特殊な錠前
あなた: 「この錠前（公開鍵）を渡します」
サービス: 「保管します」
ログイン時:
サービス: 「この箱に鍵をかけて送ってください」
あなた: （秘密鍵で鍵をかける）→ 送信
サービス: （公開鍵で確認）「本人ですね！」
利点:
- 秘密鍵は自分のデバイスから出ない
- サービスが侵害されても、公開鍵だけでは悪用できない
- フィッシングサイトに秘密鍵を渡すことはない
重要なポイント
公開鍵から秘密鍵は作れない
これが最も重要な特徴です。公開鍵を知っていても、秘密鍵を逆算することは、現代のコンピュータでは事実上不可能です（理論上は数百万年以上かかるほどの計算量になります）。
公開鍵が漏れても問題ない
名前の通り、公開鍵は「公開」されることを前提に設計されています。誰かが公開鍵を手に入れても、それだけではログインできません。
4. パスキー認証の仕組み
この章では、パスキーがどのように生成・保存・検証されるのかを、ステップごとに見ていきます。
初回登録（Registration）
サービスに初めてパスキーを登録するとき：
ステップ1: アカウント作成
あなた: 「example.comに登録したい」
サービス: 「わかりました」
ステップ2: パスキー作成
デバイス（自動的に）:
- 秘密鍵と公開鍵のペアを生成
- 秘密鍵をセキュア領域に保存
- 公開鍵をサービスに送信
あなた: （指紋認証または顔認証で承認）
サービス:
- 公開鍵をデータベースに保存
- 登録完了！
このとき重要なのは、秘密鍵はあなたのデバイスから一歩も外に出ないということです。
ログイン時（Authentication）
次回ログインするとき：
ステップ1: ログインリクエスト
あなた: 「ログインしたい」
サービス: 「ランダムな文字列（チャレンジ）を送ります」
例: "xyz789random"
ステップ2: 署名の作成
デバイス（自動的に）:
- チャレンジを受け取る
- セキュア領域で秘密鍵を使って「署名」を作成
- 署名をサービスに送信
あなた: （指紋認証または顔認証で承認）
ステップ3: 検証
サービス:
- 保存している公開鍵で署名を検証
- 正しければログイン成功！
チャレンジ・レスポンス方式の利点
毎回異なる「チャレンジ」を使うことで：
- リプレイ攻撃を防ぐ: 盗聴しても、同じ署名は二度と使えない
- フィッシング耐性: 偽サイトでは異なるドメインが検出され、署名が失敗する
5. なぜパスキーは安全なのか
パスキー認証が従来の方法より優れている理由を、具体的に見ていきましょう。
フィッシング攻撃への高い耐性
従来の認証（パスワード・MFA）
悪意あるサイト: 「こちらで銀行にログインしてください」
（本物そっくりの偽サイト）
あなた: パスワードとSMSコードを入力
攻撃者: すぐに本物のサイトで使用 → 乗っ取り成功
パスキー認証
悪意あるサイト: 「こちらでログインしてください」
デバイス: （自動的にドメインを確認）
「このサイトは bank.com ではなく、
bank-fake.com です」
→ 署名を拒否
あなた: ログインできない = 攻撃失敗
重要なのは、ユーザーがうっかり騙されても、デバイスが自動的に保護してくれるということです。
サーバー侵害への耐性
従来の認証（パスワード）
攻撃者がサービスのデータベースを盗む
↓
パスワードハッシュを入手
↓
ブルートフォース攻撃で解読
↓
ユーザーのアカウント乗っ取り
パスキー認証
攻撃者がサービスのデータベースを盗む
↓
公開鍵を入手
↓
公開鍵だけでは何もできない
↓
攻撃失敗
サーバーに保存されているのは公開鍵だけなので、漏洩しても悪用できません。
中間者攻撃への耐性
従来の認証（SMS、TOTP）
あなた → 攻撃者 → 本物のサービス
（中継）
攻撃者が間に入ってコードを中継し、
リアルタイムでログインできてしまう
パスキー認証
署名には以下が含まれる:
- チャレンジ（毎回異なる）
- ドメイン名
- その他の検証情報
中継しても、検証で弾かれる
パスワード関連リスクの排除
パスキーではパスワードそのものが存在しないため：
- ✅ パスワードの使い回しができない（そもそも存在しない）
- ✅ 弱いパスワードを設定できない
- ✅ パスワードを忘れることがない
- ✅ キーロガーで盗まれない
- ✅ ソーシャルエンジニアリングで聞き出されない
6. 多要素認証（MFA）との比較
「多要素認証を使っているから安全」と思っている方も多いでしょう。しかし、パスキーはさらに進化した仕組みです。
認証の「3要素」
セキュリティでは、認証に3つの要素があるとされています：
1. 知識要素（Something you know）
例: パスワード、PIN
2. 所持要素（Something you have）
例: スマホ、セキュリティキー
3. 生体要素（Something you are）
例: 指紋、顔、虹彩
従来の多要素認証（MFA）
第1段階: パスワード入力（知識要素）
第2段階: SMSコード入力（所持要素）
または: TOTPコード入力（所持要素）
これでも2要素で、かなり安全です。しかし問題は：
- ❌ 両方ともフィッシング可能
- ❌ 2段階の手間がかかる
- ❌ パスワードの問題は残る
パスキー認証
1回の認証で3要素を満たす:
所持要素: デバイスに保存された秘密鍵
生体要素: 指紋認証・顔認証
（知識要素: PIN も選択可能）
しかも:
- ✅ フィッシング不可能
- ✅ 1ステップで完了
- ✅ パスワード不要
比較表
| 特徴 | パスワード | パスワード + MFA | パスキー |
|---|---|---|---|
| フィッシング耐性 | ❌ | △ | ✅ |
| サーバー侵害への耐性 | ❌ | △ | ✅ |
| 使いやすさ | △ | ❌ | ✅ |
| パスワード管理 | 必要 | 必要 | 不要 |
| デバイス紛失時影響 | なし | 影響あり | 影響あり ※ |
| 認証にかかる時間 | 普通 | 長い | 短い |
※ 複数のパスキーを登録することで対策可能
7. デバイスと対応状況
「特別な機器が必要なのでは？」と思うかもしれませんが、実は今お使いのデバイスがすでに対応している可能性が高いです。
対応デバイス
スマートフォン
- iPhone / iPad（iOS 16以降）
- Android（Android 9以降）
パソコン
- Mac（macOS Ventura以降）
- Windows 10 / 11（Windows Hello対応）
ブラウザ
- Chrome
- Safari
- Edge
- Firefox
セキュア領域について
パスキーの秘密鍵は、デバイスの「セキュア領域」に保存されます。
iPhone / iPad
Secure Enclave（セキュアエンクレーブ）
- メインCPUとは物理的に分離された専用チップ
- Face ID、Touch IDのデータも同じ場所に保存
- 取り出すことが物理的に不可能な設計
Android
TEE（Trusted Execution Environment）
- ハードウェアレベルで保護された領域
- 指紋認証データも同じ場所に保存
Windows
TPM（Trusted Platform Module）
- セキュリティ専用のチップ
- 暗号化処理を安全に実行
重要な特徴
これらのセキュア領域は：
- 物理的に分離: メインメモリとは別の場所
- 暗号化: データは暗号化されて保存
- 取り出し不可: 秘密鍵をエクスポートする機能がない
- 認証必須: 使用時は生体認証またはPIN が必要
つまり、ハッキングソフトでも秘密鍵を盗み出すことはできないのです。
専用デバイスを使用する
より高いセキュリティが必要な場合、専用のセキュリティキーも使えます：
YubiKey、Titan Security Key など
- USB接続またはNFC接続
- 秘密鍵を物理デバイスに保存
- 企業や重要アカウント向け
ただし、一般的な用途ではスマホやPCで十分です。
8. パスキーの移行と管理
「デバイスを買い替えたらどうなるの？」という疑問にお答えします。
クラウド同期型パスキー
最近のパスキーは、クラウド経由で同期できます。
Apple（iCloudキーチェーン）
iPhone で作成したパスキー
↓（自動同期）
iPad、Mac でも使える
Google（Googleパスワードマネージャー）
Androidスマホで作成したパスキー
↓（自動同期）
Chrome、別のAndroidでも使える
重要: 同期中もセキュリティは保たれます
- 転送時は暗号化
- エンドツーエンド暗号化（E2EE）
- Google や Apple も中身を読めない
クラウド同期型パスキーのセキュリティリスク
クラウド同期型パスキーを使えば、どの端末でも同じようにログインできます。
この利便性の影には、同期アカウント（例：Apple ID、Google アカウント）乗っ取りによる事実上のパスキー漏洩リスクがあることを理解する必要があります。
利便性と安全性のバランスを取るために、同期アカウントの多要素認証・デバイス管理・信頼済みデバイス設定を確実に行うことが重要です。
デバイス専用パスキー
一部のパスキーは、特定のデバイス専用です：
Windows Hello のパスキー
- そのPCでのみ使用可能
- 買い替え時は再登録が必要
セキュリティキー（YubiKey）
- 物理デバイスそのものを持ち運ぶ
- 秘密鍵は取り出せない設計
推奨される運用方法
複数のパスキーを登録する
- メインのパスキー: iPhone（同期型）
- バックアップ1: Macにも自動同期
- バックアップ2: セキュリティキー（紛失対策）
多くのサービスは、1つのアカウントに複数のパスキーを登録できます。これにより：
- ✅ デバイス紛失時も別のデバイスでログイン可能
- ✅ 機種変更してもスムーズに移行
- ✅ 複数デバイスで使い分け可能
9. 認証の歴史と未来
パスキーは突然現れたわけではありません。長い歴史と技術の積み重ねがあります。
なぜ今まで普及しなかったのか
実は公開鍵暗号を使った認証自体は、1990年代から存在していました。
過去の試み: クライアント証明書
問題点:
- 証明書の管理が複雑
- 専門知識が必要
- ユーザーエクスペリエンスが悪い
- ブラウザごとに異なる実装
過去の試み: スマートカード
問題点:
- 専用のカードリーダーが必要
- コストが高い
- 企業や政府機関でしか使われなかった
何が変わったのか
2010年代の変化
- ハードウェアの進化
- ほぼ全てのスマホに Secure Enclave 搭載
- 生体認証センサーが標準装備
- 専用デバイス不要に
- 標準化の完成
- 2013年: FIDO Alliance 設立
- 2019年: WebAuthn が W3C 標準に
- ブラウザAPIで統一的に実装可能に
- エコシステムの協調
- Apple、Google、Microsoft が共同で推進
- 2022年: 3社が共同声明
- 各社のOSで一斉対応
- ユーザー体験の改善
- 過去: 証明書ダウンロード → インストール → 設定
- 現在: 指紋認証1回で完了
パスキーとマイナンバーカードの関係
日本では、マイナンバーカードも電子署名機能を持っています。
マイナンバーカードの仕組み
- ICチップに秘密鍵を保存
- 公開鍵は証明書として配布
- 行政手続きでの電子署名に使用
パスキーとの違い
-
マイナンバーカード:
- JPKI（公的個人認証）規格
- 中央集権型（J-LISが管理）
- 行政サービス向け
- カードリーダーまたは専用アプリが必要
-
パスキー:
- FIDO2/WebAuthn 標準
- 分散型（各サービスが管理）
- 一般Webサービス向け
- ブラウザだけで使える
-
現状: マイナンバーカードで直接パスキー認証はできません
-
将来: スマホ搭載マイナンバーが普及すれば、WebAuthn 対応の可能性もあります
これからの認証
短期（2025〜2027年）
- パスワード + MFA が主流
- パスキーはオプションとして追加
- 大手サービスから導入開始
中期（2027〜2030年）
- パスキーがデフォルトに
- パスワードはフォールバックとして残る
- 多くのサービスで対応
長期（2030年以降）
- パスキーが標準認証方法に
- パスワードのみ認証は廃止
- レガシーシステムでのみ MFA が残る
完全に置き換わる？
おそらく**完全には置き換わりません。**理由は：
- レガシーシステムとの互換性
- 特定の規制要件
- フォールバック・バックアップの必要性
- 全てのユーザーがデバイスを持つわけではない
しかし、新しいシステムではパスキーが第一選択になるでしょう。
10. パスキー認証フロー
実際にパスキー認証を実装する際の基本的なフローを紹介します。
WebAuthn API について
パスキー認証は WebAuthn（Web Authentication）API という Web標準を使って実装します。主要なブラウザすべてが対応しており、JavaScriptから呼び出すことができます。
SimpleWebAuthn ライブラリの推奨
WebAuthn API を使用して手動実装することも可能ですが、必要な実装が多く複雑なため、実際の開発ではWeb標準をラップしたSimpleWebAuthn ライブラリの使用を推奨します。
手動実装との比較：
| 項目 | 手動実装 | SimpleWebAuthn |
|---|---|---|
| Base64変換 | 手動でコード実装 | 自動処理 |
| チャレンジ生成 | 自前の実装 | generateXxxOptions() |
| 検証処理 | 各検証を個別実装 | verifyXxxResponse() |
| エラーハンドリング | 細かい実装が必要 | 統一されたエラー形式 |
| セキュリティ設定 | 自分で調査・設定 | セキュアなデフォルト |
| TypeScript型定義 | 自作が必要 | 完全な型サポート |
パスキー登録フロー（Registration）
パスキー認証フロー（Authentication/Login）
実装のポイント
セキュリティ上の重要事項として以下の処理実装が推奨されます：
-
チャレンジ（Challenge）
- ランダムに生成される32バイトの値
- リプレイ攻撃を防ぐための使い捨てトークン
- 1回のみ有効で、使用後は無効化
-
Origin（オリジン）検証
- リクエスト元のドメインを検証
- フィッシング攻撃を防ぐ重要な仕組み
-
カウンター値のチェック
- 認証器の使用回数を記録
- 値が減少した場合はクローンやリプレイ攻撃を疑う
11. まとめ
パスキー認証の本質
パスキー認証とは：
- ✅ パスワード不要
- ✅ デバイスの秘密鍵で認証
- ✅ 生体認証で本人確認
- ✅ フィッシング不可能
- ✅ サーバー侵害にも強い
- ✅ 使いやすい
なぜ安全なのか
3つの重要な原則
- 秘密鍵はデバイスから出ない
- セキュア領域に保存
- 取り出し不可能
- ネットワーク経由で盗めない
- 公開鍵暗号の数学的安全性
- 公開鍵から秘密鍵は作れない
- サーバー侵害されても悪用不可
- 盗聴されても意味がない
- ドメイン検証の自動化
- フィッシングサイトでは動作しない
- ユーザーが騙されてもデバイスが守る
- 中間者攻撃も防ぐ
従来の認証との比較
| パスワード | パスワード + MFA | パスキー | |
|---|---|---|---|
| 安全性 | 低 | 中 | 高 |
| 使いやすさ | 中 | 低 | 高 |
| フィッシング耐性 | なし | 弱い | 強い |
| サーバー侵害への耐性 | なし | 弱い | 強い |
| 管理の手間 | 大 | 大 | 小 |
誰が使えるのか
必要なもの
- スマートフォンまたはパソコン（最近のもの）
- 指紋認証または顔認証機能
- 対応ブラウザ
特別な知識は不要
- 難しい設定は不要
- デバイスが自動で処理
- ユーザーは生体認証するだけ
パスキー認証を実装するには
- WebAuthn API の学習
- SimpleWebAuthn などのライブラリの学習
- セキュリティ上の重要事項の学習
最後に
パスキー認証は、インターネットの安全性を大きく向上させる技術です。
セキュリティと利便性の両立という、今まで難しかった課題を、ついに解決できる可能性を持っています。
パスワードを覚える苦労から解放され、フィッシング詐欺の心配も不要になる未来が、すぐそこまで来ています。
ぜひ、パスキー対応のサービスを見つけたら、一度試してみてください。その使いやすさと安全性に、きっと驚くはずです。
参考資料
- Passkeys.dev - パスキーについての総合情報サイト
- WebAuthn Guide (MDN)
- W3C WebAuthn 仕様
- WebAuthn Guide - 詳細な技術ガイド
- SimpleWebAuthn - 推奨ライブラリの公式Doc
- FIDO Alliance - FIDO(Fast Identity Online: パスワードレス認証規格) 標準化団体の公式サイト
Discussion