CN104184740A - 可信传输方法、可信第三方和可信传输系统 - Google Patents

Abstract

本发明公开了一种可信传输方法、可信第三方和可信传输系统，可信传输方法包括：判断接收到的用户端发送的上传文件是否完整；若判断出接收到的用户端发送的上传文件完整时，对上传文件进行加密得到存储文件，并将存储文件发送至存储服务器集群。或该可信传输方法包括：判断接收到的存储服务器集群发送的存储文件是否完整；若判断出接收到的存储服务器集群发送的存储文件完整时，对存储文件进行解密得到上传文件，并将上传文件发送至用户端。本发明中可信第三方为用户端对存储服务器集群的“控告”提供仲裁结果，有效防止用户端与存储服务器集群之间的诬告，同时可信第三方可实现加密或解密处理，因此减小了用户端的数据处理压力。

Description

可信传输方法、可信第三方和可信传输系统

技术领域

本发明涉及信息安全技术领域，特别涉及一种可信传输方法、可信第三方和可信传输系统。

背景技术

利用云计算的强大的计算能力以及存储能力，用户端可以将数据计算任务交给云来完成，同样也可以将数据存储于云提供商的云存储服务器上，从而尽可能减轻用户端的计算与存储负载。

当用户端将数据存储于云提供商的存储服务器上时，用户端失去了对数据的直接控制权，转而将控制权交予云存储服务器集群。在无法保证存储服务器集群是诚实可信、无恶意时，用户端的数据存在着泄露以及被破坏的风险。

如果用户端的上传文件以明文形式存储，一方面，它容易使得用户的上传文件的机密性被破坏；另一方面，管理员可以对明文数据进行操作，它可以聪明地只修改用户端数据的一小部分，如将10000改为10001，将10000改为100等，或者在返回用户端数据时只返回了部分数据，这显然破坏了用户端的上传文件的完整性。当用户端再次从服务器下载上传文件时，由于数据量大或在者服务器所进行的不明显的修改，使得用户端并不能立刻发现自己的上传文件破坏。

目前，为了保证上传文件的机密性，一般要求用户端在数据上传至存储服务器端时对上传文件进行加密，然后存储服务器对加密的数据进行存储，当用户端下载数据时，再进行解密操作恢复出明文数据。这种方法虽然实现了机密性的要求，但也带来了一定的局限性。其一，数据加解密操作增加了用户端端的计算负载，对用户端的计算能力要求提高，假设用户端是一个瘦终端，没有进行加解密运算的能力时，这种方法就不适用了；其二，虽然服务器不知道明文数据，但他依然可以修改用户端的密文数据，聪明的服务器可以修改很少量比特的信息，这种情况下的破坏行为会比明文情况下的破坏行为更难发现，而且密文数据1比特的修改就可能导致用户端数据无法正确解密，这种后果对于用户端来说是非常可怕的。

在这两种情况下，都存在着用户端数据被破坏的风险。由于缺少相应的仲裁机制，即使用户端发现自己的数据被修改，用户端也无法去指证自己的数据遭到修改，服务器可以去抵赖。

在上述的数据存储的方法中，是在假定用户端是无恶意的情况下进行的。然而，实际环境中，我们也可以假设用户端是一个恶意用户端，而服务器是诚实可信的，这种情况下就存在着用户端诬告服务器的情形。明文存储的情况下，用户端可以修改自己的上环文件，然后诬告是服务器修改了自己的数据。密文存储情况下，服务器并未修改用户端数据；而当用户端下载数据时，服务器返回原始保存的数据，用户端经过解密可以恢复原始数据。然而，用户端自己可以修改数据，并加密得到相应密文。然后，用户端可以声称服务器端修改了自己的数据。

如果两方都不诚实的情况下，那么两者之间的相互诬陷的情况就更加复杂。在上述的情况中，都急需一套仲裁机制来对用户端提出的“控告”进行仲裁。

发明内容

本发明提供一种可信传输方法、可信第三方和可信传输系统，可信第三方可以为用户端对存储服务器集群的“控告”提供仲裁结果，同时，该可信第三方可以减小用户端的数据处理压力。

为实现上述目的，本发明提供一种可信传输方法，包括：

判断接收到的用户端发送的上传文件是否完整；

若判断出接收到的用户端发送的上传文件完整时，对所述上传文件进行加密得到存储文件，并将所述存储文件发送至存储服务器集群。

可选地，所述判断接收到的用户端发送的上传文件是否完整的步骤之前还包括：

接收并存储所述用户端发送的上传文件和所述上传文件对应的第一哈希值；

所述判断接收到的用户端发送的上传文件是否完整的步骤包括：

对存储的所述上传文件进行哈希计算得到第二哈希值；

比较所述第一哈希值与所述第二哈希值是否一致，若比较出所述第一哈希值与所述第二哈希值一致时，则判断出所述上传文件完整。

可选地，所述存储文件包括若干密文子文件，所述对所述上传文件进行加密得到存储文件，并将所述存储文件发送至存储服务器集群的步骤包括：

根据预设的数据分割算法将所述上传文件分割为具有特定长度的上传子文件；

对每个所述上传子文件进行加密处理得到对应的密文子文件；

对所述密文子文件进行哈希计算得到第三哈希值；

将全部所述密文子文件和所述密文子文件对应的第三哈希值发送至所述存储服务器集群。

为实现上述目的，本发明还提供一种可信传输方法，包括：

判断接收到的存储服务器集群发送的存储文件是否完整；

若判断出接收到的所述存储服务器集群发送的所述存储文件完整时，对所述存储文件进行解密得到上传文件，并将所述上传文件发送至用户端。

可选地，所述存储文件包括：若干个密文子文件，所述判断接收到存储服务器集群发送的存储文件是否完整的步骤之前包括：

接收并存储所述密文子文件和所述密文件对应的第三哈希值；

所述判断接收到存储服务器集群发送的存储文件是否完整的步骤包括：

逐个的判断存储的所述密文子文件是否完整；

若判断出全部所述密文子文件都完整时，则所述存储文件完整。

可选地，所述判断存储的所述密文子文件是否完整的步骤包括：

对存储的所述密文子文件进行哈希计算得到第四哈希值；

