こんにちは、富士榮です。
9月にPublic Review期間に入ったAuthZEN WGのAuthorization API 1.0のImplementer's draftですが来週11/7〜14で投票期間に入ります。
認可の標準化は人類の長年の夢だったのでこの機会に仕様を学んでフィードバックをぜひしていきましょう。
APIの概要はこちらに書いています。
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の方が適しているものもある気がしますので、ちゃんと適切にプロトコルを選択していけると良いかと思います。
こんにちは、富士榮です。
毎年恒例のAdvent Calendarの季節になってきましたね。（はやい・・・）
https://qiita.com/advent-calendar/2024/iddance
こんにちは、富士榮です。
Okta社よりAD/LDAP DelAuthモジュールに関する脆弱性が報告されていますね。
報告されている内容としては、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文字以上でなければなりません。
こんにちは、富士榮です。
IIWや、その前日のOpenID Foundation Workshopでも取り上げられていたとおり、OpenID for Verifiable Presentationsの新たなImplementer's draftのPublic Review期間に入りました。
アナウンス
主な更新はこちら
こんにちは、富士榮です。
いよいよIIWも最終日です。
かなり疲れてきたので頭が回らず英語が聞き取れなくなってきました。（来週いっぱいまで英語生活なので週末はゆっくりしないと・・・）
ということで今日も楽しい話題がいっぱいでした。
以前も書いたStatusList周りを含むクレデンシャルの取り消しに関する話題です。
確かに色々な方法があるんですよねぇ。古き良きOCSPとか。。。
そもそもクレデンシャルの取り消しをしたくなるトリガーとしては、こんなことが挙げられます。
ドイツ政府はイタリアやフランスと協力してシナリオと方法論の比較検討を進めているみたいです。考えているシナリオはこんなところだそうです。
この辺りをスケーラビリティとプライバシー（Linkability）を考えつつ解くのは難しい問題ですよねぇ。。
こんなクライテリアで比較しているそうです。
しかし、こう言う比較検討の段階でIIWのようなプロフェッショナルが集う場所へ投げ込んでブラッシュアップするって方法、本当にいいと思うんですよね。プレゼンする方も「こう思うんだけどどう？」って投げかけてちゃんとその場で議論になる。これを政府や金融機関の中の人たちがちゃんとオープンな場でやっている、ってなかなか日本では考えられないことだと思います。日本政府もこう言う場に来ればいいのに（チラッ）
次はDigital Credentials APIの話です。
カスタムURLスキームでウォレットが起動されるのではなくFIDOと同じようにCredentials APIで起動できるようにしましょう、って話です。
そもそもカスタムURLスキームで何が問題だったか、というと
Issuance
この辺りでdemoが見れますよ。
https://digital-credentials.dev/
色々なシナリオを網羅的に考えていかないと社会基盤としては使えないということでかなり色々なユースケースを考えていますね。
https://bmi.usercontent.opencode.de/eudi-wallet/eidas-2.0-architekturkonzept/flows/Presentation-During-Issuance/
こちらにあるようなPresentationの結果を受けてIssuanceを行う、というシナリオもその一つです。
例として、学校でDegreeを発行してもらう際にmDLを提示して本人確認をする、みたいなシナリオが挙げられていました。
Presentationの結果を受けてPre-authorization用のコードを発行〜そのままOID4VCIを走らせるってことですね。
こちらが最後のセッションでしたが、またマニアックな話題でした。
前半パートはOliverがクレデンシャルにバージョンをつけるとするとどうなるのか？という話をしていました。（何をもってそのバージョンが最新であるか、を証明することも含め）
まぁ、バージョンと言っても色々な解釈があるのでその辺りの整理をして議論をするところまで、となりましたが。
投稿
すべてのコメント
