DELIVERABLE - SECUREIoT Project D4.9... · 2019-09-22 · Version: v1.0 - Final, Date 30/11/2018...

This document is part of a project that has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 779899. It is the property of the SecureIoT consortium and shall not be distributed or reproduced without the formal approval of the SecureIoT Management Committee. The content of this report reflects only the authors’ view. The Innovation and Networks Executive Agency (INEA) is not responsible for any use that may be made of the information it contains.

Project Acronym: SecureIoT

Grant Agreement number: 779899 (H2020-IoT03-2017 - RIA)

Project Full Title: Predictive Security for IoT Platforms and Networks of Smart

Objects

DELIVERABLE

Deliverable Number D4.9 Deliverable Name Models and Annotation for Security-Aware

IoT Programming – First version Dissemination level Public

Type of Document Report

Contractual date of delivery 30/11/2018

Deliverable Leader UBITECH

Status & version Final-v1.0

WP / Task responsible WP4 (INRIA) / Task T4.4 (UBI)

Keywords: model; annotation; security-aware; access control

Abstract (few lines): The aim of the deliverable is to define the prototype

implementation of a context-base model and annotations-

oriented programming approach. This deliverable will serve

as a basis for supporting secure IoT programming. Policy

models and their description in XACML will also considered.

Deliverable Leader: UBI

Contributors: Sofianna Menesidou (UBI)

Reviewers: Jürgen Neises (FUJITSU), Daniel Calvo (ATOS)

Approved by: Stylianos Georgoulas (INTRA)

Project Title: SecureIoT Contract No. 779899 Project Coordinator: INTRASOFT International S.A.

D4.9 - Models and Annotation for Security-Aware IoT Programming,

Version: v1.0 - Final, Date 30/11/2018

Executive Summary This deliverable D4.9 reflects the outcomes of T4.4 and provides the basis for supporting secure

IoT programming by specifying a set of models and annotations in-line with the SecureIoT

architecture. More specifically, it incorporates the notions of context and context-awareness in

security policies focused on access control. The use of contextual information enables data

owners, application operators and/or administrators to apply security policies by mainly

considering the circumstances under which access requests to sensitive data, should be granted

or not.

This deliverable focuses on providing a re-usable and generic context-aware security model to

support developers to secure their IoT applications. This context-aware security model should

provide, through an appropriate vocabulary, all the facets, which must be available to the policy

model of the Developers Support Service. In addition, a first information regarding the usage of

annotations in modern programming languages such as Java and Python is also provided.

Deliverable D4.9 presents the first version of the Models and Annotation for Security-Aware IoT

Programming. The interim and final version will be delivered later in D4.10 and D4.11

respectively.




Document History

Version Date Contributor(s) Description

V0.1 24/05/2018 Sofianna Menesidou

(UBI) Initial Structure


(UBI) Updated Structure


(UBI) Updated Structure


(UBI)

Updated Structure, Input on Introduction

and State of the Art and Key Technology

Axes


(UBI)

Input on section SecureIoT Security

Models and Annotations for the

Programming Support Service


(UBI)

Input on SecureIoT Requirements and

Architecture


(UBI)

Input on SecureIoT Requirements and

Architecture


(UBI) Conclusions


(UBI)

Various improvements based on internal

review comments


(UBI) Final version to be submitted




Table of Contents Executive Summary ......................................................................................................................... 2

Definitions, Acronyms and Abbreviations ...................................................................................... 7

1 Introduction ............................................................................................................................. 8

1.1 Scope and Purpose.......................................................................................................... 8

1.2 Background and Vision ................................................................................................... 8

1.3 Document Structure ....................................................................................................... 9

1.4 Relation with other deliverables ................................................................................... 10

2 State of the Art and Key Technology Axes ............................................................................ 11

2.1 Policy Models ................................................................................................................ 11

2.1.1 Context-aware Models ................................................................................................. 11

2.1.2 Policy Modeling through Annotations .......................................................................... 13

2.2 Security Policy Models .................................................................................................. 14

2.2.1 Context-aware Security Models ............................................................................... 17

2.2.2 Security Policy Enforcement ..................................................................................... 18

3 SecureIoT Security Models and Annotations for the Programming Support Service ........... 21

3.1 Context-aware Security Model ..................................................................................... 21

3.2 XACML 3.0 in the frame of SecureIoT ........................................................................... 27

3.3 Source Code Annotations ............................................................................................. 30

4 Mapping with SecureIoT Requirements and Architecture .................................................... 34

4.1 SecureIoT Stakeholders’ Requirements ........................................................................ 34

4.2 SecureIoT Architecture ................................................................................................. 35

5 Conclusions ............................................................................................................................ 37

References .................................................................................................................................... 38




Table of Figures FIGURE 1: RELATION WITH OTHER DELIVERABLES .................................................................................................................... 10 FIGURE 2: ABAC INDICATIVE INFORMATION FLOW ................................................................................................................. 22 FIGURE 3: CONTEXT-AWARE SECURITY META-MODEL ............................................................................................................ 24 FIGURE 4: PART OF SECURITY CONTEXT ELEMENT OVERVIEW DIAGRAM ...................................................................................... 27 FIGURE 5: XACML DATA-FLOW DIAGRAM [XACML] ................................................................................................................ 29 FIGURE 6: USAGE OF XML ARTEFACTS [XACML] ..................................................................................................................... 30 FIGURE 7: MAPPING WITH SECUREIOT ARCHITECTURE ............................................................................................................ 36




List of Tables TABLE 1 - LEGEND OF THE OVERVIEW DIAGRAMS .................................................................................................................... 25 TABLE 2: @SECUREIOTPEP ANNOTATION IN JAVA ................................................................................................................. 31 TABLE 3: ANNOTATION USAGE EXAMPLE IN JAVA .................................................................................................................... 32 TABLE 4: DECORATION USAGE EXAMPLE IN PYTHON ................................................................................................................ 32




Definitions, Acronyms and Abbreviations Acronym Title

ABAC Attribute Based Access Control

DAO Data Access Objects

CAAC Context-aware Access Control

CBAC Context-based Access Control

CSAC Context-sensitive Access Control

DAC Discretionary Access Control

IDS Intrusion detection systems

IoT Internet of Things

LAAC Location-aware Access Control

MAC Mandatory Access Control

NGAC Next Generation Access Control

ORM Object-Role Modeling

PAP Policy Administration Point

PEP Policy Enforcement Point

PDP Policy Decision Point

PIP Policy Information Point

RBAC Role‐Based Access Control

SGML Standard Generic Markup Language

SECaaS Security as a Service

TPM Trusted Platform Module

UML Unified Modeling Language

WP Work Package

W3C World Wide Web Consortium

XSD XML Schema Definition

XACML eXtensible Access Control Markup Language




1 Introduction 1.1 Scope and Purpose The scope of this deliverable is to provide the foundation for supporting secure IoT

programming based on annotations. It will consider the policy models introduced in D2.3 of the

project and their description in eXtensible Access Control Markup Language (XACML).

Accordingly, it will specify annotations supporting their deployment and enforcements across

various policy enforcement points (device, edge/fog, core/cloud) in-line with the SecureIoT

architecture. The outcomes of the task will serve as a basis for supporting developers to secure

Internet of Things (IoT) programming in WP5.

1.2 Background and Vision The idea behind the concept of Security by Design is that prevention is better than cure.

Prevention is a widely used security strategy in order to alleviate the security risks. For that

reason, we have first to focus and assist IoT application developers in defining effective context-

aware security controls for the sensitive data of IoT applications. This deliverable will include

capabilities for guiding IoT application developers through the process of defining policy

enforcement points for access control. In order to provide such capabilities, we will focus on

both

a) the appropriate access control scheme and

b) the knowledge that lurks behind such a scheme.

