Data Tampering Detection

Fystack hardens its operational databases with a parallel integrity layer that cryptographically signs sensitive rows. Each protected record produces a SHA-256 hash that is signed with an Ed25519 key stored in a dedicated SecretStore. Signatures live in their own integrity table, so even if an attacker alters operational data, the tampering is immediately detectable.

This change helps prevent insider attacks from gaining access to the database and modifying records in stealth, ensuring any unauthorized change is instantly detected and provably tamper-evident.

image-2025-11-09T07-02-02-296Z Withdrawal blocked due to tampered wallet data

Withdrawal is blocked due to tampered wallet data

1. Integrity Workflow

How the integrity layer works?

image-2025-11-09T08-04-22-396Z
  • Deterministic serialization: Protected fields are sorted and normalized before hashing, guaranteeing the same byte stream for the same logical data.

What gets protected

  • Wallet metadata: Wallet ID, workspace ownership, user ownership, threshold settings.
  • Wallet public keys: Public key contents, algorithm family (ECDSA/EdDSA), wallet association.
  • Wallet settings: Auto-approval limits, spending policies, risk controls.
  • Wallet addresses: On-chain address, address type, network standards.
  • HD key metadata: Derivation indices, encryption versions, blockchain flavor.
  • MPC wallet configuration: Signature thresholds (2-of-3, etc.), MPC library versions, TSS protocol revisions.

Signing & verification lifecycle

  1. Extract the fields marked for integrity coverage.
  2. Serialize deterministically so field order and formatting never drift.
  3. Hash with SHA-256 to produce a compact fingerprint.
  4. Sign the hash with an Ed25519 private key held in SecretStore or KMS.
  5. Store the signature, hash, version, and metadata in the integrity records table.

Verification

  1. Fetch the current operational record when it is read or audited.
  2. Recompute the SHA-256 hash from the current field values.
  3. Compare the recomputed hash to the stored hash; any mismatch flags tampering.
  4. Verify the Ed25519 signature using the current public key version from configuration (not the database).
  5. Block the operation, alert security, and log the attempt if either step fails.

2. Detection & Monitoring

Modified wallet threshold

  • Attack: DBA attempts to change a wallet from 2-of-3 to 1-of-3.
  • Result: Hash mismatch → signature verification fails → wallet operations blocked → alert fired.

Inflated auto-approval limit

  • Attack: Insider raises the auto-approval limit from $1,000 to $1,000,000.
  • Result: Signed limit field changes → system refuses to honor tampered value and logs incident.

Substituted deposit address

  • Attack: Attacker swaps a deposit address for their own.
  • Result: Address hash differs → signature mismatch → payout halted → security notified.

Threat protection matrix

Scenario

Protection

Compromised DB credentials

Tampered rows produce new hashes, so signatures fail verification immediately.

Backup restoration with edited data

Restored records no longer match persisted signatures, triggering incident response.

Malicious DBA changes policies

Auto-approval and policy fields are signed; operations block until security review.

Compromised admin account edits wallet configs

Verification uses out-of-band public keys, so forged signatures are impossible.