比较所述第三哈希值与所述第四哈希值是否一致，若比较出所述第三哈希值与所述第四哈希值一致时，则判断出所述密文子文件完整。

可选地，所述对所述存储文件进行解密得到上传文件，并将所述上传文件发送至用户端的步骤包括：

对所述密文子文件进行解密得到上传子文件；

根据预设的数据重组算法将全部所述上传子文件进行重组得到所述上传文件；

将所述上传文件传送至所述客户端。

为实现上述目的，本发明提供一种可信第三方，包括：

第一判断模块，用于判断所述可信第三方接收到的用户端发送的上传文件是否完整；

加密模块，用于若判断出接收到的用户端发送的上传文件完整时，对所述上传文件进行加密得到存储文件，并将所述存储文件发送至存储服务器集群；

可选地，所述可信第三方还包括：

第一存储模块，用于接收并存储所述用户端发送的上传文件和所述上传文件对应的第一哈希值；

所述第一判断模块包括：

第一计算子模块，用于对存储的所述上传文件进行哈希计算得到第二哈希值；

第一比较子模块，用于比较所述第一哈希值与所述第二哈希值是否一致；

第一判断子模块，用于若比较出所述第一哈希值和所述第二哈希值一致时，则判断出接收到的所述上传文件完整。

可选地，所述存储文件包括若干个密文子文件，所述加密模块包括：

分割子模块，用于根据预设的数据分割算法将所述上传文件分割为具有特定长度的上传子文件；

加密子模块，用于对每个所述上传子文件进行加密处理得到相应的密文子文件，并计算每个所述密文子文件的第三哈希值；

第一发送子模块，用于将全部所述密文子文件和每个所述密文子文件对应的第三哈希值发送至所述存储服务器集群。

为实现上述目的，本发明提供一种可信第三方，包括：

第二判断模块，用于判断所述可信第三方接收到的存储服务器集群发送的存储文件是否完整；

解密模块，用于若判断出接收到的所述存储服务器集群发送的所述存储文件完整时，对所述存储文件进行解密得到上传文件，并将所述上传文件发送至所述用户端。

可选地，所述存储文件包括：若干个密文子文件，所述可信第三方还包括：

第二存储模块，用于接收并存储所述密文子文件和所述密文件对应的第三哈希值；

所述第二判断模块包括：

第二计算子模块，用于对存储的所述密文子文件进行哈希计算得到第四哈希值；

第二比较子模块，用于比较所述第三哈希值与所述第四哈希值是否一致；

第二判断子模块，用于若比较出所述第三哈希值与所述第四哈希值一致时，则判断出接收到的所述密文子文件完整。

可选地，所述解密模块包括：

解密子模块：用于对所述密文子文件进行解密得到上传子文件；

重组子模块：用于根据预设的数据重组算法将全部所述上传子文件进行重组得到所述上传文件。

第二发送子模块：用于将所述上传文件发送至所述用户端。

为实现上述目的，本发明提供一种可信传输系统，包括：用户端、服务器集群和可信第三方，所述可信第三方采用上述的可信第三方。

本发明具有以下有益效果：

本发明提供了一种可信传输方法、可信第三方和可信传输系统，其中，可信第三方在判断出用户端发送的上传文件是完整时，才会对上传文件进行加密处理，并将加密处理后得到的存储文件发送至服务器进行存储，使得用户端上传文件的完整保存，从而避免了用户端恶意修改上传文件以诬陷存储服务器集群的问题；同时，可信第三方在判断出接收到的存储服务器集群发送的存储文件完整时，对上传文件进行解密得到上传文件，并将上传文件发送至存储服务器集群进行存储，从而避免了存储服务器集群恶意修改上传文件以诬陷用户端的问题。该可信第三方可为用户端对存储服务器集群的“控告”提供仲裁结果，有效的防止用户端与存储服务器集群之间的诬告，同时由于可信第三方可实现加密或解密处理，因此减小了用户端的数据处理压力。

附图说明

图1为本发明实施例提供的可信传输方法的流程图；

图2为本发明实施例二提供的可信传输方法的流程图；

图3为本发明实施例三提供的可信传输方法的流程图；

图4为本发明实施例四提供的可信传输方法的流程图；

图5为本发明实施例五提供的可信第三方的示意图；

图6为本发明实施例六提供的可信第三方的结构示意图；

图7为本发明实施例七提供的可信传输系统的结构示意图。

具体实施方式

为使本领域的技术人员更好地理解本发明的技术方案，下面结合附图对本发明提供的云端数据的传输方法进行详细描述。

实施例一

图1为本发明实施例提供的可信传输方法的流程图，如图1所示，该可信传输方法包括：

步骤101：判断接收到的用户端发送的上传文件是否完整。

本实施例中给出的是用户端将上传文件存储至服务器的过程，本实施例中的各步骤可以由可信第三方执行。

在步骤101中，用户端通过浏览器或客户端向可信第三方发送需要上传的上传文件，并由可信第三方对上传文件的完整性进行判断。若可信第三方判断出接收到的用户端发送的上传文件完整时，则执行步骤102，若可信第三方判断出接收到的用户端发送的上传文件不完整时，则执行步骤103。

步骤102：对上传文件进行加密得到存储文件，并将存储文件发送至存储服务器集群。

当可信第三方判断出用户端向可信第三方发送的上传文件完整时，可信第三方对上传文件进行加密得到存储文件，并将存储文件发送到存储服务器集群中的存储控制中心，存储控制中心对存储服务器集群中的各服务器进行分配，以使服务器完成对存储文件的存储。

步骤103：向用户端请求重新发送上传文件。

当可信第三方判断出用户端向可信第三方发送的上传文件不完整时，可信第三方则向用户端请求重新发送上传文件，并重新执行步骤101。

本发明实施例一提供了一种可信传输方法，可信第三方通过判断其自身接收到的用户端发送的上传文件是否完整，若判断出接收到的用户端发送的上传文件完整时，对上传文件进行加密得到存储文件，并将存储文件发送至存储服务器集群进行存储，本实施例中可信第三方在判断出用户端发送的上传文件是完整时，才会对上传文件进行加密处理，并将加密处理后得到的存储文件发送至服务器进行存储，实现了对上传文件的完整保存，从而避免了用户端恶意修改上传文件以诬陷存储服务器集群的问题，同时上传文件的加密处理过程由可信第三方执行，从而减小了用户端的数据处理压力。

