CN103747001B - 基于安全算法的音频接入式移动支付通信方法 - Google Patents

Abstract

本发明公开了一种基于安全算法的音频接入式移动支付终端及通信方法，所述移动支付终端主要包括主控模块、安全验证模块、读卡模块(接触IC卡和非接触IC卡)、人机交互模块(OLED显示和触摸键盘输入)、通信模块(USB通信和音频接入通信)、电源管理模块。在传统金融交易设备的基础上，增加安全验证模块和音频接入模块。其中安全验证模块主要实现国际(3DES、SHA‑1和RSA)和国家密码(SM2、SM3和SM4)两套安全算法，保证了金融交易数据的机密性、完整性，移植SSL协议确保了支付安全性，该基于安全算法的音频接入式移动支付终端及通信方法兼容性好，灵活性强，安全性高。

Description

基于安全算法的音频接入式移动支付通信方法

技术领域

本发明涉及一种基于安全算法的音频接入式移动支付终端及通信方法。

背景技术

目前，移动支付方案可以大致分为近场支付和远程支付两种。由于基于NFC技术的一卡式移动支付产品主要用于近场支付方案，但标准并未统一，也缺乏成熟的市场商用。目前移动支付的应用仍多集中在远程支付领域。远程支付，指用户与商户不需要面对面交互，而是使用移动终端通过无线通信网络，与后台服务器进行交互，由服务器端完成交易处理的支付方式。按照使用的技术类型，远程支付技术方案主要包括短信支付、客户端(无卡)支付、智能卡支付和智能终端外设支付四种技术方案。

手机短信支付是手机移动支付的最早和使用最多的应用方式，通过将用户手机SIM卡与用户本人的银行卡账号建立一种一一对应的关系，用户通过发送短信的方式在系统短信指令的引导下完成交易支付请求，操作简单，可以随时随地进行交易。但是这种方式存在一定的安全隐患，如果操作密码过于简单或者手机SIM卡被人复制，银行账户的资金将会被人以转账的形式转走，造成经济损失。

现有的支付终端采用国际加密算法实施加密，而且支付终端与手机通信一般采用USB通信，灵活性较差，兼容性不好。

因此，有必要设计一种新型的移动支付终端及通信方法。

发明内容

本发明所要解决的技术问题是提供一种基于安全算法的音频接入式移动支付终端及通信方法，该基于安全算法的音频接入式移动支付终端及通信方法兼容性好，灵活性强，安全性高。

发明的技术解决方案如下：

一种基于安全算法的音频接入式移动支付终端，包括主控模块、通信模块、 电源管理模块和人机交互模块，还包括安全验证模块和读卡模块；所述的通信模块包括基于音频接入的通信模块和USB通信模块；

所述的基于音频接入的通信模块用于主控模块与外部的移动智能设备通信；

所述的USB通信模块用于主控模块与外部的USB设备通信；

电源管理模块为其他模块提供电源；

安全验证模块、人机交互模块和通信模块均与主控模块连接；

人机交互模块，用于用户信息输入和信息显示；

所述的安全验证模块集成有国际密码安全算法和国家密码安全算法；

安全验证模块用于基于SSL协议保障数据的安全性。

人机交互模块包括触摸键盘输入和显示屏，读卡模块包括接触式IC卡和非接触式IC卡。

所述移动支付终端的应用平台为移动智能处理设备，为手机、个人数字助理PDA、数码相机、笔记本电脑、平板电脑中的任意一种。

所述的基于安全算法的音频接入式移动支付终端还包括USB接入检测电路和音频接入检测电路；

所述的USB接入检测电路为由电阻R4和R5组成的分压电路；电阻R4的一端接USB接口，电阻R4的另一端通过电阻R5接地，电阻R4和R5的连接点即分压点为USB检测信号输出端(USBSenser)；

所述的音频接入检测电路包括电阻R3、MOS管Q1和由电阻R1和R2组成的分压电路；MOS管为N沟道型MOS管，MOS管Q1的D极经电阻R3接3.3V直流电源；MOS管Q1的S极接地；MOS管的G极接电阻R1和R2的连接点即分压点，分压电路的两端分别与音频接口的MIC端【即麦克风端】和AGND端【即模拟地端】相接；MOS管Q1的D极为音频检测信号输出端(AudioSenser)。

音频接入式移动支付终端与移动智能设备采用FSK和ASK相结合的双调制模式进行通信：上行采用ASK模式，下行采用FSK模式；所述的上行为音频接入式移动支付终端发往移动智能设备，下行为移动智能设备发往音频接入式移动支付终端；

音频接入式移动支付终端的采样频率设定为176KHz；

在FSK模式下，即采用5.5kHz和11K Hz的2种频率的正弦波分别表示数字信号“0”和“1”；

按照以下方法判断正弦波的频率实现解码：

当每一个波形周期内采样点数在26到38之间时，则判定当前的信号为5.5KHz频率的正弦波；

当采样点数在12到20之间时，则判定当前的信号为11KHz频率的正弦波；

利用幅值门限值判断采样点数；

所述的波形周期是一个完整的正弦波对应的周期；

在下行编码中，通过发送2个连续的11KHz频率的波表示数字“1”，发送1个5.5kHz的波表示数字“0”；从而将数字信号编码成一串波形数据用于信号传输；在音频接入式移动支付终端端接收到波形数据后，通过解码得到原始数字信号，完成下行通信；

所述的音频接入式移动支付终端是基于ARM的设备，将ARM输出的调制信号的幅度放大到峰峰值为2.75V-2.85V，在ARM发送和MIC接收间再插入衰减网络，将ARM输出信号调整为移动智能设备可接受的140mV以下；

在音频接入式移动支付终端端，采用自适应的双门限判别方式抑制FSK调频信号在传输过程中尖峰的脉冲干扰(实现对信号高精度解析)：

