一种移动支付单元支付系统和安全支付方法
【专利摘要】本发明公开一种移动支付单元支付系统和安全支付方法，安装于移动智能通讯终端的应用程序APP，设置于移动智能通讯终端的移动支付单元，接受或者拒绝支付请求的支付服务器，移动支付单元包含移动身份识别模块和加密模块，移动支付单元、APP、支付服务器分别对发出或接收的移动支付请求的相关信息进行加密和解密，所述的支付服务器鉴别移动支付单元及APP的身份合法性，并对支付请求发出接收或者拒绝的命令。可以满足人们随时随地安全的移动支付的需求，其安全性可以超过UKEY电脑支付的安全性，使人们不必带着电脑就可以随时随地安全移动支付。
【专利说明】一种移动支付单元支付系统和安全支付方法
【技术领域】
[0001] 本发明涉及移动支付领域，特别是一种移动支付单元、以及基于移动支付单元的 支付系统和安全支付方法。
【背景技术】
[0002] 随着智能手机的普及以及移动支付需求的日益增加，人们需要一种更加方便简洁 的方式来完成日常的ATM机银行服务、网上银行的功能和移动支付的功能。现有的移动支 付有大约三种基本被认可的方案：（1)利用SWP+NFC技术实现小额离线支付。（2)直接利用 App 进行银行转账或支付。（3)TSM(Trusted Service Management)技术。
[0003] 移动支付的以上三种方法存在如下弊端：
[0004] (l)SWP主要是解决近程小额下线支付，但解决不了安全的在线支付或银行转账的 服务。（2)而App存在着非常严重的安全漏洞，特别是在安卓系统上，即使是增加短信发送 密码的增强功能。（3) TSM技术是想通过特定的下载中心来授权下载App，再加上手机上安 装特别的安全保密芯片（SE芯片）的方法实现一个安全的运行环境。但安卓系统是一个开 放的平台，实现不了所谓安全的运行环境。即使是Apple手机的不开放的iOS平台，刚发布 几天，就一次次被人破解越狱一样，总有一天会被人攻破。而且TSM方案需要建设额外的 Infrastructure，需要额外的在手机上安装SE芯片，成本很高，以及存量手机无法兼容TSM 的问题。
[0005] 目前比较认可的在电脑上的网银转账购物等活动是通过UKey或者令牌的方式来 实现，在各银行的实践中，也基本认可了 UKey或者令牌的安全性。Ukey已经有一代和二代 key的发展了。二代Key的产生主要是解决一代Key在使用中的安全隐患。一代Key的问 题本质上是：一代Key是一个开环，缺乏安全的双向鉴权，无法根除"man-in-the-middle" 的攻击手段，因此产生不安全的问题。该攻击手段的描述于1995年首先被Mr Gavin Lowe 在论文中提出。攻击程序处于UKEY和银行之间，模拟出伪造的交易需求和交易数据向银行 和UKEY分别提交，从而获得合法的PKI签名。
[0006] 二代Key是通过两种方法来解决一代Key的安全隐患的：（1)利用客户自己的眼 睛和大脑再次确认交易及交易数据的合法性（2)客户必须按一下Key上的按键确认，UKEY 才对交易数据签名，这是个物理操作，利用物理隔离使得黑客软件无法何获得PKI签名。
[0007] 综上所述UKEY缺陷是：保证了密钥和交易数据具有身份认证、完整性、机密性、不 可否认性等功能，但不能保证交易本身具有合法授权。
[0008] UKEY的方式一定程度上大大方便了人们的生活，不需任何事情都到银行柜台排队 办理，但是随着电子商务的发展以及快节奏生活成为主流，人们有随时随地安全转账或者 交易付款的需求，但是不会随时随地都带着电脑和UKEY，从而目前的移动支付手段在不能 满足高水平的安全保障下无法满足人们随时随时实现支付。
【发明内容】
[0009] 本发明提供一种新的移动支付的解决方案，可以满足人们随时随地安全的移动支 付的需求，其安全性可以超过UKEY电脑支付的安全性，使人们不必带着电脑就可以随时随 地安全移动支付。
[0010] 本发明通过以下技术手段实现：
[0011] 一种移动支付单元，包含移动身份识别模块和加密模块，所述的加密模块包括0ΤΑ 加密单元和至少一组的基于PKI的加密单元；所述的移动身份识别模块登陆GSM网络确定 移动支付用户的唯一身份，并通过GSM网络为移动支付用户建立支付信息上传或下载的管 道，所述的加密模块用于加密移动支付用户请求的支付信息。
[0012] 进一步的，所述的PKI加密单元通过授权方写入PKI信息。
[0013] 进一步的，所述的授权方为决定或者拒绝支付的一个或者多个支付服务器。
[0014] 一种基于移动支付单元的移动支付系统，包含安装于移动智能通讯终端的应用程 序APP，设置于移动智能通讯终端内的移动支付单元，接受或者拒绝支付请求的支付服务 器，所述的移动支付用户通过APP发起支付请求，所述的支付请求通过无线网络发送给支 付服务器，在此过程中，移动支付单元、APP、支付服务器分别对发出或接收的移动支付请求 的相关信息进行加密和解密，所述的支付服务器鉴别移动支付单元和APP的身份合法性， 并对支付请求发出接收或者拒绝的命令。
[0015] 进一步的，在初始化条件下，所述的支付服务器获取并保存移动支付单元的唯一 身份信息，并将相应的PKI信息写入移动支付单元中一组空白的PKI加密单元；在移动支付 条件下，所述的支付服务器建立一对双向鉴权数据，通过0TA/SMS及无线网络通信管道分 别发给移动支付单元和App ;所述App从所述支付服务器接收相应的一组鉴权数据，处理后 发给所述移动支付单元请求鉴权；所述移动支付单元将数据对比0TA/SMS管道收到的鉴权 数据，鉴权通过后使能对应的PKI加密单元签发相应PKI移动支付数据给App，并由App转 发给支付服务器完成该次移动支付。
[0016] 进一步的，所述App从所述支付服务器接收相应的一组鉴权数据，处理后发给所 述移动支付单元请求鉴权；所述移动支付单元将数据对比0TA/SMS管道收到的鉴权数据， 鉴权未通过，则PKI加密单元拒绝签发PKI移动支付数据，支付请求被决绝，并将错误信息 通过0TA/SMS管道发回给支付服务器报备。
[0017] 所述的无线网络为WIFI无线网络或者GSM无线网络。
[0018] 一种基于移动支付系统的安全支付方法，由App通过无线网络向支付服务器发送 交易请求，所述交易请求包含交易号，交易额度；支付服务器收到所述的交易请求后，产生 一个随机的鉴权号，连同交易请求信息的部分或者全部信息生成一对鉴权数据B1和数据 B2,其中数据B1由0ΤΑ途径打包加密后发送给移动支付单元，数据B2加密后发给App ;APP 收到数据B2后进行相应的处理产生数据A1然后将数据A1发给移动支付单元；移动支付单 元收到所述的从支付服务器发来的数据B1以及从APP发来的数据A1后，对数据B1处理生 成数据C1，对数据A1处理后生成数据C2 ;比对数据C1与数据C2是否符合鉴权要求；如果 符合，则使能对应的PKI单元对数据C1和数据C2中的相关数据进行PKI加密和签名，产生 数据C3,并将数据C3发回给App，由APP继续完成支付。
[0019] 进一步的，如果数据C1与数据C2对比失败，则相应的PKI单元将处于关闭/失效 状态，同时将数据C1和数据C2中的相关数据从0ΤΑ或SMS途径上传至支付服务器进行错 误报备，方便支付服务器进行伪造支付数据的侦测。
[0020] 进一步的，如果在规定时间内，数据C1或数据C2中的任意一方缺失，则该次移动 支付归零，并将相关信息经0TA/SMS上传至支付服务器报备。
[0021] 更进一步的，所述的支付服务器为一个或者多个，所述的支付服务器为银行服务 器或者其他非银行类金融支付服务器。所述的多个银行服务器之间，或者银行服务器与第 三方支付服务器之间在移动支付中互相进行鉴权。
[0022] 更进一步的，所述的交易信息包含交易号、交易额度、交易时间、请求打包时间中 的一个或者多个信息。
[0023] 更进一步的，所述的加密模块包含0ΤΑ加密单元和PKI加密单元。
[0024] 进一步的，所述的数据处理为数据加/解密，或者是对数据新增或减少部分数据 形成新的数据的过程，或者是对原数据的组成部分进行新的排列组合。
[0025] 最后，所述的无线网络为WIFI无线网络或者GSM无线网络。
[0026] 本发明通过设置在移动智能通讯终端的安全的移动支付单元使用户实现在移动 智能终端随时随地的支付、转账需求，且安全程度高。
【专利附图】
【附图说明】
[0027] 图1为三方鉴权闭环示意图；
[0028] 图2为多支付服务器的三方鉴权闭环示意图。
【具体实施方式】
[0029] 以下将详细描述本发明的实施方式。
[0030] 一种移动支付单元，包含移动身份识别模块和加密模块，所述的加密模块包括0ΤΑ 加密单元和至少一组的基于PKI的加密单元；所述的移动身份识别模块登陆GSM网络确定 移动支付用户的唯一身份，并通过GSM网络为移动支付用户建立支付信息上传或下载的管 道，所述的加密模块用于加密移动支付用户请求的支付信息。
[0031 ] 具体来说，所述的移动支付单元兼具现有技术SIM卡的功能与UKEY等银行支付设 备的功能，通过在移动智能通讯终端的插槽与移动智能通讯终端电连接，或者作为移动智 能终端的一个内在结构设置在移动智能通讯终端内。所述的移动支付单元构建了 GSM通讯 管道和物理上安全的支付硬件。
[0032] 所述的PKI加密单元为一组或者多组，每组存放一个支付服务器的授权信息，这 里的移动支付服务器，可以为各大银行的服务器，也可以为类似支付宝、财付通等非银行类 第三方服务机构的支付服务器。使用时，需先由授权的银行/或单位将授权信息下载到申 请用户移动支付单元的一组空白PKI加密单元。
[0033] 为了更方便的实现移动支付，本发明还构建了基于所述的移动支付单元的移动支 付系统，即安装于移动智能通讯终端的银行或第三方金融机构的APP，设置于所述的移动智 能终端的移动支付单元，以及接受或者拒绝支付请求的银行或第三方支付服务器。
[0034] 具体来说，以手机为例作为移动智能通讯终端，以银行作为支付服务器，在初始化 条件下，银行获取并保存移动支付单元的唯一身份信息，并将相应的PKI信息写入移动支 付单元中一组空白的PKI加密单元；所述的移动支付用户通过所持手机端的APP发起支付 请求，支付请求通过无线网络与银行建立联系，所述的无线网络可以为WIFI无线网络或者 GSM无线网络，而App与所述的移动支付单元之间的通信可以利用IS07816的管道，或着利 用SWP的通信管道，或者利用USB的通信管道，实现APP与移动支付单元之间的信息交互。 在此过程中，移动支付单元、APP、银行分别对发出或接收的移动支付请求的相关信息进行 加密和解密，银行鉴别移动支付单元及APP的身份合法性，并对支付请求发出接收或者拒 绝的命令，即在APP、银行、移动支付单元之间形成支付闭环。
[0035] 所述的支付闭环简单来说是：分别利用手机上网的网络通道和GSM所固有的0ΤΑ/ SMS通道建立两套独立的、各自不同安全机制的通信管道，鉴权信息分别在两个独立管道中 流通，并交互对比，从而杜绝黑客针对单个管道或单体对象的攻击，当鉴权失败时，可以将 失败信息通过独立的0TA/SMS通道发送给服务器建立预警机制。具体来说是，银行建立一 对双向鉴权数据，通过0TA/SMS及无线网络通信管道分别发给移动支付单元和App，App接 收到银行发来的相应的一组鉴权数据，处理后发给移动支付单元请求鉴权；所述移动支付 单元将此数据对比0TA/SMS管道收到的鉴权数据，鉴权通过后使能对应的PKI加密单元签 发相应PKI移动支付数据给App,并由App转发给银行并完成该次移动支付。
[0036] 举例来说，由App向支付服务器发送交易请求，所述交易请求包含交易号，交易额 度，也可以包含交易请求时间，交易地点、数据打包时间等多项信息，形成数据包A，然后银 行收到所述的含有交易请求数据的数据包A后，产生一个随机的鉴权号，连同交易请求信 息的部分或者全部信息生成一对鉴权数据B1和B2,这里的鉴权号是附件的信息之一，也可 以是根据需求进一步附加的其他信息，所述的数据B1和数据B2可以是包含由APP发来的 请求数据的全部，也可以是APP发来的请求数据的一部分，也可以是对原数据重新排列组 合后的数据；接着其中数据B1由0TA/SMS途径打包加密后发送给移动支付单元，数据B2加 密后通过无线网络发给App ;APP收到数据B2后进行相应的处理后产生数据A1，然后将数 据A1发给移动支付单元；移动支付单元收到所述的从银行发来的数据B1以及从APP发来 的数据A1后，对数据B1处理生成数据C1，对数据A1处理后生成数据C2 ;最后比对数据C1 与数据C2是否符合鉴权要求；如果符合，则使能对应的PKI单元，对数据C1和数据C2中的 相关数据进行PKI加密和签名，产生数据C3,并将C3发回给App，由APP继续完成支付。如 果数据C1与数据C2对比失败，则相应的PKI单元将处于关闭或失效状态，同时将数据C1 和数据C2中的相关数据从0ΤΑ或SMS途径上传至银行服务器进行错误报备，方便相关机构 对伪造支付数据的来源进行侦测。如果在规定时间内，数据C1或数据C2中的任意一方缺 失，则该次移动支付归零，也将相关信息经0ΤΑ上传至银行服务器报备。
[0037] 如果支付需要通过多个支付服务器，比如支付需要经过支付宝、银行两个支付服 务器才能完成，则支付过程中，银行与支付宝也需要进行相互鉴权，鉴权的方式可以是图1 所不的：A B C A，也可以是图 2 所不的 A B C A，B D ;其中 A代表App ;B代表一个或多个银行或者第三方支付机构，C代表移动支付单兀，D代表银行 或第三方支付机构。即移动支付所涉及的各个单元之间形成串联式鉴权闭环，也可以是在 多个支付服务器之间互相鉴权，然后产生一个鉴权代表与App和移动支付单元再组成鉴权 闭环。
[0038] 使用时，为了更安全，可以建议用户在银行指定的安全环境下下载手机银行的 App，并进行如下的绑定：将App和手机绑定；将银行和智能手机中的移动支付单元绑定， 即绑定移动支付单元的身份号码及密钥。密钥的绑定有很多种方法，例如用三组密钥： KeyO(上传数据密钥）；Keyl(下传数据密钥）；Key2(App转发数据密钥）；
[0039] 进行交易时，由App向银行发送请求，包括交易号，款额等。银行收到后，产生一个 随机的鉴权号，将交易号、款额、鉴权号，时间范围等用Keyl (下行数据密钥）打包加密并数 字签名后，由0ΤΑ或SMS管道发给移动支付单元。银行同时将鉴权号利用服务器和App的 安全协议进行处理，然后通过网络发给App，其中Key2可以用数字信封方式一起发给App。 App收到后将交易号、款额再加上这个加密信息合在一起形成数据2,然后用key2签名后发 给移动支付单元。移动支付单元收到0ΤΑ或SMS短信后解密，然后移动支付单元收到App 发来的信息，用Key2对加密信息解密和验证签名。然后将0TA/SMS信息和App信息进行比 对。如果对比成功，则签发数字签名，并将数据发回给App。同时将比对结果用KeyO加密及 签名后用SMS发给银行，支付可以安全的进行了。
[0040] 通过以上实现的移动支付单元，以及在移动支付单元上形成的支付系统和安全支 付方法，相比现有的移动支付在安全性方面有以下特点：
[0041] 1、可以充分利用现有的基础设施和技术规范，将目前SIM和UKEY的优点有机的结 合在一起实现安全的三方双向鉴权，使只要在有GSM网络或者无线WIFI网络的地方，就可 以安全的进行线上支付或者银行转账。
[0042] 2、移动支付单元安全的加密/解密类似在黑箱中进行，移动支付单元物理上独立 于电脑或手机的操作系统，很难被拆解，防止了从移动支付单元内部监控的运行，密钥存在 于移动支付单元中，并且不可读。
[0043] 3、移动支付单元独立的0ΤΑ短信管道只发0TA/SMS给该用户，并有自己的一套安 全机制，给黑客的破解带来极大的困难。
[0044] 4、当手机丢失或被窃取时，用户只需报失，只要该移动支付单元登录GSM网络，就 可以立即通过0ΤΑ短信将该SM内部敏感信息全部删除。
[0045] 5、GSM网络鉴权系统的保护。因为UKEY只有在移动支付单元正常上网的情况下 才能被激活，因此黑客首先需要破解GSM网络的系统，才有可能进行移动支付单元的破解。
[0046] 对本发明进行简单变化所得的方案也在本发明保护的范围之内，在此不--列 举。
【权利要求】
1. 一种移动支付单元，其特征在于：包含移动身份识别模块和加密模块，所述的加密 模块包括OTA加密单元和至少一组的基于PKI的加密单元；所述的移动身份识别模块登陆 GSM网络确定移动支付用户的唯一身份，并通过GSM网络为移动支付用户建立支付信息上 传或下载的管道，所述的加密模块用于加密移动支付用户请求的支付信息。
2. 根据权利要求1所述的移动支付单元，其特征在于：所述的PKI加密单元通过授权 方写入PKI信息。
3. 根据权利要求2所述的移动支付单元，其特征在于：所述的授权方为决定或者拒绝 支付的一个或者多个支付服务器。
4. 一种基于权利要求1所述的移动支付单元的移动支付系统，包含安装于移动智能通 讯终端的应用程序APP，设置于移动智能通讯终端内的移动支付单元，接受或者拒绝支付请 求的支付服务器，所述的移动支付用户通过APP发起支付请求，所述的支付请求通过无线 网络发送给支付服务器，在此过程中，移动支付单元、APP、支付服务器分别对发出或接收的 移动支付请求的相关信息进行加密和解密，所述的支付服务器通过OTA/SMS管道和无线网 络管道分别鉴别移动支付单元和APP的身份合法性，并对支付请求发出接收或者拒绝的命 令。
5. 根据权利要求4所述的移动支付单元的移动支付系统，其特征在于：在初始化条件 下，所述的支付服务器获取并保存移动支付单元的唯一身份信息，并将相应的PKI信息写 入移动支付单元中一组空白的PKI加密单元；在移动支付条件下，所述的支付服务器建立 一对双向鉴权数据，通过OTA/SMS及无线网络分别发给移动支付单元和App ;所述App通过 无线网络从所述支付服务器接收相应的一组鉴权数据，处理后发给所述移动支付单元请求 鉴权；所述移动支付单元将数据对比OTA/SMS管道收到的鉴权数据，鉴权通过后使能对应 的PKI加密单元签发相应PKI移动支付数据给App，并由App转发给支付服务器完成该次 移动支付。
6. 根据权利要求5所述的移动支付单元的移动支付系统，其特征在于：所述App从所 述支付服务器接收相应的一组鉴权数据，处理后发给所述移动支付单元请求鉴权；所述移 动支付单元将数据对比OTA/SMS管道收到的鉴权数据，鉴权未通过，则PKI加密单元拒绝签 发PKI移动支付数据，支付请求被决绝，并将错误信息通过OTA/SMS管道发回给支付服务器 报备。
7. 根据权利要求4-6任意权利要求所述的移动支付系统，其特征在于：所述的无线网 络为WIFI无线网络或者GSM无线网络。
8. -种基于根据权利要求4所述的移动支付系统的安全支付方法，包含以下步骤： S1，由App通过无线网络向支付服务器发送交易请求，所述交易请求包含交易号，交易 额度； 52, 支付服务器收到所述的交易请求后，产生一个随机的鉴权号，连同交易请求信息的 部分或者全部信息生成一对鉴权数据B1和数据B2,其中数据B1由OTA/SMS途径打包加密 后发送给移动支付单元，数据B2加密后发给App ; 53, APP收到数据B2后进行相应的处理产生数据A1然后将数据A1发给移动支付单元； 54, 移动支付单元收到所述的从支付服务器发来的数据B1以及从APP发来的数据A1 后，对数据B1处理生成数据C1，对数据A1处理后生成数据C2 ; S5,比对数据Cl与数据C2是否符合鉴权要求；如果符合，则使能对应的PKI单元对数 据C1和数据C2中的相关数据进行ΡΚΙ加密和签名，产生数据C3,并将数据C3发回给Αρρ， 由ΑΡΡ继续完成支付。
9. 根据权利要求8所述安全支付方法，其特征在于：所述的步骤S5中，如果数据C1与 数据C2对比失败，则相应的ΡΚΙ单元将处于关闭/失效状态，同时将数据C1和数据C2中 的相关数据从ΟΤΑ或SMS途径上传至支付服务器进行错误报备，方便支付服务器进行伪造 支付数据的侦测。
10. 根据权利要求8所述安全支付方法，其特征在于：所述的步骤S5中，如果在规定时 间内，数据C1或数据C2中的任意一方缺失，则该次移动支付归零，并将相关信息经OTA/SMS 上传至支付服务器报备。
11. 根据权利要求8所述安全支付方法，其特征在于：所述的支付服务器为一个或者多 个，所述的支付服务器为银行服务器或者第三方支付服务器。
12. 根据权利要求11所述安全支付方法，其特征在于：所述的多个银行服务器之间，或 者银行服务器与第三方支付服务器之间在移动支付中互相进行鉴权。
13. 根据权利要求8所述安全支付方法，其特征在于：所述的交易信息包含交易号、交 易额度、交易时间、请求打包时间中的一个或者多个信息。
14. 根据权利要求8所述安全支付方法，其特征在于：所述的加密模块包含ΟΤΑ加密单 元和ΡΚΙ加密单元。
15. 根据权利要求8所述安全支付方法，其特征在于：所述的数据处理为数据加/解 密，或者是对数据新增或减少部分数据形成新的数据的过程，或者是对原数据的组成部分 进行新的排列组合。
16. 根据权利要求8所述安全支付方法，其特征在于：所述的无线网络为WiFi无线网 络或者GSM无线网络。
【文档编号】G06Q20/40GK104143142SQ201410341832
【公开日】2014年11月12日 申请日期:2014年7月17日 优先权日:2014年7月17日
【发明者】马洁韵, 唐毅 申请人:马洁韵, 唐毅