零售交易流程相关知识（top-down拆解）

引入 

关于POS机交易时的后台数据交互

模块之间数据交换，都可以能被窃取或篡改。由此引入加密、解密机制和签名、验签机制

经典的加密、解密机制：

对称加密：DES\ TDES\  AES\ RC4

非对称加密：RSA\ DSA\ ECC

经典的签名、验签机制：

MD5\ SHA1\ SH256\ RSA\ MAC(Message Authentication Code)

通常网站对注册密码只保存签名而不保存真实的密码，但MD5\ SHA1\ SH256对以字符串签名结果是确定的，所以黑客可能通过签名的结果猜出密码，所以产生了mac。MAC使用的签名方式不变，但是添加了key，则生成的签名就完全变了，那么要破解就必须先破解对应的可以，增加了破解难度。

总体加解密流程拆解

对称加密TDES\  AES, 具有运算速度快的特点，但因为对称怎存在破解的风险。需要保证加解密双方具有相同的key。

非对称加密RSA公开密钥密码体制的原理是：根据数论，寻求两个大素数比较简单，而将它们的乘积进行因式分解却极其困难，因此可以将乘积公开作为加密密钥。

RSA具有运算速度慢，但破译风险很小的特点。加解密双方具有不相同的公钥和私钥。公钥是公开的，通常会发布到公共平台；而私钥是自己拥有，需要保密。

基于以上特点，设计通常用 非对称加密算法 传输对称加密的密钥，用 对称加密算法 对数据进行加密， 既保证了运算速度，有保证了保密性 ANS X9.24-2 Retail Financial Services Symmetric Key Management Part 2: Using Asymmetric Techniques for the Distribution of Symmetric Keys

RSA算法讲解：

 公钥加密、私钥解密、私钥签名、公钥验签
如下图所示双向对称加密双方都是有三个密钥的，比如：

组织\密钥	支付宝公钥	支付宝私钥	商家公钥	商家私钥
支付宝平台	拥有	拥有	拥有(商家上传)	没有
商家	拥有(支付宝平台下载)	没有	拥有	拥有

为了让大家分清楚这四者的区别，我们用支付宝支付进行举例，但是一定要知道两个前提：

密钥是有两对，支付宝公钥和私钥，商家公钥和私钥
公钥双方都会有（包括对方的），私钥只有自己拥有自己的，不会支付宝有商家私钥或者商家有支付宝私钥
当商户向支付宝发送订单请求时：
商户是用支付宝的公钥进行数据加密，用商户的私钥进行签名。
支付宝接收数据后
支付宝可以用支付宝私钥进行数据的解密，用商户的公钥进行验签。

当支付宝异步通知商户支付结果时：
支付宝是用商户的公钥进行数据加密，用支付宝私钥进行签名。
商户接收数据后
商户就用商户的私钥进行解密，用支付宝公钥进行验签。

结合上面的图表，这样大家就应该理解了吧。实际支付宝支付都有SDK，不用你进行实质的加密加签，只要你不把密钥传错就行了，这里也是举这个例子让大家了解RSA这种加密机制的安全性。

上面对需要通过互联网情况会起到很好的保密性，当然有部分情况不需那么保密，比如工厂生成中POS机下载KEY，那么对key进行对称加密解密就行，只需遵守一定协议就行。那么美国国家标准 TR-31基于对称加密的key互操作 应运而生

asc x9 tr 31-2018 Interoperable Secure Key Exchange Key Block Specification

TR31 load key的Raw Data结构（header+DATA）

头部结构

  B0144B1TX00N04000108000102080005KS18FFFF1100000000000000

数据部分TR-31图解说明

  32字节的对KEY的加密值和8字节的数字指印

介绍:

B0144B1TX00N0400：写明了版本、长度、用途、加密方法等TR31密钥块分析 - 百度文库

01 08 0001 是 KeyName ，值为 0x01

02 08 0005 是 KeySlot = 0x00

KS18  FFFF1100000000000000 是 KSN值

DUKPT（Derived Unique Key Per Transaction）是被ANSI定义的一套密钥管理体系和算法，用于解决金融支付领域的信息安全传输中的密钥管理问题，应用于对称密钥加密MAC,PIN等数据安全方面。保证每一次交易流程使用唯一的密钥，采用一种不可逆的密钥转换算法，使得无法从当前交易数据信息破解上一次交易密钥。要求收单行与终端必须同步支持该项密钥管理技术。由交易发起端点（S-TRSM,如pos，ATM）与交易接收端点（R-TRSM,如收单行）两部分组成。

如此总的框架就形成了，基于上面的理论可以操作了，但是对称加密部分如TDES因为key没变化，生成的结果就不变，保密性就弱了点，那么需要更好的标准使其保密性更好。那么关于key的部分下面我们继续分解

ASN.1 TR31/TR34解析网址

KEY的保存与变更

先了解几个概念：

DUKPT是由基础密钥BDK和KSN组成，其中BDK是基础主密钥，它派生出加密安全模块的初始密钥。初始密钥和KSN一起装入加密模块，保证每个终端的主密钥都不重复。

BDK（Base Derived Key）是用于派生其他密钥的基础密钥。在金融行业和加密领域中，BDK通常是一个16字节（128位）的密钥，用于生成其他密钥，如PIN加密密钥、MAC密钥等。BDK的安全性对整个加密系统至关重要，因为它作为生成其他关键的基础。一般是一个双倍长或三倍长的T-DES密钥。

