しばらく認証関係の仕事から離れていたうちに、いよいよパスワードレスが現実的となりNISTもSP800を更新しちゃうような仕組みが確立されつつあった。
PassKeyである。自分なりに整理してみる。
PassKeyとは
パスワード認証に変わる認証手段としてウェブサイトやアプリへのログインを簡単かつ安全に行うことを可能とするもの。
この2022年5月5月の#WorldPasswordDayにAppleから出た文書で初めてパスキーという言葉が使われたそう
（ていうか昨日ワールドパスワードデーだったんすね）
ここでは「FIDOサインインの認証情報」をパスキーと呼んでいる。
むむ、、FIDOサインインの認証情報、、FIDO2となにが違うのか、、？
FIDO2はWebAuthnとCTAPのことであり
WebAuthn→ WebブラウザーがJavaScriptを用いて秘密鍵にアクセスするためのAPI
CTAP→ クライアントと外部認証器間の通信をサポートする認証プロトコル
こちらの図がわかりやすかったので引用
FIDOのキモは、ユーザの「認証」はローカルで行うので、ユーザの識別情報がネットワーク上に流れないということ。
FIDO2まででは、認証器として想定されているものは
例えばYubiKeyのようなUSB/NFC/Bluetoothなどで接続可能な外部認証機器、
あるいはWindowsHelloのようなプラットフォーム内蔵の認証器
だったはず。
しかし、この方式では、デバイスの紛失やスマートフォンの機種変更など、認証器が使えなくなると認証不可能となり、新しいデバイスの再登録が必要となり、パスワード認証と比較して利便性が低下しました。この問題を解決するため、図右のように秘密鍵とそのメタデータに相当する「FIDO認証資格情報（FIDOクレデンシャル）」をクラウド経由で同期し、複数のデバイスで利用できるようにする仕組みが考案されました。（上述の大和総研資料より引用）
つまり、認証行為自体ローカルで行うという考え方は維持したまま
FIDO認証資格情報（＝パスキー）をクラウド経由で同期し利便性を高めたもの ということのよう。
googleであればGooglepasswordマネージャー、iOS/iPadOS/macOSではiCloud キーチェーンによってパスキーを同期するようです。
なお2022年段階ではパスキーの同期は同じエコシステム内のみ、つまりスマホをAndroidからiPhoneに乗り換えたとき、パスキーの同期はできなかったようですが、
現時点では例えばchromeのパスキーを使えばiCloud キーチェーンと同期ができるようです。
安全性は大丈夫なんだろうか？
もともと認証はローカルで行うのでネットワーク上に流れず、攻撃に強いというのがFIDOの利点だったはず。パスキーをネットワーク越しにクラウドと同期して大丈夫なんだろうか。
その答えとしては
複数デバイスでパスキーが同期される際はエンドツーエンドで暗号化されているので、そのためサーバ側での不正アクセスから保護されるようになっているとのこと。
そうなの？（そうなの？）
こちらの技術ブログが参考になった
パスキーでNIST SP800-63B で定義されている AAL3 (Authenticator Assurance Level 3) から外れてしまうという懸念はあるので、
パスワードを使い続けるのは論外として、利便性も悪くフィッシングに弱い認証方法を残さざるをえない従来の FIDO クレデンシャルと、利便性は高いがリスクが若干増してしまうパスキーと、どちらを選ぶべきかという話になります。ここはニーズで使い分けるのがベストではないかと思います。
ある程度リスクが許容できるユースケースであれば、利便性が向上した新しい選択肢が増えた、ということですね。
むむ、、ちょっと待てよ、、？
上述のNIST SP800-63Bは最近、同期可能なクレデンシャルの取り扱いに関する補足文書なるものが公表されている
一回読んだ時はなんかわかったようなわからなかったような感じだったけど
もしかしてここにパスキーの課題に対する見解があるのでは！
NIST SP800-63Bの補足文書
長いのでとりあえず結論を訳してみる（DeepLによる翻訳）
8. 結論
同期可能な認証子は、認証の状況、特に多要素暗号認証子の使用における実質的な技 術的変化を示 すものである。暗号鍵の複製とクラウド・インフラへの保存を許可する ことに関連するトレードオフの 評価は、必然的に行われることになる。このことは、 明確なリスク(認証鍵に対する企業の管理能力の喪失など)をもたらすが、同時に、一般市民や企業にとっての主要な脅威ベクトルを排除する、便利でフィッシングに強 い認証機能への道筋を提供する。同期可能な認証機能はすべてのユースケースに適しているわけではない。しかし、本補足文書に含まれるガイドラインに沿った方法で導入される場合、AAL2 リスク軽減策との整合性を達成し、フィッシング耐性認証の採用をより広範に促進することができる。
つまり・・？
ということですかね
この文書は腰を据えて後程ちゃんと読むとして、、気になったところをかいつまむと
- これまでのSP800-63Bでは「多要素暗号ソフトウェア認証機能は、複数のデバイスへの秘密鍵 のクローニングを抑制すべきであり、 また促進すべきではない (SHALL NOT)。」としていた。
- しかし今回以下要件満たせばAAL2 で想定される脅威から保護するために十分であるとみなされるものとする。
- その要件とは、例えば「承認された暗号技術を用いて生成する」など6項目（＋連邦企業向けに追加4項目）
どういうシーンで利用できるのか
すでにAmazonなどコンシューマ向けサービスでパスキーは実装されているし、ひさびさにこのブログ（はてな）にログインしたところパスキーを設定するかと言われた。このあたりはパスワードの代替として置き換わっていくのだろうと思った
自分の仕事の領域は行政DXなのだが、行政だと例えばGビズID（法人共通認証基盤）というIdPがある。OpenIDConnectのAuthorization Code Flowで実装されており、
gBizプライム/メンバーは当人認証保証レベルAAL2を保証する。現状では当人認証方法としてパスワード認証＋所有物認証方式（スマホアプリあるいはワンタイムパスワード）が実装されているが、パスキーだと
ローカル認証とサーバーでの署名検証で、合計二回認証していることにお気付きでしょうか？つまり、パスキーは単体で生体認証 (もしくは知識認証) と所有認証の二要素認証を行っている（上述の技術ブログより引用）
つまりパスキーだけで認証が完結し、ユーザの操作もかなりシンプルになり便利になるのではと思う
ただ一方で、パスキーを使う場合のAuthorization Code Flowがどんなフローになるのかまだイメージが沸いておらず、、今後考えてみます
（追記）
Xにて尊敬するIDプロフェッショナルな方々に反応をいただいたのでありがたくメモ
> ただ一方で、パスキーを使う場合のAuthorization Code Flowがどんなフローになるのかまだイメージが沸いておらず
— 👹秋田の猫🐱 (@ritou) 2024年5月6日
ユーザー認証部分だけパスキーに置き換わるのでOIDCのフロー自体には変更がありません。 https://t.co/d4fEWhIcnl
なるほどー。「OpenID Connect は認証手段独立なので、任意の認証手段（含むパスキー）と組み合わせられます。それによってフローは影響を受けません」というところから説明が必要なんですね。 OpenID Connect （OIDC ）とパスキー（ Passkeys ）の組み合わせ。 https://t.co/OQ2iff9AjG
— Nat Sakimura/崎村夏彦 (@_nat) 2024年5月6日
そうか、、認証リクエスト出した後IdP（OP）がユーザに認証求める時の手段が変わるだけでOIDCのフローは同じですね。確かに認証の方式は定めていないですね
（5/6）新規作成
（5/6）追記
