CN113162762A

CN113162762A - Key authorization method, encryption machine, terminal and storage medium

Info

Publication number: CN113162762A
Application number: CN202110416975.2A
Authority: CN
Inventors: 孙吉平; 黄梦龙
Original assignee: Beijing Senseshield Technology Co Ltd
Current assignee: Beijing Senseshield Technology Co Ltd
Priority date: 2021-04-16
Filing date: 2021-04-16
Publication date: 2021-07-23
Anticipated expiration: 2041-04-16
Also published as: CN113162762B

Abstract

The application discloses a secret key authorization method, an encryption machine and a terminal. The method comprises the following steps: receiving a first license and a second license request; verifying with the first license and the second license request; generating a second license under the condition of passing the verification, wherein the second license contracts a second operation right of a second user on the license key, the first operation right comprises the second operation right, and the first license is a parent license of the second license; and issuing a second license to the second user to enable the second user to issue at least part of the second operating right to the third user. By adopting the scheme provided by the application, the first operation authority of the first user comprises the second operation authority obtained by the second user, and when the first user serving as an authorizer authorizes the second user serving as an agent, the first user can control the specific range of the second operation authority, so that the control on the behavior of the agent can be realized by controlling the specific range of the second operation authority.

Description

Key authorization method, encryption machine, terminal and storage medium

Technical Field

The present application relates to the field of key management, and in particular, to a key authorization method and product.

Background

Key management is an important part of cryptographic techniques. In modern cryptography, in addition to cryptology and cryptanalysis, a key management is also independently developed. The key management comprises the links of key generation, distribution, injection, storage, destruction and the like, and the most important of the key management is proxy authorization management of the key. The proxy re-encryption is a public key encryption system with the function of decrypting the authority proxy.

In the conventional proxy re-encryption scheme, the proxy can convert all the ciphertext of the authorizer into the ciphertext for the authorizee. However, after authorization, the authorizer has no control capability on the behavior of the agent, which is a technical problem to be solved urgently.

Disclosure of Invention

An object of the embodiments of the present application is to provide a key authorization method, an encryption apparatus, and a terminal, which are used to control the behavior of an agent after an authorizer authorizes the agent.

In order to solve the technical problem, the embodiment of the application adopts the following technical scheme: a method of key authorization, comprising:

receiving a first permission and a second permission request, wherein the first permission agrees with a first operation right of a first user to a permission key, and the second permission request is used for requesting to grant a second operation right of a second user to a second request key;

performing a validation with the first license and the second license request, wherein the validation comprises: determining whether an originator of the second license request is the first user and whether the second request key is the license key;

generating a second license when the verification is passed, wherein the second license contracts a second operation right of the second user on the license key, the first operation right comprises the second operation right, and the first license is a parent license of the second license;

and issuing the second license to the second user so that the second user can issue at least part of the second operation right to a third user.

The beneficial effect of this application lies in: the first operation authority of the first user on the license key comprises a second operation authority of the second user on the request key, and the first license is a parent license of the second license, namely the first operation authority of the first user comprises the second operation authority obtained by the second user after the first user authorizes the second user through the second license request.

In one embodiment, the method further comprises:

receiving a third public key packet;

and determining that the initiator of the second license request is the first user when the third public key packet and the first license are both legal, the signature of the second license request passes verification based on the third public key packet, and the owner of the third public key packet is consistent with the first user in the first license.

The beneficial effect of this embodiment lies in: and receiving the third public key packet, and determining whether the initiator of the second permission request is the first user or not through the third public key packet, namely verifying whether the initiator of the second permission request and the owner of the first permission are the same user or not, so that the illegal user can be prevented from pretending to be a legal authorizer to authorize the agent, and the safety is improved.

In one embodiment, the method further comprises:

receiving a license key package, the license key package comprising: an identification of a license key;

and determining the second request key as the license key under the condition that the license key package is legal and the identification of the second request key in the second license request is consistent with the identification of the license key.

In one embodiment, the first license is generated based on:

receiving a first permission request, wherein the first permission request is used for requesting to grant a first operation right of a first user to a first request key;

generating a first license if an originator of the first license request is an owner of a license key and the first request key is the license key.

In one embodiment, the method further comprises:

receiving a second public key package and a license key package;

and determining that the initiator of the first license request is the owner of the license key under the conditions that the second public key package and the license key package are both legal, the signature of the first license request passes the verification based on the second public key package, and the owner of the second public key package is consistent with the owner of the license key package.

The beneficial effect of this embodiment lies in: and receiving the second public key packet and the license key packet, and determining that the initiator of the first license request is the owner of the license key under the condition that the owner of the second public key packet is consistent with the owner of the license key packet, so that the condition that an illegal user pretends to be the owner of the license key can be avoided, and the safety is improved.

In one embodiment, further comprising:

receiving a key creation request;

under the condition that the identity of the initiator of the key creation request is legal, creating a permission key; the owner of the license key is the originator of the key creation request.

In one embodiment, the method is applied to an encryption engine,

the second license includes a first check code generated by the encryption engine using a first key of the encryption engine; and/or the presence of a gas in the gas,

the first license includes a third check code generated by the encryption engine using a second key of the encryption engine; and/or the presence of a gas in the gas,

the license key package contains a fifth check code generated by the encryption engine using a third key of the encryption engine.

In one embodiment, further comprising:

receiving a revoke request for requesting revoking of the fourth license;

revoking the fourth license if the originator of the revoke request is the issuer of the fourth license and the type of the fourth license is a first preset type; or,

revoking the fourth license and all licenses issued based on the fourth license if the originator of the revoke request is the issuer of the fourth license and the type of the fourth license is a second preset type.

The beneficial effect of this embodiment lies in: the authorizer can revoke the permission issued by the authorizer based on the revoking request or revoke all permissions related to the permission issued by the authorizer, so that the control capability of the authorizer on the behaviors of the agent and other authorizers is further improved.

The application also provides a key authorization method, which comprises the following steps:

receiving a second permission request, wherein the second permission request is used for requesting to grant a second operation right of a second user to a second request key;

performing a verification using the second permission request, wherein the verification comprises: determining whether an originator of the second license request is an owner of a license key and whether the second request key is the license key;

generating a second license when the verification is passed, wherein the second license contracts a second operation right of the second user on the license key, and the operation right of the owner of the license key on the license key comprises the second operation right;

