Selective Cryptographic Integrity Verification of High-Value Payloads [LOW]

[HayimShaul]

Description
The store services currently make no integrity guarantees: they store what they receive. Architects should explicitly decide, for each asset class, whether to verify cryptographic integrity before persistence, on retrieval, or not at all -- and document that decision as a security posture choice. At minimum, the highest-value assets warrant verification: endorsement ack signatures (TransactionEndorseAck.sigma) should be verified against the endorser's public key before insertion; serialized token request bytes should be checked for valid deserialization and a matching pp_hash before storage; identity bytes should be verified against a known public key before being written to IdentityInfo or Signers. For lower-value or high-volume assets (movements, locks, metadata), the cost-benefit trade-off may favour deferred or sampled verification. The key architectural requirement is that the API surface makes its verification guarantees explicit -- "we store what you give us, unverified" is an acceptable posture only if callers are required to perform verification themselves before calling.

Summary
Need to add the defense-in-depth checks in the table below.

Check	Operation	Cost
1. Endorsement Signature Verification	Verify signature is valid for claimed endorser	Medium (1 DB read + crypto verify ~1-5ms)
2. Token Request Integrity	Verify data deserializes and hash matches	Low (deserialize + hash ~0.1-1ms)
3. Identity Validation	Verify identity contains valid public key	Low (key format check ~0.1ms)
4. Signer Registration Validation	Verify signer's public key matches identity	Low (key comparison ~0.1ms)

Also,
5. Remove NoOp Bypass: Eliminate option to skip verification

Crypto related data should be checked when inserted to the database and when retrieved. This can be time consuming. We need to find the checks that protect against systemic failures and check only those.

[SurbhiAgarwal1]

Hi @HayimShaul, I’d like to take this on.

From what I understand, the main gap is that the store layer currently persists data without making any explicit integrity guarantees, which leaves room for inconsistent or malicious data being stored unless callers verify everything themselves.

My plan is to start with the high-value assets and add verification at insertion time:

• Endorsement signatures: verify TransactionEndorseAck.sigma against the claimed endorser’s public key before persisting
• Token request integrity: ensure the payload deserializes correctly and that the computed hash matches pp_hash
• Identity validation: check that identity bytes correspond to a valid public key format
• Signer registration: verify that the signer’s public key matches the associated identity

I’ll keep the implementation focused and avoid introducing unnecessary overhead for high-volume/low-value data (like movements or metadata), aligning with the selective verification approach mentioned.

In addition:

• remove any NoOp/bypass paths that allow skipping verification
• make verification guarantees explicit in the store layer (so it’s clear what is validated vs what is caller responsibility)
• structure the checks so they can be extended later (e.g., retrieval-time verification or sampling if needed)

I’ll start with minimal, well-scoped changes around insert-time validation and ensure existing flows are not impacted.

Let me know if this approach aligns, and I can begin with a PR.

[SurbhiAgarwal1]

Hi @adecaro , Can you assign me this issue ?

[adecaro]

Hi @SurbhiAgarwal1 , let me review your analysis and then I'll assign to you. We need to be careful here. Thanks much for your patience 🙏

[SurbhiAgarwal1]

Thanks @adecaro — makes sense, this definitely needs careful handling.

I took another pass focusing specifically on risk boundaries and avoiding unintended overhead or behavioral changes.

My updated approach would be:

• Limit strict verification to insertion-time for high-value assets only, avoiding any implicit changes to existing read paths
• Ensure all checks are fail-fast and explicit, so invalid data never reaches persistence
• Avoid adding hidden latency by:
– keeping verification local (no extra network calls)
– reusing already available identity/public key material where possible
• Make verification opt-in at the API boundary (explicit contract) rather than silently enforcing it everywhere, so we don’t break existing flows unexpectedly

For the actual checks:
– Signature verification only where the endorser identity is already resolved
– Token request validation strictly scoped to deserialization + hash match (no extra semantic validation)
– Identity/signer checks limited to structural + key consistency (no trust chain expansion)

I’ll also make sure:
• no NoOp/bypass paths remain
• behavior is clearly documented as part of the store contract (what is verified vs assumed)

Before I start implementation, I want to confirm one thing to avoid misalignment:

👉 Should the store layer enforce verification by default for these high-value assets, or should it expose verification as an explicit mode/contract that callers opt into?

That decision seems important for backward compatibility and API expectations.

Happy to proceed once this is clarified.