Service-oriented architecture (SOA) is a paradigm for organizing and utilizing distributed services that may be under the control of different ownership domains [1].
SOA provides a uniform means of offering, discovering, and interacting with and using services to produce desired effects consistent with measurable preconditions and expectations. Being service-oriented requires services to be only loosely coupled to operating systems and other technologies that underlie applications. SOA separates functions into distinct units, or services [8], which developers make accessible over a network so that users can combine and reuse them when producing applications. These services communicate with each other by exchanging data or by coordinating an activity between multiple services.
As SOA services are opened up, it is necessary to consider how to combine these services securely [11]. In many business domains, Web services must exhibit quality attributes such as robustness, security, and maintainability. Several emerging technologies and standards address different aspects of the problem of security of services in SOA. For example, standards such as WS-Security [12], SAML [13], WS-Trust [14], WS-SecureConversation [15], and WS-SecurityPolicy [16] focus on the security and identity management of SOA implementations that use Web services.
These standards have been created to address message-level security and provide the ability to satisfy security requirements within an SOA environment.
In the standard recommended by W3C, it is demanded to follow SOAP to communicate with Web service. In WS-Security recommended by OASIS, it specifies how to attach the XML digital signature to SOAP messages. The XML digital
signature lets XML messages possess the non-repudiation. It offers the confidentiality, integrity and requester’s identity of SOAP message. The clients need to follow the policies, WS-Policy and WS-SecurityPolicy, in WSDL defined by the service provider, and sign its messages correctly. However, these standards just offer the properties covered by XML digital signature. They cannot preserve the order of requests sent by different clients, and even prove the CIWF (confidentiality, integrity, write serializability, and read freshness) of the requested resource.
It has been proved that a XML message which includes the owner’s digital signature is non-repudiated. In existing fair non-repudiation researches, they proposed serveal protocols which let requester and responder both obtain the signed message.
Following the protocols, the participants can get the available messages to claim what has happened. It is a fair process, and no one can have the advantage. Many Web services providing the critical resources always ask the requesters who want to invoke their operations to sign their request messages. However, it is assumed that there are many different clients invoking the same Web service resource. The transaction messages may be interleaved. Althrough the signature can provide the non-repudiation of each message, the dispute about the temporl order is hard to be settled.
Serializability is the classical concurrency scheme and discussed at database domain. It ensures that a schedule for executing concurrent transactions is equivalent to one that executes the transactions serially in some order. It assumes that all accesses to the database are done using read and write operations. Besides the XML digital signature, it is needed to have another protocol to offer the serializability for SOA.
The digital forensic, it includes the investigation and recovery of material found in digital devices, often in relation to computer crime. When investigating needed evidences, it spends much effort on determining and collecting the available records.
The data is used to judge whether the defendant is guilty. However, it is an ever-discussing issue about how to investigate evidences in various network environments. Since Web service, SOA, and Cloud was announced, many researches proposed several solutions to help corresponding system collect and investigate records. A lot of them employ the inline or online third party services which monitor every system transactions. The third parties store the transferred messages or transaction logs. They can provide required records to settle the possibly dispute, moreover, they can make reports or alert administrator in the run-time. But, SOA and cloud environment are more flexible and adaptable than classical client-server architecture. They can bear unlimited and non-predicted numbers of service transactions including file transaction, message transaction, etc. If there is a third party which monitors whole system traffic. It is obvious that the third party will be the bottleneck of the system.
A Service-level agreement (SLA) refers to the contractual obligations between a cloud service provider and a service consumer (or client) [L.J. Jin, V. Machiraju, and
A. Sahai. Analysis on service level agreement of web services. In HP Lab Tech. Rep.,
2002].The SLA can document the promised quality of service (QoS) from a service
provider and the para-functional requirements of service delivery to the client. In a context of cloud services, the SLA denotes the requirements and capabilities of the services. SLA violation detection is a popular topic in recent researches. If there is a SLA violation detected, it is necessary to find the provenance of problem. Like the evidence investigation in digital forensic does, it needs a mechanism collecting enough data to settle dispute. Since the third parties are also needless, it can only demand the participants to preserve the appropriate attestations. When a dispute is occurred, these attestations from client-side and service-side can be gathered for a judgment. Once theproblem is determined, the participant who made the mistake should compensate others by the SLA.
In the advance research, it proposed a novel scheme, C&L scheme, which does not need any third party to participate in a cloud storage system. It employs digital signature and chain hash to offer the fail non-repudiation and serializability. When any participant doubts the order of executed operations, the complete evidences stored in both client-side and service-side can be used to prove the innocence of defendant. The architecture like C&L does not exist in recently SOA and cloud system standards. It can be applied to various services which have quantities of transaction and client which needs to resist roll-back attack from malicious service provider.
There is a simple example to demonstrate the leaking serializability problem about the same timestamp of messages, when a Web service resource has been modified by different clients simultaneously. In a contract, if a withdraw operation will let John’s Bank A balance be minus, Bank A will deposit the inadequate money into John’s account and charge a fee. It possibly has equivalent timestamps of the messages which records the withdrawing and depositing operations for John’s bank account. If the service of Bank A does not support serializability, no one can judge the temporal order of these messages. Bank A may rely on a third party service to provide the timestamp, e.g. Time Stamping Authority (TSA). But it possibly creates the same timestamp as well.
This chapter addresses the problem of the motivating example. It proposes a new scheme based on C&L offering non-repudiated and serialized transaction for SOA. A Web service with the new scheme does not require a registration in advance and can still provide the CIWF property for its resources. The new scheme is more suitable than C&L scheme for Web service and can be applied to any transaction-based system
in SOA or Cloud environment, e.g., E-mail service, shopping service, auction service, and message board service.
This chapter is organized as follows: Section 6-1 presents a new scheme modified from C&L scheme to support general systems in SOA, Section 6-2 discusses the architecture to process the new scheme, Section 6-3 presents the implementation details and experimental results, Section 6-4 describes related work.
6-1. A new protocol from C&L for SOA
In service-oriented architecture, Web service is the basic component. It uses SOAP as the standard communication protocol. According to WS-security specification, XML digital signature can be attached to SOAP. Although signature can guarantee the integrity, authentication, and non-repudiation, it is necessary to have another mechanism which helps the participants preserve and prove the sequence of their invocations. In the motivation introduced above, the timestamp is insufficient to show the temporal order. Even though there are logs stored in service-side. They are created by the service, and there is a risk of getting fake records. It requires a fair mechanism which lets clients and service provider have the same evidences for proving the invocation serialization.
The C&L scheme is a novel mutual nonrepudiation protocol. It considers the situation where multiple client devices need to access files in a single account while they do not exchange messages when performing file operations and do not have sufficient space to store all the user-side attestations. It uses four steps to provide an ability which can guarantees the CIWF for Cloud storage system. The participants have to apply for a local sequence number (LSN) to server before they use the system.
The LSN in the client request can defeat roll-back attack and replay attack. However, the cloud storage system is a part of transaction-based system in cloud. If there is a
Web service which has no reason to be registered in advance, it is needed to have another method to be instead of LSN.
This chapter proposes a double chain (DoubleC) scheme which does not initialize the LSN. In the last step of DoubleC scheme, client always get a latest attestation which includes two hash values from service. For convenience, we call the two hash values Main Chain Hash (MCH) and Client Chain Hash (CCH). Every Web service resource has its own MCH. Every client has its own CCH for each service resource. In the auditing phase, each of the clients who requested the same service resource provides its latest attestenation including its latest MCH and CCH. The collected
MCHs and CCHs can be used to determine the serialization violation of the service
resource operating sequense. Every client only needs to keep the latest attestation. The CCH in each attestation can defeat the roll-back attack from malicious service provider.The following steps abstractly describe how DoubleC scheme works:
Step 1. When a client of user U wants to access a resource in a Web service, the
client sends a request message Qi, where Qi={ OPi, ti, [OPi, ti]pri(U) }, to the service. Note that OPi specifies the required operation and resource, such as getting a resource, or modifying a resource. The ti is the time of message creating.Step 2. When the service receives Q
i, it verifies if this is a valid request message by checking the digital signature [OPi, ti]pri(U). If the message is acceptable, it prepares the corresponding attestations according to the requested resource and user ID in Qi. Finally, it sends a response message Ri, where Ri={ Si, Qi, tsi, CHi-1, CHj, [Si, Qi, tsi, CHi-1, CHj]pri(SP) }, to client. Note that CHi-1 is the MCH and CHjis the CCH. CH
i-1 is the digest value in thedigital signature of Ri-1 in ACKi-1. CHj is the digest value in the digital signature of Rj in ACKj. Assume ACKj is user U’s latest attestation provided from service. If user U is the (i-1)th requester, CHi-1 will be equal to CHj. Si is the snapshot of the expected result. For example, it could be a hash value of the client requiring resource or the result of determined access right.
Step 3. When the client receives R
i, it verifies if its digital signature is valid and makes sure that the CHj is valid. Note that the client can only check if the digital signature is valid; it cannot check if Ri is correctly chained to Ri-1(i.e. CHi-1
is correct or not correct). Because the client only keeps the latest
acknowledgement message ACKj received from the service provider, where j<i and j may not equal i-1. When the verification is successful, the client sends a reply-response message RRi to the service, where RRi={ Ri, [Ri]pri(U) }.Step 4. After service received RR
i, it executes commands in Qi. If the invocation is successful, the service sends an acknowledgement message ACKi to user U, where ACKi ={ Li, RRi, [Li, RRi]pri(SP) } and Li is the execution result. If the invocation is failed, there will be compensation between the client and service. Note that the service keeps all the ACK messages for when proofs are required.Step 5. When the client receives ACK
i, it verifies if the snapshot of Li is equal to Si.
If the result is false, client must demand service to revoke the invocation or start an audit.Below is an example to demonstrate DoubleC scheme. Assume that there are two clients wanting to modify the same Web service resource. The client owner’s IDs offered by their certificates are “User A” and “User B”, respectively.
Q1={ OP1, t1, [OP1, t1]pri(A) }
Figure 6-1: Messages for five operations of the same resource in DoubleC scheme As shown in Figure 6-1, there are three attestations for user A’s client: they are CH1, CH2, and CH4. In DoubleC scheme, the clients only have to preserve the latest attestations of their requesting sequence. If a client lost its attestation, it cannot audit the requesting sequence of a resource to service. The overhead for DoubleC scheme includes that service needs to find the latest CHi-1 and CHj which belongs to the requesting client. Each client keeps the latest acknowledgement messages supplied by the protocol.
Theorem 6-1: It is impossible for a service provider to launch a roll-back attack if we
apply DoubleC scheme.Proof: In the DoubleC scheme, the service must store a legal sequence of service-side attestations that conform with the following three requirements for each resource: [R1]
All the digital signatures are valid; [R2] The Client Chain Hash (CCH) in response
message in each service-side attestation is chained properly and the end of the chain is
the predefined initial chain hash; and [R3] The Main Chain Hash (MCH) in response
message in each service-side attestation is chained properly and the end of the chain is
the predefined initial chain hash. According to three requirements, R1, R2, and R3, the service cannot lose or insert any illegal service-side attestation without this being detected, because each client possesses the latest acknowledgement message received from the service. In the Step 3 of DoubleC scheme, the client cannot check whether the MCH in response message is correct, because it may not be the previous requester, but it can check if CCH is correct. That is according to requirement R2, the service has to correctly chain the CCH in each response message sent to client. The malicious service provider cannot launch a roll-back attack without being detected at proving or auditing time. QED
Assume that a malicious service provider tries to drop or hide some service-side attestations for the same resource from RRm to RRn. Frist, if the hidden attestations are existed in client-side, the misdeed can be detected at auditing time. Second, if a client sends Qp for starting a new invocation and the client has the latest CCH in ACKj, where m<j<n<p, it will cause failure in Step 3 of DoubleC scheme. Because clients knew their latest attestation, there is no doubt that the malicious service provider cannot provide the wrong CCH in the response message. However, if the malicious service provider still responses the correct CCH to the client and cheats other clients, the violation will be detected eventually at auditing time.
In another case, assume that a malicious service provider tries to change the order of some service-side attestations, for example, he tries to let { …, RRm+1, RRm+2, RRm+3, … } be { …, RRm+3, RRm+2, RRm+1, …}. However, he cannot fake the client signature in each RR. Each CCH is required to be verified by client in Step 3. The misdeed will be detected at runtime or auditing time as well.
In addition to mutual nonrepudiation, DoubleC scheme guarantees the service transaction serializability in SOA, because all the MCHs and CCHs for the same resource in response messages are properly chained.
6-2. Architecture of C&L and DoubleC schemes for SOA
operations which client requested to the service for its resources. Although a malicious service provider tries to hide some attestations, he cannot decrease or fake the LSN which only can be modified by its owner. It defeats roll-back and replay attack from the malicious service provider. Because the LSN is like a counter, any client is required to apply a LSN before they request the Web service. The C&L scheme can be applied to the particular Web service, but the LSN is not suitable for a public Web service.………
Figure 6-2: Architecture of C&L and DoubleC scheme for Web service
The difference between C&L scheme and DoubleC scheme is that the latter uses the CCH instead of the LSN. They all have to maintain a chain hash and store attestations. It is obvious that they can be operated in the same architecture. Figure 6-2
shows the architecture of both C&L and DoubleC schemes that supports a Web service in SOA. A Web service consists of a service operation port, and communicates with a
resource manager and a chain hash manager. The service operation port is the
connection point to the Web service. It is typically represented by a simple HTTP URL string. The clients invoke the service via the service operation port. The resourcemanager controls the resources provided by the Web service. It could be a database
management system, storage system, or web content management system. Whenservice operation port receives a request message Q
i, the service first checks the resource required by the client and verifies the signature. If the message is acceptable, it prepares the corresponding MCH, and CCH or LSN via the chain hash manager.The all attestations and LSN are maintained by the chain hash manager. If there are two or more clients requesting the same resource, the chain hash manager handles the concurrent accessing situation by a synchronization handler. For example, there are two request messages which request the same resource from client A and B. If the request of client A is received by the service first and the service is starting to prepare the Ri message to client A. Another request from client B is required to wait for client A’s operation complete. The simple blocking mechanism is used to guarantee the serialization of MCH. When service operation port receives a reply-response message RRi, the service executes the requested operation which could be a resource modification or gather.
Figure 6-3 is a SOAP message with WS-security. The SOAP Header includes the WS-security element following OASIS WS-security standard. WS-security element includes a XML digital signature element. In the signature, the signed value is a Base64 encoded signature result from digest value. The digest value is a hash value of the SOAP Body. It is considered that the SOAP Body is signed by the client, if client
encodes the digest value by its private key. In DoubleC scheme, the MCH and CCH are the digest values in signatures of corresponding Ri messages. The SOAP Body includes the contexts of Qi, Ri, RRi, and ACKi of both schemes.
SOAP envelope WS-security element
XML Digital Signature
SOAP BODY SOAP Header Digest value
Signed value
Figure 6-3: The SOAP message with WS-security
6-3. Implementation and experimental results
We used Apache Axis2 and Apache Rampart [29, 137] to build the Web service and SOAP with WS- security. The chain hash manager in Figure 6-2 and corresponding hash function were implemented in Java programming language. The each sample resource and corresponding attestations were XML files stored on hard drives of server. We conducted a series of experiments to demonstrate the differences of C&L scheme and DoubleC scheme. We measured the following: the sizes of ACK messages; the times required to prove the legality of a sequence of ACK messages in the both schemes; the average times required to perform a Web service operation with plain scheme, C&L scheme, and the DoubleC scheme.
The request, response, reply-response, and ACK messages were represented as SOAP in our implementation. Here we consider the size of some example ACK
messages in the C&L and DoubleC schemes. The ACK messages must be stored by the service provider before transferring to the next epoch. Table 6-1 indicates that the sizes of these messages increase linearly with their number and are very similar in the C&L and DoubleC schemes.
Table 6-1: Sizes of chained ACK messages (|ACK| is the number of messages)
Applied scheme see that the C&L scheme is slightly faster than the DoubleC scheme, which is due to the latter needing to verify if the CCH of each client ID are consecutive. In the auditing process of DoubleC, it temporary keeps the CCHs required to be verified of each client in the memory and verifies them when verifying the MCHs of each ACK message. The time complexity can be similar to O(1).
Table 6-2: Times (in ms) required to prove the legality of a sequence of ACK messages
Applied scheme service operations in the C&L and DoubleC schemes. We implemented a Web service operation involving the following steps: (1) the client sends a request message, (2) the service sends a response message, (3) the client sends back a reply-response message, and (4) the service provider performs the requested operation and sends an