云存储中基于分组的秘密共享修复模型

孙书豪 李大刚 符玥 都政

摘 要：云存储应用广泛，但云端节点的不可控特性使存储的数据安全性得不到保障，制约了云存储在敏感数据和关键数据存储中的推广。秘密共享技术通过将原始数据作为秘密拆分成若干秘密份额并规定访问门限，为云存储数据安全提供保障。虽然部分份额的损坏不会影响到数据恢复，但若超过一定限度将无法恢复原始数据。针对该问题，设计了一个基于分组的秘密共享修复模型，可以在不影响秘密共享安全保证的前提下修复丢失或受损的秘密份额，并且可以降低修复代价。该方案突破了以往份额修复的惯用方法，实现了安全修复和局部性统一，为份额修复提供了新思路，为后续研究打下了良好的基础。

关键词：云存储；秘密共享；份额修复模型；修复冗余；修复函数

DOI：10.11907/rjdk.172681

中图分类号：TP309

文献标识码：A 文章编号：1672-7800（2018）005-0205-06

Abstract：After years of rapid development， cloud storage has become widely used， but the security of data in the cloud is still highly worried， which holds back its further endorsement by highly sensitive and confidential data. Secret sharing is an important security technology that can be applied to cloud storage to improve data security. It divides the original data into shares and sets a minimum threshold on number of shares required to recover the original data. Although by nature secret sharing has certain level of fault tolerance since one or two damaged shares will not hurt the recovery capability， but such tolerance will go away if the number of remaining shares is below the threshold. Aiming at this problem we propose， a group-based secret sharing repair model in this paper to provide safe and efficient share repairement for secret sharing. This model has higher security and lower repair cost than recovering the original secret and regenerating new shares. In addition， this model provides new views for share repairing over conventional methods， which lays a sound foundation for further research.

Key Words：cloud storage； secret sharing； share repair model； repair redundancy； repair function

0 引言

云存儲的安全性体现为数据的机密性、完整性和可用性：云存储中的很多数据会涉及到个人隐私信息，具有高度的隐私性和敏感性，必须确保其机密性；云存储中节点失效等问题可能导致云数据永久丢失或在一段时间内无法访问，其完整性和可用性也是亟需解决的问题[1-3]。

秘密共享作为一种重要的安全技术，为云存储数据安全提供了解决方案[3-6]。以Shamir[7]的门限秘密共享方案为例，它可以将关键数据作为秘密拆分成n个秘密份额，并分发给n个服务器，只有得到不小于t个秘密份额时，才能对秘密进行恢复从而得到原始数据。因此，即使有攻击者攻击部分服务器得到少数秘密份额，也无法获得原始数据，有效保障了云数据的机密性。

秘密共享可以忍受一定数量的节点故障，在少数份额丢失或损坏的情况下仍能完成原数据的恢复。然而，这种错误容忍力是有限的，损坏超过（n-t）后无法恢复。因此，秘密共享也需要一个良好的数据修复机制，从而能够及时补充丢失或受损的秘密份额，维持系统冗余度，以保障云数据的完整性和可用性[8]。份额修复这一重要特性在基于纠删码的存储方案中得到了较好应用，但在秘密共享方案中研究不多。在秘密共享中提供份额修复能力，需要注意不要影响到秘密共享本身的门限要求和完备安全性。为此，本文做了如下工作：

（1）设计了一个基于分组的秘密共享修复模型，以分组为单位提供份额修复功能，实现份额修复的局部化以降低修复代价，并提出了弱修复冗余、强修复冗余以及修复函数等概念，以精确描述模型性质。

（2）提供了修复功能与原秘密恢复独立的新思路：用于修复的数据与秘密共享份额数据解耦，不会影响到原秘密共享的门限要求，保证其安全性。

（3）本文模型是一个通用的份额修复模型，适用于除Shamir外其它类型的秘密共享方案。除此之外，模型本身还具有较好的灵活性，在使用中可以根据实际需要选择合适的修复能力和计算代价。

1 相关工作

秘密共享技术本身具有最原始的修复能力：在份额损坏后可以通过恢复秘密然后重新分发的方式补充损坏的份额，这也是云存储系统中常用的份额修复方法。但这样不安全，它使秘密在不是用户访问的情况下被恢复，增加了泄露的风险。另外，修复一份份额需要在网络中传输至少t+1倍的数据，传输代价较大。

针对秘密共享份额修复的研究成果较少。Herzberg等 [9]于1998年最先提出了一个针对Shamir方案的秘密共享份额恢复协议，其目的是避免各份额本身在修复过程中被曝露出来。基本思想是：未损失份额的t个成员发送一些伪份额信息给份额受损成员，该成员利用这些信息可计算出自己的原始份额。此协议后来被学者改造用于秘密共享的新成员加入协议[10]。Guang等[11]于2014年提出了一种可修复门限秘密共享方案（GLF），利用再生码的性质实现秘密的恢复和份额的修复；2016年，Stinson等[12]提出了两种份额修复方法，首先对Nojoumian等[13]对秘密共享新成员加入协议进行了改造，使改造后的协议用于份额修复，然后提出了一种（k，n）门限秘密共享份额修复方法，套用两层秘密共享方案实现份额的修复。

除了原始修复方法外，其它份额修复方法都不具备通用性，不适用于不同类型的秘密共享方案。其中，Herzberg协议、Stinson的第一种方法以及GLF方案，弥补了原始修复方法在安全性上的不足，但为之付出的代价是巨大的网络通信开销，其通信量比原始修复方法增加了一个数量级，并且一次修复过程要访问的节点数甚至大于恢复秘密需要访问的节点数，修复代价非常大；Stinson的第二种方法具有较低的通信复杂性，但是其产生的存储开销却十分巨大。因此，上述方案中，尚没有一个安全、通用且具有较高性能的份额修复方案。

本文提出的云存储中基于分组的秘密共享修复模型具有通用性，可适用于各种类型的秘密共享方案，除此之外，该方案的分组修复能力还具有较高的安全性和灵活性，以及较小的修复代价，为秘密共享份额修复提供了一个较好的选择。

2 基于分组的秘密共享修复模型

对国内外相关工作调研发现，秘密共享修复方案的修复代价与其安全性是相对的，安全性越高修复代价越大，于是尝试均衡两者关系，并以此展开模型设计。基本思想是通过分组降低修复份额时涉及的节点数和远程通信代价，然后通过分组策略和修复算法设计，保证局部修复能力的引入不会影响到原秘密共享安全特性。

2.1 设计思想

模型分为3个阶段：①分组阶段。为了减少修复过程中的通信代价，提出了一种分组机制，在所有存储秘密份额的服务器中，将物理距离近的服务器分到一组。这些分组只是逻辑意义上的，并不改变这些份额在秘密共享方案中的角色以及功能。将修复过程限定在组内，使组内服务器之间互相修复受损份额，不能跨组进行；②初始化阶段。在分组基础上，每个组内计算用于修复组内份额的冗余并将其合理存储。要保证这些冗余不用来恢复原始秘密，且与原秘密共享方案完全无关，从而维持原秘密共享方案的安全级别；③份额修复阶段。当组内份额失效时，修复冗余与组内其它份额合作可以恢复出一个修复函数，它仅在组内生效。通过修复函数可计算出失效份额，从而实现修复。

2.2 初始化阶段

初始化后系统整体情况如图2所示，模型将原来的n个秘密份额分为m个组，且每组都生成了修复冗余。从以上描述可知，在初始化阶段，所有修复冗余实际上与原始数据的秘密份额完全无关，也就是说引入的冗余并不能用于原始秘密的恢复，也就不会影响到原始秘密共享的所有安全特性。

2.3 份额修复阶段

定义1：修复函数。修复函数具有修复组内所有秘密份额功能。方案中的r-1次多项式f（x）=b0+∑r-1i=1bixi即为组内的修复函数。

定义2：强修复冗余。如果一个冗余可以独立确定整个修复函数，则称之为强修复冗余。例如，当修复冗余个数为r时是一种强修复冗余。

定义3：弱修复冗余。如果一个冗余可以在组内其它服务器的协助下确定修复函数，则称之为弱修复冗余。例如，当修复冗余只为一个yr+1时，是一种弱修复冗余，也是最弱修复冗余，随着冗余个数的增加，弱修复冗余的能力逐渐增强，当个数等于r时就成为强修复冗余。

