Direct Wallet Authentication

flowchart RL
    U("🔑 User")
    C("☁️ </br> Customer </br> Server")
    S("☁️ </br> Custody </br> Server")
    HSM("🔒 HSM </br> (Key Storage)")
    
    U -- e2e authenticate --> HSM
    U .- C
    C .- S
    S .- HSM

    A1(("😡 </br> Attack"))
    A1 -- 🚫 blocked --> C
    A2(("😡 </br> Attack"))
    A2 -- 🚫 blocked --> S

Direct wallet authentication binds every signing request to the user’s device rather than to any intermediary server. In this model, the user’s device (backed by a Secure Element and PassKey) produces a cryptographic authorization over the actual request that the HSM will execute. The HSM then independently verifies this user‑originated signature before it will even parse or queue the request. Because the check happens at the cryptographic boundary of the HSM, a compromised middle server (exchange backend or WaaS control plane) cannot fabricate or replay transactions on behalf of users: it lacks a valid user‑device signature over the request payload.

In the diagram, the user communicates Direct with the HSM for authentication, while customer and custody servers only relay messages. If either server is compromised, injected requests are blocked at the HSM because they are missing a valid user signature bound to the request’s contents, the target key, and a freshness nonce. This flips the trust model: servers no longer grant transaction authority; they merely transport requests that must already be authorized by the legitimate user device.

How it Works

User intent on device
The user approves a transaction on their device (e.g., via PassKey/biometric). The device’s Secure Element (or platform enclave) signs a canonical request envelope.
Relay through servers (untrusted transport)
The signed envelope is forwarded by the customer server and the custody server without modification. They can queue, rate‑limit, or log—but they cannot create a valid envelope.
HSM verification at the boundary
The HSM verifies: (a) the user’s public key (registered during enrollment), (b) the signature over the exact envelope, (c) freshness (nonce/expiry/anti‑replay), and (d) policy (quorum, limits, allowlists). Only if all checks pass does the HSM execute the signing operation.
Signature result and audit
The HSM produces a blockchain‑valid signature, attaches an audit record (including the verified user signature and envelope digest), and returns the result through the same relay path.

Why Server Compromise No Longer Grants Signing Power

In server‑centric designs, middle servers authenticate users and then ask the enclave to sign—making the enclave trust the server’s word. Here, the HSM does not trust the server for user intent. It trusts only a verifiable signature from the user’s Secure Element bound to the precise request. An attacker who owns a server can forward traffic but cannot forge user intent, cannot alter parameters without invalidating the signature, and cannot replay because freshness is enforced inside the HSM.

Security Properties

Authenticity and Intent Binding

Every signing request carries a user‑device signature over canonicalized fields. Any bit flipped by an attacker invalidates the request at the HSM.

Phishing and Origin Binding

Using PassKey/WebAuthn on the device ties user approval to the correct service origin and to the registered public key, resisting credential forwarding and fake prompts.

Replay Protection

Nonces are validated by the HSM; stale or duplicated envelopes are rejected even if a server is malicious.

Least Trust in Middleware

Customer and custody servers can throttle, shard, and observe traffic, but they cannot originate valid requests or escalate privileges.

Policy Co‑enforcement

User secure element signatures prove human intent; HSM policies (quorums, limits, allowlists, time windows) prove organizational intent. Both must pass.

Deployment Notes

During wallet setup, the user device first registers a PassKey and publishes its associated public key into the HSM’s policy domain, with the option to enroll multiple devices or define recovery procedures. To ensure consistency and prevent signature malleability, all requests are encoded into a strictly defined canonical envelope, where the field order, encoding rules, and domain separation tags are explicitly enforced. Each request also carries a unique nonce, which the HSM verifies and enforces per wallet, effectively preventing replay attacks across different servers or environments. In deployments that use Multi-Party Computing, the user-signed envelope is treated as a mandatory precondition for the MPC signing process; the HSM share, along with other participants, verifies the envelope before generating its partial signature. From a usability perspective, end users approve transactions with their biometric authentication or PassKey, avoiding the need for passwords or OTPs, while automated agents such as trading bots are provisioned with their own public keys so they too can produce authorized requests for the HSM.

Threats Mitigated

Threat	Mitigation
Compromised customer/WaaS server	Cannot fabricate valid envelopes; the HSM rejects unsigned, altered, or replayed requests.
Man-in-the-middle	Transport tampering invalidates the envelope signature; origin binding via PassKey prevents phishing.
Insider abuse on servers	Attackers lack the user’s private key and cannot bypass HSM boundary checks or enforced policies.
Replay attack	Nonce enforcement ensures old approved requests cannot be reused; the HSM rejects duplicates.

In summary, Direct wallet authentication relocates the decisive “yes/no” from fallible servers to cryptographic checks at the HSM boundary, using signatures produced by the user’s Secure Element. This eliminates the middle‑server as an authentication oracle and ensures that every signature reflects explicit, verified user intent—even in the face of server compromise.

The Secubit Whitepaper