Generic Identity Device Specification (GIDS) KB

GIDS (stand for Generic Identity Device Specification) is a specification for smart card. It aims to offer an interface between a card & a driver.

GIDS is the only card (with PIV) to be deployed on all Windows starting windows 7. It is a plug & play card.

Here is some data we share.

GIDS characteristics


GIDS is supposed to support RSA from 1024 to 4096 bits. The minidriver implements only RSA 1024 and RSA 2048. ECC is not implemented in the minidriver.

Source: Function I_GetKeyClassAndAlgIdFromKeySpecAndKeySize


Admin authentication:

On Windows 7, only the mutual authentication is implemented. That means that the challenge size is 40 bytes. Since Windows 10 (8?) the general authentication, if available, is supported. That means shorter challenge size (8 bytes).

The mutual authentication requires a 3DES CBC encryption instead of a 3DES ECB encryption ?

There is an inconsistency in the step 4 of the mutual authentication. It is R1||R2||Z1 instead of R2||R1||Z1.

Undocumented feature

There is 2 undocumented tag in the Discretionary data objects tag 73 of the FCI next to the tag 0x40:

  • Reminder: 0x40: supported authentication protocol (allows the use of short challenge)
  • 0x41 ? (value 0x80?)
  • 0x42: enable read only ? (value 0x80?)

These tags are read only if the GIDS version is set to 4 (one of the byte of the AID).

Source: I_GIDS_InitializeVendorSpecific

Key importation

Key importation is implemented only since the Windows 10.

GIDS knowledge base

1) FCI tag

This page describe the FCI tag as 0x64. It is incorrect. The GIDS & minidriver document specify 0x61 and that the tag is optional as return to the SELECT command. If the tag is not set in the select response, the card is not recognized by the minidriver. Only Windows 10 (not Windows 7) check for the FCI data.


The GIDS implementation does not behave correctly with the flag CRYPT_NOHASHOID of CryptSignHash (CAPI). The APDUs sent do not change if the flag is enforced (removal of the digest info) and the mindriver do not return unsupported. As a consequence, the signature is considered as invalid. Tested on Windows 7.

Problem tested with SHA1, SHA256, MD5.

Note: CALG_SSL3_SHAMD5 is working (because there is no OID sent)

3) Global cache

The public keys are cached in the smart card service across all processes with the function ScardWriteCache / ScardReadCache. When reformatting the card a lot with the same serial number and with a different public key can confuse the driver and make the signature & decryption fail.

4) no support for pinpad reader

When a pinpad reader is connected, no change is made and the UI is still asking for the PIN. When there is a pin firewall (like Gemalto Ezio shield), it is impossible to use the card (returned code for the APDU = 64 04 => translated to 0x8010001F).

GIDS smart card pinpad firewall

5) Not every OS allow the import keys

Even if the Base CSP import policy is modified, the import is not supported on Windows 7.

Import is supported and works on Windows 10.

6) Big endian

RSA keys are pushed in big endian format (the same than a javacard). The translation from little endian (Windows computer) is made by the minidriver.

7) No smart card logon with ECC by design

There is no support for ECDH in the specification. ECC can only be used to sign data (typically a TLS authentication)

8) the GET PUBLIC KEY documentation is wrong

The documentation specify a A3 tag at the beginning of the GET DATA. The minidriver issues a 70 tag.


minidriver: 00 CB 3F FF 0A 70 08 84 01 82 A5 03 7F 49 80 00

documentation: 00 CB 3F FF 0A A3 08 84 01 82 A5 03 7F 49 80 00