PIN codes and Hardware Wallets

[o_e_l_e_o]

Or use any other attack type that doesn't require waiting for potentially days or weeks.

But surely it you can bypass the PIN counter altogether to earn yourself unlimited attempts, then you would also bypass any delay imposed on repeated attempts. In such a case it then becomes fairly easy to set up a program to just brute force every combination from 00000000 to 99999999. And with the seed dumping vulnerability you mention now patched, then if such an attack were possible then I suspect we would have seen it by now.

So if it seems not possible to bypass the PIN counter, then that comes back to the original question of what does bricking after x attempts rather than resetting after x attempts achieve, other than forcing you to buy a new device?

[1714934140]

1714934140

[1714934140]

1714934140

[1714934140]

1714934140

[n0nce]

Or use any other attack type that doesn't require waiting for potentially days or weeks.

But surely it you can bypass the PIN counter altogether to earn yourself unlimited attempts, then you would also bypass any delay imposed on repeated attempts. In such a case it then becomes fairly easy to set up a program to just brute force every combination from 00000000 to 99999999. And with the seed dumping vulnerability you mention now patched, then if such an attack were possible then I suspect we would have seen it by now.

I'm not sure that they added such delay deliberately, but as soon as you attack an embedded device (from a separate PC), you either have inherent delays in the communication or need to add some yourself since the device may not be ready to respond fast enough or the data isn't yet available. It's not like bruteforcing a software target on the same machine which could process PIN attempts at incredible speeds.

So if it seems not possible to bypass the PIN counter, then that comes back to the original question of what does bricking after x attempts rather than resetting after x attempts achieve, other than forcing you to buy a new device?

If there is a secure / non-bypassable PIN counter implementation that doesn't rely on the secure element, I currently see no technical reason holding hardware wallet developers back from using that instead of the more destructive method. I doubt that any 'non-destructive' implementation is as secure as one that leverages secure chip counters, though.

[dkbit98]

What is the benefit of a device bricking itself after x number of attempts, rather than just factory resetting itself? Assuming in both cases there is no chance to recover access to the original wallet without knowledge of the seed phrase, then bricking instead of simply securely wiping/shredding the data seems like a bug, not a feature, and simply forces the user to purchase another hardware wallet rather than just using their newly reset one to recovery from a back up.

Maybe there is still a theoretical chance that some important secure leftovers could remain in secure element, and that could be exploited by malicious attacker.
Passport used old Coldcard code as a base and they are the first ones to introduce this feature, knowing how old secure elements they used had known security flaws, this is not totally impossible.
You won't hear about flaws in ledger and similar blackbox devices, because they signed secret NDA  
Anyway, I like this self-destruct mechanism, other wallets have this enabled when you try to open device and mess with the inside.

If there is a secure / non-bypassable PIN counter implementation that doesn't rely on the secure element, I currently see no technical reason holding hardware wallet developers back from using that instead of the more destructive method. I doubt that any 'non-destructive' implementation is as secure as one that leverages secure chip counters, though.

Passport is hardware wallet for (old) 007 James Bond, mi6 only needs to add special bomb explosion option when you enter wrong pin 13-1 time   💣

[n0nce]

Anyway, I like this self-destruct mechanism, other wallets have this enabled when you try to open device and mess with the inside.

I'm personally relatively 'neutral' about the self-destruct; I'd prefer it to just fully reset itself when hitting the PIN entry limit, due to the possibility of false positives, as o_e_l_e_o pointed out. These devices aren't exactly cheap.
What I do hate is when devices, like you mentioned, self-destruct when opened. It is essential to be able to fix and potentially even check hardware against its specification ('verifiable builds' - hardware style).

[zherbert]

Hi all, Zach from Foundation here, wanted to comment as to why we brick Passport after 21 PIN attempts instead of factory resetting it.

In short, with all the possible supply chain attacks out there, we want to encourage that customers only purchase Passport from us or from an official reseller. If it was possible to reset Passport to factory state, I think we'd see a lot of used devices on Ebay and such, and I think that sets a bad security precedent.

There's no way to factory reset Passport even if you know the PIN – you can wipe the device and create/restore a seed, but you cannot ever reach the "Welcome to Passport" setup screen.

