2024年11月6日水曜日

AuthZEN WG Authorization API 1.0 Implementer's draftの投票期間がもうすぐ始まります

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

9月にPublic Review期間に入ったAuthZEN WGのAuthorization API 1.0のImplementer's draftですが来週11/7〜14で投票期間に入ります。


https://openid.net/notice-of-vote-implementers-draft-authzen-authorization-api-1-0/


認可の標準化は人類の長年の夢だったのでこの機会に仕様を学んでフィードバックをぜひしていきましょう。

APIの概要はこちらに書いています。




2024年11月5日火曜日

DID CommのFormal Verificationとセキュリティ強化

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

クレデンシャル交換のプロトコルとして適しているのはDID CommなのかOpenID for Verifiable Credentials(OID4VC)なのか、という議論がひところ各所で聞かれましたが最近はそんな議論も落ち着いてきているのかな?と思っている今日この頃です(エコーチェンバー)。

当時、DID Commを否定的に捉える論拠の一つにFormal Verificationもすんでないじゃん、という話がありましたが、ようやく?やったみたいです。

What Did Come Out of It? Analysis and Improvements of DIDComm Messaging



Abstractにはこんなことが書いてあります。
Self-Sovereign Identity (SSI) empowers individuals and organizations with full control over their data. Decentralized identifiers (DIDs) are at its center, where a DID contains a collection of public keys associated with an entity, and further information to enable entities to engage via secure and private messaging across different platforms. A crucial stepping stone is DIDComm, a cryptographic communication layer that is in production with version 2. Due to its widespread and active deployment, a formal study of DIDComm is highly overdue.
We present the first formal analysis of DIDComm’s cryptography, and formalize its goal of (sender-) anonymity and authenticity. We follow a composable approach to capture its security over a generic network, formulating the goal of DIDComm as a strong ideal communication resource. We prove that the proposed encryption modes reach the expected level of privacy and authenticity, but leak beyond the leakage induced by an underlying network (captured by a parameterizable resource).
We further use our formalism to propose enhancements and prove their security: first, we present an optimized algorithm that achieves simultaneously anonymity and authenticity, conforming to the DIDComm message format, and which outperforms the current DIDComm proposal in both ciphertext size and computation time by almost a factor of 2. Second, we present a novel DIDComm mode that fulfills the notion of anonymity preservation, in that it does never leak more than the leakage induced by the network it is executed over. We finally show how to merge this new mode into our improved algorithm, obtaining an efficient all-in-one mode for full anonymity and authenticity.

自己主権型アイデンティティ(SSI)は、個人や組織が自分のデータを完全にコントロールできるようにする。分散型識別子(DID)がその中心であり、DIDには、エンティティに関連する公開鍵のコレクションと、エンティティが異なるプラットフォーム間で安全かつプライベートなメッセージングを介して関与できるようにするためのさらなる情報が含まれている。その重要な足がかりとなるのがDIDCommであり、バージョン2で製品化された暗号通信レイヤーである。DIDCommは広く活発に展開されているため、DIDCommの正式な研究は非常に遅れている。

本稿では、DIDCommの暗号技術に関する初の形式的分析を行い、(送信者の)匿名性と真正性というDIDCommの目標を形式化する。DIDCommの目標を強力な理想的通信リソースとして定式化することで、一般的なネットワーク上での安全性を実現する。提案する暗号化モードは、期待されるプライバシーと真正性のレベルに達するが、(パラメータ化可能なリソースによって捕捉される)基礎となるネットワークによって誘発される漏洩を超えて漏洩することを証明する。

次に、匿名性と真正性を同時に達成し、DIDCommメッセージフォーマットに適合し、暗号文のサイズと計算時間の両方において、現在のDIDCommの提案をほぼ2倍上回る最適化アルゴリズムを提示する。最後に、この新しいモードを改良されたアルゴリズムにマージする方法を示し、完全な匿名性と真正性を実現する効率的なオールインワンモードを得る。


中身はまだ細かく見ていませんが、しっかりと分析を行うプロセスが実行された、ということなので良かったんじゃないかと思います。

いずれにしても特にIoTのユースケースなどDID Commの方が適しているものもある気がしますので、ちゃんと適切にプロトコルを選択していけると良いかと思います。


2024年11月4日月曜日

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

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

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


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

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


2024年11月3日日曜日

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となっており気が付かないまま3ヶ月経過しているので。

そもそも論として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文字以上って言うのもあんまりないとは思いますが。

2024年11月2日土曜日

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

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

2024年11月1日金曜日

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ということでこれからドイツ経由のダブリンへ移動します。。。






2024年10月31日木曜日

IIW 39 Day2クィックレビュー

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

ということでInternet Identity Workshop(IIW)も2日目です。

今日は朝からワーキンググループコールも入っていたので早めの時間から会場でZoomコールをしていたのでより疲れました。

ということで、本日のレシピは、
  • Delegation + Impersonation for Agents on behalf of human
  • Wallet + Key Attestation
  • Zero Knowledge Proof for mdoc
  • Originator Profile
  • JSON-LD VC with BBS Signature
の5本です。

ということで観ていきます。

Delegation + Impersonation for Agents on behalf of human… OIDC, OAuth

まずひとつ目です。最近よくきくエージェントに自分の代わりに何かをさせましょう、って話です。


まぁ、色々と話はしましたが結果的にOAuthのモデルに当てはめるとどう考えられるのか?という話だったのでそれほど目新しさはなかったですね。

当てはめとしては、
  • Resource owner : End user
  • Client : Agent
  • Relying party : API
とおいているので、まぁそうでしょうねぇ。

Agentかどうかは置いておいて普通のOAuthですね。Token Exchangeつかえそうだね、みたいな話もありましたが。

Wallet + Key Attestations - Paul, Christian, Kristina

ドイツのWalletの検討の話です。かなりノウハウが溜まってきていますね。

検討の対象は以下の2つのアテステーションです。
  • Wallet/Client Attestation:ウォレットが正しいかどうかを示す
  • Key Attestation : キーストレージの状態とユーザの認証状態を示す
EUでは政府認定の民間ウォレットに対して国がクレデンシャルを発行する、というモデルを取るため、野良ウォレットでないこと、ユーザが認証されていること、秘密鍵がちゃんと管理されていることを示さないとクレデンシャルの発行など怖くてできないわけです。

チェックのタイミングについても色々と考えていて、
  • Issuerがクレデンシャル発行をする際:WalletもKeyも必須
  • ウォレットからVerifierへクレデンシャルを提示する際:オプション(Issuerが発行時に確認しているから推移的に確認できる、という判断もあり)


アテステーション自体はWallet Providerが発行します。
ここの発行・管理プロトコルは標準化されていませんが、いずれ標準になってくるのかもしれません。(まぁウォレットベンダーがそれぞれやってよ、でもいいんだと思いますが)

この仕組みがあることで、以下のようなシナリオに対応ができるようになります。
  • スマホの機種変更
  • 複数端末の利用の管理
  • 端末を盗まれた、無くした
  • ウォレットに脆弱性が見つかった
どう言うことかと言うと、Issuerはクレデンシャルを発行する時に発行先のWalletの情報(アテステーション)を管理しているので、ウォレットプロバイダがウォレットアテステーションをRevokeするのをトリガーにIssuerは発行済みのクレデンシャルをRevokeする、という使い方ができます。こうすることで機種変更時や盗難時などに以前の端末に入っていたクレデンシャルを一括で無効化できるので安心、というわけです。
属性証明と違って本人確認書類とし利用する身分証明書となるとやはり発行管理が必要になるので、日本のように民間のウォレットがマイナンバーカードに依拠したクレデンシャル(いわばマイナンバーカードのコピー)を身分証明書として利用できるなんて変なことは起きないわけですね。

ちなみにVerifierに提示する際にWalletアテステーションを提示するかどうか、って議論もありましたが個人的にはLinkabilityが上がっちゃうのでやめたほうがいいんじゃないかな?って思います。やっぱりIssuer側でちゃんと管理って世界なのかと。

Zero Knowledge Proof for mdoc - Google

次はGoogleの方からmdocに関するZKPの実装の話です。

先ほどのWalletアテステーションのセッションのところにも書きましたが、mdocでもSD-JWTでもプロトコルの一部としてリンク可能性を高めてしまう情報が埋め込まれてしまうことがあります。
これをなんとかできないか?って話ですね。


そうするとデバイスとのバインドを示す鍵の置き場所はSEに限られてしまう、と。
この鍵はPresentation時に使われるので、BBS+などIssue時にデバイスバインドされた鍵の変更を要求する仕組みを使うのは非常に難しいってことになってしまいます。何しろ一番下のレイヤーの変更をしなきゃいけないって話になるので。

mdocやSD-JWTで選択的情報開示をすることでデータ見にマイゼーションの問題が解決できたとしても、リンク可能性の問題が残っちゃうよね、って話は前からありましたが、いよいよそこに手をつけ始めようとしている感じですね。



Googleでは内部ロジックの高速化などを図り、BBS+など従来の”スマートな”方法ではない方法(Hyrax)を模索していく、ということです。


Originator Profiles - Shigeya Suzuki

鈴木先生によるオリジネータープロファイルの話です。
何気に中身を詳しく聞いたことはなかったので非常に興味深かったです。

コンテンツの発行元とコンテンツの内容の真正性の両方をちゃんと検証できるようにしましょう、って話に加えて認められた場所(アグリゲーターなど)でその情報が発信されているかどうかを確認できるようにしましょう、という仕組みです。

現状はブラウザにエクステンションを入れてチェックするとブラウザの中で表示されているコンテンツ(ニュースなど)がどのメディアによって発行されたものなのか、そのメディアはどう言うプロファイルなのかなどが確認できるのと、ちゃんと許可されたサイトでコンテンツが表示されているか確認できます。

偽情報・誤情報を利用者自身で確認できるようになるのはいいですし、広告主が意図しないサイトに広告が掲載されてしまうことが防げるようになるとブランドイメージの保護などにも役立ちそうです。

今後が非常に楽しみです。


JSON-LD VC with BBS - Dan Yamamoto

最後はIIJの山本さんのBBSの話です。


BBSの部分は前回まででほぼ完成しているので今回のポイントはやはりリンク可能性です。今日はこのテーマで1日終わった感じです。やはり熱い領域です。

山本さんのアプローチはPseudonym did:keyを使うということです。
これはひとつの秘密鍵に対応する複数の公開鍵を作成できる技術をうまく使ってIssue時、Verify時にSubject Identifierとして使う署名検証鍵を含む識別子(did:key)の出汁わけができる、と言うことです。

ドメイン単位でこれを使うことでInner domain linkabilityとinter domain linkabilityの両方を実現できるわけですね。



まだ標準化へ持ち込めているわけではないそうですが、今後の標準化が望まれますね。


ということで明日は最終日です。