In a previous post
PC/SC workgroup, November 2011 meeting and on the
MUSCLE mailing list I asked for suggestion to submit at the PC/SC workgoup planned for November 2011. I got some feedback. Here is the proposal I sent to the PC/SC workgroup.
Misc PC/SC proposals
| Author: | Ludovic Rousseau |
|---|
| Date: | October 2011 |
|---|
Introduction
In October 2011 I asked on the MUSCLE mailing list (
http://musclecard.com/list.html) what changes where expected by the PC/SC workgroup.
Here is a list of the items.
Changes in PC/SC workgroup documents
The PC/SC workgroup specifications contain a "Revision History" section with a brief description of the changes. It would be even better to have all the changes directly visible within the document.
This can be done using different processes:
PDF with revision marks
When a new document is provided by the PC/SC workgroup a second document with the changes (compared to the previous version of the document) can be provided. This second document is easy to generate using the "compare" feature of MS Word.
Provide the document in ODF format
If providing the second document with the changes is too much work for the process another solution is to provide the document in ODF (Open Document Format) format (in addition to the PDF format). With this format it is easy to use, for example, Libre Office and compare two versions of the same specification document.
Provide the document in .DOC format
If providing the documents in ODF format is too much work for the process another solution is to provide the document in MS .DOC format. I guess the original format of the specification is already .DOC so the only added step is to store the .DOC documents on the PC/SC workgroup web site.
Firewalled pinpad
Some pinpad readers implement a firewall. If a PIN Verify command (INS byte 0x20) is sent using
SCardTransmit() the reader will reject it. With a firewalled pinpad the only way to verify a PIN is by using the
secure verify PIN feature. The problem is that 2 different readers will return 2 different status word in case of firewall rejection. In the field we already have noted two different Status Word in this case: 0x6985 and 0x6D00.
According to ISO 7816-4 we have:
- 0x6D00:
- Instruction code not supported or invalid
- 0x69xx:
- Command not allowed (further qualification in SW2)
- 0x6985:
- Conditions of use not satisfied
These values are not really correct. Another problem is that it is hard (or impossible) to know if the error is really a invalid INS code or a rejection by the firewall. Another option it to use an
not already used value like 0x6404
- 0x64xx:
- State of non-volatile memory is unchanged (further qualification in SW2)
Some special Status Word values are already used (in the field) with a pinpad:
| SW | Description |
|---|
| 0x6400 | Timeout |
| 0x6401 | Canceled by user |
| 0x6402 | PIN mismatch |
| 0x6403 | Too short or too long PIN |
The PC/SC workgroup should define the status word (SW1 and SW2) to be reported by the reader in such a case. We propose to use 0x6404.
FEATURE_WRITE_DISPLAY
PC/SC v2 part 10 defines
FEATURE_WRITE_DISPLAY. But I could not find how to implement it in the driver at the CCID level. I guess some reader manufacturers have implemented it using CCID proprietary extensions.
- Proposal:
- Document how
FEATURE_WRITE_DISPLAY should or could be implemented at the CCID level
FEATURE_GET_KEY
PC/SC v2 part 10 defines
FEATURE_GET_KEY. But I could not find how to implement it in the driver at the CCID level. I guess some reader manufacturers have implemented using CCID proprietary extensions.
- Proposal:
- Document how
FEATURE_GET_KEY should or could be implemented at the CCID level
FEATURE_VERIFY_PIN_START
PC/SC v2 part 10 defines
FEATURE_VERIFY_PIN_START,
FEATURE_GET_KEY_PRESSED and
FEATURE_VERIFY_PIN_FINISH. But I could not find how to implement it in the driver at the CCID level. I guess some reader manufacturers have implemented using CCID proprietary extensions.
- Proposal:
- Document how
FEATURE_VERIFY_PIN_START, FEATURE_GET_KEY_PRESSED and FEATURE_VERIFY_PIN_FINISH should or could be implemented at the CCID level
The same issue also exists for
FEATURE_MODIFY_PIN_START and
FEATURE_MODIFY_PIN_FINISH.
Unblock PIN feature
Add the possibility to unblock a PIN code using a pinpad. The unblock INS code is 0x2C and defined by TS 51.011 EN (
http://www.3gpp.org/ftp/Specs/html-info/51011.htm). Some pinpad reader do not accept INS=0x2C for a VERIFY PIN command.
I propose to accept at least:
| INS byte | Description |
|---|
| 0x20 | VERIFY command (ISO 7816-4) |
| 0x2C | UNBLOCK (3GPP TS 51.011 EN) |
- Proposal:
- Document the minimum set of INS bytes that a pinpad reader shall accept for a secure verify PIN command.
PIN merge feature
Add a 'pin merge' feature in which: part of the PIN is provided by the application and the other part is entered on the pinpad reader. Some readers already allow this: you just put part of the PIN in the APDU -- but some readers seem to overwrite the APDU's PIN buffer with padding bytes.
For eID cards, it happens that a PUK is split between the citizen and the governement. The examples below come from an eID card with ASCII encoded PINs:
E.g. of a 'PIN unblock without PIN change', in this case you can do an
SCardControl(ctrl-for-FEATURE_VERIFY_PIN_DIRECT , data) with:
data = 1E 1E 02 00 00 00 00 08 04 00 02 01 16 08 00 00 00 00 00 00 0D 00 00 00
00 2C 01 81 08 FF FF FF FF 31 32 33 34 (37 bytes)
So the application provides the last part of the PUK (= "1234" in this case) and the pinpad reader should ask the first part of the PUK to the user and fill it in at the location of the
FF FF FF FF.
So for ASCII and BCD encoded PINs, this trick works on readers that don't write padding bytes to the PIN buffer (i.e. they should not change the
31 32 33 34 into
FF FF FF FF in the above example).
Another example, of a 'PIN unblock with PIN change', in this case you can do an SCardControl(ctrl-for-FEATURE_CHANGE_PIN_DIRECT , data) with
data = 1E 1E 02 00 00 00 08 08 04 03 02 03 16 08 00 00 00 00 00 00 15 00 00 00
00 2C 00 81 10 FF FF FF FF 31 32 33 34 FF FF FF FF FF FF FF FF (45 bytes)
Here again, the first
FF FF FF FF are for the user's part of the PUK, and the last 8 FF bytes are for the new PIN. Same remarks as above apply.
Conclusion
PC/SC defines some services at the PC/SC layer. This is fine. But the CCID specification does not provide any documentation or specification for these services.
A documentation is needed so that these services can be implemented in a "class" CCID driver.
Updating the CCID specification may be a difficult task. So I propose to host the documentation in the PC/SC workgroup. I do not ask to add the documentation in an existing document, just to host the documentation in a central place.
One easy solution is to host the CCID level programing manual of readers implementing the solutions we described above.