CN116401650B - Determinant-based API finite state security calling method - Google Patents
Determinant-based API finite state security calling method Download PDFInfo
- Publication number
- CN116401650B CN116401650B CN202310398193.XA CN202310398193A CN116401650B CN 116401650 B CN116401650 B CN 116401650B CN 202310398193 A CN202310398193 A CN 202310398193A CN 116401650 B CN116401650 B CN 116401650B
- Authority
- CN
- China
- Prior art keywords
- api
- state
- client
- key
- request
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 48
- 230000005540 biological transmission Effects 0.000 claims abstract description 21
- 230000008569 process Effects 0.000 claims abstract description 21
- 239000008186 active pharmaceutical agent Substances 0.000 claims description 305
- 230000004044 response Effects 0.000 claims description 48
- 238000002360 preparation method Methods 0.000 claims description 16
- 238000012545 processing Methods 0.000 claims description 13
- 239000000284 extract Substances 0.000 claims description 8
- 230000000977 initiatory effect Effects 0.000 claims description 4
- 238000010586 diagram Methods 0.000 description 10
- 238000013461 design Methods 0.000 description 6
- 238000004891 communication Methods 0.000 description 3
- 238000007792 addition Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
- G06F21/44—Program or device authentication
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Computer Hardware Design (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Communication Control (AREA)
Abstract
The invention discloses an API finite state safety calling method based on determinant, which comprises a client and an API, and comprises the following steps: defining a refined client call API framework, which comprises a plurality of step flows; step two, defining different finite states of the client and the API according to the step flow in the process of calling the API by the client; step three, designing data packets with different formats under different finite states; step four, designing a determinant-based secure transmission mode of an identity identifier (API_Key), so that an attacker cannot directly intercept the API_Key information issued by the API in the process of calling the API by a client, and ensuring the process safety; step five, the client acquires the specific value of the API_Key by calculating the information of the API_Key, so that the API call is successfully realized; according to the invention, determinant call is carried out between the set client and the API, so that the flow of the API call is standardized, and the safety transmission and transmission performance of the API_Key in the API call process are ensured.
Description
Technical Field
The invention relates to the technical field of API safe call, in particular to an API finite state safe call method based on determinant.
Background
An API is a set of programming instructions and criteria for accessing web-based software applications or web tools, simply a way for different software programs to communicate with each other. A developer may use the API to access a pre-existing set of functionality provided through the web-based interface. Because the API is generally subjected to security treatment, if an open API interface is not subjected to security treatment, three types of security problems can easily occur, including information interception, tampering and leakage, and in order to ensure the secure use of the API, the existing API can be prevented and blocked by using asymmetric encryption, MD5 digest and token mechanism; and the Eolinker Api testing tool is used for encrypting the API interface information, so that the interface call is safer and more reliable.
The existing API calling application programs are diversified, so that the calling flow patterns of the APIs are changeable and complicated, and the problem of safe use caused by code errors in the calling process of more APIs is also caused; however, how to ensure the specification of the API call flow and the security of the call process is an important issue in current research.
Disclosure of Invention
The invention aims to provide an API finite state safety calling method based on determinant, which solves the following technical problems:
how to ensure the flow of the standard API call and ensure the safe transmission and transmission performance of the API_Key in the API call process.
The aim of the invention can be achieved by the following technical scheme:
a determinant-based API finite state secure call method, comprising a client and an API, the method comprising:
defining a refined client call API framework, which comprises a plurality of step flows;
step two, defining different finite states of the client and the API according to the step flow in the process of calling the API by the client;
step three, designing data packets with different formats under different finite states;
designing a determinant-based secure transmission mode of an identity identifier (API_Key), ensuring that an attacker cannot directly intercept API_Key information issued by an API in the process of calling the API by a client, and ensuring the security of the transmission process;
and fifthly, the client acquires the specific value of the API_Key by calculating the information of the API_Key, so that the API call is successfully realized.
Preferably, the steps of calling the API framework in the step one are as follows:
s1, selecting an API: selecting, by the client, an appropriate API for the desired function for its application;
s2, acquiring an API_Key: acquiring an API_Key from a server API library by using a client;
s3, initiating API request setting: creating an API request according to the client, wherein the API request comprises required functions and any necessary parameter information, and sending the created API request to a server of an API provider;
s4, receiving an API response: processing the API request by a server of the API provider and sending a response back to the client;
wherein the response may include the requested data, and may include an error message if the request was not successful;
s5, analyzing API response: the client analyzes the API response and extracts relevant information from the API response;
s6, processing API response: finally, based on the API response, the client can perform any subsequent operations required by its application, including: such as displaying information to the user, storing data, or triggering further API requests.
Preferably, each of the six finite states of the API in the second step is specifically designed as follows:
sleep state: this state indicates that the API interface is idle and no request is processed;
an active state: when the API interface is in a Sleep state, the API interface receives an API-Request packet sent by the client, the API interface state is changed from the Sleep state to an active state, and the API interface verifies whether the API has the function requirement of the client;
feed back_request state: when the API interface is in an active state, if the API library has the function of the client side and requires the API interface, the API interface state is changed from the active state to a feed back_requests state, and a content package is returned to the client side; if the API library does not have the function of the client side for requiring the API interface, the state of the API interface is changed from an active state to a Sleep state, and a Stop packet is returned to the client side;
send_key state: when the API interface is in a feed back_request state, the API interface receives a client_Info packet sent by a Client, and at the moment, the API interface state is changed from the feed back_request state to a send_Key state, and a function API interface and authority are distributed for the Client;
send_response state: when the API interface is in a send_Key state, a request_Info packet sent by a client is received, the API interface state is changed from the send_Key state to a send_response state, a Response is made to a client Request, and an Offer_result packet is sent to the client;
end state: when the API interface is in a send_response state, a request result returns to the client to finish, the state of the API interface is changed from the send_response state to an End state, and the processing of the API interface request is finished;
in the fifth step, the determinant-based API secure call method is calculated as follows:
issuing the client API_Key by using a determinant, and randomly generating a determinant of (n+1) x n according to the length n of the API_Key;
an API_Key field of a randomly produced determinant in an Offer_result packet is placed through an API and is issued to a client;
the client calculates determinant according to determinant theorem to obtain original API_Key and realize secret transmission of the API_Key;
the client in the second step includes six finite states: an Init state, a preparation state, a get_key state, a send_info state, a get_result state and an End state; in the second step, the API includes six finite states: a Sleep state, an active state, a feed back_request state, a send_key state, a send_response state, and an End state.
Preferably, in the third step, the specific formats of the different data packets are as follows:
api_request packet: packet type-definition 01 representation, API address, client function requirements list;
a content packet: package type-definition 02, client address, API-implementable function, feedback function call result, expressed in percentage;
stop packet: packet type-definition 03 representation, API address, client address, feedback function call result, API state description;
client_info package: packet type-definition 04 indicates, client address, client information, including client throughput specific feature information, client state, indicate old user with 0, 1 indicates new user;
verify_info packet: packet type-definition 05 representation, client address, identity verifier, data represented in determinant, client rights;
request_info packet: packet type-definition 06 represents, API address, identity verifier, data represented in determinant, specific request content;
the offer_result packet: packet type-definition 06 means, client address, client rights, request response result.
Preferably, each of the six finite states of the client is specifically designed as follows:
the Init state: the client is in an initial state, and in the initial state, the client prepares to send an API-Request packet;
prepore state: when the client is in the Init state, if the client receives a continuous packet returned by the API interface, the client indicates that the current server API library can meet the functions required by the client, and the client state is changed from the Init state to the preparation state; if the client receives a Stop packet returned by the API interface, the client indicates that the current server API library cannot provide the client with the required functions, and the client keeps the Init state;
get_key state: when the Client is in the preparation state, sending a client_Info packet to the API interface, and changing the Client state from the preparation state to the get_Key state;
send_info state: when the client is in the get_Key state, the client receives a verify_Info packet returned by an API interface, if the packet contains the API_Key issued from an API library, the client state is changed from the get_Key state to the Send_Info state, a request_Info packet is sent, a task Request is initiated, and otherwise, the client keeps the get_Key state;
get_result state: when the client is in the send_info state and receives an offer_result packet returned by the API interface, the client state is changed from the send_info state to the get_result state, and the client analyzes the API response and extracts relevant information from the API response;
end state: when the client is in the get_result state, the client executes any subsequent operation required by the application program of the client, and the client state is changed from the get_result state to the End state, and the request is ended; or trigger a further API request when the client state changes from End state to send_info state.
Preferably, the determinant theorem is: any constant K multiplied by the determinant is equal to the constant multiplied by a certain row or column of the determinant.
The invention has the beneficial effects that:
according to the method, through the multiple step processes of designing the API call in a standard manner, the communication burden of the client and the API is reduced; in the API calling process, the client side API_Key is transmitted in an plaintext manner, so that the process safety of the API calling is ensured; by designing the API safe calling method based on determinant, complicated data processing operation is avoided, and complexity and performance loss of client calling are reduced.
Of course, it is not necessary for any one product to practice the invention to achieve all of the advantages set forth above at the same time.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings that are needed for the description of the embodiments will be briefly described below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a schematic diagram of a determinant-based API finite state safety call method according to the present invention;
FIG. 2 is a flowchart illustrating steps for a client to invoke an API framework according to the present invention;
FIG. 3 is a flow chart of an overall method for finite state safety call of an API based on determinant in the present invention;
FIG. 4 is a schematic diagram of a client state according to the present invention;
FIG. 5 is a schematic diagram of the state of the API of the present invention;
FIG. 6 is a diagram of the format of an API_Request packet according to the present invention;
FIG. 7 is a diagram of a continuous packet format according to the present invention;
FIG. 8 is a schematic diagram of a Stop packet format according to the present invention;
FIG. 9 is a diagram showing the client_Info packet format according to the present invention;
FIG. 10 is a diagram showing the format of a VerifyInfo packet according to the present invention;
FIG. 11 is a diagram showing the format of a Request_Info packet according to the present invention;
fig. 12 is a diagram illustrating an Offer-result packet format according to the present invention.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
Referring to fig. 1, the present invention is a determinant-based API finite state secure call method, including a client and an API, the method including:
defining a refined client call API framework, which comprises a plurality of step flows;
step two, defining different finite states of the client and the API according to the step flow in the process of calling the API by the client;
step three, designing data packets with different formats under different finite states;
designing a determinant-based secure transmission mode of an identity identifier (API_Key), ensuring that an attacker cannot directly intercept API_Key information issued by an API in the process of calling the API by a client, and ensuring the security of the transmission process;
and fifthly, the client acquires the specific value of the API_Key by calculating the information of the API_Key, so that the API call is successfully realized.
Through the technical scheme: the existing API calling application programs are diversified, so that the calling flow patterns of the APIs are changeable and complicated, and the problem of safe use caused by code errors in the calling process of more APIs is also caused; in order to solve the problems, the invention designs a determinant API finite state safe calling method, and the specific steps of realizing the method by setting a client and an API are as follows: firstly, defining a refined client call API framework, which comprises a plurality of step flows; secondly, defining different finite states according to the step flow in the process of calling the API by the client; in addition, under different finite states, data packets with different formats are designed; then, a determinant-based secure transmission mode of an identity verifier (API_Key) is designed, so that an attacker cannot directly intercept API_Key information issued by an API in the process of calling the API by a client, and the security of the API calling process is ensured by the non-plaintext transmission mode; finally, the client side obtains the specific value of the API_Key through calculation, and successfully realizes the calling flow of the API; the complex data processing operation is avoided by the determinant identity identifier (API_Key) secure transmission mode, and the complexity and the performance loss of the client call are reduced.
As an embodiment of the present invention, please refer to fig. 2-3 of the accompanying drawings, specifically, a plurality of step flows for calling an API framework in the step one are designed as follows:
s1, selecting an API: selecting, by the client, an appropriate API for the desired function for its application;
s2, acquiring an API_Key: acquiring an API_Key from a server API library by using a client;
s3, initiating API request setting: creating an API request according to the client, wherein the API request comprises required functions and any necessary parameter information, and sending the created API request to a server of an API provider;
s4, receiving an API response: processing the API request by a server of the API provider and sending a response back to the client;
wherein the response may include the requested data, and may include an error message if the request was not successful;
s5, analyzing API response: the client analyzes the API response and extracts relevant information from the API response;
s6, processing API response: finally, based on the API response, the client can perform any subsequent operations required by its application, including: such as displaying information to the user, storing data, or triggering further API requests.
Through the technical scheme: according to the step flow in the step I, calling the API framework by using the client, the specific steps are designed as follows: s1, selecting an API: the client needs to select the appropriate API that provides the required functionality for its application; s2, acquiring an API_Key: the client needs to obtain the api_key from the server API library. It should be noted that the api_key is a unique identifier that can help authenticate a client's request and grant access to API features, which are obtained according to the prior art; s3, initiating API request setting: the client needs to create an API request which comprises the required functions and any necessary parameter information, and sends the created API request to a server of an API provider; s4, receiving an API response: the server of the API provider processes the API request and sends a response back to the client. The response may include the requested data, and may include an error message if the request was not successful; s5, analyzing API response: the client analyzes the API response and extracts relevant information from the API response; s6, processing API response: finally, based on the API response, the client may perform any subsequent operations required by its application, such as displaying information to the user, storing data, or triggering further API requests; and through a plurality of step flows of the standard design API call, the communication burden of the client and the API is reduced.
As an embodiment of the present invention, please refer to fig. 4-5 of the accompanying drawings, specifically, the client in the second step includes six finite states: an Init state, a preparation state, a get_key state, a send_info state, a get_result state and an End state; in step two, the API includes six finite states: a Sleep state, an active state, a feed back_request state, a send_key state, a send_response state, and an End state.
The invention designs the corresponding data packet according to the mutual connection between the states by respectively setting six states of the client and six states of the API, wherein the six states of the client comprise: an Init state, a preparation state, a get_key state, a send_info state, a get_result state and an End state; the six states of the API include: a Sleep state, an active state, a feed back_request state, a send_key state, a send_response state, and an End state.
As an embodiment of the present invention, please refer to fig. 6-12 of the accompanying drawings, specifically, the specific formats of the different data packets in the third step are as follows:
api_request packet: packet type-definition 01 representation, API address, client function requirements list;
a content packet: package type-definition 02, client address, API-implementable function, feedback function call result, expressed in percentage;
stop packet: packet type-definition 03 representation, API address, client address, feedback function call result, API state description;
client_info package: packet type-definition 04 indicates, client address, client information, including client throughput specific feature information, client state, indicate old user with 0, 1 indicates new user;
verify_info packet: packet type-definition 05 representation, client address, identity verifier, data represented in determinant, client rights;
request_info packet: packet type-definition 06 represents, API address, identity verifier, data represented in determinant, specific request content;
the offer_result packet: packet type-definition 06 means, client address, client rights, request response result.
Through the technical scheme: the data packet sent by the invention under different states comprises: API_Request packet, continue packet, stop packet, client_Info packet, verifyInfo packet, request_Info packet, and Offer_Result packet; the specific format design content comprises: api_request packet: packet type-definition 01 representation, API address, client function requirements list; a content packet: package type-definition 02, client address, API-implementable function, feedback function call result, expressed in percentage; stop packet: packet type-definition 03 representation, API address, client address, feedback function call result, API state description; client_info package: packet type-definition 04 indicates, client address, client information, including client throughput specific feature information, client state, indicate old user with 0, 1 indicates new user; verify_info packet: packet type-definition 05 representation, client address, identity verifier, data represented in determinant, client rights; request_info packet: packet type-definition 06 represents, API address, identity verifier, data represented in determinant, specific request content; the offer_result packet: packet type-definition 06 means, client address, client rights, request response result.
As an embodiment of the present invention, please refer to fig. 3 and 4 of the accompanying drawings, specifically, each of six finite states of the client is specifically designed as follows:
the Init state: the client is in an initial state, and in the initial state, the client prepares to send an API-Request packet;
prepore state: when the client is in the Init state, if the client receives a continuous packet returned by the API interface, the client indicates that the current server API library can meet the functions required by the client, and the client state is changed from the Init state to the preparation state; if the client receives a Stop packet returned by the API interface, the client indicates that the current server API library cannot provide the client with the required functions, and the client keeps the Init state;
get_key state: when the Client is in the preparation state, sending a client_Info packet to the API interface, and changing the Client state from the preparation state to the get_Key state;
send_info state: when the client is in the get_Key state, the client receives a verify_Info packet returned by an API interface, if the packet contains the API_Key issued from an API library, the client state is changed from the get_Key state to the Send_Info state, a request_Info packet is sent, a task Request is initiated, and otherwise, the client keeps the get_Key state;
get_result state: when the client is in the send_info state and receives an offer_result packet returned by the API interface, the client state is changed from the send_info state to the get_result state, and the client analyzes the API response and extracts relevant information from the API response;
end state: when the client is in the get_result state, the client executes any subsequent operation required by the application program of the client, and the client state is changed from the get_result state to the End state, and the request is ended; or trigger a further API request when the client state changes from End state to send_info state.
Through the technical scheme: analyzing according to six states of the client, and combining with the data packet in the corresponding state to realize data transmission fluency; the specific state design sequentially comprises the following steps: the Init state: the client is in an initial state, and in the initial state, the client prepares to send an API-Request packet; prepore state: when the client is in the Init state, if the client receives a continuous packet returned by the API interface, the client indicates that the current server API library can meet the functions required by the client, and the client state is changed from the Init state to the preparation state; if the client receives a Stop packet returned by the API interface, the client indicates that the current server API library cannot provide the client with the required functions, and the client keeps the Init state; get_key state: when the Client is in the preparation state, sending a client_Info packet to the API interface, and changing the Client state from the preparation state to the get_Key state; send_info state: when the client is in the get_Key state, the client receives a verify_Info packet returned by an API interface, if the packet contains the API_Key issued from an API library, the client state is changed from the get_Key state to the Send_Info state, a request_Info packet is sent, a task Request is initiated, and otherwise, the client keeps the get_Key state; get_result state: when the client is in the send_info state and receives an offer_result packet returned by the API interface, the client state is changed from the send_info state to the get_result state, and the client analyzes the API response and extracts relevant information from the API response; end state: when the client is in get_result state, the client performs any subsequent operations required by its application (e.g. displaying information to the user, storing data), at which time the client state changes from get_result state to End state, this request ends; or trigger a further API request when the client state changes from End state to send_info state.
As an embodiment of the present invention, please refer to fig. 3 and 5, specifically, each of six finite states of the API in the second step is specifically designed as follows:
sleep state: this state indicates that the API interface is idle and no request is processed;
an active state: when the API interface is in a Sleep state, the API interface receives an API-Request packet sent by the client, the API interface state is changed from the Sleep state to an active state, and the API interface verifies whether the API has the function requirement of the client;
feed back_request state: when the API interface is in an active state, if the API library has the function of the client side and requires the API interface, the API interface state is changed from the active state to a feed back_requests state, and a content package is returned to the client side; if the API library does not have the function of the client side for requiring the API interface, the state of the API interface is changed from an active state to a Sleep state, and a Stop packet is returned to the client side;
send_key state: when the API interface is in a feed back_request state, the API interface receives a client_Info packet sent by a Client, and at the moment, the API interface state is changed from the feed back_request state to a send_Key state, and a function API interface and authority are distributed for the Client;
send_response state: when the API interface is in a send_Key state, a request_Info packet sent by a client is received, the API interface state is changed from the send_Key state to a send_response state, a Response is made to a client Request, and an Offer_result packet is sent to the client;
end state: when the API interface is in the Send_response state, the request result returns to the client to finish, the state of the API interface is changed from the Send_response state to the End state, and the processing of the API interface request is finished.
Through the technical scheme: in order to ensure smooth output of data packets in different states, six finite states of the API are set, and specific designs include: sleep state: this state indicates that the API interface is idle and no request is processed; an active state: when the API interface is in a Sleep state, the API interface receives an API-Request packet sent by the client, the API interface state is changed from the Sleep state to an active state, and the API interface verifies whether the API has the function requirement of the client; feed back_request state: when the API interface is in an active state, if the API library has the function of the client side and requires the API interface, the API interface state is changed from the active state to a feed back_requests state, and a content package is returned to the client side; if the API library does not have the function of the client side for requiring the API interface, the state of the API interface is changed from an active state to a Sleep state, and a Stop packet is returned to the client side; send_key state: when the API interface is in a feed back_request state, the API interface receives a client_Info packet sent by a Client, and at the moment, the API interface state is changed from the feed back_request state to a send_Key state, and a function API interface and authority are distributed for the Client; send_response state: when the API interface is in a send_Key state, a request_Info packet sent by a client is received, the API interface state is changed from the send_Key state to a send_response state, a Response is made to a client Request, and an Offer_result packet is sent to the client; end state: when the API interface is in the Send_response state, the request result returns to the client to finish, the state of the API interface is changed from the Send_response state to the End state, and the processing of the API interface request is finished.
As an embodiment of the present invention, specifically, the API secure call method based on determinant in the fifth step is calculated as follows:
issuing the client API_Key by using a determinant, and randomly generating a determinant of (n+1) x n according to the length n of the API_Key;
an API_Key field of a randomly produced determinant in an Offer_result packet is placed through an API and is issued to a client;
and the client calculates the determinant according to the determinant theorem, so that the original API_Key can be obtained, and secret transmission of the API_Key is realized.
As an embodiment of the present invention, the determinant theorem is specifically: any constant K is multiplied by a determinant, and is equal to the constant multiplied by a certain row or a certain column of the determinant, wherein secret transmission of the API_Key is realized through the determinant theorem; for example: if the API_Key is (5, 3), then the determinant may be randomly generatedMultiplying constant 5 by the first column and constant 3 by the second column to obtain the packaged API_Key as +.>The API puts the two determinant into the API_Key field in the Offer_result packet and sends the two determinant to the client, and the client calculates the two determinant, thus obtaining the original API_Key (5, 3).
The whole technical scheme is as follows: the method standardizes the step flow of calling the API interface by the client, avoids plaintext transmission in the transmission process of the API_Key, ensures communication safety, is simple and feasible, avoids complex operation of the traditional data protection method, and reduces the complexity and performance loss of calling the client.
The foregoing is merely illustrative and explanatory of the principles of the invention, as various modifications and additions may be made to the specific embodiments described, or similar thereto, by those skilled in the art, without departing from the principles of the invention or beyond the scope of the appended claims.
Claims (6)
1. A determinant-based API finite state secure call method, comprising a client and an API, the method comprising:
defining a refined client call API framework, which comprises a plurality of step flows;
step two, defining different finite states of the client and the API according to the step flow in the process of calling the API by the client;
step three, designing data packets with different formats under different finite states;
designing a determinant-based secure transmission mode of an identity identifier (API_Key), ensuring that an attacker cannot directly intercept API_Key information issued by an API in the process of calling the API by a client, and ensuring the security of the transmission process;
step five, the client acquires the specific value of the API_Key by calculating the information of the API_Key, so that the API call is successfully realized;
each of the six finite states of the API in the second step is specifically designed as follows:
sleep state: this state indicates that the API interface is idle and no request is processed;
an active state: when the API interface is in a Sleep state, the API interface receives an API-Request packet sent by the client, the API interface state is changed from the Sleep state to an active state, and the API interface verifies whether the API has the function requirement of the client;
feed back_request state: when the API interface is in an active state, if the API library has the function of the client side and requires the API interface, the API interface state is changed from the active state to a feed back_requests state, and a content package is returned to the client side; if the API library does not have the function of the client side for requiring the API interface, the state of the API interface is changed from an active state to a Sleep state, and a Stop packet is returned to the client side;
send_key state: when the API interface is in a feed back_request state, the API interface receives a client_Info packet sent by a Client, and at the moment, the API interface state is changed from the feed back_request state to a send_Key state, and a function API interface and authority are distributed for the Client;
send_response state: when the API interface is in a send_Key state, a request_Info packet sent by a client is received, the API interface state is changed from the send_Key state to a send_response state, a Response is made to a client Request, and an Offer_result packet is sent to the client;
end state: when the API interface is in a send_response state, a request result returns to the client to finish, the state of the API interface is changed from the send_response state to an End state, and the processing of the API interface request is finished;
in the fifth step, the determinant-based API secure call method is calculated as follows:
issuing the client API_Key by using a determinant, and randomly generating a determinant of (n+1) x n according to the length n of the API_Key;
an API_Key field of a randomly produced determinant in an Offer_result packet is placed through an API and is issued to a client;
and the client calculates the determinant according to the determinant theorem, so that the original API_Key can be obtained, and secret transmission of the API_Key is realized.
2. The determinant-based API finite state security call method as claimed in claim 1, wherein the steps of calling the API framework in step one are as follows:
s1, selecting an API: selecting, by the client, an appropriate API for the desired function for its application;
s2, acquiring an API_Key: acquiring an API_Key from a server API library by using a client;
s3, initiating API request setting: creating an API request according to the client, wherein the API request comprises required functions and any necessary parameter information, and sending the created API request to a server of an API provider;
s4, receiving an API response: processing the API request by a server of the API provider and sending a response back to the client;
wherein the response may include the requested data, and may include an error message if the request was not successful;
s5, analyzing API response: the client analyzes the API response and extracts relevant information from the API response;
s6, processing API response: finally, based on the API response, the client can perform any subsequent operations required by its application, including: such as displaying information to the user, storing data, or triggering further API requests.
3. The determinant-based API finite state security call method according to claim 1, wherein said step two client comprises six finite states: an Init state, a preparation state, a get_key state, a send_info state, a get_result state and an End state; in the second step, the API includes six finite states: a Sleep state, an active state, a feed back_request state, a send_key state, a send_response state, and an End state.
4. The method for safely calling finite state of APIs based on determinant according to claim 1, wherein the specific formats of different data packets in the third step are as follows:
api_request packet: packet type-definition 01 representation, API address, client function requirements list;
a content packet: package type-definition 02, client address, API-implementable function, feedback function call result, expressed in percentage;
stop packet: packet type-definition 03 representation, API address, client address, feedback function call result, API state description;
client_info package: packet type-definition 04 indicates, client address, client information, including client throughput specific feature information, client state, indicate old user with 0, 1 indicates new user;
verify_info packet: packet type-definition 05 representation, client address, identity verifier, data represented in determinant, client rights;
request_info packet: packet type-definition 06 represents, API address, identity verifier, data represented in determinant, specific request content;
the offer_result packet: packet type-definition 06 means, client address, client rights, request response result.
5. A determinant-based API finite state security call method in accordance with claim 3, wherein each of said six finite states of said client is specifically designed as follows:
the Init state: the client is in an initial state, and in the initial state, the client prepares to send an API-Request packet;
prepore state: when the client is in the Init state, if the client receives a continuous packet returned by the API interface, the client indicates that the current server API library can meet the functions required by the client, and the client state is changed from the Init state to the preparation state; if the client receives a Stop packet returned by the API interface, the client indicates that the current server API library cannot provide the client with the required functions, and the client keeps the Init state;
get_key state: when the Client is in the preparation state, sending a client_Info packet to the API interface, and changing the Client state from the preparation state to the get_Key state;
send_info state: when the client is in the get_Key state, the client receives a verify_Info packet returned by an API interface, if the packet contains the API_Key issued from an API library, the client state is changed from the get_Key state to the Send_Info state, a request_Info packet is sent, a task Request is initiated, and otherwise, the client keeps the get_Key state;
get_result state: when the client is in the send_info state and receives an offer_result packet returned by the API interface, the client state is changed from the send_info state to the get_result state, and the client analyzes the API response and extracts relevant information from the API response;
end state: when the client is in the get_result state, the client executes any subsequent operation required by the application program of the client, and the client state is changed from the get_result state to the End state, and the request is ended; or trigger a further API request when the client state changes from End state to send_info state.
6. The determinant-based API finite state security call method of claim 1, wherein said determinant theorem is: any constant K multiplied by the determinant is equal to the constant multiplied by a certain row or column of the determinant.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310398193.XA CN116401650B (en) | 2023-04-14 | 2023-04-14 | Determinant-based API finite state security calling method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310398193.XA CN116401650B (en) | 2023-04-14 | 2023-04-14 | Determinant-based API finite state security calling method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN116401650A CN116401650A (en) | 2023-07-07 |
| CN116401650B true CN116401650B (en) | 2023-11-14 |
Family
ID=87010196
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310398193.XA Active CN116401650B (en) | 2023-04-14 | 2023-04-14 | Determinant-based API finite state security calling method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116401650B (en) |
Families Citing this family (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116805912B (en) * | 2023-08-21 | 2023-12-19 | 徐州医科大学 | College educational administration system data transmission and storage method based on angle mapping |
| CN116781244B (en) * | 2023-08-21 | 2023-10-27 | 徐州医科大学 | MNSS platform data privacy and management method based on cosine chaos |
| CN117040934B (en) * | 2023-10-09 | 2023-12-22 | 徐州医科大学 | College VPN user identity security re-verification method based on geometric mapping |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107872484A (en) * | 2016-09-27 | 2018-04-03 | 中国电信股份有限公司 | REST API fast registration methods, devices and systems |
| CN108471432A (en) * | 2018-07-11 | 2018-08-31 | 北京智芯微电子科技有限公司 | Prevent web application interface by the method for malicious attack |
| CN108768622A (en) * | 2018-03-30 | 2018-11-06 | 国网河南省电力公司新乡供电公司 | The safely outsourced calculating encryption method of matrix determinant in a kind of cloud computing |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103220259B (en) * | 2012-01-20 | 2016-06-08 | 华为技术有限公司 | The use of Oauth API, call method, equipment and system |
| EP3937450A1 (en) * | 2020-07-07 | 2022-01-12 | Curity AB | A login and consent methodology that follows rest principles and uses the oauth protocol with attested clients |
-
2023
- 2023-04-14 CN CN202310398193.XA patent/CN116401650B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107872484A (en) * | 2016-09-27 | 2018-04-03 | 中国电信股份有限公司 | REST API fast registration methods, devices and systems |
| CN108768622A (en) * | 2018-03-30 | 2018-11-06 | 国网河南省电力公司新乡供电公司 | The safely outsourced calculating encryption method of matrix determinant in a kind of cloud computing |
| CN108471432A (en) * | 2018-07-11 | 2018-08-31 | 北京智芯微电子科技有限公司 | Prevent web application interface by the method for malicious attack |
Non-Patent Citations (2)
| Title |
|---|
| A Novel Embedded Platform for Secure and Privacy-Concerned Cross-Domain Service Access;Alexander Rech et al.;《2019 IEEE Intelligent Vehicles Symposium (IV)》;全文 * |
| 一种形式化的可信平台模块应用编程接口安全性分析方法;杨;张焕国;张帆;徐士伟;;武汉大学学报(理学版)(第04期);全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN116401650A (en) | 2023-07-07 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN116401650B (en) | Determinant-based API finite state security calling method | |
| US10382426B2 (en) | Authentication context transfer for accessing computing resources via single sign-on with single use access tokens | |
| US9654462B2 (en) | Late binding authentication | |
| US6785729B1 (en) | System and method for authorizing a network user as entitled to access a computing node wherein authenticated certificate received from the user is mapped into the user identification and the user is presented with the opprtunity to logon to the computing node only after the verification is successful | |
| CN108494740A (en) | Token generates and method of calibration, intelligent terminal and server | |
| WO2000079432A1 (en) | Enhanced security for applications employing downloadable executable content | |
| US8429676B2 (en) | Integrated trading platform architecture | |
| CN113704210A (en) | Data sharing method and electronic equipment | |
| EP4049154A1 (en) | Private password constraint validation | |
| WO2021137769A1 (en) | Method and apparatus for sending and verifying request, and device thereof | |
| CN113746719A (en) | Task information processing method and device, electronic equipment and storage medium | |
| EP3937450A1 (en) | A login and consent methodology that follows rest principles and uses the oauth protocol with attested clients | |
| CN115396443B (en) | Time factor-based alliance chain consensus method, device, equipment and storage medium | |
| Gajek et al. | Provably secure browser-based user-aware mutual authentication over TLS | |
| CN113779522B (en) | Authorization processing method, device, equipment and storage medium | |
| CN112994882B (en) | Authentication method, device, medium and equipment based on block chain | |
| EP1168763B1 (en) | Systems and methods for delegated digest access authorization | |
| CN114238925A (en) | Aggregation authentication method of non-mutual trust heterogeneous system based on JWT token | |
| KR100835260B1 (en) | Internet-banking controll method | |
| CN113364821A (en) | Functional service access method, device and storage medium | |
| CN110166452A (en) | A kind of access control method and system based on JavaCard shared interface | |
| CA2403383C (en) | System, method and computer program product for providing unified authentication services for online applications | |
| JP2004355471A (en) | Method for preventing unauthorized access | |
| KR102628775B1 (en) | Cloud HSM system for accessing token based on certificates and ID and method thereof | |
| Rahaeimehr et al. | Recursive Augmented Fernet (RAF) Token: Alleviating the Pain of Stolen Tokens |
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 |