密钥授权方法、加密机、终端及存储介质与流程

本申请涉及密钥管理领域，特别涉及一种密钥授权方法及产品。

背景技术：

密钥管理是密码技术的重要环节。在现代密码学中，在密码编码学和密码分析学之外，又独立出一支密钥管理学。密钥管理包括密钥的生成、分配、注入、保管、销毁等环节，而其中最重要的就是密钥的代理授权管理。代理重加密是一种具有解密权限代理功能的公钥加密体制。

在传统的代理重加密体制中，代理者可以将授权者的所有密文都转换为针对被授权者的密文。但是，在授权之后，授权者对代理者的行为没有控制能力，这是一亟待解决的技术问题。

技术实现要素：

本申请实施例的目的在于提供一种密钥授权方法、加密机及终端，用以在授权者向代理者授权之后，能够对代理者的行为进行控制。

为了解决上述技术问题，本申请的实施例采用了如下技术方案：一种密钥授权方法，包括：

接收第一许可和第二许可请求，其中，所述第一许可约定了第一用户对许可密钥的第一操作权限，所述第二许可请求用于请求授予第二用户对第二请求密钥的第二操作权限；

利用所述第一许可和所述第二许可请求进行验证，其中，所述验证包括：确定所述第二许可请求的发起者是否为所述第一用户，以及所述第二请求密钥是否为所述许可密钥；

在通过所述验证的情况下，生成第二许可，其中，所述第二许可约定了所述第二用户对所述许可密钥的第二操作权限，所述第一操作权限包含所述第二操作权限，所述第一许可为所述第二许可的父许可；

将所述第二许可颁发给所述第二用户，以使所述第二用户能够将所述第二操作权限中的至少部分权限颁发给第三用户。

本申请的有益效果在于：第一用户对许可密钥的第一操作权限中包含了第二用户对请求密钥的第二操作权限，且第一许可为第二许可的父许可，即在第一用户通过第二许可请求对第二用户进行授权之后第一用户的第一操作权限包含了第二用户获得的第二操作权限，作为授权者的第一用户在向作为代理者的第二用户授权时，由于其可以控制第二操作权限具体的范围，因此，能够通过控制第二操作权限具体的范围来实现对代理者行为的控制。

在一个实施例中，所述方法还包括：

接收第三公钥包；

在所述第三公钥包和所述第一许可均合法，所述第二许可请求的签名通过基于所述第三公钥包进行的验证，并且所述第三公钥包的所有者与所述第一许可中的第一用户一致的情况下，确定所述第二许可请求的发起者为所述第一用户。

本实施例的有益效果在于：接收第三公钥包，通过第三公钥包确定第二许可请求的发起者是否为第一用户，即验证第二许可请求的发起者与第一许可的所有者是否为同一用户，从而能够避免非法用户冒充合法授权者对代理者进行授权，提高了安全性。

在一个实施例中，所述方法还包括：

接收许可密钥包，所述许可密钥包包括：许可密钥的标识；

在所述许可密钥包合法，并且所述第二许可请求中的第二请求密钥的标识与所述许可密钥的标识一致的情况下，确定所述第二请求密钥为所述许可密钥。

在一个实施例中，所述第一许可基于以下方式生成：

接收第一许可请求，所述第一许可请求用于请求授予第一用户对第一请求密钥的第一操作权限；

在所述第一许可请求的发起者为许可密钥的所有者，且所述第一请求密钥为所述许可密钥的情况下，生成第一许可。

在一个实施例中，所述方法还包括：

接收第二公钥包和许可密钥包；

在所述第二公钥包和许可密钥包均合法，所述第一许可请求的签名通过基于所述第二公钥包进行的验证，以及，所述第二公钥包的所有者与许可密钥包的所有者一致的情况下，确定所述第一许可请求的发起者为所述许可密钥的所有者。

本实施例的有益效果在于：接收第二公钥包和许可密钥包，在第二公钥包的所有者与许可密钥包的所有者一致的情况下，确定所述第一许可请求的发起者为所述许可密钥的所有者，从而能够避免非法用户冒充许可密钥的所有者发起第一许可请求，提高了安全性。

在一个实施例中，还包括：

接收密钥创建请求；

在所述密钥创建请求的发起者的身份合法的情况下，创建许可密钥；所述许可密钥的所有者为所述密钥创建请求的发起者。

在一个实施例中，所述方法应用于加密机，

所述第二许可包含第一校验码，所述第一校验码由所述加密机利用所述加密机的第一密钥生成；和/或，

所述第一许可包含第三校验码，所述第三校验码由所述加密机利用所述加密机的第二密钥生成；和/或，

所述许可密钥包包含第五校验码，所述第五校验码由所述加密机利用所述加密机的第三密钥生成。

在一个实施例中，还包括：

接收撤销请求，所述撤回请求用于请求撤销第四许可；

在所述撤销请求的发起者为所述第四许可的颁发者，以及所述第四许可的类型为第一预设类型的情况下，撤销所述第四许可；或者，

在所述撤销请求的发起者为所述第四许可的颁发者，以及所述第四许可的类型为第二预设类型的情况下，撤销所述第四许可，以及基于所述第四许可而颁发的所有许可。

本实施例的有益效果在于：授权者能够基于撤销请求撤销其颁发的许可，或者撤销与其颁发的许可相关的所有许可，从而进一步提升了授权者对于代理者以及其他被授权者行为的控制能力。

本申请还提供一种密钥授权方法，包括：

接收第二许可请求，其中，所述第二许可请求用于请求授予第二用户对第二请求密钥的第二操作权限；

利用所述第二许可请求进行验证，其中，所述验证包括：确定所述第二许可请求的发起者是否为许可密钥的所有者，以及所述第二请求密钥是否为所述许可密钥；

在通过所述验证的情况下，生成第二许可，其中，所述第二许可约定了所述第二用户对所述许可密钥的第二操作权限，所述许可密钥的所有者对所述许可密钥的操作权限包含所述第二操作权限；

将所述第二许可颁发给所述第二用户，以使所述第二用户能够将所述第二操作权限中的至少部分权限颁发给第三用户。

在一个实施例中，所述方法还包括：

接收许可密钥包，所述许可密钥包包括：许可密钥的标识；

在所述许可密钥包合法，并且所述第二许可请求中的第二请求密钥的标识与所述许可密钥的标识一致的情况下，确定所述第二请求密钥为所述许可密钥。

在一个实施例中，还包括：

接收密钥创建请求；

在所述密钥创建请求的发起者的身份合法的情况下，创建许可密钥；所述许可密钥的所有者为所述密钥创建请求的发起者。

在一个实施例中，所述方法应用于加密机，

所述第二许可包含第一校验码，所述第一校验码由所述加密机利用所述加密机的第一密钥生成；和/或，

所述许可密钥包包含第五校验码，所述第五校验码由所述加密机利用所述加密机的第三密钥生成。

本申请还提供一种密钥授权方法，包括：

向加密机发送第一许可和第二许可请求以使所述加密机在接收到所述第一许可和第二许可请求之后，利用所述第一许可和所述第二许可请求进行验证，以及在通过所述验证的情况下，生成第二许可，并将所述第二许可颁发给第二用户，进而使所述第二用户能够将所述第二操作权限中的至少部分权限颁发给第三用户；

其中，所述第一许可约定了第一用户对许可密钥的第一操作权限，所述第二许可请求用于请求授予第二用户对第二请求密钥的第二操作权限；所述验证包括：确定所述第二许可请求的发起者是否为所述第一用户，以及所述第二请求密钥是否为所述许可密钥；所述第二许可约定了所述第二用户对所述许可密钥的第二操作权限，所述第一操作权限包含所述第二操作权限，所述第一许可为所述第二许可的父许可。

本申请还提供一种加密机，包括：

处理器；

用于存储所述处理器中可执行指令的存储器；

其中，所述处理器被配置为：

执行加密机所对应的任一实施例所涉及的密钥授权方法。

本申请还提供一种终端，包括：

处理器；

用于存储所述处理器中可执行指令的存储器；

其中，所述处理器被配置为：

向加密机发送第一许可和第二许可请求，以使所述加密机在接收到所述第一许可和第二许可请求之后，利用所述第一许可和所述第二许可请求进行验证，以及在通过所述验证的情况下，生成第二许可，并将所述第二许可颁发给第二用户，进而使所述第二用户能够将所述第二操作权限中的至少部分权限颁发给第三用户；

其中，所述第一许可约定了第一用户对许可密钥的第一操作权限，所述第二许可请求用于请求授予第二用户对第二请求密钥的第二操作权限；所述验证包括：确定所述第二许可请求的发起者是否为所述第一用户，以及所述第二请求密钥是否为所述许可密钥；所述第二许可约定了所述第二用户对所述许可密钥的第二操作权限，所述第一操作权限包含所述第二操作权限，所述第一许可为所述第二许可的父许可。

本申请还提供一种非临时性计算机可读存储介质，当所述存储介质中的指令由加密机中的处理器执行时，能够执行加密机所对应的任一实施例所涉及的密钥授权方法；

当所述存储介质中的指令由终端中的处理器执行时，能够执行一种密钥授权方法，包括：

向加密机发送第一许可和第二许可请求以使所述加密机在接收到所述第一许可和第二许可请求之后，利用所述第一许可和所述第二许可请求进行验证，以及在通过所述验证的情况下，生成第二许可，并将所述第二许可颁发给第二用户，进而使所述第二用户能够将所述第二操作权限中的至少部分权限颁发给第三用户；

其中，所述第一许可约定了第一用户对许可密钥的第一操作权限，所述第二许可请求用于请求授予第二用户对第二请求密钥的第二操作权限；所述验证包括：确定所述第二许可请求的发起者是否为所述第一用户，以及所述第二请求密钥是否为所述许可密钥；所述第二许可约定了所述第二用户对所述许可密钥的第二操作权限，所述第一操作权限包含所述第二操作权限，所述第一许可为所述第二许可的父许可。

本申请还提供一种密钥授权装置，包括：

第一接收模块，用于接收第一许可和第二许可请求，其中，所述第一许可约定了第一用户对许可密钥的第一操作权限，所述第二许可请求用于请求授予第二用户对第二请求密钥的第二操作权限；

验证模块，用于利用所述第一许可和所述第二许可请求进行验证，其中，所述验证包括：确定所述第二许可请求的发起者是否为所述第一用户，以及所述第二请求密钥是否为所述许可密钥；

生成模块，用于在通过所述验证的情况下，生成第二许可，其中，所述第二许可约定了所述第二用户对所述许可密钥的第二操作权限，所述第一操作权限包含所述第二操作权限，所述第一许可为所述第二许可的父许可；

颁发模块，用于将所述第二许可颁发给所述第二用户，以使所述第二用户能够将所述第二操作权限中的至少部分权限颁发给第三用户。

在一个实施例中，所述装置还包括：

第二接收模块，用于接收第三公钥包；

第一确定模块，用于在所述第三公钥包和所述第一许可均合法，所述第二许可请求的签名通过基于所述第三公钥包进行的验证，并且所述第三公钥包的所有者与所述第一许可中的第一用户一致的情况下，确定所述第二许可请求的发起者为所述第一用户。

在一个实施例中，所述装置还包括：

第三接收模块，用于接收许可密钥包，所述许可密钥包包括：许可密钥的标识；

第二确定模块，用于在所述许可密钥包合法，并且所述第二许可请求中的第二请求密钥的标识与所述许可密钥的标识一致的情况下，确定所述第二请求密钥为所述许可密钥。

在一个实施例中，所述第一许可基于以下方式生成：

接收第一许可请求，所述第一许可请求用于请求授予第一用户对第一请求密钥的第一操作权限；

在所述第一许可请求的发起者为许可密钥的所有者，且所述第一请求密钥为所述许可密钥的情况下，生成第一许可。

在一个实施例中，所述装置还包括：

第四接收模块，用于接收第二公钥包和许可密钥包；

第三确定模块，用于在所述第二公钥包和许可密钥包均合法，所述第一许可请求的签名通过基于所述第二公钥包进行的验证，以及，所述第二公钥包的所有者与许可密钥包的所有者一致的情况下，确定所述第一许可请求的发起者为所述许可密钥的所有者。

在一个实施例中，还包括：

第五接收模块，用于接收密钥创建请求；

创建模块，用于在所述密钥创建请求的发起者的身份合法的情况下，创建许可密钥；所述许可密钥的所有者为所述密钥创建请求的发起者。

在一个实施例中，所述装置应用于加密机，

所述第二许可包含第一校验码，所述第一校验码由所述加密机利用所述加密机的第一密钥生成；和/或，

所述第一许可包含第三校验码，所述第三校验码由所述加密机利用所述加密机的第二密钥生成；和/或，

所述许可密钥包包含第五校验码，所述第五校验码由所述加密机利用所述加密机的第三密钥生成。

在一个实施例中，还包括：

第六接收模块，用于接收撤销请求，所述撤回请求用于请求撤销第四许可；

第一撤销模块，用于在所述撤销请求的发起者为所述第四许可的颁发者，以及所述第四许可的类型为第一预设类型的情况下，撤销所述第四许可；

第二撤销模块，用于在所述撤销请求的发起者为所述第四许可的颁发者，以及所述第四许可的类型为第二预设类型的情况下，撤销所述第四许可，以及基于所述第四许可而颁发的所有许可。

本申请还提供一种密钥授权装置，包括：

第一接收模块，用于接收第二许可请求，其中，所述第二许可请求用于请求授予第二用户对第二请求密钥的第二操作权限；

验证模块，用于利用所述第二许可请求进行验证，其中，所述验证包括：确定所述第二许可请求的发起者是否为许可密钥的所有者，以及所述第二请求密钥是否为所述许可密钥；

生成模块，用于在通过所述验证的情况下，生成第二许可，其中，所述第二许可约定了所述第二用户对所述许可密钥的第二操作权限，所述许可密钥的所有者对所述许可密钥的操作权限包含所述第二操作权限；

颁发模块，用于将所述第二许可颁发给所述第二用户，以使所述第二用户能够将所述第二操作权限中的至少部分权限颁发给第三用户。

在一个实施例中，所述装置还包括：

第二接收模块，用于接收许可密钥包，所述许可密钥包包括：许可密钥的标识；

