広告

パスキー認証について

Azure

パスキー認証(パスワードレス認証)

パスキー(FIDO2)では主に ECDSA という署名方式が使われており、公開キーで復号するのではなく、「この署名を作った秘密キーに対応する公開キーか?」を数学的に検証しています。

  • 代表例:
    • Windows Hello
    • Microsoft Authenticator のパスキー
    • iCloud キーチェーンのパスキー
    • Google パスワードマネージャーのパスキー
    • YubiKey などの FIDO2 セキュリティキー
  • メリット
    • パスワード不要
    • フィッシング耐性が高い
    • MFA 相当以上の強い認証
    • サインインが速い
# サーバー側:チャレンジデータを送る
Challenge = "ABC123"

# 端末側:チャレンジデータを署名し、署名データをサーバー側に送り返す
「秘密キー」 + 「"ABC123"」 → 「署名 = XYZ」

# サーバー側:下記3つのデータで検証する
「Challenge = ABC123」+「署名 = XYZ」+「公開キー」 → Verify(公開キー, ABC123, XYZ)

# 結果が True だったら、「対応する秘密キーを保有する端末によって署名された」だと確認できる
True

QA:

  1. Challenge は毎回変わりますか
    • はい、攻撃者が送信データを盗んで再利用する攻撃を防ぐため、毎回変わります。
  2. 署名データは公開キーですか
    • いいえ。署名データは公開キーではありません。
    • サーバーは「Challenge」「署名データ」「公開キー」の3つを使い、署名が対応する秘密キーで生成されたかを数学的に検証する。(challenge が変わっても、検証はできる。具体的にどう検証するのかは深堀していない)
  3. パスキー認証はパスワード使いますか
    • 秘密キーそのものも、パスワードも、サーバーには送られません。
    • 漏えいしにくく、フィッシング(サイト)に対して非常に強い耐性がある
  4. 各種データの配置場所

    種類 保管場所 役割
    秘密キー 端末 署名を作る
    公開キー サーバー 署名を検証する
    署名データ ログイン時に毎回生成 本人証明
  5. パスキー認証の目的
    • 本当にその秘密キーの持ち主なのか証明する:登録済み秘密キーを保有し、かつ利用権限(顔認証・指紋認証・PIN)を持つことを証明する
  6. SSH との違い
    • SSH:秘密キーを盗まれた → ログインできてしまう
    • パスキー:秘密キーだけでは使えない → 「秘密キー」 + 「顔認証 / 指紋認証 / PIN」両方必要
      • 端末内の TPM や Secure Enclave 等に秘密キーを格納し、本人確認後にしか署名できません
  7. 端末側:チャレンジデータを署名はただの暗号化ですか
    • パスキー(FIDO2)で一般的な ECSDA では、実際には暗号化ではない。「署名アルゴリズムによって署名データを生成する」が正確
      • RSAでは「秘密キーで暗号化して署名」と説明されることもある

SSH 公開鍵認証

サーバーにログインする前に公開キーを登録します。

PC
├─ 秘密キー(id_rsa)
└─ 公開キー(id_rsa.pub)

Linuxサーバー
└─ authorized_keys

ログイン時:

サーバー
↓ Challenge送信

PC
↓ 秘密キーで署名

サーバー
↓ 公開キーで検証

OKならログイン

実はこれもパスワードは送っていません。

コメント

タイトルとURLをコピーしました