Introduction

Secubit is a Wallet-as-a-Service (WaaS) platform designed to provide secure, cost-efficient, and flexible custody for institutional crypto assets. Built on modern cryptographic techniques, tamper-proof Hardware Security Modules (HSMs), Multi-Party Computation (MPC), and standards such as FIPS 140-3 and PassKey, Secubit delivers a custody framework that combines bank-grade security with self-sovereign flexibility.

This introduction outlines the system’s design goals, its core entities, and the custodial modes supported by the platform.

Design Goals

Lower Cost

Traditional custody solutions are costly and centralized. Secubit introduces a commoditized HSM wallet model with cost-sharing and mass-scaling methods, enabling institutions of all sizes to benefit from secure custody. By shifting risk into a self-sovereign paradigm, organizations reduce dependency on third parties while maintaining institutional-grade assurance.

Bank-Grade Security

Secubit adopts the same cryptographic standards banks have used for decades:

• Tamper-resistant true random number generation (TRNG)
• Secure Key generation and protected key storage
• In-HSM signing and policy execution
• MPC-based threshold approvals for distributed trust
• FIPS 140-3 Level 3 certified HSMs
• SOC-2 certified datacenter infrastructure

These measures ensure protection against both physical and logical attacks, delivering the strongest possible custody foundation.

Full Key Ownership

Secubit is built around the principle: “Not your keys, not your coins.”

The platform ensures:

• Client-controlled threshold authorizations with MPC
• Censorship resistance, ensuring independence from unilateral third-party controls
• Flexible custody models: from fully custodial to self-sovereign non-custodial setups

Easy Integration

Secubit is designed to integrate seamlessly into existing workflows:

• Rich developer APIs and SDKs for backend integration
• Universal Passkey support for secure authentication directly with HSM
• Smooth integration with web and mobile platforms

System Entities

The diagram illustrates the high-level architecture of Secubit’s Wallet-as-a-Service (WaaS) platform and the interaction between its core entities.

flowchart LR
    N{{"Blockchain </br> Nodes"}}
    HSM("🔒 Secubit HSM")
    S("☁️ </br> Secubit </br> Cloud Service")
    C("Customer </br> System")
    U1("🔑 User")
    U2("🔑 User")
    U3("🔑 User")
    
    N --- S
    HSM --- S
    S -- Secubit API --- C
    C -- approve --- U1
    C -- approve --- U2
    C -- approve --- U3

At the center of the system is the Secubit Cloud Service, which acts as the coordination layer between the secure hardware, the blockchain networks, and the customer’s infrastructure. The cloud service provides a unified API surface for wallet creation, transaction management, policy enforcement, and integration with customer applications.

Behind the cloud service, the Secubit HSM Network provides bank-grade security for cryptographic operations. Private keys are never exposed outside the HSM, and all signing and policy logic are executed inside the tamper-resistant environment. This ensures compliance with standards such as FIPS 140-3 and enables strong protections against both external and insider threats.

The cloud service also maintains a trusted connection to blockchain nodes, enabling reliable transaction broadcasting and state queries. This connection abstracts away the complexity of running and maintaining blockchain infrastructure, allowing customers to focus on business logic while benefiting from secure, highly available blockchain connectivity.

On the customer side, the Customer System integrates directly with Secubit via the Secubit API. This system may represent a treasury platform, exchange backend, or fund management application. Individual user participate in approval workflows by authenticating with Passkeys or secure elements. These users enforce threshold-based policies in an approval quorum, ensuring that no single actor has unilateral control over funds.

Together, these components establish a custody framework that combines bank-grade cryptographic assurance with the flexibility of a self-sovereign model, empowering institutions to operate securely at scale.

Custodial Modes

Secubit supports flexible operational models that allow institutions to balance convenience, control, and compliance.

Custodial Wallet

In custodial mode, Secubit manages the entire private key lifecycle inside its FIPS 140-3 Level 3 HSMs. Keys are never exported; they remain locked within the secure boundary of the HSM at all times.
Transaction signing is only performed when the HSM verifies a quorum of approvals from authorized users, based on policies defined by the client (e.g., 2-of-3 multi-approver). This ensures that even though Secubit holds the keys, control is always governed by client-defined rules.
This model is particularly suited for organizations that prefer the simplicity of managed custody with the assurance of policy-enforced, bank-grade security.

Non-Custodial Wallet

In non-custodial mode, Secubit enables a self-sovereign custody model by splitting control across two independent shares using MPC (Multi-Party Computation).

• One share is held securely within the Secubit HSM network.
• The other share is managed by the client on their own infrastructure.

The client-side share can be protected in multiple ways:

• Bound to one or a quorum of user using Passkey (WebAuthn) controlled by user biometrics on trusted devices.
• Delegated to one or more trading bot, enabling automated execution strategies.

When a transaction needs to be signed, both shares must participate. The HSM will only complete the operation if the client-side share collaborates, ensuring Secubit cannot unilaterally access or move client funds.

This model offers maximum censorship resistance and aligns with the principle of “Not your keys, not your coins”, while still benefiting from Secubit’s secure infrastructure for coordination, signing, and blockchain connectivity.

Building Blocks

The foundation of Secubit’s custody architecture relies on a set of carefully chosen cryptographic and security primitives. These building blocks provide the trust, resilience, and flexibility required for institutional-grade digital asset management. Each component addresses a specific challenge in custody design, and together they form a layered defense that balances security, usability, and scalability.

At the hardware layer, Secubit uses Hardware Security Modules (HSMs) as the root of trust. HSMs are tamper-resistant devices purpose-built to generate, store, and use cryptographic keys without exposing them in plaintext. They enforce strict security policies, support quorum-based approvals, and provide high-assurance cryptographic operations such as signing, encryption, and hashing. In Secubit’s architecture, HSMs guarantee that private keys never leave protected hardware, forming the anchor of both custodial and hybrid custody modes.

On top of this hardware foundation, Secubit integrates Multi-Party Computing (MPC) to distribute trust across multiple entities. Instead of relying on a single private key stored in one location, MPC allows keys to be split into cryptographic shares and used collaboratively without ever reconstructing the full key. This eliminates single points of failure and enables flexible models where Secubit holds one share inside its HSMs while clients hold another, secured by biometrics, PassKey authentication, or automated trading systems. By requiring joint participation, MPC ensures that no single insider or attacker can authorize a transaction on their own.

For user authentication and approval, Secubit adopts PassKey, the modern replacement for passwords that leverages public-key cryptography and biometric factors. PassKey binds user approvals to device-level secure enclaves, ensuring that only legitimate, verified individuals can initiate sensitive actions. Whether approving a custodial transaction or unlocking a non-custodial share, PassKey provides phishing-resistant, user-friendly authentication that integrates seamlessly into Secubit’s workflow.

Finally, Secubit employs Merkle Trees to guarantee data integrity with minimal storage overhead. Instead of storing entire datasets in the HSM, Secubit stores only the Merkle root, which cryptographically commits to all underlying wallet data and policies. Any attempt to alter data can be detected by recomputing the tree and verifying the root. This approach optimizes for the limited storage capacity of HSMs while preserving full integrity guarantees over large and evolving datasets.

Together, these building blocks—HSMs for hardware-rooted trust, MPC for distributed control, PassKey for secure user authentication, and Merkle Trees for scalable data integrity—form the backbone of Secubit’s Wallet-as-a-Service platform. Their interplay ensures that institutional clients gain a custody solution that is both secure and flexible, reducing risks without compromising usability or performance.

Hardware Security Module (HSM)

A Hardware Security Module (HSM) is a purpose-built, tamper-resistant device for generating, storing, and using cryptographic keys. Unlike general-purpose servers or software libraries, an HSM provides a hardened boundary with both physical and logical protections, ensuring that private keys never leave the device in plaintext. All sensitive operations, such as transaction signing or decryption, take place inside the secure enclosure.

HSMs have been the backbone of digital trust in industries such as banking, payments, government, and certificate authorities for decades. In cryptocurrency custody, they provide the security anchor that enables institutional-grade key protection, strong policy enforcement, and compliance with strict regulatory standards.

Key Characteristics

Tamper resistance

HSMs are engineered with protective meshes, epoxy coatings, sensors, and active countermeasures that detect probing or fault injection. When tampering is detected, the device automatically zeroizes sensitive material, erasing secrets to prevent compromise.

True Random Number Generation (TRNG)

Keys are generated using hardware entropy sources that produce truly random numbers. Continuous health tests monitor the output of the TRNG, ensuring that randomness remains unbiased and reliable.

Isolated cryptographic execution

All cryptographic operations such as signing, decryption, or key derivation are executed inside the HSM. By keeping private keys within the secure boundary, the device prevents exposure to host memory, disk, or application software.

Access control & roles

Role-based access ensures separation of duties between administrators, operators, and auditors. Strong authentication, often with multiple factors, is required for sensitive administrative functions.

Policy enforcement

HSMs enforce security policies directly in hardware, such as quorum approvals, dual control, usage restrictions, and time-based access windows. These constraints prevent unauthorized use of keys, even by privileged insiders.

Performance & scaling

Dedicated cryptographic accelerators allow HSMs to process large volumes of asymmetric and symmetric operations quickly. Clustering and partitioning enable scaling for high throughput and multi-tenant isolation.

Security Standards & Assurance

FIPS 140-3 (Level 3 or higher)

This U.S. government standard validates cryptographic modules for tamper resistance, role separation, and identity-based authentication. Compliance with FIPS 140-3 establishes trust for institutional and regulated environments.

Common Criteria (EAL4+)

Independent evaluations of the device’s security functions and development processes provide additional assurance. Common Criteria certifications are widely recognized internationally.

PCI HSM (payments)

In payment systems, PCI HSM certification ensures PIN protection and secure processing of cardholder data. These requirements have become the global baseline for financial transaction security.

Operational controls (hosting)

HSMs are deployed in SOC-2–compliant datacenters with strict access controls, monitoring, and auditing. This ensures that physical security and operational practices complement the hardware protections.

Core Functions

Key generation

HSMs generate keys internally using their built-in True Random Number Generators (TRNGs). This guarantees that the cryptographic material is created with high entropy and free from predictable patterns. The keys are never exposed in plaintext outside of the device during or after generation. This process removes the risk of weak randomness or software-based key creation, which could otherwise undermine the entire security system. By ensuring that keys are born inside trusted hardware, institutions can have confidence that their cryptographic foundations are uncompromised from the very beginning.

Key storage

Once generated, keys are securely stored inside the HSM under device master keys. The storage is encrypted at rest within tamper-resistant memory, ensuring that even if the hardware is stolen, the keys cannot be extracted or reconstructed. Extraction is disallowed or strictly controlled through cryptographic wrapping mechanisms, requiring quorum approval or multi-party authorization. This prevents administrators, insiders, or attackers from ever gaining direct access to private keys while still enabling secure backup and restore procedures under tightly managed conditions.

Cryptographic operations

Digital signatures, encryption and decryption, key exchanges, hashing, and key derivations are executed entirely within the secure boundary of the HSM. Applications interact with these functions through APIs, but the key material itself never leaves the device. This model ensures that cryptographic functions remain trustworthy and resistant to software compromise, malware, or memory scraping.

Key lifecycle management

Throughout their lifecycle, keys can be rotated, archived, destroyed, or backed up, all under strict security controls. When backups are necessary, they are encrypted and authenticated, often requiring split knowledge or quorum control to restore. This ensures no single operator can compromise key material. Regular lifecycle operations extend the long-term security of the system and keep cryptographic practices aligned with compliance and industry standards.

Policy enforcement

HSMs can enforce sophisticated policies at the hardware level. Examples include requiring quorum approvals for signing operations, restricting the number of operations per time window, limiting which algorithms or key sizes can be used, or binding usage to specific contexts. Because these rules are implemented directly inside hardware, they cannot be bypassed or tampered with by compromised host software.

Auditability

Every administrative and cryptographic action performed on the HSM can be logged in a tamper-evident manner. These logs provide accountability for operators, traceability for forensic analysis, and verifiable evidence for regulatory compliance. Institutions can review these logs to ensure that key material is being used correctly and only under authorized workflows.

HSMs in Cryptocurrency Custody

Private key protection

Keys never leave the HSM in plaintext, protecting them from malware, insider attacks, or memory scraping. This makes HSMs the anchor of secure custody, where key secrecy is paramount.

In-HSM signing

Transactions are signed directly within the HSM. Since key material is never exposed to application memory, the attack surface is drastically reduced, ensuring that even compromised software cannot leak or misuse private keys.

Threshold & approval workflows

HSMs can enforce multi-approval requirements such as 2-of-3 or 3-of-5 authorizers before a signature is released. This ensures that no single individual can unilaterally authorize transfers, providing robust governance and preventing fraudulent activity.

Integration with MPC

HSMs can serve as one component of a broader Multi-Party Computation scheme. In this setup, the HSM holds one share of a key, while another share is controlled by the client. Signing requires cooperation across parties, ensuring that no single system or organization ever controls the entire private key.

Threat Model (HSM-Relevant) & Mitigations

How Secubit Uses HSMs

Secubit uses HSMs as the hardware root of trust in its custody platform. Keys are generated with strong entropy inside the HSM, remain confined within secure hardware, and are subject to strict policy enforcement. In custodial mode, Secubit stores the complete key in its HSMs and enforces quorum approvals before any signing operation is released. In non-custodial or hybrid mode, the HSM holds one share of a cryptographic key as part of an MPC scheme, while clients hold the other share. This design ensures that no single party, insider, or attacker can compromise the custody arrangement. By combining HSMs with modern authentication like Passkeys, Secubit can deliver both custodial and self-sovereign wallets, offering institutional-grade security without sacrificing flexibility.

Multi-Party Computing (MPC)

Multi-Party Computing (MPC) is a cryptographic approach that enables multiple independent parties to jointly perform cryptographic operations without ever exposing or reconstructing the underlying private key. In the context of cryptocurrency custody, MPC eliminates the single point of failure inherent in traditional wallets by distributing trust across multiple participants or devices.

MPC has become one of the most important innovations for secure digital asset custody, allowing institutions to enforce governance policies, mitigate insider risk, and enable flexible operational models without compromising security.

Key Characteristics

Threshold key sharing

Instead of generating and storing a private key on one device, MPC protocols create cryptographic shares of a key that are distributed across multiple parties. Each party holds only its own share, and the full key is never reconstructed—not during storage, not during signing.

Distributed signing

When a transaction needs to be signed, each party uses its share to compute a partial signature. These partial signatures are then combined into a final valid signature that the blockchain recognizes as authentic. At no stage is the private key itself reconstructed, meaning that even if some shares are compromised, the private key never exists in any single place.

Policy and quorum enforcement

MPC wallets can enforce quorum policies such as “2-of-3 approvers must sign” or “at least one corporate and one external approver are required.” Because the protocol requires multiple shares to produce a valid signature, these policies are enforced cryptographically rather than relying only on organizational discipline.

Flexibility and resilience

MPC allows different shares to live in different environments—HSMs, secure elements, cloud servers, or end-user devices. Shares can also be backed by biometrics, passkeys, or automated trading engines (trading bots), depending on the client’s operational needs. This distribution enhances resilience against both hardware failure and targeted attacks.

Security Benefits

Elimination of single points of failure

No single system, administrator, or insider can compromise a private key. An attacker would need to compromise multiple independent parties simultaneously.

Resistance to theft and misuse

Because each share is mathematically meaningless on its own, exfiltrating one does not endanger the wallet. Attackers must compromise enough shares to meet the signing quorum, and even then, policy enforcement can block unauthorized use.

Cryptographic strength

MPC protocols rely on advanced mathematics (such as threshold signatures over elliptic curves) that produce signatures identical to those from a conventional private key. To the blockchain, the signature is indistinguishable from one generated in a traditional wallet.

MPC in Cryptocurrency Custody

Operational flexibility

Institutions can run hybrid custody models: for example, Secubit may hold one share in a secured HSM cluster while the client holds another on their own infrastructure. A transaction requires cooperation, making unilateral compromise impossible.

Integration with HSMs

MPC and HSMs complement each other. An HSM can safeguard one share, ensuring tamper-resistant protection and auditability, while other shares can be managed by client systems or user devices. This hybrid approach combines the benefits of hardware security with distributed trust.

Threat Model (MPC-Relevant) & Mitigations

How Secubit Uses MPC

Secubit leverages Multi-Party Computing as a foundational layer of its Wallet-as-a-Service (WaaS) platform. In custodial mode, Secubit may hold all key shares within HSMs but still enforce quorum approvals before signing. In non-custodial or hybrid models, Secubit stores one share in its HSM network while the client holds another, protected by user biometrics, passkeys, or automated trading systems.

By combining MPC with tamper-resistant HSMs, Secubit ensures that keys are never reconstructed, policies are enforced cryptographically, and governance remains both secure and flexible. This enables institutions to adopt custody models that fit their risk tolerance while maintaining bank-grade security.

PassKey

PassKey is a new standard for passwordless authentication based on public-key cryptography, designed to replace passwords with a simpler and more secure model. Instead of remembering and typing a password, users authenticate with a biometric (such as Face ID or fingerprint), a device PIN, or a trusted authenticator. The device generates and stores the private credential securely, and only a corresponding public key is shared with the service.

In the context of cryptocurrency custody, PassKey is a natural fit for protecting wallet access and transaction authorization. It brings both security and usability, ensuring that only legitimate users can initiate actions, while removing many of the risks and inconveniences of passwords and shared secrets.

Key Characteristics

Cryptographic authentication

When a PassKey is created, a key pair is generated on the user’s device. The private key never leaves the device and cannot be extracted. During authentication, the device signs a challenge from the service, proving possession of the private key without exposing it.

Biometric and device binding

PassKey is tied to the user’s device and secured with a biometric factor (fingerprint, facial recognition) or a device PIN. This ensures that even if someone steals the device, they cannot use the PassKey without unlocking it locally.

Cross-platform support

PassKey is built on the WebAuthn and FIDO2 standards. It works across platforms and browsers, and can sync through trusted cloud providers (such as iCloud Keychain or Google Password Manager), allowing users to log in on multiple devices without manual key transfer.

Phishing resistance

Unlike passwords or SMS codes, PassKey is bound to a specific domain. A phishing site cannot trick a PassKey into authenticating because the cryptographic challenge is tied to the legitimate service origin.

Security Benefits

Stronger than passwords

PassKey removes common password vulnerabilities: weak selection, reuse, database breaches, and phishing attacks. Authentication relies on cryptographic proof, not shared secrets.

Easy for users

No need to remember or manage complex credentials. Users simply approve with Face ID, fingerprint, or a device PIN, making secure authentication as seamless as unlocking a phone.

Resistance to credential theft

Because the private key never leaves the device, even a compromised server or intercepted network traffic cannot reveal the secret.

PassKey in Cryptocurrency Custody

Wallet access

PassKey authenticates users into the Secubit dashboard, replacing passwords with biometric-backed cryptography.

Transaction approval

In non-custodial or hybrid wallet models, PassKey protects a user’s approval key or MPC share. A transaction may require multiple PassKey-backed approvals, enforcing strong governance with a simple user experience.

Integration with standards

Since PassKey is based on WebAuthn, it integrates directly with browsers, mobile apps, and hardware authenticators. This makes it a natural fit for Secubit’s goal of easy integration and universal support.

How Secubit Uses PassKey

Secubit leverages PassKey as the default user authentication method for wallet operations. In custodial mode, PassKey is used to sign approvals for HSM. In non-custodial mode, Passkey provides the same approval signing plus PassKey protects the client’s local MPC key share by Secure Element, ensuring that only the rightful user can participate in signing.

By combining PassKey with HSMs and MPC, Secubit achieves a model where cryptographic security extends from the hardware root of trust all the way to the end-user device, providing institutional security with consumer-grade usability.

Merkle Tree

A Merkle Tree, also called a hash tree, is a cryptographic structure that organizes data into a hierarchy of hashes. Each piece of data, such as a transaction, is individually hashed to create the leaves of the tree. Pairs of leaf hashes are then combined and hashed again, forming higher-level nodes. This process continues recursively until only a single hash remains at the top: the Merkle Root. The Merkle Root is a compact cryptographic fingerprint that represents the entire dataset. If even a single bit of input data is changed, the change propagates through the tree and alters the root, making tampering immediately detectable.

flowchart BT
    H1["H1 = h(data1)"]
    H2["H2 = h(data2)"]
    H3["H3 = h(data3)"]
    H4["H4 = h(data4)"]

    H12["H12 = h( H1,H2 )"]
    H34["H34 = h( H3,H4 )"]

    R["root hash = h( H12,H34 )"]

    H1 --> H12
    H2 --> H12
    H3 --> H34
    H4 --> H34
    H12 --> R
    H34 --> R

The efficiency of Merkle Trees comes from the fact that one does not need to recompute or verify the entire dataset to prove membership. Instead, a verifier only needs the data item and the set of intermediate hashes along the path to the Merkle Root, known as a Merkle Proof. This enables logarithmic verification complexity, which is highly efficient even for very large datasets. For example, in a blockchain block with thousands of transactions, a lightweight client can verify that a transaction is valid by checking only a handful of hashes, without downloading the full block.

Merkle Trees guarantee integrity because any attempt to alter a piece of data will be exposed by a mismatch in the Merkle Root. They also offer compact representation, allowing systems to exchange only the root and short proofs rather than complete datasets. This makes them especially valuable in distributed systems, where bandwidth and trust are limited.

In the context of cryptocurrency, Merkle Trees are fundamental to transaction verification and auditing. Bitcoin, for example, arranges all transactions in a block into a Merkle Tree, with the Merkle Root stored in the block header. This root acts as a cryptographic anchor, binding the transactions to the chain’s consensus mechanism. Custody providers also use Merkle Trees to provide clients with proofs of reserves or inclusion proofs that demonstrate holdings or operations without exposing internal records in full.

How Secubit Uses Merkle Tree

Secubit leverages the Merkle Tree structure to efficiently manage wallet data and policy records. Instead of storing every wallet data or policy hash directly in the Hardware Security Module (HSM), Secubit only stores the Merkle root. This approach significantly reduces storage requirements within the constrained environment of the HSM while still guaranteeing the integrity of all underlying wallet data and policies. By verifying any change against the Merkle root, Secubit ensures that even the smallest tampering attempt or inconsistency in the stored data can be detected with cryptographic certainty.

Threat Model

Secubit’s threat model is based on a simple principle: do not trust networks or servers. Middle servers such as exchanges, WaaS providers, or custody orchestration layers are treated as potential points of compromise. They may relay information, but they are never relied upon for authenticating or safeguarding user intent.

Instead, all trust is anchored in cryptographic proofs and direct authentication between the user and the HSM. The user’s device, protected by biometrics and backed by secure hardware (such as a Secure Element or PassKey), signs every individual request. The HSM verifies these proofs before performing any sensitive operation, ensuring that only explicitly authorized actions are executed.

This means that one-time approvals cannot be reused or expanded into multiple actions. Every transaction, policy change, or cryptographic operation must carry its own fresh, user-bound approval. Replay attempts, insider misuse, and server-side compromises are neutralized because the HSM requires verifiable proof of user intent for every request.

By structuring the system around this model, Secubit ensures that even if servers or communication channels are compromised, attackers cannot impersonate users or bypass key security policies. The combination of per-request authentication and hardware-enforced policy checks makes cryptographic validation—not network perimeter defenses—the ultimate arbiter of trust.

Wallet Authentication Vulnerability

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

    A1(("😡 </br> Attack"))
    A1 -- ✅ bypass user --> C
    A2(("😡 </br> Attack"))
    A2 -- ✅ bypass user --> S

In digital asset custody systems, authentication is often the most critical line of defense. While cryptographic algorithms and secure enclaves are mathematically strong, the weakest links usually emerge in the layers that sit between the user and the secure signing environment. These are the so-called middle servers—such as exchange backend servers or Wallet-as-a-Service (WaaS) cloud servers—that act as intermediaries for transaction requests.

These middle servers become highly attractive targets for attackers because they serve as central aggregation points for user requests. If compromised, they effectively act as honey pots, holding both the authority to forward transactions and, in many cases, sensitive metadata about users, wallets, and policies.

The primary risk comes from server-side compromise. If an attacker gains control over a middle server, they can initiate fraudulent signing requests directly to the wallet enclave or HSM. Since the enclave itself typically cannot distinguish between a genuine request from a user and a forged request from a compromised server, the attacker gains the ability to submit arbitrary transactions. This bypasses end-user intent entirely, undermining the trust model of the custody solution.

In other words, even if keys remain secure inside an HSM or enclave, the authentication path is broken. A compromised middle server can impersonate any user, turning the wallet enclave into a blind signing machine. This type of vulnerability illustrates that security does not end at cryptography—authentication workflows and trust boundaries must also be hardened.

To mitigate this risk, modern custody architectures must push authentication checks as close as possible to the user and the secure enclave. Techniques such as direct PassKey verification, quorum-based approvals, out-of-band confirmations, and MPC-based distributed signing are designed to prevent compromised servers from unilaterally generating valid signing requests. By ensuring that every signing operation reflects the explicit, authenticated intent of a legitimate user, the attack surface of middle servers can be drastically reduced.

End‑to‑End 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    

End‑to‑end 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 end‑to‑end 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

1. 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.

2. 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.

3. 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.

4. 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

In summary, end‑to‑end 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.

Security Foundations

The strength of Secubit’s rests on its security foundations. These foundations define how cryptographic material is created, protected, and used, ensuring that every operation is trustworthy and resistant to compromise.

Rather than relying on the security of servers or networks, Secubit is built on hardware-rooted trust anchored in tamper-resistant HSMs. Within these devices, private keys are generated using True Random Number Generators, stored in secure hardware, and never leave the protected environment in plaintext. All sensitive operations—such as user authentication, transaction signing, and policy enforcement—are executed inside the HSM boundary, providing strong guarantees against insider abuse, software compromise, or external attacks.

This chapter introduces the core building blocks of Secubit’s security model: key generation, key storage, user authentication, transaction signing, policy checking, and secure software updates. Together, these mechanisms form the foundation that enables bank-grade security, self-sovereign control, and compliance with institutional standards.

User Authentication

Secubit secures user authentication with a direct, end-to-end link between the end-user and the Hardware Security Module (HSM). Instead of relying solely on cloud servers or application intermediaries, every critical wallet operation is cryptographically bound to the user’s device and identity.

When a user initiates an action, their device’s Secure Element or PassKey signs the request locally, often gated by biometrics such as fingerprint or Face ID. This signature travels with the transaction request all the way to the HSM. The HSM, before processing, verifies that the request was indeed authorized by the registered user device.

This architecture ensures that even if an intermediate server (e.g., a WaaS service or custody platform) is compromised, attackers cannot fabricate valid signing requests. The HSM will reject any request that lacks a genuine user-device signature.

By requiring user approval for each request, Secubit eliminates the risk of blanket approvals or silent server-side substitutions. The combination of strong device-bound authentication, biometric protection, and hardware-enforced verification creates a trust model that does not depend on network security or server integrity—only on cryptographic proof.

Transaction Signing

Transaction signing in Secubit is performed entirely within the secure boundary of the Hardware Security Module (HSM). Private keys never leave the HSM in plaintext, and all signing operations are coupled with strict access policies and authentication checks.

When a transaction request reaches the HSM, the module first verifies that the request has been authenticated by the end-user through a PassKey or Secure Element signature. Only after this verification does the HSM derive or access the corresponding key material needed for the signing process.

Key derivation and cryptographic signing happen strictly inside the HSM, leveraging hardware acceleration and tamper-resistant protections. The resulting digital signature is returned to the application layer, while the private key remains confined to secure storage.

This approach ensures that transactions cannot be signed without explicit user approval and that no attacker—whether external or insider—can extract or misuse signing keys. By binding every signature to in-HSM execution, Secubit establishes a trustworthy root of security for all wallet operations.

Policy Checking

Policy checking in Secubit is enforced directly inside the Hardware Security Module (HSM). Instead of relying on external servers or middleware, the HSM itself validates that each transaction request complies with the security and governance rules defined by the client.

These policies may include quorum approvals, dual control, spending limits, time-based restrictions, or algorithm constraints. Because they are executed inside the secure boundary, they cannot be bypassed by compromised servers or manipulated through network attacks.

When a transaction request reaches the HSM, the module first authenticates the user signature and then evaluates the request against the defined policies. Only if all conditions are satisfied will the HSM proceed to sign the transaction.

By embedding policy checking in hardware, Secubit ensures that governance rules are enforced with cryptographic certainty, not server trust. This guarantees that even privileged insiders or compromised infrastructure cannot override organizational controls.

Key Generation

At the heart of any secure wallet system lies the process of key generation. Cryptographic keys are the anchors of trust: if they are weak, predictable, or exposed, the entire system becomes vulnerable. For this reason, Secubit relies on True Random Number Generation (TRNG) inside its Hardware Security Modules (HSMs) to generate all cryptographic keys.

Unlike pseudo-random software generators, which rely on deterministic algorithms and can be influenced by external conditions, a TRNG uses dedicated hardware sources of entropy—such as electronic noise, oscillator drift, or quantum effects—to produce unpredictable values. These entropy sources are continuously tested to ensure health and uniformity, preventing bias or degradation over time.

By confining key generation to the HSM, private keys are created entirely within the device’s tamper-resistant boundary. They never exist in plaintext outside of secure hardware, nor do they traverse application memory, disks, or networks. This ensures that even if the surrounding infrastructure is compromised, the cryptographic root of trust remains uncompromised.

Keys generated in this way are immediately protected under the HSM’s internal master keys, and their usage is subject to strict hardware-enforced policies. Whether for signing, encryption, or participation in Multi-Party Computing (MPC), every key begins its lifecycle with strong entropy and secure creation.

This approach guarantees that the cryptographic foundation of Secubit wallets is not only mathematically secure, but also hardware-anchored and resistant to external manipulation. Key generation with TRNG inside HSMs is therefore the cornerstone of Secubit’s security model.

Key Storage

Once cryptographic keys are generated, they must remain secure throughout their entire lifecycle. Secubit ensures this by relying on tamper-resistant storage within Hardware Security Modules (HSMs).

Keys never leave the secure boundary of the HSM in plaintext. Instead, they are stored internally in encrypted form, protected by device-specific master keys that are rooted in hardware. This wrapping process ensures that even if data were copied from the device, it would be useless without the HSM that created it.

The physical and logical protections of the HSM—such as intrusion detection meshes, active response sensors, and zeroization mechanisms—make unauthorized extraction nearly impossible. If tampering is detected, the device automatically erases sensitive material, preventing compromise.

Additionally, key access is governed by strict hardware-enforced policies. Roles and permissions define which operations are permitted, while quorums and dual-control workflows prevent unilateral misuse. This means that even insiders with elevated privileges cannot bypass protections to misuse stored keys.

By anchoring key storage in tamper-resistant HSMs, Secubit ensures that private keys are never exposed to host memory, operating systems, or cloud environments. This guarantees that the most sensitive assets in the system remain safeguarded against both physical and digital threats.

Software Update

Secubit employs a layered and ceremonial model to secure HSM firmware updates. Since the wallet program is a critical component of the custody platform, updates must be delivered in a way that prevents tampering or unauthorized modifications.

In this model, every HSM wallet program update is digitally signed within a controlled ceremony using keys stored inside an HSM. The signing process ensures that only authorized and verified versions of the program can be deployed to HSM.

When the HSM receives an updated program, it verifies the digital signature before loading the new code. If the signature does not match or if the update has been altered, the HSM will reject it. This guarantees that only authentic, integrity-checked, and authorized program can run within the secure environment.

By combining formal signing ceremonies with hardware-based verification, Secubit eliminates the risk of malicious code injection or unauthorized changes, providing confidence that the software foundation of the custody platform remains trustworthy.

Software Architecture

The Secubit platform is designed with a layered architecture that separates trust domains and ensures that sensitive operations are performed only within secure boundaries. Each component plays a distinct role in providing security, scalability, and usability.

flowchart LR
    subgraph HSM["🔒 Secubit HSM"]
        V("vault")
    end

    N{{"Blockchain </br> Nodes"}}

    subgraph CS["☁️ Secubit Cloud Service"]
        S("server")
        DB[("database")]
    end

    C("Customer </br> System")
    
    subgraph U["User Machine"]
    direction TB
        B("browser")
        JS("secubit.js")  
        SE("🔑 secure element")
    end
    
    N --- S
    V --- S
    S -- Secubit API --- C
    C --- B

At the foundation is the Secubit HSM, which serves as the hardware root of trust. Inside the HSM, the vault module is responsible for generating, storing, and using cryptographic keys. All private key material remains confined to this environment, and only cryptographic results (such as signatures) leave the device.

The Secubit Cloud Service operates as the orchestration layer. It provides a secure API, manages the database of wallet metadata and policies, and coordinates requests between customer systems, blockchain nodes, and the HSM. Importantly, the cloud service never has access to raw private keys. Instead, it enforces access policies, tracks audit logs, and provides integration points for institutional workflows.

On the client side, the Customer System interacts with the Secubit API to request operations such as wallet creation, transaction signing, or policy updates. These systems represent funds, custodians, or other organizations managing crypto assets through Secubit’s platform.

End users interact through the User Machine, which may include a browser, the secubit.js client library, and the user’s local Secure Element. The secure element ensures that end-to-end authentication is maintained between the user and the HSM, preventing attacks from compromised servers or intermediaries.

Finally, Blockchain Nodes connect Secubit’s custody layer to public networks. The system interacts with nodes to broadcast signed transactions and query blockchain state, but no sensitive operations are performed outside the HSM.

Vault

The Vault is Secubit’s custom firmware extension that runs inside the HSM, acting as the core of the platform’s security model. It extends the native HSM capabilities with specialized logic for wallet custody, policy enforcement, and direct user authentication. Unlike general-purpose applications, the Vault operates entirely within the HSM’s secure boundary, ensuring that sensitive processes never leave trusted hardware.

flowchart LR
    subgraph HSM["🔒 Secubit HSM"]
        V("vault")
    end

    S["☁️  </br> Secubit  </br> Cloud Service"]

    V --- S

The Vault integrates several critical functions. It executes policy checking directly inside the HSM, enforcing rules such as quorum approvals, rate limits, and key usage restrictions without relying on external servers. It also provides direct PassKey authentication, allowing the HSM to verify end-to-end user signatures without exposing credentials to intermediary services. Furthermore, the Vault manages key derivation and transaction signing, ensuring that all cryptographic operations remain confined to the secure environment.

To guarantee integrity, the Vault itself is subject to a secure loading ceremony. Before it is installed, the HSM verifies its signature, preventing the execution of unauthorized or tampered firmware. This process provides strong assurance that only trusted code governs key material and wallet operations.

The Vault also incorporates Merkle Tree support within the HSM. By storing only the root hash inside the device, it optimizes limited storage space while preserving full verifiability of wallet data and policies. This allows Secubit to guarantee data integrity without overloading the secure boundary with large datasets.

As the core security component of Secubit, the Vault represents the point where cryptographic strength, hardware protections, and advanced protocols converge. It ensures that the HSM is not only a passive key container but an active enforcement engine for security, authentication, and governance.

Server

The Server is the orchestration layer that connects all of Secubit’s components together. Running in a secure cloud environment, it integrates with the Vault inside the HSM, communicates with external blockchain nodes, manages the database, and interfaces with customer systems through the Secubit API.

flowchart LR
    HSM["🔒 Secubit HSM"]

    N{{"Blockchain </br> Nodes"}}

    subgraph CS["☁️ Secubit Cloud Service"]
        S("server")
        DB[("database")]
    end

    C["Customer </br> System"]
    
    N --- S
    HSM --- S
    S -- Secubit API --- C

The server plays a central role in coordinating operations across the custody platform. It provides the Secubit API, which enables customers to initiate wallet actions, query balances, or request transaction signing in a standardized and secure manner. All requests received through the API are authenticated, ensuring that only authorized customer systems can access custody services.

In addition to communication and coordination, the server maintains a copy of the full Merkle Tree inside its database. This enables efficient data queries, policy tracking, and transaction management, while the HSM stores only the root hash to guarantee integrity. The server thus balances performance and scalability with hardware-based trust.

By serving as the bridge between the HSM, the customer systems, and the blockchain network, the server allows Secubit’s custody framework to operate seamlessly. While the HSM enforces strict security and policy checks, the server ensures that customers and external networks can interact with the platform efficiently and reliably.

Approver

The Approver is the Secubit module that provides the approval mechanism for all wallet actions. It is implemented as a lightweight JavaScript component that can run directly in a user’s browser or in other environments such as automated trading systems.

flowchart LR
    C["Customer </br> System"]

    subgraph U["User Machine"]
    direction TB
        B("browser")
        JS("secubit.js")  
        SE("🔑 secure element")
    end
    
    C --- B

At its core, the Approver interacts with the device’s Secure Element through PassKey, ensuring that approvals are tied to strong, biometric-backed authentication. By supporting the exact message formats and canonical encodings expected by the HSM, the Approver enables direct end-to-end authentication between the user’s device and the HSM, without relying on intermediate servers.

Because of its flexible design, the Approver can be used not only for individual users but also for trading bots or other automated agents. In those cases, bots are enrolled with their own public keys and can sign requests on behalf of the user, subject to the policies enforced inside the HSM.

The Approver thus serves as the last step of user intent verification, ensuring that no request—whether initiated by a human user or an automated system—can be processed by the HSM without valid, cryptographically bound approval.

Wallet Models

Secubit supports multiple wallet models to meet the diverse needs of institutional clients. These models define how private keys are managed, who holds control, and how approvals are enforced. By offering both custodial and non-custodial options, Secubit balances flexibility with bank-grade security.

In the custodial wallet model, Secubit’s HSMs hold the entire signing key, and clients delegate custody to Secubit’s infrastructure. Even so, user approvals are still required: transactions are only signed if the HSM verifies that the threshold of authorized users has approved the request. This provides the convenience of managed custody while ensuring that unilateral actions are not possible.

In the non-custodial wallet model, no single party holds the complete key. Instead, keys are divided into shares using Multi-Party Computing (MPC). One share remains inside the HSM, while the other share is distributed to client users. Transactions require both user approvals and collaboration between the HSM and user key share to produce a valid signature. This ensures that clients maintain direct control over their assets, while still benefiting from Secubit’s hardware-rooted enforcement and infrastructure.

Together, these models provide institutions with the choice of full custody convenience or elf-sovereign control, both backed by the same cryptographic protections and policy enforcement inside Secubit’s HSM network.

Custodial Wallet

In the custodial wallet model, Secubit takes full responsibility for the secure storage and use of the cryptographic signing key. The entire private key is generated and protected inside the Secubit HSM, where it never leaves in plaintext. Customers delegate custody of the signing key to Secubit, while still maintaining control through approval policies.

Each user enrolled in the system holds an approving private key. This key is protected by PassKey or biometrics on the user’s device in Secure Element and used to sign approval messages for transaction requests. When a transaction is initiated, the request is distributed to the approvers. Each approver signs it with their private key, creating a digital approval.

These approvals are sent to the HSM, which verifies their authenticity and checks that the required threshold policy (for example, 2-of-3 approvals) has been met. Only if the necessary quorum of approvals is satisfied will the HSM unlock access to the signing key for that specific transaction. The HSM then signs the transaction internally and outputs a valid blockchain signature, while the key itself never leaves the device.

This workflow ensures that while Secubit holds the signing key inside its secure HSM, no single party can authorize a transaction unilaterally. Both the customer’s approval workflow and the HSM’s hardware-enforced policies must align for a transaction to be signed. In this way, Secubit provides the convenience of custodial management with the security of strong cryptographic policy enforcement.