实施例二

图2为本发明实施例二提供的可信传输方法的流程图，如图2所示，该可信传输方法包括：

步骤201：用户端向可信第三方发送上传请求。

用户端通过浏览器或客户端向可信第三方发送上传请求，其中上传请求中包含有用户端自身的相关信息(如：用户端的IP地址)。

步骤202：可信第三方根据上传请求对用户端的进行认证，若用户端没有通过认证，则用户无法进行后续的上传工作；若用户端通过认证，则可信第三方生成上传请求成功信息。

在步骤202中，根据上传请求对用户端的进行认证的方法有多种，本实施例以通过验证IP地址的方式进行示例性描述，具体地，上传请求中包含有用户的IP地址，而可信第三方中预先存储有可享受上传服务的用户端的IP地址数据集合，当可信第三方从IP地址数据集合中查询到上传请求中包含的IP地址时，则说明用户端通过认证；反之，则说明用户端没有通过认证。

当认证模块认定用户端通过认证后，认证模块生成相应的上传请求成功信息。

步骤203：可信第三方将上传请求成功信息发送至用户端。

可信第三方将上传请求成功信息发送至用户端，用户端在接收到上传请求成功信息时，表明用户端可以进行后续的上传工作。

步骤204：用户端对上传文件进行哈希计算，生成第一哈希值。

用户端在上传上传文件File1之前，首先对上传文件File1进行哈希计算Hash(File1)得到该上传文件File1的完整性摘要，即第一哈希值H1。

步骤205：用户端将上传文件和第一哈希值发送至可信第三方。

用户端将上传文件File1以及第一哈希值H1发送至可信第三方。

步骤206：可信第三方接收并存储上传文件和第一哈希值。

可信第三方接收到上传文件File2以及第一哈希值H1。此处需要说明的是，用户端在将上传文件发送至可信第三方的过程中，可能存在用户端将错误的文件或修改后的文件作为上传文件，从而导致实际上传的上传文件与预期上传的上传文件File1不同，从而导致可信第三方接收到的上传文件File2可能与用户端实际上传的上传文件File1不同。在本实施例中，将客户端中的预期上传的上传文件记为“File1”，将可信第三方接收到的上传文件记为“File2”。可信接收端在接收到上传文件File2和第一哈希值H1后，并对上传文件File2和第一哈希值H1进行存储。

步骤207：可信第三方对存储的上传文件进行哈希计算得到第二哈希值,比较第一哈希值与第二哈希值是否一致,若比较出第一哈希值和第二哈希值不一致时，则判断出上传文件不完整，可信第三方清除存储的上传文件，并请求客户端重新发送上传文件和上传文件对应的第一哈希值；若比较出第一哈希值和第二哈希值一致时，则判断出上传文件完整。

在步骤207中，首先，可信第三方对上传文件File2进行哈希计算Hash(File2)得到第二哈希值H2；然后，可信第三方接比较第一哈希值H1和第二哈希值H2是否一致。若第一哈希值H1与第二哈希值H2是不一致，则说明可信第三方接收到的上传文件File2与客户端预期上传的上传文件File1是不同的，即上传文件File1的完整性被破坏，此时可信第三方删除之前存储的上传文件File2和第一哈希值H1，并要求用户端重新发送数据，并重新的执行上述步骤204；若第一哈希值H1与第二哈希值H2是一致的，则说明可信第三方接收到的上传文件File2与用户端预期上传的上传文件File1是相同的，即上传文件File1的完整性没有被破坏，则判断出上传文件File1完整，并继续执行步骤208。

步骤208：可信第三方根据预设的分割算法将上传文件分割为具有特定长度的上传子文件。

需要说明的是，在执行步骤208时，可信第三方存储的上传文件File2与用户端预期上传的上传文件File1是相同的。可信第三方根据预设的数据分割算法将上传文件File2分割为具有特定长度的N个上传子文件，记为file_1、file_2、file_3……file_N，并对最后一个长度不等的上传子文件file_N的长度进行填充，以使上传子文件file_N与其余的上传子文件的长度相同。其中，需要说明的是，上述的“特定长度”是指上传子文件的文件大小，单位为bit，例如：假定特定长度为512bit，即通过步骤208可将上传文件分割为若干个512bit的上传子文件。

步骤209：可信第三方对每个上传子文件进行加密得到对应的密文子文件，并对每个密文子文件进行哈希计算得到每个密文子文件对应的第三哈希值。

在步骤209中，首先，可信第三方通过随机数种子S生成与上传子文件的特定长度相等的随机数R,并存储随机数种子S。然后，可信第三方利用随机数R分别与上传子文件file_1、上传子文件file_2、上传子文件file_3……上传子文件file_N进行异或运算，得到对应的N个密文子文件，记为Cipher_1、Cipher_2、Cipher_3……Cipher_N，其中Cipher_i＝file_i⊕R，i的取值为1、2、3……N。可信第三方对N个密文子文件分别进行哈希计算Hash(Cipher_i)得到每个密文子文件对应的完整性摘要，即第三哈希值hash_1、hash_2、hash_3……hash_N，其中hash_i＝Hash(Cipher_i)，i的取值为1、2、3……N。

需要说明的是，本实施例中的步骤208和步骤209即为上述实施例一中的加密处理的一种可选实施方案。本实施例中通过执行步骤209后得到的全部密文子文件的集合即为上述实施例一中的存储文件。

步骤210：可信第三方将全部的密文子文件和每个密文子文件对应的第三哈希值采用分段分布的方式发送到存储控制中心。

在步骤210中，可信第三方将全部的密文子文件(Cipher_1、Cipher_2、Cipher_3……Cipher_N)以及第三哈希值(hash_1、hash_2、hash_3……hash_N)发送至存储服务器集群中存储控制中心。

步骤211：存储控制中心根据预设的调度算法生成调度结果，并将调度结果进行存储。