KSN（Key Serial Number）是由59bit设备标识IKSN(Initial Key Serial Number)和21bit交易次序EC(Encryption Counter)拼凑出的一种序列号。每次交易成功会加一，KSN通常与加密操作一起使用，特别是在金融交易领域，用于生成派生密钥和跟踪加密设备的使用情况。

IPEK（Initial Pin Encrypt Key）是金融领域中用于加密和解密用户个人身份号码（PIN）的密钥。IPEK通常是从BDK（Base Derivation Key）派生而来，通过一个特定的密钥派生函数生成。在金融交易中，IPEK用于保护用户的PIN，确保其传输和存储的安全性。PEK由PEK_IPEK、PEK_KSN生成
“FK” 通常指 “Future Key”。在密码学和安全领域中，“Future Key” 指代在将来某个时刻用于加密或其他安全目的的密钥。因为交易时使用的加密的KEY每次都要生成，为了减少交易的运算量，通常会预存储21个FK，交易后会更新使用过的KEY

“TK” 通常指 “Transaction Key”，在金融领域中，这是一个用于保护特定交易的密钥。与之前提到的 IPEK（Initial Pin Encrypt Key）和 BDK（Base Derivation Key）等密钥相似，TK 也可能是从 BDK 派生出来的，用于对交易数据进行加密和解密。

DEK 通常指 “Data Encryption Key”，是用于加密和解密数据的密钥。这个密钥在加密系统中用于对用户数据、文件、通信等进行加密，以确保数据的保密性。 DEK 是对称密钥，这意味着相同的密钥用于加密和解密过程。由DEK_IPEK、DEK_KSN构成，来生成加密用的DEY

HSM (Host Security Module) 用于向POS机下载PEK、DEK的设备（遵循TR31协议）

LCL-KEK （Key Encryption Key）用于下载KEY的时候，对PEK、DEK进行加密，由LCL_KEK_IPEK、LCL_KEK_KSN构成，来生成加密的KEY

 所有的KSN每次交易后都会加一，用来保证每次生成的密钥不同

由以上介绍可以推理，在POS出厂前必须至少下载好LCL-KEK、 BDK、常用的CA证书（RSA使用），其他DEK、PEK、Salt、MAC等相关的key可以通过TR31或TR34交互下载，当然也可以直接下载。Salt、MAC为固定的KEY，LCL-KEK、BDK、DEK、PEK是由对应的key和ksn动态生成。

怎么验证下载的KEY为希望的KEY，也就是 KCV（Key Check Value），POS机对用KEY对一串0进行加密返回一个值，本地也做同样运算。如果结果相同则KEY正确，否则错误。KCV（Key Check Value）算法示例

POS和Acquirer Host的交易流程：交易流程很易懂的解释

初始化：Acquirer Host和POS交互相同的BDK，且POS中销毁BDK，仅保存由BDK分散出来的Initial PEK
发生交易时，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
收到交易时，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、后续交易处理

对于怎么派生新的密钥PEK_DERIVE的步骤如下图：

简要说明：

1. 黄色底色的2个框框，是PEK_DERIVE的2个入参；绿色底色的框框，是PEK_DERIVE的结果

2. 图中的“Set Bit”（右边KSN的黄色框框 下面的步骤），是一个很简单的步骤：

   • 取KSN中最右边的21bit的EC（例如，01100000…1000，共21bit）
   • 得到EC中最右侧的bit “1”（01100000…1 000）
   • 将EC其余bit置为0，即获得Set Bit的结果（00000000…1 000）

https://codeload.github.com/chhil/TR31Keyblock/zip/refs/heads/main 这是java版本的，TR31Keyblock-main\src\main\java\org\keyblock\tr31\KeyHelper.java文件夹下存在类似的密钥生成代码

其他官方github上 C代码 

GitHub - openemv/dukpt: ANSI X9.24 DUKPT libraries and tools

GitHub - openemv/tr31: Key block library and tools for ANSI X9.143, ASC X9 TR-31 and ISO 20038

1. ANS X9.24 Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques: 2004
2. ANS X9.24 Retail Financial Services Symmetric Key Management Part 2: Using Asymmetric Techniques for the Distribution of Symmetric Keys; (draft) 
3. ANS X3.92 Data Encryption Algorithm (DEA) 
4. ANS X9.52:1998 Triple Data Encryption Algorithm Modes of Operations 
5. ISO 9797: 1999 Information technology -- Security techniques -- Message Authentication Codes (MACs) -- Part 1: Mechanisms using a block cipher 
6. ISO 9797: 2011 Information technology -- Security techniques -- Message Authentication Codes (MACs) -- Part 1: Mechanisms using a block cipher 
7. ANS X9 TR-39: TG 3 PIN Security Compliance Guideline 
8. ANS X9 TG 7 Initial DEA Key Distribution for PIN Entry and Transaction Originating Devices Guideline 
9. ISO 16609-2004, Banking – Requirements for message authentication using symmetric techniques 
10. NIST SP 800-38B, Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication 
11. NIST SP 800-108, Recommendation for Key Derivation Using Pseudorandom Functions. 
12. FIPS 197 Advanced Encryption Standard (AES), November 26, 2001 
13. FIPS 198-1 The Keyed-Hash Message Authentication Code (HMAC), July 2008

DUKPT、BDK和KSN：金融交易中的加密密钥体系详解-CSDN博客

DUKPT IPEK KSNPOS机的加密传输过程_ipek和bdk-CSDN博客

Java实现RSA工具类（加密、解密、签名、验签）_java rsa工具类-CSDN博客

DUKPT(derived unique key per Transaction)-CSDN博客