1)结合实时信号的包络，算出信号中心平均值，然后对该值分别加、减△A值，算出高低两个电平门限；【(如果将中心值到波峰或者波谷的电平值定为参数R，这里取0.5V[3.3-2.8＝0.5V]，由中心值出发，分别加减0.7R，就得出上下门限的具体值，即△A＝0.7R)，这样能保证高低两个门限的电平差值大于绝大部分尖峰脉冲的峰峰值。根据电路的实际测量结果得出，很多尖峰有0.2R到0.3R左右，现在由于采用双门限后，整个系统已经能容忍小于1.4R的尖峰干扰。从信号传输随机过程来看，已经能消除绝大多数的尖峰干扰】

2)当信号从高电平往下低电平发展时，不管在这个过程中受到几次尖峰干扰的叠加，一直要到达低门限以下，才算一次有效的信号下降沿，反之亦然；当信号由低电平向高电平发展时，不论其自有多少次尖峰叠加，也必须信号电平达到上门限的时候，才认为是一次有效的信号上跳变；【高门限已经达到了(2.8+0.7R)V，低门槛2.8v-0.7Rv，真实信号即移动智能设备端发送信号峰峰 值值通过软件设置到最大，同时在通信时将移动智能设备耳机接口音量也调到最大，多次实验证明，真实信号波峰值接近3.3V，波谷值接近2.3V。】

具体实现方式是：采用滞回原理，采用从第一次上升到达高门限值开始到第一次下降到达低门限为一个下降过程，第一次下降到低门限到第一次上升到高门限值为上升过程来判断，由于高低门限值的差距比较大，可以有效去除干扰。

一种基于安全算法的通信方法，采用前述的基于安全算法的音频接入式移动支付终端与外部设备进行通信，所述的外部设备包括移动智能设备和外部的USB设备通信；

采用所述的USB接入检测电路和音频接入检测电路自动检测当前的接入状态是USB接入还是音频接入；

所述安全算法3DES是指国际对称密码算法，SHA-1是国际哈希算法，RSA为国际非对称密码算法，SM2为国密非对称算法，SM3为国密哈希算法，SM4为国密对称算法。

在移动支付终端与银行服务器进行交易前建立安全通道；采用两套密码算法机制，其中国密算法采用SM2/SM3/SM4算法实现，国际标准算法采用RSA/SHA-1/3DES算法实现。整个SSL协议包含两个部分，分别是握手协议和记录层协议；

握手协议

1)客户端利用随机数产生机制产生32字节随机数ClientHello.random，根据终端的算法支持设置ClientHello.cipherSuite，向服务器端发送ClientHello消息，启动握手协议；

客户端的ClientHello消息包括32字节的随机数和1个字节的算法标识：32字节的随机数random由终端安全芯片生成；根据终端所支持的对称算法与非对称算法设置cipherSuite，算法标识字节的具体设置参见下表：

表1算法描述符字节定义

注：cipherSuite字节的相应位置为1表示终端可支持的密码算法集，ServerHello.cipherSuite的设置同上表，相应位置为1表示服务器选择的密码算法；

2)服务器端产生32字节随机数ServerHello.random，根据接收的ClientHello.cipherSuite选定可用的密码算法，设置ServerHello.cipherSuite；

服务器端ServerHello包括32字节的随机数和1字节的算法标识cipherSuite；服务器端产生32字节随机数ServerHello.random；根据接收的1字节的算法标识ClientHello.cipherSuite中获得终端支持的对称和非对称算法列表，检查算法列表中是否包含处理中心的对称算法和渠道证书所用的签名算法。服务器选定可用的密码算法，设置ServerHello.cipherSuite；

3)服务器端使用服务器证书设置ServerCertificate.certificate。

证书可以是SM2证书也可以是RSA证书。服务器证书用于认证渠道服务器的真实身份，确保终端与合法的渠道服务器进行通信；

4)服务器端发送ServerHello和ServerCertificate消息；

5)客户端收到证书后，利用CA证书中的公钥验证收到的服务器端证书，如果验证不通过，则发送ServerCertificateError消息，结束链接；否则，客户端产生48字节随机数作为共享主秘密master_secret，设置ClientKeyExchange.encryptedSharedSecret为加密master_secret得到的密文；根据协商的非对称公钥算法用服务端的公钥对master_secret加密；

6)客户端使用客户端证书设置ClientCertificate.certificate，使用客户端私钥生成CertificateVerify.signature＝Sign(ClientHello||ServerHello)；根据协商的非对称签名算法；客户端发送ClientCertificate、CertificateVerify和ClientKeyExchange到服务器端；

7)服务器端用CA证书的公钥验证客户端证书的合法性，用客户端证书的公钥验证客户端证书签名CertificateVerify；若验证不通过，则发送ClientCertificateError消息，结束链接；否则，利用服务端自己的私钥从ClientKeyExchange消息中解密得到共享主秘密master_secret；

8)服务器端发送握手验证消息ServerFinished。

服务器端对握手过程的验证消息定义如下：

message_MAC＝HMAC(master_secret,Finish_label||Hash

(handshake_messages))

HMAC是密钥相关的哈希运算消息认证码【(Keyed-Hash Message AuthenticationCode)，总而言之，它是一种常用的保证数据完整性不被别人篡改的安全算法。】，master_secret为主秘密【通俗的说是主密码或主密钥】，Finish_label为6个字节的ASCII码值“SERVER”，Hash算法使用SM3或SHA-1；Handshake_messages为握手消息的连接：

handshake_messages＝(ClientHello||ServerHello||Hash(ServerCertificate)||Hash(ClientCertificate)||CertificateVerify||ClientKeyExchange)；

9)客户端验证接收到的ServerFinished消息，若验证不成功，则发送ServerHandshakeError消息，结束链接；否则，发送客户端握手验证消息ClientFinished；

10)服务器端验证接收到的ClientFinished消息。验证失败，则发送ClientHandshakeError消息，结束链接。