修复函数参考shamir方案选择多项式构造，使修复冗余和组内份额之间具备类似的门限关系。在份额修复阶段，只要修复冗余和未失效份额的总数不小于r，就可以利用r个坐标恢复修复函数f（x）。此时将份额失效服务器的x值代入f（x）中即可求出它的份额y，从而实现修复。

修复冗余越强修复能力就越强。设修复冗余的个数为g，只要冗余和组内份额的总数为r，就可以恢复修复函数，所以参与恢复的组内份额数量为r-g。因此，g越大，恢复修复函数需要的组内份额数量就越小，可容忍的组内份额失效数就越大，方案的修复能力就越强。所以，当模型使用者不需要方案具有较强修复能力时，就可选择生成相对弱的修复冗余，而当需要较强的修复能力时，就可以选择相对强的修复冗余。可按照具体应用需求选取，说明该模型具有极高的灵活性。

2.4 冗余存储修复

设计了修复冗余的两种存储方式，可根据有无增加参与秘密共享的服务器进行区分。

（1）将g个修复冗余分布存储到每组附近没有秘密份额的g台服务器上，将这g台服务器加入该组，如图3所示。以后的修复过程就以组内的r+g台服务器為单位进行：①当组内服务器受损时，剩余服务器发送r个点坐标到修复服务器中，共同恢复修复函数f（x）；②受损服务器Pi将xi发送到修复服务器中，即可求出自己的原始份额yi。

这一方案完全不会改变原始秘密共享的所有操作，而且所有修复过程中的数据传输全部局限在组内进行，不牵涉到远程的组间数据交换，影响更小。

（2）若使用者不想增加参与秘密共享的服务器个数，就可采用这种方式，将g个修复冗余分布存储到组外的g台存有秘密份额的服务器上，如图4所示。具体存储到哪一台是随机的，组内服务器并不知道。

当组内份额损坏时，组内服务器向所有存有份额的服务器广播一个哈希值，组外存有该组冗余的服务器就可通过验证哈希值，得知这个修复过程并识别出对应的冗余，进而将其发回给组内负责修复的服务器，对受损份额进行修复。

修复代价与安全性是对立的，而在该模型中这个问题已经得到了较好解决。利用分组将修复过程局域化，减少了修复过程中的网络通信开销，进而减小了修复代价；同时，模型在修复过程中没有涉及到秘密的任何信息，因此在修复代价和安全性方面都比原始的修复方法更有优势。

3 安全性仿真实验

云存储中秘密共享原始的修复方法是，先由一台服务器（称为repair server）向未受损服务器请求份额，将原来的秘密恢复，再对受损的服务器重新分发份额。本文模型中，若将所有的份额均匀分成m组，每组r个份额，并且每组生成g个修复冗余，则称之为（m，r，g）修复方案。为了方便比较，将门限秘密共享作为基础的秘密共享，以此为例进行仿真实验。

3.1 实验设计

原始方案需要恢复出原来的秘密才能进行份额修复，一旦在修复过程中被攻击者攻击，秘密就极有可能泄露。例如，如果攻击者知道这个修复过程，且知道修复过程在哪台服务器上进行，那么在修复时间内对这台修复服务器不断发起攻击，就很有可能获取秘密。而本文模型中，每次的修复过程并不会暴露秘密信息，倘若被攻击者获取，最多也只能得到该组内的份额，无法得到秘密。

攻击者想要获取存储在云服务器上的秘密数据，假设该攻击者能进行最大程度的攻击，即对每台服务器同时并行进行攻击，每台服务器被攻破的概率为p。以一轮攻击时间为单位，设该时间段内发生修复过程的概率为q，攻击者攻破一台服务器之后可以获取这台服务器上的全部数据。若有修复过程就包括repair server发来的请求份额进行修复的信息，那么此时这个攻击者就可以锁定repair server，从而在修复时间内对这台服务器发起攻击。设攻击者在修复时间内可以对repair server发起h次攻击，每次攻破的概率为z。

两个测试模型为：①原始模型：应用在云存储系统中的（8，12）门限秘密共享方案；②本文模型：对原始的（8，12）门限秘密共享采用（3，4，1）均匀分组的修复方案。

实验内容：假设攻击者分别在原始模型和本文模型下对12台存有份额的服务器展开时长为t0的攻击，求这一轮攻击结束后攻击者获取秘密的概率ψ0和ψ1。

