d3.1 version for pcc - cordis · document)name:)d3.1)core)certification)mechanisms)v1)...

Document name: D3.1 Core Certification Mechanisms v1 Version: 1.0

Security: Public

Date 27/09/2013

/134

Project Acronym: CUMULUS Project Title: Certification infrastrUcture for MUlti-‐Layer cloUd Services Call identifier: FP7-‐ICT-‐2011-‐8 Grant agreement no.: 318580 Starting date: 1st October 2012 Ending date: 30th September 2015

D3.1 Core Certification Mechanisms

AUTHOR(S): Maria Krotsiani (CITY), Khaled Mahbub (CITY), George Spanoudakis (CITY), Francesco Zavatarelli (UNIMI), Maria Rosa Vieira (ATOS), Antonio Maña (UMA), Antonio Muñoz (UMA), Rajesh Harjani (UMA), Carlos Sánchez(WELL),

Konstantinos Mantzoukas (CSA), Matthias Junk (IFX)

REVIEWERS(S): Rodrigo Diaz (ATOS), Stelvio Cimato (UNIMI)

PROPRIETARY RIGHTS STATEMENT This document contains information, which is proprietary to the CUMULUS consortium. Neither this document nor the information contained herein shall be used, duplicated or

communicated by any means to any third party, in whole or in parts, except with prior written consent of the CUMULUS consortium.

Ref. Ares(2015)360096 - 29/01/2015


Security: Public

Date 27/09/2013

/134

Summary

Executive Summary ..................................................................................................................... 6

1. Introduction ......................................................................................................................... 7

2. CUMULUS Infrastructure ...................................................................................................... 7

3. Related Standards ................................................................................................................ 9 3.1. Testing standards and tools ......................................................................................................... 9 3.2. Monitoring standards and tools ................................................................................................ 10 3.3. Trusted Computing standards and tools .................................................................................... 11

4. Monitoring Based Certification Mechanisms ....................................................................... 12 4.1. Overview of Implementation .................................................................................................... 12 4.2. Supported Use Cases ................................................................................................................. 16 4.3. Architecture .............................................................................................................................. 17 4.4. Components .............................................................................................................................. 22

4.4.1. Certification Manager ................................................................................................................ 22 4.4.2. Monitoring Manager .................................................................................................................. 24 4.4.3. Detailed Evidence Manager ....................................................................................................... 25 4.4.4. Aggregation Manager ................................................................................................................ 25 4.4.5. Certification Communicator ...................................................................................................... 25 4.4.6. Certificate Generator ................................................................................................................. 26 4.4.7. Event Captors ............................................................................................................................. 26 4.4.8. Monitoring Module .................................................................................................................... 29 4.4.9. Event Bus ................................................................................................................................... 30 4.4.10. Evidence Database ................................................................................................................... 32 Detailed Evidence .................................................................................................................................... 32 Sender ..................................................................................................................................................... 33 Receiver ................................................................................................................................................... 33 Notifier .................................................................................................................................................... 34 Aggregated Evidence ............................................................................................................................... 34 4.4.11. Certification Model Database .................................................................................................. 36 4.4.12. Certificates Database ............................................................................................................... 36 4.4.13. CTP ........................................................................................................................................... 37 4.4.14. Monitoring Dashboard ............................................................................................................ 44

4.5. Future enhancements ............................................................................................................... 47

5. Test Based Certification Mechanisms .................................................................................. 47 5.1. Overview of Implementation .................................................................................................... 47 5.2. Offline testing ........................................................................................................................... 48

5.2.1. Design ........................................................................................................................................ 51 5.2.2. Implementation ......................................................................................................................... 51 5.2.3. Examples of use ......................................................................................................................... 51

5.3. Online testing ............................................................................................................................ 51 5.3.1. Design ........................................................................................................................................ 53


Security: Public

Date 27/09/2013

/134

5.3.2. Implementation ......................................................................................................................... 53 5.3.3. Examples of use ......................................................................................................................... 54

5.4. Supported Use Cases ................................................................................................................. 54 5.5. Architecture .............................................................................................................................. 56 5.6. Components .............................................................................................................................. 58

5.6.1. Testing Manager ........................................................................................................................ 58 5.6.2. TestCertification Manager ......................................................................................................... 59 5.6.3. Testing Module .......................................................................................................................... 60 5.6.4. Testing Agent ............................................................................................................................. 61

5.7. Open issues and future enhancements ...................................................................................... 62

6. Trusted Computing Mechanisms ......................................................................................... 62 6.1. Overview of Implementation .................................................................................................... 62 6.2. Supported Use Cases ................................................................................................................. 65 6.3. Architecture .............................................................................................................................. 66 6.4. Components .............................................................................................................................. 70

6.4.1. TPMSimulator ............................................................................................................................ 70 6.4.2. TPMVisualizer ............................................................................................................................ 72

6.5. Future enhancements ............................................................................................................... 73

7. Conclusions ........................................................................................................................ 73

References ................................................................................................................................ 74

Appendix A: Monitoring Mechanisms ........................................................................................ 77 A.1 Installation Instructions ................................................................................................................. 77 A.2 Example Scenario and Usage Instructions ...................................................................................... 81

A.2.1 Example Scenario ........................................................................................................................... 81 A.2.2 Usage Instructions for Monitoring Based Certification .................................................................. 84 A.2.3 Usage Instructions for CTP ............................................................................................................. 91

Appendix B: Testing Mechanisms .............................................................................................. 98

Appendix C: Trusted Computing Mechanisms ............................................................................ 99

C.1 TPM Installation .................................................................................................................. 99 Host Computer .................................................................................................................................. 103

C.1.1 Installing Debian on the Raspberry pi .......................................................................................... 104 o Compiling and patching a new Kernel for Raspberry pi ................................................................ 104 o Using the TPM with Trousers ...................................................................................................... 106 o Create an openssl certificate ....................................................................................................... 108 o Create an GnuTLS certificate ....................................................................................................... 110

§ Installation ...................................................................................................................................... 110 o Generate a Certificate with GnuTLS ............................................................................................. 112

Appendix D: Evidence XML Schema ......................................................................................... 115

D.1 Detailed Evidence XML Schema ......................................................................................... 115


Security: Public

Date 27/09/2013

/134

D.2 Aggregated Evidence XML Schema .................................................................................... 121

Appendix E -‐ Examples of Certification Model and Certificate XML Representation ................. 125

E.1 Example of Certification Model XML Representation ......................................................... 125

E.2 Example of Certificate XML Representation ....................................................................... 132

Glossary .................................................................................................................................. 134

List of Figures Figure 1 – CUMULUS Infrastructure ...................................................................................................................... 8 Figure 2 – Life cycle Model for Monitoring Based Certificates ................................................................ 14 Figure 3 – Monitoring Architecture ..................................................................................................................... 20 Figure 4 – UC_1 Sequence Diagram ..................................................................................................................... 20 Figure 5 – UC_2 Sequence Diagram .................................................................................................................... 22 Figure 6 – Certification Manager .......................................................................................................................... 22 Figure 7 – Monitoring Manager ............................................................................................................................. 24 Figure 8 – Certification Communicator .............................................................................................................. 25 Figure 9 – Certificate Generator ............................................................................................................................ 26 Figure 10 – Event Captor .......................................................................................................................................... 27 Figure 11 -‐ Event format sent from the Event Captor to the Event Bus .............................................. 28 Figure 12 – Monitoring Module ............................................................................................................................. 29 Figure 13 – org.slasoi.common.messaging.pubsub.PubSubManager ................................................... 31 Figure 14 – PubSubMessage class ........................................................................................................................ 32 Figure 15 – Simplified example of the CTP API .............................................................................................. 38 Figure 16 – Monitoring Dashboard interaction .............................................................................................. 45 Figure 17 – Monitoring Dashboar Frontpage .................................................................................................. 45 Figure 18 – Interface for selecting target of certification .......................................................................... 45 Figure 19 – The user selects security properties ........................................................................................... 46 Figure 20 – Generation of the certificate ........................................................................................................... 46 Figure 21 – Retrieving a certificate ...................................................................................................................... 46 Figure 22 – Confidentiality Certificate .............................................................................................................. 50 Figure 23 – Testing Components .......................................................................................................................... 56 Figure 24 – Testing Scenario (Offline, Confidentiality in transit for a WS toc) ................................ 57 Figure 25 – Testing Scenario (Online, Confidentiality in transit for a WS toc) ................................. 57 Figure 26 – Testing Scenario (Offline, Confidentiality at rest for a VM toc) ...................................... 58 Figure 27 – Testing Scenario (Online, Confidentiality at rest for a VM toc) ...................................... 58 Figure 28 – Certificate use for TPM based certification .............................................................................. 66 Figure 29 – Conceptual Binding Scheme ........................................................................................................... 67 Figure 30 – New Certification Approach ........................................................................................................... 68 Figure 31 – Semantic based certificate usage ................................................................................................. 70 Figure 32 – TPM Simulator Class Diagram ....................................................................................................... 71 Figure 33 – Serial to USB ........................................................................................................................................... 99 Figure 34 – Raspberry Pi Expansions .............................................................................................................. 100 Figure 35 – TPM Expansion Header ................................................................................................................. 101 Figure 36 – TPM Pin assigments ........................................................................................................................ 102 Figure 37 – TPM on Raspberry pi ......................................................................................................................... 102


Security: Public

Date 27/09/2013

/134

Figure 38 – TPM related software ....................................................................................................................... 106 Figure 39 – Detailed Evidence XML Schema ................................................................................................. 115 Figure 40 – EventIdType ....................................................................................................................................... 116 Figure 41 – EventTime ........................................................................................................................................... 116 Figure 42 – EventNotifier ...................................................................................................................................... 117 Figure 43 – EventSource ........................................................................................................................................ 117 Figure 44 – InteractionEventType .................................................................................................................... 118 Figure 45 – MonitoringResultEventType ....................................................................................................... 119 Figure 46 – PreconditionResultEventType ................................................................................................... 120 Figure 47 – InfrastructureMonitoringEventType ...................................................................................... 120 Figure 48 – EventMetaDataType ....................................................................................................................... 121 Figure 49 – Aggregated Evidence XML Schema .......................................................................................... 121 Figure 50 – ReportInfoType ................................................................................................................................. 122 Figure 51 – MonitoringResultEventType ....................................................................................................... 123 Figure 52 – AssessmentResultSummaryType .............................................................................................. 124 Figure 53 – FunctionalAggregatorResultType ............................................................................................. 124

List of Tables Table 1 – UC_1 Certificate Generation ................................................................................................................ 16 Table 2 – UC_2 Certificate's Retrieval ................................................................................................................. 17 Table 3 – TOCs and Security Properties for the Test-‐based scenarios. ............................................... 48 Table 4 – Raspberry Expansion Connector Signals ................................................................................... 102


Security: Public

Date 27/09/2013

/134

Executive Summary In this deliverable, we provide a description of the initial implementation of the core mechanisms that

are required for the generation of certificates by the CUMULUS infrastructure. These include: (a) monitoring mechanisms which are used for the generation of certificates based on the monitoring data: (b) testing mechanisms which are used for the generation of certificates based on static and dynamic testing data, and (c) trusted computing mechanisms which are used in order to enable the binding of certificates to the cloud services that they refer to and the validation of bound certificates by service clients when the latter wish to use the services. The deliverable includes also a description of two additional components of the CUMULUS infrastructure. These are a dashboard providing access to monitoring based certification components, and an implementation of the Cloud Trust Protocol (CTP) that is used to provide programmatic access to evidence underpinning certificates which is stored in the Cumulus infrastructure. The implementation of the above components has been focused on specific use cases in the overall CUMULUS architecture, notably the use cases regarding the generation and retrieval of certificates from the framework, and offers an initial realisation of these use cases. The components described in this document can be downloaded, installed and used according to the guidelines given in the deliverable.


Security: Public

Date 27/09/2013

/134

1. Introduction The overall vision of CUMULUS is to produce an integrated framework of models, processes and tools to

enable the certification of security properties of services at all layers of the cloud stack using different types of evidence demonstrating the preservation of the required properties. The types of evidence, which have been envisaged for the CUMULUS framework, include monitoring data, testing data and information extracted from trusted computing modules (chips).

In this deliverable, we provide a description of the initial implementation of the core mechanisms that are required for the generation of certificates by the CUMULUS infrastructure. These include:

1. monitoring mechanisms which are used for the generation of certificates based on the monitoring data,

2. testing mechanisms which are used for the generation of certificates based on static and dynamic testing data, and

3. trusted computing mechanisms which are used in order to enable the binding of certificates to the cloud services that they refer to and the validation of bound certificates by service clients when the latter wish to use the services.

The deliverable includes also a description of two additional components of the CUMULUS infrastructure, namely:

1. dashboard providing access to monitoring based certification components, and

2. an implementation of the Cloud Trust Protocol (CTP) that is used to provide programmatic access to evidence underpinning certificates which is stored in the CUMULUS infrastructure.

The design and implementation of the core certification mechanisms has been based on the architecture of the CUMULUS infrastructure that was defined in deliverable D5.1 (CUMULUS, D5-‐1) and the certification meta model and certification model specification schema that have been defined in deliverable D2.2 (CUMULUS, D2-‐2). The development of the mechanisms introduced in the deliverable has also been driven by the use cases specified in deliverable D6.1 (CUMULUS, D6-‐1). In particular, our initial implementation has focused on the use cases related to the generation and retrieval of certificates.

The remaining of this deliverable is structured as follows. In Section 2, we provide a brief overview of the CUMULUS infrastructure in order to enable the reader understand the overall context within the implementation of components described in this deliverable has taken place. In Section 3, we provide a brief overview of the standards that have been used in implementing different mechanisms. In Section 4, we describe the core mechanisms for generating certificates based on monitoring evidence. In Section 5, we describe the core mechanisms for generating certificates based on testing evidence. In Section 6, we describe the core mechanisms for utilising trusted computing proofs in the generation, binding and validation of certificates prior to their use.

2. CUMULUS Infrastructure One of the main overall objectives of the CUMULUS project is to build a novel infrastructure supporting

the certification of multi-‐layered cloud services. This infrastructure will provide models, processes and tools supporting the certification of compliance and security properties of all types of cloud services, i.e., infrastructure (IaaS), platform (PaaS) and software services (SaaS), through the use of multiple types of evidence including testing, monitoring and trusted computing proofs. It will also support incremental certification, if necessary.

The utilisation of multiple types of evidence for producing security certificates is necessary as the assessment of certain security properties in clouds might be possible only through a combination of such evidence types. Trusted Computing (TC) proofs, for instance, can assess the trustworthiness of the lower


Security: Public

Date 27/09/2013

/134

hardware level of the cloud stack. Consequently, combining certificates underpinned by TC proofs with others based on testing and monitoring provides a comprehensive trust chain for covering further properties as well as hierarchically dependent services in higher layers of the cloud stack.

The integration of results of different types of evidence in the CUMULUS infrastructure will be based on hybrid certification models supporting the identification of gaps arising from evidence from a specific verification method (testing/monitoring/TC) and finding ways of filling them by evidence from other methods. Test based certificates of software services that have been issued under certain operational conditions can, for example, be combined with monitoring data acquired in cases where the related conditions are violated to produce extended hybrid certificates for the properties of interest. Also, the test plan that has been used to produce the original certificate may provide the basis for assessing the length of monitoring activity required to validate the certificate under new conditions at run-‐time. Similarly, a hybrid certification model may support the combination of evidence coming from TC-‐proofs with other testing and/or monitoring based certificates. A TC proof can, for instance, provide evidence that an infrastructure configuration upon which a service instance runs is the same as the one for which the service was originally tested. In certain cases, the integration of evidence requires also the ability to combine existing certificates and freshly acquired raw evidence from all layers of the cloud stack to produce composite certificates. In the context of the CUMULUS infrastructure, the expectation is that the integration of evidence in such cases will be handled by multi-‐layer certification models. The CUMULUS infrastructure will also support incremental certification. Incremental certification is needed to address a major limitation of traditional certification processes, namely their inability to cover changes that affect certified properties without having to re-‐certify from scratch. Incremental certification can be supported by continuous monitoring of cloud services to ensure the validity of previously verified properties following changes in the stack (e.g., deployment of new middleware and service instances). Certification based on continuous monitoring can achieve an awareness of the operational context that is hard to obtain with static certification techniques such as testing.

FIGURE 1 – CUMULUS INFRASTRUCTURE

A conceptualization of the CUMULUS infrastructure is shown in Figure 1. The infrastructure includes: (a) security and certification models; (b) components producing core test, monitoring and trusted computing based certifications as well as multi-‐layer and components producing incremental and hybrid certifications; (c) components providing certification related evidence from clouds (test and monitoring services and


Security: Public

Date 27/09/2013

/134

trusted computing platforms); (d) an interaction protocol for the provision of certification evidence; and (e) tools supporting the engineering of cloud services that can make use of the infrastructure. The infrastructure can be used by cloud certification authorities to generate certificates for SaaS, PaaS and IaaS services.

The components that we describe in the rest of this deliverable offer an initial implementation corresponding to the parts of the CUMULUS infrastructure, which have been identified as Test Based Certification, Monitoring Based Certification, Trusted Computing Based Certification, and Certification Models. They have also been integrated with pre-‐existing components enabling the monitoring of cloud services, namely the Event Reasoning Toolkit (EVEREST) (Mahbub 2011), and include an implementation of event captors that enable the transmission of monitoring results from cloud servers to the infrastructure. They also provide an initial implementation of the basic Cloud Trust Protocol, although the current implementation of this protocol is used to extract certification data from the CUMULUS infrastructure itself rather than the monitoring components that exist on cloud infrastructures.

The initial implementation does not cover the part of the infrastructure identified as Multi-‐layer and hybrid certification. Components that will realise this part of the infrastructure will be developed in the subsequent years of the project.

3. Related Standards In this section, we provide an overview of standards developed prior to CUMULUS and which have been

used in the implementation of the components of the CUMULUS framework that we discuss in this deliverable. These include testing standards, monitoring standards and trusted computing standards. The relevant standards under each of these categories are overviewed in the next three subsections.

3.1. Testing standards and tools

Standards consist of terms, concepts, data formats, document styles and techniques agreed upon by software or service creators so that their products can understand data created by a different vendor. Historically, standards have been the result of an agreement between regulatory authorities, customers and technology suppliers at a national or international level and the emergence of standards has been crucial to ensure interoperability among different brands of software products or services.

Informally, software development can be defined as the process of designing and implementing a software product, which meets some functional and non-‐functional user requirements. In turn, software testing can be defined as the process of validating a software product’s functionalities, and, even more importantly from our point of view, of verifying that the software has all the desired non-‐functional properties (performance, robustness, security and the like) its users expect. Hopefully, the testing process will also reveal the software product’s defects.

In practice, software testing is performed as an iterative process: in each iteration some tests are designed and executed to reveal software problems and the detected problems are fixed. The test process is also composed of several activities: the first step is test planning, when the software functions (also called test objects) to be tested are identified; then during test case investigation the test cases for these test objects are created and described. The last step is test execution when test scripts are executed to feed the test cases. De-‐facto testing standards often take in account this process describing in details the various testing phases and supplying frameworks to follow the methodology.


Security: Public

Date 27/09/2013

/134

Software testing in the cloud changes the traditional testing scenario: the cloud computing infrastructure provides the resources to reduce test execution time, increase the test efficacy and improve the overall quality of the process. But testing in the cloud also relies on distributed environments, service-‐oriented architecture (SOA), and hardware virtualization; furthermore, some business applications may not be already available in SaaS mode, while others need heavy changes to undergo the full testing process and these changes could be too onerous. However, when appropriate, testing in the cloud can provide significant benefits. Ultimately, the decision to migrate testing to the cloud is managerial with many business, technical and operational issues. In this Section we cite frameworks, programs, guidance documents and best practices that provide a standardized approach to test cloud products and services.

Since migrating testing to the cloud can be challenging it could be useful to utilize frameworks that help in such a process: among the emerging tools on the market for testing Web Services we cite QTP (QuickTest Professional User Guide s.d.), Parasoft SOATest (Lanowitz, Theresa 2002) and SOAP UI (Kankanamge 2012) . We focused on SOAP UI for our demo in CUMULUS project.

SOAP UI is a new and open-‐source testing tool based on free standards, such as XML and XPATH, and works with SOAP and REST web services. SOAP UI performs Web Service testing operation like regression testing, test automation and load testing. SOAP UI is an open-‐source tool, but there is also a commercial version; the two versions however do not differ much, the latter has a few templates for common assertions and a more visually oriented way of creating and executing test cases. Among the functionalities of SOAP UI there are the creation of new projects using only the web service WSDL link (from the WSDL link, SOAP UI will get the details of all methods and import them automatically), the creation of test cases directly from the web method request, the possibility to test web methods separately or in combination, the validation on the web method results through assertions (the assertions can be created either in XPATH or XQUERY).

3.2. Monitoring standards and tools

There are several available commercial solutions related to cloud monitoring that allows monitoring metrics and events for the entire cloud. Some of these solutions will be summarized below in this section, namely: Zenoss and Rackspace.

Zenoss1 tool allows to add the CloudStack and/or Citrix CloudPlatform to the system along with all of its associated zones, pods, clusters and VMs. Then, the monitoring task will start after the discovery is completed. Once the cloud is added, Zenoss will begin to check the following metrics available for the entire cloud. These numbers are aggregated from all zones, pods, clusters and hosts.

Note: Public IPs: Total and Used

Note: Private IPs: Total and Used

Note: Memory: Total (with and without over-‐provisioning), Allocated and Used

Note: CPU: Total (with and without over-‐provisioning), Allocated and Used

Note: Primary Storage: Total (with and without over-‐provisioning), Allocated and Used

Note: Secondary Storage: Total and Used

Note: Network: Read and Write

The same list of metrics is available for each zone. The same metrics with the exception of public IPs and secondary storage are also available for each pod.

The following metrics are available aggregated to each cluster, and for each host.

1 http://wiki.zenoss.org/ZenPack:CloudStack


Security: Public

Date 27/09/2013

/134

• Memory: Total and Used

• CPU: Total (with and without over-‐provisioning), Allocated, Used and Cores

• Network: Read and Write

Zenoss will also automatically receive all CloudStack alerts as events. Clients will also automatically receive all CloudStack events. However, the events will go straight into the event history by default.

Rackspace Cloud Monitoring2 is an API-‐driven cloud service built for infrastructure monitoring. It analyses cloud services and dedicated infrastructure using a simple, yet powerful API (RESTful web service interface). Rackspace allows monitoring websites and applications —whether they're hosted on the Rackspace Cloud, Rackspace dedicated servers, servers in customer data centre or even other service providers. It sends alerts3 to customer’s laptop or smartphone, or automatically raises a ticket with Rackspace. When an alarm occurs on a monitored resource, Rackspace Cloud Monitoring sends customer a notification so that he can take the appropriate action to either prevent an adverse situation from occurring or rectify a situation that has already occurred. These notifications are sent based on the severity of the alert as defined in the notification plan.

3.3. Trusted Computing standards and tools

A Trusted Platform Module (TPM) is an implementation of a defined set of capabilities that is intended to provide authentication and attestation functionality for a computing device, and protect information by controlling access to plain-‐text data. A TPM is self-‐sufficient as a source of authentication and as a means of enhancing the protection of information from certain physical attacks. A TPM requires the cooperation of a Trusted Computing Group (TCG) “Trusted Building Block” (outside the TPM, that is also part of the computing device) in order to provide attestation and protect information from software attacks on the computing device. Typical TPM implementations are affixed to the motherboard of a computing device (such as a PC, a laptop, a PDA, a mobile phone). A computing device that contains both a TPM and a Trusted Building Block is called a Trusted Platform. Trusted Platforms offer improved, hardware-‐based security in numerous applications, such as file and folder encryption, local password management, S-‐MIME e-‐mail, VPN and PKI authentication and wireless authentication for 802.1x and LEAP.

A TPM owns shielded locations (i.e. no other instance but the TPM itself can access the storage inside the TPM) and protected functionality (the functions computed inside the TPM cannot be tampered with). The TPM can be accessed directly via TPM commands or via higher layer application interfaces (the TCG Software Stack, TSS). The TPM offers two main basic mechanisms: It can be used to prove the configuration of the platform it is integrated in and applications that are running on the platform, and it can protect data on the platform (such as cryptographic keys). These mechanisms can be performed by means of the crypto co-‐processor, hash and HMAC algorithm, key generator, etc, provided by TPM.

In order to prove a certain platform configuration, all parts that are engaged in the boot process of the platform (BIOS, master boot record, etc) are measured (i.e. some integrity measurement hash value is computed), and the final result of the accumulated hash values is stored inside the TPM in a so-‐called Platform Configuration Registers (PCR). An entity that wants to verify that the platform is in a certain configuration requires the TPM to sign the content of the PCR using a so-‐called Attestation Identity Key (AIK), a key particularly generated for this purpose. The verifier checks the signature and compares the PCR values to some reference values. Equality of the values proves that the platform is in the desired state. Finally to verify the trustworthiness of an AIK’s signature, the AIK has to be accompanied by a certificate

2 http://www.rackspace.co.uk/cloud-monitoring/ 3 http://docs.rackspace.com/cm/api/v1.0/cm-devguide/content/Concepts.html


Security: Public

Date 27/09/2013

/134

issued by a trusted Certification Authority, a so-‐called Privacy CA (PCA). Note that an AIK does not prove the identity of the TPM owner.

Keys generated and used by the TPM have different properties: Some (so-‐called non-‐migratable keys) cannot be used outside the TPM that generated them; some (like AIKs) can only be used for specific functions. We highlight the fact that keys can be tied to PCR values (by specifying PCR number and value in the key’s public data). This has the effect that such a key will only be used by the TPM if the platform (or some application) configuration is in a certain state (i.e. if the PCRs the key is tied to contains a specific value). In order to prove the properties of a particular key, for example that a certain key is tied to specific PCR values, the TPM can be used to generate a certificate for this key by signing the key properties using an AIK. For requesting a TPM to use a key (i.e. for decryption), the key’s authorization value has to be presented to the TPM. This together with the fact that the TPM specification requires a TPM to prevent dictionary attacks provides the property that only those entities that know the key’s authorization value can use that key. Non-‐migratable keys are especially useful for preventing unauthorized access to some data present in a platform. Binding such a key to specific PCR values and using it to encrypt data to be protected achieves two properties: The data cannot be decrypted on any other platform (because the key is non-‐migratable), and the data can only be decrypted when the specified PCR contains the specified value (i.e. when the platform is in a specific secure configuration and is not manipulated).

The current version of the TPM specification is 1.2 Revision 116, published on March 3, 2011. This specification is also available as the international standard ISO/IEC 118894. Specification for the TPM library version 2.0 has been released for public review by the TCG5.

The TPM main specification is an industry specification that enables trust in computing platforms in general. The main specification is broken into parts to make the role of each document clear. A version of the specification (like 1.2) requires all parts to be a complete specification. A TPM designer MUST be aware that for a complete definition of all requirements necessary to build a TPM, the designer MUST use the appropriate platform specific specification for all TPM requirements.

4. Monitoring Based Certification Mechanisms

4.1. Overview of Implementation The provision and assessment of cloud service security is difficult and not well supported by the existing

state of the art. Researchers have made significant progress delivering methods and tools for access control and identity management on clouds; secure storage protocols (e.g., proof-‐of-‐retrievability (Cachin 2009); proof-‐of-‐storage protocols (Kamara 2010)); encryption and key management (Li 2011); and secure virtualization (Lombardi 2011). Despite advances in these areas, however, the security of cloud services is still far from perfect. This is due to several vulnerabilities of cloud service provision that are related to the possibility of breaches of integrity, confidentiality and privacy due to multi-‐tenancy of services; interference between security mechanisms operating at different layers of cloud services (infrastructure, platform and software services); interference between security and cloud virtualization/optimisation mechanisms (e.g., spreading of DoS attacks due to load balancing in cloud federations (Jensen 2009)); and subverting administrative functions of the cloud infrastructure.

The risk arising from these vulnerabilities is increased by dependencies between services at all the layers of the cloud stack (i.e., IaaS, PaaS and SaaS services), which may also evolve dynamically (e.g., changing VMs, configurations of platform services, or deployed software services). These dependencies and their dynamic changes make it difficult to introduce appropriate pre-‐deployment and operation controls for 4 https://www.iso.org/obp/ui/#iso:std:iso-iec:11889:-1:ed-1:v1:en 5 http://www.trustedcomputinggroup.org/resources/tpm_library_specification


Security: Public

Date 27/09/2013

/134

assessing and guaranteeing the security (Catteddu 2009), (Jensen 2009). Furthermore, the exact provision of cloud services is frequently opaque; making it difficult to assess cloud security through audit mechanisms.

Under these circumstances, the security and trustworthiness of cloud services requires continuous and transparent assessment. Certification has a long history as a mechanism for verifying properties of software systems and increasing trust in them, mainly due to the liability that it entails for the authority that issues the certificates. However, existing certification methods, such as those based on the Common Criteria model (D. Herrmann 2002), focus mainly on systems with a stable structure that operate under stable operational conditions and, therefore, they are not suitable for the cloud. Recent research focuses on certification of service-‐based systems, whose structure can change dynamically (M. e. Anisetti 2010). However, it still ignores the deployment infrastructure and platform services that are involved in the provision of software services in a cloud. Also, SOA certification research (M. e. Anisetti 2010), (M. A. Anisetti 2012) is centred on certificates produced through pre-‐deployment testing and/or formal analysis of services without incorporating real and continuous cloud service monitoring data.

To address these limitations, CUMULUS is aimed at developing a novel cloud service certification approach based on the creation of monitoring based certificates for security properties of cloud services. In such certificates, the evidence required for assessing and verifying security properties is acquired through continuous monitoring of the operation of cloud services. Hence, the evidential basis for the assessment of properties can cover contextual conditions that might not be possible to envisage, test or simulate through other forms of assessment (e.g., testing and static analysis) before deploying a cloud service. Continuous monitoring can capture contextual conditions in cloud service provision as, for example, changes in the population of co-‐tenant services, the deployed virtualization and optimisation strategies and mechanisms, and network and middleware configurations in a cloud, which are difficult to take into account in static forms of assessment. It can also capture and adapt to the migration of SaaS cloud services within cloud federations, providing support for the adaptation of monitoring infrastructures when this happens.

Monitoring based certification adheres to the certification meta-‐model of CUMULUS that is described in deliverable D2.2 (CUMULUS, D2-‐2). According to it, certification refers to a security property regarding an asset of a cloud service (e.g., a specific service operation, a set of service operations, data managed by the service) or an asset that is required for or contributes to the realization of a cloud service (e.g., a virtual machine), collectively referred to as targets of certification (ToC). CUMULUS certificates are produced based on a certification model that is defined (or endorsed) by a certification authority, and are signed by this authority. The certification model defines the security property that needs to be certified, the ToC that this property applies to, an assessment scheme that determines the evidence that should be taken into account for assessing a property, how frequently this evidence should be checked and when the accumulated evidence will be sufficient for issuing the certificate. Certification models define also validity checks that should be executed before issuing a certificate. Such checks may, for example, require that the monitoring infrastructure, which is used to gather the operational evidence for the certificate C, has itself a certificate C’ confirming the integrity and non-‐repudiation of the monitoring data that it captures and provides, and that C’ must have been valid for the entire period over which the particular monitoring infrastructure has been used to gather evidence for C.

When the evidence gathered for a certificate type is sufficient for verifying the security property related to it (as determined by the certification model), a certificate that is an instance of this type could be issued. However, even after they are issued, certificates can be updated subject to changes in the operational conditions of the cloud service that they are associated with. The possible updates and other key changes in the life cycle of monitoring based certificates are described in a certificates life cycle model. This model is defined as part of the certification model that is used to generate the certificates. Figure 2 below shows the default life cycle model, assumed for monitoring based certificates in the CUMULUS framework.


Security: Public

Date 27/09/2013

/134

FIGURE 2 – LIFE CYCLE MODEL FOR MONITORING BASED CERTIFICATES

According to this model, the first state in the certificate’s lifecycle is Activated. In this state, a certificate type is activated with a unique ID; a reference to the certification model that it will be used for its incremental assessment and for issuing and updating certificates that are instances of it; a reference to the asset(s) of the cloud service that it refers to; and a digital signature of its issuer. The signature confirms that certificates, which are instances of the particular type, may be potentially issued for the referenced cloud service, based on the specific certification model and the evidence that needs to be collected.

After being activated, a certificate type enters the SetUpMonitors state. At this state, the monitoring infrastructure that will be used to acquire the operational evidence required for the assessment of a security property is generated. If a suitable monitoring infrastructure for the type can be identified and set up, the certificate type moves to UpdateCertificationModel state. At this state, a concrete operational specification of the security property of the certificate type is generated for the particular infrastructure. This specification will enable the monitoring infrastructure to determine the monitoring events (evidence) required for the assessment of the property and how to use them in order to assess the property. When these updates are completed and recorded in the certification model, the certificate type moves to Monitoring state. Note, however, that if no suitable monitoring configuration is found, the certificate type will cease to exist.

Whilst at the monitoring state, the evidence required for the assessment of the certificate type is continually gathered by the monitoring infrastructure. When the accumulated evidence becomes sufficient for confirming the validity of the security property of the type, the certificate type gets to the sub state CanBeIssued. This state indicates that certificates of the particular type can be issued by the certification platform. Whilst a certificate type is at the state CanBeIssued, its monitoring continues and, at specific checkpoints defined by the certification model, any additional operational evidence that is acquired for the type by the monitoring infrastructure is recorded in an aggregated format within the certification infrastructure (see the self-‐transition EvidenceUpdate).

When a certificate type gets to the state CanBeIssued, any agent interested in it (whether an application or a human actor) can request the generation of a certificate that is an instance of the particular type from the certification infrastructure by using the certificate type’s unique ID. Upon such a request, the certification infrastructure will check if the extra validity conditions for the certificate type (if any) are satisfied and, if they are, the certificate will move to the state Issued, from which it will generate a certificate instance and return it back to the requester. The generated instance will be identified by the combination of the ID of the certificate type and its own unique ID. The certificate instance will also record


Security: Public

Date 27/09/2013

/134

the expiry date of its type (as this date will apply to it as well). These actions are executed during the transition “Request Instance” in Figure 2. The issued instance of the certificate type will incorporate the aggregated evidence until the last checkpoint when monitoring data were retrieved from the monitoring infrastructure and aggregated for the certificate type. It will also contain the timestamp of the earliest and latest available evidence for the security property that it asserts, in order for its users to know the exact period covered by the evidence.

In case a conflict occurs, the certificate from either the CanBeIssued or Issued state moves to the Suspended state. While in this state the framework will try to handle the conflict according to the specification given in the Certification Model about conflicts’ resolution. If the occurred conflict is handled, then the certificate moves back to the previous states CanBeIssued or Issued (“Handled Conflict” transaction), otherwise moves to the Revoked state (“Unhandled Conflict” transaction).

A certificate type that is at the state Issued may be revoked. This will happen if the monitoring infrastructure identifies new monitoring data contradicting the evidence gathered so far and indicating that the relevant security property has been compromised. The occurrence of such evidence is signified by the transition “Security Property Violation” to the state Revoked. When a certificate type gets to the state Revoked, all the previously generated instances of it will be revoked. Also, the certificate type will be flagged as revoked in the certification infrastructure in order to prevent the generation of new instances of it, and its monitoring will be terminated. Moreover, a notification will be sent to the owners of the certificates, to inform them about their revocation.

In line with traditional models of certification, a certificate type has an expiry date. When this date is reached, the certificate type will move to the state Audit. This state signifies an audit of the certification model and the evidence gathered for the certificate type. The certification authority, which defined the certification model, will carry this out in order to ascertain that it may continue to use the certification model for producing certificates. If the audit is successful, the certificate type can be renewed: the transition “Renewed” brings the certificate back to the state where it was prior to reaching its expiration date and moving to the state Audit. If the audit is unsuccessful, the specific certificate type will be terminated. In this case, a notification should also be sent to owners of any issued instance certificates of the type to notify them that the type no longer exists but that the instances of it that have been issued will remain valid until their expiry date.

Following the expiry of a certificate instance, its users can request from the certification infrastructure to provide a renewed instance of the same certificate type. The infrastructure will be able to do so only if the certificate type at this stage is at the state CanBeIssued or Issued.

The life cycle mode reflects also reactions to changes related to the cloud infrastructure where the certified service has been deployed, or the monitoring infrastructure that is used to generate the operational evidence for the certificate. Such changes may require a change in the monitoring infrastructure that is used to gather the operational evidence underpinning the certificates of the given type and the concrete operational specification of the security property of the certificate type that drives the operation of the monitoring infrastructure. The evidence, however, that has been held so far in the certification infrastructure regarding the property may (depending on the certification model) remain relevant and should be maintained by the certification structure so that to be used when issuing new instances of the given type.

Changes in the cloud infrastructure and/or the monitoring infrastructure will trigger the transition of the certificate type to the SetUpMonitors state to check whether after the changes, the cloud deployment infrastructure of the service provides the monitoring capabilities required for continuing the monitoring of the specific certificate type. If successful, the certificate will move to the UpdateCertificationModel during which the certification model will be updated as described previously. When this completes successfully, the certificate will transit back to the evidence accumulation state inside Monitoring. If, however, the security property cannot be monitored after the changes, the certificate type will cease to exist.


Security: Public

Date 27/09/2013

/134

4.2. Supported Use Cases The initial implementation of the monitoring components supports two different use cases that cover

the use case UC_11 described in the deliverable D5.1 (CUMULUS, 2013) and correspond to a scenario where a Certification Authority (CA) uses the CUMULUS framework in order to issue a certificate for a specific cloud service.

The first Use Case (UC_1) describes the scenario where a CA requests to certify a service for a particular security property, according to a specific certification model. In this description, three more steps were added in the third step of UC_11, in order to provide in details the process followed for the Monitoring based Certification. The detailed specification of this use case is shown in Table 1.

Certificate Generation

Use Case Name Certificate Generation for a security property of a service, based on monitoring

Use Case ID UC_1 Description: A Certification Authority uses the CUMULUS framework in order to issue a

certificate for a security property of a cloud service, based on monitoring. Actors: CA, CUMULUS framework, Cloud Provider Pre-‐conditions: Trigger: A Cloud Service Provider requests the CA to certify a given service

Basic Flow:

1. The CA selects the service to be certified and the certification model to be used for its certification.

2. The CA requests to CUMULUS framework the carry out certification. 3. The CUMULUS framework creates the certificate if possible.

3.1. The framework checks the available monitors, selects the most suitable one and creates the monitoring configuration, based on the certification model.

3.2. The framework monitors the service according to the certification model.

3.3. The framework aggregates the monitoring events according to the certification model.

4. If a certificate can be created, the CUMULUS framework stores, maintains and manages the certificate according to the provisions of the certification model (this may require the explicit approval of the certificate by the CA).

Alternate flows: 1. If no appropriate certification model is available, the CA may define one by executing the use case UC_12 “CA defines a certification model”

Post-‐conditions:

Dependencies TABLE 1 – UC_1 CERTIFICATE GENERATION

The second Use Case (UC_2) describes the scenario for the retrieval of a generated certificate. The flow of events that constitute this use case is described in Table 2.

Certificate’s Retrieval

Use Case Name Certificate’s Retrieval in pull mode, for a security property of a service.


Security: Public

Date 27/09/2013

/134

Use Case ID UC_3

Description: An actor uses the CUMULUS framework in order to retrieve a specific certificate for a security property of a cloud service, based on monitoring.

Actors: Actor, CUMULUS framework, Cloud Provider

Pre-‐conditions:

Trigger: An actor (user) requests a specific certificate

Basic Flow: 1. The user requests a specific certificate from the CUMULUS framework. 2. The CUMULUS framework searches for the certificate in the Certified

Services DB. 3. The framework sends the certificate to the user.

Alternate flows:

Post-‐conditions:

Dependencies

TABLE 2 – UC_2 CERTIFICATE'S RETRIEVAL

4.3. Architecture The monitoring mechanisms of the CUMULUS framework have been designed according to the architecture model shown in Figure 3. The figure provides a refined version of the overall architecture of the CUMULUS framework that was defined in (CUMULUS, D5-‐1), showing the internal design of the Monitoring Manager, monitoring modules that are available in clouds, the evidence database, and an event bus that is used to communicate monitoring events to the monitoring module.

As shown in the figure, the monitoring mechanisms of CUMULUS are realised through the following components:

[1] Certification Manager: This component communicates with actors to create or modify Certification Models and it delegates the appropriate Manager, according to the type of model the CA requires, to start the certification process.

[2] Certification Communicator: This component communicates with actors that request a certificate and send them the generated certificates (if any). Moreover, in case users subscribe to get updates about any change that might occur in a specific certificate, this component is responsible to notify them.

[3] Certificate Generator/Attestation: This component is responsible to issue Certificates, when enough evidence is collected, according to the information of the Certification Models. It checks in every aggregation period the “Evidence DB”, and when it issues the certificate, it inserts the evidence to them and stored them into the “Certificates DB”.

[4] Monitoring Manager module: The Monitoring Manager Module is the component in the architecture that is responsible for detecting the availability of an adequate monitoring infrastructure for the realization of a certification model, the assembling and configuration of this infrastructure, and the initiation of the overall monitoring process in order to collect and store the primitive and aggregated monitoring evidence required for the generation of monitoring based certificates. To fulfil these responsibilities it consists of the following sub-‐components:


Security: Public

Date 27/09/2013

/134

a. Configuration Selector: This component has responsibility for checking the availability of an adequate monitoring infrastructure for the generation of certificates as required by a specific certification model and selecting the most appropriate monitoring configuration for this. To do so, it parses the assertion that defines the security property in a certification model and generates an Abstract Syntax Tree (AST) of this property based on the BNF grammar of the assertion language. Then, it searches through a registry of the monitoring capabilities of different cloud infrastructures, which is maintained by the CUMULUS framework (this registry is denoted as “Monitoring Capabilities DB” in the architecture model of Figure 3), to check if there are suitable event captors for providing the necessary primitive events and monitors for analysing these events in order to check the preservation of the assertion at runtime. This part of the architecture follows the approach defined in (Foster 2011).

b. Monitoring Manager: This component coordinates the activities of other components (e.g. Configuration Selector, Detailed Evidence Manager, Aggregation Manager) in the Monitoring Manager Module. More specifically it receives the certification model and configures the monitoring infrastructure required for the realization of the certification model according to the monitoring configuration selected by the Configuration Selector. It also configures the Detailed Evidence Manager and the Aggregation Manager in order to process the monitoring results.

c. Detailed Evidence Manager: This component polls the monitoring module at a regular interval in order to collect the monitoring results generated for a given certification model and stores the monitoring results detailed evidence table of the CUMULUS framework database.

d. Aggregation Manager: This component has responsibility for aggregating monitoring results and storing them in the “Evidence DB” of the CUMULUS framework as required by a given certification model (e.g., periodically). The aggregation manager polls the detailed evidences at a regular interval in order to aggregate and store these events in an aggregated form, which is defined by the certification model, in the “Evidence DB”. For example, primitive monitoring results may denote lengths of individual periods of unavailability of a service and aggregated results may indicate the average length of unavailability periods over a monitoring period of one week.

e. Conflict Manager: This component has responsibility for the detection and handling of conflicts in the evidence collected by the monitoring infrastructure for the generation of certificates. The ways to detect and handle conflicts are defined in the certification model. The current implementation does not include this component. An implementation of it will be developed in the second year of the project.

[5] Monitoring Module: The monitoring module is responsible to monitor the events for a specific security property and target of certification (ToC). This module may reside on a cloud infrastructure or be external to it. In our current implementation, we assume that it is external to it. The Monitoring Module gets a monitoring configuration with all the details required for the monitoring process (e.g., the assertions that constitute the specification of the security properties that need to be monitored at runtime, where to report the results of the monitoring process) from the Monitoring Manager. The Monitoring Module consists of two components:

a. Reasoning Component Gateway (RCG): This component has responsibility for translating the assertion that specifies the security property of a certification model into an operational specification that can be understood and realized by the exact reasoner, which will carry out the monitoring process.


Security: Public

Date 27/09/2013

/134

b. Reasoner: This component is responsible for carrying out the actual monitoring process (i.e., it is the actual monitor).

[6] CTP: This component is part of the cloud and dynamically acquires information about specific metrics with regards to the properties of cloud-‐based system (e.g. percentage of uptime etc.).

[7] Dashboard: This component provides a web based front end user interface for requesting the generation of monitoring based certificates and retrieving them from the current implementation of the CUMULUS framework.

[8] Event Bus: This component has responsibility for communicating primitive monitoring events from and monitoring results from the between the different components of the monitoring infrastructure used in the generation of monitoring based certificates, and between such components and the CUMULUS framework.

Moreover, in the architecture some databases are presented, which are used by different components to store or read data. These are:

[9] Evidence Database: This database is used by the Aggregation Manager that records all types of evidence (primitive and aggregated) and all their details, and by the Certificate Generator, which reads the data in order to generate a certificate.

[10] Certification Models DB: In this database all certification models are stored and read by the Certification Manager, in order to start the requested certification process.

[11] Certificates DB: In this database the Certificate Generator component records all generated certificates, which are then read by the Certification Communicator in order to sent them to the requestors.

The current implementation covers all the above components, except the Configuration Selector and Conflict Manager. The latter component will be implemented in the second year of the project following the full development of the CUMULUS approach to the definition and handling of conflicts within a monitoring based certification process. It should also be noted that although the first three components of those listed above (i.e., the Certification Manager, Certification Communicator and the Certification Generator) do not pertain only to monitoring mechanisms and may be used for other types of certificates, our current implementation includes initial primitive versions of them to enable the demonstration of the overall monitoring based certification process. The implementation of the Configuration Selector could be based on the SMART tool (see (Foster 2011)) but has been postponed, as it is mostly relevant in the cases of cloud federations and migrations of services within them, and therefore it was not deemed to be of high priority for the first year of the project (the current implementation assumes that there is a single monitoring configuration). Also the current implementation uses the Event Reasoning Toolkit (EVEREST) as a reasoner and a reasoning component gateway that has been developed for it (Mahbub 2011), (Foster 2011).


Security: Public

Date 27/09/2013

/134

FIGURE 3 – MONITORING ARCHITECTURE

The monitoring components of the CUMULUS framework are involved in the realization of UC_1 as indicated in the sequence diagram of Figure 4.

FIGURE 4 – UC_1 SEQUENCE DIAGRAM


Security: Public

Date 27/09/2013

/134

More specifically, monitoring components interact as described below to realize the flow of events in the use case description:

• The CA selects the service to be certified and picks a certification model to be used for its

certification. 1. CA will request to certify a service 2. Dashboard will request to the “Certification Manager” component 3. Dashboard will provide to the CA a list of TOC and security properties 4. CA will select the relevant TOC and security property to use 5. Dashboard will ask the “Certification Manager” component to retrieve all the certification models for

the selected TOC and property 6. The “Certification Manager” component will check the “Certification Model DB” for the relevant

certification models and will return them to the “Certification Manager” component 7. The “Certification Manager” component will display the certification models to the Dashboard

• The CA requests the CUMULUS framework to carry out certification.

8. The CA will choose a model to proceed with the process • The framework checks the available monitors, selects the most suitable one and creates the

monitoring configuration, based on the certification model. 9. The “Certification Manager” component extracts the security property and the assessment scheme

from the certification model and send it to the “Monitoring Manager” component 10. The “Certification Manager” component initiates the event captor.

• The framework monitors the service according to the certification model.

11. The “Monitoring Manager” component send the security property to the “Monitoring Module” component

12. The “Monitoring Module” component parses the security property and produces the operational monitoring property

13. The “Monitoring Module” component starts monitoring the property as the events arrive. • The framework aggregates the monitoring events according to the certification model.

14. The “Monitoring Module” component send the monitoring results to the “Aggregator” component 15. The “Aggregator” component aggregates the results and stores them in the “Evidence DB”

• If a certificate can be created, the CUMULUS framework stores, maintains and manages the

certificate according to the provisions of the certification model (this may require the explicit approval of the certificate by the CA).

16. The “Certificate Generator” component will generate the certificate according to the Assessment Scheme of the certification model, by checking if there is enough evidence in the “Evidence DB”. Then, if the certificate is created, it stores it to the “Certificate DB”.

Furthermore, the realisation of the flow of events of UC_2 will take place through the following interactions between the monitoring components of the CUMULUS framework:

• The user requests a specific certificate from the CUMULUS framework. 17. The CA requests to retrieve a certificate for a specific TOC through the GUI

• The CUMULUS framework searches for the certificate in the Certified Services DB.

18. The “Certification Communicator” component will retrieve the certificates for the selected TOC


Security: Public

Date 27/09/2013

/134

• The framework sends the certificate to the user. 19. The “Certification Communicator” component send the retrieved certificates to GUI

The sequence diagram showing the interactions realising UC_2 is shown in the sequence diagram of Figure 5.

FIGURE 5 – UC_2 SEQUENCE DIAGRAM

4.4. Components

4.4.1. Certification Manager

This component communicates with actors through the “Management API”, to create or modify Certification Models and it delegates the appropriate Manager, according to the type of model the CA requires, to start the certification process.

FIGURE 6 – CERTIFICATION MANAGER

The Certification Manager component is responsible to handle requests from Certification Authorities (CA) or Cloud Service Providers about generating Certification Models or issuing new certificates for specific security properties. After receiving the requests, the Certification Manager will delegate the Monitoring Manager Module to begin the certification process, according to the type of model the CA requires, through the “Monitoring Manager API”, and will provide it with all the necessary information from the agreed certification model.

This component is also connected with the Certification Models DB, so as to retrieve all necessary information about the required models and it also provides information stored in Certification Models to


Security: Public

Date 27/09/2013

/134

the Certification Generator/Attestation through the “Generation API", for the generation of new certificates.

Management API

retrievePropertyAndTOCS(): String

This method retrieves all available TOC and Security properties, from the available certification models stored in the database.

Parameters

Name Type Description

Return Type String This method returns a string representation of an XML of the following structure, which describes all the available properties and TOCs.

<PropertiesAndTocs>

<Property category="xxxxxx">

<TargetOfCertification ID="yyyyy" />

</Property>

<Property category="xxxxxxx">

<TargetOfCertification ID="yyyyy" />

</Property>

.. .. ..

.. .. ..

</PropertiesAndTocs>

retrieveCertificationModel(String property, String toc): String

Retrieves certification models for specific TOC and property, requested from the CA.

Parameters


Property String The selected property by the CA to be certified

TOC String The selected TOC by the CA

Return Type String This method returns the string representation of XML certification model, where the XML is written according to the schema presented in (CUMULUS, D2-‐2).

addCertificationModel(String This method stores the confirmed certification model of the CA to the


Security: Public

Date 27/09/2013

/134

cmInstanceId, String modelXML,) database.

Parameters


cmInstanceId String The unique identifier of the certification model instance that has been confirmed

modelXML String The confirmed CM in the XML format

submitCertificationModel(String modelXML,)

This method allows the CA to submit a certification model in order to start the certification process.

Parameters


modelXML String The string representation of the XML certification model.

4.4.2. Monitoring Manager

The Monitoring Manager component is responsible to coordinate the automatic configuration of the monitoring system and manage the monitoring process. It decides which is the most convenient monitoring configuration in the cloud infrastructure, according to configurable selecting criteria. It also configures the Detailed Evidence Manager and the Aggregation Manager in order to process the monitoring results. It exposes its functionality through the following “Monitoring Manager API”.

FIGURE 7 – MONITORING MANAGER


Security: Public

Date 27/09/2013

/134

Monitoring Manager API

submitCertificationModel (String model)

This method allows submitting a certification model to the monitoring manager.

Parameters


Model String String representation of an XML certification model.

4.4.3. Detailed Evidence Manager

This component is part of the Monitoring Manager component and is responsible to poll the monitoring module at a regular interval to collect the produced monitoring results. If it fetches any monitoring result from the monitoring module, it stores the results in the detailed evidence table of the CUMULUS framework database.

4.4.4. Aggregation Manager

Aggregation Manager is a part of the Monitoring Manager component and is responsible to aggregate the monitoring results. The monitoring manager configures the aggregation manager in order to accumulate the monitoring results for every aggregated period, defined in the certification model. The aggregator also stores the aggregated results to the “AggregatedEvidence” table of the CUMULUS framework database (see Section 4.4.10).

4.4.5. Certification Communicator

This module allows the actors to request a generated Certificate. To enable this communication the Certification Communicator component exposes a set of two APIs, the “Retrieval API” and the “Notification API”.

FIGURE 8 – CERTIFICATION COMMUNICATOR

The Retrieval API defines methods to establish the communication with CUMULUS framework in order to request to generate a certificate.

Retrieval API

Get(Assert4SoaASSERTStandaloneType cert)

Retrieves the requested certificate (cert) from the “Certificate” DB

Parameters



Security: Public

Date 27/09/2013

/134

cert Assert4SoaASSERTStandaloneType

The generated certificate stored in the database

Provide(Assert4SoaASSERTStandaloneType cert)

Provides the certificate (cert) to the dashboard, to be sent to the CA

Parameters


cert Assert4SoaASSERTStandaloneType The generated certificate stored in the database

The Notification API is responsible to notify every registered actor for any update of the relevant certificate. This interface will be developed in Year 2.

4.4.6. Certificate Generator

This component is responsible to issue Certificates. It receives a Certification Model from the certification manager through the “Generator API” and produces certificate for the model if the necessary conditions (e.g. enough monitoring results are produced or specified monitoring period has passed) to generate certificate is fulfilled. This component exposes its functionality through the following “Generation API”.

FIGURE 9 – CERTIFICATE GENERATOR

Generation API

submitCertificationModel(String model)

This method allows submitting a certification model to the Certificate Generator.

Parameters


Model String String representation of an XML certification model.

4.4.7. Event Captors

The Event Captor works as a tunnel between a Web Service Client, Web Service Container and an Event Receiver (Event Bus component), as it is shown in the components diagram below (Figure 10). It listens any SOAP request that arrives at the port where the Event Captor is running and forward them to Web Service


Security: Public

Date 27/09/2013

/134

container (i.e. to (tunnelhost, tunnelport)), as well as it creates and sends events to Event Bus (i.e. to (receiverhost, receiverport)). On the other hand, any SOAP response received from web service container (i.e. from (tunnelhost, tunnelport)) is forwarded to the web service client (i.e. to listener port) and the generated events to Events Receiver (i.e. to (receiverhost, receiverport)).

FIGURE 10 – EVENT CAPTOR

The Event Captor works as follows:

• Any Web Service is deployed and running on the Web Service Container. For instance let is take the web service example “ http://localhost:8080/axis2/services/ServerDoctorWS”, which uses axis2 and it is deployed in Tomcat server

• Start simple event receiver by executing SeCSEEventReceiver.java in SimpleEventReceiver project. This class creates a listener to port 12345

• The main class for starting the Event Captor is TcpTunnel.java. It is need to enter listernerport, tunnelhost, tunnelport, receiverhost, receiverport as arguments. For instance: “ 8083 localhost 8080 localhost 12345”. This means that the Event Captor will intercept all SOAP requests that it receives in 8083 port and it forward them to the Web Service Container (localhost:8080). Moreover, the Event Captor will build an event which will be sent to the Event Receiver (Event Bus) running on localhost:12345. The format of this event is shown in Figure 11.

• The Web Service Client which invokes the previous deployed web service must be configured for sending the SOAP request to the port where the Event Captor is running (8083)


Security: Public

Date 27/09/2013

/134

FIGURE 11 -‐ EVENT FORMAT SENT FROM THE EVENT CAPTOR TO THE EVENT BUS

<?xml version="1.0" encoding="windows-‐1250"?> <Event> <EventID> <ID>35</ID> <EventIdType>Event Test</EventIdType> </EventID> <EventContext> <Time> <CollectionTime>2013-‐07-‐29T12:28:10</CollectionTime> <Timestamp>1375093690836</Timestamp> <ReportTime>2013-‐07-‐29T12:28:10</ReportTime> </Time> <Notifier> <Name>Notifier host name</Name> <IP>122.412.41.12</IP> <Port>7070</Port> </Notifier> <Source> <SwServiceLayerSource> <sender> <name>servicename</name> <ipAddress>122.412.41.12</ipAddress> </sender> <receiver> <name>receiverservicename</name> <ipAddress>45.23.62.1</ipAddress> <port>8080</port> </receiver> </SwServiceLayerSource> </Source> </EventContext> <EventPayLoad> <InteractionEvent> <OperationName>operationName</OperationName> <operationID>1312</operationID> <status>skata</status> <Parameters> <Argument> <ArgName>argname1</ArgName> <ArgType>argtype1</ArgType> <Value>argvalue1</Value> <Direction>IN</Direction> </Argument> <Argument> <ArgName>argname2</ArgName> <ArgType>argtype2</ArgType> <Value>argvalue2</Value> <Direction>OUT</Direction> </Argument> </Parameters> </InteractionEvent> </EventPayLoad> <EventMetadata> <key>key</key> <value>value</value> </EventMetadata> </Event>


Security: Public

Date 27/09/2013

/134

TcpTunnel class

start This is the main method that starts the Event Captor working.

Parameters


listernerport String The port where the Event Captor is running/listening

tunnelhost String The address where the Web Service Container is running

tunnelport String The port where the Web Service Container is running

receiverhost String The address where the events receiver (Event Bus) is running

receiverport String The port where the events receiver (Event Bus) is running

4.4.8. Monitoring Module

The monitoring module is responsible to monitor a specific security property as defined in the Certification Model against runtime events of a system. This module is on the cloud infrastructure and it exposes its functionality through the following “Monitoring Module API”.

FIGURE 12 – MONITORING MODULE

MonitoringModuleAPI

submitMonitoringConfiguration(String configuration)

This method allows to submit a monitoring configuration to the monitoring module, where the monitoring configuration contains all the details required for the monitoring process (e.g., the assertions that constitute the specification of the security properties that need to be monitored at runtime, where to report the results of the monitoring process)

Parameters


configuartion String String representation of the XML monitoring configuration.

List<String> getLatestMonitoringResults()

This method allows retrieving the latest monitoring results from the monitoring module.


Security: Public

Date 27/09/2013

/134

Parameters


Return Type List of String String representation of the XML monitoring result, where XML monitoring result is composed according to the schema presented in Appendix D.2.

4.4.9. Event Bus

The Event Bus component is a “publish/subscribe” event communication infrastructure that will be used in CUMULUS architecture in the following manner: after locating a Monitor, CUMULUS framework gets from it a token designating an event channel of interest and uses this token to subscribe the monitor to the Event Bus. The same token is passed to the Event Captor to be used when it publishes events to the bus so that these events can be forwarded to the appropriate monitor.

The Event Bus component support several technologies/protocols related to messaging implementation, namely: XMPP, JMS (Celesti 2010) and AMQP (Grobauer 2011), but for CUMULUS purposes only XMPP will be used.

The main class of the Event Bus component is “ PubSubManager class”, and the table below describes the provided methods.

PubSubManager class

connect() connects to the pubsub server

getId() returns the ID of the connection

Parameters Type Description

Channel Channel Represents a channel to publish messages and to which can be subscribed (see Figure 13)

isChannel(channelName) return true if channel exists


channelName String The name associated to the channel.

deleteChannel(channelName) Delete the pubsub channel


channelName String The name associated to the channel.

publish(message) Publishes the message


message PubSubMessage The message that will be sent (see Figure 14)

subscribe(channelName)


channelName String Channel identifier


Security: Public

Date 27/09/2013

/134

unsubscribe(channelName)


channelName String

close() Closes the connection with pubsub server

The PubSubManager class extends from org.slasoi.common.messaging.pubsub.PubSubManager, which provides the methods shown in Figure 13.

XMPP implementation of PubSub FIGURE 13 – ORG.SLASOI.COMMON.MESSAGING.PUBSUB.PUBSUBMANAGER

The Class that encapsulates the message for being sent over pubsub is PubSubMessage, as it is shown in figure below. The main properties of PubSubMessage are Channel to which Message is published and payload which is the actual content.


Security: Public

Date 27/09/2013

/134

PubSubMessage FIGURE 14 – PUBSUBMESSAGE CLASS

4.4.10. Evidence Database

The Evidence Database is used to record all types of evidence (primitive and aggregated) and all their details, in case they will be needed (i.e. for auditing purposes). All tables will be built based on MySQL.

Detailed Evidence

This table records primitive evidence that is collected regarding the assessment of security properties. Columns Description

Event_Id A unique identifier for every event captured

CM_Instance_Id Reference to the Certification Model instance that the aggregated evidence relates to (Foreign key referencing CertificationModel table)

TimeStamp Time of evidence collection

EventPayloadType Type of evidence:

• InteractionEventType (the evidence captures a call of a service operation or a response from the execution of a service operation)

• MonitoringResultEventType (a monitoring result regarding the


Security: Public

Date 27/09/2013

/134

satisfaction or not of a security property that is produced by a monitor)

• PredictionResultEventType (a prediction regarding the satisfaction or not of a security property by the end of a specific period of time in the future that is produced by the monitor)

• InfrastructureMonitoringEventType (a measure regarding some infrastructure layer property)

Evidence_ XML The XML encoding of the evidence represented as a string.

Evidence_ Object The evidence as java object (automatically produced) by the monitoring manager before getting recorded in the database)

Sender

This table records the sender of each primitive event that is collected regarding the assessment of security properties. Columns Description

Event_Id Reference to a specific event captured (Foreign key referencing the Detailed Evidence table)

Name Id of the sender

IP IP address of the sender

Port Port number used by the sender process

User_Id ID of the user that started the sender process

ProcessId ID of the process that generates the event

Receiver

This table records the receiver of each primitive event that is collected regarding the assessment of security properties. Columns Description


Name Id of the receiver

IP IP address of the receiver

Port Port number used by the receiver process

User_Id ID of the user that started the receiver process

ProcessId ID of the process that generates the event


Security: Public

Date 27/09/2013

/134

Notifier

This table records the notifier (event captor) of each primitive event that is collected regarding the assessment of security properties. Columns Description


Name Id of the notifier

IP IP address of the notifier

port Port number used by the notifier process

The example below shows how the payload is defined in the XML representation of the detailed evidence, derived from the XML Schema of the detailed evidence presented in Appendix D.1. It is showed that the Event Type is MonitoringResultEventType, and that the result is a violation. The event metadata signifies that 100 events were used to derive this monitoring result.

Aggregated Evidence

This table records the aggregated evidence that is generated by the “Aggregator” component according to the CM and is inserted in the certificates.

<eventInstance xmlns="http://www.slaatsoi.org/eventschema">

……

<EventPayload> <MonitoringResultEvent> <SecurityPropertyInfo assessmentResult="violation" cmInstanceID="1001-‐inst" securityPropertyID="1001-‐inst"> <GuaranteedState assessmentResult="violation" guaranteedID="ORCThroughputConstraintInventoryBookSaleState"> <QoSName>http://www.slaatsoi.org/commonTerms#arrival_rate</QoSName> <QoSValue>0.008264462809917356</QoSValue> </GuaranteedState> </SecurityPropertyInfo> </MonitoringResultEvent> </EventPayload>

<EventMetadata> <key>NumberOfEvents</key> <value>100</value> </EventMetadata> </eventInstance>


Security: Public

Date 27/09/2013

/134

Columns Description

AggregatedEvents_Id A unique identifier for aggregated evidence

CM_Instance_Id Reference to the Certification Model instance that the aggregated evidence relates to (Foreign key referencing CertificationModel table)

Creation_Time Creation Time of the aggregated evidence

Start_Time Start time of the aggregation period

End_Time End time of the aggregation period

Assertion_ID Reference to the Assertion ID that expresses the security property for which this aggregation is produced (Foreign key referencing Certification Model Table)

Assessment_Result Overall assessment result of the security property (satisfied/violated)

Evidence_ XML The aggregated evidence as string representation of XML

Evidence_ Object The aggregated evidence as java object

The example below shows an XML representation of aggregated evidence. This representation is structured according to the XML Schema of the aggregated evidence presented in Appendix D.2. In the reportInfo element the creator, the start and end date of the aggregation are being defined, as well as the Certification Model Instance that was used to assess the property (“reportId=”Report-‐1001-‐inst”). Moreover, the AssessmentResultSummary signifies that for the Guaranteed of the monitored property, 58 violations were detected. Finally, the FunctionalAggregatorResult element shows the measure used to aggregate the monitoring results of the security property, which was the “average” value.

<aggregatedReportType xmlns:ns2="http://www.slaatsoi.org/eventschema" xmlns="http://www.slaatsoi.org/business-‐report-‐schema">

<ReportInfo reportCreatorId="SLA@SOI Business Reporting"

endTime="2013-‐08-‐29T15:32:57.136+01:00"

startTime="2013-‐08-‐29T15:32:57.073+01:00" timestamp="2013-‐08-‐29T15:32:57.136+01:00"

reportId="Report-‐1001-‐inst"/> …… <AssessmentResultSummary> <SecurityProperty notAssessted="0" satisfactions="0" violations="58"/> <Guaranteed notAssessted="0" satisfactions="0" violations="58"/> </AssessmentResultSummary> <FunctionalAggregatorResultSummary> <FunctionalAggregatorResult aggregateValue="0.0018021085940434745" functionalAggregatorId="Average" guaranteedTermId="ORCThroughputConstraintInventoryBookSaleState" securityPropertyId="1001-‐inst"/> </FunctionalAggregatorResultSummary>

</aggregatedReportType>


Security: Public

Date 27/09/2013

/134

4.4.11. Certification Model Database

This table records certification models that are used to assess security properties. For every request of a specific certification model (CM_Id), a new CM Instance (CM_Instance_Id) will be created. Columns Description

CM_Id A unique identifier for every certification model (CM) -‐ primary key

CM_Instance_Id A unique identifier for every request made by a CA to apply the specific CM to a ToC (two separate requests for applying the same CM to the same ToC will result in two separate CM instances)

CASignature The CA signature of the specific instance of the CM

Security_Property The security property category that is going to be certified

Assertion_ID ID of the assertion that expresses the property

Assertion Specification of security property in the certification language

ToC_ID The ID of the Target of Certification (ToC) that is being certified by the specific instance

ToC_Name Name of the ToC that is being certified by the specific instance

CM_ XML The whole CM as string representation of XML

CM _Object The whole CM as java object

An Example of the XML representation of the CM is given in the Appendix E.1.

4.4.12. Certificates Database

This table records all generated certificates. Columns Description

certPK A unique identifier for every certificate generated (cert) -‐ primary key

certSerialNo The serial number of the generated certificate

Security_Property The security property category that is being certified

tocName Name of the ToC that is being certified by the specific instance (Foreign key referencing Certification Model Table)

validFrom The date from which the certificate begins to be valid

validUntil The expiration date of the certificate

certString The whole cert as string representation of XML

certObject The whole cert as java object

An Example of the XML representation of the Certificates is given in the Appendix E.2.


Security: Public

Date 27/09/2013

/134

4.4.13. CTP

CTP stands for Cloud Trust Protocol and it is intended to be used as a means for exposing to the outside world details with regards to the runtime properties of cloud environments. Such properties can be availability, up-‐time or percentage of requests served by the system within a specific time window, as described in D2-‐1 deliverable (CUMULUS, D2-‐1). With the use of CTP cloud clients will have the chance to get at all times a close look of the operational characteristics of the environment that their applications are running on, allowing them to have a greater degree of control over the cloud platform that they have deployed their applications.

The adoption of CTP is a way for giving to cloud customers an insight with regards to the behaviour of a cloud system through an API that uses the rational of web services and more specifically of restful web services. The CTP API considers everything as a resource allowing cloud customers to dynamically monitor the operation of the system by invoking a set of web services that have been defined in great detail at the CTP specification. Each cloud provider that decides to support the CTP specification needs to implement those services with an API, providing in that way the common grounds for all cloud providers on how their clients will be able to continuously monitor their cloud applications.

CTP can add great value to the overall collaboration and relationship between cloud clients and providers due to the increased degree of control that its gives to the clients. First and foremost, CTP makes the internal operation of cloud providers more transparent to its customers, attempting to overcome lack of transparency, one of the major setbacks that cloud computing has introduced since its very existence as a distributed computing technology. Constant awareness of the system’s operation by simply invoking a web service makes clients more willing to use cloud platforms to deploy their applications, setting cloud providers more trustworthy and reliable. In addition, CTP can be also used as a tool for enhancing accountability and help define who is responsible for malfunctions and deviations of the system’s operation from what is described as normal in SLAs. Finally, it offers a unified way for customers to discover the resources that are available from cloud providers making it easier for cloud customer to migrate their applications to different cloud platforms without having to change the way they monitor them.

In order to provide some insight with regards to the CTP specification we need to introduce and define some cornerstone concepts upon which the API has been built on. Below follows a list with those concepts along with the description on how they are been interpreted with the context of the API.

Service-‐units: A Service-‐unit represents a service offered to customers under the responsibility of a single provider. This service is usually described in a SLA or service interface. A Service-‐unit encompasses a set of “cloud resources”.

Cloud resources: A cloud resource describes any physical or virtual component of a cloud information system. The definition of a cloud resource will vary according to the context and may include for example simple API calls, storage, processor cores or compute instances, databases, full blown platforms, etc. A set of security attributes is attached to a cloud resource.

Security attributes: A security attribute is specified through a security attribute name, which describes what the security attribute is about (e.g. “availability in terms of a percentage of successful requests”, “mean time between failure”, etc.). This name is optionally complemented with a measurement context, as some security attributes need extra parameters to define how they are measured.

Measurements contexts: A measurement context is an optional list of measurement parameters that specify how a security attribute is evaluated (e.g.: when measuring availability of a service, we may wish to define the maximum delay allowed for a service request to be executed by the service provider before the request can be considered as failed.).

Within the scope of the CTP API, that has been developed for the purpose of CUMULUS, only one operation has been built that can be invoked on a cloud system’s security attribute and it is a report of the value of specific security properties. An example of such a value would be the percentage of uptime of a


Security: Public

Date 27/09/2013

/134

specific service that would be expressed as a float number. The following image has been produced in order to better demonstrate the structure of the restful CTP API and depict the organization of the resources.

FIGURE 15 – SIMPLIFIED EXAMPLE OF THE CTP API

In this simplified example a service unit can include a set of resources and each resource can include certain attributes. Additionally, each attribute has a measurement context where there is a detailed description of how the measurement of the property takes place. In order to more accurately describe the measurement context we can think of availability where measurement information such as the time window within which availability is measured or what indicates that a service is unavailable can have a great impact on the calculated value of availability.

Bellow follows a list of tables that summarizes the web services that have been implemented to demonstrate some basic functionality of the CTP API.

Web Service URL

http://ctp-‐cumulusdemo.rhcloud.com/CTP

Description

This is the base URL for the CTP API that provides the URL where the service units for the cloud provider can be found.


Security: Public

Date 27/09/2013

/134

Parameters

None

Response

1. User id of the invoker

2.Version of the CTP implementation

3. Link to the XML schema that the API conforms to

4.Link to the URL where a list with the service units can be found.

Example response <baseURI self="http://ctp-‐cumulusdemo.rhcloud.com/CTP/">

<id>demo-‐user</id>

<version>1.00</version>

<link rel="schema" location="http://ctp-‐cumulusdemo.rhcloud.com/CTP/schemas/ctp.xsd"/>

<link rel="serviceUnitCollection" location="http://ctp-‐cumulusdemo.rhcloud.com/CTP/ServiceUnits"/>

</baseURI>

Web Service URL

http://ctp-‐cumulusdemo.rhcloud.com/CTP/ServiceUnits

Description

This provides us with a list of the available service units offered by the cloud provider.

Parameters

None

Response


2.A collection with all the links that point to the available service units.

Response example <serviceUnitCollection self="http://ctp-‐cumulusdemo.rhcloud.com/CTP/ServiceUnits">


<collection>

<link rel="ServiceUnit" location="http://ctp-‐cumulusdemo.rhcloud.com/CTP/ServiceUnits/1"/>






Security: Public

Date 27/09/2013

/134



</collection>

</serviceUnitCollection>

Web Service URL

http://ctp-‐cumulusdemo.rhcloud.com /CTP/ServiceUnits/{service unit id}

Description

This provides us with a set of information with regards to a specific service unit.

Parameters

None

Response


2.Provider of the service

3. Link to URL where the dependencies of that service unit can be discovered (Not implemented)

4.Link to the URL where a list with the cloud resources of that specific service unit can be found.

Response example <serviceUnit>


<provider>Cloud Secourity Alliance</provider>

<link rel="dependenciesCollection" location="http://ctp-‐cumulusdemo.rhcloud.com/CTP/ServiceUnits/1/Dependencies"/>

<link rel="cloudResourceCollection" location="http://ctp-‐cumulusdemo.rhcloud.com/CTP/ServiceUnits/1/CloudResources"/>

</serviceUnit>

Web Service URL

http://ctp-‐cumulusdemo.rhcloud.com /CTP/ServiceUnits/{service unit id}/CloudResources

Description

This provides us with a list of the available cloud resources offered by the cloud provider for a specific service unit.

Parameters

None

Response


2.A collection with all the links that point to the available cloud resources for a specific service unit.


Security: Public

Date 27/09/2013

/134

Response example <cloudResourceCollection self="http://ctp-‐cumulusdemo.rhcloud.com/CTP/ServiceUnits/1/CloudResources">


<collection>

<link rel="CloudResource" location="http://ctp-‐cumulusdemo.rhcloud.com/CTP/ServiceUnits/1/CloudResources/1"/>




</collection>

</cloudResourceCollection>

Web Service URL

http://ctp-‐cumulusdemo.rhcloud.com /CTP/ServiceUnits/{service unit id}/CloudResources/{cloud resource id}

Description

This provides us with a set of information with regards to a specific cloud resource of a specific service unit.

Parameters

None

Response


2. Name of the provider

3. Service class that the type of cloud resource belongs to.

4. Link to the URL where a list with the attributes of a specific cloud resource of a specific service unit can be found.

Response example <cloudResource>


<name>www.csa.org</name>

<serviceClass>IaaS-‐Compute</serviceClass>

<link rel="attributeCollection" location="http://ctp-‐cumulusdemo.rhcloud.com/CTP/ServiceUnits/1/CloudResources/1/Attributes"/>

</cloudResource>


Security: Public

Date 27/09/2013

/134

Web Service URL

http://ctp-‐cumulusdemo.rhcloud.com/CTP/ServiceUnits/{service unit id}/CloudResources/{cloud resource id}/Attributes

Description

This provides us with a list of the available attributes of a specific cloud resource of a specific service unit that are offered by the cloud provider.

Parameters

None

Response


2. A collection with all the links that point to the available attributes of specific cloud resource of a specific service unit.

Response example <attributeCollection self="http://ctp-‐cumulusdemo.rhcloud.com/CTP/ServiceUnits/1/CloudResources/1/Attributes">


<collection>

<link rel="Attribute" location="http://ctp-‐cumulusdemo.rhcloud.com/CTP/ServiceUnits/1/CloudResources/1/Attributes/percentage-‐of-‐uptime"/>

</collection>

</attributeCollection>

Web Service URL

http://ctp-‐cumulusdemo.rhcloud.com/CTP/ServiceUnits/{service unit id}/CloudResources/{cloud resource id}/Attributes/{attribute id}

Description

This provides us with a set of information with regards to a attribute of a specific cloud resource of a specific service unit.

Parameters

None

Response


2. Description of how the value of the attribute will be represented

3. Capabilities represent the operations that can be applied on the specific attribute and the URL under which the service invocation can be made in order to perform the operation

4. Whether the attribute is active or not


Security: Public

Date 27/09/2013

/134

Response example <attribute self="http://ctp-‐cumulusdemo.rhcloud.com/CTP/ServiceUnits/1/CloudResources/1/Attributes/percentage-‐of-‐uptime/">


<attributeDefinition class="availability-‐class">

<attributeRowDefinition repeat="false">

<attributeCellDefinition name="percentage">

<type>cp:float</type>

</attributeCellDefinition>

</attributeRowDefinition>

</attributeDefinition>

<capabilities>

<link rel="report" location="http://ctp-‐cumulusdemo.rhcloud.com/CTP/ServiceUnits/1/CloudResources/1/Attributes/percentage-‐of-‐uptime/report"/>

<link rel="trigger" location="http://ctp-‐cumulusdemo.rhcloud.com/CTP/ServiceUnits/1/CloudResources/1/Attributes/percentage-‐of-‐uptime/trigger"/>

