CN114567669A

CN114567669A - Credible SOA architecture based on block chain

Info

Publication number: CN114567669A
Application number: CN202210223222.4A
Authority: CN
Inventors: 陈星�; 蒋腾聪; 陈艳
Original assignee: Fuzhou University
Current assignee: Fuzhou University
Priority date: 2022-03-09
Filing date: 2022-03-09
Publication date: 2022-05-31
Anticipated expiration: 2042-03-09
Also published as: CN114567669B

Abstract

The invention provides a credible SOA architecture based on a block chain, wherein in the architecture, the block chain is introduced as a service registration agent and an evidence recorder, and the service provider agent and the service consumer agent are provided to ensure that the processes of service registration, discovery, calling and execution are automatic and credible; for a given Web Service, a Service provider agent converts the Web Service into a Trusted Service description model Trusted Service supporting a Trusted SOA; the Service consumer proxy shields the difference between different Service description models, so that the Service consumer can use the Trusted Service description model in the original mode; by applying the technical scheme, the service dispute between the service provider and the requester can be effectively processed in the specified trusted calling time regardless of independent malicious behaviors or compound malicious behaviors.

Description

Credible SOA architecture based on block chain

Technical Field

The invention relates to the technical field of Web services, in particular to a block chain-based trusted SOA architecture.

Background

With the development of internet technology, various Web services emerge, thereby facilitating the use of internet IT personnel and irrelevant personnel. Currently, the mainstream Web services include mailbox verification, weather, zip code, flight inquiry, and the like. However, the increasing amount of Web Service causes the amount of information on the internet to be increasingly large and diversified, which not only imposes a great burden on a user to search for a desired Service, but also reduces the burden on a Service provider. In order to maintain a loosely coupled relationship between Web services and Service consumers, SOAs have been developed. SOA is considered a service-oriented architecture for developing, designing, deploying and managing services. The traditional SOA mainly contains 3 core roles of registry, service provider and service consumer and 3 basic operations of service registration, service discovery and service invocation. The process of the service consumer to make one service call is as follows: the service provider firstly releases the service description to the registry; then the service consumer sends a service request to the registry, the registry discovers the service according to the service request and feeds back the target service description to the service consumer; and finally, the service consumer determines a service provider according to the target service and directly initiates service calling to the service provider. The registry not only reduces the burden on the service provider, but also facilitates the search for the target service, thereby enabling the service consumer to maintain a dynamically invoked relationship with the service.

However, in an untrusted distributed scenario, such a service provisioning scheme is facing new trust challenges. Untrusted service providers may offer unqualified or even malicious services, while dishonest customers may maliciously refuse to accept the correct service for their own benefit, even \ 35820; "trap service providers. The lack of an effective non-repudiation dispute resolution mechanism means that the trustworthiness of the services of these two parties that are not trusted to each other is not guaranteed. The dispute resolution mechanisms that have been proposed so far fall into two main categories: trusted third party based and non-trusted third party based. Since there is not necessarily a trusted third party in the distributed scenario, trusted third party based solutions are not applicable in the distributed scenario. Moreover, solutions based on trusted third parties are prone to single point of failure and performance bottleneck problems, which makes the maintenance cost of the third parties high.

Disclosure of Invention

In view of this, the present invention provides a block chain-based trusted SOA architecture, which can ensure that service disputes between a service provider and a requester can be effectively handled within a specified trusted invocation time regardless of independent malicious behaviors or complex malicious behaviors.

In order to achieve the purpose, the invention adopts the following technical scheme: a block chain-based trusted SOA architecture, in the architecture, a block chain is introduced as a service registration agent and an evidence recorder, and a service provider agent and a service consumer agent are provided to enable the process of service registration, discovery, invocation and execution to be automated and trusted; for a given Web Service, a Service provider agent converts the Web Service into a Trusted Service description model Trusted Service supporting a Trusted SOA; the Service consumer proxy shields the difference between different Service description models, so that the Service consumer can use the Trusted Service description model in the original mode; based on the framework, the service calling flow is as follows: firstly, a service consumer encrypts calling parameters such as a calling process, service input parameters and the like, and then constructs a service calling request on the basis and sends the service calling request to a service provider; secondly, after receiving the calling request, the service provider decrypts the calling parameter and executes the corresponding service according to the service name and the input parameter in the calling parameter; finally, after the service execution is finished, the service provider encrypts the output result of the service and sends the encrypted result to the service consumer, and the service calling process is signed by the service consumer and the service provider and then used as a trusted certificate uplink; the service consumer can obtain the target value by decrypting the encrypted output result; when a service dispute occurs, a dispute resolution intelligent contract is triggered, and the contract is verified by reacquiring the trusted certificate on the chain, so that the service dispute is correctly processed.

In a preferred embodiment, the trusted service description model is described below using definition 3-1:

definition 3-1: a Trusted Service description model based on a block chain can be represented as a binary group of TrustedService < basicinffromation, TraceInformation >, wherein basicinffromation represents basic description information of a Service, and the specific meaning is defined as 3-2, and TraceInformation represents traceable information, and the specific meaning is defined as 3-4;

definition 3-2: basic description information of the Trusted Service is expressed as a quadruplet of < BFintersection, BTextDescription, Burl, BProvider >, wherein BFintersection represents a method statement of the Service, BTextDescription represents a Service text description of the Service, Burl represents a method address of the Service, the Service is uniquely identified by using a Uniform Resource Locator (URL), BPprovider represents a Service provider of the Service, and the Service provider is identified by using an identity certificate, namely Fabric-CA, of a Service provider node in a Fabric network;

definitions 3 to 3: the method statement of the Trusted Service is expressed as a triple group of BFunction ═ BServiceName, BInput and BOutput >, and the method statement comprises a Service name BServiceName, a Service input parameter BInput and a Service output result BOutput; where BInput is denoted herein as the set BInput ═ { BI1, BI 2., BIn }, any one of the BIs including the input parameter name BIName, the input parameter type BIType, and the input parameter value BIValue, in the form of a triplet of BI ═ BIName, BIType, BIValue >; meanwhile, BOutput is represented as a set BOutput ═ BO1, BO2,.., BOn }, where any BO contains an output result name BOName, an output result type BOType, and an output result value BOValue, and is expressed as a triplet of BO ═ BOName, BOType, BOValue >; in addition, in order to ensure the privacy of data, the service input parameters and the service output results are encrypted in the calling process;