制定本实验的各个参数值。根据云存储系统中的实际情况，将攻击者一分钟攻破一台服务器的概率定为0.000 2。因此，本实验将t0合理地设置为8小时，在这8小时中每台服务器被攻破的概率为0.000 2·60·8≈0.1，因此 p=0.1。同时，参考Facebook部署的Hadoop集群的日节点失效数设定q的大小，如图5所示。

Hadoop集群共有3 000个节点，包含大约45PB的数据，每天的节点失效数平均为22个，其中最高的数目甚至高于100个[14]。根据数据，假设这22个失效节点中有12个节点的失效引发了修复过程，那么平均每个节点一天内需要修复的概率为12/3 000=0.004，每小时需要修复的概率为0.004/24≈0.000 167。因此，在本实验的一轮攻击时间8小时内，每个服务器份额需要修复的概率为0.000 167·8≈0.001 3。所以，在原始模型中，一轮攻击时间内发生修复过程的概率为q1=C＼+1120.0013=0.016；在本文模型中修复是分组进行的，每组加上冗余共有5个份额，因此一轮攻击时间内每组发生修复过程的概率为q2= C＼+130.0013=0.0065。假设修复过程持续时间为10分钟，设h=10，那么z=0.000 2。

综上，将系统参数设定为t0=8h、p=0.1、q1=0.016、q2=0.006 5、h=10、z=0.000 2，将原始模型和本文模型在相同系统环境下展开仿真实验。

3.2 实验过程

原始模型：假设攻击者在一轮攻击后至少攻破了1台服务器，并且该时间段内有修复过程，那么攻击者就可以接收到repair server发来的请求修复信息，进而锁定repair server进行攻击，若攻击成功就可获取秘密。这样一轮攻击结束后，若攻击者攻破的服务器总数超过了门限值8，或者攻击者成功攻破了repair server，攻击者就成功得到了秘密。

假设攻击者在一轮攻击后至少攻破组内1台服务器，并且该时间段内该组有修复过程，那么攻击者就可锁定该组内的repair server进行攻击，若攻击成功就可获取到该组内所有的服务器份额。这样一轮攻击结束后，攻击者攻破的服务器个数同时加上攻击repair server成功后拿到的份额数量总数若超过了门限值8，攻击者就成功得到了秘密。

假设攻击者共发起10 000 000轮攻击，统计10 000 000轮攻击中成功获取秘密的次数，同时将以上过程循环100次，实验结果如图6所示。

从图6可以看出，原始模型获取到的秘密次数远大于本文模型。对这两条折线取平均值，得到10 000 000轮攻击中原始模型、本文模型平均获取秘密的次数，分别为265.11、31.85。因此，ψ0=2.7·10-5，ψ1=3.2·10-6，原始模型泄露秘密的可能性比本文模型大了一个数量级，可见通过恢复秘密进行修复对安全性造成了很大的威胁。

3.3 安全性实验结果分析

通过对安全性進行仿真实验测试，证明了本文所提出的模型在安全性方面明显高于原始方案的安全性。原始方案通过恢复秘密来修复份额的方式存在很大的安全威胁，本文模型很好地解决了这个问题，具有更高的安全性。

4 修复代价仿真实验

原始修复方法每次修复都需要恢复出秘密，在恢复秘密过程中的通信量有时延等修复代价，不仅占用了大量网络资源，还降低了修复效率。本文模型采用分组机制，将服务器按照物理距离因素进行分组，将修复限定在组内，极大减小了修复过程中的修复代价。下面对本文模型与原始模型展开修复的通信量和时延进行仿真实验。

3个测试模型为：

方案Q1：不作任何处理的（8，12）原始秘密共享方案；

方案Q2：在本文模型上对原始方案采用（3，4，1）的修复方案，并采用方式①存储冗余；

方案Q3：在本文模型上对原始方案采用（3，4，1）的修复方案，并采用方式②存储冗余。

4.1 通信量实验

在网络中，节点间通信会存在一定的重传概率，通信的两个节点距离越远则重传概率越大，按照实际情况合理设置重传概率。因为组内的服务器距离较近，因此将组内的重传概率设为p1=0.01，组外的服务器距离较远，将组外的重传概率设为p2=0.05。若数据重传，则此次的通信量加倍。假设每个份额大小为size=10 000，系统中每个服务器份额在某段时间内失效的概率为q=0.1，份额失效后即展开修复过程，求系统分别采用方案Q1、Q2、Q3时在该段时间内修复所需的总通信量。

