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

こんにちは。サービス統括本部ID本部で認証サービスの開発運用を担当している服部です。

パスワードに代わる新たな認証手段としてパスキーが登場し、多くのサービスでも利用ができるようになってきていますが、みなさんはご活用されていますでしょうか。このパスキーとはパスワードに代わる認証情報で、Fast IDentity Online（FIDO）仕様というFIDOアライアンスによって規格策定されている技術をベースとしています。ヤフーでも2018年から「生体認証でログイン」としてFIDO認証に対応し、2023年よりパスキーをつかった認証にも対応しています。

この記事ではこのFIDO認証の技術的な説明から当時の課題と解決方法、そしてその解決方法を前提として登場したパスキーについて解説します。

FIDO認証とは

FIDO認証とは、FIDOアライアンスによって規格策定されている認証技術仕様にのっとった認証方法で、パスワードに代わって安全かつ便利な認証方法を目指して作られています。

ヤフーでFIDO認証を行った際は以下のようなフローとなります。

このようにFIDO認証は生体認証（画面ロック解除）を行うことでWebサイトにログインが成功します。そのため、ユーザはSMSで送られる確認コードの受信を待ったりパスワードを覚えたりする必要はありません。

このFIDO認証の流れを簡単に説明すると以下のようになります。

次節ではこのFIDO認証の特徴を解説します。

1.公開鍵暗号方式

FIDO認証では公開鍵暗号方式を用いて認証が行われます。もう少し具体的にフローを説明すると以下になります。

• 登録フロー
  1. サーバがそのフローでのみ利用されるランダムな文字列（チャレンジ）を発行する
  2. クライアントがデバイス内で公開鍵ペア（FIDOクレデンシャル）を作り、公開鍵、チャレンジ、それらの署名データ※をサーバに送信する
  3. サーバは受信したチャレンジや署名データを検証する
  4. 検証に成功できた場合、公開鍵をユーザアカウントに紐づけて保存する
• 認証フロー
  1. サーバがそのフローでのみ利用されるチャレンジを発行する
  2. クライアントはチャレンジに対して秘密鍵で署名してサーバに送信する
  3. サーバは発行したチャレンジと保存済みの公開鍵を用いて受信した署名データを検証する
  4. 検証に成功できた場合、認証成功

※ 登録時に作成される署名データはデバイスごとに形式が異なります。また署名を作成しない形式も存在します。https://www.w3.org/TR/webauthn-3/#sctn-defined-attestation-formats （外部サイト）

この特徴のメリットはサーバに保存されるのは公開鍵のみとなる点です。もしサーバ側から公開鍵が流出したとしても適切な署名データを作成することはできないため、攻撃者は正規ユーザのアカウントになりすますことはできません。

2.originごとにFIDOクレデンシャルが管理されている

公開鍵ペアであるFIDOクレデンシャルは認証器（Authenticator）で作成/管理されています。この認証器はデバイスに内蔵されているものや物理的なセキュリティキーとよばれる専用デバイスなどがあります。そしてブラウザやアプリはAPIを通じて認証器からFIDOクレデンシャルの公開鍵を取得したり、署名作成を行います。

この認証器内のFIDOクレデンシャルにはRelying Party Identifier（RPID）というサービスごとの識別子が設定されています。そのためブラウザやアプリはFIDOクレデンシャルの作成や署名の作成を行う際にこのRPIDを指定する必要があります。RPIDはブラウザやアプリから自由に指定することはできず、現在アクセスしているサービスのoriginのdomain部と完全一致または後方一致したもののみが指定できます。このことから、domainの異なるフィッシングサイト上では正規サイトのRPIDを指定できず、正規サイトのFIDOクレデンシャルの作成や署名ができません。

たとえば、現在ブラウザが表示しているサイトURLがhttps://login.yahoo.co.jpの場合、そのdomain部に後方一致しているyahoo.co.jpというRPIDで管理されているFIDOクレデンシャルで署名を作成できます。

このようにFIDO認証では正規サイトのURL判別およびその記憶をシステム的に行うため、パスワード認証やSMS認証と違いフィッシング攻撃への耐性があります。

3. 本人検証をする生体認証データは認証器内でのみ利用される

FIDO認証というと生体認証を用いてWebサイトのログインを行っているイメージが強いかと思います。この生体認証は認証器がFIDOクレデンシャルを作成または署名を行う際に求められるのですが、それはあくまでユーザと認証器間の本人検証のために実施されます。つまり、ここで利用される生体認証データはクライアント側（認証器）でのみ扱われブラウザやサーバ側に送信されません。

