CN117728976A - 数据传输方法、装置、设备及存储介质 - Google Patents

Abstract

本申请提出一种数据传输方法、设备及存储介质，应用于代理服务器，代理服务器部署在第一服务端，包括：接收客户端发送的服务请求数据；基于USBKey驱动配置信息，获取与代理服务器相连接的USBKey设备中的秘钥信息；利用秘钥信息对服务请求数据进行加密，得到数字签名；将数字签名和服务请求数据发送至第二服务端，以用于第二服务端在验证数字签名无误的情况下，完成服务请求数据对应的服务请求。本申请实施例避免了数字签名过程为在每个工作人员进行操作的设备上安装相应的数字签名的相关签名控件，节省需要多个USBKey设备的设备管理成本，并且USBKey设备与第一服务端连接，避免了客户端直接操作USBKey设备的风险。

Description

数据传输方法、装置、设备及存储介质

技术领域

本申请属于数据处理技术领域，具体涉及一种数据传输方法、装置、设备及存储介质。

背景技术

目前，银行会为企业提供各种服务，比如贷款服务，存款服务，企业的相关人员会在相关服务请求上进行数字签名，以保证相关服务请求的数据完整性以及不可否认性，进一步将签名后的相关服务请求提交银行以进行身份认证完成相关服务。

企业的相关人员在相关服务请求上进行数字签名时，需要在每个工作人员进行操作的设备上安装相应的数字签名的相关签名控件，比如密码控件，中间件，USBKey设备驱动等，并插入相应的USBKey设备，通过USBKey设备存储的私钥完成数字签名。

目前的数字签名过程需要在每个工作人员进行操作的设备上安装相应的数字签名的相关签名控件，操作麻烦，且如果存在多个工作人员，需要多个USBKey设备，如果不同工作人员相互借用USBkey设备，有设备管理成本。工作人员可以直接在客户端操作USBKey设备，存在安全风险。

发明内容

本申请提出一种数据传输方法、装置、设备及存储介质，能够缓解相关技术中在企业端进行数字签名时操作麻烦、设备管理成本以及安全风险高的技术问题。

本申请第一方面实施例提出了一种数据传输方法，应用于代理服务器，所述代理服务器部署在第一服务端，包括：

接收客户端发送的服务请求数据；

基于USBKey驱动配置信息，获取与所述代理服务器相连接的USBKey设备中的秘钥信息；

利用所述秘钥信息对所述服务请求数据进行加密，得到数字签名；

将所述数字签名和所述服务请求数据发送至第二服务端，以用于所述第二服务端在验证所述数字签名无误的情况下，完成所述服务请求数据对应的服务请求。

本申请第二方面的实施例提供了一种数据传输装置，应用于代理服务器，所述代理服务器部署在第一服务端，包括：

接收模块，用于接收客户端发送的服务请求数据；

获取模块，用于基于USBKey驱动配置信息，获取与所述代理服务器相连接的USBKey设备中的秘钥信息；

加密模块，用于利用所述秘钥信息对所述服务请求数据进行加密，得到数字签名；

发送模块，用于将所述数字签名和所述服务请求数据发送至第二服务端，以用于所述第二服务端在验证所述数字签名无误的情况下，完成所述服务请求数据对应的服务请求。

本申请第三方面的实施例提供了一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器运行所述计算机程序以实现上述第一方面所述的方法。

本申请第四方面的实施例提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行实现上述第一方面所述的方法。

本申请实施例中提供的技术方案，至少具有如下技术效果或优点：

本申请提出一种数据传输方法、设备及存储介质，应用于代理服务器，代理服务器部署在第一服务端，在本申请实施例中，接收客户端发送的服务请求数据；基于USBKey驱动配置信息，获取与代理服务器相连接的USBKey设备中的秘钥信息；利用秘钥信息对服务请求数据进行加密，得到数字签名；将数字签名和服务请求数据发送至第二服务端，以用于第二服务端在验证数字签名无误的情况下，完成服务请求数据对应的服务请求。本申请实施例通过部署在第一服务端的代理服务器确定与代理服务器相连接的USBKey设备中的秘钥信息，并对服务请求数据完成数字签名，避免了数字签名过程需要为在每个工作人员进行操作的设备上安装相应的数字签名的相关签名控件，以及节省需要多个USBKey设备的设备管理成本，并且USBKey设备与第一服务端连接，避免了客户端直接操作USBKey设备的风险。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变的明显，或通过本申请的实践了解到。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本申请的限制。而且在整个附图中，用相同的参考符号表示相同的部件。

在附图中：

图1示出了本申请一实施例所提供的一种数据传输方法的场景示意图；

图2示出了本申请一实施例所提供的一种数据传输方法流程图；

图3示出了本申请一实施例所提供的一种数据传输装置的结构示意图；

图4示出了本申请一实施例所提供的一种电子设备的结构示意图；

图5示出了本申请一实施例所提供的一种存储介质的示意图。

具体实施方式

下面将参照附图更详细地描述本申请的示例性实施方式。虽然附图中显示了本申请的示例性实施方式，然而应当理解，可以以各种形式实现本申请而不应被这里阐述的实施方式所限制。相反，提供这些实施方式是为了能够更透彻地理解本申请，并且能够将本申请的范围完整的传达给本领域的技术人员。

需要注意的是，除非另有说明，本申请使用的技术术语或者科学术语应当为本申请所属领域技术人员所理解的通常意义。

承接上述背景技术，相关技术中目前的数字签名过程需要在每个工作人员进行操作的设备上安装相应的数字签名的相关签名控件，操作麻烦，且如果存在多个工作人员，需要多个USBKey设备，如果不同工作人员相互借用USBkey设备，有设备管理成本。工作人员可以直接在客户端操作USBKey设备，存在安全风险。

进一步的，为了避免工作人员直接在客户端操作USBKey设备，存在的安全风险，可以采用软证书的方式进行数字签名。

但是虽然软证书颁发机构会对申请人进行身份验证，但是在互联网上，伪造一个看起来合法的数字证书并不困难。因此，如果没有其他安全措施，软证书也无法完全保证数据的安全性和身份的真实性，且软证书存储在计算机系统中，如果系统受到恶意攻击或者病毒感染，私钥可能会被盗用。此外，在生成和管理软证书的过程中，如果不注意安全措施，也可能会导致私钥泄露，总之，软证书的加密方式会导致新的安全问题。

为了解决上述技术问题，本申请提出一种数据传输方法、设备及存储介质，应用于代理服务器，代理服务器部署在第一服务端，在本申请实施例中，接收客户端发送的服务请求数据；基于USBKey驱动配置信息，获取与代理服务器相连接的USBKey设备中的秘钥信息；利用秘钥信息对服务请求数据进行加密，得到数字签名；将数字签名和服务请求数据发送至第二服务端，以用于第二服务端在验证数字签名无误的情况下，完成服务请求数据对应的服务请求。本申请实施例通过部署在第一服务端的代理服务器确定与代理服务器相连接的USBKey设备中的秘钥信息，并对服务请求数据完成数字签名，避免了数字签名过程需要为在每个工作人员进行操作的设备上安装相应的数字签名的相关签名控件，以及节省需要多个USBKey设备的设备管理成本，并且USBKey设备与第一服务端连接，避免了客户端直接操作USBKey设备的风险，且秘钥信息存储在USBKey设备中，降低了秘钥信息泄露的风险。

首先对本申请实施例提供的数据传输方法的应用场景进行描述。如图1所示，该场景包括第一服务端、第二服务端和客户端，其中第一服务端部署有代理服务器。

其中，代理服务器和客户端之间可以进行通信以及代理服务器和第二服务器之间可以通信，通信方式包括有线通信和无线通信等。其中，有线通信可以是通过物理媒介(如电缆、光纤)传输信息。例如，电话线路、局域网(LAN)、广域网(WAN)等。无线通信可以通过无线电波或红外线等无线信号传输信息。例如，无线电、移动通信(如手机、蜂窝网络)、Wi-Fi、蓝牙等。

第一服务端和第二服务端可以为服务器，如一台服务器、多台服务器、服务器集群、云计算平台等，可选地，计算设备还可以为其他类型的设备，本公开对计算设备的设备类型不加以限定。

