引入
关于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的部分下面我们继续分解
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的步骤如下图：
简要说明：
-
黄色底色的2个框框，是PEK_DERIVE的2个入参；绿色底色的框框，是PEK_DERIVE的结果
-
图中的"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
-
ANS X9.24 Retail Financial Services Symmetric Key Management Part 1: Using Symmetric Techniques: 2004
-
ANS X9.24 Retail Financial Services Symmetric Key Management Part 2: Using Asymmetric Techniques for the Distribution of Symmetric Keys; (draft)
-
ANS X3.92 Data Encryption Algorithm (DEA)
-
ANS X9.52:1998 Triple Data Encryption Algorithm Modes of Operations
-
ISO 9797: 1999 Information technology -- Security techniques -- Message Authentication Codes (MACs) -- Part 1: Mechanisms using a block cipher
-
ISO 9797: 2011 Information technology -- Security techniques -- Message Authentication Codes (MACs) -- Part 1: Mechanisms using a block cipher
-
ANS X9 TR-39: TG 3 PIN Security Compliance Guideline
-
ANS X9 TG 7 Initial DEA Key Distribution for PIN Entry and Transaction Originating Devices Guideline
-
ISO 16609-2004, Banking -- Requirements for message authentication using symmetric techniques
-
NIST SP 800-38B, Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication
-
NIST SP 800-108, Recommendation for Key Derivation Using Pseudorandom Functions.
-
FIPS 197 Advanced Encryption Standard (AES), November 26, 2001
-
FIPS 198-1 The Keyed-Hash Message Authentication Code (HMAC), July 2008
DUKPT、BDK和KSN：金融交易中的加密密钥体系详解-CSDN博客
DUKPT IPEK KSNPOS机的加密传输过程_ipek和bdk-CSDN博客