おはようございます、ritouです。
何の話？
最近のユーザー認証を取り巻く状況について、次の2つの事例の共通点を考えましょう
- Passkey(FIDOアライアンスが言ってるMulti-Device FIDO Credentialsの方)はFIDOクレデンシャルがApple/Google/MSといったプラットフォーム(など)のアカウントに紐づけられる仕組み
- Google Authenticator のクレデンシャル管理がデバイス単位からGoogleアカウントに紐づくデバイス間で同期されるように変わる
これらは "クレデンシャル" と呼ばれる、秘密鍵やパスワードなどの "認証のための情報" をデバイス単位ではなくプラットフォームアカウント単位に保存/管理するというお話です。
そのおかげで、新しいデバイスを使い始める際にこれまで利用してきたサービスに対して色々と設定しなおすことなく、AppleやGoogleアカウントを設定してゴニョゴニョするだけで今までのデバイスと同様に利用できますよ、というのが謳い文句となっています。
本投稿では
- 「プラットフォームアカウントに紐づいたクレデンシャルを利用する認証デバイス」をどう捉えるべきか
- プラットフォームアカウントとのID連携との違い
について考察します。
※Google AuthenticatorのE2EEの話はしません
認証方式とクレデンシャル管理
世の中で使われているいくつかのユーザー認証の説明において、いわゆる認証要素と呼ばれるもので分類されることがあります。 私たちは以下の3つの中のどれか、もしくは組み合わせによってユーザー認証の特徴を表現してきました。
- 記憶 : Something You Know(SYK)
- 所持 : Something You Have(SYH)
- 生体 : Something You Are(SYA)
パスワード認証はSYK, SMS OTPや公開鍵暗号を用いた認証方式はSYH, 指紋や顔を用いたいわゆる生体認証はSYAに分類されます。 FIDOでは、公開鍵暗号方式(SYH)とローカル認証(SYA or SYK)が組み合わせられることで高い認証強度を実現できていると説明されています。
ここまでのところでは、それほどプラットフォームアカウントの概念は出てきません。 そこで一段深掘りして、このようなユーザー認証を実現するためのクレデンシャル管理に着目した時に出てきます。
- パスワード認証 : 人体の記憶領域、パスワードマネージャー、デスクトップに貼られた付箋、エンディングノート
- TOTP : 設定したデバイス、もしくはプラットフォームアカウントや専用アプリのアカウントが所有する複数デバイス
- FIDO/Passkey : 端末やセキュリティキーのTPM、もしくはプラットフォームユーザーのクラウドストレージ
このクレデンシャル管理の多様化によって影響を受けるのが、最初に挙げた3要素の中の所持要素(SYH)です。 クレデンシャルの保存箇所について、当初はユーザー本人の記憶や設定したシングルデバイスのみに保存されている前提が一般的だったと思います。 複数デバイスで(暗号化を駆使しつつ)の同期について語られることが増えたのは、パスワードマネージャーやTOTPでAuthyのような専用アプリが登場したあたりでしょうか。 現状はパスワードもChromeやSafariのようにブラウザに関連するプラットフォームアカウントに紐づけて保存する仕組み、1Passwordのようなアプリのアカウントに紐づく管理はもはや普通に行われていますし、PasskeyやGoogle Authenticatorの動向からもその勢いが加速していることがわかります。
プラットフォームアカウントをキーとしてクレデンシャルを奪われるリスク
このようなクレデンシャル管理は端末が壊れた時や新規端末を使い始めたときにとても便利です。しかし、クレデンシャルの漏洩というリスクを考えると頭を抱えてしまうこともあるでしょう。 具体的にいうと、これまで想定されていた "デバイスのコントロールを奪われる" リスクに加えて "プラットフォームアカウントを奪われる" リスクについても考慮する必要が出てきます。
もうちょっと細かい話をすると、"複数デバイスにクレデンシャルが保存されている状態" と "プラットフォームアカウントに紐づけられた複数デバイスでクレデンシャルが同期されている状態" は特性が異なります。 "複数デバイスに..." は単純に管理しなければならないデバイスが複数ある話なのでいずれかのコントロールを奪われることだけがリスクとなるわけですが、"プラットフォームアカウントに..." はプラットフォームアカウント自体のクレデンシャル管理が一番の肝となります。
C向けのサービスであればユーザーの責任でこの辺りちゃんとやってねとなるのかもしれませんが、B向けのサービスとなるとデバイス管理の方法というところから考慮が必要となるでしょう。
これまでも議論を呼んでいたメールOTP
これまでの人生において、いくつかのユーザー認証の方式を比較しながら説明してきました。その中でたまに議論になっていたのが "メールOTP" の扱いです。 ユーザー認証を要求するサービスは対象アカウントのメールアドレス宛にOTPを送信し、受信したOTPを画面のフォームなどに入力することで認証する方式です(リンクを踏ませるものもありますがその辺はおいておきます)。
この認証方式を SYH と捉える場合、所有しているのは "メールを受信できる環境" です。 SMSの場合、"SIMが設定されてSMSを受信可能なデバイス" とすると(通信網に依存はするものの)一意に識別可能な端末として扱えますが、メールに関してはメールアプリに "メールアカウントが設定されている端末" となります。 そのメール設定のためにはメールアカウントのクレデンシャルもしくはメールアカウントを提供するサービスとのOAuthによる設定が必要ですし、その対象はシングルデバイスではなく複数デバイスのメーラー、そしてWebアプリだったりもします。このため「メールOTPはSYHの扱いとしてどう扱うべきか」みたいな議論は以前からありました。
今回の "プラットフォームアカウントにクレデンシャルが紐づく" ユーザー認証についても、上記の."メールアカウント" の話に近いものがあります。 ここで "メールアカウントやプラットフォームアカウント、専用アプリのアカウントの認証強度とは？" を詰めていけば全て整理できるのではと考えたくなるのですが、メールアカウントの例で設定方法がパスワードからOAuthの形式に変わったりしてメールアカウントのユーザー認証と分離されるようになったように、 "プラットフォームアカウントがどの認証方式を採用しているのか" というところに依存することで認証強度の解釈が多段というか複雑になり、統一的に語れなくなるでしょう。 よって、今後は "プラットフォームアカウントに紐づく" というクレデンシャル管理のパターンをしっかり定義して、使っていく必要があるででしょう。
プラットフォームアカウントによるID連携との違い
Apple信者という言葉はなんだか信仰のなんたらを意識してしまいそうなので、例えばGoogleプロダクト大好きさんがいたとします。
- Google Chrome にパスワード、Google AuthenticatorでTOTPのSecretを保存した状態で2FAでログインする
- Android で同期しているパスキーを利用してログインする
- Sign In with Google(ID連携)でログインする
これらのユーザー認証はいずれもクレデンシャル管理をGoogleアカウントが支えている状態なので、Googleアカウントがあれば新しいAndroid端末からすぐにこれらのユーザー認証を利用できます。では、1,2 と 3 の違いは何があるでしょうか？
- 認証方式の違い : 1,2 は認証を行うサービス側からパスワード、TOTP、FIDOという方式を固定してユーザーに要求しますが、3はどの認証方式を利用するかはプラットフォームやユーザー自身により決められます
- 他プラットフォームアカウントの利用 : 1,2はAppleプロダクト大好きさんであればSafariとAppleアカウント、iCloud Keychainのパワーで同じようなことができますが、3はサービスがSign In with Appleに対応する必要があります
- プラットフォームアカウント情報のやり取り : 3はOIDCの仕組みなどによりプラットフォームアカウントの属性情報をサービスに渡せますが 1,2 は基本的にそれができません。
というところで、1,2はユーザーから見たらプラットフォームアカウントに依存しているがサービス側からは見えない、言うなれば "シャドーID連携" といった感じに見えます。特定のOSやブラウザ、アプリの組み合わせによってはID連携と似たようなUXとなることはあるものの、細かい違いがあること、そして逆にプラットフォームアカウントによるSPOFを避けるためには、パスワードと2FAで利用するクレデンシャルが紐づけられているプラットフォームアカウントを分けるという方法もあるということを意識しましょう。
ユーザー認証に関わるガイドラインについて
ユーザー認証というかIdentity管理について様々な仕様から参照されているガイドラインは "NIST SP 800-63 Digital Identity Guidelines" です。現行のものは63-3というもので、63-4が現在策定中です。
OpenIDファウンデーション・ジャパンによる翻訳に参加された方のTweetで63-3と63-4で今回の話と関連する記述の変更がされているようでその影響ではないか、という意見が見られました。
お〜これはきっとNIST SP800-64 revision4でOTP AuthenticatorsやCryptographic Software Authenticatorsの記述が変わったこと（「鍵の複製をdiscourageすべき」という文言が削除された）が影響しているように思いました。 https://t.co/y6VbJs0913
— Hitomi Kimura (@hitok_) 2023年4月25日
対象はSP 800-63B Authentication and Lifecycle Managementというドキュメントです。 63-3では複数デバイスでの秘密鍵保持に対して否定的でした。
OTP authenticators — particularly software-based OTP generators — SHOULD discourage and SHALL NOT facilitate the cloning of the secret key onto multiple devices.
63-4ではデバイス変更時にユーザーアカウントに紐付け(て移行し)、古い方消せみたいな雰囲気の記載になっています。
If a subscriber needs to change the device used for a software-based OTP authenticator, they SHOULD bind the authenticator application on the new device to their subscriber account as described in Sec. 6.1.2.1 and invalidate the authenticator application that will no longer be used.
表現の仕方が変わったとはいえ、あまり複数端末でクレデンシャルを同期してどっちもアクティブなまま使えることまでは想定していないように見てとれます。
繰り返しになりますが今までもTOTPを複数デバイスで使える仕組みはあったわけですし、個人的にはこの記載の変更によりGoogleが対応したというよりは時流の流れをNISTが少しだけ汲み取ったという方が適切な気がしています。
今後はシングルデバイスなのかマルチデバイスなのか、それをアプリやプラットフォームアカウントが仲介するのかによって認証強度(AAL)の定義が変わったり、NISTの定義を参照しつつ「この処理を行うサービスではこのような仕組みを利用してはいけない」と言った細かい整理が行われる可能性もあるでしょう。
まとめ
ざっくりまとめると次のようなところでしょうか。
- クレデンシャルの保存がシングルデバイスからアプリやプラットフォームアカウントへと拡張される事案が増えてきた
- いわゆる認証の3要素の所持要素の部分に影響する話であるが、単純な複数デバイスにクレデンシャルを保存されている状態とも話が違う
- NISTの定義も認証アプリをプラットフォームアカウントと紐付けて移行することについての記載がありこの辺りの潮流を意識している気はするが、今後より整理が行われるのではないか
この話をすると「巨大プラットフォーマー、特にモバイル端末を持っているAppleとGoogleへの2極化が進んでいるように見える」という感想をいただくことがあります。全てを握られている感は気になるものの、"シャドーID連携" と表現したようにプラットフォームアカウントの管理だけ頑張れば良い仕組みと言い換えることもできるので、今後も動向を見守りたいと思います。
ではまた。
