Signer without secret storage

[Slesarew]

This is a proposal of super-hardened Signer setup.

In essence, Signer is not a tool to store keys, it's a tool to use keys stored elsewhere (on paper). Let's use this feature!

There should be an optional mode of operation for Signer, where seeds are not stored at all; user has to manually input them every time for signing or address creation (pubkey generation) either manually or with the use of bananasplit-based tool.

This might benefit from another build/fork of Signer, so that we eliminate secure hardware chip altogether, move yet more logic to pure Rust and greatly extend hardware compatibility.

Depends on:

#872
#857

Discuss.

[Tbaut]

I guess this goes together with the banana split issue #872

In essence, Signer is not a tool to store keys, it's a tool to use keys stored elsewhere (on paper)

If paper was as hard to get access to as the key stored on an encrypted device, I'd agree. The thing is it's much easier to hack a paper sheet. I def. use Signer as a cold storage. It doesn't mean it shouldn't be able to use an externally stored key, but expecting this flow to be the main one would be a mistake IMHO.

[kirushik]

It's unclear to me what it the workflow here.
Is this flavour of Signer only for keys which are to be used once, under some terrible conditions (like revocation keys)?
If it's for more day-to-day use, the user would inevitably have to keep enough of the paper backups at hand, and then indeed there's no benefit in going through the whole BananaSplit excercise, just writing the seed down on a piece of paper would be exactly the same from the security perspective.
So essentially your Signer keys would be as secure (in terms of both Confidentiality and Availability) as that piece of paper.

And current Signer provides stronger security guarantees than a piece of paper with a seed phrase: it's not enough to steal the Signer device physically, the attacker would also need to crack the encryption open (multiple levels even, both full-disk encryption and our seed/key protection).

So all in all, I don't see this as a significant security improvement or a desired feature/subproject.
Feel free to reopen if you want to try changing my mind.

[Slesarew]

Waait, you are forgetting about actually memorizing seed phrase! That's why they are proper words, 24 could be properly memorized (while backup is kept in safe or something like that). I'm pretty sure there are more use cases, let's just revisit this idea again when we have spare time; I'm only sure it won't happen it 5.0.*

[goldsteinsveta]

2cents, if this is for public releases
I do not know of anyone requesting this feature.
Given Signer's praised security and how it is communicated i.g. here, people do perceive Signer as one of the backup media and use it this way too. By failing expectations about what Signer does (they are already created: "The simplest solution for cold storage", "Generate and store multiple private keys", "Scan your transaction, verify and sign"), we won't improve practical security in the world.

I think we should

1. Make banana split nice, helpful, useable and well documented, also to make this flow considerable at all
2. Carefully experiment with an option of showing seed phrase just once and asking for a feedback about that one first
3. And only then in case there are requests, we could consider this feature for public release

[krodak]

Not requested by users and not relevant to any item on roadmap