CN117201029A - Http communication tamper-proof method and system based on domestic CPU and OS - Google Patents
Http communication tamper-proof method and system based on domestic CPU and OS Download PDFInfo
- Publication number
- CN117201029A CN117201029A CN202311092774.7A CN202311092774A CN117201029A CN 117201029 A CN117201029 A CN 117201029A CN 202311092774 A CN202311092774 A CN 202311092774A CN 117201029 A CN117201029 A CN 117201029A
- Authority
- CN
- China
- Prior art keywords
- client
- signature
- server
- appkey
- information
- 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.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 57
- 238000004891 communication Methods 0.000 title claims abstract description 35
- 238000004364 calculation method Methods 0.000 claims abstract description 15
- 238000012795 verification Methods 0.000 claims description 32
- 238000004458 analytical method Methods 0.000 claims description 24
- 238000011084 recovery Methods 0.000 claims description 6
- 238000004422 calculation algorithm Methods 0.000 description 10
- 230000005540 biological transmission Effects 0.000 description 4
- 238000013496 data integrity verification Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 238000002360 preparation method Methods 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 238000013459 approach Methods 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
Landscapes
- Storage Device Security (AREA)
Abstract
The invention discloses an http communication tamper-proof method and system based on a domestic CPU and an OS, belongs to the technical field of communication, and aims to solve the technical problem of how to realize communication tamper-proof in a domestic environment. The method comprises the following steps: registering: the client sends a registration request to the server and sends a signature to the server; the server compares the calculated signature with the signature received from the client and returns an AppSecret to the client; and (3) login: the client side codes and encrypts to obtain a signature; the server compares the calculated signature with the signature received from the client, and if the calculated signature is consistent with the signature received from the client, the token is returned to the client; other requests: for other logged requests, the client sends the request to the server and sends the signature to the server; the server analyzes and verifies the token and compares the signature obtained by calculation with the signature received from the client.
Description
Technical Field
The invention relates to the technical field of communication, in particular to an http communication tamper-proof method and system based on a domestic CPU and an OS.
Background
In recent years, the development of nationwide software and hardware with independent intellectual property rights is strongly supported by the nation, and a plurality of basic software and hardware products with independent intellectual property rights represented by a domestic operating system and a CPU are emerging. The ecological environment of domestic operating systems such as a Galaxy kylin system, a Union uos operating system and the like is becoming perfect, high-end universal chips with independent intellectual property rights such as Loongson and the like are becoming very popular, and the technical level reaches or approaches the world advanced level of similar products.
With the vigorous development of domestic basic software and hardware, the popularization and the use of domestic basic software and hardware bring unprecedented opportunities. The server has extremely high requirements on safety and stability as a device for bearing corresponding service requests, bearing services and guaranteeing services.
The server often stores some data that is important to the whole system, such as client information, client passwords, and statistics of the whole system. To prevent leakage of such important information, security of the server is particularly important. When the attacker of the server obtains the server data, under the condition that the defending mechanism of the server cannot be completely mastered, the attacker can disguise the attacker as a common user or super user to send a request of specific parameters to the server so as to obtain corresponding data. Tampering with the requested data in normal client requests is a common masquerading method by intercepting the requests.
For preventing data tampering requests, the server mostly adopts asymmetric encryption and a third party certificate method for identification. Asymmetric encryption ensures that the data cannot be directly decrypted after being intercepted to obtain the content and format of the data, and a third party certificate ensures the reliability of encryption. However, the method can simulate normal requests to attack the server by intercepting the public key and the certificate.
How to realize the tamper resistance of communication in domestic environment is a technical problem to be solved.
Disclosure of Invention
The technical task of the invention is to provide the http communication tamper-proof method and the http communication tamper-proof system based on the domestic CPU and the OS to solve the technical problem of communication tamper-proof in the domestic environment.
In a first aspect, the invention provides an http communication tamper-proof method based on a domestic CPU and an OS, comprising the following steps:
registering: the client side uses the AppKey, the hardware information and the asset information as registration information, sends a registration request to the server side, encrypts and obtains a signature based on encoding of the AppKey, the hardware information, the asset information and the timestamp, and sends the signature to the server side; the method comprises the steps that a server analyzes received registration information, codes and encrypts analyzed AppKey, hardware information, asset information and a timestamp to obtain a signature, compares the calculated signature with the signature received from a client, allows the client to register and returns AppSecret to the client if the calculated signature is consistent, wherein the AppKey is generated by the client and serves as a unique identifier of the client, and the AppSecret is generated by the server and stored in a server database, and corresponds to the AppSecret one by one;
and (3) login: the client side sends a login request to the server side based on the APPKey and the timestamp as login information, encrypts and obtains a signature based on the APPKey, the timestamp and the AppSecret, and sends the signature to the server side; the server analyzes the received login request information, retrieves a corresponding AppSecret from a database according to the APPKey, encrypts and obtains a signature based on the APPKey, a time stamp and the AppSecret, compares the obtained signature with the signature received from the client, generates a token based on APPKey, appSecret and the current time if the obtained signature is consistent with the signature received from the client, returns the token to the client, sets the expiration time for the token, and records the effective time of the token;
other requests: for other logged requests, the client sends a request to the server based on a token, a timestamp, an AppSeset, a request parameter and a URL of the current request as request information, encrypts and obtains a signature based on AppSecret, token, the timestamp, the request parameter and the URL of the current request, and sends the signature to the server; after receiving the request information, the server analyzes and verifies the token, after the token passes the verification, the server encrypts and encrypts the received signature based on APPKey, appSecret obtained by the token analysis, the timestamp obtained by the request information analysis, the request parameter and the URL of the current request to obtain the signature, compares the calculated signature with the signature received from the client, and returns response information to the client if the calculated signature is consistent with the signature received from the client.
Preferably, the client performs hybrid coding based on the AppKey, a check item in the hardware information, an ID of the asset information and a time stamp, and generates an MD5 value as a signature;
correspondingly, the service end performs mixed coding on the AppKey obtained by analysis, the check item in the hardware information, the ID of the asset information and the timestamp, and generates an MD5 value as a signature;
the client performs mixed coding based on APPKey, a time stamp and AppSecret, and generates an MD5 value as a signature;
correspondingly, the server retrieves a corresponding AppSecret from the database according to the APPKey, performs hybrid coding based on the APPKey, the timestamp and the AppSecret, and generates an MD5 value as a signature; a step of
Hybrid encoding based on AppSecret, token, timestamp, request parameters, and URL of the current request, and generating MD5 value as signature;
correspondingly, the method carries out mixed coding on the basis of APPKey, appSecret obtained by token analysis and the timestamp obtained by request information analysis, the request parameters and the URL of the current request, and generates an MD5 value as a signature.
Preferably, during registration, comparing the calculated signature with the signature received from the client, if the calculated signature is consistent with the signature received from the client, locating the client in a server database according to the AppKey, and if no data corresponding to the client and no repeated hardware information and asset information exist in the server database, recording the client as a new client and returning the AppSecret to the client; if the data corresponding to the client exists in the database of the server, the authenticity of the data is ensured by comparing the asset information with the hardware information, and registration success information is returned to the client;
if the client loses the AppKey, the registration information sent by the client is inconsistent with the AppKey stored in the database of the server, the client is not registered, and the client makes a recovery request to the server.
Preferably, for other requests, after receiving the request information, the server analyzes the token, determines whether the analyzed content of the token includes APPKey, appSecret and the time of generating the token, so as to verify the information integrity of the token, and if the verification is passed, determines whether the token is within the valid time based on the expiration time of the token.
In a second aspect, the invention provides an http communication tamper-proof system based on a domestic CPU and an OS, including a client and a server, where the client and the server cooperate to execute an http communication tamper-proof method based on the domestic CPU and the OS according to any one of the first aspects;
at registration, the client is configured to perform the following: based on the AppKey, the hardware information and the asset information as registration information, a registration request is sent to a server, encoding encryption is carried out based on the AppKey, the hardware information, the asset information and the time stamp to obtain a signature, and the signature is sent to the server; correspondingly, the server is configured to perform the following: analyzing the received registration information, coding and encrypting the analyzed AppKey, hardware information, asset information and time stamp to obtain a signature, comparing the calculated signature with the signature received from the client, and if the calculated signature is consistent with the signature received from the client, allowing the client to register and returning an AppSecret to the client, wherein the AppKey is generated by the client and is used as a unique identifier of the client, the AppSecret is generated by a server and stored in a database of the server, and the AppKey corresponds to the AppSecret one by one;
the client is used for executing the following steps: based on the APPKey and the timestamp as login information, sending a login request to a server, carrying out coding encryption based on the APPKey, the timestamp and the AppSecret to obtain a signature, and sending the signature to the server; correspondingly, the server is configured to perform the following: analyzing the received login request information, retrieving a corresponding AppSecret from a database according to the APPKey, carrying out coding encryption based on the APPKey, a time stamp and the AppSecret to obtain a signature, comparing the calculated signature with the signature received from the client, generating a token based on APPKey, appSecret and the current time if the calculated signature is consistent with the signature received from the client, returning the token to the client, setting the failure time for the token, and recording the effective time of the token;
for other requests after login, the client is configured to perform the following: based on token, timestamp, appSecret, request parameters and URL of the current request as request information, sending a request to a server, coding and encrypting based on AppSecret, token, timestamp, request parameters and URL of the current request to obtain a signature, and sending the signature to the server; correspondingly, the server is configured to perform the following: after receiving the request information, analyzing and verifying the token, after the token passes the verification, encoding and encrypting based on APPKey, appSecret obtained by the token analysis, a timestamp obtained by the request information analysis, a request parameter and a URL of the current request to obtain a signature, comparing the signature obtained by calculation with the signature received from the client, and if the signature is consistent with the signature, returning response information to the client.
Preferably, the client is used for performing mixed coding based on the AppKey, the check item in the hardware information, the ID of the asset information and the timestamp, and generating an MD5 value as a signature;
correspondingly, the server is used for performing mixed coding on the AppKey obtained through analysis, the check item in the hardware information, the ID of the asset information and the timestamp, and generating an MD5 value as a signature;
the client is used for carrying out mixed coding based on APPKey, a time stamp and AppSecret and generating an MD5 value as a signature;
correspondingly, the server is used for retrieving the corresponding AppSecret from the database according to the APPKey, carrying out mixed coding based on the APPKey, the timestamp and the AppSecret, and generating an MD5 value as a signature; a step of
The client is used for performing mixed coding based on AppSecret, token, the time stamp, the request parameter and the URL of the current request, and generating an MD5 value as a signature;
correspondingly, the server is used for performing mixed coding based on APPKey, appSecret obtained by token analysis and a timestamp obtained by request information analysis, a request parameter and a URL of a current request, and generating an MD5 value as a signature.
Preferably, during registration, comparing the calculated signature with the signature received from the client, if the calculated signature is consistent with the signature received from the client, locating the client by the server according to the AppKey in a server database, and if no data corresponding to the client and no repeated hardware information and asset information exist in the server database, recording the client as a new client and returning the AppSecret to the client; if the data corresponding to the client exists in the database of the server, the authenticity of the data is ensured by comparing the asset information with the hardware information, and registration success information is returned to the client;
if the client loses the AppKey, the registration information sent by the client is inconsistent with the AppKey stored in the database of the server, the client is not registered, and the client is used for providing a recovery request to the server.
Preferably, for other requests, after receiving the request information, the server is configured to perform the following steps: analyzing the token, judging whether the analyzed content of the token comprises APPKey, appSecret and the time for generating the token so as to verify the information integrity of the token, and judging whether the token is in the valid time based on the expiration time of the token if the verification is passed.
The http communication tamper-proof method and system based on the domestic CPU and the OS of the invention has the following advantages:
1. the method can be based on hardware information and asset information of the client device as registration information, can strictly limit registration conditions, and ensures the safety and purity of the registered client to a certain extent;
2. the AppKey, appSecret flow is optimized, so that leakage of AppSecret is effectively avoided, and simulation access by stealing AppKey and AppSecret is effectively prevented;
3. the signature is calculated by carrying out mixed coding on the token, the url of the request and the request parameter mixed AppSecret and the timestamp and calculating the MD5 value, and the integrity of the data is verified through the signature, so that the situation that key data are tampered is effectively prevented, and the request is difficult to forge due to the privacy of the AppSecret.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings that are needed in the embodiments or the description of the prior art will be briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and that other drawings can be obtained according to these drawings without inventive effort for a person skilled in the art.
The invention is further described below with reference to the accompanying drawings.
Fig. 1 is a flow chart of communication between a client and a server in an http communication tamper-proof method based on a domestic CPU and an OS in embodiment 1;
fig. 2 is a flow chart of tamper-proof communication between a client and a server in an http communication tamper-proof method based on a domestic CPU and an OS in embodiment 1.
Detailed Description
The invention will be further described with reference to the accompanying drawings and specific examples, so that those skilled in the art can better understand the invention and implement it, but the examples are not meant to limit the invention, and the technical features of the embodiments of the invention and the examples can be combined with each other without conflict.
The embodiment of the invention provides an http communication tamper-proof method and system based on a domestic CPU and an OS, which are used for solving the technical problem of communication tamper-proof in a domestic environment.
Example 1:
the invention discloses an http communication tamper-proof method based on a domestic CPU and an OS, which comprises the following steps:
s100, registration: the client side uses the AppKey, the hardware information and the asset information as registration information, sends a registration request to the server side, encrypts and obtains a signature based on encoding of the AppKey, the hardware information, the asset information and the timestamp, and sends the signature to the server side; the method comprises the steps that a server analyzes received registration information, codes and encrypts the obtained AppKey, hardware information and asset information and a timestamp to obtain a signature, compares the calculated signature with the signature received from a client, allows the client to register and returns an AppSecret to the client if the calculated signature is consistent with the signature received from the client, wherein the AppKey is generated by the client and serves as a unique identifier of the client, the AppSecret is generated by the server and stored in a server database, the AppKey corresponds to the AppSecret one by one, and the hardware information and the asset information are hardware information and asset information of client equipment;
s200, login: the client side sends a login request to the server side based on the APPKey and the timestamp as login information, encrypts and obtains a signature based on the APPKey, the timestamp and the AppSecret, and sends the signature to the server side; the server analyzes the received login request information, retrieves a corresponding AppSecret from a database according to the APPKey, encrypts and obtains a signature based on the APPKey, a time stamp and the AppSecret, compares the obtained signature with the signature received from the client, generates a token based on APPKey, appSecret and the current time if the obtained signature is consistent with the signature received from the client, returns the token to the client, sets the expiration time for the token, and records the effective time of the token;
s300 other requests: for other logged requests, the client sends a request to the server based on a token, a timestamp, an AppSeset, a request parameter and a URL of the current request as request information, encrypts and obtains a signature based on AppSecret, token, the timestamp, the request parameter and the URL of the current request, and sends the signature to the server; after receiving the request information, the server analyzes and verifies the token, after the token passes the verification, the server encrypts and encrypts the received signature based on APPKey, appSecret obtained by the token analysis, the timestamp obtained by the request information analysis, the request parameter and the URL of the current request to obtain the signature, compares the calculated signature with the signature received from the client, and returns response information to the client if the calculated signature is consistent with the signature received from the client.
When registering in step S100, the client generates a UUID as an AppKey, and sends a registration request to the server together with the machine hardware information and asset information of the client as request contents. Wherein, the timestamp, appKey and check item (here, MAC is taken as an example) in the hardware information and ID of the asset information at the time of request are mixed-coded and md5 is generated as signature.
When the server processes the registration request, the mixed coding is firstly carried out according to the AppKey, the MAC and the asset ID in the request packet, the md5 is calculated, the comparison is carried out with the signature in the request, if the comparison is the same, the data is proved to be complete, otherwise, the data is not proved to be complete, and the registration is not carried out.
After md5 passes the comparison, positioning the client in a server database according to the AppKey, recording as a new client if no repeated MAC and asset ID exist in the database, and returning to the AppSecret; if the data exists in the database, comparing the MAC with the asset ID to ensure the authenticity of the data, and returning to successful registration; if the client loses the AppKey due to special reasons, the requested data is inconsistent with the data AppKey in the database, registration is not performed, and a recovery request is provided in the asset system.
In this process, the AppKey is in an exposed state, and AppSecret is exposed only when a new client is registered. The registration process is to use https protocol instead of http in order to guarantee the privacy of AppSecret.
In the login process of step S200, the AppKey and the timestamp of the client form the data of the login request, and AppSecret, appKey and the timestamp are added into the data to perform hash calculation to generate a characteristic value as a signature. After receiving the request, the server searches the corresponding AppSecret in the database according to the AppKey, and performs hash calculation again by combining with the timestamp to generate a characteristic value, and compares the characteristic value with the signature in the request to verify the integrity of the login data. The characteristic value generated by hash calculation replaces plaintext transmission of AppSecret.
After verification is successful, the server returns the token generated by mixing AppKey, appSecret with the current time to the client as a certificate logged in after the client, sets the expiration time for the token, and records the validation time of the token. Subsequent requests from clients all require verification of this token. Because the token is only generated at the server and parsed at the server, no information of the AppSecret and the private key required by the algorithm for generating or parsing the token is revealed.
Step S300 is to add a token to the http header for other logged requests, and perform hash computation using AppSecret, token, timestamp, url, and request parameters as a signature, and send a response request to the server.
After the server receives the request, the token should be parsed first, the correctness of the information in the token should be verified, and whether the token is invalid or not, the verification can determine whether the source of the request is a legal client or not, and preparation is made for the next hash algorithm verification.
After verification, hash calculation is carried out according to AppKey, appSecret analyzed in the token and the timestamp, the request parameter and the url of the current request in combination, and signature verification is carried out, so that the url and the parameter of the request are ensured not to be tampered.
In summary, the registration-login procedure uses the asset management ID and the machine hardware information as the registered credentials to strengthen the uniqueness of the client ID. In login and other requests, the md5 algorithm is used for encrypting key information such as AppSecret, so that leakage of the AppSecret is effectively prevented, and the function of preventing the key information of other requests from being tampered is achieved.
The method of the present embodiment involves the following aspects:
(1) Generation of AppKey and AppSecret
The AppKey is generated by the client, and the AppSecret is generated by the server. The AppKey takes account of the effect of the unique identifier of the client, is generated in the registration process, and is respectively stored in the client and the server without being transmitted in the clear in any route.
(2) Use of token
In the method described in this patent, after the registration is successful, the registration can be performed by using the AppKey and the AppSecret, after the registration is successful, the server should issue a token to the client, and after all the client requests, the server should carry the token to perform an http request. the token is time-efficient and requires the client to acquire a new token from a new login operation after the token fails. the token carries information such as AppKey of the client, and the tokens of different clients cannot be mixed.
(3) Use of time stamps
The timestamp is a string of numbers that can mark the current time. In the method, the timestamp of the request is marked in the request header of each http, the server limits the time recorded in the timestamp, compares the time obtained when the request is processed with the time in the timestamp of the request, does not process the request exceeding a certain threshold range, and returns a notification of overtime of the timestamp.
(4) AppKey, appSecret, token encryption method
The encrypted information in the login process is AppKey, appSecret and a time stamp. Other requests after logging require hash computation with AppSecret, token, time stamp, url of the request, content of the request, etc. And the characteristic value calculated through the hash algorithm is used for ensuring that the information transmission is complete and consistent.
(5) Data integrity verification method
The server verification method is divided into two parts, namely identity information verification and characteristic value verification.
Authentication of identity information is achieved through a token. the token has information of AppKey for verification of the client, and the client sending the request can be determined by analyzing the token for identity information verification.
And verifying the characteristic value, namely performing characteristic value calculation on the transmitted data through the same hash algorithm as the client, and comparing the characteristic value calculated by the server and the client.
The method of the embodiment improves the traditional AppKey, appSecret and token flow based on the core point, and enhances the security of the communication mode.
Example 2:
the invention discloses an http communication tamper-proof system based on a domestic CPU and an OS, which comprises a client and a server, wherein the client and the server cooperate to execute the method disclosed in the embodiment 1.
At registration, the client is configured to perform the following: based on the AppKey, the hardware information and the asset information as registration information, a registration request is sent to a server, encoding encryption is carried out based on the AppKey, the hardware information, the asset information and the time stamp to obtain a signature, and the signature is sent to the server; correspondingly, the server is configured to perform the following: analyzing the received registration information, coding and encrypting the analyzed AppKey, hardware information, asset information and time stamp to obtain a signature, comparing the calculated signature with the signature received from the client, and if the calculated signature is consistent with the signature received from the client, allowing the client to register and returning an AppSecret to the client, wherein the AppKey is generated by the client and is used as a unique identifier of the client, the AppSecret is generated by the server and stored in a database of the server, and the AppKey corresponds to the AppSecret one by one.
In this embodiment, during registration, the client generates a UUID as an AppKey, and sends a registration request to the server together with the machine hardware information and asset information of the client as request contents. Wherein, the timestamp, appKey and check item (here, MAC is taken as an example) in the hardware information and ID of the asset information at the time of request are mixed-coded and md5 is generated as signature.
When the server processes the registration request, the mixed coding is firstly carried out according to the AppKey, the MAC and the asset ID in the request packet, the md5 is calculated, the comparison is carried out with the signature in the request, if the comparison is the same, the data is proved to be complete, otherwise, the data is not proved to be complete, and the registration is not carried out.
After md5 passes the comparison, positioning the client in a server database according to the AppKey, recording as a new client if no repeated MAC and asset ID exist in the database, and returning to the AppSecret; if the data exists in the database, comparing the MAC with the asset ID to ensure the authenticity of the data, and returning to successful registration; if the client loses the AppKey due to special reasons, the requested data is inconsistent with the data AppKey in the database, registration is not performed, and a recovery request is provided in the asset system.
In this process, the AppKey is in an exposed state, and AppSecret is exposed only when a new client is registered. The registration process is to use https protocol instead of http in order to guarantee the privacy of AppSecret.
At login, the client is used for executing the following steps: based on the APPKey and the timestamp as login information, sending a login request to a server, carrying out coding encryption based on the APPKey, the timestamp and the AppSecret to obtain a signature, and sending the signature to the server; correspondingly, the server is configured to perform the following: analyzing the received login request information, retrieving a corresponding AppSecret from a database according to the APPKey, carrying out coding encryption based on the APPKey, a time stamp and the AppSecret to obtain a signature, comparing the calculated signature with the signature received from the client, generating a token based on APPKey, appSecret and the current time if the calculated signature is consistent with the signature received from the client, returning the token to the client, setting the failure time for the token, and recording the effective time of the token.
In this embodiment, in the login process, the AppKey and the timestamp of the client form the data of the login request, and AppSecret, appKey and the timestamp are added to the data to perform hash calculation to generate a characteristic value as a signature. After receiving the request, the server searches the corresponding AppSecret in the database according to the AppKey, and performs hash calculation again by combining with the timestamp to generate a characteristic value, and compares the characteristic value with the signature in the request to verify the integrity of the login data. The characteristic value generated by hash calculation replaces plaintext transmission of AppSecret.
After the verification is successful, the server is used for returning the token generated by mixing AppKey, appSecret with the current time to the client, taking the token as a credential logged in after the client, setting the expiration time for the token, and recording the validation time of the token. Subsequent requests from clients all require verification of this token. Because the token is only generated at the server and parsed at the server, no information of the AppSecret and the private key required by the algorithm for generating or parsing the token is revealed.
For other requests after login, the client is configured to perform the following: based on token, timestamp, appSecret, request parameters and URL of the current request as request information, sending a request to a server, coding and encrypting based on AppSecret, token, timestamp, request parameters and URL of the current request to obtain a signature, and sending the signature to the server; correspondingly, the server is configured to perform the following: after receiving the request information, analyzing and verifying the token, after the token passes the verification, encoding and encrypting based on APPKey, appSecret obtained by the token analysis, a timestamp obtained by the request information analysis, a request parameter and a URL of the current request to obtain a signature, comparing the signature obtained by calculation with the signature received from the client, and if the signature is consistent with the signature, returning response information to the client.
In this embodiment, for other requests after login, a token needs to be added to the http header, hash calculation is performed using AppSecret, token, a timestamp, url, and a request parameter as a signature, and a response request is sent to the server.
After the server receives the request, the token should be parsed first, the correctness of the information in the token should be verified, and whether the token is invalid or not, the verification can determine whether the source of the request is a legal client or not, and preparation is made for the next hash algorithm verification.
After verification, hash calculation is carried out according to AppKey, appSecret analyzed in the token and the timestamp, the request parameter and the url of the current request in combination, and signature verification is carried out, so that the url and the parameter of the request are ensured not to be tampered.
In summary, the registration-login procedure uses the asset management ID and the machine hardware information as the registered credentials to strengthen the uniqueness of the client ID. In login and other requests, the md5 algorithm is used for encrypting key information such as AppSecret, so that leakage of the AppSecret is effectively prevented, and the function of preventing the key information of other requests from being tampered is achieved.
The communication system of the present embodiment involves the following aspects when performing the method of embodiment 1 for communication:
(1) Generation of AppKey and AppSecret
The AppKey is generated by the client, and the AppSecret is generated by the server. The AppKey takes account of the effect of the unique identifier of the client, is generated in the registration process, and is respectively stored in the client and the server without being transmitted in the clear in any route.
(2) Use of token
In the method described in this patent, after the registration is successful, the registration can be performed by using the AppKey and the AppSecret, after the registration is successful, the server should issue a token to the client, and after all the client requests, the server should carry the token to perform an http request. the token is time-efficient and requires the client to acquire a new token from a new login operation after the token fails. the token carries information such as AppKey of the client, and the tokens of different clients cannot be mixed.
(3) Use of time stamps
The timestamp is a string of numbers that can mark the current time. In the method, the timestamp of the request is marked in the request header of each http, the server limits the time recorded in the timestamp, compares the time obtained when the request is processed with the time in the timestamp of the request, does not process the request exceeding a certain threshold range, and returns a notification of overtime of the timestamp.
(4) AppKey, appSecret, token encryption method
The encrypted information in the login process is AppKey, appSecret and a time stamp. Other requests after logging require hash computation with AppSecret, token, time stamp, url of the request, content of the request, etc. And the characteristic value calculated through the hash algorithm is used for ensuring that the information transmission is complete and consistent.
(5) Data integrity verification method
The server verification method is divided into two parts, namely identity information verification and characteristic value verification.
Authentication of identity information is achieved through a token. the token has information of AppKey for verification of the client, and the client sending the request can be determined by analyzing the token for identity information verification.
And verifying the characteristic value, namely performing characteristic value calculation on the transmitted data through the same hash algorithm as the client, and comparing the characteristic value calculated by the server and the client.
The method of the embodiment improves the traditional AppKey, appSecret and token flow based on the core point, and enhances the security of the communication mode.
While the invention has been illustrated and described in detail in the drawings and in the preferred embodiments, the invention is not limited to the disclosed embodiments, but it will be apparent to those skilled in the art that many more embodiments of the invention can be made by combining the means of the various embodiments described above and still fall within the scope of the invention.
Claims (8)
1. An http communication tamper-proof method based on a domestic CPU and an OS is characterized by comprising the following steps:
registering: the client side uses the AppKey, the hardware information and the asset information as registration information, sends a registration request to the server side, encrypts and obtains a signature based on encoding of the AppKey, the hardware information, the asset information and the timestamp, and sends the signature to the server side; the method comprises the steps that a server analyzes received registration information, codes and encrypts the obtained AppKey, hardware information and asset information and a timestamp to obtain a signature, compares the calculated signature with the signature received from a client, allows the client to register and returns an AppSecret to the client if the calculated signature is consistent with the signature received from the client, wherein the AppKey is generated by the client and serves as a unique identifier of the client, the AppSecret is generated by the server and stored in a server database, the AppKey corresponds to the AppSecret one by one, and the hardware information and the asset information are hardware information and asset information of client equipment;
and (3) login: the client side sends a login request to the server side based on the APPKey and the timestamp as login information, encrypts and obtains a signature based on the APPKey, the timestamp and the AppSecret, and sends the signature to the server side; the server analyzes the received login request information, retrieves a corresponding AppSecret from a database according to the APPKey, encrypts and obtains a signature based on the APPKey, a time stamp and the AppSecret, compares the obtained signature with the signature received from the client, generates a token based on APPKey, appSecret and the current time if the obtained signature is consistent with the signature received from the client, returns the token to the client, sets the expiration time for the token, and records the effective time of the token;
other requests: for other logged requests, the client sends a request to the server based on a token, a timestamp, an AppSeset, a request parameter and a URL of the current request as request information, encrypts and obtains a signature based on AppSecret, token, the timestamp, the request parameter and the URL of the current request, and sends the signature to the server; after receiving the request information, the server analyzes and verifies the token, after the token passes the verification, the server encrypts and encrypts the received signature based on APPKey, appSecret obtained by the token analysis, the timestamp obtained by the request information analysis, the request parameter and the URL of the current request to obtain the signature, compares the calculated signature with the signature received from the client, and returns response information to the client if the calculated signature is consistent with the signature received from the client.
2. The http communication tamper-proof method based on the domestic CPU and the OS according to claim 1, wherein the client performs hybrid encoding based on the AppKey, a check item in hardware information, an ID of asset information, and a time stamp, and generates an MD5 value as a signature;
correspondingly, the service end performs mixed coding on the AppKey obtained by analysis, the check item in the hardware information, the ID of the asset information and the timestamp, and generates an MD5 value as a signature;
the client performs mixed coding based on APPKey, a time stamp and AppSecret, and generates an MD5 value as a signature;
correspondingly, the server retrieves a corresponding AppSecret from the database according to the APPKey, performs hybrid coding based on the APPKey, the timestamp and the AppSecret, and generates an MD5 value as a signature; a step of
The client performs mixed encoding based on AppSecret, token, the time stamp, the request parameter and the URL of the current request, and generates an MD5 value as a signature;
correspondingly, the server performs mixed encoding on the basis of APPKey, appSecret obtained by token analysis and the timestamp obtained by request information analysis, the request parameter and the URL of the current request, and generates an MD5 value as a signature.
3. The http communication tamper-proof method based on a domestic CPU and an OS according to claim 1, wherein, when registering, the calculated signature is compared with the signature received from the client, if it is consistent, the client is located according to AppKey in a server database, if there is no data corresponding to the client in the server database and there is no repeated hardware information and asset information, it is recorded as a new client, and AppSecret is returned to the client; if the data corresponding to the client exists in the database of the server, the authenticity of the data is ensured by comparing the asset information with the hardware information, and registration success information is returned to the client;
if the client loses the AppKey, the registration information sent by the client is inconsistent with the AppKey stored in the database of the server, the client is not registered, and the client makes a recovery request to the server.
4. The method according to claim 1, wherein for other requests, after the server receives the request information, the server parses the token, determines whether the parsed content of the token includes APPKey, appSecret and the time of generating the token, so as to verify the information integrity of the token, and if the verification is passed, determines whether the token is within the valid time based on the expiration time of the token.
5. An http communication tamper-proof system based on a domestic CPU and an OS, which is characterized by comprising a client and a server, wherein the client and the server are matched and used for executing the http communication tamper-proof method based on the domestic CPU and the OS as set forth in any one of claims 1-4;
at registration, the client is configured to perform the following: based on the AppKey, the hardware information and the asset information as registration information, a registration request is sent to a server, encoding encryption is carried out based on the AppKey, the hardware information, the asset information and the time stamp to obtain a signature, and the signature is sent to the server; correspondingly, the server is configured to perform the following: analyzing the received registration information, coding and encrypting the analyzed AppKey, hardware information, asset information and time stamp to obtain a signature, comparing the calculated signature with the signature received from the client, and if the calculated signature is consistent with the signature received from the client, allowing the client to register and returning an AppSecret to the client, wherein the AppKey is generated by the client and is used as a unique identifier of the client, the AppSecret is generated by a server and stored in a database of the server, and the AppKey corresponds to the AppSecret one by one;
the client is used for executing the following steps: based on the APPKey and the timestamp as login information, sending a login request to a server, carrying out coding encryption based on the APPKey, the timestamp and the AppSecret to obtain a signature, and sending the signature to the server; correspondingly, the server is configured to perform the following: analyzing the received login request information, retrieving a corresponding AppSecret from a database according to the APPKey, carrying out coding encryption based on the APPKey, a time stamp and the AppSecret to obtain a signature, comparing the calculated signature with the signature received from the client, generating a token based on APPKey, appSecret and the current time if the calculated signature is consistent with the signature received from the client, returning the token to the client, setting the failure time for the token, and recording the effective time of the token;
for other requests after login, the client is configured to perform the following: based on token, timestamp, appSecret, request parameters and URL of the current request as request information, sending a request to a server, coding and encrypting based on AppSecret, token, timestamp, request parameters and URL of the current request to obtain a signature, and sending the signature to the server; correspondingly, the server is configured to perform the following: after receiving the request information, analyzing and verifying the token, after the token passes the verification, encoding and encrypting based on APPKey, appSecret obtained by the token analysis, a timestamp obtained by the request information analysis, a request parameter and a URL of the current request to obtain a signature, comparing the signature obtained by calculation with the signature received from the client, and if the signature is consistent with the signature, returning response information to the client.
6. The http communication tamper-resistant system based on the domestic CPU and the OS according to claim 5, wherein the client is configured to perform hybrid encoding based on the AppKey, a check item in hardware information, an ID of asset information, and a timestamp, and generate an MD5 value as a signature;
correspondingly, the server is used for performing mixed coding on the AppKey obtained through analysis, the check item in the hardware information, the ID of the asset information and the timestamp, and generating an MD5 value as a signature;
the client is used for carrying out mixed coding based on APPKey, a time stamp and AppSecret and generating an MD5 value as a signature;
correspondingly, the server is used for retrieving the corresponding AppSecret from the database according to the APPKey, carrying out mixed coding based on the APPKey, the timestamp and the AppSecret, and generating an MD5 value as a signature; a step of
The client is used for performing mixed coding based on AppSecret, token, the time stamp, the request parameter and the URL of the current request, and generating an MD5 value as a signature;
correspondingly, the server is used for performing mixed coding based on APPKey, appSecret obtained by token analysis and a timestamp obtained by request information analysis, a request parameter and a URL of a current request, and generating an MD5 value as a signature.
7. The http communication tamper-resistant system based on a domestic CPU and an OS according to claim 5, wherein, when registering, the calculated signature is compared with the signature received from the client, if the calculated signature is consistent, in a server database, the server is used for locating the client according to the AppKey, if there is no data corresponding to the client in the server database, and there is no repeated hardware information and asset information, the server is recorded as a new client, and AppSecret is returned to the client; if the data corresponding to the client exists in the database of the server, the authenticity of the data is ensured by comparing the asset information with the hardware information, and registration success information is returned to the client;
if the client loses the AppKey, the registration information sent by the client is inconsistent with the AppKey stored in the database of the server, the client is not registered, and the client is used for providing a recovery request to the server.
8. The http communication tamper-resistant system based on the domestic CPU and the OS according to claim 5, wherein for other requests, after the server receives the request information, the server is configured to perform the following: analyzing the token, judging whether the analyzed content of the token comprises APPKey, appSecret and the time for generating the token so as to verify the information integrity of the token, and judging whether the token is in the valid time based on the expiration time of the token if the verification is passed.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311092774.7A CN117201029A (en) | 2023-08-29 | 2023-08-29 | Http communication tamper-proof method and system based on domestic CPU and OS |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311092774.7A CN117201029A (en) | 2023-08-29 | 2023-08-29 | Http communication tamper-proof method and system based on domestic CPU and OS |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117201029A true CN117201029A (en) | 2023-12-08 |
Family
ID=88986199
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311092774.7A Pending CN117201029A (en) | 2023-08-29 | 2023-08-29 | Http communication tamper-proof method and system based on domestic CPU and OS |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117201029A (en) |
-
2023
- 2023-08-29 CN CN202311092774.7A patent/CN117201029A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112218294B (en) | 5G-based access method and system for Internet of things equipment and storage medium | |
| US10516662B2 (en) | System and method for authenticating the legitimacy of a request for a resource by a user | |
| US6732270B1 (en) | Method to authenticate a network access server to an authentication server | |
| Backes et al. | Cryptographically sound security proofs for basic and public-key kerberos | |
| US20140006781A1 (en) | Encapsulating the complexity of cryptographic authentication in black-boxes | |
| CN111800378B (en) | Login authentication method, device, system and storage medium | |
| CN111884811B (en) | Block chain-based data evidence storing method and data evidence storing platform | |
| JP3362780B2 (en) | Authentication method in communication system, center device, recording medium storing authentication program | |
| CN109687965A (en) | The real name identification method of subscriber identity information in a kind of protection network | |
| CN113872932B (en) | SGX-based micro-service interface authentication method, system, terminal and storage medium | |
| CN110838920B (en) | Password authentication and key agreement protocol in web system without storing password related information | |
| CN110768973A (en) | Signaling safety evaluation system and method based on GB35114 standard | |
| JP2001186122A (en) | Authentication system and authentication method | |
| CN110891065A (en) | Token-based user identity auxiliary encryption method | |
| CN111600948B (en) | Cloud platform application and data security processing method, system, storage medium and program based on identification password | |
| CN114513339A (en) | Security authentication method, system and device | |
| Kleiner et al. | On the relationship between web services security and traditional protocols | |
| CN110572392A (en) | Identity authentication method based on HyperLegger network | |
| CN111225001B (en) | Block chain decentralized communication method, electronic equipment and system | |
| CN115549930B (en) | Verification method for logging in operating system | |
| CN113992336B (en) | Encryption network offline data trusted exchange method and device based on block chain | |
| CN113285934B (en) | Method and device for detecting IP (Internet protocol) of server cryptographic machine client based on digital signature | |
| CN112035820B (en) | Data analysis method used in Kerberos encryption environment | |
| CN117201029A (en) | Http communication tamper-proof method and system based on domestic CPU and OS | |
| CN114422266A (en) | IDaaS system based on dual verification mechanism |
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 |