<link rel="commitment" location="http://ctp-‐cumulusdemo.rhcloud.com/CTP/ServiceUnits/1/CloudResources/1/Attributes/percentage-‐of-‐uptime/commitment"/>

</capabilities>

<attributeState>ACTIVATED</attributeState>

</attribute>

Web Service URL

http://ctp-‐cumulusdemo.rhcloud.com/CTP/ServiceUnits/{service unit id}/CloudResources/{cloud resource id}/Attributes/{attribute id}/report

Description


Parameters

None

Response


2.Link that points to the report of the specific attribute

3. The actual value of the attribute


Security: Public

Date 27/09/2013

/134

4.Date and time that the report was taken

5. Assertion for the attribute if there is one

Response example <report>


<link rel="self" location="http://ctp-‐cumulusdemo.rhcloud.com/CTP/ServiceUnits/1/CloudResources/1/Attributes/percentage-‐of-‐uptime/report/"/>

<attributeValue>

<attributeRowValue>

<attributeCellValue name="percentage-‐uptime">

<value>57</value>

</attributeCellValue>

</attributeRowValue>

</attributeValue>

<dateTime>Wed Aug 21 12:23:49 EDT 2013</dateTime>

<assertion/>

</report>

4.4.14. Monitoring Dashboard

The Monitoring Dashboard (MD) component provides a web based front end user interface for requesting the generation of monitoring based certificates and retrieving them from the current implementation of the CUMULUS framework. It provides end-‐users and Certification Authorities an easy tool to interact with the CUMULUS Framework.

This interface exchanges XML information with the Certification Manager (CM) through SOAP (Simple Object Access Protocol) protocol via HTTP requests. CM interacts with the Certification Model DB, the Monitoring Manager, the Event Captor, the Event Bus, the Monitoring Modules, the Evidence DB, the Aggregator and the Certificate Generator in order to generate or retrieve a certification. The user only needs to access to the Monitoring Dashboard through a Web Browser (Chrome, Firefox, etc.) and select some parameters.


Security: Public

Date 27/09/2013

/134

FIGURE 16 – MONITORING DASHBOARD INTERACTION

The MD has been implemented by a HTML + JavaScript application that performs SOAP requests to the CM. The user interface has been designed with Bootstrap (Twitter s.f.), a powerful front-‐end framework (HTML and CSS tools) created by Twitter. The SOAP communications with the CM is handled by a jQuery SOAP plugin (Blom s.f.).

As detailed in section 4.2 the first version of the MO will only support two initial Use Cases: Certificate’s Generation and Certificate’s Retrieval. Hence, only three main sections are presented to the user.

FIGURE 17 – MONITORING DASHBOAR FRONTPAGE

In the first Use Case, a Certification Authority (CA) requests to certify a service for a particular security property, according to a specific certification model. To do so, the CA interacts with the MD to request available Target of Certification (TOC) and properties. The MD will make a request to the CM and will show to the CA the results.

FIGURE 18 – INTERFACE FOR SELECTING TARGET OF CERTIFICATION


Security: Public

Date 27/09/2013

/134

Once the CA selects a suitable TOC and property, the MD will request the CM this information and present to the CA the available models to proceed with the process.

FIGURE 19 – THE USER SELECTS SECURITY PROPERTIES

Finally, the MD will send all this information to the CM and the creation of the certification will begin. Figure 18, Figure 19 and Figure 20 show some screenshots of the process.

FIGURE 20 – GENERATION OF THE CERTIFICATE

In the second Use Case a user requests a specific certificate for a security property of a cloud service through the web interface. The MD requests the CUMULUS framework to search for the certificate in the Certified Services DB and shows to the user the results.

FIGURE 21 – RETRIEVING A CERTIFICATE


Security: Public

Date 27/09/2013

/134

4.5. Future enhancements The current implementation of the Certification manager is tested only for availability QoS. It will be

enhanced to support more QoS terms in the future versions. Furthermore, the Event Collector only intercepts messages being exchanged with a web service deployed in Axis1.4, which should be enhanced to support Axis2 services, as well as to intercept events from other layers such as infrastructure layer. Moreover, the Event Captor only supports SOAP web services, and it will be enhanced for being compliant with REST. Finally, the Dashboard only supports Firefox and Google Chrome browser. It does not support Internet Explorer, something that will be enhanced in future versions.

5. Test Based Certification Mechanisms 5.1. Overview of Implementation

According to CUMULUS project approach, some accredited authority could continuously produce and maintain signed certificates of security properties held by cloud entities. In order to achieve such result we need to produce evidence supporting Test-‐based assertions of security properties, in other words evidence that some tests were carried out on software or a service, or more generally on a cloud layer, have given a certain result. We call this kind of tests as offline or static when performed in a pre-‐production environment; alternatively, we could dynamically test production periodically or when a specific software or service is invoked or when a specific condition is met, and this is what we call online or dynamic or runtime tests. Ultimately we state that Test based certification process of a property includes two different kinds of mechanisms: the Offline or Static Testing and the Online Testing also defined as Dynamic or Runtime.

In our demo scenario we carry on offline/online tests to certify Confidentiality: the definition Confidentiality in a cloud environment depends on the layer or on the Target of Certification we consider: for example if we consider data in transit (i.e. Confidentiality for data flowing in the network) it means that the network itself must offer a confidential network channel where data are exchanged with external parties. This property can be shortly defined as “Confidentiality in transit” but a detailed definition is given in D2-‐1 deliverable where security property AIS:confidentiality:external-‐data-‐exchange-‐confidentiality (CUMULUS, D2-‐1) is formally defined and described.

But, when working in another layer, the notion of Confidentiality can change: a data owner may wish to know whether his data are accessible or not by other parties including the TOC personnel or the Cloud Provider itself. In this case a server side mechanism such storage encryption could maintain this kind of data protection that we call “Confidentiality at rest”. In this case the formal definition of the property is AIS:confidentiality:service-‐provider-‐data-‐access-‐level (CUMULUS, D2-‐1).

The simulation in our use cases does not solve all the issues related to Confidentiality: we should also consider “Confidentiality in memory”, where also the data in memory must not be accessible by other parties or be deleted after a given period of time. Also “Confidentiality across tenants” (i.e. confidentiality when services are shared) could be another aspect to be taken into account. The following table gives the full picture of the Test-‐based scenarios.

Confidentiality

Tests Confidentiality in transit Confidentiality at rest Confidentiality in memory

Confidentiality across tenants


Security: Public

Date 27/09/2013

/134

Offline TOC = Web Service

AIS:confidentiality:external-‐data-‐exchange-‐confidentiality

TOC = Virtual Machine

AIS:confidentiality:service-‐provider-‐data-‐access-‐level

N/A at the moment N/A at the moment

Online TOC = Web Service

AIS:confidentiality:external-‐data-‐exchange-‐confidentiality

TOC = Virtual Machine

AIS:confidentiality:service-‐provider-‐data-‐access-‐level

N/A at the moment N/A at the moment

TABLE 3 – TOCS AND SECURITY PROPERTIES FOR THE TEST-‐BASED SCENARIOS.

5.2. Offline testing Web Service offline testing for “Confidentiality in transit”

First, in this use case we perform an offline testing to verify AIS:confidentiality:external-‐data-‐exchange-‐confidentiality security property (defined also as “Confidentiality in transit”) at Web Service level (TOC). According to D2-‐1 description (CUMULUS, D2-‐1) the TOC should offer a confidential network channel for data exchanges with external parties: we utilize data encryption to provide such mechanism.

In our use case we use a Web Service in a cloud platform that performs a simple arithmetic operation: when the service receives a numeric parameter, it adds 100 to the input value. The use case demonstrates the correct implementation of data encryption in transit, i.e. data are encrypted in the channel from the client (the Testing Manager in our implementation) to the Web Service and vice versa; thus data are not readable even when they are intercepted.

The actors of our use case are: the tester, the client software or probe (Testing Manager component) that performs the test, the Web Service under test.

For this use case we have the following actions:

• the tester needs to certify “Confidentiality in transit” for a certain TOC, in our case a Web Service,

• the client software sends an encrypted numeric parameter (for example test input value = 10) to the Web Service,

• the Web Service receives it and decrypts it,

• the Web Service performs a simple add operation (i.e. 10 + 100 in our example), encrypts the result (110 in our example) and sends it back to the client,

• the client receives the result and decrypts it,

• the correctness of the whole process is checked, by matching the result with the original parameter:

o the process is correct and the tester approves, in this case the test evidence is saved (for example test id = 1, test input = 10, test result = 110) to a EVIDENCE DB, a certificate is created and saved to a CERTIFICATE DB with a Life Cycle ISSUED state.

o the process fails and the tester does not approve, no certificate is created.

We have a correct process (and an approval is made by the tester, see the last step of the process described before) when:

• the numeric value received by the client is correct (110 in our example),


Security: Public

Date 27/09/2013

/134

• the parameter sent by the client and intercepted by the intermediary software is encrypted; since the parameter was saved by the intermediate software, the client can decrypt and verify its correctness, similarly the client can decrypt and verify the parameter sent by the Web Service.

Instead the process fails when:

• the key used by the client is wrong,

• the key used by the Web Service is wrong,

• the decrypting operation fails,

• the parameter is not encrypted when received

• the result set received by the client is not correct, i.e. the add operation failed and this could be due to encryption/decryption issues.

A slight different case could be the offline testing of the same AIS:confidentiality:external-‐data-‐exchange-‐confidentiality security property (or “Confidentiality in transit”) when the Web Service performs an echo on an input string.

Platform offline testing for “Confidentiality at rest”

The second offline use case is about the AIS:confidentiality:service-‐provider-‐data-‐access-‐level security property or “Confidentiality at rest”. According to property description in D2-‐1 deliverable (CUMULUS, D2-‐1) the property describes the confidentiality level of the data in a TOC with respect to the personnel operating the TOC and it is expressed in terms of performance objective, independently of the underlying mechanism, with a level between 0 and 4.

As already stated, this test implies the verification of “Confidentiality at rest” i.e. at storage level; at the moment our simplified view does not consider the memory and the across tenancy level. The process we put in place should enable remote parties to assess whether a system meets the Confidentiality security goal of AIS:confidentiality:service-‐provider-‐data-‐access-‐level property.

The actors of our use case are: the tester, the client software (or probe) that performs the test, the Virtual Machine under test, and a trusted software agent at server side (the Testing Agent in our implementation).

In this scenario the Cloud Provider acts as an attacker, since the requirement is that the Cloud Provider cannot read client’s data.

Preliminary to our use case, the following actions are to be taken, since we propose to shift part of the verification process from our client side to the Cloud Provider site, where a software agent can verify and monitor some system characteristics on behalf of the client:

• the client has prepared a Virtual Machine with a Web Service that performs a simple operation (for simplicity we suppose the same arithmetic operation we saw before),

• the Virtual Machine has an encrypted disk and the encryption key is kept by the client only,

• the Virtual Machine is deployed at a Cloud Provider site,

• at boot time the Virtual Machine is launched by a server side software agent that is fully trusted by the client; this software agent, for example a service resident in another Virtual Machine, could check and monitor the system characteristics of all the VMs owned by the client and hosted at the Cloud Provider site (Schiffman, Vijayakumar e Jaeger 2012),

• the software agent can be queried by the client software since it offers a public interface,

• the software agent performs some basic operations:


Security: Public

Date 27/09/2013

/134

o the software agent must verify that the Virtual Machine is the one prepared by the client (signature check)

o the software agent keeps the association between the Virtual Machine identifier and the Web Services run by the Virtual Machine itself (among them there will be the WS which is performing the arithmetic operation we defined above) in a table row; also this table is signed by the client;

• at a later stage the client software will be able to query the software agent with an input (= the URL of a Web Service performing our simple arithmetic operation) and receiving an output (= ID of the Virtual Machine running that specific WS),

• there are several challenges in designing the software agent described above, but, since it works locally in the Cloud Provider infrastructure, in future a good option could be make it the core module of the online testing mechanism: it can have direct access to resident VMs and this eliminates the necessity of remote connections from the client to the target VM, and it can take immediate remedial measures such as rebooting the VM; however it must be deployed at a software layer whose integrity can be easily verified by the client.

For this use case the actions are:

• the tester needs to certify “Confidentiality at rest” for a certain Virtual Machine (TOC), that hosts a Web Service,

• the client software queries the software agent with input = Web Service URL and receives the Virtual Machine ID

• the software agent receives the request, retrieves the Virtual Machine ID, and checks the encryption status, by verifying that the VM cannot be boot without the correct password;

• the client software receives the answer and the correctness of the whole process is checked:

o if the process is correct (i.e. the information received by the client is that the server storage is properly encrypted) a certificate is created and saved to a CERTIFICATE DB with a Life Cycle ISSUED state.

o the process fails, no certificate is created.

Combination of Web Service and platform offline testing

We also could consider the full certification process involving both the “Confidentiality in transit” and the “Confidentiality at rest” to build another Certificate that is the composition of the two; see Figure 22. All these aspects will be taken into account in the second and third year of the project.

FIGURE 22 – CONFIDENTIALITY CERTIFICATE


Security: Public

Date 27/09/2013

/134

5.2.1. Design This use case falls into the UC_11 typology as described in D5-‐1 deliverable (CUMULUS, D5-‐1) and

corresponds to a scenario where the main actors use CUMULUS framework for getting all benefits that it offers when they need to manage a certification process. In particular a Certification Authority uses some CUMULUS framework components to issue a certificate on a cloud service. The basic flow described in D5-‐1 is the following: first a CA selects the service to be certified and the certification model to be used for its certification. This corresponds to the first steps of our process where a Tester need to certify “Confidentiality in transit” for a certain TOC, in our case a Web Service.

Then the same CA requests the CUMULUS framework the carry out a certification process. This means that the CA requests the generation of a certificate verifying the compliance of the service with specific security properties (AIS:confidentiality:external-‐data-‐exchange-‐confidentiality in our case), as specified in the Test based certification model.

The CUMULUS framework creates the certificate after the tester formal approval.

Then the CUMULUS framework (in our case the client software) stores, maintains and manages the certificate according to the provisions of the certification model.

In our case all the components used to certify Confidentiality fit into the CUMULUS Framework as it was described in D5-‐1 deliverable (CUMULUS, D5-‐1) i.e. an integrated framework of models, processes and tools supporting the certification of security properties of infrastructure (IaaS), platform (PaaS) and software application layer (SaaS) services in cloud networks.

5.2.2. Implementation We use the following environment:

1. Java as programming language,

2. Apache Tomcat as Application Server and Axis2 as WebService/Soap engine,

3. HttpClient libraries for querying the Web Services,

4. Quartz as a scheduler for the offline tests.

5.2.3. Examples of use

Offline tests can be run following the actions provided in the previous Sections. In all the positive circumstances a new Certificate record is created with an ISSUED life cycle state. If the tests fail no certificate is created.

5.3. Online testing Web Service online testing for “Confidentiality in transit”

As in the previous offline case, we perform an online testing to verify AIS:confidentiality:external-‐data-‐exchange-‐confidentiality security property (“Confidentiality in transit”), where the TOC must offer a confidential network channel for data exchanges with external parties (CUMULUS, D2-‐1); also here we utilize data encryption to certify the property.

The working environment is similar to the one we used for the offline testing: we have a Web Service in a cloud platform that performs a simple arithmetic operation. The differences between the previous offline case and the actual one are: (i) a Certificate already exists with an ISSUED life cycle state, (ii) the Certificate


Security: Public

Date 27/09/2013

/134

already contains the tests performed in the pre-‐production environment, and (iii) the tests must start when some conditions are verified, for example they are performed at a specified time or when traffic is under a certain threshold, or more simply they are performed periodically,

The actors of our use case are: the tester, the client software that performs the test, the aggregator module that computes metrics on the result set, the Web Service under test and a intermediary software that is in the middle of the communication.

We performs the following actions:

• the tester needs to certify “Confidentiality in transit” for a certain TOC; in our case the TOC is a Web Service,

• the tester chooses the starting conditions for the test; the conditions could be “periodic test” (when tests must be run periodically), “test performed at a specific time”, “when traffic is under a certain threshold”; let us suppose to choose “periodic test”,

• the client retrieves the certificate issued previously (i.e. certificate issued when test was performed offline in pre-‐production environment), reads it, and retrieves the tests from the Certificate; for example the tests to be run are test the same we did in offline mode (id = 1, test input value = 10, test result = 110),

• since the starting conditions are “periodic test” the client starts operating and sends an encrypted numeric parameter (test input value = 10) to the Web Service,

• the Web Service receives it and decrypts it,

• the Web Service performs the amount operation (i.e. 10 + 100 in our example), encrypts the result (110 in our example) and sends it back to the client,

• the intermediary software receives the result set, saves it, and sends it to the client,

• the client receives the result and decrypts it,

• the correctness of the whole process is checked by matching the result with the original parameter:

o the process is correct (i.e. actual result set received by the client and the old test evidence retrieved with the certificate match), the certificate is edited, the validity period of the certificate is extended, the certificate is saved to a CERTIFICATE DB with the same Life Cycle ISSUED state,

o the process fails since the actual and the old evidence do not match, the certificate is edited and saved to a CERTIFICATE DB with a Life Cycle SUSPENDED state.

Platform online testing for “Confidentiality at rest”

The second online use case is about AIS:confidentiality:service-‐provider-‐data-‐access-‐level security property (“Confidentiality at rest”). Also in this case as we did in offline mode, the test implies the verification of the storage level, but not the memory.

The actors of our use case are: the tester, the client software (or probe) that performs the test, the Virtual Machine under test, and the same trusted software agent at server side described in the previous Sections.

The Cloud Provider acts as an attacker, and the requirement is that the Cloud Provider must not be able to access clients’ data.


Security: Public

Date 27/09/2013

/134

We suppose that the same preliminary actions of the offline case were taken (i.e. the client has prepared a encrypted Virtual Machine with a Web Service that performs a simple operation, and the encryption key is kept by the client only, etc.).

For this use case the actions are:

• the tester needs to certify “Confidentiality at rest” for a certain Virtual Machine (TOC), that hosts a certain Web Service,

• the tester chooses the starting conditions for the test; the conditions could be “periodic test” (when tests must be run periodically), “test performed at a specific time”, “when traffic is under a certain threshold”; let us suppose we choose “periodic test”,

• the client retrieves the certificate issued previously (i.e. certificate issued when test was performed offline in pre-‐production environment), reads it, and retrieves the tests from the Certificate; for example the tests to be run are test the same we did in offline mode (id = 1, test input = IP address, test result = Boolean value),

• since the starting conditions are “periodic test” the client starts operating and queues the trusted software agent with input = Web Service URL,

• the software agent receives the request, retrieves the Virtual Machine IP address, sends the answer about the encryption status of the storage back to the client,

• the client software receives the answer and checks the correctness of the whole process:

o the process is correct (i.e. the feedback sent by the agent is that the server storage is properly encrypted), the certificate is edited (validity period extended) and saved to a CERTIFICATE DB still with a Life Cycle ISSUED state,

o the process fails since and the certificate is edited and saved to a CERTIFICATE DB with a Life Cycle SUSPENDED state.

Combination of Web Service and platform online testing

As in the offline case we can consider the two certification processes to build a Certificate that is the composition of the two “Confidentiality in transit” and “Confidentiality at rest” certifications. All these aspects will be taken into account in the second year of the project.

5.3.1. Design

This use case is very similar to the corresponding offline test falling into the UC_11 test case typology described by D5-‐1 deliverable (CUMULUS, D5-‐1): again the scenario where the main actors use CUMULUS framework to manage a certification process and a Certification Authority uses CUMULUS components to confirm a certificate on a cloud Web service.

5.3.2. Implementation We use the following environment:

5. Java as programming language,

6. Apache Tomcat as Application Server and Axis2 as WebService/Soap engine,

7. HttpClient libraries for querying the Web Services,

8. Quartz as a scheduler for the offline tests.


Security: Public

Date 27/09/2013

/134

5.3.3. Examples of use Online tests can be run following the actions provided in the previous Sections. As the certification

process does not fail, the Certificate record is retrieved and then stored with a new validity period and with a confirmed ISSUED life cycle state.

5.4. Supported Use Cases

The implementation of the testing components supports the UC_11 use case described in D5.1 CUMULUS deliverable for two different properties (UC_1 for “Confidentiality in transit” and UC_2 for “Confidentiality at rest”). The single use case describes both the offline and the online scenarios.


Use Case Name Cloud Service Certificate Generation on behalf of CA (where Security Property is “Confidentiality in transit”, the specific TOC layer is a Web Service, all based on a testing mechanism)

Use Case ID UC_1

Description: Generation of a Certificate for the Security Property “Confidentiality in transit” related to a specific Web Service layer (TOC), based on a testing mechanism in two scenarios: offline and online.

Certificate is generated in pre-‐production (offline) and confirmed in production (online).

Actors: Certification Authority, CUMULUS framework, Cloud infrastructure

Pre-‐conditions:

Trigger: A Certification Authority wants to start a certification process of a specific TOC layer for a specific security property

Basic Flow:

Offline (Static)

1 The Certification Authority starts the certification process by choosing a TOC (Web Service) and a property (Confidentiality in transit)

2 The Testing Manager starts operating, set-‐ups the operational specifications, generates Testing Module configuration, and then launches the Testing Module

3 The Testing Module tests the TOC and collects the test result set 4 If Offline (Static) tests are successful, the Testing Module generates

and stores the specific Certificate.

Online (Dynamic)

[1] The Certification Authority requests confirmation of the certificate [2] The Testing Manager starts operating, set-‐ups the operational

specifications, generates Testing Module configuration, and then launches the Testing Module


Security: Public

Date 27/09/2013

/134

[3] The Testing Module tests the TOC periodically and collects the test result set

[4] If Online (Dynamic) tests are successful, the Testing Module stores the specific Certificate with an extended validity period

Alternate flows:

Post-‐conditions:

Dependencies


Use Case Name Cloud Service Certificate Generation on behalf of CA (where Security Property is “Confidentiality at rest”, the specific TOC layer is a Virtual Machine, all based on a testing mechanism)

Use Case ID UC_2

Description: Generation of a Certificate for the Security Property “Confidentiality at rest” related to a specific Virtual Machine layer (TOC), based on a testing mechanism in two scenarios: offline and online.

Certificate is generated in pre-‐production (offline) and confirmed in production (online).

Actors: Certification Authority, CUMULUS framework, Cloud infrastructure, a server side agent, a client

Pre-‐conditions: A Virtual Machine with an encrypted disk was set up by a client and deployed at a Cloud Provider site; the encryption key is unknown to the Cloud Provider and is kept by the client only.

At boot time the Virtual Machine is launched by a server side software agent that is fully trusted by the client; this software agent can check and monitor the system characteristics of the VM hosted at the Cloud Provider site.

Trigger: A Certification Authority wants to start a certification process of a specific TOC layer for a specific security property

Basic Flow:

Offline (Static)

[1] The Certification Authority starts the certification process by choosing a TOC (Virtual Machine) and a property (Confidentiality at rest)

[2] The Testing Manager starts operating, set-‐ups the operational specifications, generates Testing Module configuration, and then launches the Testing Module

[3] The Testing Module tests the TOC and collects the test result set (in this case the Testing Module queries the Testing Agent)

[4] If Offline (Static) tests are successful, the Testing Module generates


Security: Public

Date 27/09/2013

/134

and stores the specific Certificate.

Online (Dynamic)

[5] The Certification Authority requests confirmation of the certificate [6] The Testing Manager starts operating, set-‐ups the operational

specifications, generates Testing Module configuration, and then launches the Testing Module

[7] The Testing Module tests the TOC periodically and collects the test result set (in this case the Testing Module queries the Testing Agent)

[8] If Online (Dynamic) tests are successful, the Testing Module stores the specific Certificate with an extended validity period

Alternate flows:

Post-‐conditions:

Dependencies

5.5. Architecture

The testing mechanisms have been implemented according to the architecture defined in D5-‐1 CUMULUS deliverable and have the following components:

1) Testing Manager: the component receives input from the various actors, start the certification process, and delegates the Testing Module to perform tests,

a. Testing Manager: the main subcomponent module,

b. TestCertificate Manager: the subcomponent accesses the Certificate database for storing/retrieving operations,

2) Testing Module: this component performs tests on the TOC for a specific property, receives the result set and computes metrics. It has the following sub-‐components:

a. Testing Module: the subcomponent sends test input and receives the result set,

b. Testing Agent: the subcomponent provides encryption information about the Virtual Machine under test (as requested, for example, in "Confidentiality at rest" property certification)

FIGURE 23 – TESTING COMPONENTS


Security: Public

Date 27/09/2013

/134

The following sequence diagram describes UC_1 in the offline scenario.

FIGURE 24 – TESTING SCENARIO (OFFLINE, CONFIDENTIALITY IN TRANSIT FOR A WS TOC)

The following sequence diagram describes UC_1 in the online scenario.

FIGURE 25 – TESTING SCENARIO (ONLINE, CONFIDENTIALITY IN TRANSIT FOR A WS TOC)

The following sequence diagram describes UC_2 in the offline scenario.


Security: Public

Date 27/09/2013

/134

FIGURE 26 – TESTING SCENARIO (OFFLINE, CONFIDENTIALITY AT REST FOR A VM TOC)

The following sequence diagram describes UC_2 in the online scenario.

FIGURE 27 – TESTING SCENARIO (ONLINE, CONFIDENTIALITY AT REST FOR A VM TOC)

5.6. Components

5.6.1. Testing Manager

The Testing Manager main task is setting up the CUMULUS testing infrastructure after a “Testing Manager API” call. The Testing Manager interface allows accessing, configuring and controlling the underlying and dynamically scalable Testing Module, setups operational specifications and then launches the Testing Module. The operational specifications define how the underlying Testing Module will perform the execution of tests needed to establish the current state of the test-‐based certificate of a cloud-‐based service.


Security: Public

Date 27/09/2013

/134

TestingManager API

AddTestingConfiguration This method initializes the process configuration

Parameters

testingConfiguration Type Configuration

5.6.2. TestCertification Manager

The TestCertificate Manager task is accessing the Certificate database to store or retrieve a certificate.

TestCertificate API

GetCertificate This method retrieves a Certificate from the Certificate database

Parameters

certID Type String

Return parameter

cert Type Certificate

GetCertificateByURL This method retrieves a Certificate from the Certificate database

Parameters

certURL Type String

Return Parameter


SetCertificateStatus This method sets the Certificate Life Cycle Status in the Certificate database

Parameters

certStatus Type String

certID Type String

DeleteCert This method deletes a Certificate in the Certificate database

Parameters

certID Type String

InsertCert This method inserts a new Certificates into the Certificate database

Parameters


AddConfiguration This method adds the configuration to the Certificate database


Security: Public

Date 27/09/2013

/134

Parameters

config Type Configuration

GetConfiguration This method gets the configuration from the Certificate database

Parameters

ID Type String

Return Parameter

Configuration Type Configuration

The following database table records the generated certificates in a Test-‐based scenario: Columns Description

CertificateId A unique identifier for every certificate

CertificationModelId A Foreign key reference to the certification model

Security_Property The security property to be certified

Certificate Status ISSUED /SUSPENDED / REVOKED

Expiration date Expiration date or Validity Period of the Certificate

Validity_Test Boolean for Validity Tests records in Validity Test table

ToC_Name Target of Certification name

The following database table records the validity tests for a single certificate: Columns Description

TestId A unique identifier for every test input/output

CertificateId A unique identifier for every certificate

Validity_Test_Input Validity Test Input

Validity_Test_Output Validity Test Output

5.6.3. Testing Module

The Testing Module runs the static/dynamic tests as instructed by Testing Manager. The Testing Module uses the test results either to create (when offline tests are performed) or to enable update (when online tests are performed) of certificate state according to the certificate lifecycle. The Testing Manager has also access to these results, in order to support advanced test analytics and enable run-‐time identification of test delivery problems.


Security: Public

Date 27/09/2013

/134

Testing Module

StartTest This method starts tests based on the input configuration

Parameters


configuration Type Configuration

Return parameter

certState Type Enum

ScheduleTest This method schedules the tests for the online scenario

Parameters

configID Type String

schedule Type String

PauseTest This method pauses the test execution

Parameters


ResumeTest This method resumes the test execution

Parameters


StopTest This method stops the test execution

Parameters


5.6.4. Testing Agent

The Testing Agent task provides information about the encryption status of Virtual Machine storage.

VerifyProperty This method gives information about storage encryption in an online test scenario

Parameters

vmID Type String

propertyName Type String

Return parameters

response Type boolean


Security: Public

Date 27/09/2013

/134

5.7. Open issues and future enhancements As already stated the online/offline tests describes in the previous Sections do not solve all the issues

related to Confidentiality security property since we may consider also “Confidentiality in memory” (memory must not be accessible by other parties and/or must be deleted after a given period of time) and “Confidentiality across tenants” (in case some the services are shared across tenants in a single Virtual Machine). In the next year of the project we will address these considerations.

As already stated for the offline case, the tests we perform do not solve all the issues related to Confidentiality security property, since the “Confidentiality in memory” and “Confidentiality across tenants” should also be taken into account.

6. Trusted Computing Mechanisms 6.1. Overview of Implementation

In cloud computing environment, many users participate in the CLOUD and they join or leave CLOUD dynamically. Other resources in the cloud computing platforms have the same behaviour too. Users, resources, and the CLOUD should establish the trustful relationship among themselves. And they will be able to deal with all these dynamic changes affecting the configuration of the environment. The CLOUD includes distributed users and resources from distributed local systems or organizations, which have different security policies. According to this reason, how to build a suitable relationship among them is a complex challenge. In fact, the requirements for the security in cloud computing environment have multiple aspects to be considered such as confidentiality, multiple security policies, constant evolution and dynamism of the services, the trust among the entities or the multiple building of trust domains. In the next section, we will propose the mechanism of trusted computing platform and other related functions that aid to achieve the trusted cloud computing requirements in the CUMULUS project.

The Trusted Computing Group (TCG) offers certification software for selected TCG specifications and they have also created a certification program, they have been created to promote consistent quality among products built to their specifications, providing useful tools and mechanisms to assist customers in verifying security and functional compliance of products fulfilling the TCG specifications. In particular, TCG’s TPM Certification program includes security evaluation requirements, based on the established international Common Criteria (CC) framework, and compliance testing requirements, based on TCG developed test suite tools. Software that successfully meet the requirements of a TCG certification program, such as security evaluation, compliance, and interoperability testing, can be awarded recognition on a certified software list. TCG is based on the CC since it is the most widely accepted information security standard. CC certification can be performed around the world, with certification labs available to our members in many countries to perform security evaluation of their software.

Certification offers a way aimed to ensure consistency of the implementation and interoperability of their products with those from other vendors following the TCG specifications. Public recognition of certified software may translate into increased sales. For users, certification helps the selection of products that are tested to implement specific capabilities and specifications, and that will be interoperable with other software using those specifications.

The Trusted Computing mechanism supports and helps to establish security environments. The model of trusted computing was originally designed to provide privacy and trust in the personal platform, and it becomes the Trusted Computing Platform (TCP), base of the trusted computing. Indeed the model of trusted computing is being developed to the network computing, especially the distributed systems environment. The cloud computing, as a distributed system model plays an important role in appearing e-‐businesses and research environments. Cloud Computing systems are evolving to Cloud Computing Services


Security: Public

Date 27/09/2013

/134

that integrate the cloud computing with web service technologies. So we can extend the trusted computing mechanism to cloud computing service systems by integrating TCP into cloud computing systems.

In cloud computing environment, different entities can appeal to join the Cloud. Then the first step is to prove their identities to the cloud computing system administration. Because cloud computing should involve a large amount of entities, such as users and resources from different sources, the authentication is important and difficult. Therefore one approach uses the TCP to help with the authentication mechanism in cloud computing. The TCP is based on the TPM. Indeed, the TPM is a logic independent hardware that can resist software or even hardware based attacks. The TPM contain a private master key which can provide protect for other information store in the cloud computing system, since the hardware certificate can store in TPM, this can provide the root of trust for users.

Since the users have full information about their identity, the cloud computing system can use some mechanism to trace the users and locate their origin. Because in the TCP the user’s identity is proved by user’s personal key and this function is integrated in the hardware, such as the BIOS and TPM, so it is very hard to the user to make deceiving for their identity information. Each site in the cloud computing system will record the visitor’s information. So by using the TCP mechanism in cloud computing, the trace of participants can be known by the cloud computing trace mechanism.

In the cloud computing system, there are a great number of users who hope to access to the cloud computing service. They do have their own goal and behaviour. If the cloud computing systems hope to deal with them one by one, there will be a great hard work. In order to reduce the complexity of the access control model, we should classify them into several classes or groups and define the required access control criteria for these classes. So the users should initially register themselves in to one or some of the classes and get some credentials to express their identities. When they make the access to the cloud computing resource or hope to get the cloud computing service, they should take their full ID, which includes their personal identities or the classes/group. The objective environment will have a relative simple way to control their accessing in order to reach the goal of trusted computing, the users should come from the TCP, and take the security mechanism on this platform to achieve the privacy and security for themselves. The user has his personal ID and secrete key, such as the USB Key, to get the right to use the TCP. They can use the decryption function to protect their data and other information. By using the remote attest function, the user in the TCP could to notify their identities and relevant information to the remote machine that they want to make access to. And each objective environment has the mechanism to clarify the accessing entity’s information about their identity, role, and other information about the security. The user should bind their personal ID used for TCP, the standard certificate, such as X.509, took from the CA, and the role information together. And the cloud computing system has the according mechanism to verify this information about each user. Moreover, a role hierarchy is introduced to reflect inheritance of authority and responsibility among the roles. If a user has a user-‐role certificate showing membership in role R, and a cloud computing service requires role r, the user should be able to get permission. On the other hand, the resource owners should also use this mechanism to express their identities, and get the rights to provide their resources to other users. The cloud computing service should present which role it will give the permission, when the cloud computing service notifies itself to the cloud computing environment. So the user will able to know whether he could make access to that cloud computing service before his action.

The encryption is another major mechanism. This function lets data be encrypted in such a way that it can be decrypted only by a certain machine, and only if that machine is in a certain configuration. This service is built by a combination of hardware and software application. The hardware maintains a “master secret key” for each machine, and it uses the master secret to generate a unique sub-‐key for every possible configuration of that machine. As a result, data encrypted for a particular configuration cannot be decrypted if the machine remains in a different configuration. When one machine wants to join the cloud computing, it will show its certificate and generate session key with other co-‐operators buy using the unique sub-‐key. If the configuration in the local machine is changed, the session key will not be useful. So in


Security: Public

Date 27/09/2013

/134

the distributed environment, we can use this function to transmit data to remote machine and this data can be decrypted when the remote machine has certain configuration. The user logins in the CLOUD from the TCP, which is based on the TPM and she obtain the trusted certificate from the CA. When the participant wants to communicate with the remote entity, it will carry all the information, including the personal ID, certificate and role information. And the information between them is protected with their session key.

Since the users have full information about their identity, the cloud computing system can use some mechanism to trace the users and get their origin. Because in the TCP the user’s identity is proved by user’s personal key and this mechanism is integrated in the hardware, such as the BIOS and TPM, so it is very hard to the user to make deceiving for their identity information. Before the distributed machine cooperates to do something, they should attest their local information to the remote site. When the user login the cloud computing system, his identity information should be recorded and verified at first. Each site in the cloud computing system will record the visitor’s information. So if the TCP mechanism is integrated into the cloud computing, the trace of the participants, including the users and other resources, can be knew by the cloud computing trace mechanism. Then if the participants do some malicious behaviour, they will be tracked and be punished. In order to achieve the trusted computing in the cloud computing system, we should have the mechanism to know not only what the participants can do, but also what the participant have done. So the monitoring function should be integrated into the cloud computing system to supervise the participants’ behaviour. In fact, reference monitors have been used in the operation system for more than several decades, and it will be useful in cloud computing too.

On its part hardware virtualization has enjoyed a huge impact in recent years as a way to reduce total cost of ownership of computer systems, which is especially relevant in corporate data centres (web hosting), where sharing each platform among multiple software workloads leads to improved utilization and reduced expenses. Nevertheless, this brings security concerns; workloads that share the same platform must often be kept separate for several reasons. Let us introduce some real cases to show it, government regulations may require an investment bank to maintain a strict separation between its market analysis and security underwriting departments, which includes their respective information processing facilities. Another example is given by commercial interests that the web sites of competing business not have access to each other’s data. Also it is relevant, concerns about malicious software subverting normal operations become especially acute in these shared hardware environments. As an example, a remote client of a medical services site would like to determine that the server is not running corrupted software that will expose private information to a third party or return wrong medical information. Thus the increasing use of virtualization gives rise to stringent security requirements. A combination of a hardware-‐based root of trust as the provided by TPM and a virtual machine is well suited to satisfy these requirements, as presented in. Particularly, the TPM enables remote attestation by digitally signing cryptographic hashes of software and hardware components, to affirm that those components are genuine or correct. In is presented an approach to virtualize the TPM that is necessary to make its capabilities available to all virtual machines running on a platform. Each virtual machine with need of TPM functionality should be made to feel that it has access to its own private TPM, even though there may be many more virtual machines than physical TPMs on the system. It is necessary to create multiple virtual TPM instances, each of which faithfully emulates the functions of hardware TPM.

In the context of CUMULUS, in a public cloud, you share computing resources with other companies. In a shared pool outside the enterprise, indeed you do not have any knowledge or control of where the resources run.

Most compliance standards do not envision compliance in the world, which proves that one of the key challenges in the cloud computing is data-‐level security. Indeed, there is a huge body of standards that apply for IT, security and compliance, governing most business interactions that will, over time, have to be translated to the cloud (SAML Oauth, OpenID, SSL/TLS). One of the most relevant aspects of the migration to the cloud is that despite the benefits on cloud computing, not least of which is significant cost savings,


Security: Public

Date 27/09/2013

/134

many corporations are likely rushing into cloud computing without serious consideration of the security implications. This is the main motivation of our work, thus we propose the certification of cloud applications. Certification has a long history as a mechanism for verifying properties and increasing trust in software services and their providers. Indeed, emerging research results in this area demonstrate the feasibility of this approach. CUMULUS deals with services at different levels in the Cloud Stack as known as platform as a service, henceforth we make use of the term service in this sense.

Certification is a widespread mechanism for the provision of assertions on security properties of entities; it is applied both to systems and services. The final objective of certificates is that people using or any entity interacting with certified entities can rely on the asserted properties. This must be performed in such a way that the process of certification is known to produce sufficient evidence for the validity of the property for the certified entity.

Current certification mechanisms find many fields of application in computer sciences, ranging from hardware certification to software certification. Software certification comprises a wide range of formal, semiformal, and informal evaluation techniques. Consequently, the certificates can have different types, and the certification process requires different mechanisms. However, current certification schemes are either insufficient or not applicable at all in cloud computing. Indeed they cannot be used to support and automate run-‐time security assessment in its current form. Existing certification processes include a thorough examination by experts following pre–defined and publicly accepted criteria, but the evidence itself is not typically part of the awarded certificate. This fact implies that the relying party needs to trust the certificate, the experts, and the certification scheme. In order to establish the trust the scheme being run by accredited authorities, the accreditation of the experts themselves, and the certificate being officially approved. While this applies to product and system certification, if the scope of the examination is the system itself, we need an even higher level of trust in the case of process certification. For those cases in which the scope is the process that has been used to produce a system, the relying party also needs to assume and accept that certain process qualities are likely to result in certain different system qualities.

6.2. Supported Use Cases

Figure 28 shows all the steps for the certificate creation and the certificate Use for the CUMULUS TPM-‐based certification model. Certificate creation action is performed by a Certification Authority in charge of evaluating a service according to a set of properties required. The Certification Authority produces the Service Security Assurance and by means of this represents the certificate for that particular service and a specific set of properties. The next step is the binding of the certificate to a state of the cloud stack. For this purpose a key pair bound to the CloudStack state is generated using the values of certain PCRs. A migratable key is included in the certificate as well as the public key of the Test environment together with some additional information as the state and the signature.

From the client side, the service owner installs the service and its associated certificate in the Cloud. Client selects the service, from this point he keeps connected to the service and the certificate associated to that service is verified. Certificate verification indicates that cloud state matches certificate with the signed reply, which is signed with the key associated to the service.


Security: Public

Date 27/09/2013

/134

FIGURE 28 – CERTIFICATE USE FOR TPM BASED CERTIFICATION

6.3. Architecture

The main target of our approach is bridging the gap that exists between the software certification and the means for hardware certification, in order to provide a solution for the whole system certification using hardware technology.

Trusted Computing (TC) technology is the hardware element for providing trustworthiness at the lower levels of the stack, as underlying infrastructure. The main functionality of TC is to allow someone else to verify that only authorized code runs on a system. This authorization covers initial booting and kernel and may also cover applications and various scripts. Just by itself TC does not protect against attacks that exploit security vulnerabilities introduced by programming bugs. However, since this kind of technology is considerably restricted, we have adopted an approach based on different levels of dependence on the Trusted Platform Module (TPM) chipset. According to the flexibility requirements of our system, by means of this mechanism we provide a tailored solution for different contexts. The provision of a complete study of the spectrum of possible cases is out of the scope of this paper. Our motivation is the description of the problem of the existing gap and provides a solution for the highest level of certified system stack, that is, the more TPM dependent one.

The proposed approach targets semi-‐automatic service certification using TPM as security technological basis. This approach makes use of certification for the higher layers, and for linking the certificates to proofs produced by TC for the lower layers, thus bridging the gap between these technologies. Figure 29 shows how TC Proofs are used to certify the lower layers (hardware, native OS and software infrastructure) and the software certificate is used for the higher levels (applications, services, software infrastructure).


Security: Public

Date 27/09/2013

/134

FIGURE 29 – CONCEPTUAL BINDING SCHEME

Current certification schemes do not provide a reliable way to assess the trustworthiness of a composite application at the point of use. We highlight that certificates are intended for human use. They lack machine-‐readable format and explicit and precise formulation of security properties, and therefore cannot be used for runtime security assessment. Additionally these are not suitable for dynamic environments, highly distributed environments, systems without a central control or controlled ownership, systems modified (e.g. by policy decisions), and these do not support dynamic replacement of components and the most relevant any kind of runtime binding mechanism. For this reason we make use of an extended concept of certificate.

We propose a mechanism based on a combination of certification of higher levels of abstraction (applications, services and parts of cloud software infrastructure) with the lower levels (hardware, Native OS, rest of cloud security infrastructure) using the TC Proofs, in such a way that software certificate and TC Proofs keeps. In practical application, we propose a model based on three levels of certification, to know the Service/Application, Platform and TC Proof.

Our definition of binding corresponds to any means used to guarantee that a certificate corresponds to a service in the cloud. The most relevant appeal settles in the importance that a failure to guarantee that the certificate corresponds to the service will yield the whole CUMULUS infrastructure useless. Since we face our problem for cloud computing, this entails some relevant challenges, such as certificates contain very heterogeneous information (Certifier, Processes, Evidences, Concepts, Modes, Results, Properties, etc.).

Additionally, it is important to mention that services in cloud are remote, opaque, dynamic and clients have restricted access capabilities to them, understood as services in the cloud stack as we previously aimed.

The binding mechanism designed fulfils certain requirements. We highlight that the main aim of our approach is to ensure that the service (code and data) remains unchanged since evaluation, which is the hardest target to achieve. Therefore, we should not bind certificates to services but to complete configurations. Likewise, if the service asserted uses other services, these are also unchanged. Also, any


Security: Public

Date 27/09/2013

/134

dynamic check can be conveniently performed (this means quickly, transparently…), and all relevant information contained in the certificate is bound to the service.

We aim an approach based on a previous study of the spectrum of possible cases of certified services in the cloud according to the level of flexibility and therefore its dependence on the TPM chipset. According to the flexibility requirements of our system, by means of this mechanism we provide a tailored solution for different contexts.

FIGURE 30 – NEW CERTIFICATION APPROACH

Figure 30 shows our certification approach together with the existing certification mechanisms structure. Opposite to current certification mechanisms based on previous software analysis then the certificate is generated. In our semantic based approach, we perform two intermediate steps to determine the proofs and to specify them to generate the certificate.

Figure 28 shows an overview of our approach, with both use cases. The certificate authorization (certificate creation) and client use case. The certificate creation entails three steps to know; the evaluation of the service where the CA inspects the service and search in the properties.

The second step is the certificate creation, according to the properties the CA fills certificate. The last step is securing the certificate, a key pair is generated using the TPM functionalities sealed with the state of the system, then both the public key and the migratable key are included in the certificate. The second use case corresponds to the client consists on three steps. By means of the set up the client verify the certificate using the key related with the service. The second step is the usage, client requests a service this replies encrypted/signature with private keys and the public key is used for the verification. In the last step the data within certificate are used to install the migratable key in the destination TPM.

The basic binding scheme to start with each service is asserted to operate with a key pair. Additionally, service providers can be made legally responsible for using the key pair only with the asserted service. The key pair resides in a TPM and it is bound to the asserted configuration of the service, since the TPM chipset provides means needed to both key generation and securely storage. The workflow is when the service is called, the TPM functionalities are used to attests the (complete) service configuration and the key is made available to the service. If the service has changed the TPM functionalities are used to check (attestation) will fail and the key will not be available. We highlight the fact that each response to a call to the service is signed with the service private key. In order to allow for different configurations each group of services sharing an infrastructure is executed in a virtual machine. Obviously, this solution implies some restrictions,


Security: Public

Date 27/09/2013

/134

such as services always run on TPM-‐equipped hardware. In those cases in which services run on virtual machines, then hardware must be provided on this. Evidently, clients must use cryptography, and also run on TPM-‐equipped hardware, at least in the more restricted cases. However, these restrictions are not hard to meet. Moreover, some restrictions can be relaxed since our model can be implemented without virtualization, and we can use sessions to avoid signature of all messages. One important appeal of our model is the inherent flexibility of this model since it allows that several binding mechanisms can co-‐exist.

As we previously mentioned, our approach is based on the usage of trusted computing technology, which is essential to perform the attestation of both the hardware and the native OS. Our basic scheme makes use of the sealed bind key functionality provided by the trusted computing technology, in such a way that the sealed bind key is used to encrypt part of the service code in such a way that it can be only used when the platform is in that trusted state. This model is very restrictive, but it provides a high level of security since it establishes a very limited execution environment. Nevertheless, the limitations of this model make difficult its integration in real world scenarios, but a tailored solution based on this scheme can be suitable for particular cases.

We differentiate between two use cases, the certificate creation use case, where the Certificate Authority is involved and the certificate User use case. The first step in the Certificate Creation use case is the service evaluation, which involves that the CA checks a list of properties that must be fulfilled and makes an inspection of the service. Thus, CA fills in the certificate form with extracted data. For this purpose, a key pair is created from a sealed key related to the state of the platform.

A possible binding scheme must to consider that each service is asserted to operate with a key pair. Additionally, service providers can be made legally responsible for using the key pair only with the asserted service. The key pair resides in a TPM and it is bound to the asserted configuration of the service. When the service is called, the TPM attests the (complete) service configuration and the key sets as available to the service. If the service has been changed the TPM functionality is used to attest the state the checking will fail and the key will not be available. Each response to a call to the service is signed with the service private key. In order to allow different configurations, each group of services sharing the same infrastructure is executed in a virtual machine.

This solution implies several restrictions, such as the services must be run on TPM-‐equipped hardware (or even virtualized). Additionally, the service clients must use cryptography. Nevertheless, these restrictions are not hard to meet and even some restrictions can be relaxed. In some cases we can do without virtualization. The most relevant appeal of our approach is the scalability.

TC Proofs are limited (for this scenario), in the case that a high-‐level certificate (for instance for a service) refers to a standard TC proof to define the platform state, and a different certificate needs to be issued for each valid platform configuration. This addresses to the need of improvements in flexibility, and interoperability. Following this target, we propose semantic approaches that can be the basis for the necessary improvements.

Certificate Service A provides “confidentiality of user data” if the platform provides “encrypted isolated storage”. The semantic proof specification is “encrypted isolated storage”. And destination platform provides “encrypted isolated storage” if measured configuration is “mc”.


Security: Public

Date 27/09/2013

/134

FIGURE 31 – SEMANTIC BASED CERTIFICATE USAGE

Figure 31 shows different steps in the workflow of the process of certification. In the traditional scheme validity and properties are analysed and then the certificate is accepted or rejected. In our scheme we introduced the extraction of runtime proofs that making use of a semantic proof specification TC software measurement are generated. Then workflow is split to generate measured TC Proof and we get the platform semantic certificate. Then the semantic proof certificate is generated and validated. Finally, measure TC proofs and required TC proofs from the semantic proof certificate are compared to accept or reject the certificate.

6.4. Components

Two main components are in the initial implementation of the TPM-‐based certification mechanism. The first component is the TPMSimulator that is next described in this section. The second component, called TPMVisualizer, is a graphical visualization tool that shows the PCRs status and the TPMs states, in order to show that the attestation is properly done.

6.4.1. TPMSimulator

The first version of the implementation of our model will be based on a TPM simulator in order to facilitate the tasks related to access and use of the TPM functionalities. The TPM simulator will be tailored developed for the proof of concept of the binding mechanism described. As it is shown in Figure 32, the class diagram of the TPM simulator is restricted to the functionalities requested for the proposed certification model.


Security: Public

Date 27/09/2013

/134

FIGURE 32 – TPM SIMULATOR CLASS DIAGRAM

For the implementation of our basic binding scheme we make use of the Certified Migratable Key (CMK) functionality provided by the TPM. It is a kind of key that is halfway between a non-‐migratable key and a migratable key. These are inside of a TPM chip, but it can be migrated to another TPM. Due to its features it fits in our requirements. At the time they are created, the creator has to pick up a Migration Authority (MA) or a Migration Selection Authority (MSA), which will have the authority to migrate the key. CMKs can both be migrated and also be considered secure; in the case you trust the MSA and MAs to migrate the key.

The complete trust and security functionality of a Trusted Computing Platform is based on the capabilities of the TPM to protect these keys and certificates. A TPM contains a Root of Trust Storage (RTS), which protects data and keys entrusted to the TPM. The RTS manages a small amount of volatile storage inside the TPM device that is used to hold currently used keys. Unused keys may be encrypted with a storage key and moved off the TPM chip, e.g., to a hard disk drive. The migratable key chain is designed so that only one key, the Legacy key (or Platform Migratable Storage Key) needs to be migrated in order to take all the keys below in the hierarchy in to a new TPM.

For the migration it could be necessary that keys are required on different platforms, which are handled by a user alternatively. Sharing the same key across multiple platforms may be achieved by using key migration mechanisms. Key migration mechanisms allow the private keys from TPM-‐protected key hierarchy to be attached to other TPM-‐protected storage trees.

Migratable Keys (MK) can be moved to another TPM by using either rewrap (TPM_MS_REWRAP) or migration scheme (TPM_MS_MIGRATE). To migrate a key with TPM_MS_REWRAP, a destination TPM selects a storage key. This will be used as a parent for the migratable key and sends its public part to a source TPM. The source TPM rewraps the migratable key under the destination public key. The using of destination public key should be authorized by owner with TPM_AuthorizeMigrationKey command and rewrap procedure can be done with command TPM_CreateMigrationBlob. Resulting blob is then forwarded to the destination TPM in conjunction with a plaintext object describing the public key from the key pair to be migrated. The destination TPM can load blob with TPM_LoadKey command.

