CN116112172B - Android client gRPC interface security verification method and device - Google Patents
Android client gRPC interface security verification method and device Download PDFInfo
- Publication number
- CN116112172B CN116112172B CN202211396684.2A CN202211396684A CN116112172B CN 116112172 B CN116112172 B CN 116112172B CN 202211396684 A CN202211396684 A CN 202211396684A CN 116112172 B CN116112172 B CN 116112172B
- Authority
- CN
- China
- Prior art keywords
- key
- signature
- client
- application
- encryption
- 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
Classifications
-
- 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/3247—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 digital signatures
-
- 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/08—Network architectures or network communication protocols for network security for authentication of entities
-
- 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
Abstract
The application discloses a method and a device for security verification of an Android client gRPC interface, wherein the method generates a second signature according to application information, request parameters, preset parameters and a first key by acquiring the request parameters and bound application information of a service call request, wherein the first key is maintained in advance by a service calling party; if the second signature is consistent with the first signature carried in the service call request, response data are acquired according to the request parameters; generating an encryption key according to the application information, the preset parameters and the first key, and encrypting the response data by using the encryption key to obtain an encrypted ciphertext; and returning the encrypted ciphertext so that the client decrypts the encrypted ciphertext. The application solves the technical problem that the trust and the safe transmission of the client and the server are difficult to be ensured in the related technology, realizes the mutual trust between the client and the server, and simultaneously ensures that the data transmission is safer and more reliable.
Description
Technical Field
The application belongs to the technical field of computers, and particularly relates to a method and a device for security verification of an Android client gRPC interface.
Background
In gRPC, the client application can directly call the method of the server application on another different machine like the local object, so that the distributed application and service can be created more easily. gRPC messages are serialized by using Protobuf (a high-efficiency binary message format), the Protobuf can be serialized very quickly on a server and a client, and the payload generated by serialization is small, so that the gRPC messages are important in bandwidth-limited schemes such as mobile application and the like.
In the related art, when a client application calls a server application, trust and secure transmission between the client and the server cannot be effectively solved.
Aiming at the technical problem that the trust and the safe transmission of a client and a server are difficult to be ensured in the related technology, no effective solution is proposed at present.
Disclosure of Invention
Therefore, an embodiment of the application provides a method, a device, electronic equipment and a storage medium for security verification of an Android client gRPC interface, which aim to solve at least one problem existing in the prior art.
In order to achieve the above object, in a first aspect, the present application provides a method for security check of an Android client gRPC interface, including:
acquiring request parameters of a service call request and bound application information, and generating a second signature according to the application information, the request parameters, preset parameters and a first key, wherein the first key is maintained in advance by a service caller;
if the second signature is consistent with the first signature carried in the service call request, response data are acquired according to the request parameters;
generating an encryption key according to the application information, the preset parameters and the first key, and encrypting the response data by using the encryption key to obtain an encrypted ciphertext;
and returning the encrypted ciphertext so that the client decrypts the encrypted ciphertext.
In one embodiment, the application information includes an address of the application and a certificate fingerprint; the preset parameters comprise the current time and a random character string; and splicing the request parameters, the address of the application program, the certificate fingerprint, the first key, the preset second key, the current time and the random character string to generate the second signature.
In one embodiment, the first signature is pre-generated by a service caller, and the method for generating the first signature is the same as the method for generating the second signature.
In one embodiment, the address of the application, the certificate fingerprint, the current time, the random string, the first key, and the second key are input into a key generation algorithm to obtain the encryption key.
In one embodiment, the encryption key and the response data are input into a symmetric encryption algorithm for encryption to obtain the encrypted ciphertext.
In one embodiment, the client decrypting the encrypted ciphertext includes: and acquiring the request parameters and the application information, inputting the address, the certificate fingerprint, the current time, the random character string, the first key and the second key of the application program into a key generation algorithm to generate a decryption key, and inputting the decryption key and the encrypted ciphertext into a symmetric decryption algorithm to decrypt to obtain the response data.
In a second aspect, the present application further provides a device for security verification of an Android client gRPC interface, including:
the extraction module is used for acquiring the request parameters of the service call request and the bound application information, and generating a second signature according to the application information, the request parameters, the preset parameters and a first key, wherein the first key is maintained in advance by a service calling party;
the verification module is used for acquiring response data according to the request parameters if the second signature is consistent with the first signature carried in the service call request;
the encryption module is used for generating an encryption key according to the application information, the preset parameters and the first key, and encrypting the response data by using the encryption key to obtain an encrypted ciphertext;
and the response module is used for returning the encrypted ciphertext so that the client decrypts the encrypted ciphertext.
In one embodiment, the application information includes an address of the application and a certificate fingerprint; the preset parameters comprise the current time and a random character string; and splicing the request parameters, the address of the application program, the certificate fingerprint, the first key, the preset second key, the current time and the random character string to generate the second signature.
In a third aspect, the present application further provides an electronic device, including a memory and a processor, where the memory stores a computer program, and when the computer program is executed by the processor, the processor is caused to execute the steps of the method for security checking of the gppc interface of the Android client.
In a fourth aspect, the present application further provides a computer readable storage medium, where a computer program is stored, where the computer program when executed by a processor causes the processor to execute the steps of the method for security checking of the gppc interface of the Android client.
According to the method, the device, the electronic equipment and the storage medium for Android client gRPC interface security verification, the request parameters of the service call request and the bound application information are obtained, and a second signature is generated according to the application information, the request parameters, the preset parameters and the first secret key, wherein the first secret key is maintained in advance by a service calling party; if the second signature is consistent with the first signature carried in the service call request, response data are acquired according to the request parameters; generating an encryption key according to the application information, the preset parameters and the first key, and encrypting the response data by using the encryption key to obtain an encrypted ciphertext; and returning the encrypted ciphertext so that the client decrypts the encrypted ciphertext. The technical problem that the trust and the safe transmission of the client and the server are difficult to be ensured in the related technology is solved, and the following beneficial effects are realized: mutual trust between the client and the server is realized, and meanwhile, data transmission is safer and more reliable.
Drawings
The accompanying drawings, which are included to provide a further understanding of the application, are incorporated in and constitute a part of this specification. The drawings and their description are illustrative of the application and are not to be construed as unduly limiting the application. In the drawings:
fig. 1 is a flow chart of implementation of a method for security check of an Android client gRPC interface provided by an embodiment of the present application;
fig. 2 is a schematic diagram of main modules of an Android client gppc interface security verification apparatus provided by an embodiment of the present application;
FIG. 3 is a diagram of an exemplary system architecture to which embodiments of the present application may be applied;
fig. 4 is a schematic diagram of a computer system suitable for use in implementing an embodiment of the application.
Detailed Description
In order that those skilled in the art will better understand the present application, a technical solution in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings in which it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present application without making any inventive effort, shall fall within the scope of the present application.
It should be noted that the terms "first," "second," and the like in the description and the claims of the present application and the above figures are used for distinguishing between similar objects and not necessarily for describing a particular sequential or chronological order. It is to be understood that the data so used may be interchanged where appropriate in order to describe the embodiments of the application herein. Furthermore, the terms "comprises," "comprising," and "having," and any variations thereof, are intended to cover a non-exclusive inclusion, such that a process, method, system, article, or apparatus that comprises a list of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, article, or apparatus.
In the present application, the terms "upper", "lower", "left", "right", "front", "rear", "top", "bottom", "inner", "outer", "middle", "vertical", "horizontal", "lateral", "longitudinal" and the like indicate an azimuth or a positional relationship based on that shown in the drawings. These terms are only used to better describe the present application and its embodiments and are not intended to limit the scope of the indicated devices, elements or components to the particular orientations or to configure and operate in the particular orientations.
Also, some of the terms described above may be used to indicate other meanings in addition to orientation or positional relationships, for example, the term "upper" may also be used to indicate some sort of attachment or connection in some cases. The specific meaning of these terms in the present application will be understood by those of ordinary skill in the art according to the specific circumstances.
In addition, the term "plurality" shall mean two as well as more than two.
It should be noted that, without conflict, the embodiments of the present application and features of the embodiments may be combined with each other. The application will be described in detail below with reference to the drawings in connection with embodiments.
Fig. 1 shows a flow chart for implementing the method for security check of the gRPC interface of the Android client according to the embodiment of the present application, fig. 2 shows a main processing flow chart of the method for security check of the gRPC interface of the Android client according to the embodiment of the present application, and for convenience of explanation, only the portions related to the embodiment of the present application are shown, and the details are as follows:
a method for security check of an Android client gRPC interface comprises the following steps:
s101: acquiring request parameters of a service call request and bound application information, and generating a second signature according to the application information, the request parameters, preset parameters and a first key, wherein the first key is maintained in advance by a service caller;
s102: if the second signature is consistent with the first signature carried in the service call request, response data are acquired according to the request parameters;
s103: generating an encryption key according to the application information, the preset parameters and the first key, and encrypting the response data by using the encryption key to obtain an encrypted ciphertext;
s104: and returning the encrypted ciphertext so that the client decrypts the encrypted ciphertext.
It should be noted that the application is applied to security check of the gRPC interface of the Android client. In gRPC, the client application can directly call the method of the server application on another different machine like the local object, so that the distributed application and service can be created more easily. gRPC messages are serialized by using Protobuf (a high-efficiency binary message format), the Protobuf can be serialized very quickly on a server and a client, and the payload generated by serialization is small, so that the gRPC messages are important in bandwidth-limited schemes such as mobile application and the like. Server (server) and client (client) trust are also required, and https may be used for server trust of gppc, i.e. signature verification mode. The device solves the problem of trusted and secure transmission at the android client.
In step S101: and acquiring request parameters of the service call request and the bound application information, and generating a second signature according to the application information, the request parameters, preset parameters and a first key, wherein the first key is maintained in advance by a service caller.
In general, a client application invokes a service of a server by initiating a service invocation request, and the server performs a corresponding service return response according to a request parameter in the request. And after receiving the service call request initiated by the client, acquiring request parameters and bound application information in the service call request. Here, in order to ensure the credibility of the client, the information of the application APP is bound to the client in advance, so that the client can identify the corresponding application when initiating the call. And after the request parameter information and the application information are extracted, generating a second signature according to the application information, the request parameter, the preset parameter and the first key, and performing comparison and verification on the credibility of the client according to the generated second signature and the signature of the client which is generated in advance to perform trust on the client.
Here, the preset parameter may be formed based on a preset parameter generation rule, for example, the current time at the time of the preset acquisition request may be the preset parameter, or the preset rule may be a string that generates a preset number of bits based on a random symbol generation algorithm.
Meanwhile, the first key is a key (key) agreed by the client and the server, and can be maintained in advance by the client of the calling party, for example, the key can be a token of the user after the user of the calling party logs in, and the key can be a character string object for temporary session when the user of the calling party does not log in.
Illustratively, the preset parameters include a current time and a random string; and splicing the request parameters, the address of the application program, the certificate fingerprint, the first key, the preset second key, the current time and the random character string to generate the second signature. Therefore, the problem of trust between the client and the server is solved, and signature verification between the client and the server is realized. Here, the second key is a built-in key configured in advance, and is directly acquired at the time of key generation.
The random string may be a UUID (universally unique identification code) to increase randomness. The current time is 0 time zone time.
In one embodiment, the first signature is pre-generated by a service caller, and the method for generating the first signature is the same as the method for generating the second signature.
For example, to facilitate verification of the signature, to enable mutual trust between the client and the server, the client application may pre-generate an application signature, i.e. the first signature. Specifically, the client extracts parameters and bound application information according to request parameters or response result data (gRPC binary data), wherein the application information comprises an address and a certificate fingerprint of an application program; the parameters comprise the current time and a random character string; and splicing the request parameters, the address of the application program, the certificate fingerprint, the first key, the preset second key, the current time and the random character string to generate the first signature. The second key is a built-in key which is configured in advance, is directly acquired during key generation, can be configured by the client, and is transmitted to the server.
In step S102: and if the second signature is consistent with the first signature carried in the service call request, acquiring response data according to the request parameters. Verifying whether the client application is a trusted application and a client through comparison of the second signature and the first signature, and acquiring corresponding response data through verification and request parameters when the second signature is consistent with the first signature; when the second signature and the first signature are inconsistent, the client is not trusted, i.e. the signature verification is not passed, and the request is rejected.
In step S103: and generating an encryption key according to the application information, the preset parameters and the first key, and encrypting the response data by using the encryption key to obtain an encrypted ciphertext. And encrypting the response data after the response data is acquired so as to ensure the safety of data transmission. Specifically, after response data is obtained, an encryption key is generated according to the application information, preset parameters and the first key, and then the response data is encrypted by using the encryption key to obtain an encrypted ciphertext. Here, the preset parameter is a preset parameter in the second signature generation, the first key is also a first key in the second signature generation, and the client, that is, the service caller, maintains the first key. The encryption key may be generated by an existing key generation algorithm, or the ciphertext may be encrypted by an existing encryption/decryption algorithm, for example, the encryption key may be generated by an MD5 algorithm, and the ciphertext may be encrypted by an algorithm such as DES, AES, or 3 DES.
In one embodiment, the address of the application, the certificate fingerprint, the current time, the random string, the first key, and the second key are input into a key generation algorithm to obtain the encryption key. The key generation algorithm may be MD5, RSA algorithm, or the like, and for example, the address of the application program, the certificate fingerprint, the current time, the random string, the first key, and the second key are input into the RSA algorithm to generate the encryption key. Therefore, the generation of the encryption key is efficiently realized, the randomness of the encryption key is realized, and meanwhile, the security of the encryption key is higher, so that the secure transmission of data is ensured. Here, the second key is a preset second key at the time of signature generation.
And further, after generating an encryption key, inputting the encryption key and the response data into a symmetric encryption algorithm to encrypt so as to obtain the encrypted ciphertext. The encryption algorithm may be any one of DES, AES, 3DES, etc., and for example, the response data is input into DES to obtain an encrypted ciphertext.
In step S104: and returning the encrypted ciphertext so that the client decrypts the encrypted ciphertext.
Specifically, the client decrypting the encrypted ciphertext includes: and acquiring the request parameters and the application information, inputting the address, the certificate fingerprint, the current time, the random character string, the first key and the second key of the application program into a key generation algorithm to generate a decryption key, and inputting the decryption key and the encrypted ciphertext into a symmetric decryption algorithm to decrypt to obtain the response data. Here, the key generation algorithm may be selected from MD5, RSA algorithm, etc., for example, the address of the application program, the certificate fingerprint, the current time, the random string, the first key and the second key are input into the RSA algorithm to generate the decryption key; the decryption algorithm may be any one of DES, AES, 3DES, etc., and for example, the response data is obtained by inputting a decryption key and an encrypted ciphertext into the DES algorithm.
In the implementation of the application, the problem of trust of both servers and clients, namely signature verification, can be solved, and the problem of transmission content security, namely data security transmission encryption and decryption flow, wherein the signature and key generation process can bind a plurality of keys applied to the current, and particularly the behavior of the Android terminal is solved: and inputting a key1 maintained by a calling party, namely a certificate fingerprint key2 applied currently, and embedding a key3 into the device to generate a signature string. The encryption and decryption can involve binding of 4 keys, key1 maintained by a calling party, certificate key2 currently applied, key3 built in the device and key0 generated by a contract algorithm are input, and a key used for encryption and decryption is not transmitted through an interface but obtained through an encryption device and a decryption device, so that the security of the key is ensured, the variability of the key is increased, completely different and non-repeated encryption and decryption keys can be used for each request and response, and the key is simple and safe in the data transmission process of a C/S interface. The device is based on C/S realization, can be used for gRPC and can also be used for interface data transmission under Http (S).
According to the Android client gRPC interface security verification method provided by the embodiment of the application, the request parameters of the service call request and the bound application information are obtained, and the second signature is generated according to the application information, the request parameters, the preset parameters and the first key, wherein the first key is maintained in advance by the service calling party; if the second signature is consistent with the first signature carried in the service call request, response data are acquired according to the request parameters; generating an encryption key according to the application information, the preset parameters and the first key, and encrypting the response data by using the encryption key to obtain an encrypted ciphertext; and returning the encrypted ciphertext so that the client decrypts the encrypted ciphertext. The technical problem that the trust and the safe transmission of the client and the server are difficult to be guaranteed in the related technology is solved, the mutual trust between the client and the server is realized, and meanwhile, the data transmission is safer and more reliable.
Fig. 2 is a schematic diagram of main modules of an Android client gRPC interface security verification apparatus according to an embodiment of the present application, and for convenience of explanation, only the relevant parts of the embodiment of the present application are shown, which is described in detail below:
an Android client gRPC interface security check device 200 includes:
the extraction module 201 is configured to obtain a request parameter of a service call request and bound application information, and generate a second signature according to the application information, the request parameter, a preset parameter and a first key, where the first key is maintained in advance by a service caller;
a verification module 202, configured to obtain response data according to the request parameter if the second signature is consistent with the first signature carried in the service call request;
the encryption module 203 is configured to generate an encryption key according to the application information, a preset parameter, and the first key, and encrypt the response data with the encryption key to obtain an encrypted ciphertext;
and the response module 204 is used for returning the encrypted ciphertext so that the client can decrypt the encrypted ciphertext.
For the extracting module 201, the extracting module is configured to obtain a request parameter of a service call request and bound application information, and generate a second signature according to the application information, the request parameter, a preset parameter and a first key, where the first key is maintained in advance by a service caller.
In general, a client application invokes a service of a server by initiating a service invocation request, and the server performs a corresponding service return response according to a request parameter in the request. And after receiving the service call request initiated by the client, acquiring request parameters and bound application information in the service call request. Here, in order to ensure the credibility of the client, the information of the application APP is bound to the client in advance, so that the client can identify the corresponding application when initiating the call. And after the request parameter information and the application information are extracted, generating a second signature according to the application information, the request parameter, the preset parameter and the first key, and performing comparison and verification on the credibility of the client according to the generated second signature and the signature of the client which is generated in advance to perform trust on the client.
Here, the preset parameter may be formed based on a preset parameter generation rule, for example, the current time at the time of the preset acquisition request may be the preset parameter, or the preset rule may be a string that generates a preset number of bits based on a random symbol generation algorithm.
Meanwhile, the first key is a key (key) agreed by the client and the server, and can be maintained in advance by the client of the calling party, for example, the key can be a token of the user after the user of the calling party logs in, and the key can be a character string object for temporary session when the user of the calling party does not log in.
Illustratively, the preset parameters include a current time and a random string; and splicing the request parameters, the address of the application program, the certificate fingerprint, the first key, the preset second key, the current time and the random character string to generate the second signature. Therefore, the problem of trust between the client and the server is solved, and signature verification between the client and the server is realized. Here, the second key is a built-in key configured in advance, and is directly acquired at the time of key generation.
The random string may be a UUID (universally unique identification code) to increase randomness. The current time is 0 time zone time.
In one embodiment, the first signature is pre-generated by a service caller, and the method for generating the first signature is the same as the method for generating the second signature.
For example, to facilitate verification of the signature, to enable mutual trust between the client and the server, the client application may pre-generate an application signature, i.e. the first signature. Specifically, the client extracts parameters and bound application information according to request parameters or response result data (gRPC binary data), wherein the application information comprises an address and a certificate fingerprint of an application program; the parameters comprise the current time and a random character string; and splicing the request parameters, the address of the application program, the certificate fingerprint, the first key, the preset second key, the current time and the random character string to generate the first signature. The second key is a built-in key which is configured in advance, is directly acquired during key generation, can be configured by the client, and is transmitted to the server.
And the verification module 202 is configured to obtain response data according to the request parameter if the second signature is consistent with the first signature carried in the service call request. Verifying whether the client application is a trusted application and a client through comparison of the second signature and the first signature, and acquiring corresponding response data through verification and request parameters when the second signature is consistent with the first signature; when the second signature and the first signature are inconsistent, the client is not trusted, i.e. the signature verification is not passed, and the request is rejected.
And the encryption module 203 is configured to generate an encryption key according to the application information, the preset parameter and the first key, and encrypt the response data with the encryption key to obtain an encrypted ciphertext. And encrypting the response data after the response data is acquired so as to ensure the safety of data transmission. Specifically, after response data is obtained, an encryption key is generated according to the application information, preset parameters and the first key, and then the response data is encrypted by using the encryption key to obtain an encrypted ciphertext. Here, the preset parameter is a preset parameter in the second signature generation, the first key is also a first key in the second signature generation, and the client, that is, the service caller, maintains the first key. The encryption key may be generated by an existing key generation algorithm, or the ciphertext may be encrypted by an existing encryption/decryption algorithm, for example, the encryption key may be generated by an MD5 algorithm, and the ciphertext may be encrypted by an algorithm such as DES, AES, or 3 DES.
In one embodiment, the address of the application, the certificate fingerprint, the current time, the random string, the first key, and the second key are input into a key generation algorithm to obtain the encryption key. The key generation algorithm may be MD5, RSA algorithm, or the like, and for example, the address of the application program, the certificate fingerprint, the current time, the random string, the first key, and the second key are input into the RSA algorithm to generate the encryption key. Therefore, the generation of the encryption key is efficiently realized, the randomness of the encryption key is realized, and meanwhile, the security of the encryption key is higher, so that the secure transmission of data is ensured. Here, the second key is a preset second key at the time of signature generation.
And further, after generating an encryption key, inputting the encryption key and the response data into a symmetric encryption algorithm to encrypt so as to obtain the encrypted ciphertext. The encryption algorithm may be any one of DES, AES, 3DES, etc., and for example, the response data is input into DES to obtain an encrypted ciphertext.
And the response module 204 is configured to return the encrypted ciphertext, so that the client decrypts the encrypted ciphertext.
Specifically, the client decrypting the encrypted ciphertext includes: and acquiring the request parameters and the application information, inputting the address, the certificate fingerprint, the current time, the random character string, the first key and the second key of the application program into a key generation algorithm to generate a decryption key, and inputting the decryption key and the encrypted ciphertext into a symmetric decryption algorithm to decrypt to obtain the response data. Here, the key generation algorithm may be selected from MD5, RSA algorithm, etc., for example, the address of the application program, the certificate fingerprint, the current time, the random string, the first key and the second key are input into the RSA algorithm to generate the decryption key; the decryption algorithm may be any one of DES, AES, 3DES, etc., and for example, the response data is obtained by inputting a decryption key and an encrypted ciphertext into the DES algorithm.
Therefore, the Android client gRPC interface security verification device provided by the embodiment of the application solves the technical problem that the trust and the security transmission of the client and the server are difficult to be ensured in the related technology, realizes the mutual trust between the client and the server, and simultaneously ensures that the data transmission is safer and more reliable.
The embodiment of the application also provides electronic equipment, which comprises: one or more processors; and the storage device is used for storing one or more programs, and when the one or more programs are executed by the one or more processors, the one or more processors realize the method for the security check of the Android client gRPC interface.
The embodiment of the application also provides a computer readable medium, on which a computer program is stored, and when the program is executed by a processor, the method for realizing the security check of the Android client gRPC interface of the embodiment of the application is realized.
Fig. 3 illustrates an exemplary system architecture 300 of a method or apparatus for Android client gRPC interface security verification to which embodiments of the application may be applied.
As shown in fig. 3, the system architecture 300 may include terminal devices 301, 302, 303, a network 304, and a server 305. The network 304 is used as a medium to provide communication links between the terminal devices 301, 302, 303 and the server 305. The network 304 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.
A user may interact with the server 305 via the network 304 using the terminal devices 301, 302, 303 to receive or send messages or the like. Various communication client applications, such as shopping class applications, web browser applications, search class applications, instant messaging tools, mailbox clients, social platform software, etc., may be installed on the terminal devices 301, 302, 303.
The terminal devices 301, 302, 303 may be a variety of electronic devices having a display screen and supporting web browsing, including but not limited to smartphones, tablets, laptop and desktop computers, and the like.
The server 305 may be a server providing various services, such as a background management server providing support for user messages sent to and from the terminal devices 301, 302, 303. The background management server can perform analysis and other processes after receiving the terminal equipment request, and feed back the processing result to the terminal equipment.
It should be noted that, the method for security check of the Android client gRPC interface provided by the embodiment of the present application is generally executed by the terminal device 301, 302, 303 or the server 305, and correspondingly, the device for security check of the Android client gRPC interface is generally set in the terminal device 301, 302, 303 or the server 305.
It should be understood that the number of terminal devices, networks and servers in fig. 3 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.
Referring now to FIG. 4, there is illustrated a schematic diagram of a computer system 400 suitable for use in implementing an electronic device of an embodiment of the present application. The computer system shown in fig. 4 is merely an example, and should not be construed as limiting the functionality and scope of use of embodiments of the present application.
As shown in fig. 4, the computer system 400 includes a Central Processing Unit (CPU) 401, which can perform various appropriate actions and processes according to a program stored in a Read Only Memory (ROM) 402 or a program loaded from a storage section 408 into a Random Access Memory (RAM) 403. In RAM 403, various programs and data required for the operation of system 400 are also stored. The CPU 401, ROM 402, and RAM 403 are connected to each other by a bus 404. An input/output (I/O) interface 405 is also connected to bus 404.
The following components are connected to the I/O interface 405: an input section 406 including a keyboard, a mouse, and the like; an output portion 407 including a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker, and the like; a storage section 408 including a hard disk or the like; and a communication section 409 including a network interface card such as a LAN card, a modem, or the like. The communication section 409 performs communication processing via a network such as the internet. The drive 410 is also connected to the I/O interface 405 as needed. A removable medium 411 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is installed on the drive 410 as needed, so that a computer program read therefrom is installed into the storage section 408 as needed.
In particular, according to embodiments of the present disclosure, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method shown in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network via the communication portion 409 and/or installed from the removable medium 411. The above-described functions defined in the system of the present application are performed when the computer program is executed by a Central Processing Unit (CPU) 401.
The computer readable medium shown in the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present application, however, the computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with the computer-readable program code embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.
The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The modules involved in the embodiments of the present application may be implemented in software or in hardware. The described modules may also be provided in a processor, for example, as: a processor includes a determination module, an extraction module, a training module, and a screening module. Where the names of the modules do not constitute a limitation on the module itself in some cases, the determination module may also be described as "module for determining a candidate set of users", for example.
The foregoing examples illustrate only a few embodiments of the application and are described in detail herein without thereby limiting the scope of the application. It should be noted that it will be apparent to those skilled in the art that several variations and modifications can be made without departing from the spirit of the application, which are all within the scope of the application. Accordingly, the scope of protection of the present application is to be determined by the appended claims.
The above description is only of the preferred embodiments of the present application and is not intended to limit the present application, but various modifications and variations can be made to the present application by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the protection scope of the present application.
Claims (7)
1. The Android client gRPC interface security verification method is characterized by comprising the following steps:
acquiring request parameters of a service call request and bound application information, and generating a second signature according to the application information, the request parameters, preset parameters and a first key, wherein the first key is maintained in advance by a service caller;
if the second signature is consistent with the first signature carried in the service call request, response data are acquired according to the request parameters;
generating an encryption key according to the application information, the preset parameters and the first key, and encrypting the response data by using the encryption key to obtain an encrypted ciphertext;
returning the encrypted ciphertext so that the client decrypts the encrypted ciphertext;
the application information comprises an address of an application program and a certificate fingerprint; the preset parameters comprise the current time and a random character string; splicing the request parameters, the address of the application program, the certificate fingerprint, the first key, the preset second key, the current time and the random character string to generate the second signature;
the client decrypting the encrypted ciphertext includes: acquiring the request parameters and the application information, inputting an address, a certificate fingerprint, the current time, a random character string, a first key and a second key of the application program into a key generation algorithm to generate a decryption key, and inputting the decryption key and the encrypted ciphertext into a symmetric decryption algorithm to decrypt to obtain the response data;
the signature and key generation process binds a plurality of keys of the current application, and specifically acts on the Android side: the key1 maintained by the calling party, the key2 of the certificate of the current application, the key3 built in the device, the signature string is generated, encryption and decryption can involve binding of 4 keys, the key1 maintained by the calling party, the key2 of the certificate of the current application, the key3 built in the device and the key0 generated by the agreed algorithm are input, and the key used for encryption and decryption can not be transmitted through an interface but is obtained through the encryption device and the decryption device.
2. The method for security verification of an Android client gRPC interface according to claim 1, wherein the first signature is pre-generated by a service caller, and the method for generating the first signature is the same as the method for generating the second signature.
3. The method for security verification of the gRPC interface of the Android client according to claim 1, wherein the address, the certificate fingerprint, the current time, the random string, the first key and the second key of the application are input into a key generation algorithm to obtain the encryption key.
4. The method for security verification of the gppc interface of the Android client according to claim 3, wherein the encryption key and the response data are input into a symmetric encryption algorithm to be encrypted to obtain the encrypted ciphertext.
5. The utility model provides an Android customer end gRPC interface safety check-up's device which characterized in that includes:
the extraction module is used for acquiring the request parameters of the service call request and the bound application information, and generating a second signature according to the application information, the request parameters, the preset parameters and a first key, wherein the first key is maintained in advance by a service calling party;
the verification module is used for acquiring response data according to the request parameters if the second signature is consistent with the first signature carried in the service call request;
the encryption module is used for generating an encryption key according to the application information, the preset parameters and the first key, and encrypting the response data by using the encryption key to obtain an encrypted ciphertext;
the response module is used for returning the encrypted ciphertext so that the client decrypts the encrypted ciphertext;
the application information comprises an address of an application program and a certificate fingerprint; the preset parameters comprise the current time and a random character string; splicing the request parameters, the address of the application program, the certificate fingerprint, the first key, the preset second key, the current time and the random character string to generate the second signature;
the client decrypting the encrypted ciphertext includes: acquiring the request parameters and the application information, inputting an address, a certificate fingerprint, the current time, a random character string, a first key and a second key of the application program into a key generation algorithm to generate a decryption key, and inputting the decryption key and the encrypted ciphertext into a symmetric decryption algorithm to decrypt to obtain the response data;
the signature and key generation process binds a plurality of keys of the current application, and specifically acts on the Android side: the key1 maintained by the calling party, the key2 of the certificate of the current application, the key3 built in the device, the signature string is generated, encryption and decryption can involve binding of 4 keys, the key1 maintained by the calling party, the key2 of the certificate of the current application, the key3 built in the device and the key0 generated by the agreed algorithm are input, and the key used for encryption and decryption can not be transmitted through an interface but is obtained through the encryption device and the decryption device.
6. An electronic device comprising a memory and a processor, the memory having stored therein a computer program which, when executed by the processor, causes the processor to perform the steps of the method of Android client gRPC interface security check of any one of claims 1 to 4.
7. A computer readable storage medium, characterized in that the computer readable storage medium has stored thereon a computer program which, when executed by a processor, causes the processor to perform the steps of the method of Android client gRPC interface security verification according to any one of claims 1 to 4.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211396684.2A CN116112172B (en) | 2022-11-09 | 2022-11-09 | Android client gRPC interface security verification method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211396684.2A CN116112172B (en) | 2022-11-09 | 2022-11-09 | Android client gRPC interface security verification method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116112172A CN116112172A (en) | 2023-05-12 |
| CN116112172B true CN116112172B (en) | 2023-08-22 |
Family
ID=86262677
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211396684.2A Active CN116112172B (en) | 2022-11-09 | 2022-11-09 | Android client gRPC interface security verification method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116112172B (en) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018000886A1 (en) * | 2016-07-01 | 2018-01-04 | 广州爱九游信息技术有限公司 | Application program communication processing system, apparatus, method, and client terminal, and server terminal |
| CN110868291A (en) * | 2019-11-26 | 2020-03-06 | 普联技术有限公司 | Data encryption transmission method, device, system and storage medium |
| CN111475824A (en) * | 2020-03-23 | 2020-07-31 | 深圳前海百递网络有限公司 | Data access method, device, equipment and storage medium |
| US11057215B1 (en) * | 2021-01-27 | 2021-07-06 | Garantir LLC | Automated hash validation |
| CN113918967A (en) * | 2021-09-24 | 2022-01-11 | 深圳市天威网络工程有限公司 | Data transmission method, system, computer equipment and medium based on security check |
| CN114553416A (en) * | 2022-03-18 | 2022-05-27 | 北京友普信息技术有限公司 | Data encryption processing method for signature verification of application program interface |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103067174B (en) * | 2012-12-27 | 2015-06-17 | 飞天诚信科技股份有限公司 | Digital signature method and system completed in mobile operating system |
-
2022
- 2022-11-09 CN CN202211396684.2A patent/CN116112172B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2018000886A1 (en) * | 2016-07-01 | 2018-01-04 | 广州爱九游信息技术有限公司 | Application program communication processing system, apparatus, method, and client terminal, and server terminal |
| CN110868291A (en) * | 2019-11-26 | 2020-03-06 | 普联技术有限公司 | Data encryption transmission method, device, system and storage medium |
| CN111475824A (en) * | 2020-03-23 | 2020-07-31 | 深圳前海百递网络有限公司 | Data access method, device, equipment and storage medium |
| US11057215B1 (en) * | 2021-01-27 | 2021-07-06 | Garantir LLC | Automated hash validation |
| CN113918967A (en) * | 2021-09-24 | 2022-01-11 | 深圳市天威网络工程有限公司 | Data transmission method, system, computer equipment and medium based on security check |
| CN114553416A (en) * | 2022-03-18 | 2022-05-27 | 北京友普信息技术有限公司 | Data encryption processing method for signature verification of application program interface |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116112172A (en) | 2023-05-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107249004B (en) | Identity authentication method, device and client | |
| US9430211B2 (en) | System and method for sharing information in a private ecosystem | |
| CN107888656B (en) | Calling method and calling device of server-side interface | |
| CN113179323B (en) | HTTPS request processing method, device and system for load balancing equipment | |
| CN109981576B (en) | Key migration method and device | |
| US10230762B2 (en) | System and method for sharing information in a private ecosystem | |
| CN112039826A (en) | Login method and device applied to applet terminal | |
| CN111246407B (en) | Data encryption and decryption method and device for short message transmission | |
| CN112202794A (en) | Transaction data protection method and device, electronic equipment and medium | |
| CN109995534B (en) | Method and device for carrying out security authentication on application program | |
| CN112560003A (en) | User authority management method and device | |
| CN116112172B (en) | Android client gRPC interface security verification method and device | |
| CN111767550A (en) | Data storage method and device | |
| CN112565156B (en) | Information registration method, device and system | |
| CN113626848A (en) | Sample data generation method and device, electronic equipment and computer readable medium | |
| CN110166226B (en) | Method and device for generating secret key | |
| CN112966287A (en) | Method, system, device and computer readable medium for acquiring user data | |
| CN113761566A (en) | Data processing method and device | |
| CN110619236A (en) | File authorization access method, device and system based on file credential information | |
| CN110858243A (en) | Page acquisition method and device for gateway | |
| CN113420331B (en) | Method and device for managing file downloading permission | |
| CN112926076B (en) | Data processing method, device and system | |
| CN113572763B (en) | Data processing method and device, electronic equipment and storage medium | |
| CN110490003B (en) | User trusted data generation method, user trusted data acquisition method, device and system | |
| CN114598549B (en) | Customer SSL certificate verification method and device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |