CN114205170B - Bridging port platform networking communication and service encryption calling method - Google Patents
Bridging port platform networking communication and service encryption calling method Download PDFInfo
- Publication number
- CN114205170B CN114205170B CN202111571803.9A CN202111571803A CN114205170B CN 114205170 B CN114205170 B CN 114205170B CN 202111571803 A CN202111571803 A CN 202111571803A CN 114205170 B CN114205170 B CN 114205170B
- Authority
- CN
- China
- Prior art keywords
- platform
- data
- shared
- information
- service
- 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 28
- 238000004891 communication Methods 0.000 title claims abstract description 18
- 230000006855 networking Effects 0.000 title claims abstract description 18
- 238000013475 authorization Methods 0.000 claims abstract description 20
- 230000004044 response Effects 0.000 claims abstract description 15
- 230000008569 process Effects 0.000 claims abstract description 4
- 230000003993 interaction Effects 0.000 claims description 5
- 238000012795 verification Methods 0.000 claims description 4
- 238000012550 audit Methods 0.000 claims description 3
- 238000004806 packaging method and process Methods 0.000 claims 1
- 238000003032 molecular docking Methods 0.000 abstract description 8
- 230000005540 biological transmission Effects 0.000 description 4
- 210000001503 joint Anatomy 0.000 description 4
- 238000010276 construction Methods 0.000 description 3
- 238000007726 management method Methods 0.000 description 3
- 238000007792 addition Methods 0.000 description 2
- 238000010586 diagram Methods 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000002688 persistence Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 230000000739 chaotic effect Effects 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- 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/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Telephonic Communication Services (AREA)
- Storage Device Security (AREA)
Abstract
A bridging port platform networking communication and service encryption calling method comprises the following steps: the method comprises the steps that a first platform (p 1) receives a connection application of a second platform (p 2), wherein the connection application comprises information of the second platform; the first platform (p 1) generates authentication request information (authMsg) based on the information of the second platform, then sends the authentication request information (authMsg) to the second platform (p 2), and the second platform generates authentication response information (respAuthmsg) according to the authentication request information (authMsg) and then sends the authentication response information (respAuthmsg) to the first platform (p 1); both the first platform and the second platform acquire a shared key by using authentication request information (authMsg) and authentication response information (respAuthmsg); after the first platform (p 1) acquires the connection information, connection with the second platform (p 2) is initiated, and a networking connection state is achieved. The invention can effectively process the cross-platform safe docking interface service, realize data encryption sharing and quickly realize encryption authorization and call of the interface service.
Description
Technical Field
The invention relates to the technical field of data communication, in particular to a cross-port platform networking communication and service encryption calling method.
Background
In recent years, many enterprises have reconfigured business applications of companies with the idea of micro-services, and saas software for a wide variety of business functions has been developed. The problem is followed that the interface call between saas software in the enterprise becomes chaotic, the service authority and the call cannot be uniformly managed, the service docking is relatively complex, and the docking cost is high. So the interface service management is started to be referred to by more and more people, more and more enterprises start to build an interface service management platform inside the enterprise by integrating the actual business application of the enterprises based on the data center, and the butt joint between the interface service platforms is troublesome. On the other hand, today, where networks are rapidly developed, information security of data is also being paid more attention to, and interface service interfacing and encrypted transmission of data of call procedures are of great importance.
The existing interface platform is single, unidirectional and other interface platforms for manual butt joint, and the butt joint data transmission process is also to encrypt and transmit by using plaintext or personnel self-defined unsafe passwords. The unified management of interface services is realized inside the existing enterprises, but the service docking of the cross-port platform among enterprises is performed in a more traditional mode of manually docking API documents, so that the quick and batch docking of the interface services cannot be realized. The data security problem of the service docking mode also has great hidden trouble, the data is easily intercepted and decrypted by people when the service is called, and the information security is not ensured.
Disclosure of Invention
In order to solve the problem of the data interaction and butt joint of the cross-over port platform, the invention provides a cross-over port platform networking communication and service encryption calling mode.
The invention provides a bridging port platform networking communication and service encryption calling method, which comprises the following steps:
the method comprises the steps that a first platform receives a connection application of a second platform, wherein the connection application comprises information of the second platform;
the first platform generates authentication request information based on the information of the second platform, sends the authentication request information to the second platform, generates authentication response information according to the authentication request information, and sends the authentication response information to the first platform;
the first platform and the second platform acquire a shared key by using authentication request information and authentication response information so as to decrypt the shared information based on the shared key; after the first platform acquires the connection application information, connection with the second platform is initiated, so that a networking connection state is achieved.
In the invention, the service platform forms a trust network node by applying for approval, the platforms generate a shared key by negotiation of encrypted communication, and the shared key is used for carrying out encrypted transmission on interface authorization data, call data and return data. The invention can effectively process the cross-platform safe docking interface service, realize data encryption sharing and quickly realize encryption authorization and call of the interface service.
Drawings
Fig. 1 is a communication networking and service invocation flow diagram.
Fig. 2 is a communication networking and service invocation process diagram.
Detailed Description
The basic processing flow of the invention is as follows:
as shown in fig. 1, a receiving node is first set on each platform as a first interface url1 for connection application through http protocol, and another receiving node is set as a second interface url2 for connection approval result, where the interfaces can use oauth2 security authentication, ip whitelist and other restrictions to prevent malicious call. The platforms are connected through applying for a connection request, and the other side checks and passes through a mechanism to conduct node connection, wherein each service platform can be regarded as a node, and each node has a unique node identification node_id which is equivalent to a public key of the node. The nodes are applied for connection through an http protocol, and share keys are negotiated and generated in an encrypted communication mode, so that a p2p communication mode based on websocket is realized, each node can be a server or a client, namely, each node can provide service or call service. After the platforms are successfully connected, the interface service of the platform is subjected to data encryption authorization to the connecting node. The authorization information for the service may be stored in a database, such as a mysql database for data persistence and redis for caching of the authorization information. And (3) performing AES encryption on the data by utilizing a websocket message pushing form, and sending the data, wherein the opposite platform can decrypt the encrypted authorization data by using the shared key to obtain interface service information. After successful service authorization, the opposite side platform calls the interface service by adopting an AES encryption transmission method based on the data request mode of the http protocol, the data is returned to the calling side by adopting the AES encryption method, and then the data is decrypted by using the shared key solution.
The following describes specific embodiments of the present invention in detail.
A bridging port platform networking communication and service encryption calling method comprises the following steps: as shown in figures 1-2 of the drawings,
s1, the first platform p1 receives a connection application of the second platform p2 through a node connection application interface, receives a public key p2_node_id1 of the second platform p2, and stores the public key p2_node_id1 to the rear end of the first platform p1.
S2, the first platform generates a random first public key p1_ puk, a random private key p1_prk and a random number p1_nonce, a shared private key token is generated by using the private key p1_node_key of the first platform and the public key p2_node_id of the second platform, then the random number p1_nonce and the shared private key token are subjected to exclusive or to obtain to-be-signed information unsigned, then the random private key p1_prk of the first platform is used for signing the to-be-signed information unsigned to obtain signature information, and the first platform packages the random number p1_nonce, the signature information sign, the public key p1_node_id of the first platform and the interface information p1_url2 of the second platform for receiving the verification result into authentication request information authMsg.
S3, the first platform p1 requests the node connection application interface p2_url1 of the second platform to receive authentication request information authMsg through a network channel of an http protocol, and accordingly the authentication request information authMsg is sent to the second platform p2.
S4, after receiving the authentication request information authMsg, the second platform p2 server writes the data of the authentication request information authMsg into a database mysql thereof, and the user performs auditing at the front end of the second platform. If the user refuses the connection request, the data interaction between the first platform and the second platform is not performed. The database may be, for example, of the mysql type, the first platform and the second platform may each have a corresponding database, or a shared database for storing interaction data.
S5, if the user agrees to the connection request, the data of authentication request information authMsg are taken out from the database mysql, the second platform p2 generates a corresponding shared private key token by using the private key p2_node_key of the second platform and the public key p1_node_id of the first platform p1, the shared private key token of the two parties is the same according to the encryption technology of the ECDH algorithm, and the random number p1_nonce of the first platform and the shared private key token are used for exclusive OR to obtain to-be-signed information unsigned, and the random public key p1_ puk of the first platform p1 can be derived by using the to-be-signed information unsigned and the signature information signature. The second platform p2 generates a random private key p2_prk and a random number p2_nonce of the second platform, and then encapsulates the random public key p2_ puk and the random number p2_nonce of the second platform, and websocket connection information into authentication response information repauthmsg.
S6, the second platform p2 receives authentication response information repauthmsg through an http request node connection application interface p1_url2 of the first platform. At this time, both the first platform and the second platform can acquire the shared secret key by using the own random private key p_prk and the random public key p_ puk of the other party. After the first platform p1 acquires the websocket connection information, websocket connection with the second platform p2 is initiated, and the first platform p1 and the second platform p2 achieve a p2p networking connection state.
Interface encryption authorization preference scheme:
in fig. 1, S7, after the first platform and the second platform are successfully networked, service authorization is performed on the first platform p1, and a function of node authorization is added. The method comprises the steps of selecting an interface service to be authorized to a second platform p2, obtaining a shared secret key between two platform nodes as a secret key, performing AES encryption on data of the interface service to obtain a first encryption character string enCodeResult1, finally forming first json data, sending the first json data in a websocket message pushing mode, writing the shared data into a database mysql, and storing a combination (p2_node_id+ "_id+service_id) of a second platform node mark p2_node_id and a service mark service_id as a tag key in a rediss cache. The second platform p2 receives the data and then decrypts the data by using the shared key, after the decryption is successful, the decrypted data is stored in the local database mysql, if the decryption fails, the access data is possibly malicious code access, and the write operation is not performed.
S8, after the second platform p2 obtains the shared service data of the first platform p1, the front end of the second platform p2 can call a service interface in the browser.
S9, after the back end of the second platform p2 receives the first platform shared service data request received by the front end, the shared service data is packaged into parameter data param, AES encryption is carried out on the parameter data param by using a shared key to obtain a second encryption character string encodeResult2 when the parameter data param is finally called, second json data is finally formed as parameters, and an interface of the first platform p1 (service_url in each service) is accessed in an http protocol request mode.
S10, after receiving the request information, the first platform p1 uses the shared secret key to carry out AES decryption, if decryption fails, an error instruction is returned to the second platform, and if decryption succeeds, the verification of the interface service authority is carried out. And judging whether the obtained combination (p2_node_id plus "_id plus service_id) of the second platform node mark p2_node_id and the service_id exists in the redis storage or not as a criterion, judging that the second platform has authority to call the interface of the data if the combination exists, then using the shared key as a secret key to carry out AES encryption on the returned data of the interface, returning the data to the back end of the second platform p2, decrypting the data by using the shared key after the back end of the second platform p2 obtains the data, and displaying the data to the front end.
After the back end of the second platform p2 receives the front end request, parameter data encapsulation is performed to form a param, and when the parameter data param is finally called, AES encryption is performed on the parameter data param by using a shared key to obtain a second encryption character string enCodeResult2, and finally second json data (such as: { "p2_node_id": "p2_node_id", "data": enCodeResult2 }) are formed as parameters, and a service_url interface in each service is accessed in an http protocol request mode.
Examples
The processing flow of the invention is as follows:
firstly, each platform is provided with an interface url1 serving as a receiving node to receive a connection application of an http protocol, and then another receiving node is provided with an interface url2 for receiving an approval result, and the interface can use restrictions such as oauth2 security authentication, ip whitelist and the like to prevent malicious call. The platforms are connected through applying for a connection request, and the other side checks a passing mechanism to perform node connection, wherein each service platform can be regarded as a node, and each node has a unique identifier node_id which is equivalent to a public key of the node. The nodes interact through the network through an http protocol and can carry out connection application, a shared secret key is generated through encryption communication negotiation, a p2p communication mode based on websocket is realized, and each node can be used as a server or a client, namely, can provide service or call service. After the platforms are successfully connected, the interface service of the platform is subjected to data encryption authorization to the connecting node. The authorization information of the service is stored in a persistence mode through a mysql database, and the authorization information is cached through redis storage. Through the form of websocket message pushing, data AES is encrypted and sent, and the other party can use a shared key to decrypt and obtain interface service information after receiving encryption authorization data. After successful service authorization, the other party calls the interface service by adopting an http-based data request mode and adopting AES encryption to transmit the interface service, the data is also returned to the calling party by AES encryption, and then the shared key solution is used for decryption. See in detail the accessory figure 1.
For a communication networking construction scheme, see fig. 2:
in step 1, the first platform p1 inputs the public key p2_node_id of the counterpart platform (second platform) p2 to be applied for connection and the node connection application of the second platform p2 at the front end of the browser, and these messages are sent to the back end of the first platform p1 through the connection application receiving interface p1_url1.
In step 2, the first platform p1 emulates an RLPX encryption communication protocol encryption handshake procedure, and is based on the encryption technique of ECDH (a private key, B public key) = ECDH (B private key, a public key) algorithm. The first platform p1 back-end will generate a random public key p1_ puk, a secret key p1_prk pair and a random number p1_nonce. Generating a static shared private key token by using a private key p1_node_key of the user and a public key p2_node_id of the user, performing exclusive or on the random number p1_node and the shared private key token to obtain information unsigned to be signed, and then signing the information unsigned to be signed by using a random private key p1_prk of the first platform p1 to obtain signature information, wherein the first platform p1 can package the random number p1_node, the signature information, the first platform public key p1_node_id and p1_url2 (an interface for receiving an audit result) into authentication request information authMsg.
And 3, the back end of the first platform p1 sends authentication request information authMsg to the back end of the second platform p2 through an http protocol by sending a request to the back end of the second platform p2 through a node connection application interface p2_url1 of the second platform.
And 4, after receiving the information, the second platform p2 server writes the data requested to be applied into the database mysql, and the user performs auditing at the front end. If refused, the data interaction is not carried out downwards.
In step 5, if the data is agreed, the second platform p2 uses its own private key p2_node_key and the received public key p1_node_id of the first platform p1 to generate a corresponding private key token, and according to the encryption technique of the ECDH algorithm, it is known that the private keys token of the first and second platforms are identical, and the random public key p1_ puk of the first platform p1 can be derived by performing exclusive or on the same secret key token by using the random number p1_nonce and the shared private key token. The second platform p2 generates its own random private key p2_prk and random number p2_nonce, and then encapsulates the random public key p2_ puk and random number p2_nonce of the second platform and websocket connection information into authentication response information repauthmsg.
In step 6, the second platform p2 back end sends the authentication response message repauthmsg to the first platform p1 through the node connection application interface p1_url2 of the first platform by an http protocol request. At this time, both parties can acquire the shared secret key by using the own random secret key p_prk and the random public key p_ puk of the other party. After the first platform p1 acquires websocket connection information, websocket connection with the second platform p2 is initiated, and the first platform and the second platform achieve a p2p networking connection state.
Interface encryption authorization construction scheme participation fig. 2
And 7, after the networking of the two platforms is successful, authorizing the service on the first platform p1, and adding the function of node authorization. Selecting an interface service to be authorized to authorize the second platform p2, acquiring a shared secret key between two platform nodes as a secret key, performing AES encryption on data (such as [ { "service_url": "http:// xxxx/xx", "method": "post", "service_id": "service id", "params" [ "param1_key": "param1_name", "param2_key": "param2_name" ]) of the interface service to obtain a first encryption character string encoresult 1, finally forming first json data (such as { "p1_node_id": "p1_node_id", "data": encoresult 1 }), transmitting the shared data in a websocket message push form, and writing the shared data in a mysql database, and writing the shared data in a key cache by using p2_node_id+ "+service_name" +key_name }). And the second platform p2 receives the data, then decrypts the data by using the shared key, successfully stores the data in the local mysql database, and if the data fails, the access request can be malicious code access and does not perform writing operation.
Interface encryption call construction scheme see fig. 2
In step 8, after the shared service data of the first platform p1 is obtained, the front end of the second platform p2 may perform service interface call in the browser.
And 9, after receiving the front-end request, the second platform p2 receives the front-end request, encapsulates the parameter data param, and finally uses the shared key to carry out AES encryption on the parameter data param (such as: { "service_id": "service_id", "params": [ "Param1_value": "Param2_key": "Param2_value" ] }) as a parameter when calling, so as to obtain a second encrypted encodeResult2 character string, and finally forms json data (such as: { "p2_node_id": "p2_node_id", "data": "encodeResult 2 }) as a parameter, and carries out service_url interface access in the first platform p1 (each service) in an http request mode.
In step 10, after receiving the request information, the first platform p1 uses the shared key to perform AES decryption, returns an error instruction after the decryption failure, and performs verification of the interface service authority after the decryption success. Judging whether the obtained p2_node_id+ "_id+service_id exists in the redis storage, if so, judging that the obtained p2_node_id has authority, then calling the interface of the data, carrying out AES encryption on the returned data of the interface by using the shared secret key as a secret key, returning the encrypted data to the rear end of the second platform p2, decrypting the data obtained by the rear end of the second platform p2 by using the shared secret key, and displaying the decrypted data to the front end of the second platform.
After the back end of the second platform p2 receives the front end request, parameter data param is encapsulated, when the shared secret key is finally called, the parameter data param (such as { "service_id": "service_id", "params" [ "Param1_key": "Param1_value", "Param2_key": "Param2_value" ] }) is used as a parameter, AES encryption is performed to obtain a second encryption character string enCodeResult2, and finally second json data (such as { "p2_node_id": "p2_node_id", "data": "enCodeResult 2 }) is formed, and an interface of the first platform p1 (service_url in each service) is accessed in an http request mode.
The foregoing is merely a preferred embodiment of the present invention, and it should be noted that modifications and additions may be made to those skilled in the art without departing from the method of the present invention, which modifications and additions are also to be considered as within the scope of the present invention.
Claims (7)
1. A method for calling cross-port platform networking communication and service encryption is characterized by comprising the following steps:
the first platform p1 receives a connection application of the second platform p2, wherein the connection application comprises information of the second platform;
the first platform p1 generates authentication request information authMsg based on the information of the second platform, then sends the authentication request information authMsg to the second platform p2, and the second platform generates authentication response information respAuthmsg according to the authentication request information authMsg and then sends the authentication response information respAuthmsg to the first platform p1;
both the first platform and the second platform acquire a shared key by using authentication request information authMsg and authentication response information repauthMsg so as to decrypt shared information based on the shared key; after the first platform p1 acquires the connection application information, connection with the second platform p2 is initiated, so that a networking connection state is achieved;
after the first platform and the second platform are successfully networked, the first platform performs service authorization, and interface service requiring authorization is authorized to the second platform;
the first platform acquires a shared secret key, encrypts data of interface service to obtain a first encrypted character string enCodeResult1, finally forms first json data, sends the first encrypted character string enCodeResult1 in a message pushing mode, writes the shared data into a database mysql, and stores a combination p2_node_id+ "+ service_id of a second platform node mark p2_node_id and a service mark service_id in a redis cache as a tag key; the second platform p2 decrypts the shared data by using the shared key after receiving the shared data, stores the decrypted data, and does not store if the decryption fails;
after the second platform p2 obtains the shared service data of the first platform p1, the front end of the second platform p2 can call a service interface in the browser;
after the second platform p2 receives the first platform shared service data request, packaging the shared service data into parameter data param, encrypting the parameter data param by using a shared key to obtain a second encryption character string enCodeResult2 when the parameter data param is called, and finally forming second json data as parameters to access an interface of the first platform p1 in a request mode;
after receiving the request information, the first platform p1 uses the shared secret key to decrypt, if the decryption fails, an error instruction is returned to the second platform, and if the decryption succeeds, the verification of the interface service authority is carried out; judging whether the obtained combination p2_node_id of the second platform node mark p2_node_id and the service mark service_id exist in a redis cache or not as a criterion, judging that the second platform node mark p2_node_id has authority to call an interface of data if the combination p2_node_id is in the redis cache, encrypting the returned data of the interface by using a shared key as a secret key, returning the data to the second platform p2, and decrypting and displaying the data by using the shared key after the second platform p2 obtains the data;
after the rear end of the second platform p2 receives the front end request, parameter data param is packaged, and finally, the parameter data param is encrypted by using a shared key to obtain a second encryption character string enCodeResult2 when the second platform p2 is called, and finally, second json data serving as parameters is formed to access the first platform p1 interface.
2. The method of claim 1, wherein authenticating the request information authMsg comprises: a random number p1_nonce, signature information signature, a public key p1_node_id of the first platform, and an interface p1_url2 for receiving an audit result by the second platform.
3. The method of claim 2 wherein the first platform generates a random public key p1_ puk, a random private key p1_prk and a random number p1_nonce, generates a shared private key token using the private key p1_node_key of the first platform and the public key p2_node_id of the second platform, generates a to-be-signed message unsigned based on the random number p1_nonce and the shared private key token, and then signs the to-be-signed message unsigned using the random private key p1_prk of the first platform to obtain the signature message.
4. A method according to claim 1, characterized in that the second platform p2, upon receipt of the authentication request information authMsg, writes the data of said authentication request information authMsg into the database mysql.
5. The method of claim 4, wherein the user performs an audit at the front end of the second platform, and if the user refuses the connection request, no data interaction is performed between the first platform and the second platform; if the user agrees to the connection request, continuing the authentication process.
6. The method according to claim 5, wherein the second platform reads the data of the authentication request information authMsg, generates a corresponding shared private key token by using the private key p2_node_key of the second platform and the received public key p1_node_id of the first platform p1, the shared private key token of both sides being identical, obtains an unsigned information based on the random number p1_nonce of the first platform and the shared private key token, and derives the random public key p1_ puk of the first platform p1 by using the unsigned information unsigned and the signature information signature; the second platform p2 generates a random private key p2_prk and a random number p2_nonce of the second platform, and then encapsulates a random public key p2_ puk and a random number p2_nonce of the second platform, and connection information into authentication response information repauthmsg.
7. The method of claim 6 wherein the second platform p2 requests the first platform connection application interface p1_url2 to receive authentication response information repauthmsg, and both the first platform and the second platform acquire the shared key with their own random private key and the other party's random public key; after the first platform p1 acquires the connection information, connection with the second platform p2 is initiated, and a p2p networking connection state is achieved.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111571803.9A CN114205170B (en) | 2021-12-21 | 2021-12-21 | Bridging port platform networking communication and service encryption calling method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202111571803.9A CN114205170B (en) | 2021-12-21 | 2021-12-21 | Bridging port platform networking communication and service encryption calling method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114205170A CN114205170A (en) | 2022-03-18 |
| CN114205170B true CN114205170B (en) | 2023-11-17 |
Family
ID=80655742
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202111571803.9A Active CN114205170B (en) | 2021-12-21 | 2021-12-21 | Bridging port platform networking communication and service encryption calling method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114205170B (en) |
Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105307108A (en) * | 2015-11-17 | 2016-02-03 | 成都工百利自动化设备有限公司 | Internet of things information interactive communication method and system |
| CN105873031A (en) * | 2016-04-08 | 2016-08-17 | 西安电子科技大学 | Distributed UAV authentication and key agreement method based on trusted platform |
| WO2018109010A1 (en) * | 2016-12-15 | 2018-06-21 | Luxembourg Institute Of Science And Technology (List) | P2p network data distribution and retrieval using blockchain log |
| CN108616540A (en) * | 2018-05-09 | 2018-10-02 | 聚龙股份有限公司 | A kind of platform authentication method and system filtering certification with statement formula based on cross-platform Encryption Algorithm |
| CN110099031A (en) * | 2018-01-30 | 2019-08-06 | 普天信息技术有限公司 | A kind of service calling method, device and micro services platform |
| CN110708170A (en) * | 2019-12-13 | 2020-01-17 | 腾讯科技（深圳）有限公司 | Data processing method and device and computer readable storage medium |
| CN111953491A (en) * | 2020-09-01 | 2020-11-17 | 杭州视洞科技有限公司 | SSHCertite and LDAP based two-step authentication auditing system |
| CN112073188A (en) * | 2020-08-31 | 2020-12-11 | 北京市商汤科技开发有限公司 | Authentication method, device, equipment and computer readable storage medium |
| CN112583802A (en) * | 2020-12-03 | 2021-03-30 | 重庆新致金服信息技术有限公司 | Data sharing platform system and equipment based on block chain and data sharing method |
| CN112581126A (en) * | 2020-12-08 | 2021-03-30 | 腾讯科技（深圳）有限公司 | Block chain-based platform data management method and device and storage medium |
| CN113422686A (en) * | 2021-06-24 | 2021-09-21 | 平安国际智慧城市科技股份有限公司 | Gateway layer authentication method, system, electronic device and storage medium |
| CN113497827A (en) * | 2021-04-26 | 2021-10-12 | 深圳力维智联技术有限公司 | Information sharing method and device |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11032076B2 (en) * | 2019-06-12 | 2021-06-08 | Visa International Service Association | System and method for testing authentication and reviewing implementation processes of an application programming interface in a software development platform |
-
2021
- 2021-12-21 CN CN202111571803.9A patent/CN114205170B/en active Active
Patent Citations (12)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105307108A (en) * | 2015-11-17 | 2016-02-03 | 成都工百利自动化设备有限公司 | Internet of things information interactive communication method and system |
| CN105873031A (en) * | 2016-04-08 | 2016-08-17 | 西安电子科技大学 | Distributed UAV authentication and key agreement method based on trusted platform |
| WO2018109010A1 (en) * | 2016-12-15 | 2018-06-21 | Luxembourg Institute Of Science And Technology (List) | P2p network data distribution and retrieval using blockchain log |
| CN110099031A (en) * | 2018-01-30 | 2019-08-06 | 普天信息技术有限公司 | A kind of service calling method, device and micro services platform |
| CN108616540A (en) * | 2018-05-09 | 2018-10-02 | 聚龙股份有限公司 | A kind of platform authentication method and system filtering certification with statement formula based on cross-platform Encryption Algorithm |
| CN110708170A (en) * | 2019-12-13 | 2020-01-17 | 腾讯科技（深圳）有限公司 | Data processing method and device and computer readable storage medium |
| CN112073188A (en) * | 2020-08-31 | 2020-12-11 | 北京市商汤科技开发有限公司 | Authentication method, device, equipment and computer readable storage medium |
| CN111953491A (en) * | 2020-09-01 | 2020-11-17 | 杭州视洞科技有限公司 | SSHCertite and LDAP based two-step authentication auditing system |
| CN112583802A (en) * | 2020-12-03 | 2021-03-30 | 重庆新致金服信息技术有限公司 | Data sharing platform system and equipment based on block chain and data sharing method |
| CN112581126A (en) * | 2020-12-08 | 2021-03-30 | 腾讯科技（深圳）有限公司 | Block chain-based platform data management method and device and storage medium |
| CN113497827A (en) * | 2021-04-26 | 2021-10-12 | 深圳力维智联技术有限公司 | Information sharing method and device |
| CN113422686A (en) * | 2021-06-24 | 2021-09-21 | 平安国际智慧城市科技股份有限公司 | Gateway layer authentication method, system, electronic device and storage medium |
Non-Patent Citations (1)
| Title |
|---|
| 校园网与互联网交互云平台的研究与实现;李智超;袁胜忠;;信息系统工程(第07期);第13-15页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114205170A (en) | 2022-03-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN105721502B (en) | A kind of authorization access method for browser client and server | |
| US8499156B2 (en) | Method for implementing encryption and transmission of information and system thereof | |
| CN113612605A (en) | Method, system and equipment for enhancing MQTT protocol identity authentication by using symmetric cryptographic technology | |
| CN111756529B (en) | Quantum session key distribution method and system | |
| CN101247407B (en) | Network authentication service system and method | |
| US20010023482A1 (en) | Security protocol | |
| KR19990072733A (en) | Method and Apparatus for Conducting Crypto-Ignition Processes between Thin Client Devices and Server Devices over Data Network | |
| EP2767029B1 (en) | Secure communication | |
| CN1977559B (en) | Method and system for protecting information exchanged during communication between users | |
| CN103906052B (en) | A kind of mobile terminal authentication method, Operational Visit method and apparatus | |
| CA2661922A1 (en) | Method and system for providing authentication service for internet users | |
| WO2010078755A1 (en) | Method and system for transmitting electronic mail, wlan authentication and privacy infrastructure (wapi) terminal thereof | |
| CA2321407C (en) | Security mechanisms and architecture for collaborative systems using tuple space | |
| EP2984782A1 (en) | Method and system for accessing device by a user | |
| CN113918971B (en) | Block chain-based message transmission method, device, equipment and readable storage medium | |
| CN111756528B (en) | A quantum session key distribution method, device and communication architecture | |
| CN116132025A (en) | Key negotiation method, device and communication system based on preset key group | |
| JP2001251297A (en) | Information processor, and cipher communication system and method provided with the processor | |
| CN116800499A (en) | Encrypted data transmission methods and devices, equipment and storage media | |
| JPH10242957A (en) | User authentication method, system therefor and storage medium for user authentication | |
| CN107104888B (en) | A Secure Instant Messaging Method | |
| CN114205170B (en) | Bridging port platform networking communication and service encryption calling method | |
| CN113676468B (en) | Three-party enhanced authentication system design method based on message verification technology | |
| CN112035820B (en) | Data analysis method used in Kerberos encryption environment | |
| CN118264422A (en) | Multi-factor identity authentication method, device and system for mail system |
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 |