Starcos3x pin format

[jozsefd]

Checklist

• Documentation is added or updated
• [x ] PKCS#11 module is tested
• [x ] Windows minidriver is tested
• macOS tokend is tested

I have adjusted the actual starcos driver for the cards of a large German federal organization. They have StarCOS 3.4 and 3.5 cards in use, I changed the following:

• the cards have alphanumeric PINs, so they use ASCII encoding instead of GLP. Added a function to detect the PIN transmission format of the card
• added a new StarCOS 3.5 ATR (v3.52)
• adjusted the path fixing "unify path (the first FID should be MF)" in function starcos_select_file. StarCOS 3.5 works now the same way as v3.4
• enabled extended APDU support for v3.x cards

I have tested it with StarCOS 3.4 and StarCOS 3.5 cards on Ubuntu with opensc-explorer and on Windows 7 signing and decrypting with the minidriver and signing with the PKCS#11 Module in Firefox.

[frankmorgner]

I imagine that the PIN type needs to be set PIN-wise, which means that I guess pin_encoding needs to track the individual PINs rather than being a global property... What do you think?

[jozsefd]

Yes, it sounds possible, but as far as I know, in practice a given card uses the same encoding for all PINs. I made a quick test of all StarCOS cards at my disposal:

1. StarCOS 3.4 (D-Trust)
   ATR: 3b:d8:18:ff:81:b1:fe:45:1f:03:80:64:04:1a:b4:03:81:05:61

• MF/EF.PWDD: 7B 0A 80 01 00 89 01 12 9F 22 01 FF
• MF/EF.RCD: 7B 06 80 01 00 89 01 12
• SigG/EF.PWDD: 7B 0A 80 01 00 89 01 12 9F 22 01 01
• SigG/EF.RCD: 7B 06 80 01 00 89 01 12

2. StarCOS 3.4 (BA)
   ATR: 3b:d8:18:ff:81:b1:fe:45:1f:03:80:64:04:1a:b4:03:81:05:61

• MF/EF.PWDD: 7B 06 80 01 00 89 01 21
• MF/EF.RCD: 7B 06 80 01 00 89 01 21
• QES/EF.PWDD: 7B 0A 80 01 00 89 01 21 9F 22 01 01
• QES/EF.RCD: 7B 06 80 01 00 89 01 12 (QES PUK is disabled!)

3. StarCOS 3.5 (BA)
   ATR: 3b:df:96:ff:81:31:fe:45:80:5b:44:45:2e:42:41:5f:53:43:33:35:32:81:05:b5

• MF/EF.KEYD[17]: 7B 0B 80 01 00 A4 06 95 01 08 89 01 21
• MF/EF.KEYD[18]: 7B 0B 80 01 00 A4 06 95 01 08 89 01 21
• QES/EF.KEYD[3]: 7B 0F 80 01 00 A4 0A 95 01 08 89 01 21 9F 22 01 01

The only exception is the deactivated Signature PUK encoding, but that info is not valid anyway.

It is surely possible to call the function starcos_determine_pin_encoding for each PIN, on demand, but I think it is not necessary.

[frankmorgner]

I agree that most likely the PIN format is the same for every PIN on the card. I think, for now, the code can stay as is.

[frankmorgner]

Do you need to include this in the upcoming release?

[jozsefd]

Thank you! It is not that urgent, I am working on a PKCS#15 emulator PR for the same StarCOS cards anyway.

[frankmorgner]

Oh, I wish you had said that earlier, because the PIN format would normally be something that's defined in the PKCS#15-layer and passed to the driver! Although, pkcs15-pin.c currently doesn't know the GP format, that would just be a matter of adding a new flag.

I didn't suggest this solution, because Starcos currently doesn't have a specialized PKCS#15 emulator. But this is exactly what you want to add... (Note that a PKCS#15 emulator can very easily iterate through all the PIN objects and set the correct format for each one!)

[jozsefd]

I also had the feeling that the PIN format would better fit into the PKCS15 part, but the starcos driver has explicitly set the PIN encoding for all PINs that's why I decided to fix that first. And if the PIN format is unspecified in PKCS15 than the driver can fall back to the determined encoding.

