Cryptographic Security

Cryptographic Security (ZKP)

The Cryptographic Security layer mitigates credential theft by implementing a mechanism functionally identical to a Zero-Knowledge Proof (ZKP). Specifically, it proves possession of authorization without transmitting the authorization secret across the network.

Protocol Implementation: ECDSA over SECP256R1

The implementation relies on the Elliptic Curve Digital Signature Algorithm (ECDSA) utilizing the NIST P-256 (SECP256R1) curve. This standard provides a high level of security (128-bit symmetric equivalent) with minimal computational overhead, ensuring rapid authentication suitable for high-frequency API gateways.

Key Management

The system necessitates asymmetric cryptography:

• Private Key ($d$): Generated entirely on the client-side using the window.crypto.subtle API. It resides exclusively locally (e.g., localStorage or ideally a Secure Enclave/TPM). It is never transmitted.
• Public Key ($Q = dG$): Exported in X.509 SubjectPublicKeyInfo (SPKI) PEM format and registered with the server.

The Challenge-Response Handshake

To prevent interception and reuse of legitimate signatures, the system enforces a strict Challenge-Response protocol:

1. Nonce Generation: The server (crypto_utils.py) utilizes secrets.token_bytes(32) to generate a cryptographically secure 32-byte pseudo-random challenge nonce.
2. Commitment Binding: The server stores this nonce in a thread-safe ChallengeStore mapped to the user_id, alongside a rigid 60-second expiration timestamp.
3. Proof Generation: The client retrieves the nonce and signs it using the private key and a SHA-256 hash function: $Sign(PrivateKey, SHA256(Challenge))$.
4. Verification: The client submits the resulting signature. The server verifies the signature against the registered Public Key using the exact same nonce parameters.

Defense Mechanisms

1. Credential Stuffing & Phishing Immunity: Standard attacks rely on capturing a static password or OTP. Even if an attacker captures the traffic from a legitimate session, they only acquire the public signature and the specific nonce for that session. Because they do not possess the Private Key mathmatically required to sign a new nonce, subsequent login attempts are impossible.

2. Replay Attack Prevention: The ChallengeStore utilizes a strict single-use policy. Upon a successful verification, the state of the challenge is immediately inverted to used=True. If an attacker intercepts a valid signature and attempts to resubmit the exact same payload a millisecond later, the server identifies the nonce as consumed and terminates the connection (HTTP 403).

3. Format Interoperability Pipeline: Standard WebCrypto operations in JavaScript browsers natively generate IEEE P1363 raw signatures (a concatenated 64-byte array containing the $r$ and $s$ components). Conversely, standard Python cryptography verification methods anticipate ASN.1 DER-encoded signatures. The backend elegantly resolves this by implementing dual-verification logic: it initially attempts DER validation, and upon failure, dynamically invokes internal utility functions to structurally encode the raw 64-byte array into valid DER format before finalizing verification.