In the context of card minidriver certification within the HLK framework, it is needed to run a tool named CMCK which will run certification tests for a card minidriver. One of the functions that must be tested is the so-called “admin authentication” which consists here in a challenge/response mechanism . This mechanism is done in two steps:

1. The minidriver request a challenge from the card using a getChallenge function
2. The minidriver encrypts the received challenge with an admin key and sends it to the card for verification purposes cardAuthenticateChallenge function.
   Here the encryption is 3DES in ECB mode (there are various other types of encryption)

When the tests are done directly with a custom test tool developed internally, which will emulate a CSP/KSP context and call the functions, all is fine, and the authentications goes well but when CMCK is executed the authentication failed and as a consequence all subsequent certification fails.
Does anyone have a clue about why CMCK is doing this?

Here is the CMCK configuration, which is correctly indicating this is a challenge-response type PIN (3DES key)

<PinEntry> <RoleID>2</RoleID> <!-- authentication/ROLE_ADMIN --> <Type>ChallengeResponsePinType</Type> <Value>0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 </Value> <Blocking>True</Blocking> <AllowZeroLength>False</AllowZeroLength> </PinEntry>

When debuging CMCK calls to the minidriver (unfortunately CMCK source code is not distributed so it is not possible to debug it) , we see that it doesn’t request encryption of the received challenge but of something else instead, which is also a 8-byte value.

So far, I could not find a reason for this in the Microsoft Minidriver specifications (latest version).