## 4 Selection of Services
### An Example of Service Discovery and Dynamic Certification  
Let us assume that a web farm is supplying a secure storage service based on an _ad hoc_ security framework. The service is tested in a given context (_i.e._, on a physical machine), and CCerts are issued (_i.e._, static certification), containing evidence that all the tests have passed successfully (cf. Section 3). For the sake of simplicity, we consider a simple service implementing the concatenation of two strings, whose sequence diagram is presented in Figure 1.  
The service first receives as input the two RSA encrypted strings (_String a'_ and _String b'_), then decrypts the strings (_String a_ and _String b_) concatenating them (_String ab_), and finally encrypts the concatenated response using the RSA algorithm (_String ab'_). Such encryption is performed by the service itself and not by the container. The example can be easily reformulated in the case where the  
Figure 1: String concatenation service sequence diagram. container performs SOAP encryption according to WS-Security. In this scenario, it is the container that, using an ad-hoc component (e.g., Apache Rampart), is responsible for encrypting and decrypting the input strings and their concatenated version. In the following we consider the first scenario in which encryption and decryption are managed by the service implementation. Test cases in the service certificate assert the confidentiality of the response data by providing the encrypted response string, the key, and the input parameters used to compute the response. Suppose that the test suite includes some critical input parameters that may generate a service response too big for the local RSA implementation to encrypt. In fact, in the case of very long strings, their concatenation could exceed the number of characters accepted by the RSA implementation; furthermore, different systems could manage very long strings differently, having unpredictable results at client-side. In particular, those tests are to guarantee that no data leakage happens during the execution on the server, and that the information is secure at the application level during the entire exchange of messages between the clients and the service. Each time a user searches for a secure storage server certified for the \"Confidentiality\" property having the class attribute _MsgEncryption_ set to \"RSA\", the repository will return the certificate along with the property and the evidence of the tests applied to the service interface (_i.e._, triples \(<\)_encryptedtext_, _key_, _plaintext\(>\)_). The above discussion assumes static certification. However, there are cases in which changes in the service context and environment invalidate the certificates awarded to the service. As an example, consider a service provider rationalizing its software infrastructure, moving its storage service to the cloud. The service is instanced in a dedicated virtual machine and, from that moment on, the certification is no longer valid. In fact, moving the architecture to a virtualized system has added a new virtualization layer to it, and the encryption/decryption takes place on the same physical server hosting other containers and services. In this situation when a user asks for a string concatenation service with the confidentiality property on parameters, the original certificate can no longer be considered since the context has changed. The provider can dynamically re-create the certificate re-running the test suite enclosed in the certificate evidence, and obtain a certificate for the new context. Alternatively, re-certification can be carried out by the service user, executing the test suite in the old certificate in the new context. In principle, server-side re-certification may be preferable for two main reasons: (_i_) the re-certification process could be too heavy for common client infrastructures; (_ii_) online re-certification can represent a security threat for the service.