Trust and Security Issues and Solutions (Public)

Ref. Ares(2015)2268119 - 01/06/2015

317959 Mobile Opportunistic Traffic Offloading

D4.3 – Trust and Security Issues and solutions (public)

Grant Agreement No. 317959 Project acronym MOTO Project title Mobile Opportunistic Traffic Offloading Advantage

Deliverable number D4.3 Deliverable name Trust and Security Issues and solutions Version V 1.0

Work package WP 4 – Offloading Protocols and Algorithms Lead beneficiary INNO Authors Oscar Lázaro (INNO), Patricia Ortiz (INNO), Iván Prada (INNO), Sebastien Tixeuil (UPMC), Marcelo Dias de Amorim (UPMC), Andrea Passarella (CNR), Giovanni Mainetto (CNR) Nature R – Report Dissemination level PU – Public Delivery date 31/05/2015 (M31)

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Executive Summary Mobile Opportunistic networking presents a challenging environment from a security perspective. This is because they are more vulnerable to attacks than other networks due to the lack of a central trusted node, dynamic topology of the network and limited resources (bandwidth, processing power and energy consumption). In this sense, MOTO is not a pure opportunistic network as the MOTO platform acts as a central trusted entity and manages the network. Within this document, the main security considerations, addressed in the MOTO environment, are presented. The document provides the results of the research that has been carried out in Task 4.3, where the security framework has being designed within the project. Indeed, the research performed reveals that the most important security and privacy challenges identified for MOTO are: A. End-to-end integrity and confidentiality B. Trust management and hop-to-hop security C. Identity and location privacy D. User authentication E. Mitigating malicious insiders The trade-off between performance/efficiency of the network and security is also covered. Moreover, the first simulation results of the security performance are provided. Finally, the security implementation approach and planning is presented.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Table of Contents

1 OVERVIEW ...... 6

1.1 INTRODUCTION ...... 6 1.2 SCOPE OF THIS DOCUMENT ...... 6 2 SECURITY CONTEXT IN MOTO ...... 8

2.1 CHALLENGES IN A HYBRID OPPORTUNISTIC NETWORK ...... 8 2.2 MOTO CONTEXT DESCRIPTION ...... 10 3 MAIN THREATS IN MOTO COMMUNICATIONS ...... 12 4 SECURITY GOALS IN MOTO ...... 18 5 THE PROPOSED SECURITY APPROACH ...... 20

5.1 AUTHENTICATION ...... 20 5.2 INTEGRITY AND CONFIDENTIALITY OF INFORMATION ...... 20 5.3 TRUSTWORTHINESS OF THE USERS ...... 21 5.4 USERS’ PRIVACY ...... 21 5.5 OVERALL SECURITY APPROACH ...... 21 5.6 GENERAL DESCRIPTION: END-TO-END SECURITY ...... 23 5.6.1 Multiple phase Cryptography ...... 23 5.7 ANONYMITY THROUGH THE USE OF PSEUDONYMOUS ...... 26 5.8 TRUST & REPUTATION MANAGEMENT ...... 32 5.8.1 Trust framework previous considerations ...... 32 5.8.2 Trust Feedback ...... 37 5.8.3 Environmental Factor ...... 38 5.8.4 Computation of the trust value of a user ...... 39 5.9 OVERALL SECURITY APPROACH ALGORITHM ...... 43 6 PRIVACY VS OFFLOADING PROTOCOLS: A CROSSROADS ...... 46 7 INITIAL SIMULATION RESULTS ON SECURITY ...... 47 8 SECURITY IMPLEMENTATION PLAN ...... 50

8.1 THEORETICAL SECURITY APPROACH ...... 50 8.2 MOTO DEMO SCENARIO ...... 51 8.3 SECURITY IMPLEMENTATION FOR THE 1ST MOTO DEMO SCENARIO ...... 52 8.4 PLANNING FOR THE SECURITY IMPLEMENTATION FOR THE 1ST MOTO DEMO SCENARIO ...... 53 9 CONCLUSIONS AND FUTURE WORK ...... 54 10 REFERENCES ...... 55

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

List of Figures

Figure 1. MOTO Security Channels ...... 9 Figure 2. Content encryption with Content provider session key and key distribution (confidentiality) ...... 11 Figure 3. MOTO offloading strategy ...... 12 Figure 4. MOTO Architecture (D.2.1.1)...... 13 Figure 5. Seed misbehavior in erroneous content injection ...... 14 Figure 6. Relay misbehavior in erroneous content injection ...... 15 Figure 7. Selfish seed in a no content retransmission threat ...... 15 Figure 8. Selfish relay in a no content retransmission threat...... 15 Figure 9. User identity disclosure threat in personal data disclosure ...... 16 Figure 10. User location and tracking threat in personal data disclosure...... 16 Figure 11. Monitoring of node activity threat in personal data disclosure ...... 17 Figure 12.Security Objective: End-to-end content protection ...... 18 Figure 13. Security Objective: Strong Authentication Mechanisms ...... 19 Figure 14. Security Objective: Availability in all cases ...... 19 Figure 15.Security Objective: Contribution to the quality of the service) ...... 20 Figure 16. Overall security approach proposed ...... 22 Figure 17. Overall proposed security approach ...... 23 Figure 18. Asymmetric cryptography approach to assure the origin and integrity of the content ...... 24 Figure 19. Confidentiality & Integrity encryption phases ...... 25 Figure 20. Overview of the multi-layer encryption proposed for MOTO communications ...... 26 Figure 21. Pseudonym delivery to user 1 and user 2 in time 1 ...... 27 Figure 22. Use of pseudonym in a content offloading opportunity ...... 28 Figure 23. Pseudonym delivery to same users 1 and 2 in Time 2 ...... 29 Figure 24. Reuse of pseudonyms within MOTO users through time ...... 30 Figure 25. Proposed pseudonymous security scheme ...... 31 Figure 26. Expected timely homogeneity of user’s received feedback ...... 34 Figure 27.The environmental factors expected homogeneity ...... 35 Figure 28. Expected historic homogeneity of user feedback ...... 36 Figure 29. Content Hash function received with user's feedback ...... 38 Figure 30. Recalculation of a user's Trust value ...... 41 Figure 31 Network stabilization time ...... 48 Figure 32 Comparison of the whole ad-hoc communication process with (blue) and without (orange) security in place ...... 49 Figure 33 MOTO 1st Demo scenario ...... 52

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

List of Tables

Table 1. Security requirements stated in D2.1 – Use case and requirements ...... 18 Table 2. Calculation of user trust triggered by feedback receipt ...... 43 Table 3. Proposed Security algorithm pseudo code ...... 45 Table 4 Simulation parameters (Montecarlo simulation) ...... 47 Table 5 Network stabilisation time...... 48 Table 6 Simulation parameters (Event driven simulation) ...... 48 Table 7 Number of nodes ...... 48

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

1 OVERVIEW 1.1 Introduction Mobile Opportunistic networking presents a challenging environment from a security perspective. This is because they are more vulnerable to attacks than other networks due to the lack of a central trusted node, dynamic topology of the network and limited resources (bandwidth, processing power and energy consumption). In this sense, MOTO is not a pure opportunistic network as the MOTO platform acts as a central trusted entity and manages the network. The objective of this document is to provide an understandable overview of the security solution for the communication scheme proposed in the MOTO project under Task 4.3. The main objective of this task, as outlined in the DoW, is to investigate security and trust issues both concerning the infrastructure and the opportunistic network. So that users could be encouraged to use the MOTO services, it is essential that the following security guarantees are achieved by the security model proposed:

 the content end-to-end integrity and confidentiality is assured  the real identity and location of the users should be preserved and never available other nodes that participate in the communication  the nodes that participate in MOTO are trustworthy, leading to the identification and withdrawal of any node that acts in a malicious or selfish way For achieving all the essential security needs addressed above, the MOTO project proposes the following security mechanisms, which will be further detailed in this document: (1) Multi phase cryptography (2) Pseudonyms anonymization (3) Trust & reputation management After deep analysis and thorough investigation, we can conclude that the combination of all these security approaches keeps under control the identified risks and provides the stated security objectives. This document also covers the trade-off between performance/efficiency of the network and security. Moreover, the first results of the simulations that have been carried are presented in order to demonstrate that the security mechanisms proposed do not introduce a high overload, thus not being a barrier to network efficiency. Finally, the plan that has been proposed in order to implement and develop the security mechanisms over the MOTO prototype is also included within this document.

1.2 Scope of this Document This document is organised as follows:  First of all, section 2 presents the MOTO context and environment where the security mechanisms will be proposed.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

 Section 3 presents the main threats that can be found in an environment such as the one presented in section 2.  Afterwards, section 4 presents the main security goals in MOTO.  Section 5 explains the proposed security approach to secure the MOTO communications.  Section 6 describes the problems of the forwarding protocols that should be taken into account.  Section 7 presents the first simulation results on security.  Section 8 presents the security implementation plan which will be put into place over the demo scenario.  Section 9 concludes the document and presents the future work to be carried out.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

