## 4 Results
### Software Architecture
#### 4.1.2 Cloud Management Script  
Our proposed software approach relies on a cloud management script to provide a solution independent of the selected cloud service model and vendor. The cloud management script must run on a cloud instance (i.e., a virtual machine in which the cloud application is deployed), and must have a data connection to (1) the blockchain, (2) the provided cloud application, and (3) the cloud management system. The cloud management script synchronizes with the management smart contract through the blockchain connection. The cloud management script uses a pull-or-push mechanism to monitor the _getFirstSymmetricKey_, _getSecondSymmetricKey_, and _getConfiguration_ functions for changes. Such a connection can usually be ensured using remote procedure calls (RPCs). The cloud management script requires a connection to the cloud application to process a detected application configuration. Consequently, through this connection, new configurations can be implemented. This connection can be ensured via a representational state transfer (REST) interface or an exchange directory. Moreover, the cloud management script requires connecting to the cloud management console. The cloud provider provides cloud management, and is used to configure existing cloud instances or deploy new cloud services. The cloud management script serves as the underlying configuration layer for cloud instances. For example, the cloud management script can change an existing cloud instance's memory or CPU capacity, or can launch another virtual cloud instance. The script can store and retrieve snapshots (the current state of a cloud instance). Generally, cloud providers offer a cloud management connection via an application programming interface (API) in a specific programming language, such as Python, (Power) Shell, or Ruby. Brokered by the cloud management connection, the script can store and retrieve snapshots (i.e., the current state of a cloud instance). Figure 4: Initial sequence diagram of negotiating a shared symmetric encryption key \(s\). Once the cloud management script obtains all three described connections, it needs to monitor the blockchain (through the blockchain connection) for changes in the smart contract. The monitoring may result in two main scenarios:  
The cloud management script detects a change triggered by the _getFirstSymmetricKey_ function within the first scenario. Consequently, a participant wants to change the secret key \(s\). Subsequently, the cloud management script performs the steps shown in Figure 4.  
The cloud management script detects modifications when triggered by the _getConfiguration_ function within the second scenario. Consequently, a participant wants to change a cloud application configuration. This scenario is shown in Figure 5. If the cloud management script detects such a change, it executes the _getConfiguration_ function of the monitored smart contract, and receives the ciphertext \(c\) and the corresponding authentication tag \(t\). Since the cloud management script has access to the secret symmetric key \(s\), it verifies the message tag \(t\) and decrypts the configuration to be implemented from c. Using the blockchain-cloud application connection, the cloud management injects the new configuration into the cloud application. Concurrently, the cloud application can also use this blockchain-cloud connection to provide feedback on the implementation status (or, alternatively, to monitor the log files). If the implementation fails, the cloud management script writes the implementation error to the blockchain via _setStatus_, terminates the cloud configuration, and continues monitoring the smart contract. Conversely, if the cloud application reports a positive status (i.e., the implementation of the configuration succeeded), the cloud management script uses the cloud management connection. The cloud management script triggers the execution of a snapshot from the current cloud instance through the cloud management system.