The planned emulator would work with the special profile on the cards of this German federal organization. It has 2 applications: ESIGN (for authentication and decryption) and QES (for qualified signing), and both apps have a related CIA (Cryptographic Information Application), but the card has no PKCS15 application.
These CIA apps are very similar to PKCS15 but I could not set up OpenSC to parse them, that's why I am writing an emulator.

[frankmorgner]

Strange, from what I've seen so far it looked like CIA (ISO 7816-15) is backward compatible with PKCS#15...

[jozsefd]

Yes, I think it should be compatible and the actual CIA looks like a PKCS#15 information structure, but it is different, for example:

1. CIA_ESIGN EF(ODF)

   30 28 A0 06 30 04 04 02 44 00 A4 06 30 04 04 02 0(..0...D...0...
   44 04 A8 06 30 04 04 02 44 08 A7 06 30 04 04 02 D...0...D...0...
   44 07 A1 06 30 04 04 02 44 01 90 00 D...0...D...

2. PKCS#15 EF(ODF)

   A0 0A 30 08 04 06 3F 00 50 15 44 01 A4 0A 30 08 ..0...?.P.D...0.
   04 06 3F 00 50 15 44 41 A5 0A 30 08 04 06 3F 00 ..?.P.DA..0...?.
   50 15 44 51 A7 0A 30 08 04 06 3F 00 50 15 44 07 P.DQ..0...?.P.D.
   A8 0A 30 08 04 06 3F 00 50 15 44 81 A1 0A 30 08 ..0...?.P.D...0.
   04 06 3F 00 50 15 44 11 90 00 ..?.P.D...

OpenSC fails to parse CIA_ESIGN EF(ODF), because of the extra SEQUENCE wrapper:

asn1.c:1642:asn1_decode: Looking for 'privateKeys', tag 0x21000000, CHOICE
asn1.c:1656:asn1_decode: 'privateKeys' not present
asn1.c:1642:asn1_decode: Looking for 'publicKeys', tag 0x21000001, CHOICE
asn1.c:1656:asn1_decode: 'publicKeys' not present
asn1.c:1642:asn1_decode: Looking for 'trustedPublicKeys', tag 0x21000002, CHOICE
asn1.c:1656:asn1_decode: 'trustedPublicKeys' not present
asn1.c:1642:asn1_decode: Looking for 'secretKeys', tag 0x21000003, CHOICE
asn1.c:1656:asn1_decode: 'secretKeys' not present
asn1.c:1642:asn1_decode: Looking for 'certificates', tag 0x21000004, CHOICE
asn1.c:1656:asn1_decode: 'certificates' not present
asn1.c:1642:asn1_decode: Looking for 'trustedCertificates', tag 0x21000005, CHOICE
asn1.c:1656:asn1_decode: 'trustedCertificates' not present
asn1.c:1642:asn1_decode: Looking for 'usefulCertificates', tag 0x21000006, CHOICE
asn1.c:1656:asn1_decode: 'usefulCertificates' not present
asn1.c:1642:asn1_decode: Looking for 'dataObjects', tag 0x21000007, CHOICE
asn1.c:1656:asn1_decode: 'dataObjects' not present
asn1.c:1642:asn1_decode: Looking for 'authObjects', tag 0x21000008, CHOICE
asn1.c:1656:asn1_decode: 'authObjects' not present
asn1.c:1684:asn1_decode: returning with: -1402 (Required ASN.1 object not found)

It seems that the actual card profile is broken an it does not comply with the standards.
EF 5031 is EF.OD in 7816-5 and EF(ODF) in PKCS#15 and defined the same way.

[frankmorgner]

Seems like your card issuer has messed up the meta info, because ISO 7816-15 is makes clear that

EF.OD shall contain the concatenation of 0, 1 or more DER-encoded CIOChoice values. Any number of ‘ FF ’
octets may occur before, between, or after the values without any meaning (i.e. as padding for unused space
or delete values). A specific choice may appear more than once in the file (which may be done, for example,
to apply different access control rules to separate collections of objects of the same type).

At least you can use the builtin functions for parsing by stripping the extra sequence header...