CN109981287B - 一种代码签名方法及其存储介质 - Google Patents

Abstract

本申请实施例提供一种代码签名方法及其存储介质，涉及数据加密技术领域。该代码签名方法包括：接收客户端发送的摘要，所述摘要基于需要进行代码签名的代码文件生成；通过连接的可信部件对所述摘要进行私钥签名，生成数字信封，并将所述数字信封发送至所述客户端，其中，所述可信部件中存储有用于私钥签名的第一私钥。上述方法在对代码文件进行远程签名时，采用可信部件进行私钥签名，提高了代码签名的安全性。

Description

一种代码签名方法及其存储介质

技术领域

本申请涉及数据加密技术领域，具体而言，涉及一种代码签名方法及其存储介质。

背景技术

目前，传统的代码签名方案，大多采取文件的完整性摘要和私钥签名在同一台电脑上执行的方案，例如微软的SignTool签名工具，这在签名的便利性和私钥的安全性上都存在很大的问题。SignTool是微软的数字签名制作工具，只能制作windows平台的签名，代码签名(散列和加密)同一台电脑上执行，无法实现远程签名，私钥的保护，证书的使用上都存在局限性，安全风险大，不能跨平台。而现有的远程代码签名方案允许用户上传代码文件进行远程签名，但是远程签名需要对代码文件、密钥以及其他涉密文件进行网络传输，现有的远程代码签名方案直接采用对应服务节点的计算设备进行证书管理和私钥签名，证书和密钥暴露在网络中，其安全性无法得到保障。

发明内容

本申请实施例的目的在于提供一种代码签名方法及其存储介质，用以实现在进行远程代码签名的同时，保障私钥签名的相关证书、私钥以及其他数据的安全性。

本申请实施例提供了一种代码签名方法，应用于服务端，所述方法包括：接收客户端发送的摘要，所述摘要基于需要进行代码签名的代码文件生成；通过连接的可信部件对所述摘要进行私钥签名，生成数字信封，并将所述数字信封发送至所述客户端，其中，所述可信部件中存储有用于私钥签名的第一私钥。

在上述实现过程中，服务端在客户端有代码文件签名需求时对客户端发来的摘要进行私钥签名后，由客户端基于完成私钥签名的数字信封获取签名文件，从而实现了跨设备的远程签名；同时服务端通过连接的可信部件对摘要进行证书验证和私钥签名，避免将证书和私钥直接存储在安全风险较大的服务端或计算机本地，从而提高了私钥签名的安全性；将可信部件签名以及基于客户端、服务端的远程签名相配合，使用户能够在多客户端、多区域需要进行可信部件认证的代码文件签名时，直接通过服务端连接的可信部件进行私钥签名，避免在多个客户端处配置多个可信部件或多个客户端通过网络分享可信部件带来安全隐患，从而提高了可信部件的远程使用便利性和安全性。

进一步地，在所述接收客户端发送的摘要之前，所述方法还包括：接收所述客户端发送的证书申请请求；基于初始设置的根证书和所述证书申请请求生成操作员证书，向所述客户端返回所述操作员证书。在上述实现过程中，服务端基于证书申请请求向客户端发送操作员证书，通过强PKI身份认证授权，确保进行代码文件签名的操作人员合法，提高了签名安全性。

进一步地，在所述通过连接的可信部件对所述摘要进行私钥签名之前，所述方法还包括：接收所述客户端发送的操作员证书，采用所述操作员证书对所述摘要进行签名验证，确定所述摘要已通过所述操作员证书的认证。在上述实现过程中，服务端对客户端发送来的待签名的摘要进行一次签名验证，确保摘要的来源可靠性和合法性，从而进一步提高了安全性。

进一步地，在所述接收所述客户端发送的操作员证书之后，以及所述通过连接的可信部件对所述摘要进行私钥签名之前，所述方法还包括：接收所述客户端发送的文件信息，采用所述操作员证书对所述文件信息进行签名验证，确定所述文件信息是完整的，所述文件信息包括所述代码文件的文件类型、文件名、文件大小。在上述实现过程中，对文件信息进行签名验证，以保证文件信息的完整性和安全性，提高了代码签名的准确性和安全性。

进一步地，在所述接收所述客户端发送的证书申请请求之前，所述方法还包括：接收所述客户端的操作员账号的登录请求，向所述客户端返回所述操作员账号对应的登录验证值。在所述向所述客户端返回所述操作员证书之前，所述方法还包括：基于所述客户端的登录验证值确定所述操作员账号为正常登录账号。在上述实现过程中，服务端通过验证客户端的登录验证值，对操作人员的账号身份以及登录状态进行验证，在确保安全性的同时简化了操作人员的登录操作。

进一步地，所述方法还包括：确定所述客户端的互联网协议地址、所述客户端完成签名的时间、所述摘要、所述代码文件的文件名、所述根证书以及所述代码文件的完整哈希值；将所述互联网协议地址、所述时间、所述摘要、所述文件名、所述根证书以及所述完整哈希值进行存储并作为审计数据。在上述实现过程中，将客户端IP、签名时间、代码文件的文件名、根证书数据以及代码文件完整哈希值作为审计数据，能够在完成代码签名的同时具备审计功能，从而提高了签名安全程度和追责便利程度，并且通过签名审计日志记录谁、什么时候、签了什么文件，跟踪签名的代码和活动，以确保问责制和合规性。

进一步地，所述通过连接的可信部件对所述摘要进行私钥签名，包括：通过连接的可信部件，调用基于PKCS#11标准定义的应用程序编程接口对所述摘要进行私钥签名。

进一步地，所述生成数字信封，包括：基于PKCS#7标准生成数字信封。

本申请实施例还提供了一种代码签名方法，应用于客户端，所述方法包括：基于需要进行代码签名的代码文件生成摘要，将所述摘要发送至服务端；接收所述服务端返回的数字信封，将所述数字信封写入所述代码文件的对应区域，获得签名文件。

在上述实现过程中，客户端将需要进行代码签名的摘要发送给服务端并接收远程签名结果获得签名文件，从而实现了跨设备的远程签名，避免将证书和私钥直接存储在安全风险较大的服务端或计算机本地，从而提高了私钥签名的安全性。

进一步地，在所述将所述摘要发送至服务端之前，所述方法还包括：向所述服务端发送证书申请请求；接收所述服务端返回的操作员证书，并将所述操作员证书导入证书池。在上述实现过程中，客户端导入操作员证书后以对操作员的合法性以及摘要的完整性进行验证，提高了签名安全性。

进一步地，在所述将所述摘要发送至服务端之前，所述方法还包括：生成与所述证书申请请求对应的第二私钥；采用所述第二私钥，基于所述操作员证书对所述摘要进行私钥签名。在上述实现过程中，采用操作员证书对摘要进行签名，能够确保摘要发送方的合法性，提高签名的安全性。

进一步地，所述基于所述操作员证书对所述摘要进行私钥签名，包括：采用所述第二私钥，基于所述操作员证书对所述摘要以及文件信息进行私钥签名，所述文件信息包括所述代码文件的文件名、文件类型和文件大小。在上述实现过程中，对文件信息进行私钥签名以便于进行签名验证，以保证文件信息的完整性和安全性，提高了代码签名的准确性和安全性。

进一步地，在所述向所述服务端发送证书申请请求之前，所述方法还包括：向所述服务端发送操作员账号的登录请求，接收所述服务端返回的所述操作员账号对应的登录验证值。在上述实现过程中，客户端在进行账号登录时进行登录验证值的请求，从而对操作人员的账号身份以及登录状态进行验证，在确保安全性的同时简化了操作人员的登录操作。

进一步地，所述可信部件为USB Key。

本申请实施例还提供了一种计算机可读取存储介质，所述计算机可读取存储介质中存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行上述方法中的步骤。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本申请的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种远程签名***的结构示意图；

图2为本申请实施例提供的一种代码签名方法的流程示意图；

图3为本申请实施例提供的一种操作员证书传输步骤的流程示意图；

图4为本申请实施例提供的一种摘要签名验证步骤的流程示意图。

图标：10－远程签名***；11－客户端；12－服务端；13－可信部件；14－网络。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述。

应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。同时，在本申请的描述中，术语“第一”、“第二”等仅用于区分描述，而不能理解为指示或暗示相对重要性。

请参考图1，图1为本申请实施例提供的一种远程签名***的结构示意图。

该远程签名***10用于执行本申请实施例提供的代码签名方法，远程签名***10包括客户端11、服务端12、可信部件13和网络14，客户端11通过网络14和服务端12连接，可信部件13与服务端12物理连接。

作为一种可选的实施方式，客户端11、服务端12可以为普通计算机、云服务器、智能终端(如智能手机、平板电脑等)或其他具有数据处理功能的电子设备。进一步地，网络14可以为互联网、局域网或其他能够支持客户端11、服务端12进行数据传输的网络。

