CN109547445B - Method and system for verifying legality of network request of client - Google Patents
Method and system for verifying legality of network request of client Download PDFInfo
- Publication number
- CN109547445B CN109547445B CN201811438219.4A CN201811438219A CN109547445B CN 109547445 B CN109547445 B CN 109547445B CN 201811438219 A CN201811438219 A CN 201811438219A CN 109547445 B CN109547445 B CN 109547445B
- Authority
- CN
- China
- Prior art keywords
- client
- key
- secret
- code
- security
- 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
- 238000000034 method Methods 0.000 title claims abstract description 22
- 238000013475 authorization Methods 0.000 claims description 7
- 230000001172 regenerating effect Effects 0.000 claims description 6
- 230000000977 initiatory effect Effects 0.000 claims description 4
- 238000004891 communication Methods 0.000 description 2
- 238000012795 verification Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 238000010586 diagram Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000003999 initiator Substances 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
- H04L63/108—Network architectures or network communication protocols for network security for controlling access to devices or network resources when the policy decisions are valid for a limited amount of time
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/12—Applying verification of the received information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
- H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Power Engineering (AREA)
- Computer And Data Communications (AREA)
Abstract
The invention relates to a method and a system for verifying the legality of a client network request, wherein the method comprises the following steps: the client requests a secret key _ key from the server, then generates a security code _ code according to a preset rule, and then encrypts the security code with a symmetric encryption algorithm to obtain a token api _ token; when a request is initiated, the client places the client id and the api _ token in an interface and sends the client id and the api _ token to the server, and after the server verifies that the api _ token is valid, whether the interface is in a valid period or not is detected; if so, the requested data is returned, otherwise, the interface expiration timestamp is updated and a secret _ key is generated again, and the new secret _ key is sent to the client, and the client resends the request according to the new secret _ key. The invention can verify the request initiated by the client, and ensure that the data of the client is not intercepted and artificially tampered by the sniffer in the network request process.
Description
Technical Field
The present invention relates to a secure communication technology between a client and a server, and in particular, to a method and a system for verifying that a network request of a client is legitimate.
Background
In the prior art, the client and the server transmit data by using https, so that the requirement on the security of the data is not high, and the flexibility is not enough for the special project requirements.
Disclosure of Invention
The present invention is directed to solving the above-mentioned problems in the communication between the client and the server in the prior art.
To achieve the above object, in one aspect, the present invention provides a method for verifying that a network request of a client is legal, the method comprising the following steps:
the client requests a secret key _ key from the server, then generates a security code _ code according to a preset rule, and then encrypts the security code with a symmetric encryption algorithm to obtain a token api _ token; when a request is initiated, the client places the client id and the api _ token in an interface and sends the client id and the api _ token to the server, and after the server verifies that the api _ token is valid, whether the interface is in a valid period or not is detected; if so, the requested data is returned, otherwise, the interface expiration timestamp is updated and a secret _ key is generated again, and the new secret _ key is sent to the client, and the client resends the request according to the new secret _ key.
Preferably, the security code security _ code is generated by the following preset rule: security _ code ═ Module + controller + Function + Date; wherein, Module is the Module to which the Function belongs, controller is the specific execution Module, Function is the Function in the Module which is finally responsible for the Function, and Date is the current Date.
Preferably, the table of the key secret _ key includes a user table user _ table; when the service side verifies that the api _ token is valid, whether the interface is in the valid period or not is detected, if not, the interface expiration timestamp is updated and a secret _ key is generated again, the secret _ key is updated to the user _ table, the new secret _ key is sent to the client side, and the client side sends a request again according to the new secret _ key.
Preferably, when the client initiates an interface request for the first time, the server will make a record, and the table structure includes an authorization table, which contains fields add _ time and expire _ time; and judging whether the current timestamp exceeds the expire _ time or not in the stage, if so, updating the add _ time and the expire _ time, regenerating a secret _ key and updating the secret _ key to a user _ table, returning the new secret _ key to the client, and initiating the request again by the client according to the new secret _ key.
Preferably, when a request is initiated, the client places the client id and the api _ token in the interface and sends the client id and the api _ token to the server, the server decrypts the security _ code by using the security _ key corresponding to the client _ id in the database table after receiving the request, then generates a security _ code _ s by using a preset rule, and then judges whether the security _ code is equal to the security _ code _ s, if so, the security _ code is not tampered in the interface request process, otherwise, an error is directly returned.
In another aspect, the present invention provides a system for verifying the validity of a network request of a client, comprising a client and a server; wherein,
the client requests a secret key _ key from the server, then generates a security code _ code according to a preset rule, and then encrypts the security code with a symmetric encryption algorithm to obtain a token api _ token;
when a request is initiated, the client places the client id and the api _ token in an interface and sends the client id and the api _ token to the server, and after the server verifies that the api _ token is valid, whether the interface is in a valid period or not is detected; if so, the requested data is returned, otherwise, the interface expiration timestamp is updated and a secret _ key is generated again, and the new secret _ key is sent to the client, and the client resends the request according to the new secret _ key.
The invention can verify the request initiated by the client, and ensure that the data of the client is not intercepted and artificially tampered by the sniffer in the network request process.
Drawings
Fig. 1 is a schematic flowchart of a method for verifying that a network request of a client is legal according to an embodiment of the present invention;
fig. 2 is a system application scenario diagram for verifying that a network request of a client is legal according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are some, but not all, embodiments of the present invention. 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 invention.
Fig. 1 is a flowchart illustrating a method for verifying that a network request of a client is legal according to an embodiment of the present invention. As shown in fig. 1, the method comprises steps S101-S102:
step S101, a client requests a secret key _ key from a server, then a security code security _ code is generated according to a preset rule, and then the security _ code is encrypted by using a symmetric encryption algorithm to obtain a token api _ token; the security code security _ code is generated by the following preset rules: security _ code ═ Module + controller + Function + Date; wherein, Module is the Module to which the Function belongs, controller is the specific execution Module, Function is the Function in the Module which is finally responsible for the Function, and Date is the current Date.
The table of the key secret _ key includes a user table user _ table (as in table 1); when the service side verifies that the api _ token is valid, whether the interface is in the valid period or not is detected, if not, the interface expiration timestamp is updated and a secret _ key is generated again, the secret _ key is updated to the user _ table, the new secret _ key is sent to the client side, and the client side sends a request again according to the new secret _ key.
Table 1: user meter (user _ table)
| Name of field | Type of field | Description of the invention |
| client_id | varchar(20) | Client ID |
| secret_key | varchar(20) | Symmetric encryption key |
Step S102, when a request is initiated, a client places a client id and an api _ token in an interface and sends the client id and the api _ token to a server, and after the server verifies that the api _ token is valid, whether the interface is in a valid period or not is detected; if so, the requested data is returned, otherwise, the interface expiration timestamp is updated and a secret _ key is generated again, and the new secret _ key is sent to the client, and the client resends the request according to the new secret _ key.
Preferably, when a request is initiated, the client places the client id and the api _ token in the interface and sends the client id and the api _ token to the server, the server decrypts the security _ code by using the security _ key corresponding to the client _ id in the database table after receiving the request, then generates a security _ code _ s by using a preset rule, and then judges whether the security _ code is equal to the security _ code _ s, if so, the security _ code is not tampered in the interface request process, otherwise, an error is directly returned.
In one embodiment, when the client initiates an interface request for the first time, the server will make a record, and the table structure includes an authorization table, which contains fields add _ time and expire _ time (as shown in table 2);
table 2: authorization table (authorized _ table):
and judging whether the current timestamp exceeds the expire _ time or not in the stage, if so, updating the add _ time and the expire _ time, regenerating a secret _ key and updating the secret _ key to a user _ table, returning the new secret _ key to the client, and initiating the request again by the client according to the new secret _ key. Thus completing the security verification of a network request.
In an example, if the client wants to enter a page of music details from a music list by clicking, the data of the music details needs to be returned from the server at this time, and the specific operations are as follows:
according to the client-server agreement, this request is divided into the following parts, Product: the Module belongs to a Module (the Module may also comprise a User, a Service, a Vip and the like) part and represents a music product Module, including product updating and adding, product information and the like; ProductInfo: the part of controller (controller also includes product update, addition, etc.) represents that the information of music is relevant; product detail: a Function (Function also includes a music list and the like) part, which represents the details of music; the Module, the controller and the Function are logically divided layers, and the ProductInfo and the ProductDetail are actually used.
The client requests a secret _ key from the server through http and obtains a server time Date (accurate to the second level), and then generates a secret _ code according to a rule M (secret _ code is Product + Product info + Product detail + Date); then, using DES (the encryption mode can encrypt and decrypt data according to the key, and the result obtained by encrypting the same data by the same key is definitely the same) to encrypt security _ code according to the key secret _ key to obtain api _ token; and then the user id (namely the client _ id) and the api _ token are sent to the server side.
The server side finds the corresponding secret _ key from the library according to the client _ id, if the secret _ key is not expired, data is decrypted according to the secret _ key, the data is temporarily recorded as the secret _ code _ c (if the data is not tampered in the transmission process, the secret _ code _ c generated by the client side is supposed to be), at this time, a secret _ code _ s is calculated according to the rule M, the requested interface information and the add _ time (in the data table structure), then the secret _ code _ c and the secret _ code _ s are compared, and if the secret _ code _ c and the secret _ code _ s are equal, the music detail information is returned; if any verification error occurs, an error message is returned to inform the client, the client re-initiates a request of secret _ key and Data, and then the process goes once more.
The method has the advantages that the service end can control the valid period which can be used after the client end is verified once, and replace the whole-course http request and the corresponding performance consumption of the two ends.
Correspondingly, the embodiment of the invention also provides a system for verifying that the network request of the client is legal (as shown in fig. 2), which comprises the client and a server; wherein,
the client requests a secret key _ key from the server, then generates a security code _ code according to a preset rule, and then encrypts the security code with a symmetric encryption algorithm to obtain a token api _ token;
when a request is initiated, the client places the client id and the api _ token in an interface and sends the client id and the api _ token to the server, and after the server verifies that the api _ token is valid, whether the interface is in a valid period or not is detected; if so, the requested data is returned, otherwise, the interface expiration timestamp is updated and a secret _ key is generated again, and the new secret _ key is sent to the client, and the client resends the request according to the new secret _ key.
The invention can verify the request initiated by the client, and ensure that the data of the client is not intercepted and artificially tampered by the sniffer in the network request process. In addition, the invention can ensure the uniqueness and the safety of the data of the initiator in the network request process.
The above-mentioned embodiments are intended to illustrate the objects, technical solutions and advantages of the present invention in further detail, and it should be understood that the above-mentioned embodiments are merely exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made within the spirit and principle of the present invention should be included in the scope of the present invention.
Claims (4)
1. A method for verifying that a client network request is legitimate, comprising the steps of:
the client requests a secret key _ key from the server, then generates a security code _ code according to a preset rule, and then encrypts the security code with a symmetric encryption algorithm to obtain a token api _ token;
when a request is initiated, the client places the client id and the api _ token in an interface and sends the client id and the api _ token to the server, and after the server verifies that the api _ token is valid, whether the interface is in a valid period or not is detected; if so, returning the requested data, if not, updating the interface expiration timestamp and regenerating a secret _ key, sending the new secret _ key to the client, and sending the request again by the client according to the new secret _ key;
when a client initiates an interface request for the first time, a server makes a record, a table structure comprises an authorization table, and the authorization table comprises a field add _ time and an expiry _ time; judging whether the current timestamp exceeds the expire _ time or not in the stage, if so, updating add _ time and expire _ time, regenerating a secret _ key and updating the secret _ key to a user _ table, returning the new secret _ key to the client, and initiating the request again by the client according to the new secret _ key;
the security code security _ code is generated by the following preset rules: security _ code = (Module + controller + Function + Date); wherein, Module is the Module to which the Function belongs, controller is the specific execution Module, Function is the Function in the Module which is finally responsible for the Function, Date is the current Date;
the table of the key secret _ key comprises a user table user _ table; when the service side verifies that the api _ token is valid, whether the interface is in the valid period or not is detected, if not, the interface expiration timestamp is updated and a secret _ key is generated again, the secret _ key is updated to the user _ table, the new secret _ key is sent to the client side, and the client side sends a request again according to the new secret _ key.
2. The method according to claim 1, wherein when a request is initiated, the client sends the client id and the api _ token in the interface to the server, the server decrypts the security _ code with the security _ key corresponding to the client _ id in the database table after receiving the request, then generates a security _ code _ s with a preset rule, and then determines whether the security _ code is equal to the security _ code _ s, if so, the security _ code is not tampered in the interface request process, otherwise, an error is directly returned.
3. A system for verifying the legality of a network request of a client is characterized by comprising the client and a server; wherein,
the client requests a secret key _ key from the server, then generates a security code _ code according to a preset rule, and then encrypts the security code with a symmetric encryption algorithm to obtain a token api _ token;
when a request is initiated, the client places the client id and the api _ token in an interface and sends the client id and the api _ token to the server, and after the server verifies that the api _ token is valid, whether the interface is in a valid period or not is detected; if so, returning the requested data, if not, updating the interface expiration timestamp and regenerating a secret _ key, sending the new secret _ key to the client, and sending the request again by the client according to the new secret _ key;
when a client initiates an interface request for the first time, a server makes a record, a table structure comprises an authorization table, and the authorization table comprises a field add _ time and an expiry _ time; judging whether the current timestamp exceeds the expire _ time or not in the stage, if so, updating add _ time and expire _ time, regenerating a secret _ key and updating the secret _ key to a user _ table, returning the new secret _ key to the client, and initiating the request again by the client according to the new secret _ key;
the security code security _ code is generated by the following preset rules: security _ code = (Module + controller + Function + Date); wherein, Module is the Module to which the Function belongs, controller is the specific execution Module, Function is the Function in the Module which is finally responsible for the Function, Date is the current Date;
the table of the key secret _ key comprises a user table user _ table; when the service side verifies that the api _ token is valid, whether the interface is in the valid period or not is detected, if not, the interface expiration timestamp is updated and a secret _ key is generated again, the secret _ key is updated to the user _ table, the new secret _ key is sent to the client side, and the client side sends a request again according to the new secret _ key.
4. The system of claim 3, wherein when the request is initiated, the client sends the client id and the api _ token in the interface to the server, and after receiving the request, the server decrypts the security _ code with the secret _ key corresponding to the client _ id in the database table, then generates a security _ code _ s with a preset rule, and then determines whether the security _ code is equal to the security _ code _ s, and if so, the security _ code is not tampered in the interface request process, otherwise, the client directly returns an error.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811438219.4A CN109547445B (en) | 2018-11-27 | 2018-11-27 | Method and system for verifying legality of network request of client |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811438219.4A CN109547445B (en) | 2018-11-27 | 2018-11-27 | Method and system for verifying legality of network request of client |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109547445A CN109547445A (en) | 2019-03-29 |
| CN109547445B true CN109547445B (en) | 2021-05-14 |
Family
ID=65850955
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811438219.4A Active CN109547445B (en) | 2018-11-27 | 2018-11-27 | Method and system for verifying legality of network request of client |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109547445B (en) |
Families Citing this family (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110891065A (en) * | 2019-12-03 | 2020-03-17 | 西安博达软件股份有限公司 | Token-based user identity auxiliary encryption method |
| CN111212066B (en) * | 2019-12-31 | 2022-04-01 | 浙江工业大学 | Dynamic allocation request verification method |
| CN111325879A (en) * | 2020-01-21 | 2020-06-23 | 上海钧正网络科技有限公司 | Vehicle remote control method and device, storage medium and equipment |
| CN111640248A (en) * | 2020-04-07 | 2020-09-08 | 北京聚利科技有限公司 | Refueling processing method, device, equipment, storage medium and system |
| CN111935164B (en) * | 2020-08-14 | 2022-11-08 | 天元大数据信用管理有限公司 | Https interface request method |
| CN112104646B (en) * | 2020-09-14 | 2022-07-19 | 福建天晴在线互动科技有限公司 | Method and system for safety transmission of app data interface |
| CN112434339A (en) * | 2020-12-01 | 2021-03-02 | 北京五八信息技术有限公司 | Information processing method and device |
| CN113271306B (en) * | 2021-05-18 | 2023-03-24 | 上海星融汽车科技有限公司 | Data request and transmission method, device and system |
| CN113225351B (en) * | 2021-05-28 | 2022-12-13 | 中国建设银行股份有限公司 | Request processing method and device, storage medium and electronic equipment |
| CN114124440B (en) * | 2021-09-29 | 2023-09-26 | 平安养老保险股份有限公司 | Secure transmission method, apparatus, computer device and storage medium |
| CN114915495B (en) * | 2022-07-05 | 2022-11-01 | 浙江华东工程数字技术有限公司 | Message encryption and decryption method supporting multi-algorithm switching |
| CN116015955B (en) * | 2023-01-04 | 2023-12-01 | 三峡高科信息技术有限责任公司 | Configurable method for verifying validity security of uploading file in application system |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7539310B2 (en) * | 2000-06-15 | 2009-05-26 | Microsoft Corporation | Encryption key updating for multiple site automated login |
| CN101997880A (en) * | 2010-12-01 | 2011-03-30 | 湖南智源信息网络技术开发有限公司 | Method and device for verifying security of network page or interface |
| CN104821937A (en) * | 2015-03-26 | 2015-08-05 | 腾讯科技（北京）有限公司 | Token acquisition method, device and system |
| CN105577680A (en) * | 2016-01-18 | 2016-05-11 | 青岛海尔智能家电科技有限公司 | Key generation method, encrypted data analyzing method, devices and key managing center |
| CN106533659A (en) * | 2015-09-14 | 2017-03-22 | 北京中质信维科技有限公司 | Secret key updating method and system |
| CN107612889A (en) * | 2017-08-23 | 2018-01-19 | 四川长虹电器股份有限公司 | The method for preventing user profile from revealing |
-
2018
- 2018-11-27 CN CN201811438219.4A patent/CN109547445B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7539310B2 (en) * | 2000-06-15 | 2009-05-26 | Microsoft Corporation | Encryption key updating for multiple site automated login |
| CN101997880A (en) * | 2010-12-01 | 2011-03-30 | 湖南智源信息网络技术开发有限公司 | Method and device for verifying security of network page or interface |
| CN104821937A (en) * | 2015-03-26 | 2015-08-05 | 腾讯科技（北京）有限公司 | Token acquisition method, device and system |
| CN106533659A (en) * | 2015-09-14 | 2017-03-22 | 北京中质信维科技有限公司 | Secret key updating method and system |
| CN105577680A (en) * | 2016-01-18 | 2016-05-11 | 青岛海尔智能家电科技有限公司 | Key generation method, encrypted data analyzing method, devices and key managing center |
| CN107612889A (en) * | 2017-08-23 | 2018-01-19 | 四川长虹电器股份有限公司 | The method for preventing user profile from revealing |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109547445A (en) | 2019-03-29 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109547445B (en) | Method and system for verifying legality of network request of client | |
| US10848492B2 (en) | Certificate system for verifying authorized and unauthorized secure sessions | |
| US10361852B2 (en) | Secure verification system | |
| KR100925329B1 (en) | Method and apparatus of mutual authentication and key distribution for downloadable conditional access system in digital cable broadcasting network | |
| US7689828B2 (en) | System and method for implementing digital signature using one time private keys | |
| CN103051453B (en) | A kind of mobile terminal network affaris safety trade system based on digital certificate and method | |
| US20200320178A1 (en) | Digital rights management authorization token pairing | |
| US10432595B2 (en) | Secure session creation system utililizing multiple keys | |
| CN106452764B (en) | Method for automatically updating identification private key and password system | |
| US20110138177A1 (en) | Online public key infrastructure (pki) system | |
| US10374808B2 (en) | Verification system for creating a secure link | |
| CN102438013A (en) | Hardware-based credential distribution | |
| CN111884811B (en) | Block chain-based data evidence storing method and data evidence storing platform | |
| US20190140834A1 (en) | Advanced Crypto Token Authentication | |
| CN104574176A (en) | USBKEY-based secure online tax declaration method | |
| JP5992535B2 (en) | Apparatus and method for performing wireless ID provisioning | |
| WO2021019248A1 (en) | Secure media delivery | |
| CN114697040B (en) | Electronic signature method and system based on symmetric key | |
| CN113051540B (en) | Application program interface safety grading treatment method | |
| CN113472790A (en) | Information transmission method based on HTTPS (hypertext transfer protocol secure protocol), client and server | |
| US11570008B2 (en) | Pseudonym credential configuration method and apparatus | |
| KR101749449B1 (en) | Two Level Privacy Preserving Pseudonymous Authentication Method for Vehicular Ad-Hoc Network and System Therefor | |
| CN116318637A (en) | Method and system for secure network access communication of equipment | |
| US20170118198A1 (en) | Identity verification | |
| CN110225011B (en) | Authentication method and device for user node and computer readable storage medium |
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 |