flowchart
    R["request"]
    R --> U1
    R --> U2
    R --> U3
    R --> TS

    subgraph U1["User 1"]
        AK1("🔑 approving privkey 1")
        AK1 --> S1
        S1(["sign"])
    end
    S1 --> A1 --> V1
    A1["approval 1"]

    subgraph U2["User 2"]
        AK2("🔑 approving privkey 2")
        AK2 --> S2
        S2(["sign"])
    end
    S2 --> A2 --> V2
    A2["approval 2"]

    subgraph U3["User 3"]
        AK3("🔑 approving privkey 3")
        AK3 --> S3
        S3(["sign"])
    end
    S3 --> A3 --> V3
    A3["approval 3"]

    subgraph HSM["Secubit HSM"]
        V1{"verify?"}
        V1 --> TH

        V2{"verify?"}
        V2 --> TH

        V3{"verify?"}
        V3 --> TH

        TH{"threshold?"}
        TH --> TS

        SK("🔑 signing key")
        SK --> TS
        TS(["sign"])
    end

    TS --> T
    T["transaction"]

Non-Custodial Wallet

In the non-custodial wallet model, Secubit provides secure infrastructure but does not hold the entire signing key. Instead, the key is divided into cryptographic shares using Multi-Party Computing (MPC). One share remains inside the Secubit HSM, while the other shares are distributed to client users. This ensures that no single party — not even Secubit — ever has the full key, and every transaction requires collaboration.

Each user holds two components: an approving private key and a signing key share. The approving private key is used to authorize requests, protected by PassKey or biometrics on the user’s device Secure Element. The signing key share participates in the MPC signing process, where users generate partial signatures without ever reconstructing the complete key.

When a transaction is requested, each user must first approve the request with their approving private key. Then, their signing key share contributes a partial signature. All of These partial signatures are equal, and one of them will be used as signature share A.

Inside the HSM, the Vault verifies that the required threshold of user approvals has been satisfied. If valid, the HSM uses its own signing key share to produce another partial signature, signature share B. Finally, the HSM combines signature share A (from the client) and signature share B (from the HSM) into the complete transaction signature.

This workflow guarantees that:

1. Users retain direct control over their key shares, ensuring self-sovereignty.
2. Threshold approvals must be satisfied before the HSM contributes its share.
3. The full private key is never reconstructed, only the final transaction signature is produced.

The non-custodial model provides the highest degree of client control, while still leveraging Secubit’s HSM network for secure enforcement, auditability, and policy integration.

flowchart
    R["request"]
    R --> U1
    R --> U2
    R --> U3
    R --> SB

    subgraph U1["User 1"]
        AK1("🔑 approving </br> privkey 1")
        AK1 --> S1
        S1(["sign"])

        SK1("🔑 signing </br> key share A")
        SK1 --> SA1
        SA1(["mpc sign"])
    end
    S1 --> A1 --> V1
    A1["approval 1"]
    SA1 -.-> SIG_A

   subgraph U2["User 2"]
        AK2("🔑 approving </br> privkey 2")
        AK2 --> S2
        S2(["sign"])

        SK2("🔑 signing </br> key share A")
        SK2 --> SA2
        SA2(["mpc sign"])
    end
    S2 --> A2 --> V2
    A2["approval 2"]
    SA2 -.-> SIG_A

    subgraph U3["User 3"]
        AK3("🔑 approving </br> privkey 3")
        AK3 --> S3
        S3(["sign"])

        SK3("🔑 signing </br> key share A")
        SK3 --> SA3
        SA3(["mpc sign"])
    end
    S3 --> A3 --> V3
    A3["approval 3"]
    SA3 -.-> SIG_A

    SIG_A["signature share A"]

    subgraph HSM["Secubit HSM"]
        SK("🔑 signing key share B")
        SK --> SB
        SB(["mpc sign"])

        V1{"verify?"}
        V1 --> TH

        V2{"verify?"}
        V2 --> TH

        V3{"verify?"}
        V3 --> TH

        TH{"threshold?"}
        TH --> SB --> SIG_B

        SIG_B["signature share B"]
        SIG_B --> C

        C(["mpc combine"])
    end

    SIG_A --> C --> T
    T["transaction"]

HSM Workflows

At the core of Secubit’s custody platform, Hardware Security Modules (HSMs) enforce all critical cryptographic guarantees. To support secure wallet operations at scale, HSMs not only protect private keys but also manage wallet state, derive signing keys, and remain synchronized across distributed deployments.

Wallet data is committed into a balanced Merkle tree, where the HSM stores only the root hash while the server maintains the full structure. Whenever a wallet is added, updated, or removed, the HSM verifies the change through Merkle proofs. This design keeps secure storage inside the HSM minimal while still guaranteeing the integrity of all wallet records.

Key material is managed through a process of sealed derivation inside the HSM. Wallet seeds are encrypted under a sealing key derived from the HSM’s master key and the wallet hash. The server holds only encrypted seeds, while the HSM decrypts them on demand and deterministically derives signing keys. For compatibility across blockchain ecosystems, derivation follows BIP-32 for secp256k1 or SLIP-10 for ed25519. At no stage does plaintext key material ever leave the secure hardware boundary.

In distributed environments, synchronization across multiple HSMs ensures that state remains consistent. Each HSM validates root transitions using both the Merkle root update and an HMAC generated with a shared sync key. Updates are applied only when the HMAC matches and the current root aligns with the expected state, preventing forgery, replay, or divergence across devices.

Together, these workflows form the operational backbone of Secubit’s security model. They guarantee that wallet state is compact, auditable, and cryptographically verifiable, that key derivation remains confined to secure hardware, and that multiple HSMs operate in lockstep to preserve institutional-grade trust.

Wallet Data and Merkle Tree

This page explains how Secubit manages a Merkle tree of wallet metadata, how it hashes and serializes wallet data, and why the tree is kept balanced.

At a high level, the server maintains the full Merkle tree for fast queries and auditing, while the HSM stores only the Merkle root (to minimize secure storage usage) and verifies updates/proofs against that root. Every change to wallet metadata updates exactly one leaf and recomputes hashes only along its path to the root.

Merkle Node

Wallet data includes the following fields:

#![allow(unused)]
fn main() {
pub struct WalletData {
    /// Version of the wallet data format
    pub version: u8,
    /// Wallet ID
    pub id: u64,
    /// Threshold of approvers required to sign a transaction
    pub threshold: u8,
    /// Whether the wallet is custodial or non-custodial
    pub custodial: bool,
    /// List of approvers' public keys
    pub approvers: Vec<String>,
}
}

Wallet data is serialized in a canonical format (stable field order, unambiguous encoding, domain‑separated) before hashing. Each leaf Merkle node contains a wallet hash where:

wallet_hash = SHA-256( serialize(wallet_data) )

And, each parent node contains the hash of its two children concatenated as left–right:

parent_hash = SHA-256( left_child_hash || right_child_hash )

Empty leaves are represented by a fixed constant ZERO (a 32‑byte all‑zero value). In the diagrams, "0000000000" labels the zero for empty leaves.

Why only the root in the HSM? The HSM stores the Merkle root to commit to all wallets without storing the entire dataset. The server proves changes by supplying the updated leaf and its Merkle path.

Algorithm

The goal is keeping the tree balanced which means a complete binary tree that fills left‑to‑right, level‑by‑level. This yields predictable paths, minimal height, and efficient proofs.

New wallets are inserted at the leftmost available leaf position (BFS order). Conceptually:

1. Start from the current node pointer.
2. If the current node has a right sibling, move to the right sibling and try to descend left.
3. If the current node has no right sibling, move up to the parent and repeat unless the parent is root which makes root current.
4. When descending, always take the left child while it exists; when you find a node with no left child, that’s the insertion point

This ensures efficient addition (O(log N) nodes updated) while maintaining tree balance and the integrity of all remaining wallet data.

The following is the flowchart of finding the next current node (next position to add a new node).

flowchart TD
    S(("start"))
    S --> GetCurrent
    GetCurrent("get current node")
    GetCurrent --> HasFather
    HasFather{"has parent?"}

    HasFather -- no --> HasLeftChild
    
    HasFather -- yes --> HasRight
    HasRight{has right </br> sibling?}
    HasRight -- yes --> SetRightToCurrent
    SetRightToCurrent("current node := </br> right node")
    SetRightToCurrent --> HasLeftChild

    HasRight -- no --> SetParentToCurrent
    SetParentToCurrent("current node := </br> parent node")
    SetParentToCurrent --> HasFather

    HasLeftChild{has left </br> child?}
    HasLeftChild -- no --> E
    HasLeftChild -- yes --> SetLeftChildToCurrent
    SetLeftChildToCurrent("current node := </br> left child node")
    SetLeftChildToCurrent --> HasLeftChild

    E(("end"))

Initializing Merkle Tree

The diagrams show which node changes (red border) and which ancestors are recomputed (orange border).

At initialization, the tree contains only one empty leaf which is root too; therefore the root is set to zero, and the current node is set to root.

flowchart TD
    R("root hash = 0000000000 </br> (current)")
    style R stroke:red,stroke-width:2px

Adding Wallet

Adding a wallet causes growing the Merkle tree. The algorithm keeps it balanced which makes it efficient with shortest update path in parents.

Adding 1st wallet

flowchart TD
    R("root hash")
    R -- L --- Z
    R -- R --- W1

    Z("0000000000 </br> (current)")
    W1("wallet hash 1")

    style W1 stroke:red,stroke-width:2px
    style R stroke:orange,stroke-width:2px

Adding 2nd wallet

flowchart TD
    R("root hash")
    R -- L --- PL
    R -- R --- W1
    W1("wallet hash 1 </br> (current)")

    PL("parent hash - L")
    PL -- L --- Z
    PL -- R --- W2
    Z("0000000000")
    W2("wallet hash 2")

    style W2 stroke:red,stroke-width:2px
    style PL stroke:orange,stroke-width:2px
    style R stroke:orange,stroke-width:2px

Adding 5th wallet

flowchart TD
    R("root hash")
    R -- L --- PL
    R -- R --- PR

    PL("parent hash - L")
    PL -- L --- PLL
    PL -- R --- PLR

    PLL("parent hash - LL")
    PLL -- L --- Z
    PLL -- R --- W4
    Z("0000000000")
    W4("wallet hash 4")

    PLR("parent hash - LR")
    PLR -- L --- W2
    PLR -- R --- W5
    W2("wallet hash 2")
    W5("wallet hash 5")

    PR("parent hash - R")
    PR -- L --- W1
    PR -- R --- W3
    W1("wallet hash 1 </br> (current)")
    W3("wallet hash 3")

    style W5 stroke:red,stroke-width:2px
    style PLR stroke:orange,stroke-width:2px
    style PL stroke:orange,stroke-width:2px
    style R stroke:orange,stroke-width:2px