Another alternative is the scheme based on the participation of an intermediary Migration Authority (MA). In this case we make use of the TPM_MS_MIGRATE mode provided by the TPM. In this scheme the source TPM is used to encrypt the migratable key under the public key of the MA. There is no assurance that the public key does actually represent the MA public key, therefore the owner of source platform must authorize the correct destination with a command TPM_AuthorizeMigrationKey before the creation of migratable blob with a command TPM_CreateMigrationBlob. Blob is passed to MA, where it is unwrapped and rewrapped under the public key of the destination TPM (MA runs TPM_MigrateKey command to do that). To prevent the intermediary from getting unauthorized access to the migrated key, the key is additionally protected with XOR encryption with randomly generated string. The string is sent directly to a


Security: Public

Date 27/09/2013

/134

destination TPM omitting the Migration Authority. The destination TPM can install the migratable blob with the TPM command TPM_ConvertMigrationBlob. Output of this command is a key blob including migratable key encrypted with a storage key. Then the key blob can be loaded into the TPM with a command TPM_LoadKey. Certified Migratable Keys (CMKs) can be migrated only with help of MA (TSS_MS_MIGRATE scheme), the migration with TPM_MS_REWRAP scheme is restricted. To enforce authorized control for CMK destination, either owner authorization or a Migration Selection Authority (MSA) can be used. If MSA was selected as intermediary using CMK creation, it will be then responsible for selection allowed Mas. Otherwise the owner should use a command TPM_CMK_ApproveMA to authorize a public key of intermediating MA.

PCR_Info

Get_PCR_Value This function returns the hash stored in a certain set of PCRs

Parameters

PCRs_index [Int] This parameter indicates the number of the indexes of PCRs to access

Quote This function updates the content of PCRs indicated in the parameters

Parameters

PCRs_index [Int] This parameter indicates the number of the indexes of PCRs to update

GetKey This function returns the indicated (in the paramenter) type of key of the TPM

Parameters

Key_Type key This parameter indicates the type of key (Migratable, NonMigratable)

LoadKey This function loads the key to be used

Parameters

key key This parameter indicates the key to be loaded

6.4.2. TPMVisualizer

The first version of the implementation of our model will be based on a TC simulator in order to facilitate the tasks related to access and use of the TC functionalities. The TC simulator will be tailored developed for the proof of concept of the binding mechanism described. As it is shown in Figure 33, the class diagram of the TC simulator is restricted to the functionalities requested for the proposed certification model.

Display TPM

ShowPCRValues This function shows PCR Values


Security: Public

Date 27/09/2013

/134

ShowTPMStatus This function shows TPM status

6.5. Future enhancements

As further developments we have planned to use the Raspberry pi version B with the Infineon TPM Module over one of the Expansion header. This development will be a proof of concept of the CUMULUS results in a real use case, taking advantages of the functionalities provided by the TPM chipset. The implementation plan for this development includes a first version by the end of the second year.

Appendix C describes in detail every step starting from the installation and configuration of an embedded Linux Distribution to the first use case for a TPM.

7. Conclusions In this deliverable we have provided a description of the implementation of initial versions of

components required for the realisation of the CUMULUS framework. These components belong to three general groups:

• Monitoring components

• Testing components

• TC components

and support the generation of monitoring, test and TC based certificates.

The implementation has been driven by the decision to focus on specific use cases in the overall CUMULUS architecture, notably the use cases regarding the generation and retrieval of certificates from the framework, and provide components that could offer an initial realisation of these use cases.

The components described in this document can be downloaded, installed and used according to the guidelines given in Appendix A, B and C either for monitoring, testing or TC components, respectively.


Security: Public

Date 27/09/2013

/134

References http://www.computing.co.uk/ctg/news/2113323/ovum-‐public-‐cloud-‐services-‐market-‐explode . https://cloudsecurityalliance.org/research/ocf/. Ammann, P., and J. Offutt. “Introduction to Software Testing.” (Cambridge University Press) 2008. Anisetti, M. et al. “ASSERT4SOA: Toward Security Certification of Service-‐Oriented Applications.” 2010. 38-‐40. Anisetti, M., Ardagna, C. A. and Damiani, E. “A Low-‐Cost Security Certification Scheme for Evolving Services.” IEEE 19th International Conference on Web Services. 2012. 122-‐129. Balasubramaniam, Sriram, Grace Lewis, Ed Morri, Soumya Simanta, and Dennis Smith. “SMART: Application of a Method for Migration of Legacy Systems to SOA Environments.” 2008. Blom, Remy. jQuery Repository. Cachin, C., Keider, I. and Shraer, A. “Trusting The Cloud.” IBM Research, Zurich Research laboratory, 2009. Catteddu, D. and Hogben, G. “Cloud Computing: Benefits, Risks and Recommendations for Information Security.” European Network and Information Security Agency (ENISA), 2009. Celesti, A., Tusa, M., and Puliafto, A. “Security and Cloud Computing:InterCloud Identity Management Infrastructure.” 19th IEEE International Workshops on Enabling Technologies:Infrastructures for Collavorative Enterprises. 2010. 263-‐265. CIO Council, and Chief Acquisition Office Council. “Creating Effective Cloud Computing Contracts for the Federal Government.” 2012. CSA. Cloud Audit. https://cloudsecurityalliance.org/research/cloudaudit/. —. Cloud Controls Matrix. https://cloudsecurityalliance.org/research/ccm/. CSA. “D2.1 Security-‐aware SLA specification language and cloud security dependency model.” 2013. —. Security Guidance for Critical Areas of Focus in Cloud Computing vol 2. http://www.cloudsecurityalliance.org/guidance/csaguide.v2.1.pdf (accessed June 2013). CUMULUS. “D2-‐1.” 2013. CUMULUS. “D2-‐2.” 2013. CUMULUS. “D5-‐1.” 2013. CUMULUS. “D6-‐1.” 2013. Damiani, E. and Mana, A. “Toward WS-‐Certificate.” ACM Workshop on Secure Web Services. 2009. Doelitzscher, F., Reich, C., Knahl, M. H. and Clarke, N. L. “Incident detection for cloud environments .” Third International Conference on Emerging Network Intelligence. 2011. Doelitzscher, F., Reich, C., Knahl, M. H., Passfall, A. and Clarke, N. L. “An agent based business aware incident detection system for cloud environments.” Journal of Cloud Computing: Advances, Systems and Applications 1 (2012). Emeakaroha, V. C., Calheiros, R.N., Netto, M.A.S., Brandic, I. and De Rose, C.A.F. “DeSVi: An Architecture for Detecting SLA Violations in Cloud Computing Infrastructures.” 2nd International ICST Conference on Cloud Computing. 2010. Foster, H. and Spanoudakis, G. “Advanced Service Monitoring Configurations with SLA Decomposition and Selection.” 26th Annual ACM Symposium on Applied Computing (SAC). 2011.


Security: Public

Date 27/09/2013

/134

Foster, H. and Spanoudakis, G. Dynamic Creation of Monitoring Infrastructures, In Service Level Agreements for Cloud Computing. Vol. 3, by Weider P. et al., 123-‐138. New York: Springer, 2011. Grobauer, B., Walloschek, T., and Stocker, E. “Understandingn Cloud Computing Vulnerabilities.” IEEE Security & Privacy. 2011. 50-‐57. Heiser, J. and Nicolett, M. “Assessing the Security Risks of Cloud Computing.” Gartner technical report. 2008. Herrmann, D. “Using the Common Criteria for IT security evaluation.” (Auerbach Publications) 2002. Herrmann, D.S. Using the Common Criteria for IT security evaluation. Auerbach Publications, 2002. Jensen, M., Schwenk, J., Gruschka, N. and Iacono, L. L. “ On Technical Security Issues in Cloud Computing.” IEEE International Conference on Cloud Computing. 2009. 109-‐116. Kamara, S. and Lauter, K. “Cryptographic cloud storage.” 14th International Conference on Financial cryptograpy and data security. 2010. 136-‐149. Kankanamge, C. “Web Services Testing with SoapUI.” 2012. Kearney, K., Torreli, F. and Kotsokalis, C. “SLA*: An Abstract Syntax for Service Level Agreements.” 10th IEEE/ACM International Conference on Grid Computing. 2010. 217-‐224. Kourtesis, D., E. Ramollari, D. Dranidis, and I. Paraskakis. “Increased reliability in SOA environments through registry-‐based conformance testing of web services.” Production Planning & Control, 2010: 130-‐144. Lanowitz, Theresa . Parasoft's Web Service Testing Tool Should. Gartner Research, 2002. Li, H., Dai, Y. and Yang, B. “Identity-‐Based Cryptography for Cloud Security.” IACR Cryptology ePrint Archive. 2011. 169-‐169. Lombardi, F. and Di Pietro, R. “Secure virtualization for cloud computing.” J. Netw. Comput. Appl. 34, no. 4 (July 2011): 1113-‐1122. Mahbub, K., Spanoudakis, G. and Tsigkritis, T. “Translation of SLAs into Monitoring Specifications.” In Service Level Agreements for Cloud Computing, by R. and P. Weider, P. Yahyapour. Springer-‐verlag, 2011. Massie, M. L., Chun, B. N. and Culler, D. E. “The ganglia distributed monitoring system: design, implementation, and experience.” Parallel Computing. 2004. 817–840. Mate Bacic, E. “The canadian trusted computer product evaluation criteria.” In Proc. of the Sixth Annual Computer Security Applications Conference, 1990. McGee, P., and C, Kaner. Experiments with high volume test automation. SIGSOFT Softw. Eng. Notes, 2004. Microsoft. “The Economics of Cloud for the EU Public Sector.” Microsoft. 2010. http://www.microsoft.eu/Portals/0/Document/EU_Public_Sector_Cloud_Economics_A4.pdf (accessed June 2013). Nagios. 2011. http://www.nagios.org/. Papazoglou, M., V. Andrikopoulos, and S. Benbernou. “Managing evolving services.” IEEE Software, 2011: 49-‐55. “PCI DSS Quick Reference Guide: Understanding the Payment Card Industry Data Security Standard v2.” PCI Security Standards Council. https://www.pcisecuritystandards.org/documents/PCI%20SSC%20Quick%20Reference%20Guide.pdf. Pezz`e, M., and M. Young. Software Testing and Analysis: Process, Principles, and Techniques. Wiley, 2010.


Security: Public

Date 27/09/2013

/134

Pino, L. and Spanoudakis, G. “Constructing Secure Service Compositions with patterns.” IEEE 8th World Congress on Services. 2012. 184-‐191. QuickTest Professional User Guide. Mercury Interactive Corporation. Russell, D., and G. Gangemi. “Computer Security Basics.” (O’REILLY,) 1991. Schiffman, J., H. Vijayakumar, and T. Jaeger. Verifying System Integrity by Proxy. 2012. SEI. “Securing Web services for army SOA.” 2011. Sekar, R., V. Venkatakrishnan, S. Basu, S. Bhatkar, and D. DuVarney. “Model-‐carrying code: A practical approach for safe execution of untrusted applications.” Proc. of the 19th ACM Symposium on Operating Systems Principles (SOSP 2003), 2003. Spanoudakis, G., Kloukinas, C. and Mahbub, K. “The SERENITY Runtime Monitoring Framework.” In Security and Dependability for Ambient Intelligence, 213-‐238. Springer, 2009. Tilley, and Parveen. “Software Testing in the Cloud.” 2012. Tilley, S., and T, Parveen. “Software Testing in the Cloud: Perspectives on an Emerging Discipline.” 2012. Twitter. Twitter Bootstrap. USA Department of Defense. “DEPARTMENT OF DEFENSE TRUSTED COMPUTER SYSTEM EVALUATION CRITERIA.” 1985.


Security: Public

Date 27/09/2013

/134

Appendix A: Monitoring Mechanisms In this chapter we describe the installation and basic usage instructions for the Monitoring Based

Certification Mechanism.

A.1 Installation Instructions

All the components of the Monitoring Architecture (as shown in Figure 3) and the required tools (e.g. MySQL database, OpenFire server, tomcat server and apache server) are released in a preconfigured Virtual Machine (denoted as Cumulus VM in the following text). It should be noted that the operating system Cumulus VM is Windows XP. In order to install and use the monitoring based certification tool follow the steps below,

1. Download Cumulus VM from the following location

url: ftp://ra.crema.unimi.it

login: CUMULUS

pwd: CuMuluS_ftp

File Name: Cumulus_VM.rar

2. Unzip Cumulus_VM.rar in C:\Cumulus_VM folder.

3. Download Oracle VM Virtual Box for Windows hosts (file name VirtualBox-‐4.2.18-‐88781-‐Win.exe) from the following link

https://www.virtualbox.org/wiki/Downloads

4. Install Oracle VM Virtual Box by double clicking on VirtualBox-‐4.2.18-‐88781-‐Win.exe. During the installation process accept all the default configurations. It should be noted that Cumulus VM is configured to have 2GB of memory and 10 GB of hard disk space. Therefore the Virtual Box should be installed on machine that has at least 4GB memory and 10GB free hard disk space. During the installation process, the installer may show several warning message stating that Virtual Box has not passed Windows Logo testing (as shown below). In all cases click on “Continue Anyway” button to continue the installation.


Security: Public

Date 27/09/2013

/134

5. Once the Virtual Box is installed successfully, start the virtual box by double clicking the icon “Oracle VM VirtualBox” on the desktop. This will start the Virtual Box as shown below

6. In order to import Cumulus VM in the installed Virtual Box, select Machine-‐>add menu as shown below

7. From the opened file dialog box, open the file “Cumulus VM.vbox” in the Cumulus_VM folder as shown below


Security: Public

Date 27/09/2013

/134

8. As mentioned before that Cumulus VM is configured with 2GB of memory, therefore the host machine needs to have at least 4GB of memory. If the host machine has memory lesser than 4GB, then Cumulus VM’s memory needs to be adjusted accordingly. This can be done by selecting Settings button from the toolbar of Oracle Virtual Box and then by selecting Systems in the setting dialog box as shown below

9. Once Cumulus VM is added successfully to the Oracle VM Virtual Box it should look as shown below.


Security: Public

Date 27/09/2013

/134

10. Cumulus VM can be started by clicking the Start button from the tool bar. During the booting process Cumulus VM may display several warning messages, which should be ignored. If Cumulus VM boots up successfully then following desktop will show up


Security: Public

Date 27/09/2013

/134

A.2 Example Scenario and Usage Instructions

A.2.1 Example Scenario

This release of Monitoring Based Certification Tool includes a case study in order to demonstrate the use cases described in Section 4.2. The case study is based on a simple web service (denoted as ORCInventoryService) that offers two operations. The partial WSDL of the service is shown in Figure A.1 <wsdl:definitions targetNamespace="http://localhost:8888/axis/services/ORCInventoryService" … … xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <wsdl:message name="hasSoldRequest"> <wsdl:part name="ID" type="xsd:string"/> </wsdl:message> <wsdl:message name="bookSaleRequest"> <wsdl:part name="ShopID" type="xsd:string"/> <wsdl:part name="SaleTO" type="xsd:string"/> </wsdl:message> <wsdl:message name="hasSoldResponse"> <wsdl:part name="hasSoldReturn" type="xsd:string"/> </wsdl:message> <wsdl:message name="bookSaleResponse"></wsdl:message> <wsdl:portType name="ORCInventory"> <wsdl:operation name="bookSale" parameterOrder="ShopID SaleTO"> <wsdl:input message="impl:bookSaleRequest" name="bookSaleRequest"/> <wsdl:output message="impl:bookSaleResponse" name="bookSaleResponse"/> </wsdl:operation> <wsdl:operation name="hasSold" parameterOrder="ID"> <wsdl:input message="impl:hasSoldRequest" name="hasSoldRequest"/> <wsdl:output message="impl:hasSoldResponse" name="hasSoldResponse"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="ORCInventoryServiceSoapBinding" type="impl:ORCInventory"> ... ... ... </wsdl:binding> <wsdl:service name="ORCInventoryService">.. .. .. </wsdl:service> </wsdl:definitions>

Figure A.1 – WSDL of ORCInventoryService

As shown in the figure ORCInventoryService has two operations, namely bookSale and hasSold. This release also includes a simple client for the ORCInventoryService that makes random calls to the operations of the ORCInventoryService.

In addition to the example service and it’s client, this release of Monitoring Based Certification Tool includes an example Certification Model to produce certificate for the ORCInventoryService based on the monitoring of the bookSale operation of the service. The partial Certification Model is shown in Figure A.2.


Security: Public

Date 27/09/2013

/134

<ns1:CertificationModel xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:ns4='http://www.sla_at_soi.eu/slamodel' xmlns:ns1='http://www.cumulus.org/certificate/model'.. .. .. > <Model_Id>1001</Model_Id> <CASignature>CUMULUS_City</CASignature> <SecurityProperty Property_Category="BCR:availability:percentage-of-uptime"> <Assertion ID="1100"> <InterfaceDeclr><ns4:Text/><ns4:Properties/> <ns4:ID>ORCInventoryService</ns4:ID> <ns4:ProviderRef>ORCProvider</ns4:ProviderRef> <ns4:Interface> <ns4:InterfaceSpec><ns4:Text/><ns4:Properties/> <ns4:Name>ORCInventoryService</ns4:Name> <ns4:Operation><ns4:Text/><ns4:Properties/> <ns4:Name>bookSale</ns4:Name> <ns4:Input><ns4:Text/><ns4:Properties/> <ns4:Name>ShopID</ns4:Name> <ns4:Auxiliary>false</ns4:Auxiliary> <ns4:Datatype>http://www.w3.org/2001/XMLSchema#string</ns4:Datatype> </ns4:Input> <ns4:Input><ns4:Text/><ns4:Properties/> <ns4:Name>SaleTO</ns4:Name> <ns4:Auxiliary>false</ns4:Auxiliary> <ns4:Datatype>http://www.w3.org/2001/XMLSchema#string</ns4:Datatype> </ns4:Input> </ns4:Operation> </ns4:InterfaceSpec> </ns4:Interface> </InterfaceDeclr> <VariableDeclr><ns4:Text/><ns4:Properties/> <ns4:Customisable> <ns4:Var>Var_ORCAvailabilityInventoryBookSale</ns4:Var> <ns4:Value><ns4:Value>1</ns4:Value> <ns4:Datatype>http://www.slaatsoi.org/coremodel/units#ms</ns4:Datatype> </ns4:Value> <ns4:Expr> <ns4:CompoundDomainExpr> <ns4:Subexpression> <ns4:SimpleDomainExpr> <ns4:ComparisonOp> http://www.slaatsoi.org/coremodel#less_than_or_equals </ns4:ComparisonOp> <ns4:Value><ns4:CONST><ns4:Value>1</ns4:Value> <ns4:Datatype> http://www.slaatsoi.org/coremodel/units#ms </ns4:Datatype> </ns4:CONST></ns4:Value> </ns4:SimpleDomainExpr> </ns4:Subexpression> <ns4:Subexpression> <ns4:SimpleDomainExpr> <ns4:ComparisonOp>http://www.slaatsoi.org/coremodel#greater_than </ns4:ComparisonOp> <ns4:Value><ns4:CONST><ns4:Value>0.65</ns4:Value> <ns4:Datatype>http://www.slaatsoi.org/coremodel/units#ms </ns4:Datatype> </ns4:CONST></ns4:Value> </ns4:SimpleDomainExpr> </ns4:Subexpression>


Security: Public

Date 27/09/2013

/134

<ns4:LogicalOp>http://www.slaatsoi.org/coremodel#and</ns4:LogicalOp> </ns4:CompoundDomainExpr> </ns4:Expr> </ns4:Customisable> </VariableDeclr> <Guaranteed> <ns4:ID>ORCAvailabilityInventoryBookSaleState</ns4:ID> <ns4:Priority xsi:nil="true"/> <ns4:Constraint> <ns4:TypeConstraintExpr> <ns4:Value> <ns4:FuncExpr><ns4:Text/><ns4:Properties/> <ns4:Operator> http://www.slaatsoi.org/commonTerms#availability </ns4:Operator> <ns4:Parameter><ns4:ID>ORCInventoryService/bookSale</ns4:ID> </ns4:Parameter> </ns4:FuncExpr> </ns4:Value> <ns4:Domain> <ns4:SimpleDomainExpr> <ns4:ComparisonOp>http://www.slaatsoi.org/coremodel#less_than </ns4:ComparisonOp> <ns4:Value><ns4:ID>Var_ORCAvailabilityInventoryBookSale</ns4:ID> </ns4:Value> </ns4:SimpleDomainExpr> </ns4:Domain> </ns4:TypeConstraintExpr> </ns4:Constraint> </Guaranteed> </Assertion> </SecurityProperty> <AssessmentScheme>.. .. .. </AssessmentScheme> <ValidityTests>.. .. ..</ValidityTests> <MonitoringConfigurations>.. .. .. </MonitoringConfigurations> <EvidenceAggregation> <Startdate>2013-15-09</Startdate> <Intervals intervalsTime="45" intervalUnits="seconds"></Intervals> <FunctionalAggregatorId>Average</FunctionalAggregatorId> <IntermediateResults>true</IntermediateResults> </EvidenceAggregation> <LifeCycleModel>.. .. ..</LifeCycleModel>

</ns1:CertificationModel>

Figure A.2 – Example Certification Model

As shown in the figure, the certification model defines a security property for category availability. The security property definition includes the interface of the ORCInventoryService that contains bookSale operation. The security property definition also includes a guarantee term which defines that the availability of the bookSale operation should be between 1 and 0.65 (i.e. greater than 65%). The certification model also defines that the evidence should be aggregated every 45 seconds during the monitoring period.


Security: Public

Date 27/09/2013

/134

A.2.2 Usage Instructions for Monitoring Based Certification

In order to execute case study described above, follow the steps below,

1. Start MySQL: In Cumulus VM, Go to Start -‐> Programs -‐> MySQL and click on “MySQL System Tray Monitor”. MySQL Tray Monitor short cut will appear on the status bar (right side of the status bar, near to the clock). Right click on “MySQL System Tray Monitor” on the status bar, and select “Start Instance” (as shown below). It will start the MySQL server. Once the server starts the red spot on the MySQL Tray Monitor short cut will turn into green.

2. Start Open Fire Server: Start open fire server by double clicking the icon “openfire” on Cumulus VM desktop. This will start open fire server that supports the event bus messaging of monitoring framework. Once the open fire server starts, the open fire window will look as shown below. You may minimize the open fire window once it is started.

3. Start Tomcat Server: Start tomcat server by double clicking the icon “Start Tomcat” on Cumulus VM desktop. This will start tomcat server that hosts i) ORCInventoryService and ii) CTP web services. Once tomcat server starts the tomcat console will look as shown below,


Security: Public

Date 27/09/2013

/134

4. Start Apache Server: Start apache server by double clicking the icon “Start Apache Server” on Cumulus VM desktop. This will start apache server that hosts the Dashboard. Once apache server starts the apache server console will look as shown below,

5. Start Event Captor: Start the event captor by double clicking the icon “Start Event Captor” on Cumulus VM desktop. This will start SOAP captor that intercepts all the events exchanged between ORCInventoryService and its client, and pushes the events to the event bus. Once the event captor starts, its console will look as shown below,


Security: Public

Date 27/09/2013

/134

6. Start Certification Manager: Start the certification manager double clicking the icon “Start Certification Manager” on Cumulus VM desktop. This will start the certification framework. This may require several minutes to load. Once certification manager starts, the console will look like as shown below,

7. Start Dashboard: The dashboard should be accessed through a web browser. Current implementation of the dashboard supports Mozilla Firefox and Google Chrome. Start the Firefox browser then locate the dashboard at the URL http://localhost/dahsboard as shown below,


Security: Public

Date 27/09/2013

/134

Click on the Generate button at the top navigation bar of dashboard. This will make the dashboard to contact certification manager and retrieve available security property categories and target of certifications from the database. The retrieved properties and categories are presented in a list as shown below,


Security: Public

Date 27/09/2013

/134

Select ORCInventoryService from the drop down list and click on the “Get Certification Models” button in the dashboard as shown below,

This will make the dashboard to contact the certification model service and retrieve certification models for the selected Target of Certification. The retrieved certification model IDs will be displayed as a list in the dashboard as shown below,


Security: Public

Date 27/09/2013

/134

Select Certification model 1001 from the drop down list and dashboard will display the certification model as shown below,

Now click on the “Generate certificate” button on the dashboard as shown below. This will make the dashboard to submit the selected certification model to the certification manager in order to generate a certificate.


Security: Public

Date 27/09/2013

/134

8. Start Inventory Client: Start the client to the ORCInventoryService by double clicking the icon “Start Inventory Client”. This will start the client that makes 50 calls to the operations of the ORCInventoryService through the Event Captor. Once the client starts, its console will look as shown below

The client randomly selects an operation to call from the ORCInventoryService and calls the operation with randomly selected input values. The client allows random delay between two successive calls where the delay is uniformly distributed in the range 0 to 5 seconds. When the client is invoking the ORCInventoryService the Event Captor intercepts all the exchanged messages and forwards the events to the monitor through the event bus and triggers the monitoring based certification process.

9. Retrieve Certificate: During the monitoring based certification process if a certificate is generated, it can be retrieved and viewed using the dashboard. To do this click on the Retrieval button in the navigation bar of the dashboard. If certificates are generated dashboard will list the certificates as shown below,


Security: Public

