retry counters

[My1]

There are a few things about the retry cunters and the GUI software: 1) you can neither change/reset them in the GUI, must be done in CLI sadly) 2) when the puk was blocked and I reset the PUK retry counter in the CLI the gui still says puk blocked.

[emlun]

1. You're right, there's no such feature in the GUI. I'm sorry, but we won't add it either since it can be done in the CLI for the few cases when it's needed.
2. Which kind of YubiKey and which version of YubiKey PIV Manager are you using?

[My1]

1. but for that one needs to know that it exists in the first place and why does it even hurt to add it?
2. Yubi 4 nano, and the version is 1.4.2

[emlun]

1. We're moving to merge the PIV Manager functionality into YubiKey Manager and retire PIV Manager, so we don't currently plan to add any new features to PIV Manager.
2. That's strange, I can't get yubico-piv-tool to change the retry counters at all on my YK4 Nano. This might be a bug in yubico-piv-tool. On a YK Neo I was able to reset the PUK retry counter after blocking the PUK; note however that yubico-piv-tool also resets the PIN and PUK to the defaults when you reset the retry counters.

[My1]

1. okay, didnt know. but yeah not needing three pieces of software if awesome (I hope the manager will get a portable version though)
2. weird I just did that not long before the issue and the version of the piv tool was freshly downloaded (1.4.4 win x64)

and I know that the pin and puk get reset to defaults this isnt the problem. the problem is that the gui still says that the puk is blocked even though that's no longer the case (you can change the PUK in the PIV Tool without issues, which proves the GUI wrong)

but honestly why even reset the PIN? the PIN is needed anyway to reset the counters in the first place, so it can be changed back as well, so it just adds an unnessecary step, for the puk though it's not bad to reset it when you forgot that one.

otherwise it might be possible to drop the PIN requirement and just use the MGM to reset botth PIN and PUK.

[emlun]

How did you get the PUK blocked?

[My1]

well there are only 2 things to do with PUK, unblock pin and change puk. when the pin still works, I guess I tried to change my PUK which I forgot :-)

essentially change PUK 3 times with wrong PUK -> blocks PUK

then use PIV CMD tool to reset the counters -> unblocks PUK

change the PUK to something you can remember -> proves PUK works

open PIV Manager -> still thinks PUK is blocked.

[emlun]

That's strange... when I tried the same thing the PIV Manager GUI did not say the PUK was still blocked after resetting the retry counters. This smells like a bug.

There are some implementation details that are probably behind this. There's actually no way to tell whether the PUK is blocked by querying the device, only how many PUK retries are left. Instead PIV Manager writes a bit flag to a PIV Manager specific memory location when the PUK is blocked, which is probably the reason you see the discrepancy between the CLI and the GUI. I'm told that bit shouldn't be written by failing too many PUK attempts, though - which agrees with my own experiments - so I'm not sure what's actually going on in your case.

It looks like we'll have to look further into this, but I'd like to postpone that until we've worked out whether merging into YubiKey Manager is feasible.

[My1]

well when the PIV manager just writes a flag in a specific location, then yeah that's the reason. I used the PIV tool for trying to change the PUK.

but when the bit shouldnt be written by failing the PUK what ELSE does trigger it? I mean the only reason the thing is there is to say that it's blocked.

do you maybe know where that damn flag is stored to I can just annihilate it an have at least temporary peace?

also question about the retry counter, does the counter include the first try or not (aka when retry counter is set to 3 (default) in the 3rd wrong pin/puk shuts the thing down. does the internal counter in that case also start at 3 or just at 2? because if it starts at 3 that would mean that 0 means blocked.

[dainnilsson]

The number indicates tries remaining, so it should start at 3 and 0 means blocked.

The flag (along with some other pivman-specific data) is stored as an object with ID 0x5fff00. The easiest way to delete it is to reset the entire applet, but obviously that removes everything PIV related. Unsetting the flag isn't trivial I'm afraid, as the data contains other stuff as well, and removing it may have other side effects. If you're not using the management key derivation functionality it should be safe to just remove the data, which you can do by using the write-data action available in yubico-piv-tool, and writing an empty object to it.

[My1]

oh the flag is stored ON the Yubi ITSELF., okay, with PIV manager specific location I juts thought it is on the computer

but when it is possible to read the retry counter, why did you say then that one cannot see whether it's blocked? because by the logic used above counter=0 means blocked and base it upon that.

but I guess if that flag is there, someone could try to write a reset for it in the PIV Tool and later the complete Yubico manager.

[dainnilsson]

I think @emlun misspoke. You can't read the PUK retries counter from the device, only the PIN retries counter. This is the reason for the flag.

[My1]

oh that sux, but as I said, maybe the PIV Tool should just reset the flag. would it be okay making an issue over there and referencing this?

also why go and make the PIN counter public but not the PUK counter as well? seems weird imo.

[dainnilsson]

Part of the PIV specification again, I'm afraid.

Some of the features that pivman proves are specific to this tool, and may not work if you use other tools (like yubico-piv-tool) to modify the device. Specifically these are things like using the PIN to protect the Management Key, or setting a PIN expiration date where you're prompted to change your PIN every X days. We may end up supporting some of these features in yubico-piv-tool as well, but for now it doesn't make sense to do this one thing there if using that tool is still going to break other stuff.

[My1]

is this some kind of ugly joke? who wrote this thing in the first place? (honestly I dunno whether to laugh or cry)

I mean I can get digits of PIN/PUK minimum while slightly annoying we dont need to argue about why they are there (more security obviously)

but keeping the PUK counter private while the PIN counter is open makes absolutely no sense. I mean what would an attacker gain if he can see "oh we have 3 remaining tries on the PUK"

I mean if both would be secret we would have security by obscurity at its best with almost no advantage, but at least it's remotely reasonable. in comparison keeping both open also makes sense because the application can properly react and tell the user to keep hard attention because there is only one try left.

[dainnilsson]

The way to read out the PIN retries is done by sending a VERIFY command (which is used to provide the correct PIN to "unlock" the card) with an empty PIN. If you VERIFY with a wrong PIN the tries counter gets decremented and you get an error back telling you the value of the counter. If you VERIFY with an empty PIN you get the same error back, but the counter isn't decremented:

VERIFY(PIN) -> SUCCESS
VERIFY(WRONG_PIN) -> ERROR(X remaining)  //X is now 1 less than before.
VERIFY(EMPTY) -> ERROR(X remaining)  //Note, no counter decrement!

My guess about why there isn't a command like that for PUK is that there is no similar VERIFY for PUK, it's always used as an argument to a command that does something else, like resetting the PIN.

[dainnilsson]

In other words, I would assume that isn't not a matter of "the PUK counter must be kept secret for security" but rather that there was no foreseen need for being able to read it out.

[My1]

okay, so the PIN counter is implicitly public over the command, but the PUK was just forgotten, lol. so the PUK counter is not explicitly secret but just because no one thought of it.

but honestly, when the yubi already has a "private" approach to this, wouldnt it have made more sense that for example change PUK with 3 empty values or whatever would returns the counter instead of writing it in some arbitary value that is just completely arbitrary and can break stuff easier than one might think (see this issue)

[dainnilsson]

There's definitely a risk of breaking something or inadvertently introducing some security issue with these types of changes, so you have to take a lot of care in doing so (there are so many different use cases and weird combinations of things used). It is possible to do, but it would also mean that all existing YubiKeys before it would miss out, and the tools would have to deal with that case as well, adding even more complexity.

[My1]

but it would also mean that all existing YubiKeys before it would miss out

isnt that always the case with new features? also I thought that could have been done before the smartcard yubis came (iirc the first with smartcard was the neo, but not sure)

about the security thing well true that there may come issues with some thing but a hyper specific check on triple empty on change PUK doesnt sound like it can add a lot of problems because all thee parameters are empty and therefore way below the threshold.

and considering this is based upon something else that already is specified (verify PIN with empty) it seems to kinda make sense throwing in that as well.