Grant agreement no: Project Acronym: INTrEPID Project Title: INTelligent systems for Energy Prosumer buildings at District level

Transcription

1 Grant agreement no: Project Acronym: INTrEPID Project Title: INTelligent systems for Energy Prosumer buildings at District level Instrument: STREP Call identifier: FP7-ICT Deliverable D3.4: Communication architecture for device interoperability Due date: Delivery Date: Start of Project: Duration: 36 Months Nature: Report Dissemination Level: PU Executive summary This document describes the INTrEPID communication architecture. It focuses on devices interoperability by providing system infrastructure information and security within the cloud in compliance with the architecture and specifications of WP2. Partners owning: ADV Authors: G. Glorioso (ADV), N. Cuervo (ADV), C. Borean (TI), R. Drogo De Iacovo (TI) Partners contributed: ADV, TI, HON, SLX, and ENEL Revision: 1.0

2 Table of Contents 1. Introduction INTREPID Architecture Cloud Infrastructure Models Cloud models and architecture mapping INTrEPID Requirements Cloud models and requirements INTrEPID Cloud Model selection Framework for Secure communications within the INTrEPID network HAN-to-Middleware communications SSL/TLS VPNs solutions Including VPN-based solution into INTREPID Security for ZigBee connections ZigBee Trust Center used in INTrEPID Security policies for ZigBee profiles Trust Center in INTrEPID ZigBee Gateway Cloud Security and Assets Management IaaS- Availability Distributed Data Center Elimination of single point failure Load balancer Storage services Redundancy of components Monitoring services Asset Management Assets inventory Assets updates Back-up recovery policy Access control policies Identity management (Identity and Access Management) Components for communication over insecure network Publish/subscribe model for message broker Availability Confidentiality Middleware messaging security ActiveMQsecurity Authentication and authorization control of messaging assets Keys, certificates and CA certificates INTREPID secure architecture proposal Network security configuration Establishing a connection OpenVPN (for each workstation hosting an adapter): INTREPID Public Deliverable 2 2

3 5.3 Establishing a connection over HTTPS Conclusions References Acronyms INTREPID Public Deliverable 3 3

4 1. Introduction This document is part of WP3 developments regarding T3.4. The task is in charge of developing an infrastructure that ensures INTrEPID architecture components interoperability while dealing with security and privacy requirements. The deliverable is made of the following chapters: Chapter two consists of a mapping between several Cloud Infrastructure models and the intrepid architecture requirements. This mapping further defines which components will be stored or be hosted in the Cloud and which will be accessible from the Cloud via a remote connection. In addition, a section analysing different technologies for implementing the model is added to end up with a motivation for the technology selection. Chapters three and four provide a deeper analysis on intra-intrepid communications and Cloud security considerations. Several alternatives for secure communications implementation over IP based networks are presented along with security management in the Cloud infrastructure. As such, these chapters provide information about existing technologies for secure communication in order to allow partners involved in INTrEPID network design select their infrastructure and provide their requirements parameters for its implementation. INTREPID Public Deliverable 4 4

5 2. INTREPID Architecture The following architecture corresponds to the INTrEPID system. Its layers represent heterogeneous hardware and software components that perform their execution in different environments therefore they need a platform to enable a seamless communication with each other in an easy and secure manner. Moreover, this architecture has been envisioned as a highly distributed system designed by the basics of SoA (Service oriented Architecture) concept where microservices [1] are exposed to other components of the system. Therefore, computational processing power is distributed like in Grid computing models and Cloud models. Figure 1: INTrEPID Architecture As Grid computing architecture can be similar than the INTrEPID architecture (Figure 2), in this model one large job is divided into many small portions and executed on multiple machines. This characteristic is fundamental to a grid; not so in a cloud. Grid computing is usually confused with Cloud computing yet the main advantage of Cloud is that the infrastructure intended to allow the user to avail of various services without investing in the underlying architecture [2] which is one of the main reasons of its wide adoption and its suitability for instantiating INTrEPID components. INTREPID Public Deliverable 5 5

6 Figure 2: Grid computing architecture In this context, all components requirements should be addressed by the proposed platform to host these applications. Specifications about non-functional requirements define the selection of a suitable infrastructure to work with the system therefore this chapter will map these requirements with different cloud models characteristics. 2.1 Cloud Infrastructure Models In this section, an overview of main Cloud models is outlined for the selection for the instantiation of INTrEPID services as a distributed system. Based on the location where services are deployed the Cloud can be classified in four different infrastructures: Public: The computing infrastructure is located in the premises of a cloud computing company that offers the cloud service; Private: The Cloud infrastructure (network) is used only by one customer/organization Hybrid: Both Public and Private Community Cloud: The infrastructure can be both located in and out provider premises and is shared between organizations, usually with the shared data and data management concerns. Based on services the Cloud offers, it can be classified in infrastructure, platform, software or storage. The latest is out of INTrEPID scope as there is no reason why hiring storage capacity, therefore the three main categories of Cloud services relevant for INTrEPID are: Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS). INTREPID Public Deliverable 6 6

7 Figure 3: Cloud computing models Software as a Service (SaaS) is a software delivery method that provides access to software and its functions remotely as a Web-based service. With SaaS, a provider licenses an application to customers either as a service on demand, through a subscription, in a pay-as-you-go model, or at no charge when there is opportunity to generate revenue from streams other than the user, such as from advertisement or user list sales: SaaS Features: Web access to commercial software Software is managed from a central location Software delivered in a one to many model Users not required to handle software upgrades and patches Application Programming Interfaces (APIs) allow for integration between different pieces of software SaaS scope of application: Applications where there is significant interaction between the organization and the outside world. Google, Twitter, Facebook and Flickr are all examples of SaaS, with users able to access the services via any internet enabled device. Software that is only to be used for a short term need. An example would be collaboration software for a specific project Software where demand spikes significantly, for example tax or billing software used once a month Platform as a Service (PaaS) is a category of cloud computing services that provides a computing platform and a solution stack as a service. In this model, the consumer creates an application or service using tools and/or libraries from the provider. The consumer also controls software deployment and configuration settings. The provider provides the networks, servers, storage, and other services that are required to host the consumer's application. PaaS is analogous to SaaS except that, rather than being software delivered over the web, it is a platform for the creation of software, delivered over the web. Some examples of PaaS include Google App Engine, Microsoft Azure Services, and the Force.com platform. PaaS features: Services to develop, test, deploy, host and maintain applications in the same integrated development environment. All the varying services needed to fulfil the application development process Web based user interface creation tools help to create, modify, test and deploy different UI scenarios Multi-tenant architecture where multiple concurrent users utilize the same development application Built in scalability of deployed software including load balancing and failover Integration with web services and databases via common standards Support for development team collaboration some PaaS solutions include project planning and communication tools Tools to handle billing and subscription management INTREPID Public Deliverable 7 7

