今年もDigital Identity技術勉強会のAdvent Calendarの季節がやってきた

こんにちは、富士榮です。

毎年恒例のAdvent Calendarの季節になってきましたね。（はやい・・・）

ということでDigital Identity技術勉強会（#iddance）のAdvent Calendarも作られていますので、この機会にぜひ皆さん参加しましょう。

https://qiita.com/advent-calendar/2024/iddance

Okta AD/LDAP DelAuthモジュールに関する脆弱性

こんにちは、富士榮です。

Okta社よりAD/LDAP DelAuthモジュールに関する脆弱性が報告されていますね。

https://trust.okta.com/security-advisories/okta-ad-ldap-delegated-authentication-username/

報告されている内容としては、AD/LDAP DelAuthモジュールを使っている環境で、過去にキャッシュログインに成功したことのある場合、ユーザー名が52文字以上だとパスワードなし（キャッシュのみで）ログインが成功してしまう、という話です。

こちら上記のサイトからの引用です。

On October 30, 2024, a vulnerability was internally identified in generating the cache key for AD/LDAP DelAuth. The Bcrypt algorithm was used to generate the cache key where we hash a combined string of userId + username + password. During specific conditions, this could allow users to authenticate by only providing the username with the stored cache key of a previous successful authentication.

Note: A precondition for this vulnerability is that the username must be or exceed 52 characters any time a cache key is generated for the user.

2024年10月30日、AD/LDAP DelAuthのキャッシュキーの生成において、内部的に脆弱性が確認されました。キャッシュキーの生成には Bcrypt アルゴリズムが使用され、userId + username + password を組み合わせた文字列がハッシュ化されます。特定の条件下では、ユーザー名と、過去に認証に成功した際に保存されたキャッシュ・キーだけを提供することで、ユーザーが認証できる可能性があります。

注：この脆弱性の前提条件として、キャッシュ・キーが生成される際には、ユーザー名が52文字以上でなければなりません。

すでにOktaのプロダクション環境では解消されているようですが、本モジュールを利用している場合（特にAD連携をしている場合はほぼ必ず使っているはずのモジュールなので）は、ユーザ名が52文字以上あるユーザがいるかどうか、侵入の痕跡がないか、など確認しておいた方が良さそうです。タイムラインを見ると脆弱性のあるモジュールがリリースされたのが2024/7/23で、発見されて対応されたのが2024/10/30となっており気が付かないまま３ヶ月経過しているので。

そもそも論としてAD/LDAP DelAuthってなんだ？って人もいると思うので簡単に。

要するに、クラウド上にあるOktaへオンプレのADやLDAPのパスワードを使ってログインできるようにするモジュールです。

AD版はこちら

https://help.okta.com/en-us/content/topics/security/enable_delegated_auth.htm

LDAP版はこちら

https://help.okta.com/en-us/content/topics/security/security_authentication.htm

ざっくりとした仕組みですが、Oktaへの認証要求があるとオンプレのAD/LDAPへ認証要求が行われ、成功するとパスワードハッシュのキャッシュがOktaクラウド側に置かれ、以降キャッシュが有効な間はオンプレ側への問い合わせなしにクラウド側だけで認証処理が行われる、という感じです。

すでに対応は終わっているとは言えなかなかな脆弱性ですね。。。

まぁ、ユーザ名が52文字以上って言うのもあんまりないとは思いますが。

OpenID for Verifiable Presnetationsの新しいImplementer's draftのPublic Reviewが始まりました

こんにちは、富士榮です。

IIWや、その前日のOpenID Foundation Workshopでも取り上げられていたとおり、OpenID for Verifiable Presentationsの新たなImplementer's draftのPublic Review期間に入りました。

アナウンス

https://openid.net/public-review-period-for-proposed-third-implementers-draft-of-openid-for-verifiable-presentations-specification-3/

主な更新はこちら

1. Introduces the Digital Credentials Query Language; this is an alternative to Presentation Exchange
2. Introduces the transaction data mechanism that enables a binding between the user's identification/authentication and the user’s authorization, for example to complete a payment transaction, or to sign specific document(s) using QES (Qualified Electronic Signatures).
3. Removes the client_id_scheme parameter and instead makes the client id scheme a prefix on the client_id; this addresses a security issue with the previous solution.

1. デジタル・クレデンシャル・クエリ・ランゲージ（Digital Credentials Query Language）を導入。
2. トランザクション・データ・メカニズムを導入し、ユーザの識別/認証とユーザの認可の間のバインディングを可能にする（例えば、支払いトランザクションの完了や、QES（Qualified Electronic Signatures）を使用した特定の文書への署名など）。
3. client_id_schemeパラメータを削除し、代わりにクライアントIDスキームをclient_idのプレフィックスとする。

今後のスケジュールはこちら

• Implementer's Draft public review period: Friday, November 1, 2024 to Sunday, December 16, 2024 (45 days)
• Implementer's Draft vote announcement: Tuesday, December 3, 2024
• Implementer's Draft early voting opens: Tuesday, December 10, 2024
• Implementer's Draft official voting period: Tuesday, December 17 to Tuesday, December 24, 2024

年内に承認されそうですね。実装中の皆さんは対応方針を考えておきましょう。

IIW 39 Day3クィックレビュー

こんにちは、富士榮です。

いよいよIIWも最終日です。

かなり疲れてきたので頭が回らず英語が聞き取れなくなってきました。（来週いっぱいまで英語生活なので週末はゆっくりしないと・・・）

ということで今日も楽しい話題がいっぱいでした。

Credential Status Comparison Mechanisms - Paul