方案Q1：每次修复都需要传输8个份额恢复出原始秘密，且因为repair server平均距离每台服务器较远，因此每次通信的重传概率为p2。

方案Q2：不管是份额受损还是冗余受损，每次修复都只需传输组内4个份额恢复修复函数，重传概率为p1。

方案Q3：当组内服务器受损时，需要传输组外1个冗余和组内3个份额。传输组内份额时重传概率为p1，传输组外冗余则为p2；当组外冗余受损时，不仅需要对该冗余进行修复，还需要对这台服务器上的份额进行修复，此时通信量为其它修复过程的两倍。两次修復都在各组内进行，修复结束后再发给受损份额，重传概率为p1。

在方案Q1、Q2、Q3下分别展开一轮通信量实验并循环1 000次，将实验结果整理到图7中。

从结果可以看出，方案Q1所需的平均通信量大于方案Q2和方案Q3的通信量，对这3种方案的通信量求平均值得：ωQ1=102 550，ωQ2=59 870，ωQ3=62 970，可见本模型修复所需的通信量远小于原始方案的通信量，同时模型内部的第一种方法比第二种方法在通信量上略有优势。

4.2 时延实验

在云存储系统中，数据从一个节点传输到另一个节点会产生通信时延，主要为发送时延、传播时延、处理时延和排队时延。一般来说，发送时延和传播时延是主要因素，其中，发送时延=数据帧长度（b）/发送速率（b/s），传播时延=信道长度（m）/信道上的传播速率（m/s）。

在同一系统环境下，方案Q1、Q2和Q3每次节点间通信的数据量是一样的，因此决定3个方案时延的主要原因是传播时延，而传播时延又与信道长度有关，即与节点间的传输距离有关。因此设组内通信时延为t1=50ms，组间通信时延为t2=300ms，其余系统参数与通信量一致，若数据需要重传则时延加倍。

求系统分别采用方案Q1、Q2、Q3时在该段时间内修复所需的总时延：

方案Q1：修复过程中每次通信的时延为t2=300ms，重传概率p2=0.05，一旦需要重传则此次通信的时延加倍。

方案Q2：不管是份额受损还是冗余受损，每次修复都只在组内进行，因此每次通信的时延为t1=30ms，重传概率p1=0.01。

方案Q3：当组内服务器受损时，需要传输1个组外冗余和3个组内份额，传输组内份额的通信时延为t1，传输组外冗余则为p2，相应的重传概率分别为p1和p2；当组外冗余受损时，通信次数为其它修复过程的两倍，两次修复都在各组内进行，修复结束后再发给受损份额，时延为t1，重传概率为p1。

在方案Q1、Q2、Q3下分别展开一轮实验，并循环1 000次，将实验结果整理到图8中。

从结果可以看出，平均时延Q1>Q2>Q3，且方案Q1所需的时延远大于方案Q2和方案Q3，对这3种方案的时延求平均值得：TQ1=1723.85ms，TQ2=306.1ms，TQ3=617.6ms，本模型修复时延远小于原始方案的时延，同时模型的方法①比方法②所花费的时延还要小一点。

4.3 修复代价实验结果分析

无论是从通信量还是时延来看，本文模型的修复代价都小于原始的修复方法，具有更高的性能。通信量和时延的差距原因与通信距离和参与修复的节点数有关，这也证明修复模型采用的分组机制极大减小了修复代价，在不占用过多网络资源的同时还能高性能地修复失效节点。

5 模型其它性能分析

5.1 模型的计算复杂性

模型中没有编解码过程，生成修复冗余以及恢复修复函数的过程都是求解线性方程组，没有复杂的计算过程。

已知求解线性方程组的计算复杂度在O（n2）与O（n3）之间，模型中份额总数为n，将n个份额均匀分入m个组，每组中有r个成员，于是有：

当系统中的m个组中只有一组使用修复功能时，计算复杂度处于两者之间：

可以看出，当分组结束后r确定为一个不大的常数时，计算复杂度的上界r3较小，因此整个修复过程的计算复杂度也较小。

最坏的一种情况就是系统中的m个组同时使用修复功能，此时的计算复杂度处于两者之间：

