Security hardening: certification binding, predicate canonicalization, split-proof dedup, CBOR strictness

[martti007]

[b3y0urs3lf]

Tested on top of: issue-52 merge commit (4b1fc0a). Branch bdd-phase-0 of state-transition-sdk-java runs the BDD suite against this baseline.

Test environments verified:

• Hermetic (StrictTestAggregatorClient) — default, ~7s
• Real bft-shard 16-shard topology via subscription proxy (AGGREGATOR_URL=…:8080, AGGREGATOR_API_KEY=sk_…, 16 aggregator-go containers behind the proxy)

Result: 351 scenarios, 0 unexpected failures. 18 environment-gated skips (@stateful, @fresh-aggregator, @bft-shard-only, @multi-shard-only, @pending-src-cleanup, @slow,
@hermetic-only).

BDD coverage by hardening dimension

1. Certification binding (CertificationData ↔ Transaction)

• inclusion-proof-statuses.feature — TRANSACTION_HASH_MISMATCH scenario verifies that mutating the certified transaction hash breaks the proof chain
• inclusion-proof-statuses.feature — Status precedence — txhash failure dominates path-invalid failure confirms the binding-failure check fires before lower-level checks
• token-certification-status.feature — Transfer signed with wrong key is rejected by aggregator (SIGNATURE_VERIFICATION_FAILED)

2. Predicate canonicalization (EncodedPredicate / lockScript stability)

• cbor-envelope-tags.feature — CertificationData lockScript is canonicalized and round-trips stably (encode → decode → re-encode produces byte-identical CBOR)
• cbor-envelope-tags.feature — EncodedPredicate decoded with the wrong CBOR tag throws CborError
• cbor-envelope-tags.feature — EncodedPredicate's correct-shape payload decodes (3-element, no version slot) — predicate envelopes have no version slot, asserts the parser respects
  this
• All ~120 mint/transfer scenarios round-trip predicates through EncodedPredicate as recipient (post-PR #60 Use predicates instead of address, move mint justification to mint root #61 — implicitly exercises canonicalization)

3. Split-proof dedup (5 of 12 FAIL branches reachable from BDD)

• split-mint-justification-verifier.feature outline (5 mutations):
  • stripping the justification field → Transaction has no justification
  • stripping the data field → Assets data is missing
  • adding an extra asset to data not present in proofs → Total amount of assets differ in token and proofs
  • renaming one proof's assetId to one not in data → not found in asset data
  • mismatching one asset's value between data and tree → does not match asset tree leaf
• split-mint-justification-envelope.feature — SplitMintJustification.create rejects empty proof list
• Note: the remaining 7 FAIL branches (including duplicate asset id, duplicate proof per asset, asset tree path verification, aggregation path root mismatch) are covered by the SDK
  author's unit test src/test/java/org/unicitylabs/sdk/functional/payment/SplitMintJustificationVerifierTest.java because they require surgical CBOR/MerkleTreePath manipulation that
  BDD's mutation harness can't cleanly produce. TS BDD makes the same trade-off explicitly.

4. CBOR strictness (tag, version, arity, length enforcement)

• cbor-envelope-tags.feature — wrong-tag rejection across 8 envelope types: CertificationData (39031), InclusionProof (39033), InputRecord (39002), ShardTreeCertificate,
  MintTransaction (39041), SplitMintJustification (39044), UnicityCertificate (39001), UnicityIdMintTransaction
• cbor-envelope-tags.feature — wrong-version rejection (versions 0 and 2) across 7 versioned envelope types
• cbor-envelope-tags.feature — SplitMintJustification arity gate fires before any version concern (arity 1 and arity 3 both rejected before version is even checked)
• state-id-encoding.feature — 32-byte length enforcement on StateId.fromCbor (rejects 0/31/33/34-byte payloads; explicitly rejects the legacy 34-byte algorithm-prefixed form)
• inclusion-certificate-binary.feature — InclusionCertificate.decode rejects when popcount(bitmap) != siblings count (binary wire-format strictness)
• inclusion-certificate-binary.feature — InclusionCertificate.decode rejects malformed binary of length <0/31/33/63/65> (5 outline rows)

What's NOT in BDD (and why that's correct)

• Null checks for token creation (Objects.requireNonNull guards in Token.mint/transfer, SplitMintJustificationVerifier ctor) — defensive code against illegal API use; covered by
  SDK unit tests, not user-observable behavior.
• Split-proof dedup branches beyond the 5 mutation matrix — require private-field manipulation; covered by SplitMintJustificationVerifierTest.
• UnicityId issuer-check hardening contracts (5 @pending-src-cleanup scenarios in token-nametag-negative.feature) — forward contracts for option-2 source removal; mirror TS
  exactly, will turn green when SDK author deletes legacy UnicityIdPredicate files.

Moving task to done.