以前も書いたStatusList周りを含むクレデンシャルの取り消しに関する話題です。

確かに色々な方法があるんですよねぇ。古き良きOCSPとか。。。

そもそもクレデンシャルの取り消しをしたくなるトリガーとしては、こんなことが挙げられます。

• Credentialデータセットが無効（例えばover18になった）
• 発行システムの侵害
• アルゴリズムの危殆化（量子コンピューターの発展など）
• ウォレットや鍵の侵害

ドイツ政府はイタリアやフランスと協力してシナリオと方法論の比較検討を進めているみたいです。考えているシナリオはこんなところだそうです。

• ユーザが死んだ
• ユーザが自らRevokeしたい（スマホなくした）
• キーストレージが脆弱性にさらされた

この辺りをスケーラビリティとプライバシー（Linkability）を考えつつ解くのは難しい問題ですよねぇ。。

こんなクライテリアで比較しているそうです。

• Credential format（対応している種類）
• Technology readiness level（成熟度）
• Status tracking by verifier（トラッキング）
• Holder tracking by issuer（トラッキング）
• Unlinkability（紐付け可能度合い）
• Complexity(0が高い）
• Scalability(0が高い）
• Offline/caching（オフラインシナリオへの対応）

色々と考慮点はあって、例えばBitStringでStatusListを作るとある程度サイズ圧縮は効くもののの上限はあるので、一定期間でガベージコレクションをしたり、クレデンシャルのバッチ発行をすることでリンク可能性に対策できるかどうか考えたり、、と。

しかし、こう言う比較検討の段階でIIWのようなプロフェッショナルが集う場所へ投げ込んでブラッシュアップするって方法、本当にいいと思うんですよね。プレゼンする方も「こう思うんだけどどう？」って投げかけてちゃんとその場で議論になる。これを政府や金融機関の中の人たちがちゃんとオープンな場でやっている、ってなかなか日本では考えられないことだと思います。日本政府もこう言う場に来ればいいのに（チラッ）

Digital Credentials API - Tim

次はDigital Credentials APIの話です。

カスタムURLスキームでウォレットが起動されるのではなくFIDOと同じようにCredentials APIで起動できるようにしましょう、って話です。

そもそもカスタムURLスキームで何が問題だったか、というと

• 安全ではないコンテキストでアプリを起動
• デバイス上でのフィッシング（悪意のあるアプリを選択）
• リクエスターオリジン、アイデンティティがない

ということなので、この辺りはパスキーから学ぼうよ、という話です。この辺りが学びとしてあげられていました。

• 呼び出し元のコンテキストがキーとなっている
• クロスデバイス認証はセキュア・簡単・フィッシング耐性があることが必要

こんな構造です。

FIDOにおけるCTAPとWebAuthnとよく似てますね。

こんな感じで動くようです。

APIも割とシンプルです。

Presentation

let digiCred = await navigator.credentials.get({

signal: controller.signal,

digital: {

requests: [{

protocol: "openid4vp",

data: "{request json}"

}]

}

});

Issuance

let digiCred = await navigator.credentials.create({

signal: controller.signal,

digital: {

requests: [{

protocol: "openid4vci",

data: "{request json}"

}]

}

});

この辺りでdemoが見れますよ。

https://digital-credentials.dev/

OID4VCI Browser API Issuance Profiles - Joseph, Kristina, Paul

色々なシナリオを網羅的に考えていかないと社会基盤としては使えないということでかなり色々なユースケースを考えていますね。

https://bmi.usercontent.opencode.de/eudi-wallet/eidas-2.0-architekturkonzept/flows/Presentation-During-Issuance/

こちらにあるようなPresentationの結果を受けてIssuanceを行う、というシナリオもその一つです。

例として、学校でDegreeを発行してもらう際にmDLを提示して本人確認をする、みたいなシナリオが挙げられていました。

Presentationの結果を受けてPre-authorization用のコードを発行〜そのままOID4VCIを走らせるってことですね。

これもプレゼンテーションを行うクレデンシャルが入っていたWalletとIssuanceを行う先のWalletが異なるケースにどうやって対応するのか？みたいな話で議論が盛り上がりました。

OIDC4VCI Credential Versions / Purpose on presentation - Oliver, Daniel

こちらが最後のセッションでしたが、またマニアックな話題でした。

前半パートはOliverがクレデンシャルにバージョンをつけるとするとどうなるのか？という話をしていました。（何をもってそのバージョンが最新であるか、を証明することも含め）

まぁ、バージョンと言っても色々な解釈があるのでその辺りの整理をして議論をするところまで、となりましたが。

1. 同じクレームとバリューを含んでいるが、別デバイスの鍵とバインドされていたり、別で発行された
2. クレームは一緒でも値が異なる。値が変わった場合、Frequent Flyer Statusが変わった場合など
3. クレームは一緒でも値が異なる場合。なぜなら別の人やものに関するもの
4. クレームも値も異なる。全然別のクレデンシャルなので

誰がトリガーで発行し直すのか、Shared Signalで通知するのが良いのか、、などなど。。

後半はDanielがPresentation requestの中のクエリ言語（PEやDCQL）に指定するpurposeについての話題。（これもコアだな）

現状はクレデンシャルの単位でpurposeを指定するので、クレデンシャルセット全体に関するpurposeってないよね、とか多言語対応させるにはどうするべきなのか？みたいな話題で盛り上がりました。こちらも時間切れ。

ということであっという間の3日間でした。

とりあえず次はIETFということでこれからドイツ経由のダブリンへ移動します。。。