change GP-Key on JavaCard - javacard

Question

I want to block my card
for further development.
Does anyone know how to do
that with GPShell?
I found this command:
open_sc -security 3 -keyind 0 -keyver 0 -key "currentKey" -keyDerivation visa2 // Open secure channel
put_sc_key -keyver 0 -newkeyver 0 -mac_key "newKey" -enc_key "newKey" -kek_key "newKey"-current_kek "currentKey"
but got this error:
put_secure_channel_keys() returns 0x80206A80 (6A80: Wrong data / Incorrect values in command data.)
I also tried:
put_sc_key -keyver 1 -newkeyver 1 -key "newKey" -keyDerivation visa2
but got this error:
put_secure_channel_keys() returns 0x80206A88 (6A88: Referenced data not found.)

Answer 1

I was dealing with the same problem about two years ago with GPShell and Gemalto card (not so sure if I was getting 0x6A80, but probably yes) -- if I remember correctly, GPShell used wrong diversification data for new keys and (which is worse) wrong KEK for put_sc_key command with -keyDerivation option.
Maybe this was fixed in upstream -- you might want to consider trying the latest svn version (UPDATE: I was told that the problem is fixed now).
That time I used the following ugly modifications against svn revision 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);
Which worked for me with this script:
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
If my memory serves me well the patch does the following:
saves key diversification data during the first authentication (i.e. the open_sc) and then uses them when diversifying new keys for put_sc_key.
saves the derived KEK during the first authentication and then uses it as KEK for new key values encryption (this triggers by using the 0000....0000 KEK).
You may consider using another tool (GlobalPlatformPro?), but I am not sure whether it supports key diversification for PUT KEY (never tried).
Good luck!
EDIT> Regarding the block my card for further development part
This method (presumably) changes the ISD keys, which in most cases (i.e. when no other SD is in place) protect the access to the card management
my bet is that your cards initially have one of well-known javacard default keys in place -- and by changing these default keys to some other strong value you prevent attackers knowing these default keys from authenticating to your card (emphasis on strong means you should avoid using keys like 0102030405..)
changing the keys actually does not prevent the entity knowing the new keys from managing the card contents -- with the keys you can manage the card at will. The idea is that you are the only one with access to the keys
changing the (I)SD keys changes the keys used by GPSystem.getSecureChannel() if your applet uses it
The only method (I am aware of) to block the card for further management while preserving the loaded applet functionality is to block the (I)SD access by unsuccessfully attempting authentication about ~10 times -- as most cards do block access to the (I)SD under this condition (your mileage may vary). I would not recommend this way.