Date 27/09/2013

/134

To view the detail certificate click on the link of the certificate from the list and dashboard will display the whole certificate as shown below,

It should be noted that certification process only generates certificates if and only if the guarantee terms specified in the certification model are not violated during the monitoring process. Therefore, if there is no certificate generated after a monitoring session, then steps 6 – 9 can be repeated to generate certificates.

A.2.3 Usage Instructions for CTP

Bellow follows a list of tables that summarizes the web services that have been implemented to demonstrate some basic functionality of the CTP API. For a real demo, after a monitoring session as described in Section A.2.2 above, follow the link http://localhost:8888/CTP/ with Mozilla Firefox. Bear in mind that this is a demo and works properly only for service unit with id 1, cloud resource with id 1, attribute with id percentage-‐of-‐uptime and the only operation that can be invoked on the percentage-‐of-‐uptime attribute is a report, which practically means that the actual value of the property will be obtained.

Web Service URL

http://localhost:8888/CTP

Description


Parameters

None


Security: Public

Date 27/09/2013

/134

Response


2.Version of the CTP implementation

3. Link to the XML schema that the API conforms to

4.Link to the URL where a list with the service units can be found.

Example response

<baseURI self="http://localhost:8888/CTP/">


<version>1.00</version>

<link rel="schema" location="http://localhost:8888/CTP/schemas/ctp.xsd"/>

<link rel="serviceUnitCollection" location="http://localhost:8888/CTP/ServiceUnits"/>

</baseURI>

Web Service URL

http://localhost:8888/CTP/ServiceUnits

Description

This provides us with a list of the available service units offered by the cloud provider.

Parameters

None

Response


2.A collection with all the links that point to the available service units.

Response example

<serviceUnitCollection self="http://localhost:8888/CTP/ServiceUnits">


<collection>

<link rel="ServiceUnit" location="http://localhost:8888/CTP/ServiceUnits/1"/>






Security: Public

Date 27/09/2013

/134



</collection>

</serviceUnitCollection>

Web Service URL

http://localhost:8888 /CTP/ServiceUnits/{service unit id}

Description

This provides us with a set of information with regards to a specific service unit.

Parameters

None

Response


2.Provider of the service

3. Link to URL where the dependencies of that service unit can be discovered (Not implemented)

4.Link to the URL where a list with the cloud resources of that specific service unit can be found.

Response example <serviceUnit>


<provider>Cloud Secourity Alliance</provider>

<link rel="dependenciesCollection" location="http://localhost:8888/CTP/ServiceUnits/1/Dependencies"/>

<link rel="cloudResourceCollection" location="http://localhost:8888/CTP/ServiceUnits/1/CloudResources"/>

</serviceUnit>

Web Service URL

http://localhost:8888 /CTP/ServiceUnits/{service unit id}/CloudResources

Description

This provides us with a list of the available cloud resources offered by the cloud provider for a specific service unit.

Parameters

None

Response



Security: Public

Date 27/09/2013

/134

2.A collection with all the links that point to the available cloud resources for a specific service unit.

Response example <cloudResourceCollection self="http://localhost:8888/CTP/ServiceUnits/1/CloudResources">


<collection>

<link rel="CloudResource" location="http://localhost:8888/CTP/ServiceUnits/1/CloudResources/1"/>




</collection>

</cloudResourceCollection>

Web Service URL

http://localhost:8888 /CTP/ServiceUnits/{service unit id}/CloudResources/{cloud resource id}

Description

This provides us with a set of information with regards to a specific cloud resource of a specific service unit.

Parameters

None

Response


2. Name of the provider

3. Service class that the type of cloud resource belongs to.

4.Link to the URL where a list with the attributes of a specific cloud resource of a specific service unit can be found.

Response example <cloudResource>


<name>www.csa.org</name>

<serviceClass>IaaS-‐Compute</serviceClass>

<link rel="attributeCollection" location="http://localhost:8888/CTP/ServiceUnits/1/CloudResources/1/Attributes"/>

</cloudResource>


Security: Public

Date 27/09/2013

/134

Web Service URL

http://localhost:8888/CTP/ServiceUnits/{service unit id}/CloudResources/{cloud resource id}/Attributes

Description

This provides us with a list of the available attributes of a specific cloud resource of a specific service unit that are offered by the cloud provider.

Parameters

None

Response


2.A collection with all the links that point to the available attributes of specific cloud resource of a specific service unit.

Response example <attributeCollection self="http://localhost:8888/CTP/ServiceUnits/1/CloudResources/1/Attributes">


<collection>

<link rel="Attribute" location="http://localhost:8888/CTP/ServiceUnits/1/CloudResources/1/Attributes/percentage-‐of-‐uptime"/>

</collection>

</attributeCollection>

Web Service URL

http://localhost:8888/CTP/ServiceUnits/{service unit id}/CloudResources/{cloud resource id}/Attributes/{attribute id}

Description

This provides us with a set of information with regards to a attribute of a specific cloud resource of a specific service unit.

Parameters

None

Response


2. Description of how the value of the attribute will be represented

3. Capabilities represent the operations that can be applied on the specific attribute and the URL under which the service invocation can be made in order to perform the operation

4. Whether the attribute is active or not

Response example


Security: Public

Date 27/09/2013

/134

<attribute self="http://localhost:8888/CTP/ServiceUnits/1/CloudResources/1/Attributes/percentage-‐of-‐uptime/">


<attributeDefinition class="availability-‐class">

<attributeRowDefinition repeat="false">

<attributeCellDefinition name="percentage">

<type>cp:float</type>

</attributeCellDefinition>

</attributeRowDefinition>

</attributeDefinition>

<capabilities>

<link rel="report" location="http://localhost:8888/CTP/ServiceUnits/1/CloudResources/1/Attributes/percentage-‐of-‐uptime/report"/>

<link rel="trigger" location="http://localhost:8888/CTP/ServiceUnits/1/CloudResources/1/Attributes/percentage-‐of-‐uptime/trigger"/>

<link rel="commitment" location="http://localhost:8888/CTP/ServiceUnits/1/CloudResources/1/Attributes/percentage-‐of-‐uptime/commitment"/>

</capabilities>

<attributeState>ACTIVATED</attributeState>

</attribute>

Web Service URL

http://localhost:8888/CTP/ServiceUnits/{service unit id}/CloudResources/{cloud resource id}/Attributes/{attribute id}/report

Description


Parameters

None

Response


2.Link that points to the report of the specific attribute

3. The actual value of the attribute

4.Date and time that the report was taken

5. Assertion for the attribute if there is one

Response example


Security: Public

Date 27/09/2013

/134

<report>


<link rel="self" location="http://localhost:8888/CTP/ServiceUnits/1/CloudResources/1/Attributes/percentage-‐of-‐uptime/report/"/>

<attributeValue>

<attributeRowValue>

<attributeCellValue name="percentage-‐uptime">

<value>57</value>

</attributeCellValue>

</attributeRowValue>

</attributeValue>

<dateTime>Wed Aug 21 12:23:49 EDT 2013</dateTime>

<assertion/>

</report>


Security: Public

Date 27/09/2013

/134

Appendix B: Testing Mechanisms Download instructions

Ftp url: ftp://ra.crema.unimi.it (login: CUMULUS pwd: CuMuluS_ftp)

Download VMwareESXi5-‐VM.zip Windows7-‐VM.zip client.zip

Server side components are: VmWare Virtual Machine,Esxi , VmWare Tools; notice that an encrypted file system is provided inside VMwareESXi5-‐VM; another VmWare Virtual Machine (Windows7-‐VM) is provided with a management console.

Client side components are: Tomcat, Axis2, MySql, testing components in .jar format to be deployed in Tomcat environment.

Installation instructions

Unzip Virtual Machines

Install Tomcat, Axis2, MySql

Install .jar components in Tomcat environment

Usage instructions

At client side start Tomcat, MySql, EventReceiver, SOAPCollector (parameters: listening port for collector / l’host, requestport, host, listening port for EventReceiver; example java –jarSOAPCollector8081 localhost 8080 localhost 56777), VMEventsMonitor (parameters: URL ESXI username, ESXI password, VM username, VM password; example: java –jar VmEventsMonitor.jar https://172.16.75.128/sdkroot Pinturicchio_83 jonatan store), tester.

For use case #1 (confidentiality in transit) go to “Test Service Layer” tab

Select the Web Service and the Security Property

To run offline tests: press start and stop

To run online tests: set delay, press start and stop

For use case #2 (confidentiality at rest) go to “Test Service Layer” tab

Select the Virtual Machine and the Security Property

To run offline tests: press start and stop

To run online tests: set delay, press start and stop


Security: Public

Date 27/09/2013

/134

Appendix C: Trusted Computing Mechanisms

C.1 TPM Installation TPM installation within the CUMULUS framework step by step is described in this Appendix, this section

includes the new features described in this document are:

• The new Infineon TPM Module V1.2 which works with the Raspberry pi (kernel version 3.6.y).

• Use the Infineon TPM on the Raspberry pi

• Create an Openssl certificate with the Infineon TPM Module

We used a Debian Linux Distribution on the embedded platforms and if you like to use another Distribution, then you may adjust the commands in this document.

Hardware

The Hardware Distribution consists of:

• Host computer

• Raspberry pi

• Infineon TPM Module V1.2

• RS232 adapter for the connection between host and Raspberry Pi

• USB for power and Ethernet

• SD Flashcard

• Monitors with HDMI

The host system is a normal desktop computer or laptop with USB 2.0 and a serial port. A USB to serial adapter can be used for computers without a serial port.

FIGURE 33 – SERIAL TO USB

The Raspberry pi version B has a 700 MHz ARM11 processor and 256 MB or 512 MB Ram. An integrated Broadcom Video Core provides for a 1080p Video output. The next picture shows our Raspberry pi development with all expansions.


Security: Public

Date 27/09/2013

/134

FIGURE 34 – RASPBERRY PI EXPANSIONS

To work with the Raspberry, you need a monitor with HDMI connection and a USB-‐Keyboard, because it has no RS232 connection. Then the raspberry pi has an Ethernet controller for internet and a Micro USB supplies the Raspberry pi with power. The reset will only be triggered if the Raspberry pi is disconnected from power. These are all the differences between Raspberry.

Expansion header and TPM module

The TPM module can connect with Raspberry pi over one of the two Expansion headers. For data transfer the module uses the I2C bus.


Security: Public

Date 27/09/2013

/134

FIGURE 35 – TPM EXPANSION HEADER

The TPM board has a reset button, which ASSERTS the reset line of the TPM for the right amount of time after VCC becomes available. The reset on the module is low active and can also be set by combining the reset and the ground.

For a lot of TPM-‐commands you need “physical presence” which also can be set with a jumper (JP1). Physical presence is a security feature to ensure, that a person sits in front of the computer. For the application examples in this documentation you do not need to set hardware physical presence.

LED1 shows the 5 Volt and LED2 the VCC connection. Figure WW shows all pin assignments from the TPM module. On The Top is the Raspberry pi 26 pin header with 3.3 Volt, 5 Volt, SCL, SDA and Ground.


Security: Public

Date 27/09/2013

/134

FIGURE 36 – TPM PIN ASSIGMENTS

Pin 1 2 3 4 5 6 Signal +3.3 V +5 V SDA SCL GND

TABLE 4 – RASPBERRY EXPANSION CONNECTOR SIGNALS

The TPM module on the Raspberry pi looks like this.

FIGURE 37 – TPM ON RASPBERRY PI


Security: Public

Date 27/09/2013

/134

Software

Host Computer A native or virtual Linux Distribution like Ubuntu, Debian, Suse or something else should be used as

operating system on the host system. It is recommended to use Ubuntu 12.04 LTS.

All commands and troubleshooting hints in this guide have only been tested on this excact same Ubuntu version, other versions can be used on your own risk.

Although by default Ubuntu already comes with many features and packages, the following additional packages and programs must be installed manually via “sudo apt-‐get install [package name]“ (requires an active internet connection):

• git

• openssl

• openssh-‐server

• openssh-‐client

• vim

• dpkg

• ddrescue

• arm-‐linux-‐gnueabi

• ncurses-‐devel

• uboot-‐mkimage

Note: Since Debian (and thus all its derivates like Raspbian OS and Ubuntu) has a security concept similar to UAC on Windows Vista and higher, some actions might be restricted to the super user (aka root), even if you are logged in as a user with administrative rights. Thus, if any command in this guide fails, first retry the same command as root by putting “sudo ” in front of the command, e. g. “sudo apt-get install …” instead of just “apt-get install …”.

If you can’t install arm-‐linux-‐gnuebai then download the Linaro-‐toolchain and install it. Linaro-‐toolchain is a tool package for cross-‐compiling a new kernel on the host computer. Unzip the tar file and and install Linaro with the following commands. tar –xvaf gcc-linaro-4.7-2012.06.tar.bz2

cd gcc-linaro-4.7-2012.06

./configure

make

make install

Note: make is a command used to call the build steps defined in a makefile in the current directory.

You also can install the Linaro-‐toolchain with the following commands.

sudo add-apt-repository ppa:linaro-maintainers/tools

sudo apt-get update

sudo apt-get install gcc-arm-linux-gnueabi


Security: Public

Date 27/09/2013

/134

C.1.1 Installing Debian on the Raspberry pi

You need a two GB SD-‐Card for the Raspberry pi. You can download a precompiled Debian distribution and extract the file on your host computer. Switch to the new folder and copy the image on the SD-‐Card. Therefore connect the Flashcard via a Card reader to the host computer and insert the following command.

ddrescue [name of the image].img /dev/sdX

sdX is the SD-‐Card and X has to be replace by the correct Device which can be found with the command fdisk -l. You will be informed by the script if packages are missing. Insert the SD-‐Card into the Raspberry pi and reset it. Now the new Linux-‐kernel should boot. Username: pi Password: raspberry

o Compiling and patching a new Kernel for Raspberry pi The kernel, from the new Linux distribution does not support the TPM module. Therefore you have to

download, patch and compile a new Linux Kernel. Perform these steps on the host computer, because the compile process takes more than 6 hours on the Raspberry pi.

Now you need the new version of the Linux-‐kernel:

git clone https://github.com/raspberrypi/linux.git

Switch to the new directory

cd linux

If you like to use the new kernel and Infineon TPM driver (recommended), make sure to get the latest kernel branch. So far branch rpi-‐3.6.y worked fine. To verify which branch is currently checked out, type

git branch

Its output should be something like

*rpi-3.2.27

rpi-3.6.y (maybe this entry is missing completely on your system)

The “ * ” indicates which branch is selected. To switch to another branch, type

git checkout [branchname]

To see which branches are available and open the “branch:” drop down list box just above the file and folder list.

Copy the /proc/config.gz file via ssh from the Raspberry pi to the host. To do so, start the Raspberry, login and type the following command:

scp /proc/config.gz [username]@[host ip]:/path/to/your/home/folder


Security: Public

Date 27/09/2013

/134

You get the IP with ifconfig. Then extract the config.gz with the name .config to the linux folder.

zcat config.gz > /path/to/linux/.config

In order to use the new driver and kernel, you must apply two kernel patches BEFORE you continue. You can find them in the zip-‐file Sources → Raspberry pi → Kernelpatches. The patch 0001_raspberry_kernel includes the I²C driver from Chris Boot & Frank Buss.

Patch the kernel with

patch -p1 < [Patchname]

The patches are for older kernel versions, so errors will come up during applying the patches on the newer kernel. In that case, apply them manually, e.g. via copying the failed patch lines with a text editor.

After that, select the tpm-‐driver as module.

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- oldconfig

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig

Device Drivers → Character devices → TPM Hardware Support = M → TPM Interface Specification 1.2 Interface (I2C) = M

• arm is the architecture of the Raspberry pi • arm-linux-gnueabi is the Linaro-toolchain for cross-compiling the kernel Use the following commands to compile the modules and the kernel.

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- -jX

X is the number of cores you like to use for compiling. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules

You have to install the modules from the new kernel on the SD-Card; therefore we insert the card into the card reader of the host system and type the following command. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- INSTALL_MOD_PATH=/media/rootfs/ modules_install

/media/rootfs/ is the path to the root-file-system on the flashcard. To create a Raspberry pi aware kernel. You can also find them in Sources → Raspberry pi → Firmware. • args-uncompressed.txt • boot-uncompressed.txt • first32k.bin • imagetool-uncompressed.py Copy these files to the linux/arch/arm/boot folder on the host computer. Switch to the folder and create the kernel with the following command.

python imagetool-uncompressed.py Image

The python script creates a kernel.img. Copy this image to the boot partition from the SD-Card /media/boot.


Security: Public

Date 27/09/2013

/134

cp kernel.img /media/boot

Insert the SD-Card into the Raspberry pi and set the reset. Now the new Linux-kernel should boot. Note: If the Raspberry pi does not boot correctly, you have to update the Raspberry firmware.

o Using the TPM with Trousers To use the TPM under Linux, you have to install several packages on the embedded board, create a start up script and load the module drivers.

Installation apt-get install trousers

apt-get install tpm-tools

apt-get install openssl

apt-get install libcurl3-openssl-dev

apt-get install python

apt-get install libtspi-dev

apt-get install i2c-tools

FIGURE 38 – TPM RELATED SOFTWARE

Trousers is a CPL (Common Public License) licensed Trusted Computing Software Stack. It is the layer between the user application and the TCSD (Trusted Computing Software Deamon). Tpm-tools is a software for user-friendly commands which is based on Trousers.

Examples


Security: Public

Date 27/09/2013

/134

• tpm_version • tpm_takeownership • tpm_selftest • tpm_getpubek • etc. Tpm-tools send one of these commands to Trousers which interprets them and sends a TCSD-understandable command to the deamon. TCSD forwards this command to raw bytes and sends it to the TPM driver. To start the TCSD and Trousers you have to start the TPM driver and create a TPM startup script.

Before you can load the tpm driver-module you have to check over which i²c bus the tpm module is connected. Therefore use i2cdetect -r 1, i2cdetect -r 2 and i2cdetect -r 3. The Terminal output looks like this:

i2cdetect –r 2

WARNING! This program can confuse your I2C bus, cause data loss and worse!

I will probe file /dev/i2c-2.

I will probe address range 0x03-0x77.

Continue? [Y/n]

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- --

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

20: -- 20 -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --

70: -- -- -- -- -- -- -- --

The tpm-module is connected on the example above on i2c-bus 2. Now you can load the tpm driver.

echo tpm_i2c_infineon 0x20 > /sys/bus/i2c/devices/i2c-2/new_device

After loading the Infineon TPM driver the last output in dmesg shows like this:

tpm_tis_i2c 2-0020: 1.2 TPM (device-id 0xB)

tpm_tis_i2c 2-0020: A TPM error (38) occurred attempting to determine the timeouts

tpm_tis_i2c 2-0020: A TPM error (38) occurred attempting to determine the durations

tpm_tis_i2c 2-0020: A TPM error (38) occurred continue selftest


Security: Public

Date 27/09/2013

/134

The error massage means that the TPM needs a startup to run correctly. Copy the script from Sources → tpmstartup.py to the embedded platform and start it with:

python tpmstartup.py

Attention: After every restart you have to load the TPM driver, start the TPM startup scipt and the TCSD

This startup script is a modified version and takes these tasks: • Run a Startup • Run a TPM selftest • Set a flag that allow to use a Hardware PhysicalPresence • Set a flag that allow to use a Software Physical Presence • Set Physical Presence • Enable the TPM • Activate the TPM • Set a flag that allow to use Owner Start the TCSD deamon and put it in the background

tcsd –f

Press control + z, then type and execute command

bg

If you take the reset on the Infineon TPM module, you have to terminate the TCSD deamon with pkill tcsd and execute the TPM startup script and TCSD again. Now the trouser commands can be used. Attention: After every restart you have to load the TPM driver, start the TPM startup scipt and the

TCSD

o Create an openssl certificate In this section you create an openssl certificate on the embedded board with a key file, created by the TPM. Note: Before you can continue, you might have to set the system clock to a correct time. Search google for

how to do this.

Now download the libengine-tpm-oppenssl source and extract it with tar –xvaf libengine-tpm-openssl_0.4.1+20071221.orig.tar.gz. Switch to the new folder and change two lines in the create_tpm_key.c file.

From (line numbers might be slightly different) 148 char *filename, c, *openssl_key = NULL;

149 int option_index, auth = 0, popup = 0, wrap = 0;

To

148 char *filename, *openssl_key = NULL;

149 int option_index, c, auth = 0, popup = 0, wrap = 0;

Then configure and install the package. ./configure

make

make install


Security: Public

Date 27/09/2013

/134

Now you can use the TPM with the trouser commands to create a public key. For the next TPM commandos you need software physical presence and an enabled TPM (will be done in startup.py). Therefore set the physical presence jumper on the board. To enable and activate the Infineon TPM Module, insert the following commands: tpm_setenable -e -f

tpm_setactive –a

Note: After that you may have to reset the TPM, send the startup command again (via python startup.py) and restart the tcsd. If you cannot reset the chip independently, shutdown and turn off your embedded platform and disconnect the power supply. Now you can do a restart, load the TPM driver, send the startup and restart the tcsd as described in the previous chapter.

Then you have to create an owner (entering passwords is not necessary; just leave it empty and confirm with pressing enter): tpm_takeownership

With the next command you can create a public key. This key will be saved in the volatile storage. If you have used a password in the step before, you might need it in the next steps. create_tpm_key –a tpm_tss.key

Now create an Openssl certificate with the tpm_tss.key file:

openssl req -keyform engine -engine tpm -key tpm_tss.key -new -x509 -days 365 -out cert.crt

The certificate will be saved on the storage at the cert.crt. The openssl certificate uses the Infineon TPM Module as engine and the tpm_tss.key. The certificate should be new, based on cryptography standard x509 and will be valid for 365 days. Note: In case the command does not run, search for the libtpm.so at the library and replace tpm with the

path to it in the Openssl command. In my case the libtpm were at /usr/lib/openssl/engines/libtpm.so and my Openssl command looks like this: openssl req -keyform engine -engine /usr/lib/openssl/engines/libtpm.so -key /home/pi/tpm_tss.key -new -x509 -days 365 -out cert.crt

Now you can test the new certificate. Therefore start an openssl server on the Raspberry pi with the certificate, engine as tpm, the tpm_tss.key key file and connect with a client to the same computer:

openssl s_server -cert cert.crt -www -accept 4433 -keyform engine -engine tpm -key tpm_tss.key

Note: In case the command does not run, use full path for engine as described in previous note.

Press control + z, then type and execute command bg

openssl s_client -connect localhost:4433 # or https://localhost:4433


Security: Public

Date 27/09/2013

/134

o Create an GnuTLS certificate GnuTLS is Open Source Software for secure communication. The library implements SSL, TLS and DTLS and works with x.509, PKCS #12, OpenPGP and other required structures. This section explains each step from the installation and configuration of GnuTLS to the first use case for Infineon TPM. The difference to “Create an openssl certificate” is that the key is stored on the Infineon TPM.

§ Installation

Before you install the packages on the embedded Linux platform you have to load the tpm module driver and start the tcsd.

$ echo tpm_i2c_infineon 0x20 > /sys/bus/i2c/devices/i2c-2/new_device

$ python tpmstartup.py

$ tcsd -f

Press ctrl + z, then type and execute this command

$ bg

To use GnuTLS with the Infineon TPM you have to install the following packages with

$ apt-get install

• keyutils • libkeyutils-dev • libpam-dev • python-dev • cryptsetup • trousers • trousers-dbg • m4 • guile-1.8 • guile-1.8-dev And download these four packages with wget [download URL]

• gmp 5.0.5 or newer (http://gmplib.org/) • libnettle 2.5 (http://www.linuxfromscratch.org/blfs/view/svn/postlfs/nettle.html) • PKCS#11 (http://p11-glue.freedesktop.org/p11-kit.html) • gnutls 3.1.1 (http://ftp.gnu.org/gnu/gnutls/) (for gnutls 3.1.2 or newer you have to install unbound-

anchor) Now you have to compile and install the downloaded sources with the following commands:

Gmp, Libnettel, PKCS#11

$ tar -xvaf (Packagename)

$ cd (new folder)

$ ./configure --prefix=/usr/

$ make

$ make install


Security: Public

Date 27/09/2013

/134

Gnutls

$ tar -xvaf (Packagename)

$ cd (new folder)

$ ./configure –prefix=/usr/

After configure GnuTLS you get a list with supported tools: configure: summary of build options:

version: 3.1.1 shared 39:0:11

Host type: armv7l-unknown-linux-gnueabi

Install prefix: /usr

Compiler: gcc -std=gnu99

CFlags: -g -O2

Warning flags: errors: warnings:

Library types: Shared=yes, Static=yes

Valgrind: no

configure: Optional features: (note that included applications might not compile properly if features are disabled)

OCSP support: yes

OpenPGP support: yes

SRP support: yes

PSK support: yes

Anon auth support:yes

Trust store pkcs:

Trust store file: /etc/ssl/certs/ca-certificates.crt

CRL file:

configure: Optional applications:

crywrap app: yes

local libopts: yes

configure: Optional libraries:

Guile wrappers: no

C++ library: yes

OpenSSL compat: yes

configure: Hardware acceleration/support:

/dev/crypto: no

Hardware accel: none

PKCS#11 support: yes TPM support: yes


Security: Public

Date 27/09/2013

/134

Check is the TPM and PKCS#11 support is enabled and install GnuTLS with the following commands.

$ make

$ make install

o Generate a Certificate with GnuTLS Before you can generate a certificate you have to set the TPM Owner.

$ tpm_takeownership

Enter owner password: Confirm password: Enter SRK password: Confirm password: The SRK password should not be empty. Now you can create a TPM key which will be stored in the user section of the Infineon TPM.

$ tpmtool --generate-rsa --bits=2048 --register -–user

The terminal output looks like this:

tpmkey:uuid=fcf82685-83fb-423b-89c1-20da0d4189a9;storage=user

The Infineon TPM has generated a user private key and the uuid is a link to it. The private keys never leave the TPM. With the command tpmtool --list you can see all uuids to the TPM-keys.

$ tpmtool -–list

Available keys: • 0: tpmkey:uuid= fcf82685-83fb-423b-89c1-20da0d4189a9;storage=user • 1: tpmkey:uuid=00000000-0000-0000-0000-000000000001;storage=system

With the new generated uuid you can create a public key which will be stored in pubkey.pem.

$ tpmtool --pubkey "tpmkey:uuid=fcf82685-83fb-423b-89c1-20da0d4189a9;storage=user" --outfile=pubkey.pem

To create a certificate you need also a ca-key and ca-cert file, which will be created by the following two commands.

$ certtool --generate-privkey --outfile ca-key.pem

$ certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca-cert.pem


Security: Public

Date 27/09/2013

/134

Now you have all files to generate the certification. This command uses the private key on the TPM and the created public key is stored under pubkey.pem.

$ certtool --generate-certificate --outfile cert.pem --load-privkey "tpmkey:uuid=fcf82685-83fb-423b-89c1-20da0d4189a9;storage=user" --load-pubkey pubkey.pem --load-ca-certificate ca-cert.pem --load-ca-privkey ca-key.pem

You have to insert the hostname at “Enter a dnsName of the subject of the certificate” and “Enter a URI of the subject of the certificate”. To test the new certificate use the following command to start the gnutls server and client therefore you can use a minicom and ssh connection to the Raspberry:

$gnutls-serv --x509keyfile " tpmkey:uuid=fcf82685-83fb-423b-89c1-20da0d4189a9;storage=user " --x509certfile cert.pem -p 443

$ gnutls-cli --x509cafile ca-cert.pem --x509keyfile ca-key.pem -p 443 debian

The Client output looks like that:

Processed 1 CA certificate(s).

Resolving 'debian'...

Connecting to '127.0.1.1:443'...

- Peer's certificate is trusted

- The hostname in the certificate matches 'debian'.

- Successfully sent 0 certificate(s) to server.

- Session ID: BE:AD:C9:F1:9B:28:B9:F3:4F:94:69:36:37:83:90:D3:F4:48:DD:E1:F3:75:3A:1B:73:2A:98:B0:2D:8F:D5:4D

- Server has requested a certificate.

- Certificate type: X.509

- Got a certificate list of 1 certificates.

- Certificate[0] info:

- subject `O=debian', issuer `', RSA key 2048 bits, signed using RSA-SHA256, activated `2000-01-01 00:30:18 UTC', expires `2000-12-31 00:30:20 UTC', SHA-1 fingerprint `85ec56ec4be04f6b24c912179bab4df323d'

Public Key Id:

ed8ef4a8872cdbb7b50aa9b3ed4651268f49b78d

Public key's random art:

+--[ RSA 2048]----+

| |

| o + |

| . O + |

| + E.. |

| .S . |

| .. . |

| oo.. o |

| o++oo* . |

| +B=+=o+ |

+-----------------+


Security: Public

Date 27/09/2013

/134

- Ephemeral EC Diffie-Hellman parameters

- Using curve: SECP192R1

- Curve size: 192 bits

- Version: TLS1.2

- Key Exchange: ECDHE-RSA

- Cipher: AES-128-CBC

- MAC: SHA1

- Compression: NULL

- Handshake was completed

- Simple Client Mode:


Security: Public

Date 27/09/2013

/134

Appendix D: Evidence XML Schema

D.1 Detailed Evidence XML Schema

FIGURE 39 – DETAILED EVIDENCE XML SCHEMA

In the figure above it is shown the elements of the detailed evidence XML Schema. Every event has a sequence of elements defined, such as:

1) The EventId of a type EventIdType, 2) The EventContext, of a type EventContectType, 3) The EventPayload, of a type EventPayloadType, and 4) The EventMetaData, an optional element of a type EventMetaDataType.