In one embodiment, the method further comprises:

In one embodiment, further comprising:

receiving a key creation request;

In one embodiment, the method is applied to an encryption engine,

sending a first license and a second license request to an encryption machine so that the encryption machine can verify by using the first license and the second license request after receiving the first license and the second license request, and if the verification is passed, generating a second license and issuing the second license to a second user so that the second user can issue at least part of the second operation right to a third user;

the first permission agrees with a first operation permission of a first user to a permission key, and the second permission request is used for requesting to grant a second operation permission of a second user to a second request key; the verification comprises: determining whether an originator of the second license request is the first user and whether the second request key is the license key; the second license contracts second operation authority of the second user on the license key, the first operation authority comprises the second operation authority, and the first license is a parent license of the second license.

The present application further provides an encryption apparatus, including:

a processor;

a memory for storing executable instructions in the processor;

wherein the processor is configured to:

and executing the key authorization method according to any embodiment corresponding to the encryption machine.

The present application further provides a terminal, including:

a processor;

a memory for storing executable instructions in the processor;

wherein the processor is configured to:

sending a first license and a second license request to an encryption machine, so that the encryption machine performs verification by using the first license and the second license request after receiving the first license and the second license request, generates a second license and issues the second license to a second user if the verification is passed, and further enables the second user to issue at least part of the second operation right to a third user;

The application also provides a non-transitory computer readable storage medium, wherein when instructions in the storage medium are executed by a processor in an encryption machine, the storage medium can execute a key authorization method according to any embodiment corresponding to the encryption machine;

the instructions in the storage medium, when executed by a processor in a terminal, are capable of performing a key authorization method comprising:

The present application further provides a key authorization apparatus, including:

the device comprises a first receiving module, a second receiving module and a third receiving module, wherein the first receiving module is used for receiving a first permission and a second permission request, the first permission agrees with a first operation permission of a first user to a permission key, and the second permission request is used for requesting to grant a second operation permission of the second user to a second request key;

a verification module configured to perform verification using the first license and the second license request, wherein the verification includes: determining whether an originator of the second license request is the first user and whether the second request key is the license key;

a generating module, configured to generate a second license if the verification is passed, where the second license contracts a second operation right of the second user to the license key, the first operation right includes the second operation right, and the first license is a parent license of the second license;

an issuing module, configured to issue the second license to the second user, so that the second user can issue at least part of the second operation right to a third user.

In one embodiment, the apparatus further comprises:

the second receiving module is used for receiving the third public key packet;

a first determining module, configured to determine that an initiator of the second license request is the first user when the third public key package and the first license are both legal, a signature of the second license request passes verification performed based on the third public key package, and an owner of the third public key package is consistent with the first user in the first license.

In one embodiment, the apparatus further comprises:

a third receiving module, configured to receive a license key package, where the license key package includes: an identification of a license key;

and a second determining module, configured to determine that the second request key is the license key when the license key package is legal and an identifier of the second request key in the second license request is consistent with the identifier of the license key.

In one embodiment, the first license is generated based on:

In one embodiment, the apparatus further comprises:

a fourth receiving module, configured to receive the second public key package and the license key package;

and a third determining module, configured to determine that an initiator of the first license request is an owner of the license key when the second public key package and the license key package are both legal, the signature of the first license request passes verification performed based on the second public key package, and an owner of the second public key package is consistent with an owner of the license key package.

In one embodiment, further comprising:

a fifth receiving module, configured to receive a key creation request;

a creation module configured to create a license key if an identity of an initiator of the key creation request is legitimate; the owner of the license key is the originator of the key creation request.

In one embodiment, the apparatus is applied to an encryption engine,

In one embodiment, further comprising:

a sixth receiving module, configured to receive a revoke request, where the revoke request is used to request to revoke the fourth license;

a first revoking module, configured to revoke the fourth license if an initiator of the revoking request is an issuer of the fourth license and a type of the fourth license is a first preset type;

a second revoking module for revoking the fourth license and all licenses issued based on the fourth license if an initiator of the revoking request is an issuer of the fourth license and the type of the fourth license is a second preset type.

the first receiving module is used for receiving a second permission request, wherein the second permission request is used for requesting to grant a second operation right of a second user to a second request key;

a verification module configured to perform verification using the second permission request, wherein the verification includes: determining whether an originator of the second license request is an owner of a license key and whether the second request key is the license key;

a generating module, configured to generate a second license if the verification is passed, where the second license contracts a second operation right of the second user to the license key, and an operation right of an owner of the license key to the license key includes the second operation right;

In one embodiment, the apparatus further comprises:

a second receiving module, configured to receive a license key package, where the license key package includes: an identification of a license key;

a determining module, configured to determine that the second request key is the license key when the license key package is legal and an identifier of the second request key in the second license request is consistent with the identifier of the license key.

In one embodiment, further comprising:

a third receiving module, configured to receive a key creation request;

In one embodiment, the apparatus is applied to an encryption engine,

the sending module is used for sending a first license and a second license request to the encryption machine, so that the encryption machine performs verification by using the first license and the second license request after receiving the first license and the second license request, generates a second license and issues the second license to a second user if the verification is passed, and further enables the second user to issue at least part of the second operation right to a third user;

Drawings

Fig. 1 is a flowchart of a key authorization method according to an embodiment of the present application;

FIG. 2 is a flow chart of the owner of the license key issuing a license to himself;

FIG. 3 is a flowchart of a key authorization method according to an embodiment of the present application, describing a process in which an encryptor issues a license to an authorized person using a first license request and a second license request sent by a license key owner;

FIG. 4 is a flowchart of a key authorization method according to an embodiment of the present application, describing a process in which an encryptor issues a license to an authorized person by sending a second license request to a license key owner;

fig. 5 is a flowchart of a key authorization method according to an embodiment of the present application, which is used to describe a response process of an encryptor to an initiator of a revocation request;

FIG. 6 is a block diagram of a key authorization apparatus according to an embodiment of the present application;

FIG. 7 is a block diagram of a key authorization apparatus according to another embodiment of the present application;

fig. 8 is a block diagram of a key authorization apparatus according to another embodiment of the present application.

Detailed Description

Various aspects and features of the present application are described herein with reference to the drawings.