なおスマートフォン（Android/iOS）での本人検証は画面ロックの解除を用いて行われています。そのため必ずしも指紋/顔といった生体認証で本人検証をする必要はなくPINやパターンロックなどでも本人検証が可能です。

FIDO認証の課題

ここまでの説明でFIDO認証は安全な認証であることを説明しましたが利便性の面で課題がありました。それはFIDOクレデンシャルを管理しているデバイスの紛失や機種変更をした場合にFIDO認証ができなくなってしまう課題です。

また前述の課題と少し似ていますが、FIDOクレデンシャルをもっていない2台目以降のデバイスでもFIDO認証ができないという課題も存在しました。たとえばスマートフォンでアカウント登録と同時にFIDOクレデンシャルの登録をした場合、別のデバイスであるパソコン上にはFIDOクレデンシャルが存在しないのでFIDO認証ができません。

これらの課題はFIDOクレデンシャルが単一デバイス内でのみ管理されているという仕様から発生しています。

マルチデバイス対応FIDOクレデンシャルの登場

前章ではFIDO認証においてデバイスの紛失や機種変更、2台目以降のデバイスでFIDO認証ができないという課題がありました。この課題の解決につながる仕様とユースケースを紹介したものとして、Yahoo! JAPAN研究所の大神が執筆したホワイトペーパーがあります。こちらに関しては大神から解説記事が投稿されていますのでご興味ある方は参考にしてみてください。
パスワードレス認証のアカウントリカバリーの必要がない戦略とは - Yahoo! JAPAN Tech Blog

そして前述のホワイトペーパーから発展し、後述する「パスキー」と密接に関わる仕様を提案したのが「ホワイトペーパー：マルチデバイス対応FIDO認証資格情報」です。このホワイトペーパーでは主に2つの仕様がピックアップされています。

1.FIDOクレデンシャルのデバイス間同期

これまでのFIDOクレデンシャルの秘密鍵はデバイス内にのみ保存され、デバイスの紛失や機種変更が発生する度にFIDO認証ができなくなってしまう課題がありました。この課題に対して、FIDOクレデンシャルをデバイス間で同期できるようにするというのがこの仕様です。

2023年8月現在、AndroidであればGoogle パスワード マネージャー、iOS/iPadOS/macOSではiCloud キーチェーンによってFIDOクレデンシャルを同期することができます。一方でAndroidとiOS間でFIDOクレデンシャルを同期する機能は提供されていません。このプラットフォームをまたいだ共有は「The Credential Migration Protocol」として提案されている仕様によって実現できる可能性があります。

なお、複数デバイスでFIDOクレデンシャルが同期される際はエンドツーエンドで暗号化されています(※)。そのためサーバ側での不正アクセスから保護されるようになっています。

※ Apple: https://developer.apple.com/jp/passkeys/ （外部サイト）
※ Google: https://developers.google.com/identity/passkeys?hl=ja （外部サイト）

2.デバイス内蔵の認証器を別のデバイスから利用する（hybrid/Cross-Device Authentication）

前節で紹介した仕様によって、AndroidはAndroid同士、iOSであればiOSまたはiPadOSやmacOS間でFIDOクレデンシャルを同期させることができます。しかし、2台目以降のデバイスにFIDOクレデンシャルが同期されないケースではFIDO認証ができない課題は残っています。たとえば、AndroidとWindowsを持つユーザが、最初にAndroidでFIDOクレデンシャルを登録した場合、その後WindowsではFIDOクレデンシャルが端末内にないためFIDO認証ができません。

この課題に対して解決策が、スマートフォンなどのデバイスに内蔵された認証器をパソコンなどの別デバイスから利用できる仕様です。この仕様は「hybrid（またはhybrid transport）」や「Cross-Device Authentication」と呼ばれています。

実際の使用例はGoogle Chrome DevelopersがYouTube上で公開している動画がわかりやすいためここで紹介します。

ヤフーでもFIDOクレデンシャル未登録のデバイスでログインする際にFIDOクレデンシャル登録済みデバイスに内蔵される認証器を利用できます(※)。

※ ログイン時FIDOクレデンシャルが未登録のOSではFIDO認証が自動発動しないため、「他の認証方法」→「指紋・顔など」でFIDO認証フローを発動させる必要があります。

この図のフローではQRコードを表示/スキャンを通じてパソコンとスマートフォン間のBLE（Bluetooth Low Energy）のペアリング/通信を行っています。そしてここで確立した経路を用いて従来のFIDO認証のフローを実行しています。

この仕組みはセキュリティ観点からいくつかの特徴があります。なお、ここでは攻撃者がクレデンシャル未登録デバイスを所持し、正規ユーザがクレデンシャル登録済みデバイスを所持している前提で話をします。

