PIN change fails with CKR_PIN_LEN_RANGE because current PIN is too long about opensc HOT 10 CLOSED

Thanks!

• 80 24 01 00: CLASS, INS, P1, P2
• 10: Length=16
• 43 54 6d ff 42 a5 8c 41: This is the encoding of the old PIN
• 31 31 32 32 33 33 34 34: The new PIN in ASCII, thats what we have right

There are different standard ways to encode pin, except for ASCII according to the opensc source code definintions: BCD, HALFNIBBLE_BCD, ISO9564_1, which obviously need to limit the allowed characters set so my guess would be iso9564-1, but there is no implementation for this in OpenSC (except for headers). The wikipedia describes various types of encoding PINs, where this would match the type 4 based on the first nibble involving AES encryption, which is something we will likely not be able to do in OpenSC

https://en.wikipedia.org/wiki/ISO_9564

https://www.eftlab.com/knowledge-base/complete-list-of-pin-blocks#ISO-4 (the anchor does not work)

So it looks like the actual pin is not passed through, just some encrypted "fingerprint" as we can not really encode 16 alphanumeric characters into 8B. We also do not know the PAN nor the key used for encrypting the PIN, if this is what is done.

So I think this will be dead end, unless somebody has some more ideas how to decode/encode this PIN.

from opensc.

You may want to look at this first: https://militarycac.com/CAC.htm

Since there is only one pIn and has only 3 tries left till it locks the card. You could circumvent the OpenSC code that tries to catch error before send a non valid PIN to the card and issue the ADPU to change the pin directly.

If you really think you know the old pin, the following should work.
The card will only give you 3 retries before locking the card.
Use at your own risk.