请参考图2，图2为本申请实施例提供的一种代码签名方法的流程示意图，该代码签名方法的具体步骤可以如下：

步骤S21：客户端基于需要进行代码签名的代码文件生成摘要，将生成的摘要发送至服务端。

在本申请的实施例中，代码文件可以是操作人员自行选取，该代码文件通常是可移植的可执行的文件(例如exe、dll、sys、msi、ocx格式文件)、压缩文件(例如cab格式文件)或Cat安全编录文件。

在本申请的实施例中，摘要即为消息摘要(Message Digest)又称为数字摘要(Digital Digest)。它是一个唯一对应一个消息或文本的固定长度的值，它由一个单向Hash加密函数对消息进行作用而产生，如果消息在途中改变了，则接收者通过对收到消息的新产生的摘要与原摘要比较，就可知道消息是否被改变了。因此摘要保证了消息的完整性。例如摘要采用单向Hash函数将需加密的明文＂摘要＂成一串128bit的密文，这一串密文亦称为数字指纹(Finger Print)，它有固定的长度，且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致。

应当理解的是，客户端在发送代码文件的摘要的同时，还将代码文件的文件名、文件大小、文件类型等文件信息和文件摘要经第二私钥签名后的文件的完整性摘要发送至服务端，以使服务端通过文件信息获取审计完整的代码文件的相关信息，并能够基于文件信息确定接收到的信息完整性。

步骤S22：服务端接收客户端发送的摘要，通过连接的可信部件对摘要进行私钥签名，生成数字信封，并将数字信封发送至客户端。

在现有技术中，可信部件作为代码签名证书和私钥的载体，在带来便利性的同时带来了额外的安全风险。当位于不同区域的客户端需要使用可信部件签名代码文件时，在传输过程中无法跟踪可信部件的行踪，密码、密钥容易被盗，可信部件存在丢失或是被盗取用于签名恶意软件的问题。例如一个公司只有一把用于签名的可信部件，拥有三家分公司位于A地、B地和C地，当位于A、B、C中某一地分公司请求可信部件签名时，还可以满足需要，但当两家甚至三家分公司同时发出签名请求时，一把可信部件分身乏术，无法同时满足多方需要。而且，可信部件在发往下一家公司途中的安全性也令人担忧。

为了解决多用户同时使用的问题，可以选择购买多把可信部件分发给多个节点，但无法跟踪或审计签名活动，哪个用户在什么时候签了什么文件都难以被统计，分散的部门和机构导致操作人员的身份很难被验证。例如某公司为了同时解决多家分公司同时签名的需求的问题，为代码签名证书复制了多把可信部件，分别分发给A地、B地和C地的分公司，共享的问题解决了，但是可信部件的使用脱离了掌控，管理上存在安全隐患，谁在什么时间什么地点执行了哪些操作，公司管理人员都无从得知，有可能C地分公司的可信部件就被黑客用于签名了。

因此在本申请实施例中将服务端、客户端和可信部件结合进行远程文件签名，既保证了可信部件的安全性和审计需求，又使签名可以在多个节点远程进行。

在本申请实施例中，可信部件可以是USB Key、DKey、USB Token或其他动态口令身份认证硬件。该可信部件用于对证书和私钥进行存储，还用于运用证书和私钥进行私钥签名，且可信部件内部的证书和私钥无法被导出，保证了远程签名的安全性。

在本申请实施例中，数字信封是一种综合利用了对称加密技术和非对称加密技术两者的优点进行信息安全传输的一种技术。在数字信封中，信息发送方采用对称密钥来加密信息内容，然后将此对称密钥用接收方的公开密钥来加密(这部分称数字信封)之后，将它和加密后的信息一起发送给接收方，接收方先用相应的私有密钥打开数字信封，得到对称密钥，然后使用对称密钥解开加密信息，具备相当高的安全性。

步骤S23：客户端接收服务端返回的数字信封，将数字信封写入代码文件的对应区域，获得签名文件。

在上述实施例中，服务端在客户端有代码文件签名需求时对服务端发来的摘要进行私钥签名后，由客户端基于完成私钥签名的摘要获取签名文件，从而实现了跨设备的远程签名；同时服务端通过连接的可信部件对摘要进行操作证书验证和私钥签名，避免将证书和私钥直接存储在安全风险较大的服务端或计算机本地，从而提高了私钥签名的安全性，还解决了大文件传输受限和耗时长的问题；将可信部件签名以及基于客户端、服务端的远程签名相配合，使用户能够在多客户端、多区域需要进行可信部件认证的代码文件签名时，直接通过服务端连接的可信部件进行私钥签名，避免在多个客户端处配置多个可信部件或多个客户端通过网络分享可信部件带来安全隐患，从而提高了可信部件的远程使用便利性和安全性。

