CN110659457B - Application authorization verification method and device and client - Google Patents
Application authorization verification method and device and client Download PDFInfo
- Publication number
- CN110659457B CN110659457B CN201910891876.2A CN201910891876A CN110659457B CN 110659457 B CN110659457 B CN 110659457B CN 201910891876 A CN201910891876 A CN 201910891876A CN 110659457 B CN110659457 B CN 110659457B
- Authority
- CN
- China
- Prior art keywords
- application
- time
- authorization
- field
- cpu
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000013475 authorization Methods 0.000 title claims abstract description 242
- 238000012795 verification Methods 0.000 title claims abstract description 62
- 238000000034 method Methods 0.000 title claims abstract description 51
- 230000004048 modification Effects 0.000 claims description 9
- 238000012986 modification Methods 0.000 claims description 9
- 239000007858 starting material Substances 0.000 claims description 7
- 238000012544 monitoring process Methods 0.000 claims description 2
- 230000001960 triggered effect Effects 0.000 abstract description 7
- 239000003999 initiator Substances 0.000 description 15
- 230000006870 function Effects 0.000 description 9
- 230000008569 process Effects 0.000 description 8
- 238000010586 diagram Methods 0.000 description 7
- 230000003213 activating effect Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000005059 dormancy Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000000750 progressive effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 239000000126 substance Substances 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
- G06F21/12—Protecting executable software
- G06F21/121—Restricting unauthorised execution of programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
Abstract
The application authorization verification method, device and system are characterized in that an application authorization file is verified based on an application starting request, the application is triggered to send a service request under the condition that the authorization file is verified to be passed, whether the application is in an authorization authority is verified according to the authorization file, and if the application is determined not to be in the authorization authority, the application is prohibited from responding to the service request. Because the service request is triggered according to the authorization file, and whether the application is in the authorization authority is further verified according to the authorization file, the application can only respond to the service request if the authorization file is legal and the application is in the authorization authority. Therefore, even if the application is started by means of a command line and the like based on the characteristics of the pseudo CS architecture, the service request sent by the application can be responded only after the authority verification, so that the problem that the service request bypasses the authorization verification can be effectively avoided, and the authorization protection is carried out on the application of the pseudo CS architecture.
Description
Technical Field
The present application relates to the technical field of authorization mechanisms, and in particular, to a method, an apparatus, and a client for verifying application authorization.
Background
With the rapid development of the internet, the concept of software (typically in the form of applications, hereinafter collectively referred to as applications) protection is increasingly important. The application authorization means that a producer of the application specifies the authority for using the application for a user, and the authority comprises a service life and/or functions and the like. For example, a user purchases a year of application lifetime, and the producer of the application authorizes the user to open the lifetime one year after the user registration. At present, authorization files are generally used to record the authority of a user, that is, the authorization files are sent to a client, and an application of the client runs according to the authorization files.
An authorization method in the prior art is usually used for an application of a CS architecture, but an effective authorization protection cannot be performed for an application of a currently mainstream pseudo CS architecture, that is, an authorization verification method corresponding to an existing authorization method can easily bypass verification of an authorization file in an application running process of the pseudo CS architecture.
Disclosure of Invention
The application provides a verification method, a verification device and a client for application authorization, and aims to solve the problem that the existing authorization method cannot effectively perform authorization protection on an application.
In order to achieve the above object, the present application provides the following technical solutions:
the first aspect of the embodiments of the present application discloses a method for verifying application authorization, where the method for verifying application authorization includes:
verifying an authorization file of an application based on a starting request of the application;
under the condition that the authorization file passes verification, triggering the application to send a service request;
after the service request is monitored, verifying whether the application is in an authorization authority according to the authorization file;
and if the application is determined not to be in the authorization authority, prohibiting the application from responding to the service request.
Optionally, in the method for verifying the authorization of the application, the verifying the authorization file of the application based on the start request of the application includes:
acquiring the authorization file based on a starting request of an application, wherein the authorization file is generated according to a machine code, and the machine code is generated by hardware information of equipment operated by the application;
and verifying the authorization file.
Optionally, in the method for verifying the authorization of the application, acquiring the authorization file based on the start request of the application includes:
after receiving a starting request of the application, if the authorization file does not exist locally, generating the machine code according to the collected hardware information, sending the machine code to an authorizing party, and storing the authorization file sent by the authorizing party;
And after receiving a starting request of the application, if the authorization file exists locally, acquiring the local authorization file.
Optionally, in the verification method for authorization of an application, the machine code satisfies a first preset encoding rule, where the first preset encoding rule is used to indicate fields included in the machine code, identifiers of the fields, a length, a field value, and an encrypted identifier, where the hardware information is encoded into a hardware information field, the fields further include at least one of a basic information field, a registration time field, and a check value field, the basic information field is used to indicate an encryption type of the encryption field, and the registration time field is used to indicate registration time of the application, and the check value field is used to indicate a check code.
Optionally, in the verification method for authorization of an application, the authorization file satisfies a second preset encoding rule, where the second preset encoding rule is used to indicate fields included in the authorization file, identifiers of the fields, a length, a field value, and an encrypted identifier, where the hardware information is encoded as one of the fields, the authorization authority of the application is encoded as at least one of the fields, and the fields further include at least one of a basic information field, a registration time field, and a check value field, where the basic information field is used to indicate an encryption type of the encrypted field, the registration time field is used to indicate registration time of the application, and the check value field is used to indicate a check code.
Optionally, in the method for verifying authorization of an application, the verifying whether the application is in an authorization right according to the authorization file includes:
calculating the current time according to the local current time, the registration time of the application, the CPU beat of the equipment operated by the application and the CPU clock frequency;
and judging whether the application is within the authorization deadline indicated by the authorization file or not by using the current time.
Optionally, in the method for verifying authorization of an application, before calculating the current time according to the local current time, the registration time of the application, the CPU beat of the device on which the application runs, and the CPU clock frequency, the method further includes:
determining that the local current time is legal under the condition that the local current time is less than or equal to the preset time;
the preset time comprises at least one of modification time, registration time, last starting time and last request time of the Bootstat.
Optionally, in the verification method for authorization of an application, the preset time is stored in a preset format;
the preset format comprises: the content field comprises a timestamp of the preset time, and the body field comprises a storage rule of the timestamp in the content field;
The storage rule includes at least one of an encryption manner, a scrambling rule between time stamps, and a random position.
Optionally, in the verification method for application authorization, the timestamp of the preset time is a result of removing a random time offset from a code of the real time of the preset time, and the random time offset is a numerical value of a preset number of bits in the code of the real time;
the body field further includes: the random time offset.
The second aspect of the embodiment of the present application discloses an authentication device for application authorization, where the authentication device for application authorization includes:
the verification unit is used for verifying the authorization file of the application based on the starting request of the application;
the triggering unit is used for triggering the application to send a service request under the condition that the authorization file passes verification;
the verification unit is used for verifying whether the application is in the authorization authority according to the authorization file after the service request is monitored;
a prohibiting unit, configured to prohibit the application from responding to the service request if it is determined that the application is not within the authorization authority.
A third aspect of the embodiment of the present application discloses a processor, where the processor is configured to execute a program, where the program executes the method for verifying the authorization of the application disclosed in the first aspect of the embodiment of the present application when running.
A fourth aspect of the embodiments of the present application discloses a storage medium, where the storage medium includes a stored program, and when the program runs, the device where the storage medium is located is controlled to execute the method for verifying the authorization of the application disclosed in the first aspect of the embodiments of the present application.
A fifth aspect of an embodiment of the present application discloses a client, where the client includes:
the launcher is used for verifying the authorization file of the application based on the starting request of the application; under the condition that the authorization file passes verification, triggering the application to send a service request;
the daemon service is used for verifying whether the application is in the authorization authority or not according to the authorization file after the service request is monitored; and if the application is determined not to be in the authorization authority, prohibiting the application from responding to the service request.
Optionally, in the client, the method further includes:
and the application is used for sending the service request to the daemon service based on the trigger of the starter and responding to the verification result fed back by the daemon service.
According to the application authorization verification method, the application authorization verification device, the client, the processor and the storage medium, the authorization file of the application is verified based on the starting request of the application, the application is triggered to send the service request under the condition that the authorization file is verified to be passed, whether the application is in the authorization authority is verified according to the authorization file, and if the application is determined not to be in the authorization authority, the application is prohibited from responding to the service request. Because the service request is triggered according to the authorization file, and whether the application is in the authorization authority is further verified according to the authorization file, the application can only respond to the service request if the authorization file is legal and the service request is in the authorization authority. Therefore, even if the application is started by means of a command line and the like based on the characteristics of the pseudo CS architecture, the service request sent by the application can be responded only after the authority verification, so that the problem that the service request bypasses the authorization verification can be effectively avoided, and the authorization protection is carried out on the application of the pseudo CS architecture.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.
Fig. 1 is a schematic architecture diagram of a client according to an embodiment of the present disclosure;
fig. 2 is a schematic diagram of a verification process of application authorization provided in an embodiment of the present application;
fig. 3 is a schematic diagram illustrating a process of verifying an authorization deadline of an application by a daemon service according to an embodiment of the present application;
fig. 4 is a schematic structural diagram of an application authorization verification apparatus according to an embodiment of the present application.
Detailed Description
The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.
As shown in fig. 1, an architecture diagram of a client provided in the embodiment of the present application includes:
The launcher 100 and the daemon service 200 may be provided in a client of an application (for the sake of distinction, the other parts of the client except for the device shown in fig. 1 are hereinafter referred to as applications), and thus, the application 300 is also included in the client in fig. 1. That is, in the embodiment of the present application, by adding the launcher 100 and the daemon service 200 to the client of the application 300, the more accurate authorization authority verification of the application 300 is realized.
In the embodiment of the present application, the architecture type of the application includes, but is not limited to: cs-side architecture, pseudo cs-side architecture, etc.
Specifically, as shown in fig. 2, the verification process of the application authorization includes the following steps:
s201: the launcher checks the authorization file of the application based on the launch request of the application. If the authorization file passes the verification, S202 is executed. If the authorization file is not verified, S203 is executed.
In this embodiment, the authorization file is generated according to a machine code, and the machine code is generated by hardware information of a device on which the application runs, where the hardware information includes but is not limited to: processor information, hard disk information, MAC information, etc. of the device.
It should be noted that, after the initiator receives the start request of the application, the initiator may determine whether an authorization file exists locally. And if the authorization file exists locally, acquiring the local authorization file.
If the authorization file does not exist locally, the application is determined to be started for the first time. Under the condition, when the device running by the application is in a networking state, the initiator collects hardware information, generates a machine code according to the collected hardware information, and sends the machine code to the authorizer, and the authorizer usually generates an authorization file from the machine code after verifying that the machine code passes and sends the authorization file to the initiator. And under the condition that the equipment with the application running is not networked, the starter sends out a prompt for activating the application to prompt the equipment to be networked, and after the equipment is networked, the process of obtaining the authorization file from the authorization party is executed.
In the above explanation, the process of generating the machine code according to the collected hardware information is well known to those skilled in the art, and will not be described herein.
Optionally, in order to ensure confidentiality of the machine code, the initiator generates and transmits the machine code using a first preset encoding rule. The first preset encoding rule is used for indicating fields included in the machine code, identification of each field, length, field value and encryption identification (used for indicating whether the fields are encrypted or not). The hardware information is coded into one field (hardware information field), and besides the hardware information field, the field also comprises at least one of a machine code information structure field, a basic information field, a registration time field and a check value field.
Taking table 1 as an example, the machine code adopts a BER-TLV encoding rule, and the preset fields in the machine code include:
the field of the machine code information structure (machine coded info (structured)) is used for indicating each field included in the machine code after the field, the identifier of the field of the machine code information structure is 01, the length of the field of the machine code information structure is determined by the length of each subsequent field, the field value is the value of each subsequent field, and the encrypted identifier of the field of the machine code information structure indicates that the encryption is not performed.
Basic information field (basic) indicating the encryption type of the encryption field (hardware information field and registration time field), and an index of the scrambling code, wherein a field value of 01 indicates exclusive or encryption, a field value of 02 indicates Des encryption, and a field value of 03 indicates Aes encryption. The index of the scrambling code ranges from 0 to 15. The identification of the basic information field is 02, the length of the basic information field is 2 bytes, and the encryption identification of the basic information field indicates no encryption.
A hardware information field (denoted by prime) for indicating the information of the hardware collected by the initiator, wherein the identifier of the hardware information field is 03, the field value is the serial number of each hardware, the length is the sum of the serial numbers of each hardware, and the encryption identifier indicates encryption.
A registration time field (prime) for indicating a registration time of the application, the registration time field having an identifier of 04, a length of 14 bytes, and a field value of registration time, and the encryption identifier indicating encryption.
A check value field (Md5 (prime)) for indicating a check code, the check value field having an identifier of 09, the check value field having a length of 16 bytes, the field value being a check code, the encryption identifier of the check value field indicating encryption.
TABLE 1
Optionally, in order to improve the confidentiality of the authorization file, the authorizer may generate and transmit the authorization file using the second preset encoding rule. The second preset encoding rule is used for indicating fields, identifications of the fields, lengths, field values and encryption identifications (used for indicating whether the fields are encrypted) included in the authorization file. The hardware information is coded into one field, the authorization authority of the application is coded into the other field, and the fields further comprise at least one of an encryption mode of the hardware information, an identification of a random scrambling code and a check value.
Taking table 2 as an example, the authorization file adopts a BER-TLV encoding rule, and the fields preset in the encoding of the authorization file include:
An authorized file information structure field (represented by license imfo (structured)) is used for indicating each field included in the authorized file after the field, the identifier of the authorized file information structure field is 0c, the length of the authorized file information structure field is determined by the length of each subsequent field, the field value is the value of each subsequent field, and the encryption identifier of the authorized file information structure field indicates that the file is not encrypted.
Basic information field (basic) indicating an encryption type of an encryption field (hardware information field, registration time field, expiration time field, and authorization type field), and an index of a scrambling code, wherein a field value of 01 indicates exclusive or encryption, a field value of 02 indicates Des encryption, and a field value of 03 indicates Aes encryption. The index of the scrambling code ranges from 0 to 15. The identification of the basic information field is 02, the length of the basic information field is 2 bytes, and the encryption identification of the basic information field indicates no encryption.
A hardware information field (denoted by prime) for indicating the information of the hardware collected by the initiator, wherein the identifier of the hardware information field is 03, the field value is the serial number of each hardware, the length of the hardware information field is the sum of the serial numbers of each hardware, and the encryption identifier of the hardware information field indicates encryption.
A registration time field (prime) for indicating a registration time of the application, the registration time field having an identifier of 04, a length of 14 bytes, and a field value of registration time, the encryption identifier of the registration time field indicating encryption.
An expiration time field (prime) for indicating an expiration time of an authorization period of the application, the expiration time field having an identification of 05, the expiration time field having a length of 14 bytes, and a field value of the expiration time, the encryption identification of the expiration time field indicating encryption.
An authorization type field (denoted by permission type) for indicating an authorization type of an application, the authorization type field having a length of 06 bytes, a field value 01 for indicating an authorization duration of one month, a field value 02 for indicating an authorization duration of three months, a field value 03 for indicating an authorization duration of six months, a field value 04 for indicating an authorization duration of one year, and an encryption flag of the authorization type field indicating encryption.
And a check value field (Md5 (Primitive)) for indicating a check code, wherein the identification of the check value field is 09, the length of the check value field is 16 bytes, the field value is the check code, and the encryption identification of the check value field indicates encryption.
TABLE 2
After the initiator receives the authorization file sent by the authorizing party, if the initiator verifies that the authorization file passes, the initiator stores the authorization file. The specific way to verify the authorization document can be seen in the prior art. Of course, the initiator may also store the authorization file directly without authentication.
S202: the launcher triggers the application to send a service request to the daemon service.
The service request includes at least a start request and possibly other service requests, such as a trigger request for a certain function.
S203: the launcher triggers the application to send unauthorized information.
Wherein the unauthorized information is used for indicating that the current user has no authority to use the application.
S204: and after monitoring the service request, the daemon service verifies whether the application is in the authorization authority according to the authorization file. If the application is not in the authorized right, S205 is executed. If the application is in the authorized right, S206 is executed.
It should be noted that, in the embodiment of the present application, the authorization right includes an authorization term and an authorization function.
Verifying whether the application is specifically within the authorization authority according to the authorization file comprises: verifying whether the sending time of the service request is within an authorized duration of the application and/or verifying whether the function requested by the service request is within an authorized function of the application. That is, both of the above two verifications may be performed, and when both of the two verifications pass, the application is determined to be in the authorization authority, or only one of the two verifications may be performed, and as long as one passes, the application is determined to be in the authorization authority.
The specific process of verifying whether the application is within the authorized period can be seen in fig. 3.
Optionally, in order to improve security, the service request sent by the application to the daemon service may be encoded by using a third preset encoding rule, taking table 3 as an example, the service request adopts a BER-TLV encoding rule, and a preset field in encoding of the service request includes:
the field of the structure of the service request information (clientinfo (structured)) is used for indicating each field included after the field in the service request, the identifier of the field of the structure of the service request information is 0d, the length of the field of the structure of the service request information is determined by the length of each subsequent field, the field value is the value of each subsequent field, and the encryption identifier of the field of the structure of the service request information indicates that the field is not encrypted.
Basic information field (basic) (prime) indicating an encryption type of an encryption field (a random number field and a current time field), and an index of a scrambling code, wherein a field value of 01 indicates exclusive or encryption, a field value of 02 indicates Des encryption, and a field value of 03 indicates Aes encryption. The index of the scrambling code ranges from 0 to 15. The identification of the basic information field is 02, the length of the basic information field is 6 bytes, and the encryption identification of the basic information field indicates that no encryption is performed.
A random number field (prime) for indicating a random password, the random password being automatically generated by a random password device in an application, the identifier of the random number field being 07, the field value being a random number, the length of the random number field being 10 bytes, the encryption identifier of the random number field indicating encryption.
A current time field (critical) for indicating a time when the application sends the service request to the daemon service, the current time field is identified as 08, the field value is the current time, the length of the current time field is 14 bytes, and the encryption identification of the current time field indicates encryption.
TABLE 3
S205: the daemon service prohibits the application from responding to the service request.
Specifically, the daemon service informs the application of prohibiting the response to the service request by feeding back a verification result indicating that the verification is not legal to the application.
Optionally, in order to improve the security of the verification result, an encoding rule taking table 4 as an example is used to generate and transmit the verification result, the verification result adopts a BER-TLV encoding rule, and a preset field in the encoding of the verification result includes:
the field of the structure of the authentication result information (serverinfo (structured)) is used for indicating each field included after the field in the authentication result, the identification of the field of the structure of the authentication result information is 0f, the length of the field of the structure of the authentication result information is determined by the length of each subsequent field, the field value is the value of each subsequent field, and the encryption identification of the field of the structure of the authentication result information indicates that the field is not encrypted.
Basic information field (basic) indicating an encryption type of an encryption field (an authorization status code field and an encryption string field), and an index of a scrambling code, wherein a field value 01 indicates exclusive or encryption, a field value 02 indicates Des encryption, and a field value 03 indicates Aes encryption. The index of the scrambling code ranges from 0 to 15. The identification of the basic information field is 02, the length of the basic information field is 6 bytes, and the encryption identification of the basic information field indicates no encryption.
An authorization status code field (valid) for indicating an authorization status code generated by the daemon service, wherein the identifier of the authorization status code field is 0a, a field value is 0 indicating that the service request is legal, a field value of not 0 indicating that the service request is illegal, the length of the authorization status code field is 1 byte, and the encryption identifier of the authorization status code field indicates encryption.
An encrypted string field (denoted by secret) for indicating an encrypted string generated by the daemon service, where an identifier of the encrypted string field is 0b, a field value is an encrypted string, a length of the encrypted string field is a length of a string obtained by the daemon service applying an encryption algorithm, and an encrypted identifier of the encrypted string field indicates encryption.
TABLE 4
S206: the daemon service allows the application to respond to the service request.
Specifically, the daemon service informs that the application can respond to the service request by feeding back a verification result indicating that the verification is legal to the application.
In this embodiment, the initiator verifies the authorization file of the application based on the start request of the application, and when the authorization file is verified, the initiator triggers the application to send the service request. The daemon service verifies whether the application is in the authorization authority according to the authorization file, and if the application is determined not to be in the authorization authority, the daemon service prohibits the application from responding to the service request. Because the starter triggers the service request according to the authorization file, and the daemon service further verifies whether the application is in the authorization authority according to the authorization file, the application can only respond to the service request if the authorization file is legal and the service request is in the authorization authority. Therefore, even if the application is started by means of a command line and the like based on the characteristics of the pseudo CS architecture, the service request sent by the application can be responded only after the authority verification, so that the problem that the service request bypasses the authorization verification can be effectively avoided, and the authorization protection is carried out on the application of the pseudo CS architecture.
Fig. 3 is a schematic diagram of a process of verifying an application authorization deadline by a daemon service according to an embodiment of the present application, including the following steps:
s301: and acquiring the local current time.
S302: and verifying whether the local current time is legal or not, if so, executing S303, and if not, sending out prompt information that the local current time is illegal.
S302 is an optional step, and is intended to prevent tampering of the local current time, and improve accuracy of authorization verification. In the case where S302 is not performed, S303 may be directly performed.
Specifically, when the local current time meets the following conditions, it is determined that the local current time is legal:
1. is less than or equal to the modification time of the boottat.dat file, wherein the boottat.dat file is modified by the daemon service at initialization and by the launcher at each boot.
2. And less than or equal to the registration time, wherein the registration time is the registration time of the application and is obtained from the authorization file.
3. And the time is less than or equal to the last starting time, wherein the last starting time is the registration time used when the application is operated for the first time, and after each starting of the application, if the starter verifies that the local current time is not tampered, the latest starting time is updated. Optionally, the initiator may authenticate using at least one of conditions 1, 2, and 4.
4. And the time is less than or equal to the last request time, wherein the last request time is updated by the daemon service when the service request is received, and is updated to the local current time included in the service request.
It should be noted that the above 4 conditions are not limited to be satisfied simultaneously, and the more conditions that are satisfied, the less the possibility that the local current time is tampered with.
The modification time, the registration time, the last start time and the last request time of the boot.
Table 5 shows the specific content in the preset format, and the locally stored time includes four parts: a Body field Body, a Body field check value (e.g., a crc check value), a Content field Content, and a Content field check value (e.g., an MD5 check value).
TABLE 5
| Body | Bodycrc check value | ContentMD5 check value | Content |
Wherein, Body can be encrypted by AES encryption mode, and Content can be encrypted by XOR, Des or Aes encryption mode.
The specific Content of Content is shown in table 6, where the first column in table 6 represents the name of each item and the second column represents the number of bytes occupied by each item. As can be seen from table 6, the Content includes the timestamp of the above 4 times, as well as the random scrambling code character. And a random scrambling code character is arranged between two adjacent timestamps. The purpose of setting the random scrambling code character is to further improve the time security, and it may not be set.
Optionally, to further improve the time security, the timestamp is calculated in the following manner: any one timestamp is the true time encoding-random timestamp offset. The real time encoding is a numerical value obtained by encoding in a preset encoding mode, such as an Aes encrypted value of the real time. The random timestamp offset is a value of a preset number of bits in the encoding of the real time, for example, the last 5-bit value of the Aes encrypted value of the real time.
Optionally, in order to further improve the time security, the positions of the 4 timestamps in the Content are randomly selected, that is, when the Content is updated each time, the front-back sequence of the 4 timestamps is randomly fixed, and the timestamps are written in the front-back sequence. For example, in table 6, the boottat.dat file modification timestamp is at the forefront position, and after updating the Content again, the boottat.dat file modification timestamp may be ranked after the registration timestamp. The position of the respective timestamp position is indicated in Body.
Optionally, the obtaining method of the random scrambling code character is as follows: and (3) performing MD5 encryption on the first three timestamps in the Content to obtain a ciphertext, and intercepting the numerical value of the last N (such as 2) digits of the ciphertext to be used as a random scrambling code character.
TABLE 6
Specific contents of Body are shown in table 7, where the first column in table 7 indicates names of the respective items, the second column indicates the number of bytes occupied by the respective items, the third column indicates the meaning of the respective items, and the fourth column indicates the meaning or optional values of the respective items.
TABLE 7
It should be emphasized that only the sequence identifiers of the last start time and the last request time are described in table 7, that is, only the positions of the last start time and the last request time in the Content are selectable, which is only an example, and the positions of all timestamps may also be randomly selected.
Specifically, 4 timestamps and timestamp offsets are obtained from the time files shown in local lookup tables 5, 6, and 7, then the code of the real time is obtained according to the calculation mode of the code of the real time, i.e., timestamp + timestamp offset, and then the real time (the modification time of the boottat. Then, whether the local time is legal or not is verified through the 4 conditions.
S303: and calculating the current time according to the local current time, the registration time of the application, the CPU beat of the equipment operated by the application and the CPU clock frequency.
Specifically, the current time is registration time + number of CPU beat cycles + CPU beat cycle time + (current CPU beat count + offset of CPU beat count)/CPU clock frequency.
Wherein the content of the first and second substances,
the number of CPU beat cycles is equal to (local current time-registration time)/CPU beat cycle time;
the offset of the CPU beat number is (local current time-registration time)% CPU beat cycle time;
the CPU clock frequency (difference between the TSC obtained the second time and the TSC obtained the first time)/(difference between the second time and the first time); a Time Stamp base number (TSC) exists in a CPU register of the application running equipment, after the TSC is obtained from the CPU register for the first Time, the equipment dormancy preset Time length is triggered, and then the TSC is obtained from the CPU register for the second Time;
acquiring registration time from an authorization file; the CPU beat cycle time is calculated by using the prior art according to the data type of the local equipment; acquiring the current CPU beat number from local equipment; % represents the remainder operation.
S304: using the current time, it is determined whether the application is within an authorization deadline.
For example, the difference between the current time and the registration time may be determined to be within the authorization deadline if the current time is within the authorization type indicated by the authorization file, or the current time may be determined to be within the authorization deadline if the current time is before the expiration time indicated by the authorization file.
As can be seen from the flow shown in fig. 3, whether the local current time is tampered or not is verified by using a plurality of comparison times, and in the case that the local current time is not tampered, the CPU beat of the local device is reused to determine the current time as the time authority verification, and the plurality of comparison times are encoded and stored by using a series of algorithms, so that the verification method can prevent and recognize that the local current time is tampered, and has high accuracy.
It should be noted that, the verification method of the function authority may be: the authorized function is indicated in the authorization file and the daemon service verifies whether the service requested by the service request belongs to the authorized function.
As shown in fig. 4, an embodiment of the present application further provides a schematic structural diagram of an apparatus for verifying application authorization, where the apparatus includes:
the verifying unit 401 is configured to verify an authorization file of an application based on a start request of the application.
The specific implementation manner of the verification unit 401, based on the start request of the application, for verifying the authorization file of the application includes: and acquiring an authorization file based on the starting request of the application, generating the authorization file according to a machine code, generating the machine code by hardware information of equipment operated by the application, and verifying the authorization file.
The specific implementation manner of the checking unit 401, based on the start request of the application, acquiring the authorization file includes: after receiving a starting request of an application, if an authorization file does not exist locally, generating a machine code according to the collected hardware information, sending the machine code to an authorizing party, and storing the authorization file sent by the authorizing party. After receiving a starting request of an application, if an authorization file exists locally, acquiring the local authorization file.
In addition, the machine code mentioned in the verification unit 401 satisfies a first preset encoding rule, where the first preset encoding rule is used to indicate fields included in the machine code, identifiers of the fields, a length, a field value, and an encryption identifier, where the hardware information is encoded into one of the fields, and the fields further include at least one of an encryption manner of the hardware information, an identifier of a random scrambling code, an application registration time, and a verification value.
The authorization file mentioned in the verification unit 401 satisfies a second preset encoding rule, where the second preset encoding rule is used to indicate fields, identifiers of the fields, lengths, field values, and encryption identifiers included in the authorization file. The hardware information is coded into one field, the authorization authority of the application is coded into the other field, and the fields further comprise at least one of an encryption mode of the hardware information, an identification of a random scrambling code and a check value.
A triggering unit 402, configured to trigger the application to send the service request when the authorization file passes verification.
And an verifying unit 403, configured to verify whether the application is in the authorization right according to the authorization file after the service request is monitored.
The verification unit 403 is specifically configured to: and calculating the current time according to the local current time, the registration time of the application, the CPU beat of the equipment in which the application runs and the CPU clock frequency. And judging whether the application is within the authorization deadline indicated by the authorization file or not by using the current time.
Furthermore, the verification unit 403 is further configured to: and determining that the local current time is legal under the condition that the local current time is less than or equal to the preset time. Wherein the preset time comprises at least one of modification time, registration time, last start time and last request time of the Bootstat. Wherein, the preset format comprises: the content field comprises a timestamp of preset time, and the body field comprises a storage rule of the timestamp in the content field. The storage rule includes at least one of an encryption manner, a scrambling rule between time stamps, and a random position. The timestamp of the preset time is a result of removing the random time offset from the code of the real time of the preset time, and the random time offset is a numerical value of a preset digit in the code of the real time. The body field further includes: a random time offset.
A disabling unit 404 configured to disable the application from responding to the service request if it is determined that the application is not within the authorization authority.
In summary, in the verification apparatus for application authorization provided in the embodiment of the present application, an authorization file of an application is verified based on a start request of the application, and if the authorization file is verified to be passed, the application is triggered to send a service request, and whether the application is in an authorization right is verified according to the authorization file, and if it is determined that the application is not in the authorization right, the application is prohibited from responding to the service request. Because the service request is triggered according to the authorization file, and whether the application is in the authorization authority is further verified according to the authorization file, the application can only respond to the service request if the authorization file is legal and the service request is in the authorization authority. Therefore, even if the application is started by means of a command line and the like based on the characteristics of the pseudo CS architecture, the service request sent by the application can be responded only after the authority verification, so that the problem that the service request bypasses the authorization verification can be effectively avoided, and the authorization protection is carried out on the application of the pseudo CS architecture.
Further, an embodiment of the present application provides a processor, where the processor is configured to execute a program, where the program executes the method for verifying the authorization of the application disclosed in the embodiment of the present application when running.
Further, an embodiment of the present application provides a storage medium, on which a program is stored, where the program, when executed by a processor, implements the method for verifying the authorization of the application disclosed in the embodiment of the present application.
The functions described in the method of the embodiment of the present application, if implemented in the form of software functional units and sold or used as independent products, may be stored in a storage medium readable by a computing device. Based on such understanding, part of the contribution to the prior art of the embodiments of the present application or part of the technical solution may be embodied in the form of a software product stored in a storage medium and including several instructions for causing a computing device (which may be a personal computer, a server, a mobile computing device or a network device) to execute all or part of the steps of the method described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk, and various media capable of storing program codes.
The embodiments are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same or similar parts among the embodiments are referred to each other.
The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims (13)
1. A verification method for application authorization is characterized in that a launcher and a daemon service are arranged in a client of an application in advance, and the method comprises the following steps:
the method comprises the steps that a starter verifies an authorization file of an application based on a starting request of the application;
under the condition that the authorization file passes verification, the starter triggers the application to send a service request to a daemon service;
after monitoring the service request, the daemon service verifies whether the application is in the authorization authority according to the authorization file;
if the application is determined not to be within the authorization rights, prohibiting the application from responding to the service request;
The verifying whether the application is in the authorization authority according to the authorization file comprises the following steps:
calculating the current time according to the local current time, the registration time of the application, the CPU beat of the equipment in which the application runs and the CPU clock frequency;
judging whether the application is within an authorization deadline indicated by the authorization file or not by using the current time;
the current time = the registration time + the number of CPU beat cycles + the CPU beat cycle time + (offset of current CPU beat number + CPU beat number)/the CPU clock frequency;
wherein, the number of CPU beat cycles = (local current time-registration time)/CPU beat cycle time; the offset of the CPU beat number = (local current time-registration time)% CPU beat cycle time; the CPU clock frequency = (difference between the second acquired time stamp base and the first acquired time stamp base)/(difference between the second acquisition time and the first acquisition time).
2. The method of claim 1, wherein verifying the authorization file of the application based on the application start request comprises:
acquiring the authorization file based on a starting request of an application, wherein the authorization file is generated according to a machine code, and the machine code is generated by hardware information of equipment operated by the application;
And verifying the authorization file.
3. The method of claim 2, wherein obtaining the authorization file based on the application launch request comprises:
after receiving a starting request of the application, if the authorization file does not exist locally, generating the machine code according to the collected hardware information, sending the machine code to an authorizing party, and storing the authorization file sent by the authorizing party;
and after receiving the starting request of the application, if the authorization file exists locally, acquiring the local authorization file.
4. The method according to claim 2 or 3, wherein the machine code satisfies a first preset encoding rule, the first preset encoding rule is used for indicating fields included in the machine code, identification of each field, length, field value and encryption identification, wherein the hardware information is encoded into a hardware information field, the fields further include at least one of a basic information field, a registration time field and a check value field, the basic information field is used for indicating an encryption type of the encryption field, and the registration time field is used for indicating a registration time of the application and the check value field is used for indicating a check code.
5. The method according to claim 1, wherein the authorization file satisfies a second preset encoding rule, the second preset encoding rule is used for indicating fields included in the authorization file, identification of each field, length, field value and encryption identification, wherein hardware information is encoded into one field, authorization authority of the application is encoded into at least one field, the fields further include at least one of a basic information field, a registration time field and a check value field, the basic information field is used for indicating encryption type of the encryption field, the registration time field is used for indicating registration time of the application, and the check value field is used for indicating check code.
6. The method of claim 1, further comprising, prior to said calculating a current time from a local current time, a registration time of the application, a CPU beat of a device on which the application is running, and a CPU clock frequency:
determining that the local current time is legal under the condition that the local current time is less than or equal to preset time;
the preset time comprises at least one of modification time, registration time, last starting time and last request time of the Bootstat.
7. The method of claim 6, wherein the preset time is stored in a preset format;
the preset format comprises: the content field comprises a timestamp of the preset time, and the body field comprises a storage rule of the timestamp in the content field;
the storage rule includes at least one of an encryption manner, a scrambling rule between time stamps, and a random position.
8. The method according to claim 7, wherein the timestamp of the preset time is a result of removing a random time offset from the real-time code of the preset time, wherein the random time offset is a value of a preset number of bits in the real-time code;
the body field further includes: the random time offset.
9. An apparatus for verifying authorization of an application, comprising:
the verification unit is used for verifying the authorization file of the application based on the starting request of the application;
the triggering unit is used for triggering the application to send a service request under the condition that the authorization file passes verification;
the verification unit is used for verifying whether the application is in the authorization authority according to the authorization file after the service request is monitored;
A prohibiting unit configured to prohibit the application from responding to the service request if it is determined that the application is not within the authorization authority;
the verifying whether the application is in the authorization authority according to the authorization file comprises the following steps:
calculating the current time according to the local current time, the registration time of the application, the CPU beat of the equipment in which the application runs and the CPU clock frequency;
judging whether the application is within an authorization deadline indicated by the authorization file or not by using the current time;
the current time = the registration time + the number of CPU beat cycles + the CPU beat cycle time + (the current number of CPU beats + the offset of the number of CPU beats)/the CPU clock frequency;
wherein, the number of CPU beat cycles = (local current time-registration time)/CPU beat cycle time; the offset of the CPU beat number = (local current time-registration time)% CPU beat cycle time; the CPU clock frequency = (difference between the second acquired time stamp base number and the first acquired time stamp base number)/(difference between the second acquisition time and the first acquisition time).
10. A processor configured to run a program, wherein the program when running performs the method of verifying the authorization of an application according to any one of claims 1 to 8.
11. A storage medium, characterized in that the storage medium comprises a stored program, wherein a device on which the storage medium is located is controlled to execute the method for verifying the authorization of an application according to any one of claims 1-8 when the program runs.
12. A client, comprising:
the launcher is used for verifying the authorization file of the application based on a starting request of the application; under the condition that the authorization file passes verification, triggering the application to send a service request to a daemon service;
the daemon service is used for verifying whether the application is in an authorization authority or not according to the authorization file after the service request is monitored; if the application is determined not to be within the authorization rights, prohibiting the application from responding to the service request;
the verifying whether the application is in the authorization authority according to the authorization file comprises the following steps:
calculating the current time according to the local current time, the registration time of the application, the CPU section of the equipment operated by the application and the CPU clock frequency;
judging whether the application is within an authorization deadline indicated by the authorization file or not by using the current time;
the current time = the registration time + the number of CPU beat cycles + the CPU beat cycle time + (offset of current CPU beat number + CPU beat number)/the CPU clock frequency;
Wherein, the number of CPU beat cycles = (local current time-registration time)/CPU beat cycle time; the offset of the CPU beat number = (local current time-registration time)% CPU beat cycle time; the CPU clock frequency = (difference between the second acquired time stamp base and the first acquired time stamp base)/(difference between the second acquisition time and the first acquisition time).
13. The client of claim 12, further comprising:
and the application is used for sending the service request to the daemon service based on the trigger of the starter and responding to the verification result fed back by the daemon service.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910891876.2A CN110659457B (en) | 2019-09-20 | 2019-09-20 | Application authorization verification method and device and client |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910891876.2A CN110659457B (en) | 2019-09-20 | 2019-09-20 | Application authorization verification method and device and client |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110659457A CN110659457A (en) | 2020-01-07 |
| CN110659457B true CN110659457B (en) | 2022-06-07 |
Family
ID=69038322
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910891876.2A Active CN110659457B (en) | 2019-09-20 | 2019-09-20 | Application authorization verification method and device and client |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110659457B (en) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112069471B (en) * | 2020-09-21 | 2023-05-23 | 浪潮云信息技术股份公司 | Application system authorization method, device and medium based on domestic CPU |
| CN112395559A (en) * | 2020-10-10 | 2021-02-23 | 武汉虹旭信息技术有限责任公司 | Software authorization management system and software authorization management method |
| CN113254887A (en) * | 2021-06-04 | 2021-08-13 | 统信软件技术有限公司 | Authorization method of application program, computing device and storage medium |
| CN113536334A (en) * | 2021-06-09 | 2021-10-22 | 佛山市青松科技股份有限公司 | Authorization checking method, module and system |
Family Cites Families (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CA2313839A1 (en) * | 1999-07-27 | 2001-01-27 | Lucent Technologies Inc. | Method of monitoring runtime usage of demo evaluation software |
| JP4994970B2 (en) * | 2006-08-21 | 2012-08-08 | 株式会社リコー | Image processing system, image processing apparatus, program management method, and management program for managing program |
| US7908292B2 (en) * | 2006-12-05 | 2011-03-15 | Nokia Corporation | Metadata broker |
| EP2156353A1 (en) * | 2007-06-08 | 2010-02-24 | Sandisk Corporation | Memory device with circuitry for improving accuracy of a time estimate used in digital rights management (drm) license validation and method for use therewith |
| BRPI1101401A2 (en) * | 2011-03-29 | 2013-06-04 | Inst Alberto Luiz Coimbra De Pos Graduacao E Pesquisas De Engenharia Coppe Ufrj | Strictly growing virtual clock for high precision timing of programs in multiprocessing systems |
| CN102184362B (en) * | 2011-05-19 | 2014-11-26 | 中国石油集团川庆钻探工程有限公司 | Combined verifying and authorizing method for fixed license and floating license |
| CN102707765B (en) * | 2012-05-15 | 2014-12-31 | 江苏中科梦兰电子科技有限公司 | Timekeeping method using mixed clock source |
| CN104580316B (en) * | 2013-10-24 | 2019-03-22 | 深圳市国信互联科技有限公司 | Soft ware authorization management method and system |
| CN105516186B (en) * | 2015-12-31 | 2019-07-23 | 华为技术有限公司 | A kind of method preventing Replay Attack and server |
| CN106682300A (en) * | 2016-12-22 | 2017-05-17 | 中国西电电气股份有限公司 | Digital signal generating device and method |
| CN110213276B (en) * | 2019-06-05 | 2021-08-27 | 宁波深擎信息科技有限公司 | Authorization verification method under micro-service architecture, server, terminal and medium |
-
2019
- 2019-09-20 CN CN201910891876.2A patent/CN110659457B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN110659457A (en) | 2020-01-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110659457B (en) | Application authorization verification method and device and client | |
| US11876791B2 (en) | Message authentication with secure code verification | |
| CN110968844B (en) | Software authorization method in off-line state, server and readable storage medium | |
| CN102426640B (en) | For the fail-safe software product identifiers of Product Validation and activation | |
| US9443107B2 (en) | Method for protecting the integrity of a group of memory elements using an aggregate authentication code | |
| WO2017000648A1 (en) | Authentication method and apparatus for reinforced software | |
| CN109347643B (en) | Ethernet-based user center system security supervision method and device | |
| CN114186199B (en) | License authorization method and device | |
| CN111177693B (en) | Method, device, equipment and medium for verifying terminal root certificate | |
| CN110825639B (en) | Tamper-resistant time software License verification method | |
| CN113395406B (en) | Encryption authentication method and system based on power equipment fingerprint | |
| CN112800392A (en) | Authorization method and device based on soft certificate and storage medium | |
| Banescu et al. | Software-based protection against changeware | |
| CN106850232B (en) | The authorization management method and system that state is kept | |
| CN108256351B (en) | File processing method and device, storage medium and terminal | |
| CN114363008A (en) | Virtual equipment authentication method and device, electronic equipment and storage medium | |
| CN107133499B (en) | Software copyright protection method, client, server and system | |
| CN111224826B (en) | Configuration updating method, device, system and medium based on distributed system | |
| CN112000933A (en) | Application software activation method and device, electronic equipment and storage medium | |
| CN112733126B (en) | Product license authentication method and system | |
| JPH09319571A (en) | License managing system for software | |
| CN112087295B (en) | Encryption and decryption method and device for electronic lock, electronic lock and storage medium | |
| CN112887099A (en) | Data signature method, electronic device and computer readable storage medium | |
| US10425233B2 (en) | Method for automatically verifying a target computer file with respect to a reference computer file | |
| CN117390599B (en) | Offline multi-device product license issuing and verifying method, system and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |