続々々々々々）リンク可能性、リンク不可能性の話

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

引き続きWalletモデルを考える時のクレデンシャルのリンクの件についてみていきましょう。

元記事はSpruce IDのWayneのこの記事です。

https://blog.spruceid.com/provably-forgotten-signatures-adding-privacy-to-digital-identity/

前回はリンク可能性についてTEEを使うアプローチについてでしたが、その方式に関しても考慮点はあるようです。

However, as with all new approaches, there are some considerations when using this one as well. We will explore a few of them, but this is not an exhaustive list.

The first consideration is that TEEs have been compromised in the past, and so they are not foolproof. Therefore, this approach is best incorporated as part of a defense-in-depth strategy, where there are many layered safeguards against a system failure. Many of the critical TEE failures have resulted from multiple things that go wrong, such as giving untrusted hosts access to low-level system APIs in the case of blockchain networks, or allowing arbitrary code running on the same systems in the case of mobile devices.

しかし、新しいアプローチにはすべて言えることですが、このアプローチを使用する際にも考慮すべき点がいくつかあります。ここではそのいくつかを取り上げますが、これは網羅的なリストではありません。

まず、TEEsは過去に問題があったため、完璧なものではないという点が挙げられます。したがって、このアプローチは、システム障害に対する多くの層状の安全対策を講じる「多重防御戦略」の一部として組み込むのが最適です。TEEの重大な障害の多くは、複数の要因が重なって発生しており、例えばブロックチェーンネットワークの場合、信頼できないホストに低レベルのシステムAPIへのアクセスを許可したり、モバイルデバイスの場合、同じシステム上で任意のコードの実行を許可したりすることが挙げられます。

まぁ、そりゃそうですけど、TEEに頼りすぎるのもね、って話ですね。完璧なものはないですから。

One benefit of implementing this approach within credential issuer infrastructures is that the environment can be better controlled, and so more forms of isolation are possible to prevent these kinds of vulnerability chaining. Issuing authorities are not likely to allow untrusted hosts to federate into their networks, nor would they allow arbitrary software to be uploaded and executed on their machines. There are many more environmental controls possible, such as intrusion detection systems, regular patching firmware, software supply chain policies, and physical security perimeters.

We are solving the problem by shifting the trust model: the wallet trusts the hardware (TEE manufacturer) instead of the issuing authority.

このアプローチを認証発行者のインフラストラクチャに導入する利点のひとつは、環境をより適切に制御できるため、こうした脆弱性連鎖を防ぐための分離形態をより多く実現できることです。発行機関は、信頼できないホストがネットワークに統合することを許可しないでしょうし、任意のソフトウェアがアップロードされ、そのマシン上で実行されることも許可しないでしょう。侵入検知システム、定期的なファームウェアのパッチ適用、ソフトウェアのサプライチェーンポリシー、物理的なセキュリティ境界など、他にも多くの環境制御が可能です。

私たちは、信頼モデルを変更することで問題を解決しています。つまり、ウォレットは発行機関ではなく、ハードウェア（TEEメーカー）を信頼するのです。

それは解決になるのか？というか比較問題ってことですね。

この手の話をすると誰をどこまで信じるのか？ってところに帰結してしまうんですが、結局のところ、ソフトウェアを認定するのか、さらにハードウェアメーカやOSベンダを信じるのか、、ってところまで行きますね。

Another consideration is that certain implementation guidelines for digital credentials recommend retention periods for unique values for issuing authorities. For example, AAMVA’s implementation guidelines include the following recommendations for minimum retention periods: 

もう一つの考慮事項として、デジタル資格証明書の特定の実装ガイドラインでは、発行機関の固有の値の保存期間を推奨しているものもあります。例えば、AAMVAの実装ガイドラインには、最小保存期間に関する以下の推奨事項が含まれています。 

こういうガイドがあったんですね。

Validなものはできるだけ長く、Invalidになったものはなるべく早く消す、ログは長期に、という感じでデータを保持していくことが求められる感じでしょうか。

結構いいガイドっぽいので今度ちゃんと読んでみようと思います。

https://www.aamva.org/assets/best-practices,-guides,-standards,-manuals,-whitepapers/mobile-driver-s-license-implementation-guidelines-1-2

ちなみにURL上は1.2に見えますがダウンロードすると1.3です。

To navigate these requirements, it is possible to ensure that the retention periods are enforced within the TEE by allowing for deterministic regeneration of the materials only during a fixed window when requested by the right authority. The request itself can create an auditable trail to ensure legitimate usage. Alternatively, some implementers may choose to override (or update) the recommendations to prioritize creating unlinkability over auditability of certain values that may be of limited business use.

これらの要件に対応するため、権限のある当局から要求があった場合のみ、一定の期間に限定して資料の決定論的な再生成を許可することで、TEE内で保存期間が確実に守られるようにすることができます。この要求自体が監査証跡を作成し、正当な利用を確保することができます。あるいは、実装者によっては、限定的な業務利用にしかならない特定の値の監査可能性よりも、非関連付け可能性の作成を優先させるために、推奨事項を上書き（または更新）することを選択する場合もあります。

A third consideration is increased difficulty for the issuing authority to detect compromise of key material if they do not retain the signatures in plaintext. To mitigate this downside, it is possible to use data structures that are able to prove set membership status (e.g., was this digital signature issued by this system?) without linking to source data records or enumeration of signatures, such as Merkle trees and cryptographic accumulators. This allows for the detection of authorized signatures without creating linkability. It is also possible to encrypt the signatures so that only the duly authorized entities, potentially involving judicial processes, can unlock the contents.

3つ目の考慮事項は、署名を平文で保持しない場合、発行機関が鍵の侵害を検出するのがより困難になることです。この欠点を緩和するために、メルクレツリーや暗号集約器などの署名の列挙やソースデータレコードにリンクすることなく、セットのメンバーシップの状態（例えば、このデジタル署名は、このシステムによって発行されたか？）を証明できるデータ構造を使用することが可能です。これにより、リンク可能性を作成することなく、認証された署名を検出することができます。また、署名を暗号化して、正式に認証されたエンティティのみが、場合によっては司法手続きに関与しながら、その内容を解読できるようにすることも可能です。

結局のところ、TEEに暗号化してリンクに使える署名の値を保存したりすると保存と閲覧の要件への対応ができなくなるのでうまくやらないとダメ、ってところですね。

もろもろ考慮点があることも見えてきましたね。 

 

 

 

 

 

 

続々々々々）リンク可能性、リンク不可能性の話

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

引き続きWalletモデルを考える時のクレデンシャルのリンクの件についてみていきましょう。

元記事はSpruce IDのWayneのこの記事です。

https://blog.spruceid.com/provably-forgotten-signatures-adding-privacy-to-digital-identity/

前回はゼロ知識証明をうまく使ってリンク可能性への対応をして行こうとしている、という話でしたが、今回はより実用的な方式について書かれているところを紹介しましょう。

Given the challenges in deploying zero-knowledge proof systems in today’s production environments, we are proposing a simpler approach that, when combined with key and signature cycling, can provide protection from both verifier-verifier collusion and issuer-verifier collusion by using confidential computing environments: the issuer can forget the unique values that create the risk in the first place, and provide proof of this deletion to the user. This is implementable today, and would be supported by existing hardware security mechanisms that are suitable for high-assurance environments.

ゼロ知識証明システムを今日の運用環境に導入する上での課題を踏まえ、弊社では、秘密計算環境を使用することで、キー・サイクリングおよび署名・サイクリングと組み合わせることで、検証者同士の共謀および発行者と検証者との共謀の両方から保護できる、よりシンプルなアプローチを提案しています。発行者は、そもそもリスクを生み出す固有の値を忘れることができ、その削除の証拠をユーザーに提示することができます。これは現在でも実装可能であり、高信頼環境に適した既存のハードウェアセキュリティメカニズムによってサポートされるでしょう。

やはり鍵管理は鬼門ですね。今回のSpruce ID以外にもこの領域の課題に取り組んでいるベンダーは複数いますが、なかなか標準的な手法が生まれてこないので鍵管理の課題解決をする一方で相互運用性に課題が出てしまっています。この辺りが今後進むとさらに良いですね。

こんな感じで動くものらしいです。

1. During the final stages of digital credential issuance, all unique values, including digital signatures, are exclusively processed in plaintext within a Trusted Execution Environment (TEE) of confidential computing on the issuer’s server-side infrastructure.
2. Issuer-provided data required for credential issuance, such as fields and values from a driver’s license, undergoes secure transmission to the TEE.
3. Sensitive user inputs, such as unique device keys, are encrypted before being transmitted to the TEE. This encryption ensures that these inputs remain accessible only within the secure confines of the TEE.
4. Within the TEE, assembled values from both the issuer and user are used to perform digital signing operations. This process utilizes a dedicated security module accessible solely by the TEE, thereby generating a digital credential payload.
5. The resulting digital credential payload is encrypted using the user’s device key and securely stored within the device’s hardware. Upon completion, an attestation accompanies the credential, verifying that the entire process adhered to stringent security protocols.

 

1. デジタル・クレデンシャル発行の最終段階では、デジタル署名を含むすべての一意の値は、 発行者のサーバー側インフラストラクチャ上の機密コンピューティングの信頼された実行環境（TEE） 内で排他的に平文で処理される。
2. 運転免許証のフィールドや値など、クレデンシャル発行に必要な発行者が提供するデータは、 TEE への安全な伝送を受ける。
3. 一意のデバイス・キーなどの機密性の高いユーザ入力は、TEE に伝送される前に暗号化される。この暗号化により、これらの入力は、TEEの安全な範囲内での みアクセス可能であることが保証されます。
4. TEE 内では、発行者とユーザの両方からアセンブルされた値が、デジタル署名処理の実行に使用されます。このプロセスは、TEE によってのみアクセス可能な専用のセキュリティ・モジュールを利用し、デジタル・クレデンシャル・ペイロードを生成する。
5. 生成されたデジタル・クレデンシャル・ペイロードは、ユーザのデバイス鍵を使用して暗号化され、デバイスのハードウェア内に安全に格納される。完了すると、証明書がクレデンシャルに添付され、プロセス全体が厳格なセキュリ ティ・プロトコルに準拠していることが検証される。 

このアプローチの特徴も書かれています。

• Protection Against Collusion: By employing confidential computing and strict segregation of cryptographic operations within a TEE, the risk of verifier-verifier and issuer-verifier collusion is mitigated.
• Privacy and Security: User data remains safeguarded throughout the credential issuance process, with sensitive information encrypted and managed securely within trusted hardware environments.
• Compliance and Implementation: Leveraging existing hardware security mechanisms supports seamless integration into high-assurance environments, aligning with stringent regulatory and security requirements.
• 関連付けからの保護： TEE 内で機密コンピューティングと暗号操作の厳格な分離を採用することで、Verifier同士、IssuerとVerifierが結託するリスクを軽減する。
• プライバシーとセキュリティ： 機密情報は暗号化され、信頼できるハードウェア環境で安全に管理される。
• コンプライアンスと実装： 既存のハードウェア・セキュリティ・メカニズムを活用することで、高保証環境へのシームレスな統合をサポートし、厳しい規制要件やセキュリティ要件に対応します。

一位に識別できてしまう部分（署名とか）をTEEの中に閉じ込めちゃいましょう、ってアプローチですかね。

By prioritizing compatibility with current environments instead of wholesale replacement, we propose that existing digital credential implementations, including mobile driver’s licenses operational in 13 states and legislatively approved in an additional 18 states, could benefit significantly from upgrading to incorporate this technique. This upgrade promises enhanced privacy features for users without necessitating disruptive changes.

全面的な置き換えではなく現在の環境との互換性を優先することによって、13 の州で運用され、さらに 18 の州で立法的に承認されたモバイル運転免許証を含む既存のデジタル・クレデンシャル実装は、この技 術を組み込むためにアップグレードすることで大きな恩恵を受ける可能性があることを提案する。このアップグレードは、破壊的な変更を必要とすることなく、利用者のプライバシ ー機能の強化を約束する。 

環境面で条件はついてしまいそうなアプローチではありますが、うまく広げていけると良いですね。

今回はこんなところかと。

続々々々）リンク可能性、リンク不可能性の話

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

引き続きWalletモデルを考える時のクレデンシャルのリンクの件についてみていきましょう。

タイトルを連番にすれば良かったと若干後悔しています。

元記事はSpruce IDのWayneのこの記事です。

https://blog.spruceid.com/provably-forgotten-signatures-adding-privacy-to-digital-identity/

前回はVerifier-Verifierの結託の話だったので、今回はIssuer-Verifierの結託の話です。

A harder problem to solve is known as “issuer-verifier” collusion. In this scenario, the issuer of an ID–or, more likely, a rogue agent within the issuing organization–remembers a user’s unique values (such as keys or digital signatures) and, at a later time, combines them with data from places where those keys or signatures are used. This is possible even in architectures without “phone home” because issuing authorities (such as governments or large institutions) often have power over organizations doing the verifications, or have been known to purchase their logs from data brokers. Left unsolved, the usage of digital identity attributes could create surveillance potential, like leaving a trail of breadcrumbs that can be used to re-identify someone if recombined with other data the issuer retains.

より解決が困難な問題として、「発行者と検証者」の共謀が知られています。このシナリオでは、IDの発行者（あるいは、より可能性が高いのは、発行組織内の不正なエージェント）がユーザーの固有の値（キーやデジタル署名など）を記憶し、後日、それらのキーや署名が使用された場所からのデータと組み合わせます。これは、「電話による問い合わせ」機能のないアーキテクチャでも起こり得ます。なぜなら、発行当局（政府や大規模な機関など）は、検証を行う組織に対して権限を有していることが多く、また、データブローカーからログを購入していることが知られているからです。デジタルID属性の利用が放置されたままでは、発行者が保持する他のデータと組み合わせることで、誰かを再識別するために使用できるパンくずの跡を残すような、監視の可能性を生み出すことになります。

まぁ、これが行われるとどうしようもないって話ではありますが、Issuer-Verifierの間の結託は非常に難しい問題です。何しろアサーションを発行する側ですから全てを知っているわけです。

IIWなどでも話がありましたが、前回のVerifier同士の結託を含めゼロ知識証明をうまく使ってこれを解決できるようにならないか？という取り組みが注目されています。

Implementing advanced cryptography for achieving unlinkability, such as with Boneh–Boyen–Shacham (BBS) signatures in decentralized identity systems, has recently gained prominence in the digital identity community. These cryptographic techniques enable users to demonstrate possession of a signed credential without revealing any unique, correlatable values from the credentials.

分散型 ID システムにおけるBoneh-Boyen-Shacham（BBS ）署名など、リンク不能性を実現するための高度な 暗号の実装が、最近デジタル ID コミュニティで注目を集めている。これらの暗号化技術により、ユーザは、クレデンシャルから一意の相関可能な値を明かすことなく、 署名されたクレデンシャルを所有していることを示すことができる。

Previous methods like AnonCreds and U-Prove, which rely on RSA signatures, paved the way for these innovations. Looking forward, techniques such as zk-SNARKs, zk-STARKs, which when implemented with certain hashing algorithms or primitives such as lattices can support requirements for post-quantum cryptography, can offer potential advancements originating from the blockchain ecosystem.

RSA署名に依存するAnonCredsや U-Proveのような以前の手法は、これらの革新への道を開いた。zk-SNARKsやzk-STARKsのような技術は、特定のハッシュアルゴリズムや格子などのプリミティブと一緒に実装することで、ポスト量子暗号の要件をサポートすることができ、ブロックチェーンエコシステムに由来する潜在的な進歩を提供することができます。

However, integrating these cutting-edge cryptographic approaches into production systems that meet rigorous security standards poses challenges. Current standards like FIPS 140-2 and FIPS 140-3, which outline security requirements for cryptographic modules, present compliance hurdles for adopting newer cryptographic algorithms such as the BLS 12-381 Curve used in BBS and many zk-SNARK implementations. High assurance systems, like state digital identity platforms, often mandate cryptographic operations to occur within FIPS-validated Hardware Security Modules (HSMs). This requirement necessitates careful consideration, as implementing these technologies outside certified HSMs could fail to meet stringent security protocols.

しかし、このような最先端の暗号化アプローチを、厳格なセキュリティ標準に適合する本番システムに統合することは、困難を伴う。FIPS 140-2やFIPS 140-3 のような現行の標準は、暗号モジュールのセキュリティ要件を概説していますが、BBS や多くの zk-SNARK 実装で使用されている BLS 12-381 カーブのような新しい暗号アルゴリズムを採用するには、コンプライアンス上のハードルがあります。州のデジタル ID プラットフォームのような高保証システムは、多くの場合、FIPS ValidatedHardware Security Modules（HSM）内で暗号処理を行うことを義務付けている。認定された HSM 以外にこれらの技術を実装すると、厳格なセキュリティ・プロトコルを満たせなくなる可能性があるため、この要件には慎重な検討が必要である。

Moreover, there's a growing industry shift away from RSA signatures due to concerns over their long-term security and increasing emphasis on post-quantum cryptography, as indicated by recent developments such as Chrome's adoption of post-quantum ciphers.

さらに、Chromeがポスト量子暗号を採用するなどの最近の動きに見られるように、長期的な安全性に対する懸念やポスト量子暗号への重点の高まりから、業界ではRSA署名からの移行が進んでいる。

Balancing the need for innovation with compliance with established security standards remains a critical consideration in advancing digital identity and cryptographic technologies.

技術革新の必要性と確立されたセキュリティ基準への準拠とのバランスを取ることは、デジ タル ID および暗号化技術を進歩させる上で依然として重要な考慮事項である。

U-Prove懐かしいですね。

WIFのPreviewを触ってました（前も書いたかな？）。

より現代的なアルゴリズムに対応した手法へのシフトが進んできているということです。

次回はより実用的なアプローチについて見ていきます。 

 

 

 

 

 

 

 

 

 

そういえばNewsPicksにパスキーネタが載ってます

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

そういえば先日NewsPicksから取材受けていたなぁ、と思ったら記事になってました。

【真相】パスワード消滅｡｢ログイン｣はここまで便利になった

https://newspicks.com/news/10849029/body/

パスワードの使い回しの危険性から他要素認証、パスキーまでを網羅した良い記事になっていると思います。

有料記事なので登録しないと最後まで見れませんが。

よろしければどうぞ。

Taiwan Digital Wallet International Forum 2024に登壇します

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

来月12月11日（水）に台湾政府主催の「Taiwan Digital Wallet International Forum 2024」に登壇します。

私はキーノートとパネルディスカッションで既存システムとWalletエコシステムの相互運用の話などをさせていただく予定です。また後半にはMarkus Sabadelloも登壇するそうなのでとても楽しみです。

場所は台湾の「GIS MOTC Convention Center, International Conference Hall」です。もし台北にいらっしゃる場合はぜひお越しください。

こちらから申し込めます。

https://seminars.tca.org.tw/D10s00033.aspx

こちらがアジェンダです。

Time	Topic	Speakers
10:30-10:45	Opening Remarks	Yi-Jing Lin, Deputy Minister, Ministry of Digital Affairs
10:45-11:20	Keynote Speech 1: How to achieve interoperability with the current ecosystems	Naohiro Fujie, Chairman, OpenID Foundation Japan
11:20-12:00	Panel Discussion 1: Building a Cross-domain Ecosystem for Digital Wallets	Moderator:      Nicole T.I Chan, Chairperson, Digital Trust Association in Taiwan   Panelists:       Amber Zhong, Payment Partner Development Manager, SG & GRCN, Google       Jeng Linda Wen, Founder & CEO, Digital Self Labs LLC       Naohiro Fujie, Chairman, OpenID Foundation Japan
12:00-13:30	Lunch Networking
13:30-14:00	Keynote Speech 2: EU Digital Identity Wallet & The pursuit of Self-Sovereignty	Markus Sabadello, Founder, Danube Tech
14:00-14:30	Keynote Speech 3: Creating a citizen-first digital wallet blueprint	Moderator:          Yen-Lin Huang, Web3 Architect,  Ministry of Digital Affairs Speakers:       Denken,Tech Lead, NYCU Innovation Research Lab      Angela Sher, Director, DreamVok      Chang En Li, Section Chief, Enterprise Business Group Chunghwa Telecom Co., Ltd.
14:30-14:50	Tea Break
14:50-15:20	Fireside Chat: Digital Sovereignty and Physical Privacy— Digital Footprints, Anti-tracking, and Privacy Enhancement as a Vision	Alexis Hancock, Director, Engineering of Electronic Frontier Foundation       Singing Li, CEO, Open Culture Foundation
15:20-16:00	Panel Discussion 2: How to Build a Trusted Digital Economy Ecosystem	Moderator:      Wei-Chung Hwang, Director, Industrial Technology Research Institute (ITRI) Panelists:       Hung-Yi Tu, Chief Strategy Officer, TWCA       Jeff Kuo,Co-Founder & CEO, Gogolook       Karen Chang, Chair of FIDO Taiwan Engagement Forum

続々々）リンク可能性、リンク不可能性の話

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

引き続きWalletモデルを考える時のクレデンシャルのリンクの件についてみていきましょう。

元記事はSpruce IDのWayneのこの記事です。

https://blog.spruceid.com/provably-forgotten-signatures-adding-privacy-to-digital-identity/

なんだかんだで長くなってしまいましたが、ようやく中身の話です。

前回、RP同士の結託の話をしましたが、課題についてこのように続きます。

To maximize privacy, these pieces of data presented using a VDC should be “unlinkable.” For instance, if the same user who’d proven their age at a content website later went to a bank and proved their name, no one should be able to connect those two data points to the same ID holder, not even if the content website and the bank work together. We wouldn’t want the bank to make unfair financial credit decisions based on the perceived web browsing habits of the user.

プライバシーを最大化するために、VDCを使って提示されるこれらのデータは 「リンク不可能 」であるべきだ。例えば、コンテンツ・ウェブサイトで年齢を証明した同じユーザーが、その後銀行に行って名前を証明した場合、コンテンツ・ウェブサイトと銀行が連携していたとしても、この2つのデータを同じID保持者に結びつけることは誰にもできないはずだ。たとえコンテンツサイトと銀行が連携していたとしてもだ。私たちは、銀行がユーザーのウェブ閲覧の習慣に基づいて、不公正な金融上の信用判断を下すことを望まない。

However, VDCs are sometimes built on a single digital signature, a unique value that can be used to track or collate information about a user if shared repeatedly with one or more parties. If the content website in our example retains the single digital signature created by the issuing authority, and that same digital signature was also shared with the bank, then the content website and the bank could collude to discover more information about the user than what was intended.

しかし、VDCは、1つまたは複数の当事者と繰り返し共有された場合、ユーザーに関する情報を追跡または照合するために使用することができる一意の値である単一のデジタル署名に基づいて構築されることがあります。この例のコンテンツ・ウェブサイトが、発行機関によって作成された単一のデジタル署名を保持し、その同じデジタル署名が銀行とも共有された場合、コンテンツ・ウェブサイトと銀行が結託して、意図された以上のユーザーに関する情報を発見する可能性がある。

The case where two or more verifiers of information can collude to learn more about the user is known as verifier-verifier collusion and can violate user privacy. While a name-age combination may seem innocuous, a third-party data collector could, over time, assemble a variety of data about a user simply by tracking their usage of unique values across many different verifiers, whether online or in-person. At scale, these issues can compound into dystopian surveillance schemes by allowing every digital interaction to be tracked and made available to the highest bidders or an unchecked central authority.