其中，第一服务端可以是企业端的服务端，第二服务端可以是为企业提供服务的设备端，客户端可以是企业端的客户端。

客户端安装用于提交服务请求数据的企业客户端接口，进一步建立企业客户端接口与第一服务端的代理服务的安全通道。企业客户端还用于接收浏览器，或者其他第三方软件提交的服务请求数据，并通过上述安全通道将服务请求数据发送至代理服务器。

客户端可以实现为以电子设备，该电子设备可以是手机、平板电脑、笔记本电脑、台式电脑、电视、投影仪、数字相机、声音设备、游戏机、智能手表、智能穿戴设备电子阅读器、汽车娱乐系统和家用电器(如冰箱、洗衣机)等。电子设备可以安装有用户端，该用户端可以是实现某一功能的应用，比如可以是手机银行应用，购物应用等等。

第一服务端安装有代理服务器，并安装有数字签名所需的相关中间件和USBKey驱动程序，代理服务器配有代理服务参数，包括USBKey驱动配置，以及与第二服务器相关的通信配置，安全套接层(Secure socket layer，简称SSL)等配置。

在代理服务器启动后，监听企业客户端接口发送的服务请求数据，并通过安全通道接收企业客户端发送的服务请求数据，并基于USBKey驱动配置，获取与代理服务器相连接的USBKey设备中的秘钥信息；利用秘钥信息对服务请求数据进行加密，得到数字签名，基于与第二服务器相关的通信配置，SSL等配置，建立代理服务器与第二服务端的通信通道，并将数字签名和服务请求数据通过该通信通道发送至第二服务端。

第二服务端用于通过通信通道接收代理服务器发送的数字签名和服务请求数据，并对数字签名进行验证，并在验证无误的情况下，完成服务请求数据对应的服务。

下面结合附图来描述根据本申请实施例提出的一种数据传输方法、装置、设备及存储介质。

本申请的各实施例中均以一个服务请求数据的数据传输为例进行说明，对于其他服务请求数据体，都按照与该服务请求数据相同的方式来传输。且对于执行主体，本申请各实施例中均以代理服务器为例进行说明，代理服务器部署在第一服务端。

参见图2，该方法具体包括以下步骤：

S201、接收客户端发送的服务请求数据。

其中，客户端为企业端的客户端，服务请求数据为企业端请求某一服务的请求数据，比如，企业需要贷款服务，那么服务请求数据可以是贷款的机构，贷款的金额等等。

一些实施例中，为了提高客户端与代理服务器之间通信的安全性，接收客户端发送的服务请求数据，包括：

建立与客户端接口的安全通道；

通过安全通道接收客户端发送的服务请求数据。

服务请求数据为客户端从浏览器或者预设第三方程序接收的。

在一个可选的实施例中，建立与客户端接口的安全通道可以包括以下步骤：

协商加密算法和参数：通信的双方首先需要协商使用的加密算法和相关参数。这些算法和参数决定了数据在传输过程中的加密和解密方式。常见的加密算法有高级加密标准(Advanced Encryption Standard，AES)、RSA等，参数包括密钥长度、初始化向量等。

密钥交换：为了进行加密和解密，通信双方需要共享一个密钥。密钥交换是确保密钥安全传输的过程。常见的密钥交换协议包括Diffie-Hellman协议和公钥加密算法(如RSA)等。

身份验证：在建立安全通道之前，通信双方通常需要进行身份验证，以确保通信的双方都是合法的。身份验证可以使用数字证书、用户名密码等方式进行。

加密数据传输：通过协商好的加密算法和共享的密钥，通信双方对要传输的数据进行加密。发送方使用密钥对数据进行加密，接收方使用相同的密钥进行解密。

数据完整性验证：为了确保数据在传输过程中没有被篡改，通信双方可以使用消息认证码(MAC)或者哈希函数对数据进行验证。发送方在发送数据时生成一个MAC或哈希值，并将其发送给接收方。接收方同样计算MAC或哈希值，并与接收到的值进行比较，以确保数据的完整性。

通信结束：当数据传输完成后，通信双方可以关闭安全通道，并释放相关资源。在某些情况下，也可以周期性地更新密钥，以增强安全性。

进一步，代理服务器可以监听客户端接口发送的服务请求数据，在监听到有服务请求数据发出的情况下，通过上述安全通道接收服务请求数据。

S202、基于USBKey驱动配置信息，获取与代理服务器相连接的USBKey设备中的秘钥信息。

在本申请实施例中，USBKey设备存储有用于数字签名的秘钥信息，为了完成数字签名，需要从对应USBKey设备获取对应的秘钥信息。

其中，USBKey驱动配置信息包括有对应USBKey设备标识，该USBKey设备标识可以为USBKey设备唯一的标识符，用于区分不同的设备。

可以基于USBKey设备标识确定目标USBKey设备，并获取目标USBKey设备中的秘钥信息。

可以理解的是，由于目标USBKey设备与代理服务器相连接，并不是与客户端相连接，因此，只需要一个目标USBKey设备就可以完成多个工作人员进行数字签名的操作，从而避免了USBKey设备管理的问题，进一步，由于目标USBKey设备与代理服务器相连接，避免了工作人员通过客户端直接操作USBKey设备带来的安全风险。

其中，目标USBKey设备与目标USBKey接口的连接方式为以下任一种：无线连接、蓝牙连接或者物理连接。

S203、利用秘钥信息对服务请求数据进行加密，得到数字签名。

一些实施例中，数字签名包括以下步骤：

创建消息摘要：首先，对服务请求数据(通常是电子文档)应用一个散列函数(如SHA-256)，生成一个称为消息摘要或哈希值的固定长度字符串。消息摘要可以看作是原始数据的"指纹"，具有唯一性，并且对于任何微小的数据改变都会产生完全不同的摘要。

使用秘钥信息加密消息摘要：签名者使用自己的秘钥信息对消息摘要进行加密，生成一个数字签名。这个过程使用非对称加密算法(如RSA)来保证只有持有与该私钥对应的公钥才能解密和验证签名。

将签名附加到原始数据：将数字签名与原始数据一起发送或存储。通常，数字签名会被附加到原始数据的尾部。

S204、将数字签名和服务请求数据发送至第二服务端，以用于第二服务端在验证数字签名无误的情况下，完成服务请求数据对应的服务请求。

一些实施例中，代理服务器还存储有与第二服务端的通信通道配置信息，数字签名和服务请求数据发送至第二服务端，包括：

确定与第二服务器的通信通道配置信息；

基于通信通道配置信息建立与第二服务器的通信通道；

通过通信通道将数字签名和服务请求数据发送至第二服务端。

其中，通信通道配置信息包括：代理服务器与第二服务端的通道配置信息以及安全SSL配置信息等等。

通过代理服务器与第二服务端的通道配置信息建立通信通道，并建立SSL安全连接，进一步通过建立SSL安全连接的通信通道将数字签名和服务请求数据发送至第二服务端。

一些实施例中，验证数字签名包括以下步骤：

a.使用签名者的公钥解密数字签名，还原出原始的消息摘要。

b.对接收到的服务请求数据再次应用相同的散列函数，生成一个新的消息摘要。

c.比较解密得到的消息摘要与重新生成的消息摘要。如果两者相同，那么签名有效，数据未被篡改；否则，签名无效，数据可能被篡改。

本申请提出一种数据传输方法、设备及存储介质，应用于代理服务器，代理服务器部署在第一服务端，在本申请实施例中，接收客户端发送的服务请求数据；基于USBKey驱动配置信息，获取与代理服务器相连接的USBKey设备中的秘钥信息；利用秘钥信息对服务请求数据进行加密，得到数字签名；将数字签名和服务请求数据发送至第二服务端，以用于第二服务端在验证数字签名无误的情况下，完成服务请求数据对应的服务请求。本申请实施例通过部署在第一服务端的代理服务器确定与代理服务器相连接的USBKey设备中的秘钥信息，并对服务请求数据完成数字签名，避免了数字签名过程需要为在每个工作人员进行操作的设备上安装相应的数字签名的相关签名控件，以及节省需要多个USBKey设备的设备管理成本，并且USBKey设备与第一服务端连接，避免了客户端直接操作USBKey设备的风险。