11)上述握手过程成功后，双方使用如下方法计算会话密钥：

(a)采用SM3计算HMAC

X＝HMAC_sm3(master_secret,

key_label||ClientHello.random||ServerHello.random)

其中key_label为3字节ASCII码“KEY”，HMAC算法参见密码算法部分；令X₁X₂…X₃₂分别为X的第1个至第32字节，则加密密钥SKey为：SKey＝X₁X₂…X₁₆，MAC密钥MKey为：MKey＝X₁₇X₁₈…X₃₂；

(b)采用SHA-1计算MAC

X＝HMAC_SHA-1(M1,key_label||ClientHello.random||ServerHello.randomM1为master_secret取其前16个字节；

其中key_label为3字节ASCII码“KEY”，令X₁X₂…X₂₀分别为X的第1个至第20字节，则加密密钥SKey为：SKey＝X₁X₂…X₁₆，MAC密钥MKey为：MKey＝X₅X₆…X₂₀；

12)握手过程结束；

记录协议

在记录层，在建立安全通道的基础上，终端与服务器通讯双方进行数据传输；

记录层消息用于应用数据传输，定义如下：

其中encryptedData为加密后在安全信道中传输的应用数据；数据加密算法使用SM4算法或3DES算法；若采用SM4算法，消息认证码dataMac为使用SM4CBC模式最后一块数据计算结果的左8字节作为消息认证码；若采用3DES算法，消息认证码dataMac为8字节；length为encryptedData和dataMac长度之和，在实际使用中为2字节；

握手成功之后，双方在建立的安全通道上进行数据传输；

记录层协议的数据加密方法如下：

在传输的数据Data前添加数据块长度Length，构成数据块D＝(Length||Data)；默认使用加密密钥SKey和SM4算法CBC模式对D进行加密，即：

Record.encryptedData＝SM4_SKey(D)；

在数据传输过程中，为了保证记录层协议的数据完整性，采用以下保护方法：

在记录层协议的传输过程中，为双端每个发送和接收记录指定记录序列号；其初始值Seq₀的设置为：

令R₁R₂…R₃₂是ClientHello.random的第1到32字节，并令Q₁Q₂…Q₃₂是ServerHello.random的第1到32字节，则：Seq0＝R₁R₂…R₈||Q₁Q₂…Q₈；以后每发送或接收一帧记录信息后，记录序列号加1，双端要保持发送接收序列号的同步：

Seq_i＝Seq_i-1+1

双方交互的应用数据的完整性使用消息认证码MAC进行保护，MAC的生成 方法为：

Record.data_MAC＝MAC(MKey,Seq_i||Record.encryptedData)

其中Record.encryptedData是所传输的加密应用数据，Seq_i是当前的记录序列号；客户端或服务器端接收到数据后，首先验证MAC的正确性，如果正确则进行处理；否则，发送错误消息，重启握手协议。

移动支付终端,包括：

主控模块，用于控制各个模块正常工作；

安全验证模块，用于实现安全算法和存储设备及用户敏感信息；

读卡模块，用于处理接触IC卡和非接触IC卡信息；

人机交互模块，用于用户信息输入和信息显示；

通信模块，用于实现与外界移动智能终端进行音频接入或USB通信；

电源管理模块，用于为整个系统提供3.3V直流电压。

所述主控模块包括主控芯片和存储芯片等，主控芯片是整个系统的控制中心，选择主流控制芯片，满足软硬件需求。存储芯片用于存储各种程序和数据。

所述安全验证模块是专门用于存储敏感信息和进行关键安全运算的模块，是保证安全支付的基础。主要存储的敏感信息包括CA根证书(用于在交易过程中验证证书合法性)、终端证书(用于标识终端合法身份的唯一公钥证书)、终端公私钥(公私钥由安全模块安全算法生成，私钥不能导出安全模块)、PIN加密证书(用于联机PIN的加密)。

所述通信模块主要实现了两种外部通信方法，即USB接入和3.5mm音频接入方法，并实现两种通信方式自动切换。

所述移动支付终端实现了多个业务功能，如主账户余额查询、IC卡交易明细、电子现金余额查询、交易、圈存、优惠信息下载、查询卡内应用、信用卡还款等，确保发明的移动支付终端能够满足中国银联在线支付要求。

所述人机交互模块主要包括OLED显示屏和触摸键盘。OLED显示屏用于显示各类订单信息，触摸键盘用于输入交易密码、交易金额等。

所述安全算法主要包括国际(3DES、SHA-1和RSA)和国密(SM2、SM3和SM4)两套密码算法，通过设置密码算法选择标识位，使两套密码算法之间自由切换使用。移植SSL协议保证支付安全性。同时，为了保证传输信息和业务安全性，结 合安全算法设计了一系列安全机制，如加解密处理、传输信息完整性保护、信息不可重放保护、抗抵赖处理、超时处理、敏感信息安全存储等。

所述音频接入方法采用FSK和ASK相结合的双调制通信模式实现支付设备与移动智能设备的通信；即上行采用ASK模式，在下行采用FSK模式；所述的上行为支付设备发往移动智能设备，下行为移动智能设备发往支付设备。

所述移动支付终端的应用平台为移动智能设备，如手机、个人数字助理PDA、数码相机、笔记本电脑、平板电脑中的任意一种。

所述安全算法3DES是指国际对称密码算法，SHA-1是国际哈希算法，RSA为国际非对称密码算法，SM2为国密非对称算法，SM3为国密哈希算法，SM4为国密对称算法。

有益效果：

本发明的基于安全算法的音频接入式移动支付终端及通信方法，所述移动支付终端包括主控模块、安全验证模块、读卡模块(接触IC卡和非接触IC卡)、人机交互模块(OLED显示和触摸键盘输入)、通信模块(USB通信和音频接入通信)、电源管理模块。在传统金融交易设备的基础上，增加了自主选型、设计的安全验证模块和音频接入模块。其中安全验证模块主要实现国际(3DES、SHA-1和RSA)和国家密码(SM2、SM3和SM4)两套安全算法，保证了金融交易数据的机密性、完整性，移植SSL协议确保了支付安全性。