2 SECURITY CONTEXT IN MOTO 2.1 Challenges in a hybrid opportunistic network For the purpose of this document, a hybrid opportunistic network [1] is considered as an AD-HOC mobile network, delay-tolerant (opportunistic), where mobile nodes are also supported by the operator’s infrastructure and where there is a central trusted node accessible at any moment but which does not manage the ongoing communication. However, this central entity (in this case, MOTO) is not a completely passive observer, as it sends instructions to guide the offloading in the Ad-hoc network and receives information from other nodes. Therefore, although the MOTO platform is not directly involved in the communication that takes place between User’s Equipment’s (UE), it supports the decision making that manages it. It is essential to consider, first, the environment where the MOTO services take place [2]:

 MOTO context 1 - Dynamic topology: Nodes are expected to move during content dissemination

 MOTO context 2 - Nodes can disconnect at any moment: Users can move out of coverage, turn off connectivity capabilities, switch off the device, etc.

 MOTO context 3 - Constrained Resources: Participating nodes are mainly mobile handsets with limited battery life and processing capabilities.  MOTO context 4 - The network is delay-tolerant: It is based on the store-carry and forward paradigm; content is not immediately forwarded and nodes may store and carry it in search of communication opportunities.

 MOTO context 5 - Existence of a central trusted node (MOTO Platform): In contrast to the typical opportunistic networks, MOTO approach has the possibility of using the MOTO platform as a central trusted node, for example to act as Certificate Authority, to deliver public keys among UE, etc.

 MOTO context 6 - Nodes can be presumably selfish and/or malicious: As nodes communication through the alternate channel (oppnet) are not under direct control of the network manager, the MOTO platform cannot monitor communications or decide which communications between which nodes should take place. Thus, it is presumable that they can act selfishly or even maliciously even after having authenticated to MOTO (insiders). All the circumstances described set an enormous challenge for security. Moreover, the MOTO platform might need to know the location of the UE (User’s equipment) to manage efficiently opportunity of communication between them and thus optimise content distribution. This sets another challenge for security, as location privacy has become a greater concern in mobile networks [3] and it is particularly difficult to achieve a satisfactory level of location privacy in situations where nodes rely on location-based services – LBS [4].

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Figure 1. MOTO Security Channels Thus, the goal for MOTO security is to ensure that end-to-end content integrity, privacy & confidentiality are guaranteed, without resorting to complex and expensive solutions. Integrity is assuring the absence of content modification through the communications, that is, data hops through successive relays unmodified from origin to destination. Privacy is a crucial issue in Oppnets [5] and mostly deals with preventing the identity and the location of the nodes from being disclosed to other nodes or third party entities which do not have the right to access such information, while confidentiality means keeping the secrecy of the exchanged data from being revealed to those not authorized to access it.

As explained in section 5.6.1‎ , cryptography is essential in order to assure integrity in opportunistic networks and it increases the performance and efficiency of the communications when the assurance of the content integrity is mandatory. To enable end-to-end integrity and confidentiality, it is essential to secure both, the information that is exchanged between two nodes in hop-to-hop communications and the identity and location information of these opportunistic nodes. Taking into account the typology of the communication scheme proposed in MOTO, where ideally the communication bulk relies within UEs, with or without central entity intervention (MOTO platform), it is necessary to propose a security scheme that can assure the confidentiality of the personal information that can be transmitted through any possible communication situation.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

2.2 MOTO context description Additionally, it is also necessary to analyze the proposed MOTO communication workflows defined in D2.2.1. (In particular in Section 4.5) to assess what are the elements of the architecture that are involved in the communication, which information is transmitted and through which channel. Based on the sequences defined in the use cases proposed, we can extrapolate the following eight basic communication cases between the internal and external actors of the proposed MOTO approach: 1. Communication between core MOTO services and application API: In this communication scene, the core MOTO services and the application API exchange information about the users to which certain content should be distributed, the dissemination constrains (allowed delay tolerance, etc.) and the content itself. Information of clients might include personal information; therefore, this communication should be protected from disclosure (authentication and encryption). 2. Authentication of UE to core MOTO services: This communication encompasses the interaction of the UE with the core MOTO service so that the UE can start using MOTO services. Information exchanged in this communication may include credential expedition, and therefore should be secured (encryption). 3. Offloading instructions delivery: this communication encompasses the delivery of information with the instructions of the dissemination to be accomplished by MOTO users. The information exchanged can include location and identification of users, and therefore should be encrypted. 4. Content download: this communication deals with the delivery of content from the Internet or core MOTO services CDM to the UE. Eventually, content is not sensitive information so there are no confidentiality implications, but it should be taken into account when dealing with integrity. 5. Authentication between UEs: this communication defines the exchange of credentials between MOTO users for identification and trust purposes before the exchange of content or other data. Information exchanged in this communication includes credentials. However, as it does not encompass the expedition of credentials, it does not have confidentiality concerns, but it should be taken into account when dealing with integrity. 6. Content offloading: this communication is defined as the transmission of content from one UE to another one through an opportunistic (Ad Hoc/Wi-Fi) channel. There is no confidentiality concern in this communication as there is no personal information intended to be exchanged. Again, as in the case of content download, integrity shall be analyzed. 7. Content tracking feedback: this communication is the acknowledgement of a UE for the content received to be sent to the core MOTO services. As this information includes identification of the UE who received the content, it could content personal information (location, user identification) and therefore needs to be secured (encryption). 8. Topological information: this communication although not being defined in the use case sequences, is defined in the description of the terminal architecture. It is defined as the delivery of topological information from the topological information building block in the UE to the LOC module of the MOTO architecture in the operator core network. As the information exchanged includes personal information (location data) of UEs, this communication should be secured (encryption and authentication).

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

In order to be able to secure the MOTO communication scheme, some aspects of the communication are assumed to be already secure. These previous assumptions, which are based on the availability of reliable traditional techniques to provide the required security guarantees, are: 1. MOTO Assumption 1: It is granted by encryption at the source (Content provider). This condition is stated to guarantee that no entity which has not been given privileges by the content provider (even the MOTO platform), cannot decrypt the content delivered. To grant this assumption, three main conditions must be fulfilled: a) Existence of a secure connection between the nodes and content providers, external to MOTO services (e.g. https through LTE) b) Delivery of Encryption Keys to nodes through this secure channel c) Encryption keys are strong enough and are only in possession of intended destination nodes (securely stored) When these conditions are fulfilled, the confidentiality of the content is granted end-to-end (see Figure 2). It is also assumed that the encryption key file size is negligible compared to the content file size.

Figure 2. Content encryption with Content provider session key and key distribution (confidentiality) 2. MOTO Assumption 2: MOTO platform is always accessible to the nodes. As defined in the use cases, MOTO platform is reachable by the UEs, although it does not participate directly in the Oppnet communications. 3. MOTO assumption 3: All authorized MOTO users are in possession of the MOTO platform’s public key, and therefore they are authenticated when communication takes place. They are “insiders”. 4. MOTO assumption 4: Additionally, the physical and logical layers of the infrastructure where MOTO services are deployed are assumed to be secured by traditional techniques with a sufficient security level. We therefore assume that potential malicious attacks are either external to MOTO, or end users of MOTO, but that they do not come neither from the MOTO infrastructure nor from the MOTO content providers.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

5. MOTO assumption 5: Finally, both the MOTO platform and the content provider are considered honest.

3 MAIN THREATS IN MOTO COMMUNICATIONS MOTO communication encompasses a very vast scheme. So that MOTO can operate properly, all ongoing communications, as well as all assets must be adequately secured. The functioning of MOTO is complex, and requires multiple actors’ coordination, secure information storing, secure data exchange and proper monitoring and security in place. MOTO communications are addressed to reduce operator’s infrastructure use in content distribution. The main idea is shown in the next figure:

Figure 3. MOTO offloading strategy The MOTO architecture, as exposed in D2.2.1: General Architecture of the Mobile Offloading System (Release A), is shown in the figure bellow:

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Figure 4. MOTO Architecture (D.2.1.1) To perform as expected, MOTO needs the following communications: 1. A secure and efficient transmission of the content to be offloaded (Application API), along with the clients which are expected to receive such content and the offloading requirements (content, SLA and Subscribers: top box), which will be delivered from several customer application (Application 1..N). This communication will be done through Internet, and as stated in D4.2 [6], using a Restful (Representational State Transfer) solution through HTTPS protocol. 2. A secure and efficient transmission of the state of the operators network (network monitoring & management), along with access to the operators network (e-UTRAN) and, to information related to user’s location (LOC) and their identity information (Auth & accounting). This communication will be done through Internet, and as stated in D4.2 [6],, using a Restful (Representational State Transfer) solution through HTTPS protocol. 3. A secured and efficient communication with the users’ terminals in order to disseminate content (cache, routing), regulate the use of the network (Topo, diffusion instructions, content tracking feedback, flow identification) and authenticate users (auth). Again, as stated in D4.2. [6], the selected protocol for this communications is Atom Protocol (XML through HTTPS). 4. A secure and efficient content offloading between user’s terminals. For this communication, the selected protocol is EPICS: Terminal-to-terminal dissemination with intra- and inter-content piece selection through Wi-Fi connectivity of terminals. And at least the following assets: 1. Databases: To store all the information required to perform the communications (content, client list, contract, client info database, etc.).

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