definitions 3-4: traceable information of the Trusted Service is represented as a binary group of traceinforation ═ BRequest _ Process, PrA (BRequest _ Info) >, wherein BRequest _ Process represents a calling procedure proof obtained by combining the Service consumer and the Fabric-CA of the Service provider, and is represented herein as a binary group of BRequest _ Process ═ BConsumer, BProvider >; PrA (BRequest _ Info) represents a call information encrypted using the service consumer private key PrA, and for any call information BRequest _ Info, it is denoted herein as a triplet of BRequest _ Info ═ BRequest _ Process, BServiceName, brequestttime >, i.e. the above call procedure, service name, and brequestttime represents the service call initiation time.

In a preferred embodiment, the system comprises a service provider proxy mechanism, wherein the service provider proxy mechanism mainly comprises a service registration module and a service execution module; the service registration module mainly completes automatic registration of service description information on a block chain; the execution of the Web Service is abstracted into the invocation of the method; when the Service credibility is not considered, the traditional Web Service only contains description information of the Web Service, and the Service registration module converts the traditional Service description model Webservice into a credible Service description model Trustedservice based on a block chain;

the service execution module is mainly responsible for forwarding the request of the service consumer to the real Web service for execution; the service execution module needs to complete earlier-stage work before executing service execution: decrypting a service input parameter BInput sent by a service consumer to obtain WInput; after the service input parameters are acquired, the service execution module forwards and calls the real Web service, uses the data as input to execute the real service and returns a result; the follow-up work needs to be done after the service execution: and constructing a trusted certificate Proof _ Call, registering the trusted certificate Proof _ Call in a historical database of the block chain, and performing persistence.

In a preferred embodiment, the service consumer proxy mechanism is included, and the service consumer proxy mechanism mainly comprises a service discovery module and a service calling module; the service discovery module is mainly responsible for completing the search of the target service according to the functional service requirement of the service consumer; the module realizes the query function based on the block chain; the service calling module mainly completes two processes: firstly, constructing a service calling parameter model and completing trusted service calling; and secondly, receiving and analyzing an output result of the service trusted execution.

In a preferred embodiment, the service trusted process uses Pu to represent the Public Key Public _ Key, PuA to represent the Public Key of the service provider, PuB to represent the Public Key of the service consumer; pr denotes the Private Key Private _ Key, PrA denotes the Private Key of the service provider, and PrB denotes the Private Key of the service consumer:

step 1[ Encrypt (PuB, Input _ Info) ]: after the service consumer A provides an Input parameter Input _ Info, a service consumer agent obtains a public key PuB of a service provider B through an identity certificate BProvider of the service provider B of a target trusted service description TrustedService matched by a service, and then encrypts the Input _ Info by using the PuB to obtain an encrypted value PuB (Input _ Info);

step 2[ Encrypt (PrA, Request _ Info) and construct Request ]: after the Input _ Info is encrypted, the service consumer proxy further constructs a service call Request based on the encrypted information; the Request comprises three parts, the first part is a calling Process Request _ Process of the service, the second part is that the service consumer A uses PrA encryption calling information Request _ Info to obtain an encryption value PrA (Request _ Info), and the last part is the encryption value PuB (Input _ Info) obtained in step 1;

step 3[ send Request ]: the service consumer proxy obtains a method address BUrl which is responsible for receiving a service calling Request in the service provider proxy according to the service matched during service discovery, and then sends a Request through RPC;

step 4[ Decrypt (PuA, PrA (Request _ Info)) and locate service ]: the service provider agent firstly obtains a public key PuA of the service consumer through an identity certificate Coummer of the service consumer A in the calling process, then decrypts a PrA (Request _ Info) part in the Request through PuA to obtain Request _ Info, and finally locates the real service of the Request through the service ServiceName in the Request _ Info;

step 5[ Decrypt (PrB, PuB (Input _ Info)) ]: the service provider agent decrypts the PuB (Input _ Info) through a private key PrB of the service provider agent to obtain an Input parameter Input _ Info;

step 6[ execute service and Encrypt (PuA, Result) ]: the service provider B transmits the Input _ Info obtained in the step 4 to the real service positioned in the step 4, obtains a corresponding Result after the service execution is finished, and then the service provider agent encrypts the Result through PuA to obtain an encrypted value PuA (Result);

step 7[ Encrypt (PrB, PuA (Result)) and return PrB (PuA (Result)) ]: the service provider B further encrypts the encrypted value PuA (result) obtained in the step 6 by using PrB to obtain an encrypted value PrB (PuA (result)), and returns the encrypted value PrB to the service consumer A through RPC;

step 8[ construct Proof _ Call ]: in order to ensure the traceability of the service, the service provider B needs to construct a service trusted voucher Proof _ Call while returning Result to the service consumer a; proof _ Call consists of two parts, one is the Request sent by the service consumer and the other is the result encrypted value pua (result) obtained by step 6;

step 9[ issue Proof _ Call ]: the service provider B triggers the credible certificate registration contract by taking the Proof _ Call as the parameter of the contract, so that the Proof _ Call is issued to the chain in a transaction format;

step 10[ dispute resolution mechanism ]: when the service provider and the service consumer dispute the calling process or the output result (for example, the service consumer does not trust the output result returned by the service provider), the dispute presenter triggers a dispute contract, and the contract disputes the dispute; the identity Fabric-CA of the decision-making initiator is verified by the contract date verification, so that the service provider and the service consumer can only judge the related calling process through the credible certificates related to the two parties, and the calling process and the credible certificates of other nodes are not interfered.

In a preferred embodiment, when the service consumer a and the service provider B generate a service dispute, the dispute presenter applies for arbitration in the last step, step 10, and the sanction intelligent contract deployed on the dispute presenter is triggered to execute to sanction the involved call process.

