Skip to Content
OverviewArchitecture & Security ModelMalware Resistance

Malware Resistance

WaaP assumes the dapp, the browser, and the user’s whole device may be compromised. A compromised component can at most request a transaction. It cannot approve one outside the account’s policy, and it cannot alter a transaction after the user has reviewed it.

Compromised User Device

The user’s device holds no signing key. Standard-mode keys are generated and held inside the enclave, so there is nothing on the device for malware to steal, and no local ceremony it can hijack.

What malware on the device can do is issue requests as the user. That is what the authorization gate exists to contain:

  • Every request is decided by the Policy Engine, not by the client. Spend limits, risk thresholds, and multifactor requirements apply regardless of what the compromised client asks for.
  • High-risk or high-value transactions can require confirmation on a separate device. A phone or hardware wallet. Which malware on the compromised machine does not control.
  • The session credential is bound to a non-extractable key via DPoP. Copying the session token to another machine does not carry the session with it.

Compromised WaaP Server

No single service can produce a signature. The Policy Engine makes the authorization decision and issues a narrow approval; the key manager independently re-verifies the user, digest, wallet, key, and operation before signing. Compromising one of them is not sufficient.

The approval itself is deliberately hard to reuse. It is bound to a specific user, transaction digest, wallet and key, operation and revision, purpose, and expiry, and it is redeemed exactly once. Burned before the signature is produced. A captured approval cannot be replayed, and cannot be pointed at a different transaction.

Compromised Network

An attacker on the network sees encrypted traffic and cannot read or modify it. Replay is separately blocked: each request carries a fresh DPoP proof covering its method and URL, and each approval is bound to one transaction digest and burned on use.

Defense in Depth

WaaP layers independent defenses so that one breached component does not lead to loss of funds:

  1. Keys off the device. Standard-mode keys never leave the enclave. Squid mode goes further and distributes key material across the Ika validator set, so no single operator holds it either.
  2. Byte verification before policy. The canonical chain bytes are decoded and checked before any authorization decision, so the transaction that is reviewed is the transaction that gets signed.
  3. Independent decision and verification. The Policy Engine decides; the key manager verifies again before signing.
  4. Single-use, fully bound approvals. An approval names its user, digest, wallet, key, operation, and expiry, and is burned before signing.
  5. Transaction simulation. Simulations are run and presented in human-readable form on a secure device, preventing blind signing.
  6. Policy engine controls. Configurable spend limits, per-transaction authorization, and risk-threshold blocking.
  7. Multifactor authorization. High-value or high-risk transactions can require confirmation on a separate secure device.

Moving funds against the user’s policy requires defeating the Policy Engine and the key manager independently, and doing so within the lifetime of a single approval that names one exact transaction. Compromising the user’s device alone does not achieve it.

Last updated on
WaaP vs Embedded Wallet ServicesBlind Signing Resistance