安全认证方法、设备和系统与流程

本发明涉及安全通信领域，更具体地涉及使用认证客户端来进行安全认证的方法、设备和系统。

背景技术：
随着网络通信技术的发展，网络交易已经成为当今社会中重要的经济活动组成部分。然而，随之而来的则是与网络交易的安全性相关的各种问题。例如，当用户使用移动终端来进行交易支付时，其使用的交易客户端软件有可能是经过恶意第三方修改过的伪交易客户端软件。由于这种伪交易客户端软件通常具有与正常的交易客户端软件相似乃至相同的界面，用户很容易受到欺骗并使用该伪交易客户端软件来进行交易支付，从而导致用户的个人资料、信用卡/借记卡号、支付密码等信息泄漏给恶意第三方，并极有可能给用户造成巨大的、不可挽回的损失。通常，很多银行、信用卡发行机构等采用Java语言来开发它们自己的交易客户端软件。然而，对以Java语言编写的程序的反编译与其它高级语言相比更加容易实现，并且反编译后的代码几乎能够与源代码相媲美。从而，基于Java语言的交易客户端软件对于恶意第三方的篡改、攻击是脆弱的。例如，在基于Android平台的移动终端上，通过对其上运行的以Java编写的交易客户端软件进行反编译并进行篡改，恶意第三方可以向该交易客户端软件的通信模块、输入模块、短信模块等重要模块植入恶意代码(监控模块)。通过该监控模块，恶意第三方可以掌握并篡改通过移动终端上的伪交易客户端软件输入和/或输出的各种信息，例如：支付平台地址、支付对象、支付金额、支付短信确认等等。这样，有可能通过向用户显示篡改后的信息以及通过向与用户预期相同或不 同的交易平台发送篡改后的对象、金额等，在用户意识不到的情况下，产生过度支付、向错误对象支付等各种情况。