一些实施例中，代理服务器安装有USBKey驱动程序，基于USBKey驱动配置信息，获取与代理服务器相连接的USBKey设备中的秘钥信息，包括：

利用USBKey驱动程序识别与USBKey驱动配置信息对应的目标USBKey设备；

确定与目标USBKey设备连接的目标USBKey接口；

通过目标USBKey接口获取目标USBKey设备的秘钥信息。

一些实施例中，可以在代理服务器预先配置有USBKey驱动程序，一旦有USBKey设备接入代理服务器，USBKey驱动程序会识别USBKey设备，并与其建立通信，每种USBKey设备都有特定的通信协议，驱动程序可以负责处理与该设备的通信协议。例如，USBKey设备可能需要传输加密数据或数字签名，驱动程序需要确保这些数据能够正确地传输和解析，USBKey设备通常具有安全性较高的特点，驱动程序需要确保设备和计算机之间的通信是安全可靠的。例如，在数据传输过程中对数据进行加密、解密，或者要求输入密码等安全措施，驱动程序需要能够正确地处理这些情况。不同厂商的USBKey设备可能有不同的硬件规格或软件协议，驱动程序需要支持不同型号和版本的设备，以确保其能够在操作系统中正常工作。

USBKey驱动程序完成上述过程之后，此时代理服务器已经与连接到代理服务器的至少一个USBKey设备建立了通信，并且可以识别至少一个USBKey设备，进一步的，可以识别与USBKey驱动配置信息对应的目标USBKey设备，即识别与USBKey驱动配置信息的设备标识对应的目标USBKey设备，并确定出与目标USBKey设备相连接的目标USBKey接口；通过目标USBKey接口获取目标USBKey设备的秘钥信息。

一些实施例中，USBKey驱动配置信息包括USBKey设备标识，利用USBKey驱动程序识别与USBKey驱动配置信息对应的目标USBKey设备，包括：

利用USBKey驱动程序识别与USBKey设备标识对应的目标USBKey设备。

一些实施例中，代理服务器安装有中间件，利用秘钥信息对服务请求数据进行加密，得到数字签名，包括：

利用中间件基于服务请求数据生成散列值；

利用秘钥信息对散列值进行加密，得到数字签名。

可以理解的是，为了完成数字签名，除了需要秘钥信息之外，还需要对应的加密算法以及证书管理系统以及一些用于提供数字签名的相关接口。

一些实施例中，由于数据的散列值可以提供数据的完整性验证和提高数字签名的效率和安全性，因此，在进行数字签名的过程中，可以基于服务请求数据生成散列值。

一些实施例中，中间件可以是加密算法库，包括有用于生成散列值的哈希算法，基于服务请求数据生成散列值一般包括以下步骤：

选择哈希算法：从加密算法库选择一种合适的哈希算法。常见的哈希算法有MD5、SHA-1、SHA-2等。

初始化哈希函数：根据选择的哈希算法，初始化哈希函数。通常情况下，哈希函数会使用特定长度的初始值作为初始状态。

处理输入数据：将要生成哈希值的数据分块处理。较长的数据可能需要被分成多个块进行处理。在每个块上执行哈希函数，得到一个中间结果。

合并中间结果：将所有分块处理得到的中间结果合并起来，得到最终的哈希值。合并中间结果的方式和哈希算法有关。一些哈希算法使用简单的位运算和异或操作进行合并，而另一些则使用更复杂的算法，例如SHA-1和SHA-2算法使用“迭代压缩”算法来合并中间结果。

输出哈希值：输出最终的哈希值。哈希值可以表示为二进制数、十六进制数或其它格式，用于唯一地标识输入数据。

本申请实施例还提供一种数据传输装置，应用于代理服务器，代理服务器部署在第一服务端，该装置用于执行上述任一实施例提供的数据传输方法。如图3所示，该装置包括：接收模块301、获取模块302、加密模块303和发送模块304。

接收模块301，用于接收客户端发送的服务请求数据；

获取模块302，用于基于USBKey驱动配置信息，获取与代理服务器相连接的USBKey设备中的秘钥信息；

加密模块303，用于利用秘钥信息对服务请求数据进行加密，得到数字签名；

发送模块304，用于将数字签名和服务请求数据发送至第二服务端，以用于第二服务端在验证数字签名无误的情况下，完成服务请求数据对应的服务请求。

本申请提出一种数据传输方法、设备及存储介质，应用于代理服务器，代理服务器部署在第一服务端，在本申请实施例中，接收客户端发送的服务请求数据；基于USBKey驱动配置信息，获取与代理服务器相连接的USBKey设备中的秘钥信息；利用秘钥信息对服务请求数据进行加密，得到数字签名；将数字签名和服务请求数据发送至第二服务端，以用于第二服务端在验证数字签名无误的情况下，完成服务请求数据对应的服务请求。本申请实施例通过部署在第一服务端的代理服务器确定与代理服务器相连接的USBKey设备中的秘钥信息，并对服务请求数据完成数字签名，避免了数字签名过程需要为在每个工作人员进行操作的设备上安装相应的数字签名的相关签名控件，以及节省需要多个USBKey设备的设备管理成本，并且USBKey设备与第一服务端连接，避免了客户端直接操作USBKey设备的风险。

一些实施例中，代理服务器安装有USBKey驱动程序，获取模块302，具体用于：

利用USBKey驱动程序识别与USBKey驱动配置信息对应的目标USBKey设备；

确定与目标USBKey设备连接的目标USBKey接口；

通过目标USBKey接口获取目标USBKey设备的秘钥信息。

一些实施例中，USBKey驱动配置信息包括USBKey设备标识，获取模块302，进一步具体用于：

利用USBKey驱动程序识别与USBKey设备标识对应的目标USBKey设备。

一些实施例中，目标USBKey设备与目标USBKey接口的连接方式为以下任一种：无线连接、蓝牙连接或者物理连接。

一些实施例中，代理服务器安装有中间件，加密模块303，具体用于：

利用中间件基于服务请求数据生成散列值；

利用秘钥信息对散列值进行加密，得到数字签名。

一些实施例中，接收模块301，具体用于：

建立与客户端接口的安全通道；

通过安全通道接收客户端发送的服务请求数据，服务请求数据为客户端从浏览器或者预设第三方程序接收的。

一些实施例中，发送模块304，具体用于：

确定与第二服务器的通信通道配置信息；

基于通信通道配置信息建立与第二服务器的通信通道；

通过通信通道将数字签名和服务请求数据发送至第二服务端。

本申请实施方式还提供一种电子设备，以执行上述数据传输方法。请参考图4其示出了本申请的一些实施方式所提供的一种电子设备的示意图。如图4所示，电子设备7包括：处理器700，存储器701，总线702和通信接口703，所述处理器700、通信接口703和存储器701通过总线702连接；所述存储器701中存储有可在所述处理器700上运行的计算机程序，所述处理器700运行所述计算机程序时执行本申请前述任一实施方式所提供的数据传输方法。

其中，存储器701可能包含高速随机存取存储器(RAM：Random Access Memory)，也可能还包括非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。通过至少一个通信接口703(可以是有线或者无线)实现该装置网元与至少一个其他网元之间的通信连接，可以使用互联网、广域网、本地网、城域网等。

总线702可以是ISA总线、PCI总线或EISA总线等。所述总线可以分为地址总线、数据总线、控制总线等。其中，存储器701用于存储程序，所述处理器700在接收到执行指令后，执行所述程序，前述本申请实施例任一实施方式揭示的所述数据传输方法可以应用于处理器700中，或者由处理器700实现。

处理器700可能是一种集成电路芯片，具有信号的处理能力。在实现过程中，上述方法的各步骤可以通过处理器700中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器700可以是通用处理器，包括中央处理器(Central Processing Unit，简称CPU)、网络处理器(Network Processor，简称NP)等；还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器701，处理器700读取存储器701中的信息，结合其硬件完成上述方法的步骤。

本申请实施例提供的电子设备与本申请实施例提供的数据传输方法出于相同的发明构思，具有与其采用、运行或实现的方法相同的有益效果。

