世界を動かす技術を、日本語で。

パスキーの背後にある暗号技術

概要

  • 暗号技術では 認証 も暗号化と同じくらい重要であることを強調
  • Passkey は公開鍵暗号をベースとした認証方式で、 WebAuthn 仕様に準拠している
  • Passkeyは フィッシング耐性 やパスワード再利用防止など、多くのセキュリティ強化を実現
  • しかし 完全な安全性 はなく、ブラウザや認証器の脆弱性、認証情報衝突などのリスクも存在
  • 適切な リカバリー機構 や運用上の注意が必要であることを指摘

パスキーの暗号基盤とWebAuthnのセキュリティ

パスキーの基本構造と認証プロセス

  • Passkey は公開鍵暗号ペア(公開鍵・秘密鍵)を用いる認証方式とすること
  • 登録時に 公開鍵と識別子 をウェブサイトへ保存し、秘密鍵はユーザー端末に保持すること
  • 認証時は、ウェブサイトが チャレンジ (ランダムな値)を発行し、ユーザーが秘密鍵で署名して応答すること
  • サーバーは 公開鍵 で署名を検証し、ユーザーの正当性を確認すること
  • サーバーには秘密情報が送信されず、 リプレイ攻撃防止 も実現すること

パスキー単体の課題とWebAuthnによる解決

  • デジタル署名のみでは フィッシング鍵ペアの再利用 を防げないこと
  • WebAuthn 仕様は「オリジンバインディング」により、正規サイトでしかパスキーが使えないよう制御すること
  • オリジン(ドメイン名)情報を認証器へ伝達し、異なるサイトでのパスキー利用を防止すること
  • 各サイトごとに 固有の鍵ペア を生成し、パスワード再利用問題を解消すること
  • HTTPSのみ許可 し、有効なサーバー証明書が必須となること

認証器の種類と特徴

  • 認証器は「 所持しているもの」に該当し、ユーザー存在確認を必須とすること
  • 主な種類:
    • プラットフォーム認証器 :端末内蔵型(例:iCloud Keychain, Google Password Manager, Windows Hello, 1Password)
      • 利便性・クラウドバックアップ可能だが、端末侵害時は脆弱となること
    • ローミング認証器 :外部ハードウェア型(例:YubiKey, Titan Security Key, Feitian keys)
      • 高いセキュリティ隔離・端末依存性なし、紛失時の復旧不可
  • Bluetooth等で クロスプラットフォーム利用 も可能とすること
  • 高価値用途では 専用ハードウェア認証器 の利用を推奨すること

パスキーの登録・保存・管理方法

  • 登録時、認証器が パスキーと識別子(credential ID) を生成し、ウェブサイトが公開鍵・識別子を保存すること
  • 一部認証器はパスキー自体を保存できず、 暗号化したパスキー を識別子としてウェブサイトへ渡す方式も存在
  • 認証時、ウェブサイトが識別子をブラウザ経由で認証器へ渡し、認証器が復号・署名を行うこと
  • パスキーのバックアップ家族アカウント共有 など、プラットフォーム独自の運用も増加していること

認証器の信頼性証明(アテステーション)

  • 認証器は アテステーション証明書 を用いて、製造元などの情報を証明できること
  • 企業用途では、特定のセキュリティ要件を満たす認証器の運用を強制可能とすること
  • アテステーションは オプション であり、全認証器が対応必須ではないこと

パスキー紛失・リカバリーの課題

  • 認証器の紛失や故障時は 全パスキーが失われる リスクがあること
  • クラウド同期によるバックアップは可能だが、 攻撃対象面の拡大 にも注意すること
  • ウェブサイト側は リカバリー機構 の実装が必須だが、攻撃者による悪用リスクも考慮すること

脅威モデルと残るリスク

  • Passkey はパスワードの持つ多くの脅威(フィッシング、再利用)を排除可能とすること
  • ただし、 完全な安全性 は保証されず、以下のような攻撃が残ること:
    • ブラウザ攻撃 :認証器が表示機能を持たない場合、ブラウザが不正なサイト情報を表示する恐れ
    • 認証器の侵害 :偽造・バックドア認証器やマルウェアによる秘密鍵の窃取リスク
    • ユーザー端末の完全侵害 には無力であり、認証器ごとの ユーザー操作が攻撃のレートリミット となるのみ
    • ドメイン乗っ取りやサブドメインハイジャック には対応できないこと
  • credential IDの衝突 リスクも考慮し、仕様上は「確率的に一意」であることが求められるが、完全な衝突排除は不可能とすること

