Back to all stories
Highlighted Stories
Technical Blogs
Technical Insights
Private Key, Public Risk
6/22/2025
Private Key, Public Risk

Introduction

In the Web3 world, our project’s most valuable assets, such as tokens, governance powers, and user trust, often hinge on a single point of failure: the private key.

Private keys are the cryptographic backbone of your blockchain infrastructure. They prove the ownership of a wallet address and control over assets through signing transactions with the private keys, for example, transferring tokens, authorizing smart contract upgrades, signing cross-chain transactions, and controlling treasury wallets.

Yet despite their critical role, private keys are often mismanaged, left in plaintext, stored in unsecured environments, encrypted insecurely, derived from low entropy, or controlled by a single individual. This makes them prime targets for attackers and a leading cause of catastrophic breaches across the industry.

As a project manager, you may not interact with private keys directly, but the consequences of a compromised key fall squarely on your shoulders, from operational disruptions to financial loss and reputational damage. Understanding the risks and ensuring proper key management practices are in place is not just a technical concern. It’s a business imperative.

While we've already introduced the concept of private keys and the risks of centralization in two of our previous blogs, this post takes it a step further. We'll dive deeper into the security considerations around private key generation, storage, usage, and why getting each of these stages right is critical to protecting your Web3 projects. Let's start with how a private key can be generated.

Private Key Generation

Private key generation is the foundational step in any blockchain system, and it's one of the most overlooked yet critical components of overall security. Broadly, key generation can be performed through software-based methods or by using dedicated Hardware Security Modules (HSMs).

Securely generating a private key relies on several pivotal factors:

  • The source of randomness and entropy
  • The algorithm used to generate the private key
  • The implementation and integration of the algorithm.

Most software-based key generators rely on Pseudorandom Number Generators (PRNGs). While convenient, PRNGs are vulnerable if improperly seeded or implemented, and often lack sufficient entropy, particularly in constrained or misconfigured environments. For attackers with enough resources or insider knowledge, these flaws can be exploited to predict or reconstruct private keys. One notable example is the vulnerability in Profanity of 2022. Profanity is a vanity-address generator that uses a 32-bit seed and expands it into a 256-bit private key. Because there are only 2^32 possible initial key pairs and each iteration is reversible, attackers could recover any Profanity-generated private key from its corresponding public key. In September 2022, this flaw was exploited against multiple users, most strikingly Wintermute, which suffered a $160 million loss. For more information about the exploit, please check our previous article here.

This is why the gold standard for key generation relies on specialized hardware. A Hardware Security Module (HSM), a tamper-resistant appliance, is purpose-built for this task. Certified HSMs (e.g., FIPS 140-3) provide verifiable assurance through features like:

  • True Random Number Generators (TRNGs): Unlike software PRNGs, TRNGs derive entropy from physical phenomena, producing genuinely unpredictable and high-quality randomness. This ensures that newly created keys are impossible to guess or computationally derive.

The process of using this hardware is often formalized in a Key Generation Ceremony, a scripted and audited procedure where multiple trusted individuals convene to create the organization's root keys within the secure boundary of the HSM. This eliminates single points of failure from the very inception of the keys.

For teams without access to on-premise HSMs, leading cloud providers (such as AWS CloudHSM, GCP Cloud HSM, and Azure Managed HSM) offer HSM-backed services. These platforms provide scalable, compliant, and secure environments for key management, with API access and integration into modern DevOps workflows.

Private Key Storage

Once a private key is securely generated, it must be stored in a highly controlled and tamper-resistant environment. The core principle of secure storage is isolation. The key material should never be exposed in plaintext to any human, operating system, or application outside a trusted execution boundary.

Storage-Related Security Pitfalls in Web3 Apps

Centralization Risks in Key Management

Many dApps claim decentralization but rely on centralized servers to store or manage users' private keys, creating a single point of failure. If the backend is compromised, all user assets become vulnerable. During a penetration test, we found that some bridge apps use a centralized backend to handle the private key for contract withdrawals. If this key isn’t securely stored, attackers can execute unauthorized withdrawals and drain funds. We also saw wallets poorly designed to send encrypted private keys to the backend with weak encryption. A compromised backend puts users at risk. Additionally, some companies even skip proper network penetration tests, allowing attackers to move laterally within their network to access backend private keys. This vulnerability remains one of the most critical issues we encounter.

Weak Encryption Practices and Lack of Transparency

Encryption is a major vulnerability for many applications. While some claim to use strong standards like AES-GCM or 256-bit encryption, we have also seen some bots promote themselves as using highly secure double encryption, which in reality offers little actual protection. This raises doubts about developers’ understanding of secure key storage and adherence to best practices. Besides, we have also seen weak encryption choices like MD5 hashing and ECB mode for private keys. Despite this being well-known weak encryption, developers still use these insecure methods.

Insecure Storage Practices

Storing sensitive data like access tokens, encryption keys, or mnemonics in unsecured places such as local storage or unencrypted app preferences makes them easily accessible to attackers with physical or remote access to a user’s device. If the device is rooted or jailbroken, this risk becomes even greater, as attackers can bypass many of the built-in security protections. Without encryption or proper sandboxing, attackers can steal these credentials to compromise the entire account.

Secure Key Storage: A Practical Remediation Plan

To reduce risk and align with industry best practices, we recommend a layered and resilient storage architecture:

Isolated Local Storage on User Devices

To prevent exposure of private keys in logs, memory, or insecure environments, keys should be stored locally on user devices using secure storage like Apple’s Secure Enclave, Trusted Execution Environments (TEEs), or encrypted OS-level keychains. These isolate keys from the main app, protecting them even if the device is compromised. For devices lacking advanced hardware security, fallback to encrypted storage options such as Android’s Keystore, encrypted SharedPreferences, or iOS Keychain is recommended.

Hardware Security Modules (HSMs)

Software-based storage is inherently vulnerable. If the host system is compromised, an attacker can steal the encrypted key file to launch offline brute-force attacks or use keyloggers to capture the decryption password. An HSM solves this problem with its isolated design.

  • Complete Key Isolation: Keys are stored and processed within the HSM's fortified boundary and can never be exported in plaintext. All cryptographic operations (like signing) occur inside the module. The outside world can request an operation, but it can never access the key itself.
  • Physical and Logical Tamper Controls: HSMs are designed to be "tamper-resistant." If an attacker attempts to physically breach the device (e.g., by drilling or opening the casing), the HSM will detect the intrusion and automatically erase its critical key material, rendering it useless.
  • Modern Accessibility: This level of security is no longer limited to on-premise data centers. Leading cloud providers now offer HSM-backed services (e.g., AWS CloudHSM, GCP Cloud HSM, Azure Managed HSM), making institutional-grade key storage accessible to a wider range of organizations.

By using certified HSMs for storage, organizations maximize security versus software-only solutions and satisfy the stringent expectations of regulators and cyber-insurance underwriters.

Multi-Party Computation (MPC)

MPC splits private keys into encrypted shares stored across different locations, requiring multiple authenticators for recovery. This eliminates single points of failure and adds layers of security through multi-factor authentication (biometrics, KYC, secure links). Choosing well-audited MPC solutions that restrict private key export and enforce strong access controls is crucial for trust and asset protection.

Multi-Signature (Multisig) Wallets

Multisig wallets require multiple independent approvals for transactions, preventing unauthorized fund movements even if one key is compromised. By integrating multisig logic at the protocol or smart contract level, Web3 apps mitigate phishing, insider threats, and single-point failures.

Hardware Wallets for End-User Key Management

Hardware wallets keep private keys offline, enhancing security. Use multiple devices with distinct roles (e.g., separate wallets for daily use and multisig signing to isolate critical processes and reduce risk). Maintain backup hardware wallets securely to ensure recoverability from loss or damage. This structured approach balances convenience with robust asset protection.

Private Key Usage

Secure key generation and storage is only half the battle. Even with an HSM acting as your root of trust, the security of your digital assets ultimately depends on how private keys are used in practice. People, processes, and policy enforcement determine whether the system is resilient or dangerously exposed.

A secure key usage strategy includes well-defined operational procedures, clear access controls, and automated safeguards that minimize the chance of human error, insider abuse, or malware-based manipulation.

Even the strongest hardware can’t prevent poor decisions or procedural mistakes. A compromised operational process, such as a rushed withdrawal, an overlooked approval, or an unclear delegation of authority, can completely bypass the protections offered by HSMs or multisig setups.

This is why we recommend that every team conduct an Operational Integrity Assessment, which evaluates how the private keys are actually used in day-to-day operations. The goal is to surface weak links in transaction flows, access management, policy enforcement, and human factors.

Best Practices for Transaction Signing

