CN105025470A - Service request processing method, system and related device - Google Patents
Service request processing method, system and related device Download PDFInfo
- Publication number
- CN105025470A CN105025470A CN201410158474.9A CN201410158474A CN105025470A CN 105025470 A CN105025470 A CN 105025470A CN 201410158474 A CN201410158474 A CN 201410158474A CN 105025470 A CN105025470 A CN 105025470A
- Authority
- CN
- China
- Prior art keywords
- service request
- token
- app
- module
- validity
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Abstract
An embodiment of the invention discloses a service request processing method which is applied to a terminal side or application app billing point and comprises the following steps: an app encrypts a service request according to an app key; and the app sends the encrypted service request and the app id of the terminal app. Another embodiment of the invention discloses a service request processing method which is applied to a service platform and comprises the steps of receiving a service request and an app id, acquiring a corresponding app key according to the app id, and decrypting the service request according to the app key. Embodiments of the invention further disclose a service request processing method, a service request processing device, a service request processing system and a service platform.
Description
Technical field
The present invention relates to mobile data services field, particularly relate to a kind of service request processing method, system and relevant apparatus.
Background technology
Along with the development of intellectual technology, the household bill charging such as present water, electricity, combustion gas can realize Intelligent statistical and generate bill.But user's inquiry, payment can only be gone inquiry payment to each trade company (service company such as water, electricity, combustion gas, cable TV) or pay the fees to appointed bank, make troubles to user.The rise of mobile-phone payment makes user not go out family realization inquiry payment becomes possibility.Cellphone subscriber sends short-message instruction to mobile-phone payment household bill system, and system analysis process short-message instruction, to each corresponding trade company inquiring user bill information, arrives payment platform afterwards and pays.
Although the mode of paying household bill by short message enjoys the favors such as trade company, bank, operator, bring convenience efficiently simultaneously at it, people are also worrying that how high its fail safe have actually.At present in order to the main method of the safety problem solving payment by using short messages has following several:
1, increasing the fail safe that note secondary-confirmation ensures payment by using short messages, is send payment instruction user, and system confirms to pay the content of replying as allowing user according to certain generate rule sequence code after receiving the request of payment again.Like this can the payment request of authentication of users again;
2, based on the payment by using short messages method and system of fingerprint recognition mobile phone, at payment system fingerprint register, account and its phone number and fingerprint template are bound; Generating public and private key, generate digital certificate, and described digital certificate, private key and fingerprint template are provided to user mobile phone, when mobile phone checking fingerprint passes through when paying, with private key to payment note and fingerprint characteristic digital signature, and being sent to payment system; Payment system public key decryptions, and verify fingerprint characteristic; When being verified, pay according to payment note;
3, note pre-authorization, Mobile banking client is taked to be applied for the mode of pre-authorization, grant number to bank by note, there is provided the pre-authorization of some money in advance to beneficiary, when reality is settled accounts, beneficiary and paying party are settled accounts within the pre-authorization amount of money according to grant number.This means of payment decreases Mobile banking user and spends in the time of waiting above communication when settling accounts, and can use when waiting in line or requestee is absent from the scene.
But there is following shortcoming in above-mentioned prior art:
1, for said short message secondary-confirmation mode, first, adopt which to increase short message interacting waste note resource and system loading, each pays request note system expense is more than twice; Secondly, adopt which can not prevent trade company from being falsely used, such as one legal trade company is falsely used by illegal trade company, and a porns, gambling and drugs app falsely uses legal app and charges, and is the maximum problem that online payment by using short messages faces; Again, short message content may be obtained the payment information of user by intercepting, payment safety is low;
2, for the above-mentioned payment by using short messages mode based on fingerprint recognition mobile phone, adopt which use cost too high and be not suitable for large-scale popularization use;
3, for said short message pre-authorization mode, adopt which can only realize the safety in transmission channel, the problem that illegal charging point falsely uses legal charging point cannot be solved, thus payment safety is low.
Summary of the invention
In view of this, for solving the technical problem of existing existence, the embodiment of the present invention provides:
A kind of service request processing method, is applied to end side or application app charging point, comprises:
App is encrypted service request according to application private key appkey;
Send the application identities appid of the service request after described encryption and described app.
Preferably, before app to be encrypted service request according to appkey, the method also comprises:
Described app carries out app registration, obtains corresponding appid, appkey, token and token term of validity,
Described service request carries described token and service request content.
Preferably, described service request also carries anti-replay value counter, and the counter value that described service request is carried is greater than the counter value that in the described token term of validity, a upper service request is carried.
Preferably, the service request after the described encryption of described transmission, comprising:
Service request after adopting Hyper text transfer security protocol https to send described encryption, or,
After the relevant Hash operation message authentication code HMAC process of key is carried out to the service request after described encryption, the service request after adopting https to send described HMAC process.
Preferably, the method also comprises:
When the token term of validity is exceeded the time limit, carry out initialization operation, again obtain new token and the token term of validity.
Preferably, described terminal applies app is encrypted service request according to application private key appkey, comprising:
Obtain service request content;
Call fail-safe software development kit SDK to be encrypted service request according to appkey.
Preferably, described service request is for paying request.
A kind of service request processing method, is applied to business platform, comprises:
Receive service request and appid;
Corresponding appkey is obtained according to described appid;
According to described appkey, described service request is decrypted.
Preferably, the method also comprises:
When app carries out app registration, for described app distributes corresponding appid, appkey, token and token term of validity;
Store described appid, appkey, token and token term of validity.
Preferably, described service request carries token and service request content, and the method also comprises:
After according to described appkey described service request being decrypted, judging that the token whether token that described service request is carried is corresponding with the described appid stored is consistent, if unanimously, determine that described service request is legitimate request, carry out corresponding service process; Otherwise, determine that described service request is illegal request, refuse described service request.
Preferably, described service request also carries counter, and the method also comprises:
After determining that described service request is legitimate request, judge the counter value whether counter that described service request is carried is greater than in the described token term of validity the upper service request that receives and carries, if so, carry out corresponding service process; Otherwise, refuse described service request.
Preferably, the method also comprises:
When the token term of validity is exceeded the time limit, carry out initialization operation, for corresponding app distributes new token and the token term of validity.
A kind of service request processing method, comprising:
App adopts the above-mentioned method being applied to end side or app charging point to send service request and appid;
The above-mentioned method being applied to business platform of business platform processes described service request.
A kind of service request processing unit, is arranged at end side or app charging point, comprises encrypting module and sending module; Wherein,
Described encrypting module, for being encrypted service request according to application private key appkey;
Described sending module, for sending the application identities appid of the service request after described encryption and corresponding app.
Preferably, this device also comprises the first acquisition module,
Described first acquisition module, for carrying out app registration, obtains corresponding appid, appkey, token and token term of validity,
The service request that described sending module sends carries described token and service request content.
Preferably, the service request that described sending module sends also carries anti-replay value counter, and the counter value that described service request is carried is greater than the counter value that in the described token term of validity, a upper service request is carried.
Preferably, described sending module, the service request after described encryption is sent specifically for adopting Hyper text transfer security protocol https, or, after the relevant Hash operation message authentication code HMAC process of key is carried out to the service request after described encryption, the service request after adopting https to send described HMAC process.
Preferably, this device also comprises the second acquisition module,
Described second acquisition module, for when the token term of validity is exceeded the time limit, carries out initialization operation, again obtains new token and the token term of validity.
Preferably, described encrypting module comprises: obtain submodule and safe SDK submodule; Wherein,
Described acquisition submodule, for obtaining service request content; And call SDK submodule service request is encrypted;
Described SDK submodule, for when obtaining submodule and calling, is encrypted service request according to appkey.
A kind of business platform, comprising: receiver module, acquisition module and deciphering module; Wherein,
Described receiver module, for receiving service request and appid;
Described acquisition module, for obtaining corresponding appkey according to described appid;
Described deciphering module, for being decrypted described service request according to described appkey.
Preferably, this business platform also comprises the first distribution module and memory module, wherein,
Described first distribution module, during for carrying out app registration at app, for described app distributes corresponding appid, appkey, token and token term of validity;
Described memory module, for storing described appid, appkey, token and token term of validity.
Preferably, described service request carries token and service request content, and described business platform also comprises the first judge module and processing module; Wherein,
Described first judge module, consistent for judging the token whether token that described service request carries is corresponding with the described appid stored, if unanimously, determine that described service request is legitimate request; Otherwise, determine that described service request is illegal request;
Described processing module, for when determining that described service request is legitimate request, carries out corresponding service process; Determining that described service request is illegal request, refuse described service request.
Preferably, this business platform also comprises the second judge module,
Described second judge module, after determining that described service request is legitimate request at the first judge module, judge the counter value whether counter that described service request is carried is greater than in the described token term of validity the upper service request that receives and carries, if so, notification handler module carries out corresponding service process; Otherwise notification handler module refuses described service request.
Preferably, this business platform also comprises the second distribution module,
Described second distribution module, for when the token term of validity is exceeded the time limit, carries out initialization operation, for corresponding app distributes new token and the token term of validity.
A kind of service request treatment system, comprising: service request processing unit and business platform; Wherein,
Described service request processing unit is above-mentioned service request processing unit;
Described business platform is above-mentioned business platform.
Service request processing method described in the embodiment of the present invention, system and relevant apparatus, app is encrypted service request according to application private key appkey; Send the application identities appid of the service request after described encryption and described terminal app.Adopt the technical scheme described in the embodiment of the present invention, can ensure that service application is not illegally falsely used, ensure that in data transmission procedure, data are not tampered and prevent malice from repeating initiation business, thus improve data service fail safe.
Accompanying drawing explanation
Fig. 1 is a kind of service request processing method schematic flow sheet being applied to end side of one embodiment of the invention;
Fig. 2 is a kind of service request processing method schematic flow sheet being applied to network side of one embodiment of the invention;
Fig. 3 is a kind of terminal equipment structural representation of one embodiment of the invention;
Fig. 4 is a kind of terminal equipment structural representation of another embodiment of the present invention;
Fig. 5 is a kind of terminal equipment structural representation of yet another embodiment of the invention;
Fig. 6 is the structural representation of a kind of encrypting module 31 of one embodiment of the invention;
Fig. 7 is a kind of business platform structural representation of one embodiment of the invention;
Fig. 8 is a kind of business platform structural representation of another embodiment of the present invention;
Fig. 9 is a kind of business platform structural representation of yet another embodiment of the invention;
Figure 10 is a kind of business platform structural representation of yet another embodiment of the invention;
Figure 11 is a kind of business platform structural representation of yet another embodiment of the invention;
Figure 12 is the method for payment schematic flow sheet described in the embodiment of the present invention 1;
Figure 13 is the structural representation of safe SDK module in the embodiment of the present invention 1.
Embodiment
The embodiment of the present invention proposes a kind of service request processing method, is applied to end side, and as shown in Figure 1, the method comprises:
Step 101:app is encrypted service request according to application private key appkey;
Step 102: the application identities appid sending the service request after described encryption and described terminal app.
It should be noted that, the method described in the embodiment of the present invention can be applied to end side or app charging point.
Optionally, before app to be encrypted service request according to appkey, the method also comprises:
Described app carries out app registration, obtains corresponding appid, appkey, token and token term of validity,
Described service request carries described token and service request content.
Optionally, described service request also carries anti-replay value counter, and the counter value that described service request is carried is greater than the counter value that in the described token term of validity, a upper service request is carried.
Optionally, the service request after the described encryption of described transmission, comprising:
Service request after adopting Hyper text transfer security protocol https to send described encryption, or,
After the relevant Hash operation message authentication code HMAC process of key is carried out to the service request after described encryption, the service request after adopting https to send described HMAC process.
Optionally, the method also comprises:
When the token term of validity is exceeded the time limit, carry out initialization operation, again obtain new token and the token term of validity.
Optionally, described terminal applies app is encrypted service request according to application private key appkey, comprising:
Obtain service request content;
Call fail-safe software development kit SDK to be encrypted service request according to appkey.
Optionally, described service request is for paying request.
The embodiment of the present invention also proposed a kind of service request processing method, is applied to network side, and as shown in Figure 2, the method comprises:
Step 201: receive service request and appid;
Step 202: obtain corresponding appkey according to described appid;
Step 203: described service request is decrypted according to described appkey.
Optionally, the method also comprises:
When app carries out app registration, for described app distributes corresponding appid, appkey, token and token term of validity;
Store described appid, appkey, token and token term of validity.
Optionally, described service request carries token and service request content, and the method also comprises:
After according to described appkey described service request being decrypted, judging that the token whether token that described service request is carried is corresponding with the described appid stored is consistent, if unanimously, determine that described service request is legitimate request, carry out corresponding service process; Otherwise, determine that described service request is illegal request, refuse described service request.
Optionally, described service request also carries counter, and the method also comprises:
After determining that described service request is legitimate request, judge the counter value whether counter that described service request is carried is greater than in the described token term of validity the upper service request that receives and carries, if so, carry out corresponding service process; Otherwise, refuse described service request.
Optionally, the method also comprises:
When the token term of validity is exceeded the time limit, carry out initialization operation, for corresponding app distributes new token and the token term of validity.
The embodiment of the present invention also proposed a kind of service request processing method, and the method comprises:
App adopts the method shown in Fig. 1 to send service request and appid;
Business platform adopts the method shown in Fig. 2 to process described service request.
The embodiment of the present invention also correspondingly proposes a kind of service request processing unit, and as shown in Figure 3, this service request processing unit comprises encrypting module 31 and sending module 32; Wherein,
Encrypting module 31, for being encrypted service request according to application private key appkey;
Sending module 32, for sending the application identities appid of the service request after described encryption and corresponding app.
Optionally, as shown in Figure 4, this terminal equipment also comprises the first acquisition module 33,
First acquisition module 33, for carrying out app registration, obtains corresponding appid, appkey, token and token term of validity,
The service request that sending module 32 sends carries described token and service request content.
Optionally, the service request that sending module 32 sends also carries anti-replay value counter, and the counter value that described service request is carried is greater than the counter value that in the described token term of validity, a upper service request is carried.
Optionally, sending module 32, the service request after described encryption is sent specifically for adopting Hyper text transfer security protocol https, or, after the relevant Hash operation message authentication code HMAC process of key is carried out to the service request after described encryption, the service request after adopting https to send described HMAC process.
Optionally, as shown in Figure 5, this terminal equipment also comprises the second acquisition module 34,
Second acquisition module 34, for when the token term of validity is exceeded the time limit, carries out initialization operation, again obtains new token and the token term of validity.
Optionally, as shown in Figure 6, encrypting module 31 comprises: obtain submodule 311 and safe SDK submodule 312; Wherein,
Obtain submodule 311, for obtaining service request content; And call SDK submodule 312 pairs of service request and be encrypted;
SDK submodule 312, for when obtaining submodule and calling, is encrypted service request according to appkey.
The embodiment of the present invention also correspondingly proposes a kind of business platform, and as shown in Figure 7, this business platform comprises: receiver module 71, acquisition module 72 and deciphering module 73; Wherein,
Receiver module 71, for receiving service request and appid;
Acquisition module 72, for obtaining corresponding appkey according to described appid;
Deciphering module 73, for being decrypted described service request according to described appkey.
Optionally, as shown in Figure 8, this business platform also comprises the first distribution module 74 and memory module 75, wherein,
First distribution module 74, during for carrying out app registration at app, for described app distributes corresponding appid, appkey, token and token term of validity;
Memory module 75, for storing described appid, appkey, token and token term of validity.
Optionally, described service request carries token and service request content, and as shown in Figure 9, described business platform also comprises the first judge module 76 and processing module 77; Wherein,
First judge module 76, consistent for judging the token whether token that described service request carries is corresponding with the described appid stored, if unanimously, determine that described service request is legitimate request; Otherwise, determine that described service request is illegal request;
Processing module 77, for when determining that described service request is legitimate request, carries out corresponding service process; Determining that described service request is illegal request, refuse described service request.
Optionally, as shown in Figure 10, this business platform also comprises the second judge module 78,
Second judge module 78, after determining that described service request is legitimate request at the first judge module 76, judge the counter value whether counter that described service request is carried is greater than in the described token term of validity the upper service request that receives and carries, if so, notification handler module carries out corresponding service process; Otherwise notification handler module refuses described service request.
Optionally, as shown in figure 11, this business platform also comprises the second distribution module 79,
Second distribution module 79, for when the token term of validity is exceeded the time limit, carries out initialization operation, for corresponding app distributes new token and the token term of validity.
The embodiment of the present invention also correspondingly proposes a kind of service request treatment system, and this system comprises: terminal equipment and business platform; Wherein,
Described terminal equipment is the arbitrary shown terminal equipment of Fig. 3 to 6;
Described business platform is the arbitrary shown business platform of Fig. 7 to 11.
Below by specific embodiment, the present invention is described in further detail.
Embodiment 1
Figure 12 is the method for payment schematic flow sheet described in the embodiment of the present invention 1, and as shown in figure 12, this flow process comprises:
Step 1201: payment platform when app registers as app distributes appid, appkey, token and token term of validity.
It should be noted that, appkey is the private key of app, is kept at payment platform.
When step 1202:app needs to send payment request to payment platform, according to application private key appkey, payment request is encrypted.
Concrete, app calls the method that safe SDK provides, and oneself appid, appkey, token and payment request content are passed to safe SDK as parameter.Safe SDK uses appkey to be encrypted for double secret key pays request (comprise token and pay request content), and payment platform is passed in the payment request after encryption and appid.
Step 1203:app sends the payment request after encryption and appid to payment platform.
In order to ensure the fail safe of data transmission channel, app(charging point in the present embodiment) mutual with payment platform by safe SDK, first, between safe SDK and payment platform, adopt https to transmit the safety ensureing transmission channel; Secondly, the data of transmission use the private key of app to be encrypted, but the payment request only transmitted in the process of transmission after appid and encryption and do not transmit the private key of app.At payment platform end, be decrypted by integrated security module, if data are replaced, separate secret meeting failure, ensure that the fail safe of transfer of data.
Step 1204: after payment platform receives the request of payment, inquires about the corresponding appkey oneself preserved, and is decrypted payment request according to described appkey according to appid.
Step 1205: whether the token arrived is deciphered in checking correct, if correct, think that the request of payment is legal payment request, otherwise is illegal request, thus ensure the legitimacy of app, avoid illegally falsely using of app.
The present embodiment illegally repeats to pay to prevent, anti-replay checking is increased in safe SDK, same charging point safeguards a counter value in a token term of validity, each value paying request counter that sends can increase according to preset strategy, counter value is safeguarded by safe SDK, payment platform security module safeguards the counter value of an app example in the token term of validity, if the anti-replay value of this request is less than asked anti-replay value last time, then think that this time request is not security request, thus reach and prevent illegal data intercept from repeating payment problem.
Figure 13 is the structural representation of safe SDK module in the embodiment of the present invention, and as shown in figure 13, this safe SDK module can comprise:
Ability to pay interface, safe SDK provides ability to pay calling interface to app, and app does not need oneself to realize security algorithm logic in the process of exploitation, only need to call interface that safe SDK provides with.App developer's application of payment by using short messages easy to use, developer does not need to be concerned about bottom layer realization;
App initialization module, when the token that app first time calls safe SDK or safe SDK maintenance exceedes the term of validity, SDK needs to carry out initialization, in initialized process, security module sends initialization request to the security module of payment platform, and payment platform security module verification appid and appkey also generates the token that possesses the term of validity;
SDK security computing layer, can adopt symmetric encipherment algorithm etc. to be responsible for being encrypted the data of transmission.Security computing layer realizes adopting symmetrical AES encryption algorithm to use app private key appkey be encrypted request msg and do HMAC process, ensure that data are intercepted and captured also can not be cracked, payment platform security module is only had to adopt identical algorithm to use the private key appkey of app to decrypt data, could this ensure that app can not illegally be falsely used.
SDK secure transport layers, first, adopts https to transmit the safety ensureing transmission channel between safe SDK and payment platform; Secondly, the private key of the data use app of transmission is encrypted and does HMAC process, but only transmit appid and encryption in the process transmitted after, payment is asked and do not transmit the private key of app.Be decrypted by integrated security module at payment platform end, if data are replaced, separate secret meeting failure, ensure the fail safe of transfer of data.
In addition, safe SDK possesses anti-replay function, same app example safeguards a counter value in a token term of validity, the value of each request counter can weight increase, counter value is safeguarded by safe SDK, payment platform security module safeguards the counter value of an app example in the token term of validity, if the anti-replay value of this request is less than asked anti-replay value last time, then think that this time request is not security request, even so the original text intercepted transmits again also can be considered to illegal transmissions, thus ensure the safe transmission of data.
The present embodiment, on the basis of fully practice demonstration, adopts the fail safe of safe SDK technique guarantee charging point and transmission channel.Charging point needs integrated security SDK, the service end integrated security module of payment system in the process of exploitation.The technical problem mainly solved has:
1, ensure that namely charging point only has safely the charging point of lawful registration just can pay, by integrated security SDK, payment by using short messages instruction is dealt into charging point by user, and charging point sends to payment platform the request of payment by safe SDK;
2, the fail safe of data transmission channel is ensured, charging point is mutual with payment platform by safe SDK, the data of transmission use the private key of charging point to be encrypted, but in the process of transmission, do not transmit the private key of app, payment platform is handed to after payment platform end is decrypted by integrated safe SDK, if data are replaced, decipher failure, ensure the fail safe of transfer of data;
3, prevent from illegally repeating to pay, another problem that payment by using short messages faces is that after payment request is intercepted, data are not made any change and again paid, and the wooden horse of this use acquisition of information can easily be accomplished.This motion adopts increases anti-replay checking in safe SDK, if same charging point example anti-replay value in a token term of validity is less than asked anti-replay value last time, then thinks that this time request is not security request.
The above, be only preferred embodiment of the present invention, be not intended to limit protection scope of the present invention.
Claims (25)
1. a service request processing method, be applied to end side or application app charging point, it is characterized in that, the method comprises:
App is encrypted service request according to application private key appkey;
Send the application identities appid of the service request after described encryption and described app.
2. method according to claim 1, is characterized in that, before app to be encrypted service request according to appkey, the method also comprises:
Described app carries out app registration, obtains corresponding appid, appkey, token and token term of validity,
Described service request carries described token and service request content.
3. method according to claim 2, is characterized in that, described service request also carries anti-replay value counter, and the counter value that described service request is carried is greater than the counter value that in the described token term of validity, a upper service request is carried.
4. method according to claim 1, is characterized in that, the service request after the described encryption of described transmission, comprising:
Service request after adopting Hyper text transfer security protocol https to send described encryption, or,
After the relevant Hash operation message authentication code HMAC process of key is carried out to the service request after described encryption, the service request after adopting https to send described HMAC process.
5. method according to claim 2, is characterized in that, the method also comprises:
When the token term of validity is exceeded the time limit, carry out initialization operation, again obtain new token and the token term of validity.
6. method according to claim 1, is characterized in that, described terminal applies app is encrypted service request according to application private key appkey, comprising:
Obtain service request content;
Call fail-safe software development kit SDK to be encrypted service request according to appkey.
7. the method according to any one of claim 1 to 6, is characterized in that, described service request is for paying request.
8. a service request processing method, is applied to business platform, it is characterized in that, the method comprises:
Receive service request and appid;
Corresponding appkey is obtained according to described appid;
According to described appkey, described service request is decrypted.
9. method according to claim 8, is characterized in that, the method also comprises:
When app carries out app registration, for described app distributes corresponding appid, appkey, token and token term of validity;
Store described appid, appkey, token and token term of validity.
10. method according to claim 9, is characterized in that, described service request carries token and service request content, and the method also comprises:
After according to described appkey described service request being decrypted, judging that the token whether token that described service request is carried is corresponding with the described appid stored is consistent, if unanimously, determine that described service request is legitimate request, carry out corresponding service process; Otherwise, determine that described service request is illegal request, refuse described service request.
11. methods according to claim 10, is characterized in that, described service request also carries counter, and the method also comprises:
After determining that described service request is legitimate request, judge the counter value whether counter that described service request is carried is greater than in the described token term of validity the upper service request that receives and carries, if so, carry out corresponding service process; Otherwise, refuse described service request.
12. methods according to claim 8, it is characterized in that, the method also comprises:
When the token term of validity is exceeded the time limit, carry out initialization operation, for corresponding app distributes new token and the token term of validity.
13. 1 kinds of service request processing method, it is characterized in that, the method comprises:
App adopts the method described in any one of claim 1 to 7 to send service request and appid;
Business platform adopts the method described in any one of claim 8 to 12 to process described service request.
14. 1 kinds of service request processing unit, be arranged at end side or app charging point, it is characterized in that, this device comprises encrypting module and sending module; Wherein,
Described encrypting module, for being encrypted service request according to application private key appkey;
Described sending module, for sending the application identities appid of the service request after described encryption and corresponding app.
15. devices according to claim 14, is characterized in that, this device also comprises the first acquisition module,
Described first acquisition module, for carrying out app registration, obtains corresponding appid, appkey, token and token term of validity,
The service request that described sending module sends carries described token and service request content.
16. devices according to claim 15, is characterized in that,
The service request that described sending module sends also carries anti-replay value counter, and the counter value that described service request is carried is greater than the counter value that in the described token term of validity, a upper service request is carried.
17. devices according to claim 14, is characterized in that,
Described sending module, the service request after described encryption is sent specifically for adopting Hyper text transfer security protocol https, or, after the relevant Hash operation message authentication code HMAC process of key is carried out to the service request after described encryption, the service request after adopting https to send described HMAC process.
18. devices according to claim 15, is characterized in that, this device also comprises the second acquisition module,
Described second acquisition module, for when the token term of validity is exceeded the time limit, carries out initialization operation, again obtains new token and the token term of validity.
19. devices according to claim 14, is characterized in that, described encrypting module comprises: obtain submodule and safe SDK submodule; Wherein,
Described acquisition submodule, for obtaining service request content; And call SDK submodule service request is encrypted;
Described SDK submodule, for when obtaining submodule and calling, is encrypted service request according to appkey.
20. 1 kinds of business platforms, is characterized in that, this business platform comprises: receiver module, acquisition module and deciphering module; Wherein,
Described receiver module, for receiving service request and appid;
Described acquisition module, for obtaining corresponding appkey according to described appid;
Described deciphering module, for being decrypted described service request according to described appkey.
21. business platforms according to claim 20, is characterized in that, this business platform also comprises the first distribution module and memory module, wherein,
Described first distribution module, during for carrying out app registration at app, for described app distributes corresponding appid, appkey, token and token term of validity;
Described memory module, for storing described appid, appkey, token and token term of validity.
22. business platforms according to claim 21, is characterized in that, described service request carries token and service request content, and described business platform also comprises the first judge module and processing module; Wherein,
Described first judge module, consistent for judging the token whether token that described service request carries is corresponding with the described appid stored, if unanimously, determine that described service request is legitimate request; Otherwise, determine that described service request is illegal request;
Described processing module, for when determining that described service request is legitimate request, carries out corresponding service process; Determining that described service request is illegal request, refuse described service request.
23. business platforms according to claim 22, is characterized in that, this business platform also comprises the second judge module,
Described second judge module, after determining that described service request is legitimate request at the first judge module, judge the counter value whether counter that described service request is carried is greater than in the described token term of validity the upper service request that receives and carries, if so, notification handler module carries out corresponding service process; Otherwise notification handler module refuses described service request.
24. business platforms according to claim 21, is characterized in that, this business platform also comprises the second distribution module,
Described second distribution module, for when the token term of validity is exceeded the time limit, carries out initialization operation, for corresponding app distributes new token and the token term of validity.
25. 1 kinds of service request treatment systems, is characterized in that, this system comprises: service request processing unit and business platform; Wherein,
Described service request processing unit is the service request processing unit described in any one of claim 14 to 19;
Described business platform is the business platform described in any one of claim 20 to 24.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410158474.9A CN105025470A (en) | 2014-04-18 | 2014-04-18 | Service request processing method, system and related device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410158474.9A CN105025470A (en) | 2014-04-18 | 2014-04-18 | Service request processing method, system and related device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN105025470A true CN105025470A (en) | 2015-11-04 |
Family
ID=54415094
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201410158474.9A Pending CN105025470A (en) | 2014-04-18 | 2014-04-18 | Service request processing method, system and related device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN105025470A (en) |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106411958A (en) * | 2016-12-06 | 2017-02-15 | 北京锐安科技有限公司 | Data transmission method and device based on HTTP protocol |
| CN108737110A (en) * | 2018-05-23 | 2018-11-02 | 中汇会计师事务所（特殊普通合伙） | A kind of data encryption and transmission method and device for anti-replay-attack |
| CN109450643A (en) * | 2018-11-05 | 2019-03-08 | 四川长虹电器股份有限公司 | The signature sign test method realized in Android platform based on native service |
| CN114338091A (en) * | 2021-12-08 | 2022-04-12 | 杭州逗酷软件科技有限公司 | Data transmission method and device, electronic equipment and storage medium |
| CN114567480B (en) * | 2022-02-28 | 2024-03-12 | 天翼安全科技有限公司 | Method, device, secure network and storage medium for identifying effective attack alarm |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101178671A (en) * | 2007-12-11 | 2008-05-14 | 北大方正集团有限公司 | Method and system for dynamically configuring service treatment progress on server terminal |
| CN102546532A (en) * | 2010-12-07 | 2012-07-04 | 中国移动通信集团公司 | Capacity calling method, capacity calling request device, capacity calling platform and capacity calling system |
| CN102572815A (en) * | 2010-12-29 | 2012-07-11 | 中国移动通信集团公司 | Method, system and device for processing terminal application request |
| CN103106581A (en) * | 2012-12-21 | 2013-05-15 | 福建联迪商用设备有限公司 | Method, device and system of safe electronic payment |
| US20130124421A1 (en) * | 2011-11-04 | 2013-05-16 | Alibaba Group Holding Limited | Secure authentication method and system for online transactions |
-
2014
- 2014-04-18 CN CN201410158474.9A patent/CN105025470A/en active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101178671A (en) * | 2007-12-11 | 2008-05-14 | 北大方正集团有限公司 | Method and system for dynamically configuring service treatment progress on server terminal |
| CN102546532A (en) * | 2010-12-07 | 2012-07-04 | 中国移动通信集团公司 | Capacity calling method, capacity calling request device, capacity calling platform and capacity calling system |
| CN102572815A (en) * | 2010-12-29 | 2012-07-11 | 中国移动通信集团公司 | Method, system and device for processing terminal application request |
| US20130124421A1 (en) * | 2011-11-04 | 2013-05-16 | Alibaba Group Holding Limited | Secure authentication method and system for online transactions |
| CN103106581A (en) * | 2012-12-21 | 2013-05-15 | 福建联迪商用设备有限公司 | Method, device and system of safe electronic payment |
Cited By (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106411958A (en) * | 2016-12-06 | 2017-02-15 | 北京锐安科技有限公司 | Data transmission method and device based on HTTP protocol |
| CN108737110A (en) * | 2018-05-23 | 2018-11-02 | 中汇会计师事务所（特殊普通合伙） | A kind of data encryption and transmission method and device for anti-replay-attack |
| CN108737110B (en) * | 2018-05-23 | 2021-05-14 | 中汇会计师事务所（特殊普通合伙） | Data encryption transmission method and device for preventing replay attack |
| CN109450643A (en) * | 2018-11-05 | 2019-03-08 | 四川长虹电器股份有限公司 | The signature sign test method realized in Android platform based on native service |
| CN114338091A (en) * | 2021-12-08 | 2022-04-12 | 杭州逗酷软件科技有限公司 | Data transmission method and device, electronic equipment and storage medium |
| CN114567480B (en) * | 2022-02-28 | 2024-03-12 | 天翼安全科技有限公司 | Method, device, secure network and storage medium for identifying effective attack alarm |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10885501B2 (en) | Accredited certificate issuance system based on block chain and accredited certificate issuance method based on block chain using same, and accredited certificate authentication system based on block chain and accredited certificate authentication method based on block chain using same | |
| US8763097B2 (en) | System, design and process for strong authentication using bidirectional OTP and out-of-band multichannel authentication | |
| CN103020825B (en) | A kind of secure payment authentication method based on software client | |
| CN101510877B (en) | Single-point logging-on method and system, communication apparatus | |
| US8499156B2 (en) | Method for implementing encryption and transmission of information and system thereof | |
| CN103440444B (en) | The signing method of electronic contract | |
| CN102880960B (en) | Based on the payment by using short messages method and system of fingerprint recognition mobile phone | |
| CN102546532B (en) | Capacity calling method, request unit, platform and system | |
| US20090187980A1 (en) | Method of authenticating, authorizing, encrypting and decrypting via mobile service | |
| CN101860525B (en) | Realizing method of electronic authorization warrant, intelligent terminal, authorization system and verification terminal | |
| WO2012155644A1 (en) | Bill entrustment payment management method, device, and system | |
| CN101772024B (en) | User identification method, device and system | |
| CN107516196A (en) | A kind of mobile-payment system and its method of mobile payment | |
| CN102378170A (en) | Method, device and system of authentication and service calling | |
| CN102571693A (en) | Capability safety calling method, device and system | |
| CN102868665A (en) | Method and device for data transmission | |
| CN108712382A (en) | A kind of authentication method and system of the digital identity based on safe Quick Response Code | |
| CN105025470A (en) | Service request processing method, system and related device | |
| WO2018133674A1 (en) | Method of verifying and feeding back bank payment permission authentication information | |
| JP2006318489A (en) | Method and device for confirming authentication of id of service user | |
| JP2008099267A (en) | Method for securing session between wireless terminal and equipment in network | |
| CN106230838A (en) | A kind of third-party application accesses the method and apparatus of resource | |
| CN102254380A (en) | Safe mobile phone payment method and system based on hybrid encryption mechanism | |
| CN109873819A (en) | A kind of method and system preventing unauthorized access server | |
| CN101895847A (en) | Short message service authenticated encryption system and method based on digital certificate |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20151104 |