针对步骤S21，作为一种可选的实施方式，摘要可以是基于单向哈希函数生成。

针对步骤S22，作为一种可选的实施方式，上述“通过连接的可信部件对所述摘要进行私钥签名”可以具体包括：通过连接的可信部件，调用基于PKCS#11标准定义的应用程序编程接口对所述摘要进行私钥签名。其中，PKCS#11是公钥加密标准(PKCS，Public－KeyCryptography Standards)中的一份子，由RSA实验室发布，它为加密令牌定义了一组平台无关的API，如硬件安全模块和智能卡，从而提高了加密安全性。

上述“生成数字信封”具体可以包括：基于PKCS#7标准生成数字信封。其中，PKCS#7是加密消息的语法标准，由RSA安全体系在公钥加密***中交换数字证书产生的一种加密标准。

应当理解的是，在考虑到服务端对摘要进行私钥签名的安全性的同时，还应当保证摘要来源的可靠性，因此本实施例需要对请求发送摘要的客户端的操作人员的身份进行验证，可以基于操作员证书完成身份验证，则客户端需要预先从服务端获取操作员证书。

请参考图3，图3为本申请实施例提供的一种操作员证书传输步骤的流程示意图，该操作员证书传输步骤具体步骤可以如下：

步骤S31：客户端向服务端发送证书申请请求。

步骤S32：服务端接收客户端发送的证书申请请求，基于初始设置的根证书和所述证书申请请求生成操作员证书，向客户端返回操作员证书。

步骤S33：客户端接收服务端返回的操作员证书，并将操作员证书导入证书池。

作为一种可选的实施方式，步骤S32中的根证书在密码学和计算机安全领域中，是未被签名的公钥证书或自签名的证书。根证书是CA认证中心给自己颁发的证书，是信任链的起始点，安装根证书意味着对这个CA认证中心即服务端的信任，从而能够通过服务端进行证书发放以及私钥签名等操作。在本实施例中，操作员证书即通过根证书认证后生成并发放的用于验证操作人员的摘要发送及签名文件合成等操作的操作资格的证书。

进一步地，本申请实施例中的根证书可以是但不限于是X.509证书，其用于规定证书可以包含什么信息，并说明了记录信息的方法(即数据格式)。

在上述实施例中，客户端在需要通过服务端进行代码文件签名之前需要先获取操作员证书，以保证合法的操作人员才能基于操作员证书进行摘要传输，从而避免不具备签名资格的用户占用服务端的相关资源，提高了签名效率和安全性。

进一步地，为了保证摘要的安全性，本申请实施例还可以对摘要进行签名，以使服务端在接收到摘要后能够基于签名确定摘要的可靠性和安全性。请参考图4，图4为本申请实施例提供的一种摘要签名验证步骤的流程示意图，该摘要签名验证步骤可以如下：

步骤S41：生成与证书申请请求对应的第二私钥。

步骤S42：采用第二私钥，基于操作员证书对摘要进行私钥签名。

步骤S43：服务端接收客户端发送的操作员证书，采用操作员证书对客户端发送来的摘要进行签名验证，确定摘要已通过所述操作员证书的认证。

对于步骤S42，除了对摘要进行第二私钥的签名，还可以对代码文件的文件名、文件大小和文件类型等文件信息进行第二私钥的私钥签名。在此类实施例中，步骤S43中“采用操作员证书对客户端发送来的摘要进行签名验证”则包括：采用操作员证书对客户端发送来的摘要和文件信息进行签名验证。进而确保操作员的合法性以及文件信息的文完整性和安全性。

作为一种可选的实施方式，本申请实施例中的第二私钥被标记为不可导出，该操作员证书也被标记为不可导出，从而避免其他人进行恶意冒充签名等操作，提高了签名安全性。

作为一种可选的实施方式，本申请实施例中对摘要或文件信息进行签名，在代码签名场景中可以有效避免重放攻击，因为攻击者要通过重放攻击签一个恶意程序，将会因为文件HASH不一致而被拒绝，从而进一步提高了签名安全性。

