DUKPT算法简析-1

神马是DUKPT？

简单来说，DUKPT（Derived Unique Key Per Transaction）是被ANSI定义的一套密钥管理体系和算法，用于解决金融支付领域的信息安全传输中的密钥管理问题。

以下内容引用自ANSI X9.24规范文档（Retail Financial Services Symmetric Key Management）

This standard establishes requirements and guidelines for the secure management and application-level
interoperability of keying operations. Such keys could be used for authenticating messages (see Reference 5), for
encrypting Personal Identification Numbers (PIN) (see Reference 4), for encrypting other data, and for encrypting
other keys.

DUKPT应用场景举例

Jacky到Wal-Mart购买了一双鞋，结帐时使用VISA信用卡刷卡，刷卡后POS需要与后台系统进行数据交互，将此交易的信息告知发卡行，交易信息的传递路径大概描述如下：

从信息传递的安全性上考虑：
1. 上图的交易信息传递过程中，会涉及到一些敏感信息的传输，例如可能有卡片有效期、CVV2、密码等，如何保证这些信息的安全性？
2. 每个结点如何校验接收到的数据是来自可信的相邻结点？即，如何校验数据的完整性，防止被恶意篡改？

于是，聪明的孩子就想到了使用DES/T-DES算法，针对敏感数据进行加密，解决了第一个问题；使用基于DES/T-DES的MAC算法，解决了报文校验问题。（为神马是T-DES和MAC？这不重要，我们要解释的是DUKPT！）

那么问题来了，既然使用了DES/T-DES这类的对称加密算法，就一定会涉及到对称密钥的交互问题。只有保证了密钥的安全性，对称加密才有意义。

于是，DUKPT应运而生。

DUKPT流程简析

说了半天，DUKPT到底干了些神马？别急，马上为你娓娓道来。

为了说明DUKPT流程，先介绍几个基本概念：

• BDK(Base Derivation Key)：DUKPT密钥体系的根密钥，一般是一个双倍长或三倍长的T-DES密钥。一定要保证它的安全性哦！

• KSN(Key Serial Number)：一串80bit的(20 hexadecimal digits)序号，由59bit的IKSN(Initial Key Serial Number)和21bit的EC(Encryption Counter)组成。所谓的“Unique Key Per Transaction”，全靠它啦！

• PEK(PIN Encryption Key)：顾名思义，加密PIN（卡片密码）的密钥咯！一般是双倍长的T-DES密钥。

依旧引用上图，我们单看POS和Acquirer Host这两个结点之间（其它结点之间的处理，基本类似）：

1. Acquirer在布放POS到Wal-Mart时，已经提前给这台POS的安全芯片中，灌输了BDK【BDK的灌输过程，是有Acquirer的安全部门保证的哦】，并：
   1> 生成了EC=0的Initial PEK：Initial PEK = PEK_Derive(BDK, KSN with EC=0)
   2> 销毁了终端中的BDK（保证BDK的安全性）
2. 当然，BDK在Acquirer Host中肯的是有保存的（不然他收到交易后怎么解密！）。别担心，一般来说Acquirer Host都是使用硬件加密机（HSM）保存密钥的，基本不会存在密钥泄漏的风险。
3. 重头戏来啦：Jacky在POS上进行刷卡交易，此时POS做了哪些事情呢？
   1> Current KSN = IKSN and EC++【即，Current KSN中的EC = 1】
   2> Current PEK = PEK_Derive(Initial PEK, Current KSN)
   3> Encrypted PIN = T-DES(Opr=Encrypt, Current PEK, Clear PIN)
4. 至此，Encrypted PIN已经得出来啦！POS开开心心的把Encrypted PIN放到交易报文里面，送给Acquirer Host咯。

5. 等等！POS只送出一个Encrypted PIN，真的够了吗？

   想一下，Acquirer Host收到交易报文之后，需要解密Encrypted PIN的哦！怎么解密？Clear PIN = T-DES(Opr=Decrypt, Current PEK, Encrypted PIN)
   【淡定，这个步骤是在HSM里面做的，只有HSM知道clear PIN，Acquirer Host的软件是不知道的哦】。

   问题又来了，Acquirer Host大叫：我怎么知道Current PEK是神马？我只知道BDK啊！
   Acquirer Host真是个笨蛋！人家POS都知道怎么算Current PEK，你咋不知道？同样的步骤算一下呗：
   1> Initial PEK = PEK_Derive(BDK, KSN with EC=0)
   2> Current PEK = PEK_Derive(Initial PEK, Current KSN)

   Acquirer Host再次大叫：我说了我只知道BDK啊！看看上面两个步骤的参数，我还需要Current KSN，才能算出Current PEK呢！

6. 好吧，POS不得不承认自己的错误：不好意思刚刚只在交易报文里面塞进了Encrypted PIN，忘了把Current EC塞进去啦！

   于是，POS不得不屁颠屁颠的把Encrypted PIN和Current KSN都塞进交易报文，送给Acquirer Host
   于是，Acquirer Host收到报文后，开开心心的解密成功，可以进行后续交易处理啦。

于是，我们总结一下上述流程：

1. 初始化：Acquirer Host和POS交互相同的BDK，且POS中销毁BDK，仅保存由BDK分散出来的Initial PEK
2. 发生交易时，POS的处理：再重复一遍，不就是上面的这些步骤么
   1> Current KSN = IKSN and EC++
   2> Current PEK = PEK_Derive(Initial PEK, Current KSN)
   3> Encrypted PIN = T-DES(Opr=Encrypt, Current PEK, Clear PIN)
   4> 把Current KSN和Encrypted PIN放到交易报文里面，发送给Acquirer Host
3. 收到交易时，Acquirer Host的处理：
   1> Initial PEK = PEK_Derive(BDK, KSN with EC=0)
   2> Current PEK = PEK_Derive(Initial PEK, Current KSN)
   3> Clear PIN = T-DES(Opr=Decrypt, Current PEK, Encrypted PIN)
   4> 后续交易处理

呼…说这么多，刚解释完DUKPT的第一轮计算方式…
亲，想想如果是你来设计这个算法，接下来该怎么处理EC=2、EC=3…EC=n的情况呢？留给大家些思考的空间吧【好吧我承认是我写的累了，想偷懒……】