Updating Wallet

When a wallet’s metadata changes (for example, new approvers or a threshold adjustment), its leaf hash must be updated and all ancestors on the Merkle path recomputed up to the root.

For example, updating wallet 2 follows this Merkle path from root: L/R/L

To verify and update this path, the HSM needs:

• the new wallet hash computed from wallet_data_2,
• the sibling hashes along the path (here, wallet hash 5 - sibling of wallet hash 2, parent LL - sibling of LR, and parent R - sibling of L),
• and the current root hash for verification.

The HSM recomputes hashes along the path using the formula parent = SHA-256(left || right). If the recomputed root matches the stored root, the update is accepted and the new root replaces the old one.

flowchart TD
    R("root hash")
    R -- L --- PL
    R -- R --- PR

    PL("parent hash - L")
    PL -- L --- PLL
    PL -- R --- PLR

    PLL("parent hash - LL")
    PLL -- L --- Z
    PLL -- R --- W4
    Z("0000000000")
    W4("wallet hash 4")

    PLR("parent hash - LR")
    PLR -- L --- W2
    PLR -- R --- W5
    W2("wallet hash 2")
    W5("wallet hash 5")

    PR("parent hash - R")
    PR -- L --- W1
    PR -- R --- W3
    W1("wallet hash 1 </br> (current)")
    W3("wallet hash 3")

    style W2 stroke:red,stroke-width:2px
    style PLR stroke:orange,stroke-width:2px
    style PL stroke:orange,stroke-width:2px
    style R stroke:orange,stroke-width:2px

Removing Wallet

When a wallet is deleted, its leaf in the Merkle tree is replaced with a ZERO value to preserve the tree’s balanced structure. Ancestors along the path must then be recomputed up to the root. This approach avoids reshuffling other wallets and keeps indices and paths stable.

For example, removing wallet 2 follows this Merkle path from root: L/R/L

To perform the removal, the HSM needs:

• the ZERO leaf value to replace wallet_data_2,
• the sibling hashes along the path (here, wallet hash 5 - sibling of wallet hash 2, parent LL - sibling of LR, and parent R - sibling of L),
• and the current root hash for verification.

The HSM recomputes the path using parent = SHA-256(left || right). If the recomputed root matches the stored root, the update is accepted and the new root is committed.

flowchart TD
    R("root hash")
    R -- L --- PL
    R -- R --- PR

    PL("parent hash - L")
    PL -- L --- PLL
    PL -- R --- PLR

    PLL("parent hash - LL")
    PLL -- L --- Z
    PLL -- R --- W4
    Z("0000000000")
    W4("wallet hash 4")

    PLR("parent hash - LR")
    PLR -- L --- W2
    PLR -- R --- W5
    W2("0000000000")
    W5("wallet hash 5")

    PR("parent hash - R")
    PR -- L --- W1
    PR -- R --- W3
    W1("wallet hash 1 </br> (current)")
    W3("wallet hash 3")

    style W2 stroke:red,stroke-width:2px
    style PLR stroke:orange,stroke-width:2px
    style PL stroke:orange,stroke-width:2px
    style R stroke:orange,stroke-width:2px

Key Derivation in HSM

Secubit uses a layered key derivation model that ensures wallet keys are never exposed outside of the HSM in plaintext and are always bound to cryptographic proofs of the wallet’s identity. The HSM combines its root of trust (root hash) with a hardware-protected master key to seal and control wallet data, while the server stores only encrypted values.

The process works as follows:

• Wallet identity commitment
  Each wallet has a unique hash aka wallet hash derived from its metadata and validated against the Merkle root stored in the HSM. The wallet hash, together with the relevant parent hashes, establishes a proof of membership in the Merkle tree.

• Sealing with a master key
  The HSM holds a hardware-protected master key. Using AES-256 encryption, the HSM combines the master key with the wallet hash to derive a wallet sealing key. This key never leaves the HSM in plaintext and acts as a per-wallet symmetric key used for encrypting or decrypting wallet seeds.

• Server storage of encrypted seeds
  The Secubit server stores only encrypted wallet seeds in its database. These seeds are protected with the corresponding wallet sealing key, meaning that even if the database is compromised, no usable key material is exposed without the HSM.

• Key derivation
  When a wallet needs to sign, the HSM uses the wallet sealing key to decrypt the wallet seed. From this seed, the HSM performs deterministic derivation according to BIP-32 or SLIP-10 standards. The derived private key (e.g., secp256k1 or ed25519) is then used for signing inside the HSM.

• Security boundary
  At no point is the plaintext wallet seed or signing key available outside of the HSM. The server and database only see encrypted values, while the HSM enforces policies and produces signatures.

flowchart TD
    subgraph HSM["Secubit HSM Store"]
        R("root hash")
        MK("🔑 master key")
    end

    R --- P --- W
    P("parent hashes")
    W("wallet hash")
    W ---> E

    MK ---> E
    E(["encrypt (aes256)"])
    E ---> WSK
    WSK("🔑 wallet sealing key")
    WSK ---> D

    subgraph S["Secubit Server"]
        DB[("database")]
    end
    DB ---> EWS
    EWS("encrypted wallet seed")
    EWS ---> D

    D(["decrypt (aes256)"])
    D ---> WS ---> DR ---> SK
    WS("🔑 wallet seed")
    DR(["derive (bip32/slip10)"])
    SK("🔑 signing key")

Cryptography Specifications

Secubit supports industry-standard cryptographic curves and deterministic derivation schemes that match the requirements of different blockchain ecosystems.

• secp256k1
  The elliptic curve used in Bitcoin and Ethereum. Secubit uses this curve for ECDSA and Schnorr signatures. Key derivation for secp256k1 follows the BIP-32 standard for hierarchical deterministic (HD) wallets.

• ed25519
  A modern elliptic curve designed for both speed and security. It is widely used in newer blockchain platforms. Key derivation for ed25519 uses the SLIP-10 scheme, which adapts hierarchical deterministic derivation to this curve.

• BIP-32 (Bitcoin Improvement Proposal 32)
  Defines HD wallets specifically for secp256k1. From a single seed, an entire structured key tree can be derived, making account and address management efficient and reproducible.

• SLIP-10 (SatoshiLabs Improvement Proposal 10)
  Provides deterministic derivation for ed25519. This enables account hierarchies and structured key management in ecosystems that rely on ed25519-based signatures.

By combining these cryptographic standards with AES-256 sealing inside the HSM, Secubit ensures that wallet seeds are deterministically derived and cryptographically secure, with no plaintext key material ever leaving the secure hardware boundary.

HSMs Synchronization

In Secubit’s architecture, multiple HSMs may be deployed across different secure facilities or datacenters. These HSMs must always agree on the current Merkle root to guarantee consistency of wallet data and policies. The synchronization process ensures that updates are cryptographically validated before any root change is applied, preventing unauthorized modifications or state divergence.

The protocol works as follows:

1. HMAC Generation
   Each HSM derives a synchronization proof by concatenating the old root hash with the new root hash and computing an HMAC-SHA256 over this data using a shared sync key. The sync key is provisioned securely into all HSMs during initialization and never leaves hardware.

2. Cross-Validation
   When an update is proposed, HSM 1 generates a sync object containing the old root hash, the new root hash, and its HMAC. This object is sent to HSM 2, which recomputes the HMAC locally and checks for equality. If the HMACs differ, the update is rejected.

3. Current State Check
   In addition to HMAC validation, HSM 2 checks whether the provided old root hash matches its currently stored root hash. This prevents replay attacks or desynchronization if one HSM has already advanced.

4. Update Process
   Only if both checks succeed—the HMAC matches and the current root matches the expected old root—does HSM 2 accept the update and replace its root hash with the new root hash. If either validation fails, the update is discarded.

flowchart
    subgraph HSM1["HSM 1"]
        RH_OLD1("old_root_hash")
        RH_NEW1("new_root_hash")        
        SK1("🔑 sync_key")

        RH_OLD1 --> C1
        RH_NEW1 --> C1
        C1(["concat"])

        C1 --> H1
        SK1 --> H1
        H1(["hmac256"])
        H1 --> HMAC1
        HMAC1("hmac")
    end
    
    subgraph SO["sync_object"]
        RH_OLD_SO("old_root_hash")
        RH_NEW_SO("new_root_hash")
        HMAC_SO("hmac")
    end
    style SO fill:none

    RH_OLD1 --> RH_OLD_SO
    RH_NEW1 --> RH_NEW_SO
    HMAC1 --> HMAC_SO

    subgraph HSM2["HSM 2"]
        RH_OLD_SO --> C2
        RH_NEW_SO --> C2
        C2(["concat"])

        SK2("🔑 sync_key")

        C2 --> H2
        SK2 --> H2
        H2(["hmac256"])
        H2 --> HMAC2

        HMAC2("hmac")
        HMAC2 --> EH2
        HMAC_SO --> EH2
        EH2{"equal?"}

        RH2("root_hash")
        RH_OLD_SO --> ER2
        RH2 --> ER2
        ER2{"equal?"}

        ER2 --> U2
        EH2 --> U2
        U2[["update root_hash to new_root_hash"]]
    end

Security Guarantees

• Data integrity
  Every update binds both the old root hash and the new root hash into the HMAC, ensuring that no forged or altered update can be applied undetected.

• Replay resistance
  The HSM validates that the provided old root hash matches its current state, preventing an attacker from replaying a previously valid synchronization object.

• Shared secret protection
  The synchronization key used for HMAC is provisioned securely inside each HSM and never leaves the hardware boundary, making it impossible to forge updates from outside.

• Consistency across HSMs
  Updates are accepted only when both the HMAC check and the root equality check succeed, guaranteeing that all HSMs converge on the same new root hash.

HSM Key Management

Key management is the foundation of Secubit’s custody platform, and Hardware Security Modules (HSMs) serve as the trusted anchor for every critical operation. To protect against external attacks, insider misuse, and catastrophic failures, Secubit employs a layered key management strategy that combines resilient online operations, secure offline backups, and strict role-based governance.

Online HSMs provide the primary signing and policy enforcement functions, distributed across multiple datacenters with redundancy and automatic synchronization to ensure high availability. Even under hardware or datacenter failures, the architecture guarantees continuity of service while maintaining cryptographic integrity.

For disaster recovery scenarios, Secubit maintains offline air-gapped backup HSMs. These devices store encrypted copies of keys under strict multi-factor authorization, ensuring that even the complete loss of online infrastructure does not result in loss of assets. Recovery from backups also incorporates Merkle root verification to preserve the integrity of wallets' state.

All sensitive operations on HSMs are controlled through clearly defined roles, enforced by physical USB tokens, secure PIN pads, and multi-factor ceremonies. Every action — from key generation to backup to recovery — requires explicit role authorization and is performed in official, recorded ceremonies, creating a transparent and auditable chain of trust.

Together, these mechanisms form Secubit’s HSM Key Management framework: highly available, recoverable, auditable, and cryptographically secure, designed to meet the requirements of institutional-grade custody.

Online HSMs

To deliver high availability and resilience, Secubit operates its Hardware Security Modules (HSMs) in multiple datacenters across distinct geographic locations. This setup ensures continuity of service while meeting strict uptime guarantees.

Secubit’s design targets an SLA of 99% uptime. To achieve this, two datacenters are provisioned, each equipped with two redundant HSMs. Across these sites, one HSM is designated as the primary, while the other three act as standby fail-over devices. If the primary HSM becomes unavailable, Secubit automatically redirects operations to a standby unit, preserving service availability without manual intervention.

Synchronization between HSMs is handled continuously and securely. The system propagates Merkle root updates across datacenters so that all HSMs share a consistent view of wallets' state. If a fail-over occurs, the standby HSM can take over immediately without data loss or state divergence. This synchronization protocol is described in detail in HSMs Synchronization.

flowchart LR
    subgraph DC1["Datacenter 1"]
        HSM1["🔒 HSM 1 </br> (primary)"]
        HSM2["🔒 HSM 2 </br> (standby)"]
    end
    DC1 --- S

    subgraph DC2["Datacenter 2"]
        HSM3["🔒 HSM 3 </br> (standby)"]
        HSM4["🔒 HSM 4 </br> (standby)"]
    end
    DC2 --- S

    S("☁️ </br> Secubit </br> Cloud Service")

All cryptographic keys used by Secubit are generated in a formal key ceremony, ensuring that master secrets are created, verified, and cloned to each HSM under strict security controls. By replicating keys during the ceremony and maintaining state consistency through automatic synchronization, Secubit guarantees that any HSM in the cluster can serve as a trusted anchor of security.

The datacenters hosting Secubit’s HSMs are SOC 2 certified and operated under strict physical protections, including 24/7 surveillance, controlled access, and monitoring, providing assurance that hardware remains physically secure at all times.

Secubit’s architecture is designed to be scalable, since it uses minimal HSM storage (only a few keys and a single Merkle root) and the performance of HSMs for key operations and policy checking far exceeds the system’s requirements. A single HSM can already support millions of wallets. Additional HSMs are deployed primarily for redundancy and fail-over, ensuring resilience. At the same time, the design makes it straightforward to add more HSMs and datacenters in the future if needed, without disrupting existing operations.

This distributed online HSM architecture provides the foundation for Secubit’s institutional custody platform: a system that is fault-tolerant, resilient against datacenter failures, and continuously available without compromising cryptographic integrity.

Offline Backup HSMs

Secubit’s custody architecture is designed so that even extreme scenarios—such as the simultaneous loss of all online HSMs across every datacenter—can be recovered without compromising cryptographic integrity. While the probability of such an event is very low, Secubit ensures resilience by maintaining secure air-gapped backup HSMs.

Two dedicated cold backup HSMs are provisioned to hold an encrypted copy of the master keys. These devices are FIPS 140-2 certified, providing the same level of assurance as the online network HSMs. During the key generation ceremony, a secure transfer is performed directly between a network HSM and the backup HSMs. The process uses end-to-end encryption between the HSMs, so at no point do keys appear in plaintext outside of secure hardware. A quorum of HSM officers must physically authorize this operation using hardware tokens, providing strong multi-factor control.

flowchart LR
    Q(["👮👮👮 Officers"])
    HSM["🔒 Online HSM"]
    B1["❄️ Backup HSM 1 </br> (air-gapped)"]
    B2["❄️ Backup HSM 2 </br> (air-gapped)"]

    HSM -- "encrypted keys" --> B1
    HSM -- "encrypted keys" --> B2

In a disaster recovery event, the same quorum of HSM officers must again present their hardware keys to authorize restoration. Encrypted key material is securely transferred from a backup HSM into new blank network HSMs. To complete recovery, the system also needs the latest Merkle root, which is not stored in backup HSMs. Instead, Secubit maintains a chain of Merkle root history, each signed with an HMAC inside the HSM as part of synchronization mechanism. The Secubit server provides the most recent signed Merkle root to the recovered HSMs, which verify the HMAC before accepting it.

Through this mechanism, Secubit can bring new network HSMs online and restore service quickly, even under catastrophic conditions. The combination of offline key escrow, multi-factor approval, and verifiable Merkle root history ensures that disaster recovery is both practical and cryptographically trustworthy, while keeping the security guarantees of the platform intact.

HSM Roles

To maintain strong separation of duties and reduce insider risk, Secubit enforces role-based access control (RBAC) within its Hardware Security Modules (HSMs). Each role has clearly defined responsibilities, with access restricted by physical tokens and secure PIN entry on dedicated hardware keypads. No single operator can bypass these controls, and sensitive tasks require explicit authorization from the appropriate role.

Security Officers are responsible for establishing the security perimeter within the HSM. They create secure partitions, configure access and key policies, and approve firmware or custom extension updates. This role defines the overall trust boundary of the HSM.

Crypto Officers manage cryptographic material. They generate keys, securely replicate them to offline backup HSMs during key ceremonies, perform key recovery when authorized, and approve signing of firmware extensions or customization modules.

Crypto Users interact with the service layer by generating authentication credentials, such as strong passwords, used by applications or services to request cryptographic operations from the HSM.

Audit Users are dedicated to accountability and compliance. They configure secure audit logging and are the only role permitted to retrieve logs from the HSM. This ensures that all security events and administrative actions remain tamper-proof and independently reviewable.

Domain Users establish and maintain trust domains between online and offline HSMs. When HSMs belong to the same domain, they can securely transfer encrypted key material (for backup or restore) under domain keys, ensuring that secrets never leave hardware unprotected.

All of these roles are tied to physical USB security tokens and PIN entry devices, requiring operators to present their assigned token and enter their PIN on a dedicated hardware pad. This prevents credential sharing, enforces multi-factor authentication, and provides cryptographic proof of operator presence for every critical action. All operations performed by these roles on the HSM take place within official, recorded ceremonies, ensuring full accountability and an auditable trail for every sensitive action.

HSM Hardening

Secubit’s Hardware Security Modules (HSMs) serve as the root of trust for all custody operations, which makes their protection and integrity paramount. Beyond relying on the built-in tamper-resistant design of modern HSMs, Secubit applies a series of hardening techniques to ensure that no critical operation can be bypassed, misused, or subverted.

Hardening begins with customization: Secubit develops its own firmware extension, called vault, in Rust. By moving key derivation, signing, policy enforcement, PassKey authentication, and Merkle tree management directly inside the HSM, no critical logic ever runs in vulnerable external environments.

This is reinforced by strict PKCS#11 key attributes. All external cryptographic permissions are disabled, and every key object is marked as private, preventing enumeration or misuse by compromised servers. The only entity allowed to operate keys is the Vault itself, running inside the secure boundary.

Secubit further applies the principle of least privilege by restricting external access to the Crypto User role. Servers can interact with Vault through this constrained account, but cannot generate, delete, or alter keys directly. Administrative operations remain confined to formal ceremonies requiring officer approval.

Finally, code signing controls protect the integrity of the Vault itself. Firmware extensions must be signed by a trusted key inside the HSM, with Crypto Officer approving the signing ceremony and Security Officer authorizing the load process. This dual-control model ensures that only verified and audited code is ever deployed.

Together, these measures — secure customization, locked-down key attributes, least-privilege external access, and hardware-enforced code signing — form Secubit’s HSM Hardening strategy. They ensure that the HSM not only protects keys, but also enforces policies and executes all sensitive workflows with maximum assurance, auditability, and resilience against attack.

HSM Customization in Rust

Secubit’s threat model assumes that any process executed outside of the Hardware Security Module (HSM) can be compromised by attackers. To eliminate this risk, all critical workflows — including key derivation, transaction signing, blockchain-specific transaction marshalling, the policy engine, end-to-end authentication with PassKey, and Merkle tree validation — are implemented inside the HSM. By doing so, no sensitive operation depends on external servers or application code that may be exposed to compromise.

To achieve this level of customization, Secubit extends the HSM firmware with custom modules tailored for its custody architecture. Although the HSM natively supports customization using a C compiler, Secubit deliberately chose Rust as its development language. Rust provides memory safety guarantees at compile time without requiring a garbage collector or runtime, eliminating entire classes of vulnerabilities such as buffer overflows, memory leaks, and use-after-free attacks that have historically plagued low-level systems code.

The Secubit development framework compiles Rust code into a form compatible with the HSM, then packages it into a signed firmware extension. This extension is signed by the HSM itself during a secure ceremony before being loaded into the device. The signature binding ensures that only authorized and verified extensions can run inside the secure boundary, maintaining the integrity of the HSM environment.

Rust-based extensions provide performance equivalent to C while dramatically reducing the attack surface. By combining Rust’s safety features with the HSM’s tamper-resistant hardware, Secubit delivers a hardened execution layer where policy enforcement, authentication, and signing operations cannot be bypassed or subverted by external threats.

This approach of Rust-driven HSM customization creates a platform that is not only secure by design but also extensible for supporting new blockchains, new cryptographic algorithms, or evolving custody policies without compromising the hardware root of trust.