2. Functions: There are a set of functionalities (user authorization, content tracking, user location, etc.) that must be correctly working. The security of the majority of the communications (MOTO  Operator Infrastructure, MOTO  Content provider, MOTO  UE’s) can be well covered by traditional techniques, such as HTTPS, and functionalities and databases located in the MOTO platform can be secured also by traditional techniques and mechanisms (proper access control, IDS, SIEM, Antivirus, etc.). The main threats that are potentially uncontrollable or at least not fully under control, are those related to the offloading of the content through the alternative channel, this is, offloading within the user devices. Thus, the security definition in MOTO is focused on the securing of the ad-hoc communications. As it is assumed (MOTO assumption 3), all users participating in the MOTO communications through the opportunistic channel are insiders and already authenticated to the MOTO platform. Therefore, the threats for communications must come from inappropriate or negligent behaviour of the nodes. These nodes can be classified in three main groups; seeds, relays and recipients:

 SEED: Nodes that receive the content directly from the MOTO platform and are responsible to conduct the offloading to the rest of the nodes.

 RELAY: These are intermediate nodes which retransmit the content received from one node to another different node.

 RECIPIENT: These nodes are the recipients of the content. They also act as relays, as they can redistribute the content among other nodes. The main threats identified having these nodes as disseminators of content are:

1. Erroneous content injection: This occurs when the content received by a seed is modified (content integrity) or even changed by another unwished content. Examples of behaviour that can lead to the materialisation of such a risk are:

 Seed misbehaviour: A seed node which receives certain content from MOTO modifies it or even substitutes it by another potentially unwanted one. The unwanted content is then spread all over the network.

Figure 5. Seed misbehavior in erroneous content injection  Relay misbehaviour: A relay node which receives certain content through another node of the opportunistic network modifies it or even substitutes it by another potentially unwanted one. The unwanted content is then spread all over the network.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Figure 6. Relay misbehavior in erroneous content injection 2. No content retransmission: This threat occurs when the content is not retransmitted through the opportunistic network. Examples of behaviour that can lead to the materialisation of such a risk are:

 Selfish Seed: A seed node which receives the content directly from the MOTO platform but does not forward it to others. The nodes which should have received the content from this node may require direct transmission from the MOTO platform when reaching the panic zone:

Figure 7. Selfish seed in a no content retransmission threat  Selfish Relay: A relay node which receives certain content through another node of the opportunistic network but does not forward it to others. The nodes which should have received the content from this node may require direct transmission from the MOTO platform when reaching the panic zone:

Figure 8. Selfish relay in a no content retransmission threat

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

3. Personal data disclosure: There are different types of personal information that can be disclosed through the opportunistic network, which can dissuade users from trusting the service and must be avoided:

 Disclosure of real user identity: This occurs when nodes participating in the opportunistic communications are capable of discovering the true identity of other nodes.

Figure 9. User identity disclosure threat in personal data disclosure  Location and tracking of user: This occurs when nodes participating in the opportunistic communications are capable of correlating the location of a certain node during the communication. This threat is more severe in the case where users are also capable of discovering the true identity of the other nodes.

Figure 10. User location and tracking threat in personal data disclosure  Monitoring of user activity: This occurs when nodes participating in the opportunistic communications are capable of tracking a user’s communications in the alternative channel, including which type of content it downloads/requests, with which nodes it communicates, at which hours it connects, etc. As in the case of user tracking, this threat is more severe if the users are also capable of discovering the true identity of other nodes.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Figure 11. Monitoring of node activity threat in personal data disclosure In addition to these threats, we must take into account the security requirements stated in task T2.1., which were collected in D2.1 – Use case and requirements.

Requirement ID Description

The MOTO Platform MUST verify the reputation (acceptable historic trust R-7 profile) of users before providing them access to the MOTO Services

The MOTO Applications MUST allow MOTO clients to decide whether to R-10 participate or not in a MOTO offloading service at a certain point or location.

R-14 MOTO Application MUST guarantee privacy of user’s data stored in the UE.

The MOTO Application MUST request MOTO clients to authenticate before R-15 start using MOTO Services.

MOTO Application SHOULD enable users to define connection features such R-16 as access rights, encryption and signature.

The client-pair association MUST be secure, including authentication, R-17 encryption and signature when necessary.

Clients MUST interchange their credentials so that they can validate each R-18 one’s real identity in order to establish a connection.

Clients MUST be able to send trust feedback about the other clients to the R-19 MOTO Platform

The system MUST gather historical trust profiles from all clients that have R-20 already used MOTO Services

R-25 MOTO communications MUST be encrypted.

Security features in UE and core MOTO services MUST be correctly R-26 implemented and updated regularly to patch vulnerabilities.

R-27 Personal data stored in MOTO SHOULD be encrypted

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

MOTO SHOULD make use of strong authentication and access control R-28 mechanisms in all communications

Table 1. Security requirements stated in D2.1 – Use case and requirements

4 SECURITY GOALS IN MOTO

Taking into account the threats identified and the requirements exposed in section 3‎ , in this section, the targets for the MOTO proposed security are described. MOTO services are innovative from the point of view of the communication manager in which the infrastructure delegates the control of the communication. MOTO proposes the migration from an operator infrastructure centric communication, to a hybrid communication, which will rely mostly on user equipment (D2D communications) in order to decongest the operator’s bandwidth. The success of such an approach undoubtedly lies on users’ adoption. Therefore, the main goal of the proposed MOTO security approach will be focused on accomplishing users’ concerns about security. In this sense, to assure the success and optimal efficiency of the proposed MOTO services, users must be confident in the quality and security of the service. It is therefore necessary that the security solution protects the communications against the threats identified while, at the same time, do not degrade the user experience to an unacceptable level. This can be translated into the necessity of providing adequate levels of: 1. Confidentiality regarding the content exchanged with other users  The MOTO security solution must ensure that transmitted content cannot be read by unauthorized parties. 2. Privacy regarding the user’s location and identity  The MOTO security solution must ensure that the identity and locations of nodes are not disclosed to other users. 3. Integrity perceived as the detection of the manipulation of content  The MOTO security solution must detect any intentional or unintentional change in the transmitted data. All these needs shape the specific security objectives stated for the MOTO security approach: - User’s trust related to privacy of personal data and content integrity:

. End-to-end content protection: the objective of the proposed MOTO security approach is to assure that the content transmitted through the opportunistic network is secured against modifications, unauthorized disclosure and replacement.

Figure 12.Security Objective: End-to-end content protection

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

. Strong Authentication Mechanisms: the objective of the proposed MOTO security approach is to assure that all nodes participating in the opportunistic communications are authorized users (insiders).

Figure 13. Security Objective: Strong Authentication Mechanisms - Trustworthiness of the nodes:

. Nodes trustworthiness: the objective of the proposed MOTO security is to assure that users can enjoy MOTO services under hostile environments, assuring that only trusted and benevolent users participate in the ongoing communications; this is, whenever they are under coverage of the LTE or Wi-Fi operator’s coverage even in the presence of selfish and malicious nodes.

Figure 14. Security Objective: Availability in all cases

. Contribution to the quality of the service: the objective of the proposed MOTO security is to assure that users not only can enjoy MOTO services (provided by the objective above) but also that this occurs under expected performance, by facilitating the selection of optimal seed and relays, and the exclusion of selfish and/or inefficient nodes.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Figure 15.Security Objective: Contribution to the quality of the service)

5 THE PROPOSED SECURITY APPROACH