确定模块，用于在所述许可密钥包合法，并且所述第二许可请求中的第二请求密钥的标识与所述许可密钥的标识一致的情况下，确定所述第二请求密钥为所述许可密钥。

在一个实施例中，还包括：

第三接收模块，用于接收密钥创建请求；

创建模块，用于在所述密钥创建请求的发起者的身份合法的情况下，创建许可密钥；所述许可密钥的所有者为所述密钥创建请求的发起者。

在一个实施例中，所述装置应用于加密机，

所述第二许可包含第一校验码，所述第一校验码由所述加密机利用所述加密机的第一密钥生成；和/或，

所述许可密钥包包含第五校验码，所述第五校验码由所述加密机利用所述加密机的第三密钥生成。

本申请还提供一种密钥授权装置，包括：

发送模块，用于向加密机发送第一许可和第二许可请求，以使所述加密机在接收到所述第一许可和第二许可请求之后，利用所述第一许可和所述第二许可请求进行验证，以及在通过所述验证的情况下，生成第二许可，并将所述第二许可颁发给第二用户，进而使所述第二用户能够将所述第二操作权限中的至少部分权限颁发给第三用户；

其中，所述第一许可约定了第一用户对许可密钥的第一操作权限，所述第二许可请求用于请求授予第二用户对第二请求密钥的第二操作权限；所述验证包括：确定所述第二许可请求的发起者是否为所述第一用户，以及所述第二请求密钥是否为所述许可密钥；所述第二许可约定了所述第二用户对所述许可密钥的第二操作权限，所述第一操作权限包含所述第二操作权限，所述第一许可为所述第二许可的父许可。

附图说明

图1为本申请实施例的一种密钥授权方法的流程图；

图2为许可密钥的所有者先给自己签发许可的流程图；

图3为本申请实施例的一种密钥授权方法的流程图，用于描述加密机利用许可密钥所有者发送的第一许可和第二许可请求给被授权者颁发许可的过程；

图4为本申请实施例的一种密钥授权方法的流程图，用于描述加密机利用许可密钥所有者发送第二许可请求给被授权者颁发许可的过程；

图5为本申请实施例的一种密钥授权方法的流程图，用于描述加密机对撤销请求的发起者的响应过程；

图6为本申请一实施例中一种密钥授权装置的框图；

图7为本申请另一实施例中一种密钥授权装置的框图；

图8为本申请又一实施例中一种密钥授权装置的框图。

具体实施方式

此处参考附图描述本申请的各种方案以及特征。

应理解的是，可以对此处申请的实施例做出各种修改。因此，上述说明书不应该视为限制，而仅是作为实施例的范例。本领域的技术人员将想到在本申请的范围和精神内的其他修改。

包含在说明书中并构成说明书的一部分的附图示出了本申请的实施例，并且与上面给出的对本申请的大致描述以及下面给出的对实施例的详细描述一起用于解释本申请的原理。

通过下面参照附图对给定为非限制性实例的实施例的优选形式的描述，本申请的这些和其它特性将会变得显而易见。

还应当理解，尽管已经参照一些具体实例对本申请进行了描述，但本领域技术人员能够确定地实现本申请的很多其它等效形式。

当结合附图时，鉴于以下详细说明，本申请的上述和其他方面、特征和优势将变得更为显而易见。

此后参照附图描述本申请的具体实施例；然而，应当理解，所申请的实施例仅仅是本申请的实例，其可采用多种方式实施。熟知和/或重复的功能和结构并未详细描述以避免不必要或多余的细节使得本申请模糊不清。因此，本文所申请的具体的结构性和功能性细节并非意在限定，而是仅仅作为权利要求的基础和代表性基础用于教导本领域技术人员以实质上任意合适的详细结构多样地使用本申请。

本说明书可使用词组“在一种实施例中”、“在另一个实施例中”、“在又一实施例中”或“在其他实施例中”，其均可指代根据本申请的相同或不同实施例中的一个或多个。

图1为本申请实施例的一种密钥授权方法的流程图，该密钥授权方法可用于服务器或者加密机，该加密机可以处于服务器侧。以下将以应用在加密机中为例，来对本申请的方案作说明。该方法包括以下步骤s11-s12：

在步骤s11中，接收密钥创建请求；

在步骤s12中，在密钥创建请求的发起者的身份合法的情况下，创建许可密钥；许可密钥的所有者为密钥创建请求的发起者。

在本实施例中，加密机可以接收终端发送的密钥创建请求，然后对密钥创建请求的发起者的身份进行验证。在密钥创建请求的发起者的身份合法的情况下，加密机创建许可密钥。许可密钥的所有者为密钥创建请求的发起者，终端为密钥创建请求的发起者对应的终端。

应理解，本申请实施例中请求的发起者，可以是设备(例如前述的终端)或者设备的用户。相应地，验证发起者的身份是否合法，可以理解为验证发起请求的设备的身份是否合法，或者验证操作该设备的用户的身份是否合法。

在其中一种实现方式中，对密钥创建请求的发起者的身份进行验证过程可被实施为以下步骤a1-a3：

在步骤a1中，接收密钥创建请求的发起者发送的第一公钥包，验证第一公钥包的合法性；

在步骤a2中，在第一公钥包合法的情况下，验证第一公钥包的所有者与密钥创建请求的发起者是否一致；

在步骤a3中，在第一公钥包的所有者与密钥创建请求的发起者一致的情况下，确定密钥创建请求的发起者的身份合法。

合法的公钥包包括校验码(mac值)，校验码是服务器侧的加密机在创建该公钥包时，基于加密机中的一个密钥对公钥包中除校验码之外的其他信息(例如该公钥的所有者id，该公钥的密钥类型和算法、该公钥的长度等)做哈希运算得到的。

假设第一公钥包中原本存储有校验码a。上述步骤a1中，验证第一公钥包的合法性时，可以基于加密机中的密钥对第一公钥包中除校验码以外的信息做哈希运算，得到校验码b；然后确定校验码a和校验码b是否一致，在校验码a和校验码b一致的情况下，确定第一公钥包合法。

加密机通过上述第一公钥包合法性验证的方式，判断本次接收到的第一公钥包是否确实是自己创建的，第一公钥包中的内容是否被篡改过。如果确实是加密机创建的，并且没有被篡改过，加密机就认为本次接收到的第一公钥包是合法的、可以信任的。然后，加密机再利用第一公钥包中的公钥信息去验证密钥创建请求的签名，从而确定密钥创建请求的发起者与第一公钥的所有者是不是同一个人。采用这样的实现方式，可以防止攻击者同时篡改密钥创建请求中的内容(包括密钥创建请求的签名)，以及第一公钥包的内容，提高许可密钥生成和授权过程中的安全性。例如，如果攻击者同时篡改密钥创建请求中的内容和第一公钥包的内容，加密机在利用第一公钥包来验证密钥创建请求的签名时会发现签名验证是可以通过的。在这个时候，加密机会误认为本次的密钥创建请求是身份合法的用户或者设备发起的，为之创建许可密钥，而实际上这个许可密钥却是为攻击者创建的，这就容易为攻击者后续的攻击提供基础。采用上述实现方式可以有效避免该问题。

