## 4 Results
### Software Architecture
#### 4.1.1 Management Smart Contract  
A fundamental aspect of the proposed architecture is that each interaction between the three participants is managed via a smart contract. The management smart contract ensures that each communication step is digitally signed and documented on the blockchain. Consequently, our approach aims to ensure that any cloud configuration to be implemented is also stored on a smart contract. If configurations are directly written to the blockchain, any blockchain network participant could read them. This transparency would be a disadvantage when implementing confidential cloud application configurations. Therefore, cloud application configurations must be encrypted when stored. For this to occur, all communicating parties must have the ability to store and retrieve configurations in an encrypted form. Our approach utilizes the Diffie-Hellman key-exchange protocol [37] to ensure the creation of a shared encryption key for cloud configurations. The sequence diagram in Figure 4 and the smart contract's function description highlight the sequence used for creating a shared key via the management smart contract. As already mentioned, the management smart contract is a deployed smart contract, through which it is possible to (1) exchange public Diffie-Hellman values, (2) automatically and transparently store and retrieve cloud application configurations, and (3) store and track the cryptographic hash  
Figure 3: The general architecture of the proposed approach. values of committed cloud configurations. The cloud application provider initially creates the management smart contract on the blockchain. Following this step, the smart contract is then used by the provider, consumer, and application to configure the application. The basic functions of the smart contract are as follows:  
1. _Constructor(uint g, uint q, address cloudAppProvider, address cloudAppConsumer, address cloudApp)_: The _Constructor_ of the smart contract. The unsigned Diffie-Hellman \(g,q\in[1,q-1]\) must instantiate a new management contract. Moreover, the _Constructor_ expects the blockchain addresses for all three communicating parties. The values g and q are later used for creating a shared secret key between the communicating parties. The blockchain addresses of the cloud application provider (_cloudAppProvider_), the cloud application consumer (_cloudAppConsumer_), and the cloud application (_cloudApp_) are all employed for authenticating smart contract requests. All management smart contract requests are authenticated based on the provided digital signature of placed transactions. 2. _getSymmetricParameters():_ Returns the public Diffie-Hellman key-exchange values g and q. The values are initially set at the construction of the smart contract. 3. _setFirstSymmetricKey(uint value):_ Past research [38] has already shown that the Diffie-Hellman key-exchange protocol is vulnerable to man-in-the-middle (MITM) attacks; therefore, public keys should only be exchanged in an authenticated manner. The _setFirstSymmetricKey_ function ensures an authenticated first exchange of the public Diffie-Hellman keys. 4. _setSecondSymmetricKey(uint value):_ At the same time as the _setFirstSymmetricKey_ function, the _setSecondSymmetricKey_ function ensures an authenticated first exchange of the public Diffie-Hellman keys. 5. _getFirstSymmetricKey():_ Using the _setFirstSymmetricKey_ function, the public Diffie-Hellman keys are stored on the blockchain. The _getFirstSymmetricKey_ ensures that the set public keys can be retrieved from the blockchain. 6. _getSecondSymmetricKey():_ At the same time as the _getFirstSymmetricKey_ function, the _getSecondSymmetricKey_ function ensures that the public keys set with the _setSecondSymmetricKey_ function can be retrieved from the blockchain. 7. _setConfiguration(string c, string t)_: Using the Diffie-Hellman key-exchange protocol, a shared symmetric key \(s\) is created among the three communicating parties.