Signing a transaction is the most sensitive moment in the life cycle of a private key. It’s when real value is placed at risk. The signing process must be designed to verify both authenticity and intent while protecting against compromise. Key best practices include:

  • M-of-N Quorum Systems: Use threshold signature schemes (TSS) or multisig wallets to avoid single points of failure. No single person should have unilateral signing authority for critical transactions.
  • Automated Policy Enforcement: Augment signing flows with pre-defined policies enforced by smart contracts or off-chain logic:
    • Address whitelisting to restrict where funds can be sent
    • Spending limits to cap the daily or per-transaction amount
    • Cooldown periods to delay large transactions and allow for human review or rollback
  • "What You See Is What You Sign" (WYSIWYS): The final transaction details must be verified on an independent, trusted channel that is isolated from the potentially compromised environment where the transaction was initiated. This ensures that the signer's approval applies to the genuine transaction, not a fraudulent one presented by malware.

Critical Operational Domains for Key Usage Security

Applying the principles above is essential, but they must be evaluated within the context of specific, high-risk operational areas. A thorough assessment focuses on the following domains.

  • Cold Storage Security and Management. It involves evaluating the physical security of the location where the hardware is stored, strict access control protocols for personnel, and documented procedures for the key generation ceremony. Furthermore, it assesses disaster recovery plans, ensuring that secure, encrypted backups of the keys exist and can be restored safely in a crisis.

  • Transfer Mechanisms between Storage Types. The process for moving funds between them is a critical control point. Assessments must scrutinize the security of the protocols used for refilling hot wallets from cold storage, ensuring these transfers are subject to the strictest M-of-N and policy controls to prevent unauthorized draining of the main reserve.

  • Deposit and Withdrawal Process Security. This assesses the end-to-end flow of funds into and out of the custody system. For deposits, it involves monitoring for suspicious patterns that could indicate money laundering or exploits. For withdrawals, it verifies that the entire security framework, from M-of-N approvals and policy checks to WYSIWYS validation, is rigorously and consistently applied to every single transaction, without exception.

How CertiK Can Help

CertiK delivers end-to-end security services that strengthen key management from generation and storage to day-to-day use. We have supported teams running public-facing dApps and large institutional custody platforms, and our work blends deep technical insight with clear, collaborative guidance.

Architecture Review and Threat Modeling

We analyze how a system’s parts interact, how trust is built between them, and where design assumptions create hidden risk. Key management is central to this review, covering how keys are generated, stored, isolated, and invoked during signing or approval flows. Threat modeling then maps realistic attack paths, showing where controls could fail under real-world pressure. Findings translate into practical design and process changes that fit the project’s scale and goals.

Penetration Testing

Our team simulates focused attacks against backend services, APIs, user interfaces, and supporting infrastructure to expose weaknesses in logic, access control, and configuration. Testing depth matches the access provided (black-box when little is known, white-box when full detail is shared) so results reflect plausible attacker capabilities. Each engagement ends with proof-backed issues and prioritized fixes that let engineering teams act quickly.

Operational Security Review

We examine how everyday workflows, devices, and people influence key safety. This includes access provisioning, device hygiene, communication practices, and incident-response readiness under stress. By linking technical safeguards to real operational habits, we uncover gaps that paperwork alone can miss and recommend changes that hold up over time.

Our engagements are designed to integrate security into the system’s lifecycle. Not just as a final step, but as a foundation for trustworthy development. Whether you're building a custody solution, managing user keys in production, or designing new wallet architecture, CertiK can help you assess risks, harden your system, and deploy with greater confidence.

Conclusion

Private key management isn’t just a backend detail. It’s the foundation of your project’s security and operational integrity. From generation to storage to day-to-day usage, each stage introduces risks that can be exploited if not properly addressed.

Whether you're securing a multi-chain bridge, managing a DAO treasury, or launching a new smart contract system, the cost of neglecting key management can be devastating. Fortunately, with the right strategy, tools, and security practices in place, these risks are manageable and preventable.

CertiK specializes in helping Web3 teams build resilient, secure systems that scale. From designing secure key ceremonies to auditing DevOps pipelines and implementing advanced key-sharing schemes like TSS or MPC, we partner with you to ensure your most critical assets remain secure at every stage.

Largest Blockchain Security Auditor
Ready to take the next step? Connect with our sales team to request your free quote and secure your project today!
Client Testimonials