To this end, the appropriate access control scheme should consider the inherently dynamic and

heterogeneous nature of IoT environments. This characteristic calls for the incorporation of the

notion of context in access control policies. Dynamically changing contextual attributes that

may characterise data accesses should also be considered. The use of contextual information

will enable the ability to application operators or IoT administrators to apply access control

policies considering the circumstances under which access requests to sensitive data occurred.

This characteristic involves the development of a re-usable and generic context-based model

that will further elaborated later in this deliverable.

In addition, it will capture the relevant information that lurks behind such as actions occurred,

subjects’ attributes, locations, object attributes, environmental attributes, attestation

properties etc. This knowledge, as already pointed out, should be generic, easily adapted and

also extensible in order to support the particular needs of different, dynamic and

heterogeneous IoT applications.

The IoT has gained much popularity in the past few years due to integration of several devices

such as smartphones, tablets, sensors etc. into the Internet [habib2015]. The IoT envisions an

interoperable environment in which all the IoT devices are networked together and are actively




tracking the changes of their surroundings. The contextual information can be tracked through

various deployed probes on edge devices, in order to provide information regarding the device

the status, the user’s behavior, and even the environmental information. Such data, provided

by the deployed probes, are referred to as the contextual data, since they contain information

about the context in which each entity, user or subject is located. Again, the contextual

information can be considered dynamic, due to the dynamic nature of the underlying IoT

networks. According to [habib2015] typical contextual information can be about user’s location

and behavior, current time, state of system resources, and state of network and security

configurations.

SecureIoT application developers will use a context-aware security model, in order to indicate,

using annotations on web endpoints, access control to data managed by their applications. All

the contextual-based knowledge as well as the data sensitivity should be considered before

granting or denying a data access request.

Our vision in terms of SecureIoT is to provide an approach based on “Security by Design” and

“Secure by Default” principles.

• “Security by Design” is an approach to information security which, like Privacy by

Design, is at once holistic, creative, anticipatory, interdisciplinary, robust, accountable

and embedded into IoT systems [ann2013].

• “Secure by Default” is a concept that covers policies for implementing security controls

and specific methods for installing and configuring software [ann2013]. In the broader

policy-driven view, “Secure by Default” requires that access to information, systems and

applications be limited to just the data and functionality that are needed for a task.

1.3 Document Structure This document consists of the following chapters:

Chapter 1 introduces briefly scope and purpose of the "Models and Annotation for Security-

Aware IoT Programming ", the background and the vision. The relation with other deliverables

is also provided.

Chapter 2 gives an overview of the existing approaches towards context awareness and policy

modelling and enforcement. To this end, the most relevant state-of-the-art is presented, not

only research-wise, but also approaches that have been adopted by the industry. Furthermore,

research decisions and strategies that can affect the overall design of the architecture and its

higher-level structures are thoroughly discussed.

Chapter 3 provides an overview of the supported models and annotations in the programming

support service and their representation in XACML.




Chapter 4 presents the mapping between the policy models and annotations and the SecureIoT

requirements introduced in D2.2 and the SecureIoT architecture of the D2.4.

Chapter 5 concludes the deliverable by highlighting the most crucial parts of the deliverable.

1.4 Relation with other deliverables Deliverable D4.9 is the first version of Models and Annotation for Security-Aware IoT

Programming, delivered in month eleven (M11) of the project. The interim version will be

available on M19 in D4.10, while the final version will be available on M27 in D4.11. Figure 1,

depicts the relation of D4.9 with other deliverables in its pathway towards to D4.10 and D4.11.

D2.2 presents the stakeholders’ requirements, D2.3 specifies a set of IoT security, privacy and

data protection models that are used to comply with various policies in the context of multi-

platform interactions while D2.4 is the SecureIoT architecture. All three aforementioned

deliverables will serve as a basis for this D4.9 deliverable. The implementation of the

programming support security as a service (SECaaS) of WP5 and specifically the deliverables

D5.7, D5.8 and D5.9 will be based on the provided models and annotations of this WP4

deliverables.

Figure 1: Relation with other deliverables




2 State of the Art and Key Technology Axes In this chapter, we discuss the notion of context in access control systems and the significance

of security policy modelling. Specifically, several efforts are presented that concern context

modelling, detection and awareness methods and tools, while other relevant context-driven

access control approaches are highlighted, arguing on their advantages and disadvantages.

Regarding the policy modelling an extensive state-of-the-art analysis is given, concerning efforts

focused on the declarative representation of policies. For both context and policy modelling

related efforts we present the envisaged progress beyond the state of the art.

2.1 Policy Models The rapid evolution of IoT has had a concurrent effect on related research domains such as

context-aware computing [schmohl2008]. In the literature, there is a plethora of policy models

utilizing awareness of context across several domains.

2.1.1 Context-aware Models The most widely used definition of context in computer science is the one proposed by Abowd

et al. [abowd1999] and Dey [dey2001] who define context as:

“any information that can be used to characterize the situation of an entity. An

entity is a person, place, or object that is considered relevant to the interaction

between a user and an application, including the user and applications

themselves”.

Moreover, context comprises of contextual information which may be retrieved from

heterogeneous sources. Two other necessary definitions are the context awareness and the

context modeling that provided below as:

“Context awareness is the ability of capturing and processing contexts”

[anagnostopoulos2007].

“Context modeling is the process of abstracting and representing contextual

information for further processing” [schmohl2008].

According to [anagnostopoulos2007], context modeling particularly includes the following three

aspects:

• identification of the most appropriate contextual information

o that can model well enough the specific context in a certain domain.

• identification and modeling of relations among pieces of contextual information

• identification of possible dynamic changes in contextual information

o modeling appropriate reactions to such changes




In [anagnostopoulos2007], modeling context is referred as a technique focusing on how to find

and relate contextual information, that captures the observation of certain worlds of interest.

In context modeling first, we have to identify abstracted conceptually characteristics from real

world and then to map this concept to the context model. Context modeling approaches can be

classified into two but not necessarily disjoint, taxonomies [schmohl2008]:

• Context Theoretic Modeling: Aim of context theoretic modeling is to represent the

context primarily by fusing information that describes situations of entities that are

dynamically changing.

• Context Conceptual Modeling: This type of context modeling describes context as

concepts, as well as the relations among such concepts.

Another classification of context modeling is by the scheme of data structures which are used

to exchange contextual information in the respective system. More specifically, context models

can be categorized in the following set of models [schmohl2008][strang2004]:

• Key-value models: Such models are the simplest data structures associating context

attributes with specific values of contextual information. In particular, key-value pairs

are easy to manage, but lack capabilities for sophisticated structuring for enabling

efficient context retrieval algorithms.

• Markup scheme models: Such models consist of hierarchical data structures based on

markup tags including attributes and comments. The content of the markup tags is

usually defined by other mark-up tags. They are usually implemented as derivatives of

Standard Generic Markup Language (SGML).

• Graphical models: Such rich data type models represent contextual entities and their

relationships graphically. The most prominent examples are Unified Modeling Language

(UML), which is a suitable due to its generic structure paired with a strong graphical

component; and Object-Role Modeling (ORM), which can be nicely utilized to represent

context graphically by identifying facts and enriching those with types and roles.

However, such models luck of formalism and support for distributed context model.

• Object-oriented-models: Such models use object oriented languages and consist of

encapsulating contextual information into objects. More specifically, the context

information is used as a method applied to an object. The information can only be

accessed through well-defined interfaces and is therefore hidden to from other objects.

Due to the nature of object-oriented modeling this approach emphasizes reusability and

controlled access to contextual information. However, such models do not provide

support for interoperability.

• Logic-based models: Such models represent a highly formal modeling approach, where

the context is defined with facts. More specifically, are based on logics, which define

