Brute force protection on PIN code

[aegyed91]

Hi! Do you think it would make sense to implement brute force protection against guessing the PIN code?

Trezor uses rate-limiting, Ledger simply wipes the device after 3 incorrect PIN code entries (in this context, the app could wipe the corresponding Identity). I think implementing either one of these would be a nice additional security feature.

P.S thanks a lot for providing this app, it is an awesome idea and I found it really useful :)

[burdges]

We'll provide k-of-n threshold signing w3f/schnorrkel#11 eventually at which point you just use n old phones kept physically separated. In this, we've no reason each threshold signer retains k or n so an adversary compromising some only knows when their done, not how much further they must go, nor in how many places you've hidden them.

Could rate limiting be done using TPM chips somehow?

I'd think device wipes sound more likely to blow up in someone's face. We could provide device wipe as a compile time option, so you could use it if you can successfully build parity signer from source, after uncommenting some line with scary warnings, and maybe place a license on some file that prevents app store distribution.

[aegyed91]

The idea is to prevent someone from guessing the PIN by trying different variations. Setting a 6 digit PIN would take 9^6 variations to guess. I was thinking of a simple software level solution that would factor out common people trying to guess the PIN code.

We'll provide k-of-n threshold signing w3f/schnorrkel#11 eventually at which point you just use n old phones kept physically separated. In this, we've no reason each threshold signer retains k or n so an adversary compromising some only knows when their done, not how much further they must go, nor in how many places you've hidden them.

This sounds like the ultimate solution. After all, this app is running on android instead of dedicated hardware, because of that, it is not hard to crack it. Having your secret split into N slices and stored on N devices make it much more difficult for the attacker to do harm.

[burdges]

We should investigate TPM chips more surely. I know @Lederstrumpf speaks with some folks around that.

[HCastano]

I think that we can think about this from a more practical point of view. When you set up Signer it is encouraged that you a) encrypt your phone and b) choose a good lockscreen password. If you have an encrypted phone with a sufficiently complex password chances are nobody will be able to unlock your phone and make it to the Signer app in the first place.

I imagine you can also set your phone up to wipe itself after a certain number of failed lockscreen attempts, essentially doing what you're looking for.

[kirushik]

In addition to the above, we use https://github.com/paritytech/react-native-secure-storage for storage on the platforms which support it.
While not being an ideal solution (in the ideal world we would only ever store the key in the Secure Enclave and sign the payloads from there), it at least allows us to limit access to the "data at rest", adding "you need to exfiltrate the encrypted key from the Secure Enclave-protected storage" on top of the regular PIN bruteforcing (there's also a decent KDF function involved in encryption using that PIN, but I agree that for the average PIN length this is more of a "cosmetic" measure).

[burdges]

As an aside, there is a nice workflow for the k-of-n threshold story: First, you initialize the key using k devices, but using random field elements as device ids. At this point, the devices forget k and n=k but nobody even defined the real n yet. Next, anytime you like you increase n by adding another device, using a ceremony in which k devices give the new device shares.

Only the coordinating human knows k, if multiple humans hold devices then they do not necessarily not k, although any k of them can discover k and the secret. We do not require that anyone man or machine know n. All this gives rather nice opsec options. :)