It will be understood that various modifications may be made to the embodiments of the present application. Accordingly, the foregoing description should not be construed as limiting, but merely as exemplifications of embodiments. Those skilled in the art will envision other modifications within the scope and spirit of the application.

The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate embodiments of the application and, together with a general description of the application given above and the detailed description of the embodiments given below, serve to explain the principles of the application.

These and other characteristics of the present application will become apparent from the following description of preferred forms of embodiment, given as non-limiting examples, with reference to the attached drawings.

It is also to be understood that although the present application has been described with reference to some specific examples, those skilled in the art are able to ascertain many other equivalents to the practice of the present application.

The above and other aspects, features and advantages of the present application will become more apparent in view of the following detailed description when taken in conjunction with the accompanying drawings.

Specific embodiments of the present application are described hereinafter with reference to the accompanying drawings; however, it is to be understood that the disclosed embodiments are merely exemplary of the application, which can be embodied in various forms. Well-known and/or repeated functions and constructions are not described in detail to avoid obscuring the application of unnecessary or unnecessary detail. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a basis for the claims and as a representative basis for teaching one skilled in the art to variously employ the present application in virtually any appropriately detailed structure.

The specification may use the phrases "in one embodiment," "in another embodiment," "in yet another embodiment," or "in other embodiments," which may each refer to one or more of the same or different embodiments in accordance with the application.

Fig. 1 is a flowchart of a key authorization method according to an embodiment of the present application, where the key authorization method is applicable to a server or an encryption apparatus, and the encryption apparatus may be located on a server side. The scheme of the present application will be described below by taking an application to an encryption machine as an example. The method includes the following steps S11-S12:

in step S11, a key creation request is received;

in step S12, in a case where the identity of the originator of the key creation request is legitimate, a license key is created; the owner of the license key is the originator of the key creation request.

In this embodiment, the encryption engine may receive a key creation request sent by the terminal, and then verify the identity of an initiator of the key creation request. In the case where the identity of the originator of the key creation request is legitimate, the encryption engine creates a license key. The owner of the license key is the initiator of the key creation request, and the terminal is the terminal corresponding to the initiator of the key creation request.

It should be understood that the initiator of the request in the embodiment of the present application may be a device (e.g., the aforementioned terminal) or a user of the device. Accordingly, verifying whether the identity of the initiator is legitimate may be understood as verifying whether the identity of the device that initiated the request is legitimate, or verifying whether the identity of the user operating the device is legitimate.

In one implementation, the process of verifying the identity of the originator of the key creation request may be implemented as the following steps a 1-A3:

in step a1, receiving a first public key package sent by an initiator of a key creation request, and verifying the validity of the first public key package;

in step a2, in the case where the first public key package is legitimate, verifying whether the owner of the first public key package agrees with the originator of the key creation request;

in step a3, in the case where the owner of the first public key package agrees with the originator of the key creation request, it is determined that the identity of the originator of the key creation request is legitimate.

The legal public key packet includes a check code (MAC value), which is obtained by performing a hash operation on information (e.g., an owner ID of the public key, a key type and an algorithm of the public key, a length of the public key, etc.) in the public key packet, except for the check code, based on a key in the encryption apparatus when the encryption apparatus on the server side creates the public key packet.

It is assumed that the first public key package originally stores the check code a. In the step a1, when verifying the validity of the first public key package, hash operation may be performed on information in the first public key package, except for the check code, based on the key in the encryption engine, to obtain the check code b; and then determining whether the check code a is consistent with the check code b, and determining that the first public key packet is legal under the condition that the check code a is consistent with the check code b.

The encryption machine judges whether the received first public key packet is actually created by the encryption machine or not and whether the content in the first public key packet is tampered or not in a mode of verifying the validity of the first public key packet. If the first public key packet is really created by the encryption machine and is not tampered, the encryption machine considers that the first public key packet received this time is legal and can be trusted. The encryption engine then re-uses the public key information in the first public key package to verify the signature of the key creation request, thereby determining that the originator of the key creation request is not the same person as the owner of the first public key. By adopting the implementation mode, an attacker can be prevented from simultaneously tampering the content in the key creation request (including the signature of the key creation request) and the content of the first public key packet, and the safety in the license key generation and authorization process is improved. For example, if an attacker tampers with both the content in the key creation request and the content of the first public key package, the encryptor may find the signature verification to be acceptable when verifying the signature of the key creation request using the first public key package. At this time, the encryption machine may misunderstand that the key creation request of this time is initiated by a user or device with a legitimate identity, and create a license key for the user or device, and actually, the license key is created for an attacker, which easily provides a basis for subsequent attacks of the attacker. The problem can be effectively avoided by adopting the implementation mode.

In the above step a2, when verifying whether the owner of the first public key package agrees with the originator of the key creation request, the verification can be performed by the following steps a21-a 23:

in step a21, it is checked whether the owner ID of the first public key in the first public key package is the same as the owner ID of the third request key in the key creation request; and/or checking whether the fingerprint of the first public key in the first public key packet is the same as the fingerprint of the public key of the key creation request initiator in the key creation request;

in step a22, in the case that the owner ID of the first public key in the first public key package is the same as the owner ID of the third request key in the key creation request, and the fingerprint of the first public key in the first public key package is also the same as the public key fingerprint of the key creation request initiator in the key creation request, verifying the signature of the key creation request by using the first public key in the first public key package; the signature of the key creation request is a character string calculated by using a private key of an initiator of the key creation request;

in step a23, in the case where the signature verification of the key creation request passes, it is determined that the owner of the first public key package is consistent with the originator of the key creation request.

In another implementation of verifying whether the owner of the first public key package is consistent with the originator of the key creation request, the signature of the key creation request may be verified directly with the first public key. Illustratively, verification is performed by the following steps A24-A25:

in step a24, verifying the signature of the key creation request with the first public key in the first public key package; the signature of the key creation request is a character string calculated by using a private key of an initiator of the key creation request;

in step a25, in the case where the signature verification of the key creation request passes, it is determined that the owner of the first public key package is consistent with the originator of the key creation request.

In the above step S12, the ways of creating the license key may include the following exemplary ways:

in a first mode

Under the condition that the key algorithm indicated in the key creation request is a symmetric key algorithm, a license key is generated according to the symmetric key algorithm; a license key package is created. Wherein the license key package includes: an encrypted license key. For example, the encryptor encryption license key may use a symmetric key such as an AES key stored in the encryptor, and a corresponding encryption algorithm.

The license key package may further include: a license key ID, a license key owner ID, a key type and algorithm of the license key, a length of the license key, a validity period, etc.

In addition, the license key package may further include: and checking the code. The check code may be obtained by the encryption apparatus by performing a hash operation on information other than the check code in the license key package, and may be, for example, a hash value, a MAC value, an HMAC value, or the like.

Mode two

Under the condition that the key algorithm indicated in the key creation request is an asymmetric key algorithm, generating a license key according to the symmetric key algorithm, wherein the license key comprises a license public key and a license private key;

creating a license key package, comprising: the encrypted license private key. For example, the encryptor encryption license private key may use a symmetric key such as an AES key stored in the encryptor, and a corresponding encryption algorithm.

Creating a license key public key package, comprising: the encrypted license public key. The encryption license public key of the encryptor can adopt a symmetric key such as an AES key stored in the encryptor and a corresponding encryption algorithm.

It should be understood that the encryption key and the encryption algorithm used by the encryption machine to encrypt the license public key and the license private key may be the same or different, and the present application does not limit this.

It should also be understood that optional information such as those in the former implementation, as well as a check code (e.g., a MAC value or HMAC value, etc.) may also be included in the license key package, the license key public key package. The check code is obtained by the encryption machine through hash operation on other information except the check code in the license key package or the license key public key package.

It should be noted that the encryption engine may create a license key and a corresponding data packet (e.g., a license key packet, a license key public key packet, etc.) for many users. If these data packets are stored in the encryption engine, the license key or the license private key may not be encrypted, or may be stored encrypted. But in this way it takes up too much memory space of the encryption engine. In order to save the storage space of the encryption apparatus, when the data packets are stored outside the encryption apparatus, in order to avoid leakage of the license key or the license private key, it is necessary to encrypt the data packets by using a symmetric key such as AES in the encryption apparatus and store the encrypted data packets outside the encryption apparatus, for example, in a data storage system.

Therefore, when the encryption device executes the above-described step of creating the license key, the license key package, or the license key package and the license key public key package may be encrypted and then stored in the data storage system on the server side. The data storage system is communicatively coupled to the encryptor, and the data storage system may retransmit the packets to the encryptor when needed. Thereby saving the storage space of the encryption machine.

In addition, it should be noted that, before verifying the validity of the public key package, it may also be checked whether the key creation request is within the validity period. One implementation of checking whether it is within the validity period is as follows:

the key creation request carries a time stamp, and the time stamp is used for indicating the generation time of the key creation request; and determining that the key creation request is within the validity period in the case that the time difference between the current time and the time indicated by the timestamp is within the preset threshold value range. The current time here may be obtained in real time by the server or the encryption machine at or before the time of implementing the method, such as real-time obtained world time, international atomic time, coordinated world time, and the like. This prevents an attacker from attacking the server by sending a key creation request to the server a number of times after intercepting the request.

The above scheme describes the creation process of the license key, and below, the process of how the owner of the license key issues the license is described by an embodiment.

The application discloses two methods for realizing issuing permission:

the method comprises the following steps: the owner of the license key issues a license to himself, and then issues a license to the agent using the first license.

The second method comprises the following steps: the owner of the license key issues the license directly to the agent.

These two methods will be described separately below.

Regarding the first method, it is first necessary to describe the process of the owner of the license key issuing the license to itself first, as shown in fig. 2, the process of the owner of the license key issuing the license to itself first may be implemented as the following steps S21-S23:

in step S21, a first permission request is received, where the first permission request requests that a first operation right to a first request key is granted to a first user.

In this step, when the owner of the license key issues a license to himself, a license request is sent to the encryption device. The encryption engine receives a license request, which is referred to as a first license request in this embodiment for the sake of differentiation. The first permission request is used for requesting to grant a first user a first operation right to a first request key.

In step S22, in a case where the originator of the first license request is the owner of the license key, and the first request key is the license key, a first license is generated; the first license is used for indicating a first operation right of the first user on the license key.

In step S23, a first license is issued to the first user.

In one implementation, determining that the originator of the first license request is the owner of the license key is achieved by the following steps B1-B4:

in step B1, receiving a second public key package and a license key package;

in step B2, verifying the legitimacy of the second public key package and the license key package;

in step B3, in the case where both the second public key package and the license key package are legitimate, verifying whether the owner of the second public key package and the owner of the license key package are consistent, and verifying whether the identity of the originator of the first license request is legitimate using the second public key package;

in step B4, in a case where the owner of the second public key package agrees with the owner of the license key package and the identity of the originator of the first license request is legitimate, it is determined that the originator of the first license request is the owner of the license key.

It should be noted that the sequence of the above steps can be adaptively adjusted according to the requirement, as long as the overall scheme is not contradictory. Illustratively, step B1 may be performed after step S21, or may be performed together with step S21, but must be performed before the step of generating the first license. Further exemplarily, the step of verifying whether the owner of the second public key package is consistent with the owner of the license key package may be performed together with or sequentially with the step of verifying whether the identity of the initiator of the first license request is legal by using the second public key package, which is not limited in this application. In addition, as long as the steps of the scheme are not contradictory, the sequence of other steps in the embodiment of the present application can also be adjusted.

In the step B3, the step of verifying whether the identity of the originator of the first license request is legal by using the second public key package may exemplarily include the following steps B31-B33:

in step B31, it is checked whether the owner ID of the second public key in the second public key package is the same as the owner ID of the first request key in the first license request; and/or checking whether the fingerprint of the second public key in the second public key packet is the same as the public key fingerprint of the initiator of the first permission request;

in step B32, in the case that the owner ID of the second public key is the same as the owner ID of the first request key in the first license request, and the fingerprint of the second public key in the second public key package is the same as the public key fingerprint of the originator of the first license request, verifying the signature of the first license request using the second public key in the second public key package; the signature of the first permission request is a character string obtained by calculation by using a private key of an initiator of the first permission request;

in step B33, in the case where the signature verification of the first license request passes, it is determined that the identity of the originator of the first license request is legitimate.

It should be noted that, in another implementation manner of verifying whether the identity of the initiator of the first license request is legal by using the second public key package, the signature of the first license request may be verified by directly using the second public key. The signature of the first license request here is a character string calculated using the private key of the initiator of the first license request. The method is similar to the aforementioned process of verifying the signature of the key creation request by using the first public key, and is not described herein again.

It should be noted that the first license request also has a validity period, and in the case that the first license request is within the validity period, the step B31 or the step of verifying the signature of the first license request by using the second public key is executed again.

The method of checking whether or not it is within the validity period is similar to the aforementioned method of checking whether or not the key creation request is within the validity period. One implementation manner is as follows: the first permission request carries a timestamp, and the timestamp is used for indicating the generation time of the first permission request; in a case where a time difference between the current time and the time stamp is within a preset threshold range, it is determined that the first permission request is within the validity period. By setting the validity period, an attacker can be prevented from repeatedly sending a first license request to the server in a large number after intercepting the request, so as to attack the server.

The scheme disclosed by the steps B1-B4 can determine whether the initiator of the first license request is the owner of the license key, thereby avoiding the first license request initiated by the owner of the license key pretended by an illegal user and improving the security.

One implementation of the above step S22 of generating the first license is as follows: constructing a first license, which may include: an owner ID of the first license, a public key fingerprint of an owner of the license key, a license key ID, license terms describing the first operation right, a license ID, a parent license ID, and the like. In constructing the first license, the encryption engine may assign the owner ID of the first user, and also in the foregoing embodiment, the owner ID of the second public key, to the owner ID of the first license, and assign the fingerprint of the second public key to the public key fingerprint of the owner of the license key.

Since the first user is the owner of the license key and is also the originator of the first license request, the parent license of the first license is itself. In this case, the parent license ID in the first license is the same as the license ID of the first license. In addition, the first license may further include: an issuer ID of the first license. The encryptor may assign an owner ID of the license key to the issuer ID of the first license.

The first license may further include: the check code (e.g., MAC, etc.) of these license information in the first license. The calculation method of the check code is similar to the calculation method of the check code of the public key packet, and the calculation method can be mainly used for verifying the validity of the first license.

The above is a process in which the owner of the license key issues the license to himself first, and after the process in which the owner of the license key issues the license to himself is described, a process in which the agent is issued with the first license is described.

Fig. 3 is a flowchart of a key authorization method according to an embodiment of the present application, and the process for issuing a license to an authorized person by an encryption engine using a first license and a second license request sent by a license key owner may be exemplarily implemented as the following steps S31-S34.

In step S31, a first license that agrees with a first operation right of the first user to the license key and a second license request for requesting to grant a second operation right of the second user to the second request key are received.

Specifically, in this step, the first license is the first license generated in the foregoing embodiment, the first user is an owner of the first license, and the first license may carry an identifier of the first user, so that after receiving the first license, the encryption device may know who the owner of the first license is. As can be seen from the foregoing embodiments, the license key, after being created, may be hosted on the data storage server/cloud. In addition, the first license may also carry a license key identifier, so that the encryption engine may obtain a corresponding license key from the data storage server/cloud based on the license key identifier.

Before this step is performed, the first user may set the license terms, which may be carried in the second license request in the form of a license terms package. Thus, both the first operating right of the first user to the first license key and the scope of the second operating right of the second license request that requests the second user to grant the second request key are agreed in the license terms package. Second, the license terms package may also have agreed upon the validity period of the second license request, as well as the license type, e.g., whether it is a "legacy" type or a "proxy" type.

In step S32, verification is performed using the first license and the second license request, wherein the verification includes: it is determined whether the originator of the second license request is the first user and the second request key is the license key.

In this step, one implementation manner of determining whether the initiator of the second permission request is the first user is exemplarily implemented by performing the following steps S321 to S322:

in step S321, a third public key packet is received;

in step S322, in a case where the third public key package and the first license are both legitimate, the signature of the second license request passes verification based on the third public key package, and the owner of the third public key package agrees with the first user in the first license, it is determined that the originator of the second license request is the first user.

Through the steps S321 to S322, it is verified whether the initiator of the second license request and the owner of the first license are the same user, so that it can be avoided that an illegal user pretends to be a legal authorizer to authorize the agent, and the security is improved.

Specifically, when verifying whether the third public key packet is legal, hash operation may be performed on information in the third public key packet, other than the check code, based on the secret key in the encryption machine, to obtain a check code d; and then determining whether the check code d is consistent with the check code c originally stored in the third public key packet or not, and determining that the third public key packet is legal under the condition that the check code d is consistent with the check code c.

When the encryption machine creates each public key packet and license, the used keys are the keys of the encryption machine, and may be the same or different.

In addition, the third public key package includes: an owner identification of the third public key and third public key information. Therefore, in the above step S322, the signature of the second license request may be verified by using the third public key information therein. In addition, since the first license includes the identifier of the first user, in step S322, it can be determined whether the owner of the third public key package is consistent with the first user in the first license by determining whether the identifier of the first user is consistent with the owner identifier of the third public key in the third public key package.

In addition, in step S32, one implementation manner of verifying whether the second request key is the license key is as follows: receiving a license key package, the license key package comprising: an identification of a license key; in the case where the license key package is legitimate and the identification of the second request key in the second license request coincides with the identification of the license key, it is determined that the second request key is the license key.

It has been described in the foregoing embodiment that the created license key is a license key package. When the license key package is created, a check code is generated, and the check code can be obtained by performing hash operation on other information except the check code in the license key package. Therefore, since the verification code is generated when the license key package is created, it can be seen that, regarding whether the license key package is legal or not, the verification process can be similar to the process of verifying whether the first public key package is legal or not, and can also be performed by using the key of the encryption engine and the verification code in the license key package.

In step S33, in case of passing the verification, a second license is generated, wherein the second license contracts a second operation right of the second user to the license key, the first operation right includes the second operation right, and the first license is a parent license of the second license.

Because the first operation authority of the first user on the license key includes the second operation authority of the second user on the request key, and the first license is the parent license of the second license, that is, after the first user requests to authorize the second user through the second license, the first operation authority of the first user includes the second operation authority obtained by the second user, when the first user as an authorizer authorizes the second user as an agent, the first user can control the specific range of the second operation authority, and therefore, the fine-grained control of the behavior of the authorized person can be realized by controlling the specific range of the second operation authority. Optionally, the range of the second operation right is smaller than the first operation right.

In addition, since the contents regarding the license terms package have been described above, it will be understood that the manner of verifying with the first license and the second license request may further include verifying the ranges of the first operation right and the second operation right. For example, the ranges of the first operation right and the second operation right are checked by the license provision package, and in the case where the range of the first operation right is greater than or equal to the range of the second operation right, it is determined that the verification is passed, and in the case where the range of the first operation right is smaller than the range of the second operation right, it is determined that the verification is not passed.

In step S34, a second license is issued to the second user to enable the second user to issue at least some of the second operating rights to the third user.

It is understood that the second user in this step may be an agent. The agent may continue to issue the license to the authorized person using the second license in a manner similar to steps S31-S33 described above. That is, the first user may be replaced with the agent identity, and the second user may be replaced with the authorized person identity, so as to perform the above steps S31-S33.

The process of generating the second license is similar to the process of generating the first license, specifically: constructing a second license, the second license comprising: owner of the second license, public key fingerprint of owner of the license key, license key ID, license terms describing the second operation right, license ID, parent license ID. Where the parent license of the second license is the first license, and thus the parent license ID is the ID of the first license. The second license may further include: the issuer of the first license (i.e., the owner of the license key). In addition, a check code (e.g., MAC) is also included in the second grant.

After the licensee acquires the license issued by the issuer, the licensee can hold the license to call the license key stored in the server/cloud to execute all possible operations within the scope of the authority.

The above is a method one for issuing a license, and by adopting the method one, the following beneficial effects are realized:

the first operation authority of the first user on the license key comprises a second operation authority of the second user on the request key, and the first license is a parent license of the second license, namely after the first user authorizes the second user through the second license request, the first operation authority of the first user comprises the second operation authority obtained by the second user.

The key agent authorization method provided by the application can solve the problems of limitation and safety of the authority agent on the key authorization chain. The scheme is based on the encryptor performing proxy authorization of keys and uses various cryptographic algorithms such as encryption and decryption, signing, and verifying signatures. By adopting the technical scheme, the proxy authorization of the key can be completed safely, quickly and efficiently, and the development period and the cost are reduced.

Next, a second method of issuing a license is described, in which the owner of the license key directly issues a license to another user without issuing a license to itself first.

Fig. 4 is a flowchart of a key authorization method according to an embodiment of the present application, describing a process in which the encryptor issues a license to the authorized person with a second license request, which is implemented as the following steps S41-S44.

In step S41, a second permission request for requesting that a second user be granted a second operation right to the second request key is received.

Before the step is executed, the first user may set the license terms, specifically, the license terms may be carried in the second license request in the form of a license term package, and therefore, the first operation right of the first license key by the first user and the range of the second operation right of the second request key requested by the second user in the second license request are both agreed in the license term package. Second, the validity period of the second license request is agreed in the license terms package, and whether the license type is the "legacy" type or the "proxy" type. After the license terms are carried in the second license request in the form of the license term packet, the second license request is sent to the encryption machine, and the encryption machine receives the second license request.

In step S42, a verification is performed with the second permission request, wherein the verification includes: determining whether an originator of the second license request is an owner of the license key and whether the second request key is the license key;

the encryption machine utilizes the second permission request to carry out verification, and the specific verification mode is as follows: it is determined whether the originator of the second license request is the owner of the license key and whether the second request key is the license key.

One implementation manner of determining whether the initiator of the second license request is the owner of the license key is as follows: receiving a fourth public key packet; and in the case that the fourth public key package is legal, the signature of the second license request passes verification based on the fourth public key package, and the owner of the fourth public key package is consistent with the originator of the second license request, determining that the originator of the second license request is the owner of the license key.

Specifically, when verifying whether the fourth public key packet is legal, hash operation may be performed on information in the fourth public key packet, other than the check code, based on a secret key in the encryption machine, to obtain a check code f; and then determining whether the check code f is consistent with the check code e originally stored in the fourth public key packet or not, and determining that the fourth public key packet is legal under the condition that the check code f is consistent with the check code e.

The fourth public key package may be the same as or different from the third public key package, and the fourth public key package includes: an owner identification of the fourth public key and fourth public key information. Therefore, the signature of the second license request can be verified using the fourth public key information therein.

One implementation way to verify whether the second request key is the license key is as follows: receiving a license key package, the license key package comprising: an identification of a license key; in the case where the license key package is legitimate and the identification of the second request key in the second license request coincides with the identification of the license key, it is determined that the second request key is the license key.

In step S43, generating a second license in case of passing the verification, wherein the second license contracts a second operation right of the second user to the license key, and the operation right of the owner of the license key to the license key includes the second operation right;

the process of generating the second license is similar to the process of generating the first license, specifically: constructing a second license, the second license comprising: owner of the second license, public key fingerprint of owner of the license key, license key ID, license terms describing the second operation right, license ID, parent license ID. Where the parent license of the second license is the first license, and thus the parent license ID is the ID of the first license. The second license may further include: the issuer of the first license (i.e., the owner of the license key). In addition, a check code (MAC) is also included in the second grant.

In step S44, a second license is issued to the second user to enable the second user to issue at least some of the second operating rights to the third user.

In addition, as can be seen from the above example, the check code is included in each of the first license, the second license, and the license key package, and can be used to verify the validity of the first license, the second license, and the license key package. Thus, in one embodiment, in the case where the method is applied to an encryption engine, the second license comprises a first check code, the first check code being generated by the encryption engine using a first key of the encryption engine; when the validity of the second license is verified, the first secret key of the encryption machine and other information except the first check code in the second license are utilized to carry out Hash calculation to obtain a second check code, the first check code and the second check code are compared, and the validity of the second license is determined to pass under the condition that the comparison is consistent.

The first license contains a third check code, and the third check code is generated by the encryption machine by using a second secret key of the encryption machine; when the validity of the first license is verified, the second secret key of the encryption machine and other information except the third check code in the first license are utilized to carry out hash calculation to obtain a fourth check code, the third check code and the fourth check code are compared, and the validity of the first license is determined to pass under the condition that the comparison is consistent.

The license key packet comprises a fifth check code, and the fifth check code is generated by the encryption machine by using a third key of the encryption machine; when the legality of the license key package is verified, the third key of the encryption machine and other information except the fifth check code in the first license are utilized to perform hash calculation to obtain a sixth check code, the fifth check code is compared with the sixth check code, and the legality of the license key package is determined to pass under the condition that the comparison is consistent.

In order to further improve the control capability of the key owner on the proxy authorization link, in the present application, a technical solution regarding revoking the license is also provided, fig. 5 is a flowchart of a key authorization method in an embodiment of the present application, which is used for describing a response process of the encryptor to an initiator of the revoke request, and may be specifically implemented as the following steps S51-S53:

in step S51, a revoke request for requesting revoking of the fourth license is received;

in step S52, in the case that the originator of the revoke request is the issuer of the fourth license and the type of the fourth license is the first preset type, revoking the fourth license;

in step S53, in a case where the originator of the revoke request is the issuer of the fourth license and the type of the fourth license is the second preset type, the fourth license is revoked, and all licenses issued based on the fourth license are revoked.

In this embodiment, the fourth license may be any license that has been issued. After receiving a revocation request for requesting revocation of the fourth license, which is sent by a terminal where the revocation request initiator is located, the encryptor/server determines whether the initiator of the revocation request is an issuer of the fourth license. In addition, the license provision package referred to in the foregoing embodiments also has a license type agreed therein, and specifically, the license type may be an "inheritance" type or an "agency" type. For example, the agent type may refer to a case where the first user is an issuer, the second user is an agent, and the third user is an actual user, or a case where the second user is a primary agent, the third user is a secondary agent, and the fourth user is an actual user, and the like. The key owner grants the agent a second right to license the key, thereby delegating the agent to issue at least some of the second rights to other agents or actual users. And the inheritance type can mean that the second user and the third user are both actual users, and the second user has the capability of issuing at least part of the second operation permission to the third user.

When the license type is an agent type, the first user wants to revoke the fourth license issued to a certain user (for example, the second user) without revoking other licenses issued based on the fourth license, so that the second user can be disabled from the agent, and the rights and interests of other users (the third user or the fourth user) are guaranteed. When the license type is an inheritance type, all licenses issued based on the fourth license may be revoked simultaneously while the fourth license is revoked. That is, in this embodiment, the first preset type may be an agent type, and the second preset type may be an inheritance type.

In determining whether the originator of the revocation request is the issuer of the fourth license, this is accomplished by the following steps C1-C2:

in step C1, a fifth public key package is received;

in step C2, where the fifth public key package and the fourth license are both legitimate, the signature of the revocation request passes verification based on the fifth public key package, and the owner of the fifth public key package is in agreement with the licensor in the fourth license, the originator of the revocation request is determined to be the issuer of the fourth license.

With regard to all licenses issued based on the fourth license revoked as referred to in the above step S53, the present application exemplarily presents the following two different implementations:

implementation mode 1:

each license indicating a corresponding license key, a license issuer, and a license owner, respectively;

revoking all licenses issued based on the fourth license, including: looking up all fifth licenses, the licensor indicated by the fifth license being consistent with the owner of the fourth license, and the license key indicated by the fifth license being consistent with the license key indicated by the fourth license;

the fifth permission is revoked.

Since the generated licenses respectively indicate the corresponding license key, the issuer of the license, and the owner of the license, it can be determined whether the licensor indicated in the other license is consistent with the owner of the fourth license and the license key indicated by the other license is also consistent with the license key indicated by the fourth license by traversing the other licenses, and if so, the license is determined to be the license issued based on the fourth license, and thus, the license needs to be revoked.

Implementation mode 2:

each license indicates an identity of the license and a parent license identity, respectively;

revoking all licenses issued based on the fourth license, including:

searching all sixth licenses, wherein the parent license identifier indicated by the sixth license is consistent with the identifier of the fourth license;

the sixth permission is revoked.

In this way, each license indicates the identifier of the license and the identifier of the parent license, respectively, and therefore, it is possible to search through whether the parent license indicated in the other licenses is consistent with the identifier of the fourth license; if the license is identical, the license is a license issued based on the fourth license, and the license needs to be revoked.

It will be appreciated that tracing back down may also continue until the next level of permissions is not found, for example, assuming that user G issued permission H to user H based on permission G, user H issued permission I to user I based on permission H, user I issued permission J to user J based on permission I, and user J did not continue to issue permissions down. Then, assuming that the user G needs to revoke the license H issued to the user H, a request for revoking the license H is sent to the encryption engine, the encryption engine judges whether the license is the request issued by the user G based on the revoke request, if so, revokes the license H, and traces back based on the above-described implementation 1 or implementation 2, revoking both the licenses i and j issued based on the license H. Since user J does not continue to issue licenses down, revocation of license J stops tracing.

It should be noted that besides the owner of the license key, each authorized person may revoke the license issued by the authorized person based on the above-mentioned manner, for example, the user H in the above example, and may revoke both the licenses i and j issued based on the license H in the above-mentioned manner.

It should be noted that, in the above-mentioned scheme, before revoking the fifth license or the sixth license, it may be verified whether the fifth license or the sixth license is legal, and after verifying that the fifth license or the sixth license is legal, the fifth license or the sixth license is revoked. In this way, it is possible to avoid the problem that the attacker spoofing the fifth license/sixth license causes the server or the encryption machine to falsely revoke a license that is not revoked.

In the present application, when the server/encryption apparatus receives the license request, some information indicated in the request is not consistent with those in the public key package and the license key package, and is unknown, and needs to be determined, so in the present application, the information indicated in the request for determination and the similar information indicated in the license are distinguished by different concepts, but it can be understood that when the user is legal, the similar information distinguished by different concepts is substantially consistent.

The present application further provides a key authorization method, where an execution subject may be a terminal device used by a first user, including:

sending a first license and a second license request to the encryption machine, so that the encryption machine performs verification by using the first license and the second license request after receiving the first license and the second license request, generates a second license and issues the second license to a second user if the verification is passed, and further enables the second user to issue at least part of the second operation right to a third user;

the first permission agrees with a first operation permission of the first user to the permission key, and the second permission request is used for requesting to grant a second operation permission of the second user to the second request key; the verification comprises the following steps: determining whether an originator of the second license request is the first user and whether the second request key is a license key; the second license contracts a second operation right of the second user on the license key, the first operation right comprises the second operation right, and the first license is a parent license of the second license.

In addition, this application still provides an encryption equipment, includes:

a processor;

a memory for storing executable instructions in the processor;

wherein the processor is configured to:

The present application further provides a terminal, including:

a processor;

a memory for storing executable instructions in the processor;

wherein the processor is configured to:

sending a first license and a second license request to the encryption machine so that the encryption machine can verify by using the first license and the second license request after receiving the first license and the second license request, generate a second license and issue the second license to a second user if the first license and the second license request are verified, and further enable the second user to issue at least part of the second operation right to a third user;

Fig. 6 is a block diagram of a key authorization apparatus according to an embodiment of the present application, for an encryption device, as shown in fig. 6, the apparatus includes the following modules:

a first receiving module 61, configured to receive a first license and a second license request, where the first license contracts a first operation right of a first user to a license key, and the second license request is used to request to grant a second operation right of a second user to a second request key;

a verification module 62 configured to perform verification using the first license and the second license request, wherein the verification includes: determining whether an originator of the second license request is the first user and whether the second request key is a license key;

a generating module 63, configured to generate a second license in the case of passing the verification, where the second license agrees with a second operation right of the second user to the license key, the first operation right includes the second operation right, and the first license is a parent license of the second license;

an issuing module 64 for issuing a second license to the second user to enable the second user to issue at least some of the second operating rights to a third user.

In one embodiment, as shown in fig. 7, the apparatus further comprises:

a second receiving module 71, configured to receive the third public key packet;

the first determining module 72 is configured to determine that the initiator of the second license request is the first user if the third public key package and the first license are both legal, the signature of the second license request passes verification performed based on the third public key package, and the owner of the third public key package is consistent with the first user in the first license.

In one embodiment, the apparatus further comprises:

and the second determining module is used for determining the second request key as the license key under the condition that the license key package is legal and the identification of the second request key in the second license request is consistent with the identification of the license key.

In one embodiment, the first license is generated based on:

in a case where the originator of the first license request is the owner of the license key, and the first request key is the license key, the first license is generated.

In one embodiment, the apparatus further comprises:

and the third determining module is used for determining that the initiator of the first license request is the owner of the license key under the conditions that the second public key packet and the license key packet are both legal, the signature of the first license request passes verification based on the second public key packet, and the owner of the second public key packet is consistent with the owner of the license key packet.

In one embodiment, further comprising:

a fifth receiving module, configured to receive a key creation request;

a creation module for creating a license key in the case that an identity of an initiator of the key creation request is legitimate; the owner of the license key is the originator of the key creation request.

In one embodiment, the apparatus is applied to an encryption engine,

the second license contains a first check code, and the first check code is generated by the encryption machine by using a first secret key of the encryption machine; and/or the presence of a gas in the gas,

the first license contains a third check code, and the third check code is generated by the encryption machine by using a second secret key of the encryption machine; and/or the presence of a gas in the gas,

the license key package contains a fifth check code, and the fifth check code is generated by the encryption engine by using the third key of the encryption engine.

In one embodiment, further comprising:

the first revocation module is used for revoking the fourth license under the condition that an initiator of the revocation request is an issuer of the fourth license and the type of the fourth license is a first preset type;

and the second revocation module is used for revoking the fourth license and all licenses issued based on the fourth license if the initiator of the revocation request is the issuer of the fourth license and the type of the fourth license is a second preset type.

Fig. 8 is a block diagram of a key authorization apparatus according to an embodiment of the present application, for an encryption device, as shown in fig. 8, the apparatus includes the following modules:

a first receiving module 81, configured to receive a second permission request, where the second permission request is used to request that a second user is granted a second operation right to a second request key;

a verification module 82, configured to perform verification using the second permission request, where the verification includes: determining whether an originator of the second license request is an owner of the license key and whether the second request key is the license key;

the generating module 83 is configured to generate a second license in the case of passing the verification, where the second license contracts a second operation right of the second user to the license key, and the operation right of the owner of the license key to the license key includes the second operation right;

an issuing module 84 for issuing a second license to the second user to enable the second user to issue at least some of the second operating rights to a third user.

In one embodiment, the apparatus further comprises:

a second receiving module for receiving a license key package, the license key package comprising: an identification of a license key;

and the determining module is used for determining the second request key as the license key under the condition that the license key package is legal and the identification of the second request key in the second license request is consistent with the identification of the license key.

In one embodiment, further comprising:

a third receiving module, configured to receive a key creation request;

In one embodiment, the apparatus is applied to an encryption engine,

the sending module is used for sending the first license and the second license request to the encryption machine, so that the encryption machine can verify by using the first license and the second license request after receiving the first license and the second license request, generate a second license and issue the second license to the second user under the condition of passing the verification, and further enable the second user to issue at least part of the second operation right to a third user;

The above embodiments are only exemplary embodiments of the present application, and are not intended to limit the present application, and the protection scope of the present application is defined by the claims. Various modifications and equivalents may be made by those skilled in the art within the spirit and scope of the present application and such modifications and equivalents should also be considered to be within the scope of the present application.

Claims

1. A method of key authorization, comprising:

2. The method of claim 1, wherein the method further comprises:

receiving a third public key packet;

3. The method of any of claims 1 to 2, further comprising:

4. The method of any of claims 1 to 3, wherein the first permission is generated based on:

5. The method of claim 4, wherein the method further comprises:

receiving a second public key package and a license key package;

6. The method of any of claims 1 to 5, further comprising:

receiving a key creation request;

7. The method according to any of the claims 1 to 6, characterized in that the method is applied to an encryption machine,

8. The method of any one of claims 1-7, further comprising:

receiving a revoke request for requesting revoking of the fourth license;

9. A method of key authorization, comprising:

10. A method of key authorization, comprising:

11. An encryption engine, comprising:

a processor;

a memory for storing executable instructions in the processor;

wherein the processor is configured to:

performing the method of any one of claims 1-8;

or

The method of claim 9 is performed.

12. A terminal, comprising:

a processor;

a memory for storing executable instructions in the processor;

wherein the processor is configured to:

13. A non-transitory computer readable storage medium, wherein instructions in the storage medium, when executed by a processor in an encryption engine, are capable of performing the key authorization method of any one of claims 1-8 or of performing the key authorization method of claim 9;

the instructions in the storage medium, when executed by a processor in a terminal, are capable of performing the key authorization method of claim 10.