conditions on which concluding expressions or facts may be derived from sets of other

expressions or facts. Those conditions are described by rules in a formal system, so that

the facts, expression and rules put all together define the context.




• Ontology-based models: Such models represent a concept group in a given domain, and

the relationship between the different concepts. More specifically, ontologies are a

promising instrument to specify concepts and interrelations. They are particularly

suitable to project parts of the information describing and being used in our daily life

onto a data structure utilizable by computers. They represent a uniform way for

specifying the model’s core concepts as well as sub concepts and facts, thus enabling

contextual knowledge sharing and reuse. Ontologies are the most expressive context

representation models, but unfortunately have scalability issues.

In the literature there are plenty of proposed context-based models. For instance, the work in

[strang2004] reviews and classifies the aforementioned six categories of context models. Miele

et al. [miele2009] proposed a context model focused on mobile devices. A year later,

Bucchiarone et al. extended this work for usage in service-based applications apart from the

mobile devices. Truong et al. [truong2009] proposed and developed an ontological model of

the W4H classification for context. This W4H ontology provides a set of general classes,

properties, and relations exploiting the five semantic dimensions: identity (who), location

(where), time (when), activity (what) and device profiles (how). Moreover, interesting efforts

that focused on modelling languages have been identified. More specifically, ContextUML is a

UML-based modelling language which was specifically designed for Web service development

and applies model-driven development principles [sheng2005]. In a Web-service-based

environment ContextUML considers that context contains any information that can be used by

a Web service to adjust its execution and output. Typical examples of contexts in ContextUML

language are:

• contexts related to a service requester, including the requester’s identification

information, personal preferences, current situation, and other information;

• contexts related to a web service, such as service location, service status and its QoS

attributes; and

• other contexts like time and weather information.

Moreover, ContextUML has been adopted for the development of a model-driven platform,

called ContextServ, which is used to develop context-aware Web applications [sheng2010].

2.1.2 Policy Modeling through Annotations

Annotation systems add value to digital resources by the attachment of additional data in the

form of comments, explanations, references, reviews, corrections and other types of external,

subjective remarks [khan2006]. More specifically, annotations have long been used as a tool to

facilitate collaborative scholarly discourse, by enabling users to attach additional material such

as comments, notes, queries, assessments, references to resources such as documents, images

or datasets. In [khan2006], annotations are identified as powerful and collaborative tool, when

applied to digital resources shared via the Web.




A usage example of annotations, apart from the inversion of control and dependency injection

in programming languages, is the security annotations. Security annotations can provide

information about confidentiality (i.e. who can read data) and integrity (i.e. who can modify

data) that can guide the use of encryption and digital signing during transmission. Various

works in literature have proposed the usage of annotations as a flexible way to indicate the

aspects for which model elements can fall under some policy and showed how annotations

could be used to impose constraints on configurations of domain resources, how to derive

application conditions on their transformations, and how to annotate complex patterns

[bottoni2015]. In particular, this allows the handling of situations in which policies of access

change dynamically, or different policies have to be simultaneously applied.

The authors in [khan2006] stated that annotation systems vary regarding the types of content

they annotate, the extent of collaboration and sharing they allow and the communities which

they serve. However, there is a need to restrict access to the annotations to a particular group

of trusted users, in order to protect intellectual property rights or personal privacy. For that

reason, in terms of SecureIoT we will enable this ability to IoT application developers.

Annotated types are a well-known concept in programming languages, refining type

specifications with additional information.

2.2 Security Policy Models Security policies are impossible to circumvent in specifying security requirements in terms of

services they provide. A well written policy contains sufficient definition of “what” to do so that

the “how” can be identified and measured or evaluated. A security policy imposes a set of

requirements about the security infrastructure and defines which kind of mechanisms need to

be implemented. There exists a number of fundamental security principles, particularly

applicable within security systems:

• Least Privilege: every program and every user of the system should operate using the

least set of privileges necessary to complete the job;

• Separation of Duty: two or more different people should be responsible for the

completion of a task;

• Chinese Wall: people are only allowed to access to information which is not held to

conflict with any other information that they already possess.

In general, the term access control is used to refer to the model, which is the blueprint that is

used to guide the access control process; the policy language, which defines both the syntax

and the semantics of the access control rules; and the framework, which is a combination of the

access control model, the language and the enforcement mechanism. An access control or

authorization rule can be represented as this tuple:

(S, R, AR)




• S – This parameter denotes the subject i.e. entities requesting access to resources;

• R – This parameter denotes the resource i.e. entities that need to be protected;

• AR – This parameter represents the access rights i.e. permissions and prohibitions that

often based on actions pertaining to the resource.

Sets of access control rules are collectively referred to as an access control policy. The decision

to grant or deny access is based on two distinct processes, authentication and authorization.

Authentication involves the verification of credentials. Whereas, authorization is the process of

granting or denying access to system resources based on credentials.

Authorization constraints are an important aspect of access control and are a powerful

mechanism for laying out higher level policy. In the literature many commonly used access

control models are defined such as

• the Mandatory Access Control (MAC),

• the Discretionary Access Control (DAC) and

• the Role‐Based Access Control (RBAC).

All these models are known as identity-based access control models where users (subjects) and

resources (objects) are identified by unique names. Static access control models, usually,

provide a list of permissions that each subject has on certain objects. The literature on

combining context and security mainly concentrates on context-based RBAC. Moreover, in the

literature, a fourth type has been identified,

• the Attribute Based Access Control (ABAC).

Such a scheme is by nature dynamic. The main difference of ABAC with the previews schemes

is the fact that the concept of provided policies can express a complex Boolean rule set that can

evaluate many different attributes. One example of this access control framework that is

consistent with ABAC is the OASIS XACML [xaml]. It has been used for describing declarative

access control policies encouraging the separation of the access decision from the point of

use. In ABAC, there are not static lists of permissions that associate subjects with objects, but

instead there are “snapshots” of such associations that can be generated and dynamically

change based on the current context.

Although these models have been successfully used, there is a need for richer and more flexible

security models. In order to ensure that users possess authorizations only when required, a

dynamic authorization management framework has to be introduced.

A number of research efforts [corradi2004][hulsebosch2005] have further extended the

Attribute-based Access Control (ABAC) approach to provide access control to software services

in a context-aware manner. Such an example is the concept of location-aware access control

(LAAC). LAAC allows a system to grant, or deny, access to users based on their physical location.

In general, LAAC models typically extend the three basic access control models [decker2011].




Corradi et al. [corradi2004] proposed a Context-aware Access Control (CAAC) model for

ubiquitous environments, where permissions are directly associated with contexts (e.g. user

location, user activities, user device, time, resource availability and resource status).

Hulsebosch et al. [hulsebosch2005], proposed a context-sensitive access control (CSAC)

framework and suggested a process whereby the service provider can define various security

rules based only on the context of the user and not her actual identity. They actually define

access control on the basis of an inextricable relationship between user/device and service, and

they proposed verification methods for anonymous access based on location and service usage

history patterns. In particular, the subject authentication is based on verifying whether or not

the situational context claimed is a valid context attribute of the subject. However, all these

models consider only a limited set of contexts which limits the functionality that can be offered

to the end-user. However, in terms of SecureIoT we need to cover a broad range of scenarios

and for that reason these models are not suitable. Context-aware security policies aim at

considering context explicitly as a guide to deduce which security level to apply in a given

situation [kouadri2004].

In most security models a static approach to enforcing access control is implemented for

simplicity reasons. Subjects, objects, and right accesses that subjects possess to gain access to

the various objects are represented in such structures as capabilities or access control lists, that

are defined by security administrators or designers, and that do not incorporate any dynamic

changes. This static subject-object view approach of access control can be identified to the

earliest passive security models.

Passive security models are enforced according to a simple rule which can be stated that if a

subject has requested an access operation to an object, and the subject possesses the

permission to the operation, then access is granted. Any other contextual information about

ongoing tasks is not taken into account when evaluating access requests; so long as a

permission exists the subject can use it any number of times.

On the other hand, active security models are enforced according to the current activities. For

example, if access requests are being evaluated within the context of progressing tasks; access

to the specific operation is granted only if this operation is required to complete a started task.

This results in permissions being allowed and denied according to authorization requirements

within context of tasks. Context-aware authorizations are concerned with evaluating previous

accesses and planning future access decisions.

The IoT faces challenges such as security, privacy, trust, and context-awareness about the

surrounding environment and about the system state itself. The challenges are important due

to the dynamic nature of IoT and does not have very well-defined network boundaries. The IoT

envisages dynamic and heterogeneous environment in which a context-aware based security

can deal with the aforementioned security problems. Ubiquitous applications can utilise the

environmental information for decision making [pierre2010]. This means that the security

mechanisms developed for the IoT, can incorporate the contextual information while making a




security decision. A security mechanism can be considered context aware, if it can spot the

event happening in surrounding environment. In addition, in [rsa2013] is correctly stated that

context-awareness is an essential element for an authentication system while evaluating

associated risks with a system.

2.2.1 Context-aware Security Models As its name suggests, context-aware security aims at introducing context in security solutions

such as access control models, cryptographic protocols, etc. The context-aware security is the

dynamic adjustment of security policy based on the context. Context-aware security approach

emerged recently in order to cope with the new types of security problems introduced by the

high mobility of IoT and the heterogeneity of devices used in these types of environments

[kouadri2003]. The IoT environment is initially controlled with a particular configuration of the

security policy in an initial context. This context is continually and dynamically changing in

request to triggers. The security policy must then adapt itself to the new updated security

context in order to fill the breaches that may be opened by the new context, as Kouadri et al.

[kouadri2003] stated.

Context-aware security systems are designed with built-in “intelligence” to use situational

information such as identity, location, time, device, business function etc., in order to make

more effective security decisions. The PaaSword project is one work that is actually based on

the context-awareness focused on the cloud. This research paper [verginadis2017] produced

from this project proposes the PaaSword framework that involves a) a context-aware security

model, b) the necessary policies enforcement mechanism along with a physical distribution,

encryption and query middleware. In this deliverable we will extend the proposed context-

based model by considering and adding all the necessary attributes of the IoT environment

such as IoT environment variables and IoT device attestation. The work in [mandyam2017]

states the significance of attestation in IoT devices and proposes that the IoT devices can

leverage the attestation data as part of their authentication and authorization procedures. For

that reason, in terms of SecureIoT we will combine these both research areas.

They are well suited to today’s mobile, cloud-based and IoT environments as they can respond

more intelligently and quickly to unexpected situations. By understanding the context of a user

request, the security system can adjust the security response and control how information is

delivered to the user, greatly simplifying an increasingly complex computing world. Industry

experts believe that the context-based security model will soon replace the static security

infrastructure that currently exists in most organizations. To this end, context-aware security

management systems are going to overtake the traditional security models and replace them

with next generation infrastructure that is far more efficient and simpler to manage. Some of

the key benefits of context-aware security summarized in [jain2014] are:

• Improved Decision-Making: A context-aware solution uses information from multiple

sources and has the ability to intelligently put it in the right context.

o This advantage increases the accuracy of security decisions during an incident.




• Better Focus, Faster Response: Filtering techniques based on the context are necessary

in order to reduce the need for multiple security alerts or false positives to only a few

key vulnerabilities that represent the highest risk.

o This also enables reduction in response time.

• Detecting Advanced Threats: A context-based system is proactive in its approach and

gives greater visibility and insights so IT managers can easily track what is happening on

the network.

o This is particularly useful for preventing unknown malware and advanced threats

that are emerging.

• Operational Savings: Reduction in response time, increase in accuracy of decisions and

improved focus of security strategies are all factors that collectively result in operational

savings for the organization.

• Access Control & Authentication: Context-based systems are better at managing

authentication and access control. Such systems keep track of information relevant to

who is accessing what, at what location, what time, using which device etc. With high

value information and sensitive data being accessed by managers through mobile

devices or any other IoT device, the need for improved access management systems is

much higher today.

Context-aware authentication and access control mechanisms can be projected for taking

advantage of information related to the users’ role and behavior or even attestation properties

and environment properties where system entities are immersed. The emerging and ubiquitous

computing environments such as IoT, need security control that is easily adaptable to the

changing user or environmental contexts. Context information used in an access control

decision can be defined as any relevant information about the state of a relevant contextual

entity or the state of any relevant relationship between different relevant entities at a

particular time that should be taken into account before granting or rejecting a specific access

request. From this perspective, context-awareness is related to the use of this context

information for decisions regarding access control.

2.2.2 Security Policy Enforcement

Security enforcement mechanisms are employed in order to prevent unauthorized behavior. A

security enforcement mechanism is said to enforce a security policy when it permits all

behavior that the policy classifies as authorized (allow) and prevents all behavior that it

classifies as unauthorized (deny). Security enforcement mechanisms developed to date can be

divided into three different classes based on their approach of enforcement security policies

[hamlen2006]:

• Static analyses – This class determine a program’s possible behavior prior to its

execution, while rejecting some programs whose set of possible behaviors includes

unauthorized behavior.




• Execution monitors – This class dynamically monitor a program’s behavior as it executes,

intervening when an imminent policy violation is detected.

• Program-rewriters – This class transform programs into policy-satisfying programs prior

to their execution.

The authors in [migliavacca2010] listed several reasons why enforcing security policies in cross-

domain, event-driven applications are challenging:

• Ineffective policy checks – due to the complexity and scale of applications, there is a risk

that software faults may render policy checks ineffective. For example, a single

component that omits an access control check may reveal a confidential patient record

to the outside world;

• Omitted policy checks – the integration of third-party components and libraries, often

without source code auditing, may mean that necessary policy checks are omitted

altogether. For example, a third-party developer may have a different interpretation of

a security policy and decide incorrectly that revealing a patient record to an insurance

provider is acceptable;

• Trust and legal issues – application deployments across multiple administrative domains

introduce issues of trust and legal responsibility when enforcing security policies. For

example, a hospital domain may trust an insurance provider with billing-related data but

not with a complete patient health history. All these factors put the managed data at

risk— security violations of organizations’ private data may be disastrous; violations of

third-party user data may make them liable to lawsuits.

In traditional event-based and message-oriented middleware the task of enforcing security

policy is assigned to application developers [migliavacca2010]. They have to include in their

application components the appropriate policy enforcement points (PEPs) that carry out checks

before executing sensitive operations. In particular, a middleware may provide support for the

implementation of PEPs in the form of access control models such as ACLs and capabilities.

However, this is not a good strategy, since these are low-level mechanisms that require the

configuration of permissions at the granularity of individual operations. With this approach, is

very difficult to realize a high-level security policy correctly. For instance, in distributed, multi-

domain environments with different levels of trust between organisations, the developer is not

possible to have such a high-level overview of the need policy. To address the aforementioned

concerns, it should be possible to express high-level security policy as constraints on permitted

data flows (e.g. and expression editor) throughout a distributed, event-driven application

[migliavacca2010].

A better approach is that the middleware itself and not the developer should be responsible to

enforce such security policy uniformly cross-domain by taking a data-centric view. The policy

enforcement should occur automatically during the run-time when data flows cross boundaries

between components and domains, instead of carrying out access control checks over




individual operations. This approach makes policy enforcement transparent to application

developers and at the same time does not add further complexity to the application

implementation.




3 SecureIoT Security Models and Annotations for