在步骤211中，存储服务器集群中存储控制中心用于接收全部的密文子文件以及第三哈希值，并通过预设的调度算法生成相应调度结果。

为使本领域的技术人员更好的理解本实施例中存储控制中心的作用，下面通过举例来描述本实施例中存储控制中心的工作过程。其中，假定存储控制中心接收到的密文子文件的数量为4个(Cipher_1、Cipher_2、Cipher_3和Cipher_4)，对应的第三哈希值数量为4个(hash_1、hash_2、hash_3和hash_4)。此外，为方便描述，将密文子文件Cipher_1与其对应的第三哈希值hash_1共同记为Data_1,密文子文件Cipher_2与其对应的第三哈希值hash_2共同记为Data_2，密文子文件Cipher_3与其对应的第三哈希值hash_3共同记为Data_3，密文子文件Cipher_4与其对应的第三哈希值hash_4共同记为Data_4。

存储控制中心根据预设的调度算法对Data_1、Data_2、Data_3、和Data_4生成相应的调度结果。该调度结果存储于存储控制中心。调度结果用于记录Data_1、Data_2、Data_3和Data_4的分段情况以及分段处理后的存储每段数据的服务器的编号。

作为一种可选的调度结果，具体如下：

Data_1和Data_2作为一个数据段Section_1，Section_1存储于1号服务器中；

Data_2和Data_3作为又一个数据段Section_2，Section_2存储于2号服务器中；

Data_3和Data_4作为又一个数据段Section_3，Section_3存储于3号服务器中；

Data_4和Data_1作为又一个数据段Section_4，Section_4存储于4号服务器中。

需要说明的是，上述调度结果仅仅是起到示例性的作用，本领域技术人员应该知晓的是，本实施例中还可以生成其他不同的调度结果。

步骤212：存储控制中心根据调度结果将分段后的全部密文子文件和每个密文子文件对应的第三哈希值发送至不同的服务器。

存储控制中心根据调度结果将数据段Section_1、数据段Section_2、数据段Section_3和数据段Section_4分别发送至对应的服务器中。

步骤213：被调度的服务器接收数据并对数据进行存储。

在步骤213中，被调度的服务器将接收并存储控制中心发送的数控段。例如，在存储控制中心在发送数据段Section_1时，相应的1号服务器被调度，此时1号服务器接收并存储Data_1(密文子文件Cipher_1和第三哈希值hash_1)和Data_2(密文子文件Cipher_2和第三哈希值hash_2)。

采用这种分段分布式的存储方式对全部的密文子文件进行存储，可以防止一个服务器或几个服务器出现问题后数据无法恢复的问题。

当全部的数据段都存储至存储服务器集群中的相应服务器后，则表明用户端上传上传文件的过程结束。该上传文件以密文子文件的形成存储于存储服务器集群中的各服务器中。

本发明实施例二提供了一种可信传输方法，其中可信第三方通过判断其自身接收到的用户端发送的上传文件是否完整，若判断出接收到的用户端发送的上传文件完整时，对上传文件进行加密得到存储文件，并将存储文件发送至存储服务器集群进行存储。本实施例中可信第三方在判断出用户端发送的上传文件是完整时，才会对上传文件进行加密处理，并将加密处理后得到的存储文件发送至服务器进行存储，使得用户端上传文件的完整保存，从而避免了用户端恶意修改上传文件以诬陷存储服务器集群的问题；同时上传文件的加密处理过程由可信第三方执行，从而减小了用户端的数据处理压力，而且本实施例中对上传子文件的加密处理是采用简单的运算实现，从而在实现数据机密性的同时减少了可信第三方的计算量、提升了可信第三方的计算速度。此外，存储服务器集群采用分段分布的方式对存储文件进行存储，可以有效防止服务器出现问题后数据无法恢复的问题。

实施例三

图3为本发明实施例三提供的可信传输方法的流程图，如图3所示，该可信传输方法包括：

步骤301：判断接收到的存储服务器集群发送的存储文件是否完整。

本实施例中给出的是用户端从存储服务器集群下载上传文件的过程，本实施例中的各步骤可以由可信第三方执行。

在步骤301之前，存储服务器集群中的存储控制中心根据用户端所需要下载的上传文件，找出与上传文件对应的存储于存储服务器集群中各服务器的存储文件。

存储服务器集群中的存储控制中心将存储文件发送至可信第三方，并由可信第三方对存储文件的完整性进行判断，若可信第三方判断出接收到的存储服务器集群发送的存储文件完整时，则执行步骤302，若判断出接收到的存储服务器集群发送的存储文件不完整时，则执行步骤303。

步骤302：对存储文件进行解密得到上传文件，并将上传文件发送至用户端。

当可信第三方判断出接收到存储服务器集群发送的存储文件是完整时，可信第三方对存储文件进行解密得到上传文件，并将上传文件发送至服务器中的浏览器或客户端。

步骤303：向存储服务器集群请求重新发送存储文件。

当可信第三方判断出存储服务器集群向可信第三方发送的存储文件是不完整时，可信第三方则向存储服务器集群请求重新发送存储文件，并重新执行步骤301。

本发明实施例三提供了一种可信传输方法，可信第三方通过判断其自身接收到的存储服务器集群发送的存储文件是否完整，若判断出接收到的存储服务器集群发送的存储文件完整时，对上传文件进行解密得到上传文件，并将上传文件发送至存储服务器集群进行存储，本实施例中可信第三方在判断出存储服务器集群发送的存储文件是完整时，才会对存储文件进行解密处理，并将解密处理后得到的上传文件发送至用户端，使得用户端接收到完整的上传文件，从而避免了存储服务器集群恶意修改上传文件以诬陷用户端的问题，同时存储文件的解密处理过程由可信第三方执行，从而减小了用户端的数据处理压力。

实施例四

图4为本发明实施例四提供的可信传输方法的流程图，如图4所示，该可信传输方法包括：

步骤401：用户端向可信第三方发送下载请求。

用户端通过浏览器或客户端向可信第三方发送下传请求，其中下载请求包含有用户端自身的相关信息(如：用户端的IP地址)和所需要下载的上传文件的相关信息(如：上传文件的文件名称)。

