CRYPTOGRAPHIC EVIDENCE CHAIN:
DELETE ONE ROW. BREAK THE CHAIN.
A database log is a claim someone can edit. NonaShield's evidence record is a hash-chained, dual-signed, write-once ledger — tampering with one entry is mathematically detectable.
What is cryptographic evidence for mobile fraud?
Cryptographic evidence is a record of a mobile event that can be proven unaltered. Each NonaShield record is hash-chained to the one before it, signed on the device with a hardware key and again by the server (ECDSA P-256), and stored write-once under S3 Object Lock with five-year retention.
Regulator-mapped compliance · Hardware-backed possession · The unified platform
// Hash-Chain Construction
Every evidence record's chain hash is SHA-256(previous record's hash + this event's hash), assigned a monotonic chain index under a row lock. Every tenant chain starts from a fixed genesis constant — deleting or reordering any record breaks every hash after it.
// Dual Signature
- Device signature — ECDSA P-256, signed on-device against the hardware key.
- Server signature — ECDSA P-256, signed against the tenant's KMS key.
- Non-repudiation from both the originating device and the server — not just one.
Not even the root
account can delete it.
Every signed evidence object is written under S3 Object Lock in COMPLIANCE mode — not the weaker "Governance" mode — with a default 5-year retention. If Object Lock can't be applied, the write fails closed rather than silently storing an unprotected copy.
ObjectLockManager: COMPLIANCE mode
Retain-until date cannot be shortened or deleted by any account, including the AWS root account.
// Regulator-Mapped Export
Every export bundles event ID, device identity, threat ID, rule metadata (version + hash), model metadata (name, version, hash, feature-schema version), and the hash-chain proof itself — then a signed, human-readable PDF report for RBI/NPCI SAR submission.
// On-Device Buffer
Before it ever reaches the backend, each threat event is stamped with a monotonic sequence number and signed on-device, buffered, and flushed both event-driven and on app-background — so evidence isn't lost even offline.
A log is only an audit trail if it is impossible to change.
Most systems keep history as editable rows. NonaShield replaces that with a non-repudiable, hardware-signed ledger.
Centralised logs
- Soft record entry. Transaction history is saved as simple rows in a SQL table. They are not cryptographically sealed.
- Admin vulnerability. Anyone with database access can modify or delete logs to hide unauthorised activity or system errors.
- Post-breach deletion. Attackers often wipe audit trails as their final step, leaving forensic teams with no visibility.
- Repudiation risk. Without hardware proof, a user can claim "I never did this" and the bank cannot prove otherwise.
NonaShield: mathematical custody
- Cryptographic sealing. Every action generates a hardware-signed proof that is time-stamped and sealed immediately.
- Chained integrity. Entries are linked by hashes. Deleting one row breaks the chain and the break is detected.
- Admin-proof logs. The chain of custody is independent of user permissions, so even a root admin cannot quietly alter the past.
- Non-repudiation. The proof is tied to a unique hardware key: evidence that a specific device authorised a specific action.
The evidence signing architecture is designed hybrid: a mandatory classical ECDSA P-256 signature today, with a defined extension point for a post-quantum signature layered alongside it. That post-quantum signer is a documented stub, not yet active — we say "hardware-rooted, dual-signed evidence" because that's what ships today, and we don't market "quantum-resistant" as a live capability until it is.
The Verdict.
"A log tells you what happened. A hash chain proves nobody changed the story afterward."