通信模块在传统金融交易设备支持的USB通信的基础上，增加了新型的音频接入模块，音频接入模块提高了该设备的使用范围，满足用户与移动智能设备通信需要。所述的移动支付终端实现了多个业务功能，如主账户余额查询、IC卡交易明细、电子现金余额查询、交易、圈存、优惠信息下载、查询卡内应用、信用卡还款等，确保了发明的移动支付终端能够满足在线支付要求。

本发明利用移动智能设备较为通用的音频接口进行通讯，从而形成便携智能支付终端，具有很多现实意义：

(3)生产成本低，作为便携智能收款终端潜力巨大；

(4)将日常由银联或银行线下铺设的POS装置安装在移动智能设备(如智能手机)上，形成全新的移动支付方案，满足用户随时、随地消费需求，增加银行交易量；

(5)解决现有移动智能设备移动支付中存在的通信不稳定、使用不方便等问题，通过SSL协议六次握手建立SSL安全逻辑通道保证数据传输安全性；

(6)将移动智能设备的标准配置——音频接口作为切入点，满足用户对刷卡设备便携性和通用性的需求。

本发明的基于移动智能设备音频接口的数据通信方法，具有以下突出优点：

(1)通用性

目前，移动智能设备应用广泛，利用移动智能设备实现移动支付便于广大用户使用。

(2)以软件代硬件，降低成本

用软件方式实现正弦波发送、编解码、降噪处理、自适应算法等。不需要太多额外硬件电路，降低了成本。

(3)通信可靠性

通过大量实验和数据采集，解决通信过程中的不稳定因素，保证了通信的可靠性和零误码率。通过预加重以及双门限滞回技术应对干扰，提高可靠性。

(4)准确发波机制

采用D/A模块配置、软算法以及DMA实现波形幅值、频率以及发送个数的精确控制；数据质量高。

本发明通过移动智能设备+外接刷卡器模式，即本发明提到的移动支付终端应用模式。有银行IC卡+服务密码+安全算法的多重安全保障，刷卡器中的安全模块是专门用于存储敏感信息和进行关键安全运算的模块，是保证信息安全的基础，安全模块主要实现敏感信息的存储，用户身份鉴别信息、各种数字证书以及私钥保护PIN码等信息都是存储在安全模块内部的，其中用户身份鉴别信息，即终端私钥必须在初始化的时候在安全模块内部生成，生成后不能通过任何技术手段导出安全模块，用户身份鉴别的关键操作(数字签名)，必须在安全模块内部进行。同时，安全模块自身也设置密码保护，只有通过PIN码认证的用户，才能使用设备。

基于模块化、低功耗设计原则，为了使移动支付终端与银行服务器之间能进行安全通信，通过移动支付终端与网上银行服务器建立Internet上的安全通道，实现对持卡用户与后台服务器的双重身份认证，确保终端与银行之间通信的安全 性。

本发明具有以下突出优点：

(1)在传统银行卡交易设备的系统架构上新增加了安全验证模块和音频接入模块，使得该新设备的金融交易的安全性得到更高保障，并兼容我们国家对国密算法的加密要求。同时，音频接入新增了该设备的移动使用功能，使其随时随地可以与智能手机或IPAD等设备互联，实现金融交易，兼容性和灵活性好。

(2)实现多个业务功能，如主账户余额查询、IC卡交易明细、电子现金余额查询、交易、圈存、优惠信息下载、查询卡内应用、信用卡还款等，发明的移动支付终端满足在线支付要求。

(3)采用双密码安全算法体系保证安全支付：实现国际(3DES、SHA-1和RSA)和国密(SM2、SM3和SM4)两套安全软算法，使用SSL协议保证支付安全性。为了保证传输信息和业务安全性，结合安全算法设计了一系列安全机制，如加解密处理、传输信息完整性保护、信息不可重放保护、抗抵赖处理、超时处理、敏感信息安全存储等。

综上所示，本发明集成了多种加密算法，且兼容USB接口与音频接口通信，兼容性好，灵活性强，安全性高。

附图说明

图1为移植SSL握手协议示意图；

图2为音频接入检测电路图；

图3为USB接入检测电路图；

图4为移动支付终端安全通信示意图；

图5为移动支付终端的组成框图；

图6为移动支付终端音频接入示意图；

图7为移动支付终端上行链路示意图；

图8移动支付终端下行链路示意图；

图9为移动支付终端业务处理流程图。

具体实施方式

以下将结合附图和具体实施例对本发明做进一步详细说明：

实施例1：

如图1-9，随着网银业务的不断发展，越来越多的个人用户已经体会到它的简单和便捷之处。在可接入互联网环境中的PC终端上，随时都可进行账户查询、转帐汇款等业务办理，方便了人们的生活，同时也减轻了银行柜台压力，减少了银行的运营成本。但随着磁条卡犯罪日益猖獗，磁条卡在安全方面缺陷越来越突出，金融IC卡替代磁条卡成为了必然的事实。随着智能手机、平板电脑、PDA等移动智能设备的普及，充分利用、体现移动智能终端的强大功能和移动互联网，打造一个看不见的在线安全支付系统，又能让用户真实体验到便捷、安全的移动支付业务，参见图4，我们发明了一种基于安全算法的音频接入式移动支付终端，实现了移动支付终端的安全通信。

模块功能介绍

所述的移动支付终端采用模块化的设计原则，主要分为主控模块、安全验证模块、读卡模块(接触和非接触)、人机交互模块、通信模块和电源管理模块，参见图5。

主控模块：采用32位处理器，该处理器外设资源丰富，满足我们在逻辑处理和业务流程中对硬件资源的需求。