可以看出，当分组结束后r确定为一个不大的常数时，计算复杂度的上界O（r2n）可以近似看成O（n），这也进一步说明了采用分组机制可以很好地提高模型性能。

5.2 模型存储代价

假设份额总数为n，系统中采用（m，r，g）修复模型。假定秘密份额的存储大小为1，则系统中未加入修复功能之前的存储量为n。

若m个组都选择存储最弱修复冗余，则存储量为m，这是存储量最少的情况；而存储量最多的情况是m个组都选择存储强修复冗余，为rm，因此模型增加的存储量处于两者之间：

可以看出，在最坏的情况下，即m个组都选择最强修复冗余时，存储量最多比原来增加一倍，这是非常值得的；而当m个组都选择最弱修复冗余时，整个系统增加的存储量较少，为分组个数m。因此综合来看，模型在存储量方面也具有较好性质。

6 结语

云存储安全性是一个非常重要的问题，秘密共享技术可以用于提高云端数据的安全性，但如何及时高效地修复和补充丢失或损坏的数据份额，是秘密共享技术应用中需要解决的实际问题，也是关系到云存储技术未来发展应用的重要问题。

本文设计了一个基于分组的秘密共享修复模型，通过将修复冗余、修复过程与原秘密共享的数据和操作解耦，从而无需在暴露原始数据、不影响秘密共享安全的前提下，降低受损份额的修复代价，有效保障了数据的安全性、完整性和可用性。通过仿真实验和理论分析，证明本文模型比原始修复方法具有更高的安全性和更低的修复代价。同时，本文模型解决了以往份额修复方案中安全性和局部性的矛盾，为份额修复提供了新思路。

参考文献：

[1] LIN C， SU W B， MENG K， et al. Loud computing security： architecture， mechanism and modeling[J]. Chinese Journal of Computers， 2013，36（9）：1765-1784.

[2] ZISSIS D， LEKKAS D. Addressing cloud computing security issues[J]. Future Generation Computer Systems， 2012，28（3）：583-592.

[3] LIN H Y， TZENG W G. A secure erasure code-based cloud storage system with secure data forwarding[J]. IEEE Transactions on Parallel & Distributed Systems， 2012，23（6）：995-1003.

[4] BESSANI A， CORREIA M， QUARESMA B， et al. DepSky： dependable and secure storage in a cloud-of-clouds[J]. Acm Transactions on Storage， 2011，9（4）：31-46.

[5] ALZAIN M A， SOH B， PARDEDE E. MCDB： Using multi-clouds to ensure security in cloud computing[C]. IEEE Ninth International Conference on Dependable， Autonomic and Secure Computing. IEEE Computer Society， 2011：784-791.

[6] ALSOLAMI F， BOULT T E. Cloud stash： using secret-sharing scheme to secure data， not keys， in multi-clouds[C]. International Conference on Information Technology： New Generations. IEEE Computer Society， 2014：315-320.

[7] SHAMIR A. How to share a secret[J]. Communications of the Acm， 1979，22（11）：612-613.

[8] LI J， YANG S， WANG X， et al. Tree-structured data regeneration in distributed storage systems with regenerating codes[C].Conference on Information Communications. IEEE Press， 2010：2892-2900.

[9] HERZBERG A， JARECKI A. Proactive secret sharing or： how to cope with perpetual leakage[J]. Advances in Cryptology-Crypto'95， 1998（963）：339-352.

[10] YU J， KONG F， HAO R. An efficient member expansion protocol for threshold schemes[C].Communication Technology， 2006. ICCT '06. International Conference on. IEEE， 2006：1-4.

[11] XUAN G， LU J， FU F W. Repairable threshold secret sharing schemes[J]. Computer Science， 2014（6）：49-52.

[12] STINSON D R， WEI R. Combinatorial repairability for threshold schemes[J]. Designs Codes & Cryptography， 2016（2）：1-16.

[13] NOJOUMIAN M， STINSON D R， GRAINGER M. Unconditionally secure social secret sharing scheme[J]. Iet Information Security， 2010，4（4）：202-211.

[14] LIN H Y， TZENG W G. A secure erasure code-based cloud storage system with secure data forwarding[J]. IEEE Transactions on Parallel & Distributed Systems， 2012，23（6）：995-1003.

（責任编辑：杜能钢）