seo排名点击器,网站如何进行优化,WordPress defcon,建设网站模板引入
关于POS机交易时的后台数据交互 模块之间数据交换#xff0c;都可以能被窃取或篡改。由此引入加密、解密机制和签名、验签机制
经典的加密、解密机制#xff1a;
对称加密#xff1a;DES\ TDES\ AES\ RC4
非对称加密#xff1a;RSA\ DSA\ ECC
经典的签名、验签…引入
关于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结构headerDATA 头部结构 B0144B1TX00N04000108000102080005KS18FFFF1100000000000000 数据部分TR-31图解说明 32字节的对KEY的加密值和8字节的数字指印 介绍: B0144B1TX00N0400写明了版本、长度、用途、加密方法等TR31密钥块分析 - 百度文库 01 08 0001 是 KeyName 值为 0x01 02 08 0005 是 KeySlot 0x00 KS18 FFFF1100000000000000 是 KSN值 DUKPTDerived Unique Key Per Transaction是被ANSI定义的一套密钥管理体系和算法用于解决金融支付领域的信息安全传输中的密钥管理问题应用于对称密钥加密MAC,PIN等数据安全方面。保证每一次交易流程使用唯一的密钥采用一种不可逆的密钥转换算法使得无法从当前交易数据信息破解上一次交易密钥。要求收单行与终端必须同步支持该项密钥管理技术。由交易发起端点S-TRSM,如posATM与交易接收端点R-TRSM,如收单行两部分组成。 如此总的框架就形成了基于上面的理论可以操作了但是对称加密部分如TDES因为key没变化生成的结果就不变保密性就弱了点那么需要更好的标准使其保密性更好。那么关于key的部分下面我们继续分解
ASN.1 TR31/TR34解析网址 KEY的保存与变更
先了解几个概念
DUKPT是由基础密钥BDK和KSN组成其中BDK是基础主密钥它派生出加密安全模块的初始密钥。初始密钥和KSN一起装入加密模块保证每个终端的主密钥都不重复。
BDKBase Derived Key是用于派生其他密钥的基础密钥。在金融行业和加密领域中BDK通常是一个16字节128位的密钥用于生成其他密钥如PIN加密密钥、MAC密钥等。BDK的安全性对整个加密系统至关重要因为它作为生成其他关键的基础。一般是一个双倍长或三倍长的T-DES密钥。
KSNKey Serial Number是由59bit设备标识IKSN(Initial Key Serial Number)和21bit交易次序EC(Encryption Counter)拼凑出的一种序列号。每次交易成功会加一KSN通常与加密操作一起使用特别是在金融交易领域用于生成派生密钥和跟踪加密设备的使用情况。
IPEKInitial Pin Encrypt Key是金融领域中用于加密和解密用户个人身份号码PIN的密钥。IPEK通常是从BDKBase Derivation Key派生而来通过一个特定的密钥派生函数生成。在金融交易中IPEK用于保护用户的PIN确保其传输和存储的安全性。PEK由PEK_IPEK、PEK_KSN生成 “FK” 通常指 “Future Key”。在密码学和安全领域中“Future Key” 指代在将来某个时刻用于加密或其他安全目的的密钥。因为交易时使用的加密的KEY每次都要生成为了减少交易的运算量通常会预存储21个FK交易后会更新使用过的KEY
“TK” 通常指 “Transaction Key”在金融领域中这是一个用于保护特定交易的密钥。与之前提到的 IPEKInitial Pin Encrypt Key和 BDKBase 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为固定的KEYLCL-KEK、BDK、DEK、PEK是由对应的key和ksn动态生成。
怎么验证下载的KEY为希望的KEY也就是 KCVKey Check ValuePOS机对用KEY对一串0进行加密返回一个值本地也做同样运算。如果结果相同则KEY正确否则错误。KCVKey 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(OprEncrypt, Current PEK, Clear PIN) 加密 4、把Current KSN和Encrypted PIN放到交易报文里面发送给Acquirer Host 收到交易时Acquirer Host的处理 1、 Initial PEK PEK_Derive(BDK, KSN with EC0) 2、Current PEK PEK_Derive(Initial PEK, Current KSN) 3、Clear PIN T-DES(OprDecrypt, 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
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博客