安全验证模块：采用国家密码管理局认可的安全芯片【具体采用国民技术的SSX1205芯片】，并配合COS(片上系统)实现国际和国密两套密码安全算法，同时开辟安全存储区域，确保用户敏感信息能够不会泄露，保证了金融交易安全性。

读卡模块：采用接触IC卡和非接触IC卡接口芯片，实现了对卡片的读写控制。

人机交互模块：使用高灵敏度触摸按键，用于交易密码和交易金额等输入；选择液晶显示屏，实现汉字和字符的显示，用于显示用户订单信息和菜单信息。

通信模块：支持USB通信和音频通信两种方式，并实现自主切换通信模式。

电源模块：用于为整个系统提供3.3V直流电压。

安全算法使用

为了保证传输信息和业务安全性，结合双密码安全算法设计了一系列安全机制，如加解密处理、传输信息完整性保护、信息不可重放保护、抗抵赖处理、超时处理、敏感信息安全存储等。具体采用的安全算法主要通过交互过程中的算法标志位来确定。安全机制具体介绍如下：

(1)身份可认证性和不可抵赖性：终端与服务器交换数字证书，并通过预先持有的CA根证书进行验证，服务器还要验证终端私钥的数字签名，签名算法使用SM2(或RSA)和SM3(或SHA-1)密码算法，所有证书为使用SM2(或RSA)密码算法的X.509证书。发送方使用自己的私钥对明文(SendData)进行加密，接收方使用发送方的公钥对密文(EData0)进行解密得到(ReceiveData)。接收方使用发送方的公钥进行解密，可以确信信息是由发送方加密的，也就可以认证发送方的身份。使用流程如下：

(2)信息保密性：在传输的过程中，所有的业务数据都通过SM4(或3DES)对称加密算法加密。使用流程如下：

(4)信息完整性

计算会话密钥的时候，握手通讯的所有消息都需要做HMAC进行完整性确认。使用流程如下：

在业务通讯的时候，所有的数据必须通过基于SM4(或3DES)密码算法的MAC算法进行MAC验证。使用流程如下：

(5)不可伪造性：通过添加MAC和消息序号Seq的方式。使用流程如下：

Record.data_MAC＝MAC(MKey,Seq_i||EData1)

其中，MKey为MAC密钥，Seq_i为序列号，EData1为SM4或3DES对称 加密数据。

(6)防止重放攻击：每条交易通讯指令都添加一个Seq(序列号)信息，如果Seq验证失败，则重新握手。使用流程如下：

令R₁R₂…R₃₂是客户端随机数ClientHello.random的第1到32字节，并令Q₁Q₂…Q₃₂是服务器端随机数ServerHello.random的第1到32字节，则：Seq0＝R₁R₂…R₈||Q₁Q₂…Q₈。以后每发送或接收一帧记录信息后，记录序列号加1，双端要保持发送接收序列号的同步：

Seq_i＝Seq_i-1+1

双密码安全算法为本发明独创的技术。

移动支付终端的硬件上采用A/D和D/A输入输出接口，参见图6。同时设计阻抗匹配网络和信号缩小电路保证信号良好、稳定地传输。

上行链路(UPLINK)：信号由设备的D/A输出到，移动智能设备MIC接入，具体硬件电路参见图7，电路组成如下表2所示。

表2上行链路元件介绍

PART	VALUE	DESCRIPTION
			R1	1K	主要用来做插耳机动作检测
C1	100NF	隔直电容
			R2	预留	预留将来使用
R3	0欧姆	起连通作用
			R4	预留	预留将来使用
C2	10UF	音频隔直电容
			L1	预留	预留将来使用

下行链路(DOWNLINK)：信号由智能设备音频输出通道发送至支付设备的A/D端，外加DC_REF主要为了满足硬件需求，具体硬件电路参见图8，电路组成如下表3所示。

表3下行链路元件介绍

终端业务处理流程

当移动支付终端连接处理中心进行联机交易时，终端必须判断所连的处理中心身份，并执行相应处理中心的终端功能、终端交易应用(业务)流程和选用相应渠道的PIN加密证书加密PIN数据。终端程序处理流程参见图9，具体流程为：

1)持卡人开始联机交易；

2)处理中心与终端建立安全通道；

3)终端根据建立安全通道中获取的渠道证书内容，判断终端所连接的处理中心身份；

4)根据步骤3)判断执行处理中心终端应用(业务)流程(包括使用对应处理中心的PIN加密证书进行PIN加密、冲正机制、显示信息提示等)；

5)交易流程执行完毕，交易结束。

上面所述交易内容包括主账户余额查询、IC卡交易明细、电子现金余额查询、订单交易、圈存、优惠信息下载、查询卡内应用、信用卡还款等。

本发明涉及到的关键技术有：

(1)双向SSL握手协议移植和双密码算法使用

传统的SSL安全协议是建立在PC机同服务器之间的握手，本协议借鉴SSL安全协议，结合国密和国际安全算法。巧妙的通过TCP/IP协议和设备通信协议之间的数据转换，完成了终端与服务器之间的SSL安全协议。这样成功避免了PC或移动智能终端这个安全隐患，有效防止了木马和钓鱼网站。在移动支付终端与银行服务器进行交易前建立安全通道。采用两套密码算法机制，其中国密算法采用SM2/SM3/SM4算法实现，国际标准算法采用RSA/SHA-1/3DES算法实现。整个SSL协议包含两个部分，分别是握手协议和记录层协议。

握手协议

握手具体流程如图1所示：

1)客户端利用随机数产生机制产生32字节随机数ClientHello.random，根据终端的算法支持设置ClientHello.cipherSuite，向服务器端发送ClientHello消息，启动握手协议。

客户端的ClientHello消息包括32字节的随机数和1个字节的算法标识：32字节的随机数random由终端安全芯片生成；根据终端所支持的对称算法与非对称算法设置cipherSuite，算法标识字节的具体设置参见表1.

