私は約2年前にGPShellとGemaltoカードで同じ問題を扱っていました(0x6A80を取得しているかどうかはわかりませんが、おそらくそうです)-私の記憶が正しければ、GPShellは新しいキーに間違った多様化データを使用し、(さらに悪いことに)オプションを指定したput_sc_key
コマンドの KEK が正しくありません。-keyDerivation
たぶん、これはアップストリームで修正されました-最新のsvnバージョンを試すことを検討したいかもしれません(更新:問題は現在修正されていると言われました)。
その時、私は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
私の記憶がうまく機能する場合、パッチは次のことを行います。
別のツール ( GlobalPlatformPro ?) の使用を検討することもできますが、それが PUT KEY のキーの多様化をサポートしているかどうかはわかりません (試したことはありません)。
幸運を!
編集>さらなる発展のためのブロックマイカードについて
この方法は (おそらく) ISD キーを変更し、ほとんどの場合 (つまり、他の SD が配置されていない場合) カード管理へのアクセスを保護します。
私の予想では、あなたのカードは最初はよく知られている javacard デフォルト キーの 1 つを備えていると思います。これらのデフォルト キーを他の強力な値に変更することで、これらのデフォルト キーを知っている攻撃者がカードを認証するのを防ぐことができます (強力なキーを強調すると、のようなキーの使用は避けてください0102030405..
)
キーを変更しても、実際には、新しいキーを知っているエンティティがカードの内容を管理することを妨げません。キーを使用すると、カードを自由に管理できます。アイデアは、キーにアクセスできるのはあなただけだということです
(I)SD キーを変更するGPSystem.getSecureChannel()
と、アプレットが使用する場合に使用されるキーが変更されます
ロードされたアプレットの機能を維持しながら、さらなる管理のためにカードをブロックする (私が認識している) 唯一の方法は、(I)SD アクセスをブロックすることです。これは、ほとんどのカードが ( I)この状態で SD (走行距離は異なる場合があります)。この方法はお勧めしません。