Compared with the prior art, the invention has the following beneficial effects:

the invention constructs the service calling process as a credible certificate after being signed by both the service consumer and the service provider, and records the credible certificate in a historical database of a block chain in a transaction format, thereby ensuring the traceability of the service; when dispute occurs between two service parties, the trusted certificate on the chain is obtained again for verification, so that the service trust is ensured. Meanwhile, in order to ensure the privacy of service data, the method carries out encryption processing on input parameters and results of the service in the process of constructing the trusted certificate.

The invention enables the calling process of the service to be recorded and persisted by redefining the service description model, and ensures the credibility and traceability of the service. Meanwhile, the service provider agent and the service consumer agent make the trusted service transparent, so that the service provider and the consumer can perform service registration, service discovery, service invocation and service execution in the original mode. The whole framework uses the block chain as the bottom support, and realizes a trusted certificate recorder by utilizing the characteristics of decentralization, non-tampering and traceability, thereby persisting the service calling process of both service parties in the framework.

Compared with the traditional calling method, the method can correctly process the service dispute between the service provider and the requester under the condition of most malicious behaviors.

Drawings

FIG. 1 is a service trusted invocation flow overview diagram of the preferred embodiment of the present invention;

FIG. 2 is an overview of a support framework method for a trusted SOA according to a preferred embodiment of the present invention;

FIG. 3 is a schematic diagram of a service provider proxy mechanism in accordance with a preferred embodiment of the present invention;

FIG. 4 is a flow diagram of trusted execution of services in accordance with a preferred embodiment of the present invention;

FIG. 5 is a schematic diagram of a service consumer proxy mechanism in accordance with a preferred embodiment of the present invention;

FIG. 6 is a service trusted invocation flow diagram of the preferred embodiment of the present invention;

FIG. 7 is a scenario 1-malicious service provider results presentation of the preferred embodiment of the present invention;

FIG. 8 is a scenario 2-malicious service provider result presentation of the preferred embodiment of the present invention;

FIG. 9 is a scenario 1-malicious service consumer results presentation of the preferred embodiment of the present invention;

FIG. 10 is a scenario 1-malicious service consumer results presentation of the preferred embodiment of the present invention.

Detailed Description

The invention is further explained below with reference to the drawings and the embodiments.

It should be noted that the following detailed description is exemplary and is intended to provide further explanation of the disclosure. Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs.

It is noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments according to the present application; as used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, and it should be understood that when the terms "comprises" and/or "comprising" are used in this specification, they specify the presence of stated features, steps, operations, devices, components, and/or combinations thereof, unless the context clearly indicates otherwise.

A service calling process is signed by a service consumer and a service executor to form a trusted certificate, and the trusted certificate is stored in a historical database on a block chain in a transaction format, so that the traceability of the service is ensured, and service disputes can be solved by re-acquiring the trusted certificate on the chain. Meanwhile, in the process of constructing the trusted certificate, the input parameters and the result of the service are encrypted, so that the privacy of service data is ensured. A block chain based trusted SOA support framework is included to ensure trusted invocation of services. The architecture uses a block chain as a bottom layer storage, and mainly comprises two parts: a service consumer proxy and a service provider proxy. The service provider agent provides support for the service provider to complete service registration and service execution functions, and the service consumer agent provides support for the service consumer to complete service discovery and service calling functions. By means of the support framework, service consumers and service providers can register, discover, call and execute services in an original mode, and agents can automatically complete other related work for supporting credible services.

Fig. 1 shows a service invocation flow based on a trusted SOA. Firstly, a service consumer encrypts calling parameters such as a calling process, service input parameters and the like, and then constructs a service calling request on the basis and sends the service calling request to a service provider; secondly, after receiving the calling request, the service provider decrypts the calling parameter and executes the corresponding service according to the service name and the input parameter in the calling parameter; finally, after the service execution is finished, the service provider encrypts the output result of the service and sends the encrypted result to the service consumer, and the service calling process is signed by the service consumer and the service provider and then used as a trusted certificate uplink; the service consumer can obtain the target value by decrypting the encrypted output result. When a service dispute occurs, a dispute resolution intelligent contract is triggered, and the contract is verified by reacquiring the trusted certificate on the chain, so that the service dispute is correctly processed.

Figure 2 illustrates the overall architecture of the framework in which blockchains are introduced as a service registration agent and an evidence logger, further, providing service provider agents and service consumer agents to automate and trust the process of service registration, discovery, invocation and execution. For a given Web Service, a Service provider agent can convert the Web Service into a Trusted Service supporting a Trusted SOA; the Service consumer proxy shields the difference between different Service description models, so that the Service consumer can use the Trusted Service in the original mode.

In order to make the Service support the Trusted invocation and ensure the traceability of the Service, the invention also comprises a Trusted Service description model Trusted Service, which is described by using the definition 3-1.

Definition 3-1: a Trusted Service description model based on a block chain can be represented as a binary set of TrustedService < basicinffromation, TraceInformation >, wherein basicinffromation represents basic description information of a Service, and the specific meaning is defined as 3-2, and TraceInformation represents traceable information, and the specific meaning is defined as 3-4.

Definition 3-2: the basic description information of the Trusted Service is expressed as a quadruplet of < BFunction, BTextDescription, BUrl, BProvider >, wherein BFunction represents a method statement of the Service, BTextDescription represents a Service text description of the Service, BUrl represents a method address of the Service, the Service is uniquely identified by using Uniform Resource Locator (URL), BProvider represents a Service provider of the Service, and the Service is identified by using an identity certificate Fabric-CA of a Service provider node in a Fabric network.