步骤402：可信第三方根据下载请求对用户端的进行认证，若用户端没有通过认证，则用户无法进行后续的下载工作；若用户端通过认证，则可信第三方判断用户端所需要下载的上传文件是否存在于存储服务器集群中，若判断出用户端所需要下载的上传文件不存在于存储服务器集群中时，则可信第三方向用户端发送用户未上传此上传文件的提示信息，若判断出用户端所需要下载的上传文件存在于存储服务器集群中时，可信第三方生成下载请求成功信息。

在步骤402中，可信第三方先对用户端进行认证，并在用户端通过认证后，再判断用户端所需要下载的上传文件是否存在于存储服务器集群。其中对可信第三方对用户端的认证过程可参见上传实施例二中对步骤202的描述，此处不再赘述。

作为一种可选方案，可信第三方判断用户端所需要下载的上传文件是否存在于存储服务器集群的大致过程如下。在可信第三方内预先存储有记录用户端上传的全部上传文件的文件名称列表，同时用户端发送的下载请求内包含有所需要下载的上传文件的文件名称，当可信第三方在文件名称列表中查询到下载请求内包含的客户端所需要下载的上传文件的文件名称时，则判断出该上传文件存在于存储服务器集群中；反之，则判断该上传文件不存在于存储服务器集群中。

需要说明的是，步骤402中的用户端的认证过程以及用户端所需要下载的上传文件是否存在于存储服务器集群的判断过程还可以采用其他方式，此处不再一一举例。

步骤403：可信第三方将下载请求转发给存储服务器集群中的存储控制中心。

步骤404：存储控制中心接收下载请求，并根据下载请求从预先存储的调度结果中查询出所需要下载的上传文件对应的全部密文子文件的存储位置，并生成调度请求。

需要说明的是，用户端在将上传文件存储于存储服务器集群的过程可参见上述实施例二中的描述，上传文件的处理过程大致如下：首先，上传文件被分割为若干个上传子文件；然后，每个上传子文件均经过加密处理后变为密文子文件；最后，全部的密文子文件采用分段分布的方式存储于存储服务器集群内的各服务器中，且调度结果存储于存储服务器集群内的存储控制中心。

需要说明是，本实施例中全部的密文件子文件所构成的集合即为上述实施例三中的存储文件。

本实施例中，假定上传文件File1经过分割处理后形成具有特定长度的4个上传子文件，记为file_1、file_2、file_3和file_4，4个上传子文件分别经过加密处理后形成4个密文子文件。其中，加密处理的过程如下：首先可信第三方中随机数种子S生成与上传子文件的特定长度相等的随机数R,并存储随机数种子S；然后，可信第三方利用随机数R分别与上传子文件file_1、上传子文件file_2、上传子文件file_3和上传子文件file_4进行异或运算，得到对应的4个密文子文件，记为Cipher_1、Cipher_2、Cipher_3和Cipher_4，4个密文子文件对应的第三哈希值分别为hash_1、hash_2、hash_3和hash_4，其中，Cipher_i＝(file_i⊕R)，hash_i＝Hash(Cipher_i)，i的取值为1、2、3或4。同时，4个密文子文件及其第三哈希值的的调度结果如下：

Cipher_1、hash_1、Cipher_2和hash_2存储于1号服务器中；

Cipher_2、hash_2、Cipher_3和hash_3存储于2号服务器中；

Cipher_3、hash_3、Cipher_4和hash_4存储于3号服务器中；

Cipher_4、hash_4、Cipher_1和hash_1存储于4号服务器中。

在步骤404中，存储控制中心根据下载请求从调度结果中查询到用户端所需要下载的上传文件对应有4个密文子文件(Cipher_1、Cipher_2、Cipher_3和Cipher_4)，且密文子文件Cipher_1存储于1号服务器和4号服务器，密文子文件Cipher_2存储于1号服务器和2号服务器，密文子文件Cipher_3存储于2号服务器和3号服务器，密文子文件Cipher_4存储于3号服务器和4号服务器。存储控制中心在查询到4个密文子文件的存储位置后，生成调度请求。

步骤405：存储控制中心将调度请求发送给需要被调度的服务器。

步骤406：被调度的服务器准备密文子文件和密文子文件对应的第三哈希值。

步骤407：被调度的服务器将准备好的密文子文件和密文子文件对应的第三哈希值发送给存储控制中心。

其中，调度请求包括需要被调度的服务器的编号和该编号的服务器所需要传送给存储控制中的密文子文件的相关信息。

下面以存储控制中心从1号服务器下载密文子文件Cipher_1和第三哈希值hash_1的情况为例，来对步骤405、步骤406和步骤407进行描述。

在步骤405中，存储控制中心向1号服务器发送调度请求；在步骤406中，1号服务器节接收到该调度请求，并根据调度请求可以得知存储控制中心需要下载密文子文件Cipher_1和密文子文件Cipher_1对应的第三哈希值hash_1；在步骤407中，1号服务器将事先准备好的密文子文件Cipher_1和第三哈希值hash_1发送给存储控制中心。

当然，本实施例中存储控制中心也可以通过向4号服务器发送调度请求，以实现下载密文子文件Cipher_1和第三哈希值hash_1。

步骤408：存储控制中心接收密文子文件和第三哈希值。

在步骤408中，存储控制中心接收密文子文件Cipher_1和第三哈希值hash_1。

需要说明的是，重复执行上述步骤405、步骤406、步骤407和步骤408，存储控制中心最终可以接收到4个密文子文件(Cipher_1、Cipher_2、Cipher_3和Cipher_4)和4个第三哈希值(hash_1、hash_2、hash_3和hash_4)。

步骤409：存储控制中心向可信第三方发送密文子文件和该密文子文件对应的第三哈希值。

需要说明的是，本实施例中，步骤408和步骤409可以同时进行。例如，存储控制中心在接收到密文子文件Cipher_1和第三哈希值hash_1后，直接将密文子文件Cipher_1和第三哈希值hash_1发送给可信第三方，同时存储控制中心开始接收2号服务器发送来的密文子文件Cipher_2和第三哈希值hash_2。

