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

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

引き続き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に暗号化してリンクに使える署名の値を保存したりすると保存と閲覧の要件への対応ができなくなるのでうまくやらないとダメ、ってところですね。

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