Bitcoin Forum
June 25, 2024, 05:02:19 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: "Bitcoin Security Module": Adding hardware security for hot wallets  (Read 5325 times)
DeathAndTaxes (OP)
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1079


Gerald Davis


View Profile
May 27, 2012, 01:49:31 AM
Last edit: May 27, 2012, 02:21:19 AM by DeathAndTaxes
 #21

I think robberies would be solved really easy if a bitcoin developer is willing to dedicate some time to it. Writing a patch that implements a set of custom rules in bitcoind that any merchant can configure when compiling the daemon could render hotwallet wallet hacks a thing of the past. Some rule examples: allowed coin amount per tx, e-mail warning of the wallet coins level.

I remind you that we already have private key protection implemented at the lowest level with the wallet encryption. Unlocking the wallet when needed is done by the online platform on the same rpc channel. The passwords used for connecting to rpc and for unlocking the wallet can be obfuscated within a compiled binary on the same server as the app.

Why use expensive and dedicated hardware when all that's needed is a little brainstorming ?

While that would be better (anything would be better) it wouldn't provide much protection from an informed theif. I do agree it would prevent the smash & grab type robberies but nothing more sophisticated.  If the attack has root/admin access to the server then any software level protections would be rendered inert.

For example no "alert emails" would go out because a good thief would stop all outbound communication.  If an application on the server can unlock the wallet so can a good attacker.   Also when the wallet is decrypted for legit transactions it is loaded into memory.  An attacker with root access can recover can recovery the decrypted wallet from memory even if he never gets the encryption key.

Likewise any code which relies on the host (under the control of the attacker) to validate tx is doomed.  The attacker has control of the system clock and can use that to bypass any protections.

Essentially one must assume that one that attacker has control over the host that any and all protection systems of that host are disabled.  The goal then it to have protection systems which don't rely on the compromised host, which operate from a security perspective that the host may be at any time compromised.

Essentially trust still comes down to the assumption that the thief won't gain root/admin access to the server.  I guess it all depends on what you are protecting.  I would imagine if the Bitcoinica team could have gone back in time before the first robbery and installed a HSM/BSM they would have gladly done so. Smiley
sebastian
Full Member
***
Offline Offline

Activity: 129
Merit: 118


View Profile
May 27, 2012, 11:32:49 AM
 #22

aha now I understand.
But you talked about having some "bypass" or "override" of the builtin rules.

What about a physical button that needs to be held down? So if you are going to do a tx that would violate the BSM rules, you have to be physically present at the BSM and hold down the button while doing the tx, and then release button. And of course it would only allow one tx per button press.
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!