Topic: "Bitcoin Security Module": Adding hardware security for hot wallets - page 2. (Read 5364 times)

I'm no cryptographer but I seem to remember that algorithms exist to split an encryption key such that N of M fragments must be used to form a valid signature.

Could such a system be used to create a separate verification system on a physically different computer (without requiring special hardware) so that even if the computer storing the hot wallet is compromised it can't generate transactions by itself?

Bitcoinica didn't need to happen and yet it did twice.  Hot wallets are a necessity in some applications yet the nature of Bitcoin means any security breach now matter how rare puts the full value of the wallet at risk.  Since knowledge of the private key is control of the funds the only safe hot wallet is one where gaining access to the tx server doesn't give one the ability to access the private key.  This means keeping keys even from admins or super-admins.

I am building a hardware based solution around a programmable cryptographic processor.  The cost is in the hundreds of dollars but still significantly cheaper than a an off the shelf HSM.  Bitcoin presents some unique challenges for a HSM.  Simply keeping the key a secret until needed isn't sufficient.  The hardware module needs to sign transactions while never revealing the key. 

At this point the prototype can only sign a (2 output only) tx based on a single internally stored private key.  At this point the prototype wouldn't provide any real security.  While the attacker couldn't gain access to the private key he could just request an unlimited number of signed tx.  The full solution would be to allow programming the device with business rules which limit the type, value, and frequency of the transactions.

The hardware has both volatile and non-volatile storage so keys can either held in volatile memory only (and need to be reloaded loaded upon power cycle) or can stored in non-volatile encrypted storage to allow keys to survive power cycle.  An independent hardware timer allows the module to keep track of time which can't be spoofed by the attacker but will require secure timestamp to be provided at initialization (most likely from NTP server).

Constraints on the available memory prevent creating an entire bitcoin client so the module will need to rely on a host client for transaction setup, initialization, and connectivity to the bitcoin network.

Current capabilities:
* prevent extraction of a single private key once loaded
* sign dual output tx (where change is returned to same address)

Planned capabilities:
* limits on tx size and volume
* lock-down mode based on threat detection rules (client asking for tx which violate rules)
* delayed tx signing based on business rules (module returns tx encrypted w/ AES-256 which client will request decryption after "cooldown" time has elapsed)
* intrusion notification
* random write-erase-write cycle to ensure key destruction