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

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

ようやく終われそうです。

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

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

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

前回は政策・ルールなども大事だよ、という話がありましたが、最後にこの先について書いています。

Digital identity systems are being rolled out in production today at a blazingly fast pace. While they utilize today’s security standards for cryptography, their current deployments do not incorporate important privacy features into the core system. We believe that ultimately we must upgrade digital credential systems to post-quantum cryptography that can support zero-knowledge proofs, such as ZK-STARKs, but the road ahead is a long one given the timelines it takes to validate new approaches for high assurance usage, especially in the public sector.

デジタル・アイデンティティ・システムは、今日猛烈な速さで実運用に展開されている。これらのシステムは、暗号化に関する今日のセキュリ ティ標準を利用しているが、現在の展開では重要なプライバシー機能がコア・システムに組み込まれて いない。私たちは、最終的にはデジタル・クレデンシャル・システムをZK-STARKのようなゼロ知識証明をサポートできるポスト量子暗号にアップグレードしなければならないと考えていますが、特に公共部門において、高保証の使用に対する新しいアプローチを検証するのにかかるスケジュールを考えると、前途は多難です。

Instead of scorching the earth and building anew, our proposed approach can upgrade existing systems with new privacy guarantees around unlinkability by changing out a few components, while keeping in line with current protocols, data formats, and requirements for cryptographic modules. With this approach, we can leave the door open for the industry to transition entirely to zero-knowledge-based systems. It can even pave the path for them by showing that it is possible to meet requirements for unlinkability, so that when policymakers review what is possible, there is a readily available example of a pragmatic implementation. 

大地を焦がし、新たに構築するのではなく、我々の提案するアプローチは、現在のプロトコル、データフォーマット、暗号モジュールの要件に沿いながら、いくつかのコンポーネントを変更することで、リンク不能性に関する新たなプライバシー保証で既存のシステムをアップグレードすることができる。このアプローチによって、私たちは業界がゼロ知識ベースのシステムに完全に移行するための扉を開くことができる。政策立案者が何が可能かを検討する際に、すぐに利用できる実用的な実装例があるように、リンク不能の要件を満たすことが可能であることを示すことで、その道を開くことさえできる。

なるほど。まずは誰かが先陣を切ってこの世界に足を踏み入れる必要がある、ということですね。まぁ、難しいのはどうしてもスタートアップがファーストペンギンになりがちなところかと思います。うまく政府や学術機関を巻き込んでいかないと単なる独りよがりなソリューションになってしまうところは難しいところです。

We hope to collaborate with the broader community of cryptographers, public sector technologists, and developers of secure systems to refine our approach toward production usage. Specifically, we wish to collaborate on:

私たちは、暗号技術者、公共部門の技術者、セキュアなシステムの開発者など、より広範なコミュニティと協力し、実運用に向けたアプローチを改良していきたいと考えています。具体的には、以下のようなコラボレーションを希望しています：

• Enumerated requirements for TEEs around scalability, costs, and complexity to implement this approach, so that commercial products such as Intel SGX, AMD TrustZone, AWS Nitro Enclaves, Azure Confidential Computing, IBM Secure Execution, or Google Cloud Confidential Computing can be considered against those requirements.
• A formal paper with rigorous evaluation of the security model using data flows, correctness proofs, protocol fuzzers, and formal analysis.
• Prototyping using real-world credential formats, such as ISO/IEC 18013-5/23220-* mdocs, W3C Verifiable Credentials, IMS OpenBadges, or SD-JWTs.
• Evaluation of how this approach meets requirements for post-quantum cryptography.
• Drafting concise policy language that can be incorporated into model legislation or agency rulemaking to create the requirement for unlinkability where deemed appropriate. 
• Intel SGX、AMD TrustZone、AWS Nitro Enclaves、Azure Confidential Computing、IBM Secure Execution、Google Cloud Confidential Computingなどの商用製品を、これらの要件に照らして検討できるように、このアプローチを実装するためのスケーラビリティ、コスト、複雑さに関するTEEの要件を列挙。
• データフロー、正しさの証明、プロトコルファザー、形式分析を使用した、セキュリティモデルの厳密な評価を含む正式な論文。
• ISO/IEC 18013-5/23220-* mdocs、W3C 検証可能クレデンシャル、IMS OpenBadges、SD-JWT などの実世界のクレデンシャル形式を使用したプロトタイピング。
• このアプローチがポスト量子暗号の要件をどのように満たすかの評価。
• 適切と判断される場合に、リンク不能の要件を作成するためのモデル法案または省庁の規則制定に組み込むことができる簡潔なポリシー文言を起草する。

さすがWayne、良いところをついていると思います。

先に私のコメントで書いた通り、うまく仲間を作りつつ、学術機関の評価をもらいながらポリシーに組み込んでいく、というあたりは重要ですね。

というところで長々と見てきましたがWayneのドキュメントはこれで終わりです。

この分野はかなり面白い分野で、IHV（Issuer-Holder-Verifier）モデルの普及のためのボトルネックになっているところでもあるので、ここ数年で技術革新と標準化が進むことを期待しています。

 

 

 

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

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

そろそろタイトルがおかしなことになってきました。

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

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

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

今回は、やはり最終的にはゼロ知識証明ってことで、そこへの道筋について見ていきましょう。

We believe that the future will be built on zero-knowledge proofs that support post-quantum cryptography. Every implementation should consider how it may eventually transition to these new proof systems, which are becoming faster and easier to use and can provide privacy features such as selective disclosure across a wide variety of use cases.

