Auditing an offline wallet - page 2.

DeathAndTaxes

donator

Activity: 1218

Merit: 1079

Gerald Davis

What use is verifying the balance displayed is correct? Your own first posts indicates the possible threat is that an attacker includes the wrong address. The offline wallet can easily determine which addresses correspond to keys it controls. There is no need for the blockchain or balances.

Quote

It would also be possible to get a reasonable degree of assurance in a trust-free manner, simply by having the offline system display the difficulty after the last block, which the user can verify is roughly correct. This is enough to prove that whoever constructed this chain expended work at least equivalent to the entire bitcoin network hashing at current speeds for several weeks over four days, which is still a pretty high bar to faking an audit.

The entire network creates one block at current difficulty every 10 minutes. I am not sure where you got 4 days from.

Maybe it would be better to state exactly what you are trying to prove and why.

If you are just trying to prove the online wallet only contains your addresses then all you need is an export of those addresses. The cold wallet can instantly determine if there is an address in the hotwallet which it doesn't have the private key for.

Roy Badami

hero member

Activity: 563

Merit: 500

Yes, currently the offline wallet knows nothing about the blockchain, and therefore can't computer the balance of the wallet.

I'm proposing an audit mode whereby the offline wallet could be given a file containing just enough of the blockchain to determine the balance, and I'm also proposing countermeasures to guard against some possible attacks against that mechanism (since the offline wallet has no access to the Bitcoin network and hence can't apply the usual rules to determine the longest chain)

CircusPeanut

full member

Activity: 123

Merit: 100

Quote from: Roy Badami on May 12, 2014, 04:00:28 PM

If the compromised wallet actually correctly faked the balance your off-line wallet should have, it might be possible for such an attack to go unnoticed for a considerable time.
....
I'm wondering whether the following process for a wallet-supported audit would be viable:

In order to conduct an audit, the watching-only wallet would write a flie to a flash drive, containing the following:
...
This file could then be loaded into the offline wallet, which could then verify the header chain, and compute the balances of all the UTXOs.
...

It's not conclusive, though, if the attacker has had months or even years to prepare the fake chain, but for the truly paranoid you could display a more detailed difficulty history, which would defeat an attacker who used lots of 4x difficulty increases to minimise the amount of work they needed to do.

From these lines in your post it seems to me like you've mixed up the concepts of the address/key chain and the block chain.

The offline wallet has no connection to block chain. Only online watching only wallet does that. There is no need to "fake the balance" because the only record of your wallet's balance is in the online watching only wallet.

If you are worried, all you really have to do is make sure your online watching only wallet is giving you the correct public addresses. To do this, you can just try to sign a transaction every once in awhile with the offline wallet. Or, you can verify a bunch of addresses by manually generating them on both systems (Needs expert mode). Then you can compare the lists.

Roy Badami

hero member

Activity: 563

Merit: 500

So, there's been some discussion of the idea that a watching-only wallet might be compromised in such a way that it gives out receiving addresses that are actually controlled by an attacker. If the compromised wallet actually correctly faked the balance your off-line wallet should have, it might be possible for such an attack to go unnoticed for a considerable time.

One obvious countermeasure would be to periodically audit the balnce of the offline wallet by setting up a new watching-only wallet on a clean machine, and verifying the balance that way. However, since this involves getting the blockchain onto the new system, such an audit is never going to be a quick and easy process.

I'm wondering whether the following process for a wallet-supported audit would be viable.

[NM, this doesn't work. DeathAndTaxes points out to me that it's impossible to determine whether those coins have already been spent without access to the full blockchain. I guess the only way to audit a cold wallet really is to set up a new watching-only wallet on a known-good machine. Or at least, to maintain sufficient watching-only wallets that compromise of all of them is unlikely]

~~In order to conduct an audit, the watching-only wallet would write a flie to a flash drive, containing the following:~~

~~Block headers of the entire block chain~~
~~The complete transaction history of all UTXOs in the wallet, stretching back to the coinbase transactions that mined those coins~~
~~The merkle branches that prove these transactions are in the relevant blocks~~

This file could then be loaded into the offline wallet, which could then verify the header chain, and compute the balances of all the UTXOs. The above information is enough to prove that some chain exists that contains the purported transactions. It's not, in theory, quite enough to prove that that chain is the real blockchain, but that could be assured by a system of signed checkpoints.

It would also be possible to get a reasonable degree of assurance in a trust-free manner, simply by having the offline system display the difficulty after the last block, which the user can verify is roughly correct. This is enough to prove that whoever constructed this chain expended work at least equivalent to the entire bitcoin network hashing at current speeds for ~~several weeks~~ over four days, which is still a pretty high bar to faking an audit.

It's not conclusive, though, if the attacker has had months or even years to prepare the fake chain, but for the truly paranoid you could display a more detailed difficulty history, which would defeat an attacker who used lots of 4x difficulty increases to minimise the amount of work they needed to do.

Is this idea viable, or is there some reason I'm missing why this wouldn't work?

roy

EDIT: Rather than displaying the difficulty after the last block, display the difficulty value that was current immediately before the last difficulty change. An attacker would have to have mined a full 2016 blocks at this difficulty, so it raises the bar significantly. Signed checkpoints aren't as useful as I first thought, but I think there are still relatively simle checkpoint schemes that help here

EDIT: Better: pick the block midway between the last two difficulty changes, and display the date and time, balance, and difficulty as of that block.

Topic: Auditing an offline wallet - page 2. (Read 1170 times)