Capacity calling method, capacity calling request device, capacity calling platform and capacity calling system

[0017] Method embodiment one

[0018] Such as figure 1 As shown, the embodiment of the capability invocation method of the present invention includes the following steps:

[0019] Step 102: The client sends a token acquisition request to the application side;

[0020] Step 104: The application side generates a Token according to the Token acquisition request, and returns the Token to the client; the details are as follows:

[0021] In order to ensure the confidentiality of the Token and avoid its unauthorized use, the Token can be customized during specific operations. The customized algorithm includes the Token generation function on the application side and the Token verification function on the server side (that is, the ability to call the platform side). And in the process of business use, the internal mechanism of Token is kept confidential; the implementation mechanism is divided into five levels from bottom to top:

[0022] a. Standardized algorithm. The bottom layer is the implementation of standardized algorithm, such as HOTP algorithm using RFC 4226 standard;

[0023] b. GDK parameters, namely global master key settings, used to participate in the generation of authorized tokens; that is, the original key used to generate authorized tokens is replaced by Key and the hash value of GDK;

[0024] c. Algorithm input conversion, that is, to convert the plain text input parameters originally used to generate the authorization token, for example, the left and right parts of the plain text input parameters can be exchanged;

[0025] d. Application and capability binding, that is, binding the authorization information, and verifying the Token while verifying the authorization information;

[0026] e. Operator network binding. While performing Token verification for order or registration request, it is necessary to check whether operator parameters such as IMSI belong to the operator deploying the service, focusing on the MCC mobile country code (for example, "46" for China) ) And MNC mobile network code (such as China Mobile, GSM: "000" or "002", TS-SCDMA: "007") when requesting capability, it is necessary to check whether the first three digits of MSISDN belong to the operation of the deployed service Quotient

[0027] Those skilled in the art can understand that the above five levels for ensuring the confidentiality of Tokens are preferred solutions to enhance security, and the specific Token generation algorithm is the prior art, and will not be repeated;

[0028] Step 106: The client generates and sends a capability call request including the Token; in specific operations, the capability call request may include: the application ID APPID of the application corresponding to the Token (that is, the application that receives the Token acquisition request on the application side) , Application side application user identity (referred to as user) identifies PID and Token, where the user can initiate a capability call through a mobile terminal or the Web. Correspondingly, Token can include TerToken and WebToken;

[0029] Step 108: The capability invocation platform performs verification according to the capability invocation request; the specific explanation is as follows:

[0030] First, verify the Token in the capability invocation request; specifically, before the application is officially used, the capability invocation platform allocates the corresponding application key APPKEY for each application in advance and stores it on the application side and the capability invocation platform side respectively for guarantee For the authenticity of the application identity, the application side (as in step 104) uses the APPKEY to encrypt and generate the Token according to a preset generation algorithm; after receiving the capability call request, the capability invocation platform selects a preset school that is consistent with the generation algorithm. Verify the function, and obtain the corresponding APPKEY stored on the capability call platform side according to the application identification APPID included in the call request, call the APPKEY stored on the platform side according to the verification algorithm and the capability to generate a verification token, and compare the verification Token and the Token generated on the application side are verified. When the two are consistent, the verification is successful, that is, the APPID and APPKEY of the application have a one-to-one correspondence. If the verification fails, the operation ends. If the verification passes, the step 110. Those skilled in the art can understand that the verification function is consistent with the generation function. If the Token is generated, the generation function also includes other parameters, such as the count value of the number of client requests. When the Token is verified, It is necessary to use the count value counter to generate the verification Token, which will not be repeated;

