Topic: Possible security issue in wallet.dat encryption (Read 1216 times)
This message was too old and has been purged
I doubt the highlight, if you extend the file with zeros, the file will remain in the same sector. Only deleting and rewriting should cause a rewrite to a different position.
Maybe I am getting it wrong, but that would be my thought.
Maybe I am getting it wrong, but that would be my thought.
You are getting it wrong. At the OS level it would be at the same logical sector but behind the scenes SSD continually reorganize data. This happens in every SSD and is due to two limitations of flash memory. The first is that you can't update a block. You have to erase it and write it again. You also can't update part of a block, changing a single bit requires retrieving the restor of the data in the block, erasing the entire block, and then writing the new block. The erase portion of the read-erase-write cycle is very long (relatively speaking). Performing an inline update would cripple performance (we are talking something like a 90%+ reduction in throughput). The second limitations of flash is it wear out and if updates were written to the same sector it would wear out some blocks prematurely.
SSDs overcome the first limitation by never updating blocks. So if you have data in block A and you update it what happens if the SSD will find a free zeroed block (say B) write the updated version to B and then mark A as unused. If you do a block by block analysis of your SSD right now there is huge amounts of blocks containing 'old' copies of your data. Only when the drive is unused will the SSD go back and like a garbage collector reset those blocks to all zero and mark them as available for reading. Because SSD can't perform an erase on less than a full block the data of one file may move even if it is never updated because a single bit in the data of another file in the same block is written.
SSD overcome the second limitation by tracking how often a particular block has been written to and trying to balance the number of writes per block so that no block is written to significantly more often than another. Once the write limit for a cell has been exceeded the cell will not reliably accept a change so the drive will mark it as permanently dead. This means capacity will shrink overtime but due to write leveling and over provisioning (a 256GB drive is actually >256GB of raw flash) this is hidden from the user.
SSD (and to a lesser extent even modern HDD) do not operate like the freshman college textbook model of how storage works. All this is hidden from the OS, as far as the OS is concerned the data never moves and it can always retrieve the stored data using the same logical sector. The SSD maintains a lookup table to keep the logical sector (location known to the OS) in sync with the current (and continually changing) raw location in the flash banks. In reality even this explanation is just a simplistic abstraction. In reality the situation is even more complex as performance is a huge driver of SSD sales. To get more performance out of a given raw flash spec modern SSDs are increasingly using more and more powerful controllers which perform all kinds of 'behind the scene' optimizations like writing in parallel across multiple chips, writing multiple copies (when free space is available), moving data to keep the flash banks balance and probably a lot more.
You really should consider an SSD a black box. You (the OS) can request to store data, retrieve previously stored data, and notify the black box when it no longer needs to store a previously stored data. Beyond that you should assume you have no idea what is actually written on the SSD at any given time. If this has made you paranoid most SSD include tools for doing a low level erase (write all blocks to all zeroes).
This message was too old and has been purged
This is the reason that setting the passphrase forces a shutdown. Bitcoin core completely rewrites the wallet and deletes the old file.
Especially with modern disks and file systems once data has _ever_ hit the disk you cannot be confident that it has been deleted-- e.g. _no_ SSD will do rewrite-in-place.
This is less of a big deal than you might expect because the keypool is all set to 'used' prior to encryption, so any address you retrieve from the wallet after enabling encryption will be born encrypted and will have never been on the disk unencrypted.
Especially with modern disks and file systems once data has _ever_ hit the disk you cannot be confident that it has been deleted-- e.g. _no_ SSD will do rewrite-in-place.
This is less of a big deal than you might expect because the keypool is all set to 'used' prior to encryption, so any address you retrieve from the wallet after enabling encryption will be born encrypted and will have never been on the disk unencrypted.
Why doesn't the bitcoind fill the old wallet with zeros before deleting it? You'd be safe for everything except fancy forensic magnetism leaking which is useless after some time using the disk.
highlight for you
This is the reason that setting the passphrase forces a shutdown. Bitcoin core completely rewrites the wallet and deletes the old file.
Especially with modern disks and file systems once data has _ever_ hit the disk you cannot be confident that it has been deleted-- e.g. _no_ SSD will do rewrite-in-place.
This is less of a big deal than you might expect because the keypool is all set to 'used' prior to encryption, so any address you retrieve from the wallet after enabling encryption will be born encrypted and will have never been on the disk unencrypted.
Especially with modern disks and file systems once data has _ever_ hit the disk you cannot be confident that it has been deleted-- e.g. _no_ SSD will do rewrite-in-place.
This is less of a big deal than you might expect because the keypool is all set to 'used' prior to encryption, so any address you retrieve from the wallet after enabling encryption will be born encrypted and will have never been on the disk unencrypted.
Why doesn't the bitcoind fill the old wallet with zeros before deleting it? You'd be safe for everything except fancy forensic magnetism leaking which is useless after some time using the disk.
This message was too old and has been purged
This is the reason that setting the passphrase forces a shutdown. Bitcoin core completely rewrites the wallet and deletes the old file.
Especially with modern disks and file systems once data has _ever_ hit the disk you cannot be confident that it has been deleted-- e.g. _no_ SSD will do rewrite-in-place.
This is less of a big deal than you might expect because the keypool is all set to 'used' prior to encryption, so any address you retrieve from the wallet after enabling encryption will be born encrypted and will have never been on the disk unencrypted.
Especially with modern disks and file systems once data has _ever_ hit the disk you cannot be confident that it has been deleted-- e.g. _no_ SSD will do rewrite-in-place.
This is less of a big deal than you might expect because the keypool is all set to 'used' prior to encryption, so any address you retrieve from the wallet after enabling encryption will be born encrypted and will have never been on the disk unencrypted.
This looks like an issue, but if I understand it correctly it happens only when you encrypt the wallet for the first time, afterwards they are decrypted to memory, not disk, right?
I suppose Bitcoin-QT should zero the unencrypted wallet.dat before deleting it.
I suppose Bitcoin-QT should zero the unencrypted wallet.dat before deleting it.
Hi at all,
I've looking how work the encryption in the wallet.dat file. During the encryption's process the bitcoin client encrypt the privatekeys, write them on the file and only after (of course for be sure to don't lost nothing) delete the original privatekeys.
This is right, but the original privatekeys is not wiped from the disk and if you going to search it into the hdd sectors it's possibile to find them.
The risk is for addresses (and privatekeys) already stored in the wallet file before the process and not for the addresses generated late.
FaSan
I've looking how work the encryption in the wallet.dat file. During the encryption's process the bitcoin client encrypt the privatekeys, write them on the file and only after (of course for be sure to don't lost nothing) delete the original privatekeys.
This is right, but the original privatekeys is not wiped from the disk and if you going to search it into the hdd sectors it's possibile to find them.
The risk is for addresses (and privatekeys) already stored in the wallet file before the process and not for the addresses generated late.
FaSan
Jump to: