top of page

THREAT MODEL
CUVEX

A threat model defines which threats are considered relevant, which are explicitly mitigated, and which fall outside the scope of the system.

​

Cuvex does not attempt to protect against every possible risk. It is designed to mitigate a specific set of real-world threats in self-custody through verifiable architectural decisions. This page describes Cuvex’s threat model in a clear, explicit, and transparent manner.

FUNDAMENTAL PRINCIPLE

The majority of self-custody incidents do not stem from broken cryptography, but from poor architectural design, metadata leakage, and overreliance on connected software.

​

Cuvex addresses this problem at the design level.

PROTECTED ASSETS

Cuvex is designed to protect:

​

  • Seed phrases (BIP-39 and equivalents)

  • Derived signing material

  • Integrity of the signing process

  • Privacy of financial activity (metadata)

​

Cuvex does not custody funds nor interact directly with the network.

THREATS COVERED

1. Remote Attacks

Threat

​

  • Malware on a PC or smartphone

  • Compromised applications

  • Backdoors in wallet or management

software

Mitigation in Cuvex

​

  • Fully offline signing

  • Watch-only architecture

  • PSBT as the data interface

  • Dual air gap between transaction

preparation and signing

2. Metadata Leakage and Correlation

Threat

​

  • Balance correlation

  • XPUB exposure

  • IP address to activity linkage

Mitigation in Cuvex

​

  • No backend infrastructure

  • No balance tracking or auditing

  • No accounts or identity layer

  • User-controlled endpoints

3. Physical Attacks on the Device

Threat

​

  • Physical access to the hardware

  • Memory extraction

  • Post-use attacks

Mitigation in Cuvex

​

  • No persistence of secrets

  • Volatile memory only

  • Automatic erasure after each operation

  • Secret separation (external cryptograms)

4. Supply Chain Attacks

Threat

​

  • Tampered devices

  • Modified or replaced firmware

  • Installation of malicious firmware during manufacturing, distribution, or update processes

Mitigation in Cuvex

​

  • Secure bootloader that cryptographically verifies the firmware’s RSA signature before allowing installation or execution

  • Automatic rejection of any unsigned or modified firmware

  • Architecture that does not rely on persistent state

  • Mandatory human verification during critical processes

  • Minimal reliance on firmware for secret custody

5. Human Error

Threat

​

  • Unintended or misunderstood signatures

  • Automatic confirmations

  • Incorrect use of software

Mitigation in Cuvex

​

  • Signing as an explicit, conscious action

  • Visual verification on a dedicated screen

  • Clear separation of roles

OUT-OF-SCOPE THREATS

Cuvex does not aim to mitigate:

​

  • Direct physical coercion of the user

  • Compromise of the physical environment

  • Legal or regulatory attacks

  • Voluntary loss of secrets

​

These risks require additional operational safeguards beyond the scope of the system.

CONCEPTUAL COMPARISON OF MODELS

THREAT MODEL_EN.jpg

RELATIONSHIP WITH THE ARCHITECTURE

Cuvex’s threat model is realized through:

​

  • Personal HSM

  • Sovereign Signing Device

  • Double Air-Gap PSBT architecture

  • Privacy by Design

​

Each technical decision directly addresses a specific threat.

TRANSPARENCY

Cuvex publishes its threat model in order to:

​

  • Enable independent auditing

  • Avoid vague or unfounded claims

  • Support informed decision-making

Security is not based on trust, but on verifiable design.

bottom of page