Я был имея дело с одной и той же проблемой два года назад с картой GPShell и Gemalto (не так уверен, что я получаю 0x6A80, но, вероятно, да). Если я правильно помню, GPShell использовал неверные данные диверсификации для новых ключей и (что хуже) неправильно KEK для команды put_sc_key
с -keyDerivation
вариант.
Возможно, это было исправлено в восходящем направлении - возможно, вам стоит попробовать попробовать последнюю версию svn (UPDATE: I was told that the problem is fixed now).
Это время я использовал следующие уродливые изменения в отношении пересмотра Svn 419:
--- globalplatform/src/globalplatform.c (revision 419)
+++ globalplatform/src/globalplatform.c (working copy)
@@ -61,6 +61,10 @@
#ifndef MAX_PATH
#define MAX_PATH 257
#endif
+
+static BYTE savedKEK[16];
+
+
static BYTE C_MACDerivationConstant[2] = {0x01, 0x01}; //!< Constant for C-MAC session key calculation.
static BYTE ENCDerivationConstant[2] = {0x01, 0x82};//!< Constant for encryption session key calculation.
@@ -3309,6 +3313,15 @@
OPGP_LOG_START(_T("VISA2_derive_keys"));
OPGP_LOG_HEX(_T("VISA2_derive_keys: Base Key Diversification Data: "), baseKeyDiversificationData, 10);
+ static BYTE savedBaseKeyDiversificationData[10];
+ if(memcmp(baseKeyDiversificationData, "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", 10)==0) {
+ // In trouble -> patch
+ memcpy(baseKeyDiversificationData, savedBaseKeyDiversificationData, 10);
+ } else {
+ memcpy(savedBaseKeyDiversificationData, baseKeyDiversificationData, 10);
+ }
+
+ OPGP_LOG_HEX(_T("VISA2_derive_keys: Base Key Diversification Data2: "), baseKeyDiversificationData, 10);
/* Key Diversification data VISA 2
KDCAUTH/ENC xxh xxh || IC serial number || F0h 01h ||xxh xxh || IC serial number
@@ -3971,6 +3984,9 @@
OPGP_LOG_MSG(_T("mutual_authentication: S-MAC Session Key: "), secInfo->C_MACSessionKey, 16);
+ if (secInfo->secureChannelProtocol == GP211_SCP01) {
+ memcpy(savedKEK, secInfo->dataEncryptionSessionKey, 16);
+ }
#ifdef OPGP_DEBUG
if (secInfo->secureChannelProtocol == GP211_SCP01) {
OPGP_LOG_HEX(_T("mutual_authentication: Data Encryption Key: "), secInfo->dataEncryptionSessionKey, 16);
@@ -4513,6 +4529,12 @@
OPGP_ERROR_STATUS status;
GP211_SECURITY_INFO gp211secInfo;
mapOP201ToGP211SecurityInfo(*secInfo, &gp211secInfo);
+
+ if(memcmp(KEK, "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", 10)==0) {
+ // In trouble -> patch
+ memcpy(KEK, savedKEK, 16);
+ }
+
memcpy(gp211secInfo.dataEncryptionSessionKey, KEK, 16);
status = put_secure_channel_keys(cardContext, cardInfo, &gp211secInfo, keySetVersion, newKeySetVersion,
NULL, new_encKey, new_macKey, new_KEK);
Который работал для меня с этим скриптом:
mode_201
....skipped...
open_sc -security 3 -keyind 0 -keyver 0 -key <motherKey> -keyDerivation visa2
put_sc_key -scp 1 -keyver 1 -newkeyver 1 -key <newMotherKey> -keyDerivation visa2 -current_kek 00000000000000000000000000000000
Если моя память мне хорошо патч делает следующее:
сохраняет ключевые данные диверсификации во время первой аутентификации (т. open_sc
), а затем использует их при диверсификации новых клавиш для put_sc_key
.
сохраняет полученную KEK во время первой аутентификации, а затем использует ее как KEK для шифрования новых ключей (это срабатывает с использованием 0000....0000
KEK).
Вы можете использовать другой инструмент (GlobalPlatformPro?), Но я не уверен, поддерживает ли он диверсификации ключей для PUT KEY (не пробовал).
Удачи вам!
EDIT> Что касается блокировать свою карту для дальнейшего развития части
Этот метод (предположительно) изменяет ISD ключи, которые в большинстве случаев (т.е.когда никакая другая SD не находится в месте) защиты доступа к управлению картой
моя ставка является то, что ваши карты изначально имеют один из хорошо известных ключей JavaCard по умолчанию на месте - и за счет изменения этих клавиш по умолчанию для некоторых другое значение сильного предотвратить злоумышленник, зная ключи этих значений по умолчанию от аутентификации на карту (акцент на сильном означают, что вы должны избегать использования ключей как 0102030405..
)
изменения ключей фактически не мешает объект понимающих новых ключей от управления содержимым карты - с помощью клавиш, которые вы c управлять карточкой по желанию. Идея заключается в том, что вы только один с доступом к ключам
изменяющих (I) ключей SD изменения ключи, используемые GPSystem.getSecureChannel()
если апплет использует его
Единственный метод (я), чтобы заблокировать карту для дальнейшего управления, сохраняя при этом функциональность загруженного апплета, чтобы заблокировать (I) доступ к SD, безуспешно попытку аутентификации примерно в 10 раз - поскольку большинство карт блокируют доступ к (I) SD при этом условии (ваш пробег может отличаться). Я бы не рекомендовал этого.
_He хочет заблокировать карту для дальнейшего развития_, Итак, почему он не просто меняет ключи аутентификации? – Abraham
@Abraham Я понимаю, что OP пытался изменить ключи аутентификации с помощью GPShell, но это не сработало. Моя ставка заключается в том, что используемый KEK/DEK был неправильным (из-за ошибки GPShell) и KCV не совпадают. – vlp