上述步骤a2中，验证第一公钥包的所有者与密钥创建请求的发起者是否一致时，可通过以下步骤a21-a23进行验证：

在步骤a21中，检查第一公钥包中的第一公钥的所有者id与密钥创建请求中的第三请求密钥的所有者id是否相同；和/或，检查第一公钥包中的第一公钥的指纹与密钥创建请求中密钥创建请求发起者的公钥指纹是否相同；

在步骤a22中，当第一公钥包中的第一公钥的所有者id与密钥创建请求中的第三请求密钥的所有者id相同，且第一公钥包中的第一公钥的指纹与密钥创建请求中密钥创建请求发起者的公钥指纹也相同的情况下，利用第一公钥包中的第一公钥验证密钥创建请求的签名；密钥创建请求的签名为利用密钥创建请求的发起者的私钥计算得到的字符串；

在步骤a23中，密钥创建请求的签名验证通过的情况下，确定第一公钥包的所有者与密钥创建请求的发起者一致。

在验证第一公钥包的所有者与密钥创建请求的发起者是否一致的另一种实现方式中，可以直接利用第一公钥来验证密钥创建请求的签名。示例性地，通过以下步骤a24-a25进行验证：

在步骤a24中，利用第一公钥包中的第一公钥验证密钥创建请求的签名；密钥创建请求的签名为利用密钥创建请求的发起者的私钥计算得到的字符串；

在步骤a25中，密钥创建请求的签名验证通过的情况下，确定第一公钥包的所有者与密钥创建请求的发起者一致。

上述步骤s12中，创建许可密钥的方式可包括以下几种示例性的方式：

方式一

在密钥创建请求中指示的密钥算法为对称密钥算法的情况下，根据对称密钥算法生成的许可密钥；创建许可密钥包。其中，许可密钥包包括：被加密后的许可密钥。示例性地，加密机加密许可密钥可以采用加密机中存储的aes密钥等对称密钥，以及相应的加密算法。

许可密钥包还可以包括：许可密钥id、许可密钥的所有者id、许可密钥的密钥类型和算法、许可密钥的长度、有效时间段等。

另外，许可密钥包还可以包括：校验码。该校验码可以是加密机对许可密钥包中除该校验码之外的其他信息做哈希运算得到的，示例性地可以是哈希值、mac值或hmac值等。

方式二

在密钥创建请求中指示的密钥算法为非对称密钥算法的情况下，根据对称密钥算法生成的许可密钥，许可密钥包括许可公钥和许可私钥；

创建许可密钥包，包括：被加密后的许可私钥。示例性地，加密机加密许可私钥可以采用加密机中存储的aes密钥等对称密钥，以及相应的加密算法。

创建许可密钥公钥包，包括：被加密后的许可公钥。加密机加密许可公钥可以采用加密机中存储的aes密钥等对称密钥，以及相应的加密算法。

应理解，加密机加密许可公钥和许可私钥所采用的密钥及算法可以相同，也可以不同，本申请对此不作限定。

还应理解，许可密钥包、许可密钥公钥包中也可以包括前一种实现方式中的那些可选信息，以及校验码(例如mac值或hmac值等)。该校验码也是加密机对许可密钥包或许可密钥公钥包中除该校验码之外的其他信息做哈希运算得到的。

需要说明的是，加密机可以为很多用户创建许可密钥以及对应的数据包(例如许可密钥包、许可密钥公钥包等)。如果这些数据包都存在加密机中，许可密钥或者许可私钥可以不用加密，也可以加密存储。但采用这样的方式会过多占据加密机的存储空间。在为了节约加密机的存储空间而将这些数据包都存储到加密机外的情况下，为避免许可密钥或许可私钥泄露，需要采用加密机中的aes等对称密钥将其加密后再存储到加密机外部，例如，存储在数据存储系统中。

因此，由加密机来执行前述的创建许可密钥的步骤时，可以将许可密钥包，或者许可密钥包与许可密钥公钥包，进行加密之后存储到服务器侧的数据存储系统中。该数据存储系统与加密机通讯连接，在需要的时候，该数据存储系统可以将这些包再发送给加密机。从而节省了加密机的存储空间。

另外，需要说明的是，在验证公钥包的合法性之前，还可以检查密钥创建请求是否处于有效期内。检查是否处于有效期内的一种实现方式如下：

密钥创建请求中携带时间戳，该时间戳用于指示密钥创建请求的生成时间；在当前时间与时间戳指示的时间差处于预设阈值范围内的情况下，确定密钥创建请求处于有效期内。这里的当前时间可以采用服务器或者加密机在实现该方法时或之前实时获取到时间点，例如实时获取的世界时、国际原子时、协调世界时等。这样的做法可以防止攻击者截获了密钥创建请求之后大量反复向服务器发送该请求，以此来攻击服务器。

上述方案介绍了许可密钥的创建过程，下面，通过一实施例介绍许可密钥的所有者如何签发许可的过程。

本申请公开两种签发许可的实现方法：

方法一：许可密钥的所有者先给自己签发许可，再利用第一许可给代理者签发许可。

方法二：许可密钥的所有者直接给代理者签发许可。

以下将分别描述这两种方法。

关于上述方法一，首先需要介绍许可密钥的所有者先给自己签发许可的过程，如图2所示，许可密钥的所有者先给自己签发许可的过程可被实施为以下步骤s21-s23：

在步骤s21中，接收第一许可请求，其中，该第一许可请求用于请求授予第一用户对第一请求密钥的第一操作权限。

该步骤中，许可密钥的所有者给自己签发许可时，向加密机发送许可请求。加密机接收到一个许可请求，为便于区分，本申请实施例中称之为第一许可请求。该第一许可请求用于请求授予第一用户对第一请求密钥的第一操作权限。

在步骤s22中，在第一许可请求的发起者为许可密钥的所有者，且第一请求密钥为许可密钥的情况下，生成第一许可；其中，第一许可用于指示第一用户对许可密钥的第一操作权限。

在步骤s23中，将第一许可颁发给第一用户。

在其中一种实现方式中，确定第一许可请求的发起者为许可密钥的所有者时，通过以下步骤b1-b4实现：

在步骤b1中，接收第二公钥包和许可密钥包；

在步骤b2中，验证第二公钥包和许可密钥包的合法性；

在步骤b3中，在第二公钥包和许可密钥包都合法的情况下，验证第二公钥包的所有者与许可密钥包的所有者是否一致，以及，利用第二公钥包验证第一许可请求的发起者的身份是否合法；

在步骤b4中，第二公钥包的所有者与许可密钥包的所有者一致且第一许可请求的发起者的身份合法的情况下，确定第一许可请求的发起者为许可密钥的所有者。

需要说明的是，上述步骤的先后顺序可以根据需要进行适应性调整，只要方案整体不矛盾即可。示例性地，步骤b1可以在步骤s21之后执行，也可以与步骤s21一起执行，但必须在生成第一许可的步骤之前执行。又示例性地，验证第二公钥包的所有者与许可密钥包的所有者是否一致的步骤，与利用第二公钥包验证第一许可请求的发起者的身份是否合法的步骤可以一起执行，也可以先后执行，本申请对此不作限定。此外，只要方案的步骤之间不矛盾，本申请实施例中其他步骤的先后顺序亦可以作调整。

