I'm working on a centralized exchange for cryptocurrencies. the approach that I'm taking for some reasons is to create an account(private key) per user inside platform. so these accounts should be controlled by platform. now my problem is how to safely store private keys in server and then safely retrieve them for signing transactions. since I'm using a VPS, it's not possible to use HSM or any other hardware-based solutions.

the approach I'm thinking about for securing private keys is this: for each user when he creates his account, app will generate a private key and encrypt that private key using his password. now if a user wants to transfer cryptocurrency from his inside platform account to his external account, in addition to his external account address, he also have to provide his password and app uses that password to decrypt his internal account's private key and sign the transaction using it.

so even if my database compromises, the attacker cant use private keys since they are encrypted and he cant use password to decrypt them since passwords are hashed.

now I wanna know that is there any problem with this approach that I dont see?

edit- also I'm gonna keep an offline backup of private keys in which passwords are not encrypted. so forget password option gonna be a bit manual. anytime a user forget his password, an admin will find user's private key in backup file and generate a new password and update the database using this new password and user's private key and after that email password to user.
thanks in advance.

  • 4
    The fact that you don't know how to handle these things means you shouldn't be building a platform in which the money of people depends on you getting these things right.
    – user163495
    Commented Nov 16, 2020 at 20:58
  • First you must learn how a crypto exchange works. Before that, it's an useless exercise. You don't store users' private keys, you store the exchange private keys, offline, and most of the funds are on cold storage. Users' password unlocks their account, not the private keys.
    – ThoriumBR
    Commented Nov 16, 2020 at 21:54
  • The best practice in order would be a) not store user private keys b) store them in a HSM so not even you can export them c) ... nevermind Stick to a) or b)
    – eckes
    Commented Nov 17, 2020 at 4:05

2 Answers 2


Couple observations:

he also have to provide his password and I'm gonna use his password to decrypt his private key and sign the transaction using it

not soure what exactly this means, but you shouldn't use user's private key. Transaction signing should be done in client context (user memory). User shall not delegate signing to shared process or send private key anywhere outside.

Since private key is decrypted in memory (even for short time frame), it is in memory in clear text, so password can be extracted from there. This is a common issue for any kind of software-based systems. HSMs do key extraction and key operation in tamper-evident zone. This is main purpose of HSM.

In fact, certain Windows components implement this (such as EFS, for example). Private key is encrypted with user password, so even systems administrator cannot extract the key unless they know password.

And there is one problem: password management. If user lose their password, encryption key is lost as well. If password is reset, the key is lost. Windows correctly handles standard password changes using windows security dialog, where user types current password and provide a new one. In this case, Windows automatically re-encrypt required keys with new password and everything is transparent to the user.


an update to your edits:

offline backups aren't different than online backups in terms of security. Therefore offline backup shall include private keys and passwords only in encrypted form. Suggested pasword management solution is way too far from acceptable (considering this is a platform that does financial transactions).

Such cases are solved in different way: you designate a group of persons as key recovery agants (KRA) and store their public keys somewhere on a system. Once the private key is generated, it is automatically encrypted using public keys of recovery agents. In the case if user loses their access to the key, it can be recovered by providing a quorum of recovery agents. Key recovery agents shall not have access to encrypted private key database. These should be different persons. One person group manages the encrypted private key database and another group owns key recovery certificates.

As of HSMs, there are network-attached HSMs (nCipher nShield, SafeNet Luna and others. You can use them on VPS over network. Alternatively, there are cloud-based HSMs.

  • thanks for answering. I think I need to make some clarifications. "User shall not send private key anywhere outside" private keys that I'm talking about belongs to users inside platform accounts and even users do not have access to those private keys. "Since private key is decrypted in memory (even for short time frame), it is in memory in clear text", because I'm using vps, I cant use any hardware-based solution. now is there any better software-based solution? "And there is one problem" actually I have a solution for this. I forgot to mention it. I'm gonna edit the question
    – omid
    Commented Nov 16, 2020 at 21:05
  • see updated response.
    – Crypt32
    Commented Nov 16, 2020 at 21:56

Don't try to learn data security by building a crypto exchange. It's like learning how to make a boat by creating a cruise ship. Or learn Physics starting with Quantum Chromodynamics.

Try a secure file storage first. Or a secure messaging platform. Or a secure emoji election. Simpler things, no financial damage if done wrong, no massive lawsuits, no need to flee from your country.

In a crypto exchange, the users don't have private keys, they have passwords for their accounts, like an email, or bank account. Think of a bank: the users usually don't have a private safe inside the bank, only the bank have one. Users have their funds stored on the bank database, and the bank is the owner of all the money. Regulations aside, the bank is the real owner of the money.

When users want to transfer their funds to another wallet, you is the one making the transfer in your own name. You can have a wallet for every user, but you are the owner of the wallet. Users will either don't care about the private keys (the vast majority of users), or will never ever trust you their private keys. There won't be much users not on those groups: ones savvy enough to have their own private keys in hand and willing to give you access to their key.

Crypto stored on your exchange will not be on a hot wallet, but a cold one. The hot, online wallet will only cover the day to day withdraws, and all the funds should stay offline. In the case of a wallet theft, you don't lose everything.

You don't want to have only one cold storage either. Losing access to it would lose access to all the funds, and that will be catastrophic. You will rather have several cold wallets, and keep them balanced. And the private keys should be stored in a way that in the even of the death of the owner, someone could access the funds. This is usually called Break Glass Procedure, and it's a safeguard against losing access forever in case of a disaster.

It should be tested before a disaster, and be implemented in a way that's not possible to use the emergency passwords undetected, and require more than one user. It could involve, for example, the Shamir's Secret Sharing scheme for half of the private key, and a printout stored on a tamper-evident container stored on a bank safe with an access ledger (or the owner will, safe with his attorney). In the case of disaster, a couple of high rank employees would get together to have half the key, and get the other half on storage.

Backing up private keys are usually a bad idea. They are the only protection against the total loss of funds, so the backup would have to be protected as much as the private key itself. And you will not want to use a VPS for hosting a crypto exchange. You will either have your own datacenter, or at minimum a co-location of your own custom server chassis with tamper proof sensors and automated data destruction in case of tampering.

  • thanks for answering. it was helpful
    – omid
    Commented Nov 16, 2020 at 23:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .