はじめに
Passkeys are a trap. Do not use them.
https://nonfunctional.substack.com/p/passkeys-are-a-trap-do-not-use-them
─
What’s important to know is that unlike with any other kind of login credential, you do not have ultimate control over your passkeys.
知っておくべきなのは、ほかの種類のログイン認証情報とは違い、パスキーについては最終的な決定権を自分では持てないということです。
この記事を読んで、パスキーについてちゃんと理解を深めたくなった。
パスキーというキーワードで検索すると
- 生体認証だから安全
- デバイス間で情報が共有されるから便利
- Yubikey等のハードウェアセキュリティキーを使うと外部へ流出することがない
など、いろいろな情報が出てくるため、実態がどういうものなのかがパッと分かりにくい。 この記事では、このパスキーの公開鍵認証に使う「秘密鍵」の保存に焦点を当てて調べたことをまとめる。
FIDO Alliance とパスキー関連の用語まとめ
まず、パスキーの技術仕様の策定をリードしている団体 FIDO Alliance がいつからあるのか調べてみた。
FIDOアライアンス、認証プログラムを拡大し、標準ベースの認証デバイスへの信頼をさらに強化 | FIDO Alliance
https://fidoalliance.org/fido-alliance-extends-certification-program/?lang=ja
─
FIDO(Fast IDentity Online)アライアンス(www.fidoalliance.org )は、強力な認証技術間の相互運用性の欠如に対処し、ユーザーが複数のユーザー名とパスワードを作成して記憶する際に直面する問題を解決するために、2012年7月に設立されました。
実は結構前からある。また、パスキー関連の用語として以下を理解しておく必要がある。
- WebAuthn（ウェブオースン）
- Web Authentication の略。 Web サイトがブラウザーを通じて、パスキーやセキュリティキーによる認証を利用するための共通規格。「サイトがブラウザーに鍵の作成やログインの認証を頼む方法」を定めている。 W3C が標準化している。
- CTAP（シータップ）
- Client to Authenticator Protocol の略。PC やスマートフォンが、外付けのセキュリティキーや別のスマートフォンなどの認証器と通信するための共通ルール。スマートフォン内のパスキーを使って PC 側のサイトにログインする「クロスデバイス認証」の通信方式も定めている。
- FIDO2（ファイドツー）
- パスキーやセキュリティキーによる認証の土台となる規格セット。 Web サイトがブラウザー経由で認証を利用するための WebAuthn と、 PC やスマートフォンが外付けの認証器などと通信するための CTAP を組み合わせたもの。 FIDO Alliance と W3C が協力して整備している。
- FIDO（ファイド）
- Fast IDentity Online の略。パスワードへの依存を減らし、安全で簡単にログインするための認証規格群の総称。 FIDO2 のほか、 UAF や U2F などを含む。いずれも、手元の秘密鍵で作った署名を、サービスに登録した公開鍵で検証する仕組みを使う。
- FIDO Alliance（ファイド・アライアンス）
- パスワードに頼りすぎない認証の仕組みを開発・普及する業界団体。さまざまな企業や組織が参加し、メーカーやサービスが違っても共通して使える認証規格を作る。 WebAuthn については W3C と協力している。
- W3C（ダブリュースリーシー）
- World Wide Web Consortium の略。 Web で使う技術の共通ルールを作る国際的な標準化団体。パスキーの文脈では、 FIDO Alliance と協力して WebAuthn を整備・標準化している。
図で整理するとこのような感じ
┌─────┐ ┌─ FIDO: Authentication standards ─────────────────────────────────────────────────────────┐
│ W3C ├────────────Standardizes───────────┼┐ │
└─────┘ ││┌─ FIDO2: WebAuthn + CTAP ─────────────────────────────────────────────────────────────┐ │
│││ │ │
│││ ┌────────────────────────┐ │ │
│└┼─▶ WebAuthn │ │ │
┌───────────────┐ ┌───Defines standards───▶ │ │ Web authentication API ◀───Works with───┐ ┌──────────────────────────────────────┐ │ │
│ │ │ & Promotes │┌┼─▶ │ └─▶ CTAP │ │ │
│ │ │ │││ └────────────────────────┘ │ Authenticator communication protocol │ │ │
│ │ │ │││ └─────────────────────────▲────────────┘ │ │
│ ├─┘ │││ │ │ │
│ FIDO Alliance ├──── Contributes ────┼┘└───────────────────────────────────────────────────────────────────────┼──────────────┘ │
│ │ to specification │ │ │
│ │ └─────────────────────────────────────────────────────────────────────────┼────────────────┘
│ │ │
│ │ │
└───────┬───────┘ │
└──────────────────────────────────────────────────Develops─────────────────────────────────────────────────┘パスキーとは
まずパスキーとは何かだが、公式サイトの説明を見ると
パスキーのセキュリティ | Passkey Central
https://www.passkeycentral.org/ja/introduction-to-passkeys/passkey-security
─
パスキーは、非対称暗号技術に基づくチャレンジ・レスポンス認証プロトコルを使用しています。
このような説明が書かれており、それぞれ
- 非対称暗号技術
- チャレンジ・レスポンス認証プロトコル
について調べると、以下となる。
非対称暗号化とは | IBM
https://www.ibm.com/jp-ja/think/topics/asymmetric-encryption
─
非対称暗号化とは、公開鍵と秘密鍵という2つの異なる鍵を用いてデータを暗号化および復号化する暗号化方法のことです。
Challenge-Response Protocol - Glossary | CSRC
https://csrc.nist.gov/glossary/term/challenge_response_protocol
─
An authentication protocol where the verifier sends the claimant a challenge (usually a random value or a nonce) that the claimant combines with a secret (often by hashing the challenge and a shared secret together, or by applying a private key operation to the challenge) to generate a response that is sent to the verifier.
認証プロトコルの一種で、検証者が請求者にチャレンジ（通常は乱数やノンス）を送信し、請求者がそれを秘密情報と組み合わせ（多くの場合、チャレンジと共有秘密をハッシュ化するか、チャレンジに秘密鍵演算を適用することで）、検証者に送信するレスポンスを生成します。
つまり、馴染みのある SSH の公開鍵認証 と同じ原理。ということで、一気に理解のハードルが下がった。 パスキーにはいろいろな方式があるが、結局のところベースとなる仕組みはユーザーの秘密鍵を使った公開鍵認証を指している。
SSH の公開鍵認証とパスキーの違いは、秘密鍵・公開鍵の他に
public-key-credential-source
https://www.w3.org/TR/webauthn-3/#public-key-credential-source
に列挙されている情報を含んでいる点がある。
詳細な説明は公式サイトに任せるとして、特徴は「認証情報＋どのサイトのものか」がセットになっているところ。
特にパスキーは、サービスの指定のみで、そこから適合する認証情報の候補を見つけることができる性質を持つ必要がある。この性質を持つ認証情報を Discoverable credential と呼ぶ。
discoverable-credential
https://www.w3.org/TR/webauthn-3/#discoverable-credential
この性質により、ユーザーがサイトやアプリで認証を開始した際、アカウントを特定する前にパスキーの候補を自動的に選出することができる。
WebAuthn とは
パスキーは、 WebAuthn という規格に従って、以下のようなルールの上で利用される。
- 登録：サイトがブラウザーを通じて認証器(
Authenticator)に鍵の作成を依頼し、公開鍵を受け取る - 認証：サイトが送ったチャレンジなどを含むデータに対して、認証器が秘密鍵で署名する。サイトは公開鍵で検証する
- 利用先の制限：認証情報をサービスの識別子である RP ID に紐づけ、ブラウザーがアクセス元のオリジンとの関係を検査する。署名対象にも RP ID やオリジンに関する情報が含まれ、サイト側でも検証する
ここでいう 認証器 とは、 秘密鍵と公開鍵のペアを作ったり、鍵で署名を行うことができるアプリやデバイスを指す。
authenticator - Web Authentication
https://www.w3.org/TR/webauthn-3/#authenticator
sctn-op-make-cred - Web Authentication
https://www.w3.org/TR/webauthn-3/#sctn-op-make-cred
sctn-registering-a-new-credential - Web Authentication
https://www.w3.org/TR/webauthn-3/#sctn-registering-a-new-credential
sctn-spec-roadmap - Web Authentication: An API for accessing Public Key Credentials - Level 3
https://www.w3.org/TR/webauthn-3/#sctn-spec-roadmap
─
the Relying Party’s request consists of a challenge and other input data supplied by the Relying Party and sent to the authenticator.
sctn-verifying-assertion - Web Authentication
https://www.w3.org/TR/webauthn-3/#sctn-verifying-assertion
パスキーはどこに保存されるのか？どういうパターンがあるのか？
パスキーの保存方式には多くのパターンがあり、その保存方式の多さがパスキーの仕組みの理解を複雑化させている要因となっている。 ここでは、保存方法のパターンについて具体的なサービス名をベースに一つずつ確認していく。
1. ユーザーが自由にパスキーを取り出せるパターン
まず最初は、パスキーの保存に対応するローカルデータベース内に秘密鍵を含む認証情報を暗号化して保存し、必要に応じて取り出せるパターン。 パスキーを自分でファイルに書き出して別の場所にコピーしたり、バックアップを取ったりすることができる（=文字列・ファイルとして自由に扱える）。
これに該当する代表的なアプリは以下。
- https://bitwarden.com/ja-jp/ (クラウド同期機能も提供されている)
- https://keepassxc.org/
- https://strongboxsafe.com/
2. ユーザーがパスキーを直接取り出せないパターン
このパターンには
- クラウド・ローカルアプリ側でパスキーが管理されており、ユーザーが直接扱えるファイルとして書き出せないパターン
- 秘密鍵を外部へ書き出す機能を持たないハードウェア認証器のパターン
の大きく二つのパターンがある。
2-1. クラウド・ローカルアプリ側でパスキーが管理されているパターン
Google パスワードマネージャーや Apple パスワードアプリなどがこれに該当する。 これらのサービス・アプリでは、ユーザー自身がパスキーの中身（秘密鍵の値など）を直接見れない。 また、パスキーを、ユーザーが直接扱えるファイルとして書き出す機能は提供されていない。
ただし、FIDOの「Credential Exchange」という仕様に基づいたパスキーの移行には対応している。
Securely switch password managers on Android
https://blog.google/products-and-platforms/platforms/android/switch-password-managers/
─
Transfer passwords and passkeys with ease.
Passkeys Overview - Apple Developer
https://developer.apple.com/passkeys/
─
And users can securely import and export passkeys between password managers,
ファイルに直接書き出すことはできないが、アプリ間でパスキーを移動させることはできる。
これに該当する代表的なサービス・アプリは以下。
2-2. 秘密鍵を外部へ書き出す機能を持たないハードウェア認証器のパターン
このパターンでは、パスキーをハードウェアの保護された領域で管理し、外部へ書き出す機能を提供しない。 認証時は内部で署名を行い、その署名した結果だけを返す。 このため、秘密鍵をファイルとしてコピーして盗み出す攻撃に強い設計と言える。 一方で、認証器(ハードウェア)を紛失・破損に備えたバックアップ目的であっても秘密鍵を取り出すことはでないため、予備のハードウェアを別途用意し登録するなどの備えが必要となる。
これに該当する代表的なデバイスが以下。
改めてパスキーとは？
ここまでの話を理解した上で、冒頭に書いた
パスキーというキーワードで検索すると
- 生体認証だから安全
- デバイス間で情報が共有されるから便利
- YubiKey 等のハードウェアセキュリティキーを使うと外部へ流出することがない
について改めてみてみると
生体認証だから安全
-> 生体認証は必須ではなく、PINなども使える。生体認証は、認証器側でユーザーを確認する手段の一つなだけ
デバイス間で情報が共有されるから便利
-> クラウドに秘密鍵を保存するタイプのサービスでは複数デバイスを跨いでパスキーでログインが可能。また、秘密鍵を自分で書き出せるタイプも手動ではあるが、デバイス間で同じ秘密鍵を使いまわせる。
YubiKey 等のハードウェアセキュリティキーを使うと外部へ流出することがない
-> これは保存先の一例であって、パスキー全てがそうであるという説明にはならない
ということが分かった。
今回はパスキーの秘密鍵の保存方式について理解できたので、次回はパスキーそのものの仕組みについてもう少し深掘りしてみようと思う。