解密加密DUKPT跟踪数据

正如标题所说，我试图解密加密DUKPT轨迹数据从启用DUKPT扫描器的。解密加密DUKPT跟踪数据

我有DUKPT在ANSI标准（X9.24），并已成功实施从KSN和BDK产生伊佩克的能力。此外，我已成功实现了通过对PIN加密密钥进行异或来生成左右MAC请求和响应密钥的功能。最后，我能够生成EPB。

从这里，我不明白如何从我所产生的L/R键的MAC请求和响应。

最后，一旦我走到那一步，接下来会发生什么？我什么时候能够解密由启用DUKPT的设备发送的轨道数据的密钥？

我意识到泰雷兹模拟器和jPOS。我的代码目前正在引用泰利斯模拟器来完成所有工作。但是，文件解密过程并没有返回预期的数据。

如果有人可以提供一些洞察到解密的轨道数据，这将是大加赞赏。

http://thalessim.codeplex.com/

http://jpos.org/

来源

2012-07-31 bdeetz

我花了太多时间研究可怕X9.24规格，终于得到了加密和解密与我的供应商的实例和营销工作及时决定交换机厂商。既然它是一个标准，你会认为任何人的实现都是一样的。我希望。无论如何，有关如何实施的变化。你必须研究细则以确保你的工作与你的另一面相同。

但这不是你的问题。

首先，如果你需要从信用卡解密数据轨道，你可能有兴趣生产，这将解密仍按原超级秘密基地推导关键数据的关键。这与MAC一代没有任何关系，只是在传递这个可怕的规范时才提到。您需要为该密钥序列号和设备ID生成IPEK，并且如果在HSM的完整密钥序列号的计数器部分中设置了位，则重复应用规范中的“不可逆密钥生成过程”。

那我的代码部分如下：（对不起，在张贴的长列表。）

/* 
* Bit "zero" set (this is a 21 bit register)(ANSI counts from the left) 
* This will be used to test each bit of the encryption counter 
* to decide when to find another key. 
*/ 
testBit=0x00100000; 
/* 
* We have to "encrypt" the IPEK repeatedly to find the current key 
* (See Section A.3). Each time we encrypt (generate a new key), 
* we need to use the all prior bits to the left of the current bit. 
* The Spec says we will have a maximum of ten bits set at any time 
* so we should not have to generate more than ten keys to find the 
* current encryption key. 
*/ 
cumBits=0; 
/* 
* For each of the 21 possible key bits, 
* if it is set, we need to OR that bit into the cumulative bit 
* variable and set that as the KSN count and "encrypt" again. 
* The encryption we are using the goofy ANSI Key Generation 
* subroutine from page 50. 
*/ 
for(int ii=0; ii<21; ii++) 
{ 
    if((keyNumber&testBit) != 0) 
    { 
     char ksr[10]; 
     char eightByte[8]={0}; 

     cumBits |= testBit; 
     ksn.count=cumBits; /* all bits processed to date */ 

     memcpy(ksr, &ksn,10);  /* copy bit structure to char array*/ 
     memcpy(crypt,&ksr[2],8); /* copy bytes 2 through 9 */ 

     /* 
     * Generate the new Key overwriting the old. 
     * This will apply the "Non-reversible Key Generation Process" 
     * to the lower 64 bits of the KSN. 
     */ 
     keyGen(&key, &crypt, &key); 
    } 
    testBit>>=1; 
}

哪里 keyNumber从KSN KSN当前计数器是一个80位的结构，其中包含HSM crypt的80位密钥序列号是一个64位的数据块，因为我使用的是openSSL，所以它有DES_cblock类型。密钥是一个128位双DES_cblock结构。 keyGen例程几乎完全来自规范第50页上的“不可逆密钥生成过程”本地子例程。

在这段结束时，关键变量将包含可用于解密的密钥，几乎。编写规范的帅哥在关键时加入了一些“变体”行为，让我们留在脚趾上。如果密钥要用于解密诸如信用卡轨道之类的数据流，则需要使用0xFF对字节5和13进行XOR，并使用Triple DES对其自身（ECB模式）进行加密。我的代码如下所示：

DOUBLE_KEY keyCopy; 
char *p; 
p=(char*)&key; 
p[ 5]^=0xff; 
p[13]^=0xff; 
keyCopy=key; 
des3(&keyCopy, (DES_cblock *)&key.left, &key.left); 
des3(&keyCopy, (DES_cblock *)&key.right, &key.right);

如果您正在使用此解密PIN块，你需要XOR字节7和15为0xFF。（我不是100％肯定这不应该适用于流模式，但我的供应商将它放弃。）

如果它是PIN块，它将在ECB模式下使用3-DES进行加密。如果它是一个数据流，它将在CBC模式下以零初始化向量加密。

（难道我提到我对规格不太在意？）有趣的是，如果服务器端（上面）记住并且加密端可以用于非硬件防篡改安全模块拒绝先前使用的密钥。技术非常整齐。 ANSI规范留下了一些需要的东西，但技术是可以的。

祝你好运。 /鲍勃·布莱恩

来源

2012-08-03 23:17:42

也就是说一些精彩的信息相关的代码。感谢您抽出宝贵时间回复这些细节。我一定会继续提供你所提供的工作。 – bdeetz 2012-08-06 14:15:10

我希望我能给你一票。互联网上最好的资源。 – Jonathan 2013-02-07 23:50:39

对于数据加密，所述变体是0000000000FF0000.0000000000FF0000所以需要XOR字节5和13代替图7和15中。另外，需要每个关键部位的附加3DES自加密步骤（左和对）。

这里是初级专业人员 https://github.com/jpos/jPOS/blob/master/jpos/src/main/java/org/jpos/security/jceadapter/JCESecurityModule.java#L1843-1856

来源

2013-04-23 21:28:13 apr

解密加密DUKPT跟踪数据

回答

相关问题