週末に家に帰ったら先行して届いていました。12月27日に発売になる「デジタルアイデンティティのすべて」です。
原著と比べると少しだけ大きいですね。
こちらから予約注文できますのでどうぞ。
ついでにSoftware Designの最新号も届いていましたし、年末年始はアイデンティティとパスキーざんまいですね！
1月末には「パスキーのすべて」も発売されますので、体（頭）をあっためておきましょう。
Why I Joined Hawcx
2 週間前
2024年12月21日土曜日
2024年12月13日金曜日
Googleが公開している「４分でパスキーを理解する」動画が素晴らしい件
こんにちは、富士榮です。
昨日はFIDO東京セミナーでしたね。私は台北にいたので参加できませんでしたが・・・
ということで悔しいので #fido でXを追いかけていましたが、えーじさんのパート（だと思う）で触れられていたっぽい「４分でパスキーを理解する」動画が素晴らしくわかりやすいかったのでメモしておこうというポストです。
ざっくりシナリオはこんな感じでした。
- 長らくパスワードを使ってきたけど、難しいパスワードは覚えられないし、同じパスワードの使い回しが起きるので危ないよね
- そんなあなたにGoogleはパスワードマネージャを提供しているよ！
- デバイスを跨いで同期されるのでとっても便利！
- でも全員がパスワードマネージャに頼っているわけじゃないよね
- その前にそもそもパスワードってセキュアじゃないよ
- 2段階認証はセキュリティ強度を上げるけど面倒だしなぁ
- そんなあなたにパスキー！
- パスキーはセキュアで安全なテクノロジーなんだ
- 多くのサイトにパスワードなしでログインができるんだよ
- OSやブラウザがプロンプトを出してくるだけで、ユーザはスマホのロック解除と同じことをすればいいんだ
- これはすごくベネフィットがあって、ログインが簡単だからユーザはドロップしないしコンバージョンレートもあげられる
- ２段階認証にかかるコストもかからない
- フィッシングにも強いんだ
- パスキーは公開鍵暗号技術で構成されているんだよ
- 秘密鍵はデバイスに保管され、スクリーンロック解除のメカニズムでアクセスできる
- その秘密鍵とセットになっている公開鍵はサーバに保存される
- 秘密の情報はサーバに保存されないからサーバからの漏洩の心配はないよ
- そしてパスキーは生成したデバイスごとに保存されるんだ
- だから別の人がパスキーを不正に使うことはできないんだ
- パスキーは多くのブラウザやプラットフォームでサポートされているよ
- そしてパスキーはクレデンシャルマネージャを経由してバックアップすることもできる
- だから新しいAndroidデバイスを手に入れても同じGoogleアカウントでログインすればパスキーを引き継ぐことができるんだ
- またパスキーは同期できないデバイスに対しても使うことができるんだ。これにはハイブリッドプロトコルを使うんだ
- 例えばAndroidデバイスの持ち主がMacOSのブラウザにログインするときはQRコードを読み込んでAndroidデバイス側でパスキーをつかうとMacOS側でログインできる
- 今すぐパスキーを導入しよう！
- 安全で便利な世の中が待っているよ
結構４分に詰め込んだなぁ、、って印象ですが流れがしっかり練り込まれているので非常にわかりやすかったです。
でも多分、本当は「３分でわかるパスキー」にしたかったんだろうなぁw
2024年11月27日水曜日
パスキーの情報をRPとパスキープロバイダで同期する話
こんにちは、富士榮です。
少し前にGoogleのえーじさんがPasskeyのSingal APIについて記事を書いていました。
要するに、RP側に登録済みのパスキーの情報と、ユーザ側に存在しているパスキーの情報がずれないようにするためにSignalを使って検知〜同期をできるようにしましょう、という話ですね。
よくあるケースだとRP側にパスキーを登録したのはいいんだけど、ブラウザ側でパスキーを削除してしまった、もしくはその逆をしてしまった、という場合に認証情報が送れない、もしくは送っても登録情報が削除されていて認証できない、という状態を防ぎましょう、ってことかと。
ただ、Signal APIではこのシナリオのうちの前者には対応できず、後者への対応のみとなるみたいです。つまり、RP側がSignal APIに対応していればパスキープロバイダへ通知はできるけど、パスキープロバイダ側で削除した情報はRPへは通知されない、ってことですね。
仕様はW3CのGithubで公開されているので時間を見て読んでみようと思います。（ほぼ１年前に作ったテスト用の実装へも反映したいですね）
2024年11月20日水曜日
そういえばNewsPicksにパスキーネタが載ってます
こんにちは、富士榮です。
そういえば先日NewsPicksから取材受けていたなぁ、と思ったら記事になってました。
【真相】パスワード消滅｡｢ログイン｣はここまで便利になった
https://newspicks.com/news/10849029/body/
パスワードの使い回しの危険性から他要素認証、パスキーまでを網羅した良い記事になっていると思います。
有料記事なので登録しないと最後まで見れませんが。
よろしければどうぞ。
2024年11月13日水曜日
パスキーのテストサイトがリニューアル
こんにちは、富士榮です。
なんと日本語に対応しています。
スクラッチで実装する人も、パスキーを基礎から学習したい人にもとても良いサイトなのでぜひアクセスしてみると良いと思います。
以前も何度かWebAuthnのテストをするためのサイトを紹介しましたが、今回Okta（Auth0）がパスキー学習サイトをリニューアルしてきたので試してみます。
なんと日本語に対応しています。
ユーザIDやユーザ名など登録に使う情報はあらかじめ決まっていますが、デモとして試すこともできますし、API仕様などを含むリソースもまとまっています。
スクラッチで実装する人も、パスキーを基礎から学習したい人にもとても良いサイトなのでぜひアクセスしてみると良いと思います。
2024年10月17日木曜日
Credential Exchange Format/Protocolの新Working draft
こんにちは、富士榮です。
Authenticate 2024が10/14-16で開催されましたね。
各社イベントに向けて色々と実装をして発表にこぎつける、というのは世の常ですが、これはもちろんスペックライターについても同じようです。
ということで満を持して発表されましたね。
- Credential Exchange Format
- Credential Exchange Protocol
これらの新しいWorking draftが今週金曜日18日にリリースされるようです。
以前から触れていたCredential Exchange Specificationsですがパスキーのインポート・エクスポートのための仕様という冠で登場って感じですかね。
同期パスキーなど色々と新しい考え方が盛り込まれてきたFIDO関係ですが、NISTを含めちゃんと利用ガイドを整えていかないといけませんね。（まぁ、そもそも鍵はデバイスから出ないっていうのが原則だったわけなので、考え方を変えていかないといけません）
2024年10月10日木曜日
Windowsのパスキー対応の今後
こんにちは、富士榮です。
いよいよ来週はAuthenticate 2024ですね。残念ながら参加できませんが。
ということで、Authenticateに向けて各社パスキー周りの話題が進んできていそうです。
MicrosoftからもWindowsのパスキー対応について記事を公開しています。
Passkeys on Windows: Authenticate seamlessly with passkey providers
こちらの機能がWindows Insiderチャネルで配信されるようです。久しぶりにWindows PCでも触ろうかな・・・
- A plug-in model for third-party passkey providers
- Enhanced native UX for passkeys
- A Microsoft synced passkey provider
サードパーティプロバイダとの連携では1Passwordなどとの連携ができるようになるようです。3点目のMicrosoftが提供する同期ファブリックと連携できたりすると面白そうです。Credential Exchange Specificationが実装されてくると面白いと思います。
いずれにしても来週のAuthenticateで詳しく言及されるのかと思います。楽しみですね。
2024年8月29日木曜日
パスキーのデモサイトが便利
こんにちは、富士榮です。
Googleのえーじさんが公開されているパスキーのデモサイトがめちゃ便利です。
パスキーのデモにクレデンシャルの中身を解析する機能を追加しました。attestationObjectとかも中まで見えます。https://t.co/kWVU0flcfH pic.twitter.com/p6JDWZJkpf
— Eiji Kitamura / えーじ (@agektmr) August 28, 2024
こちらです。
登録した認証器がタイプなどの情報が見やすく表示されます。
この辺りでパスキーの実装を試していた時にも認証器を色々と試しては情報の解析をしたりしていたので、このサイトを使うとその辺の作業がとっても楽ですね！
2024年8月21日水曜日
パスキーはエンタープライズで使えるのか？
こんにちは、富士榮です。
先日、IDProで紹介されていた記事を見つつ以下のポストをしました。
記事の中では同期ファブリックの安全性や互換性に関する課題が指摘され、デバイス紐付けパスキーという選択肢やUniversal Credential Exchangeによる相互運用性の実現に向けた取り組みの紹介をしました。
結果、エンタープライズでの利用の場合は同期パスキーよりもデバイス紐付けと管理などが現実的なのかな？？などのコメントを各所で頂いたりしました。
そんな中、RSAが最近こんなブログを公開しました。
Are FIDO Passkeys Ready for Enterprise Use?
https://www.rsa.com/ja/resources/blog/passwordless/are-fido-passkeys-ready-for-enterprise-use/
 |
