Way to keep plausible deniability intact

[LedgerUser1]

• [x] I have checked this feature was not yet requested.

Part of the application

application

Description

Way to keep plausible deniability intact when forced to connect Ledger Nano S to Ledger Live application. An the moment all the accounts show up regardless of the current passphrase.

Possible solution:

1. Two passwords on the application or
2. optional use the ledger instead of the password to unlock the application (still different accounts depending on with passphrase is used).

[EricLarch]

Right now, the practical solution is to import a passphrase protected account, view it, do transactions if needed, and then delete it.

Click on the account, then on the wrench icon:

You can then safely remove the account from the Ledger Live app:

[gre]

We could have a specific mode of the app that never keep the accounts. A new advanced settings basically. Accounts stay in memory but are not persisted on disk. Meaning you always would need to import accounts again each time. Only settings would get saved so we can actually know onboarding was passed, etc..

[tookdrums]

gre this is exactly the Idea I was trying to support when the plausible deniability was debated on reddit.

I don't really see drawbacks to it beside:

• cluttering the interface (should be somewhat hidden in advanced options)

• The time to import account each time (I have no idea if it is comparable or much slower than what was done with the chrome app)

[gre]

@tookdrums it will be faster because under the hood, the libcore (C++ backend) have a cache and will get faster if you scan a second time.

[rrlamichhane1]

Guys, I have a bigger concern here. How was Ledger Live able to read my 'plausible deniability' account on the first place? When I enter my default pin-code to connect my Ledger Nano to the Ledger Live; it should be completely isolated, decoupled, and unaware of the fact that I have a 'plausible deniability' account associated with it.

• What's the freaking point of having a 'plausible deniability' account if someone can see it by connecting my device to a Ledger LIve app?
• What is the point of having extra passphrase and another pin-code if the plausible deniability account is visible and accessible without them?

This is a fiasco.

[juan-cortes]

@rrlamichhane I don't think it works that way. When you use the alternative pin or the temporary passphrase, you are essentially adding a 25th word to your seed, which means a completely different set of addresses are derived from the root key. If you import accounts from both pins (your main and plaussible deniability one), it's like importing from two devices and you should trigger the Oops, wrong device for ‘{{accountName}}’ error when trying to operate on one not derived from the seed in use.

If you only import from your main, or your plausible deniability one, the app doesn't know anything else.

Having this "non-persistent account importation" would allow you to have your "plausible deniability" ones imported, and import the main ones temporarily when you want to operate with them, or the other way around. Hope that makes sense.

[dasilvarosa]

An idea to address this would be a private mode when adding accounts:

• Add a checkmark in the add accounts flow to remove the account when closing the app.
• Add an icon in the accounts list / account page that indicates that the account is hidden/private

[Oliver917]

@gre Now that everyone remotely interested has our residential address, this issue should get a million billion times more priority.

At the very least make an implementation using multiple ledgers. e.g.:

• Mobile: Show different accounts (associated to different ledger(s)) based on pin / password . Pin/Password decrypts data. Find a way to plausibly deny that other 'real' accounts exist. E.g. always create 100 'instances' with random data, indistinguishable from encrypted data (a core characteristic of modern ciphers)
• Desktop: Like mobile, but also make ledger live portable, allow for multiple (USB thumbdrive) installs. (The workaround of creating multiple ledger live Operating System users is not sufficient.)

I know this may not be an easy problem to tackle, but the risk of home robbery had to be addressed at some point anyway. The hack just means it has to be done faster. Much faster.

[fti7]

+1 I would like to see a similiar Implementation as e.g. the KeePass Password Manager is working today.

Ledger Live itself does not store any User Data in its folders. Instead you can open a external Database File (Basically the SQLITE DB). Call it Ledger Live Tresor/Vault/Database or something.

Each Database has its own Password which will be used to Decrypt it. Everything from the User is then stored in there. Accounts, Settings etc.

So Users can easily switch between multiple User Databases (e.g. Different Persons) and/or also between the Main and the Hidden Account.

BTW there is also a Discussion Issue for it:

https://github.com/LedgerHQ/ledger-live-desktop/discussions/3669#discussioncomment-612844

[tvarsis]

This issue is 3 years old. Is there any progress on it?

In my point of view, Ledger Live should load the accounts from Nano when the Nano is unlocked with the matching pin. So if I unlock it with pin 1, it will load the accounts related to pin 1. If I load it with pin 2, then those accounts will be loaded. Starting Ledger Live should show no accounts at all unless an unlocked Nano is connected to it. This is in my opinion the only reasonable (and expected) way it should work for plausible deniability, and will also provide the best user experience. Should also be pretty straight forward to implement with no need of external databases or secondary passwords etc. Just use/show the accounts that are currently unlocked on the connected Nano, that's it.

[alandefreitas]

Any progress with this? Any related discussions?

[timmolter]

@tvarsis 's solution is how I was expecting it to work out of the box. Very disappointed and confused regarding the current implementation. As it is now, there is just way too many manual steps needed to be taken.

[alandefreitas]

@timmolter Exactly.

The "practical solution" of reimporting a passphrase is not very practical when there are 30+ tokens in the wallet.

Putting the manual work aside, it might even be dangerous to forget to import some tokens because if you write what tokens should be imported in an external file, this obviously defeats the whole purpose of plausible deniability.

In fact, leaving the tokens with no password in one machine and using a virtual machine for the tokens with a passphrase is more practical than always reimporting the accounts.