2つ以上の情報検証者が結託してユーザーについてより多くのことを知ることができるケースは、検証者と検証者の結託として知られ、ユーザーのプライバシーを侵害する可能性がある。名前と年齢の組み合わせは無害に見えるかもしれないが、第三者のデータ収集者は、オンラインであれ対面であれ、多くの異なる検証者間でユニークな値の使用状況を追跡するだけで、時間の経過とともに、ユーザーに関するさまざまなデータを組み立てることができる。規模が大きくなれば、このような問題は、あらゆるデジタル交流が追跡され、最も高い入札者やチェックされていない中央当局が利用できるようになることで、ディストピア的な監視スキームへと複雑化する可能性がある。

書いてあることとしては、フェデレーションモデルでも課題となっていた一つまたは複数の事業者への複数回ID情報を同一の識別子で渡す場合に意図しない属性のLookupができてしまう可能性がある、ということです。Verifiable Credentials（最近のNISTの資料ではVerifiable Digital Credentials/VDCと記載されていることが多い）だとデジタル署名が共通であることで同じことが起きてしまう、ということについて問題視されています。

まさに上記の図に記載されていることですね。

で、どうするの？という話ですが、フェデレーションの時と同じようにPairwiseな値をVerifier単位で渡してあげるということです。

Fortunately, a simple solution exists to help prevent verifier-verifier collusion by cycling digital signatures so that each is used only once. When a new VDC is issued by a post office, DMV, or other issuer, it can be provisioned not with a single signature from the issuing authority that produces linkable usage, but with many different signatures from the issuing authority. If user device keys are necessary for using the VDC, as in the case of mobile driver’s licenses, several different keys can be used as well. A properly configured digital wallet would then use a fresh signature (and potentially a fresh key) every time an ID holder uses their VDC to attest to particular pieces of information, ideally preventing linkage to the user through the signatures.

幸いなことに、デジタル署名を循環させ、各署名が一度しか使用されないようにすることで、 検証者と検証者の癒着を防ぐシンプルなソリューションが存在する。新しいVDCが郵便局、陸運局、またはその他の発行者から発行される場合、リンク可能な使用法を生成する発行機関の単一の署名ではなく、発行機関の多くの異なる署名でプロビジョニングすることができる。モバイル運転免許証の場合のように、VDCを使用するためにユーザーデバイスキーが必要な場合、複数の異なるキーを使用することもできる。適切に構成されたデジタル・ウォレットは、ID保有者がVDCを使用して特定の情報を証明するたびに、新しい署名（および潜在的に新しい鍵）を使用し、理想的には署名を通じてユーザーへのリンクを防止する。

Using our earlier example of a user who goes to a content website and uses their VDC to prove they are over 18, the digital wallet presents a signature for this interaction, and doesn’t use that signature again. When the user then visits their bank and uses a VDC to prove their name for account verification purposes, the digital wallet uses a new signature for that interaction.

コンテンツ・ウェブサイトにアクセスし、18歳以上であることを証明するためにVDCを使用するユーザーを例にとると、デジタルウォレットはこのインタラクションのために署名を提示し、その署名を再度使用することはありません。その後、ユーザが銀行を訪れ、口座確認のために自分の名前を証明するためにVDCを使用すると、デジタルウォレットはそのインタラクションのために新しい署名を使用します。

Because the signatures are different across each presentation, the content website and the bank cannot collude to link these two interactions back to the same user without additional information. The user can even use different signatures every time they visit the same content website, so that the content website cannot even tell how often the user visits from repeated use of their digital ID.

署名は各プレゼンテーションで異なるため、コンテンツ・ウェブサイトと銀行は結託して、追加情報なしにこれら2つのインタラクションを同じユーザーに結びつけることはできない。ユーザーは、同じコンテンツ・ウェブサイトを訪問するたびに異なる署名を使用することもできるため、コンテンツ・ウェブサイトは、デジタルIDの繰り返し使用からユーザーの訪問頻度を知ることさえできない。 

要はキーローテーションで鍵が一度しか使われないようにすればいいじゃん、って話ですね。まぁ、Transientにするにはこの方法でも良さそうですが、結構実装コスト高そうです。過去の署名に使った公開鍵をひたすら公開し続ける（もしくはクレデンシャル自体に含める）ことになるような気もしますし、同一VerifierでPersistentにすることができません。もう少し工夫も必要になりそうな気がします。

