パスキーは本当に2要素認証なのか問題、またの名を、あまり気にせず使えばいいと思うよ。

kkoiwai
·

この記事の内容は、個人の意見であり感想です。くれぐれもよろしくおねがいします。

とりあえずドラフトですが公開します。識者のみなさまの暖かく、そして鋭いツッコミを期待します。

パスキーについて、非常にわかりやすいブログをえーじさんが書いてくださいました。コレを読んで頂ければほとんどのことが分かると思います。

そんななか、「パスキーって本当に2要素認証なんだっけ」という疑問をもたれた方がいらっしゃったようです。

先日の次世代Webカンファレンスで、私は、「結局、パスキーは秘密鍵と公開鍵のペア」と申し上げた立場からも、この疑問はごもっともだと思いましたので、すこし、私の思うところを述べたいと思います。

パスキーは2要素認証の場合が多い

ほとんどのユーザは、OS標準のパスキーを使うのではないかと思います。そして、生体認証、もしくは画面ロック用のパスワードやPIN等が設定されていない限り、OS標準のパスキーを使うことができません。そして、OS標準パスキーの利用時には、生体認証もしくは画面ロック解除のための入力が要求されます。

よって、ほとんどの場合において、パスキーでの認証成功は、秘密鍵を持っているという意味での所持認証(1要素目)と、生体もしくは記憶を組み合わせた、2要素認証の成功を意味します。

パスキーの認証結果には2要素認証を行ったかどうかの情報が含まれる。

パスキーの認証処理で送信されるデータの中に、UVフラグというフラグがあります。これはUser Verificationの略で、パスキーを使う際に生体認証やPIN等でユーザ認証が行われたかを示すフラグです。上記の通り、ほとんどのパスキーによる認証結果は、このUVフラグが1で返却されます。Webサイトは、このフラグを確認することで、2要素認証であるかどうかを判別できるのです。

さて、ここからが本番です。

Webサイト側で、2要素認証を行ったかを担保できるのか。(結論:まだできない)

よくある2要素認証では、たとえば記憶要素としてのパスワードと、所持要素としてのSMS認証を組み合わせます。これは、Webサイト側で、両方の認証をするので、確実に2要素認証であることをWebサイト側で担保できます。

一方パスキーは、生体orPINの要求は、パスキー(デバイス)だったり、パスキー管理アプリ側で行うので、Webサイト側でそれが確実に実施されたことを確認できるんだっけ、担保できるんだっけというのが課題になります。

現実問題として、パスキー管理アプリは誰でも作れます。もし私がパスキー管理アプリを作ったとして(実は作ったし、某所でソースを公開しているのですが)、そのアプリでパスキーを使う際、ユーザ認証を省略したままUVフラグを1にしたって、Webサイトは気付かない訳です。

そして現状、スマホのパスキーでは、原則、そのパスキーがどのアプリによって作られたり、管理されているか、Webサイト側で確認する方法がないのです。そして、パスキー管理アプリのことが分からなければ、もちろん、そのパスキーが2要素認証を経たものかの確認もできません。

でも、それで困るんだっけ?

2要素認証であることが確認できないパスキーなんて、危なくて使えないよと思われるかも知れませんが、パスワードのほうがよっぽど危険ですよね。そして、ほとんどのユーザがOS搭載のパスキー機能を使うでしょうし、それ以外のパスキー管理アプリを使うユーザは、そもそもリテラシが高いからそんなに心配しなくてもいいと思います。

SMSによる2要素認証には送信コストの課題とフィッシング被害のリスクがありますので、多くのWebサービスにとって、今の時点でパスキーに移行する方がお得なのではないかと私は思います。(何度も申し上げますが個人の感想です。)

そして何より、UXが大きく改善し、ユーザが便利に簡単にあなたのサービスにログインできるようになると、コンバージョンにも大きく響いてきますし、SMS認証のコスト削減効果と併せて、パスキーへの投資のための材料になるのではないでしょうか。

そもそもアカウントリカバリーをどれだけ厳密にしているんだ問題

ところでいま、パスワードを忘れた場合は、Eメールにリンクなどを送ってパスワード再設定を行っていると思います。結局Webサービスは一番弱いところが攻撃されます。どれだけパスキーのセキュリティを上げたとしても、パスワードと同様にパスキー再設定の導線を残している限り(そして現実的に残さざるを得ないと思います)、再設定導線のセキュリティレベルがWebサイト全体の認証のセキュリティレベルです。

結論

2要素認証であることの確実な確認はまだできないけど、それを差し引いてもパスワードからパスキーに移行する価値はあると思う。

ここからはおまけです。

パスキーのベースとなる仕様に関して、現状の話とこれからの話を少しだけ述べさせて頂きます。

