Internet of things for Wireless and Mobile communication

internet of mobile things challenges and opportunities and internet of things capstone build a mobile surveillance system mobile agents for the internet of things
Dr.MohitBansal Profile Pic
Dr.MohitBansal,Canada,Teacher
Published Date:26-10-2017
Your Website URL(Optional)
Comment
A Policy-Based Approach for Informed Consent in Internet of ThingsAbstract Informed consent is an essential element of data protection for information and communication technology (ICT) systems as the consent of a data subject (e.g., the citizen) is often necessary for a third party to legitimately process personal data. To provide informed consent regarding the use of personal data, the citizen must have a clear understanding of how his/her personal data will be used by ICT applications. This may not be an easy task, especially for a citizen with a limited understanding of the complexities of ICT systems, as End User License Agreements (EULAs) are often either too complex or too generic to be easily understood. This issue is likely to become more critical in the Internet of Things (IoT) where the collection of personal data can happen in various ways, which are often not evident to the user. There is a need to define new models of informed consent that (a) address the different capabilities and features of the user of IoT systems and applications and (b) make the provision of informed consent easier. In this chapter, we describe an approach to informed consent founded on a policy- based framework whereby policies that are more suited to the complexities of IoT and that can be refined on the basis of the specific features of the user or categories of users can be used to implement EULAs or more sophisticated forms of informed consent. 19.1 Introduction The term informed consent originates in the medical community and describes the process for obtaining permission from a patient to perform a medical proce- dure on the basis that he/she has been fully informed about the benefits and risks of the procedure, and has agreed to the procedure being undertaken. Informed consent may only be given by patients who have adequate reasoning faculties and are aware and in possession of all relevant facts at the time the informed consent is given. The informed consent process has now been adopted to regulate the interac- tions of citizens within the digital world. From a legal perspective, the notionA Policy-Based Approach for Informed Consent in Internet of Things  523 of informed consent is essential for the data protection of information and communication technology (ICT) systems as the consent of a data subject (e.g., the citizen) is often necessary for a third party to legitimately process per- sonal data. Within the European Union, the data protection directive 1, which defines conditions under which personal data can be processed, specifies that the consent must be “freely given, specific and informed” and “unambiguous.” The foreseen evolution of this regulation 2 further strengthens this definition of consent by narrowing it to “explicit, clear affirmative action,” thus excluding the possibility of implicit content. To provide informed consent regarding the use of personal data, the citizen must have a clear understanding on how his/her personal data will be used by the ICT systems and applications. This may not be an easy task, especially for a citizen with a limited understanding of the complexities of ICT. On the other hand, informed consent must be collected before ICT applications can be used. This has led to the development of End User License Agreements (EULAs), which are often too complex or too generic for most users of ICT applications. The complexity and length (e.g., often tens of pages) of current instances of EULAs has developed a consent fatigue, whereby most users accept the licensing agreement by default, often without reading it 3. The generic nature of EULAs is evident in the fact that they are often the same for all users regardless of the user’s role or proficiency in the use of the ICT application. These issues notwithstanding, EULAs are generally used because there are no widely available alternatives. For the user then, the choice is between (a) not having access to the ICT application or (b) having some potential risks to his/her privacy in a distant and vague future. In recent times, point (b) has become less vague and more menacing as private photos and information are now routinely distributed to the public. In addition, EULAs are often static artifacts and are not related to a specific context or domain. For example, in many cases the EULA is the same regardless of whether the ICT application is used for personal or business reasons. More- over, EULAs are often not changed by the ICT application developers, even if the usage of personal data may change due to technology trends (e.g., cloud com- puting), or interaction with other applications. There is a need for a more sophisticated tool for informed consent, which would provide the following features at a minimum: 1. Support different types of users across the full spectrum of users in the digital divide (i.e., from the most ICT literate to the least) and/or support different user roles. 2. Be customizable so that the user can change settings if he/she wishes to within preestablished parameters, as defined by the regulations or the application developer. 3. Support different type of contexts or changes in the environment.524  Security and Privacy in Internet of Things (IoTs) Beyond the ICT domain, the issue of providing a tool for “informed con- sent” with these features is further complicated by the evolution of the IoT. The definition of EULAs for end users may be further complicated by the lim- ited processing capabilities of IoT devices, the distributed nature of the IoT, and the integration of the digital with the real world. The numbers of potential data operations in a fully deployed IoT make the adoption of EULA less practical. In addition, the nature of the informed consent required would vary depending on the data provided by the IoT device and the related data flow. In other words, IoT device manufacturers should provide more decentralized control over the processing of personal data in the new data-driven environment IoT so that users could gain a better understanding of what data of theirs is col- lected and how it is used. This should be reflected in the definition of a new approach to providing informed consent in the IoT. In this chapter, we propose a new approach and the related tools to support the features and challenges identified earlier. The approach is based on the definition, deployment, and adoption of policies through a policy-based framework. The policies consist of authorizations and obligations specified as Event- Condition-Action (ECA) enforcement rules. These rules use as a reference a set of interrelated design models representing different aspects of the IoT system and the related data flows. The policy framework consists of a collection of metamodels for the specifi- cation of a computer system structure, information, behavior, context, identities, organizational roles, and security rules. The policy framework adopts a generic design language to represent the architecture of a distributed system across appli- cation domains and levels of abstraction, including the refinement of relations inspired in the Interaction System Design Language (ISDL) 4. As described in the rest of the chapter, sets of policies can be used to define profiles for informed consent. The policy framework provides the flexibility to adapt the informed consent definition for different types of users and different types of IoT contexts or conditions. This chapter is organized as follows: Section 19.2 provides an analysis of the issues and challenges in implementing an effective informed consent process in the Internet of Things. Section 19.3 provides an overview of the current results from the research domain on the potential approaches for Informed Consent with a specific focus on the IoT. Section 19.4 describes the design of the informed consent based on the policy-based framework. The system describes the generic framework and how it can be applied to provide informed consent in the IoT systems and devices. Finally, Section 19.5 concludes the book. 19.2 Problems Defining Informed Consent in the Internet of Things Informed consent is a term which originates in the medical research community and describes the process by which a person—such as a patient or a participantA Policy-Based Approach for Informed Consent in Internet of Things  525 in a research study—has been fully informed about the benefits and risks of a medical procedure and has agreed on the medical procedure being undertaken on them. Informed consent should be given based on a clear appreciation and understanding of the facts, implications, and future consequences of the action of providing the consent. In order to give informed consent, the individual con- cerned must have adequate capabilities and be in possession of all relevant infor- mation at the time that the informed consent is given. From a legal perspective, the notion of consent is essential in data protection as the consent of a data subject is often necessary for a third party to legitimately process personal data. Within the European Union, the data protection direc- tive 3, which defines conditions under which personal data can be processed, specifies that the consent must be “freely given, specific and informed” and “unambiguous.” The foreseen evolution of this regulation 4 further strengthens this definition of consent by narrowing it to “explicit, clear affirmative action” excluding the possibility of implicit content. In Europe, the Article 29 Working Party issued an opinion on privacy issues with regard to mobile applications 5, which could also be extended to the future development of the IoT. The Working Party provided specific suggestions to the industry players (e.g., application developers, application stores, application and service providers, manufacturers of mobile devices). The suggestions included the provision of tools for free, specific, informed consent, a “readable, under- standable and easily accessible” privacy policy. The Article 29 Working Party emphasized that the notice should be provided “at the point in time when it mat- ters to consumers, just prior to the collection of such information by applications.” It required that the initial notice contain the minimum information required by the EU legal framework, and that further information be made available through links to the whole privacy policy. The Working Party also defined the minimum information that should be included: (a) identity and contact details (b) precise categories of data to be processed by the application which requires the informed consent (c) information as to whether the data would be disclosed to third parties, and (d) the rights of users in terms of withdrawal of consent and deletion of data. The Working Party’s analysis identified the following areas to be addressed by a new approach to informed consent:  Lack of control and information asymmetry. As mentioned earlier in this chapter, the large amount of data generated by IoT systems and devices can be difficult to control using conventional systems. In other words, the generation of data flows can hardly be managed with the classical tools used to ensure the adequate protection of the data subjects’ interests and rights.  Quality of the user’s consent. Users may not be aware of the data pro- cessing carried out by specific objects. They also may not know precisely when and if an object is connected or not.526  Security and Privacy in Internet of Things (IoTs)  Inferences derived from data and repurposing of original processing. Modern analytical techniques can cross-correlate data from different sources to extract information that may point to personal data, even if the single data flows do not include personal data.  Security risks: security versus efficiency. As pointed out before in this chapter, there is a trade-off between the need to design and implement confidentiality, integrity, and availability measures and the need to opti- mize the use of computational resources—and energy—by objects and sensors. Ensuring this level of “informed consent” can already be an issue in itself for traditional ICT applications, while the technical and legal complexity of the prob- lem can be an obstacle to informing potential end users. This has led to the devel- opment of so-called End User License Agreements (EULAs). A EULA is usually presented as a text box in an ICT application, containing a large amount of legal text, with a scroll function to enable reading of the entire document. The text box has a process (e.g., a check box) that requires the approval of the EULA by the user on the basis that the user has read and understood the content of the EULA. If the response is positive, the ICT application grants access to the requested ser- vices. There are various problems with EULAs, when they are applied to ICT and in extension to the IoT domain. The set of issues includes 1. The EULA text is the same for all users. There is no effort to tailor the text of the EULA to specific categories of users or a specific context (e.g., home or office). From one point of view this is understandable, as the legal framework which generates the EULA is usually generic. Still, informed consent and the treatment of personal data in ICT are slightly different from the healthcare domain where the informed consent concept origi- nated. 2. The EULA text is usually very long and complex and often difficult for the generic user to read and understand. Therefore, there is the risk that the condition identified earlier, that “a clear appreciation and understanding of the facts, implications, and future consequences of the action,” is not satisfied. In the IoT, informed consent is even more complex than in ICT systems because the following challenges may also arise: 1. The “things” collecting data, may not be fully evident as this data could be embedded in other devices. For example, future wearable sensors for healthcare could collect and transmit information for healthcare purposes that the user is not aware of. 2. The difficulty in requesting informed consent because of the lack of iden- tifiable places and times to implement consent mechanisms (e.g., whenA Policy-Based Approach for Informed Consent in Internet of Things  527 a driver uses an intelligent car, which provides information to a remote server). 3. The difficulty in opting out for specific services. It may be difficult to understand when and how the user can opt out from some services, and maintain the consent from other services, if an IoT device supports various applications. 4. While the informed consent for a specific ICT application in a defined place or context (e.g., at home) could be relatively easy to obtain, a change in the context (e.g., from home to office, or if a person’s role changes) may require a new informed consent but this may not be easy to achieve in the current situation. In addition, the collection and processing of data by the IoT can be more com- plex and pervasive than the current model of a specific website or application, whereby the human–computer interface (HCI) is well defined and specific to the Web portal or the HCI application. Data can be collected and distributed from a variety of IoT devices, which can be used by the individual at the same time and place. For example, an individual may wear a wearable device for health- care, may use a mobile phone or drive a connected vehicle all at the same time. In addition, all of these devices may independently transmit to external servers or remote applications. In this situation, there would also be different interfaces, data collections points, and data flows for the personal data of the individual. Even if the informed consent is provided separately for each specific device or application, remote analytical tools could be used to exploit the combination of collected and processed data to identify correlated information, which could impact on the privacy of the individual. For example, even if the position of a car is obfuscated by decreasing the accuracy of information obtained from a GNSS system, other events (e.g., road charging or the position from a cellular base station) could be used to pinpoint the position of the individual in a more accurate way. This example shows that there is the need for a more sophisticated process for informed consent, which addresses the increased complexity of IoT. We propose a policy-based framework to address this complexity and the issues presented above. 19.3 State of Art 19.3.1 Dynamic and context-aware approach To face the dynamic and distributed nature of the IoT, it has been proposed to take into account the context in which an application operates to influence the authorization 6 and disclosure of information 7. In particular, 6 addresses the problem of highly dynamic environments where standard access control may528  Security and Privacy in Internet of Things (IoTs) not work in an effective way, as authorization is most often static or controlled by applications, which can lead to users being considered authorized even after a change of the context. With context changes, we cannot assume that a user is authorized for the duration of their use of an application, even if that user is still authenticated. This paper then proposes an approach based on dynamic autho- rization, which could also be used for informed consent, even though authoriza- tion is only one of the features. In a similar way, 7 presents an approach called the Dynamic Disclosure-Control Method (DDCM), which offers protection of location privacy through an agent. The agent provides a location privacy method that adapts to variations in contexts by using an efficient context analysis pro- cess. In addition, this method takes into consideration the privacy preferences of the users and the object operators. The approach proposed in this paper is based on these existing trends toward dynamic and context-aware disclosure of information. 19.3.2 Semiautonomous agent The use of a user-centric, semiautonomous agent to negotiate the consent of the user with third-party applications, based on user-defined rules and preferences, has been discussed in 8. This approach has the advantage of keeping the end user in control (by clearly defining the rules) while allowing for the scaling up to a large number of data authorization operations (matching the needs of a fully deployed IoT). However, the scope of the privacy coach proposed in 8 was limited to a single technology (RFID) and did not take into account any context information. 19.3.3 Reputation systems A complementary and promising approach to further increase end-user informa- tion on privacy and data protection in IoT would be to rely on reputation systems. Initial examples of reputation-based systems for trustworthy communications are provided in 9,10. We propose to extend and generalize them to both become visible to end users and integrate user feedback and perceptions on IoT applications’ respect for privacy. Such ranking could not only provide information for end users but also be taken into account in the semiautomatic selection of which nodes are trustworthy for information sharing. 19.3.4 Behavior modeling Advanced techniques have been developed to model and analyze the behav- ior of humans and their interactions with each other and with ICT technolo- gies, as presented in 11–13. These models can be used to create user adaptiveA Policy-Based Approach for Informed Consent in Internet of Things  529 systems as in 14, which describe services tuned to the individual preferences of the users. Although this profiling can in itself lead to privacy issues, we argue that it could, with the necessary safeguards 15, be used to better understand individ- ual user privacy requirements. We propose here to use profiling to automatically propose data operation authorization decisions to the user that match his/her pre- vious decisions. 19.3.5 Analysis of the EULA The use of standardized license agreements can be made available in three dif- ferent but coherent version: full legal text (enforceable legal text), simplified text (short and understandable by most user), and machine-readable versions (enabling automated processing). All these forms have been experimented with some degree of success in the copyright domain, as described in 16. In this section, we describe new technologies and tools for improving the basic EULA model. A very good analysis on this topic is provided in 17, where various technologies are identified. An example is the EULAlyzer 18, which analyzes the text of the EULA and tries to identify words that could hint to a spe- cific use of the personal data (e.g., advertising or mobile commerce). The tool then notifies the user about these words and shows the context (e.g., the portion of the EULA text) where the words have been identified. In this way, the user is alerted to the potential misuse of their personal data by the application. The EULAlyzer is a good example of a category of tools that analyze EULAs and aim to protect the user from misuse by web applications. A potential issue with this category of tools is that the web application can modify the EULA against the analyzer and obfuscate the use of personal data using other words or a spe- cific jargon. Another potential issue of this category of tools is that it does not address some of the basic challenges of the EULA described in the introduction, regarding the customization of the informed consent for different classes of users when the EULA is still the same for all users. As outlined earlier in this chapter, EULAs have too many limitations for IoT. 19.4 Overview of the System The policy-based approach that we propose in this paper builds on and com- bines these different trends to offer a solution to the informed consent problem in the IoT. As described in Figure 19.1, the system is user-centric. A graphic user inter- face enables the user to define a set of rules embedded in policies that should be both simple enough for the user to comprehend and complex enough to enable advanced users to fine-tune them if necessary. The user can also define530  Security and Privacy in Internet of Things (IoTs) Rank applications and Ensure policy third parties... enforcement Context IoT system Community Policy based system - Defines basic rules - Can fine tune if necessary Policy management Evaluates: - Defines when/how to be GUI - User defined rules prompted - User habits/behaviors - Operation context - Application reputation Authorize data operations e user notify the user Figure 19.1: Overview of the system. how and when to be contacted by the system and notified about a change in the context. The policy-based system is a semiautonomous agent in itself, whose main role is to authorize or deny data operations on behalf of the user. In making each decision, the agent evaluates the rules/policies defined and chosen by the user but also takes into account context elements, and eventually information relating to user behavior and the reputations of third parties. To handle the reputation system, the user is able to participate in communities which evaluate and rank IoT applications and third parties (e.g., service providers and application developers). To ensure the policy enforcement, the whole system is built on an IoT plat- form that embeds policy enforcement components and the policy framework, as described in the rest of this chapter. To be implemented successfully, the system must address the following requirements: 1. Support different types of users across the full spectrum of users in the digital divide (i.e., from the most ICT literate to the less) and/or the dif- ferent roles. This includes the necessity of providing the user with easily understood information in a simple GUI, and also the setup of mechanisms to train and motivate the user to define policies (i.e., to ensure regular use of the system). 2. Be customizable so that the user can change settings if he/she wishes. One of the challenges of customization is to adapt the GUI to follow the user proficiency.A Policy-Based Approach for Informed Consent in Internet of Things  531 3. Support different type of contexts or changes in the IoT environment and ensuring the enforcement of the policies chosen by the user. A description on how the proposed policy-based framework is able to address these challenges is provided in Section 19.4.1. 19.4.1 Policy-based framework We propose to use the Model-based Security Toolkit (SecKit) for the specifi- cation and enforcement of informed consent rules 19. The SecKit includes a collection of metamodels, runtime components, and technology-specific Policy Enforcement Points (PEPs) that are used as the foundation for the security engi- neering process. Models in the SecKit are specified to represent the IoT system data, identities, behavior, structure, context, roles, trust relationships, threat sce- narios for risk analysis, and security policy rules as reactive or preventive security countermeasures for the identified threats. From a methodology point of view, the first step for the specification of pol- icy rules is to model the target IoT system, which is done in the SecKit using a generic design language to represent the architecture of a distributed sys- tem across application domains and levels of abstraction. The system design is divided into two domains named entity domain and behavior domain, with an assignment relationship between entities and behaviors. In the entity domain the designer specifies the entities and interaction points between entities representing communication mechanisms. In the behavior domain the behavior of each entity is detailed including actions, interactions, causality relations, data, and identity information attributes. Activities in the behavior domain may handle user data or identities. For example, an IoT weather station may provide the current indoor home temperature (data) of a specific person (identity). The second step is to specify the supporting models necessary, depending on the security requirements including business roles, context information and/or situations, and trust relationships. The context model specifies types of Con- text Information and Context Situations. Context Information is a simple type of information about an entity that is acquired at a particular moment in time, and Context Situations are a complex type that models a specific condition that begins and finishes at specific moments in time 20. For example, the “GPS loca- tion” is a Context Information type, while “at home” and “at work” are examples of context situations where a person or employee (target entity) is at their home or work environment. The person that is at home or at work is assigned a role in that specific situation. The results of the context situation monitoring are events generated when the situation begins and ends. These events contain references to the entities that par- ticipate in the situation and can be used to support the specification of the policy rules. Policy rules can be specified to represent authorizations to be granted when a situation begins and data protection obligations that should be fulfilled when532  Security and Privacy in Internet of Things (IoTs) the situation ends. For example, access to the patient data can be allowed when an emergency situation starts with the obligation that all data is deleted when the emergency ends. For example, a security policy may be specified to allow access to data when the situation starts and to trigger the deletion of the data when the situation ends. Existing policy language standards like XACML 21 only support the specification of context as attributes and of textual obligations to be fulfilled when the access to data is granted and not in the future. The security policies have to be disseminated to the device(s) that are gath- ering the data under consideration in a secure way. Depending on the security policy, the device has to trigger and apply the appropriate mechanism for trans- mitting the data in the exact format needed by the application. This includes a two-step process: first the device has to map the policies for the application to specific data-gathering policies, and second, it should identify the encryption/ security level of the data to identify the proper transmission mechanisms, consid- ering also the energy efficiency requirements of the devices (i.e., using an adap- tive encryption scheme). For example, in a traffic-monitoring scenario, users in cars may be sending information regarding traffic in an application server. The application should know only how much traffic there is at every street segment. The users’ phone has the ability to send various types of traffic-related data, that is, the exact location every second, speed every second, direction of movement, etc. If the application wants to estimate the traffic, the related policies should be considered by the devices of the users, so that only an average speed per time period and street segment is sent, in order to avoid disclosing the exact location of the user at each point of time (ensuring privacy by design). Actually, interme- diate nodes (i.e., the gateway) should also consider these policies and send to the application server only aggregated/average data so that the location of the users will be hidden from the application point of view. Other applications that need to know the exact location of the user (depending on their access control policies) will indeed be identified as such by the devices, which will transmit the exact location (i.e., for a person to track his car if it is stolen). The security rules model consists of the security rule templates (aka policy rules) specified to be enforced and the configuration rules for these templates. The security rule templates are Event-Condition-Action rules, with the Action part being an enforcement action of Allowing, Denying, Modifying, or Delaying a service or data in the IoT device or system. Furthermore, the Action part may also trigger the execution of additional actions to be enforced, or specify trust management policies to increase/decrease the trust evidence for a specific trust aspect. For the purposes of informed consent, we also support the execution of an Ask for User Consent abstract activity, which may be instantiated differently depending on the current user situation (busy, available, in a meeting, etc.) and the previously specified user preferences. From an informed consent perspective, users have two alternatives: (1) to specify a priori the consent rules to allow,A Policy-Based Approach for Informed Consent in Internet of Things  533 deny, modify, or delay an activity or (2), to specify rules that declare when the users should be explicitly asked for consent in an interactive way. Considering the second alternative our policy language is very expressive and allows users to specify temporal and cardinality constraints for the informed consent rules, for example, that consent should be explicitly asked once per hour, or once per day, if the data access requests are not more than 10 per day. The security rule semantics is based on temporal logic and is evaluated using a configurable discrete time-step window of observed events, for exam- ple, 30 s. Details about the security rule model are described in previously pub- lished research papers 19. Examples of security policy rules are provided for our scenario implementation in the following section. From an architectural perspective, policy rules representing users’ informed consent requirements can be exchanged between administrative domains that collaborate in an IoT scenario. For example, when a smart device exchanges data with a user mobile phone, the smart device can exchange the informed con- sent policies that regulate the authorizations and obligations associated to the exchanged data that should be enforced by the mobile phone. This delegation of sticky flow policies must be supported by trust management mechanisms in order to guarantee or increase the level of assurance with respect to the enforcement of the policy rules by the mobile phone. 19.4.2 Enforcement In this section, we show how the SecKit is applied to an IoT architecture already defined in the FP7 iCore project and based on the concept of Virtual Objects and Composite Virtual Objects to represent IoT devices and IoT systems and applications. The architecture is described in 22 and the main concepts of the architecture are described here. The main concept of the iCore project is to enable each IoT node with mul- tiple functionalities based on its capability. For this, three key communication abstraction layers are identified, besides the necessary connectivity layers such as PHY, MAC and Network layers. They are (a) Virtual Object (VO) layer, (b) Composite Virtual Object (CVO) layer, and (c) Service layer. VO abstrac- tion is applied to each node/device, which makes it easy to reuse the IoT devices. Figure 19.2 is a pictorial description of the architecture. For example, the ambient light control in a smart building could indeed use the projector VO to realize that there is a movie or slide projected in a particular room and therefore lights can be turned off. The idea is to reuse IoT devices in multiple applications. The CVO layer enables the IoT devices to interact with other devices, and can mashup multiple VOs to offer smart applications. For example, a smart home has strict requirements regarding energy reduction, light control, climate control, and security. By combining multiple VOs, these534  Security and Privacy in Internet of Things (IoTs) Application Sub- Service Service Service layer tasking analyzer generation Approximation Observation CVO layer Coordination Optimization Discovery Translation VO layer Heterogeneous networks, devices, systems Physical and communication layer Figure 19.2: FP7 iCore architecture. requirements could be served. At the service layer, multiple application require- ments can be addressed. Going along with the previous example, the service layer enables an ambient light control application to use information from the projector by querying IoT devices (or services) in the vicinity, learning from the obtained information, and making intelligent decisions. Of course, this also requires semantic interoperability on all respective layers. Figure 19.1 shows the SecKit enforcement components. In our enforcement architecture, the IoT Framework and platform are monitored by a technology- specific Policy Enforcement Point (PEP), which observes and intercepts service, CVO, and VO invocations, taking into account event subscriptions of a Policy Decision Point (PDP). The PEP component signals these events to the PDP, and receives enforcement actions in case a tentative event is signaled. If required for policy evaluation the PDP may implement custom actions to retrieve status information of VOs and CVOs and subscribe to context information and situation events with the Context Manager component, both using existing functionality provided by the IoT Framework. In order to concrete implementation scenarios, the SecKit must be extended with technology-specific runtime monitoring components. In the iCore project, we provide one extension to support monitoring and enforcement of policies through a MQTT broker, which is the technology adopted by most of the project partners to support communication between VOs, and CVOs. The SecKit may be used in a hospital scenario where VOs and CVOs represent the staff and medical devices being used that communicate using a MQTT middleware. Policies are IoT daemon Security management Any available PHY An IoT node middleware space access technologiesA Policy-Based Approach for Informed Consent in Internet of Things  535 specified to control access to the hospital staff information (e.g., location) and to control the access to medical devices represented as VOs. 19.4.3 Application of the SecKit framework to internet of things for informed consent Figure 19.3 shows the design of the IoT system behavior and the Consent Man- ager behavior type, which instantiates the action type Ask For User Consent. This action represents an abstract activity that interacts with the user and requests the consent for a specific operation. Interactive consent policy rules instantiate this behavior type to request the user consent. Figure 19.4 shows the design of context information and situation types. In this figure we highlight the context situation Working, which models a person that is currently performing this activity. Figure 19.5 shows the approach we adopt for specification of trust beliefs that are used in the policy rule language. Trust relationships are specified for a spe- cific trust aspect, for example, to enforce privacy preferences, and a trust value is assigned to a specific entity for this aspect. In this example, the European Com- mission Joint Research Center (JRC) is considered to be very trustworthy for the aspect. The measurement of trust beliefs is implemented using the Subjective Logic opinion triangle, which assigns belief, disbelief, and uncertainty values to an opinion. A complete description of the approach adopted by us is already provided in 23. Figure 19.6 shows a sample interactive consent policy rule template. In this rule, whenever an access to user data is detected by an event, and the relevant IoT System Services, Context Context CVOs, and VOs monitoring manager Execute Containers behavior Context information and situation events Policy Enforcement (subscribe/notify) Point (PEP) Actual or tentative event Enforcement behavior (subscribe/notify) (allow, deny, modify, or delay) Policy decision Retrieve Role Check role point (PDP) policies assignments manager Notify policy updates Update role assignments Save Policy Update Policy management Policy policy server (PS) policies GUI repository (PR) Figure 19.3: IoT system behavior model.536  Security and Privacy in Internet of Things (IoTs) Figure 19.4: Context model. Figure 19.5: Visualization of trust beliefs and reputation values.A Policy-Based Approach for Informed Consent in Internet of Things  537 Figure 19.6: Interactive informed consent rule. person is currently not working, a consent manager is instantiated to interac- tively request consent to allow, deny, modify, or delay the data being access. We illustrate the specification also for a variable in this rule template, to represent the specific person for whom the template should be instantiated and enforced. Variables can be also used to parameterize the event being considered and to specify generic consent rules that apply for all activities of a particular subtype. For example, a set of rules could be specified to all access to personal informa- tion, access to photos, and so on. Figure 19.7 illustrates an informed consent rule template that is defined a priori by users and allows all data access but anonymizes the identity of the users. By anonymization in this context, we mean simply replacing the identity attribute by the string anonymous. Depending on the specific requirements, anonymiza- tion could also include the replacement/modification by a service specific user pseudonym. Figure 19.8 illustrates a policy rule that allows any operation to be performed by trustworthy entities. This rule is generic and does not specify in the event part the specific activity that should be allowed, for example, any data access538  Security and Privacy in Internet of Things (IoTs) Figure 19.7: Off-line informed consent anonymization rule. Figure 19.8: General-purpose trust-based access rule. request would be allowed. This type of generic rule allows more generality in the specification of policy rules. Figure 19.9 illustrates a policy rule template that allows access in the case of a specific user identified by a variable who has given consent (result = true) in the previous n time steps. It is up to each user that instantiates this template to specify how often the system should require his consent, for example, every dayA Policy-Based Approach for Informed Consent in Internet of Things  539 Figure 19.9: Consent check rule. Figure 19.10: Composite rule with combining algorithm conflict resolution. or every hour. An additional variable could be specified in this rule template to identify the specific activity where consent is required more often than for others. Figure 19.10 shows a policy rule template that instantiates the previously described policy rules in a more complex template, which demonstrates the con- flict resolution approach we adopt in our policy rule language. In this example, access is denied by default to all untrustworthy entities that try to access user540  Security and Privacy in Internet of Things (IoTs) data. However, in case a trustworthy entity tries to access the data or if con- sent was explicitly given by the user in the previous n time steps, the access is allowed. The strategy for the combining algorithm adopted here is named Allow overrides, meaning that if any of the nested rules allows the access, this is the final result chosen by the container rule template. 19.5 Conclusion and Future Developments In this paper we introduced a novel approach to handle the authorization of data operation in the IoT, by combining a number of previously introduced different approaches, to produce a semiautonomous, rule based agent, which integrates context-awareness and enforcement through the “SecKit” mechanisms. We believe that such an approach can significantly improve the way the informed consent question is handled. The definition of rule can be very specific (taking into account the type of data, type of operation, identity of the third party requesting the data operation and context of the operation) enabling detailed con- trol by the end user. Further developments can now be envisioned to further refine the system and increase its impact on the informed consent of IoT end users: (a) providing information, training, and motivation of the user and (b) facilitat- ing the definition of rules and policy implementation, which are described next. 19.5.1 Information, training, and motivation of the user To actually achieve the “informed consent” of data operations by a large number of end users, some of which have low digital literacy, the ability to define data policy rules and strongly customize their application to the context of their use is not by itself sufficient. Dedicated efforts are needed to ensure that the policy- based system helps to inform, train, and motivate the user to actually care about his privacy and to define policies. Thus, the following additions to the system have to be considered:  The development and embedding of contextual help mechanisms in the Policy Management GUI to inform the user about the behavior of the system and the potential impacts of his decisions.  Progressive complexity of the user interface: one option could be to have different levels of complexity in the Policy Management GUI to accom- modate users from beginner (that need a simple GUI to start defining pol- icy rules) to expert levels (who need to be able to define complex custom rules). Tutorials can be created to help train the user in defining their first rules and to present the challenges of data protection in the IoT context.

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.