| RSA社のブログ |
ベンダのブログなので若干バイアスがかかる可能性は否定しませんが、まさにエンタープライズでパスキーを使えるのかどうか気になっている人は必見だと思います。
ということで簡単に見ていきましょう。
Device-Bound Passkeys vs. Synced Passkeys
まずはデバイス紐付きのパスキーと同期パスキーについて解説されています。この辺りはご存知の方が殆どだと思いますがおさらいしておきましょう。
Device-bound passkeys are generally hosted on specific ‘security key’ devices. On a device-bound passkey, key pairs are generated and stored on a single device; moreover, the key material itself never leaves that device.
With synced passkeys, the key material is saved via a so-called remote sync fabric, and the key material can then be restored on any other devices owned by the same user. The current major sync fabrics are Microsoft, Google and Apple. This means that if you were to register your Android phone as a passkey, then the corresponding key material would be available on all your other Android devices shortly after.
Synced passkeys are—in addition to the support of widely used services such as WhatsApp or Facebook—a main reason for the sharp increase in the general use of passkeys. It’s easy to see why: one user with a lot of accounts and a lot of devices can use the same synced passkey between all of them.
デバイスに紐づけられたパスキーは、通常、特定の「セキュリティキー」デバイスにホストされています。デバイスに紐づけられたパスキーでは、キーペアが生成され、単一のデバイスに保存されます。さらに、キー素材自体はデバイスから決して離れることはありません。
同期パスキーでは、鍵情報はリモート同期ファブリックと呼ばれる仕組みを介して保存され、同じユーザーが所有する他のデバイスにも復元することができます。現在、主な同期ファブリックとしては、Microsoft、Google、Appleが挙げられます。つまり、Androidフォンをパスキーとして登録すると、その後すぐに、他のすべてのAndroidデバイスでも対応する鍵情報を利用できるようになるということです。
同期されたパスキーは、WhatsAppやFacebookなどの広く使用されているサービスのサポートに加えて、パスキーの一般的な使用が急激に増加している主な理由です。その理由は簡単です。多くのアカウントとデバイスを持つユーザーは、それらすべてに同じ同期されたパスキーを使用することができます。
ユーザが直接サインアップして使うコンシューマ向けサービスではユーザビリティの向上を目標として同期パスキーが使われることで急激にパスキー自体の普及率が上がっている、ということですね。
The Benefits of Passkeys
パスキーの利点についてもおさらいされています。
Passkeys are an excellent MFA method: safe, fast, convenient, and users are already familiar with them. But the passkey benefit that’s beginning to get a lot of attention is that they’re phishing-resistant.
Passkeys can help organizations stop traditional phishing in its tracks: if there’s no password being used, then there’s no password to steal. And while that’s true for other passwordless MFA methods, passkeys have an added level of security provided by that synched key/service domain match.
In the U.S., phishing resistance is a major driver for government agencies. Executive Order 14028 requires phishing-resistant, passwordless authentication to secure critical infrastructure.
パスキーは優れた多要素認証の方法です。安全で、高速で、便利であり、ユーザーもすでに慣れ親しんでいます。しかし、現在注目を集め始めているパスキーの利点は、フィッシング対策に有効であるという点です。
パスキーは、従来のフィッシングを阻止するのに役立ちます。パスワードが使用されていなければ、盗むべきパスワードも存在しないからです。これはパスワード不要の他の多要素認証方法にも当てはまりますが、パスキーには、同期されたキー/サービスドメインの一致による追加のセキュリティレベルが備わっています。
米国では、フィッシング対策は政府機関にとって重要な推進要因となっています。大統領令14028では、重要なインフラストラクチャを保護するために、フィッシング対策のパスワード不要の認証が義務付けられています。
パスキーの一番の利点としてフィッシング耐性があることに触れられています。米国では大統領令でもフィッシングについての記載があるんですね。
The Challenges with Passkeys
ここからパスキーの課題について触れられています。
While passkeys provide significant advantages, they also come with a few significant challenges and problems.
For a solution that has grown up in the consumer environment, user guidance and the user experience can sometimes be a challenge.
Dialogs that ask the user to insert the passkey into the USB port or enter the PIN, for example, look different depending on the operating system and browser. Those prompts will likely make it more difficult to train users and minimize support calls.
Why not just change the prompts you ask? Because third-party service providers like RSA can’t: those prompts are set by the browser or OS vendor themselves in their own vendor (for instance, Apple sets their prompt for iOS, Google for Chrome, etc). There’s some good reason for this: if vendors could change the prompt, then so could attackers, using an updated form to spy on users. Keeping those log-in prompts locked is an important security measure, but it can make for a one-size-fits-all approach.
The high level of phishing resistance is a clear advantage, but it can also be a distraction. Anyone who thinks that the use of passkeys suddenly makes them immune to social engineering attacks is very much mistaken. Passkeys help against one type of social engineering attack: phishing. Unfortunately, there are other variants. The attacks on MGM Resorts or Caesars Palace in Las Vegas had a social engineering component: exploiting the help desk to allow the attacker to register an MFA authenticator himself.
Attackers adapt as a matter of course. The proliferation of MFA has made phishing much less attractive, so it’s only natural that vulnerabilities around the MFA system are exploited. Such as the way users register. Anyone who thinks passkeys solve these problems is very wrong.
パスキーには大きな利点がある一方で、いくつかの重大な課題や問題も伴います。
消費者環境で成長してきたソリューションでは、ユーザーへのガイダンスやユーザーエクスペリエンスが課題となることがあります。
たとえば、パスキーをUSBポートに挿入するようユーザーに求めるダイアログやPINの入力などは、オペレーティングシステムやブラウザによって表示が異なります。このようなプロンプトは、ユーザーのトレーニングを難しくし、サポートコールを最小限に抑えることが難しくなるでしょう。
では、求めるプロンプトを変更すればよいのでしょうか?RSAのようなサードパーティのサービスプロバイダーにはできないからです。これらのプロンプトは、ブラウザやOSのベンダー自身が、それぞれのベンダーで設定しています(例えば、AppleはiOS、GoogleはChromeなど)。これにはいくつかの理由があります。もしベンダーがプロンプトを変更できるのであれば、攻撃者も同様に変更でき、最新のフォームを使用してユーザーをスパイすることが可能になります。ログインプロンプトをロックすることは重要なセキュリティ対策ですが、画一的なアプローチになりかねません。
フィッシングに対する高い耐性は明らかな利点ですが、かえって邪魔になることもあります。パスキーの使用によって、ソーシャルエンジニアリング攻撃に対する耐性が突然得られると考える人は、大きな誤解をしています。パスキーは、ソーシャルエンジニアリング攻撃の一種であるフィッシングに対する防御策となります。残念ながら、それ以外にもさまざまな種類があります。ラスベガスのMGMリゾートやシーザーズパレスに対する攻撃にはソーシャルエンジニアリングの要素がありました。ヘルプデスクを悪用して、攻撃者が多要素認証の認証装置を自分で登録できるようにしたのです。
攻撃者は当然のように適応していきます。多要素認証の普及により、フィッシングはあまり魅力的ではなくなりました。そのため、多要素認証システム周辺の脆弱性が悪用されるのは当然です。例えば、ユーザーによる登録方法などです。パスキーがこれらの問題を解決すると考える人は、大きな誤りを犯しています。
1つはUI（プロンプト）がプラットフォームによって異なる（かつサードパーティのソフトウェアでは変更ができない）ことが挙げられています。OSベンダがプロンプトを変更させないのはセキュリティの観点から見ると合理的ではありますが、OSごとにプロンプトが異なるのはユーザから見ると混乱を招く一因となっていると思います。
また、フィッシング耐性がある、というキーワードがかえって誤解を与えてしまう懸念についても記載されています。そもそもフィッシングはソーシャルエンジニアリングの一部であることを理解しないと、ソーシャルエンジニアリング全般に対する対策となっている、という誤解を招く、と指摘されています。
同じく、システムへの多要素認証手段の登録機能自体がパスキーでセキュアになる、という誤解もあるようですね。
Sync Fabrics and Cybersecurity Vulnerabilities
これも以前紹介した記事にも記載があった、同期ファブリックのセキュリティの話です。
They say that when you have a hammer, everything can look like a nail. Turing a solution—even a great solution—that was originally intended for consumer use into an enterprise application can introduce significant risk.
While reading this article, you may have had a queasy feeling at the mention of ‘sync fabric’. Your gut was right.
The fact that passkeys appear as if by magic on all devices on which the user is logged in via Apple or Google is a major red flag in the corporate environment and should raise some significant questions:
Should users be allowed to use several (possibly also privately used) devices for authentication at all? If so… How many?
Synced passkeys make restoring a “lost” passkey possible with the account recovery processes of e.g. Google or Apple. That’s great… but are these processes secure enough for you?
The Apple feature that allows users to share Passkey with friends or family is quite nice… but does this also apply to Passkeys that are used to log in to enterprise applications?
When using synced passkeys, the security of your company suddenly depends largely on the technical and organizational security of Apple and Google. Sure, there is a certain dependency anyway due to the use of iOS and Android—but synced passkeys increase this dependency considerably.
This isn’t a theoretical vulnerability, either. Last year Retool discussed how threat actors had used it to gain access to its systems: Retool wrote that the functionality means that “if your Google account is compromised, so now are your MFA codes.”
ハンマーを持っていれば、すべてが釘に見えるという。もともとコンシューマー向けに意図されたソリューション、たとえそれが優れたソリューションであったとしても、それをエンタープライズアプリケーションに転用することは、重大なリスクを伴う可能性がある。
この記事をお読みになっている方の中には、「同期ファブリック」という言葉に不安を覚えた方もいらっしゃるかもしれません。その直感は正しいです。
パスキーが、Apple や Google 経由でログインしたすべてのデバイス上に魔法のように現れるという事実は、企業環境においては重大な問題であり、次のような重要な疑問が生じます。
ユーザーは、認証のために複数の(場合によっては個人用も含む)デバイスを使用することが許されるべきでしょうか? もし許されるのであれば、何台まででしょうか?
同期されたパスキーは、Google や Apple のアカウント復旧プロセスによって「紛失した」パスキーの復元を可能にします。素晴らしいことですが、これらのプロセスは十分に安全でしょうか?
友人や家族とパスキーを共有できるAppleの機能は素晴らしいですが、これは企業アプリケーションへのログインに使用するパスキーにも適用されるのでしょうか?
同期されたパスキーを使用する場合、企業のセキュリティは突如としてAppleとGoogleの技術的および組織的なセキュリティに大きく依存することになります。もちろん、iOSやAndroidを使用しているため、ある程度の依存関係は存在しますが、同期されたパスキーは、この依存関係を大幅に高めます。
これは理論上の脆弱性でもありません。昨年、Retoolは、脅威の主体がこの機能を利用してシステムにアクセスした方法について論じています。Retoolは、この機能により「Googleアカウントが侵害された場合、MFAコードも侵害される」と書いています。
想像通り、ですがAppleやGoogleがホストする同期ファブリックを介して個人の所有物を含むデバイス間でクレデンシャルが同期されていたり、家族とクレデンシャルが共有されている環境下で企業アプリケーションを利用するのは管理者から見ると悪夢となりそうです。簡単に言うとコントロールをAppleやGoogleに握られている状態（依存している状態）は企業にとって必ずしも良い状態ではない、ということですね。
Are Passkeys Ready for Enterprise Use or Not?
結局パスキーはエンタープライズで使える状態なのか？という話です。
Whether Passkeys should be used in the company cannot be answered in a general way. Every organization is different and must balance its unique security and operational priorities.
Moreover, whether to use passkeys shouldn’t be a yes/no question. The introduction of passkeys or passwordless login in general should be used to fundamentally review an organization’s entire MFA processes. What has been good for hardware OTP tokens for 15 years is probably no longer entirely true for passkeys or other MFA methods today.
RSA believes that passkeys can be deployed for enterprise use if they align with organizational strategy and if organizations think through their answers to the following questions. We’ve seen organizations use passkeys successfully using RSA® ID Plus, our comprehensive identity and access management (IAM) platform that provides a range of passwordless options.
Because we’re a security-first organization and use Secure by Design / Secure by Default principles, we prevent using synced passkeys by default. Only device-bound passkeys are available by default in RSA environments to provide the maximum level of security out-out-the-box, and without any extra work required by admins.
パスキーを企業で使用すべきかどうかは、一概に答えられるものではありません。 組織はそれぞれ異なり、独自のセキュリティと運用上の優先事項のバランスを取る必要があります。
さらに、パスキーを使用すべきかどうかは、イエス・ノーで答えられる質問ではありません。 パスキーやパスワード不要のログインを導入することは、組織のMFAプロセス全体を根本的に見直すために使用すべきです。15年間ハードウェアOTPトークンにとって有効であったことが、パスキーやその他の多要素認証方法ではもはや完全に当てはまらない可能性が高いのです。
RSAは、パスキーを企業で使用するには、組織の戦略と一致し、組織が以下の質問に対する答えを十分に検討することが必要だと考えています。RSAは、パスワード不要のさまざまなオプションを提供する包括的なアイデンティティおよびアクセス管理(IAM)プラットフォームであるRSA® ID Plusを使用して、パスキーを成功裏に使用している組織をいくつも見てきました。
当社はセキュリティを最優先する企業であり、「Secure by Design / Secure by Default」の原則を採用しているため、同期型パスキーのデフォルトでの使用は防止しています。RSA環境では、デフォルトではデバイスに紐づいたパスキーのみが利用可能であり、管理者による追加作業を必要とせずに、最大限のセキュリティをすぐに利用できます。
まぁ、この辺りはポジショントークが入ってきていますが、Yes/No問題ではない、という点は真理だと思います。結局のところパスキーの登場をきっかけに企業における認証戦略を見直すことが重要ってことです。
Questions Organizations Must Ask Before Using Passkeys
まぁ、最後は当然のことながら自社サービスへの誘導ですね。とは言え、企業が自問すべきことについて触れられているのでここはみなさんちゃんと考えてみましょう。
When assessing whether to introduce passkeys, organizations should ask: How are our authenticators registered? Are there processes that safely handle the ‘I lost my authenticator’ scenario? What about the classification of users, applications and data?
Passkeys are one MFA method among many. Yes, their phishing resistance is fantastic, but can users log in with it on their remote desktops?
For these reasons and many others, it’s important that your MFA system isn’t just technically up to date, but that it also supports a wide variety of MFA methods, such as QR codes, biometrics, OTP, push messages and FIDO passkeys.
It is also important that the processes around MFA are adapted to new threats. This goes far beyond the actual MFA system: Is your help desk also safe from social engineering attacks?
If passkeys make sense to you, then we want to help. Contact us to learn more or start a free, 45-day trial of ID Plus.
パスキーを導入すべきかどうかを評価する際、組織は次のような質問を自問すべきです。「当社の認証情報はどのように登録されているか?」「認証情報を紛失した」というシナリオを安全に処理するプロセスはあるか?」「ユーザー、アプリケーション、データの分類についてはどうなっているか?」
パスキーは、数ある多要素認証(MFA)の方法のひとつです。 確かにフィッシング対策としては素晴らしいですが、ユーザーはリモートデスクトップ上でこれを使ってログインできるのでしょうか?
こうした理由やその他の理由から、MFAシステムは単に技術的に最新であるだけでなく、QRコード、生体認証、OTP、プッシュ通知、FIDOパスキーなど、多様なMFA方式をサポートしていることが重要です。
また、MFAに関連するプロセスが新たな脅威に対応していることも重要です。これは実際のMFAシステムをはるかに超えるものです。ヘルプデスクもソーシャルエンジニアリング攻撃から安全であるか?
パスキーが適切だとお考えであれば、ぜひご相談ください。詳細についてはお問い合わせいただくか、ID Plusの45日間無料トライアルをお試しください。
確かにパスキーは多要素認証の方法の一つ、として捉えて認証戦略について考えることは大切ですね。
ということでベンダのブログではありますが、結構書いてあることは重要だと思います。
日本企業・組織においてもパスキーを前向きに捉えて導入するためにもしっかりとシナリオを設計して導入を進めてほしいところです。
2024年8月19日月曜日
端末がパスキーにどこまで対応しているか確認する方法
こんにちは、富士榮です。
Android 14 / Chromeブラウザ
iOS 17.5.1 / Safari
パスキーのテストをする際によく使うpasskeys.devに、端末（プラットフォーム・ブラウザ）がどんな機能をサポートしているのかを確認するためのページができています。
WebAuthn Features and Capability Detection
これを使うとブラウザが何をサポートしているのかが一目でわかります。
確認できるのは、以下の通りです。
- Features
- Get Client Capabilities
- Conditional Get (Autofill UI)
- Conditional Create (Opportunistic Upgrades)
- Related Origin Requests
- toJSON().Method
- Parse JSON Request Options
- Parse JSON Creation Options
- Client Capabilities
- Passkey Platform Authenticator
- User Verifying Platform Authenticator
- Hybrid Transports
- Extension: PRF
試しに手元のデバイス・ブラウザで確認してみました。
MacOS 14.6.1 / Safari
MacOS 14.6.1 / Firefox 129.0.1
Android 14 / Chromeブラウザ
iOS 17.5.1 / Safari
うーむ。まぁわかってはいましたが先日の「パスキーはパスすべきなのか？」に書いた通りまだまだサポートレベルにばらつきはありますよねぇ。
2024年8月5日月曜日
結局パスキーはパスすべきなのか？
こんにちは、富士榮です。
結局「パスキーはパスすべきなのか？」という話です。
昨日のポストでDean SaxeがIDProに反論記事を書いているということを書きましたが、今日はそちらを見ていきましょう。
Don’t Pass on Passkeys
https://idpro.org/dont-pass-on-passkeys/
 |
| IDProのポストより |
昨日取り上げたポストでは、結局認証器ベンダや同期ファブリックを運営しているベンダと鍵を共有することになる、とか、異なるベンダのプラットフォームを跨いでの鍵の同期や再利用ができないことが指摘されていました。
今回のDeanのポストではそれらの指摘に対して以下のように反論しています。
- デバイスにバインドされたパスキーであればTPMやTEE、SEに紐づいているので他者から抜き取られることはない
- 同期ファブリックは安全に管理されている
- クロスデバイス認証（Hybrid）を使うことで異なる事業者のプラットフォームでもパスキーを使える
- 最近はパスワードマネージャを提供している事業者がパスキーにも対応してきているのでプラットフォームを跨いでパスキーを利用できるようになってきている
また、特にセキュリティの指摘（LastPassからの漏洩）に関しては、「パスワードマネージャを利用している人は30%くらいで、84%の人はパスワードを自分で使い回している」と反論しています。そして、こうなるとパスワードとパスキーの強度の比較の問題になるので、NIST SP800-63Bsup1でも取り上げられているように明らかにパスキーの方が強度が高いのである、と主張しています。
そして、相互運用（ベンダロックイン）問題については、それぞれのプラットフォームごとにパスキーを登録すればいいじゃないか、という若干乱暴（？）な主張とともに、一部ベンダでは秘密鍵のエクスポートにも対応してるぞ、おすすめはしないけどね、と書いています。
最後に、FIDOアライアンスではUniversal Credential Exchangeプロトコルを開発していて、これを使えば異なるクレデンシャルマネージャの間で安全にクレデンシャル情報を転送できるようになる、と締めくくっています。
まぁ、面白い議論ですね。
いずれにしてもこの手の話は100:0になることはないので、切磋琢磨しながら技術の進歩が進んでいくものだと思います。我々は常にこういう議論があることを理解しておくことが重要なんだと思います。
2024年8月4日日曜日
パスキーはパスすべきなのか？
こんにちは、富士榮です。
パスキー便利ですよね。これまでもパスキー推しのトーンでポストを書いてきましたが、一方でX（旧Twitter）ではうまく使えない、動かない、などの声がリテラシーの高い層からも聞こえてくるのも事実です。
そんな中、IDProが「I’ll Pass (for now) on Passkeys」という記事を先日公開しています。
https://idpro.org/passing-on-passkeys/
 |
