Dr.Ruan Anbang, CEO of Trias, built a separation of power model to solve the problem in its trusted security governance above cloud platforms. Based on this model, Trias uses the mutual cooperation and separation of the three powers to solve the existing problems of insufficient rights regulation on blockchain and smart contracts between the fully decentralized and fully centralized governance structure. As a result, it is making the power check and balance, so as to finally realize the fairness and justice of the information world.

In the previous article, we gave an overview of the separation of 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.

Figure 1: The Collaboration Model

CSE acts as the cloud services executing agency , it can meet customer requirements. TER, as the reporting agency of the trust evidence, is responsible for checking the cloud service behavior performed by CSE. SPD is responsible for defining the attributes of each software component of the cloud service as the definition of the software attributes.

Figure 1 describes the collaboration between the CSE, SPD and TER. To verify the credibility of the cloud service, users need to collect information separately from each role. TER provides a summary of execution, which records the cloud service information for the target application. CSE provides service list to declare the software composition of each cloud service; The SPD provides a definition list to authenticate each service component.

CSE service manifest lists the components of software that CSE loads to build cloud services. When using trusted computing, these components are identified based on their measurements, such as their configuration files or encrypted hash values of executable code. Meanwhile, the SPD translator will use a transformation function for each hash to hide the details of the implementation, ensuring that only the designated SPD can interpret the contents of the list. On the other hand, the SPD can also implement the transformation function as an encryption function, ensuring that only the designated SPD can decrypt the hash.

TER effectively identifies these cloud services by the total measurements of all its loaded software components, which are calculated by the trusted computing devices installed on each cloud service.

SPD maintains a certificate that records each property of a software component, and when a request for a query property is received, it returns to the definition ticket that binds the property list to the software component, which is identified by the converted hash value.

Using the collaboration model, cloud user U verifies the credibility of the cloud services that support its cloud application A through the following steps:

1. User U gets a summary of the execution of cloud application A in TER and checks its integrity;

2. For each TER abstract showing service information, user U requires CSE to provide corresponding service information list.

3. The user U compares the information in the CSE information list with the information of the cloud service’s real behavior to verify whether each information in the CSE provided list represents the real behavior of the cloud service detected by TER

4. After the information in the service information list is validated, user U interprets each entry by requesting the attribute certificate from the SPD. After it is converted to a property list, it is compared with the service level protocol to verify that the user is satisfied.

The collaboration model makes CSE dependent on two separate roles, which are defined and checked by independent third parties, because of the separation of TER from SPD, it prevents the credibility of CSE from being maliciously arbitrated. In SoP, TER can only get opaque aggregate hash values without knowing how to build a cloud application. Similarly, SPD can only know the properties of individual software components and cannot explain how cloud services are assembled. Therefore, without the service manifest of CSE, TER and SPD do not have enough information to explain the internal structure of the cloud, which gives the CSE the opportunity to control over access and expose its attributes to users.

In addition, in order to check the actual behavior of TER and SPD in SoP, more restrictions were imposed in the process, which will be further explained in the restricted model.