步骤410：可信第三方接收并存储密文子文件和第三哈希值，并逐个的判断接收的密文子文件的是否完整，若判断出当前的密文子文件不完整时，则可信第三方删除当前的密文子文件和第三哈希值，并请求存储控制中心重新发送相应的密文子文件和第三哈希值，可信第三方判断重新接收的密文子文件是否完整；若判断出当前的密文子文件完整时，则可信第三方判断下一个密文子文件的是否完整，直至判断出存储的全部的密文子文件。

下面以当前密文子文件为密文子文件Cipher_1为例，对步骤410进行详细的说明。其中，假定此时可信第三方存储的密文子文件Cipher_1来自1号服务器。

首先，可信第三方对存储的密文子文件Cipher_1进行哈希计算，得到第四哈希值hash_1b；然后，可信第三方比较第四哈希值hash_1b与存储的第三哈希值hash_1是否一致。

若比较出第四哈希值hash_1b与第三哈希值hash_1不一致，则判断出可信第三方接收的密文子文件Cipher_1不完整，可信第三方删除存储的密文子文件Cipher_1和第三哈希值hash_1，并请求存储控制中心重新发送相应的密文子文件Cipher_1和第三哈希值hash_1。此时存储控制中心删除之前存储的密文子文件Cipher_1和第三哈希值hash_1，并重新向1号服务器下载密文子文件Cipher_1和第三哈希值hash_1，存储控制中心将重新下载好的密文子文件Cipher_1和第三哈希值hash_1发送给可信第三方，可信第三方重新接收并存储密文子文件Cipher_1和第三哈希值hash_1，并对重新接收的密文子文件Cipher_1的完整性进行判断。若可信第三方在对密文子文件Cipher_1的完整性判断步骤执行M(M为大于1的自然数)次后，依然判断出密文子文件Cipher_1不完整，此时，存储控制中心认定1号服务器中存储的密文子文件Cipher_1被破坏，并对1号服务器作出惩罚。同时，存储控制中心向4号服务器发送调度请求，以下载4号服务器中存储的密文子文件Cipher_1和第三哈希值hash_1，并将从4号服务器中下载的密文子文件Cipher_1和第三哈希值hash_1发送给可信第三方，可信第三方对来自4号服务器中的密文子文件Cipher_1的完整性进行判断，若存储控制中心最终认定4号服务器中存储的密文子文件Cipher_1也被破坏，则可信第三方向用户端发出上传文件被破坏的信息，用户端可以对存储服务器集群提出“控告”。

若比较出第四哈希值hash_1b与第三哈希值hash_1一致时，则判断出可信第三方存储的密文子文件Cipher_1完整，可信第三方可以对密文子文件Cipher_2或者其他的密文子文件的完整性进行判断，直至可信第三方判断出存储的全部的密文子文件(Cipher_1、Cipher_2、Cipher_3和Cipher_4)都完整。

步骤411：可信第三方对全部的密文子文件进行解密处理，得到上传子文件。

在步骤411中，可信第三方的解密处理的过程如下：

首先，可信第三方利用预先存储(在用户端向通过可信第三方向存储服务器集群存储上传文件的过程中存储的)的随机数种子S生成随机数R；然后，可信第三方利用随机数R分别与密文子文件Cipher_1、密文子文件Cipher_2、密文子文件Cipher_3和密文子文件Cipher_4进行异或运算，分别得到上传子文件file_1、上传子文件file_2、上传子文件file_3和上传子文件file_4，解密完成。其中，file_i＝Cipher_i⊕R，i的取值为1、2、3或4。

步骤412：对全部的上传子文件进行重组处理，达到上传文件。

在步骤412中，可信第三方根据预先存储的数据重组算法将全部的上传子文件(file_1、file_2、file_3和file_4)得到上传文件File1。

步骤413：可信第三方将上传文件发送至用户端。

步骤414：用户端接收可信第三方发送的上传文件。

用户端通过浏览器或客户端接收可信第三方发送的上传文件File1，流程结束。

需要说明的是，本实施例中提供的上传文件对应4个密文子文件以及4个密文子文件对应的调度结果的情况，仅起到示例性描述的作用，并不对本发明的技术方案产生限制。

本发明实施例四提供了一种可信传输方法，可信第三方通过判断其自身接收并存储的全部的密文子文件是否完整，并在当判断出存储的全部密文子文件都完整时，对全部的密文子文件进行解密处理和重组处理，并将重组后得到的上传文件发送至用户端，使得用户端接收到完整的上传文件，从而避免了存储服务器集群恶意修改上传文件以诬陷用户端的问题，同时存储文件的解密处理过程由可信第三方执行，从而减小了用户端的数据处理压力。

实施例五

图5为本发明实施例五提供的可信第三方的示意图，如图5所示，该可信第三方包括：第一判断模块4和加密模块5，其中，第一判断模块4用于判断可信第三方接收到的用户端发送的上传文件是否完整；加密模块5用于若判断出接收到的用户端发送的上传文件完整时，对上传文件进行加密得到存储文件，并将存储文件发送至存储服务器集群。

进一步地，该可信第三方还包括：第一存储模块3，第一存储模块3用于接收并存储用户端发送的上传文件和上传文件对应的第一哈希值。

可选地，第一判断模块4包括：第一计算子模块41、第一比较子模块42和第一判断子模块43，其中，第一计算子模块41用于对存储的上传文件进行哈希计算得到第二哈希值；第一比较子模块42用于比较第一哈希值和第二哈希值是否一致；第一判断子模块43用于若比较出第一哈希值和第二哈希值一致时，则判断出第一存储模块3接收到的上传文件完整。

可选地，存储文件包括若干个密文子文件，加密模块5包括：分割子模块53、加密子模块52和第一发送子模块51，其中，分割子模块53用于根据预设的数据分割算法将上传文件分割为具有特定长度的上传子文件；加密子模块52用于对每个上传子文件进行加密得到相应的密文子文件，并计算每个密文子文件的第三哈希值；第一发送子模块51用于将全部密文子文件和每个密文子文件对应的第三哈希值发送至存储服务器集群。

需要说明的是，计算密文子文件的第三哈希值的工作也可以由第一计算子模块41来完成。

本实施例提供的可信第三方可用于实现上述实施例一或者实施例二提供的可信传输方法，具体描述可参见上述实施例一或者实施例二。

