Bitcoin Forum
December 05, 2022, 02:24:36 PM *
News: Reminder: do not keep your money in online accounts
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Private keys in RAM  (Read 1221 times)
mmeijeri (OP)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500

Martijn Meijering


View Profile
April 09, 2014, 09:43:01 AM
 #1

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'.
Once a transaction has 6 confirmations, it is extremely unlikely that an attacker without at least 50% of the network's computation power would be able to reverse it.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1670250276
Hero Member
*
Offline Offline

Posts: 1670250276

View Profile Personal Message (Offline)

Ignore
1670250276
Reply with quote  #2

1670250276
Report to moderator
1670250276
Hero Member
*
Offline Offline

Posts: 1670250276

View Profile Personal Message (Offline)

Ignore
1670250276
Reply with quote  #2

1670250276
Report to moderator
mmeijeri (OP)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500

Martijn Meijering


View Profile
April 09, 2014, 12:43:17 PM
 #2

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 Offline

Activity: 2618
Merit: 1006


View Profile
April 10, 2014, 08:19:56 AM
 #3

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.

https://www.coinlend.org <-- automated lending at various exchanges.
https://www.bitfinex.com <-- Trade BTC for other currencies and vice versa.
wumpus
Hero Member
*****
qt
Offline Offline

Activity: 812
Merit: 1015

No Maps for These Territories


View Profile
April 10, 2014, 09:34:31 AM
 #4

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 FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
Sukrim
Legendary
*
Offline Offline

Activity: 2618
Merit: 1006


View Profile
April 10, 2014, 09:38:10 AM
 #5

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.

https://www.coinlend.org <-- automated lending at various exchanges.
https://www.bitfinex.com <-- Trade BTC for other currencies and vice versa.
wumpus
Hero Member
*****
qt
Offline Offline

Activity: 812
Merit: 1015

No Maps for These Territories


View Profile
April 10, 2014, 09:40:41 AM
 #6

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 FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
mmeijeri (OP)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500

Martijn Meijering


View Profile
April 12, 2014, 12:36:55 PM
 #7

Interesting OpenSSL patch by Akamai related to this, via @csoandy on Twitter:

http://marc.info/?l=openssl-users&m=139723710923076&w=2

ROI is not a verb, the term you're looking for is 'to break even'.
oakpacific
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


View Profile
April 13, 2014, 09:47:55 AM
 #8

Would it be easier to just make sure your signed tx always get on the chain first?

https://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
chen18127
Member
**
Offline Offline

Activity: 60
Merit: 10


View Profile
April 13, 2014, 10:35:59 AM
 #9

make it faster is the most improtant thing
noviapriani
Sr. Member
****
Offline Offline

Activity: 350
Merit: 250


View Profile
April 23, 2014, 09:28:31 AM
 #10

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)
Hero Member
*****
Offline Offline

Activity: 714
Merit: 500

Martijn Meijering


View Profile
April 23, 2014, 10:15:48 AM
 #11

Interesting OpenSSL patch by Akamai related to this, via @csoandy on Twitter:

http://marc.info/?l=openssl-users&m=139723710923076&w=2

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 Offline

Activity: 3
Merit: 0


View Profile
April 23, 2014, 11:11:04 AM
 #12

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.
Pages: [1]
  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!