[0031] Specifically, for WEB applications, APPKEY is in the application development stage, which is acquired by the developer and is preset in the WEB application code (corresponding to image 3 For terminal applications, APPKEY is in the online phase of the application. After the application passes the ability to call the platform audit, it is safely stored in the new terminal application security component (corresponding to image 3 In the application security component), and by replacing the security component used by the developer in the development phase with the newly-built terminal application security component, the safe distribution of APPKEY (this replacement operation ensures that the developer is unaware of the APPKEY); The capability call platform also needs to store APPKEY securely (such as through an encryption machine) and use it (mainly used to verify TerToken and WebToken) to ensure the security of APPKEY;

[0032] Those skilled in the art can know that the verification of the Token here can be performed according to a preset verification method. Obtaining the corresponding application key according to the application identifier APPID for decryption verification is a preferred method. Correspondingly, Including the Token in the capability call request can achieve the purpose of the invention, including the application identification APPID and the user identification PID as a preferred solution; in addition, the capability call request may also include a counter value representing the number of client requests. Accordingly, The capability calling platform further verifies the size and expiration of the counter to determine whether the size of the counter is within the preset range and whether the expiration date has expired. If both conditions are met, the verification is passed; otherwise, the verification fails; the count is passed The size and time limit of the value counter realizes the control that the number of times the client initiates a capability call request exceeds the preset threshold and needs to be re-registered; or if the registration time exceeds a certain time limit, it needs to be re-registered, which improves security;

[0033] Secondly, the user identity is verified according to the user ID in the ability call request; in specific operations, the user ID can be the user’s real ID or the user’s pseudo code ID; if the user ID is represented by the user’s pseudo code ID, the ability invocation platform will order the user When the application is successful, the user pseudo-code identification is generated, the corresponding relationship between the user pseudo-code identification and the user's real identification is stored, and the user pseudo-code identification is returned to the application side; when the capability is invoked, the capability invocation request sent by the application side When the user’s pseudo-code identification is included, the capability invocation platform queries whether the user's real identification exists according to the user's pseudo-code identification and the corresponding relationship with the user's real identification. When the user's real identification (such as MSIDSDN) exists, it determines the effective application The user corresponding to the pseudo code is valid; if the user ID is represented by the user's real ID (such as MSIDSDN), the validity of the user's real ID is directly verified;

[0034] Third, in order to enable the capability invocation platform to authorize application invocation capabilities, the capability invocation platform can also obtain user and application information based on the user ID and application ID, and verify the authentication application-capability contract relationship, user subscription relationship, user account, development Those skilled in the art can understand that the verification method here is mainly based on the pre-stored related information for comparison and verification, which will not be repeated;

[0035] In step 110, the capability invocation platform invokes the capabilities for the client after the verification is successful; for example:

[0036] First, the ability call platform to the corresponding capability platform is the application side call capability;

[0037] Second, the capability platform returns the capability call result response to the capability call platform;

[0038] Third, the capability invocation platform directly forwards the capability invocation result response to the client side.

[0039] In this embodiment, by verifying the capability call request including the token (ie Token) sent by the client, the security of the capability opening of the Internet platform is improved. At the same time, the client directly sends the capability call request and receives the capability directly. The call result avoids the defects of information leakage caused by application-side operations and low security.

[0040] Those skilled in the art can understand, figure 1 It mainly explains that after the application development is completed based on the ability call platform, and the completed application is registered and other operations, the application after the registration is successfully used to realize the process of safely calling the corresponding ability, in order to better understand the present invention , The following explains the other stages, such as the development stage and the ordering stage:

[0041] 1) In the application development stage, one-way HTTPS+username/password can be used to achieve two-way identity authentication between the capability invocation platform and the developer; after application development is completed, each application can be assigned a unique identification APPID by the capability invocation platform when applying for registration At the same time, in order to avoid the forgery of application identity, which may cause problems such as capacity abuse and billing damage during application operation, each application is assigned a fixed key AppKey in advance for application verification. See details figure 1 The explanation of the application side and the capability call platform needs to have a security mechanism to ensure end-to-end interaction; the security component can be combined with each application through the preset security component. The security component mainly realizes authentication, safe storage, and integrity Sexual protection and code obfuscation function;