2)服务器端产生32字节随机数ServerHello.random，根据接收的ClientHello.cipherSuite选定可用的密码算法，设置ServerHello.cipherSuite；

服务器端ServerHello包括32字节的随机数和1字节的算法标识cipherSuite。服务器端产生32字节随机数ServerHello.random；根据接收的1字节的算法标识ClientHello.cipherSuite中获得终端支持的对称和非对称算法列表，检查算法列表中是否包含处理中心的对称算法和渠道证书所用的签名算法。服务器选定可用的密码算法，设置ServerHello.cipherSuite。

3)服务器端使用服务器证书设置ServerCertificate.certificate。

证书可以是SM2证书也可以是RSA证书。服务器证书用于认证渠道服务器的真实身份，确保终端与合法的渠道服务器进行通信。

4)服务器端发送ServerHello和ServerCertificate消息。

5)客户端收到证书后，利用CA证书中的公钥验证收到的服务器端证书，如果验证不通过，则发送ServerCertificateError消息，结束链接；否则，客户端产生48字节随机数作为共享主秘密master_secret，设置ClientKeyExchange.encryptedSharedSecret为加密master_secret得到的密文。根据协商的非对称公钥算法(SM2公钥加密算法或RSA公钥加密算法)用服务端的公钥对master_secret加密。

6)客户端使用客户端证书设置ClientCertificate.certificate，使用客户端私钥生成CertificateVerify.signature＝Sign(ClientHello||ServerHello)。根据协商的非对称签名算法(SM2私钥签名算法或RSA私钥签名算法)。客户端发送ClientCertificate、CertificateVerify和ClientKeyExchange到服务器端。

7)服务器端用CA证书的公钥验证客户端证书的合法性，用客户端证书的公钥验证客户端证书签名CertificateVerify。若验证不通过，则发送ClientCertificateError消息，结束链接。否则，利用服务端自己的私钥从ClientKeyExchange消息中解密得到共享主秘密master_secret。

8)服务器端发送握手验证消息ServerFinished。

服务器端对握手过程的验证消息定义如下：

message_MAC＝HMAC(master_secret,Finish_label||Hash

(handshake_messages))

HAMC的计算方法参见密码算法部分。其中master_secret为主秘密，Finish_label为6个字节的ASCII码值“SERVER”，Hash算法可以使用SM3，也可以使用SHA-1。Handshake_messages为握手消息的连接：

handshake_messages＝(ClientHello||ServerHello||Hash(ServerCertificate)||Hash(ClientCertificate)||CertificateVerify||ClientKeyExchange)；

9)客户端验证接收到的ServerFinished消息，若验证不成功，则发送ServerHandshakeError消息，结束链接；否则，发送客户端握手验证消息ClientFinished；

10)服务器端验证接收到的ClientFinished消息。验证失败，则发送ClientHandshakeError消息，结束链接。

11)上述握手过程成功后，双方使用如下方法计算会话密钥：

(a)SM3计算HMAC

X＝HMAC_sm3(master_secret,

key_label||ClientHello.random||ServerHello.random)

其中key_label为3字节ASCII码“KEY”，HMAC算法参见密码算法部分。令X₁X₂…X₃₂分别为X的第1个至第32字节，则加密密钥SKey为：SKey＝X₁X₂…X₁₆，MAC密钥MKey为：MKey＝X₁₇X₁₈…X₃₂。

(b)SHA-1计算MAC

X＝HMAC_SHA-1(M1,key_label||ClientHello.random||ServerHello.random(M1为master_secret取其前16个字节)

其中key_label为3字节ASCII码“KEY”，HMAC算法参见密码算法部 分。令X₁X₂…X₂₀分别为X的第1个至第20字节，则加密密钥SKey为：SKey＝X₁X₂…X₁₆，MAC密钥MKey为：MKey＝X₅X₆…X₂₀；

12)握手过程结束。

记录协议

在记录层，在建立安全通道的基础上，终端与服务器通讯双方进行数据传输。

记录层消息用于应用数据传输，定义如下：

其中encryptedData为加密后在安全信道中传输的应用数据。数据加密算法可以使用SM4算法或3DES算法。若采用SM4算法，消息认证码dataMac为使用SM4CBC模式最后一块数据计算结果的左8字节作为消息认证码；若采用3DES算法，消息认证码dataMac为8字节。length为encryptedData和dataMac长度之和，在实际使用中为2字节。

握手成功之后，双方可在建立的安全通道上进行数据传输。

记录层协议的数据加密方法如下：

在传输的数据Data前添加数据块长度Length(2字节)，构成数据块D＝(Length||Data)。默认使用加密密钥SKey和SM4算法CBC模式对D进行加密。即：

Record.encryptedData＝SM4_SKey(D)；

在数据传输过程中，为了保证记录层协议的数据完整性，采用以下保护方法：

在记录层协议的传输过程中，为双端每个发送和接收记录指定记录序列号。其初始值Seq₀的设置为：

令R₁R₂…R₃₂是ClientHello.random的第1到32字节，并令Q₁Q₂…Q₃₂是ServerHello.random的第1到32字节，则：Seq0＝R₁R₂…R₈||Q₁Q₂…Q₈。以后每发送或接收一帧记录信息后，记录序列号加1，双端要保持发送接收序列号的 同步：

Seq_i＝Seq_i-1+1

双方交互的应用数据的完整性使用消息认证码MAC进行保护，MAC的生成方法为：

Record.data_MAC＝MAC(MKey,Seq_i||Record.encryptedData)

其中Record.encryptedData是所传输的加密应用数据，Seq_i是当前的记录序列号。MAC的计算方法参见密码算法部分。客户端或服务器端接收到数据后，首先验证MAC的正确性，如果正确则进行处理；否则，发送错误消息，重启握手协议。

(2)通信模式自动切换

