一种基于TR34规范的POS机远程密钥灌装协议的设计方法与流程

一种基于tr34规范的pos机远程密钥灌装协议的设计方法
技术领域
1.本发明涉及pos机密钥灌装技术领域，具体是一种基于tr34规范的pos机远程密钥灌装协议的设计方法。


背景技术：

2.根据柯克霍夫原则：密码系统的安全性绝不能依赖于密码算法，安全性取决于对密钥的保密。在pos行业，金融交易安全最核心的问题是如何在整个密钥生命周期中保障交易密钥的安全。pos产品的传统密钥安装方式，通常需使用专门的kld(key loader device)设备在工厂或维修中心的安全环境下(kif)实现集中式本地密钥灌装(direct key injection,dki)。人工操作复杂且要求具备安全房环境，成本较高。因此越来越多客户转向使用更加便捷且同样满足安全要求的远程密钥灌装方式(remote key injection,rki)。将pos直接部署到最终商户环境，通过网络远程连接密钥服务器(rkms)实现金融交易密钥的注入和更新。
3.具有生产效率高，维护方便的优势。但同时由于使用rki方式远程灌装密钥需要在开放网络中传输密钥，需要设计完善的安全协议。
4.远程密钥灌装协议在pos终端和服务器后台间分发密钥，涉及甚广，目前国内各大银行及设备厂商均有推出各自的rki解决方案，市场暂缺乏一套规范统一的协议实现。而国际上针对远程密钥灌装，美国国家标准组织ansi已制定了成熟的tr34协议规范，其中详细描述了使用非对称技术分发对称密钥的协议实现，以及推荐的密钥灌装报文kt的格式规范要求，以达到对称密钥的安全交换。
5.标准tr34协议尚未在国内pos行业得到普及，主要由于其标准规范有以下2个不足之处：
6.其核心用于分发后续密钥的传输密钥由服务端产生，用pos终端证书公钥加密，下发后需要pos终端使用对应私钥解密，在rsa这类非对称算法中私钥运算的计算量是公钥运算的数倍，终端使用非对称私钥解密安装对称密钥执行效率低。
7.根据我国国家密码管理局商用密码检测中心的检测规范要求规定，在开放网络上做双向认证和密钥分发的系统需要使用双证书机制，即用于身份认证的签名证书和用于密钥加密的加密证书，必须是两本不同的证书，这就要求应用标准tr34协议的每台pos终端上都必须至少存在2本设备证书(一本用于对报文进行签名，一本用于对临时传输密钥ke的加解密)。这对pos终端厂商的ca发证系统带来成倍的维护成本，需要在设备出厂和维修时为每台设备注入2本设备证书。
8.针对以上提到的2点不足之处，本发明在tr34协议的基础上对协议流程进行优化，解决以上提到的2个缺点，提升rki的执行效率，并降低系统中证书的数量。


技术实现要素：

9.为解决上述问题，本发明提供一种基于tr34规范的pos机远程密钥灌装协议的设
计方法。
10.为了实现上述的技术目的，本发明所采用的技术方案为：
11.一种基于tr34规范的pos机远程密钥灌装协议的设计方法，rki中终端设备(krd)与服务器(kdh)之间通过pki技术实现双向身份认证，使用非对称加密与签名技术协商生成传输密钥kn，并使用会话密钥kn实现后续的密钥传输保护。
12.进一步的，rki流程分为init、keytransport、keyloading三个阶段；
13.init阶段：将标准tr34协议规范中bind阶段与keytransport阶段的第一步rt
krd
的生成流程进行整合；
14.keytransport阶段：kdh与krd协商出核心的传输密钥，用于后续keyloading阶段的密钥下发；
15.keyloadingd阶段：kdh使用协商的传输密钥kn加密后续需要下发的密钥，krd使用相同的传输密钥kn解密kdh下发密钥密文并安装，完成整个rki流程。
16.进一步的，init阶段：将标准tr34协议规范中bind阶段与keytransport阶段的第一步rtkrd的生成流程进行整合；具体步骤如下：
17.s101：krd发起rki请求
18.krd生成一个随机数r
krd
，使用krd证书私钥签名后生成rt
krd
，联同krd证书ct
krd
一起打包发送给kdh；
19.s102：kdh接收校验rki请求
20.kdh校验ct
krd
证书，并使用ct
krd
证书校验rt
krd
签名，确认终端合法性；
21.s103：kdh保存krd证书
22.kdh保存krd证书至本地，用于后续keytransport阶段时校验kt
krd
签名；
23.s104：kdh生成rki请求应答
24.kdh生成一个随机数r
kdh
，使用kdh签名证书ct
kdh_auth
私钥签名后生成rt
kdh
，联同kdh签名证书ct
kdh_auth
以及kdh加密证书ct
kdh_enc
一起打包发送给krd；
25.s105：krd校验kdh_auth、kdh_enc证书和rt
kdh
签名
26.krd校验kdh_auth和kdh_enc证书合法性，并使用ct
kdh_auth
证书校验rt
kdh
签名；
27.s106：krd保存r
kdh
、kdh_auth和kdh_enc证书
28.krd保存r
kdh
、kdh_auth和kdh_enc证书至本地，用于后续keytransport阶段时生成kt
krd
报文。
29.进一步的，keytransport阶段：kdh与krd协商出核心的传输密钥，用于后续keyloading阶段的密钥下发；具体步骤如下：
30.s201：krd生成此次用于密钥下发的传输密钥kn；
31.s202：krd生成临时加密密钥ke；
32.s203：krd生成密文密钥包
33.krd构造包含版本、终端id、密钥包头以及传输密钥kn的密钥包，并使用ke对其加密生成密文密钥包be；
34.s204：krd使用kdh密钥加密临时加密密钥ke35.krd使用init阶段保存的kdh加密证书ct
kdh_enc
公钥加密ke；
36.s205：krd构造最终的密钥灌装协议报文kt
krd
37.krd依照pkcs#7规范中定义的cms加密信封格式规范，构造kt
krd
；
38.s206：kdh解析校验kt
krd
并安装其中kn
39.kdh接收kt
krd
后遵循pkcs#7的规范格式解析其内容，比对r
kdh
值，使用init阶段s103保存的krd的公钥证书校验签名，使用kdh加密证书对应的私钥解密encryptedkey获取ke，再使用ke解密be获得最终的传输密钥kn。
40.进一步的，s203中be＝e
ke
(version||id
krd_cred
||kn||kbh)。
41.进一步的，s205中kt
krd
＝r
kdh
||kbh||encryptedkey||be||s
krd
(r
kdh
||kbh||encryptedkey||be)||crl
ca_krd
。
42.进一步的，s204中，krd使用init阶段保存的kdh加密证书ctkdh_enc公钥加密ke；encryptedkey＝e
kdh
(ke)。
43.基于上述，本发明还提供一种计算机可读的存储介质，所述的存储介质中存储有至少一条指令、至少一段程序、代码集或指令集，所述的至少一条指令、至少一段程序、代码集或指令集由处理器加载并执行实现上述基于tr34规范的pos机远程密钥灌装协议的方法。
44.本发明提出的基于标准tr34规范协议设计的新型rki协议，核心设计思路为调整rki密钥灌装协议流程，改为由krd终端生kn并使用服务端的加密公钥证书加密返回，由服务端负责用kdh私钥解密还原密钥，具有如下有益效果：
45.1)将非对称私钥运算的性能压力由pos终端转换到运算能力更强的云端，pos端只需要处理相对简单的公钥运算，降低终端的计算成本，从而可以选用成本更低廉的芯片方案来实现rki功能。
46.2)协议流程调整后终端只需要内置一本终端签名证书即可，减少了整个系统中证书的体量，有效降低pos终端证书的维护成本。
附图说明
47.为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
48.图1为本发明的流程示意图；
49.图2为本发明中rki系统框图；
50.图3为tr34标准协议流程示意图。
具体实施方式
51.为使本发明实施方式的目的、技术方案和优点更加清楚，下面将结合本发明实施方式中的附图，对本发明实施方式中的技术方案进行清楚、完整地描述，显然，所描述的实施方式是本发明一部分实施方式，而不是全部的实施方式。基于本发明中的实施方式，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施方式，都属于本发明保护的范围。因此，以下对在附图中提供的本发明的实施方式的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施方式。基于本发明中的实施方式，
本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施方式，都属于本发明保护的范围。
52.现有标准tr34规范中定义krd(key receiving device)表示接收注入密钥的终端。kdh(key distribution host)表示下发密钥的服务器。二者在密钥灌装之前的bind流程阶段中会互相交换校验对方的公钥证书并保存在本地；keytransport阶段kdh使用krd公钥加密下发传输密钥kn；keyloading阶段kdh与krd基于传输密钥kn实现密钥的加密分发。其协议完整流程如附图3所示。其中核心的keytransport阶段的详细实现步骤如下(如下表1所示)：
53.表1
[0054][0055][0056]
a1：krd生成终端随机数
[0057]
krd生成一个随机数r
krd
，并使用krd证书签名后生成此次rki流程的token：rt
krd
，发送给kdh。
[0058]
b1：kdh接收终端随机数
[0059]
kdh接收rt
krd
校验其签名，获取终端随机数r
krd
，并保存在本地。
[0060]
b2：生成要下发的传输密钥
[0061]
kdh生成对称算法类型的传输密钥kn。
[0062]
b3：生成临时加密密钥
[0063]
kdh生成临时的对称加密密钥ke。
[0064]
b4：生成密文密钥包
[0065]
kdh构造包含版本、终端id、密钥包头以及传输密钥kn的密钥包并使用ke对其加密生成密文密钥包be，其结构如下：
[0066]
be＝eke(version||idkdh_cred||kn||kbh)
[0067]
b5：加密临时加密密钥
[0068]
kdh使用bind阶段保存的krd证书公钥加密ke：
[0069]
encryptedkey::＝e
krd
(ke)
[0070]
b6：构造最终的密钥灌装协议报文kt
kdh
[0071]
kdh依照pkcs#7规范中定义的cms加密信封格式规范，组装kt
kdh
，其结构如下：
[0072]
kt
kdh
＝r
krd
||kbh||encryptedkey||be||s
kdh
(r
krd
||kbh||encryptedkey||
[0073]
be)||crl
ca_kdh
[0074]
a2：krd解析校验kt
kdh
并安装其中kn
[0075]
krd接收kt
kdh
后遵循pkcs#7的规范格式解析其内容，比对r
krd
值，使用kdh的公钥证书校验签名，使用krd证书对应的私钥解密encryptedkey拿到ke，再使用ke解密be获得最终的传输密钥kn。
[0076]
完成上述步骤后，在keyloading阶段krd与kdh基于kn来加密分发后续的其他工作密钥。
[0077]
上述标准tr34协议存在终端使用非对称私钥解密安装对称密钥执行效率低，以及应用标准tr34协议的每台pos终端上都必须至少存在2本设备证书的不足。
[0078]
为此，本发明提供了一种基于tr34规范的pos机远程密钥灌装协议的设计方法，rki中终端设备(krd)与服务器(kdh)之间通过pki技术实现双向身份认证，使用非对称加密与签名技术协商生成传输密钥kn，并使用会话密钥kn实现后续的密钥传输保护。rki流程分为init、keytransport、keyloading三个阶段；
[0079]
init阶段：将标准tr34协议规范中bind阶段与keytransport阶段的第一步rt
krd
的生成流程进行整合；具体步骤如下：
[0080]
s101：krd发起rki请求
[0081]
krd生成一个随机数r
krd
，使用krd证书私钥签名后生成rt
krd
，联同krd证书ct
krd
一起打包发送给kdh；
[0082]
s102：kdh接收校验rki请求
[0083]
kdh校验ct
krd
证书，并使用ct
krd
证书校验rt
krd
签名，确认终端合法性；
[0084]
s103：kdh保存krd证书
[0085]
kdh保存krd证书至本地，用于后续keytransport阶段时校验kt
krd
签名；
[0086]
s104：kdh生成rki请求应答
[0087]
kdh生成一个随机数r
kdh
，使用kdh签名证书ct
kdh_auth
私钥签名后生成rt
kdh
，联同kdh签名证书ct
kdh_auth
以及kdh加密证书ct
kdh_enc
一起打包发送给krd；
[0088]
s105：krd校验kdh_auth、kdh_enc证书和rt
kdh
签名
[0089]
krd校验kdh_auth和kdh_enc证书合法性，并使用ct
kdh_auth
证书校验rt
kdh
签名；
[0090]
s106：krd保存r
kdh
、kdh_auth和kdh_enc证书
[0091]
krd保存r
kdh
、kdh_auth和kdh_enc证书至本地，用于后续keytransport阶段时生成kt
krd
报文。
[0092]
keytransport阶段：kdh与krd协商出核心的传输密钥，用于后续keyloading阶段的密钥下发；具体步骤如下：
[0093]
s201：krd生成此次用于密钥下发的传输密钥kn；
[0094]
s202：krd生成临时加密密钥ke[0095]
s203：krd生成密文密钥包
[0096]
krd构造包含版本、终端id、密钥包头以及传输密钥kn的密钥包，并使用ke对其加密生成密文密钥包be；
[0097]
be＝e
ke
(version||id
krd_cred
||kn||kbh)
[0098]
s204：krd使用kdh密钥加密临时加密密钥ke[0099]
krd使用init阶段保存的kdh加密证书ct
kdh_enc
公钥加密ke；
[0100]
encryptedkey＝e
kdh
(ke)
[0101]
s205：krd构造最终的密钥灌装协议报文kt
krd
[0102]
krd依照pkcs#7规范中定义的cms加密信封格式规范，构造kt
krd
；kt
krd
＝r
kdh
||kbh||encryptedkey||be||s
krd
(r
kdh
||kbh||encryptedkey||be)||crl
ca_krd
[0103]
s206：kdh解析校验kt
krd
并安装其中kn
[0104]
kdh接收kt
krd
后遵循pkcs#7的规范格式解析其内容，比对r
kdh
值，使用init阶段s103保存的krd的公钥证书校验签名，使用kdh加密证书对应的私钥解密encryptedkey获取ke，再使用ke解密be获得最终的传输密钥kn。
[0105]
keyloadingd阶段：kdh使用协商的传输密钥kn加密后续需要下发的密钥，krd使用相同的传输密钥kn解密kdh下发密钥密文并安装，完成整个rki流程。
[0106]
实施例1
[0107]
本实施例中rki系统组成的逻辑框图如附图2所示：终端设备(krd)与服务器(kdh)之间通过pki技术实现双向身份认证，使用非对称加密与签名技术协商生成传输密钥kn，并使用会话密钥kn实现后续的密钥传输保护。优化后的rki协议流程如附图1所示；完整rkl流程分为init/keytransport/keyloading三个阶段。
[0108]
init阶段：将标准tr34协议规范中bind阶段与keytransport阶段的第一步rt
krd
的生成流程进行整合，具体步骤如下(如下表2所示)：
[0109]
表2
[0110]
[0111][0112]
a1：krd发起rki请求
[0113]
krd生成一个随机数r
krd
，使用krd证书私钥签名后生成rt
krd
，联同krd证书ct
krd
一起打包发送给kdh。
[0114]
b1：kdh接收校验rki请求
[0115]
kdh校验ct
krd
证书，并使用ct
krd
证书校验rt
krd
签名，确认终端合法性。
[0116]
b2：kdh保存krd证书
[0117]
kdh保存krd证书至本地，用于后续keytransport阶段时校验kt
krd
签名。
[0118]
b3：kdh生成rki请求应答
[0119]
kdh生成一个随机数r
kdh
，使用kdh签名证书ct
kdh_auth
私钥签名后生成rt
kdh
，联同kdh签名证书ct
kdh_auth
以及kdh加密证书ct
kdh_enc
一起打包发送给krd。
[0120]
a2：krd校验kdh_auth和kdh_enc证书，并校验rt
kdh
签名
[0121]
krd校验kdh_auth和kdh_enc证书合法性，并使用ct
kdh_auth
证书校验rt
kdh
签名；
[0122]
a3：krd保存r
kdh
、kdh_auth和kdh_enc证书
[0123]
krd保存r
kdh
、kdh_auth和kdh_enc证书至本地，用于后续keytransport阶段时生成kt
krd
报文。
[0124]
特别的本方案中krd终端只需集成一本krd签名证书ct
krd
即可。
[0125]
keytransport阶段：kdh与krd协商出核心的传输密钥，用于后续keyloading阶段的密钥下发，具体步骤如下(如下表3所示)：
[0126]
表3
[0127][0128][0129]
a1：生成此次用于密钥下发的传输密钥kn；
[0130]
a2：生成临时加密密钥ke；
[0131]
a3：生成密文密钥包
[0132]
krd构造包含版本、终端id、密钥包头以及传输密钥kn的密钥包，并使用ke对其加密生成密文密钥包be；
[0133]
be＝e
ke
(version||id
krd_cred
||kn||kbh)
[0134]
a4：使用kdh密钥加密临时加密密钥ke[0135]
krd使用init阶段保存的kdh加密证书ct
kdh_enc
公钥加密ke；
[0136]
encryptedkey＝e
kdh
(ke)
[0137]
a5：构造最终的密钥灌装协议报文kt
krd
[0138]
krd依照pkcs#7规范中定义的cms加密信封格式规范，构造kt
krd
；kt
krd
＝r
kdh
||kbh||encryptedkey||be||s
krd
(r
kdh
||kbh||encryptedkey||be)||crl
ca_krd
[0139]
b1：kdh解析校验kt
krd
并安装其中kn
[0140]
kdh接收kt
krd
后遵循pkcs#7的规范格式解析其内容，比对r
kdh
值，使用int阶段b2步
骤保存的krd的公钥证书校验签名，使用kdh加密证书对应的私钥解密encryptedkey拿到ke，再使用ke解密be获得最终的传输密钥kn。
[0141]
keyloading阶段：kdh使用协商的传输密钥kn加密后续需要下发的密钥，krd使用相同的传输密钥kn解密kdh下发密钥密文并安装，完成整个rki流程。
[0142]
本发明通过rki协议的完整流程设计，将原标准tr34规范中的bind阶段与keytransport阶段流程进行整合，减少协议双方的交互次数，提升了rki的执行效率。
[0143]
此外，本发明重新设计标准tr34规范中keytransport阶段的kn生成方案，改为由krd生成kn并用kdh的加密证书加密返回，依然是用标准tr34规范中规定的pkcs#7格式组织kt报文，保证了报文的安全性和合规性，支持现有系统的平滑升级。
[0144]
另外，在本发明各个实施方式中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。
[0145]
集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施方式方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-only memory)、随机存取存储器(ram，random access memory)、磁碟或者光盘等各种可以存储程序代码的介质。
[0146]
以上所述仅为本发明的优选实施方式而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。