認証器の素性を確認する方法(仕様)は、ありまーす。

パスキーは、技術的にはFIDO2という仕様がベースになっていますが、FIDO2仕様には、ユーザがどういった認証器(パスキー管理アプリやUSBキーなど)を利用しているのか、登録のタイミングで、Webサイト側で確認する方法があります。これを、アテステーション(Attestation)と呼びます。アテステーションは、その認証器の作者による署名情報です。Webサイト側でこの署名を検証することで、登録されたクレデンシャル(パスキー)が信頼できるアプリやUSBキーで作成されたことを確認できる仕組みが用意されています。

そして、FIDO2仕様を策定している団体の1つである、FIDOアライアンスは、認証器の認定制度を運営していて、認定に合格した認証器の署名用の公開鍵情報は、認証器ベンダーが求めればFIDOアライアンスのWebサイトで公開されるため、そこで一定の信頼を置ける認証器の情報が得られます。

実は、パスキーという言葉が出てくる前から、Android, iOSにはFIDO2認証機能がありました。そして、当時は、Android, iOSともに、アテステーションを付与してくれていました。改造されていない安全な端末・OS上で作成されたクレデンシャルであることを、OSが署名によって証明し、受け取ったWebサイトはそれを検証する事ができたのです。そして、そのクレデンシャルは、クラウド同期したり、AirDropで他人と共有することは不可能でした。

当時、FIDO関係者の多くは、「FIDOは秘密鍵が端末から外に出ないから安全である」というコンセプトを共有していましたし、そう対外に説明している人が多かったのです。この考え方を、私は個人的に「FIDO脳」と呼びます。

現状ほとんどのパスキーにはアテステーションがつかない(つけられない)

パスキー時代になって、アテステーションは付与されなくなります。なぜなら、Android, iOSで提供されるパスキーは、クラウドで同期されたり、AirDropで他人と共有する事ができるようになったからです。(Androidでは例外がありますがここでは省略します)

いくら最初にパスキーを作成した端末が安全な端末であっても、その後に他の端末にコピーされる可能性があるのであれば、アテステーションの意味がありません。ですので、現状、クラウド同期されるAndroid, iOSのパスキーには、アテステーションがつかないのです。

パスキーに対してアテステーションをつける仕様は現在作成中

特に金融機関など、高いセキュリティを求めるFIDO脳の人たちは、そもそもクラウド同期されてしまうことも困るし、どのパスキー管理アプリが使われたか確認できないのも困るということで、追加の仕様が検討されています。SPK: Supplemental Public Key (補助的公開鍵?)という仕様です。

これは、パスキーの登録、認証のタイミングで、毎回、そのパスキーのメタデータ的な情報を付与する仕様です。そのパスキーが、現在どこで管理されているかを示す情報となります。

たとえば、そのパスキーがデバイスA上に存在するときは、デバイスA内にしか存在しない秘密鍵(SPK:A)での署名データと公開鍵を追加で付与できます。もし、パスキーがデバイスBにコピーされ、デバイスBからそのパスキーが利用されたら、デバイスBにしか存在しない秘密鍵(SPK:B)での署名データと公開鍵が追加で付与されます。Webサイト側は、前回ログイン時に付与されたSPKと、今回ログイン時に付与されたSPKを比較し、公開鍵が変更されていたら、ログイン元のデバイスが変更されたと判断し、そのリスクに応じて処理を変更します。

たとえば、Amazonでは、送付先住所を変更すると一度登録したクレジットカード番号をもう一度聞かれます。これは、悪意者がログインして勝手に買い物することを防ぐ目的だと思われますが、それと同様に、SPKを活用することで、ログイン元のデバイスが変更されたら、リスクが増えたと判断し、何か追加の認証を求める事もできるようになります。

同様に、パスキー管理アプリが生成するSPKを付与することもできます。この場合は、パスキー管理アプリ間でパスキーが移行された際に、SPKが変わります。

ここで、SPKの公開鍵情報だけを見ても、結局それが信頼できるデバイスであったり、アプリであることの担保ができないので、アテステーションを利用します。SPK+アテステーションが実装されたあかつきには、Webサイト側で、そのパスキーがどのパスキー管理アプリ、どのデバイスから使われたのか、分かるようになり、それを使ってより高度な、リスクベースの認証ができるようになる見込みです。

もう一度念のため結論

でも、SPK+アテステーションが現状無いからといって、パスワードより1万倍(当社比)安全なパスキーを移行しないという選択肢は無いと思います。

くどいけど最後にもう一度

この記事の内容は、個人の意見であり感想です。くれぐれもよろしくおねがいします。

とりあえずドラフトですが公開します。識者のみなさまの暖かく、そして鋭いツッコミを期待します。