In the previous article, we gave an overview of the separation of three powers model. The Role Model defines three roles that implement the SoP; The Collaboration Model illustrates how the three roles collaborate to achieve cloud service certification; The Constraint Model executes constraints between three roles and the same role executors. In this article, we will discuss the Constraint Model, which can effectively prevent TER and SPD from gaining too much power and thus achieve the balance of power.
CSE plays the role of cloud service executive agency, which can effectively execute cloud services that meet customer requirements and responsible for providing service list to declare the software composition of each cloud service.
TER, as a trust evidence agency, is mainly responsible for checking the cloud service behavior performed by CSE and generating a summary of the execution based on this. These abstracts mainly record the identity information of cloud services loaded to meet the requirements of the target application.
SPD acts as a software property definer, whose job is to define the properties of each software component in the cloud service. Based on this, the property definition list is generated so that the components of each service can be authenticated.
Mutual-Check-Constraint Model above describes the process of mutual restraint between TER and SPD.
Multi-Constraint Model indicates that the CSE can employ multiple executors for each role, that is, the CSE can have multiple SPD to define its software component properties, or it can hire multiple TER to check its service execution.
The model indicates that the CSE can employ multiple executors for each role, that is, the CSE can have multiple SPD to define its software component properties, or it can hire multiple TER to check its service execution.
Let’s talk about two possible threats: failure and complicity
Failure
Failure means malicious act or accidental failure that occurs in a single role. Both TER and SPD may be in the wrong or untrustworthy state, and this failure may just cause the CSE’s behavior to be misinterpreted. In addition, since TER, SPD installation software all represent CSE infrastructure, their misbehavior could further trigger internal attacks. Therefore, SoP introduces two Constraint Models of Mutual-Check-Constraint Model and Multi-Constraint Model.
The Mutual-Check-Model in Figure 1 describes the constraints between TER and SPD. Let’s look at the process. First, SPD defines the inspector’s properties so that CSE can verify the inspector’s behavior. Second, CSE is responsible for verifying the true execution of the inspector and returning the inspector’s measurements each time the authentication is performed, so that both CSE and users can know if the inspector is running correctly. However, a malicious TER can still tamper with the execution summary to get the inspector to return an error measure. More ominously, the untrusted SPD may also forge the wrong attribute definition list and assign good attributes to the malicious inspector. To solve this problem, we can introduce Multi-Constraint Model.
We mentioned above‘Multi-Constraint Model indicates that the CSE can employ multiple executors for each role, that is, the CSE can have multiple SPD to define its software component properties, or it can hire multiple TER to check its service execution.’ From this, we introduce competition and constraints between parties in the same role. In more detail, the measurements of one inspector will be checked by another, and the attributes of the inspector will be defined by multiple SPD.
Through restraint and examination between SPD, TER and multiple competitors of each role, the existing situation of trusted third-party exclusive discourse right and opaque behavior is finally broken.
Complicity
Complicity refers to the situation in which the parties maliciously cooperate in order to evade SOP inspections. TER and SPD, if complicit, would cause CSE to misjudge the behavior of meeting service-level agreements. On the other hand, SPD and CSE co-conspirators would cause CSE’s behavior to be interpreted as satisfying the service level agreement even if TER recorded its actual performance.
In SoP, users make their applications select the combination of CSE-TER-SPD, in which case any untrusted executors will cause the entire combination to be discarded in order to reduce the probability of complicity. Meanwhile, multi-party constraints allow users to verify the credibility of CSE through multiple TER or SPD. Therefore, CSE not only needs to employ more credible TER and SPD, but also needs to choose different TER and SPD to enrich the combination of CSE-TER-SPD, so as to attract more users.
