Patent Application
20200364715
The following relates to a controlled processing of service requests in an IT-based environment by taking into account a correlation of service requests and financial deposits concerning the respective service requests.
IT-based services are used by many users. Most users have a legitimate interest in using such services, while others harmfully intend to overload such a service, e.g., in order to trigger collapse of such a service. As an example, Denial-of-service (DoS) attacks may be used to overload such an IT-based service due to a huge plurality of requests, which result in an immoderate processing effort.
Various kinds of Denial of Service attacks are known. Generally, an attacker sends multiple service requests to a service provider node to cause overload and prevent the service provider node from processing legitimate service requests. An attacker may improve the efficiency of the attack by creating service requests that require little or limited processing power at the originator but require significant processing power at the service provider node. Alternatively, or additionally, a large count of service requests can be generated and remitted in parallel, e.g., using a plurality of originating nodes. Using Denial of Service attacks, the service provider node can be congested, and overload can be caused. Often, an attacker may use the situation that remitting service requests requires fewer computational resources if compared to processing service requests.
Various techniques are known in order to protect processing of service requests against Denial of Service attacks. For example, additional hardware resources may be provided. This, however, is costly and requires additional administrative work. Thus, scalability is limited and, typically, even large-scale hardware resources can be overloaded when an attack is using a plurality of nodes for remitting service requests.
A further technique implements a service provider node using cloud-based computational resources. Then, in case of a Denial of Service attack, additional hardware resources can be dynamically provisioned to process all service requests. However, also such a technique is costly, in particular where the additional hardware resources are dynamically allocated. Thresholds for additional hardware resources are often required in order to avoid unexpected costs.
A still further technique requires caching-/proxy providers for minimizing the service requests that have to be processed by the service provider node. However, such an approach has limited efficiency if an attacker requests dynamic content. Dynamic content, typically, has to be processed by the service provider node and cannot be remanded to caching-/proxy providers. Furthermore, sometimes an attacker may have knowledge on the address of the service provider node and may therefore transmit service requests directly to the service provider node, thereby circumnavigating any caching-/proxy providers.
WO 2017/145018 A1 discloses a secure method for exchanging entities via a blockchain. Hereby, tokenization techniques and techniques for embedding metadata in a redeem script of a blockchain transaction are included. The method comprises generating a first script, the first script comprising: a first set of metadata associated with a first invitation for the exchange of a first entity by a first user, the first set of metadata comprising an indication of the first entity to be offered for exchange and a first location condition for the exchange, a first user public key (P1A) associated with the first user, wherein the first user public key (P1A) is part of an asymmetric cryptographic pair comprising the first user public key (P1A) and a first user private kev (V1A).
XP055444957 discloses a deposit-based rate-limiting approach that requires a deposit before one is able to login, to facilitate denial of service attacks. After paving, the actual authentication procedure take place, i.e. bv entering a password. Honest users can expect an immediate refund after the login succeeded. In contrast, malicious attempts are not refunded. Such systems reiv on micropavmcnt technologies, such as biockchain-based payment systems that offer the ability to close smart contracts. The system disclosed bv this document also can respect concurrent logins:
Therefore, in order to provide a reliable, customer-oriented IT service, there is a need to control processing of IT-based service requests. Specifically, there is a need of protecting processing of service request against DoS attacks.
An aspect relates to provide a method for processing of service requests in a controlled and reliable manner.
According to an embodiment, a method for processing of service requests by a service provider node is disclosed. The method comprises receiving a first service request, which is remitted by a user. The method further comprises receiving first control data indicative of a first financial deposit, which is remitted by the user, wherein the first control data is referenced to at least one service request. The method further comprises processing the received first service request, if the received first control data is referenced to the received first service request. The method further comprises dispensing a third control data indicative of a third financial deposit to the user in response to receiving the first control data and based on an evaluation of a user criterion, wherein the user criterion includes behaviors of the user, and the method further comprises analyzing the behaviors of the user.
Such an approach is based on the fact that the operational point of time for processing a service request remitted or provided by a user may be controlled using control data related to a financial deposit of the respective service request. The controlled processing of service requests may be admitted when a financial deposit concerning or associated with the respective service request is remitted or executed by the user. Therefore, the method provides reliable services including protection against fraud including Denial of Service attacks. By requesting a financial deposit before processing a service request, Denial of Service attacks can be effectively mitigated service processing is protected by requiring the financial deposit. Additionally, the dispensing of the third control data enables a refund of financial efforts to a user based on the specifications of the respective user. As an example, a refund of financial efforts of a user may be correlated with the legitimacy of a user for performing the service. Financial incenti ves may be provided, which may enable not to misapply such a service, wherein on the other hand. legitimated users may be reimbursed and rnav therefore be able to use the service in a cost-efficient manner.
According to another embodiment, a service provider node adapted to process service requests is disclosed. Hereby, the service provider node comprises a control unit, which is adapted to receive a first service request, which is remit-ted by a user. The control unit is further adapted to receive a first control data indicative of a first financial deposit, which is remitted by the user, wherein the first control data is referenced to at least one service request. The control unit is further adapted to process the received first service request, if the received first control data is referenced to the received first service request. The control unit is further adapted to dispense a third control data indicative of a third financial deposit to the user in response to receive the first control data and based on an evaluation of a user criterion, wherein the user criterion includes behaviors of the user, and the method further comprises analyzing the behaviors of the user.
Such an approach enabl esthe implementation of simple technical means to perform the method outlined above in a reliable manner.
A service request within the meaning of the present disclosure may refer to any user-based inquiry which may intend the provision of a certain service. Such a service may relate to an IT-based service, e.g. a call of a web page sensor control, actuator control, Application Interface (API) access, HTTP GET or POST transactions, etc. The service request may be remitted by a user, i.e. triggered and received from a user.
A service provider node within the meaning of the present disclosure may refer to any device, which is adapted to provide IT based services. The service provider node may be adapted to receive service requests and control data indicative of a financial deposit. The service provider node may also be adapted to provide a financial deposit. The service provider node may also be adapted to dispense control data indicative of a financial deposit. The service provider node may also be adapted to dispense a financial deposit. The service preorder node may be implemented by a server.
A financial deposit within the meaning of the present disclosure may refer to a transaction of any financial value transferred from a first location to a second location or from a first holder to a second holder. The first location and/or the second location may be accessible to a user. The first location and/or the second location may also be accessible to a service provider.
In an embodiment of the method, the method further comprises storing the received first control data, if the received first control data is not referenced to the received first service request. Hence, it is possible that processing of the service request is delayed. In another embodiment of the method, receiving the first service request is performed after receiving the first control data.
Thereby, the method further enables prepayments for services. The method therefore provides for a flexible and user-friendly demand of services with costs.
In another embodiment of the method, receiving the first service request and receiving the first control data is performed simultaneously.
Thereby, since these transactions may be performed in a single shot, the method enables a quick and simple processing of services protected by the financial deposits.
In another embodiment of the method, the method further comprises receiving a second service request, which is remitted by the user. Hereby, the method further comprises receiving a second control data indicative of a second financial deposit, which is remitted by the user, wherein the second control data is referenced to the at least one service request. This method further comprises processing the received second service request, if the received second control data is referenced to the received second service request. Hereby, receiving the second service request and receiving the second control data is performed simultaneously. Further, receiving the first control and the second control data is enabled by a token dispensed from the service provider node to the user in response to a collective financial transfer performed by the user to the service provider node.
Thereby, processing of a plurality of service request may be performed, wherein only a single financial transaction of a user has to be remitted. Thus, the method may reduce efforts dedicated by the user. Therefore, an improved user-friendliness may be achieved.
In another embodiment of the method, the user criterion includes at least one of a) at least one service request remitted by the user, b) at least one login attempt of the user and c) financial resource information of the user.
Based on a), the behavior of the user concerning his requests for using a service may be analyzed in order to check whether such a user may be legitimated to use the respective service. Hereby, the type of request, the point of time of such a request, variances with respect to the type of request as well as time difference in between two request may be analyzed in order to reliably examine the legitimacy of the respective user for using this service.
Based on b), success with respect to login attempts of the respective service may be analyzed in order to reliably examine whether such a user is legitimated for using this service.
Based on c), characteristics of an IT-based wallet of a user may be taken into consideration in order to evaluate whether such a user may be legitimated to use the respective service. Hereby, the amount of financial resources deposited in the wallet, dynamics concerning these financial resources and the time of existence of such a wallet may be taken into account, in order to reliably examine the legitimacy of the respective user for using this service.
In another embodiment of the method, the first control data and the third control data are identical.
Thereby, it may be enabled that a user fulfilling the user criterion may completely be reimbursed from the remitted financial effort. The method may therefore provide for a charge-free service in case that a user is legitimately using the respective service.
In another embodiment of the method, the method further comprises dispensing a fourth control data indicative of a fourth financial deposit to the user in response to receiving the second control data based on an evaluation of at least one user criterion, wherein dispensing the third control data and the fourth control data is performed simultaneously.
Thereby, various reimbursements to a user fulfilling a certain user criterion, e.g. due to his evaluated legitimation for the respective service, may be executed contemporaneously. Thereby, the number of transactions in between the service provider node and the respective use may be reduced; thus an improved efficiency of the method is achieved.
In another embodiment of the method, receiving the first service request and receiving the first control data is enabled by a data transfer using a distributed database.
Thereby, the method is configured more flexibly.
In another embodiment of the method, receiving the first service request and receiving the first control data is enabled by a data transfer using a database based on a distributed ledger technology such as blockchain technology and/or a Directed Acyclic Graph.
IA distributed ledger technology may be characterized by replicated, shared, and/or synchronized digital data that is reproduced at multiple sites. There may be no centralized control.
Using such a decentralized database, data originating from different users may be processed at a high security level.
In another embodiment of the method, the use of the database based on distributed ledger technology includes accessing a Smart Contract service.
Using these means, the processing power of the respective method may be reduced. Thus, an improved efficiency of the respective method may be achieved.
In an embodiment of the method, receiving the first service request and receiving the first control data is enabled by a data transfer using a database based on Directed Acyclic Graph.
Such an approach may e.g. be based on IOTA and may enable fast processing of service requests, in particular in case that service requests are remitted by a large count of users.
In another embodiment of the service provider node, the service provider node is adapted to perform the method according to any of the embodiments outlined above.
Such an approach enables the implementation of simple technical means to perform any of the methods outlined above in a reliable manner.
A token within the meaning of the present disclosure may refer to any data object which is adapted to operate as an agent for supporting an IT-based trading. Such a token may be provided to a user as a trade-off compensating a financial transfer performed by the user. Such a token may enable the operation of IT-based services with costs. The token may also enable a plurality of such operations. The token may include unique checksums.
A collective financial transfer within the meaning of the present disclosure may refer to any single financial transfer, which is operated to achieve a plurality of trade-offs. Such a financial transfer may be IT-based. A user, who intends to use an IT-based service, may perform such a financial transfer.
A distributed database within the meaning of the present disclosure may refer to any database in which storage devices are not all attached to a common processor. Instead, they may be stored in multiple computers, located in the same physical location or may be dispersed over a network of interconnected computers.
The above summary is merely intended to give a short overview over some features of some embodiments and implementations and is not to be construed as limiting. Other embodiments may comprise other features than the ones explained above.
Some of the embodiments will be described in detail, with referenee to the following figures, wherein like designations denote like members, wherein:
In the following, embodiments of the invention will be described in detail with reference to the accompanying drawings. It is to be understood that the following description of embodiments is not to be taken in a limiting sense. The scope of embodiments of the invention is not intended to be limited by the embodiments described hereinafter or by the drawings, which are taken to be illustrative only.
The drawings are to be regarded as being schematic representations and elements illustrated in the drawings, which are not necessarily shown to scale. Rather, the various elements are represented such that their function and general purpose become apparent to a person skilled in the art. Any connection or coupling between functional blocks, devices, components, or other physical or functional units shown in the drawings or described herein may also be implemented by an indirect connection or coupling. A coupling between components may also be established over a wireless connection. Functional blocks may be implemented in hardware, firmware, software, or a combination thereof.
Hereinafter, techniques of processing service requests are described. Specifically, techniques of protecting said processing of the service requests against Denial of Service attacks are described.
According to various embodiments, this involves use of financial deposits—e.g., facilitated by block chain technology, micro-transactions, and/or smart contracts.
It is, e.g., possible to accompany a service request with a financial deposit. Processing of the service requires remittance of the financial deposit. Thereby, illegitimate service requests may be penalized by loss of the financial deposit. Such techniques are based on the finding that, in particular, Denial of Service attacks are typically implemented using a large count of service requests; such that the aggregated financial penalty may effectively prevent the Denial of Service attack. The high security level of distributed ledger technology such as blockchain technology may be used to protect the processing of the service requests.
If a legitimate service request is identified, it would be possible to reimburse any previously remitted financial deposit. A legitimate user can be identified based on behavior, a successful login, variances in the service request or based on a blockchain wallet. For example, it could be determined how long the block chain wallet has been in existence, whether it has a positive balance, etc,. In an example, an analysis of the behavior includes: during use of a service it is recorded which resources have been accessed by the user and what time offsets are between access to the various resources. If, for example, during the entire use of the service the same resources accessed over and over, and there are only a few milliseconds between the different accesses, then there is a large possibility that the use of the resources related to illegitimate service requests triggered, e.g., by an automatic script and not by human behavior.
At 110, the service provider node 2 may receive first control data 5 indicative of a first financial deposit 6, which may be remitted by the user 4. Hereby, the first control data may be referenced to at least one service request 1.
At 120, the service provider node 2 may receive a first service request 1, which may be remitted by the user 4. Hereby, receiving 120 the first service request 1 may be performed after receiving 110 the first control data 5. However, it is also intended that receiving 120 the first service request 1 and receiving 110 the first control data 5 may be performed simultaneously.
At 125, the service provider node 2 may investigate whether the received first control data 5 can be referenced to or associated with the received fist service request 1. Hence, it can be checked if the at last one service request associated with the first control data watches the first service request. For example, checksums or tokes may be determined and compared. Links between the first control data 5 and the first service request may be checked. If the received first control data 5 may be referenced to the received first service request 3, the received first service request 3 may be processed 130 by the service provider node 2. Otherwise, the service provider node 2 may or may not store 135 the received first control data 5.
At 210, the service provider node 2 may receive first control data 5 indicating of a first financial deposit 6, which may be remitted by the user 4. Hereby, the first control data may be referenced to at least one service request 1.
At 220, the service provider node 2 may receive a first service request 3, which may be remitted by the user 4. As can be deduced from
At 225, the service provider node 2 may investigate whether the received first control data 5 can be referenced to the received fist service request 3. If the received first control data 5 can be referenced to the received first service request 3, the received first service request 3 may be processed 230 by the service provider node 2. Otherwise, the service provider node 2 may or may not store 235 the received first control data 5.
At 240, the service provider node 2 may receive 240 a second control data 8 indicative of a second financial deposit 9, which may be remitted by the user 4, wherein the second control data 8 may be referenced to the at least one service request 1. Hereby, receiving 210, 240 the first control data 5 and the second control data 8 may be enabled by a token 10 dispensed from the service provider node 2 to the user 4 in response to a collective financial transfer 11 performed by the user 4 to the service provider node.
At 250, the service provider node 2 may receive 250 a second service request 7, which may be remitted by the user 4. Hereby, receiving 250 the second service request 7 by the service provider node 2 and receiving 240 the second control data 8 by the service provider node 2 may be performed simultaneously.
At 255, the service provider node 2 may investigate whether the received second control data 8 can be referenced to the received second service request 7.
At 260, the received second service request 7 may be selectively processed by the service provider node 2, if the received second control data 8 can be referenced to the received second service request 7.
At 270, the service provider node 2 may dispense a third control data 12 to the user 4. Such a third control data 12 may be indicative of a third financial deposit 13. Hereby, dispensing the third control data 12 may be performed in response to receiving 210 the first control data 5 based on an evaluation of a user criterion. Such a user criterion may include at least one of a) at least one service request 1 remitted by the user 4, b) at least one login attempt of the user 4 and c) financial resource information of the user 4. The first control data 5 and the third control data 12 may be identical: The respective financial deposits may be balanced.
At 280, the service provider node 2 may dispense a fourth control data 14 to the user 4. Hereby, the fourth control data 14 may be indicative of a fourth financial deposit 15. The fourth control data 14 may be dispensed in response to receiving 240 the second control data 8 based on an evaluation of at least one user criterion. Hereby, dispensing 270, 280 the third control data 12 and the fourth control data 14 may be performed simultaneously.
At first, a collective financial transfer 11 may be transferred from the user 4 to the service provider node 2. For trade-off reasons, the service provider node 2 may subsequently transfer a token 10 to the user 4. Such a token 10 may be used by the user 4 to remit first control data 5 for transferring to the service provider node 2, wherein this first control data 5 are indicative of a first financial deposit 6. Simultaneously or subsequently, the user 4 may remit the transfer of a first service request 3 to the service provider node 2.
At first, a collective financial transfer 11 may be transferred from the user 4 to the service provider node 2. For trade-off reasons, the service provider node 2 may subsequently transfer a token 10 to the user 4. Such a token 10 may be used by the user 4 to remit first control data 5 for transferring to the service provider node 2, wherein this first control data 5 are indicative of a first financial deposit 6. Simultaneously, the user 4 may remit the transfer of a first service request 3 to the service provider node 2. Such a token 10 may also be used by the user 4 to remit second control data 8 for transferring to the service provider node 2, wherein this second control data 8 are indicative of a second financial deposit 9. Simultaneously, the user 4 may remit the transfer of a second service request 7 to the service provider node 2. The service provider node 2 may then dispense a third control data 12 indicative of a third financial deposit 13 to the user 4 based on an evaluation of a user criterion as well as a fourth control data 14 indicative of a fourth financial deposit 15 to the user 4 based on an evaluation of at least one user criterion. Hereby, dispensing the third control data 12 and the fourth control data 14 may be performed simultaneously.
Summarizing, above, various techniques of protecting processing of service requests against Denial of Service attacks by requiring accompanying financial deposits have been described. Various examples of implementation are possible.
For example, a user may remit a certain financial deposit within the block chain and, thereby, acquire a token. The token can then be used to remit a number of service requests to the service provider node. If during use of the service the user is identified as being legitimate, the remitted financial deposit can be reimbursed; if, however, the user is identified as being illegitimate, the remitted financial deposit can be locked and not be reimbursed.
In a further example, a user initially transmits the address of a bitcoin wallet to the service provider node. The service provider node can then create a user session being bound to or associated with that address of the wallet. During the user session the user remits prior to or substantially contemporaneously with each service request a financial deposit in the block chain, e.g., a few cents or dollars. The service provider node processes a service only if the respective financial deposit has been remitted and received. If the user is identified as being legitimate, the financial deposit can be reimbursed; or otherwise locked. In such an implementation the available attack vectors for denial of service attacks are effectively reduced to the initial request; the initial request can be implemented resource-efficiently and supported by sufficient computational resources. For avoiding intentional spam for creation of a large count of user sessions having randomized addresses of wallets, a proof can be required from the user that he/she is the legitimate owner of the wallet; such a proof can be implemented using a signed message from the respective address, or otherwise.
In yet a further example, a smart contract is implemented as an interface to the service provider node. A user accesses the service provider node via the smart contract and, for each service request, remits an accompanying financial deposit. Smart contracts enable, by design, to be only executed if a certain accompanying financial deposit has been remitted. Smart contracts are processed and executed from an associated block chain network which is typically in possession of more computational resources if compared to the service provider node or an attacker. The security of the block chain network is based on the fact that no attacker has the possibility to provide more than 50% of the total computational resources.
Thus, the various techniques are based on the finding that it is possible to impose any financial damage caused by a Denial of Service attack on the attacker. Thus, costs at the service provider are avoided. The techniques described herein thus effectively protect processing of service request against Denial of Service attacks. The techniques described herein are easily implemented in the provisioning of a service. It is not required to provide a third-party node. By its underlying design, the techniques described herein are powerful and service continuity is insured. They are transparent, because smart contracts and coin-based financial deposits can be verified by the public and provide a large level of security. For example, any reimbursement of previously remitted financial deposits can be associated with the smart contract such that the claim can be easily enforced by the legitimate user.
Although the present invention has been disclosed in the form of preferred embodiments and variations thereon, it will be understood that numerous additional modifications and variations could be made thereto without departing from the scope of the invention.
For the sake of clarity, it is to be understood that the use of “a” or “an” throughout this application does not exclude a plurality, and “comprising” does not exclude other steps or elements.
| Number | Date | Country | Kind |
|---|---|---|---|
| 17203081.9 | Nov 2017 | EP | regional |
This application claims priority to PCT Application No. PCT/EP2015/078348, having a filing date of Oct. 17, 2018 which is based off of EP Application No. 17203081.9, having a filing date of Nov. 22, 2017, the entire contents both of which are hereby incorporated by reference.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2018/078348 | 10/17/2018 | WO | 00 |
