ansi - 解密 DUKPT 加密轨道数据

Question

正如标题所示，我正在尝试解密来自支持 DUKPT 的扫描仪的 DUKPT 加密轨道数据。

我拥有 DUKPT 的 ANSI 标准 (X9.24)，并成功实现了从 KSN 和 BDK 生成 IPEK 的功能。此外，我还成功实现了通过对 PIN 加密 key 进行异或运算来生成左右 MAC 请求和响应 key 的功能。最后，我能够生成 EPB。

从这里开始，我不明白如何从我生成的 L/R key 生成 MAC 请求和响应。

最后，一旦我到达这一步，接下来会发生什么？我什么时候真正拥有可以解密启用 DUKPT 的设备发送的轨道数据的 key ？

我知道 Thales Simulator 和 jPOS。我的代码当前正在引用 Thales Simulator 来完成其所有工作。但是，文件解密过程并没有返回预期的数据。

如果有人可以提供一些解密轨道数据的见解，我们将不胜感激。

http://thalessim.codeplex.com/

http://jpos.org/

Answer 1

我花了太多时间研究可怕的 X9.24 规范，最终通过供应商的示例实现了加密和解密，营销人员立即决定更换供应商。由于它是一个标准，您可能会认为任何人的实现都是相同的。我希望。无论如何，事情的实现方式存在差异。您必须研究细则，以确保您的工作方式与另一方相同。

但这不是你的问题。

首先，如果您需要解密信用卡中的数据轨道，您可能有兴趣生成一个 key ，该 key 将基于原始 super secret 基本派生 key 来解密数据。这与 MAC 一代无关，只是在传递那个可怕的规范时提到的。如果在 HSM 的完整 key 序列号的计数器部分中设置了位，您需要为该 key 序列号和设备 ID 生成 IPEK，并重复应用规范中的“不可逆 key 生成过程”。

我的代码的这一部分如下所示:(很抱歉在帖子中列出了很长的 list 。)

/*
 * 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 的 80 位 key 序列号crypt 是一个 64 位数据 block ，因为我使用的是 openSSL，所以它的类型为 DES_cblock。key 是一个 128 位双 DES_cblock 结构。keyGen 例程几乎逐字来自规范第 50 页的“不可逆 key 生成过程”本地子例程。

最后，key变量将几乎包含可用于解密的 key 。编写规范的人在 key 中添加了一些“变体”行为，以让我们保持警惕。如果 key 用于解密数据流(例如信用卡磁道)，则需要将字节 5 和 13 与 0xFF 进行异或，并使用 Triple DES 自身加密 key (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 block ，则需要将字节 7 和 15 与 0xFF 进行异或。 (我不是 100% 确定这也不应该应用于流模式，但我的供应商将其排除在外。)

如果是 PIN block ，则会使用 ECB 模式下的 3-DES 进行加密。如果是数据流，则会以CBC模式进行加密，初始化向量为零。

(我有没有提到我不太关心规范？)有趣的是，如果服务器端(上面)记住并拒绝，加密端可以在非硬件、防篡改安全模块中使用之前使用过的键。这项技术非常巧妙。 ANSI 规范还有一些不足之处，但技术还不错。

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