上述步骤b3中，利用第二公钥包验证第一许可请求的发起者的身份是否合法的步骤，示例性地可以包括以下步骤b31-b33：

在步骤b31中，检查第二公钥包中的第二公钥的所有者id与第一许可请求中的第一请求密钥的所有者id是否相同；和/或，检查第二公钥包中的第二公钥的指纹与第一许可请求的发起者的公钥指纹是否相同；

在步骤b32中，第二公钥的所有者id与第一许可请求中的第一请求密钥的所有者id相同，且第二公钥包中的第二公钥的指纹与第一许可请求的发起者的公钥指纹相同的情况下，利用第二公钥包中的第二公钥验证第一许可请求的签名；第一许可请求的签名为利用第一许可请求的发起者的私钥计算得到的字符串；

在步骤b33中，第一许可请求的签名验证通过的情况下，确定第一许可请求的发起者的身份合法。

需要说明的是，在利用第二公钥包验证第一许可请求的发起者的身份是否合法的另一种实现方式中，可以直接利用第二公钥来验证第一许可请求的签名。这里的第一许可请求的签名为利用第一许可请求的发起者的私钥计算得到的字符串。该方法与前述的利用个第一公钥验证密钥创建请求的签名的过程类似，此处不再赘述。

还需要说明的是，该第一许可请求也具有有效期，在该第一许可请求处于有效期内的情况下，再执行上述步骤b31或者利用第二公钥来验证第一许可请求的签名的步骤。

检查是否处于有效期内的方法与前述检查密钥创建请求是否处于有效期内的方法类似。其中一种实现方式为：第一许可请求中携带时间戳，该时间戳用于指第一许可请求的生成时间；在当前时间与时间戳的时间差处于预设阈值范围内的情况下，确定第一许可请求处于有效期内。通过设置有效期，可以防止攻击者截获了第一许可请求之后大量反复向服务器发送该请求，以此来攻击服务器。

上述步骤b1-b4所公开的方案能够确定第一许可请求的发起者是否为许可密钥的所有者，从而能够避免非法用户冒充许可密钥的所有者发起第一许可请求，提高了安全性。

上述步骤s22中所涉及的生成第一许可的一种实现方式为：构建第一许可，该第一许可可以包括：第一许可的所有者id、许可密钥的所有者的公钥指纹、许可密钥id、用于描述第一操作权限的许可条款、许可id、父许可id等。在构建第一许可时，加密机可以将第一用户，也是前述实施例中第二公钥的所有者id赋值给第一许可的所有者id，将第二公钥的指纹赋值给许可密钥的所有者的公钥指纹。

由于第一用户就是许可密钥的所有者，也是第一许可请求的发起者，因此第一许可的父许可就是自己。在这种情况下，第一许可中的父许可id和第一许可的许可id相同。另外，第一许可还可以包括：第一许可的颁发者id。加密机可以将许可密钥的所有者id赋值给第一许可的颁发者id。

第一许可还可以包括：第一许可中这些许可信息的校验码(例如mac等)。校验码的计算方法与前面公钥包的校验码的计算方式类似，主要可以用来验证第一许可的合法性。

以上内容便是许可密钥的所有者先给自己签发许可的过程在介绍完许可密钥的所有者给自己签发许可的过程之后，介绍利用第一许可给代理者签发许可的过程。

图3为本申请实施例的一种密钥授权方法的流程图，用于表述加密机利用许可密钥所有者发送的第一许可和第二许可请求给被授权者颁发许可的过程该过程可以示例性地被实施为以下步骤s31-s34。

在步骤s31中，接收第一许可和第二许可请求，其中，第一许可约定了第一用户对许可密钥的第一操作权限，第二许可请求用于请求授予第二用户对第二请求密钥的第二操作权限。

具体的，该步骤中，第一许可即为前述实施例生成的第一许可，第一用户即为该第一许可的所有者，该第一许可中可以携带第一用户的标识，从而使加密机在接收到第一许可之后，可以得知该第一许可的所有者是谁。通过前述实施例可知，许可密钥被创建之后，可以被托管在数据存储服务器/云端上。另外，第一许可中也可以携带许可密钥标识，用于使加密机可以基于该许可密钥标识从数据存储服务器/云端得到对应的许可密钥。

在执行该步骤之前，第一用户会设置许可条款，具体的，可以以许可条款包的形式携带在第二许可请求中。因此，第一用户对第一许可密钥的第一操作权限以及第二许可请求中请求授予第二用户对第二请求密钥的第二操作权限的范围都约定在该许可条款包中。其次，该许可条款包中还可以约定了第二许可请求的有效期，以及许可类型，例如为“继承”类型还是“代理”类型。

在步骤s32中，利用第一许可和第二许可请求进行验证，其中，验证包括：确定第二许可请求的发起者是否为第一用户，以及第二请求密钥是否为许可密钥。

该步骤中，示例性地，确定第二许可请求的发起者是否为第一用户的其中一种实现方式通过执行以下步骤s321-s322来实现：

在步骤s321中，接收第三公钥包；

在步骤s322中，在第三公钥包和第一许可均合法，第二许可请求的签名通过基于第三公钥包进行的验证，并且第三公钥包的所有者与第一许可中的第一用户一致的情况下，确定第二许可请求的发起者为第一用户。

通过该步骤s321-s322，验证第二许可请求的发起者与第一许可的所有者是否为同一用户，从而能够避免非法用户冒充合法授权者对代理者进行授权，提高了安全性。

具体的，验证第三公钥包是否合法时，可以基于加密机中的密钥对第三公钥包中除校验码以外的信息做哈希运算，得到校验码d；然后确定校验码d和第三公钥包中原本存储的校验码c是否一致在校验码d和校验码c一致的情况下，确定第三公钥包合法。

加密机创建各个公钥包、许可的时候，所使用的密钥都是加密机的密钥，可以相同，也可以不同。

另外，第三公钥包包括：第三公钥的所有者标识和第三公钥信息。因此，上述步骤s322中，可以利用其中的第三公钥信息来验证第二许可请求的签名。另外，由于第一许可包括第一用户的标识，因此，上述步骤s322中，可以通过判断第一用户的标识与第三公钥包中第三公钥的所有者标识是否一致来确定第三公钥包的所有者与第一许可中的第一用户是否一致。

另外，在上述步骤s32中，验证第二请求密钥是否为许可密钥一种实现方式为：接收许可密钥包，许可密钥包包括：许可密钥的标识；在许可密钥包合法，并且第二许可请求中的第二请求密钥的标识与许可密钥的标识一致的情况下，确定第二请求密钥为许可密钥。

在前述实施例中已经介绍了创建的许可密钥是一许可密钥包。该许可密钥包创建时，会生成校验码，该校验码可以是基于许可密钥包中除校验码之外的其他信息做哈希运算得到的。因此，由于许可密钥包创建时会生成校验码，可见，关于许可密钥包是否合法，其验证过程与验证第一公钥包是否合法的过程可以类似，也都可以利用加密机的密钥和许可密钥包里的检验码来进行。

在步骤s33中，在通过验证的情况下，生成第二许可，其中，第二许可约定了第二用户对许可密钥的第二操作权限，第一操作权限包含第二操作权限，第一许可为第二许可的父许可。

由于第一用户对许可密钥的第一操作权限中包含了第二用户对请求密钥的第二操作权限，且第一许可为第二许可的父许可，即在第一用户通过第二许可请求对第二用户进行授权之后，第一用户的第一操作权限包含了第二用户获得的第二操作权限，作为授权者的第一用户在向作为代理者的第二用户授权时，由于其可以控制第二操作权限具体的范围，因此，能够通过控制第二操作权限具体的范围来实现对被授权者行为细粒度的控制。可选地，第二操作权限的范围小于第一操作权限。

另外，由于前面已经介绍了关于许可条款包的内容，因此，不难理解的是，利用第一许可和第二许可请求进行验证的验证方式还可以包括对第一操作权限和第二操作权限的范围进行验证。例如，通过许可条款包查看第一操作权限和第二操作权限的范围，在第一操作权限的范围大于或等于第二操作权限的范围的情况下，确定验证通过，在第一操作权限的范围小于第二操作权限的范围的情况下，则确定验证未通过。

在步骤s34中，将第二许可颁发给第二用户，以使第二用户能够将第二操作权限中的至少部分权限颁发给第三用户。

可以理解的是，本步骤中的第二用户可以是某个代理者。该代理者可以利用第二许可向被授权者继续签发许可，具体的签发方式与上述步骤s31-s33的步骤类似。即可以将第一用户替换为代理者身份，将第二用户替换为被授权者身份，来执行上述步骤s31-s33。

生成第二许可的过程与生成第一许可的过程类似，具体的：构建第二许可，该第二许可包括：第二许可的所有者、许可密钥的所有者的公钥指纹、许可密钥id、用于描述第二操作权限的许可条款、许可id、父许可id。其中，第二许可的父许可为第一许可，因此，父许可id为第一许可的id。第二许可还可以包括：第一许可的颁发者(即许可密钥的所有者)。另外，第二许可中还包括校验码(例如mac)。

被授权者获取到颁发者颁发的许可之后，就可以持有该许可去调用存储在服务器/云端的许可密钥，来执行权限范围内的所有可能的操作。

以上为签发许可的方法一，采用该方法一，实现了以下有益效果：

第一用户对许可密钥的第一操作权限中包含了第二用户对请求密钥的第二操作权限，且第一许可为第二许可的父许可，即在第一用户通过第二许可请求对第二用户进行授权之后，第一用户的第一操作权限包含了第二用户获得的第二操作权限，作为授权者的第一用户在向作为代理者的第二用户授权时，由于其可以控制第二操作权限具体的范围，因此，能够通过控制第二操作权限具体的范围来实现对代理者行为的控制。

本申请提供的密钥代理授权方法，可以解决密钥授权链上权限代理的局限性和安全性的问题。该方案基于加密机进行密钥的代理授权，并且使用到各种密码学算法，比如加解密、签名和验证签名等。采用该技术方案可以安全、快速、高效地完成密钥的代理授权，缩减开发周期和成本。

下面，介绍签发许可的方法二，该方法二中，许可密钥的所有者直接向其他用户签发许可，而无需先对自己签发许可。

图4为本申请实施例的一种密钥授权方法的流程图，用于描述加密机利用第二许可请求给被授权者颁发许可的过程，该过程被实施为以下步骤s41-s44。

在步骤s41中，接收第二许可请求，其中，第二许可请求用于请求授予第二用户对第二请求密钥的第二操作权限。

在执行该步骤之前，第一用户会设置许可条款，具体的，可以以许可条款包的形式携带在第二许可请求中，因此，第一用户对第一许可密钥的第一操作权限以及第二许可请求中请求授予第二用户对第二请求密钥的第二操作权限的范围都约定在该许可条款包中。其次，该许可条款包中还约定了第二许可请求的有效期，以及许可类型为“继承”类型还是“代理”类型。在将许可条款以许可条款包的形式携带在第二许可请求中之后，将第二许可请求发送给加密机，加密机接收该第二许可请求。

在步骤s42中，利用第二许可请求进行验证，其中，验证包括：确定第二许可请求的发起者是否为许可密钥的所有者，以及第二请求密钥是否为许可密钥；

加密机利用第二许可请求进行验证，具体验证方式为：确定第二许可请求的发起者是否为许可密钥的所有者，以及第二请求密钥是否为许可密钥。

其中，确定第二许可请求的发起者是否为许可密钥的所有者的其中一种实现方式为：接收第四公钥包；在第四公钥包合法，第二许可请求的签名通过基于第四公钥包进行的验证，并且第四公钥包的所有者与第二许可请求的发起者一致的情况下，确定第二许可请求的发起者为许可密钥的所有者。

具体的，验证第四公钥包是否合法时，可以基于加密机中的密钥对第四公钥包中除校验码以外的信息做哈希运算，得到校验码f；然后确定校验码f和第四公钥包中原本存储的校验码e是否一致在校验码f和校验码e一致的情况下，确定第四公钥包合法。

需要说明的是，该第四公钥包可以与上述第三公钥包相同，也可以不同，另外，第四公钥包包括：第四公钥的所有者标识和第四公钥信息。因此，可以利用其中的第四公钥信息来验证第二许可请求的签名。

验证第二请求密钥是否为许可密钥一种实现方式为：接收许可密钥包，许可密钥包包括：许可密钥的标识；在许可密钥包合法，并且第二许可请求中的第二请求密钥的标识与许可密钥的标识一致的情况下，确定第二请求密钥为许可密钥。

在步骤s43中，在通过验证的情况下，生成第二许可，其中，第二许可约定了第二用户对许可密钥的第二操作权限，许可密钥的所有者对许可密钥的操作权限包含第二操作权限；

生成第二许可的过程与生成第一许可的过程类似，具体的：构建第二许可，该第二许可包括：第二许可的所有者、许可密钥的所有者的公钥指纹、许可密钥id、用于描述第二操作权限的许可条款、许可id、父许可id。其中，第二许可的父许可为第一许可，因此，父许可id为第一许可的id。第二许可还可以包括：第一许可的颁发者(即许可密钥的所有者)。另外，第二许可中还包括校验码(mac)。

在步骤s44中，将第二许可颁发给第二用户，以使第二用户能够将第二操作权限中的至少部分权限颁发给第三用户。

另外，通过上述示例可知，第一许可、第二许可以及许可密钥包中都包含校验码，可以用来验证其自身的合法性。因此，在一个实施例中，在方法应用于加密机的情况下，第二许可包含第一校验码，第一校验码由加密机利用加密机的第一密钥生成；在对第二许可的合法性进行验证时，利用加密机的第一密钥以及第二许可中除第一校验码之外的其他信息进行哈希计算得到第二校验码，将第一校验码和第二校验码进行比对，在比对一致的情况下，确定第二许可的合法性通过。

第一许可包含第三校验码，第三校验码由加密机利用加密机的第二密钥生成；在对第一许可的合法性进行验证时，利用加密机的第二密钥以及第一许可中除第三校验码之外的其他信息进行哈希计算得到第四校验码，将第三校验码和第四校验码进行比对，在比对一致的情况下，确定第一许可的合法性通过。

