Security issue: electrum handling of 25th wallet seed (for trezor) eliminates deniability

[t4777sd]

The importance of the 25th wallet seed is for deniability. However, electrum completely destroys this deniability because it uses a checksum on the 25th seed word to ensure it matches the open file. In other words, it is impossible to open "default wallet" and input any passphrase other than what the wallet was created with in electrum. This is made even more egregious due to the security issues described in #2187

The secure method to handle this would be to allow any passphrase to be entered and the corresponding wallet would load according to the passphrase entered. Or, as a compromise, perhaps a "RAM wallet" should be implemented. In this way, someone can create a new "RAM wallet" using whatever configuration they want. This wallet type would never be written to disk. As a result, there is no record that it existed.

[ecdsa]

you can already open your wallet in RAM

[t4777sd]

I went through wallet creation again and this option is not given. The only option is to create an actual wallet file that is written to disk. Of course the wallet gets loaded to RAM, but the problem is that it is written to disk. This defeats the purpose of 25th seed wallets, which is deniability.

Also, entering an arbitrary 25th seed also does not work. If a 25th seed is entered that is different than what the wallet was created with, then it will fail (again defeating deniability).

[JazzTp]

As for deniability, just an idea, provided I got the point:

You can always create another wallet, and put into it whatever you would want to show (funds/transactions), or nothing at all.

That looks to me as a better form of deniability. Being able to write whatever as seed and have Electrum accepted it, IMO, would destroy any deniability.

As for amnesia purposes:

Simply creating the wallet in RAM does not grant an amnesic environment. You might want to check out the Tails operative system and the recommendations coming with it (in another issue, I described how I'm using the latest Electrum version on it, both online and as offline cold storage, I'm on my cell phone right now but I might search for it later if you're interested... also very interesting is the website of a press association in the UK, they teach security using Tails, again I owe you the link).

[JazzTp]

http://www.tcij.org/resources/handbooks/infosec

EDIT: the last part of my last comment in #2180 was based on it.

[JazzTp]

Notice that Tails wipes RAM after using it, on exit from certain apps and/or before shutdown.

How I'm using Tails, basically:

ONLINE watch only

Boot from DVD, mount encrypted pendrive prepared for "watch only", launch a bash script from it, which performs the following steps:

• replaces .electrum folder with backup of same folder after previous session (you can just remove it on first session with new Electrum version then config Electrum again),
• extracts latest Electrum package from an encrypted archive and launches from inside its tree (otherwise the Electrum version coming with Tails would be launched)
• on exit, optionally backs up the .electrum folder

OFFLINE cold storage

Basically the same, except of course that it opens the full wallet containing the private key. Also, for the offline cold storage, I boot Tails from pendrive (faster) and use its Persistence folder instead of a second pendrive to keep my files, but my script extracts anything from it, I don't rely on any config saving features of Tails so it's easier to keep switching to the latest version of both Tails and Electrum.

(Installing Tails to pendrive is straightforward with the "Tails installer" application, after booting from DVD.)

I consider the installations of the two operative systems I've been using online a lot not safe at present, I navigated so many different news sites that I might very well have picked up some trojan horse (just give a look here https://themerkle.com/top-3-types-of-bitcoin-mining-malware/), so I'm using Tails from DVD for anything "sensible" (boots and runs faster on my system than e.g. the Ubuntu live desktop DVD).

(Tails should be pretty attack resistent, and it's being improved constantly, but I guess it's not a radically new architecture... maybe Subgraph OS will be it some day.)

[t4777sd]

Hello JazzTP, creating another wallet does not give you deniability. Here is the trezor article about denability and the 25th seed: https://blog.trezor.io/hide-your-trezor-wallets-with-multiple-passphrases-f2e0834026eb#.b8ibzdmsf

Let me better explain: 1) You get robbed or maybe you are forced to open electrum at a cross boarder check, which has precedent of boarder guards forcing people to open their software, etc

2) They can see all your wallets in the "recently open" list or simply look at the electrum data directory and ask you to open each one so they can inspect the contents.

Do you see how you lost deniability? Which is the entire purpose of the 25th seed. You might as well not even support the 25th seed if electrum cannot give deniability because it makes people believe they are getting security that does not exist.

The way it should work, where deniability is left in-tact, is you open up your wallet let's say "default_wallet". It asks for a passphrase and it generates the necessary keys based on the passphrase you entered. That way, when you are forced to enter a password you just enter in "decoypassword" which shows a near empty account. There is no way to prove that your real balances are in "realpassword".

With electrum, currently, that is impossible. Because "decoypassword" and "realpassword" are separate wallet files. So, an attacker, snooper, etc, KNOWS that you have two wallets.

Example implementations: electrum supports a RAM / no-history wallet. That means, it will accept ANY passphrase and get the corresponding keys from trezor. That also means it does not store information about any keys or data in the corresponding wallet file (if it even creates a wallet file at all).

In reality, electrum is doing more work than it should currently and the consequence of that is that it is creating a security problem. The more work that it is doing is 1) not accepting any passphrase for the 25th seed 2) writing the public keys in a file that is a huge privacy concern (even just in the case of malware / spyware that now knows all your bitcion holdings).

[JazzTp]

Hello t4777sd,

Thank you, nice info, smart idea.

Admittedly, I was only considering the case of being forced to type your seed, not of being carrying any piece of hardware.

Now I see what your point is...

Filesystem encryption does not come with some kind of steganography, as for I know, where you'd have access to two different partitions according to what password you typed, and I couldn't think of any other strategy at the moment to provide with current tools a similar feature to the one described in the article.

I'm pretty sure the main developer here owns a Trezor, too, and I guess he'll value your input.

[t4777sd]

Why not just support a RAM / temporary wallet? In other words, it never writes anything to disk when selecting this wallet type. When you open the "RAM / temporary wallet" you pair it to a trezor just like creating a new wallet. Except, it does not write a file to disk. When you close the wallet, it is deleted from ram. With this capability, you maintain deniability much better than the system where electrum is writing to disk.

The feature could be behave exactly like the new wallet creation currently, except it never actually writes the wallet to disk. In that way, 95% of the feature is already done (just use the current code and in the writeToDisk() function return null and do nothing). I think this method is extremely elegant, not complicated to implement, and maintains deniability. In fact, it is essentially what happens using the trezor main wallet.

In fact, this type of wallet would also serve people that use normal seeds, so it would not only benefit trezor users. So, when selecting "RAM / Temporary wallet" a user can select "Seed wallet" or "Hardware wallet". Nothing gets written to disk. When electrum exits, the information is gone. That would solve 99% of the cases in a very elegant way.

[ecdsa]

Your statement about a checksum on the 25th word (passphrase?) makes no sense to me. The way it works is by comparing the master public key.

As I said, you can already open a wallet in RAM, and delete it after use. That, however, does not guarantee the wallet will never get written to disk, because modern operating systems use swap.

I don't think we should add a special button for that special use; RAM gets mounted differently on various systems.

[t4777sd]

Yes, that is what I mean. Electrum will not let you open a wallet without the same master public key. Effectively making deniability impossible. Don't you see the issue? A border patrol agent says open the wallet and you input an incorrect passphrase and electrum tells you "That is not correct". Well now the border patrol agent knows that was not the correct passphrase and they detain you until you input one that electrum says is correct.

That is not how the 25th seed is supposed to work for the Trezor hardware wallet. You can see that here: https://blog.trezor.io/hide-your-trezor-wallets-with-multiple-passphrases-f2e0834026eb#.b8ibzdmsf

Opening a disk-based wallet in RAM is not a RAM wallet. Certainly, an operating system might write to swap, but that is much less probable and not persistent (it will be overwritten quickly).

The RAM wallet is simply an implementation idea. The bug and security risk is that the Trezor 25th seed is not operating according to its intended implementation. This creates a security risk of making deniability impossible. I am sure there are various solutions. Such as 1) no longer comparing master public keys and do not store those in a file 2) do not store addresses in the wallet file 3) make it so any passphrase can be entered and it will open correctly.

[ecdsa]

if you don't want to leave traces of your wallet on your computer, use Electrum with Tails. I'm closing this issue, because your other suggestions do not make sense from a technical point of view.

[t4777sd]

If I implemented this issue would you merge it?