Definitions 3 to 3: the method declaration of the Trusted Service is expressed as a triple of BFunction ═ BServiceName, BInput, BOutput >, and the method declaration includes a Service name BServiceName, a Service input parameter BInput, and a Service output result BOutput. Where BInput is denoted herein as the set BInput ═ { BI1, BI 2., BIn }, any one of the BIs including the input parameter name BIName, the input parameter type BIType, and the input parameter value BIValue, in the form of a triplet of BI ═ BIName, BIType, BIValue >; meanwhile, BOutput is represented as a set BOutput ═ BO1, BO 2.., BOn }, and any BO contains an output result name BOName, an output result type BOType, and an output result value BOValue, which is expressed as a triplet of BO ═ BOName, BOType, BOValue >. In addition, in order to ensure the privacy of data, the service input parameters and the service output results are encrypted in the calling process.

Definitions 3-4: traceable information of the Trusted Service is represented as a binary group of traceinforation ═ BRequest _ Process, PrA (BRequest _ Info) >, wherein BRequest _ Process represents a calling procedure proof obtained by combining the Service consumer and the Fabric-CA of the Service provider, and is represented herein as a binary group of BRequest _ Process ═ BConsumer, BProvider >; PrA (BRequest _ Info) represents a kind of call information encrypted using the service consumer private key PrA (the encryption rule is shown in equation (3-2)), and for any call information BRequest _ Info, it is herein denoted as a triplet of BRequest _ Info < BRequest _ Process, BServiceName, BRequestTime >, brequestname is the above call procedure, service name, and BRequestTime denotes a service call initiation time.

In an SOA, a service provider registers services, and when a service consumer calls a service registered by the service provider, the service provider needs to execute and return a result to a target service. Thus, the present invention also includes a service provider proxy mechanism to assist the service provider in automated registration and execution forwarding of services. As shown in fig. 3, the service provider proxy mechanism mainly includes a service registration module and a service execution module.

The service registration module mainly completes the automatic registration of the service description information on the blockchain. The execution of the Web Service may be abstracted as the invocation of a method. Regardless of the trustworthiness of the Service, a conventional Web Service usually contains only its own description information, which is defined as shown in definition 3-5:

definitions 3 to 5: a conventional Web Service description model may be expressed as a triplet of WebService ═ wfaction, WTextDescription, WUrl >. The WFunction represents a method statement of a service, the WTextDescription represents a service text description of the service, and the WUrl represents a method address of the service, and is generally represented by a URL.

Definitions 3-6: the method declaration of Web Service may be expressed as a triplet of WFunction ═ WServiceName, WInput, WOutput >. Wherein, WServiceName represents the service name of the service; WInput represents an input parameter of the service, and is represented as a set of WInput ═ { WI1, WI 2., WIn }, any WI is composed of an input parameter name window, an input parameter type WIType, and an input parameter value WIValue, and is represented as a triplet of WI ═ window, WIType, WIValue >; WOutput represents an output result, and is expressed as a set WOutput { WO1, WO 2., WOn }, any WO is composed of an output result name WOName, an output result type WOType, and an output result value WOValue, and is expressed as a triple of WO ═ WOName, WOType, and WOValue >.

According to the definition of the traditional service description model and the trusted service description model based on the block chain, the mapping relation of the service basic description information of the traditional service description model and the trusted service description model based on the block chain can be found. In order to support trusted service invocation on the blockchain, the service registration module converts the traditional service description model WebService into a trusted service description model TrustedService based on the blockchain.

Rule 1: establishing a mapping relation between the WServiceName and the BserviceName: the value of WServiceName corresponds to the value of BServiceName, see fig. 3-4, rule 1.

Rule 2: establishing a mapping relation between WInput and BInput: BInput corresponds to WInput; binput.biname corresponds to winput.window; binput.bitype corresponds to winput.witype; binput. bivalue corresponds to PuB (winput. wivalue), which is calculated by Encrypt (PuB, winput. wivalue), see rule 2 section of fig. 3-4.

Rule 3: establishing a mapping relation between WOutput and BOutput: BOutput corresponds to WOutput; boutput. boname corresponds to woutput. woname; boutput. botype corresponds to woutput. wotype, boutput. bovalue corresponds to PrB (PuA (woutput. wovalue)), which is calculated by Encrypt (PrA, Encrypt (PuA, woutput. wovalue)), see fig. 3-4, rule 3 section.

Rule 4: establishing a mapping relation between WTextDescription and BTextDescription: BTextDescription corresponds to

Where text (x) represents the text-plus-description for x, see rules 4 section of FIGS. 3-4.

Rule 5: newly added BUrl and BProvider: the value of BUrl corresponds to the address of the method in the service execution module of the service provider agent responsible for receiving the service consumer message; the value of BProvider corresponds to the identity certificate Fabric-CA of the service provider, see rules 5 section of fig. 3-4.

Rule 6: newly added TraceInfromation: each component in the TraceInformation is set to be a null value, and the value of each component is supplemented in the service calling process. See rules 6 section of fig. 3-4.

In the above rules, rule 4 is by sign

A new operation is introduced. It represents the string splicing operation, and the operation rule is shown in formula (2-1):

wherein A and B represent arbitrary character strings, when B is substring of A, then

When A is the substring of B, then

Otherwise

The service execution module is mainly responsible for forwarding the request of the service consumer to the real Web service for execution. As shown in fig. 4, the service execution module herein needs to complete the previous work before performing service execution (fig. 4 (a)): decrypting a service input parameter BInput sent by a service consumer to obtain WInput; after the service input parameter is acquired, the service execution module forwards and calls the real Web service, uses the data as input to execute the real service and returns a result (fig. 4 (b)); the follow-up work needs to be done after the service execution: the trusted voucher Proof _ Call is constructed, registered in the history database of the block chain, and persisted (fig. 4 (c)).

The incoming definitions 3-7 therefore represent trusted credentials:

definitions 3 to 7: a trusted voucher Proof _ Call of a trusted calling process is denoted as Proof _ Call ═ Request, pua (result), which describes a whole process from the service consumer starting to Call the service to the service provider receiving and completing the service, wherein the Request denotes that the service consumer calls a parameter model, and the specific model is defined in definitions 3-9; pua (result) represents the service export result encrypted by the service consumer's public key PuA, as defined in definitions 3-8.

Definitions 3 to 8: the service execution output Result may be represented as Result ═ { R1, R2.., Rn }, where any one of the output results R is represented by a triple R ═ RName, RType, RData >, RName represents the Result name, RType represents the Result type, and RData represents the Result data.

As can be seen from fig. 4, the service execution module herein needs to complete the previous work before performing service execution: decrypting PuB (Input _ Info) (namely PuB (BInput)) in a service calling parameter model Request (see definition 3-9) sent by a service consumer to obtain Input _ Info (namely WInput); the follow-up work needs to be completed after the execution of the service is completed: the trusted voucher Proof _ Call is registered in the history database of the blockchain. The present invention describes this using algorithm 3-1.

Encrypt(Pu_M,X)＝Pu_M(X) formula (3-1)

Encrypt(Pr_M,X)＝Pr_M(X) formula (3-2)

Equation (3-1) represents the use of the public key Pu of the user M_MEncrypting the information X to obtain encrypted information Pu_M(X). Equation (3-2) represents the use of the private key Pr of user M_MEncrypting the information X to obtain encrypted information Pr_M(X). Equation (3-3) represents the encrypted information Pr_M(X) can only be assigned to its public key Pu_MDecryption is carried out, and the non-corresponding public key Pu_N≠MCannot be decrypted by public keyAnd (4) secret data. Equation (3-4) represents the encrypted value Pu_M(X) can only be identified by its corresponding private key Pr_MDecryption is carried out, and the non-corresponding private key Pr_N≠MIt cannot be decrypted. It is assumed that a mapping relationship B ═ map (a) exists, and if B ═ map (a) and a ═ map (B), then the mapping relationship has symmetry. Therefore, it is easy to verify: the mapping relation exists between the Pu-CA and the Public _ Key. Namely:

public _ Key ═ Map (Pu-CA) ^ Pu-CA ═ Map (Public _ Key) formula (3-5)

The input of algorithm 3-1 is the service invocation parameter model Request sent by the service consumer, and the output is the trusted voucher Proof _ Call. In this algorithm, the method isSuccess (Pu)_A',Pr_A(Request _ Info)) judges the public key Pu obtained by the calling process_A'Success or failure of decryption of Pr_A(Request _ Info), and the exit (ServiceName, Input _ Info) forwards the Input _ Info to the true service ServiceName for execution, and the remote (Consumer, Pr)_B_Pu_AResult) will encrypt the Result Pr_B_Pu_AResult is returned to the service Consumer Consumer. The specific algorithm flow is as follows:

step 1(Line 1-4): firstly, acquiring an identity certificate of a service consumer in a calling process, and further acquiring a public key PuA' of the service consumer according to a formula (3-5); a decision PuA' is then made that decryption of the Request.

Step 2(Line 5-7): first decrypt request.pra (Request _ Info) using PuA' according to equation (3-3); then, decrypting request.pub (Input _ Info) by using the service provider private key PrB according to the formula (3-4); and finally, passing through Request _ info.ServiceName positioning service and transmitting the Request _ Info into Input _ Info for execution to obtain a Result.

Step 3(Line 8-15): traversing the Result, firstly encrypting the Result Ri by using PuA' according to formula (3-1) and adding the Result Ri to PuA _ Result, then traversing the encrypted Result PuA _ Result, and encrypting PuA _ Ri by using a private key PrB of the service provider according to formula (3-2) and adding the Result Ri to PrB _ PuA _ Result; and finally, sending the PrB _ PuA _ Result to the service consumer through a remote procedure Call, and completing the construction of the trusted voucher Proof _ Call.

It can be noted that the algorithm encrypts Result twice, because only once encrypted pua (Result) is transmitted to the service consumer, the dishonest service consumer may tamper with it to generate pua (Result)', at this time, the service consumer may be 35820the service consumer, the trapped service provider provides wrong service execution Result, and the service provider clearly providing correct Result cannot self-certify, which results in that correct resolution cannot be achieved at dispute; after transmission using PrB (pua (result)), the service consumer has no private key PrB of the service provider, so that the service provider can be considered as a mistake when the results are inconsistent.

In a SOA, a service consumer may discover services and initiate calls to selected services. The present invention also includes a service consumer proxy mechanism to assist a service consumer in the lookup and invocation of services. As shown in fig. 5, the service requester proxy mechanism mainly includes a service discovery module and a service invocation module.

The service discovery module is mainly responsible for completing the search of the target service according to the functional service requirements of the service consumers. The module implements a blockchain-based query function.

The service calling module mainly completes two processes: firstly, constructing a service calling parameter model and completing trusted service calling; and secondly, receiving and analyzing an output result of the service trusted execution.

The calling parameter model is described herein using definitions 3-9:

definitions 3 to 9: a service invocation parameter contains a calling Process description, invocation information encrypted by using a private key of a service consumer and one or more service Input parameters, which are expressed as triplets of Request ═ Request _ Process, PrA (Request _ Info), PuB (Input _ Info) >, wherein Request _ Process represents the calling Process description, and the specific meaning of the Request _ Process is defined in 3-10; the Request _ Info represents calling information which is a supplementary description of the calling process, PrA (Request _ Info) represents calling information obtained by encrypting the Request _ Info by using a service consumer private key PrA, and the specific meaning of the Request _ Info is defined in 3-11; the Input _ Info indicates a service execution Input parameter, PuB (Input _ Info) indicates a service execution Input parameter obtained by encrypting the Input _ Info with the service provider public key PuB, and the specific meaning of the Input _ Info is defined in definitions 3 to 12.

Definitions 3-10: request _ Process < Provider > indicates the calling procedure of a trusted service call, where Provider indicates the service Consumer identity information and Provider indicates the service Provider identity information, both of which are indicated using the identity certificate Fabric-CA.

Definitions 3 to 11: the Request _ Info ═ Request _ Process, ServiceName, and RequestTime > represent the call information of one trusted service call, where Request _ Process represents the call procedure description of the service call, ServiceName represents the service name, and RequestTime represents the start time of the service call initiated by the service consumer.

Definitions 3-12: input _ Info { I1, I2., In } represents the set of service Input parameters for one trusted service call, where any one I is denoted as I ═ parameter, IType, IValue >, parameter name, IType represents the Input parameter type, and IValue represents the Input parameter value.

Based on definitions 3-9 through 3-12, the procedure for service invocation is described as follows:

(1) constructing a calling parameter model of service calling by a service consumer;

(2) and sending the service call according to the service description model TrustedService acquired by service discovery. The expression remote (BUrl, Request) is used herein to denote that sending the call parameters to the method address BUrl where the service provider is responsible for receiving the Request is done using RPC.

(3) And after the execution of the receiving service is finished, the encrypted service outputs a result set, decrypts and acquires an output result.

Based on the constructed calling parameter model, the service calling module algorithm is shown as algorithm 3-2. Its inputs include four terms: the target trusted service description model TrustedService (obtained from the service discovery module), the private key PrA of the service Consumer, the service Consumer identity certificate Consumer, and the input parameter WInput of the service Consumer. In the algorithm, a method getcurrentTime () acquires call initiation time, and match (BInput, Request) judges whether a Request parameter Request is matched with an input BInput required by a trusted service. The specific process is as follows:

step 1(Line 1-4): firstly, acquiring a service provider public key PuB from a service provider identity certificate based on a formula (3-5); next, go through WInput, encrypt WIi using PuB based on equation (3-1), and add the encrypted value to the Input _ Info.

Step 2(Line 5-11): and constructing the Request according to the definitions 3-9, wherein the construction comprises constructing a service calling Process Request _ Process and calling information Request _ Info. The method comprises the steps of firstly completing construction of Request, Request _ Process, then obtaining service name and service initiation time, completing construction of Request _ Info, encrypting based on a formula (3-1) by using a service consumer private key PrA, assigning an encryption value to the Request, PrA (Request _ Info), and finally assigning Input _ Info to the Request, PuB (Input _ Info).

Step 3(Line 12-15): and judging whether the Request and the BInput are matched. If not, the flow is ended; and if the matching is carried out, the calling parameters are sent to the address BUrl of the service execution module through the RPC, and the service calling is carried out.

In the service trusted flow, Pu is used for representing a Public Key Public _ Key, PuA is used for representing a Public Key of a service provider, and PuB is used for representing a Public Key of a service consumer; pr denotes a Private Key Private _ Key, PrA denotes a Private Key of a service provider, and PrB denotes a Private Key of a service consumer. The detailed workflow of the process is shown in fig. 6:

step 1[ Encrypt (PuB, Input _ Info) ]: after the service consumer A provides the Input parameter Input _ Info, the service consumer agent first obtains the public key PuB of the service provider B based on the formula (3-5) through the identity certificate BProvider of the service provider B of the target trusted service description TrustedService matched by the service, and then encrypts the Input _ Info by using the PuB to obtain an encrypted value PuB (Input _ Info).

Step 2[ Encrypt (PrA, Request _ Info) and construct Request ]: after encrypting the Input _ Info, the service consumer proxy further constructs a service call Request based on the encrypted information. The Request includes three parts, the first part is the calling procedure Request _ Process of the service, the second part is that the service consumer a encrypts the calling information Request _ Info using PrA based on the formula (3-2) to obtain the encrypted value PrA (Request _ Info), and the last part is the encrypted value PuB (Input _ Info) obtained in step 1.

Step 3[ send Request ]: and the service consumer proxy obtains the method address BUrl which is responsible for receiving the service call Request in the service provider proxy according to the service matched during service discovery, and then sends the Request through RPC.

Step 4[ Decrypt (PuA, PrA (Request _ Info)) and locate service ]: the service provider agent first obtains PuA a public key of the service consumer based on the formula (3-5) by calling Coummer the identity certificate of the service consumer a in the process, then decrypts PuA the PrA (Request _ Info) part in the Request to obtain Request _ Info, and finally locates the true service of the Request by the service ServiceName in the Request _ Info.

Step 5[ Decrypt (PrB, PuB (Input _ Info)) ]: the service provider agent decrypts PuB (Input _ Info) through a private key PrB of the service provider agent based on a formula (3-4), and obtains an Input parameter Input _ Info.

Step 6[ execute service and Encrypt (PuA, Result) ]: the service provider B transmits the Input _ Info obtained in step 4 to the real service located in step 4, obtains a corresponding Result after the service execution is completed, and then the service provider agent encrypts the Result based on the formula (3-1) by PuA to obtain an encrypted value pua (Result).

Step 7[ Encrypt (PrB, PuA (Result)) and return PrB (PuA (Result)) ]: the service provider B further encrypts the encrypted value pua (result) obtained in step 6 based on the formula (3-2) using PrB to obtain an encrypted value PrB (pua (result)), and returns it to the service consumer a through RPC.

Step 8[ construct Proof _ Call ]: to ensure service traceability, the service provider B needs to construct a service trusted voucher Proof _ Call while returning Result to the service consumer a. The Proof _ Call consists of two parts, one is the Request sent by the service consumer and the other is the resulting encrypted value pua (result) obtained by step 6.

Step 9[ issue Proof _ Call ]: the service provider B triggers the trusted credential registration contract with Proof _ Call as a parameter of the contract so that Proof _ Call is issued onto the chain in transactional format.

Step 10[ dispute resolution mechanism ]: when the service provider and the service consumer dispute the calling process or the output result (for example, the service consumer does not trust the output result returned by the service provider), the dispute presenter triggers a dispute contract, and the contract resolves the dispute. The dating verification verifies the identity Fabric-CA of the decision initiator, and ensures that the service provider and the service consumer can only judge the related calling process through the credible certificates related to the two parties without interfering with the calling process and the credible certificates of other nodes.

In the invention, it is assumed that a service provider or a service consumer tries to cheat a counterpart by performing malicious activities in the service providing process due to the self-interest, namely, the service provider may provide false services, and the service consumer tries to refuse to obtain correct services. However, none of them perform unreasonable abnormal behaviors, such as receiving incorrect services on the part of service consumers, at the expense of their own interests.

Therefore, when the service consumer a and the service provider B generate a service dispute, the dispute presenter may apply for arbitration in the last step, step 10, and the sanction intelligent contract deployed on the dispute presenter may be triggered to execute to sanction the involved calling process. In the above process, the implementation of the dispute resolution mechanism algorithm on the intelligent contract is determined as shown in algorithm 3-3. The input of the method comprises a calling parameter Request to be verified sent by a service consumer A, an encryption result PrB (PuA (result)) acquired by the service consumer A, and a credible certificate Proof _ Call related to the calling process stored on a chain by a service provider B; the output is the result of dispute resolution, i.e. the decision result of whether the service consumer and the service provider are malicious or not. The specific algorithm flow is as follows.

Step 1(Line 1-3): verifying whether the PrB (PuA (result)) is tampered. Firstly, a service provider public key PuB 'is obtained based on a formula (3-5) through a provider identity certificate request, request _ Process, BProvider on a calling parameter to be verified, then whether the PrB (PuA (result)) is forged or not is verified, and if the PuB' can be successfully decrypted based on the formula (3-3) or not, the result is considered to be maliciously tampered by a service consumer if the PuA (result)) fails.

Step 2(Line 5-9): and verifying the Proof of Proof _ Call. Firstly, a service provider public key PuA 'is obtained based on formula (3-5) through a consumer identity certificate Proof _ call.request.request _ process.Consumer on a trusted certificate to be verified, then whether Proof _ call.request.PrA (Request _ Info) is forged or not is verified, and the trusted certificate is considered to be changed if the Proof _ call.request.PrA (Request _ Info) is failed by judging whether PuA' can be successfully decrypted based on formula (3-3), and the algorithm is ended. If the decryption can be successfully performed, step 3 is performed.

Step 3(Line 9-12): and verifying whether the call parameter Request to be verified is consistent with the call parameter Proof _ call. Obtaining Request _ Process, PrA (Request _ Info) and PuB (Input _ Info) from Request, then obtaining Request _ Process ', PrA (Request _ Info)' and PuB (Input _ Info) 'from on-chain trusted voucher Proof _ Call, and finally comparing whether Request _ Process and Request _ Process' are equal, whether PrA (Request _ Info) and PrA (Request _ Info) 'are equal, and whether PuB (Input _ Info) and PuB (Input _ Info)' are equal, and once there is an inequality, it is considered that service consumer a tries 35820with wrong Request parameters, i.e. malicious service consumer, and thus the service consumer a is a wrong party.

Step 4(Line 13-20): and verifying whether the result PrB (PuA (result)) to be verified is consistent with the result on the credible certificate or not. Before verification it is necessary to ensure that the results have not been altered, and if so the flow ends. If not, firstly obtaining the public key PuB of the service provider B through Request _ Process, then decrypting the encrypted result set PrB (pua (result)) to obtain pua (result)), obtaining pua (result) of the trusted voucher Proof _ Call from the chain, and finally comparing whether pua (result) and pua (result) are equal, if not, the service provider can be considered to provide malicious service, and therefore the wrong party is the service provider B. The algorithm ends.

When a service provider triggers a contract, where the values of Request and PrB (pua (result)) from the service consumer are null values, the service provider is only verified as malicious or not by the authenticity of the trusted voucher on the chain.

Method evaluation

Effectiveness of

The method selects 15 services (total 90 services) with the top rank of each category as a Service set from 6 different categories of Web services such as commerce, trade, communication, travel, public affairs and the like on a public open Web Service platform, converts each Service in the Service set into a trusted Service supporting a trusted SOA (Service oriented architecture), and tests whether the time cost of trusted call meets the use requirement of a user.

TABLE 3-1 application scope of the method of the present invention

The time overhead of the direct call of the Web Service is between 0.5s and 1s, and if the time overhead of the trusted call is more than 2.5s, the method is not suitable for the Service. The results of the experiments are shown in Table 3-1, and the method of the present invention can be applied to 79 of the services, which account for 87.78% of all the services. The method is suitable for most services, but for services with small input parameters or extremely large results, the time overhead for encrypting and decrypting the services in trusted execution is too large, so the method is not suitable for the services.

According to all service patterns of the present invention, there are malicious behaviors that will lead to dispute conflicts between service providers and service consumers. Wherein the independent malicious behavior is as follows: e1: the malicious service provider issues an erroneous Request' in step 9; e2: the malicious service provider constructs the wrong pua (result)' in the trusted voucher in step 8; e3: a dishonest service consumer denies receipt of the correct PrB (pua (result)) from step 7; e4: a dishonest service consumer tries to lift 35820via wrong Request'; e5: a dishonest service consumer sends an erroneous Request' in step 3; the existence of complex malicious behavior is as follows: e6: malicious service providers provide false requests 'and false pua (result)'; e7: malicious consumers attempt to verify the wrong Request 'and wrong PrA (pua (result))'.

The invention verifies the effectiveness of the dispute resolution mechanism by simulating 20 behaviors of 17 types (16 malicious behaviors and 1 correct behavior) on the basis of service trusted invocation. When the dispute resolution mechanism is triggered, the verification result is sent to the corresponding initiator on one hand, and is recorded on the blockchain in the form of transaction on the other hand. The verification results are shown in table 3-2, and it can be seen that the resolution of the disputes in 16 of the call processes by the method of the present invention meets the expected target.

TABLE 3-2 verification results

Then, the invention obtains the result from the stored dispute result for displaying, and discusses the above 16 typical malicious behaviors from the perspective of malicious service providers and malicious service consumers, thereby verifying the effectiveness of the dispute resolution mechanism in the trusted SOA architecture.

a) The malicious service provider: the malicious activities initiated by the malicious service provider have a total of 3, which are E1, E2, and E6, respectively. For malicious activity E1, after triggering the dispute resolution mechanism, the flow is terminated because PrA (Request _ Info) cannot be decrypted, and the wrong party is considered as the service provider, as shown in fig. 7; for malicious activity E2, the flow is terminated because the result received by the service consumer is inconsistent with the result of the chain linking with the service provider, and the wrong party is considered as the service provider, as shown in fig. 8; for the malicious behavior E6, the wrong Request' will terminate the dispute resolution process in advance and consider the wrong party as the service provider, thereby avoiding unnecessary resource consumption, as shown in fig. 7.

b) Malicious service consumers: malicious service consumers initiated malicious activities of 4 kinds, respectively E3, E4, E5 and E7. In the case of ensuring that the trusted certificate on the chain is authentic, for malicious activity E3, since the service consumer cannot forge the private key PrB of the service provider, PrB' (pua (result)) cannot be decrypted using the public key PuB of the service provider based on formula (3-4), and the result is shown in fig. 9; for malicious activity E4, the forged Request' is compared with the Request in the chain trusted certificate, and the service consumer is considered to be the wrong party, as shown in fig. 10. For the malicious behavior E5, in the process of analyzing the wrong Request', the malicious behavior can be found to be the malicious behavior of the malicious service consumer, the subsequent dispute resolution process is terminated in advance, and unnecessary resource consumption is avoided; for malicious activity E7, since the authentication Request parameter Request cannot pass, it will be determined that the service consumer is the wrong party, and the result is shown in fig. 10.

c) Malicious service providers/consumers: in this case, there are 9 malicious acts. Wherein, most complex malicious behaviors can be correctly judged by the method. The method of the present invention does not make a correct decision only when the action E6 and the action E4 or E7 occur simultaneously, and when the actions E3 and E2 occur simultaneously. This is because the trusted voucher on the chain is false and cannot provide strong evidence to support the contract to obtain the correct decision.

In summary, in 17 behaviors, the dispute resolution mechanism of the present invention can correctly determine the wrong party and 1 correct behavior of 12 malicious behaviors, thereby verifying the effectiveness of the method of the present invention.

The invention constructs the service calling process as a trusted certificate after being signed by both the service consumer and the service provider, and records the trusted certificate in the historical database of the block chain in a transaction format, thereby ensuring the traceability of the service; when dispute occurs between the two service parties, the trusted certificate on the chain is obtained again for verification, and therefore the service trust is guaranteed. Meanwhile, in order to ensure the privacy of service data, the method carries out encryption processing on input parameters and results of the service in the process of constructing the trusted certificate.

The process or mode of use of the product.

In SOA, a service provider registers service, and the invention mainly completes automatic registration of service description information on a block chain.

The service discovery module is mainly responsible for completing the search of the target service according to the functional service requirement of a service consumer, and the module realizes the query function based on the block chain.

The service calling constructs a service calling parameter model and completes trusted service calling; and receiving and analyzing an output result of the service trusted execution.

Claims

1. A trusted SOA architecture based on blockchains is characterized in that in a framework, blockchains are introduced as a service registration agent and an evidence recorder, and a service provider agent and a service consumer agent are provided to automate and trust the processes of service registration, discovery, invocation and execution; for a given Web Service, a Service provider agent converts the Web Service into a Trusted Service description model Trusted Service supporting a Trusted SOA; the Service consumer proxy shields the difference between different Service description models, so that the Service consumer can use the Trusted Service description model in the original mode; based on the framework, the service calling flow is as follows: firstly, a service consumer encrypts calling parameters such as a calling process, service input parameters and the like, and then constructs a service calling request on the basis and sends the service calling request to a service provider; secondly, after receiving the calling request, the service provider decrypts the calling parameter and executes the corresponding service according to the service name and the input parameter in the calling parameter; finally, after the service execution is finished, the service provider encrypts the output result of the service and sends the encrypted result to the service consumer, and the service calling process is signed by the service consumer and the service provider and then used as a trusted certificate uplink; the service consumer can obtain the target value by decrypting the encrypted output result; when a service dispute occurs, a dispute resolution intelligent contract is triggered, and the contract is verified by reacquiring the trusted certificate on the chain, so that the service dispute is correctly processed.

2. The block chain-based trusted SOA architecture of claim 1, wherein the trusted service description model is described using definition 3-1 as follows:

3. The architecture of claim 2, comprising a service provider agent mechanism, wherein the service provider agent mechanism mainly comprises a service registration module and a service execution module; the service registration module mainly completes automatic registration of service description information on a block chain; the execution of the Web Service is abstracted into the invocation of the method; when the Service trust is not considered, the traditional Web Service only contains description information of the traditional Web Service, and the Service registration module converts the traditional Service description model Webservice into a trusted Service description model Trustedservice based on a block chain;

4. The block chain-based trusted SOA architecture of claim 3, comprising a service consumer proxy mechanism, wherein the service consumer proxy mechanism mainly comprises a service discovery module and a service invocation module; the service discovery module is mainly responsible for completing the search of the target service according to the functional service requirement of the service consumer; the module realizes the query function based on the block chain; the service calling module mainly completes two processes: firstly, constructing a service calling parameter model and completing trusted service calling; and secondly, receiving and analyzing an output result of the service trusted execution.

5. The architecture of claim 4, wherein the service trusted flow uses Pu to represent Public Key Public _ Key, PuA to represent Public Key of service provider, and PuB to represent Public Key of service consumer; pr denotes the Private Key Private _ Key, PrA denotes the Private Key of the service provider, and PrB denotes the Private Key of the service consumer:

step 10[ dispute resolution mechanism ]: when the service provider and the service consumer dispute the calling process or the output result (for example, the service consumer does not trust the output result returned by the service provider), the dispute presenter triggers a dispute contract, and the contract disputes the dispute; the dating verification verifies the identity Fabric-CA of the decision initiator, and ensures that the service provider and the service consumer can only judge the related calling process through the credible certificates related to the two parties without interfering with the calling process and the credible certificates of other nodes.

6. The block chain-based trusted SOA architecture as claimed in claim 5, wherein when a service consumer a and a service provider B generate a service dispute, a dispute presenter applies for arbitration in the last step, step 10, and a sanction intelligent contract deployed on the dispute presenter is triggered to execute to sanction involved in the invocation process.