本发明实现了USB和音频两种通信模式，参见图2和3。图2是音频接入检测电路图，其中R1和R2是分压电阻，Q1为MOS管高电平导通，

有音频接入的时候，AudioSensor输出低电平，否则输出高电平。

图3是USB接入检测电路图，其中R4和R5是分压电阻，当主控芯片与USB接口连接时，检测到B点电压不为0，即表明有USB接入。反之，表明没有USB接入。通过检测与AudioSensor和USBSensor连接的主控芯片管脚电平，进而确定移动支付终端启用的通信模式，并自动切换到对应的应用流程。

Claims (2)

1.一种基于安全算法的通信方法，其特征在于，采用基于安全算法的音频接入式移动支付终端与外部设备进行通信，

所述的基于于安全算法的音频接入式移动支付终端，包括主控模块、通信模块、电源管理模块和人机交互模块，其特征在于，还包括安全验证模块和读卡模块；所述的通信模块包括基于音频接入的通信模块和USB通信模块；

所述的基于音频接入的通信模块用于主控模块与外部的移动智能设备通信；

所述的USB通信模块用于主控模块与外部的USB设备通信；

电源管理模块为其他模块提供电源；

安全验证模块、人机交互模块和通信模块均与主控模块连接；

人机交互模块，用于用户信息输入和信息显示；

所述的安全验证模块集成有国际密码安全算法和国家密码安全算法；

安全验证模块用于基于SSL协议保障数据的安全性；

人机交互模块包括触摸键盘输入和显示屏，读卡模块包括接触式IC卡和非接触式IC卡；

所述移动支付终端的应用平台为移动智能处理设备；

还包括USB接入检测电路和音频接入检测电路；

所述的USB接入检测电路为由电阻R4和R5组成的分压电路；电阻R4的一端接USB接口，电阻R4的另一端通过电阻R5接地，电阻R4和R5的连接点即分压点为USB检测信号输出端(USBSenser)；

所述的音频接入检测电路包括电阻R3、MOS管Q1和由电阻R1和R2组成的分压电路；MOS管为N沟道型MOS管，MOS管Q1的D极经电阻R3接3.3V直流电源；MOS管Q1的S极接地；MOS管的G极接电阻R1和R2的连接点即分压点，分压电路的两端分别与音频接口的MIC端和AGND端相接；MOS管Q1的D极为音频检测信号输出端(AudioSenser)；

音频接入式移动支付终端与移动智能设备采用FSK和ASK相结合的双调制模式进行通信：上行采用ASK模式，下行采用FSK模式；所述的上行为音频接入式移动支付终端发往移动智能设备，下行为移动智能设备发往音频接入式移动支付终端；音频接入式移动支付终端的采样频率设定为176KHz；

在FSK模式下，即采用5.5kHz和11K Hz的2种频率的正弦波分别表示数字信号“0”和“1”；

按照以下方法判断正弦波的频率实现解码：

当每一个波形周期内采样点数在26到38之间时，则判定当前的信号为5.5KHz频率的正弦波；

当采样点数在12到20之间时，则判定当前的信号为11KHz频率的正弦波；

利用幅值门限值判断采样点数；

所述的波形周期是一个完整的正弦波对应的周期；

在下行编码中，通过发送2个连续的11KHz频率的波表示数字“1”，发送1个5.5kHz的波表示数字“0”；从而将数字信号编码成一串波形数据用于信号传输；在音频接入式移动支付终端端接收到波形数据后，通过解码得到原始数字信号，完成下行通信；

所述的音频接入式移动支付终端是基于ARM的设备，将ARM输出的调制信号的幅度放大到峰峰值为2.75V-2.85V，在ARM发送和MIC接收间再插入衰减网络，将ARM输出信号调整为移动智能设备可接受的140mV以下；

在音频接入式移动支付终端端，采用自适应的双门限判别方式抑制FSK调频信号在传输过程中尖峰的脉冲干扰(实现对信号高精度解析)：

1)结合实时信号的包络，算出信号中心平均值，然后对该值分别加、减△A值，算出高低两个电平门限；

2)当信号从高电平往下低电平发展时，不管在这个过程中受到几次尖峰干扰的叠加，一直要到达低门限以下，才算一次有效的信号下降沿，反之亦然；当信号由低电平向高电平发展时，不论其自有多少次尖峰叠加，也必须信号电平达到上门限的时候，才认为是一次有效的信号上跳变；

实现方式是：采用滞回原理，采用从第一次上升到达高门限值开始到第一次下降到达低门限为一个下降过程，第一次下降到低门限到第一次上升到高门限值为上升过程来判断，由于高低门限值的差距比较大，可以有效去除干扰；

所述的外部设备包括移动智能设备和外部的USB设备通信；

采用所述的USB接入检测电路和音频接入检测电路自动检测当前的接入状态是USB接入还是音频接入；

所述安全算法3DES是指国际对称密码算法，SHA-1是国际哈希算法，RSA为国际非对称密码算法，SM2为国密非对称算法，SM3为国密哈希算法，SM4为国密对称算法。

2.根据权利要求1所述的基于安全算法的通信方法，其特征在于，在移动支付终端与银行服务器进行交易前建立安全通道；采用两套密码算法机制，其中国密算法采用SM2/SM3/SM4算法实现，国际标准算法采用RSA/SHA-1/3DES算法实现，整个SSL协议包含两个部分，分别是握手协议和记录层协议；

握手协议

1)客户端利用随机数产生机制产生32字节随机数ClientHello.random，根据终端的算法支持设置ClientHello.cipherSuite，向服务器端发送ClientHello消息，启动握手协议；

客户端的ClientHello消息包括32字节的随机数和1个字节的算法标识：32字节的随机数random由终端安全芯片生成；根据终端所支持的对称算法与非对称算法设置cipherSuite，算法标识字节的具体设置参见下表：

表1 算法描述符字节定义