The custom code that Secubit develops and deploys inside the HSM is called Vault. Vault is the core trusted component that implements policy enforcement, Merkle tree management, PassKey authentication, and blockchain-specific signing logic. It represents the heart of Secubit’s security model, acting as the binding layer between cryptographic keys, business rules, and end-user approvals.

PKCS#11 Key Attributes

Secubit’s HSM follows the PKCS#11 standard, which defines the API for key management, cryptographic operations, and key attributes. Key attributes in PKCS#11 specify how a key can be used (e.g., for signing, encryption, wrapping) and what operational or lifecycle constraints are enforced.

In Secubit’s architecture, the custom HSM code — called vault — runs inside the secure boundary of the HSM with privileged access to keys. The Secubit server connects to the HSM using PKCS#11 session APIs for authentication and communication, but it never calls the raw PKCS#11 cryptographic functions directly. Instead, it interacts with the higher-level Vault API, which abstracts complex operations such as wallet management, policy enforcement, Merkle tree validation, and transaction signing by enforcing user approval protection.

Because of this design, no external entity, including the Secubit server, needs to invoke the HSM’s native PKCS#11 cryptography APIs. As a result, all key attributes related to external usage — such as encrypt, decrypt, sign, verify, wrap, and unwrap — are set to false. This configuration ensures that keys cannot be misused by any party outside of the Vault. The keys exist and operate only within the Vault’s controlled logic, never being exposed to the application layer or to direct PKCS#11 operations.

In addition, all keys and objects in the HSM have the PKCS#11 private attribute set to true. This means that even the handles or metadata of these objects are not visible outside the HSM. If a server or application is compromised, the attacker cannot even enumerate or discover what keys exist inside the HSM, since the device will not reveal this information. Only the Vault, running internally, has the authority to reference and use these hidden objects.

This hardening has strong security implications. Even if the Secubit server were to be compromised and its credentials for establishing an HSM session were stolen, the attacker would be unable to exploit the PKCS#11 interface to misuse keys. The compromised server would still be blocked from modifying wallets or signing transactions, because those actions are exclusively authorized and executed by the Vault code inside the HSM.

By minimizing exposed key attributes, Secubit effectively reduces the attack surface of PKCS#11. The HSM enforces the principle of least privilege, allowing only the Vault to exercise cryptographic functions. This strict separation ensures that key material is never accessible to external software and that all sensitive operations remain confined to the tamper-resistant hardware boundary.

Restrict External Access to Crypto User

As explained in HSM Roles, the HSM enforces role segregation, where each role has different privileges aligned with its responsibilities. By default, access to call the cryptographic API in a PKCS#11-compliant HSM is tied to the Crypto Officer role (sometimes called Normal User). However, Crypto Officers have broader capabilities, such as generating new keys, creating objects, or removing existing ones, in addition to performing cryptographic operations.

In Secubit’s architecture, the principle of least privilege is strictly applied. The Secubit server never needs to generate or destroy raw cryptographic objects; it only needs to interact with the Vault API to manage wallets, enforce policies, and sign transactions. For this reason, Secubit restricts external access to the Crypto User role instead of the higher-privilege Crypto Officer.

This means that the Secubit server can establish a session and request operations through the Vault, but it cannot create, delete, or alter cryptographic keys at the PKCS#11 layer. The only entity with the authority to use keys is the Vault code running inside the HSM, which enforces policies and validates approvals. Even if the server is compromised, the attacker would not gain the ability to manipulate keys or bypass Vault rules, since Crypto User access does not provide such privileges.

By limiting external access to the Crypto User role, Secubit ensures that administrative and destructive operations remain strictly under the control of HSM officers during formal ceremonies, while day-to-day server interactions are constrained to the minimal rights required. This design significantly reduces the attack surface while preserving operational functionality.

HSM Code Signing

The Secubit HSM firmware extension, called vault, implements critical functionality such as key derivation, policy enforcement, transaction signing, PassKey authentication, and Merkle tree management. Because Vault code runs directly inside the HSM, protecting its integrity is essential for the overall security of the custody platform.

To prevent arbitrary or malicious code from being loaded into the device, the HSM enforces mandatory code signing at the hardware level. Every firmware extension must be signed with a trusted signing key that resides inside the HSM itself. Unsigned or improperly signed code is automatically rejected, ensuring that only verified and authorized binaries can execute within the secure boundary.

The code signing process for Vault is conducted as part of an official HSM ceremony. During this ceremony, the compiled Rust-based Vault code is presented to the HSM, which generates and applies its internal signature. A Crypto Officer must authorize this action by presenting their physical USB security key, providing multi-factor proof that the operation is intentional and approved.

Once the Vault extension has been signed, loading it into the HSM requires an additional level of authorization. A Security Officer must approve the load operation, ensuring that no code, even if properly signed, is introduced into the device without explicit administrative oversight. This dual-control mechanism enforces separation of duties: Crypto Officer authorizes the signing of code, while Security Officer authorizes its deployment.

Through this layered approach — hardware-enforced signatures, multi-factor ceremonies, and role-based approval — Secubit guarantees that only trusted, authenticated, and properly audited code can ever run inside its HSMs. This protects the integrity of the Vault and maintains the HSM as a tamper-resistant root of trust for the entire custody system.

Appendix

The appendix collects supporting material and comparative discussions that complement the main body of this whitepaper. While the core chapters focus on Secubit’s architecture, threat model, and workflows, the appendix provides space for exploring related technologies, alternatives, and background topics.

HSM vs Intel SGX

When evaluating secure execution environments for custody, two common options are HSM (Hardware Security Modules) and Intel SGX (Software Guard Extensions). While both aim to protect sensitive operations, they differ fundamentally in architecture, threat surface, and assurance levels.

Intel SGX (Software Guard Extensions)

Intel SGX provides a Trusted Execution Environment (TEE) inside a general-purpose CPU. It separates trusted enclaves from untrusted host code, allowing sensitive logic to run in a protected memory region. However, the security of enclaves depends heavily on the CPU vendor and firmware supply chain, and vulnerabilities have been repeatedly demonstrated in public research.

• Shared hardware between trusted and untrusted zones
• Multiple high-profile attacks (e.g., sgx.fail) exploiting side-channels and speculative execution
• Relies on the CPU vendor for attestation infrastructure
• Still requires an HSM or other secure device for durable key storage and code signing
• Large attack surface due to integration with full CPU, OS, and driver stacks
• Difficult to audit because enclave code executes alongside complex general-purpose systems

SGX is powerful for certain workloads, but its shared environment and history of side-channel attacks limit its suitability as a root of trust for institutional-grade custody.

Hardware Security Module (HSM)

HSMs, in contrast, are dedicated cryptographic appliances purpose-built to generate, store, and use private keys inside a tamper-resistant boundary.

• Dedicated hardware with bank-grade security used for decades in payments and finance
• Only loads the minimal wallet-specific code (Vault) into the secure execution environment
• Smaller attack surface (Vault), easier to review and audit compared to full CPU/OS environments
• Integrated True Random Number Generator (TRNG) and standards-approved DRBGs
• Tamper-resistant key storage with zeroization on tamper events
• Strict access control with PKCS#11 interface
• Certified under FIPS 140-2/3 Level 3 for cryptographic assurance
• Built-in support for segregated roles and multi-factor authentication (USB tokens, PIN pads)
• Physical and logical protections hardened specifically against key exfiltration

Because HSMs are standalone devices with narrow functionality, they reduce complexity and remove reliance on untrusted host environments. They enforce cryptographic boundaries at the hardware level and are easier to certify, monitor, and operate in regulated financial environments.

Comparison Summary

Intel SGX offers enclave-based isolation but remains vulnerable to side-channel attacks and still depends on HSMs for durable key storage. HSMs provide a hardened, certifiable, and auditable platform specifically designed to protect cryptographic material. For institutional custody, HSMs remain the gold standard as the root of trust, while TEEs like SGX are better suited for complementary tasks, not for custody keys.

HSM vs AWS Nitro Enclave

Another alternative secure execution environment is AWS Nitro Enclave, which provides isolation for workloads inside Amazon’s Nitro hypervisor architecture. Like Intel SGX, it represents a form of Trusted Execution Environment (TEE), but instead of being embedded in the CPU, it is implemented in the AWS cloud platform.

AWS Nitro Enclave

AWS Nitro Enclaves allow customers to launch a stripped-down virtual machine, often running a container, inside an isolated enclave. This enclave can run sensitive workloads without direct network access, reducing the risk of exposure. However, the enclave still runs on shared cloud infrastructure and inherits many of the complexities of the AWS ecosystem.

• TEE built on AWS Nitro hypervisor technology
• Enclaves typically run a Docker container image inside the isolated environment
• Still part of a shared hardware environment between trusted and untrusted zones
• Larger attack surface compared to a dedicated device, since code running in enclaves is customer-supplied and potentially complex
• Harder to review/audit, as enclave code may involve full Linux distributions or containers with large dependency trees
• Requires an HSM (CloudHSM or external device) for durable key storage and code signing
• Relies on AWS for the integrity of hypervisor isolation and enclave lifecycle management

Nitro Enclaves provide useful isolation for certain workloads, but as with SGX, they do not replace a dedicated cryptographic root of trust.

Hardware Security Module (HSM)

HSMs remain purpose-built, tamper-resistant devices designed specifically to protect keys and execute cryptographic operations.

• Dedicated hardware with bank-grade security
• Smaller attack surface (Vault), easier to review and audit compared to full Linux containers or hypervisors
• Integrated True Random Number Generator (TRNG) and FIPS-approved deterministic RNGs
• Tamper-resistant key storage with automatic zeroization on tamper events
• Strict access control exposed only through PKCS#11 interfaces
• Certified under FIPS 140-2/3 Level 3 and other international standards
• Hardware-enforced role separation and built-in MFA with USB tokens and PIN pads

Comparison Summary

AWS Nitro Enclaves provide useful isolation mechanisms within cloud infrastructure, especially for reducing the attack surface of sensitive workloads. However, they rely on complex hypervisors and container environments, making them harder to audit and less predictable than dedicated hardware. Just like SGX, Nitro Enclaves still require HSMs for secure key storage, code signing, and cryptographic assurance. For custody systems that demand bank-grade security and independently certifiable trust anchors, HSMs remain the superior foundation.