本发明实施例五提供了一种可信第三方，该可信第三方包括：第一判断模块和加密模块，其中第一判断模块判断可信第三方接收到的用户端发送的上传文件是否完整，若判断出接收到的用户端发送的上传文件完整时，加密模块对上传文件进行加密得到存储文件，并将存储文件发送至存储服务器集群进行存储。本实施例中加密模块在第一判断模块判断出用户端发送的上传文件是完整时，才会对上传文件进行加密处理，并将加密处理后得到的存储文件发送至服务器进行存储，使得用户端上传文件的完整保存，从而避免了用户端恶意修改上传文件以诬陷存储服务器集群的问题；同时上传文件的加密处理过程由可信第三方执行，从而减小了用户端的数据处理压力。

实施例六

图6为本发明实施例六提供的可信第三方的结构示意图，如图6所示，该可信第三方包括：第二判断模块7和解密模块8，其中，第二判断模块7用于判断可信第三方接收到的存储服务器集群发送的存储文件是否完整；解密模块8用于若判断出接收到的存储服务器集群发送的存储文件完整时，对存储文件进行解密得到上传文件，并将上传文件发送至用户端。

需要说明的是，存储文件包括：若干个密文子文件。

进一步地，该可信第三方还包括：第二存储模块6，第二存储模块6用于接收并存储密文子文件和密文件对应的第三哈希值。

可选地，第二判断模块7包括：第二计算子模块71、第二比较子模块72和第二判断子模块73，其中，第二计算子模块71用于对存储的密文子文件进行哈希计算得到第四哈希值；第二比较子模块72用于比较第三哈希值和第四哈希值是否一致；第二判断子模块73用于若比较出第三哈希值和第四哈希值一致时，则判断出第二存储模块6接收到的密文子文件完整。

可选地，存储文件包括若干个密文子文件，解密模块8包括：解密子模块83、重组子模块82和第二发送子模块81，其中，解密子模块83用于对密文子文件进行解密得到上传子文件；重组子模块82用于根据预设的数据重组算法将全部上传子文件进行重组得到上传文件；第二发送子模块81用于将上传文件发送至用户端。

本实施例提供的可信第三方可用于实现上述实施例三或者实施例四提供的可信传输方法，具体描述可参见上述实施例三或者实施例四。

本发明实施例六提供了一种可信第三方，该可信第三方包括：第一判断模块和加密模块，第一判断模块判断可信第三方接收到的存储服务器集群发送的全部密文子文件是否完整，若判断出接收到的全部密文子文件都完整时，解密模块对密文子文件进行解密上传文件，并将上传文件发送至存储服务器集群进行存储。本实施例中解密模块在第二判断模块判断出存储服务器集群发送的全部密文子文件都完整时，才会对上传文件进行解密处理，并将解密处理后得到的存储文件发送至用户端，使得用户端上传文件的完整保存，从而避免了存储服务器集群恶意修改上传文件以诬陷用户端的问题，同时存储文件的解密处理过程由可信第三方执行，从而减小了用户端的数据处理压力。

实施例七

图7为本发明实施例七提供的可信传输系统的结构示意图，如图7所示，该可信传输系统包括：用户端1、存储服务器集群2和可信第三方9，其中，存储服务器集群包括：存储控制中心和若干个服务器，可信第三方9采用上述实施例五、实施六提供的可信第三方9。

该可信传输系统的工作体现在两个过程：用户端1的上传过程和用户端1的下载过程。

用户端1的上传过程大致如下：

首先，用户端1将上传文件发送可信第三方9；然后，可信第三方9判断接收到的上传文件是否完整，并在判断出接收到的上传文件完整时，对上传文件进行加密处理得到存储文件，并将存储文件发送值存储服务器集群2；最后，存储服务器集群2中的服务器对存储文件进行存储，上传过程结束。

在上传过程中，由于可信第三方9仅在判断出接收到用户端1发送的上传文件完整时，才会将上传文件加密为存储文件，并将存储文件发送给存储服务器集群2进行存储，因此可信第三方9可保证上传文件可信的存储于存储服务器集群2中。而当可信第三方9判断出接收到用户端1发送的上传文件不完整时，可信第三方9要求用户端1重新的发送上传文件，从而对用户端1的错误上传起到了预警的作用。

用户端1的上传过程的具体描述可参见上述实施例一或实施例二，此处不再赘述。

用户端1的下载过程大致如下：

首先，用户端1将存储文件发送可信第三方9；然后，可信第三方9判断接收到的存储文件是否完整，并在判断出接收到的存储文件完整时，对上传文件进行解密处理得到上传文件，并将上传文件发送值用户端1；最后，用户端1接收上传文件，下载过程结束。

在下载过程中，由于可信第三方9仅在判断出接收到存储服务器集群2发送的存储文件完整时，才会将存储文件解密为上传文件，并将解密文件发送给用户端1，因此可信第三方9可保证上传文件可信的发送至用户端1中。而当可信第三方9判断出接收到存储服务器集群2发送的存储文件不完整时，可信第三方9要求存储服务器集群2重新发送存储文件，从而对用户端1的错误下载起到了预警的作用。

用户端1的下载过程的具体描述可参见上述实施例三或实施例四，此处不再赘述。

用户端1接收到所需要下载的上传文件后，对接收到的上传文件的完整性进行验证，若验证不通过，则用户端1也不能诬陷是服务器破坏了文件，此时，用户端1会发送上传文件被破坏的信息给可信第三方9，并请求可信第三方9重新发送上传文件；若验证通过，则用户端1会发送上传文件正确的信息给可信第三方9，可信第三方9删除自身存储的上传文件和存储文件以节省存储空间。

本发明实施例七提供了一种可信传输系统，该可信传输系统包括：用户端、服务器集群和可信第三方，可信第三方用于判断接收到的用户端发送的上传文件是否完整；若判断出接收到的用户端发送的上传文件完整时，对上传文件进行加密得到存储文件，并将存储文件发送至存储服务器集群，或者可信第三方用于判断接收到的存储服务器集群发送的存储文件是否完整；若判断出接收到的存储服务器集群发送的存储文件完整时，对存储文件进行解密得到上传文件，并将上传文件发送至用户端。本实施例中的可信第三方可以为用户端对存储服务器集群“控告”提供仲裁结果，有效的防止了用户端与存储服务器集群之间的诬告，同时，由于可信第三方可实现加密处理或解密处理，因此减小了用户端的数据处理压力。

