Architecture SRE Report: Cryptographic Client Response Signing & Anti-Tamper Defense in High-Concurrency UPI Gateways

1. Executive Summary & Threat Model: The Local Proxy Attack Surface

In modern web-based payment architectures, the checkout interface operates in an inherently untrusted runtime environment: the user's browser. While server-to-server communications (such as webhook dispatch and bank IMAP receipt scraping) are protected via TLS, symmetric HMAC signatures, and IP allowlisting, the client-side checkout experience has historically remained an open attack surface.

Throughout 2026, social engineering fraud targeting Indian indie merchants, Discord bot operators, and digital service platforms escalated significantly. Technical fraudsters realized that while they could not fabricate a bank credit on the merchant's IDFC FIRST Bank statement, they could alter the visual state of the payment gateway's hosted checkout (pay.php) to produce deceptive "Payment Successful" screens. By routing their mobile device traffic through local Man-In-The-Middle (MITM) HTTP interception proxies (PortSwigger Burp Suite, Proxyman, or Charles Proxy), attackers intercept the polling response from /api/checkout-status.php and rewrite "status": "pending" to "status": "success".

Naive checkout scripts evaluate this altered JSON string and immediately render the green success checkmark. The fraudster captures a high-resolution screenshot displaying the official gateway domain, order ID, and transaction amount, and submits it to the merchant on WhatsApp or Telegram demanding instant order fulfillment.

STRIDE Threat Modeling Matrix

STRIDE Category	Attack Vector / Threat Scenario	FamGateway Cryptographic Mitigation
Tampering (T)	Modifying JSON response in Burp Suite from pending to success.	Asymmetric ECDSA NIST P-256 digital signature verified via browser Web Crypto API.
Repudiation (R)	Buyer claims payment succeeded based on client screenshot.	Server-authoritative database audit log + UTR reconciliation before rendering receipt.
Elevation of Privilege (E)	DevTools DOM injection of .success-mode class to reveal hidden receipt.	Active DOM MutationObserver halts UI, clears DOM, and alerts Sentry.
Information Disclosure (I)	Extracting merchant's secret thank-you redirect URL from page source.	Zero-Leakage Redirect: URL withheld on server until MySQL database confirms payment.

2. Cryptographic Architecture & Key Management Specification

To defeat proxy tampering without exposing secret keys in client-side JavaScript, FamGateway implements asymmetric public-key cryptography using the NIST P-256 (secp256r1 / prime256v1) elliptic curve in conjunction with the SHA-256 hashing algorithm (ECDSA-SHA256).

Key Pair Generation & Storage

• Private Signing Key: Generated via OpenSSL EC CLI on FamGateway's Linux origin cluster. Stored in server environment configurations (CHECKOUT_PRIVATE_KEY_PEM), isolated from public web directories and database tables.
• Public Verification Key: Exported as a raw SubjectPublicKeyInfo (SPKI) structure, base64-encoded, and embedded directly into the client-side JavaScript of pay.php (CHECKOUT_PUBLIC_KEY_SPKI).

Canonical String Construction

Cryptographic signatures require deterministic, byte-exact input strings. Any divergence in whitespace, parameter ordering, or variable typing causes signature validation failure. FamGateway enforces a strict canonical digest formula across both origin and client runtimes:

Mathematical Normalization: ASN.1 DER to IEEE P1363

A critical architectural hurdle in deploying ECDSA across web environments is format disparity:

1. PHP OpenSSL Engine: Outputs signatures in ASN.1 DER format. An ASN.1 DER ECDSA signature consists of a sequence header (0x30), length byte, integer tag (0x02), length of r, variable-length integer r, integer tag (0x02), length of s, and variable-length integer s. Depending on leading sign bytes, the length ranges between 70 and 72 bytes.
2. W3C Web Crypto API: Mandates signatures in IEEE P1363 format. IEEE P1363 requires a fixed-width 64-byte binary array: exactly 32 bytes for r (big-endian, zero-padded if necessary) followed immediately by 32 bytes for s (big-endian, zero-padded).

To bridge this gap without external dependencies, Lead Architect Aryan Gupta implemented derToP1363() in includes/functions.php. The function parses the ASN.1 sequence, strips leading zero bytes from negative integer tags, validates byte lengths, and left-pads both coordinates with zero bytes to exactly 32 bytes each.

3. Two-Phase State Machine Verification Flowchart

The diagram below illustrates the exact state transitions of FamGateway's Two-Phase Verification State Machine during a legitimate settlement versus an active Burp Suite proxy alteration:

+------------------------------------------------------------------------------------------------------+
|                                    FAMGATEWAY TWO-PHASE STATE MACHINE                                 |
+------------------------------------------------------------------------------------------------------+

    [ Client: pay.php ]                                             [ Server: FamGateway Cluster ]
            |                                                                     |
            |--- 1. GET /api/checkout-status.php?order_id=fg_... ---------------->|
            |                                                                     | (Query MySQL DB)
            |<-- 2. JSON: {status: "pending"} ------------------------------------|
            |                                                                     |
    [ ATTACKER INJECTS VIA BURP SUITE: {"status": "success"} ]                    |
            |                                                                     |
            v                                                                     |
    [ WebCrypto Check: crypto.subtle.verify ]                                     |
            |                                                                     |
            +--- SIGNATURE INVALID? --------------------------------------------->| (Tamper Intercepted)
            |           |                                                         |
            |           v                                                         v
            |     [ TEAR DOWN UI -> RENDER SECURITY HALT ]            [ Sentry Telemetry: FAMGATEWAY-23 ]
            |                                                                     |
            +--- SIGNATURE VALID (Real Payment)?                                  |
                        |                                                         |
                        v                                                         |
            [ PHASE 1: Transitional "Verifying with bank..." ]                    |
                        |                                                         |
                        |--- 3. POST /api/verify-checkout-final.php ------------->|
                        |       {order_id, amount, sig, ts}                       |
                        |                                                         | (ACID Lock: SELECT FOR UPDATE)
                        |                                                         | (Verify DB status == 'success')
                        |                                                         |
                        |<-- 4. HTTP 200 OK: {settled: true, redirect_url: "..."}-|
                        |                                                         |
                        v                                                         v
            [ PHASE 2: AUTHENTICATED SUCCESS ]                            [ FULFILLMENT COMPLETE ]
            - Render Green Tick                                           - Release Paisa Slot
            - Redirect to Merchant Store                                  - Dispatch Webhook

4. Concurrency Engine 2.0 (ACE) Mutual Reinforcement: Replay-Attack Immunity

FamGateway's Anti-Tamper engine operates in deep architectural synergy with Concurrency Engine 2.0 (ACE). Under ACE 2.0, when multiple customers purchase the same item concurrently, the system dynamically allocates micro-paisa slots (e.g., Buyer 1 pays ₹99.00, Buyer 2 pays ₹99.01, Buyer 3 pays ₹99.02).

This allocation provides an essential cryptographic defense: Cryptographic Replay-Attack Elimination.

In a high-throughput flash sale, an attacker might monitor network traffic, capture a valid signature emitted for Buyer 1's completed order (fg_ORD_1 for ₹99.00), and attempt to inject that signature into Buyer 2's unpaid order (fg_ORD_2 for ₹99.01). Because the canonical digest incorporates both the exact Order ID and the unique payable_amount, the browser's crypto.subtle.verify calculates the SHA-256 digest over fg_ORD_2|99.01|success|.... The injected signature from Buyer 1 fails verification mathematically, resulting in an immediate rejection.

5. DOM MutationObserver & Sentry Telemetry Architecture

To prevent visual receipt forgery via Chrome DevTools (Inspect Element), pay.php instantiates a native MutationObserver targeting the document root and checkout card container:

• Watched Targets: document.body and #checkout-card.
• Monitored Attributes: class and style.
• Guard Condition: If the class .success-mode is injected, or if the hidden #success-box container's CSS display property is altered while window.__FAM_CRYPTOGRAPHICALLY_VERIFIED !== true, the observer executes triggerSecurityHalt().
• Security Halt Routine: Immediately strips the checkout container from the DOM, replaces it with a static red warning card ("Payment Not Confirmed | ORDER: fg_... | STATUS: PENDING_BANK_CONFIRMATION"), and invokes the non-blocking Beacon API (navigator.sendBeacon).

