分かったようでよく分からないパスキー認証の仕組み - なぜ注目される？

Introduction

WEBの世界では、ユーザーを認証する仕組みとしてパスワード認証が長らく主流となっています。これはクライアント（PC・スマートフォン等の端末）がユーザーIDとパスワードを認証先のサービス（Google、Apple、MS、Amazon、etc）に送信し、サービス側はあらかじめ登録されているユーザーIDとパスワード（通常はハッシュ化され元の文字列が分からない状態のもの）の組み合わせと比較、合致した場合は認証を成功とするものです。すなわち、パスワードという秘密の合言葉を知っている=本人であるとみなすシンプルな仕組み、一見極めて効率的なものと考えられていました。

ところが、ひとたびパスワードが第三者に知れ渡ってしまえば、いとも簡単になりすますことが可能な仕組みとも言えます。昨今 正規のログインページを模した偽のページにパスワードを入力させることでだまし取る手口が蔓延したり、パスワードを保持するサービス側が攻撃を受け情報を流出する等、パスワードの安全性は日々侵され続けています。直近でも大手ISPが提供するメールサービスが攻撃を受け、パスワードを含む顧客情報が流出した可能性があるというニュースが世間に衝撃を与えました。もはやパスワードのみに頼った認証では十分とは言い切れず、二段階認証等のパスワード認証を補完する仕組みも提案されていますが、パスワード自体は廃することはできていません。

そんな今日、パスワード自体を使わない新しい認証方式として注目されているものがパスキー認証です。Google、Apple、MS、Amazonといった大手プラットフォーマーから始まり、徐々に各種サービスでも採用する動きが広がってきています。

「パスキーは安全！」という一言で片づけられがちですが、何で安全・安心といえるのか？そもそもどんな仕組みなのか？利用者の視点でみたときに穴はないのか？

何となくは分かっているつもりでも、ちゃんとは説明できない、いつもの状態に陥っていたので、改めて自分なりに調べてみました。

このエントリーでは私の理解をもとに、パスキーについてまとめてみますが、「パスキーは安全だから使いましょう」という話ではなく、「なぜ安全と言われるのか」「どこまで安全で、どこに限界があるのか」を、できるだけ仕組みから整理してみます。

パスキーとは？

パスキーとは、FIDO（Fast IDentity Online）で標準化された技術を利用した認証方式で、パスワードに代わり安全かつ便利な認証方法を目指して作られた仕組みです。

パスワード認証では「秘密の合言葉（パスワード）を知っていること」を本人確認に利用します。一方、パスキー認証では、パスワードをサーバーへ送ることなく、「秘密鍵を持っていること（もちろん秘密鍵自体も送らず）」を証明することで本人確認を行います。

利用者から見れば、生体認証やPINを入力するだけでログインできますが、その裏では公開鍵暗号方式を利用した認証が行われています。

具体的な認証の流れを例え話を用いて説明してみます。

認証フロー

最初におさらいもかねてパスワード認証の仕組みを見てみましょう。
パスワード認証はあなたがユーザIDとパスワードをサーバーに送り、サーバーがその情報の正しさを検証することで、あなた本人からの正規の要求と判断するものです（パスワードを知っている=本人である）。

次にパスキーの仕組みは次の通りです。
あなたが認証をしたいページを訪れた際、サーバーはあなた宛にチャレンジと呼ばれる文書を送ってきます。あなたはその文書に押印し、サーバーへ返送します。このとき使用する印鑑は端末上の番人によって厳重に管理され、生体情報やPINからあなたからの依頼と判断された場合のみ押印してくれます。サーバー側は押印されたチャレンジと事前に提出された印鑑証明を照合し、合致すれば本人からの正規の要求と判断するものです（チャレンジに押印できる人=本人である）。

パスワード認証とパスキー認証の最も大きな違いは、パスワード認証が「パスワード」という本人であることを証明するもの自体をサーバーに送るのに対し、パスキーは本人であることを証明する「印鑑」は端末から出ていくことはなく、それによって押印された文書（チャレンジ）のみがサーバーに送られること。パスワードと違い、押印された文書（チャレンジ）はそのサーバーに対する、その時限りの要求にしか使えません、仮に流失しても悪用できません、第三者があなたになりすますための情報としては価値がありません。これがパスワードとパスキーの最も大きな違いであり、その強みとも言えます。

もう少しシステマチックに表現すると、サーバーから受け取ったチャレンジに対しクライアント上の認証器（生体認証やPINを確認し、秘密鍵を管理する端末内の仕組み）がユーザー本人からの要求であることを確認した上で、秘密鍵を用いてチャレンジに電子署名を付与する。電子署名が付与されたチャレンジを受け取ったサーバー側は公開鍵を用いて電子署名の正当性を検証、成功したら本人からの正規の要求と判断するものです（公開鍵暗号の仕組みについては後述）。

パスキーのこの仕組みは公開鍵暗号と呼ばれる現在最もポピュラーで安全性の高いといわれる仕組みの上で成り立ち、印鑑は「秘密鍵」、印鑑証明は「公開鍵」と呼ばれます。

パスキーがどんなものか、少しイメージはついてきたでしょうか？次にここまで理解した中で私が疑問に思ったポイントについて紐解いていこうと思います。

よくある疑問

PINや生体認証情報はサーバーに送られない？

送られません。PINや生体情報は電子署名を付与する際、認証器が本人確認するためだけに使用するものであり、サーバー側に送られることはありません。サーバー側で持っておくメリットがそもそもありません。

秘密鍵は端末内で厳重管理、端末を紛失したり機種交換したらどうなる？

ここがパスキーを理解する上で一番混乱したポイントでした。パスキーには2つの運用形態があります。

• デバイス固定パスキー
• 同期パスキー

前者は完全に端末内で閉じたものとなり、もし端末を紛失したり機種変更した場合は再度パスキーの設定が必要になります。一方の後者は大手プラットフォーマー（Google、Apple、MS）が提供するアカウントに紐づけられ、同じアカウントでログインした端末間では相互利用できる仕組みとなっています。故に新しい端末が増えたケースであっても同じアカウントでログインすればパスキーも引き継がれ、これまでと同じように利用することができます。

セキュリティ的な観点で見たとき、一見するとデバイス固有パスキーの方が安全に思えますが（秘密鍵を外部に置かないため）、そこは利便性とのトレードオフなのかなと。

偽のサイトがチャレンジを送ってきたらどうなる？

チャレンジや電子署名に使用する鍵にはRP ID（Relying Party Identifier）と呼ばれる認証先のサービスを識別する情報が付与されています。ここにはパスキーをリクエストするドメイン名が当てられるため、仮に偽のサイトがチャレンジを送ったとしても正規のRP IDは設定されないため（偽サイトと正規のサイトではドメインが異なるため）、クライアント側は該当する（偽サイトの）RP IDの鍵がなくチャレンジは成功しません。よって偽サイトがチャレンジを送ってきたとしても何もできません。

仮に偽サイト用のパスキーが作成されたとしても、それはあくまで偽サイト専用です。正規サイトに対する認証には利用できません。

サーバー側が公開鍵を漏洩したらどうなる？

公開鍵はその名の通り「公開されること」を前提とした鍵です。公開鍵は電子署名を検証するためにしか利用できないため、仮に漏洩したとしても何の害もありません。

公開鍵から秘密鍵（電子署名する際に使用する鍵）をリバースすることは理論上 不可能ではありませんが、現代最高峰のコンピューターを駆使したとしても。。。現実的な時間では解読できないといわれています。

もし電子署名付チャレンジが盗まれたら？

前述した通り、チャレンジはあるタイミングのリクエストに対して1回限りしか利用できません。またチャレンジの有効期間は長くて数分と短いものです。それ故に仮に盗んだとしてもパスワードのように1度入手すれば何度も使うことができるような代物ではありません。

さらに現実には通信自体もTLSで暗号化されているため、チャレンジを盗み見ること自体も容易ではありません。（もしそれができれば、チャレンジやパスワードを盗まなくてもやりたい放題できちゃう。。。）。

パスキーなら絶対安全？

パスキー認証は確かにパスワード認証と比べリスクの小さい方式ではありますが、だからと言って絶対安全、盲目的に信用してよいもではありません。セキュリティの世界に「絶対」は存在しません。

パスキーを導入した認証システム全体の問題の1つにパスワード認証が並行し残っている現実があります。現在パスキーは過渡期といえ、パスキーだけですべての認証が賄える状態に至ってはいません。設定したパスキーが正しく動かないケースや予期せぬ端末の故障等に備え、多くのサービスがパスワードによる認証を残しています。つまりそのパスワード使った認証が残っている以上、パスキーを使っていても絶対安全とは言えないのです。

例えば、悪意のある第三者が「パスキーの再設定が必要になりました、パスワードを入力し再設定してください」とメールを送ってきたらどうなるでしょう？ユーザー目線ではパスキーの再設定なのでパスキーは使えない→バックアップ用のパスワードの入力を求められることは至極自然なことに感じてしまいます。そうしてパスワードを盗まれてしまうと、そのパスワード認証が残っている限り、アカウントへの不正アクセスにつながるおそれがあります。

パスキーによって玄関の防御をいくら高めても、裏口（パスワード認証）が今まで通り残っていればそこを突かれてしまう、パスキーを使っていれば絶対安全とは言えない一例にあたります。

パスキーは、パスワード認証が抱えていた多くの問題を解決してくれる、とても優れた技術です。しかし、セキュリティは認証方式ひとつで決まるものではありません。アカウント復旧や例外時の運用を含めた「認証システム全体」で考える必要があります。

「パスキーだから安全」ではなく、「どこまで攻撃の余地を減らせるか」。その積み重ねこそが、現実のセキュリティ設計なのだと思います。

パスキーを支える公開鍵暗号とは

最後にパスキーを支える公開鍵暗号方式について簡単に説明したいと思います、興味がある方はぜひ。

この方式は現代において最も普及している方式で、情報を暗号化して安全に送る用途だけでなく、電子署名によって送信者が本人であることを証明する用途にも利用されています。

大きな特徴として、公開鍵と秘密鍵という鍵のペアが作られる点が挙げられます。この2つの鍵は対になる関係にあり、それぞれ役割が決まっています。例えば、秘密鍵でしかできない処理や、公開鍵でしかできない処理があります。

パスキーで利用される電子署名では、秘密鍵を持つ人だけが文書に電子署名を付与できます。一方、その電子署名が本物かどうかは、誰でも公開鍵を使って検証できます。

つまり、

• 電子署名を作成できるのは秘密鍵を持つ本人だけ
• 電子署名が正しいかどうかは公開鍵で誰でも確認できる

という役割分担になっています。

パスキー認証では、この性質を利用してサーバーが送ったチャレンジに対し、クライアントが秘密鍵で電子署名を付与します。サーバーはあらかじめ登録されている公開鍵を使ってその電子署名を検証し、正しいことが確認できれば「秘密鍵を持つ本人からの要求」であると判断します。

重要なのは、秘密鍵は認証時であっても端末の外へ送られないという点です。サーバーへ送られるのは電子署名が付与されたチャレンジだけであり、秘密鍵そのものが漏えいすることはありません。

もちろん、公開鍵から秘密鍵を求めることは理論上不可能ではありません。しかし公開鍵暗号方式は、現在知られている計算方法では現実的な時間で解くことが極めて困難な数学的性質を利用しています。そのため、現代の計算能力では十分に安全な方式として、パスキーだけでなくインターネット上の暗号通信や電子証明書など、さまざまな場面で利用されています。

まとめ

パスキーという何だか掴みどころのないものについて、その仕組みやぱっと思いつく疑問点、パスワード認証との比較についてまとめてみました。

パスキーの仕組み、パスワードに比べた優位性は腹落ちしたものの、パスワード認証がバックアップ的に残っている現状等も加味すると、それ単独で導入したから絶対安全といえるものではない、という点も改めて理解できました。

セキュリティ対策は、個々の技術だけを見て評価するものではなく、アカウント復旧や例外時の運用も含めた「認証システム全体」で考え、リスクと利便性のトレードオフを見極めることが大切と改めて感じました。

参考文献

FIDO認証＆パスキー総復習（認証の仕組みやパスキー登場までの経緯）- Yahoo! JAPAN Tech Blog