1. デバイス間の通信はBLEで行われるため、クレデンシャル未登録デバイスと登録済みデバイスが物理的に近い距離にいないとFIDO認証の署名データが送信されない。
2. ここで表示されるQRコードやサーバ側から発行されるチャレンジには期限が存在する。
3. 正規ユーザのクレデンシャル登録済みのデバイスで画面ロックなどの本人検証を実施する必要がある。（サービスの設定によっては省略される場合もあります）

この仕組みを通じて攻撃者が用意したデバイスでログインを成功させるには、

1. 正規ユーザのデバイスに物理的に近い距離にいる
2. クライアントが生成したQRコードをサービスが指定する時間内に正規ユーザのデバイスで読み込ませる
3. 正規ユーザにQRコードをスキャンさせた後に画面ロックを解除させる

のすべてを満たす必要があります。よってこの仕組みを通じて攻撃者が正規ユーザのFIDOクレデンシャルを窃取するのは難易度が高いと思われます。

※「QRコード」は株式会社デンソーウェーブの登録商標です。

パスキーとは

前述のホワイトペーパーで紹介された仕様のうち、デバイス間同期ができるFIDOクレデンシャルを一部で「パスキー」とよばれるようになりました。Apple、Google、MicrosoftがFIDO標準のサポート拡大にコミット、パスワードレス認証の普及を促進 - FIDO Alliance （外部サイト）

ただしこのパスキーの定義は2023年8月のFIDOアライアンスによる定義とは少し異なる部分があります。この章ではそこに焦点を当ててパスキーの定義について解説をします。

パスキーという単語の定義

2023年8月の段階において、FIDO Alliance: Passkeys (Passkey Authentication)のQ&Aにある「WHAT IS PASSKEY?」では以下のように説明されています。

From a technical standpoint, passkeys are “discoverable” FIDO credentials for passwordless authentication.

つまり、FIDOアライアンスは技術的観点においてdiscoverable FIDOクレデンシャル（以下、discoverable credential）をパスキーと定義しています。このdiscoverable credentialとは、今まで説明してきたFIDOクレデンシャルにユーザ識別子が含まれているものです。FIDOクレデンシャルにユーザ識別子が含まれていることで、サービスはユーザにIDの入力を省略するような機能を提供できます。

章の頭で「デバイス間同期ができるFIDOクレデンシャルを一部でパスキーと呼ばれている」と記述しましたが、この定義からするとdiscoverable credentialであればデバイス間同期がされていないFIDOクレデンシャルもパスキーとなります。

表にまとめると以下のようなイメージになります。

FIDOクレデンシャルのデバイス間同期の機能はすべてのデバイスでサポートされているわけではありません。そのようなデバイスを所有するユーザが登録したFIDOクレデンシャルにおいてもパスキーと呼ぶことができます。

パスキーの特徴

まず第一に挙げられるパスキーの特徴として「デバイス間で同期できる」点が挙げられます。前述のとおりパスキーのなかにはデバイス間同期ができないものも含んでいますが、最新OSなどで作成されるパスキーはデバイス間同期されるものがほとんどです。なお、現在の対応状況についてはpasskeys.devのdevice-supportをご確認ください。

その他パスキーの特徴としてサービスへログインする際にアカウントセレクタが利用できる点があります。ユーザはIDを入力することなく、このアカウントセレクタで表示されたアカウントを選択するだけでログインが可能です。このアカウントセレクタの活用例としてWebAuthn Autofill(Conditional UI)という機能を紹介します。下図のようにID入力欄にフォーカスするとクライアント側にパスキーが保存されている場合アカウント名と「Touch IDを仕様」という選択肢が表示されます。この選択肢をクリックするとTouch IDが発動し、ログインが成功します。（この図ではmacOSを用いた例であり、他のOSでは異なるUIが表示される場合があります）

https://passkeys-codelab.glitch.me/ より

おわりに

以上が昨今のFIDO認証の仕組みや仕様とパスキー登場までの経緯、およびFIDOアライアンスでのパスキーという単語の定義でした。

FIDOの仕様が定まった当時、FIDO認証はセキュリティ的に優秀であったがUX的な課題が残っていました。昨今ではその課題も解消されつつあり、今後もさらに利便性は向上されていくと思われます。パスワードを用いた認証は脆弱（ぜいじゃく）であるというのはすでに広く認知されている問題だと思いますが、パスキーが登場したことを機に多くのサービスでも対応され、パスワードによる不正アクセスの被害が減ることを願っています。