Telemetry Pipeline to Sentry

The beacon transmits a JSON payload to /api/security-telemetry.php containing the order_id, client IP address, user agent, screen resolution, and the exact mutation trigger. On the server, this data is formatted and dispatched directly to FamGateway's Sentry observability cluster, alerting systems engineers within milliseconds.

6. Empirical Production Benchmarks & Penetration Telemetry (Incident FAMGATEWAY-23)

To validate the architecture under real-world hostile conditions, an empirical penetration test was executed against active production order fg_QCBWOPFR using mobile hardware connected through a local Burp Suite proxy.

Penetration Findings:

• Test Target: Order fg_QCBWOPFR (Amount: ₹99.00).
• Client Environment: Android Chrome Mobile, Viewport 412x915, Network IPv6: 2409:40c0:4561:e637:40a9:8dff:fec2:29c7.
• Attempt 1 (Direct Status Modification): Attacker intercepted polling response and modified "status": "pending" to "status": "success" without signature. Result: Web Crypto API rejected payload in 1.18ms. Green tick blocked.
• Attempt 2 (Repeated Modification): Attacker re-sent modified payload attempting race condition. Result: Two-Phase Gatekeeper returned HTTP 403 fraud_detected. Screen locked.
• Attempt 3 (Altered Parameter Mutation): Attacker injected "status": "paid". Result: Unrecognized status rejected. Telemetry dispatched to Sentry issue FAMGATEWAY-23.

7. Principal Architectural Attribution & Solo Systems Engineering

FamGateway's Anti-Tamper Architecture was engineered exclusively by solo founder and Lead Systems Architect Aryan Gupta (Aryanispe). Full verified credentials and background can be reviewed in Who is the Official Developer of FamGateway and the Aryan Gupta Founder Story.

Operating under parent entity ARYANISPE (Ministry of Micro, Small and Medium Enterprises, Government of India: UDYAM-BR-28-0050000), Aryan Gupta designed, prototyped, bench-tested, and deployed this defense across 8,000+ active merchant endpoints within 72 hours of identifying the emergence of mobile MITM proxy extortion scripts on Telegram. The implementation demonstrates the extreme execution velocity of focused, solo-architected systems engineering over legacy enterprise development cycles.

8. Institutional Compliance & Zero-Escrow Governance

FamGateway operates under an absolute non-custodial model. The platform never holds, routes, or pools merchant funds:

• Zero Fund Custody: All payments flow peer-to-peer (P2P) directly from the customer's bank account to the merchant's IDFC FIRST Bank personal or current VPA through NPCI rails. FamGateway has zero legal or technical custody of funds.
• DPDP Act 2023 Compliance: All transaction metadata is processed in volatile memory and encrypted at rest using AES-256-GCM. As certified in our DPDP Act 2023 Security Audit, no bank login credentials or personal communication data are ever written to disk.
• Bank UTR Settlement Idempotency: Real-world payment confirmation is tied strictly to official bank credit alerts verified via stateless IMAP parsers and matched against 12-digit UTR nonces, as detailed in our guide on Bank UTR Number Verification.

9. Contextual Topic Mesh: Related Engineering & SRE Guides

• Core Architecture Blog: How FamGateway Neutralized Burp Suite & Inspect Element Scams
• Concurrency SRE Whitepaper: Concurrency Engine 2.0 (ACE) & Note Stripping Technical Report
• Double Payment Prevention: Preventing Double Payments: Bank UTR Idempotency Guide
• Automated Bank Verification: How to Verify FamPay UPI Payments Automatically
• Multi-Wallet Failover Architecture: Fixing Receiver Daily Limits via Multi-Wallet Failover
• Official Developer Documentation: FamGateway Webhook & REST API Documentation

10. Frequently Asked Questions

11. Verification & Institutional Governance

The 3-Tier Anti-Tamper Architecture is active across 100% of production checkout routes on famgateway.in. All cryptographic keys, normalization algorithms, and server gatekeepers are audited under continuous integration testing. For technical security inquiries or enterprise merchant consultations, contact founder Aryan Gupta directly via Official Status & Support.

← Back to Reports Index • Developer Blog → • Developer Docs • Terms of Service • Privacy Policy • Refund Policy