1. The EventId element (Figure 40) consists of an ID of the specific event, an EventTypeId, which defines if the event is detailed evidence, aggregated evidence, or monitoring result evidence.


Security: Public

Date 27/09/2013

/134

FIGURE 40 – EVENTIDTYPE

2. In the EventContext element, the Time, the Notifier and the Source elements are defined.

2.1. The Time element (Figure 41) consists of the Timestamp element, the CollectionTime and the ReportTime.

FIGURE 41 – EVENTTIME

2.2. The Notifier element defines notifier (event captor) of each primitive event that is collected regarding the assessment of security properties, and consists of a name element, a IP address and a port number used by the notifier (Figure 42).


Security: Public

Date 27/09/2013

/134

FIGURE 42 – EVENTNOTIFIER

2.3. The Source element consists of a choice of a SwServiceLayerSource, a InfrastructureLayer, or any other source type as shown in Figure 43.

FIGURE 43 – EVENTSOURCE


Security: Public

Date 27/09/2013

/134

3. The EventPayload element, in which one of the following four payload types should be defined:

3.1. InteractionEvent, in which the operation name and Id should be defined, as well as the status and any arguments as parameters should be presented for the specific monitoring security property (Figure 44).

FIGURE 44 – INTERACTIONEVENTTYPE

3.2. MonitoringResultEvent, which consists of the SecurityPorpertyInfo, the MonitoringInfo and any ExtraPorperties that should be defined, as presented in Figure 45.


Security: Public

Date 27/09/2013

/134

FIGURE 45 – MONITORINGRESULTEVENTTYPE

3.3. PredictionResultEvent, which consists of the SecurityPropertyInfo element, the PredictionInfo element and any extra properties that need to be defined (Figure 46).


Security: Public

Date 27/09/2013

/134

FIGURE 46 – PRECONDITIONRESULTEVENTTYPE

infrastructureMonitoringEventType, in which should be defined an Ifrastructure Id, a SourceId, the Type of the Infrastructure and the Infrastructure properties (Figure 47).

FIGURE 47 – INFRASTRUCTUREMONITORINGEVENTTYPE

4. The EventMetadata element, which consists of a key element and a value, as shown in Figure 48


Security: Public

Date 27/09/2013

/134

FIGURE 48 – EVENTMETADATATYPE

D.2 Aggregated Evidence XML Schema

FIGURE 49 – AGGREGATED EVIDENCE XML SCHEMA


Security: Public

Date 27/09/2013

/134

The Aggregated Evidence consists of four elements, as sown in Figure 49:

1) The ReportInfo element, of a type ReportInfoType, 2) MonitoringResult element, of a type MonitoringResultEventType, 3) AssessmentResultSummary element, of a type AssessmentResultSummaryType, and 4) FunctionalAggregatorResultSummary element, of a type FunctionalAggregatorResultSummaryType.

1. In the ReportInfo element all the relevant information about the aggregated evidence should be defined, such as the reportId, the timestamp, the start and end Time of the aggregated period, the certification model instance used to assess the property and the creator Id of the aggregation (Figure 50).

FIGURE 50 – REPORTINFOTYPE

1. The MonitoringResult element defines the type of the result, the SecurityPropertyInfo, the MonitoringInfo and any extra properties that need to be defined, as shown in Figure 51.


Security: Public

Date 27/09/2013

/134

FIGURE 51 – MONITORINGRESULTEVENTTYPE

2. The AssessmentResultSummary element consists of the SecurityProperty and the Guarateed elements. In the both elements the number of violations, satisfactions or not assessed events are defined, as shown in Figure 52.


Security: Public

Date 27/09/2013

/134

FIGURE 52 – ASSESSMENTRESULTSUMMARYTYPE

3. In the FunctionalAggregatorResultSummary element the security property Id, the guaranteed Term Id, the functional aggregator Id and the aggregated value are being defined (Figure 53).

FIGURE 53 – FUNCTIONALAGGREGATORRESULTTYPE


Security: Public

Date 27/09/2013

/134

Appendix E -‐ Examples of Certification Model and Certificate XML Representation

E.1 Example of Certification Model XML Representation

<?xml version="1.0" encoding="UTF-‐8"?> <ns1:CertificationModel xmlns:xsi='http://www.w3.org/2001/XMLSchema-‐instance' xmlns:ns4='http://www.sla_at_soi.eu/slamodel' xmlns:ns3='http://slasoi.org/monitoring/citymonitor/xmlrule' xmlns:ns2='http://assert4soa.eu/schema/Assert_SQL' xmlns:ns1='http://www.cumulus.org/certificate/model' xsi:schemaLocation='http://assert4soa.eu/schema/Assert_SQL Assert_SQL.xsd http://www.slaatsoi.eu/slamodel slasoi.xsd http://slasoi.org/monitoring/citymonitor/xmlrule EC_Assertion.xsd http://www.cumulus.org/certificate/model CertificationModel_XMLSchema.xsd'> <Model_Id>1001</Model_Id> <CASignature>CUMULUS_City</CASignature> <SecurityProperty Property_Category="BCR:availability:percentage-‐of-‐uptime"> <Assertion ID="1100"> <InterfaceDeclr> <ns4:Text></ns4:Text> <ns4:Properties> <ns4:Entry> <ns4:Key></ns4:Key> <ns4:Value></ns4:Value> </ns4:Entry> </ns4:Properties> <ns4:ID>CumulusPaymentService</ns4:ID> <ns4:ProviderRef>CumulusProvider</ns4:ProviderRef> <ns4:Endpoint> <ns4:Text></ns4:Text> <ns4:Properties> </ns4:Properties> <ns4:ID></ns4:ID> <ns4:Location></ns4:Location> <ns4:Protocol></ns4:Protocol> </ns4:Endpoint> <ns4:Interface> <ns4:InterfaceSpec> <ns4:Text></ns4:Text> <ns4:Properties></ns4:Properties> <ns4:Name>PaymentService</ns4:Name> <ns4:Operation> <ns4:Text> </ns4:Text> <ns4:Properties> </ns4:Properties> <ns4:Name>paymentValidation</ns4:Name> <ns4:Input> <ns4:Text> </ns4:Text> <ns4:Properties></ns4:Properties>


Security: Public

Date 27/09/2013

/134

<ns4:Name>cardInformation</ns4:Name> <ns4:Auxiliary>false</ns4:Auxiliary> <ns4:Datatype>http://www.w3.org/2001/XMLSchema#string</ns4:Datatype> </ns4:Input> <ns4:Input> <ns4:Text> </ns4:Text> <ns4:Properties> </ns4:Properties> <ns4:Name>cardNumber</ns4:Name> <ns4:Auxiliary>false</ns4:Auxiliary> <ns4:Datatype>http://www.w3.org/2001/XMLSchema#integer</ns4:Datatype> </ns4:Input> <ns4:Output> <ns4:Text> </ns4:Text> <ns4:Properties> </ns4:Properties> <ns4:Name>PaymentServiceResponse</ns4:Name> <ns4:Auxiliary>false</ns4:Auxiliary> <ns4:Datatype>http://www.w3.org/2001/XMLSchema#string</ns4:Datatype> </ns4:Output> </ns4:Operation> </ns4:InterfaceSpec> </ns4:Interface> </InterfaceDeclr> <VariableDeclr> <ns4:Text></ns4:Text> <ns4:Properties> </ns4:Properties> <ns4:Customisable> <ns4:Var>SERVICE_UPTIME_VAR</ns4:Var> <ns4:Value> <ns4:Value>90</ns4:Value> <ns4:Datatype>http://www.slaatsoi.org/coremodel/units#percentage</ns4:Datatype> </ns4:Value> <ns4:Expr> <ns4:CompoundDomainExpr> <ns4:Subexpression> <ns4:SimpleDomainExpr> <ns4:ComparisonOp>http://www.slaatsoi.org/coremodel#greater_than_or_equals</ns4:ComparisonOp> <ns4:Value> <ns4:CONST> <ns4:Value>90</ns4:Value> <ns4:Datatype>http://www.slaatsoi.org/coremodel/units#percentage</ns4:Datatype> </ns4:CONST> </ns4:Value> </ns4:SimpleDomainExpr> </ns4:Subexpression> <ns4:Subexpression>


Security: Public

Date 27/09/2013

/134

<ns4:SimpleDomainExpr> <ns4:ComparisonOp>http://www.slaatsoi.org/coremodel#less_than</ns4:ComparisonOp> <ns4:Value> <ns4:CONST> <ns4:Value>100</ns4:Value> <ns4:Datatype>http://www.slaatsoi.org/coremodel/units#percentage</ns4:Datatype> </ns4:CONST> </ns4:Value> </ns4:SimpleDomainExpr> </ns4:Subexpression> <ns4:LogicalOp>http://www.slaatsoi.org/coremodel#and</ns4:LogicalOp> </ns4:CompoundDomainExpr> </ns4:Expr> </ns4:Customisable> </VariableDeclr> <Guaranteed> <ns4:ID>AvailabilityState</ns4:ID> <ns4:Priority xsi:nil="true" /> <ns4:Constraint> <ns4:TypeConstraintExpr> <ns4:Value> <ns4:FuncExpr> <ns4:Text /> <ns4:Properties /> <ns4:Operator>http://www.slaatsoi.org/commonTerms#serviceUptime</ns4:Operator> <ns4:Parameter> <ns4:ID>CumulusPaymentService/paymentValidation</ns4:ID> </ns4:Parameter> </ns4:FuncExpr> </ns4:Value> <ns4:Domain> <ns4:SimpleDomainExpr> <ns4:ComparisonOp>http://www.slaatsoi.org/coremodel#equals</ns4:ComparisonOp> <ns4:Value> <ns4:ID>SERVICE_UPTIME_VAR</ns4:ID> </ns4:Value> </ns4:SimpleDomainExpr> </ns4:Domain> </ns4:TypeConstraintExpr> </ns4:Constraint> <ns4:Precondition> <ns4:CompoundConstraintExpr> <ns4:Subexpression> <ns4:CompoundConstraintExpr> <ns4:Subexpression> <ns4:TypeConstraintExpr> <ns4:Value> <ns4:FuncExpr> <ns4:Text /> <ns4:Properties />


Security: Public

Date 27/09/2013

/134

<ns4:Operator>http://www.slaatsoi.org/coremodel#day_is</ns4:Operator> </ns4:FuncExpr> </ns4:Value> <ns4:Domain> <ns4:SimpleDomainExpr> <ns4:ComparisonOp>http://www.slaatsoi.org/coremodel#equals</ns4:ComparisonOp> <ns4:Value> <ns4:CONST> <ns4:Value>MONDAY</ns4:Value> <ns4:Datatype>http://www.w3.org/2001/XMLSchema#gDay</ns4:Datatype> </ns4:CONST> </ns4:Value> </ns4:SimpleDomainExpr> </ns4:Domain> </ns4:TypeConstraintExpr> </ns4:Subexpression> <ns4:Subexpression> <ns4:TypeConstraintExpr> <ns4:Value> <ns4:FuncExpr> <ns4:Text /> <ns4:Properties /> <ns4:Operator>http://www.slaatsoi.org/coremodel#day_is</ns4:Operator> </ns4:FuncExpr> </ns4:Value> <ns4:Domain> <ns4:SimpleDomainExpr> <ns4:ComparisonOp>http://www.slaatsoi.org/coremodel#equals</ns4:ComparisonOp> <ns4:Value> <ns4:CONST> <ns4:Value>TUESDAY</ns4:Value> <ns4:Datatype>http://www.w3.org/2001/XMLSchema#gDay</ns4:Datatype> </ns4:CONST> </ns4:Value> </ns4:SimpleDomainExpr> </ns4:Domain> </ns4:TypeConstraintExpr> </ns4:Subexpression> <ns4:Subexpression> <ns4:TypeConstraintExpr> <ns4:Value> <ns4:FuncExpr> <ns4:Text /> <ns4:Properties /> <ns4:Operator>http://www.slaatsoi.org/coremodel#day_is</ns4:Operator> </ns4:FuncExpr> </ns4:Value> <ns4:Domain> <ns4:SimpleDomainExpr>


Security: Public

Date 27/09/2013

/134

<ns4:ComparisonOp>http://www.slaatsoi.org/coremodel#equals</ns4:ComparisonOp> <ns4:Value> <ns4:CONST> <ns4:Value>WEDNESDAY</ns4:Value> <ns4:Datatype>http://www.w3.org/2001/XMLSchema#gDay</ns4:Datatype> </ns4:CONST> </ns4:Value> </ns4:SimpleDomainExpr> </ns4:Domain> </ns4:TypeConstraintExpr> </ns4:Subexpression> <ns4:Subexpression> <ns4:TypeConstraintExpr> <ns4:Value> <ns4:FuncExpr> <ns4:Text /> <ns4:Properties /> <ns4:Operator>http://www.slaatsoi.org/coremodel#day_is</ns4:Operator> </ns4:FuncExpr> </ns4:Value> <ns4:Domain> <ns4:SimpleDomainExpr> <ns4:ComparisonOp>http://www.slaatsoi.org/coremodel#equals</ns4:ComparisonOp> <ns4:Value> <ns4:CONST> <ns4:Value>THURSDAY</ns4:Value> <ns4:Datatype>http://www.w3.org/2001/XMLSchema#gDay</ns4:Datatype> </ns4:CONST> </ns4:Value> </ns4:SimpleDomainExpr> </ns4:Domain> </ns4:TypeConstraintExpr> </ns4:Subexpression> <ns4:Subexpression> <ns4:TypeConstraintExpr> <ns4:Value> <ns4:FuncExpr> <ns4:Text /> <ns4:Properties /> <ns4:Operator>http://www.slaatsoi.org/coremodel#day_is</ns4:Operator> </ns4:FuncExpr> </ns4:Value> <ns4:Domain> <ns4:SimpleDomainExpr> <ns4:ComparisonOp>http://www.slaatsoi.org/coremodel#equals</ns4:ComparisonOp> <ns4:Value> <ns4:CONST> <ns4:Value>FRIDAY</ns4:Value> <ns4:Datatype>http://www.w3.org/2001/XMLSchema#gDay</ns4:Datatype>


Security: Public

Date 27/09/2013

/134

</ns4:CONST> </ns4:Value> </ns4:SimpleDomainExpr> </ns4:Domain> </ns4:TypeConstraintExpr> </ns4:Subexpression> <ns4:LogicalOp>http://www.slaatsoi.org/coremodel#or</ns4:LogicalOp> </ns4:CompoundConstraintExpr> </ns4:Subexpression> <ns4:Subexpression> <ns4:TypeConstraintExpr> <ns4:Value> <ns4:FuncExpr> <ns4:Text /> <ns4:Properties /> <ns4:Operator>http://www.slaatsoi.org/coremodel#time_is</ns4:Operator> </ns4:FuncExpr> </ns4:Value> <ns4:Domain> <ns4:CompoundDomainExpr> <ns4:Subexpression> <ns4:SimpleDomainExpr> <ns4:ComparisonOp>http://www.slaatsoi.org/coremodel#greater_than_or_equals</ns4:ComparisonOp> <ns4:Value> <ns4:CONST> <ns4:Value>8.0</ns4:Value> <ns4:Datatype>http://www.w3.org/2001/XMLSchema#time</ns4:Datatype> </ns4:CONST> </ns4:Value> </ns4:SimpleDomainExpr> </ns4:Subexpression> <ns4:Subexpression> <ns4:SimpleDomainExpr> <ns4:ComparisonOp>http://www.slaatsoi.org/coremodel#less_than_or_equals</ns4:ComparisonOp> <ns4:Value> <ns4:CONST> <ns4:Value>18.0</ns4:Value> <ns4:Datatype>http://www.w3.org/2001/XMLSchema#time</ns4:Datatype> </ns4:CONST> </ns4:Value> </ns4:SimpleDomainExpr> </ns4:Subexpression> <ns4:LogicalOp>http://www.slaatsoi.org/coremodel#and</ns4:LogicalOp> </ns4:CompoundDomainExpr> </ns4:Domain> </ns4:TypeConstraintExpr> </ns4:Subexpression> <ns4:LogicalOp>http://www.slaatsoi.org/coremodel#and</ns4:LogicalOp> </ns4:CompoundConstraintExpr>


Security: Public

Date 27/09/2013

/134

</ns4:Precondition> </Guaranteed> </Assertion> </SecurityProperty> <AssessmentScheme> <EvidenceSufficiencyCondition Id="1011"> <MonitoringPeriodCondition minMonitoredPeriod="720" periodUnit="hours"/> </EvidenceSufficiencyCondition> <ExpirationCondition Id="987"><elapsedPeriod period="1" periodUnit="years"/></ExpirationCondition> <Conflict Id="1100"> <ConflictConditions>Rule Violation</ConflictConditions> <Resolution Id="1101"> <ActionConditions SizeOfEvidence="" TimeToNextAggregation=""></ActionConditions> <Actions definiton=""></Actions> </Resolution> </Conflict> </AssessmentScheme> <ValidityTests></ValidityTests> <MonitoringConfigurations> </MonitoringConfigurations> <EvidenceAggregation> <AggregatedResultsInfo Startdate="2013-‐01-‐01" Timestamp="2014-‐08-‐31" NumberOfEvents="" intervalsTime="720" intervalUnit="hours"></AggregatedResultsInfo> <EventSummary NumberOfViolations="" NumberOfSatisfactions=""></EventSummary> <AggregatedValue>average</AggregatedValue> <IntermediateResults>true</IntermediateResults> </EvidenceAggregation> <LifeCycleModel> <InitialState stateId="10001" name="Activated"> <description> </description> </InitialState> <states> <state stateId="10010" name="Issued"> </state> <state stateId="10011" name="Audit"> </state> <state stateId="10100" name="Revoked"> </state> </states> <transitions> <transition From="10001" To="10010"> <Conditions negated="false"> <Condition> <evidenceSufficiencyCondition> 1011 </evidenceSufficiencyCondition> </Condition> </Conditions> </transition> <transition From="10010" To="10011"> <Conditions negated="false"> <Condition> <ExpirationCondition> … </ExpirationCondition> </Condition> </Conditions> </transition>


Security: Public

Date 27/09/2013

/134

<transition From="10010" To="10100"> <Conditions negated="false"> <Condition> <conflictCondition>1100</conflictCondition> </Condition> </Conditions> </transition> <transition From="10011" To="10010"> <Conditions negated="false"> <Condition> <OtherCondition></OtherCondition> </Condition> </Conditions> </transition> <transition From="10100" To="10010"> <Conditions negated="false"> <Condition> <conflictCondition>1101</conflictCondition> </Condition> </Conditions> </transition> <transition From="10100" To="10101"> <Conditions negated="false"> <Condition> <conflictCondition>1101</conflictCondition> </Condition> </Conditions> </transition> </transitions> <FinalState stateId="10101" name="Ended"> </FinalState> </LifeCycleModel> </ns1:CertificationModel>

E.2 Example of Certificate XML Representation

<?xml version="1.0" encoding="UTF-‐8" standalone="yes"?> <ns3:assert4SoaASSERTStandaloneType ValidNotOnOrAfter="2013-‐12-‐21T22:02:00.300Z" ValidNotBefore="2013-‐08-‐29T15:32:57.089+01:00" SerialNumber="1377786777089" xmlns:ns2="http://www.w3.org/2000/09/xmldsig#" xmlns:ns3="urn:assert4soa:assert:2.0"> <ASSERTCore> <CertificationProcess> <TargetOfCertification Type="http://www.assert4soa.eu/ontology/a4s-‐language/a4s-‐language#Service-‐application"> <TOCComponents> <TOCComponent TargetOfEvaluation="true" ID="ORCInventoryService"/> </TOCComponents> </TargetOfCertification> </CertificationProcess> <SecurityProperty PropertyAbstractCategory="http://www.assert4soa.eu/ontology/security/security#Availability"> <PropertyContexts>


Security: Public

Date 27/09/2013

/134

<PropertyContext>http://www.assert4soa.eu/ontology/a4s-‐language/a4s-‐language#InTransit</PropertyContext> </PropertyContexts> <NameID>BCR:availability:percentage-‐of-‐uptime</NameID> </SecurityProperty> <ServiceBinding> <WSDLBinding> <ServiceName>ORCInventoryService</ServiceName> </WSDLBinding> </ServiceBinding> <ASSERTIssuer>CUMULUS_City</ASSERTIssuer> </ASSERTCore> <ASSERTTypeSpecific> <ASSERT-‐E> <Property> <PropertyName>http://www.assert4soa.eu/ontology/security/security#Availability</PropertyName> </Property> </ASSERT-‐E> </ASSERTTypeSpecific> </ns3:assert4SoaASSERTStandaloneType>


Security: Public

Date 27/09/2013

/134

Glossary AIK Attestation Identity Key

CA Certification Authority

CMK Certified Migratable Key

CTP Cloud Trust Protocol

EVEREST Event Reasoning Toolkit

MA Migration Authority

MD Monitoring Dashboard

MK Migratable Key: key whose private part can leave the Trusted Platform Module (TPM) providing a higher level in terms of flexibility.

MSA Migration Selection Authority

NMK Non-‐migratable key: key especially useful for preventing unauthorized access to some data present in a platform that never leaves the platform

PCA Privacy Certification Authority

PCR Platform Configuration Register

RCG Reasoning Component Gateway

RTS Root of Trust Storage

SMaRT Service Monitorability Reporting Tool

SOA Service-‐Oriented Architecture

SOAP Simple Object Access Protocol

TC Trusted Computing

TCG Trusted Computing Group

TOC Targets Of Certification

TPM Trusted Platform Module

d3.1 version for pcc - cordis · document)name:)d3.1)core)certification)mechanisms)v1)...

Documents