В контексте сертификации мини-драйвера карты в рамках HLK необходимо запустить инструмент CMCK, который будет запускать сертификационные тесты для мини-драйвера карты. Одной из функций, которые необходимо протестировать, является так называемая «аутентификация администратора», которая здесь заключается в механизме запроса/ответа. Этот механизм выполняется в два этапа:
- Минидрайвер запрашивает вызов с карты с помощью функции getChallenge.
- минидрайвер шифрует полученный запрос с помощью ключа администратора и отправляет его на карту для проверки с помощью функции cardAuthenticateChallenge.
Здесь шифрование 3DES в режиме ECB (есть и другие типы шифрования)
Когда тесты выполняются непосредственно с помощью специального инструмента тестирования, разработанного внутри компании, который эмулирует контекст CSP/KSP и вызывает функции, все в порядке, и аутентификация проходит хорошо, но при выполнении CMCK аутентификация не удалась и, как следствие, не удалась вся последующая сертификация.
Кто-нибудь знает, почему CMCK это делает?
Вот конфигурация CMCK, которая правильно указывает, что это PIN-код типа запрос-ответ (ключ 3DES)
Код: Выделить всё
2 ChallengeResponsePinType 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 True False
При отладке вызовов CMCK к минидрайверу (к сожалению, исходный код CMCK не распространяется, поэтому отладить его невозможно) мы видим, что он не запрашивает шифрование полученный запрос, а вместо этого нечто другое, что также является 8-байтовым значением.
Пока мне не удалось найти причину этого в спецификациях Microsoft Minidriver (последняя версия) .
Подробнее здесь:
https://stackoverflow.com/questions/787 ... ng-the-car
Мобильная версия