8 PaaS scope of application: PaaS is especially useful in any situation where multiple developers will be working on a development project or where other external parties need to interact with the development process Infrastructure as a Service (IaaS) is a provision model in which an organization outsources the equipment used to support operations, including storage, hardware, servers and networking components. The service provider owns the equipment and is responsible for housing, running and maintaining it. There are a plethora of IaaS providers out there from the largest Cloud players like Amazon Web Services and Rackspace. IaaS features: Resources are distributed as a service Allows for dynamic scaling Has a variable cost, utility pricing model Generally includes multiple users on a single piece of hardware IaaS scope of application: Where demand is very volatile any time there are significant spikes and troughs in terms of demand on the infrastructure For new organizations without the capital to invest in hardware Where the organization is growing rapidly and scaling hardware would be problematic Where there is pressure on the organization to limit capital expenditure and to move to operating expenditure For specific line of business, trial or temporary infrastructural needs 2.2 Cloud models and architecture mapping This section provides an analysis of the INTrEPID architecture components, their non-functional requirements and their classification with respect to Cloud models features. This analysis is meant to serve for a selection of a Cloud Infrastructure INTrEPID Requirements The following requirements are derived from deliverables D2.3 INTrEPID platform reference architecture and D2.4 Detailed specification of functional scenarios. They are explicitly focused on what the Cloud Infrastructure should integrate in terms of hosting capabilities, secure communications and management. Integration [4] Software component integration the infrastructure will allow installation of processing components developed for the INTrEPID platform, including all Middleware functional blocks, especially the database (Data Management block) and event processing engine. Security [5] As regards security, there is a requirement related to the need to provide users with a secure platform capable to protect the smart appliances in their home and the data stored in the cloud from unauthorized access. Privacy [6] A privacy requirement is identified for the data collected by the HAN Gateway and, more important, the data stored in the INTrEPID Middleware. In this case, data anonymization techniques should be devised for the cloud infrastructure. INTREPID Public Deliverable 8 8

9 Communications [7] Reliability in the communication protocols for data exchange Communication with the outside the cloud infrastructure is responsible for providing endpoints, or in other words physical interfaces, to communicate with external parties and for administration of the platform. Scalability of resources for applications execution [8] The hosting platform an environment where to deploy the INTrEPID components (Supervisory Control Strategies, Business Intelligence, Middleware, and the adapters, when required), which will provide the scalable resources for applications execution. Scalability of the platform by using appropriate tools, the INTrEPID platform must be able to grow seamlessly with increasing load, especially in horizontal direction, which means by distribution on multiple computers Cloud models and requirements Web access to commercial software Characteristics of SaaS Software is managed from a central location Requirements met Communications Security Software delivered in a one to many model -- Users not required to handle software upgrades and patches -- Application Programming Interfaces (APIs) allow for integration between different pieces of software Characteristics of PaaS Services to develop, test, deploy, host and maintain applications in the same integrated development environment. All the varying services needed to fulfil the application development process Web based user interface creation tools help to create, modify, test and deploy different UI scenarios Multi-tenant architecture where multiple concurrent users utilize the same development application Built in scalability of deployed software including load balancing and failover Integration with web services and databases via common standards Support for development team collaboration some PaaS solutions include project planning and communication tools -- Requirements met Communications Communications -- Tools to handle billing and subscription management -- Resources are distributed as a service Allows for dynamic scaling Characteristics of IaaS Requirements met Communications Scalability Scalability Has a variable cost, utility pricing model -- Generally includes multiple users on a single piece of hardware Scalability Security Integration Table 1: Cloud models features and INTrEPID components requirements INTREPID Public Deliverable 9 9

10 SaaS model features show that it usually employed for the distribution of commercial software. Although it can cope with some of INTrEPID architecture requirements the main purpose of the Cloud service is not to distribute software but to make a distributed system secure and interoperable. PaaS model is used when a common platform for services development is needed. In the case of INTrEPID, services and applications are developed with different programming languages in different operative systems (which depend on the provider) and perform different functionalities. This was envisioned for the architecture to be as open as possible for developers so they can make use the tools that they think are more appropriate for them to perform their tasks. Although this model offers scalability and openness regarding standards, the whole services package is not suitable for meeting INTrEPID requirements. IaaS model seems the more appropriate one since it enables the distribution of resources as services just like INTrEPID service model. It also makes feasible the scalability of resources regarding computing processing for the availability of INTrEPID services and permits the use of multiple users in a single hardware which is administrated by the service provider and therefore meets security requirements. As for communications, having services being connected with a central point, it enables secure connections based on traditional TCP/IP or HTTP which is a requirement for INTrEPID components INTrEPID Cloud Model selection Motivated by the previous matching between platform requirements and Cloud models characteristics, the INTrEPID architecture will employ an IaaS model for the hosting of its services. Adapters and applications could be hosted as well (at least for those developers that have chosen the possibility to host them in a central server). Figure 4: INTrEPID Cloud Model Cloud Infrastructure technologies selection IaaS is a way to distribute computing infrastructure as a service, usually via a virtualization platform. Rather than purchasing servers, space in data centre or network equipment, customers buy all these resources to a third party service provider. Therefore, providers make use of Virtual Machines technologies for this purpose. In INTrEPID, the selection of a proper Cloud Infrastructure based on VM technologies is going to be down to what the integration and tests results will show. Therefore, this section is subject to WP6 results where several possibilities of VM technologies will be tested. Having done the selection of the Cloud platform for the INTrEPID architecture, the following chapters make an analysis for INTrEPID secure communications and virtual platform management in order to come up with a proposition for securing the whole infrastructure. INTREPID Public Deliverable 10 10