the Programming Support Service 3.1 Context-aware Security Model As already pointed out, context-aware extensions to RBAC model either do not cover all the

contextual elements with reusable security related context model or are proven hard to

maintain in dynamic environments where users often change roles. On the other hand, the

access control policies that can be implemented in ABAC are limited only by the computational

language and the richness of the available attributes. This flexibility enables the greatest

breadth of subjects to access the greatest breadth of objects without specifying individual

relationships between each subject and each object. Such flexibility and dynamic access control

management capability is highly desired in the heterogeneous IoT domain.

In general, ABAC avoids the need for capabilities to be directly assigned to subject requesters or

to their roles or groups before the request is made. Instead, when a subject requests access,

the ABAC compliant engine can make an access control decision based on the assigned

attributes of the requester, the assigned attributes of the object, environment conditions and a

set of policies that are specified in terms of those attributes and conditions. Furthermore,

policies can be created and managed without directly affecting users and objects, and users and

objects can be provisioned without affecting policies. ABAC enables object owners or

administrators to apply access control policy without prior knowledge of the specific subject

and for an unlimited number of subjects that might require access.

Following the strict definition of NIST [nist] we will refer to ABAC as the

“access control method where subject requests to perform operations on objects

are granted or denied based on assigned attributes of the subject, assigned

attributes of the object, environment conditions, and a set of policies that are

specified in terms of those attributes and conditions”.

Following this definition, the terms “attribute”, “subject”, “object”, “operation”, “policy” and

“environmental condition” will be unambiguous used based on the following definitions:

• Attributes are characteristics of the subject, object, or environment conditions.

Attributes contain information given by a name-value pair.

• A Subject is a human user or a systemic entity, such as a device, that issues access

requests to perform operations on objects. Subjects are assigned one or more

attributes.

• An Object is a system resource for which access is managed by the ABAC system, such

as devices, files, records, tables, processes, programs, networks, or domains containing




or receiving information. In fact, an object can be anything upon which an operation

may be performed.

• An Operation is the execution of a function at the request of a subject upon an object.

Operations include read, write, edit, delete, copy, execute.

• Policy is the representation of rules that makes it possible to determine if a requested

access should be allowed, given the values of the attributes of the subject, object, and

possibly environment conditions.

• Environment conditions represent operational or situational context in which access

requests occur. Environment conditions are detectable environment characteristics that

are modelled as attributes. Environment characteristics are independent of the subject

or object, and may include the current time, day of the week, location of a user, or the

current threat level. It should be noted that some ABAC implementations (e.g. XACML

3.0) allow policy creators to define their own attribute categories extending the set of

subject, resource, action and environment.

Any ABAC system should implement the conceptual flow that is depicted on Figure below.

Figure 2: ABAC Indicative Information Flow

The access request is handled by the ABAC Access Control Mechanism which consults a policy

repository (step 2a) in order to obtain the set of attributes that have to be examined in order to

reach a decision of “allow” or “deny”. The attribute examination phase checks subject

attributes (step 2b), object attributes (step 2c) and environmental attributes (step 2d) in order

to perform the actual assessment (step 3).




In SecureIoT, we consider ABAC as it provides the appropriate flexibility that enables the

greatest breadth of subjects to access the greatest breadth of objects without specifying

individual relationships between each subject and each object. Such flexibility and dynamic

access control management capability is highly desired in the heterogeneous IoT domain.

Further, ABAC enables object owners or administrators to apply access control policy without

prior knowledge of the specific subject and for an unlimited number of subjects that might

require access. This benefit is often referred to as accommodating the external user and is one

of the primary benefits of employing ABAC. Subsequently, SecureIoT aims to couple ABAC with

an extensible and reusable context model. This model is presented in this deliverable and it

aims to conceptualize all the necessary facets, which must be taken under consideration during

its run-time operation with respect to sensitive data access control. This model should also

consider apart from the environment properties the attestations properties of IoT devices.

Access control decisions at run-time, should consider contextual elements like the user’s IP

address and location, the type of device that s/he is using in order to interact with the

application, her position in the company, among others. In order to achieve this, an appropriate

vocabulary/model will be developed.

Also, it is considered important for this model to be generic enough to cover the contextual

modelling needs of the majority of meaningful IoT application scenarios such as the SecureIoT

use cases and at the same time to re-use as many concepts or vocabularies possible, from

widespread vocabularies, for its creation. So, this model development process will be initiated

with the consideration of the previously reported state-of-the-art and the next step will be to

create of the context-aware security meta-model that depicts the associations between the

main facets that should exist in such a model.

In SecureIoT, we examined thoroughly relevant context-aware extensions of RBAC control

models, ABAC approaches and ontological models in order to design a context-based access

model (CBAC). In addition to that, SecureIoT’s context model will include attributes for

characterizing in a fine-grained way individual resources based on their security sensitivity. The

process of granting/denying access on data artefacts is based on dynamically changing

parameters (including attestation properties for trustworthiness reasons), thus we will rely on a

CBAC model, which goes beyond the traditional security models that are usually context

insensitive. The context parameters are individual for every single entity or access request, so

for granting access it is necessary to regard the single entity, the object that it is requesting to

access and any external information that should be considered and be trusted for enhancing

the security.

3.1.1 Context-Aware Security Meta-Model

Figure 3, below presents a meta-model that captures the main facets of the Context-aware

Security Model along with their associations. This meta-model is a simplified version based on

the PaaSword project that tries to reflect the main components of ABAC. The Figure shows all

the necessary classes.




Figure 3: Context-Aware Security Meta-Model

• Request – This class captures the characteristics that should be considered for

evaluating an intercepted request.

• Subject – An instance of this class represents either the entity seeking access to a

particular object (i.e. the requestor), or the entity whose state should be considered for

allowing a certain requestor to access sensitive data and/or resources. Such an entity

can be an organisation, a person, a group or a service.

• Object – This class describes the protected entities e.g. relational or non-relational data,

files, software artefacts that manage sensitive data, as well as the underlying

infrastructural artefacts used.

• Handler – This class refers to the characteristics of dedicated software components that

are used for federating and processing raw contextual data relevant to an access control

decision and semantically uplifting them as instances of the Context Model. More

specifically, handlers instantiate the values of the modelling elements. Different kinds of

handlers may be, for example, authentication handlers, request handlers, location

handlers, IP address to city handlers, etc.

• SecurityContextElement – This class describes the various contextual attributes that

may be associated with the subjects and/or the objects of a request, as well as with the

request itself.

This meta-model provides a number of object properties that aim at:




• interrelating a request with its relevant subjects and objects;

• interrelating the subjects and objects of a request, as well as the request itself, with

contextual attributes drawn from the SecurityContextElement.

The former interrelation is achieved by associating the classes Request with the classes Object

and Subject through the object property hasAttribute. The latter interrelation is achieved by

associating the classes Object and Subject with the class SecurityContextElement through the

object property associatedWith. Contextual attributes that are relevant to a request are piggy-

backed to a request through the object property hasAttribute which interrelates the classes

Request and SecurityContextElement. Finally, the subjects and objects associated with a

request, as well as the request itself, are interrelated through the object property

associatedWith with the handlers that are responsible for providing the actual measured

contextual values that these entities possess. The associatedWith property interrelates the

classes Object, Subject and Request with the class Handler. The aforementioned interrelations

are exploited during the evaluation of a request in order to semantically infer the context that

is attached to the subjects and objects of a request, or to the request itself.

3.1.1 Context Model Facets

This section provides an elaboration of the initial set of facets that will be included in the part of

the model. In Table below, we provide the legend for the Overview diagram that are used in the

following sub-sections.

Table 1 - Legend of the Overview diagrams

Class defined in the Context-aware Security Model and It might also be a subclass of another Class.

Captures a subClassOf relation. The arrowhead indicates the parent class.

3.1.2 Security Context Element

Figure 4 below encompasses the following top-level concepts of the SecurityContextElement.

More specifically, it presents a part of the security context element, since it can be updated and

extended. As already pointed out, this work is based on the PaaSword project. For that reason,

we found crucial to describe all the amendments made in terms of SecureIoT to the

SecurityContextElement in order to support IoT devices and at the same time to be aligned with

the SecureIoT architecture. The list below summarizes the main changes and updates that

made in this element:

a) adding the AttestationProperty, to support the trustworthiness of IoT device;




b) adding an IoT device type;

c) renaming the classes to align with SecureIoT architecture and

d) removing the irrelevant classes.

The list below explains thoroughly the main classes of SecurityContextElement.

• Location – Describes a physical or a network location where data are stored or from

where a particular entity is requesting access to data, or the location of any other entity

that must be taken into account in order to permit or deny an access request. Its main

sub-classes are PhysicalLocation and NetworkLocation. A physical location may involve:

an address, a geographical position, an area and an abstract location. A network

location corresponds to an identifier for a node or network telecommunications

interface from which a particular entity is requesting access to data or the actual

network location of data objects that should be protected. In deliverable D4.3 for

instance, the acquired logs from the ISPRINT dataset contain the physical location

“bathroom”.

• Timestamp – Describes the specific chronological point expressed as an instant or an

interval that characterizes an access request. Again, from the logs from the ISPRINT

dataset we can identify that there exists the “timestamp” attribute.

• Connectivity – Captures information related to the connection used by an entity for

accessing and retrieving sensitive data. Its main sub-classes are: DeviceType,

ConnectionType, ConnectionMetrics and ConnectionSecurity. The DeviceType class

describes the device used for requesting access to sensitive data. The ConnectionType

class refers to the different ways of transmitting an access request and retrieving data

objects (e.g. LTE, 3G, Wi-Fi). Examples of DeviceType (IoT Devices) and ConnectionType

(Networking Infrastructures) are listed in Table 2.1 of D2.1. The class ConnectionMetrics

provides quantitative characteristics of the connection type used for accessing sensitive

data (e.g. the download rate). Finally, the ConnectionSecurity class provides details on

the level of security in the established connection for accessing sensitive data (e.g. SSLv3

as a security protocol, AES 128 as a connection cipher suite).

• AttestationProperty – Describes property that fulfill certain (security) requirements of

the IoT device who asks for authorization. IoT Devices and Secure Elements will be used

to provide such information. The goal of attestation properties is to improve the

security and trustworthiness of IoT platforms.

• Temperature, Gas, Humidity, CO – Describes properties that can be captured from the

environment and actually are the request attributes. In the next version of this

deliverable we will possibly made updates based on which environment attributes we

will focus upon.




Figure 4: Part of Security Context Element overview diagram

The purpose of this model is to allow the administrator or application operator to formulate

context expressions using instances of the model. In addition, we plan to implement these

aforementioned instances on the programming support service, in order to support the rule-

based decisions. In order to support the creation of the appropriate model instances that are

required, a model editor will be developed in the context of D5.7.

3.2 XACML 3.0 in the frame of SecureIoT As already discussed in previews sections, there are many reference implementations of the

ABAC model. One example of an access control framework that is consistent with ABAC is the

eXtensible Access Control Markup Language (XACML) [xaml]. Another example is the Next

Generation Access Control (NGAC) standard [ngac]. These two are considered to be the most

dominant ones [comp]. In the frame of SecureIoT, in the first implementation we will based on

ABAC and XACML 3.0.




XACML is an OASIS standard that describes both a policy language and an access control

decision request/response language [xaml]. More specifically, XACML is an XML-based language

composed primarily of two main language constructs:

a) the syntax for defining the language and

b) the semantics for processing these policies.

Both language constructs use XSD notations; hence, policy definition and request/response

elements are serialized as XML elements. To this end, XACML policies are expressed in XML and

must conform to an XML schema that defines the language semantics. The policy language

construct details general access control requirements, and has standard extension points for

defining new functions, data types, combining logic, etc. Policies are defined in a tree-like

structure as a set of rules pertaining to a particular resource and subject. The second language

construct of XACML are the requests and the responses to these requests, both of which are

also expressed as XML. Each request is composed of attributes associated with the requesting

entity, the resource being acted upon, the action being performed on the resource and

environmental information. The response always includes an answer about whether the

request should be allowed using one of four values: Permit, Deny, Indeterminate (an error

occurred, or some required value was missing, so a decision cannot be made) or Not Applicable

(no policy available to this service addresses this request).

The specification defines five main components that handle access decisions [xacml]; namely

Policy Enforcement Point (PEP), Policy Administration Point (PAP), Policy Decision Point (PDP),

Policy Information Point (PIP), and a Context Handler.




Figure 5: XACML Data-flow diagram [xacml]

The functional purpose of the main components is [xacl]:

• The Policy Administration Point (PAP) provides an interface or API to manage the

policies that are stored in the repository and provides the policies to the Policy Decision

Point (PDP).

• The Policy Enforcement Point (PEP) is the interface to the external world. It receives the

application specific access requests and translates them to XACML access control

requests, then it denies or allows access based on the result provided by the Policy

Decision Point.

• Policy Decision Point (PDP) is the main decision point for the access requests. It collects

all the necessary information from other actors and yields a decision.




• Policy Information Point (PIP) is the point where the necessary attributes for the policy

evaluation are retrieved from several external or internal actors. The attributes can be

retrieved from the resource to be accessed, environment (e.g. time), subjects, and so

forth.

• Context Handler entity converts decision requests in the native request format to the

XACML canonical form, coordinates with Policy Information Points to add attribute

values to the request context and converts authorization decisions in the XACML

canonical form to the native response format.

As already mentioned, XACML uses XSD (XML Schema Definition) notation in order to model

the three basic artefacts which are required i.e. the policy, the request and the response. XSD is

a World Wide Web Consortium (W3C) recommendation that specifies how to formally describe

the elements in an XML document. Thus, as depicted on the Figure 6, three types of XML

documents are processed or produced by an XACML engine in order to judge upon a decision:

the Policy.xml which serializes an actual policy, the Request.xml which serializes an

authorization request and the Response.xml that serializes the output of the engine.

Figure 6: Usage of XML Artefacts [xacml]

3.3 Source Code Annotations An annotation-enabled language is any formal language that supports attribute-based

programming annotations [nosal2016]. A programming language supports this functionality if

its grammar allows adding custom declarative tags to annotate standard program elements.

These custom tags have first to be structured and then to be parsable by the parser

[nosal2016]. A definition about annotations provided in [nosal2016]:

“Annotations are custom declarative structured tags in host @EL that are bound to

host program elements using an in-place binding. Annotations have to be parsable




by standard @EL parser (or a 3rd party tool) that allows implementing semantics in

form of a plug-in.”

In addition, annotation-based programming is a development technique which is recently

gaining on much attention. Annotations are used during the run-time phase of application’s

development cycle in order to bind, control execution and dynamically update a component.

Semantic-annotated web services are called semantic web services. The context-based access

control model will be used for as a semantic-annotated web service in order to be able to

process and decide on any incoming access requests based on the dynamically changing

parameters. There are many programming languages that support annotations (or any other

metadata framework). Such a feature is an essential prerequisite since encryption/decryption

policies and web-endpoints are defined using annotations. The Annotations Interpretation

mechanism is responsible for the interpretation of annotations into XACML-based enforceable

access control policies.

In terms of SecureIoT we identified an annotation type which also serves a functional purpose.

An overview example of this annotation is presented in the sub-sections below. However, more

details about the annotations, the baseline technologies and implementation aspects will be