我々は、将来はポスト量子暗号をサポートするゼロ知識証明の上に構築されると信じている。すべての実装は、最終的にどのようにこれらの新しい証明システムに移行するかを検討すべきです。これらの証明システムは、より高速で使いやすくなっており、さまざまなユースケースにおいて選択的開示などのプライバシー機能を提供することができます。

Already, there is fast-moving research on using zero-knowledge proofs in wallets to demonstrate knowledge of unique signatures and possibly the presence of a related device key for payloads from existing standards such as ISO/IEC 18013-5 (mDL), biometric templates, or even live systems like Aadhar. In these models, it’s possible for the issuer to do nothing different, and the wallet software is able to use zero-knowledge cryptography with a supporting verifier to share attributes without attribution.

すでに、ISO/IEC 18013-5 (mDL)、バイオメトリック・テンプレート、あるいはAadharのようなライブ・システムのような既存の標準のペイロードに対して、一意の署名と場合によっては関連するデバイス・キーの存在を証明するために、ウォレットでゼロ知識証明を使用する研究が急速に進んでいる。このようなモデルでは、発行者は何も変わらず、ウォレットソフトウェアはゼロ知識暗号を使用し、サポートする検証機と属性を共有することができます。

These “zero-knowledge-in-the-wallet” approaches require both the wallet and the verifier to agree on implementing the technology, but not the issuer. The approach outlined in this work requires only the issuer to implement the technology. They are not mutually exclusive, and it is possible to have both approaches implemented in the same system. Combining them may be especially desirable when there are multiple wallets and/or verifiers, to ensure a high baseline level of privacy guarantee across a variety of implementations.

これらの 「ゼロ・ナレッジ・イン・ザ・ウォレット 」アプローチでは、ウォレットと検証者の双方が技術の実装に同意する必要があるが、発行者は同意しない。本研究で概説するアプローチでは、発行者のみが技術を実装する必要がある。両者は互いに排他的なものではなく、同じシステムに両方のアプローチを実装することも可能である。複数のウォレットやベリファイアが存在する場合、様々な実装にまたがって高いプライバシー保証のベースラインレベルを確保するために、両者を組み合わせることが特に望ましいかもしれない。

However, should the issuer, wallet, and verifier (and perhaps coordinating standards bodies such as the IETF, NIST, W3C, and ISO) all agree to support the zero-knowledge approach atop quantum-resistant rails, then it’s possible to move the whole industry forward while smoothing out the new privacy technology’s rough edges. This is the direction we should go towards as an industry.

しかし、発行者、ウォレット、検証者（そしておそらくIETF、NIST、W3C、ISOなどの調整標準化団体）のすべてが、量子抵抗性レールの上でゼロ知識アプローチをサポートすることに合意すれば、新しいプライバシー技術の荒削りな部分を滑らかにしながら、業界全体を前進させることができる。これが、私たちが業界として進むべき方向です。

そうなんですよね。色々な方法をみんな考えるはいいんだけど、ちゃんと実装者が安心して合意できるように標準化が進むのがまず第一歩ですね。

そのためにもしっかりと研究と実装が進むことが必要ですが、その前にベースとなるデータモデルの揉め事をなんとかしてよって、、、って感じですね・・・・。

この辺りはテクノロジのみでは解決しないと思います。

While these technical solutions can bring enormous benefits to baseline privacy and security, they must be combined with robust data protection policies to result in safe user-controlled systems. If personally identifiable information is transmitted as part of the user’s digital credential, then by definition they are correlatable and privacy cannot be addressed at the technical protocol level, and must be addressed by policy.

これらの技術的ソリューションは、基本的なプライバシーとセキュリティに多大な利点をもたらすが、安全なユーザ管理システムを実現するためには、強固なデータ保護ポリシーと組み合わせる必要がある。個人を特定できる情報がユーザーのデジタル・クレデンシャルの一部として伝送される場合、定義によれば、それらは相関可能であり、プライバシーは技術的プロトコル・レベルでは対処できず、ポリシーによって対処されなければならない。

For example, you can’t unshare your full name and date of birth. If your personally identifiable information was sent to an arbitrary computer system, then no algorithm on its own can protect you from the undercarriage of tracking and surveillance networks. This is only a brief sample of the kind of problem that only policy is positioned to solve effectively. Other concerns range from potentially decreased accessibility if paper solutions are no longer accepted, to normalizing the sharing of digital credentials towards a “checkpoint society.”

例えば、フルネームや生年月日を共有しないことはできない。個人を特定できる情報が任意のコンピューター・システムに送信された場合、どのようなアルゴリズムも、それだけでは追跡・監視ネットワークの足かせからあなたを守ることはできない。これは、政策のみが効果的に解決することができる種類の問題のほんの一例に過ぎない。その他の懸念は、紙のソリューションが受け入れられなくなった場合のアクセシビリティの低下の可能性から、「検問社会 」に向けたデジタル証明書の共有の常態化まで、多岐にわたる。

Though it is out of scope of this work, it is critical to recognize the important role of policy to work in conjunction with technology to enable a baseline of interoperability, privacy, and security.

この作業の範囲外ではあるが、相互運用性、プライバシー、セキュリティのベースラインを可能にするために、テクノロジーと連携する政策の重要な役割を認識することは極めて重要である。

Wayneも別の意味でも技術だけではダメだ、と書いていますね。要するに政策・ルールメイキングが重要だと。

この辺りは諸刃の剣になりかねませんが、まずは技術でどこまでいけるのかを真剣に考えた上で、最後は政策に任せるところを極小化して委ねていく、というアプローチが必要なんだと思います。

 

 

 

 

 

 

 

 

 

 

 

 

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

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

引き続き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を触ってました（前も書いたかな？）。

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

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