11 3. Framework for Secure communications within the INTrEPID network 3.1 HAN-to-Middleware communications Middleware has direct communications with adapters and applications (i.e. BI, SCS, user-application) only. Herewith, some options are presented as alternatives for secure communication based on virtual private networking. The following figure provides a view of the INTrEPID architecture inside an IaaS model. A Virtual Public Cloud (VPC) has been defined and communications between External Parties, Supervisory Control Strategies (SCS) and Energy Brokerage & Business Intelligence (EBp&BI) modules are made by HTTP according to the information provided on the deliverable D2.3 INTrEPID platform reference architecture. Therefore, it is also necessary to include security in this channel by making use of the secure version of this protocol over certificates (HTTPS). Figure 5: INTrEPID Components in the Cloud Infrastructure (VPC) According to deliverable D3.1 Home Gateway and Network configuration tools, communications with Adapters are made over TCP/IP and consequently, IPSec and SSL options are considered for being widely adopted technologies. Yet, from a tools perspective for enhancing TCP/IP security, the following components can be used: Packet Rules Packet rules behave as a firewall by combining IP filtering and NAT (Network Address Translation) and accordingly protecting the network by filtering packets following predefined rules. However, its implementation is out of the scope of application for INTrEPID due to the fact that network access points would have to be configured individually meaning that time and effort will be required for its configuration and, on the other hand, some organizations do not allow access to such network components. INTREPID Public Deliverable 11 11

12 HTTP Proxy Server Proxy servers receive HTTP requests from Web browsers and resend them to Web servers. The wide success of SSL has provided benefits to the HTTP proxy protocol. It allows clients to open a secure tunnel to the proxy. Then, certificates will be exchanged between client and server, and the proxy would be aware of the source and target addresses as well as user authentication information. Nevertheless, this solution hasn t been adopted since HTTP proxy servers process it connections through a specific port (80, 8080) and VM resources may not be accessed Secure Sockets Layer (SSL) The SSL protocol establishes secure connections between clients and server applications which provide authentication of one or both endpoints of the communication session. SSL also provides privacy and integrity of the data that client and server applications exchange. Virtual Private Networking (VPN) A VPN creates a virtual tunnel connecting the two endpoints. The information running within the VPN tunnel is encrypted so that other users of the public Internet cannot easily view intercepted communications. VPN s usually rely on IPSec (Internet Protocol Security) to tunnel between the two endpoints. VPN and SSL are not from the same level. A VPN implementation requires some cryptography at some point. Some VPN implementations actually use SSL, resulting in a layered system: the VPN transfers IP packets (of the virtual network) by serializing them on a SSL connection, which itself uses TCP as a transport medium, which is built over IP packets (on the physical unprotected network). SSL passes easily through NAT allowing the access to the VM resources. IPsec is another technology which is more deeply integrated in the packets, which suppresses some of those layers, and is thus a bit more efficient (less bandwidth overhead). On the other hand, IPsec must be managed quite deep within the operating system network code, while a SSL-based VPN only needs some way to hijack incoming and outgoing traffic; the rest can be down in user-level software. Due to each organization networking settings (Figure 11), it is not possible to employ IPSec based communications and therefore SSL based VPN solutions will be employed in order to avoid networking configurations and at the same time securing communications SSL/TLS VPNs solutions Secure Socket Layer - Transport Layer Security (SSL-TLS) technology is an important component of a comprehensive enterprise security strategy. SSL-TLS is a widely used protocol for secure network communications. There are a number of diverse markets that have products using implementations of SSL- TLS. Originally designed as a way to secure browsing of the Web, SSL-TLS implementations are now used in Business Transaction Servers, Application Servers, as well as other core business functions. TLS can also be used to tunnel an entire network stack to create a VPN, as is the case with OpenVPN and OpenConnect Including VPN-based solution into INTREPID OpenVPN is one of the most popular implementations of VPN technology. It is an open source software solution for creating Virtual Private Network (VPN). OpenVPN uses a custom security protocol to achieve secure connectivity using SSL/TLS for key exchange. It is capable of traversing network address translators (NATs) and firewalls. OpenVPN allows peers to authenticate each other using a pre-shared secret key, certificates, or username/password. When used in a multiclient-server configuration, it allows the server to release an authentication certificate for every client, using signature and Certificate authority. It uses the OpenSSL encryption library extensively, as well as the SSLv3/TLSv1 protocol, and contains many security and control features. INTREPID Public Deliverable 12 12

13 Advantages: Strong Security: With security features such as peer authentication using pre-shared keys, certificates and other usual forms of authentication, strong encryption standards using the OpenSSL Library, and HMAC packet authentication, OpenVPN is ideal for people who want to keep their networks safe and secure from prying eyes and hackers. Also, OpenVPN runs in the user space and can run without root privileges, making it quite safe and robust to use. High Reliability: When OpenVPN goes down, the network is brought to a pause to allow for repair or reconfiguration, thereby ensuring that no data loss or corruption or miscommunication happens. This also acts as an additional layer of security. Great Worldwide Community Support: Being an open source solution, OpenVPN enjoys the support and community focus that comes with software licensed under the GNU GPL. Being open source, OpenVPN is free for modification, as the source code is available. Disadvantages: Proxy Problems: While most proxy servers around the world support OpenVPN, there are some that do not, and if the user happens to be unfortunate enough to be attempting to connect through one of these, problems are inevitable. This too can be resolved, however, by simply switching to a supportive proxy solution. High Overheads: Due to many overheads involved in running OpenVPN, the latencies can be high depending on the situation, location of access and the distance being covered. The latency also has another reason all the encryption and decryption processes that occur on OpenVPN occur in the user space. However, this issue can be resolved by using fairly capable machines on either ends of the VPN. Complex: Setting up the OpenVPN network can be a daunting task for beginners. With so many options and configurable aspects, OpenVPN can be difficult to work with and be disastrous if it gets into the hands of the uninitiated. The following table sets out a comprehensive comparison between IPsec and OpenVPN that has been considered to select the most suitable VPN-solution for this project: IPsec VPN (industry) standard HW platforms (devices, equipment) Well-known and tested technology Several graphic interfaces available. Complex modification of stack IP Requires critical kernel modifications Requires administrator permissions Different implementations may cause incompatibilities. Complex technology and configuration Exponential learning curve Needs several firewall ports and protocols Issues with dynamic addresses on both sides. Security issues Not compatible with IPsec PC only. Emerging technology No GUI Simple technology OpenVPN Standardized network interfaces and packages User-space and it can bechroot-ed Standardized encryption technologies. SSL/TLS as encryption standard. Easiness, well-structured, modular technology and simple configuration. Easy to use and implement Uses one firewall port Works with servers such as DynDNS or No-IP. No problems with NAT Compatible with firewall and proxies Table 2: IPsec vs OpenVPN INTREPID Public Deliverable 13 13

14 Taking into account the information explained above, the pros and cons of each specific protocol and the INTrEPID requirements [3][4], OpenVPN will be employed considering its countless benefits: speed, reliability, stability and safeness, even when connection problems might appear, keeping system privacy and security intact. Additionally, it s easy to use and fully compatible with a variety of operating systems such as, Mac OS, Windows, Linux and some IP phones. 3.2 Security for ZigBee connections This section outlines security aspects in the physical layer (Home Area Network). Due to the extensive use of IEEE , there is the necessity to make sure these communications are encrypted for ensuring data is confidential. IEEE sets the encryption algorithm to use when cyphering the data to transmit. However, the standard does not specify how the keys have to be managed or what kind of authentication policies have to be applied. These issues are treated in the upper layers which are managed by technologies such as ZigBee. [8] Encryption algorithm used is AES (Advanced Encryption Standard) with a 128-bit key used not only to encrypt the information but to validate the data which is sent. Figure 6: encryption algorithm This concept is known as Data Integrity and it is achieved using a Message Authentication Code (MAC) which is appended to the message. This code ensures integrity of the MAC header and payload data attached. It is created encrypting parts of the IEEE MAC frame using the Key of the network, so if we receive a message from a non-trusted node we will see that the MAC generated for the sent message does not correspond to the one what would be generated using the message with the current secret Key, so we can discard this message. The MAC can have different sizes: 32, 64, 128 bits, however it is always created using the 128b AES algorithm. Its size is just the bits length which is attached to each frame. The larger the more secure (although less payload the message can take). Data Security is performed encrypting the data payload field with the 128b Key. There are three fields in the IEEE MAC frame which are related to security issues: Frame Control (in the MAC Header) Auxiliary Security Control (in the MAC Header): is only enabled if the Security Enabled subfield of the Frame Control is turned on and it has 3 fields: 1) Security Control (1B): It s where Security Policy is set. Using the 2 first bits, we choose what we are going to encrypt and how long the Key is going to be: INTREPID Public Deliverable 14 14

15 Table 3: Security control bits 0x00 value means no encryption. From the 0x01 to 0x03 the data is authenticated using the encrypted MAC. The value 0x04 encrypts the payload ensuring Data Confidentiality. The 0x05 to 0x07 range ensures both data confidentiality and authenticity. 2) Frame Counter (4B) is a counter given by the source of the current frame in order to protect the message from replaying protection. Each message has a unique sequence ID represented by this field. 3) Key Identifier (0-9B) specifies the information needed to know what key we are using with the node we are communicating with. Data Payload (in the MAC Payload field) field may have three different configurations: 1) AES-CTR: data is encrypted using the defined 128-bit key along with the AES algorithm. The Frame Counter sets the unique message ID,and the Key Counter (Key Control subfield) is used by the application layer if the Frame Counter max value is reached. 2) AES-CBC-MAC: The Message Authenticity Code (MAC) is attached to the end of the data payload. Its length depends on the level of security specified in the Security Policy field. The MAC is created encrypting information from the MAC header and the data payload. 3) AES-CCM: It is the mixture of the previously defined methods. Figure 7: Security in the MAC INTREPID Public Deliverable 15 15

16 Each node in the network has to control its own Access Control List (ACL) with the following fields: Address: of the destination node Security Suite: the security police being used (AEC-CTR, AES-CCM-64, AES-CCM ) Key: 128-bit key used in the AES algorithm Last Initial Vector (IV) and Replay Counter: both are the same field. The Last IV is used by the source and the Replay Counter by the destination as a message ID in order to avoid reply attacks. When the node wants to send a message to another node or receives a packet, it looks at the ACL to see if it is a trusted brother. If it is, the node uses de data inside the specific row apply the security measures; if it s not in the list, its message will be rejected and an authentication process will start. In addition to the above-mentioned security issues, ZigBee implements two extra security layers on top of the one: the Network and Application security layers. All the security policies rely on the AES 128b encryption algorithm so the hardware architecture previously deployed for the link level (MAC layer) is still valid. There are three kinds of Keys: master, link and network keys. Master Keys: They are pre-installed in each node. Their function is to keep confidential the Link Keys exchange between two nodes in the Key Establishment Procedure (SKKE). Link Keys: They are unique between each pair of nodes. These keys are managed by the Application level. They are used to encrypt all the information between each two devices, for this reason more memory resources are needed in each device. Network key: It is a unique 128b key shared among all the devices in the network. It is generated by the Trust Center and regenerated at different intervals. Each node has to get the Network Key in order to join the network. Once the trust center decides to change the Network Key, the new one is spread through the network using the old Network Key. Once this new key is updated in a device, its Frame Counter is initialized to zero. This Trust Center is normally the Coordinator; however, it can be a dedicated device. It has to authenticate and validate each device which attempts to join the network. Every data request in ZigBee is sent (and received) on an Application Profile which consists of 16-bit numbers and range from 0x0000 to 0x7fff for public profiles and 0xbf00 to 0xffff for manufacturer-specific profiles. Table 4: ZigBee Public Profile IDs The ZigBee Alliance publishes application profiles like ZigBee Home Automation and ZigBee Smart Energy to allow different device classes to interoperate. In the Smart Grid environments, the Smart Energy Profile is the most used. Smart Energy Profile Security The Smart Energy market requires two types of ZigBee networks for metering and energy management. These include neighbourhood area networks for meters, using ZigBee for sub-metering within a home or apartment, and using ZigBee to communicate to devices within the home. Due to the type of data and control within the Smart Energy network, application security is a key requirement. To be part of a Smart Energy network, a device shall associate using one of the association methods described below and require the use of the Key Establishment Cluster for installation and updating of link keys. All devices shall have the ability to retain their joining and security settings through power outages. INTREPID Public Deliverable 16 16

