Validate and Verify Audit Information Before Registration [HIGH]

[HayimShaul]

Description
Implement comprehensive validation of all audit information and recipient data before allowing registration or updates in the wallet. This includes verifying the cryptographic consistency of identity credentials, checking that enrollment IDs and revocation handles conform to expected formats and are properly bound to the identity being registered, and validating that audit metadata is well-formed and contains all required fields. For recipient registration operations, verify that the provided RecipientData includes valid cryptographic proofs (such as signatures or zero-knowledge proofs) that demonstrate the caller legitimately controls the identity being registered. Reject any registration attempts with malformed, incomplete, or unverifiable audit information to prevent injection of forged data into the audit trail.

[SurbhiAgarwal1]

Hi @HayimShaul, I would like to work on this issue if it is available to assign.

I spent some time going through the requirements and I think this is an important security-hardening task since this flow sits directly on the trust boundary of wallet registration and audit persistence.

My approach would be to introduce a dedicated validation and verification layer before any audit or recipient registration information is accepted into wallet state. The implementation would mainly focus on:

• validating the structure and integrity of audit metadata and RecipientData
• verifying cryptographic consistency between credentials, enrollment IDs, revocation handles, and identity material
• adding proof-of-possession verification for recipient registration flows
• validating revocation and expiration state before registration succeeds
• enforcing fail-closed behavior for malformed, incomplete, or unverifiable data
• strengthening negative/security-focused test coverage for forged or tampered inputs

I also think it would be useful to centralize these checks into a reusable validator/verifier flow so the validation logic remains consistent across registration and update operations.

Before implementation, I can first prepare a small technical breakdown covering:

• validation flow design
• proof verification approach
• integration points in the registration pipeline
• testing strategy for malformed and adversarial cases

I would be happy to work on this if you think the approach aligns well with the direction of the project.

[AkramBitar]

Executive Summary: Wallet Registration Validation Issue

The Issue

Locations:

1. platform/view/services/sig/service.go:153 - Audit info registration
2. platform/fabric/services/state/recipients.go - Recipient identity exchange

Wallet registration and recipient identity exchange accept data without validating format, cryptographic binding, or proof of ownership.

What data is involved?

• Enrollment IDs that identify token owners
• Revocation handles for privacy-preserving audits
• Identity metadata binding cryptographic credentials
• Recipient identities for token transfers

How It Works Today

Audit Info Registration:

Token Wallet or Driver Component
    |
    | Generates: enrollment ID, revocation handle, metadata
    |
    v
RegisterAuditInfo(identity, auditInfoBytes)
    |
    | No validation of format or binding
    |
    v
Data stored directly in database

Recipient Identity Exchange:

Party A                          Party B
    |                                |
    | Send RecipientData             |
    | {Identity: A's identity}       |
    | ─────────────────────────────> |
    |                                |
    |                                | No proof A owns identity
    |                                | No cryptographic challenge
    |                                | Store and use identity

What Components Are Involved?

Token Wallet Component:

• Manages user identities and credentials
• Generates enrollment IDs during registration
• Examples: Idemix wallet, X.509 wallet, Fabric CA wallet

Token Driver Component:

• Cryptographic engine implementing token protocols
• Generates privacy-preserving credentials
• Examples: Zkat driver, Dlog driver, Fabtoken driver

Key point: These are core system components we deploy and control, not third-party code.

What Validation Is Missing?

For Audit Info:

• Enrollment ID format checking
• Revocation handle binding verification
• Metadata structure validation
• Cryptographic consistency checks

For Recipient Data:

• Proof of identity ownership (signature or ZK proof)
• Challenge-response to verify control
• Credential binding verification

Is This a Real Security Issue?

Short answer: Only if an internal component is compromised.

Threat: Compromised wallet/driver injects fake audit data or claims false identity through supply chain attack or malicious dependency.

NOT a threat from: External attackers, network attacks, or man-in-the-middle.

Risk level: Low in trusted, permissioned environment.

Performance Impact

Adding validation: +1-5ms per registration (negligible for infrequent setup operations).

Recommendation: Do Not Implement

Why:

• Trusted, permissioned network with known participants
• All code reviewed before deployment
• Components are trusted to generate valid data
• Existing security (TLS, auth, code review) sufficient

Summary

Unnecessary in trusted environment where all components are verified and controlled. The issue requests defense-in-depth validation that assumes components might be malicious, which contradicts the trusted environment model.