credential ID衝突の具体的リスク

  • 攻撃者が被害者のcredential IDを知っている場合、同じIDでパスキー登録を試みることによる 認証混乱 の可能性
  • 悪意ある認証器アプリが 重複credential ID を意図的に生成するリスク
  • 実装バグで 乱数性が低下 し、衝突確率が上がる事例

このように、 PasskeyとWebAuthn は現代ウェブ認証のセキュリティを大きく向上させるが、 運用・設計・実装上の注意点 を正しく理解し、リスクを最小化することが重要である。

Hackerたちの意見

パスキーが大好き!スマホにあって、生体認証が必要なのもいいね。ただ、ベンダーロックインが嫌なんだ。これについての標準の状況を知ってる人いる?何か対策を考えてるって聞いたけど、最近は追いかけてないんだよね。

ベンダーロックの部分について詳しく教えてくれる?パスワードマネージャーにパスキーを保存してるから、結構ポータブルだと思ってるんだけど。各サービスがユニークなパスキーを要求するってこと?それって、各サービスが自分のTOTPシードを必要とするのと似てるよね。

私にとって、パスキーが実用的なのはクラウドにバックアップして、デバイス間で自動的に同期できるからだけ。そうじゃなきゃ、全然信用できない。

どうやってベンダーロックインを打破するつもりなのか、いつも聞いてるんだ。結局、自分を認証するための秘密を使ってるわけでしょ。ベンダーが管理してるパスキーだと、そのベンダーに秘密を管理してもらうことになる。もしそのベンダーが秘密を他の誰かに渡せるなら、誰がその秘密を知ってるか確認できなくなるよね。秘密を広めるプロトコルを考えられるかもしれないけど、それだとみんなのコミュニケーションの負担が増えるだけだと思う。もっと賢い人が驚かせてくれるかもしれないけど、歴史的に共有できる秘密は長くは秘密じゃないよね。

自分のYubikeyをaccount.google.com(他のウェブサイト、例えばfastmail.com)でパスキーとして登録できるよ。アカウントのセキュリティページ[0]に行って「可能な場合はパスワードをスキップ」を有効にすれば、Yubikeyを使ったパスキーだけでGoogleにログインできる。Yubikeyに古いGoogleのクレデンシャルがある場合は、まずそれをアカウントから削除しないといけない(古いプロトコルと新しいプロトコルがあって、古いプロトコルが有効だとGoogleはパスワードなしのログインをサポートしないから)。バックアップが欲しいなら、複数のYubikeyが必要だよ。キー間の同期はないからね。サポートマトリックスについては[1]を見てね。[0]: https://myaccount.google.com/security [1]: https://passkeys.dev/device-support/

Androidでは、Keepass2Androidの開発者が近い将来にパスキーをサポートするために取り組んでるみたい(https://github.com/PhilippC/keepass2android/issues/2099)。正直言うと、パスキーについて十分な時間をかけて学んでないから、そのアプリがすべての実装をサポートして、ベンダーロックを完全に避けられるかは確信が持てないんだ。

FIDOアライアンス(W3Cと一緒にWebAuthn仕様を書いたところ)が、パスキーや他の認証情報を移行するためのフォーマット(Credential Exchange Format)とプロトコル(Credential Exchange Protocol)のドラフト仕様を持ってるよ。[1] まだどのプロバイダーも実装してないと思うけど、取り組んでるみたい。[1] https://fidoalliance.org/specifications-credential-exchange-...

1Passwordは、iPhone、Mac、Linuxボックスのすべてのパスキーと統合されてるよ。私にとっては、サブスクリプションの価値があるって感じ!

この件に関する標準の状態を知ってる人いる?キーのエクスポート/輸送は実装者の任意みたいだけど、私の解決策はBitwardenを使うことだから、少なくともクロスプラットフォームのキーが手に入るよ。

自分はBitwardenを使ってパスキーを保存してるよ。すべてのデバイスに同期されて、普通に動くし、問題もほとんどない。ほんとに心配性の人は、自分のサーバーでオープンソースのバックエンドを運用することもできるよ。https://bitwarden.com/passwordless-passkeys/

パスキーは人気出てきてるの?

あんまり使わないな、登録してデバイスエコシステム間で使う良い方法がないから。3つのOSを定期的に使ってるよ。

Hacker Newsで議論の続きを見る