一种动态双向认证的安全移动通讯架构及其实现方法
【技术领域】
[0001]本发明涉及移动信息安全领域，尤其涉及一种动态双向认证的安全移动通讯机制及其实现方法。
【背景技术】
[0002]截止到2015年第二季度，中国手机网民用户规模已达到6.57亿人，中国智能手机用户已达6.01亿人，移动支付同比增长445%，中国消费者已经进入移动支付时代。然而，不法分子制作假冒网银升级助手、盗版手机网银客户端、钓鱼支付宝等恶意软件，已经严重威胁到了移动支付安全。
[0003]国内首份手机银行APP安全报告显示，大部分手机银行APP并不安全，尤其少数手机银行的安卓客户端存在加密机制不完整、不校验服务器身份等安全隐患，有可能被电脑黑客或木马病毒所利用。登陆作为用户使用手机银行客户端的第一步，因为要输入银行账号及密码等敏感信息，安全性尤为重要。但是安全报告显示，两类登陆安全隐患明显:一类是加密机制不完整或过于简单，很容易被攻击者劫持或破解；另一类是在通信过程中不对服务端身份进行校验，从而导致登陆过程很容易遭遇“中间人攻击”。其中，部分手机网银APP用“HTTP (超文本传输协议)+简单加密”模式传输，极易被劫持或破解。
[0004]据悉，仿冒、钓鱼类的恶意程序很可能会采用这样一种手法:在后台监控前台窗口的运行，如果前台是一个银行应用的登陆界面，恶意程序就立即启动自己的仿冒界面，这个动作可以快到用户无任何感知。而用户在无察觉的情况下一旦在仿冒的登陆界面里输入用户名密码，就会导致账号和密码被盗。更可怕的是，一款恶意程序甚至可以同时检测、仿冒和劫持多个银行客户端的登陆界面，而很多银行APP并不能有效的解决这类问题。
[0005]APP应用的安全问题逐渐被用户关注，如果利用服务器存储客户资料，那应该考虑使用SSL加密客户跟服务器之间的通讯，SSL能保障敏感信息(如:银行卡号，社保卡号，登陆凭证等)的传输安全。
[0006]360手机安全中心统计发现，有50%的手机APP正在使用https安全传输协议，使用https协议的APP，包括手机广告插件类、手机支付类、社交分享类等多个类型的APP。来自汉诺威和马尔堡大学的专家们对Play Store中1.3万个最流行的免费软件进行了 SSL和TLS漏洞研究，他们发现，1074个APP程序包含SSL特定代码，这些代码要么接受所有认证，要么接受所有认证主机名，由此成为潜在MITM (man-1n-the-middle)攻击的漏洞。科学家们还对100个APP应用程序进行了手动审计，结果发现，由于SSL漏洞的存在，41个程序对MITM攻击是开放的。专家们表示，漏洞APP应用程序可能被利用，攻击者得以窃取高度敏感的用户信息，包括他们在Facebook、Google、Yahoo，甚至网上银行的用户名和密码。虽然使用https协议，这些APP服务器端口信息仍可能被黑客盗取，危及手机登陆所用的账号密码等隐私安全。
【发明内容】
[0007]本发明针对上述客户终端的APP与服务器端通信存在的仿冒、钓鱼、中间人攻击等问题，创新提出了一种动态双向认证的安全移动通讯架构及其实现方法，以期解决安全通信的问题。
[0008]本发明的上述第一个目的，其得以实现的技术解决方案是:一种动态双向认证的安全移动通讯架构，其特征在于:所述安全移动通讯架构基于客户终端和服务器端之间SSL证书及非对称密钥对实现，其中所述SSL证书为由服务器端签发并硬编码于客户终端开发的APP中，所述客户终端在APP业务过程中对发自服务器端的SSL证书与硬编码的SSL证书验证匹配性，所述非对称密钥对为产生于客户终端的一对公钥和私钥并与在服务器端注册的用户唯一对应，其中所述公钥通过SSL安全通道发送并仅收存至服务器端，所述私钥加密保存固化于客户终端中且具有非网络传输性，所述服务器端通过SSL安全通道及公钥验证私钥签名的有效性。
[0009]进一步地，所述SSL证书为服务器端基于证书锁定的自签发SSL证书。
[0010]进一步地，所述SSL证书为服务器端采用的第三方机构签发的SSL证书。
[0011]本发明的上述第二个目的，其得以实现的技术解决方案基于前述安全移动通讯架构实现，其特征在于包括步骤:
501、服务器端签发SSL证书并硬编码于客户终端开发的APP中，同时客户终端在用户注册时自动产生一个专属于用户及本机的非对称密钥对，将非对称密钥对的公钥通过SSL安全通道发送并收存于服务器端，并删除本机上的公钥；非对称密钥对的私钥通过PIN/passcode加密保存在客户终端的本机；
502、客户终端向服务器端发送证书验证请求；
503、服务器端将SSL证书发送给客户终端；
504、客户终端对比硬编码在本机的SSL证书与接收到的SSL证书是否一致，完成客户终端对服务器端的认证；
505、服务器端对客户终端的APP进行完整性校验，并建立SSL安全信道；
506、用户在客户终端上输入ID和PIN，本机存储的私钥得到解密；
507、服务器端向客户终端通过SSL安全信道发送一个随机挑战码；
508、客户终端用本机存储的私钥对所述随机挑战码进行签名，并将签名值回发送至服务器端；
509、服务器端用存储的对应公钥对客户终端发送的签名值进行验签，完成服务器端对客户终端的认证；
510、客户终端和服务器端进行安全的APP业务。
[0012]进一步地，所述安全移动通讯实现方法用于有防御黑客钓鱼、中间人攻击需求的手机银行、移动支付或社交分享平台分别与各自后台服务器之间的通讯。
[0013]应用本发明动态双向认证的安全移动通讯架构及其实现方法，较之于现有的移动通讯架构具有显著的进步性:客户终端与服务器端双向认证，采用SSL安全协议进行通讯，保证了通讯数据的安全性，消除了普通移动通讯机制中存在的仿冒、钓鱼、中间人攻击威胁。服务器端采用自签发证书，无需向第三方机构申请证书，省去了繁琐的证书申请、维护流程，并在一定程度上节省了成本；客户终端认证无需设备证书，通过非对称密钥对和PKI技术提供身份访问权限管理(IAM)，能完全防御黑客登陆攻击、钓鱼攻击、恶意软件攻击。
【附图说明】
[0014]图1为本发明中客户终端及用户在服务器端注册ID的流程示意图。
[0015]图2为本发明中动态双向认证的安全移动通讯架构实现方法的流程示意图。
【具体实施方式】
[0016]本发明针对现有移动通讯机制中存在的仿冒、钓鱼、中间人攻击问题，提出了一种动态双向认证的安全移动通讯架构，并给出了其实现方法。为了更清楚地说明本发明中的移动通讯架构和实现方法，下面结合附图和实施例对本发明进行具体的描述，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
[0017]首先需要介绍的是本发明动态双向认证赖以实现的硬件架构，其基于客户终端和服务器端之间SSL证书及非对称密钥对实现，其中该SSL证书为由服务器端签发并硬编码于客户终端开发的APP中，该客户终端在APP业务过程中对发自服务器端的SSL证书与硬编码的SSL证书验证匹配性，该非对称密钥对为产生于客户终端的一对公钥和私钥并与在服务器端注册的用户唯一对应，其中所述公钥通过SSL安全通道发送并仅收存至服务器端，该私钥加密保存固化于客户终端中且具有非网络传输性，该服务器端通过SSL安全通道及公钥验证私钥签名的有效性。
[0018]需要说明的是，通常一个APP是固定连接至一台服务器的，故而上述SSL证书可以是服务器端基于证书锁定的自签发SSL证书，适用性较强。当然实际应用中，服务器端也会采用第三方机构签发的SSL证书，客户终端对服务器端的认证需要验证证书链，以确认该证书是否为可信机构颁发，如果证书验证过程中出现问题，客户终端会警告用户该证书不可信，但部分用户仍然会选择信任有问题的证书，从而给黑客钓鱼和中间人攻击带来了机会。
[0019]接着详述本发明安全通讯的实现方法:在采用本发明的动态双向认证移动通讯架构进行通讯之前，客户终端用户需在服务器端进行注册，如图1所示，为本发明中客户终端用户在服务器端注册ID的流程，它至少包含以下步骤:
A、客户终端向服务器端发送证书验证请求；
B、服务器端将SSL证书发送给客户终端；
C、客户终端对比硬编码在本地的SSL证书与接收到的SSL证书是否一致；
D、服务器端对客户终端APP进行完整性校验；
E、客户终端与服务器端建立SSL安全通信信道；
F、用户设置用户名，同时客户终端在移动设备为用户产生一个非对称密钥对，并将公钥经SSL加密发送给服务器端，并删除本地公钥，服务器端将公钥加密保存；
G、客户终端用户将用户名和用户名签名一起发送给服务器端；
H、服务器端检查用户名是否可用，并验证签名的有效性；
1、客户终端要求用户设置PIN/passcode/指纹，用来加密密钥对的私钥。
[0020]进一步地、步骤B中所述服务器端SSL证书是自签发证书，即指没有通过受信任的证书颁发机构，由签名实体发给自身的证书，发布者和证书主体相同。跟电脑浏览网页不同，手机应用一般固定的连接到一台服务器端，适合采用自签发证书，使用自签名证书的好处是不需要额外申请、安装其他证书，省去了繁琐的证书申请、维护流程，同时自签名证书是免费的，一定程度上节省了成本。
[0021]进一步地，对于自签发证书，这里采用证书锁定技术，直接把服务器端证书硬编码在客户终端中，然后在应用中使用自己定义的信任存储代替手机系统自带的信任存储，去连接指定的服务器端。采用这种方式，应用不再依赖系统自带的信任存储，使得破解这种应用变得复杂。
[0022]进一步地，步骤E中客户终端与服务器端建立SSL安全信道中至少包含以下步骤:
(1)客户终端产生随机数Client.Random,发送给服务器端；
(2)服务器端产生随机数Server.Random，发给客户终端；
(3)客户终端随机产生一个用于后面通讯的预主密钥Pre-master-key，并用服务器端公钥SPubKey加密预主密钥C=E(SPubKey，Pre-master-key)发送给服务器端；
(4)服务器端收到C之后用证书私钥对其解密，得到预主密钥，然后根据Client.Random, Server.Random 和预主密钥 Pre-master-key 生成主密钥 master-key ；
(5)客户终端根据Client.Random, Server.Random 和预主密钥 Pre-master-key 用同样的方法生成主密钥mast