做支付终端、POS、密码键盘或者银行卡收单系统的同学，应该都绕不过“PIN加密”这道坎。用户在密码键盘上按下的那6位银行卡密码，在安全模块内部会被包装成标准的PIN Block，再用算法加密成密文上送后台。今天要聊的这套方案，就是金融领域最常见的组合之一：SM4 ECB模式 + ANSI X9.8 PIN Block格式，重点是带主账号（PAN）参与的加解密流程。这篇内容适合支付应用开发、密码键盘固件开发、接口联调测试以及刚接触金融数据安全的工程师参考，我会把格式结构、PAN取位、补位方式、代码实现和踩坑经验都过一遍。
1. 需求拆解与方案选型
1.1 PIN加密在支付链路中的位置
银行卡密码的泄露风险集中在传输环节。如果密码键盘把明文密码直接发给终端或收银机，那中间任何一个环节被截获，密码就没了。所以行业通行做法是：密码明文只存在于密码键盘的安全模块内部，从按键采集完成的那一瞬间起，到加密输出为止，其他任何部件都碰不到明文。密码键盘输出的是加密后的PIN Block，收发双方约定同一种格式和同一种算法，才能完成校验。
这里说的“PIN Block”不是简单把密码塞进加密函数，而是要遵循一套统一摆放规则。国际上常用ANSI X9.8，国内金融领域也大量沿用同一套思路。再加上国密合规要求，越来越多新增设备要求用SM4替代3DES，于是就有了“SM4 ECB + ANSI X9.8”这种组合。理解这个组合，需要把它拆成三层：第一层是PIN Block的格式规则（怎么摆），第二层是主账号信息参与（怎么增加差异化），第三层是分组加密算法和模式（怎么加密）。
1.2 为什么选SM4、ECB和X9.8这套组合
我在实际项目里见过不少方案对比表，这里直接说结论。老一代支付系统大量使用3DES或DES，但随着金融国密标准推进，新建系统和存量改造都在向SM4迁移。SM4是分组长度128比特、密钥长度128比特的国密算法，在硬件密码键盘、HSM（硬件加密机）、POS终端和手机支付组件里都有成熟实现，计算速度也不差。
ECB模式看起来“朴素”，但在PIN加密场景里反而常见。原因有两个：一是典型的ANS X9.8 PIN Block只有8字节，SM4一个分组是16字节，ECB模式下只需要处理一个分组的补位，逻辑最简单；二是PIN加密通常发生在密码键盘或加密机内部，每次交易输入的是独立PIN Block，不像文件加密那样需要把多个分组串联起来防篡改。ECB的短板是相同明文会得到相同密文，所以必须依靠密钥定期更换、交易流水号、挑战值等机制兜底。这个风险我在后面第5节会专门讲。
至于X9.8，关键点是带主账号信息。如果把所有账号的PIN都按同一套格式加密，两个用户选了同一个密码，PIN Block密文就会完全一致，攻击者拿一个用户的密文可以直接重放到另一个用户身上。X9.8格式0用PAN参与异或，让不同账号即使使用相同密码，生成的PIN Block也不一样，从源头把这一风险摁住了。这也是标题里“带主账号信息”这几个字的核心价值。
2. ANSI X9.8 PIN Block格式深度解析
2.1 PIN Block结构拆解：控制字节、PIN位、填充位
ANSI X9.8里有好几种格式，实际落地最广的是Format 0。这个格式固定8字节，核心结构分为三个部分：
- 第1个字节是控制字节，高4位保留为0，低4位表示PIN长度；
- 从第1字节的低半字节开始，依次存放每一位PIN数字；
- PIN数字摆完之后，所有剩余半字节统一填充0xF。
我举个例子，假设PIN是6位“123456”：
字节0: 0x06 ← 高4位0，低4位6，代表长度6 字节1: 0x12 ← 第1位1，第2位2 字节2: 0x34 ← 第3位3，第4位4 字节3: 0x56 ← 第5位5，第6位6 字节4: 0xFF ← 填充 字节5: 0xFF ← 填充 字节6: 0xFF ← 填充 字节7: 0xFF ← 填充这里有个容易踩坑的细节：控制字节的值不是固定0x06，它跟着PIN长度变。PIN如果是4位，控制字节是0x04；PIN是12位，控制字节就是0x0C。很多初学者看到别人代码里写死0x06，结果换成4位PIN就解析错了。正确做法是低4位动态填长度。
如果PIN长度是奇数，比如5位“12345”，那第3个字节会变成0x5F，即第5位数字在高半字节，低半字节补0xF。这个细节解密时也要对称处理，后面代码里我用了半字节数组来规避手动移位容易搞错的问题。
2.2 主账号PAN的处理：去掉校验位，取后12位
X9.8 Format 0和普通PIN Block最大的区别就是额外有一个PAN参与异或。PAN本身不需要保密，银行卡号都是公开信息，直接参与运算不会泄露PIN，但它能让PIN Block在不同账号之间区分开。
PAN的处理规则是：先去掉卡号最后一位校验位，然后取剩下数字的后12位，不足12位前面补0。比如卡号是“6222760012345678”，最后一位8是校验位，去掉后得到“622276001234567”，再取后12位就是“276001234567”。注意不是直接取原始卡号的后12位，那样会把校验位卷进来，导致两端计算结果不一致。
取出的12位数字要转换成BCD码，放到一个新的8字节块里。X9.8里这个块的结构是：前2字节填0x00，后6字节放12位PAN数字的BCD编码。还是用刚才的例子：
PAN: 6222760012345678 去掉校验位: 622276001234567 取后12位: 276001234567 PAN Block: 0x00 0x00 0x27 0x60 0x01 0x23 0x45 0x67到这里，手头就有两个8字节块：一个是PIN明文块，一个是PAN块。接下来把两个块逐字节异或，得到的8字节结果才是真正交给加密算法的“格式化PIN块”。
为什么标准要这么设计？因为如果没有这一步异或，两个不同账号如果选了同一个PIN，明文块完全一样，加密以后密文也完全一样，攻击者可以跨账号重放。加了PAN异或之后，即使两个账号的PIN相同，XOR之后的结果也不同，密文自然不同。
2.3 一个完整的手算实例：从PIN和PAN到最终密文
为了避免联调时两眼一抹黑，我习惯把过程完整摊开算一遍。继续用上面的例子：
PIN: 123456 PIN明文块: 0x06 0x12 0x34 0x56 0xFF 0xFF 0xFF 0xFF PAN Block: 0x00 0x00 0x27 0x60 0x01 0x23 0x45 0x67逐字节异或：
0x06 XOR 0x00 = 0x06 0x12 XOR 0x00 = 0x12 0x34 XOR 0x27 = 0x13 0x56 XOR 0x60 = 0x36 0xFF XOR 0x01 = 0xFE 0xFF XOR 0x23 = 0xDC 0xFF XOR 0x45 = 0xBA 0xFF XOR 0x67 = 0x98异或后的PIN Block：
0x06 0x12 0x13 0x36 0xFE 0xDC 0xBA 0x98这里能直观看到，即使两个用户都输入“123456”，只要卡号不同，PAN Block就不同，异或结果也就不同。联调的时候，强烈建议先把这一步的十六进制打出来和对方比对，前面几步对了，后面加解密才能真正对得上。
3. SM4在PIN加密里的落地细节
3.1 SM4分组长度与PIN Block的补位问题
SM4是分组长度为16字节的算法，而X9.8格式0的PIN Block只有8字节。这里就出现了一个无法回避的问题：8字节怎么喂给16字节分组的SM4？
在不同厂家密码键盘上，这个处理方式并没有完全统一。我见过的主流做法有两种：一种是把8字节PIN Block放在16字节缓冲区的高8字节，低8字节补0；另一种是放在低8字节，高8字节补0。两种方式从算法安全性上没有本质差别，但对端如果实现不一样，联调时就是“密文对不上”。
我下面的示例代码采用“PIN Block放在高8字节，低8字节补0”的方式，也就是16字节明文前8字节全0，后8字节是XOR后的PIN Block。这里一定要提醒一句：具体采用哪种补位方式，以你对接的密码键盘或加密机文档为准，这一步在跨厂商联调中非常关键。理论上，如果两端文档一致，用什么补位都行。
采用这种补位方式，刚才手算得到的8字节PIN Block，扩展成16字节后就是：
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x06 0x12 0x13 0x36 0xFE 0xDC 0xBA 0x98然后交给SM4 ECB加密。SM4密钥长度是16字节，我示例里用固定key：
0123456789ABCDEFFEDCBA9876543210生产环境肯定不能用固定key，密钥要由密钥管理体系生成，通过主密钥加密后灌注进密码键盘或加密机，具体要看安全规范。
3.2 ECB模式的适用边界和安全兜底
ECB模式最大的特征是每个分组独立加密，分组之间没有链接关系。好处是简单、可并行、出错只影响当前分组；坏处是相同明文必然产生相同密文，攻击者可以根据密文重复性判断明文关系。
在PIN加密这个场景里，X9.8的PAN异或已经让不同账号之间的PIN Block实现差异化，但同一张卡如果反复输入同一个PIN，加密后的PIN Block仍是一样的。针对这一点，支付系统通常用两层来兜底：一层是交易层加上随机数、流水号、挑战值等要素，使得单条密文无法脱离交易上下文被使用；另一层是工作密钥定期更换或按交易分散，让相同明文在不同时间窗口下密文不同。这属于安全设计范畴，但作为实现PIN加解密的人，心里要有这根弦。
另外，SM4 ECB在Java里的实现依赖BouncyCastle，算法名称一般写成“SM4/ECB/NoPadding”。因为明文已经是16字节整，NoPadding即可，不需要再做PKCS#5或者PKCS#7填充。如果算法名称写成了PKCS7Padding，虽然也能跑，但会多发一个分组，和厂商结果对不上，属于低级但真要命的坑。
4. 完整代码示例：Java实现带PAN的SM4 PIN加解密
4.1 依赖准备
我用Java加BouncyCastle来实现，工程里先引入bcprov依赖。如果你用的是Maven，可以加：
<dependency> <groupId>org.bouncycastle</groupId> <artifactId>bcprov-jdk18on</artifactId> <version>1.78</version> </dependency>如果是其他版本，只要包含SM4算法实现即可。代码中加一个静态块把BouncyCastleProvider注册到JCE框架里，后面才能用标准Cipher接口调SM4。
4.2 半字节合成与PAN处理工具方法
先提供两个小工具。第一个是把由半字节组成的数组压缩成字节数组，第二个是把卡号转成X9.8格式的PAN Block。半字节数组的方式最直观，不会搞错高低位顺序。
private static byte[] nibblesToBytes(int[] nibbles) { if (nibbles.length != 16) { throw new IllegalArgumentException("nibbles length must be 16"); } byte[] out = new byte[8]; for (int i = 0; i < 8; i++) { int high = nibbles[i * 2] & 0x0F; int low = nibbles[i * 2 + 1] & 0x0F; out[i] = (byte) ((high << 4) | low); } return out; } private static byte[] buildPanBlock(String pan) { if (pan == null || pan.length() < 13) { throw new IllegalArgumentException("PAN length must be >= 13"); } String panWithoutCheck = pan.substring(0, pan.length() - 1); String pan12 = panWithoutCheck.substring(Math.max(0, panWithoutCheck.length() - 12)); if (pan12.length() < 12) { pan12 = String.format("%012d", Long.parseLong(pan12)); } int[] nibbles = new int[16]; // 前4个半字节为0 for (int i = 0; i < 4; i++) { nibbles[i] = 0x00; } // 后12个半字节放PAN数字 for (int i = 0; i < 12; i++) { nibbles[4 + i] = pan12.charAt(i) - '0'; } return nibblesToBytes(nibbles); }注意我这里的半字节数组固定16个半字节，对应8个字节。前4个半字节是0x00，也就是填充了两个字节；后12个半字节是PAN的12位数字。
4.3 构造ANSI X9.8 PIN明文块与加入PAN异或
接下来构造PIN明文块，同样使用半字节数组。第一个半字节固定0，第二个半字节是PIN长度，后面依次放PIN数字，剩余全部填0xF。这样无论PIN长度是4还是12，都不用纠结奇数位填充。
private static byte[] buildPinBlockWithPan(String pin, String pan) { if (pin == null || pin.length() < 4 || pin.length() > 12) { throw new IllegalArgumentException("PIN length must be between 4 and 12"); } int[] nibbles = new int[16]; for (int i = 0; i < 16; i++) { nibbles[i] = 0x0F; // 先全部填F } nibbles[0] = 0x00; nibbles[1] = pin.length(); for (int i = 0; i < pin.length(); i++) { char c = pin.charAt(i); if (c < '0' || c > '9') { throw new IllegalArgumentException("PIN must be digit"); } nibbles[2 + i] = c - '0'; } byte[] pinBlock = nibblesToBytes(nibbles); byte[] panBlock = buildPanBlock(pan); byte[] result = new byte[8]; for (int i = 0; i < 8; i++) { result[i] = (byte) (pinBlock[i] ^ panBlock[i]); } return result; }这个方法返回的8字节数组，就是第2.3节手算得到的异或结果。到这里，格式相关的工作已经完成。
4.4 SM4 ECB加解密方法
把8字节PIN Block扩展为16字节，然后走SM4。我这里选择PIN Block放在高8字节，也就是低8字节补0。如果你对接的厂商要求反向补位，把System.arraycopy那段调整一下即可。
private static final byte[] SM4_KEY = hexToBytes("0123456789ABCDEFFEDCBA9876543210"); private static byte[] sm4EncryptPinBlock(byte[] pinBlockWithPan) throws Exception { byte[] plain = new byte[16]; System.arraycopy(pinBlockWithPan, 0, plain, 8, 8); // 低8字节补0 Cipher cipher = Cipher.getInstance("SM4/ECB/NoPadding", "BC"); SecretKeySpec keySpec = new SecretKeySpec(SM4_KEY, "SM4"); cipher.init(Cipher.ENCRYPT_MODE, keySpec); return cipher.doFinal(plain); } private static String sm4DecryptPinBlock(byte[] cipherData, String pan) throws Exception { Cipher cipher = Cipher.getInstance("SM4/ECB/NoPadding", "BC"); SecretKeySpec keySpec = new SecretKeySpec(SM4_KEY, "SM4"); cipher.init(Cipher.DECRYPT_MODE, keySpec); byte[] plain = cipher.doFinal(cipherData); // 取高8字节 byte[] pinBlockWithPan = new byte[8]; System.arraycopy(plain, 8, pinBlockWithPan, 0, 8); // 异或PAN Block，还原PIN明文块 byte[] panBlock = buildPanBlock(pan); byte[] pinBlock = new byte[8]; for (int i = 0; i < 8; i++) { pinBlock[i] = (byte) (pinBlockWithPan[i] ^ panBlock[i]); } int pinLength = pinBlock[0] & 0x0F; if (pinLength < 4 || pinLength > 12) { throw new IllegalArgumentException("invalid pin length in block"); } StringBuilder sb = new StringBuilder(); for (int i = 0; i < pinLength; i++) { int digit; if (i % 2 == 0) { digit = (pinBlock[1 + i / 2] >> 4) & 0x0F; } else { digit = pinBlock[1 + i / 2] & 0x0F; } sb.append((char) ('0' + digit)); } return sb.toString(); }解密时，先SM4解密得到16字节数组，取出高8字节，再与PAN Block异或，最后从控制字节的低4位读PIN长度，依次把PIN数字解析出来。这里也验证了补位方式必须双方一致：如果对方用低8字节放PIN Block，高8字节补0，那我取高8字节就全成0了，PIN自然解不出来。
4.5 一个可运行的验证主程序
下面给一个简单的验证入口，把加密输出的Hex和解密还原的PIN都打出来。如果打印结果和手算一致，说明格式链路上没有大问题。
public static void main(String[] args) throws Exception { String pan = "6222760012345678"; String pin = "123456"; byte[] pinBlock = buildPinBlockWithPan(pin, pan); System.out.println("XOR后的PIN Block: " + bytesToHex(pinBlock)); byte[] encrypted = sm4EncryptPinBlock(pinBlock); System.out.println("SM4加密密文: " + bytesToHex(encrypted)); String decryptedPin = sm4DecryptPinBlock(encrypted, pan); System.out.println("解密还原PIN: " + decryptedPin); System.out.println("结果校验: " + pin.equals(decryptedPin)); }这个方法里的bytesToHex是常规工具，我就省略了。跑起来后，XOR后的PIN Block应该打印出06121336FEDCBA98，解密还原的PIN应该是123456。如果你拿到的结果不一样，大概率是PAN取位或者半字节摆放出了问题。
5. 常见问题与排查技巧实录
5.1 高频问题速查表
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 加密后和厂商密文不一致 | 补位方式不同，或SM4算法名写错 | 确认对方PIN Block放在16字节的高8位还是低8位 |
| 解密后PIN完全乱码 | PAN取位方式不对 | 确认是否跳过校验位，后12位是否选对 |
| 控制字节解析出的长度异常 | PIN明文块构造时半字节位置错位 | 优先用半字节数组构造，避免手动移位 |
| 同一个卡号同一个PIN密文固定 | ECB模式固有特性，不属于格式错误 | 交易层加流水号、随机数，密钥定期更换 |
| SM4报IllegalArgumentException，输入不是16字节整 | 明文没有补位到16字节 | 检查是否漏了补位，或错误使用了PKCS7Padding |
| 两端解出来PIN第一位是0 | 半字节高低位反转 | 检查BCD编码时是高位在前还是低位在前 |
这张表基本覆盖了我联调时遇到的大部分情况，尤其是跨厂商密码键盘时，“补位方式不一致”是我见过最多的问题。
5.2 三个高频坑详解
第一个坑是PAN取位。关于“后12位”，标准文档里经常写“不包含校验位的最右侧12位”，但不同人对这句话理解不一样。有人直接取PAN字符串的后12位，结果校验位混进去了，差一位就全盘错。我自己调试时养成一个习惯：先用一个已知卡号手工算一遍，把PAN Block的十六进制打印出来，再往下走。
第二个坑是控制字节。第一次做这个功能的时候，我看到别人代码里写了byte control = 0x06，以为所有PIN都是这个值。后来测试同事拿4位PIN来验，解密出来长度变成6，直接翻车。控制字节低4位必须动态反映实际PIN长度，不能写死。
第三个坑是填充半字节。构造PIN明文块时，最稳妥的办法是先把16个半字节全部初始化为0xF，再从第3个半字节开始覆盖PIN数字，第1个半字节放0，第2个半字节放长度。如果先挖了数组再逐位填F，很容易漏掉某些半字节，导致后面填充变成0x00而不是0xFF。用“先全填F再覆盖”的思路，可以少操很多心。
5.3 联调技巧：怎么快速定位是哪一步错了
联调时如果对不上密文，我习惯按下面顺序逐步缩小范围：
第一步，先不看SM4，只对比XOR后的8字节PIN Block。很多厂商接口会提供类似“明文PIN Block”的输出，双方各自打印，手工比对前三个字节。前三个字节能对上，说明格式构造没问题。
第二步，确认补位方式。把16字节明文整体打印出来，看看是低8字节补0还是高8字节补0。这一步不花时间确认，后面全都是白干。
第三步，确认SM4密钥。固定key联调时，双方约定好一个测试key，先加解密一个全0的16字节块，两边的密文一致，说明算法链路没问题，再进入PIN流程。
第四步，最后才看PAN处理。PAN参与异或的结果通常是最后一个发现的问题，因为前面三重校验都过了，逻辑上已经很接近，但卡号多一位少一位都会导致最终结果不同。
6. 写在最后的实操体会
整个流程走下来，我的感觉是：PIN加密本身不难，难的是每一步的“小约定”。PIN Block格式有ANSI X9.8做标准，但PAN取位、控制字节低位、SM4补位方式、ECB分组边界，这些细节在不同厂商实现里都存在差异。实际联调时不要只看接口文档，最好让双方各打印中间过程的十六进制，从XOR结果开始比对，再逐层往算法层推进，这种调试方式最省时间。另外，不要把ECB模式当作包打天下的方案，它在PIN加密这种独立分组场景里够用，但安全边界要靠交易层和密钥体系来守。代码里用固定key只是演示，生产环境一定要走正规密钥灌装流程，并且要按规范定期换密钥。最后再提一句小技巧：测试阶段准备一个既能加密又能解密的工具类在本地跑通，远比你对着密文猜问题来得高效，这套代码可以直接拿去做联调脚手架。