B7 B6 B5 B4 B3 B2 B1 B0 算法 * * * * * * * 1 RSA * * * * * * 1 * ECC * * * 1 * * * * 3DES * * 1 * * * * * SM4

注：cipherSuite字节的相应位置为1表示终端可支持的密码算法集，ServerHello.cipherSuite的设置同上表，相应位置为1表示服务器选择的密码算法；

2)服务器端产生32字节随机数ServerHello.random，根据接收的ClientHello.cipherSuite选定可用的密码算法，设置ServerHello.cipherSuite；

服务器端ServerHello包括32字节的随机数和1字节的算法标识cipherSuite；服务器端产生32字节随机数ServerHello.random；根据接收的1字节的算法标识ClientHello.cipherSuite中获得终端支持的对称和非对称算法列表，检查算法列表中是否包含处理中心的对称算法和渠道证书所用的签名算法，服务器选定可用的密码算法，设置ServerHello.cipherSuite；

3)服务器端使用服务器证书设置ServerCertificate.certificate，

证书可以是SM2证书也可以是RSA证书，服务器证书用于认证渠道服务器的真实身份，确保终端与合法的渠道服务器进行通信；

4)服务器端发送ServerHello和ServerCertificate消息；

5)客户端收到证书后，利用CA证书中的公钥验证收到的服务器端证书，如果验证不通过，则发送ServerCertificateError消息，结束链接；否则，客户端产生48字节随机数作为共享主秘密master_secret，设置ClientKeyExchange.encryptedSharedSecret为加密master_secret得到的密文；根据协商的非对称公钥算法用服务端的公钥对master_secret加密；

6)客户端使用客户端证书设置ClientCertificate.certificate，使用客户端私钥生成CertificateVerify.signature＝Sign(ClientHello||ServerHello)；根据协商的非对称签名算法；客户端发送ClientCertificate、CertificateVerify和ClientKeyExchange到服务器端；

7)服务器端用CA证书的公钥验证客户端证书的合法性，用客户端证书的公钥验证客户端证书签名CertificateVerify；若验证不通过，则发送ClientCertificateError消息，结束链接；否则，利用服务端自己的私钥从ClientKeyExchange消息中解密得到共享主秘密master_secret；

8)服务器端发送握手验证消息ServerFinished，

服务器端对握手过程的验证消息定义如下：

message_MAC＝HMAC(master_secret,Finish_label||Hash(handshake_messages))

HMAC是密钥相关的哈希运算消息认证码，master_secret为主秘密，Finish_label为6个字节的ASCII码值“SERVER”，Hash算法使用SM3或SHA-1；Handshake_messages为握手消息的连接：

handshake_messages＝(ClientHello||ServerHello||Hash(ServerCertificate)||Hash(ClientCertificate)||CertificateVerify||ClientKeyExchange)；

9)客户端验证接收到的ServerFinished消息，若验证不成功，则发送ServerHandshakeError消息，结束链接；否则，发送客户端握手验证消息ClientFinished；

10)服务器端验证接收到的ClientFinished消息，验证失败，则发送ClientHandshakeError消息，结束链接，

11)上述握手过程成功后，双方使用如下方法计算会话密钥：

(a)采用SM3计算HMAC

X＝HMAC_sm3(master_secret,key_label||ClientHello.random||ServerHello.random)

其中key_label为3字节ASCII码“KEY”，HMAC算法参见密码算法部分；令X₁X₂…X₃₂分别为X的第1个至第32字节，则加密密钥SKey为：SKey＝X₁X₂…X₁₆，MAC密钥MKey为：MKey＝X₁₇X₁₈…X₃₂；

(b)采用SHA-1计算MAC

X＝HMAC_SHA-1(M1,key_label||ClientHello.random||ServerHello.randomM1为

master_secret取其前16个字节；

其中key_label为3字节ASCII码“KEY”，令X₁X₂…X₂₀分别为X的第1个至第20字节，则加密密钥SKey为：SKey＝X₁X₂…X₁₆，MAC密钥MKey为：MKey＝X₅X₆…X₂₀；

12)握手过程结束；

记录协议

在记录层，在建立安全通道的基础上，终端与服务器通讯双方进行数据传输；

记录层消息用于应用数据传输，定义如下：

其中encryptedData为加密后在安全信道中传输的应用数据；数据加密算法使用SM4算法或3DES算法；若采用SM4算法，消息认证码dataMac为使用SM4CBC模式最后一块数据计算结果的左8字节作为消息认证码；若采用3DES算法，消息认证码dataMac为8字节；length为encryptedData和dataMac长度之和，在实际使用中为2字节；

握手成功之后，双方在建立的安全通道上进行数据传输；

记录层协议的数据加密方法如下：

在传输的数据Data前添加数据块长度Length，构成数据块D＝(Length||Data)；默认使用加密密钥SKey和SM4算法CBC模式对D进行加密，即：

Record.encryptedData＝SM4_SKey(D)；

在数据传输过程中，为了保证记录层协议的数据完整性，采用以下保护方法：

在记录层协议的传输过程中，为双端每个发送和接收记录指定记录序列号；其初始值Seq₀的设置为：

令R₁R₂…R₃₂是ClientHello.random的第1到32字节，并令Q₁Q₂…Q₃₂是ServerHello.random的第1到32字节，则：Seq0＝R₁R₂…R₈||Q₁Q₂…Q₈；以后每发送或接收一帧记录信息后，记录序列号加1，双端要保持发送接收序列号的同步：

Seq_i＝Seq_i-1+1

双方交互的应用数据的完整性使用消息认证码MAC进行保护，MAC的生成方法为：

Record.data_MAC＝MAC(MKey,Seq_i||Record.encryptedData)

其中Record.encryptedData是所传输的加密应用数据，Seq_i是当前的记录序列号；客户端或服务器端接收到数据后，首先验证MAC的正确性，如果正确则进行处理；否则，发送错误消息，重启握手协议。