こんにちは、富士榮です。
いよいよ来週はAuthenticate 2024ですね。残念ながら参加できませんが。
ということで、Authenticateに向けて各社パスキー周りの話題が進んできていそうです。
MicrosoftからもWindowsのパスキー対応について記事を公開しています。
Passkeys on Windows: Authenticate seamlessly with passkey providers
こちらの機能がWindows Insiderチャネルで配信されるようです。久しぶりにWindows PCでも触ろうかな・・・
サードパーティプロバイダとの連携では1Passwordなどとの連携ができるようになるようです。3点目のMicrosoftが提供する同期ファブリックと連携できたりすると面白そうです。Credential Exchange Specificationが実装されてくると面白いと思います。
いずれにしても来週のAuthenticateで詳しく言及されるのかと思います。楽しみですね。
パスキーのデモにクレデンシャルの中身を解析する機能を追加しました。attestationObjectとかも中まで見えます。https://t.co/kWVU0flcfH pic.twitter.com/p6JDWZJkpf
— Eiji Kitamura / えーじ (@agektmr) August 28, 2024
こんにちは、富士榮です。
結局「パスキーはパスすべきなのか？」という話です。
昨日のポストでDean SaxeがIDProに反論記事を書いているということを書きましたが、今日はそちらを見ていきましょう。
Don’t Pass on Passkeys
https://idpro.org/dont-pass-on-passkeys/
 |
| IDProのポストより |
昨日取り上げたポストでは、結局認証器ベンダや同期ファブリックを運営しているベンダと鍵を共有することになる、とか、異なるベンダのプラットフォームを跨いでの鍵の同期や再利用ができないことが指摘されていました。
今回のDeanのポストではそれらの指摘に対して以下のように反論しています。
こんにちは、富士榮です。
パスキー便利ですよね。これまでもパスキー推しのトーンでポストを書いてきましたが、一方でX（旧Twitter）ではうまく使えない、動かない、などの声がリテラシーの高い層からも聞こえてくるのも事実です。
そんな中、IDProが「I’ll Pass (for now) on Passkeys」という記事を先日公開しています。
https://idpro.org/passing-on-passkeys/
 |
| IDProの記事より |
もちろん、IDProとしても著者個人の意見である旨を断った上で記事を掲載していますが、ある方面からの見え方としては正しいこともあるので把握しておくことは大切だと思います。
なお、別途書こうと思いますが、後日Dean Saxeが同じくIDProに反論（？）記事も書いているのでそれはそれで面白いです。
今回は「今の所、パスキーはやめとくわ」っていう著者の主張を見ていきましょう。
主な理由として、以下を挙げています。
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が発生した場合に過去に設定したパスキーが見つからないとか、詰む、などサービス側の問題な気がしているんですが。。。
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 の使用など、多くの利点を提供する。また、ますますマルチデバイス、マルチプラットフォーム化する世界に適合する利便性も提供する。どのような新しい技術もそうであるように、技術革新の約束には、探求し理解しなければならない新たな脅威と課題が伴う。そのため、この補遺では、連邦機関が同期可能な認証機能を実装するかどうか、またどのように実装す るかを決定する際に、現代の脅威を含めて考慮すべき事項の概要を示す。
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 の最終版に取って代わられる。
こんにちは、富士榮です。
なんだかステマっぽいですがそういう訳ではありません。
昨年末のFIDOアライアンスのイベントでAuthentrendの方から最新のカード型のパスキー「ATKey.Card NFC Bio-ID」をいただいたので試してみます。（いただいた段階では管理用のアプリがストア公開されていなかったので試せずにいたのですが2月に入りようやく公開されたので試せるようになりました）
こちらが製品のページです。
こんなやつです。
パスキーとしてみた場合は単なるNFCタイプの指紋センサー付きの外部セキュリティキーとして使えます。
早速試してみましょう。
こんにちは、富士榮です。
もうすでに記憶の彼方ですがLINEさんは過去にFIDO2サーバーをOSSで公開する！と宣言していました。それが遂に公開されました！素晴らしい！
ということでとりあえず動かしてみました。（まだ中身は全然みてません、単に動かしただけです）
LINE Security R&DチームがFIDO2認証標準を実装したFIDO2 ServerをOSSとして公開しました。
— LINE Developers (@LINE_DEV) August 5, 2021
FIDO2-Serverは、FIDO2の登録と認証の主要部分を提供します。さまざまなWebブラウザとOSプラットフォーム、および生体認証をサポートします。#fido2 #LINE_OSShttps://t.co/o4EhxpyWAi
とりあえず公開されているレポジトリをcloneしてREADME.mdに記載の通り動かしてみました。
# Start RP Server cd rpserver ./gradlew bootRun # Start FIDO2 Server or Line-fido2-spring-boot Demo cd server ./gradlew bootRun cd spring-boot-starter/line-fido2-spring-boot-demo ./gradlew bootRun
やることとしては以上です。
これで http://localhost:8000 にアクセスするとテスト用のトップ画面が出てきます。
まず画面上部のuser nameとdisplay nameに適当に名前を入れます。
— Naohiro Fujie (@phr_eidentity) 2018年10月3日
投稿
すべてのコメント
