本記事は Digital Identity技術勉強会 #iddance Advent Calendar 2023 の11日目の記事です。
最近、パスキーのことばかり考えていましたが、その中だったり、別の文脈だったりで、「認証の強度や身元確認レベルと利用可能な機能の関係」を考える機会が、ちょいちょいありました。
例えば『パスキーでアカウント登録するを実施するのが理想的だよね』という意見を聞きます。その一方で、『パスキーでphishingの対策はできるかもしれないけど、誰でも簡単にアカウント作れたらだめだから、電話番号の登録はどのみち必要。iCloud keychain/画面ロック有効にしてない人もいるし、あくまでパスキーを全面にだすのは微妙じゃない？』という意見も聞きます。
そんな話を聞いていたら、アカウントを認証強度や身元確認強度の観点から、どういう状態があって、各状態にどういうリスクがあり、それに応じて許容可能な機能・オペレーションがどのように変わるのかをまとめてみたいな、という気持ちになったのでやってみます。
起こりうるリスク
まず、認証や身元確認に関して、アカウントが直面するリスクを大きく２つに分けて考えてみたいと思います。
「アカウントが盗られるリスク」と「アカウントが悪用目的で作られるリスク」の２つです。
アカウントが盗られるリスク
これは、被害者が持っているアカウントを、攻撃者が何かしらの方法で利用可能な状態になることで、被害者になりすまして、サービスを利用するようなパターンです。
例えば、
- 弱いパスワードでアカウントにログインできる状態になっていたため、Brute forceやPassword spraying attackでアカウントが乗っ取られてしまった。
- Phishing 耐性の無い認証要素のみサポートしており、real-time phishiing attackでアカウントが乗っ取られてしまった。
- アカウントリカバリに不備がありアカウントが乗っ取られてしまった。
実際に起こった被害の例としては、2019年にあった「7payの不正アクセス問題」が挙げられます。ここでは、アカウントリカバリの不備があって、アカウントが乗っ取られる状態になってしまったようですね。。セブンペイの不正アクセスはなぜ起きたのか
この問題への基本的な対処方法は、アカウントを利用するために必要な認証とそれが利用される経路を明確にし、MFAやphishing耐性のある認証要素を導入するなどの対策をもって、弱い部分をなくすことです。
アカウントが悪用目的で作られるリスク
これは、攻撃者自身がアカウントを作り、サービス提供側の意図しない利用方法を行うようなパターンです。
例えば、
- 招待ポイントを付与している場合、大量のアカウントを作ってそのポイントを収集する
- クレジットカードを使った決済機能が提供されている場合に、盗難クレジットカードの利用場所として使われる(Card-Not-Present Fraud)
- 複数アカウント間で少額の決済を繰り返したり、存在しない商品やサービスの取引を偽装することにより、不正な資金を合法的な収益と見せかける(Money laundering)
実際に起こった被害の例としては、2020年に起きた「電子決済サービス不正引き出し事件」が挙げられます。この事件では、銀行紐付けを行い決済を行う機能を提供する決済サービスにおいて、実質匿名でアカウントがいくつも作成できることにより、盗難口座情報の利用先として使われました。2020年電子決済サービス不正引き出し事件
この問題への基本的な対処方法は、アカウントとサービス外の情報を紐付けることで、完全な匿名でアカウントを作成することを禁止する方向です。
具体的には、電話番号の登録・検証するといった簡単なものから、犯罪収益移転防止法が要求するレベルの身元確認を実施するというものまで幅広くあるでしょう。
—
これらのリスクに対して適切に対処出来ているかどうかを検討する指標として、「認証強度」と「身元確認強度」を考える事ができます。
認証強度と身元確認強度
認証強度
「認証強度」は、「アカウントの盗られにくさ」の指標と考えるとわかりやすいと思います。
これは、どのような認証要素をどのような組み合わせで使っているかで変わります。
例えば、
- パスワードのみ（1種類の認証要素の利用）
- パスワード + SMS OTP（2種類の認証要素の利用）
- パスキー（2要素かつphishing耐性がある認証要素の利用）
- パスワード + セキュリティキー（2要素かつ物理デバイスが必要な認証要素の利用）
のように、認証に利用する認証要素の種類や特徴が増えることで、攻撃者がアカウントを奪いにくくなります。
これを端的に表しているのが、NIST SP 800-63BのAuthenticator Assurance Level (AAL)です。
身元確認強度
注意: この項目は一般的なものではありません
「アカウントが悪用目的で作られるリスク」に対応するときに、NISTのIALに言及されることは多いけど、思うのは.....、自己申告の身元確認このリスクの低減には繋がらない、一方で、電話番号の登録・検証はこのリスクの低減に繋がってるように思う。。つまり、このリスクを評価するときに、「検証プロセスの信頼性」とは別に「特定する個人の解像度」みたいなのもある気がするな...と。検証プロセスの信頼性の方は、IALで表現できる話。特定する個人の解像度の方は、例えば、「電話番号だけ」と「氏名・住所・生年月日・性別を要求」だと後者の方が解像度高くて、悪用目的で取得するのが難しくなる。以下頑張ってこの説明しようとしてますが、もっとうまく説明している記事・ドキュメント、もしくは理解の仕方とかあったら教えてください...
「身元確認強度」は、「アカウントの作られにくさ」の指標と考えるとわかりやすいと思います。
これは、アカウントがどの程度、実在する個人と紐づけられているかによって変わります。
例えば、
- ① 特定のEmail addressを管理して人（Email addressにOTPを送って検証）
- ② 特定の電話番号を管理している人（SMS OTPを送って検証）
- ③ 氏名・住所・生年月日・性別で特定される人（検証なし）
- ④ 氏名・住所・生年月日・性別で特定される人（eKYCで検証）
- ⑤ 氏名・住所・生年月日・性別で特定される人（対面のやり取りにて検証）
「身元確認強度」の意味では、① < ② < ④ < ⑤ となるでしょう。
まず、③は信頼できる根拠が何もないので、「アカウントの作られにくさ」に貢献することはないので、除外されます。
次に、実在する個人の解像度の違いという意味で、① < ② < ④, ⑤と考えます。
email addressや電話番号では、実在する個人をかんぜんに特定することはできませんが、それらを管理しているかどうかを検証することで、明らかに「アカウントの作られにくさ」をあげています。
また、検証の信頼性の意味では、NIST SP 800-63AのIdentity Assurance Level(IAL)で説明されるように、③ < ④ < ⑤でしょう。
検証方法が難しくなるほど、「アカウントの作られにくさ」をあげています。
—
アカウントの作成及び、その後の操作によって、「認証強度」と「身元確認強度」がどう変わっていくかを、雰囲気で書いた図です。
例えば冒頭の『パスキーでアカウント登録するを実施するのが理想的だよね』の例で言うと、作られるアカウントは認証強度としては望みうる一番高い状態になっていても、「身元確認強度」はもっとも低い状態です。誰でも無制限に作れるから。
一方で、『電話番号とパスワード + SMS OTPでアカウント登録する』状態は、「認証強度」で言えば「パスキーで作られたアカウント」に及びませんが、「身元確認強度」はそれよりも一つ高い状態になっています。
仮に、電子決済サービス不正引き出し事件のタイミングで、すでに大多数の決済サービスでパスキーが全面的に採用されていたとしても、「身元確認強度」が低いままだったら同じような問題が起きていたでしょう。
サービスの種類と適用の違い
このような「認証強度」と「身元確認強度」が提供されるサービスに対して十分ではないと、先に上げた「アカウントが盗られるリスク」や「アカウントが悪用目的で作られるリスク」が実現してしまうことになります。
とはいえ、認証強度、身元確認強度どちらにおいても、強度を上げることとユーザビリティにはトレードオフがあるので、無闇矢鱈と上げるわけにも行きません。
結局のところ、どのようなサービスを提供していて、どのような攻撃を想定しているか、そのためにどの程度の「認証強度」と「身元確認強度」を満たす必要があるかを、サービスそれぞれで考える必要があります。
ざっくりとですが、よくあるサービスのスタンスを３パターンくらいまとめておこうと思います。
- 低い認証強度及び身元確認強度を要求するサービス
- 高い認証強度及び高い身元確認強度を要求するサービス
- 必要に応じて認証強度及び身元確認強度を上げるサービス
低い認証強度及び身元確認強度を要求するサービス
これは、提供している機能の性質上、高い認証強度や、高い身元確認強度を要求する必要がないサービスです。
アカウントが作られやすい事によって発生する問題は特になく、アカウントが盗られたとしても、ユーザ・サービス提供者共々、それほど大きな影響はない状態です。
サービス提供側としては、MFAやパスキー、パスワードを使ったログインの禁止オプション等、ユーザに対してオプショナルで利用可能なセキュリティ対策を提供し、ユーザが自身で自分のアカウントを守ることができれば、それで十分です。
最初から高い認証強度及び高い身元確認強度を要求するサービス
提供している機能の性質上、高い認証強度や、高い身元確認強度を要求しなければならないサービスで、かつアカウント登録段階でそのレベルを求めるようなサービスです。
例えば、何かしらの決済機能を提供するサービスは、犯罪収益移転防止法に基づいて、強い身元確認を要求する必要がありますし、アカウントが乗っ取られた場合、登録しているクレジットカード等を不正利用される・サービス提供側にチャージバックが発生する等、ユーザ・サービス提供者共々、大きな影響が発生する可能性があります。
このようなサービスの場合、高い認証強度や高い身元確認強度を満たすための機能はオプショナルな機能ではないので、サービスの利用開始のタイミングで、高い強度にする必要がります。
具体的な方法としては、「email address, password, 電話番号の検証でアカウント作られる」とか、「アカウント登録時にKYCの実施を要求される」、「店舗で対面でのやり取りをしないとアカウント登録できない」とか考えられますが、今後は以下みたいなのも出てくるのかな...とか思いました。
-
アカウント登録時のパスキー登録
とりあえず認証強度は求めうる一番高い状態にしておく。身元確認強度は高くなっていないので、別途何かしらを要求する必要はあるが、とわいえ、アカウント作成タイミングでphishingの可能性が極力減らせているので、強いやり方ではある。
-
マイナンバーカード使ってアカウント登録
暗証番号4桁のだと基本4情報を確認できるわけではないけど、マイナンバーもってないアカウント作れないという状態にできるので、電話番号の登録・要求するよりも強い状態になりそう？。マイナンバーカード取り出して４桁入力するのはクソめんどくさそうだけど、スマホにマイナンバーで生体認証使えるようになるんかな。
-
Social Loginでパスキー要求
よく言われるSocial Loginで認証強度指定・RPで検証とか出来たら、高い「認証強度」を要求するのできそうだよねの話。そういえば、OIDC4IDAが犯収法を満たす身元確認方法に含まれるようになる日はいつですか？
必要に応じて認証強度及び身元確認強度を上げるサービス
このアプローチは、必要になったら強い認証強度、強い身元確認強度を要求するというものです。
弱い認証強度・身元確認強度でもサービスの利用を開始時できるけど、より多くの機能を利用するためには、強い認証強度・身元確認強度が要求されるというものです。
この場合、サービス側で各機能において認証強度・身元確認強度に応じて、ユーザの要求を受けれいるかどうかを気にする必要があるので、認識の共有や実装に一定の難しさは生じますが、ユーザ体験的は良くなります。
この方法の場合、他のパターンよりも考えることが多くなるかなと思います。
もっと深ぼっていきたいところですが、時間がないので、考えたいことだけリストアップして終了しようと思います...w
-
どのように機能を制限するか？
「特定機能が使えない、利用するためには認証強度 or 身元確認強度を上げる必要がある」というのがいちばんシンプルな形。でも、一部制限がある状態で機能は使わせるという形もあるだろう。例えば、身元確認強度が不足しているなら決済金額に上限があるとか、認証強度が不足しているなら購入はできるけどクレジットカード情報を再利用できないとか。認証強度を確認すべきか、身元確認強度を確認すべきかは、どんなリスクに対応する必要があるかによるからそれは意識する必要ある。
-
認証強度のアップグレード・ダウングレードは、いろんなパターンあって狙われやすそうなだな...
例えば、「認証強度が低い状態のアカウントを乗って、攻撃者自身がcredential追加して認証強度あげる」とか「複数の認証要素登録されているアカウントだけど、低い認証強度でログインできちゃう」とか「ユーザをうまく誘導してアカウントの認証強度下げてから、乗っ取る」とか..。どのパターンでも、強度に応じて利用可能な機能がちゃんと制限されているなら、問題はないか...?
-
パスキーとの兼ね合い
「認証強度をあげたら利用する機能が増えます」という状態は、パスキーを登録する一つのモチベーションとして利用できないかなー。
-
一般的にどのようなプロセスで、必要な認証強度・身元確認強度をユーザに求めるか？
認証強度は色々ありそうな気がする。Resource ServerがClientに特定以上の認証を求めるパターン(RFC9470 step-up authentication)とか、ClientがUserに対して特定以上の認証を求めるパターン(OpenID Connectのacr_values/acr)とか。でも身元確認強度が十分でない時にどうやってそれをユーザに求めるかってあまり聞いたことないな。。何かあったら教えてください。
終わりに
認証強度と身元確認強度について、なんとなくモヤモヤと思ってることをまとめてみました。
結局、提供するサービスによって考えなきゃいけないこと変わるでしょうし、想像じゃなくて、実際のユースケースを持って考えないなーと思う今日この頃でした。おわり。