在上述实施例中，客户端采用第二私钥对生成的摘要或文件信息进行私钥签名，服务端通过操作员证书对客户端发送来的待签名的摘要或文件信息进行签名验证，确保摘要的来源可靠性和合法性，并且对摘要的来源能够进行记录和管理，从而进一步提高了安全性。

进一步地，为了简化操作人员的账户登录操作以及账户验证步骤，本实施例还可以采用登录验证值机制，该机制的具体步骤可以如下：

步骤S51：服务端接收客户端发送的证书申请请求之前，接收客户端的操作员账号的登录请求，向客户端返回操作员账号对应的登录验证值。

步骤S52：客户端接收登录验证值，并在与服务端进行数据传输时发送该登录验证值。

步骤S53：服务端基于客户端发送的登录验证值确定客户端的操作员账号为正常登录账号。

作为一种可选的实施方式，登录验证值可以为Token值，Token值是服务端生成的一串字符串，以作客户端进行请求的一个令牌，当第一次登录后，服务端生成一个Token便将此Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次带上用户名和密码。从而在客户端频繁向服务端请求数据时，避免服务端频繁的去数据库查询用户名和密码并进行对比，有效提高效率。

在上述实施例中，服务端通过验证客户端的登录验证值，对操作人员的账号身份以及登录状态进行验证，避免服务端频繁的去数据库查询用户名和密码，直接、迅速地确定账户身份，在确保安全性的同时简化了操作人员的登录操作。例如操作人员A在客户端首次登录账户1，服务端接收到该登录请求后，对账户1的账户和密码进行验证，基于数据库查询该账户和密码并进行对比后确定账户和密码正确，账户1的登录请求通过，然后服务端生成一个Token值字符串，对该Token值进行本地保存并将其发送至客户端，此后客户端登录账户1与服务端进行数据传输时带上该Token值即可省略账户和密码的验证步骤，提高数据传输效率。

应当理解的是，本申请实施例中通过登录验证值和操作员证书确认操作人员的身份后，服务端即可获取并存储客户端的互联网协议地址、客户端完成签名的时间、摘要、代码文件的文件名、根证书以及代码文件的完整哈希值，并基于上述数据进行签名数据的审计，从而跟踪或审计签名活动，确定哪个用户在什么时候签了什么文件，进一步提高代码文件的签名安全性。进一步地，审计数据中还可以包括代码文件大小、签名结果和数字信封。

作为一种可选的实施方式，本申请实施例中的可信部件可以是但不限于是USBKey，其为一种通过通用串行总线接口(英文简称：USB)直接与计算机相连、具有密码验证功能、可靠高速的小型存储设备，现在通常是把数字证书放在USB Key里，用于数字签名。它的特点是一旦放入，证书就被牢牢的封装在USB Key中，只要保管好USB Key，“木马程序”就会束手无策，这就是我们通常所说的“硬证书”。在USB Key下的签名操作不可篡改、抵赖，最大的特点就是安全性高，技术规范一致性强，操作***兼容性好，携带使用灵活。

对本申请实施例提供的代码签名方法进行举例说明，位于A地操作人员张三在客户端上相应的网页界面或应用程序界面输入账号“zhangsan”和密码“123456”进行账户登录，客户端向服务端发送账户登录请求的同时将此前登录账号“zhangsan”获取的登录验证值发送至服务端，服务端将该登录验证值与本地存储的对应值进行对比后确认账号“zhangsan”合法从而建立数据连接，客户端基于张三选中的代码文件生成摘要，并基于此前放入证书池的操作员证书以及第二私钥对该摘要进行签名，将签名后的摘要发送至服务端，服务端采用操作员证书验证摘要的合法性后，调用可信部件中的证书和第一私钥对摘要进行签名，并将签名生成的数字信封发送至客户端，客户端将数字信封写入代码文件的指定区域，从而获得签名文件。进一步地，在整个签名过程中，服务端可以对代码文件的文件名、签名时间、客户端IP地址、账号“zhangsan”、签名结果等数据进行获取和存储，以进行签名审计。

综上所述，本申请实施例提供了一种代码签名方法及其存储介质，所述方法包括：接收客户端发送的摘要，所述摘要基于需要进行代码签名的代码文件生成；通过连接的可信部件对所述摘要进行私钥签名，生成数字信封，并将所述数字信封发送至所述客户端，其中，所述可信部件中存储有用于私钥签名的第一私钥。