许可密钥包包含第五校验码，第五校验码由加密机利用加密机的第三密钥生成；在对许可密钥包的合法性进行验证时，利用加密机的第三密钥以及第一许可中除第五校验码之外的其他信息进行哈希计算得到第六校验码将第五校验码和第六校验码进行比对，在比对一致的情况下，确定许可密钥包的合法性通过。

为了进一步提高密钥所有者对代理授权链路的控制能力，本申请中，还提供了关于撤销许可的技术方案，图5为本申请实施例的一种密钥授权方法的流程图，用于描述加密机对撤销请求的发起者的响应过程，具体可被实施为以下步骤s51-s53：

在步骤s51中，接收撤销请求，撤回请求用于请求撤销第四许可；

在步骤s52中，在撤销请求的发起者为第四许可的颁发者，以及第四许可的类型为第一预设类型的情况下，撤销第四许可；

在步骤s53中，在撤销请求的发起者为第四许可的颁发者，以及第四许可的类型为第二预设类型的情况下，撤销第四许可，以及基于第四许可而颁发的所有许可。

本实施例中，第四许可可以是已经颁发出去的任意一个许可。加密机/服务器接收到撤销请求发起者所在的终端发送的用于请求撤销第四许可的撤销请求之后，会确定撤销请求的发起者是否为第四许可的颁发者。另外，前述实施例中所涉及的许可条款包中还约定了许可类型，具体的，许可类型可以为“继承”类型或者“代理”类型。示例性地，代理类型可以是指第一用户为签发者，第二用户为代理者，第三用户为实际用户的情况，或者，第二用户一级代理者，第三用户为二级代理者，第四用户为实际用户的情况等。密钥所有者授予代理者对许可密钥的第二操作权限，从而委托代理者将第二权限中的至少部分权限颁发给其他代理者或者实际用户。而继承类型可以是指第二用户和第三用户都是实际用户，第二用户具备将第二操作权限中的至少部分权限颁发给第三用户的能力。

许可类型为代理类型时，第一用户希望撤销颁发给某个用户(例如第二用户)第四许可，而不撤销基于第四许可而颁发的其他许可，从而既能够使第二用户丧失代理的能力，又保障了其他用户(第三用户或第四用户)的权益。许可类型为继承类型时，则在撤销第四许可的同时，可以同时撤销基于第四许可而颁发的所有许可。即本实施例中，第一预设类型可以为代理类型，第二预设类型可以为继承类型。

在确定撤销请求的发起者是否为第四许可的颁发者时，通过以下步骤c1-c2实现：

在步骤c1中，接收第五公钥包；

在步骤c2中，在第五公钥包和第四许可均合法，撤销请求的签名通过基于第五公钥包进行的验证，并且第五公钥包的所有者与第四许可中的许可颁发者一致的情况下，确定撤销请求的发起者为第四许可的颁发者。

关于上述步骤s53中涉及的撤销基于第四许可而颁发的所有许可，本申请示例性给出以下两种不同的实现方式：

实现方式1：

每一个许可分别指示对应的许可密钥、许可颁发者和许可所有者；

撤销基于第四许可而颁发的所有许可，包括：查找所有第五许可，第五许可指示的许可颁发者与第四许可的所有者一致，并且第五许可指示的许可密钥与第四许可指示的许可密钥一致；

撤销第五许可。

由于生成的许可分别指示对应的许可密、许可的颁发者和许可的所有者，因此，可以通过遍历其他许可，判断其他许可中指示的许可颁发者与第四许可的所有者是否一致，且其他许可指示的许可密钥与第四许可所指示的许可密钥也一致，如果一直，则认定该许可为基于第四许可颁发的许可，因此，需要撤销该许可。

实现方式2：

每一个许可分别指示该许可的标识和父许可标识；

撤销基于第四许可而颁发的所有许可，包括：

查找所有第六许可，第六许可指示的父许可标识与第四许可的标识一致；

撤销第六许可。

在该方式中，每个许可分别指示该许可的标识和父许可标识，因此，可以查找遍历其他许可中指示的父许可是否与第四许可的标识一致；如果一致，则说明该许可为基于第四许可颁发的许可，需要撤销该许可。

可以理解的是，还可以继续向下追溯，直到查找不到下一级许可为止，举例而言，假设用户g基于许可g给用户h颁发了许可h，用户h基于许可h给用户i颁发了许可i，用户i基于许可i给用户j颁发了许可j，用户j没有继续往下颁发许可。那么，假设用户g需要收回颁发给用户h的许可h，那么，向加密机发送撤销许可h的请求，加密机会基于该撤销请求判断许可是否为用户g颁发的请求，如果是，则撤销许可h，并且基于上述实现方式1或实现方式2进行追溯，将基于许可h而颁发的许可i和j都撤销。因为用户j没有继续往下颁发许可，因此，将许可j撤销掉则停止追溯。

需要说明的是，除了许可密钥的所有者之外，各个被授权者也可以基于上述方式撤销其所颁发的许可，例如上述示例中的用户h，也可以通过上述方式将基于许可h而颁发的许可i和j都撤销。

还需要说明的是，上述方案中，在撤销第五许可或第六许可之前，可以先验证第五许可或第六许可是否合法，在验证其合法之后再撤销。通过这样的方式，可以避免攻击者仿冒第五许可/第六许可导致服务器或加密机错误地撤销了不该撤销的许可的问题。

本申请中，对于服务器/加密机来说，其接收到许可请求的时候，请求中指示的某些信息是不是与公钥包、许可密钥包中的一致，属于未知的，需要判断才能确定，因此，本申请中，在确定请求中指示的信息与许可证指示的同类信息用不同的概念做了区分，但是可以理解的是，当用户合法时，这些用不同概念区分开的同类信息实质上是一致的。

本申请还提供一种密钥授权方法，执行主体可以为第一用户所使用的终端设备，包括：

向加密机发送第一许可和第二许可请求，以使加密机在接收到第一许可和第二许可请求之后，利用第一许可和第二许可请求进行验证，以及在通过验证的情况下，生成第二许可，并将第二许可颁发给第二用户，进而使第二用户能够将第二操作权限中的至少部分权限颁发给第三用户；

其中，第一许可约定了第一用户对许可密钥的第一操作权限，第二许可请求用于请求授予第二用户对第二请求密钥的第二操作权限；验证包括：确定第二许可请求的发起者是否为第一用户，以及第二请求密钥是否为许可密钥；第二许可约定了第二用户对许可密钥的第二操作权限，第一操作权限包含第二操作权限，第一许可为第二许可的父许可。

此外，本申请还提供一种加密机，包括：

处理器；

用于存储处理器中可执行指令的存储器；

其中，处理器被配置为：

执行加密机所对应的任一实施例所涉及的密钥授权方法。

本申请还提供一种终端，包括：

处理器；

用于存储处理器中可执行指令的存储器；

其中，处理器被配置为：

向加密机发送第一许可和第二许可请求以使加密机在接收到第一许可和第二许可请求之后，利用第一许可和第二许可请求进行验证，以及在通过验证的情况下，生成第二许可，并将第二许可颁发给第二用户，进而使第二用户能够将第二操作权限中的至少部分权限颁发给第三用户；

其中，第一许可约定了第一用户对许可密钥的第一操作权限，第二许可请求用于请求授予第二用户对第二请求密钥的第二操作权限；验证包括：确定第二许可请求的发起者是否为第一用户，以及第二请求密钥是否为许可密钥；第二许可约定了第二用户对许可密钥的第二操作权限，第一操作权限包含第二操作权限，第一许可为第二许可的父许可。

本申请还提供一种非临时性计算机可读存储介质，当存储介质中的指令由加密机中的处理器执行时，能够执行加密机所对应的任一实施例所涉及的密钥授权方法；

当存储介质中的指令由终端中的处理器执行时，能够执行一种密钥授权方法，包括：

向加密机发送第一许可和第二许可请求，以使加密机在接收到第一许可和第二许可请求之后，利用第一许可和第二许可请求进行验证，以及在通过验证的情况下，生成第二许可，并将第二许可颁发给第二用户，进而使第二用户能够将第二操作权限中的至少部分权限颁发给第三用户；

其中，第一许可约定了第一用户对许可密钥的第一操作权限，第二许可请求用于请求授予第二用户对第二请求密钥的第二操作权限；验证包括：确定第二许可请求的发起者是否为第一用户，以及第二请求密钥是否为许可密钥；第二许可约定了第二用户对许可密钥的第二操作权限，第一操作权限包含第二操作权限，第一许可为第二许可的父许可。

图6为本申请实施例的一种密钥授权装置的框图，用于加密机，如图6所示，该装置包括以下模块：

第一接收模块61，用于接收第一许可和第二许可请求，其中，第一许可约定了第一用户对许可密钥的第一操作权限，第二许可请求用于请求授予第二用户对第二请求密钥的第二操作权限；

验证模块62，用于利用第一许可和第二许可请求进行验证，其中，验证包括：确定第二许可请求的发起者是否为第一用户，以及第二请求密钥是否为许可密钥；

生成模块63，用于在通过验证的情况下，生成第二许可，其中，第二许可约定了第二用户对许可密钥的第二操作权限，第一操作权限包含第二操作权限，第一许可为第二许可的父许可；

颁发模块64，用于将第二许可颁发给第二用户，以使第二用户能够将第二操作权限中的至少部分权限颁发给第三用户。

在一个实施例中，如图7所示，装置还包括：

第二接收模块71，用于接收第三公钥包；

第一确定模块72，用于在第三公钥包和第一许可均合法，第二许可请求的签名通过基于第三公钥包进行的验证，并且第三公钥包的所有者与第一许可中的第一用户一致的情况下，确定第二许可请求的发起者为第一用户。

在一个实施例中，装置还包括：

第三接收模块，用于接收许可密钥包，许可密钥包包括：许可密钥的标识；

第二确定模块，用于在许可密钥包合法，并且第二许可请求中的第二请求密钥的标识与许可密钥的标识一致的情况下，确定第二请求密钥为许可密钥。

在一个实施例中，第一许可基于以下方式生成：

接收第一许可请求，第一许可请求用于请求授予第一用户对第一请求密钥的第一操作权限；

在第一许可请求的发起者为许可密钥的所有者，且第一请求密钥为许可密钥的情况下，生成第一许可。

在一个实施例中，装置还包括：

第四接收模块，用于接收第二公钥包和许可密钥包；

第三确定模块，用于在第二公钥包和许可密钥包均合法，第一许可请求的签名通过基于第二公钥包进行的验证，以及，第二公钥包的所有者与许可密钥包的所有者一致的情况下，确定第一许可请求的发起者为许可密钥的所有者。

在一个实施例中，还包括：

第五接收模块，用于接收密钥创建请求；

创建模块，用于在密钥创建请求的发起者的身份合法的情况下，创建许可密钥；许可密钥的所有者为密钥创建请求的发起者。

在一个实施例中，装置应用于加密机，

第二许可包含第一校验码，第一校验码由加密机利用加密机的第一密钥生成；和/或，

第一许可包含第三校验码，第三校验码由加密机利用加密机的第二密钥生成；和/或，

许可密钥包包含第五校验码，第五校验码由加密机利用加密机的第三密钥生成。

在一个实施例中，还包括：

第六接收模块，用于接收撤销请求，撤回请求用于请求撤销第四许可；

第一撤销模块，用于在撤销请求的发起者为第四许可的颁发者，以及第四许可的类型为第一预设类型的情况下，撤销第四许可；

第二撤销模块，用于在撤销请求的发起者为第四许可的颁发者，以及第四许可的类型为第二预设类型的情况下，撤销第四许可，以及基于第四许可而颁发的所有许可。

图8为本申请实施例的一种密钥授权装置的框图，用于加密机，如图8所示，该装置包括以下模块：

第一接收模块81，用于接收第二许可请求，其中，第二许可请求用于请求授予第二用户对第二请求密钥的第二操作权限；

验证模块82，用于利用第二许可请求进行验证，其中，验证包括：确定第二许可请求的发起者是否为许可密钥的所有者，以及第二请求密钥是否为许可密钥；

生成模块83，用于在通过验证的情况下，生成第二许可，其中，第二许可约定了第二用户对许可密钥的第二操作权限，许可密钥的所有者对许可密钥的操作权限包含第二操作权限；

颁发模块84，用于将第二许可颁发给第二用户，以使第二用户能够将第二操作权限中的至少部分权限颁发给第三用户。

在一个实施例中，装置还包括：

第二接收模块，用于接收许可密钥包，许可密钥包包括：许可密钥的标识；

确定模块，用于在许可密钥包合法，并且第二许可请求中的第二请求密钥的标识与许可密钥的标识一致的情况下，确定第二请求密钥为许可密钥。

在一个实施例中，还包括：

第三接收模块，用于接收密钥创建请求；

创建模块，用于在密钥创建请求的发起者的身份合法的情况下，创建许可密钥；许可密钥的所有者为密钥创建请求的发起者。

在一个实施例中，装置应用于加密机，

第二许可包含第一校验码，第一校验码由加密机利用加密机的第一密钥生成；和/或，

许可密钥包包含第五校验码，第五校验码由加密机利用加密机的第三密钥生成。

本申请还提供一种密钥授权装置，包括：

发送模块，用于向加密机发送第一许可和第二许可请求，以使加密机在接收到第一许可和第二许可请求之后，利用第一许可和第二许可请求进行验证，以及在通过验证的情况下，生成第二许可，并将第二许可颁发给第二用户，进而使第二用户能够将第二操作权限中的至少部分权限颁发给第三用户；

其中，第一许可约定了第一用户对许可密钥的第一操作权限，第二许可请求用于请求授予第二用户对第二请求密钥的第二操作权限；验证包括：确定第二许可请求的发起者是否为第一用户，以及第二请求密钥是否为许可密钥；第二许可约定了第二用户对许可密钥的第二操作权限，第一操作权限包含第二操作权限，第一许可为第二许可的父许可。

以上实施例仅为本申请的示例性实施例，不用于限制本申请，本申请的保护范围由权利要求书限定。本领域技术人员可以在本申请的实质和保护范围内，对本申请做出各种修改或等同替换，这种修改或等同替换也应视为落在本申请的保护范围内。