17 Preinstalled Trust Center Link Keys When using preinstalled trust center link keys, the following steps are used: 1) Trust Center link keys are installed in each device prior to joining the utility network. 2) The Trust Center link key for a device that is to be joined is provided to the local trust center through an out of band. 3) Permit joining is turned on in the network. 4) The device joins the network and is sent the network key encrypted with the key-transport key derived for the preinstalled trust center link key. The Trust Center must update the preconfigured trust center link key in the joining device using the Key Establishment Cluster after completion of the joining procedure. 5) The Trust Center of the network has the option of later updating the trust center link keys with devices in the network as desired by the application using the Key Establishment Cluster. Updating security keys should be an infrequent operation. 6) If devices leave the network, the trust center shall update remove the network Trust Center link key assigned to that device. Re-Joining a Secured Network Re-joining Node Operation: When a device is re-joining a secured network, the following steps are used: 1) Permit joining is not required to be on in the network. 2) The device shall attempt a re-join with network security. The network key and sequence number used will be the ones previously obtained from the trust center. 3) If the secured re-join is successful, nothing more is required from the device. 4) If the secured re-join fails, the device shall attempt a re-join without network security. The rejoining device is assumed to have previously joined the network and obtained a link key using the key establishment cluster procedures. If the device does not have a link key obtained via the key establishment cluster, it cannot re-join the network. 5) If the unsecured re-join fails the device may attempt it again. If the device is told to leave the network it may employ the Joining using the Key Establishment Cluster procedure. Trust Center Operation: When the Trust Center receives notification that a device has re-joined the network, the following steps are used: 1) If the device performed a secured re-join the Trust Center is not required to take any action. 2) If the device performed an unsecured re-join the Trust Center shall determine if the device is authorized to be on the network. If the Trust Center has a link key with the device that was established using the key establishment cluster then it shall be allowed back on the network. The Trust Center should send out an updated copy of the network key encrypted with the corresponding link key. 3) If the Trust Center determines that the device is not authorized to be on the network, it shall send an APS remove device command to the parent of the re-joining device, with the target address of the re-joining device s IEEE address. 4) The parent will then remove that device from its child table. Devices Leaving the Network Upon receipt of an APS update device command indicating a device has left the network, the Trust Center shall remove the Trust Center link key assigned to that device. INTREPID Public Deliverable 17 17

18 Updating the Network Key Periodically the Trust Center must update the network key so that devices that are no longer on the network will not be able to perform a secure re-join. Those devices must then perform an unsecured re-join, which allows the Trust Center to authorize them. When the Trust Center wishes to update the network key it will broadcast the network key to all devices in the network. Once the network has started using the new key, any device that has missed the key update message will not be able to communicate on the network. Those devices that missed the key must follow the Re-joining a Secured Network procedure. Updating the Link Key Periodically the Trust Center may update the link key associated with a particular device. Link keys are used for sending application messages and stack commands. When the Trust Center deems that a particular link key should no longer be used, it shall mark the key as stale which cannot be used to send data. Devices that receive a message using a stale key should discard the message and shall not send an APS acknowledgement to the sender. Devices shall accept and process APS commands that are encrypted with a stale key. When the Trust Center receives a message encrypted with a stale link key, it shall initiate the key establishment procedure to negotiate a new link key. The following picture shows an example of a successful network startup and certificate exchange: Figure 8: Join and registration INTREPID Public Deliverable 18 18

19 The Security Policies relating to Key Establishment that are recommended for Smart Energy networks are the following: Joining: If the device doesn't need to perform discovery queries or other non-secure operations after joining to an SE network and receives the Network Key, it should immediately initiate Key Establishment with the Trust Center to obtain a new Trust Center Link Key. If Key Establishment fails, the device should leave the network. Upon successful negotiation of a new Trust Center Link Key the device may communicate using clusters that require APS security. Trust Center: The Trust Center should keep track of whether a particular device has negotiated a CBKE Trust Center Link Key, or whether only a preconfigured Trust Center Link Key exists. The Trust Center should not use the preconfigured link key to send encrypted APS Data messages to the device. The Trust Center should discard any APS encrypted APS Data messages that use the preconfigured link key, and it should not send APS Acks for those messages. The Trust Center shall accept and send APS Data messages that do not use APS Encryption to a device that has not negotiated a CBKE Trust Center Link key provided that the security usage for that cluster only allows using Network layer security (encrypted with the Network Key). During Joining: Normal operation of a device in a Smart Energy network requires use of a preconfigured link key, establish by using the Installation Code to join a ZigBee network. After joining the network, a device is required to initiate key establishment using ECMQV key agreement with the ESP (Trust Center) to obtain a new link key authorized for use in application messages. Although the node has a link key, that node has not been authenticated and thus the key's use is not authorized for application messages. Once a node has authenticated by the ESP and obtained an authorized link key using key establishment, it may communicate with the ESP using APS layer security. The ESP should accept valid APS encrypted message using that new link key. After Joining: After a node has joined, been authenticated using key establishment, and obtained an authorized link key, it may need to communicate with other nodes on the network using APS layer encryption. Rather than use key establishment, if nodes have obtained link keys with the ESP using key establishment then they will use the ESP to request a link key with each other. The Trust Center will respond to each node individually, sending a randomly generated link key. Each message will be encrypted using the individual nodes' link keys. Both nodes are required to request a link key with the other node making sure that both nodes are online and ready to receive a key and that a node is not forced to accept a key it cannot support or did not want. The source node would start this process by sending a bind request command with APS ack to the key establishment cluster of the destination device. If a bind confirm is received with a status of success, the initiating device will perform a request key of the Trust Center. The Trust Center will then send a link key to each device using the key transport. If the bind confirm is received with a status other than success, the request key should not be sent to the Trust Center. ESP authenticates all devices with key establishment after joining, and limits the use of key establishment in the network. 3.3 ZigBee Trust Center used in INTrEPID Secure communication at HAN level had to be supported and implemented by the devices using ZigBee protocol and ZigBee profiles for the INTrEPID system. ZigBee technology has been adopted for the connections of a number of devices for the INTrEPID Pilot, based on the ZigBee Home Automation Profile 1.2 (see D3.1 [9] and D3.6 [10]). INTREPID Public Deliverable 19 19

