一种数字签名方法、系统及装置与流程

[0001]
本申请涉及信息安全技术领域，具体涉及一种数字签名方法、系统及装置。


背景技术：

[0002]
数字签名是附加在数据单元上的一些数据，或是对数据单元所作的密码变换。这种数据或变换允许数据单元的接收者用以确认数据单元的来源和数据单元的完整性并保护数据单元，防止被人(例如接收者)进行伪造。它是对电子形式的消息进行签名的一种方法，签名消息能在通信网络中传输。数字签名能够保证信息传输的完整性，同时可实现对发送者的身份认证，防止交易中的抵赖发生。
[0003]
当前经典网络中使用数字签名可分为非对称密钥数字签名和对称密钥数字签名两大类。非对称密钥数字签名又称为公开密钥数字签名，采用公钥密码体系实现的数字签名方法。签名数据的发送者利用自己的私钥加密签名数据的摘要，接收者利用发送者的公钥验证数据的完整性，同时对发送者身份实现验证。非对称密钥数字签名方法的安全性是建立在公钥密码体系的安全性基础上的。而公钥密码体系的安全性是建立在“分解大数的困难度”或“以大素数为模来计算对数的困难度”的基础上的。故非对称密钥数字签名方法是建立在计算复杂度基础上的，非无条件安全的。
[0004]
对称密钥数字签名，是基于可信中心的签名方法。可信中心分别与签名数据发送者和签名数据接收者之间共享对称密钥，数据发送者通过与可信中心共享的共享密钥对签名数据进行加密发送到可信中心，可信中心使用自己独有的签名密钥对签名数据进行签名，然后将签名数据通过与签名数据接收者共享的共享密钥进行加密后，将其发送给签名数据接收者。签名数据的持有者可以随时通过可信中心验证数字签名的完整性及验证数据发送者的身份。但是，该种方式数字签名系统的安全性依赖于可信中心的绝对可信性，当可信中心被攻击，则数字签名系统的安全性无法保证。


技术实现要素：