(The OpenSC code does not indicate if the CAC card has a PUK which is a pin change the pin if it is locked.

You only get 3 retries to get it changed.

https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/pkcs15-cac.c#L88-L99 shows what is expected.)

`opensc-tool -s "00:24:00:00:10:oldpin:newpin"
Where :

• 24 is change pin using oldpin to newpin
• for key ref 00 00
• 10 is length of following data 16 bytes.
• oldpin is in hex padded to 8 bytes using FF
• newpin is 4 to 8 digits padded with FF.

For example if oldpin pin was "My3pin" oldpin would be 4D:5A:33:70:69:6E:FF:FF
and newpin should be 123456 use 31:32:33:34:35:36:FF:FF

opensc-tool -s "00:24:00:00:10:4D:5A:33:70:69:6E:FF:FF:31:32:33:34:35:36:FF:FF"
If it works, it will return "90 00"

To see how many retries use: `opensc-tool -s :00:20:00:00" which returns "63 Cx" where x is number of retries. (In you log it shows 3.)

(I have not tried this on CAC cards, but have on PIV cards.)

from opensc.

We were able to get HID ActivID ActivClient installed on a Macbook (the trick was running Firefox with Rosetta enabled) and change the PIN to something shorter.

I still wanted to see how we could use OpenSC to change the PIN though. After some very careful tries this is the farthest I was able to get to (old PIN of 1234567890, new PIN 12345678)

opensc-tool -s "00 A4 04 0C 07 A0 00 00 00 79 10 00 00" -s "00 24 01 00 14 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 FF FF"
Using reader with a card: ActivIdentity Activkey_Sim
Sending: 00 A4 04 0C 07 A0 00 00 00 79 10 00 00
Received (SW1=0x90, SW2=0x00):
6F 0B 84 07 A0 00 00 00 79 10 00 A5 00 o.......y....
Sending: 00 24 01 00 14 31 32 33 34 35 36 37 38 39 30 31 32 33 34 35 36 37 38 FF FF
Received (SW1=0x67, SW2=0x00)

(found out from some other posts that I need to send a SELECT APDU first followed by the PIN change)

I am very curious what APDU the ActivClient software sends to change the PIN to something longer than 8 characters. It looks like Wireshark can capture USB traffic. May try that next.

from opensc.

(SW1=0x67, SW2=0x00) is wrong length.

According to OpenSC, the max length for a pin is 8.

https://www.cac.mil/common-access-card/getting-your-cac/ "Step 4" says: "A six (6) to eight (8) digit number to use as a Personal Identification Number (PIN). Your PIN should not be a number derived from something easily known about you, such as part of your Social Security Number (SSN), birthday, anniversary date, telephone number, or address."

Off hand why do you think the bad PIN was larger then 8?

But good to see you got it changed.

from opensc.

If you use WireShark, include the USBPcap program and look for USBCCID messages. The APDUs and responses are included in part of the data - not easy to find. (I have used this on Windows, but never on a Mac.)

from opensc.

Got Wireshark running (see https://wiki.wireshark.org/CaptureSetup/USB for details) and captured the APDU to change the PIN:

80 24 01 00 10 83 C8 0C XX XX XX XX XX YY YY YY YY YY YY YY YY

Old PIN is encrypted or encoded form of 1234567890 with the last few bytes redacted as XX, new PIN is redacted as YY and was sent in plaintext.

My understanding is CLA=80 means the APDU is using some proprietary commands. Not sure how the old PIN is encrypted or encoded but didn't want to take the chance of disclosing too much. All in all it looks like we would not have been able to change the old PIN without ActivClient.

Off hand why do you think the bad PIN was larger then 8?

We have the old PIN and it was longer than 8 chars

from opensc.

@Jakuje any comments on this CAC password change command?

Yes 0x80 says vendor defined. But rest of command matches ISO 7816-4 which is very common:

Table 102 — CHANGE REFERENCE DATA command-response pair
CLA As defined in 5.4.1
INS '24' or '25'
P1 '00' or '01' (any other value is RFU)
P2 See Table 94
Lc field Present for encoding Nc > 0
Data field
INS = '24' P1 = '00' Verification data followed without delimitation by new reference data
P1 = '01' New reference data
INS = '25'
P1 = '00' Verification data DO followed by new reference data DO
P1 = '01' New reference data DO
Le field Absent for encoding Ne = 0

Note your Nc = 0x10 says 16 bytes of data.
P1 is not 00 would mean the old and new password are in same data and 8 bytes each.
P1 == 01 implies there is only the new reference data

So not clear what they are doing.

from opensc.

If I see right, the PIN change is not defined in the latest GSC IS that is available online on https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nistir6887e2003.pdf

But it mentions the following:

The maximum effective PIN length is dependent on the card platform.

So I believe the CAC driver is written to be on lower and safer side of the PIN lengths (which has this side effect that longer pins wont work).

The specs also do not mention what are the allowed characters or how the padding should be done as it is likely also a platform dependent.

The PIN change implemented in the CAC driver was implemented as part of #2129 based on some CAC alt token from HID (and ActivClient trace), which sounds like something similar to the token you have. I did not experiment much with the lengths or allowed characters, but I do not mind extending the allowed length and character set for this type of card, if it will work.

Can you change the pin to something bogus known value (for example abcdefghij) and then change it to some other bogus known value (for example 12345678) to provide the full apdu without redacting the values so we can see how it is encoded and padded? Then you can change safely the PIN to whatever secret value you want to use. Or just clarify if the PIN is padded with fixed value (0xFF), padded to fixed length and the content is just ASCII value of the PIN.

Given that we have this specific HID card type to make pin change possible (not possible with other cac cards as far as I know), we can modify the driver to support longer PINs.

from opensc.

Unfortunately I couldn't use the values you asked for; they seemed to be rejected because they didn't meet some PIN strength requirement.

Here's what I saw when I changed the old PIN abcdefgh12345678 to new PIN 11223344:

80 24 01 00 10 43 54 6d ff 42 a5 8c 41 31 31 32 32 33 33 34 34

from opensc.

I figured this might be the case. Thanks for digging into it @dengert @Jakuje

from opensc.