This also makes it easier from a support/documentation perspective. If the device is new, then the user goes through the usual and well-documented onboarding flow. If you're instead presented with the PIN screen on startup, that means that the device has already been previously set up by someone else.

An additional benefit here is that there's no incentive to steal a Passport, because it's unusable if you don't know the PIN.

There's tradeoffs here for sure, and we are always open to reconsidering our approach based on feedback.

[o_e_l_e_o]

Thanks for your response.

In short, with all the possible supply chain attacks out there, we want to encourage that customers only purchase Passport from us or from an official reseller. If it was possible to reset Passport to factory state, I think we'd see a lot of used devices on Ebay and such, and I think that sets a bad security precedent.

There's no way to factory reset Passport even if you know the PIN – you can wipe the device and create/restore a seed, but you cannot ever reach the "Welcome to Passport" setup screen.

I take your point about not allowing a factory reset back to the Welcome screen, but I'm not sure this fully explains the requirement to brick the device however. Since you can already wipe the device and return to the restore a seed option, then surely you could just implement a similar wipe once you hit the 21 PIN limit? That way you keep the exact same protections against resetting to a factory state, while also not forcing users to buy a new device if they accidentally brick their wallet.

[zherbert]

Thanks for your response.

In short, with all the possible supply chain attacks out there, we want to encourage that customers only purchase Passport from us or from an official reseller. If it was possible to reset Passport to factory state, I think we'd see a lot of used devices on Ebay and such, and I think that sets a bad security precedent.

There's no way to factory reset Passport even if you know the PIN – you can wipe the device and create/restore a seed, but you cannot ever reach the "Welcome to Passport" setup screen.

I take your point about not allowing a factory reset back to the Welcome screen, but I'm not sure this fully explains the requirement to brick the device however. Since you can already wipe the device and return to the restore a seed option, then surely you could just implement a similar wipe once you hit the 21 PIN limit? That way you keep the exact same protections against resetting to a factory state, while also not forcing users to buy a new device if they accidentally brick their wallet.

Hmm...one thing we could potentially do is clear the seed and PIN, but display a warning screen to the user that Passport has been previously used. I'll discuss with our CTO to see if I'm missing any nuance with regard to the secure element configuration.

[dkbit98]

This also makes it easier from a support/documentation perspective. If the device is new, then the user goes through the usual and well-documented onboarding flow. If you're instead presented with the PIN screen on startup, that means that the device has already been previously set up by someone else.

I think 21 wrong PIN's are more than enough, and it's very unlikely bricking of device would happen by accident, but my question is what are the chances of someone cracking PIN with some external software/hardware attack?
There are more than enough chances for hackers to try, since Passport have most wrong PIN attempts out of all other hardware wallets.
I understand that this was first introduced with Coldcard wallet, but they have 13 wrong PIN's instead.

An additional benefit here is that there's no incentive to steal a Passport, because it's unusable if you don't know the PIN.

It's similar situation like when someone buys used smartphone that is locked and it's practically unusable, except for spare parts.

[n0nce]

Thanks for your response.

In short, with all the possible supply chain attacks out there, we want to encourage that customers only purchase Passport from us or from an official reseller. If it was possible to reset Passport to factory state, I think we'd see a lot of used devices on Ebay and such, and I think that sets a bad security precedent.

There's no way to factory reset Passport even if you know the PIN – you can wipe the device and create/restore a seed, but you cannot ever reach the "Welcome to Passport" setup screen.

I take your point about not allowing a factory reset back to the Welcome screen, but I'm not sure this fully explains the requirement to brick the device however. Since you can already wipe the device and return to the restore a seed option, then surely you could just implement a similar wipe once you hit the 21 PIN limit? That way you keep the exact same protections against resetting to a factory state, while also not forcing users to buy a new device if they accidentally brick their wallet.

Hmm...one thing we could potentially do is clear the seed and PIN, but display a warning screen to the user that Passport has been previously used.

That wouldn't even be required, since just like when 'wiping the device', you won't get the 'Welcome to Passport' setup screen ever again, right? That was Leo's idea; handle the 21 attempt limit as if the user had gone to Advanced > Erase Passport.