[0005]
有鉴于此，本申请实施例提供一种数字签名方法、系统及装置，以解决现有技术中数字签名的安全对单一可信中心具有依赖性的技术问题。
[0006]
为解决上述问题，本申请实施例提供的技术方案如下：
[0007]
一种数字签名方法，所述方法包括：
[0008]
第一终端向第一可信中心发送与所述第一可信中心对应的签名请求，所述签名请求包括第一身份信息、签名数据以及第一认证信息，所述第一认证信息为使用与所述第一可信中心共享的第一共享密钥生成的所述第一身份信息和所述签名数据的认证信息；所述第一可信中心的数量为至少一个；
[0009]
所述第一可信中心使用所述第一共享密钥对所述第一认证信息进行认证，如果所述第一认证信息认证通过，使用本地签名密钥生成所述签名数据的数字签名，将所述签名数据、所述数字签名以及第二认证信息发送给第二可信中心，所述第二认证信息为使用与
所述第二可信中心共享的第二共享密钥生成的所述签名数据和所述数字签名的认证信息；
[0010]
所述第二可信中心分别使用每个第一可信中心对应的第二共享密钥对该第一可信中心发送的第二认证信息进行认证，如果各个第二认证信息均认证通过，将所述签名数据、各个所述数字签名以及第三认证信息发送给第二终端，所述第三认证信息为使用与所述第二终端共享的第三共享密钥生成的所述签名数据和各个所述数字签名的认证信息；
[0011]
所述第二终端使用所述第三共享密钥对所述第三认证信息进行认证，如果所述第三认证信息认证通过，保留所述签名数据以及各个所述数字签名，将各个所述数字签名作为所述签名数据的数字签名。
[0012]
在一种可能的实现方式中，所述第一可信中心使用所述第一共享密钥对所述第一认证信息进行认证，包括：
[0013]
所述第一可信中心生成第四认证信息，所述第四认证信息为使用所述第一共享密钥生成的接收到的第一身份信息和接收到的签名数据的认证信息，如果所述第四认证信息与所述第一认证信息一致，则所述第一认证信息认证通过；
[0014]
所述第二可信中心分别使用每个第一可信中心对应的第二共享密钥对该第一可信中心发送的第二认证信息进行认证，包括：
[0015]
所述第二可信中心分别生成每个第一可信中心对应的第五认证信息，所述第五认证信息为使用该第一可信中心对应的第二共享密钥生成的接收到的签名数据和接收到的该第一可信中心的数字签名的认证信息，如果每个第一可信中心对应的第五认证信息与该第一可信中心发送的第二认证信息均相同，则各个第二认证信息均认证通过；
[0016]
所述第二终端使用所述第三共享密钥对所述第三认证信息进行认证，包括：
[0017]
所述第二终端生成第六认证信息，所述第六认证信息为使用所述第三共享密钥生成的接收到的签名数据和接收到的各个所述数字签名的认证信息，如果所述第六认证信息与所述第三认证信息一致，则所述第三认证信息认证通过。
[0018]
在一种可能的实现方式中，所述方法还包括：
[0019]
签名密钥分发服务器生成原始密钥数据，对所述原始密钥数据采用纠删码技术进行处理，生成签名密钥数据，将所述签名密钥数据分发给各个所述第一可信中心；所述第一可信中心中的本地签名密钥是从所述签名密钥分发服务器发送的签名密钥数据中获取的。
[0020]
在一种可能的实现方式中，所述方法还包括：
[0021]
所述签名密钥分发服务器对所述第一可信中心中的签名密钥数据进行恢复。
[0022]
在一种可能的实现方式中，所述方法还包括：
[0023]
第三终端将所述签名数据以及各个所述数字签名分别发送给产生该数字签名的第一可信中心；
[0024]
接收到数字签名的第一可信中心根据所述签名数据以及接收到的数字签名对该数字签名进行验证，向所述第三终端发送验证结果；
[0025]
所述第三终端如果接收到各个所述数字签名均通过验证的验证结果，则确定所述签名数据的数字签名正确。
[0026]
在一种可能的实现方式中，所述方法还包括：
[0027]
所述第三终端如果接收到各个所述数字签名未均通过验证的验证结果，则将所述签名数据以及验证未通过的数字签名发送给仲裁服务器；
[0028]
所述仲裁服务器判断所述验证未通过的数字签名对应的第一可信中心中的本地签名密钥是否被更改，如果未更改，向所述第三终端发送所述验证未通过的数字签名通过验证的验证结果。
[0029]
一种数字签名方法，所述方法应用于第一可信中心，所述方法包括：
[0030]
接收第一终端发送的签名请求，所述签名请求包括第一身份信息、签名数据以及第一认证信息，所述第一认证信息为使用与所述第一可信中心共享的第一共享密钥生成的所述第一身份信息和所述签名数据的认证信息；
[0031]
使用所述第一共享密钥对所述第一认证信息进行认证，如果所述第一认证信息认证通过，使用本地签名密钥生成所述签名数据的数字签名；
[0032]
将所述签名数据、所述数字签名以及第二认证信息发送给第二可信中心，以使所述第二可信中心使用所述第一可信中心对应的第二共享密钥对所述第二认证信息进行认证，如果各个所述第一可信中心发送的第二认证信息均认证通过，将所述签名数据、各个所述第一可信中心发送的各个所述数字签名以及第三认证信息发送给第二终端；所述第二认证信息为所述第一可信中心使用与所述第二可信中心共享的第二共享密钥生成的所述签名数据和所述数字签名的认证信息；所述第三认证信息为所述第二可信中心使用与所述第二终端共享的第三共享密钥生成的所述签名数据和各个所述数字签名的认证信息；所述第二终端用于使用所述第三共享密钥对所述第三认证信息进行认证，如果所述第三认证信息认证通过，保留所述签名数据以及各个所述数字签名，将各个所述数字签名作为所述签名数据的数字签名。
[0033]
在一种可能的实现方式中，所述使用所述第一共享密钥对所述第一认证信息进行认证，包括：
[0034]
生成第四认证信息，所述第四认证信息为使用所述第一共享密钥生成的接收到的第一身份信息和接收到的签名数据的认证信息，如果所述第四认证信息与所述第一认证信息一致，则所述第一认证信息认证通过。
[0035]
在一种可能的实现方式中，所述第一可信中心中的本地签名密钥是从签名密钥分发服务器发送的签名密钥数据中获取的，所述签名密钥分发服务器用于生成原始密钥数据，对所述原始密钥数据采用纠删码技术进行处理，生成签名密钥数据，将所述签名密钥数据分发给各个所述第一可信中心。
[0036]
在一种可能的实现方式中，所述签名密钥分发服务器还用于对所述第一可信中心中的签名密钥数据进行恢复。
[0037]
在一种可能的实现方式中，所述方法还包括：
[0038]
接收第三终端发送的所述签名数据以及所述数字签名，根据所述签名数据以及所述数字签名对所述数字签名进行验证，向所述第三终端发送验证结果，以使所述第三终端如果接收到各个所述第一可信中心对应的数字签名均通过验证的验证结果，则确定所述签名数据的数字签名正确。
[0039]
在一种可能的实现方式中，所述第三终端还用于如果接收到各个所述数字签名未均通过验证的验证结果，则将所述签名数据以及验证未通过的数字签名发送给仲裁服务器；
[0040]
所述仲裁服务器，用于判断所述验证未通过的数字签名对应的第一可信中心中的
本地签名密钥是否被更改，如果未更改，向所述第三终端发送所述验证未通过的数字签名通过验证的验证结果。
[0041]
一种数字签名方法，所述方法应用于第二可信中心，所述方法包括：
[0042]
接收各个第一可信中心发送的签名数据、数字签名以及第二认证信息；所述第一可信中心用于接收第一终端发送的签名请求，所述签名请求包括第一身份信息、签名数据以及第一认证信息，所述第一认证信息为所述第一终端使用与所述第一可信中心共享的第一共享密钥生成的所述第一身份信息和所述签名数据的认证信息；使用所述第一共享密钥对所述第一认证信息进行认证，如果所述第一认证信息认证通过，使用本地签名密钥生成所述签名数据的数字签名；将所述签名数据、所述数字签名以及第二认证信息发送给第二可信中心，所述第二认证信息为所述第一可信中心使用与所述第二可信中心共享的第二共享密钥生成的所述签名数据和所述数字签名的认证信息；
[0043]
分别使用每个第一可信中心对应的第二共享密钥对该第一可信中心发送的第二认证信息进行认证；
[0044]
如果各个第二认证信息均认证通过，将所述签名数据、各个所述数字签名以及第三认证信息发送给第二终端，以使所述第二终端使用第三共享密钥对所述第三认证信息进行认证，如果所述第三认证信息认证通过，保留所述签名数据以及各个所述数字签名，将各个所述数字签名作为所述签名数据的数字签名；所述第三认证信息为使用与所述第二终端共享的第三共享密钥生成的所述签名数据和各个所述数字签名的认证信息。
[0045]
在一种可能的实现方式中，所述分别使用每个第一可信中心对应的第二共享密钥对该第一可信中心发送的第二认证信息进行认证，包括：
[0046]
分别生成每个第一可信中心对应的第五认证信息，所述第五认证信息为使用该第一可信中心对应的第二共享密钥生成的接收到的签名数据和接收到的该第一可信中心的数字签名的认证信息，如果每个第一可信中心对应的第五认证信息与该第一可信中心发送的第二认证信息均相同，则各个第二认证信息均认证通过。
[0047]
在一种可能的实现方式中，所述第一可信中心中的本地签名密钥是从签名密钥分发服务器发送的签名密钥数据中获取的，所述签名密钥分发服务器用于生成原始密钥数据，对所述原始密钥数据采用纠删码技术进行处理，生成签名密钥数据，将所述签名密钥数据分发给各个所述第一可信中心。
[0048]
在一种可能的实现方式中，所述签名密钥分发服务器还用于对所述第一可信中心中的签名密钥数据进行恢复。
[0049]
一种数字签名系统，所述系统包括：第一终端、第一可信中心、第二可信中心以及第二终端；
[0050]
第一终端，用于向第一可信中心发送与所述第一可信中心对应的签名请求，所述签名请求包括第一身份信息、签名数据以及第一认证信息，所述第一认证信息为使用与所述第一可信中心共享的第一共享密钥生成的所述第一身份信息和所述签名数据的认证信息；所述第一可信中心的数量为至少一个；
[0051]
所述第一可信中心，用于使用所述第一共享密钥对所述第一认证信息进行认证，如果所述第一认证信息认证通过，使用本地签名密钥生成所述签名数据的数字签名，将所述签名数据、所述数字签名以及第二认证信息发送给第二可信中心，所述第二认证信息为
使用与所述第二可信中心共享的第二共享密钥生成的所述签名数据和所述数字签名的认证信息；
[0052]
所述第二可信中心，用于分别使用每个第一可信中心对应的第二共享密钥对该第一可信中心发送的第二认证信息进行认证，如果各个第二认证信息均认证通过，将所述签名数据、各个所述数字签名以及第三认证信息发送给第二终端，所述第三认证信息为使用与所述第二终端共享的第三共享密钥生成的所述签名数据和各个所述数字签名的认证信息；
[0053]
所述第二终端，用于使用所述第三共享密钥对所述第三认证信息进行认证，如果所述第三认证信息认证通过，保留所述签名数据以及各个所述数字签名，将各个所述数字签名作为所述签名数据的数字签名。
[0054]
在一种可能的实现方式中，所述第一可信中心，具体用于：生成第四认证信息，所述第四认证信息为使用所述第一共享密钥生成的接收到的第一身份信息和接收到的签名数据的认证信息，如果所述第四认证信息与所述第一认证信息一致，则所述第一认证信息认证通过；
[0055]
所述第二可信中心，具体用于分别生成每个第一可信中心对应的第五认证信息，所述第五认证信息为使用该第一可信中心对应的第二共享密钥生成的接收到的签名数据和接收到的该第一可信中心的数字签名的认证信息，如果每个第一可信中心对应的第五认证信息与该第一可信中心发送的第二认证信息均相同，则各个第二认证信息均认证通过；
[0056]
所述第二终端，具体用于生成第六认证信息，所述第六认证信息为使用所述第三共享密钥生成的接收到的签名数据和接收到的各个所述数字签名的认证信息，如果所述第六认证信息与所述第三认证信息一致，则所述第三认证信息认证通过。
[0057]
在一种可能的实现方式中，所述系统还包括：
[0058]
签名密钥分发服务器，用于生成原始密钥数据，对所述原始密钥数据采用纠删码技术进行处理，生成签名密钥数据，将所述签名密钥数据分发给各个所述第一可信中心；所述第一可信中心中的本地签名密钥是从所述签名密钥分发服务器发送的签名密钥数据中获取的。
[0059]
在一种可能的实现方式中，所述签名密钥分发服务器，还用于对所述第一可信中心中的签名密钥数据进行恢复。
[0060]
在一种可能的实现方式中，所述系统还包括：
[0061]
第三终端，用于将所述签名数据以及各个所述数字签名分别发送给产生该数字签名的第一可信中心；
[0062]
接收到数字签名的第一可信中心根据所述签名数据以及接收到的数字签名对该数字签名进行验证，向所述第三终端发送验证结果；
[0063]
所述第三终端，还用于如果接收到各个所述数字签名均通过验证的验证结果，则确定所述签名数据的数字签名正确。
[0064]
在一种可能的实现方式中，所述第三终端，还用于如果接收到各个所述数字签名未均通过验证的验证结果，则将所述签名数据以及验证未通过的数字签名发送给仲裁服务器；
[0065]
所述仲裁服务器，用于判断所述验证未通过的数字签名对应的第一可信中心中的
本地签名密钥是否被更改，如果未更改，向所述第三终端发送所述验证未通过的数字签名通过验证的验证结果。
[0066]
一种数字签名装置，所述装置应用于第一可信中心，所述装置包括：
[0067]
第一接收单元，用于接收第一终端发送的签名请求，所述签名请求包括第一身份信息、签名数据以及第一认证信息，所述第一认证信息为使用与所述第一可信中心共享的第一共享密钥生成的所述第一身份信息和所述签名数据的认证信息；
[0068]
第一认证单元，用于使用所述第一共享密钥对所述第一认证信息进行认证；
[0069]
第一生成单元，用于如果所述第一认证单元的认证结果为认证通过，使用本地签名密钥生成所述签名数据的数字签名；
[0070]
第一发送单元，用于将所述签名数据、所述数字签名以及第二认证信息发送给第二可信中心，以使所述第二可信中心使用所述第一可信中心对应的第二共享密钥对所述第二认证信息进行认证，如果各个所述第一可信中心发送的第二认证信息均认证通过，将所述签名数据、各个所述第一可信中心发送的各个所述数字签名以及第三认证信息发送给第二终端；所述第二认证信息为所述第一可信中心使用与所述第二可信中心共享的第二共享密钥生成的所述签名数据和所述数字签名的认证信息；所述第三认证信息为所述第二可信中心使用与所述第二终端共享的第三共享密钥生成的所述签名数据和各个所述数字签名的认证信息；所述第二终端用于使用所述第三共享密钥对所述第三认证信息进行认证，如果所述第三认证信息认证通过，保留所述签名数据以及各个所述数字签名，将各个所述数字签名作为所述签名数据的数字签名。
[0071]
在一种可能的实现方式中，所述第一认证单元，具体用于生成第四认证信息，所述第四认证信息为使用所述第一共享密钥生成的接收到的第一身份信息和接收到的签名数据的认证信息，如果所述第四认证信息与所述第一认证信息一致，则所述第一认证信息认证通过。
[0072]
在一种可能的实现方式中，所述第一可信中心中的本地签名密钥是从签名密钥分发服务器发送的签名密钥数据中获取的，所述签名密钥分发服务器用于生成原始密钥数据，对所述原始密钥数据采用纠删码技术进行处理，生成签名密钥数据，将所述签名密钥数据分发给各个所述第一可信中心。
[0073]
在一种可能的实现方式中，所述签名密钥分发服务器还用于对所述第一可信中心中的签名密钥数据进行恢复。
[0074]
在一种可能的实现方式中，所述装置还包括：
[0075]
第二接收单元，用于接收第三终端发送的所述签名数据以及所述数字签名，根据所述签名数据以及所述数字签名对所述数字签名进行验证，向所述第三终端发送验证结果，以使所述第三终端如果接收到各个所述第一可信中心对应的数字签名均通过验证的验证结果，则确定所述签名数据的数字签名正确。
[0076]
在一种可能的实现方式中，所述第三终端还用于如果接收到各个所述数字签名未均通过验证的验证结果，则将所述签名数据以及验证未通过的数字签名发送给仲裁服务器；
[0077]
所述仲裁服务器，用于判断所述验证未通过的数字签名对应的第一可信中心中的本地签名密钥是否被更改，如果未更改，向所述第三终端发送所述验证未通过的数字签名
通过验证的验证结果。
[0078]
一种数字签名装置，所述装置应用于第二可信中心，所述装置包括：
[0079]
第三接收单元，用于接收各个第一可信中心发送的签名数据、数字签名以及第二认证信息；所述第一可信中心用于接收第一终端发送的签名请求，所述签名请求包括第一身份信息、签名数据以及第一认证信息，所述第一认证信息为所述第一终端使用与所述第一可信中心共享的第一共享密钥生成的所述第一身份信息和所述签名数据的认证信息；使用所述第一共享密钥对所述第一认证信息进行认证，如果所述第一认证信息认证通过，使用本地签名密钥生成所述签名数据的数字签名；将所述签名数据、所述数字签名以及第二认证信息发送给第二可信中心，所述第二认证信息为所述第一可信中心使用与所述第二可信中心共享的第二共享密钥生成的所述签名数据和所述数字签名的认证信息；
[0080]
第二认证单元，用于分别使用每个第一可信中心对应的第二共享密钥对该第一可信中心发送的第二认证信息进行认证；
[0081]
第二发送单元，用于如果所述第二认证单元的认证结果为各个第二认证信息均认证通过，将所述签名数据、各个所述数字签名以及第三认证信息发送给第二终端，以使所述第二终端使用第三共享密钥对所述第三认证信息进行认证，如果所述第三认证信息认证通过，保留所述签名数据以及各个所述数字签名，将各个所述数字签名作为所述签名数据的数字签名；所述第三认证信息为使用与所述第二终端共享的第三共享密钥生成的所述签名数据和各个所述数字签名的认证信息。
[0082]
在一种可能的实现方式中，所述第二认证单元，具体用于分别生成每个第一可信中心对应的第五认证信息，所述第五认证信息为使用该第一可信中心对应的第二共享密钥生成的接收到的签名数据和接收到的该第一可信中心的数字签名的认证信息，如果每个第一可信中心对应的第五认证信息与该第一可信中心发送的第二认证信息均相同，则各个第二认证信息均认证通过。
[0083]
在一种可能的实现方式中，所述第一可信中心中的本地签名密钥是从签名密钥分发服务器发送的签名密钥数据中获取的，所述签名密钥分发服务器用于生成原始密钥数据，对所述原始密钥数据采用纠删码技术进行处理，生成签名密钥数据，将所述签名密钥数据分发给各个所述第一可信中心。
[0084]
在一种可能的实现方式中，所述签名密钥分发服务器还用于对所述第一可信中心中的签名密钥数据进行恢复。
[0085]
由此可见，本申请实施例具有如下有益效果：
[0086]
本申请实施例第一终端向第一可信中心发送与第一可信中心对应的签名请求，第一可信中心使用与第一终端共享的第一共享密钥对签名请求中的第一认证信息进行认证，当认证通过时，使用本地签名密钥生成签名数据的数字签名，并将签名数据、数字签名以及第二认证信息发送给第二可信中心，由第二可信中心使用与每个第一可信中心共享的第二共享密钥对第二认证信息进行认证，如果每个第二认证信息均认证通过，则将签名数据、各个数字签名以及第三认证信息发送给第二终端，再由第二终端使用与第二可信中心共享的第三共享密钥对第三认证信息进行认证，如果第三认证信息认证通过，则各个数字签名作为签名数据的数字签名，可见，本申请实施例提供的数字签名方法是基于多可信中心，由多个可信中心进行信息的认证，降低了数字签名对单一可信中心安全性的依赖，同时提高了
数字签名的安全性。
附图说明
[0087]
图1为本申请实施例提供的一种生成数字签名系统结构图；
[0088]
图2为本申请实施例提供的一种数字签名方法信令交互图；
[0089]
图3为本申请实施例提供的一种验证数字签名信令交互图；
[0090]
图4为本申请实施例提供的一种生成签名密钥的流程图；
[0091]
图5为本申请实施例提供的示例性应用场景框架图；
[0092]
图6为本申请实施例提供的第一可信中心实现数字签名方法的流程图；
[0093]
图7为本申请实施例提供的第二可信中心实现数字签名方法的流程图；
[0094]
图8为本申请实施例提供的一种数字签名系统结构图；
[0095]
图9为本申请实施例提供的一种数字签名装置结构图；
[0096]
图10为本申请实施例提供的另一种数字签名装置结构图。
具体实施方式
[0097]
为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请实施例作进一步详细的说明。
[0098]
为便于理解本申请提供的技术方案，下面先对本申请的背景技术进行说明。
[0099]
发明人在对传统的对称密钥数字签名方法研究中发现，该数字签名方法是基于可信中心的签名方法，该可信中心分别与签名数据发送者和签名数据接收者之间共享对称密钥，也就是，可信中心既用于对签名数据发送者发送的签名数据进行数字签名，还可以根据签名数据接收者发送的认证请求对已进行数字签名的签名数据的完整性进行验证，当该可信中心被攻击时，导致数字签名系统的安全性无法保证。
[0100]
基于此，本申请实施例提供了一种数字签名方法，对于签名数据的发送者，即第一终端以及签名数据的接收者，即第二终端，分别与不同的可信中心通信，当需要对签名数据进行数字签名时，第一终端向自身对应的第一可信中心发送与第一可信中心对应的签名请求，然后由第一可信中心使用与第一终端共享的第一共享密钥对第一认证信息进行认证，当认证通过时，使用本地签名密钥生成签名数据的数字签名，并将签名数据、数字签名以及第二认证信息发送给第二可信中心，由第二可信中心使用与第一可信中心共享的第二共享密钥对第二认证信息进行认证，当认证通过时，将签名数据、数字签名以及第三认证信息发送给第二终端，最后由第二终端使用与第二可信中心共享的第三密钥对第三认证信息进行认证，当认证通过时，将数字签名作为该签名数据的数字签名。另外，当第一终端对应多个第一可信中心，第一终端向每个第一可信中心发送与该第一可信中心对应的签名请求，同时第二可信中心需要对每个第一可信中心发送的第二认证信息进行认证。可见，本申请实施例提供的数字签名方法是基于多可信中心，由多个可信中心进行认证，降低了数字签名对单一可信中心安全性的依赖，同时提高了数字签名的安全性。
[0101]
参见图1，该图为本申请实施例提供的数字签名系统，该系统可以包括：签名数据的发送者、第一可信中心、第二可信中心、签名数据的接收者；在一些可能的实现方式中，该系统还可以包括：签名密钥分发服务器、签名验证者以及仲裁服务器。
[0102]
其中，签名数据的发送者、签名数据的接收者、签名验证者可以分别为本申请实施例中的第一终端、第二终端和第三终端。
[0103]
签名密钥分发服务器，用于生成密钥数据，并将生成的密钥数据分发给第一可信中心。
[0104]
签名数据的发送者，向第一可信中心进行身份认证注册，获得与注册第一可信中心的共享密钥，从而使用共享密钥加密向第一可信中心发送的签名请求。该签名数据的发送者可以是网络终端，也可以是使用网络终端的设备。
[0105]
第一可信中心，用于为签名数据的发送者提供共享密钥，并且对签名数据的发送者发送的签名请求中的第一认证信息进行认证，当认证通过时，生成签名数据的数字签名，并将签名数据以及数字签名以及第二认证信息发送给第二可信中心。
[0106]
第二可信中心，用于为签名数据的接收者提供共享密钥，并且对第二认证信息进行认证，当认证通过时，生成第三认证信息，并将签名数据、数字签名以及第三认证信息发送给签名数据的接收者。
[0107]
签名数据的接收者，向第二可信中心进行身份认证注册，获取注册第二可信中心的共享密钥，并利用共享密钥对第三认证信息进行认证，该签名数据的接收者可以为网络终端，也可以是使用网络终端的设备。
[0108]
签名验证者，可以是签名数据的接收者，也可为其他拥有数字签名的需要验证数字签名合法性的设备，当第三认证信息认证通过时，将签名数据和数字签名发送给生成数字签名的第一可信中心，并根据每个第一可信中心的验证结果判断数字签名的合法性，如果多个第一可信中心的验证结果不一致时，则可以向仲裁服务器申请签名仲裁。签名验证者将验证失败的签名数据和数字签名发送给仲裁服务器。
[0109]
仲裁服务器，用于调用验证失败的数字签名所使用的签名密钥相关数据，核对所使用验证数字签名的签名密钥是否被更改，如果被更改，则判断签名验证者接收的验证结果是正确的；如果未被更改，则判断签名验证者接收的验证结果是错误的。
[0110]
本领域技术人员可以理解，图1所示的框架示意图仅是本申请的实施方式可以在其中得以实现的一个示例。本申请实施方式的适用范围不受到该框架任何方面的限制。
[0111]
需要注意的是，本申请实施例中的签名数据的发送者以及签名数据的接受者可以是现有的、正在研发的或将来研发的、能够通过任何形式的有线和/或无线连接(例如，wi-fi、lan、蜂窝、同轴电缆等)实现与第一可信中心、第二可信中心交互的任何用户设备，包括但不限于：现有的、正在研发的或将来研发的智能手机、非智能手机、平板电脑、膝上型个人计算机、桌面型个人计算机、小型计算机、中型计算机、大型计算机等。还需要注意的是，本申请实施例中签名密钥分发服务器可以是现有的、正在研发的或将来研发的、能够向第一可信中心以及第二可信中心提供密钥数据的设备的一个示例，本申请的实施方式在此方面不受任何限制。
[0112]
通过上述描述可知，实现数字签名时，需要涉及到签名密钥的分发以及签名请求等过程，为便于理解本申请实施例提供的数字签名生成方法，将分别对签名密钥的生成方法、数字签名以及数字签名认证过程进行说明。
[0113]
一、签名密钥的创建
[0114]
签名密钥分发服务器生成原始密钥数据；然后对原始密钥数据采用纠删码技术进
行处理，生成签名密钥数据；将签名密钥数据分发给每个第一可信中心。第一可信中心将接收到的签名密钥数据划分为签名密钥序列，并为每个签名密钥进行编码，从而可以得到多个本地签名密钥。
[0115]
其中，纠删码技术是一种数据保护方法，可以将数据分割成多个片段，并把冗余数据块扩展、编码，关于利用纠删码技术生成签名密钥数据的方法将在后续实施例进行说明。
[0116]
另外，由于纠删码技术的特性，当某些第一可信中心的签名密钥数据被篡改或丢失时，签名密钥分发服务器可以对这些第一可信中心中的签名密钥数据进行恢复，从而保证第一可信中心的签名密钥数据的准确性。
[0117]
而且，当第一可信中心的签名密钥数据库中签名密钥数据不足时，第一可信中心可以向签名密钥分发服务器发送请求，以使得签名密钥服务器根据第一可信中心发送的请求，向第一可信中心补充新的签名密钥数据。
[0118]
当第一可信中心均分发到签名密钥数据时，可以根据第一终端发送的签名请求对签名数据进行数字签名，下面将结合附图对数字签名方法进行说明。
[0119]
二、数字签名的生成
[0120]
参见图2，该图为本申请实施例提供的一种数字签名信令交互图，如图2所示，该方法可以包括：
[0121]
s201：第一终端向第一可信中心发送与该第一可信中心对应的签名请求。
[0122]
本实施例中，当第一终端需要获取签名数据的数字签名时，向第一可信中心发送与该第一可信中心对应的签名请求，其中，签名请求包括第一身份信息、签名数据以及第一认证信息，该第一认证信息为第一终端使用与第一可信中心共享的第一共享密钥生成的第一身份信息和签名数据的认证信息，也就是，使用第一共享密钥对第一身份信息以及签名数据进行加密，生成第一认证信息。其中，第一身份信息可以包括第一终端的身份标识、第二终端的身份标识以及第二可信中心的身份标识。
[0123]
在具体实现时，可以利用第一共享密钥计算第一身份信息以及签名数据的哈希运算消息认证码hmac，将该认证码作为第一认证信息。例如，签名数据为p、第一终端的身份标识为a、第二终端的身份标识为b，第二可信中心的身份标识为id2，第一共享密钥为k
a
，则利用k
a
计算第一终端的身份标识a、第二终端的身份标识b以及第二可信中心id2以及签名数据p的哈希运算消息认证码hmac(a、b、id2、p；k
a
)。
[0124]
在实际应用中，在第一终端发起签名请求前，第二终端可以给第一终端发送第二终端注册的第二可信中心的身份标识，或者，第一终端所注册的第一可信中心通过查询获得第二终端所注册的第二可信中心的身份标识。当第一终端获取到第二可信中心的身份标识时，可以根据第二可信中心的身份标识将签名请求中的签名数据以及由第一可信中心生成的数字签名发送给第二可信中心。
[0125]
在具体实现时，第一终端可以向多个第一可信中心进行身份认证注册，进而向其中多个第一可信中心发送与该第一可信中心对应的签名请求。可以理解的是，由于每个第一可信中心与第一终端之间的共享密钥不同，因此，生成的第一认证信息是不同的，因此，针对每个第一可信中心，第一终端需要向第一可信中心发送对应的签名请求。
[0126]
另外，为实现一次一密，签名请求中还可以包括第一共享密钥的序号ctr，当第一可信中心接收到该签名请求时，可以根据序号，验证此次签名请求所使用的第一共享密钥
是否为已使用的密钥。
[0127]
s202：第一可信中心使用第一共享密钥对第一认证信息进行认证，如果第一认证信息认证通过，使用本地签名密钥生成签名数据的数字签名，将签名数据、数字签名以及第二认证信息发送给第二可信中心。
[0128]
本实施例中，当第一可信中心接收到第一终端发送的签名请求时，使用第一共享密钥对签名请求中的第一认证信息进行认证，如果认证通过，则从签名密钥库中获取本地签名密钥，使用该本地签名密钥生成签名数据的数字签名，并利用第一可信中心与第二可信中心共享的第二共享密钥对签名数据以及数字签名进行加密，生成第二认证信息，然后，将签名数据、数字签名以及第二认证信息发送给第二可信中心；如果认证未通过，则终止签名过程。
[0129]
在实际应用中，当签名请求中包括第一共享密钥的序号ctr1时，第一可信中心首先验证与第一终端共享的密钥中序号为ctr1的共享密钥是否已经使用，如果该第一共享密钥已使用，则终止签名过程；如果该第一共享密钥未使用，则对第一认证信息进行认证。
[0130]
在本申请实施例一种可能的实现方式中，提供了一种认证第一认证信息的实现方式，具体可以为，第一可信中心生成第四认证信息，该第四认证信息为第一可信中心使用第一共享密钥生成的接收到的第一身份信息和接收到的签名数据的认证信息；如果第四认证信息与第一认证信息一致，则第一认证信息认证通过；如果不一致，则第一认证信息认证未通过。
[0131]
在具体实现时，第一可信中心利用第一共享密钥计算第一身份认证信息以及签名数据的哈希运算消息认证码hmac
’
，即第四认证信息，然后，将hmac
’
与第一终端生成的hmac进行比较，如果二者一致，则第一认证信息认证通过；如果二者不一致，则第一认证信息认证未通过。
[0132]
当第一认证信息认证通过时，第一可信中心使用签名密钥库中未使用的本地签名密钥计算第一终端身份标识与签名数据的哈希运算消息认证码，然后将第一可信中心的身份标识、本地签名密钥的序号以及哈希运算消息认证码进行连接运算，将连接后的值作为签名数据的数字签名ds；然后，第一可信中心使用与第二可信中心共享的第二共享密钥k2计算第一终端身份标识a、第二终端身份标识b、签名数据p以及数字签名ds的哈希运算消息认证码hmac(a、b、p、ds；k2)，然后，将k2的序号ctr2、a、b、p、ds以及hmac(a、b、p、ds；k2)发送给第二可信中心。
[0133]
s203：第二可信中心分别使用每个第一可信中心对应的第二共享密钥对该第一可信中心发送的第二认证信息进行认证，如果各个第二认证信息均认证通过，将签名数据、各个数字签名以及第三认证信息发送给第二终端。
[0134]
本实施例中，当第二可信中心接收到多个第一可信中心发送的信息时，对每个第一可信中心发送的第二认证信息进行认证，具体为，第二可信中心使用与每个第一可信中心对应的第二共享密钥对该第一可信中心发送的第二认证信息进行认证，如果认证通过，则第二可信中心使用与第二终端共享的第三共享密钥对签名数据以及数字签名进行加密。生成第三认证信息，然后，将签名数据、数字签名以及第三认证信息发送给第二终端；如果认证未通过，则终止签名过程。
[0135]
在实际应用中，当第一可信中心发送的信息中包括第二共享密钥的序号ctr2时，
第二可信中心可以先验证与第一可信中心共享的密钥中序号为ctr2的共享密钥k2是否已经使用，如果该第二共享密钥已使用，则终止签名过程；如果该第二共享密钥未使用，则对第二认证信息进行认证。
[0136]
在本申请实施例一种可能的实现方式中，提供了一种认证第二认证信息的实现方式，具体可以为，第二可信中心分别生成每个第一可信中心对应的第五认证信息，该第五认证信息为第二可信中心使用该第一可信中心对应的第二共享密钥生成的接收的签名数据和接收到的该第一可信中心的数字签名的认证信息，如果每个第一可信中心对应的第五认证信息与该第一可信中心发送的第二认证信息均相同，则各个第二认证信息均通过；如果任意一个第一可信中心的第二认证信息未认证通过，则终止签名过程。
[0137]
在具体实现时，第二可信中心利用第二共享密钥k2计算第一终端身份标识a、第二终端身份标识b、签名数据p以及数字签名ds的哈希运算消息认证码hmac
’
(a、b、p、ds；k2)，即第五认证信息，然后将hmac
’
(a、b、p、ds；k2)与hmac(a、b、p、ds；k2)进行比较，如果二者一致，则第二认证信息通过；如果二者不一致，则第二认证信息认证未通过。
[0138]
当第二认证信息认证通过时，第二可信中心使用与第二终端共享的第三共享密钥k3计算第一终端身份标识a、签名数据p以及数字签名ds的哈希运算消息认证码hmac(a、p、ds；k3)，然后，将k3的序号ctr3、a、p、ds以及hmac(a、p、ds；k3)发送给第二终端。
[0139]
s204：第二终端使用第三共享密钥对第三认证信息进行认证，如果第三认证信息认证通过，保留签名数据以及各个数字签名，将各个数字签名作为签名数据的数字签名。
[0140]
本实施例中，当第二终端接收到第二可信中心发送的信息时，对该信息中的第三认证信息进行认证，具体为，第二终端使用第三共享密钥对第三认证信息进行认证，如果认证通过，则保留签名数据以及各个数字签名，将各个数字签名作为该签名数据的数字签名；如果认证未通过，则终止签名过程。
[0141]
在实际应用中，当第二可信中心发送的信息中包括第三共享密钥的序号ctr3时，第二终端可以先验证与第二可信中心共享的密钥中序号为ctr3的共享密钥是否已经使用，如果该第三共享密钥已使用，则判断接收到的数字签名无效，终止签名过程；如果该第三共享密钥未使用，则对第三认证信息进行认证。
[0142]
在本申请实施例一种可能的实现方式中，提供了一种认证第三认证信息的实现方式，具体可以为，第二终端生成第六认证信息，该第六认证信息为使用第三共享密钥生成的接收到的签名数据和接收到的各个数字签名的认证信息，如果第六认证信息与第三认证信息一致，则第三认证信息认证通过；如果第六认证信息与第三认证信息不一致，则第三认证信息认证未通过。
[0143]
在具体实现时，第二终端利用第三共享密钥k3计算第一终端身份标识a、签名数据p以及数字签名ds的哈希运算消息认证码hmac
’
(a、p、ds；k3)，即第六认证信息，然后将hmac
’
(a、p、ds；k3)与hmac(a、p、ds；k3)进行比较，如果二者一致，则第三认证信息通过；如果二者不一致，则第三认证信息认证未通过。
[0144]
本实施例中，当第三认证信息认证通过后，第二终端将保留接收的签名数据以及数字签名，并将所有的数字签名作为该签名数据的数字签名，从而实现生成签名数据的数字签名。
[0145]
通过本实施例，对于签名数据的发送者，即第一终端以及签名数据的接收者，即第
二终端，分别与不同的可信中心通信，当需要对签名数据进行数字签名时，第一终端向自身对应的第一可信中心发送与第一可信中心对应的签名请求，然后由第一可信中心使用与第一终端共享的第一共享密钥对第一认证信息进行认证，当认证通过时，使用本地签名密钥生成签名数据的数字签名，并将签名数据、数字签名以及第二认证信息发送给第二可信中心，由第二可信中心使用与第一可信中心共享的第二共享密钥对第二认证信息进行认证，当认证通过时，将签名数据、数字签名以及第三认证信息发送给第二终端，最后由第二终端使用与第二可信中心共享的第三密钥对第三认证信息进行认证，当认证通过时，将数字签名作为该签名数据的数字签名。另外，当第一终端对应多个第一可信中心，第一终端向每个第一可信中心发送与该第一可信中心对应的签名请求，同时第二可信中心需要对每个第一可信中心发送的第二认证信息进行认证，可见，本申请实施例提供的数字签名方法是基于多可信中心，由多个可信中心进行认证，降低了数字签名对单一可信中心安全性的依赖，同时提高了数字签名的安全性。
[0146]
三、数字签名验证
[0147]
在实际应用中，为防止在信息传输的过程中，数字签名被恶意篡改，还可以对数字签名进行验证，实现数字签名的抗抵赖性和鉴别假冒数字签名。基于此，本申请实施例提供一种验证数字签名的方法，下面将结合附图对该方法进行说明。
[0148]
参见图3，该图为本申请实施例提供的一种验证数字签名方法的信令交互图，如图3所示，该方法可以包括：
[0149]
s301：第三终端将签名数据以及各个数字签名分别发送给产生该数字签名的第一可信中心。
[0150]
本实施例中，当第二终端确定了签名数据的数字签名时，可以将签名数据以及各个数字签名发送给第三终端，由第三终端将签名数据以及各个数字签名分别发送给产生该数字签名的第一可信中心，也可以由第二终端直接将签名数据以及各个数字签名发送给产生该数字签名的第一可信中心。也就是说，第三终端可以为第二终端，也可以为其他终端。
[0151]
在实际应用中，当第一终端对应多个第一可信中心时，每个第一可信中心均对签名数据进行签名，生成该签名数据的数字签名，由于每个第一可信中心在生成数字签名时所使用的本地签名密钥不同，从而生成的数字签名也不同，因此，在对数字签名进行验证时，第三终端将数字签名发送给生成该数字签名的第一可信中心，由该第一可信中心进行验证。
[0152]
s302：接收到数字签名的第一可信中心根据签名数据以及接收到的数字签名对该数字签名进行验证，向第三终端发送验证结果。
[0153]
本实施例中，第一可信中心根据接收的签名数据以及数字签名对该数字签名进行验证，并向第三终端发送验证结果。
[0154]
在具体实现时，第一可信中心可以采用两种方式对数字签名进行验证，一种是，第一可信中心根据接收的签名数据从数据库中查找与该签名数据对应的数字签名，然后比较查找的数字签名与第三终端发送的数字签名是否一致，如果二者一致，则验证通过；如果二者不一致，则验证未通过。另一种是，第一可信中心根据签名数据查找到生成数字签名时所使用的本地签名密钥，然后利用该本地签名密钥生成新的数字签名，然后，比较新的数字签名与第三终端发送的数字签名是否一致，如果一致，则验证通过；如果二者不一致，则验证
未通过。
[0155]
当第一可信中心通过上述任意一种方式对数字签名进行验证后，将验证结果发送给第三终端。
[0156]
s303：第三终端如果接收到各个数字签名均通过验证的验证结果，则确定签名数据的数字签名正确。
[0157]
本实施例中，当每个数字签名的验证结果均为验证通过时，表明数字签名未被篡改，则第三终端确定签名数据的数字签名正确；如果存在一个数字签名的验证结果为验证未通过，则确定签名数据的数字签名无效。
[0158]
在实际应用中，对于数字签名的验证可以分为两种不同的验证方式，一种是实时验证，另一种是非实时验证，实时验证是指第二终端接收到签名数据以及数字签名时，即刻对该数字签名发起验证请求，如果第二终端最终认定数字签名无效，则第二终端可以重新请求第一终端发送签名；非实时验证是指由其他终端发起数字签名验证请求，或者第二终端未及时对数字签名发起验证请求。如果非实时验证时，验证结果为不一致时，第三终端对此签名验证结果有异议，可以向仲裁服务器申请仲裁，由仲裁服务器确定数字签名的正确性。具体可以为，第三终端还用于如果接收到各个所述数字签名未均通过验证的验证结果，则将签名数据以及验证未通过的数字签名发送给仲裁服务器；仲裁服务器，用于判断验证未通过的数字签名对应的第一可信中心中的本地签名密钥是否被更改，如果未更改，向第三终端发送验证未通过的数字签名通过验证的验证结果。
[0159]
在具体实现时，仲裁服务器可以通过以下方式进行验证，一种是，当第三终端对签名验证结果有异议时，则将签名数据及其数字签名以及数字签名验证失败的一个第一可信中心的标识发送给仲裁服务器；仲裁服务器根据第一可信中心的标识，请求签名密钥分发服务器判断此可信中心用于本次数字签名的签名密钥是否被更改。签名密钥分发服务器将判断结果发送给仲裁服务器。如果该签名密钥未被更改，则仲裁服务器重新使用此签名密钥验证数字签名，根据验证结果向第三终端发送所述数字签名验证结果是否正确的信息；否则向第三终端告知原来第一可信中心的验证结果正确。
[0160]
另一种是，当第三终端对签名验证结果有异议时，则将签名数据及其数字签名以及数字签名验证失败的一个第一可信中心的标识发送给仲裁服务器，仲裁服务器提取生成该第一可信中心用于本次数字签名的签名密钥，然后请求签名密钥分发服务器验证该签名密钥是否被篡改，签名密钥分发服务器将验证结果返回给仲裁服务器。如果该签名密钥未被篡改，仲裁服务器重新验证此数字签名，根据验证结果向第三终端发送该数字签名验证是否正确的确认信息；否则向第三终端告知原来第一可信中心的验证结果正确。
[0161]
仲裁服务器请求签名密钥分发服务器调用验证失败的数字签名对应的第一可信中心的本地签名密钥对应的用于本次签名的密钥数据，签名密钥分发服务器利用纠删码技术对该密钥数据进行恢复，得到该密钥数据对应的元数据，然后验证元数据的哈希码是否与签名密钥分发服务器保存的哈希码一致，如果一致，则利用该元数据生成密钥数据，利用该密钥数据验证进行数字签名验证时所使用的本地签名密钥是否被更改，从而可以防止签名密钥泄露，以及由于泄露而产生的假冒签名。
[0162]
可见，借助于仲裁服务器，通过利用纠删码技术可以对数字签名验证的结果进行仲裁，在一定程度上防止了攻击者通过控制部分参与签名的第一可信中心进行抵赖签名的
攻击，同时也防止了签名验证者通过窃取部分参与签名的第一可信中心的签名密钥进行假冒签名的攻击。
[0163]
通过上述实施例可知，签名密钥分发服务器可以利用纠删码技术生成签名密钥数据，且可以利用纠删码技术对签名密钥数据进行验证。为便于理解纠删码技术在本发明中的应用，下面将详细介绍如何利用纠删码技术生成签名密钥数据以及验证签名密钥数据是否被更改。
[0164]
在上述实施例中提出签名密钥分发服务器在生成签名密钥数据时使用了纠删码技术，本实施例将结合具体的应用场景说明。
[0165]
里所码(reed solomon codes，rs)，又称rs编码，是一种前向纠错能力很强的多进制编码，它不仅能纠正突发错误还可以纠正随机错误。一个(m,n)的纠删码可表示为：y＝x*g，其中，x＝(x1,x2,
…
,xm)是元数据包向量，y＝(y1,y2,
…
,ym)是编码后得到的数据包，g
m*n
为线性纠删码的生成矩阵。
[0166]
范德蒙码是rs类纠删码的一类，其相应的范德蒙矩阵是：
[0167][0168]
其中，g的任意k列组成的子方阵g
’
都是非奇异的，因此得到的矩阵满足纠删码生成矩阵的特性。
[0169]
由于本实施例中对纠删码维度要求和运算速度要求不高，因此，可以选择译码可靠性较高的范德蒙码用于签名密钥数据处理及实现数据纠删码恢复。
[0170]
在本实施例中，假设用于数字签名服务的第一可信中心的数量为n，选择编码数据的维度为n，满足n<n，元数据的维度m满足：n>m≥[n/2]，比如n＝7，可以选择n＝5，m＝3。
[0171]
签名密钥分发服务器使用纠删码技术进行密钥分发的流程，如图4所示，签名密钥分发服务器首先使用真随机数生成器生成m组元数据，每组的数据量相等，计算m组元数据的哈希码，然后使用m行n列的范德蒙矩阵编码生成n维编码数据，并给本次生成的编码数据一个唯一的编码编号，选择n个第一可信中心中签名密钥数据较少的n个第一可信中心，将生成的n维编码数据分发给n个第一可信中心作为签名密钥数据，每一维编码数据发给其中一个第一可信中心，每个第一可信中心记录本次分发的签名密钥数据所属的编码编号，签名密钥分发服务器分发完毕后删除所分发的编码数据，记录本次分发的签名密钥数据的编码编号、获得签名密钥数据的第一可信中心的标号和m组元数据的哈希码。
[0172]
四、场景实施例
[0173]
为了便于理解本申请实施例的具体实现，下面将以两个第一可信中心为例进行说明，在本实施例中，第一终端为alice，第二终端为bob，alice向两个第一可信中心ca注册，bob向一个第二可信中心注册，在执行下述实施例时，alice和bob均已向对应的ca进行了注册，并获得对应的ca的共享密钥数据，该共享密钥数据按照预定的一次加密所需的密钥长
度进行共享密钥的划分并编号，在数字签名过程中签名相关数据均采用一次一密的方式加密。
[0174]
另外，还需说明的是，本实施例中将采用hmac-md5算法作为数字签名算法，用于计算签名数据的密钥相关的哈希运算消息认证码，hmac-md5算法输出的哈希值为128bit，密钥长度小于128bit会降低算法的安全强度，大于这个值对于安全强度的提高没有太大的作用，由于本实施例采用一次一密签名，考虑到密钥消耗以及安全强度的问题，每次签名采用136bit的密钥长度。
[0175]
可以理解的是，在实际应用中还可以采用其他的算法作为数字签名算法，本实施例在此不进行限定。
[0176]
参见图5，该图为本申请实施例提供的一种数字签名方法的信令交互图，如图5所示，alice注册的ca为ca1和ca2，bob注册的ca为ca3，可包括：
[0177]
s501：alice使用与ca1的共享密钥数据中未使用的共享密钥k
a1
计算alice的身份标识a、bob的身份标识b、ca3的身份标识id
ca3
以及签名数据p的密钥相关的哈希运算消息认证码hmac(a、b、id
ca3
、p；k
a1
)，然后将共享密钥k
a1
的序号ctr
a1
、a、b、id
ca3
、p以及hmac(a、b、id
ca3
、p；k
a1
)发送给ca1。
[0178]
s502：alice使用与ca2的共享密钥数据中未使用的共享密钥k
a2
计算alice的身份标识a、bob的身份标识b、ca3的身份标识id
ca3
以及签名数据p的密钥相关的哈希运算消息认证码hmac(a、b、id
ca3
、p；k
a2
)，然后将共享密钥k
a2
的序号ctr
a2
、a、b、id
ca3
、p以及hmac(a、b、id
ca3
、p；k
a2
)发送给ca2。
[0179]
s503：ca1接收到ctr
a1
、a、b、id
ca3
、p以及hmac(a、b、id
ca3
、p；k
a1
)时，首先验证与alice的共享密钥数据中序号为ctr
a1
的共享密钥是否已使用，如果已使用，则终止签名过程；否则，ca1读取序号ctr
a1
对应的共享密钥k
a1
，使用k
a1
验证hmac(a、b、id
ca3
、p；k
a1
)的正确性，如果不正确，则终止认证过程；否则，将序号为ctr
a1
的共享密钥k
a1
标记为已使用，并使用签名密钥库中未使用的签名密钥k
ca1
计算a与p的哈希运算消息认证码hmac(a、p；k
ca1
)，然后将ca1的身份标识id
ca1
、k
ca1
的序号ctr
ca1
与hmac(a、p；k
ca1
)进行连接运算，得到连接值id
ca1
||ctr
ca1
||hmac(a、p；k
ca1
)，将该连接值作为签名数据p的数字签名ds1，即ds1＝id
ca1
||ctr
ca1
||hmac(a、p；k
ca1
)；ca1使用与ca3的共享密钥数据中未使用的共享密钥k1计算a、b、p与ds1的密钥相关的哈希运算消息认证码hmac(a、b、ds1、p；k1)；将k1的序号ctr1、a、b、p、ds1以及hmac(a、b、ds1、p；k1)发送给ca3。
[0180]
s504：ca2接收到ctr
a2
、a、b、id
ca3
、p以及hmac(a、b、id
ca3
、p；k
a2
)时，首先验证与alice的共享密钥数据中序号为ctr
a2
的共享密钥是否已使用，如果已使用，则终止签名过程；否则，ca2读取序号ctr
a2
对应的共享密钥k
a2
，使用k
a2
验证hmac(a、b、id
ca3
、p；k
a2
)的正确性，如果不正确，则终止认证过程；否则，将序号为ctr
a2
的共享密钥k
a2
标记为已使用，并使用签名密钥库中未使用的签名密钥k
ca2
计算a与p的哈希运算消息认证码hmac(a、p；k
ca2
)，然后将ca2的身份标识id
ca2
、k
ca2
的序号ctr
ca2
与hmac(a、p；k
ca2
)进行连接运算，得到连接值id
ca2
||ctr
ca2
||hmac(a、p；k
ca2
)，将该连接值作为签名数据p的数字签名ds2，即ds2＝id
ca2
||ctr
ca2
||hmac(a、p；k
ca2
)；ca2使用与ca3的共享密钥数据中未使用的共享密钥k2计算a、b、p与ds2的密钥相关的哈希运算消息认证码hmac(a、b、ds2、p；k2)；将k2的序号ctr2、a、b、p、ds2以及hmac(a、b、ds2、p；k2)发送给ca3。
[0181]
s505：ca3接收到ca1发送的ctr1、a、b、p、ds1以及hmac(a、b、ds1、p；k1)和ca2发送的ctr2、a、b、p、ds2以及hmac(a、b、ds2、p；k2)，ca3分别使用k1和k2验证上述数据的合法性，如果任意一组数据验证失败，则签名过程终止，签名失败；如果两组数据均合法，则ca3使用与bob之间未使用的k
b
计算a、p、ds1||ds2的密钥相关的哈希运算消息认证码hmac(a、p、ds1||ds2；k
b
)，然后将共享密钥k
b
的序号ctr
b
、a、p、ds1||ds2以及hmac(a、p、ds1||ds2；k
b
)发送给bob。
[0182]
s506：bob接收到ctr
b
、a、p、ds1||ds2以及hmac(a、p、ds1||ds2；k
b
)，首先判断与ca3共享密钥数据中序号为ctr
b
的共享密钥是否已使用，如果已使用，则所接收到的数字签名无效；否则，使用序号为ctr
b
的共享密钥k
b
验证hmac(a、p、ds1||ds2；k
b
)的正确性，如果正确，则确定所收到的数字签名ds1||ds2有效，将共享密钥k
b
标记为已使用；否则所接收到的数字签名ds1||ds2无效。
[0183]
需要说明的是，本实施例仅作为示例性实施例进行说明，在实际应用中可以使用更多的第一可信中心同时进行签名以提高签名的安全性。
[0184]
为进一步说明本申请实施例的执行过程，下面结合附图分开说明第一可信中心以及第二可信中心所执行的操作。
[0185]
参见图6，该图为本申请实施例提供的第一可信中心实现数字签名的方法流程图，如图6所示，该方法可以包括：
[0186]
s601：接收第一终端发送的签名请求。
[0187]
本实施例中，签名请求包括第一身份信息、签名数据以及第一认证信息，第一认证信息为使用与第一可信中心共享的第一共享密钥生成的第一身份信息和签名数据的认证信息。
[0188]
s602：使用第一共享密钥对第一认证信息进行认证，如果第一认证信息认证通过，使用本地签名密钥生成签名数据的数字签名。
[0189]
本实施例中，使用第一共享密钥对第一认证信息进行认证，包括：生成第四认证信息，该第四认证信息为使用第一共享密钥生成的接收到的第一身份信息和接收到的签名数据的认证信息，如果第四认证信息与第一认证信息一致，则第一认证信息认证通过。
[0190]
另外，第一可信中心中的本地签名密钥是从签名密钥分发服务器发送的签名密钥数据中获取的，签名密钥分发服务器用于生成原始密钥数据，并对原始密钥数据采用纠删码技术进行处理，生成签名密钥数据，将签名密钥数据分发给各个第一可信中心。在具体实现时，签名密钥分发服务器还用于对第一可信中心中的签名密钥数据进行恢复。
[0191]
s603：将签名数据、数字签名以及第二认证信息发送给第二可信中心。
[0192]
本实施例中，第一可信中心将签名数据、数字签名以及第二认证信息发送给第二可信中心，以使第二可信中心使用第一可信中心对应的第二共享密钥对第二认证信息进行认证，如果各个第一可信中心发送的第二认证信息均认证通过，将签名数据、各个第一可信中心发送的各个数字签名以及第三认证信息发送给第二终端；第二认证信息为第一可信中心使用与第二可信中心共享的第二共享密钥生成的签名数据和数字签名的认证信息；第三认证信息为第二可信中心使用与第二终端共享的第三共享密钥生成的签名数据和各个数字签名的认证信息；第二终端用于使用第三共享密钥对第三认证信息进行认证，如果第三认证信息认证通过，保留签名数据以及各个数字签名，将各个数字签名作为签名数据的数
字签名。
[0193]
其中，第二可信中心使用第一可信中心对应的第二共享密钥对第二认证信息进行认证，包括：第二可信中心分别生成每个第一可信中心对应的第五认证信息，第五认证信息为使用该第一可信中心对应的第二共享密钥生成的接收到的签名数据和接收到的该第一可信中心的数字签名的认证信息，如果每个第一可信中心对应的第五认证信息与该第一可信中心发送的第二认证信息均相同，则各个第二认证信息均认证通过。
[0194]
第二终端使用第三共享密钥对第三认证信息进行认证，包括：第二终端生成第六认证信息，第六认证信息为使用第三共享密钥生成的接收到的签名数据和接收到的各个数字签名的认证信息，如果第六认证信息与第三认证信息一致，则第三认证信息认证通过。
[0195]
在本申请一种可能的实现方式中，第一可信中心还可以接收第三终端发送的签名数据以及数字签名，根据签名数据以及数字签名对数字签名进行验证，向第三终端发送验证结果，以使第三终端如果接收到各个第一可信中心对应的数字签名均通过验证的验证结果，则确定签名数据的数字签名正确。
[0196]
在本申请一种可能的实现方式中，第三终端还用于如果接收到各个数字签名未均通过验证的验证结果，则将签名数据以及验证未通过的数字签名发送给仲裁服务器。
[0197]
仲裁服务器，用于判断验证未通过的数字签名对应的第一可信中心中的本地签名密钥是否被更改，如果未更改，向第三终端发送验证未通过的数字签名通过验证的验证结果。
[0198]
通过本实施例，对于签名数据的发送者，即第一终端以及签名数据的接收者，即第二终端，分别与不同的可信中心通信，当需要对签名数据进行数字签名时，第一终端向自身对应的第一可信中心发送与第一可信中心对应的签名请求，然后由第一可信中心使用与第一终端共享的第一共享密钥对第一认证信息进行认证，当认证通过时，使用本地签名密钥生成签名数据的数字签名，并将签名数据、数字签名以及第二认证信息发送给第二可信中心，由第二可信中心使用与第一可信中心共享的第二共享密钥对第二认证信息进行认证，当认证通过时，将签名数据、数字签名以及第三认证信息发送给第二终端，最后由第二终端使用与第二可信中心共享的第三密钥对第三认证信息进行认证，当认证通过时，将数字签名作为该签名数据的数字签名。另外，当第一终端对应多个第一可信中心，第一终端向每个第一可信中心发送与该第一可信中心对应的签名请求，同时第二可信中心需要对每个第一可信中心发送的第二认证信息进行认证，可见，本申请实施例提供的数字签名方法是基于多可信中心，由多个可信中心进行认证，降低了数字签名对单一可信中心安全性的依赖，同时提高了数字签名的安全性。
[0199]
参见图7，该图为本申请实施例提供的第二可信中心进行数字签名所执行的步骤，具体可以包括：
[0200]
s701：接收各个第一可信中心发送的签名数据、数字签名以及第二认证信息。
[0201]
本实施例中，所述第一可信中心用于接收第一终端发送的签名请求，签名请求包括第一身份信息、签名数据以及第一认证信息，第一认证信息为第一终端使用与第一可信中心共享的第一共享密钥生成的第一身份信息和签名数据的认证信息；使用第一共享密钥对第一认证信息进行认证，如果第一认证信息认证通过，使用本地签名密钥生成签名数据的数字签名；将签名数据、数字签名以及第二认证信息发送给第二可信中心，第二认证信息
为第一可信中心使用与第二可信中心共享的第二共享密钥生成的签名数据和数字签名的认证信息。
[0202]
其中，第一可信中心中的本地签名密钥是从签名密钥分发服务器发送的签名密钥数据中获取的，签名密钥分发服务器用于生成原始密钥数据，对原始密钥数据采用纠删码技术进行处理，生成签名密钥数据，将签名密钥数据分发给各个第一可信中心。
[0203]
在具体实现时，签名密钥分发服务器还用于对第一可信中心中的签名密钥数据进行恢复。
[0204]
s702：分别使用每个第一可信中心对应的第二共享密钥对该第一可信中心发送的第二认证信息进行认证。
[0205]
本实施例中，第二可信中心分别使用每个第一可信中心对应的第二共享密钥对该第一可信中心发送的第二认证信息进行认证，包括：分别生成每个第一可信中心对应的第五认证信息，第五认证信息为使用该第一可信中心对应的第二共享密钥生成的接收到的签名数据和接收到的该第一可信中心的数字签名的认证信息，如果每个第一可信中心对应的第五认证信息与该第一可信中心发送的第二认证信息均相同，则各个第二认证信息均认证通过。
[0206]
s703：如果各个第二认证信息均认证通过，将签名数据、各个数字签名以及第三认证信息发送给第二终端。
[0207]
本实施例中，第二可信中心将签名数据、各个数字签名以及第三认证信息发送给第二终端，以使第二终端使用第三共享密钥对第三认证信息进行认证，如果第三认证信息认证通过，保留签名数据以及各个数字签名，将各个数字签名作为签名数据的数字签名；第三认证信息为使用与第二终端共享的第三共享密钥生成的签名数据和各个数字签名的认证信息。
[0208]
通过本实施例，对于签名数据的发送者，即第一终端以及签名数据的接收者，即第二终端，分别与不同的可信中心通信，当需要对签名数据进行数字签名时，第一终端向自身对应的第一可信中心发送与第一可信中心对应的签名请求，然后由第一可信中心使用与第一终端共享的第一共享密钥对第一认证信息进行认证，当认证通过时，使用本地签名密钥生成签名数据的数字签名，并将签名数据、数字签名以及第二认证信息发送给第二可信中心，由第二可信中心使用与第一可信中心共享的第二共享密钥对第二认证信息进行认证，当认证通过时，将签名数据、数字签名以及第三认证信息发送给第二终端，最后由第二终端使用与第二可信中心共享的第三密钥对第三认证信息进行认证，当认证通过时，将数字签名作为该签名数据的数字签名。另外，当第一终端对应多个第一可信中心，第一终端向每个第一可信中心发送与该第一可信中心对应的签名请求，同时第二可信中心需要对每个第一可信中心发送的第二认证信息进行认证，可见，本申请实施例提供的数字签名方法是基于多可信中心，由多个可信中心进行认证，降低了数字签名对单一可信中心安全性的依赖，同时提高了数字签名的安全性。
[0209]
基于上述方法实施例，本申请实施例提供了一种数字签名的系统，下面将结合附图对该系统进行说明。
[0210]
参见图8，该图为本申请实施例提供的一种数字签名系统结构图，如图8所示，该系统包括：第一终端801、第一可信中心802、第二可信中心803以及第二终端804；
[0211]
第一终端801，用于向第一可信中心802发送与所述第一可信中心802对应的签名请求，所述签名请求包括第一身份信息、签名数据以及第一认证信息，所述第一认证信息为使用与所述第一可信中心802共享的第一共享密钥生成的所述第一身份信息和所述签名数据的认证信息；所述第一可信中心802的数量为至少一个；
[0212]
所述第一可信中心802，用于使用所述第一共享密钥对所述第一认证信息进行认证，如果所述第一认证信息认证通过，使用本地签名密钥生成所述签名数据的数字签名，将所述签名数据、所述数字签名以及第二认证信息发送给第二可信中心803，所述第二认证信息为使用与所述第二可信中心803共享的第二共享密钥生成的所述签名数据和所述数字签名的认证信息；
[0213]
所述第二可信中心803，用于分别使用每个第一可信中心802对应的第二共享密钥对该第一可信中心802发送的第二认证信息进行认证，如果各个第二认证信息均认证通过，将所述签名数据、各个所述数字签名以及第三认证信息发送给第二终端804，所述第三认证信息为使用与所述第二终端804共享的第三共享密钥生成的所述签名数据和各个所述数字签名的认证信息；
[0214]
所述第二终端804，用于使用所述第三共享密钥对所述第三认证信息进行认证，如果所述第三认证信息认证通过，保留所述签名数据以及各个所述数字签名，将各个所述数字签名作为所述签名数据的数字签名。
[0215]
在一种可能的实现方式中，所述第一可信中心，具体用于：生成第四认证信息，所述第四认证信息为使用所述第一共享密钥生成的接收到的第一身份信息和接收到的签名数据的认证信息，如果所述第四认证信息与所述第一认证信息一致，则所述第一认证信息认证通过；
[0216]
所述第二可信中心，具体用于分别生成每个第一可信中心对应的第五认证信息，所述第五认证信息为使用该第一可信中心对应的第二共享密钥生成的接收到的签名数据和接收到的该第一可信中心的数字签名的认证信息，如果每个第一可信中心对应的第五认证信息与该第一可信中心发送的第二认证信息均相同，则各个第二认证信息均认证通过；
[0217]
所述第二终端，具体用于生成第六认证信息，所述第六认证信息为使用所述第三共享密钥生成的接收到的签名数据和接收到的各个所述数字签名的认证信息，如果所述第六认证信息与所述第三认证信息一致，则所述第三认证信息认证通过。
[0218]
在一种可能的实现方式中，所述系统还包括：
[0219]
签名密钥分发服务器，用于生成原始密钥数据，对所述原始密钥数据采用纠删码技术进行处理，生成签名密钥数据，将所述签名密钥数据分发给各个所述第一可信中心；所述第一可信中心中的本地签名密钥是从所述签名密钥分发服务器发送的签名密钥数据中获取的。
[0220]
在一种可能的实现方式中，所述签名密钥分发服务器，还用于对所述第一可信中心中的签名密钥数据进行恢复。
[0221]
在一种可能的实现方式中，所述系统还包括：
[0222]
第三终端，用于将所述签名数据以及各个所述数字签名分别发送给产生该数字签名的第一可信中心；
[0223]
接收到数字签名的第一可信中心根据所述签名数据以及接收到的数字签名对该
数字签名进行验证，向所述第三终端发送验证结果；
[0224]
所述第三终端，还用于如果接收到各个所述数字签名均通过验证的验证结果，则确定所述签名数据的数字签名正确。
[0225]
在一种可能的实现方式中，所述第三终端，还用于如果接收到各个所述数字签名未均通过验证的验证结果，则将所述签名数据以及验证未通过的数字签名发送给仲裁服务器；
[0226]
所述仲裁服务器，用于判断所述验证未通过的数字签名对应的第一可信中心中的本地签名密钥是否被更改，如果未更改，向所述第三终端发送所述验证未通过的数字签名通过验证的验证结果。
[0227]
需要说明的是，本实施例中各个设备的实现可以参见上述方法实施例，本实施例在此不再赘述。
[0228]
基于上述方法实施例，本申请实施例还提供了一种数字签名装置，参见图9，该图为本申请实施例提供的一种数字签名装置结构图，所述装置应用于第一可信中心，所述装置包括：
[0229]
第一接收单元901，用于接收第一终端发送的签名请求，所述签名请求包括第一身份信息、签名数据以及第一认证信息，所述第一认证信息为使用与所述第一可信中心共享的第一共享密钥生成的所述第一身份信息和所述签名数据的认证信息；
[0230]
第一认证单元902，用于使用所述第一共享密钥对所述第一认证信息进行认证；
[0231]
第一生成单元903，用于如果所述第一认证单元的认证结果为认证通过，使用本地签名密钥生成所述签名数据的数字签名；
[0232]
第一发送单元904，用于将所述签名数据、所述数字签名以及第二认证信息发送给第二可信中心，以使所述第二可信中心使用所述第一可信中心对应的第二共享密钥对所述第二认证信息进行认证，如果各个所述第一可信中心发送的第二认证信息均认证通过，将所述签名数据、各个所述第一可信中心发送的各个所述数字签名以及第三认证信息发送给第二终端；所述第二认证信息为所述第一可信中心使用与所述第二可信中心共享的第二共享密钥生成的所述签名数据和所述数字签名的认证信息；所述第三认证信息为所述第二可信中心使用与所述第二终端共享的第三共享密钥生成的所述签名数据和各个所述数字签名的认证信息；所述第二终端用于使用所述第三共享密钥对所述第三认证信息进行认证，如果所述第三认证信息认证通过，保留所述签名数据以及各个所述数字签名，将各个所述数字签名作为所述签名数据的数字签名。
[0233]
在一种可能的实现方式中，所述第一认证单元，具体用于生成第四认证信息，所述第四认证信息为使用所述第一共享密钥生成的接收到的第一身份信息和接收到的签名数据的认证信息，如果所述第四认证信息与所述第一认证信息一致，则所述第一认证信息认证通过。
[0234]
在一种可能的实现方式中，所述第一可信中心中的本地签名密钥是从签名密钥分发服务器发送的签名密钥数据中获取的，所述签名密钥分发服务器用于生成原始密钥数据，对所述原始密钥数据采用纠删码技术进行处理，生成签名密钥数据，将所述签名密钥数据分发给各个所述第一可信中心。
[0235]
在一种可能的实现方式中，所述签名密钥分发服务器还用于对所述第一可信中心
中的签名密钥数据进行恢复。
[0236]
在一种可能的实现方式中，所述装置还包括：
[0237]
第二接收单元，用于接收第三终端发送的所述签名数据以及所述数字签名，根据所述签名数据以及所述数字签名对所述数字签名进行验证，向所述第三终端发送验证结果，以使所述第三终端如果接收到各个所述第一可信中心对应的数字签名均通过验证的验证结果，则确定所述签名数据的数字签名正确。
[0238]
在一种可能的实现方式中，所述第三终端还用于如果接收到各个所述数字签名未均通过验证的验证结果，则将所述签名数据以及验证未通过的数字签名发送给仲裁服务器；
[0239]
所述仲裁服务器，用于判断所述验证未通过的数字签名对应的第一可信中心中的本地签名密钥是否被更改，如果未更改，向所述第三终端发送所述验证未通过的数字签名通过验证的验证结果。
[0240]
需要说明的是，本实施例中各个单元的实现可以参见上述实施例，本实施例在此不再赘述。
[0241]
另外，本申请实施例还提供了另一种数字签名装置，参见图10，该为本申请实施例提供的另一种数字签名装置结构图，所述装置应用于第二可信中心，所述装置包括：
[0242]
第三接收单元1001，用于接收各个第一可信中心发送的签名数据、数字签名以及第二认证信息；所述第一可信中心用于接收第一终端发送的签名请求，所述签名请求包括第一身份信息、签名数据以及第一认证信息，所述第一认证信息为所述第一终端使用与所述第一可信中心共享的第一共享密钥生成的所述第一身份信息和所述签名数据的认证信息；使用所述第一共享密钥对所述第一认证信息进行认证，如果所述第一认证信息认证通过，使用本地签名密钥生成所述签名数据的数字签名；将所述签名数据、所述数字签名以及第二认证信息发送给第二可信中心，所述第二认证信息为所述第一可信中心使用与所述第二可信中心共享的第二共享密钥生成的所述签名数据和所述数字签名的认证信息；
[0243]
第二认证单元1002，用于分别使用每个第一可信中心对应的第二共享密钥对该第一可信中心发送的第二认证信息进行认证；
[0244]
第二发送单元1003，用于如果所述第二认证单元的认证结果为各个第二认证信息均认证通过，将所述签名数据、各个所述数字签名以及第三认证信息发送给第二终端，以使所述第二终端使用第三共享密钥对所述第三认证信息进行认证，如果所述第三认证信息认证通过，保留所述签名数据以及各个所述数字签名，将各个所述数字签名作为所述签名数据的数字签名；所述第三认证信息为使用与所述第二终端共享的第三共享密钥生成的所述签名数据和各个所述数字签名的认证信息。
[0245]
在一种可能的实现方式中，所述第二认证单元，具体用于分别生成每个第一可信中心对应的第五认证信息，所述第五认证信息为使用该第一可信中心对应的第二共享密钥生成的接收到的签名数据和接收到的该第一可信中心的数字签名的认证信息，如果每个第一可信中心对应的第五认证信息与该第一可信中心发送的第二认证信息均相同，则各个第二认证信息均认证通过。
[0246]
在一种可能的实现方式中，所述第一可信中心中的本地签名密钥是从签名密钥分发服务器发送的签名密钥数据中获取的，所述签名密钥分发服务器用于生成原始密钥数
据，对所述原始密钥数据采用纠删码技术进行处理，生成签名密钥数据，将所述签名密钥数据分发给各个所述第一可信中心。
[0247]
在一种可能的实现方式中，所述签名密钥分发服务器还用于对所述第一可信中心中的签名密钥数据进行恢复。
[0248]
通过上述实施例可知，第一终端向第一可信中心发送与第一可信中心对应的签名请求，第一可信中心使用与第一终端共享的第一共享密钥对签名请求中的第一认证信息进行认证，当认证通过时，使用本地签名密钥生成签名数据的数字签名，并将签名数据、数字签名以及第二认证信息发送给第二可信中心，由第二可信中心使用与每个第一可信中心共享的第二共享密钥对第二认证信息进行认证，如果每个第二认证信息均认证通过，则将签名数据、各个数字签名以及第三认证信息发送给第二终端，再由第二终端使用与第二可信中心共享的第三共享密钥对第三认证信息进行认证，如果第三认证信息认证通过，则各个数字签名作为签名数据的数字签名，可见，本申请实施例提供的数字签名方法是基于多可信中心，由多个可信中心进行信息的认证，降低了数字签名对单一可信中心安全性的依赖，同时提高了数字签名的安全性。
[0249]
需要说明的是，本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的系统或装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。
[0250]
应当理解，在本申请中，“至少一个(项)”是指一个或者多个，“多个”是指两个或两个以上。“和/或”，用于描述关联对象的关联关系，表示可以存在三种关系，例如，“a和/或b”可以表示：只存在a，只存在b以及同时存在a和b三种情况，其中a，b可以是单数或者复数。字符“/”一般表示前后关联对象是一种“或”的关系。“以下至少一项(个)”或其类似表达，是指这些项中的任意组合，包括单项(个)或复数项(个)的任意组合。例如，a，b或c中的至少一项(个)，可以表示：a，b，c，“a和b”，“a和c”，“b和c”，或“a和b和c”，其中a，b，c可以是单个，也可以是多个。
[0251]
还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。
[0252]
结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。
[0253]
对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下，在其它实施例中实现。因此，本申请
将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。