provided in WP5. The following sub-sections provide usage examples in Java and Python

respectively.

3.3.1 Java Example

Java security has attracted the attention of many researchers due to the widespread use of Java

to develop applications and businesses today. Several techniques have been considered to

provide security for Java applications. A custom annotation that a Java developer could create

and use is the @SecureIoTPEP. The definition of the presented annotation refers to access

control policies. This specific annotation is both a class and a method-level annotation i.e. it can

decorate any Java class or method in the IoT application code. Table 2 below presents how to

create a custom annotation in Java.

Table 2: @SecureIoTPEP Annotation in Java

@Retention(RetentionPolicy.RUNTIME)

@Documented

public @interface SecureIoTPEP {

String value() default "";

Type type() default Type.POLICY;

public enum Type {

RULE, POLICY, POLICY_SET

}

}




An example using the custom created @SecureIoTPEP annotation could be the following in

Table 3. For instance, in this Java example the developer defines an enforcement point (PEP)

associated with the policy named “policy1”. As already pointed out, this strategy assists in

separation of duty between the developer and the administrator. The developer has the duty to

define a PEP and associated with a pre-defined policy. The administrator has the duty

create/modify the policy, while the actual enforcement of the policy will take place during run-

time form the provided service.

Table 3: Annotation usage example in Java

@RequestMapping(value = "annotatedmethod", method = RequestMethod.GET, produces =

"application/json; charset=UTF-8")

@SecureIoTPEP(Type. POLICY,"policy1")

public List<Client> AnnotatedMethodFetchClients() {

return clientService.fetchAllClients();

}

3.3.2 Python Example

In WP5 we will enhance and elaborate further on the usage of annotations in programming

languages such as Python which is more IoT-oriented programming language. Actually, in

Python language are existing the Decorators. Python's Decorators and Java's Annotations are

fundamentally different. They can be used to achieve similar things, but with Decorators you can do

things you can't do with Python, and with annotations you can do things you can't do with Python's

decorators. However, in our case Decorator can be used in a similar manner. In Decorators

documentation [simionato2018] four main advantages of Decorators are listed. Decorators:

• help reducing boilerplate code;

• help separation of concerns;

• enhance readability and maintainability;

• are explicit

Table 4 below show a simple usage example of the @SecureIoTPEP annotation in Python.

Table 4: Decoration usage example in Python

@SecureIoTPEP

def AnnotatedMethodFetchClients():

fetchAllClients();

In addition, Python language is already part of the programming interfaces of QT over ROS

operating system of the socially assistive robot use case scenario. These interfaces do not

provide any provisions for identifying and enforcing security. For that reason, our plan is these




Python interfaces to be enhanced with SecureIoT programming model and annotations in order

to enable the developer of a rehabilitation mission to enforce policies specified in some policy

language such as XACML during run-time. The implantation aspects will be elaborated further

on WP5. Our next step is researching how to use such “annotations” in Python or any other

alternative of annotations (e.g. metadata framework), in order to support the socially assistive

robot use case scenario and at the same time the most used IoT programming language.




4 Mapping with SecureIoT Requirements and

Architecture This chapter provides a reference mapping between the SecureIoT stakeholders’ requirements

of deliverable D2.2 and the proposed models and annotation of SecureIoT.

4.1 SecureIoT Stakeholders’ Requirements In deliverable D2.2 [D2.2] the analysis leads to the identification of particular requirements

related to each task. In terms of T4.4 that relates to this deliverable four requirements

identified and listed below:

R4.4.1 Programming models and annotations should comply with existing standards

Standards are widely used and well established. Existing standard such as XACML 3.0

compliancy (at policy syntax, context syntax and functional levels) could be investigated and

used.

• Among other technologies, ABAC and its representation have been investigated for

implementing the SecureIoT security context-model. They are based on standards and

they provide the required flexibility in policy management. Therefore, in a next step the

first implementation of the SecureIoT security context model will be based on ABAC and

XACML 3.0. This requirement is one of the main focus we will try to cover on this

deliverable D4.9.

R4.4.2 Programming models should be flexibly reusable and extensible supporting a broad set

of deployment scenarios

The programming models and annotations may be implemented, deployed or used within a

single IoT component, service, network or application or may comprise a federated system.

They should consider a range of deployments varying from small sets to large deployments. The

programming models and annotations may be singular or modular according to the scenario.

Modular models are preferred for ease of maintenance and extension.

• As aforementioned, SecureIoT security context-model will be based on ABAC and

XACML 3.0, which are by nature dynamic and easily extensible [xacml]. ABAC, indeed

and can support a broad range of deployment scenarios, since the used model can be

updated during run-time. This advantage can assist in order to cover the dynamically

changing and heterogeneous IoT environment. In this deliverable, we will try to provide

a model that captures all the necessary attributes needed for the SecureIoT use cases.

However, this is not restrictive since we can update this during run-time.




R4.4.3 Annotations must support versioning and backward compatibility

Targeted components may evolve over time and new devices may be introduced, thus the

annotations must provide mechanisms for versioning and ensure compatibility.

• As already pointed out ABAC is dynamic making versioning and backward compatibility

supported by default. However, this requirement is related more on the development

aspects and we will try to address it in WP5.

R4.4.4 Programming annotations should be validated

A design-time mechanism that performs the validation of the annotations should be used by

developers, in order to guarantee their validity. Only specified annotations will be supported to

identify the policy enforcement points.

• Validation of the annotation in programming support service is necessary. Such

precondition assists the service to provide support for “Security by Design” and “Secure

by Default” principles. In addition, in the next iterations of this deliverable we will try to

identify ways of validation of the annotations and the security policy in order to identify

possible constraints and conflicts on the used policy. A possible direction to fulfil this

requirement is to use static code checkers.

4.2 SecureIoT Architecture In Deliverable D2.4 a high-level overview of the mapping between the Developers Support

Service and the SecureIoT Architecture was provided [D2.4]. The Figure provided in D2.4 further

extended and is depicted below (see Figure 7). Figure 7 depicts that a) the model will be

provided through an editor from and the SecureIoT administrator/operator and b) the usage of

annotations from the application developers IDE. In the next iterations of this deliverable we

will possible updated this Figure.

In terms of SecureIoT, we will also plan to apply these models and annotations on the use

cases. For instance, we plan to apply them to the connected car and autonomous driving use

case and to the socially assistive robot use case. ABAC and support for IoT application

programmers are missing and we will examine ways to apply this functionality.




Figure 7: Mapping with SecureIoT Architecture




5 Conclusions A clear understanding the context in which an access request is occur is an important part of

the IoT. A context-aware system can be considered different from traditional systems. The main

advantage of context-awareness is the capability to capture and incorporate environmental

attributes into decision making process [habib2015]. Especially, in IoT environment where

device and user attributes such as, location, time, behavior and attestation properties can

change dynamically, it may be very important for security mechanisms to react based on the

changing attributes/parameters and adjusted to the new conditions accordingly.

Both authentication and access control are important security services for the IoT [habib2015].

To this end, there is a need to check the necessary request attributes and to decide which

resources they can be access to. Until now, the existing developed authentication mechanisms

are mostly context unaware [habib2015], and usually do not incorporate the dynamically-

changing contextual information. Unfortunately, existing static authentication mechanisms may

not be sufficient enough to continue securing an IoT environment. Context-based

authentication mechanisms can assist in access control by providing more information

regarding the subject, the object and the surrounding environment states and make better

decisions. This mechanism in conjunction with the IoT-device trust will provide a more reliable

access control.

The main objective of this deliverable was to provide a re-usable, generic and extensible

context-aware security model that can set the basis for indicating policy enforcement points

through annotations on web endpoints that give access to sensitive data managed by IoT

applications, considering the trust-ability of the IoT device. The provided model conceptualises

