|
mmeijeri (OP)
|
 |
April 09, 2014, 09:43:01 AM |
|
After the heartbleed scare I've been thinking if perhaps we shouldn't make an effort to store private keys more securely. This isn't a new issue of course, and there are lots of existing techniques and best practices I'm only dimly aware of, including things like PKCS #11 and HSMs. I know work is also being done on Bitcoin-specific hardware solutions like Trezor.
Maybe we all need to move to hardware-based solutions in the future, but maybe there is also room for software-only solutions. Right now most people don't use specialised crypto hardware, and I was wondering if it would help if signing operations were at least located in a separate process with an independent address space. There is a library called SoftHSM which is a software-only implementation of PKCS #11. I think it's supposed to be linked directly to the application, but maybe it can be used as a starting point.
So, what do you think? Would this be a useful near-term improvement, or an undesirable half solution that discourages people from using dedicated hardware, if we believe that's the real solution?
|
ROI is not a verb, the term you're looking for is 'to break even'.
|
|
|
|
|
|
|
|
|
|
Every time a block is mined, a certain amount of BTC (called the
subsidy) is created out of thin air and given to the miner. The
subsidy halves every four years and will reach 0 in about 130 years.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
|
mmeijeri (OP)
|
|
April 09, 2014, 12:43:17 PM |
|
Well, that too of course, but 2/3 of the web was vulnerable to this one, whether they updated regularly or not. Layered defence is good.
|
ROI is not a verb, the term you're looking for is 'to break even'.
|
|
|
Sukrim
Legendary
 Offline
Activity: 2618
Merit: 1006
|
|
April 10, 2014, 08:19:56 AM |
|
The real solution is simply to not get malware and update often, IMO.
If you did NOT update to OpenSSL 1.0.1 (thus updating rarely/late) you were not hit by heartbleed... You might be exposed to other (less severe) security issues that way though. |
|
|
|
|
wumpus
|
|
April 10, 2014, 09:34:31 AM |
|
For operating systems that support a secure execution environment it'd make sense to move generating/encrypting/decrypting private keys and signing there. I'm not sure how useable this is in practice at this point. This could use TPM or HSMs if available.
And AFAIK some of the Android wallets use the OS-specific secure key storage for wallet keys.
Moving those operations to a separate, isolated process would already be a start. There are certainly baby steps to be made.
|
Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts. |
|
|
Sukrim
Legendary
Offline
Activity: 2618
Merit: 1006
|
|
April 10, 2014, 09:38:10 AM |
|
Private keys anyways should be in RAM only for a few fractions of a second: read them from HDD, decrypt them, sign whatever you need to sign (message, transaction...), zero them out again and done.
|
|
|
|
|
wumpus
|
|
April 10, 2014, 09:40:41 AM |
|
Private keys anyways should be in RAM only for a few fractions of a second: read them from HDD, decrypt them, sign whatever you need to sign (message, transaction...), zero them out again and done.
With the Bitcoin Core wallet this is already the case. The encrypted keys are stored in RAM, but they are only decrypted when necessary and zeroed afterwards (given that you use wallet encryption, of course). The memory used for storing keys is also locked, to avoid it from being swapped to disk. |
Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through File → Backup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts. |
|
|
|
|
|
oakpacific
|
|
April 13, 2014, 09:47:55 AM |
|
Would it be easier to just make sure your signed tx always get on the chain first?
|
|
|
|
chen18127
Member
Offline
Activity: 60
Merit: 10
|
|
April 13, 2014, 10:35:59 AM |
|
make it faster is the most improtant thing
|
|
|
|
|
|
noviapriani
|
|
April 23, 2014, 09:28:31 AM |
|
It's entirely possible that either a program with necessary privilege to read the memory location holding the key, or hardware utilizing DMA, can grab a private key from RAM.
|
|
|
|
|
mmeijeri (OP)
|
|
April 23, 2014, 10:15:48 AM |
|
Turns out this patch doesn't work at all, several experts panned it. |
ROI is not a verb, the term you're looking for is 'to break even'.
|
|
|
jd_grinder
Newbie
Offline
Activity: 3
Merit: 0
|
|
April 23, 2014, 11:11:04 AM |
|
my 2c. if possible use a physical storage device like a SAM module or in case of servers an HSM. storing in ram makes them vulnerable. Keyloggers and ramscrapers are just the tip of the iceberg.
|
|
|
|
|
|