[0042] In addition, in order to protect user resources from being leaked and abused, a pseudo-code mechanism can also be used. User pseudo-code identification (pseudo-code for short) is the unique identification of the user in the system, such as the unique identification of the user for different applications. Specifically, it can be "user phone number + APPID (application ID)", so that the same user can have different pseudo codes for different applications;

[0043] The pseudo code generation rules are as follows: nonce=Truncate(SHA-1(MSISDN, APPID, Random), 96); pseudo code is generated by permutation and combination of nonce and timestamp, a total of 32 characters; among them: Truncate(SHA-1(MSISDN) , APPID, Random), 96) means that only the first 96 bits are intercepted; MSISDN: is the user's mobile phone number; APPID: application identification; Random: random number (32 bits); nonce is 12Bytes, which is converted from Byte type to character type by BASE64 encoding 16 characters, the format from high to low is: N(1)N(2)N(3)...N(16); timestamp: timestamp (YYYYMMDDhhmmss) + random number supplemented with 2 characters, from high The format to the low order is: T(1)T(2)T(3)...T(16)); reversedtimestamp is the result of replacing each byte in timestamp, and the format of reversedtimestamp from high to low is: R( 1) R(2)R(3)...R(16); the replacement law is shown in Table 1:

[0044] Table 1

[0045] R1=T14

[0046] The format of the pseudo code from high to low is: B(1)B(2)B(3)...B(32); among them, B(2n-1)=N(n) (where n=1, 2 , 3,..., 16); B(2n)=R(n) (where n=1, 2, 3,..., 16);

[0047] 2) When users subscribe, through the ordering process, the ability to call the platform to generate user subscription relationships and maintain user-authorized applications; in order to prevent third-party applications from obtaining the user's true identity (such as MSISDN), the order uses the OMP authorization mechanism, that is, the ability to call the platform Provide an ordering interface for users to obtain the user’s MSISDN, and verify the authenticity of the user’s MSISDN by sending a verification code (such as SMS verification code); in addition, the capability invocation platform can also generate a pseudo code for each application for the user, and the pseudo code Send to the application to ensure that the application uses pseudocode to identify the user in subsequent applications.

[0048] Method embodiment two

[0049] Such as figure 2 As shown, the detailed process of the capability invocation method of this embodiment is as follows:

[0050] 1. The client, such as a web browser, sends a token acquisition request to an application module such as a web application module (the following steps are explained in terms of a web application, and should not be interpreted in a limited way); those skilled in the art can understand, Here are various web applications, such as Ajax web applications;

[0051] 2. The web application module forwards the request to the web security component. During specific operations, the web application module itself can confirm the authenticity of the user identity before forwarding the request;

[0052] 3. The Web security component generates a WebToken and returns a response message including the WebToken to the Web application module; the response can also include the application identifier APPID and Counter during specific operations;

[0053] 4. The web application module returns a response message to the web browser, including APPID, user identification PID (can be user pseudo code identification or user real identification), WebToken, Counter;

[0054] 5. The Web browser sends a capability call request to the platform access subsystem of the capability call platform. The capability call request can include APPID, PID, WebToken, and Counter;

[0055] 6. The platform access subsystem sends a token verification request to the platform authentication module, including APPID, PID, WebToken, and Counter;

[0056] 7. The platform authentication module sends a Token verification request to the platform security module;

[0057] 8. The platform security module verifies the WebToken (the verification process is detailed in figure 1 Explanation), if the verification fails, an error code will be returned;

[0058] 9. The platform security module returns a Token verification pass response to the platform authentication module when the verification is successful; and the platform authentication module returns a Token verification pass response to the platform access subsystem;

[0059] 10. The platform access subsystem sends a capability call request to the platform authentication module, including APPID, which is used to indicate the capability identification EID of the capability to be invoked, and the user identification PID;

[0060] 11. The platform authentication module sends confirmation request information to the access subsystem, and the confirmation request is used to confirm to the user whether to invoke the corresponding capability;

[0061] 12. The access subsystem sends the confirmation message to the user terminal corresponding to the user's real identity (such as MSISDN), such as the user's mobile phone, and there are many ways to send the confirmation message (confirmation response) to the user terminal, such as SMS, email Wait;

[0062] 13. The user terminal returns confirmation information to the access subsystem;

[0063] 14. The access subsystem forwards the confirmation message to the platform authentication module;

[0064] Those skilled in the art can understand that steps 11-14 are mainly for confirming whether the user uses the corresponding application for ability invocation, and they can operate after the verification operation in step 15 is performed, or set the order of specific operations according to actual needs;

[0065] 15. The platform authentication module verifies the capability invocation of the application corresponding to the APPID according to the capability invocation request in step 10, which specifically includes: verification of user legitimacy, the contracting relationship between the platform authority module and the application and the capability, and the user and application The ordering relationship of the product, the developer’s sub-account and the user’s account are verified one by one. If the verification fails, an error code will be returned; at the same time, the platform authentication module performs withholding fees for applications and users;

[0066] 16. The platform authentication module returns a successful verification response to the platform access subsystem;

[0067] 17. The platform access subsystem calls the capability platform that provides corresponding capabilities, such as the location platform;

[0068] 18. The capability platform returns the capability call result to the platform access subsystem;

[0069] 19. The platform access subsystem directly returns the capability call result to the Web browser; directly returns the call result to the client to avoid the participation of the application side and improve security;

[0070] 20. The platform access subsystem sends a fee deduction processing notice to the platform authentication module, including APPID and MSISDN;

[0071] 21. The platform authentication module performs fee deduction processing;

[0072] 22. The platform authentication module returns a fee deduction processing response to the platform access subsystem;

[0073] 23. The platform authentication module sends a bill request to the BOSS, including APPID and MSISDN;

[0074] 24. The BOSS returns the result of deduction to the platform authentication module. During specific operations, the platform authentication module is also used to generate call bills.

[0075] In this embodiment, by verifying the capability call request including the token (ie Token) sent by the client, the security of the capability opening of the Internet platform is improved. At the same time, the client directly sends the capability call request and directly receives the capability call result. , To avoid information leakage caused by application-side operations, and the defects of low security. In addition, the present invention provides a capability invocation system including a client, an application side, and a capability invocation platform side. Through the interaction between the three, the end-to-end security of capability opening is guaranteed.

[0076] Device embodiment one

[0077] Such as image 3 As shown, the embodiment of the capability call request apparatus of the present invention includes:

[0078] The application side 34 is configured to receive a Token acquisition request, generate a Token according to the Token acquisition request, and return the Token;

[0079] The client 32 is configured to send a token acquisition request, receive the token, and generate and send a capability call request including the token.

[0080] The application side 34 may include: an application module 342 for receiving a token acquisition request, and returning feedback information including an application identification APPID, a user identification PID, and a Token to the client; the application identification APPID is the value of the application corresponding to the Token in the application side Identification; the application security module 344 is used to receive the Token acquisition request forwarded by the application module, generate the Token, and return the Token and the application identification APPID to the application module.

[0081] The client 32 may include: a sending module 322, configured to send a token acquisition request to the application module 342; a generating module 324, configured to generate a capability call request including a token, an application identifier, and a user pseudocode identifier, and send it through the sending module 322 The capability call request is sent to the capability call platform; the receiving module 326 is used to receive the Token returned by the application module 342 and directly receive the call result returned by the capability call platform according to the capability call request; the capability module (not shown), the storage capability call platform faces The SDK class library provided by the developer encapsulates the capability resources including location and SMS.

[0082] Device embodiment two

[0083] Such as Figure 4 As shown, the embodiment of the capability call platform of the present invention includes: a verification module 42 (corresponding to the platform security module and the platform authentication module), which is used to verify according to the received capability call request including Token; the call module 46 (corresponding to the platform access Incoming subsystem), used to perform capability call operations after successful verification;

[0084] During specific operations, the capability invocation platform may also include: confirmation module 44 (in specific operations, the platform authentication module can perform the functions of confirmation module 44, such as figure 2 Explanation, an independent confirmation module 44 can also be provided, as in this embodiment), which is used to send confirmation request information to the user terminal corresponding to the user's real identity after the verification is successful, and receive the confirmation response returned by the user terminal; Billing module 48 (In specific operations, the platform security module can perform the functions of the billing module 48, such as figure 2 Explanation, an independent billing module 48 can also be set up, as in this embodiment), which is used to perform the deduction operation after the capability invocation operation is completed, and send a bill request to the BOSS system after the deduction operation is completed, and After receiving the call bill response returned by the BOSS system, the charging module 48 is also used to generate the call bill.

[0085] The verification module 42 may include:

[0086] The verification sub-module 422 (corresponding to the platform security module) is used to query the corresponding application key APPKEY according to the application identification APPID in the capability call request, and use the application key APPKEY to decrypt and verify the Token; the application identification APPID corresponds to the Token The identity of the application;

[0087] The authentication sub-module 424 (corresponding to the platform authentication module) is used to query the user pseudo-code identifier in the capability call request according to the preset correspondence between each user pseudo-code identifier and each user's real identifier after verifying that the Token is valid Corresponding user's real ID, and confirm that the verification is successful when the user's real ID is found.

[0088] The specific explanation is as follows. The calling module 46 is mainly responsible for completing network capability opening and charging control of telecommunications, IMS, Internet, etc., shielding the complexity of the underlying network, and providing a unified WebService/REST interface for various terminal or server applications; The module 422 and the authentication sub-module 424 are the core parts of the capability calling platform. They interact with the capability opening gateway and the platform management subsystem through the internal interface to complete functions such as security control and authentication, and interact with the BOSS system through the external interface to complete billing. Related functions; the verification sub-module 422 is mainly responsible for pseudo-code management, APPKEY management, Token management, identity authentication, application integrity protection, and data security management functions. Among them, identity authentication is mainly responsible for implementing user/ Application and capability invocation platform identity verification; authentication sub-module 424 mainly performs ordering relationship maintenance, ordering relationship synchronization, authentication authentication, user information synchronization, developer information synchronization, product information synchronization, call bill generation, call bill synchronization And billing execution and other functions.

[0089] During specific operations, the verification sub-module 422 may also include a pseudo-code generation unit (not shown), which is used to generate a corresponding pseudo-code generation unit (not shown) according to the user's real identity (such as MSIDSDN) and the application identity APPID after receiving the pseudo-code acquisition request sent by the application side. Code and return the pseudo code to the application side; the verification subunit is used to verify the capability call request after querying the user's real identity (such as MSIDSDN) according to the pseudo code sent by the application side.

[0090] System embodiment

[0091] Such as figure 1 , figure 2 As shown, the embodiment of the capability invoking system of the present invention includes: the application side, which is used to receive the token acquisition request, and generates and returns the token according to the token acquisition request; the client, which is used to send the token acquisition request, receive the token, and generate and merge the token. Send the capability call request including the Token; the capability call platform is used to verify the capability call request, and after the verification is successful, call the capability for the client. The system may also include a BOSS. After the capability invocation is successful, it receives the call bill request sent by the capability invocation platform and returns the deduction result to the capability invocation platform. For the application side and client side in this embodiment, see image 3 Explanation of the ability to call the platform, see Figure 4 Explanation.

[0092] The present invention provides a security architecture including a client, an application side and a capability invocation platform side, and through the interaction between the three, the end-to-end security of capability opening is guaranteed.