TRUST RELATIONS IN SERVICE ENVIRONMENTS

Figure 7.1: Distributed Trust Scenario

the platform provider treats the information sent to the service as confi-dential and that the platform does not snoop on the information exchange between the service and the consumer. The consumer can also trust the platform for service integrity, i.e., that the platform does not tamper with the service. Trust assumptions could be adapted based on the reputation of platform providers (as is the case for major platform providers such as Amazon Web Services, Google marketplace, Windows Azure, etc.).

However in this scenario, consumer’s trust relations with the CA and with the platform are independent of each other: the trust of the consumer on the certification authority for assessing a service properly and the trust of the consumer on the platform provider do not depend on each other.

Because of this independence, there is a clear threat that the most critical entity – the service – could mislead the consumer by getting a certain im-plementation of the service certified while serving another version to the consumer, masquerading the latter version as the certified version of the service. Of course, this scenario is based on the assumption that the ser-vice provider is not trusted, as there is no use for certification if the serser-vice provider is already trusted by the consumer.

7.1.2 Distributed Trust & Delegated Monitoring

Another approach is shown in Figure 7.2 where trust is still distributed, but involving a mesh of trust relations:

• The consumer trusts the CA for following the right procedures to cer-115

Figure 7.2: Distributed & Delegated Trust Scenario

tify the service as well as for monitoring the service operation all along its lifecycle

• The CA trusts the platform provider for not being malicious and for not tampering with the service that is deployed and certified; addi-tionally the CA monitors the service through the technical means that the platform provides to the CA.

• The consumergainstrust on the platform provider for not being ma-licious because the CA trusts the platform provider

This approach has the advantage that the robustness of the certificate binding can be ensured at every instance of the service invocation, thereby eliminating the need to trust the service provider. In addition, the CA can verify the operational environment’s integrity through the monitor. How-ever, there is still a strong assumption that both the consumer and the CA trust the platform provider for not being malicious.

7.1.3 Centralized Trust Scenario

Finally, a third approach to gain security assurance over the OE is through the certification of the entire service stack (Service along with the OE) by distributing the trust between the Certification Authority (CA), the Plat-form Provider (PP) and the Service Consumer (SC) as shown in Figure 7.3.

In such scenario, the consumer trusts only the certification authority for following the proper processes for certifying a service and to monitor the service – and its execution environment, which is controlled by the platform provider – throughout the service lifecycle.

7.1. TRUST RELATIONS IN SERVICE ENVIRONMENTS

Figure 7.3: Centralized Trust Scenario

Certification Authorities can monitor the platform through purely tech-nical means such as based on audit logs that are protected using Trusted Platform Module (TPM) [138]. In the case of service certification, the TPM should be used to protect a secure audit trail used by the platform to record any security relevant action performed either by the the service provider (e.g., deployment of another version of the service) or by the platform provider (e.g., change of some security relevant configurations on the soft-ware stack). The TPM allows the CA to check if the service implementation has not changed and the underlying architecture is still the same as the one considered at certification time. In other words, if a snapshot of the service implementation and the underlying software stack is certified, the TPM al-lows the CA to ensure that the service instance that is offered to consumers conforms to the version that was certified. However, this approach has two major drawbacks:

1. It requires the platform providers to add a TPM on every node in their cloud infrastructures, which is not always feasible. In addition, the technical overhead to maintain such a large network of TPMs and the associated costs hinder organizations such an approach.

2. It requires to ensure that the platform provider always registers secu-rity relevant activities on the audit trail that is protected by the TPM.

In other words, the TPM can ensure the integrity of the audit trail, however, it cannot force the platform provider to log the relevant in-117

Figure 7.4: Simplied illustration of a Service and its Operational Environ-ment

formation in the audit trail, which is necessary in a scenario where the platform provider may be malicious. Hence, this approach still has an undercurrent, implicit assumption that the platform provider is not malicious.

In addition, there are several other technical mechanisms that can be used by certification authorities to monitor the platform such as verifiable proofs[160].

The technical mechanisms based on TPMs or other such approaches help to reduce the implicit trust assumptions between entities and establish trust based on verifiable facts.