OpenSC 0.24.0 broken on Windows 10 and 11 both at 22H2 for some devices about opensc HOT 4 CLOSED

@frankmorgner I recall you saying Microsoft has dropped PIN PAD readers.

They simply don't support the CCID extension for PIN entry (and never did).

Regarding SCardControl, I think it returns 0x00000001 if one of the input parameters are bad (see LudovicRousseau/pyscard#19 for a similar issue) - in this case I assume it doesn't know GET_FEATURE_REQUEST. But as said before, we need more analyis, maybe with pyscard...

from opensc.

It is not clear when this started. I only have Windows 10 22H2 and 11 22H2.

What we really need is for someone with older Windows 10 to try 0.24.0 msi packages with a sc-hsm or other card that needs extended APDUs, i.e. larger then the default 255/256 to work.

CygWin uses the Windows, winscard.dll so would have the same problem. In my testing with CygWin I do not get the rv=0x00000001 I get rv = 0 and rcount is not changed. (I have tried setting it to 0, 256 and sizeof(buf) with same results.
also casting some parameters DWORD. and fiddling with the command code.

Have also installed VS 2022, with C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0 to see the header files. Best I can tell we are doing what is expected, which is slightly different then pcsc-lite on linux.

I also do testing using VirtualBox with an Ubuntu 22.4 guest, which has no problems accessing the sc-hsm token on the windows 11 host. So the token and its reader should return the results. (note that the VM access it in exclusive mode. Have not tried doing that the CygWin or the msi install.

CygWin is using gcc (GCC) 11.4.0 as is Ubuntu gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

If windows can not give us dwMaxAPDUDataSize from a reader that can return it we need to find a better way to allow a driver that depends on extended APDUs to not be stuck with using the default 255/256.

Right now I have been testing with the sc-hsm, there maybe other drivers that could have the same problem.

from opensc.

@frankmorgner
@LudovicRousseau
Using tip from LudovicRousseau/pyscard#19 with x86 version of pkcs11-tool -O
shows:

2023-12-20 10:21:36.639 (Thread = 0x000054E0) - SCardControl( hCard = 0xEA010000 on reader "SCM Microsystems SCx35xx v2.0 USB SC Reader 0", dwControlCode = 0x00313520, lpOutBuffer = 0x00F3F298, nOutBufferSize = 256, lpBytesReturned = 0x00F3F284 ):
 Input command = 
 
2023-12-20 10:21:36.649 (Thread = 0x000054E0) - SCardControl Response   = 
 
 Duration = 1 ms

this looks correct, as on Windows dwControlCode is 0x0031<<16 | 3600<<2 but it looks like it is not returning anything.

from opensc.

I think we can close this issue, because

• we verified that the windows driver doesnt support the request for the query of max data and we can't fix that
• we are currently already working around this where needed by assuming the reader supports the minimum data sizes required (e.g. in sc-hsm)
• we have code snippets to set the data sizes based on the reader name
  

  OpenSC/src/libopensc/reader-pcsc.c

  Lines 1282 to 1286 in 773fcc6

  	/* Try to set default limits based on device name */
  	if (!strncmp("REINER SCT cyberJack", reader->name, 20)) {
  	max_send_size = 1014;
  	max_recv_size = 1014;
  	}

If you want to, you may add data sizes of your reader with a PR extending reader-pcsc.c

from opensc.