20 Security policies for ZigBee profiles The security policies defined for ZigBee Profiles can be classifies in two groups, depending on the security requirements of the applications: Home Automation based security policy and Smart Energy based. Here it follows a description of available policies. Home automation security policies: this policy is used for devices owned directly by a user, and it is equivalent to the WPS security used in WiFi technology. There are two options defined in HA 1.2: 1. Default HA security: In fact in this case, a push-button commissioning procedure is invoked on the devices that need to be associated to an existing ZigBee network supporting such policy, The joining procedure is also invoked and on the network manager of the HAN (typically assumed the Trust Center of the network), which send a permit join commands to all the ZigBee routers in the network in order to let the network to receive other joining devices in. The joining devices try to operate a scan of the available networks, select the network that are permitting joining and try to associate to them using IEEE joining procedure. A network key is then delivered to the joining node within a Transport Key command encrypted with the network key of the HAN. In the last communication hop to the joining device (from the parent which is associating the device) the Transport Key command is sent encrypted at the APS level with a Default Trust Center link key ( ZigBeeAlliance09 ).This is done in the last hop only (so it is spatially limited) and considering the limited time-window of the network opened leads to potentially limited risk, however such as WPS in WiFi that does not prevent from local spoofing attacks. This procedure is suitable for home automation devices installed by users where no billing is performed on the HAN communication. It has been used in INTrEPID ZigBee HANs in the pilot since it is a trade-off among complexity of installation procedures, security and application requirements. 2. Installation codes: this procedure allows compatibility between Home Automation and Smart Energy certified devices; it follows the same rules as the above procedure with the exception of the transfer of the network key: in this procedure it is not used the Default Trust Center link key ( ZigBeeAlliance09 ) but a specific key per device which is derived from an installation code (as described in the SE 1.x specification). This approach add an extra security since there is no vulnerability in spoofing but it adds extra complexity (so extra costs for the devices) since a unique code (install code) has to be installed in every devices and in communicated (out of HAN band) to the Trust Center since the application link key has to be shared among the joining device and the Trust Center. The TI gateways in the INTrEPID project support this feature (supported in GAL software component) and an access list with the install codes can be configured. Smart Energy security policy: in this case, in addition to the network encryption, the devices also use APS encryption with applications link keys for all the application commands to the Trust Center (typically the energy box owned by a utility). This case the association procedure is the same as the installation code policy, with the exception that, after the joining with the installation code, the APS link keys must be updated using key establishment procedure (in SE 1.1 elliptic keys cryptography). This policy requires a Public Key Infrastructure (PKI) but enables a very high security in the system Trust Center in INTrEPID ZigBee Gateway The HAN gateway implemented for the INTrEPID system for ZigBee technology, both the Home automation security policies have been implemented. This has been decided based on the fact that the devices within the HAN could be extended with a number of sensors with very limited capabilities (so not able to manage smart energy security policy), but at the same time to be able to support devices requiring additional security and then installation code. It also worth noticing that if a more restrictive policy is required on a HAN already active it might restrict the functionality of the HAN to only the device with the extra security features. INTREPID Public Deliverable 20 20

21 4. Cloud Security and Assets Management Security management and services availability are two main aspects of the INTrEPID Cloud infrastructure. Herewith, the concept over which Virtual Machines are managed in order to ensure security and scalability of resources is outlined in detail. Configurations of Virtual Machines will be the implementation of these concepts and therefore parameters for settings will be provided once specific technologies are chosen during WP6 tests. 4.1 IaaS- Availability Unforeseen events (natural disasters, outages, etc.) can happen in data centres operated in the cloud and for this reason it is needed to plan for uninterrupted availability of the system. Since IaaS involves Virtual Machines (VM), it is required that the service provider takes into consideration redundancy from the hardware perspective Distributed Data Center The concept of redundancy, as explained before, is the most important tool that will be used to cope with the requirement of uninterrupted availability of the system. However, redundancy is a wide concept and different characteristics of the system will be considered under this umbrella: Geographical dispersion through the use of distributed data centre, Multiple instances through redundant VMs kept in sync, Task-switching through traffic re-routing (DNS, load balancing, process switching) and state transfer at application level, Backup recovery policy. The relationship among those features is shown in Figure 9. DNS, load balancing, process switching Figure 9: Redundancy concept. As an example, Amazon data centres are in several physical locations categorized by regions and Availability Zones. Regions are large and widely dispersed geographic locations; Availability Zones are distinct locations within a region that are engineered to be isolated from failures in other Availability Zones. When one Availability Zone becomes unhealthy or unavailable, new instances are launched in an unaffected INTREPID Public Deliverable 21 21

22 Availability Zone, and when the unhealthy Availability Zone returns to a healthy state, the application instances are redistributed again. In order to address and implement the above-mentioned features obtaining a highly available distributed data centre, a set of technology components are needed. The most important basic technologies are: Wide Area File Services (WAFS) technology to speed data shuffling between the user location and data centre at LAN similar speeds, Intelligent routing to the closest data centre location from a user and network point of view, Task-switching technology to manage the state transfer from one geographical location to another of the running application, Cashing techniques to assure that all the system components can operate at the fastest speed possible. It is possible to implement only a subset of the described features and technologies when a reduced degree of availability is sufficient for the target system and application. In the following sections the features actually implemented in the INTrEPID system will be identified Elimination of single point failure In order to guarantee availability of a service occurs to find out every SPoF (Single Point of Failure) in the system that supports the service Typically every instance of a component of the system, involved in making the service work, could be a SPoF and the architects of the system should design it accordingly. Elimination of a SPoF could be achieved following different techniques often integrated Load balancer Load balancing is a typical technique for distributing load among more than one instances of a system component but it can help in eliminating a SPoF. Simply adding one more instance in the pool of component instances managed by the load balancer brings a higher grade of availability and eliminates a SPoF. Clouds (public and private) offer balancing services or list ready to use balancing resources (VMs) in their catalogues; obviously the load balancer can t be a SPoF itself and should be deployed and configured accordingly if not delivered as-a-service by the cloud Storage services Public and private clouds usually offer storage services that can be seen as the typical HDU attached to a VM or as a NAS/SAN or as-a-service (web and API based) like Amazon s S3; back-end of these storage services may have different approaches in order to guarantee the access to data (e.g. datacenter redundancy and geographical synchronization) that is the main concern of the providers. Storage services themselves benefit from balancing, redundancy and availability concepts exert Redundancy of components Public and private clouds aim to be reliable and redundancy is a concept that applies to this target. It consists in duplicating critical components of the system and goes hand-to-hand with the concept of failover; failover is the action to switch to a redundant instance reacting to the failure of the previously active instance of the component and giving continuity of service (availability) Monitoring services Every cloud, public or private, provides more or less sophisticated services for monitoring the health and the performance of the deployed systems/services; usually it s included in cloud management services. Monitoring is one of the main issues to be addressed when going in production with a system/service. Mainly it consists of using dedicated software able to collect internal data, of deployed HW and SW, and display them with GUI specifically designed for capturing the attention of operation personnel. INTREPID Public Deliverable 22 22