| IDProの記事より |
もちろん、IDProとしても著者個人の意見である旨を断った上で記事を掲載していますが、ある方面からの見え方としては正しいこともあるので把握しておくことは大切だと思います。
なお、別途書こうと思いますが、後日Dean Saxeが同じくIDProに反論（？）記事も書いているのでそれはそれで面白いです。
今回は「今の所、パスキーはやめとくわ」っていう著者の主張を見ていきましょう。
主な理由として、以下を挙げています。
- セキュリティ
- 相互運用性
セキュリティ
著者は、認証器を購入する、認証器の回復をする、という行為を考えると認証器に関する情報は所有者・利用者のみならずベンダーやバックエンドファブリックを運営している事業者とも共有されてしまう、という点を挙げています。例としてLastPassからの漏洩事故を挙げていますね。
まぁ、全ての人が他人に推測されない十分なエントロピーのあるパスワードをパスワードマネージャなどに依存せずに運営できる、という状態が来れば著者の主張も納得できますが私には無理です。
相互運用性
著者はこう主張しています。
Passkeys did seem like an initial positive middle ground, however the confusing marketing, implementation limitations, sometimes lack of transparency and interoperability has so far, undermined their potential to be a truly great improvement on current password and MFA options.
パスキーは、初期のポジティブな中間的な選択肢のように思えたが、マーケティングの混乱、実装の限界、時折見られる透明性の欠如、相互運用性により、パスワードやMFAのオプションを真に大きく改善する可能性は、今のところ損なわれている。
特に透明性の欠如の部分ではProtonのブログを引用しています。
https://proton.me/blog/big-tech-passkey
Protonのブログは若干の誤認識がありそうですが、簡単にいうと結局GoogleとAppleが牛耳ってるじゃん、Synched Passkeyの鍵の同期もAppleワールドの中ではできるけど自分で好きにExportしてWindowsでも使えるようになってないじゃないか、という主張がされています。
同じようにGoogleはChromeを使っている限りはパスキーの同期はできるけどFireFoxを使ったらダメじゃん、ということで相互運用性や透明性について課題があると主張がなされています。
うーん、全体にそこじゃない感じしかしませんが。
私が観測している範囲だと、パスキーが使えないっていう主張のほとんどは一部は上記の2点に関連するところはあるものの、実際はパスキーを設定させるまでのユーザ導線が難しすぎる、とか、機種変更やサービス側の機能Updateが発生した場合に過去に設定したパスキーが見つからないとか、詰む、などサービス側の問題な気がしているんですが。。。
2024年5月19日日曜日
NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む（７）
こんにちは、富士榮です。
NIST SP 800-63B-3の追補版も最後のまとめ部分を残すのみです。
早速ですが本文書でどのように結論づけているのかをみていきましょう
同期可能な認証器は、認証の状況、特に多要素暗号認証子の使用における実質的な技術的変化を示すものである。暗号鍵の複製とクラウド・インフラへの保存を許可することに関連するトレードオフの 評価は、必然的に行われることになる。このことは、明確なリスク（認証鍵に対する企業管理の喪失など）をもたらすが、同時に、 一般市民や企業にとっての主要な脅威ベクトルを排除する、便利でフィッシングに強い認証機能への道筋を提供する。同期可能な認証器は、すべてのユースケースに適しているわけではない。しかし、本補足文書に含まれるガイドラインに沿った方法で導入される場合、AAL2 リスク軽減策との整合性を達成し、フィッシング耐性認証の採用をより広範に促進することができる。
企業等で利用する場合は鍵が制御外のファブリック（iCloudなど）に保存されることによるリスクがありますが、一般ユーザのシナリオではフィッシング耐性のない認証器を使うよりはマシっていうことなんでしょうねぇ。要はユースケースに応じたリスク分析をちゃんとやろうねっていうNISTのガイドラインの根本は変わらないわけで。
この文書は、既存のデジタル・アイデンティティ・ガイドラインに付随するものであり、各省庁 が十分な情報に基づきリスクベースの決定を行い、適切な場合には最新の業界イノベーション を統合するための情報を提供する。
改めて本文書は既存のガイドラインの付随文書であることを強調し、先に書いたとおりちゃんとしたリスク分析に則って対策を考えましょう、ということです。
ということでこれで一通り見てきたわけですが、私的なまとめとしては、
- 同期と共有は違うぞ
- 同期を許容する場合はバックエンドの同期ファブリックの信頼性も評価しないとだめ
- 統制レベルを上げる場合は同期を不許可にするようにMDMなどで制御することも必要
- ただ、かといってフィッシング耐性がない認証器を許容するよりはマシな場合もある
- 結局ユースケースごとにリスク評価をしましょうね
- その意味でこのガイドライン追補版では新たなタイプの認証器の特徴とリスクなどをまとめたのでちゃんと導入するように
ということくらいでしょうか。
2024年5月18日土曜日
NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む（６）
こんにちは、富士榮です。
少し間が開きましたがNIST SP 800-63B-3の追補版の続きです。
今回は同期と共有は違うぞ！という話のうちの共有の部分です。１回目にも書きましたがAppleの共有パスワードグループの話などもありますので、非常に重要な部分だと思います。
サイバーセキュリティ・ガイドラインは、歴史的に、ユーザ間で認証器を共有しないよう警告してきた。このガイダンスにもかかわらず、一部のユーザ・グループやアプリケーションでは、個人がデジタル・アカウントへのアクセスを共有できるようにするために、認証器とパスワードの共有が行われている。
表 3 に示すように、一部の同期可能な認証器の実装は、このようなユーザの行動を受け入れ、 異なるユーザ間で認証キーを共有する方法を確立している。さらに、一部の実装は、一般的なサービスにおいて、パスワード共有に代わる便利で より安全な方法として、同期可能な認証器の共有を積極的に推奨している。
言われてますよ、Appleさん。。
企業ユースケースの場合、鍵の共有に関する懸念は、鍵が承認されたデバイスや同期 ファブリックから移動されることを制限するデバイス管理技術を使用することで、効果的に緩和することができる。しかし、公衆向けのユースケースでは、同様の緩和策は現在のところ利用できないため、 リライングパーティは、同期可能な認証プロバイダが採用する共有モデルに依存することになる。公衆向けアプリケーションの所有者は、共有認証器に関連するリスクを認識する必要がある。公衆と対話する場合、機関は、ユーザがどの特定の認証器を使用しているのかについて限られ た可視性しか持たないため、すべての同期可能な認証器が共有の対象となる可能性があることを想定する必要がある。多くの共有モデルには、リスクを最小化する実質的な制御（例えば、共有を許可するためにデバイス間の近接を要求する）があるが、他の実装はそれほど制限的ではない。
やっぱり共有を制御する方法とセットになっていることが必要なんじゃないかと思いますね。この辺りの判断をリライングパーティに全部任せちゃうのは実質不可能だと思いますし。
この新しいクラスの認証者がもたらす共有のリスクは、特別なものではない。実際には、すべての AAL2 認証タイプに適用され、中には同期可能な認証タイプより弱いものもある。AAL2 のどの認証子も、それを共有しようとするユーザによって共有される可能性がある。ユーザは、パスワード、OTP、帯域外認証子、さらにはプッシュ認証イベントを積極的に共有したり、被指名人（正式か否かを問わない）がエンドユーザに代わって認証を行うことを許可したりすることができる。
各省庁は、直面する特定のリスク、脅威、およびユーザビリティの考慮事項に基づいて、アプリ ケーションにどの認証手段を受け入れるかを決定する。同期可能な認証方式は、AAL2 までの実装を求めるアプリケーションの新しいオプションとして提供されるかもしれず、他の認証方式と同様に、この技術のトレードオフは、セキュリティ、プライバシー、公平性、およびユーザビリティに対する期待される結果に基づいて、うまくバランスをとるべきである。
そろそろこのレポートもおしまいです。
というか早くSP800-63-4の次のドラフトが出て欲しいですね。
2024年5月11日土曜日
NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む（５）
こんにちは、富士榮です。
引き続きNIST SP 800-63B-3への追補版を見ていきましょう。
今回は同期可能な認証器に関する脅威とチャレンジについてです。
Syncable Authenticator Threats and Challenges
同期可能な認証機能には、導入または展開の前に評価すべきいくつかの明確な脅威および課題がある。表3にこれらのリスクと推奨される軽減策の概要を示す。表3. 同期可能な認証器の脅威、課題、緩和策
ここにありましたね。同期と共有の違い。やっぱりMDMとかでコントロールするしかなさそうですね。
ちなみに次の章は共有に関して丸々一章を割いているのでやはり課題感は大きいんだと思います。
2024年5月9日木曜日
NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む（４）
こんにちは、富士榮です。
引き続きNIST SP800-63B-3の同期可能な認証器に関する追補版についてみていきましょう。
今回は実際にインプリメンテーションを行う場合の考慮事項や要求事項についてです。
Implementation Considerations and Requirements
同期可能な認証器は、W3CのWebAuthn仕様に基づいて構築されており、共通のデータ構造、チャレンジ・レスポンス暗号プロトコル、公開鍵認証情報を活用するためのAPIを提供している。この仕様は柔軟で適応性があるため、WebAuthnクレデンシャルのすべてのデプロイが連邦政府機関の実装要件を満たすとは限らない。この仕様には一連の「フラグ」があり、依拠当事者（RP）アプリケーションは、認証イベ ントの追加コンテキストを提供し、それが RPのアクセス・ポリシーに適合するかどうかを判断す るために、認証者に要求することができる。本節では、RPとして活動する連邦機関が、NIST AAL2 脅威緩和策に適合する同期可能な認証器の実装を構築する際に理解し、問い合わせる必要がある、WebAuthn仕様の特定のフラグについて 説明する。表2, WebAuthn Level 3 flags
以前パスキー対応の認証機能を実装した際にも出てきたフラグですね。
https://idmlab.eidentity.jp/2024/02/api.html
同期可能かどうかの判断にはBEやBSを使うわけです。アプリによってはこのフラグを見て同期可能な認証器を受け入れるかどうかを決める、と言うことです。
表2に示されるフラグに加えて、機関は、実装および受け入れを選択する同期可能な認証器のオリジンおよび機能について、より詳細な情報を得ることを望むかもしれない。FIDO2 WebAuthn のコンテキストにおいて、認証者の中には、特定の認証者の能力および製造者を 判断するために使用できる認証機能をサポートしているものがある。企業ユースケースの場合、各機関は、プラットフォームプロバイダが提供する機能に基づいて、認証機能を実装するべきである(SHOULD)。好ましくは、RP が認証器に関する一意の識別情報を要求するエンタープライズ認証の形をとる。構成証明（Attestation)は、広範な公衆向けアプリケーションに使用すべきではない（SHOULD NOT）。このような要件（すなわち、構成証明に対応していない場合、一部の一般ユーザの同期可能な認証器をブロックする要件）は、ユーザをショートメッセージサービス（SMS）のワンタイムパスワード（OTP）のような、フィッシングに脆弱な安全性の低い認証オプションに誘導する可能性がある。
この視点は面白いですね。パブリック（共有端末とかのイメージかな？）なアプリケーションで同期可能な認証器を使うとってしまうまずいので同期可能なクレデンシャルをブロックすると言うポリシーを適用すると、手軽な認証手段を実装しがちになる、という話でしょうか？（@Shiroicaさんご指摘ありがとうございます）
RP がフラグおよび認証データを要求しても、認証器は要求された情報をすべて返さないかもしれないし、リソースへのアクセスに要求される期待応答と矛盾する情報を返すかもしれない。したがって、各機関は、同期可能な認証器を使用するユースケースを評価し、返された情報に基づいて適切なアクセスポリシー決定を行うことが決定的に重要である。
こちらも現実論として全ての認証器がちゃんとフラグを返してくるということは期待してはいけない、ちゃんとリスクを含め評価をしてポリシーを決めようね、ということです。これ非常に大事だと思います。
ということでまだ続きますが、今回はここまでです。
2024年5月7日火曜日
NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む（３）
こんにちは、富士榮です。
前回に引き続きNIST SP800-63-3の追補版を見ていきます。
早速読んでいきます。
Updates on the Allowance of Cloning Authentication Keys
SP 800-63B のセクション 5.1.8.1「多要素暗号化ソフトウェア認証機能」は、認証器があるデバイスから別のデバイスへ暗号化認証鍵を「クローン」することを制限している。具体的には、以下のとおりである：
多要素暗号化ソフトウェア認証器は、複数のデバイスへの秘密鍵のクローニングを抑制すべきであり、促進してはならない（SHALL NOT）。
同期可能な認証器は、デバイスや異なるプラットフォーム・プロバイダにまたがって、以前に 登録した認証器へのアクセスをユーザに提供するため、明示的に鍵の複製を促進する。NISTがSP 800-63B-4の初期公開草案(ipd)からこの制限を削除したことで、この現実が認識された。本文書の発行時点で、5.1.8.1 項の上記の記述は、本補足により置き換えられ、本補足に規定される要件に基 づいて導入される同期可能な認証器は、AAL2 で想定される脅威から保護するのに十分であるとみなされるものとする。
そうです、元々のSP 800-63Bでは秘密鍵のクローニングを制限していたわけです。今回の更新でこの点について緩和が行われたわけです。
ただ、そのために満たすべき要件を以下の通り定義しています。
同期可能な認証器のすべての使用に関する一般要件：
- すべての鍵は、承認された暗号技術を用いて生成されなければならない。
- デバイスからクローンまたはエクスポートされた秘密鍵は、暗号化された形式でのみ保存されるものとする。
- すべての認証トランザクションは、デバイス上で生成された、または同期ファブリック（クラウドストレージ など）から復元された暗号鍵を使用して、ローカル・デバイス上で秘密鍵操作を実行しなければならな い。
- クラウドベースのアカウントに保存された秘密鍵は、認証されたユーザのみがシンクファブリック内の秘密鍵にアクセスできるよう、アクセス制御メカニズムによって保護されなければならない。
- 同期ファブリック内の秘密鍵へのユーザ・アクセスは、同期された鍵を使用する認証プロトコルの完全性を保持するために、AAL2相当のMFAによって保護されなければならない。
- これらの一般的要件および同期可能な認証器の使用に関するその他の機関固有の要件は、文書化し、公開ウェブサイトおよびデジタル・サービス・ポリシー（該当する場合）を含め、周知されるも のとする。
ちゃんと認定された暗号技術を使うこと、同期された鍵を使って認証に必要な操作を行う場合はローカルで操作を行うこと（要するにリモート署名なんかはNGってことですね）、秘密鍵へのアクセス制御を行うこと、具体的にはAAL2相当の認証強度で保護されていること、同期可能な認証器を使っていることをポリシーとして公開・周知すること、が記載されています。要は、同期してもいいけどちゃんと認められた方法で管理し、その旨を周知せよ、ということですね。
また、追加要件として以下のについても定義されています。
連邦企業が同期可能な認証器を使用するための追加要件：
- 連邦企業の秘密鍵（すなわち、連邦鍵）は、FISMA Moderateの保護または同等の保護を達成した同期ファブリックに保管しなければならない。
- 連邦企業の秘密鍵を含む認証器を生成、保管、同期するデバイス（携帯電話、ノート型パソコン、タブレットなど）は、モバイル・デバイス管理ソフトウェアまたはその他のデバイス・コンフィギュレーショ ン・コントロールによって保護され、権限のないデバイスまたは同期ファブリックへの鍵の同期または共有を防止しなければならない。
- 同期ファブリックへのアクセスは、省庁が管理するアカウント（例えば、中央アイデンティティ・アクセス管理ソリューションまたはプラットフォーム・ベースの管理アカウント）によって制御され、 秘密鍵のライフ・サイクルに対する企業管理を維持するものとする。
- 秘密鍵を生成する認証器は、認証器の能力およびソースを検証するために使用できる認証機能（例えば、エンタープライズ認証）をサポートすべきである（SHOULD）。
これらの管理は、特に同期をサポートし、FIPS 140 の検証を含む、既存の多要素ソフトウ ェア暗号認証の要件および AAL2 の要件に追加するものとみなされるものとする。
秘密鍵の同期に使うファブリック（要するにクラウドストレージやiCloudやGoogle Platformなど）の保護レベルはFISMA（米国連邦政府のセキュリティ基準）のModerate（平均レベル）もしくは同等が求められています。
また、同期ファブリックへのアクセス制御についてはIAMなどによりしっかり管理されている必要がある、ということなので共有パスワードグループはこの辺りに引っかかるんじゃないかな、、と思います。多分、企業などでiOSやmacOSを使う場合はMDMなどで共有パスワードグループを制御する（できるかどうかは知りませんが）ことが必要になりそうです。
2024年5月6日月曜日
NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む（２）
こんにちは、富士榮です。
引き続きNIST SP800-63-3の追補版を見ていきます。
前回はイントロ、文書の目的について読みましたが今回はAAL2の要件と同期可能な認証器の関係性について見ていきます。
では早速。
Syncable Authenticators Achieve AAL2
NIST の認証機関保証レベルは、主に、認証プロセスに対する特定の脅威から保護する認証機 関の能力を中心に構成されている。AAL2 では、ユーザが 2 つの 1 要素認証子、またはユーザ・アカウントにバインドされた多要素 認証子を所持しているという高い信頼性を提供することが意図されている。表 1 は、SP800-63-3 から要求される脅威の緩和と、適切に構成された同期可能な認証子がこれらの 脅威からどのように保護されるかを示している。
SP 800-63-3 による必要な脅威の緩和（表 4-1）
セクション5では、同期可能な認証器の設定に関する追加的な考慮事項について論じる。
AAL2 要件を満たすために、同期可能な認証器は、ローカルに保存された鍵をアンロックするた めにローカル認証イベントを利用しなければならない[SHALL]。あるいは、ローカル認証の仕組みが 利用できない場合は、別の認証手段(たとえば、ユーザが選択したパスワード)と併用しなければ ならない[SHALL]。FIDO2 Web認証(WebAuthn)コンテキストでは、W3C Web認証仕様の認証子データで利用可能な User Verificationフラグの値によって示される。FIDO2 WebAuthn 認証データフラグの詳細については、セクション5を参照のこと。
ポイントは最後の一文で、やはり同期クレデンシャル「だけ」ではダメで、ちゃんとローカル認証イベント（たとえば端末アンロックの利用など）を使う必要がある、ということに触れたところでしょうか。
次回も引き続き読んでいきたいと思います。
2024年5月4日土曜日
NIST SP800-63B-3の同期可能クレデンシャルに関する追補版を読む（１）
こんにちは、富士榮です。
先日紹介した通り、NIST SP800-63-3の追補版という形で同期可能なクレデンシャルの取り扱いに関する文書がリリースされました。
今回から中身を少し見ていこうと思います。
しかし、ちょうど最近iOSやmacOSの共有パスワードグループでAirDrop環境外でもパスワードに加えてパスキーまで共有ができるようになった、というアナウンスが界隈では話題に上りました。なんだか単純な同期の話だけでは済まなくなってきてしまった気もしますが、この機能がこのガイドラインにどのような影響を与えるのかは継続ウォッチということで、まずはガイドライン（追補版）を見ていきましょう。
参考）共有パスワードグループ
Introduction
NIST デジタル ID ガイドラインは、ID 証明、認証、およびフェデレーションを 含む、デジタル ID のプロセスと技術要件を規定している。NIST 特別刊行物（SP）800-63B（SP 800-63-3 に関連する第 B 巻）は、認証およびライフサイクル管理 の要件を特に取り上げている。改訂 3 は、このガイドラインの最新の大幅な改訂であり、2017 年 6 月に発行された。シリーズ全体の更新が進行中であり、改訂 4 で完結する予定であるが、技術のペースは NIST の典型的な文書開発およびレビューのプロセスよりも速いため、この補足的な更新が正当化される。SP 800-63B で扱われるこのような認証タイプは、多要素暗号認証である。通常、この認証タイプは、ハードウェアまたはソフトウェアで暗号鍵を保護し、第 2 の認証要素（記憶された秘密またはバイオメトリック特性のいずれか）による起動を必要とする。秘密鍵を不正な暴露から保護することは、多要素暗号認証機のセキュリティ・モデルの基本である。これには従来、秘密鍵がエクスポートまたはクローン可能でないことを保証することが含まれる。しかし、このパラダイムは変わり始めている。特に、新しい一連の認証プロトコルと仕様により、同期可能な認証子（一般に「パスキー」と呼ばれる）が急速に採用されるようになり、ユーザが異なるデバイス間で秘密鍵を同期（つまり、 複製）できるようになった。SP 800-63-3 が 2017 年に発行されたとき、2 つの重要なサポート仕様である Fast Identity Online (FIDO) Client to Authenticator Protocol (CTAP) と W3C の Web Authentication（一緒に使用される場合は FIDO2 として知られる）は存在せず、実装の強固でよく理解されたエコシステムもなかった。当時利用可能であった暗号認証の種類に基づき、2017年のガイドラインは、多要素暗号認証が他のデバイスに鍵を「クローン」する能力を制限した。しかし、この2年間でエコシステムは急速に加速し、現在ではほとんどの主要なプラットフォーム・プロバイダが、スケーラブルで同期可能な認証機能を実装している。これらの認証機能は、耐フィッシング性のサポート、特定の依拠当事者にバインドする機能、パスワー ドを送信する必要性の排除、認証機能のリカバリの簡素化、保存された秘密鍵に付随する第 2 要素とし ての多様なデバイス固有の生体認証および PIN の使用など、多くの利点を提供する。また、ますますマルチデバイス、マルチプラットフォーム化する世界に適合する利便性も提供する。どのような新しい技術もそうであるように、技術革新の約束には、探求し理解しなければならない新たな脅威と課題が伴う。そのため、この補遺では、連邦機関が同期可能な認証機能を実装するかどうか、またどのように実装す るかを決定する際に、現代の脅威を含めて考慮すべき事項の概要を示す。
まぁ、先日のポストにも書いた通り、時代が変わったのでver.4を待たずに追補版で同期可能なパスキーに関してちゃんと分析して考慮をしよう、という話です。
次に文書の目的です。
Purpose
この文書の目的は、変化する認証およびクレデンシャルの市場を反映するために、現行の NIST ガイドラインを適合させることである。この補足では、SP 800-63-3 で確立された認証保証レベルと一致する方法で、同期可能な認証機能がどのように脅威を軽減するかを説明し、SP 800-63-3 認証保証レベル 2（AAL2）を達成するために活用できる同期可能な認証機能の理解を連邦機関に提供する。また、SP 800-63B の第 5.1.8 節で説明されているソフトウェア暗号化認証子の使用に関する最新情報、 特に、鍵が別のデバイスに複製（例えば、「クローン」または「同期」）された場合でも、当該認証子が AAL2 認証要件をサポートする能力についても提供する。最後に、本文書は、公衆向けアプリケーション（すなわち、OMB Memorandum M-19-17 に記 載されているように、公衆 ID と相互作用する連邦情報システム）と連邦エンタープライズ・ アプリケーション（すなわち、OMB Memorandum M19-17 に記載されているように、主に連邦エ ンタープライズ ID と相互作用する連邦情報システム）という 2 つのユースケースに基づ いて、実装に関するいくつかの考慮事項を示す。この文書は、SP 800-63-3 にある既存のガイダンスを補足するものであり、SP 800-63B-4 の最終版に取って代わられる。
記載の通りですが、同期可能であってもAAL2を達成できることを説明するための資料になっているってことですね。また、当然ですが最終的にはver.4へ統合されていく文書というわけです。
ということで、ちょっと長めのシリーズになりそうですが徐々に見ていきたいと思いますので、今回はここまでです。
2024年4月24日水曜日
NIST SP800-63Bへの同期可能な認証器に関する補足文書がリリースされています
こんにちは、富士榮です。
パスキーを使う際に、AppleやGoogle、Microsoftなどのクラウドプラットフォームを通じたデバイス間で鍵の同期を行うSyned Passkeysをどう扱うか？、つまりそもそもFIDO認証の良いところはデバイスとの紐付けが強固であることだったはず、一方で鍵のリカバリが認証強度の弱点となりクレデンシャルの盗難や不正利用のきっかけになってしまう、その意味で鍵の同期は必要なのである、といった論争もひと段落してきたわけですが、その意味でパスキーを念頭においた各種ガイドラインについても更新される時期が来ているのかもしれません。
今回、NISTからSP800-63Bに関する同期可能な認証器に関する補足文書が公開されています。
アナウンス原文はこちら）
公開された文書はこちら）
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63Bsup1.pdf
アナウンスに概要が記載されているので紹介しておきます。（Google Webページ翻訳）
補足文書とは何か？
補足は、既存の NIST Special Publication (SP) を強化、拡張、または詳しく説明することを目的とした特定の文書タイプです。これにより、SP 全体を更新するプロセスを経ることなく、対象を絞った更新や変更が可能になります。これらは、NIST がテクノロジーとリスク環境の変化により迅速に適応するためのメカニズムを提供します (たとえば、同期可能な認証システムのような新しい認証システム タイプの要件を提供します)。
同期可能な認証器とはなにか？
同期可能な認証システムは、秘密キーを複製して認証システムとは別に保存して、異なるデバイス間でのその鍵の使用 (同期など) をサポートできる暗号化認証システムです。実際には、これらは通常、FIDO Allianceによって「パスキー」と呼ばれるもので、Client-to-Authenticator Protocol や World Wide Web Consortium (W3C) の Web Authentication (WebAuthn) などの複数の標準およびプロトコルを利用します。
正しく実装されると、シンプルなリカバリ、クロスデバイスのサポート、消費者に優しいプラットフォーム認証サポート (ネイティブ生体認証など) など、多くの利点を備えたフィッシング耐性のある認証システムが提供されます。このような認証システムは、デジタル ID ガイドラインのコンテキストでは非準拠とみなされ、補足では、認証保証レベル 2 (AAL2) での使用を許可するための追加の要件と考慮事項が規定されています。
ガイドライン（SP800-63-3）が発行されてからの世の中の変化は？
多くのことが変わりました。ガイドラインが最初に開発および発行された時点では、同期可能な認証システムをサポートするための標準と仕様は開発されていませんでした。それ以来、標準は成熟し、ほとんどの主要な消費者プラットフォームが同期可能な認証システムのサポートを導入しました。 FIDO Alliance はこれまでのところ、80 億を超えるユーザー アカウントが認証にパスキーを使用するオプションを備えていると推定しています。まだどこにでも普及しているわけではありませんが、日に日に一般的になってきています。
鍵の複製に関するリスクは？
そう、リスクは常に存在するのです。補足の要件は、キーの保存、送信、保護の方法を含め、これらの要件にできるだけ多く対処することを目的としています。同期可能なオーセンティケーターには特有のリスクが伴います。特に、一部の技術実装におけるユーザーが自分の認証キーを他の個人と共有する機能です。認証子を共有する機能は同期可能なキーに固有のものではなく、ほぼすべての AAL2 認証子を共有できます。しかし、長年のセキュリティ ポリシーに反して、一部の実装では、多くの消費者シナリオでパスワード共有の安全な代替手段として同期可能な認証子の共有を推進しています。
すべてのインスタンスと同様に、組織は、提供するあらゆるタイプの認証システムを評価し、実装する前にそれに伴うメリットとリスクを比較検討する必要があります。同期可能なオーセンティケータは、すべてのアプリケーションやサービスに適しているわけではありませんが、エンドユーザーと信頼当事者の両方に多くのメリットをもたらす、新たな AAL2認証器オプションとなります。
パブリックコメント期間は設けられるのか？
この更新文書には適していません 。 SP 800-63-4 に関する最初のパブリック コメント期間からのフィードバックがこの補足資料に組み込まれました。同期可能な認証システムと補足の全体的な内容に関する追加のコメントは、リビジョン 4 の今後の第 2 回パブリック コメント期間を通じて提出できます。これは今年後半に行われる予定です。
SP800-63-4を待たないのか？
上で述べたように、デジタル ID ガイドラインの規範文に厳密に従っている政府機関は、同期可能な認証システムを使用することを許可されません。この補足では、連邦ゼロトラスト戦略をサポートする強力で使いやすく、フィッシング耐性のある認証を提供する新しいセキュリティ技術の使用方法についての指示を提供することで、多くの政府機関の当面のニーズに対応しています。リビジョン 4 が完成すると、この補足は廃止されます。
技術や状況は日々変わってきているので柔軟にガイドラインも対応していく必要がありますね。
登録:
投稿 (Atom)
投稿
