Secure Private Key Management for DApps

Why does private key require more than you have done so far?

Private key compromise has become the most significant attack vector this year so far and is responsible for the greatest financial damage. The likelihood that you will be hacked due to your negligence in operational security is ~74% according to data presented by @_iphelix during DSS2024.

Watch Peter's full presentation here.

The Most Important Rules for Safe Use of Private Keys

• Compromise or loss of access to a single private key should never impact the project and users.
• A single private key should not allow anyone to perform any important business operations (except temporary pause used in emergency).
• You must generate your key and never share it.
• Consider recovery options in case of losing the ability to obtain the majority required to execute transactions (e.g., by placing a spare access in a vault only available after legally meeting certain conditions).
• For multi-sig solutions (whether MPC or smart contract-based), use at least (2 of 3) or (3 of 5) with additional MFA for each signer (e.g., PIN for hardware wallets).
• A private key exposed even for a moment should be considered compromised, and a new one should be generated.

Who Should Generate the Private Key?

Each entity managing or being part of a privileged role in a smart contract should have its own key generated separately by itself.

How to Generate the Private Key

Preferred Option:

Buy an original hardware wallet from the official website and use the private key stored in a secure element chip, isolated from internet-connected devices.

Alternative Option:

If PC is adequately protected, consider software solutions to generate keys that utilize high entropy (ideally on a different account on the computer or on another computer dedicated for the project):

• Seed phrase-based keys (e.g., a wallet application running in an isolated browser profile).
• Raw keys (without seed phrase) (e.g., using OpenSSL: openssl ecparam -name secp256k1 -genkey -noout).

Backup the Key

• Keep the private key encrypted in a safe place. For example, a keystore file and password manager file kept on a physical drive in a physically safe place.
• Go through recovery from backup at least once to ensure everything works as it should.
• Regularly check whether you have access to the key. In case of a physical drive, regularly try to read it to make sure the drive works.

Who Should Be Considered For a Multi-Sig?

• Key stakeholders: This includes, e.g., the C-level employees.
• Technical leads: This includes team member(s) that know how the project and signing procedure works and can coordinate the signing process.
• Dedicated security personnel: If you have an internal security department or external committee, consider adding a representative from their side to ensure that every operation is reviewed for security.
• Backup with legally secured access: Only in the event of a disaster preventing the required project management thresholds from being met, a special backup should be available to regain control and appoint new members.

Who Should Have Access to the Private Key?

ONLY key owners, who should be highly trusted individuals being part of the multi-sig or managing a trusted role.

How to Share the Private Key?

NEVER share the private key.

Where to Store the Private Key?

Preferred:

• Hardware wallet in a safe: Remember not to keep keys in the same place; store each of them in different locations.

• Utilize hardware security modules (HSMs) like:

  • AWS CloudHSM
    • Best Practices for AWS CloudHSM
  • Azure Dedicated HSM
    • Azure Security Baseline for Key Vault - Managed HSM
  • Google Cloud HSM
    • Google Cloud HSM Documentation

• Utilize key management services like:

  • AWS Key Management Service (Easy integration with Foundry)
    • Best Practices for AWS KMS
  • Azure Key Vault
    • Azure Key Vault Best Practices
  • Google Cloud KMS
    • Google Cloud KMS Security

At Least:

Store the key in a software wallet in an isolated browser profile, ideally on a separate account. Consider using a separate device that is never used for non-project operations (e.g., airdrop claims!).

How to Use a Private Key for Deployment

• DO NOT ASSIGN ANY PRIVILEGED ROLE TO THE DEPLOYER ADDRESS IF THE KEY WAS NOT SECURELY STORED.
• Deployment keys are not critical and can even be single-use.
• The keys managing addresses assigned to privileged roles (e.g., Owner) are of utmost importance and should be controlled by multi-sigs or DAOs.
• Assign the correct addresses to the privileged roles immediately during deployment and keep their private keys secure.
• Use separate keys to deploy on test environments and during the main launch.

Foundry

• Use wallet options for hardware wallets:
  • --trezor to use a Trezor hardware wallet
  • --ledger to use a Ledger hardware wallet
• Use wallet options for remote:
  • --aws to use AWS Key Management Service

Hardhat

• Use official plugins for hardware wallets:
  • For Ledger: hardhat-ledger
  In both cases, the .env file can be used; however, preferably addresses from this private key should not have any privileged role assigned.

How to Use Private Keys for Management and Upgrades

• Use multi-sig solutions (e.g., Safe) where each signer has their own private key securely stored on a hardware wallet or in other secure locations as mentioned in the Where to Store the Private Key section.

• For emergency operations that need to be executed instantly in some cases (e.g., pausing during a hack) consider:

  • Adding a required role also to some EOA address controlled by the emergency application (allowing to quickly execute operations by anyone with access to the application - the red alarm button).
  • Collecting signatures from all multi-sig entities and storing them in the emergency application (allowing to quickly prepare and execute multi-sig operation by anyone with access to the application - the red alarm button).

• For software solutions:

  • Use a separate profile on your PC designated for such operations.
  • Use a separate and clean browser profile designated for such operations.

Secure Private Key Management Checklist for DApps

Want to increase the security of your project?

Composable Security 🛡️⛓️ is an elite team of 2 experienced Security Researchers who specialize in (re)staking, AVS and UniswapV4 projects.

Uniswap Foundation grant recipient. Creators of the Smart Contract Security Verification Standard and the first Security Guide for DApps CTOs, Lead Developers, and Security Enthusiasts.

• Ready to increase your security? Let us help you!

Have peace of mind like: RedStone, Braintrust, Enjin, Tellor, and many more.