技术实现要素：
因此，本发明提供了用于安全认证的方法、设备和系统。根据本发明的第一方面，提供了一种用于安全认证的方法。该方法包括：(a)向认证服务器发送与认证客户端相关的数据；(b)从所述认证服务器接收由所述认证服务器基于所述与认证客户端相关的数据和由目标服务器返回的认证数据所生成的客户端数据；(c)使用所述客户端数据中包括的可执行代码来验证所述认证客户端的安全性；以及(d)在确定所述认证客户端安全的情况下，使用所述认证数据来登录所述目标服务器。在一些实施例中，所述认证客户端是经过代码加固的。在一些实施例中，所述代码加固包括：代码加密、代码混淆、代码乱序。在一些实施例中，在步骤(a)之前，所述方法还包括：所述认证客户端自检。在一些实施例中，所述认证客户端自检的步骤包括以下一项或多项：对所述认证客户端的动态链接库文件和Java文件的完整性的校验；以及对所述目标服务器发布给所述认证客户端的公钥的验证。在一些实施例中，所述认证客户端包括使用非Java编程语言来实现的关键模块，其中，所述关键模块包括通信模块、输入模块、短信模块中的一项或多项，以及所述关键模块是通过JavaNativeInterface(JNI)来调用的。在一些实施例中，所述非Java编程语言是C或C++。在一些实施例中，所述与认证客户端相关的数据包括以下一项或多项：所述认证客户端所处的设备的设备标识符；所述认证客户端所处的设备的用户的用户标识符；所述目标服务器发布给所述认证客户端的公钥；以及所述认证客户端的版本信息。在一些实施例中，所述认证数据是由所述目标服务器响应于所述认证服务器发送的请求而生成并返回的认证数据。在一些实施例中，所述客户端数据还包括以下一项或多项：指定所述客户端数据的版本或格式的报头；指定与所述认证客户端相关的一个或多个文件的位置的信息；所述一个或多个文件的数字摘要值；指定所述可执行代码的长度的信息；以及指示所述客户端数据的末尾的数据结束标记。在一些实施例中，如果所述客户端数据是加密数据，则在步骤(c)之前，所述方法还包括：对所述客户端数据解密。在一些实施例中，步骤(c)包括：使用所述可执行代码来验证在指定位置上的与所述认证客户端相关的一个或多个文件的完整性和所述目标服务器发布给所述认证客户端的公钥。根据本发明的第二方面，提供了一种用于安全认证的设备。该设备包括：发送单元，用于向认证服务器发送与认证客户端相关的数据；接收单元，用于从所述认证服务器接收由所述认证服务器基于所述与认证客户端相关的数据和由目标服务器返回的认证数据所生成的客户端数据；验证单元，用于使用所述客户端数据中包括的可执行代码来验证所述认证客户端的安全性；以及登录单元，用于在确定所述认证客户端安全的情况下，使用所述认证数据来登录所述目标服务器。在一些实施例中，所述认证客户端是经过代码加固的。在一些实施例中，所述代码加固包括：代码加密、代码混淆、代码乱序。在一些实施例中，所述设备还包括：本地检查单元，用于所述认证客户端自检。在一些实施例中，所述本地检查单元被配置为执行以下一项或多项：对所述认证客户端的动态链接库文件和Java文件的完整性的校验；以及对所述目标服务器发布给所述认证客户端的公钥的验证。在一些实施例中，所述认证客户端包括使用非Java编程语言来实现的关键模块，其中，所述关键模块包括通信模块、输入模块、短信 模块中的一项或多项，以及所述关键模块是通过JavaNativeInterface(JNI)来调用的。在一些实施例中，所述非Java编程语言是C或C++。在一些实施例中，所述与认证客户端相关的数据包括以下一项或多项：所述认证客户端所处的设备的设备标识符；所述认证客户端所处的设备的用户的用户标识符；所述目标服务器发布给所述认证客户端的公钥；以及所述认证客户端的版本信息。在一些实施例中，所述认证数据是由所述目标服务器响应于所述认证服务器发送的请求而生成并返回的认证数据。在一些实施例中，所述客户端数据还包括以下一项或多项：指定所述客户端数据的版本或格式的报头；指定与所述认证客户端相关的一个或多个文件的位置的信息；所述一个或多个文件的数字摘要值；指定所述可执行代码的长度的信息；以及指示所述客户端数据的末尾的数据结束标记。在一些实施例中，如果所述客户端数据是加密数据，则所述设备还包括：解密单元，用于对所述客户端数据解密。在一些实施例中，所述验证单元被配置为：使用所述可执行代码来验证在指定位置上的与所述认证客户端相关的一个或多个文件的完整性和所述目标服务器发布给所述认证客户端的公钥。根据本发明的第三方面，提供了一种用于安全认证的系统。该系统包括：根据如上所述的设备；认证服务器，用于从所述设备接收与认证客户端相关的数据，验证接收到的数据，向目标服务器发送用于请求认证数据的请求，基于所述目标服务器返回的认证数据和从所述设备接收到的数据，生成客户端数据，以及向所述设备发送所述客户端数据；以及目标服务器，用于从所述认证服务器接收针对认证数据的请求，以及向所述认证服务器返回所述认证数据。使用本发明的方法、设备和系统，降低了用户信息被恶意第三方篡改的可能性，提高了支付客户端软件的破解难度，最大程度地保证 了交易信息的安全性。附图说明通过下面结合附图说明本发明的优选实施例，将使本发明的上述及其它目的、特征和优点更加清楚，其中：图1是示出了根据本发明的安全认证系统的示例的示意图。图2是示出了根据本发明实施例的安全认证方法的示例的流程图。图3是示出了根据本发明实施例的安全认证设备的示例的功能框图。在本发明的所有附图中，相同或相似的结构均以相同或相似的附图标记标识。具体实施方式下面参照附图对本发明的优选实施例进行详细说明，在描述过程中省略了对于本发明来说是不必要的细节和功能，以防止对本发明的理解造成混淆。以下，以本发明应用于无线移动通信系统的场景为例，对本发明进行了详细描述。但本发明并不局限于此，本发明也可以应用于固定通信系统、有线通信系统，或者应用于无线移动通信系统、固定通信系统、有线通信系统等的任意混合结构。就移动通信系统而言，本发明并不局限于所涉及的各个移动通信终端的具体通信协议，可以包括(但不限于)2G、3G、4G、5G网络，WCDMA、CDMA2000、TD-SCDMA系统等，不同的移动终端可以采用相同的通信协议，也可以采用不同的通信协议。本发明并不局限于移动终端的具体操作系统，可以包括(但不限于)iOS、WindowsMobile、Symbian、Android等，不同的移动终端可以采用相同的操作系统，也可以采用不同的操作系统。图1是示出了根据本发明的安全认证系统1000的应用场景的示意图。如图1所示，安全认证系统1000可以包括移动终端100、认证服 务器200、以及目标服务器300。为了清楚起见，图中仅示出了一个移动终端100，但本发明并不局限于此，还可以包括一个或多个固定终端、两个以上的移动终端、或任意数目的移动终端和固定终端的组合等等。移动终端100可以属于用户，或者可以由用户操作。移动终端100可以通过通信网络与认证服务器200和目标服务器300相连并与之进行通信。通信网络的示例可以包括(但不限于)：互联网、移动通信网络、固定线路(如xDSL、光纤等)等。此外，认证服务器200和目标服务器300也可以通过通信网络相连并彼此通信。移动终端100包括安装在其中的认证客户端150。认证客户端150可以由用户以软件的形式自行安装在移动终端100中，或者可以由终端生产厂商以硬件或固件的形式安装在移动终端100中。在一些实施例中，认证客户端150可以是例如在用户购买了移动终端100之后从例如安卓应用商店、苹果应用商店中下载的专门用于安全认证的应用软件。在另一些实施例中，认证客户端150可以是例如由终端生产厂商以固件或硬件形式预先安装在移动终端100中的应用程序。在又一些实施例中，认证客户端150可以是网页浏览器，如IE、Firefox等等，其通过安全认证页面(如银行、网络支付平台等的页面)进行认证。在另外一些实施例中，认证客户端150可以是机顶盒中的嵌入式模块(其可以是硬件、固件或软件)，其通过有线电视网络进行认证。如图1所示，认证客户端150可以包括主要以Java编写的部分和以其它编程语言编写的模块。如上所述，以纯Java语言编写的认证客户端的代码很容易被恶意第三方反编译并进而被篡改。因此，为了增加恶意第三方反编译的难度，提高反编译的成本，在本实施例中，使用了JavaNativeInterface(JNI，即Java本地接口或Java本地调用)。JNI允许Java代码和其他语言编写的代码进行交互。其原始用途是支持旧的库文件(例如，以C/C++编写的目标文件)，以减少开发周期并降低开发成本。此外，其还用于调用以C/C++/汇编语言等编写的时间敏感的底层程序，以直接与硬件/操作系统底层进行交互，从而实现例如实时任务。除了C/C++之外，其它可以通过JNI调用的模块的编程语言可以包括(但不限于)：汇编语言、FORTRAN等。在其他实施例 中，取代使用JNI，还可以使用类似于JNA(JavaNativeAccess)等方便Java调用其他语言编写的模块的接口/库等，然而为了说明的便利，在本实施例中，使用JNI。在本实施例中，我们使用JNI的主要目的与上述两个目的不同，即主要不是为了调用旧的库或实现实时任务，而是为了提高反编译的难度并增加恶意第三方篡改认证客户端150的成本。在该情况下，我们使用反编译难度更大的语言(例如，C/C++)来编写认证客户端150的关键模块，并通过JNI来调用这些模块，以在保证认证客户端150完成自身任务的同时，也能提高反编译的难度。在下文中，将把JNI以及使用其它编程语言编写的模块统称为JNI层，如图1所示。在一个实施例中，认证客户端150的一些关键模块，包括(但不限于)通信模块、输入模块、短信模块，可以由C/C++来实现。当然，其他模块也可以由C/C++来实现。此外，这三个模块中的一个或多个也可以由其他语言(例如，汇编语言/FORTRAN等)来实现，不限于上面给出的示例。在本实施例中，以C/C++语言编写的模块通常以动态链接库的形式由认证客户端150来加载并调用。在本实施例中，如图1所示，假定认证服务器200和目标服务器300始终在线，即它们始终可用。在本实施例中，目标服务器300可以是由例如银行/信用卡发行机构等金融机构提供的支付平台，其主要用于向认证客户端150所在的终端100的用户提供支付服务。在本实施例中，认证服务器200通常可以是由目标服务器300的提供方所提供的认证服务器，即认证服务器200和目标服务器300由同一提供方提供和维护，且很有可能位于同一位置(甚至是同一台物理服务器)。在该情况下，假定认证服务器200和目标服务器300之间的通信是安全的。然而，在备选实施例中，认证服务器200也可以是由独立的第三方认证机构所提供和维护的认证服务器，即认证服务器200和目标服务器300是由不同提供方提供的。在该情况下，需要保证认证服务器200和目标服务器300之间的通信是安全的。可以使用各种加密手段对认证服务器200和目标服务器300之间的通信进行加密，以保证其安全性。加密的方式包括(但不限于)：对称密钥加密，例如DES、 3DES等；非对称密钥加密，例如RSA、AES、ECC、Diffie-Hellman等。从而，在本发明中，可以保证在认证服务器200和目标服务器300之间的通信安全。如上所述，在图1所示的通信系统中，为了通过移动终端100来进行支付，移动终端100需要借助认证服务器200向目标服务器300进行认证。在本实施例中，该过程主要包括三重交互。(1)第一重交互在认证客户端150启动之前，其可以经过代码加固。代码加固通常包括以下一种或多种加固方式：代码加密、代码混淆、代码乱序等。代码加密是通过加密算法(对称算法/非对称算法)对二进制可执行文件进行加密，当运行程序时先将加密的代码解密为明文然后运行，将代码加密可以有效防止攻击者进行静态反编译。代码混淆通常是指使用以下若干方式增加反编译难度：(1)将代码中的各种元素，如变量、函数、类的名字改写成无意义的名字，甚至是“__”之类的符号，使得阅读者难以根据名字猜测其用途；(2)重写代码逻辑，将其变为功能等价但是更难以理解的形式，例如将循环改成递归、精简中间变量等等；以及(3)打乱代码格式，例如删除空格、将多行代码放到一行中等等。通过代码混淆，使得反编译出来的代码可读性极低，增加了篡改认证客户端150的难度，提高了认证客户端150的安全性。该代码加固方式通常可以使用专用的代码混淆程序来执行，例如包括(但不限于)Proguard等。代码乱序(花指令)通常是指对编译后的代码和/或其顺序进行一定的调整和/或修改，在不影响原代码的执行顺序的同时，使得恶意第三方在反编译时生成错误的代码。移动终端100在发起交易时，首先进行自检，该自检(第一重交互)可以包括例如：对动态链接库和Java文件的完整性进行校验、以及对目标服务器300发放的公钥(Publickey)进行验证。在程序启动之后，如图1所示，认证客户端150中的Java层和JNI层进行相互验证。例如，在启动之后，Java层对JNI层中的一些或全部文件(例如，C/C++代码编译后的动态链接库文件)进行完整性验 证。例如，将Java层中保存的JNI层的一些或全部文件的md5与Java层在运行时实时计算出的这些文件的md5进行比对，从而确保这些文件未被篡改过。相应地，JNI层也可以对Java层执行类似操作。对目标服务器300发放的公钥(Publickey)进行验证通常可以包括对目标服务器300发放的公钥进行签名验证，以确保该公钥确实是由目标服务器300所发放的公钥。此外，认证客户端150通过JNI层中包括的关键模块(例如，输入模块、通信模块、短信模块等)来执行以下操作：接收用户输入，与认证服务器200和目标服务器300通信，或接收确认短信等等，从而由于JNI层的难破解性，提高了认证客户端150的安全性，增加了破解的难度。(2)第二重交互在自检之后，认证客户端150向认证服务器200提交各种相关信息以进行认证。提交的信息可以包括(但不限于)：IMEI(国际移动设备身份码)、IMSI(国际移动用户身份码)、目标服务器300发布的公钥、以及认证客户端150的软件版本等。向认证服务器200提交这些信息的方式可以是通过HTTP规范的POST方法。当然，也可以通过其他方法来提交数据，并不限于上述POST方法。认证服务器200在接收到这些信息之后，对这些信息与在相关数据库中保存的信息进行比对，并确定这些信息是否匹配。如果不匹配，则认证服务器200可以忽略认证客户端150发送的认证请求，或返回拒绝响应。如果匹配，则认证服务器200向目标服务器300发送认证码请求，以请求目标服务器300返回登录目标服务器300所需的认证码。目标服务器300在接收到该请求之后，根据相关信息(例如，认证客户端150提交的IMEI/IMSI/公钥/版本等)返回登录所需的认证码。该认证码可以是永久性的也可以是有限时间/次数的(例如，仅用于指定时间内的一次或多次登录)。在认证服务器200接收到目标服务器300返回的认证码之后，认证服务器200生成客户端数据。该客户端数据可以包括(但不限于)： 指定客户端数据的版本或格式的报头；指定与认证客户端150相关的一个或多个(关键)文件的位置的信息；一个或多个(关键)文件的数字摘要值；指定可执行代码的长度的信息；可执行代码(ShellCode)；由目标服务器300返回的认证码；以及指示客户端数据的末尾的数据结束标记等。下面对这些数据进行详细说明。-指定客户端数据的版本或格式的报头，该数据表示客户端数据的版本或应当具有的格式。由于系统的升级需要，在客户端数据中所包含的数据的格式可能会不同，因此对于不同的系统，需要该报头来指定其所应当具有的格式，以保证后向兼容性。-指定与认证客户端150相关的一个或多个(关键)文件的位置的信息，该信息表示与认证客户端150的一个或多个要检查的文件的位置相关的信息。该一个或多个要检查的文件通常是认证客户端150的关键文件，例如其配置文件、关键模块对应的库文件(目标文件)等。通过指定这些文件的位置，可以使得认证客户端150对这些文件进行验证，以提升其安全性。-一个或多个(关键)文件的数字摘要值，与上述文件的位置相对应，指定相应位置上的文件所应当具有的数字摘要值。例如，如果上面的位置是“/etc/config.conf”，且相对应的数字摘要值是该文件的md5，则可以由认证客户端150对“/etc/config.conf”文件计算其md5，并与客户端数据中包括的md5进行比对，以确认该文件是否被篡改。-指定可执行代码的长度的信息，该数据表示后面紧接着的该长度的数据是可执行代码。-可执行代码(ShellCode)，由认证服务器200向认证客户端150下发的可执行代码，通过由移动终端100执行该可执行代码，可以验证认证客户端150的全部或部分(其公钥、关键文件)完整性。-由目标服务器300返回的认证码，用于移动终端100 上的认证客户端150向目标服务器300进行登录之用。-指示客户端数据的末尾的数据结束标记，表明客户端数据结束。在生成客户端数据之后，认证服务器200向认证客户端150返回该数据。在本实施例中，该数据可以是加密的。在备选实施例中，该数据也可以是部分加密的，例如对其中的“认证码”进行加密，对其余部分不加密。当然，加密的部分不限于此，也可以对其他部分加密。认证客户端150在接收到客户端数据之后，对其进行相应的解密，提取出所需的各种信息。在本实施例中，使用在解密后的客户端数据中包括的可执行代码来验证认证客户端150的完整性(包括其公钥的完整性、关键文件的完整性等)。从而，最大限度地保证了认证客户端150的安全性。(3)第三重交互认证客户端150使用在客户端数据中包括的认证码，向目标服务器300登录，并从而完成认证、交易过程。图2是示出了根据本发明实施例的安全认证方法400的流程图。如图2所示，安全认证方法400可以包括步骤S410、S420、S430、S440、S450、S460、S470、S480和S490，其中，部分步骤可以单独执行或组合执行，以及可以并行执行或顺序执行，并不局限于图2所示的具体操作顺序。在一些实施例中，安全认证方法400可以由图1所示的移动终端100或安装在移动终端100中的认证客户端150、认证服务器200和目标服务器300来执行。图3是示出了根据本发明实施例的移动终端100的框图。如图3所示，移动终端100可以包括：发送单元110、接收单元120、验证单元130、以及登录单元140。发送单元110用于向认证服务器200发送与认证客户端150相关的数据。在一些实施例中，发送单元110可以是移动终端100的中央处理单元(CPU)、数字信号处理器(DSP)、微处理器、微控制器等 等，其可以与移动终端100的发射机和/或收发信机相配合，向认证服务器200发送相关数据。接收单元120用于从认证服务器200接收由认证服务器200基于与认证客户端150相关的数据和由目标服务器300返回的认证数据所生成的客户端数据。在一些实施例中，接收单元110可以是移动终端100的中央处理单元(CPU)、数字信号处理器(DSP)、微处理器、微控制器等等，其可以与移动终端100的接收机和/或收发信机相配合，接收来自认证服务器的客户端数据。验证单元130用于使用客户端数据中包括的可执行代码来验证认证客户端150的安全性。验证单元130可以是移动终端100的中央处理单元(CPU)、数字信号处理器(DSP)、微处理器、微控制器等等，其可以与移动终端100存储器相配合，执行客户端数据中包括的可执行代码，来验证在存储器中存储的认证客户端150的相关文件。登录单元140用于在确定认证客户端150安全的情况下，使用认证数据来登录目标服务器300。登录单元140可以是移动终端100的中央处理单元(CPU)、数字信号处理器(DSP)、微处理器、微控制器等等，其可以与移动终端100的发射机、接收机、和/或收发信机相配合，使用认证数据(例如，由目标服务器300向认证服务器200返回的认证码)向目标服务器300执行登录过程。此外，在其他实施例中，移动终端100还可以包括用于认证客户端150自检的本地检查单元和用于对客户端数据解密的解密单元。其各自的具体功能分别如上面关于“自检”和“解密”过程所述，此处不再赘述。以下将结合图2和图3，对根据本发明实施例的安全认证方法400和移动终端100进行详细的描述。在步骤S410中，由移动终端100的本地检查单元对认证客户端150进行自检。在步骤S420中，由移动终端100的发送单元110向认证服务器200发送与认证客户端150相关的数据。在步骤S430中，认证服务器200在验证认证客户端150提交的数据匹配之后，向目标服务器300发送认证码请求。在步骤S440中，目标服务器300向认证服务器200返回登录目标服务器300所需的认证码。在步骤S450中，认证服务器200基于认证客户端150提交的数据和目标服务器300返回的认证码来生成客户端数据并对其加密。在步骤S460中，由移动终端100的接收单元120从认证服务器200接收该客户端数据。在步骤S470中，由移动终端100的解密单元对该客户端数据解密。在步骤S480中，由移动终端100的验证单元130使用客户端数据中包括的可执行代码来验证认证客户端150的安全性(例如，完整性)。在步骤S490中，在确定认证客户端150安全的情况下，由移动终端100的登录单元140使用客户端数据中包括的认证数据来登录目标服务器300。在一些实施例中，认证客户端150是经过代码加固的。在一些实施例中，代码加固包括：代码加密、代码混淆、代码乱序。在一些实施例中，认证客户端150自检的步骤包括以下一项或多项：对认证客户端150的动态链接库文件和Java文件的完整性的校验；以及对目标服务器300发布给认证客户端150的公钥的验证。在一些实施例中，认证客户端150包括使用非Java编程语言来实现的关键模块，其中，关键模块包括通信模块、输入模块、短信模块中的一项或多项，以及关键模块是通过JavaNativeInterface(JNI)来调用的。在一些实施例中，非Java编程语言是C或C++。在一些实施例中，与认证客户端150相关的数据包括以下一项或多项：认证客户端150所处的设备的设备标识符；认证客户端150所处的设备的用户的用户标识符；目标服务器300发布给认证客户端150 的公钥；以及认证客户端150的版本信息。在一些实施例中，客户端数据还包括以下一项或多项：指定客户端数据的版本或格式的报头；指定与认证客户端150相关的一个或多个文件的位置的信息；该一个或多个文件的数字摘要值；指定可执行代码的长度的信息；以及指示客户端数据的末尾的数据结束标记。在一些实施例中，步骤S480包括：使用可执行代码来验证在指定位置上的与认证客户端150相关的一个或多个文件的完整性和目标服务器300发布给认证客户端150的公钥。至此已经结合优选实施例对本发明进行了描述。应该理解，本领域技术人员在不脱离本发明的精神和范围的情况下，可以进行各种其它的改变、替换和添加。因此，本发明的范围不局限于上述特定实施例，而应由所附权利要求所限定。