在上述实现过程中，服务端在客户端有代码文件签名需求时对客户端发来的摘要进行私钥签名后，由客户端基于完成私钥签名的数字信封获取签名文件，从而实现了跨设备的远程签名；同时服务端通过连接的可信部件对摘要进行证书验证和私钥签名，避免将证书和私钥直接存储在安全风险较大的服务端或计算机本地，从而提高了私钥签名的安全性；将可信部件签名以及基于客户端、服务端的远程签名相配合，使用户能够在多客户端、多区域需要进行可信部件认证的代码文件签名时，直接通过服务端连接的可信部件进行私钥签名，避免在多个客户端处配置多个可信部件或多个客户端通过网络分享可信部件带来安全隐患，从而提高了可信部件的远程使用便利性和安全性。

在本申请所提供的几个实施例中，应该理解到，所揭露的装置和方法，也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的，例如，附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分，所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现方式中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个连续的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或动作的专用的基于硬件的***来实现，或者可以用专用硬件与计算机指令的组合来实现。

另外，在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分，也可以是各个模块单独存在，也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read－Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施例而已，并不用于限制本申请的保护范围，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。

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

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

Claims (10)

1.一种代码签名方法，其特征在于，应用于服务端，所述方法包括：

接收客户端发送的摘要，所述摘要基于需要进行代码签名的代码文件生成；

接收所述客户端发送的操作员证书，采用所述操作员证书对所述摘要进行签名验证，确定所述摘要已通过所述操作员证书的认证；

接收所述客户端发送的文件信息，采用所述操作员证书对所述文件信息进行签名验证，确定所述文件信息是完整的，所述文件信息包括所述代码文件的文件类型、文件名和文件大小；

通过连接的可信部件对所述摘要进行私钥签名，生成数字信封，并将所述数字信封发送至所述客户端，其中，所述可信部件中存储有用于私钥签名的第一私钥。

2.根据权利要求1所述的代码签名方法，其特征在于，在所述接收客户端发送的摘要之前，所述方法还包括：

接收所述客户端发送的证书申请请求；

基于初始设置的根证书和所述证书申请请求生成操作员证书，向所述客户端返回所述操作员证书。

3.根据权利要求2所述的代码签名方法，其特征在于，在所述接收所述客户端发送的证书申请请求之前，所述方法还包括：

接收所述客户端的操作员账号的登录请求，向所述客户端返回所述操作员账号对应的登录验证值；

在所述向所述客户端返回所述操作员证书之前，所述方法还包括：

基于所述客户端的登录验证值确定所述操作员账号为正常登录账号。

4.根据权利要求2所述的代码签名方法，其特征在于，所述方法还包括：

确定所述客户端的互联网协议地址、所述客户端完成签名的时间、所述摘要、所述代码文件的文件名、所述根证书以及所述代码文件的完整哈希值；

将所述互联网协议地址、所述时间、所述摘要、所述文件名、所述根证书以及所述完整哈希值进行存储并作为审计数据。

5.根据权利要求1所述的代码签名方法，其特征在于，所述通过连接的可信部件对所述摘要进行私钥签名，包括：

通过连接的可信部件，调用基于PKCS#11标准定义的应用程序编程接口对所述摘要进行私钥签名。

6.根据权利要求1所述的代码签名方法，其特征在于，所述生成数字信封，包括：

基于PKCS#7标准生成数字信封。

7.根据权利要求1－6中任一项所述的代码签名方法，其特征在于，所述可信部件为USBKey。

8.一种代码签名方法，其特征在于，应用于客户端，所述方法包括：

向服务端发送证书申请请求；

接收所述服务端返回的操作员证书，并将所述操作员证书导入证书池；

生成与所述证书申请请求对应的第二私钥；

基于需要进行代码签名的代码文件生成摘要；

采用所述第二私钥，基于所述操作员证书对所述摘要以及文件信息进行私钥签名，所述文件信息包括所述代码文件的文件类型、文件名和文件大小；

将所述摘要发送至服务端；

接收所述服务端返回的数字信封，将所述数字信封写入所述代码文件的对应区域，获得签名文件。

9.根据权利要求8所述的代码签名方法，其特征在于，在所述向所述服务端发送证书申请请求之前，所述方法还包括：

向所述服务端发送操作员账号的登录请求，接收所述服务端返回的所述操作员账号对应的登录验证值。

10.一种计算机可读取存储介质，其特征在于，所述计算机可读取存储介质中存储有计算机程序指令，所述计算机程序指令被一处理器读取并运行时，执行权利要求1－9任一项所述方法中。

Images