可以理解的是，以上实施方式仅仅是为了说明本发明的原理而采用的示例性实施方式，然而本发明并不局限于此。对于本领域内的普通技术人员而言，在不脱离本发明的精神和实质的情况下，可以做出各种变型和改进，这些变型和改进也视为本发明的保护范围。

Claims (14)

1.一种可信传输方法，其特征在于，包括：

判断接收到的用户端发送的上传文件是否完整；

若判断出接收到的用户端发送的上传文件完整时，对所述上传文件进行加密得到存储文件，并将所述存储文件发送至存储服务器集群。

2.根据权利要求1所述的可信传输方法，其特征在于，所述判断接收到的用户端发送的上传文件是否完整的步骤之前还包括：

接收并存储所述用户端发送的上传文件和所述上传文件对应的第一哈希值；

所述判断接收到的用户端发送的上传文件是否完整的步骤包括：

对存储的所述上传文件进行哈希计算得到第二哈希值；

比较所述第一哈希值与所述第二哈希值是否一致，若比较出所述第一哈希值与所述第二哈希值一致时，则判断出所述上传文件完整。

3.根据权利要求1所述的可信传输方法，其特征在于，所述存储文件包括若干密文子文件，所述对所述上传文件进行加密得到存储文件，并将所述存储文件发送至存储服务器集群的步骤包括：

根据预设的数据分割算法将所述上传文件分割为具有特定长度的上传子文件；

对每个所述上传子文件进行加密处理得到对应的密文子文件；

对所述密文子文件进行哈希计算得到第三哈希值；

将全部所述密文子文件和所述密文子文件对应的第三哈希值发送至所述存储服务器集群。

4.一种可信传输方法，其特征在于，包括：

判断接收到的存储服务器集群发送的存储文件是否完整；

若判断出接收到的所述存储服务器集群发送的所述存储文件完整时，对所述存储文件进行解密得到上传文件，并将所述上传文件发送至用户端。

5.根据权利要求4所述的可信传输方法，其特征在于，所述存储文件包括：若干个密文子文件，所述判断接收到存储服务器集群发送的存储文件是否完整的步骤之前包括：

接收并存储所述密文子文件和所述密文件对应的第三哈希值；

所述判断接收到存储服务器集群发送的存储文件是否完整的步骤包括：

逐个的判断存储的所述密文子文件是否完整；

若判断出全部所述密文子文件都完整时，则所述存储文件完整。

6.根据权利要求5所述的可信传输方法，其特征在于，所述判断存储的所述密文子文件是否完整的步骤包括：

对存储的所述密文子文件进行哈希计算得到第四哈希值；

比较所述第三哈希值与所述第四哈希值是否一致，若比较出所述第三哈希值与所述第四哈希值一致时，则判断出所述密文子文件完整。

7.根据权利要求5所述的可信传输方法，其特征在于，所述对所述存储文件进行解密得到上传文件，并将所述上传文件发送至用户端的步骤包括：

对所述密文子文件进行解密得到上传子文件；

根据预设的数据重组算法将全部所述上传子文件进行重组得到所述上传文件；

将所述上传文件传送至所述客户端。

8.一种可信第三方，其特征在于，包括：

第一判断模块，用于判断所述可信第三方接收到的用户端发送的上传文件是否完整；

加密模块，用于若判断出接收到的用户端发送的上传文件完整时，对所述上传文件进行加密得到存储文件，并将所述存储文件发送至存储服务器集群。

9.根据权利要求8所述的可信第三方，其特征在于，所述可信第三方还包括：

第一存储模块，用于接收并存储所述用户端发送的上传文件和所述上传文件对应的第一哈希值；

所述第一判断模块包括：

第一计算子模块，用于对存储的所述上传文件进行哈希计算得到第二哈希值；

第一比较子模块，用于比较所述第一哈希值与所述第二哈希值是否一致；

第一判断子模块，用于若比较出所述第一哈希值和所述第二哈希值一致时，则判断出接收到的所述上传文件完整。

10.根据权利要求8所述的可信第三方，其特征在于，所述存储文件包括若干个密文子文件，所述加密模块包括：

分割子模块，用于根据预设的数据分割算法将所述上传文件分割为具有特定长度的上传子文件；

加密子模块，用于对每个所述上传子文件进行加密处理得到相应的密文子文件，并计算每个所述密文子文件的第三哈希值；

第一发送子模块，用于将全部所述密文子文件和每个所述密文子文件对应的第三哈希值发送至所述存储服务器集群。

11.一种可信第三方，其特征在于，包括：

第二判断模块，用于判断所述可信第三方接收到的存储服务器集群发送的存储文件是否完整；

解密模块，用于若判断出接收到的所述存储服务器集群发送的所述存储文件完整时，对所述存储文件进行解密得到上传文件，并将所述上传文件发送至所述用户端。

12.根据权利要求11所述的可信第三方，其特征在于，所述存储文件包括：若干个密文子文件，所述可信第三方还包括：

第二存储模块，用于接收并存储所述密文子文件和所述密文件对应的第三哈希值；

所述第二判断模块包括：

第二计算子模块，用于对存储的所述密文子文件进行哈希计算得到第四哈希值；

第二比较子模块，用于比较所述第三哈希值与所述第四哈希值是否一致；

第二判断子模块，用于若比较出所述第三哈希值与所述第四哈希值一致时，则判断出接收到的所述密文子文件完整。

13.根据权利要求11所述的可信第三方，其特征在于，所述解密模块包括：

解密子模块：用于对所述密文子文件进行解密得到上传子文件；

重组子模块：用于根据预设的数据重组算法将全部所述上传子文件进行重组得到所述上传文件；

第二发送子模块：用于将所述上传文件发送至所述用户端。

14.一种可信传输系统，其特征在于，包括：用户端、存储服务器集群和可信第三方，所述可信第三方采用上述权利要求8-13中任一所述的可信第三方。