本申请实施方式还提供一种与前述实施方式所提供的数据传输方法对应的计算机可读存储介质，请参考图5，其示出的计算机可读存储介质为光盘30，其上存储有计算机程序(即程序产品)，所述计算机程序在被处理器运行时，会执行前述任意实施方式所提供的数据传输方法。

需要说明的是，所述计算机可读存储介质的例子还可以包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他光学、磁性存储介质，在此不再一一赘述。

本申请的上述实施例提供的计算机可读存储介质与本申请实施例提供的数据传输方法出于相同的发明构思，具有与其存储的应用程序所采用、运行或实现的方法相同的有益效果。

需要说明的是：

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本申请的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的结构和技术，以便不模糊对本说明书的理解。

类似地，应当理解，为了精简本申请并帮助理解各个发明方面中的一个或多个，在上面对本申请的示例性实施例的描述中，本申请的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下示意图：即所要求保护的本申请要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本申请的单独实施例。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本申请的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。

以上所述，仅为本申请较佳的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种数据传输方法，其特征在于，应用于代理服务器，所述代理服务器部署在第一服务端，包括：

接收客户端发送的服务请求数据；

基于USBKey驱动配置信息，获取与所述代理服务器相连接的USBKey设备中的秘钥信息；

利用所述秘钥信息对所述服务请求数据进行加密，得到数字签名；

将所述数字签名和所述服务请求数据发送至第二服务端，以用于所述第二服务端在验证所述数字签名无误的情况下，完成所述服务请求数据对应的服务请求。

2.根据权利要求1所述的方法，其特征在于，所述代理服务器安装有USBKey驱动程序，所述基于USBKey驱动配置信息，获取与所述代理服务器相连接的USBKey设备中的秘钥信息，包括：

利用所述USBKey驱动程序识别与所述USBKey驱动配置信息对应的目标USBKey设备；

确定与所述目标USBKey设备连接的目标USBKey接口；

通过所述目标USBKey接口获取所述目标USBKey设备的秘钥信息。

3.根据权利要求2所述的方法，其特征在于，所述USBKey驱动配置信息包括USBKey设备标识，所述利用所述USBKey驱动程序识别与所述USBKey驱动配置信息对应的目标USBKey设备，包括：

利用所述USBKey驱动程序识别与所述USBKey设备标识对应的目标USBKey设备。

4.根据权利要求2所述的方法，其特征在于，所述目标USBKey设备与所述目标USBKey接口的连接方式为以下任一种：无线连接、蓝牙连接或者物理连接。

5.根据权利要求1所述的方法，其特征在于，所述代理服务器安装有中间件，所述利用所述秘钥信息对所述服务请求数据进行加密，得到数字签名，包括：

利用所述中间件基于所述服务请求数据生成散列值；

利用所述秘钥信息对所述散列值进行加密，得到数字签名。

6.根据权利要求1所述的方法，其特征在于，所述接收客户端发送的服务请求数据，包括：

建立与客户端接口的安全通道；

通过所述安全通道接收客户端发送的服务请求数据，所述服务请求数据为所述客户端从浏览器或者预设第三方程序接收的。

7.根据权利要求1所述的方法，其特征在于，所述将所述数字签名和所述服务请求数据发送至第二服务端，包括：

确定与第二服务器的通信通道配置信息；

基于所述通信通道配置信息建立与所述第二服务器的通信通道；

通过所述通信通道将所述数字签名和所述服务请求数据发送至第二服务端。

8.一种数据传输装置，其特征在于，应用于代理服务器，所述代理服务器部署在第一服务端，包括：

接收模块，用于接收客户端发送的服务请求数据；

获取模块，用于基于USBKey驱动配置信息，获取与所述代理服务器相连接的USBKey设备中的秘钥信息；

加密模块，用于利用所述秘钥信息对所述服务请求数据进行加密，得到数字签名；

发送模块，用于将所述数字签名和所述服务请求数据发送至第二服务端，以用于所述第二服务端在验证所述数字签名无误的情况下，完成所述服务请求数据对应的服务请求。

9.一种电子设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器运行所述计算机程序以实现如权利要求1-7任一项所述的方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行实现如权利要求1-7中任一项所述的方法。