I'll discuss with our CTO to see if I'm missing any nuance with regard to the secure element configuration.

I still suspect that the secure element doesn't have the ability to do an 'Erase Passport' / i.e. if you want to use the secure element's secure counter feature, you have to brick the chip when a set limit is reached.
But I'd be thrilled to hear if my suspicion is right or not!

[o_e_l_e_o]

but my question is what are the chances of someone cracking PIN with some external software/hardware attack?

From a pure numbers point of view, Ledger allow the lowest number of guesses (3), with a PIN between 4 and 8 characters. This gives a lower limit of 1 in 3,333 and an upper limit of 1 in 33,333,333. Passport allows 21 guesses but with a longer PIN between 6 and 12 characters, giving a lower limit of 1 in 47,619 and an upper limit of 1 in 47,619,047,619. So it compares favorably.

If you are talking about an attack which can bypass the PIN counter, then whatever the PIN counter is set to is irrelevant.

[dkbit98]

If you are talking about an attack which can bypass the PIN counter, then whatever the PIN counter is set to is irrelevant.

I can't say it's totally irrelevant, but I don't know how this attack would be performed on Passport device, and if this is even possible.
I remember when hacker and electrical engineer Kingpin aka Joe Grand cracked PIN code for one of his customer Trezor wallet, he was very careful not to spend all wrong PIN attempts.
Original owner spend most of them, so he could only miss a few times with wrong PIN before device would get wiped and erased.
There was an attack on old Coldcard Mk2 device with a laser that recovered PIN Code from this device, but I think this was related with flaws in their old secure element that was later replaced.

[Coin-Keeper]

A key point to reflect on is how the PIN/SEED are removed when the "count" hits the device preset limit.  Speaking from knowledge on my Trezor T's the PIN/SEED removal is a WIPE and not a simple delete.  Most everyone knows that deleting something is almost worthless against even a moderately skilled adversary.  e.g. - using my WIPE PIN code I can observe a full wipe not a simple delete.  Of course the code is open source if you wanted to examine it for yourself!  You can observe the wipe in progress as the operation is performed.  Its not a split second delete, which should scare the crap out of users should their device do that!

[n0nce]

Its not a split second delete, which should scare the crap out of users should their device do that!

That's not necessarily the case anymore, though. Nowadays, you can securely (basically, as long as state-of-the-art symmetric cryptography is not broken) 'wipe' a drive quickly, by using full disk encryption and tossing they key. It is super fast, yet completely secure, as it leaves you with all the data 'intact' on the drive, but impossible to recover.
Keep in mind that currently used symmetric crypto schemes are already quantum-resistant, so you gain negligible speed-up even with a quantum computer.

Obviously, when it comes to a drive without encryption, it's better to do a few passes of overwriting with zeroes than just deleting an entry in the partition table.
With all that said; this applies to HDDs. Hardware wallets use flash chips which work very differently, so the 'overwrite with 0' method is not the best anymore; in fact, overwriting zeroes can harm SSD drives. So I doubt that Model T does this, it's probably just a little bit slow.

[dkbit98]

Its not a split second delete, which should scare the crap out of users should their device do that!

That's not necessarily the case anymore, though. Nowadays, you can securely (basically, as long as state-of-the-art symmetric cryptography is not broken) 'wipe' a drive quickly, by using full disk encryption and tossing they key.

This is true for SSD drives with encryption, but I am not sure is this is the case with small devices like hardware wallets because they are not using drives but memory.
I never researched if wiping hardware wallet is deleting seed words from memory with or without encryption, but in recent times I prefer devices that deletes everything after power is turned off.
So you are basically doing reset of your wallet every time, and you can quickly import seed words with a QR code, so there is no need to have PIN codes or secure elements.
I mean there are pros and cons for everything, and I am not expecting everyone to stop using PIN codes now

[n0nce]

Its not a split second delete, which should scare the crap out of users should their device do that!

That's not necessarily the case anymore, though. Nowadays, you can securely (basically, as long as state-of-the-art symmetric cryptography is not broken) 'wipe' a drive quickly, by using full disk encryption and tossing they key.

This is true for SSD drives with encryption, but I am not sure is this is the case with small devices like hardware wallets because they are not using drives but memory.

An SSD is some flash chips + a flash controller. There are already devices with 'SSDs' that are actually just the flash chips like smartphones and M1/M2 Apple computers which handle the flash controller functionality in the processor / SoC. They still have full disk encryption; so that should also work on hardware wallets, from a technical point of view.
Most hardware wallets have a secure element and use that to encrypt the flash, for instance. As soon as the secure element chip tosses the key, it's realistically impossible to retrieve any useful data from the flash.

[dkbit98]

An SSD is some flash chips + a flash controller. There are already devices with 'SSDs' that are actually just the flash chips like smartphones and M1/M2 Apple computers which handle the flash controller functionality in the processor / SoC. They still have full disk encryption; so that should also work on hardware wallets, from a technical point of view.
Most hardware wallets have a secure element and use that to encrypt the flash, for instance. As soon as the secure element chip tosses the key, it's realistically impossible to retrieve any useful data from the flash.

Some hardware wallets still don't have secure elements like Trezor's and their forks, but for all other devices you would have to trust closed source elements are encrypting everything correctly without flaw.
We don't even know what kind of encryption they are using, we can't verify anything, and not every encryption is made equal.
Even if encryption would get broken we wouldn't know anything about it because of signed NDA's.

[o_e_l_e_o]

I remember when hacker and electrical engineer Kingpin aka Joe Grand cracked PIN code for one of his customer Trezor wallet, he was very careful not to spend all wrong PIN attempts.
Original owner spend most of them, so he could only miss a few times with wrong PIN before device would get wiped and erased.

In this case, he managed to pull the PIN from the device's RAM during an update. So in such a case it wouldn't have mattered how many attempts were available to begin with or how many were used, as long as there was at least one remaining and the device hadn't wiped/bricked itself.

Follow up question to the 4-5 posts immediately above: What is actually happening when a device is bricked? Is the data being wiped? Is it being encrypted? Yes, the device may not operate through the normal channels anymore, but can you say for sure the hardware which is bricking itself is completely impervious to all attempts to access it? I guess I'm still not convinced that bricking adds meaningful security over proper data shredding.

[dkbit98]

Follow up question to the 4-5 posts immediately above: What is actually happening when a device is bricked? Is the data being wiped? Is it being encrypted?

It was probably encrypted and locked without unlocking option, but I never saw clear official explanation what really happens in this case.

One  recent post got my attention and inactive ledger device owners could check if this is true or not, but one guy reported that after few months of not using his legder wallet there was an issue with his PIN code.
Device forgot PIN code by itself, and he needed to restore everything again by importing seed words from scratch.
It could be one more mysterious issues after ledger devices were not used for longer periods of time, but support confirmed this is not normal behavior.
https://www.reddit.com/r/ledgerwallet/comments/yc5jf8/ledger_nano_s_forgets_pin/

[o_e_l_e_o]

It was probably encrypted and locked without unlocking option, but I never saw clear official explanation what really happens in this case.

But if that's the case, then a hard reset in which all the data is encrypted and then deleted would achieve the exact same amount of security without requiring the user to purchase a new device.

https://www.reddit.com/r/ledgerwallet/comments/yc5jf8/ledger_nano_s_forgets_pin/

Any time someone tells me their device or their wallet forgot their password or their PIN (and not just in bitcoin), then I am of the opinion that by far the most likely explanation is human error. Sure, he may have a faulty device, but far more likely he is simply entering the wrong PIN (especially if he hasn't entered it for a few months). Prime example is Peter Schiff, who claimed his wallet forgot his password, before admitting that actually he was entering the wrong information.

[satscraper]

~

@dkbit98, Wouldn't it be too much work for you to extend  a bit more your research by adding  the comparison of GUI used by different HWs to enter PIN code?. Recently the firmware of ledger nano s+ has  been elevated to 1.0.4 with the most noticeable change in GUI to enter PIN  code.  I  think the new GUI in  s+ is more convenient for use than it was before upgrade.