23 Asset Management The asset management deals with the maintenance (inventory) and the update of the hardware and software components of a cloud Assets inventory The assets management inventory involves gathering detailed hardware and software inventory information which is then used to make decisions in processes like purchasing and resources redistribution based on meaningful and measurable parameters. A public cloud provider usually provides the user with assets management tools providing information about the hardware (physical components of computers and computer networks) and software (OS, middleware, runtimes, data, and applications) assets. Moreover, those tools are associated with another set of tools enabling the customer to update the used assets based on specific user needs or dynamic conditions, as explained in the next section. Cloud asset management tools include specific characteristics, such as the ability to manage multiple platforms from a single point of reference and intelligent analytics to automate processes like application lifecycle management. Managing other types of cloud infrastructure (PaaS, SaaS) requires different tools. In case of PaaS and SaaS infrastructure management tools tend to be more service driven, as opposed to resource driven Assets updates Assets updates management tools can be grouped in three basic categories: Self-management: customers purchase and updates cloud assets through a web form or console interface, Advance management: customers contract in advance the needed amount of resources, with the possibility to update them later, Dynamic management: the cloud provider allocates and reallocates resources on the basis of dynamic customer needs. In case of dynamic management, the scaling ability to increase or decrease the resources capacity can be obtained by either changing the number of servers (horizontal scaling) or changing the size of the servers (vertical scaling). Depending on the infrastructure, vertical scaling might involve changes in server configurations while horizontal scaling simply increases or decrease the number of servers according to the application's demands. The horizontal scaling can automatically increase the number of servers when the user demand goes up and decrease it when demand goes down to minimize costs. It is well suited for applications that experience hourly, daily, or weekly variability in usage avoiding predicting huge traffic spikes accurately and planning for provisioning resources in advance. This dynamic management tool can be configured to scale resources dynamically based on conditions specified by the customer (e.g. percentage of CPU utilization) or predictably according to predefined schedules (e.g. every specific day in the week and/or specific hours of the day). In the INTrEPID system the asset management is used to cope with a limited number of users and a limited need to dynamically scale resources Back-up recovery policy Public and private clouds provide tools for saving and recovering the state of the VMs generating snapshots that could be used to restore a previous stable situation. Usually snapshots could be saved manually, scheduled or become part of a larger disaster recovery plan often managed by a specific sw. Sometimes clouds offer backup capabilities inside their basic services but often are a task of the operation guys that run the system/service, setup a disaster recovery process. INTREPID Public Deliverable 23 23

24 4.2 Access control policies Cloud computing allows scaling resources up and down as needed. The pay-as-you-go model of computing has made it very popular among businesses. However, one of the biggest hurdles in the widespread adoption of cloud computing is security. The cloud is vulnerable to data leaks, threats, and malicious attacks. Due to introduction of cloud computing, Database Management Systems (DBMS) has emerged into a new type of a service. A cloud database involves a huge variety of designing, developing of hardware and software. Therefore, it is important for enterprises to have strong access control policies in order to ensure the privacy and confidentiality of data in the cloud. Current access control techniques, like firewalls and VLAN, are not exactly well-suited to meet the challenges of cloud computing environment. Currently, in cloud computing platform, thousands of physical and virtual machines are added and removed every day, and the current access control mechanisms are not enough to handle this dynamic environment. In addition, as more cloud services are added, the process of managing identities is getting more complex Identity management (Identity and Access Management) DBMS (database management system) is a collection of programs which enables you to store, modify, and to extract information from a database. Clouds can be used along with DBMS for handling large volume of data improving reliability, elasticity, availability, scalability and all these capabilities are provided at low cost with enhanced performance compared to the dedicated infrastructure. Cloud services based on DBMS are gaining acceptance from vendors desiring low cost of developmental platform. The main DBMS characteristics are: - Self-describing nature of a DBMS: Database System contains the database itself as well as the descriptions of data structure and constraints (meta-data). - Support multiple views of data - Data sharing - Data independence - DBMS provides backup as well as recovery facilities - Restricting unauthorized access by means of a subsystem that creates and control the user accounts Cloud's DBMS are hard to monitor since they often span across multiple hardware servers and handle big amount of information. Security becomes a serious issue with cloud DBMS because most of the services are outsourced to the third party, which makes it difficult to maintain the data security. The best solution for dealing with security issues (identity management, computing resources, application security, privacy and legal issues) is to employ continuous database auditing to deal with security. It involves setting up a system that will continuously record, analyse and report on all activities regarding database access, specifically suspicious database access. All recorded information regarding these activities is logged and stored in a remote and secure location with alerts being sent out to cloud agent/management in the critical situations. This will provide the person in charge of security with the relevant logs information necessary to determine who is responsible, where the suspicious person is located as well as the specifics of their machine / hardware and diagnose it. On the DBMS in Cloud Architecture depicted below, the first layer contains the storage layer, followed by databases layer and the upper layer is application layer. It provides efficient data access with a better distribution of values for the data. It stores frequently used SQL statements in memory in terms of performance and avoids the need for time-consuming recompilation at run-time. At the storage layer data is encrypted when stored in the database or backed up with no need of programming to encrypt and decrypt the database.the application layer produces a detailed report on each step used for data access and allows to accurately implement the performance enhancements. INTREPID Public Deliverable 24 24

25 Figure 10: DBMS in Cloud Architecture Components for communication over insecure network Considering a scenario where a VPN network will not be available, it should also be safe to use HTTPS protocol only or rely on ActiveMQ security for all communications. In spite this scenario is not the one envisioned in INTrEPID project, the following section presents ActiveMQ security mechanisms Publish/subscribe model for message broker ActiveMQ supports different modality to reach the goals of availability together with load balancing and scalability: Queue consumer clusters, Network of brokers, Broker clusters. Queue consumer clusters ActiveMQ supports reliable high performance load balancing of messages on a queue (and a topic using virtual topics) across consumers. If a consumer dies, any unacknowledged messages are redelivered to other consumers on the queue. If one consumer is faster than the others it gets more messages etc. If any consumer slows down, other consumers pick up the slack. So you can have a reliable load balanced cluster of consumers on a queue processing messages. Networks of brokers INTREPID Public Deliverable 25 25

26 Cloud Virtual Private Cloud D3.4: COMMUNICATION ARCHITECTURE FOR DEVICE INTEROPERABILITY Having many clients and many brokers, there is a chance that one broker has producers but no consumers so that messages pile up without being processed. To avoid this ActiveMQ supports a Networks of Brokers which provides store and forward to move messages from brokers with producers to brokers with consumers which allows supporting distributed queues and topics across a network of brokers. This allows a client to connect to any broker - and fail over to another broker if there is a failure - providing from the clients perspective a cluster of brokers. Networks of brokers also allow us to scale up to massive number of clients in a network as we can run as many brokers as we need. ActiveMQ supports auto-discovery of brokers using static discovery or dynamic discovery so clients can automatically detect and connect to a broker out of a logical group of brokers as well for brokers to discover and connect to other brokers to form large networks. ActiveMQ supports two modality of network of brokers: Master Slave and Replicated Message Stores. The idea behind Master Slave is that messages are replicated to a slave broker so that in the event of catastrophic hardware failure of the master's machine, file system or data centre, there will be an immediate failover to the slave with no message loss. An alternative to Master-Slave is to have some way to replicate the message store; so for the disk files to be shared in some way. For example using a SAN or shared network drive the files of a broker can be shared so that if it fails another broker can take over straight away. Broker clusters (availability) ActiveMQ implements the failover:// protocol in the JMS client, so that, given a collection of JMS brokers, a JMS client will connect to one of them; then if the JMS broker goes down, the JMS client will auto-reconnect to another broker. The JMS clients need to know all the IP: port of the brokers in the network Availability Scalability and availability can be achieved deploying ActiveMQ on two or more servers and configuring them as a cluster for supporting shared messaging assets (queues and topics). Between clients and the cluster a load balancer (in fault-tolerant configuration) will provide the necessary distribution of messaging traffic and/or availability in case of fault of one of the brokers, as shown in Figure 11. JMS Clients Internet Public IP addresses Firewall* + NAT VPC IP addresses Firewall* Virtual IP address* HA Proxy HA Proxy Load Balancer ActiveMQ ActiveMQ Messaging Cluster** * Based on UCARP protocol ** Two or more brokers Figure 11: Messaging broker (ActiveMQ) scalability/availability. INTREPID Public Deliverable 26 26

27 Confidentiality Confidentiality is related to the definition of mechanisms to assure that sensitive information, i.e. information the users do not want to be accessed, is not disclosed to unauthorized persons or processes. In IaaS Cloud infrastructure the user is forced to use infrastructure provided by the service provider which knows where the users' data is located and has full access to them. Several approaches can be used to assure confidentiality. As an example, dedicated services can provide identity anonymization to prevent the system from revealing users' true identities. Another approach is based on data obfuscator and de-obfuscator. A data obfuscator can be installed on a virtual machine acting as an interface for the data coming from the user that encrypts data being stored in the physical storage of the cloud and obfuscates users' sensitive data being processed. A Data de-obfuscator remains in the user's personal computer all the time and provides the plain data to the user. In the INTrEPID system it has been addressed the privacy of the users involved in the pilot. Data as addresses, names, phone numbers, characteristics of the houses, characteristics of the microgeneration plants, etc. are sensitive information gathered from the users and treated as confidential with respect to the persons involved in the project for running and managing the system. With this aim, confidential information is stored in a separate VM in the cloud with the access privilege given to a person only, responsible for the management of the data. This simple approach appears to be in line with the European Union s directives on data protection avoiding more sophisticated approaches and the involved overheads in data transmission Middleware messaging security Messaging security is a main aspect regarding the intrusion of information from outsiders and keeping external applications and communications safe since the information flowing through the messaging infrastructure is legible by any certificate holder at lower levels. Therefore an extra mechanism at application layer should secure any communication between applications and INTrEPID messaging infrastructure. This feature of ActiveMQ should be taken into account in case no VPN or HTTPS is available since there is no reason to keep IP and application level secured as it would consume many resources in exchanging messages for securing both layers ActiveMQsecurity ActiveMQ 4.x and greater provides pluggable security through various different providers. The most common providers are: JAAS for authentication A default authorization mechanism using a simple XML configuration file. Authentication Authentication and authorization control of messaging assets The default JAAS plugin relies on the standard JAAS mechanism for authentication. JAAS is configured using a "config file" and set the java.security.auth.login.config system property to point to it. If no system property is specified then by default the ActiveMQ JAAS plugin will look for login.config on the classpath and use that. Authorization In ActiveMQ it is used a number of operations which can be associated with user roles and either individual queues or topics or you can use wildcards to attach to hierarchies of topics and queues. INTREPID Public Deliverable 27 27

28 Operation read write admin Description You can browse and consume from the destination You can send messages to the destination You can lazily create the destination if it does not yet exist. This allows you fine grained control over which new destinations can be dynamically created in what part of the queue/topic hierarchy Table 5: ActiveMQ Operations Keys, certificates and CA certificates ActiveMQ needs the following credentials: A copy of the site s CA certificate A certificate signed by the site s CA A private key to match its certificate INTREPID Public Deliverable 28 28

29 5. INTREPID secure architecture proposal Due to continuous data exchange from Adapters and the need to access many resources in the INTrEPID Cloud infrastructure and the use of HTTP protocol by 3 rd party applications and INTrEPID services software modules communications will be secured at IP level for Adapters and at HTTP level for the rest of applications. IP level communications will make use of VPN technologies and HTTPS will secure the correspondent level. The VPN selected is OpenVPN as it is available for many operative systems and HTTPS will be implemented with generated certificates from a PKI with an external trusted Certificate Authority (root CA). 5.1 Network security configuration Security will be enabled from the adapters to the middleware over VPNs and server components such as Energy Brokerage, Business Logic and Supervisory Control Strategy are holding private certificates and clients/components connected to INTrEPID platform are using public keys for data encryption. Figure 12: Network security configuration 5.2 Establishing a connection OpenVPN (for each workstation hosting an adapter): Download and install the OpenVPN client at o Edit configuration file Copy assigned certificate in config file folder 5.3 Establishing a connection over HTTPS An HTTPS connection is established after a handshake protocol (Figure 13) therefore each workstation hosting a 3 rd Party application or an INTrEPID software module apart from Adapters should have an assigned valid certificate installed provided by the CA (Certificate Authority). INTREPID Public Deliverable 29 29