次回はIssuer/Verifierの結託のケースをみていきましょう。

 

続々）リンク可能性、リンク不可能性の話

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

引き続きWalletモデルを考える時のクレデンシャルのリンクの件についてみていきましょう。

元記事はSpruce IDのWayneのこの記事です。

https://blog.spruceid.com/provably-forgotten-signatures-adding-privacy-to-digital-identity/

これはFederationモデルとも当然共通ですが、リンク可能性には大きく２つのパターンがあります。一つはRP（Verifier）同士が結託するパターン、もう一つはIdP（Issuer）とRP（Verifier）が結託するパターンです。

まずはRP（Verifier）同士が結託するパターンです。

One goal for a verifiable digital credential system is that a credential can be used to present only the necessary facts in a particular situation, and nothing more. For instance, a VDC could prove to an age-restricted content website that someone is over a certain age, without revealing their address, date of birth, or full name. This ability to limit disclosures allows the use of functional identity, and it’s one big privacy advantage of a VDC system over today’s identity systems that store a complete scan of a passport or driver’s license. However, even with selective disclosure of data fields, it is possible to unintentionally have those presentations linkable if the same unique values are used across verifiers.

検証可能なデジタル資格情報システムにおける目標のひとつは、特定の状況において、資格情報は必要な事実のみを提示し、それ以上の提示は行わないというものです。例えば、年齢制限のあるコンテンツウェブサイトに対して、VDCは、住所、生年月日、フルネームを明らかにすることなく、ある人が一定の年齢以上であることを証明することができます。この開示を制限する能力により、機能的なIDの利用が可能となり、パスポートや運転免許証の完全なスキャン情報を保存する現在のIDシステムに比べ、VDCシステムのプライバシー保護の面で大きな利点となります。しかし、データフィールドを選択的に開示する場合でも、検証者間で同じ固有の値が使用されていると、意図せずにそれらの提示がリンク可能となる可能性があります。

In our example, if a user proves their age to access an age-restricted content website (henceforth referred to simply as “content website”), and then later verifies their name at a bank, both interactions may run the risk of revealing more information than the user wanted if the content website and bank colluded by comparing common data elements they received. Although a check for “over 18 years old” and a name don’t have any apparent overlap, there are technical implementation details such as digital signatures and signing keys that, when reused across interactions, can create a smoking gun.

この例では、ユーザーが年齢制限のあるコンテンツ・ウェブサイト（以後、単に「コンテンツ・ウェブサイト」と呼ぶ）にアクセスするために年齢を証明し、その後、銀行で名前を確認した場合、コンテンツ・ウェブサイトと銀行が受け取った共通のデータ要素を比較することで結託すれば、両方のインタラクションで、ユーザーが望んだ以上の情報が明らかになる危険性がある。18歳以上」のチェックと名前には明らかな重複はないが、デジタル署名や署名キーのような技術的な実装の詳細があり、それが相互作用を超えて再利用されると、決定的な証拠を作り出す可能性がある。

Notably, the same digital signature is uniquely distinguishable, and also new signatures made from the same user key can be correlated. This can all work against the user to reveal more information than intended.

特筆すべきは、同じデジタル署名は一意に区別され、また同じユーザー・キーから作成された新しい署名は相関することができることである。これはすべてユーザーに不利に働き、意図した以上の情報を明らかにする可能性がある。

これまではPairwiseによる識別子の紐付けを中心に考えてきていたわけですが、デジタル署名による紐付けが問題になってきています。

こういうことですね。

数年前にIIWで初めてSD-JWTの話を聞いた時に、この質問をTorstenにしてみたんですが、まだその段階ではリンク可能性についてはそこまで大きなトピックスになっていませんでした。まずは選択的情報開示がちゃんとできるようにならないといけないよね、という。

ようやくここまで議論がすすんだなぁ、というところです。

次回もこの辺りを引き続き深掘りしていきます。