all the appropriate facets, which must be available to enforce a context-aware access control.

This model will serve as the basis of the Developers’ support service on WP5. In addition, in the

next iterations of this deliverable, we plan to focus more on the source code annotations and

semantic-annotated web services, in order to support the development for D5.8.




References

[verginadis2017] Verginadis, Y., Michalas, A., Gouvas, P., Schiefer, G., Hübsch, G. and

Paraskakis, I., PaaSword: A Holistic Data Privacy and Security by Design Framework for Cloud

Services http://westminsterresearch.wmin.ac.uk/18561/1/art_10.1007_s10723-017-9394-2.pdf

[D4.1] SecureIoT, Security Monitoring and Knowledge Inference, 2018

[D2.2] SecureIoT, Analysis of Stakeholders’ Requirements, 2018

[D2.4] SecureIoT, Architecture and Technical Specifications, 2018

[schmohl2008] Schmohl, R., Baumgarten, U., Context-aware Computing: A Survey Preparing a

Generalized Approach, 2008 https://mediatum.ub.tum.de/doc/1115382/1115382.pdf

[anagnostopoulos2007] Anagnostopoulos, B.C., Tsounis, A., and Hadjiefthymiades. S., Context

awareness in mobile computing environment, Wirel. Pres. Commun, 42(3):445-446, 2007

[strang2004] Strang, T., & Linnhoff-Popien, C., A Context Modeling Survey. In Workshop on

Advanced Context Modelling, Reasoning and Management, (UbiComp'04) - The Sixth

International Conference on Ubiquitous Computing. Nottingham, England, 2004.

https://pdfs.semanticscholar.org/2c7e/2d63520e4ca44c100e3dfffd9ffb8c9dd7ea.pdf

[jain2014] Jain S., Why The Future Of Security Is Context-Based, 2014

http://www.cxotoday.com/story/why-the-future-of-security-will-be-context-based/

[kouadri2003] Kouadri M., G., and Brezillon, P. A generic framework for context-based

distributed authorizations. In Proceedings of the Fourth International and Interdisciplinary

Conference on Modeling and Using Context (Context’03), volume LNAI 2680, 204–217. Berlin:

Springer Verlag.

[kouadri2004] Kouadri M., G., and Brezillon, P. A Context-Based Approach of Security Policies,

2004 https://www.aaai.org/Papers/FLAIRS/2004/Flairs04-102.pdf

[pierre2010] Pierre, A-C.,“A dynamic trust-based context-aware secure authentication

framework for pervasive computing environments,” PhD thesis, Computer Science, Institut

National des Télécommunications, France, 2010.

[rsa2013] RSA Risk-based Authentication, white paper, November 2013, pp. 1-4.

[habib2015] Habib, K. and Leister, W., Context-aware authentication for the internet of things,

Elev. Int. Conf. Auton. Auton. Syst. fined, 134-139

[bottoni2015] Bottoni, P., Navigli, R. and Parisi-Presicce, F., Conditions, constraints and

contracts: On the use of annotations for policy modeling, Electronic Communications of the

EASST, vol 73, 2015




[hamlen2006] Hamlen, W. K., SECURITY POLICY ENFORCEMENT BY AUTOMATED PROGRAM-

REWRITING, PhD Dissertation, 2006

[migliavacca2010] Migliavacca, M., Papagiannis, I., Eyers, E. M., Shand, B., Bacon, J. and

Pietzuch, P., Distributed Middleware Enforcement of Event Flow Security Policy. In: Gupta,

Indrani and Mascolo, Cecilia, eds. Middleware 2010. Lecture Notes in Computer Science, 6452.

Springer Berlin Heidelberg pp. 334-354, 2010.

[xaml] OASIS, "eXtensible Access Control Markup Language (XACML) Version 3.0”, 2017.

[abowd1999] Abowd, G. D., Dey, A. K., Brown, P. J., Davies, N., Smith, M., & Steggles, P.,

Towards a Better Understanding of Context and Context-Awareness. In Proceedings of the 1st

international symposium on Handheld and Ubiquitous Computing (HUC'99) (pp. 304-307).

Karlsruhe, Germany: Springer-Verlag, 1999.

[dey2001] Dey, A., Understanding and Using Context. Personal and Ubiquitous Computing, 4-7,

2001.

[miele2009] Miele, A., Quintarelli, E., & Tanca, L., A methodology for preference-based

personalization of contextual data. In Proceedings of the 12th International Conference on

Extending Database Technology: Advances in Database Technology (EDBT'09) (pp. 287-298).

Saint-Petersburg, Russia: ACM, 2009.

[bucchiarorne2010] Bucchiarone, A., Kazhamiakin, R., Cappiello, C., Nitto, E., & Mazza, V., A

context-driven adaptation process for service-based applications. In Proceedings of the 2nd

International Workshop on Principles of Engineering Service-Oriented Systems (PESOS'10) (pp.

50-56). Cape Town, South Africa: ACM, 2010.

[truong2009] Truong, H.-L., & Dustdar, S., A Survey on Context-aware Web Service.

International Journal of Web Information Systems, 5-31, 2009.

[sheng2005] Sheng, Q., & Benatallah, B., ContextUML: A UML-Based Modeling Language for

Model-Driven Development of Context-Aware Web Services Development. Proceedings of the

International Conference on Mobile Business (ICMB'05) (pp. 206-212). IEEE Computer Society,

2005.

[sheng2010] Sheng, Q., & Yu, J., Techniques on developing context-aware web services.

International Journal of Web Information Systems, 185-202, 2010.

[corradi2004] Corradi, A., Montanari, R., & Tibaldi, D., Context-based access control

management in ubiquitous environments. In Proceedings of the Network Computing and

Applications, Third IEEE International Symposium (NCA'04) (pp. 253-260). IEEE Computer

Society, 2004.

[decker2011] Decker, M., Modelling of Location-Aware Access Control Rules. IGI Global, 2011.




[nist] ABAC Comparison. Available Online: http://csrc.nist.gov/publications/drafts/800-

178/sp800_178_draft.pdf

[ngac] InterNational Committee for Information Technology Standards, American National

Standard for Information Technology - Role Based Access Control, ANSI/INCITS 359-2012,

American National Standards Institute, New York, May 29, 2012, 56pp.

[comp] XACML vs NGAC. A comparison by NIST. Available Online:

http://dl.acm.org/ft_gateway.cfm?id=2875496&ftid=1695263&dwn=1&CFID=596493327&CFT

OKEN=41911709

[ann2013] Cavoukian, A. and Dixon, M., Privacy and Security by Design: An Enterprise

Architecture Approach, 2013 https://www.ipc.on.ca/wp-content/uploads/Resources/pbd-

privacy-and-security-by-design-oracle.pdf

[khan2006] Khan, I., Schroeter, R. and Hunter, J., Implementing a Secure Annotation Service,

2006

[mandyam2017] Mandyam, G. D., Tiered Attestation for Internet-of-Things (IoT) Devices,

WiFi2017 9th International Conference on Communication Systems and Networks (COMSNETS),

2017

[simionato2018] Simionato, M., decorator Documentation, Release 4.3.1, 2018

https://media.readthedocs.org/pdf/decorator/latest/decorator.pdf

[nosal2016] Milan Nosál’, Matúš Sulír, and Ján Juhár, Language Composition Using Source Code

Annotations, Computer Science and Information Systems, 2016 13(3):707–729 DOI:

10.2298/CSIS160114024N

DELIVERABLE - SECUREIoT Project D4.9... · 2019-09-22 · Version: v1.0 - Final, Date 30/11/2018...

Documents

Transcript of DELIVERABLE - SECUREIoT Project D4.9... · 2019-09-22 · Version: v1.0 - Final, Date 30/11/2018...