The proposed security approach must be conducted to avoid the identified threats in section 3‎ , which motivate the objectives stated in section 0‎ . In order to accomplish this, a unique security mechanism is insufficient. Mechanisms such as PKI can guarantee the confidentiality and integrity of information, and can even assure the origin of certain content. However, this type of security mechanism in isolation cannot detect neither avoid user’s selfish or malicious behaviour, or identity and location disclosure. Other mechanisms such as a trust framework, can help to detect and isolate selfish and malicious users, but will give no protection against content, identity or location disclosure. Finally, anonimization approaches can avoid identity and location disclosure of users, but will not prevent malicious or selfish users in the network or content disclosure. Thus, a combined approach is proposed, which is explained bellow. 5.1 Authentication First of all, it is necessary to provide strong authentication mechanisms. MOTO authentication will take place through the primary channel, operator`s infrastructure, and therefore traditional techniques are suitable. The authentication will be done by the use of a PKI scheme, MOTO users will authenticate against the MOTO platform through HTTPS using MOTO expedited certificates (SSL/TLS). MOTO platform will act as the Certificate Authority (CA), and will generate the MOTO platform certificate for itself and for the MOTO user. These certificates are based on lightweight X.509 v3. This authentication scheme assures that all nodes that enjoy MOTO services are insiders, and helps to secure all communications between the platform and the users.

5.2 Integrity and confidentiality of information It is essential to guarantee that the content to be transmitted through the opportunistic network is not modified or even replaced by another potentially harmful or malicious content (erroneous content injection). © MOTO Consortium – 2015 20

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

The proposed mechanism to avoid such threat is the use of encryption. It has been already stated that the content will be encrypted in the source, in the Content Provider (MOTO Assumption 1), but this fact is not enough. If the source of the content (content provider) uses a symmetric encryption approach, a malicious relay in possession of the key would be able to decrypt the content, modify or replace it and encrypt it again. This means that potential malicious or erroneous content could be delivered through the opportunistic network without user’s being aware. To avoid this specific threat, a new layer of encryption above the one assumed from the content provider is placed. The approach is that MOTO platform signs the content digitally. This way, all users are able to check the content integrity and assure its origin. Additionally, nodes use asymmetric cryptography supported by the MOTO platform to deliver public keys, to transmit content between them. The sum of these mechanisms guarantees that opportunistic communications are secure against confidentiality related attacks as well as integrity. Any attempt to modify the content becomes easily detectable (each relaying node can use the MOTO public key to assess that the content to be forwarded is genuine). This encryption process which comprises several steps is proposed in order to guarantee end-to-end integrity and confidentiality of the content to be distributed to the MOTO users. This is explained in detail in section 5.6.1‎ .

5.3 Trustworthiness of the users The security approach also has to guarantee that the nodes that participate in MOTO are trustworthy. Therefore, it is needed a security approach that enables the identification and suspension of MOTO services for malicious and selfish nodes. To achieve this, a trust & reputation management approach is proposed, which is explained in section 5.8‎ .

5.4 Users’ privacy Finally, a major concern for the opportunistic networks is the assurance of the privacy of the personal data of the users. This is one of the aims identified for the MOTO proposed security (user’s trust related to privacy of personal data). To achieve this aim, it’s necessary to avoid the personal data disclosure threat. To achieve this, the proposed security approach provides anonymity for users through the use of pseudonyms. This approach is explained in section 5.7‎ .

5.5 Overall security approach To sum up, Figure 16 provides an overview of the global security proposal related to the security objectives aimed.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Figure 16. Overall security approach proposed The proposed security approach consists of the following elements: (4) Multi phase cryptography (5) Pseudonyms anonymization (6) Trust & reputation management The combination of all these security approaches keeps under control the identified risks and provides the stated security objectives. Figure 17, shows the security mechanisms to be implemented in each of the ongoing communications within the different involved actors and also the related attacks that are kept under control thanks to the proposed security approach.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Figure 17. Overall proposed security approach

5.6 General description: End-to-end security In this section, the different mechanisms involved in the assurance of the end-to-end security proposed for MOTO communications are explained. 5.6.1 Multiple phase Cryptography As it has been already introduced, several threats identified require the use of cryptography. This way, a security mechanism is needed in order to restrict the disclosure of the content as well as its modification and replacement without detection, or even malicious content injection into MOTO communications. Specifically, the aspects that require the use of cryptography are:

 Assuring that the content will not be disclosed to unintended nodes, both internal and external to MOTO services: The encryption key delivered through a secure channel to the intended recipients by the content provider (CP) assures that only intended users will be able to decrypt the content. The asymmetric encryption in hop-to-hop communications assures that only MOTO users receive the encrypted content.

 Enabling the detection of content modification or replacement on the offloading: the signature of MOTO platform assures that the modification of the content will be detectable by seeds, relays and recipients.  The assurance of the origin of the messages in the hop-to-hop communications through the alternative channel: the MOTO signature assures the content origin while the asymmetric

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

encryption approach in hop-to-hop communications assures the origin in each offloading step and that both involved nodes are trusted MOTO users. MOTO platform signs digitally the content, so recipients are able to check that the content has not been manipulated or replaced during the handing over. To do the signature, SHA-3 is proposed, as SHA-1 and MD5 are known to be vulnerable.

Figure 18. Asymmetric cryptography approach to assure the origin and integrity of the content The hash of the content is encrypted with MOTO private key. Then, the content which was already encrypted by the CP, together with the encrypted hash, is sent to the users. Users are able therefore to verify the content’s integrity and origin by calculating the hash of the encrypted content and comparing it with the one signed by MOTO. Figure 19 represents graphically the two phases of the proposed encryption that grants the confidentiality (only those intended nodes in possession of the CP encryption key are able to “read” the content) and integrity (any modification of the original content is detectable). Performing the SHA-3 computation at every hop in the D2D network can be computational expensive. But, if this computation is not performed at every hop, it is possible for a malicious user (for example, a MOTO authenticated used that has modified the MOTO app) to send a fake file and a good signed hash (see the above paragraph). The file will not be accepted by the receiver but it will have been retransmitted a number of times in D2D, causing bandwidth consumption and battery exhaustion. This way, a malicious user could make other honest user be perceived as malicious, when the hash of the content is checked against the MOTO signed hash. However, the receiving node (at every hop to hop step), if honest, should perform the SHA-3 computation over the received content and compare it against the signed hash, to avoid relaying false content There is another approach that can avoid the need to check the hash of the content in every hop, and therefore avoid resources consumption in user devices. An UE could wait until receiving the same content through different relays, in such a way that the set of relay paths cannot be cut by 2k+1 relays, when one wants to tolerate k malicious relays. The choice between those two options depends on many factors, mostly the computation capabilities of the device and the network capacity of the D2D network. If the computation capabilities of the device are limited and the capacity of the D2D network is large, the second option is preferable. Otherwise, the first option is expected to give better performance.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Figure 19. Confidentiality & Integrity encryption phases With these two encryption phases, the two major concerns that require the use of cryptography are covered. On the contrary, the assurance of the origin node in the hop-to-hop communications is still not granted. To provide this last safeguard, an additional phase of encryption is proposed. Using the MOTO platform as public key distributor, UEs acquire, for each communication opportunity, the corresponding public key of the other node they are getting in contact with. Therefore, the last proposed encryption phase consists of implementing asymmetric encryption using session private/public keys of users, where public keys will not be exchanged between the users, but will be delivered upon request made to the MOTO platform. This last encryption phase provides authentication among users. Figure 20 provides a global view of the different encryption phases applied to the content, the parties involved in each communication and the security aspects covered.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Figure 20. Overview of the multi-layer encryption proposed for MOTO communications 5.7 Anonymity through the use of Pseudonymous In the previous section, a cryptographic approach has been described to deal with some of the security concerns of the communications. However, user’s identity and location is not protected from disclosure only by these means as explained in section 5‎ . The exchange of information between nodes during contact opportunities, which includes authentication between them, gives the chance to elicit user identity and/or to track user’s location and activity, both to insiders and outsiders, as the establishment of communication is unencrypted. To deal with this issue, a pseudonym approach is proposed. As it has been already explained, personal information encompasses:

 Real identity of the user  Location and tacking

 User’s activity In order to avoid the disclosure of this information, the MOTO platform delivers through a secure channel a set of public and private keys to each user correlated to a pseudonym [7]. This approach, rather than using a unique long-term asymmetric key pair for securing communications, implies that each node uses multiple short-term private-public key pairs which are correlated with variable session IDs (pseudonyms). A mapping between the short-term credentials and the long-term identity of each node is maintained and accessible only by the MOTO platform. The basic idea is that (i) each node is equipped with multiple sessions IDs (pseudonyms) which do not reveal the node’s real identity neither allow user location tracking, and (ii) the node alternates the use of the pseudonyms through a session, this is: the user uses each of them for a short period of time, and then switches to another, not previously used pseudonym. This way, messages signed with public keys by users under different pseudonyms cannot be linked and the user location and identity privacy is guaranteed.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

As the following figure shows, two authorized MOTO users: user 1 and user 2, are provided in a certain time (time 1) a set of private/public encryption pairs with a correlation of pseudonyms to which each of these pairs of encryption keys are related to.

Figure 21. Pseudonym delivery to user 1 and user 2 in time 1 However, it is necessary to assure that: (1) MOTO platform’s and UEs’ pseudonyms and correlated asymmetric key pair match over time, and (2) Users do not change pseudonyms in the middle of a communication. To assure both aspects, the process of refreshing users’ pseudonyms and keys requires the confirmation of the reception and the statement by the UEs of when the use of the new pseudonyms will start. This protocol is shown in more detail in D4.1.2. Once users are in possession of the encryption key pairs and their related pseudonyms, when encountering a content offloading opportunity, both users will exchange their pseudonyms instead of their MOTO certificates (public keys). This avoids that a malicious node, in the proximities of both nodes, could perform a passive attack to disclose the delivered content, or to discover User’s 1 real identity. Figure 22, shows the process for the case of user 2 requesting and receiving the public key associated with user’s 1 Pseudonym 1. Instead, both users deliver their pseudonyms. Each user has to connect to the MOTO platform using a secure connection (SSL/TLS) through the primary channel in order to request the public key which corresponds to the received pseudonym in that precise moment (Time 1). When the MOTO platform has received both pseudonyms (confirming both users intentions to communicate), and after assuring both requesters are still authorized to enjoy MOTO services, the MOTO platform sends the corresponding public

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms key through the secure communication channel to each user. User 2, will then send a connection acceptance message along with a proposed session key, encrypted with the public key received. Once user 1 confirms the origin of the proposed key, it sends user 2 a confirmation message for the received session key anda secure transmission of the content takes place.

Figure 22. Use of pseudonym in a content offloading opportunity

This approach grants that only authorized users will be able to receive the content delivered through MOTO services, without the need to disclose any user’s real identity.

The next step to reach the desired confidentiality objective is to avoid the correlation between a certain user and its assigned pseudonyms through time. To do so, the proposition is to reuse the same pseudonyms over time and to assign them to different users, as shown in Figure 23. The assignment of the same pseudonyms over time to different users provides even stronger levels of privacy, as correlation of user’s location or activity over time is much more difficult. To do so, as it occurred in Time 1 (Figure 21), after a stated interval of time, the same users will be provided with a new set of public/private key pairs and a correlation of the pseudonyms to them.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Figure 23. Pseudonym delivery to same users 1 and 2 in Time 2 Figure 24 shows the assignation of previously used pseudonyms between users in different moments. As it can be seen, Pseudonym 2 of user 1 is assigned to an encryption key pair of user 2 (poseudonym 2’) in time 2, and pseudonym 2 of user 2 in time 1 is assigned to user 1 (pseudonym 3’) in time 2. This way, for a node monitoring the channel (authorized to MOTO or not), it will more complex to track a user.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Figure 24. Reuse of pseudonyms within MOTO users through time

This approach grants that user location and activity cannot be tracked over time

Figure 25. Proposed pseudonymous security scheme shows an overall view of the proposed pseudonym approach proposed.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Figure 25. Proposed pseudonymous security scheme

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

5.8 Trust & reputation management Traditionally a trust and reputation framework for an Ad Hoc network basically consists of a range of security mechanisms agreed by the nodes. Indeed, nodes agree the implementation of a set of actions that will be triggered by a set of security events. The source of information that permits the detection of such events comes from the nodes themselves. Essentially, the nodes exchange information and feedback regarding the communication that has taken place with other nodes, and based on the information received and on the previously agreed conditions; each node will decide whether to accept or not a connection with a certain node. The management of trust levels will depend on the protocols used. However, MOTO proposed communications scheme is not a pure opportunistic network, but a hybrid approach as it was explained in section 2.1‎ . MOTO is not directly involved in the communication that takes place between Users’ Equipment’s (alternative channel) but can support offloading decisions. MOTO platform sends offloading instructions to the nodes based on the received information from other nodes. 5.8.1 Trust framework previous considerations The most problematic aspect of the trust framework is that the MOTO platform has no way to confirm that the given trust feedback is fair. Therefore, in order to properly define the trust value of a user based on the feedback received, several questions must be answered: 1. How many negative feedbacks must the MOTO platform receive in order to revoke a user’s legitimation (MOTO certificate and pseudonyms) to use MOTO services? The trust value of a user is dependent on the feedback received from other users. Consequently, it is necessary that, given a number of bad feedbacks about a user, the MOTO platform reacts and revokes this user’s right to use MOTO services because he will no longer be trustable. However, before the MOTO platform performs revocation actions, it has to take into account several factors. The most obvious one is the possibility of receiving a false bad feedback from a malicious node. Another factor that must be taken into account is the environmental interference, as communications in the offloading scheme take place in an open channel; Wi-Fi connections are sensible to collisions and the frequency in which they transmit is open to other services, which is very problematic when they transmit in the 2.4 GHz band, and theoretically less problematic when they transmit in the 5 GHz band. Some Wi-Fi standards (802.11a/n/ac) can transmit in the band of 5 GHz, which is quite less interferenced. This is why the prevailing conditions in the transmission channel during the UEs connection must be taken into account when recalculating the trust value of a user based on a feedback received. Thus, it is possible that external factors to the user can affect negatively the communication, not being fair that a user trust value is affected for that reason. Therefore, MOTO services will presumably not be the only ones provided through this technology. Therefore, the trust value should also depend on the environmental conditions existing when the communication took place.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Consequently, the decision to revoke a user’s certificate should be taken when a number of bad feedbacks from trustable users are received, and when the communication environment does not affect the opportunistic channel communications. 2. Should the feedback received from all users have the same weight? One of the main threats that has been identified in the opportunistic MOTO communications is the presence of malicious insider nodes that attempt to: ruin its effectiveness, gain access to personal data of users or perform other malicious actions. This is why there are several threats that have to be taken into account before shaping the trust of a user from the feedback received. The two main threats regarding the feedback received from a user are: (1) An intentionally bad feedback of a user given from a malicious node so as to get the first user out of MOTO, (2) The false positive feedback of a node that attempts to make a malicious node look as a trustable one. Therefore, a mechanism must be put into place to avoid these situations: a. The feedback received regarding a user is expected to be homogenous over time. An incongruity between the average historical received feedback regarding a user and the received feedback in a certain moment, can serve as an indicator of irregularities. It could make a false feedback to outstand. Example: All users have always reported a good feedback (4 or 5) regarding node A, and suddenly node B sends a bad feedback about node A (1)

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Figure 26. Expected timely homogeneity of user’s received feedback b. The environmental factors should affect all communications in a certain moment and location homogenously; comparing the feedback received within the same time window may help to spot erroneous or malicious feedbacks, as external factors should affect communications more or less homogenously. The tolerance of the feedbacks based on the environmental adjustment is still to be defined. Example: If under very bad environmental conditions (average feedback (1)), only a certain feedback seems not to be affected (5), probably this feedback is either erroneous or malicious. This is also relevant in the case that the coverage of an operator is deficient in a certain area. As users rely in the communication with the MOTO platform through the services provided by the operator, this could affect negatively the communication, hampering the reception of the public keys of the pseudonyms. Therefore, the operators coverage should be taken into account.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Figure 27.The environmental factors expected homogeneity c. The historical feedback of the reporting node (the node which is receiving the content) can give a hint of its behaviour. Therefore, it should also be taken into account. If a user’s feedback of other nodes differs continuously from the historical feedback of these nodes or does not present accordance with the environmental factor, it is assumable that the user’s feedback is either erroneous or malicious. The record of the feedback reported by the nodes will help to identify if their feedback is trustable. Consequently, the trust of a node’s feedback must be taken into account before calculating the corresponding trust value of the reported user. However, this error can be malicious (on purpose) or it can be unintentional (old or damaged terminal, poor connection capabilities, etc.). Therefore, it should not be taken into account when assessing the revocation of the certificate of the reporting node. Example: Node D receives some content from Node A. Node D sends a bad feedback regarding the communication with node A (feedback value: 1). However, the environmental conditions of the communication were OK. Moreover, other nodes that have previously communicated with A always sent a good feedback about node A.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Figure 28. Expected historic homogeneity of user feedback 3. Does the sender have any role in the feedback reporting? Until now, we have exposed the construction of the trust of a user based on the feedback the MOTO platform receives from the users that have received the content, that is, from the receivers. The analysis of the senders’ perception of the communication may be interesting as it could help to spot incongruities. This will be especially helpful in the initial involvement of the user with MOTO, when there is not enough historical data to be analysed. This way, the MOTO platform will be able to compare the feedback received from the receiver of the content regarding the sender, with the feedback that the sender sends to the MOTO platform for the communication, this is, the feedback value the sender expects to be valued with. Doing this, a new user, will be better protected in front of malicious users that could expel the new user from the MOTO services, if their feedback was the only one used to calculate the user’s trust. For example, a malicious node may claim that he has not received the content or that the connection was poor, when it wasn’t. In this case, the positive feedback of the sender will point out the misbehaviour of one of the nodes. 4. What behaviours are considered negative regarding trust? One of the main features defined in the proposed MOTO security approach is that the authorization of users to participate in the MOTO services is dependant, among other factors, on the user’s behaviour. This means, that a user who is already benefiting from the MOTO services, can be expelled if it misbehaves. Behaviours that are considered inadequate are mainly: a. Acting deliberately in a way that negatively affects the dissemination of content or the MOTO services in general, including: giving false feedback, providing erroneous location information, etc.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

b. Modifying the content: it has to offload in order to avoid that the right content reaches the intended user. c. Acting selfishly: understood as participating in the dissemination scheme only as receiver of content and never as deliverer. Once the questions that must be answered regarding the trust framework have been exposed, the proposed MOTO security scheme can be defined. In order to monitor the behaviour of the MOTO users, and taking into account the semi- independent performance of the offloading scheme (communication within UEs occurs independently of the MOTO platform), the behaviour of users within the communications taking place in the alternative channel can only be monitored indirectly attending to information delivered by the nodes involved in each communication. This information would be the already mentioned feedback from the users. This feedback will include at least: 1. The acknowledgement of the content received: This information will include at least the following: (1) the user from which the content was received (2) the hash of the content received (3) the time of the reception and the user who received the content 2. The trust feedback: This information will be delivered along the acknowledgement of the content and will give information about the quality of the connection. This information will be a score based on a previously defined scale (explained in the next section) that will give the MOTO platform an idea of the user’s behaviour. 5.8.2 Trust Feedback When a communication has taken place in the opportunistic network, both nodes involved send a feedback to the MOTO platform. This message is intended to inform the MOTO platform that the recipient has received content, in order to manage the content reinjection, but is also intended to monitor the nodes behaviour for security reasons. The feedback received from a user by the MOTO platform is composed of at least the following components: 1. The hash value of the content received: the hash value will be calculated for the content delivered by the Content Provider. This content is the one with red shading in Figure 29. Content Hash function received with user's feedback

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Figure 29. Content Hash function received with user's feedback 2. Trust value for the other user involved in the communication: the trust feedback received from a certain communication between two users, User A and User B, is delivered to MOTO as a simple integer value from 1 to 4, being: [1]. Bad experience: Content not delivered, communication interrupted and never established again or malicious intrusion attempted. [2]. Poor experience: Content delivered after a time window above required QoS, multiple interruptions during connection. [3]. Acceptable experience: Content delivered within QoS defined time window, few connection interruptions. [4]. Optimal experience: Content delivered within QoS time windows and no connection interruption. Both users send their feedback about the connection to the MOTO platform. This way, the MOTO platform has both points of view of the involved communication edges and the trust feedback of the communication does not only rely on one of the sides when other sources of information are not enough. 5.8.3 Environmental Factor As stated before, the channel through which the communications take place is open (wireless) and the technology used is susceptible to collisions (Wi-Fi). Taking these facts into account, it is possible that external factors can affect the communications and affect the feedbacks. It is necessary therefore, to calculate an alternative variable, that could be called environmental adjustment (ʎ) that will take into account the average feedback received by all the communications that take place simultaneously and identify if interruptions or delays in communications can be explained by external factors to the users desires (heavy load in the channel, presence of interferences, etc.). ∑

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Being:  F = The trust feedback from all communications

 t = time  i = the time window defined

 V= the number of feedbacks received for all communications within the time window The time window is variable in dependence of specific characteristics of each location where the MOTO services are provided. The environmental factor will be discriminated in relation to the operator of the node, in order to identify if the degradation of communications is due to operators services deficiency. 5.8.4 Computation of the trust value of a user Taking into account what has already been explained (5.8.1‎ , 5.8.2‎ and 5.8.3‎ ), in this section a description of the recalculation of a certain user trust triggered by the reception of a feedback for him is given. The trust of a user above the threshold represents that the user is trusted to participate in the MOTO communications. This trust value is updated each time the user is requested to send content to another user through the alternative channel and a feedback is received in return. The information sources that can be used to update the trust value of a user after a communication has taken place are the following: 1. Feedback trust value received from the receiver node: This value received by the MOTO platform, is in the range of 1 to 4 as stated before, and is sent by the user that receives/or was supposed to receive the content from the user whose trust is being evaluated. 2. Environmental factor: This value was already explained before; it helps to spot incongruities between the feedback received and the feedback expected due to the availability of the communication channel (saturation, interferences, etc.). To calculate it, the feedback received from users communicating in the nearby of the node is taken into account. The location information is requested to the LOC module. 3. Feedback trust value received from the sender: This is the trust value that the user who sends the content sends to the MOTO platform regarding the communication that took place. It contains the feedback value the user is expecting to receive from the node who received the content. 4. Reliability of the receiver’s feedback: Reliability given to the content receiver’s feedback: this value represents the weight that the feedback of the content receiver node is given. If the receiver’s feedback is not reliable enough, it is not taken into account. If it is reliable enough, the received feedback is also weighted by this value.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

5. Record of previous feedbacks regarding the sender: This is a database which stores a number of feedbacks related to the sender of the content. It helps to spot incongruities between the feedback given for the sender previously by other nodes and the current feedback received and l also helps to detect if a node has been corrupted and is from then malicious 6. Hash of the content: The MOTO platform is able to compare the hash that the receiver in the alternative channel has included in his feedback with the hash of the content received from the external content provider, and therefore, be able to detect if the integrity of the content has been compromised. The following Figure 30 encompasses the proposed process when defining or updating a user’s trust after a feedback is received.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Figure 30. Recalculation of a user's Trust value

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

STEP DESCRIPTION

As a first step, when a feedback is received from a user regarding another user, the hash received is compared to the hash functions stored in the MOTO platforms 1 database. If the hash is related to an authorized content, the process continues to step 2, if else, the process jumps to step 2’.

Once the MOTO platform has identified that the received content is not authorized, it checks the content the sender node claims to have send, that is, it checks the hash function of the content in the sender’s feedback. There are two possibilities in the comparison of the senders feedback: 2’ 1. The feedback states a HASH function of an authorized content, which leads to step 3’. 2. The feedback stated in the HASH function is neither related to an authorized content, which leads to step 4’

The reliability of the recipient feedback is checked to weigh the reliability of the received feedback. If this reliability is above threshold, the process will jump to 3’ step 7. If reliability of sender’s feedback is not above threshold, feedback is discarded.

If the sender claims to have sent an unauthorized content, previous feedbacks of the sender have to be reviewed to point out if this unauthorized content was received from other user previously. If not, the receipt is alerted to discard the 4’ content and the process jumps to step 7. If the content was received by the user from a previous communication (other user), both sender and receipt are alerted to discard content and trust recalculation is aborted.

As a second step, the value of the feedback received by the content receiver is weighted by the environmental factor (Frec | Ef). For example, if there are very bad 2 environmental conditions, the feedback weight in the update of a user’s trust should be lower

It is checked if the previous feedbacks provided by the receiver are reliable or not. For that purpose, it is checked if the reliability of the receiver’s feedback is over a given threshold: 3  IF the Receiver’s feedback reliability (Frelrec) < Threshold  the feedback is discarded as this user has not provided reliable feedbacks before

 IF the Receiver’s feedback reliability (Frelrec) > Threshold  step 3

Being the Frelrec > Threshold, the receiver feedback (Frec | Ef) should be weighted 4 by the Frelrec (Frec | Ef | Frelrec). This way, the feedbacks coming from users with high reliability in their feedbacks is taken more into account than one of a user

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

with lower reliability for their feedback.

It is checked if the sender has received any previous feedback from other communications with other users: 5  IF YES  step 6

 IF NOT  step 6’

If there is no previous feedback about the sender, that is, it is the first time this sender sends content to a user, the feedback from the sender (Fsen) regarding the 6’ content receiver is taken into account once weighted by the environmental factor. This way, the feedback from the receiver (Frec | Ef | Frelrec) is weighted by the feedback from the sender (Frec | Ef | Frelrec | (Fsen | Ef))

Once the feedback regarding the sender has been correctly weighted, the 7 Feedback record regarding the sender is correspondingly updated with this new value as the last entry of its historic database.

The trust value of the sender is then recalculated for all the stored entries of its 8 historic database.

It is checked if the sender trust value is over a given threshold:

9  IF Sender trust value > Threshold’  nothing happens  IF Sender trust value < Threshold’  step 10

10 The user privileges to enjoy MOTO services is revoked (MOTO certificate revoked)

Table 2. Calculation of user trust triggered by feedback receipt 5.9 Overall security approach algorithm In this section, a proposed algorithm to implement the security proposed for MOTO is exposed. A pseudo code is used for this target:

For Session 1:S

Session BEGIN

# Content preparation in the Content provider (content is encrypted with a Session key by the CP)

CP: SessionKey Si [content Ci]

send Si to Ui # Content delivery to MOTO

CP : sends KPU_MOTO [contract], [Si [Ci]] to MOTO # Content preparation in MOTO and distribution to seeds

MOTO: KPR_MOTO [KPU_MOTO [contract], [Si [Ci]]  obtains contract, [Si [Ci]]

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

creates hashi_MOTO = hash [Si [Ci]]

identifies optimal seed nodes = Ni

sends KPR_MOTO [Si [Ci]] to Node Ni # Multi-hop information forwarding (seed to hop, hop-to-hop, hop to FinalNode)

for all sender Nodei Ni i : 1….N, receiver Nodek Nk k : 1….N

while t

for Ni encounters nodes Nk

Ni sends connection request to all the Nk # Pseudonyms authentication

if session is not open between Ni and Nk then

Ni requests pseudonym to Nk

Nk send Pseudk to Ni

Ni sends all KPR_Ni [Pseudk] to MOTO

MOTO: decrypts all KPu_Ni [KPR_Ni [Pseudk]]] to obtain Pseudi

checks correlation Pseudi  KPU_Ni

checks correlation Pseudk  KPU_Nk

if Ni or Nk trust level < threshold

communication Ni  Nk ends else

sends KPR_MOTO[KPu_Ni [KPu_Nk, Pseudk]] to Ni

sends KPR_MOTO [KPu_Nk [KPu_Ni, Pseudi] to Nk end if

end if

Nk decrypts KPu_MOTO [KPR_MOTO [KPr_Nk [KPu_Nk [KPu_Ni, Pseudi]]] to Nk to obtain

KPu_Ni, Pseudi

Nk requests pseudonym to Ni

Ni sends Pseudi to Nk

Nk checks if Pseudi from Ni is the same as the one received from MOTO end if

# Hop-to-hop content delivery

Ni : encrypts the content : KPR_Ni [KPR_MOTO [Si [Ci]]]

sends KPR_Ni [KPR_MOTO [Si [Ci]]] to Nk

sends expected feedback expected_feedbackNiNk to MOTO # Content reception in receiver node and feedback delivery to MOTO

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

if Nk: receives content in (t < tlimit)

sends ACK to Ni

decrypt KPu_Ni [KPR_Ni [KPu_MOTO [KPR_MOTO [Si [Ci]]]]]

obtains [Si [Ci]]

creates hash_Nk = hash [Si [Ci]]

generates feedbackNk (Ni, hash_Nk, trec, trust_feedbackNiNk)

sends feedbackNk to MOTO

# MOTO updates Ni trust value

MOTO: compares received hashci_Nk = hashci_MOTO

trustNi update = ponderation (trust_feedbackNiNk, historic trustNi,

fenvironment, freliabilityNk, expected_feedbackNiNk)

# Content not received in receiver node

else (t > tlimit)

Nk: generates bad feedback

sends feedback (Ni, trust_feedbackNiNk,) to MOTO

# MOTO updates Ni trust value

MOTO: trustNi update = ponderation (trust_feedbackNiNk, historic trustNi, fenvironment, freliabilityNk)

end if

end for

end while Session END

Table 3. Proposed Security algorithm pseudo code

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

6 PRIVACY VS OFFLOADING PROTOCOLS: A CROSSROADS Although even in the case where the pseudonym does not change over time (worst security case), the real identity of the user is anonymized in front of other nodes. The proposed pseudonym user anonymity approach, provides very good safeguard to user's privacy, regarding real identity disclosure and location (tracking). However, the approach comes into conflict with the requirements of the evaluated forwarding protocols (social aware forwarding protocols), which rely on knowledge of contacted users over time For example, utility-based forwarding protocols need to collect and analyse some statistics about past contacts among nodes. The problem is that forwarding protocols where nodes do not need to “know” if they have previously been in contact with a certain node (social oblivious such as the epidemic forwarding protocols), as it was stated in D3.1 [8] “suffer from severe resource consumption and tend to overload the network”. Therefore, the stronger the user anonymity approach provided to a user is, the more constraints are imposed to the forwarding protocols UE can use, and consequently, the more resource consumption and overload are imposed to the network. Consequently, a compromise must be achieved in order to balance user privacy and network performance. What is proposed in MOTO is to allow users to decide about the privacy they want. To do so, users must be informed of the network performance and privacy implications of the privacy level they choose. A set of privacy levels have been defined (Low, medium, high), in steps of increase of privacy (e.g. same pseudonym over time, a set of randomly generated session pseudonyms for each user, a set of randomly generated pseudonyms for users which can be assigned to different users in different sessions) and the consequent network performance is estimated as a next step. To do this, the results obtained in WP3 permit to estimate the delay experienced by the users for the different protocols and therefore, to estimate the network performance that a user could achieve in each of the privacy levels that can be selected. On the other side, it is also essential to bear in mind that a high privacy level does not always imply a slower content reception or a worse network performance. Indeed, it highly depends on the number of users that are in the area using the same privacy level (as nodes using different forwarding protocols are unable to communicate with each other). That is, despite using a high privacy level, if there are many MOTO users in the area using this same privacy level, the content is received much faster. As a conclusion, a high privacy is not a synonym of low network performance as it highly depends on the number of users.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

7 INITIAL SIMULATION RESULTS ON SECURITY This section presents the first results obtained from the simulations being carried out in order to check the efficiency of the proposed security solution. On the one hand, it has been found so far that the distribution of keys and pseudonyms approach does not imply a long period of time without service. For the analysis of the key distribution process Monte Carlo simulations have been performed. A network simulator (ns-3) providing models of how the packet data networks work has been used. A scenario with the user nodes and the MOTO platform has been configured, where the platform is responsible for the sending and reception of asymmetric keys and pseudonyms. The simulations have focused on measuring the time that it takes to stabilize the network: the time elapsed from the moment the first key is sent to all nodes of the network and the moment when all of them have received new keys and pseudonyms. In the simulation performed, nodes are placed randomly and their mobility throughout the coverage area is random. Table 4 summarizes the parameters set on the scenario for the different simulations. Different tests were carried out with two different lengths of package, in order to know whether it is feasible to send multiple pairs of keys and pseudonyms to perform the operation of key refreshment less often and therefore have less time the application without service.

Parameter Value Number of eNBs 1 Number of nodes 10, 15, 50, 150 Length of keys and pseudonyms 320 bits, 600 bits Messages lifetime 3 s Time from the first traffic delivery 250 ms Table 4 Simulation parameters (Montecarlo simulation) Figure 31 shows the results obtained in the different simulations (95% trust interval). As it can be observed, the network stabilization time (Ts) is less than 150 ms in the worst case, which means that the time the MOTO platform stops providing services for this cause is acceptable. In addition, as it can be seen in Figure 31, although the stabilization time of the network grows exponentially as the number of nodes increases, the difference between sending a smaller package and one almost twice bigger increases just a bit the delay.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Network stabilisation time

160 320 bits 140

120 600 bits

100

80 msec

0 10 15 50 150

Nodes

Figure 31 Network stabilization time

Nodes Ts; keys 320 bits Ts; keys 600 bits 10 12,99 ms 14,68 ms 15 16,86 ms 17,88 ms 50 52,50 ms 61,73 ms 150 127,52 ms 148,17 ms Table 5 Network stabilisation time On the other hand, in order to evaluate the delay introduced by the security mechanisms in the whole process of data transmission from the seed to the target node, Event Driven simulations have been carried out. The same process have been simulated with and without security in place. The worst case has been considered, in which all the nodes of the network will have to receive the content. Table 6 summarizes the parameters set on the scenarios for the different simulations: Parameter Value Number of eNBs 1 Number of nodes 10, 15, 50, 150 Length of the data 3 MB Messages lifetime 3 s Time from the first traffic delivery 1000 ms Table 6 Simulation parameters (Event driven simulation) In the simulation with security in place, the following parameters have been simulated:

Nodes Ts; keys 320 bits 10 500,13 ms 15 623,80 ms 50 3282,13 ms 150 5620,59 ms Table 7 Number of nodes © MOTO Consortium – 2015 48

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

The following figure shows the comparison of the whole process duration (sending of the content from the seed to the target node) without security (in orange) and with security in place (in blue):

Figure 32 Comparison of the whole ad-hoc communication process with (blue) and without (orange) security in place

We can conclude that even in the worst scenario, where all the nodes should receive the content, the delay introduced by the security mechanisms can be assumed. That is, in the case where 150 different nodes should receive a given content, the content will take 3.35 sec to arrive to all the destinations if we do not take security into account and the content is retransmitted directly without performing any security check (no encryption, no pseudonyms anonymisation, etc). However, if we consider the use of cryptography and the pseudonyms, the content will take 5.62 sec to arrive to the 150 nodes. Therefore, it is concluded that the cost introduced by the security mechanisms is acceptable. The complete results from the Event simulations that are currently being carried out will be provided in D5.2. Evaluation of offloading strategies based on simulations.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

8 SECURITY IMPLEMENTATION PLAN This section presents the implementation planning of the security solution. First of all, recaps the main threats to the MOTO operation and the main security mechanisms proposed to face these threats are described. After that, the first global demo scenario is described in order to understand the environment where the security mechanisms should be implemented. As this scenario shows different features in comparison with the initial MOTO scenario, the security mechanisms should be customized and adapted to the new threats that should be prevented. These new threats are presented together with the security mechanisms that will be put into place. Finally, the security implementation plan is provided. 8.1 Theoretical security approach Taking into account all the security mechanisms described in this document, the main threats that affect the MOTO operation as well as the security mechanisms that are proposed to solve them are gathered within this table: Communicating Threat Security mechanism N entities Name Description Sender Receiver Name Justification Attacker discloses the Encrypting the content will Content content when Content MOTO avoid an attacker to 1 disclosure or delivered from the Encryption provider platform change the data modification content provider to the transmitted and reading it. MOTO platform An attacker Encrypting the content masquerades as MOTO with the MOTO platform platform to trick public key will avoid an MOTO UEs/Operator or CP MOTO UE/Opera Encryption/ attacker to disclose 2 platform and get them to Platform tor/CP signature information intended to it, Impersonation download malware, while signing the messages disclose personal from the MOTO platform information, etc. will guarantee its origin. An attacker masquerades as CP to Encrypting the content CP trick MOTO Platform MOTO Encryption/ with the CP public key will 3 CP Impersonation and get it to download Platform signature guarantee its origin as well and distribute as avoid its disclosure. malware, SPAM, etc. If user’s are provided with a MOTO certificate that Unauthorized A subject accesses the they keep safe, only those MOTO User 4 access to MOTO services without UEs subjects in possession of a Platform certificates MOTO services being a Moto user valid certificate will be granted access to use MOTO services The use of encryption from A MOTO user modifies Erroneous the source of the content the content to be Seed/Rela Recipient 5 Content Encryption guarantees the integrity disseminated through y (UE) (EU) injection when content is distributed MOTO by not recipient EU, while the MOTO encryption

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

assures that the content has not being modified in transit. The implementation of a feedback feature along with a trust framework in the communication will A UE receives the permit the monitoring of MOTO services content, but does the content dissemination efficiency never disseminate it or Seed/Rela Relay/Reci Feedback + through the Oppnet and 6 reduction or disseminates it only y (UE) pient (EU) Trust the user’s behaviour, it is No some times to other important that both sender retransmission nodes and receipt of each communication send feedback to avoid receipt claiming not received content Avoiding the disclosure of A malicious node could user real identity in the Ad- User identity & Anonymization identify and/or track Hoc communication and 7 Location EUs UEs through the position of another refreshing their session disclosure pseudonyms node through time identity will avoid their tracking

8.2 MOTO demo scenario The security mechanisms should be adapted to the demo scenario over which they will be implemented in order to solve the main security threats that could have an impact over this scenario. This section provides an overview of the demo scenario so as to be able to better understand the security measures that will be put into place. The main features of the demo scenario which impact the security development are the following:  There is no Content Provider within the demo.  There are no relays. Indeed, all the nodes participating in the communication are willing to receive the content, that is, all of them are final recipients of the content.  The connection between the MOTO platform and the user devices is not secured, that is, there is no https connection, but just http.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

Figure 33 MOTO 1st Demo scenario 8.3 Security implementation for the 1st MOTO demo scenario The security mechanisms will be adapted accordingly in order to protect from the threats that may affect the demo scenario presented in the previous section: Communicating Threat Security mechanism N entities Name Description Sender Receiver Name Justification An attacker masquerades as MOTO MOTO platform to trick UEs MOTO Signing the messages platform MOTO 1 and get them to Platfor UE from the MOTO platform Impersonati Signature download malware, m will guarantee its origin. on disclose personal information, etc. The use of the MOTO A MOTO user modifies Erroneous signature, based on the the content to be Seed Recipien MOTO 2 Content hash of the content sent disseminated through (UE) t (UE) Signature injection assures the integrity of MOTO the received information Unauthorize Password/S A subject accesses the MOTO Each user is identified by d access to IM 3 MOTO services without Platfor UEs a password (SIM MOTO Identificati being a MOTO user m identification will be services on studied as the unique SIM

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

isn’t supposed to be faked) A man in the middle Change Apache server Content HTTPS could take the configuration from HTTP reception by MOTO MOTO / channel 4 information sent to HTTPS would avoid man in the / UE UE securizatio between MOTO and the anyone to “listen” to the middle n UE communication

8.4 Planning for the security implementation for the 1st MOTO demo scenario Taking into account the security mechanisms, the implementation in the Demo deployment should follow the following planning: Prioriti Security mechanism es Name Steps 1) Fork and deploy the server side web service (Droid and Feedsync). 2) Analyse the source code of the server side and define the location to insert the HTTPS security workflow. channel 3) Study the HTTP for REST connection in JAVA and configure the HTTPS in 1 Security Tomcat. methods 4) Fork and analyse the client Android Apps and locate the HTTPS client code. study 5) Coding and debugging for both server and client apps.

1) Define the signing process and algorithm. MOTO 2) Coding and merging the signing process into server source code. 2 Signature 3) Coding and merging the signature verification process in the Android App Injection

1) Define the Key distribution process with the HTTPS study results. MOTO 2) Coding and debugging the server side key distribution part. 3 Public key 3) Coding and debugging the client Android part. Distribution

1) Analyse the conventional registering system with user ID + password (might be SIM certificate.) 4 Identificatio 2) Study the possibility and complication of implementing SIM identification by n comparing with the traditional method.

1) Define testing methods with partners Testing and 5 2) Merging the security branch into main branch in GitHub Merging

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

9 CONCLUSIONS AND FUTURE WORK This document is dedicated to present the security solution for the communication scheme proposed in the MOTO project. This security approach is responsible for protecting the MOTO environment against the main threats and security attacks, with a main focus in the end-to-end content protection and user privacy. Moreover, the security solution should also be in line with the requirements of the forwarding protocols used in the communications. Furthermore, the first security simulation results are presented in this document, which show that the distribution of keys and pseudonyms approach do not imply a long period of time without service. Moreover, the event driven simulations show that the introduction of the security mechanisms within the overall ad-hoc process does not introduce a remarkable delay. More detailed simulations on the security performance are envisaged for the next months of the project and its results will be covered by D5.2 Evaluation of offloading strategies based on simulations. Apart from that, the security mechanisms responsible for securing the demo scenario will be implemented and integrated into the prototype during the next months. The implementation results will be presented in D5.3. Evaluation of offloading strategies based on experimentation.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

10 REFERENCES

[1] P. Hui, A. Lindgren and J. Crowcroft, “Empirical evaluation of hybrid opportunistic networks,” in COMSNETS, 2009. [2] A. García, D. Valerdi and F. Benbadis, “D2.1 User cases and requirements,” 2013. [Online]. Available: http://www.fp7-moto.eu/wp-content/uploads/2014/01/Deliverable_D21_1.01.pdf. [3] I. H. T. Parris, “Privacy-enhanced social-network routing,” in DOI 10.1016/j.comcom.2010.11.003.Zooloo, Z. (1201) ‘Trial and Error in Article Writing Using Chisel and Stone’, in Merlin W. (1399) Jumping Stones, 2011. [4] S. R. M. Zakhary, “Utilizing Social Links for Location Privacy in Opportunistic Delay-Tolerant Networks,” in Communications (ICC), 2012 IEEE International Conference, 2012. [5] K. Z. ,. B. V. G. A. Lilien, “Opportunistic Networks: The Concept and Research Challenges in Privacy and Security,” in Mobile and Wireless Network Security and Privacy, 2007. [6] A. Garcia and D. Valerdi, “D4.2. Protocols for infrastructure offloading control and coordination,” 2014. [7] P. B. L. H. T. S. E. F. J. R. M. M. Z. K. F. K. A. H. P. Papadimitratos, “Secure vehicular communication systems: Design and architecture,” in IEEE Commun. Mag, 2008. [8] C. R. F. B. R. B. C. M. G. P. A. D. A. M. D. Z. E. Vania, D3.1 - Initial Results on offloading foundations and enablers, FP7, 2013. [9] A. Leung, C. Mitchell and R. Holloway, “A service discovery threat model for ad hoc networks,” in Proceedings of the International Conference on Security and Criptography, Setubal, 2006.

D4.3 – Trust and security issues and solutions

WP 4 – Offloading Protocols and Algorithms

DISCLAIMER

The information in this document is provided "as is", and no guarantee or warranty is given that the information is fit for any particular purpose. The above referenced consortium members shall have no liability for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials subject to any liability which is mandatory due to applicable law. Copyright 2015 by Thales Communications & Security SA, Consiglio Nazionale delle Ricerche, Asociación de Empresas Tecnológicas Innovalia, Universite Pierre et Marie Curie - Paris 6, FON wireless ltd, Avea Iletisim Hizmetleri As, Centro Ricerche Fiat Scpa, Intecs Informatica e Tecnologia del Software s.p.a. All rights reserved.