Storing of Bitcoin & other private keys in RDBMS

[thom88]

I am currently wondering, how an application can securely store a private key of a Bitcoin wallet or Ethereum address in a RDBMS (MySql, PostgresSQL, MSSQL, Oracle) database.


The application needs to handle hundreds of transactions micro to bigger ones in a day and must create addresses (wallets) including their private keys.

To send out automatically a transaction (Event driven), the system cannot rely on cold storage services such as BitGo that take hours to release a transaction and are very costly.

Currently, I would do it that the DB server has no Internet connection and can only be accessed from the API via local connection. However, if the API server is hacked and someone gets access to it (lets assume it happens), he can if he knows how extract the data from the DB, decrypt it (via api itself) and send funds to an address of his choice.

Don't get me wrong, i believe penetrating such a setup is not that easy and would be considered very secure, if it wouldn't be for millions of dollars saved in a relational database (literally).

I just can't think of a solution that has automatic and almost instant transaction generation and full security.

If someone knows his stuff, I would very appreciate some input.

[1714899793]

1714899793

[1714899793]

1714899793

[1714899793]

1714899793

[1714899793]

1714899793

[1714899793]

1714899793

[RocketSingh]

Similar stuff has been attempted before...

https://bitcointalk.org/index.php?topic=874266.0

[HeRetiK]

To be honest I don't think you'll be able to fully rid your service of an automated hot wallet / manual cold storage set up.

Problem being, even if the private keys are securely encrypted in a way that is not accessible by an adversary, as long as they are able to call an API that even just sends a transaction, your safeguards are down. Even automating cold storage can be tricky. I remember there was a site (an exchange or a casino, I can't recall) that automatically moved coins out of cold storage to its hot wallet once the hot wallet reached a certain threshold, only to have its cold storage emptied by an attacker emptying the hot wallet (which got automatically replenished whenever the attacker had emptied the hot wallet). Put differently, keeping the private keys safe is just one part of the equation.

That's just my 2 sats though, maybe someone else has a suggestion that could actually help you with your problem.

[mocacinno]

I've attempted simular stuff in the past.. I used a combination of pgp encryption, aes_encrypt and encrypted bsd partitions on a mysql server that was only accesible over a local vlan... However, in case of a hot wallet, there is no 100% secure setup.

But in my setup, somebody with access to the frontend server could not decrypt the private keys because they were pgp encrypted, and the pgp private key wasn't stored on the frontend. The aes pass wasn't stored on the mysql server, tech guys from the hosting firm did't have my root pwd, and if they would have rebooted my machine to reset the root pwd, they would have been faced with an encrypted disk... However, my weak point was the server where the core wallet was stored since it had to have access to the private keys in order to handle outgoing payments so it needed to be on the same vlan as the mysql server with one interface, and it needed both the pgp pk and the aes password

[nothreat]

I have done this myself using BIP39 HD Wallets.
I wrote the code in C# using SQL Server for the database.

It was very hard work as most of what is out there uses non-enterprise level code such as JavaScript, GO or PHP.
Any databases they used were open source and had no consideration for security or scale.

SQL Server has built in always on encryption with enterprise level security, so a good foundation.
The way you build your API can restrict access to only the accounts that they need to access so I do not see this as an issue as far as system wide security goes.
It is only a risk to the funds of the developer holding the API key so it becomes their responsibility to look after their own keys.

Hope this gives you some clues as to where to start but HD Wallets are the future for this type of application.

[thom88]

I've attempted simular stuff in the past.. I used a combination of pgp encryption, aes_encrypt and encrypted bsd partitions on a mysql server that was only accesible over a local vlan... However, in case of a hot wallet, there is no 100% secure setup.

But in my setup, somebody with access to the frontend server could not decrypt the private keys because they were pgp encrypted, and the pgp private key wasn't stored on the frontend. The aes pass wasn't stored on the mysql server, tech guys from the hosting firm did't have my root pwd, and if they would have rebooted my machine to reset the root pwd, they would have been faced with an encrypted disk... However, my weak point was the server where the core wallet was stored since it had to have access to the private keys in order to handle outgoing payments so it needed to be on the same vlan as the mysql server with one interface, and it needed both the pgp pk and the aes password

I am having the same concept but the weak spot will be the API server who knows the private key for decrypting the bitcoin private key.

when i read about the latest and biggest hacks, actually most of them started with infected hardware from an admin. i think maybe protecting the server is one thing (offline, whitelist IP access, no SSH access to DB and Web application firewall) but for example bitstamp, all of this would not have helped as far as i know.

multi sig is the solution, yes, but when 1 server is compromised, most likely the others are too.