research article on the modelling of context-aware

Research ArticleOn the Modelling of Context-Aware Security for Mobile Devices

Tomasz Zurek1 Michail Mokkas2 and Bogdan Ksiezopolski1

1 Institute of Computer Science Maria Curie-Sklodowska University Pl M Curie-Sklodowskiej 5 20-031 Lublin Poland2Polish-Japanese Institute of Information Technology Koszykowa 86 02-008 Warsaw Poland

Correspondence should be addressed to Bogdan Ksiezopolski bogdanksiezopolskiacmorg

Received 23 May 2016 Revised 15 August 2016 Accepted 31 August 2016

Academic Editor Juan A Gomez-Pulido

Copyright copy 2016 Tomasz Zurek et al This is an open access article distributed under the Creative Commons Attribution Licensewhich permits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

Security management in wireless networks has to deal with the changing character of the environment which can further leadto decision making problem for unexpected events Among a huge list of devices the mobile ones are especially vulnerable tothis situation The solution for adapting systems and applications to dynamic environments can be context-aware description ofthe user actions which gives a possibility to take into account the factors that influence these actions In the article we proposea context-aware security adjusting model which is based on proposition logic and incorporates mechanisms that assist in thereasoning process The main benefits that differentiate our approach from similar ones are a formal representation of the modelthe usage of the whole spectrum of context attributes the detection and analysis of contextual data integrity and conflicting rulesrsquoeradication capability All these traits transcribe into amore effective way of adjusting securitymeasures in accordance with existingcircumstances To illustrate the proposed approach we present the case study of context-aware security management for mobiledevices

1 Introduction

Nowadays a lot of effort is put into providing new meth-ods of ensuring appropriate security for mobile systemsand applications The most popular approach is to applythe strongest possible security measures which guaranteemaximal security level This approach however leads to anincrease in system load and hinders its performance [1 2]The system can become unusable causing a decrease in thequality of experience (QoE) perceived by users Thereforefinding a balance between the security level and performanceof an IT system is an essential goal that we seek to achieve Forthis reason we investigate the benefits of adaptable security[3] In order to be adaptable a security mechanism needs totake into consideration a lot of additional parameters thatcan influence the outcome of a security evaluation Theseadditional parameters can be categorized as contextual dataand other facts that describe system In other words a featurecalled context-awareness (CA) has to be introduced CA is aterm coined mostly for the capability of pervasive computingsystems which allows acting in certain ways according toalready gathered sensor dataThe sensor data constitute whatwe define as context Mobile devices currently have limited

resources (such as energy supply computational power ormemory) but are equipped mostly with a vast amount ofsensors This is what makes them an ideal environment foradaptable context-aware securitymechanismswhich attemptto find the optimal level of quality of protection (QoP) andperformance ratio [4 5]

Security mechanisms should be adjusted following theimportance of the resources processed by the device itsparameters and external circumstances in which the givendevice works Adjustment of quality of protection mech-anisms to the context in which the device works shouldcontain a couple of important steps One of these steps is afull evaluation of quality of protection mechanisms anotherone is an analysis of the context in which the given deviceoperates resources which are processed by the device itstechnical parameters and all external circumstances whichinfluence the security of the device resources Analysis ofthe context should result in the definition of the qualityof protection requirements which should be compared topreviously prepared evaluation of quality of protectionmech-anisms If all requirements are met by the devicersquos securitymechanisms then a chosen activity can be performed It hasto be noted that such adaptable mechanisms have already

Hindawi Publishing CorporationMobile Information SystemsVolume 2016 Article ID 8743504 16 pageshttpdxdoiorg10115520168743504

2 Mobile Information Systems

been in the focus of many researchers and some of themare described in greater detail in the next section Howeverthe main contribution of our paper is the addition of certainelements in the process of security evaluation based on amodel of propositional logic The main elements which weintroduced and that are missing from similar approaches are

(i) a context consistency analysis mechanism whichinvestigates whether provided contextual data is cor-rectly interpreted and obtained

(ii) a conflicting rule reasoning eradication mechanismto deal with issues that might occur during the rea-soning process

(iii) a holistic approach which takes into account all con-textual factors rather than just a couple of them

(iv) a formal representation of the model with definitionsof its elements and detailed reasoning algorithms

The article is divided into six sections Section 1 is anoverall introduction to the subject of context-aware securitySection 2 focuses on the comparison of similar works brieflysummarizing their main shortcomings which we intend torectify Section 3 introduces our model and familiarizes withthe definitions of its elements Section 4 describes in detailthe algorithm of the procedure while Section 5 illustratesa couple of use case scenarios to thoroughly present thereasoning process Additionally Section 6 briefly describesthe developed implementation of the model that acts as aproof of concept and finally concludes the article In theAppendix the diagrams of the proposed algorithms arepresented

2 Related Work

This section describes the state-of-the-art ideas and conceptswhich are related to the field of study There are quitemany existing models that describe context-awareness insystems However most of them lack mechanisms thatallow dynamic reasoning capable of contextual consistencyanalysis and coping with conflicting rules One of them is[6] which describes a context-awareness framework (webi-nos) allowing webinos-enabled applications to collect andprovide contextual information This information is used toenhance multiple aspects related to human-machine inter-actions of everyday life instead of being limited only toa device-centered model for context deduction There isnot however much detail provided about the mechanismof rule forming and evaluation that our approach relieson

Another article [7] proposes a context-aware securityframework which enforces the execution of mobile applica-tions inside security incubators for the purpose of controllingthe exchange of information between mobile applicationsand mobile device resources The contextual data is gatheredfrom mobile devices equipped with sensors Whenever anapplication requests access the framework analyzes the con-textual information and security configuration to decide onpolicy enforcement The method used for this analysis is the

Analytic Hierarchy Process (AHP) which is a popular choicefor policy selection decision making adaptive learning andrecommendation and feedback systems The main advantageofAHP is its ability to break down complex decision problemsinto smaller ones which enhances the reasoning processUnfortunately the article does not mention any conflicteradication mechanisms

In [8] the authors describe a new emerging researcharea referred to as the Context-Aware Mobile and WirelessNetworking (CaMoWiN) The article is basically a surveyof existing solutions from both networking and computingenvironments where context acts as a form of a ldquoglue-pointrdquothat allows for their integration As part of this work whichdeals with context evaluation (policies decision making)several frameworks are described (through omitting anyconflict solving mechanisms)

The article [9] introduces a context-aware scalableauthentication (CASA) as a means of balancing securityand usability for authentication The idea is to performauthentication by selecting a form of active authenticationbased on a combination of multiple passive factors someof which are contextual (such as location) This procedureuses a probabilistic framework as well as a naive Bayesclassifier to combine many factors calculating risk anddetermining the required level of active authentication Aswith previous solutions there are no conflict eradication orcontext consistency mechanisms involved

The article [10] describes a context-aware security andtrust framework for Mobile Ad hoc Networks (MANET)called CAST Its primary objective is to accurately classifywhether the nodes inMANETs that misbehave do so becauseof a faulty or malicious cause The main addition of thisframework is that it takes into consideration contextual datasuch as communication channel status battery status orweather conditions In addition it uses policies to detectwhether the contextual information is intentionally falsifiedor the current environmental conditions cause their reportingtomalfunction and provide incorrect data Unfortunately thearticle does not mention any methods of detecting contextinconsistencies

In [11] the authors proposed a cloud-oriented context-aware framework for ambient assisted living (AAL) calledCoCaMAAL Their model tries to address issues such as thecomplexity in management of sensor data or the derivationof contextual information as well as the constant monitoringof the activities that are performed by users The procedureis enhanced through the implementation and use of acontext management system (CMS) Similar to other worksit lacks conflicting rule and context consistency analysismechanisms

In [12] an automated context classification for context-aware access control (ConXsense) is proposed The authorsclaim this is the first framework to provide context-awarenessin access control of mobile devices which is based on contextclassification Previous solutions relied toomuch on staticallypredefined policies ConXsense is a probabilistic approachthat overcomes previous deficiencies Context is automati-cally classified throughmachine learning and context sensingrelying on their appropriate security propertiesThe approach

Mobile Information Systems 3

does not involve capabilities for solving rule conflicts duringits reasoning

The paper [13] introduces an intelligent context-awaresystem (iConAwa) providing mobile users with the ability toobtain information and services related to their current loca-tion It describes the context and point of interest ontologiesin OWL One of the similarities with other systems is theutilization of rule-based context reasoning However it lacksa formal representation

An approach proposed in [14] uses context related pref-erences to personalize various procedures (such as queries)It deals with the problem of identification of preferencesthat have the most similar context states with those of achosen query (context resolution) The authors provide asolution for the problem in the formof a preference graph andprofile tree data structures which decreases the complexity ofrepresentation of the context related preferences This articledoes not incorporate anymethod for dealing with conflictingrules

In the paper [15] a context-aware RBAC model forbusiness processes is introduced Previous solutions relatedto business processes did not support any contextual con-straints The context constraints specify the conditions thathave to be fulfilled in order to allow the execution of a certaintask Unfortunately there is no mention of any conflictingrules solving mechanisms

In [16] two automated analysismechanismswhich exam-ine modelling errors in contextual requirements modelsare proposed The first one deals with the detection ofinconsistent specification of contexts in a goal model (usedin early stages of software development) while the secondone deals with the detection of conflicting context changesThe proposedmodel is in some points similar to mechanismsintroduced by us (especially in the point of detection ofinconsistent facts) Generally speaking the model presentedin [16] is muchmore complex than ours but the mechanismsintroduced are created to support a goal-driven softwaredevelopmentTherefore the system lacks all the mechanismsconnected with the evaluation of the context of the environ-ment in which the device works especially the mechanismof defeating of conflicting requirement rules Moreover alsothe concept of requirements which appears in the paper hasa different meaning than in our model Most notably theaspect of taking into consideration quality of protection ismissing Also there are somedifferences in the specifics of theimplementedmechanisms such as ordering of rules instead offacts to decide about actions

Another article [19] describes a context-aware and rule-based reasoning solution for mobile devices Context is rep-resented by a key-value pair where the key is the name whichdefines a context property and the value represents its currentstate An example of such pair would be (room kitchen)Thearticle compares common approaches to context modellingand concludes that most available languages offer limitedsupport for advanced inference tasks The authors also claimthat rules are the best choice for advanced context reasoningThe problem of inconsistent contextual data is not dealt with

The paper [20] presents a context-aware security policyframework for user preferences in e-services It supports

role-based access control and its aim is to create policy-based security measures in cross-organizational scenariosOne of the advantages of the framework is the integra-tion of contextual information and user preferences whichincreases flexibility It incorporates policy conflict resolutionmechanisms However the authors do not mention detectinginconsistent contextual data

Lastly in [21] the authors provide a survey on energy-aware security mechanisms The discussed articles and solu-tions are not completely context-aware since they take intoconsideration only the energy consumption related aspectsThe aspects of conflict prevention and context consistencyanalysis mechanism are unfortunately omitted and thereforeassumed nonexistent

The models in the mentioned related work are comparedwith regard to the following main attributes

(i) ldquoContext consistency analysisrdquo refers to the ability ofdetecting inconsistent context specification

(ii) ldquoConflicting rule reasoningrdquo stands for the ability ofdealing with contradictory specified rules

(iii) ldquoContext-awarenessrdquo refers to the acquisition and useof contextual information

(iv) ldquoFormal representationrdquo refers to whether the modelis presented by the use of mathematical formulae

(v) ldquoHolisticrdquo specifies the possibility of using all contex-tual factors instead of a set of selected ones

(vi) ldquoConsiders security requirementsrdquo indicates that themodel takes into account the security aspects of thesystem

The comparison is presented in Table 1

3 The Model

31 General View Ourmodel is mainly based on propositionlogic with some additions which allows for a better represen-tation of specific features of the security context evaluation

32 Facts and Rules We assume that the system context isrepresented by means of a set of propositions which arereferred to as facts

119865 = 1198911 1198912 1198913 119891119899 (1)

where 1198911 119891119899 are the facts describing a systemThe facts represent circumstances in which the analyzed

device works and they can have various levels of generalityWe assume a set of operators OP = not sim or andrArrrarr

where

(i) not is a classical (strong) negation(ii) sim represents a negation as failure(iii) or stands for a disjunction(iv) and serves as a conjunction(v) rArr is a defeasible implication(vi) rarr means a strict implication


Table 1 Model comparison

[6] [7] [17] [8] [9] [10] [11] [18] [12] [13] [14] [15] [16] [19] [20] OurContext consistency analysis mdash mdash mdash mdash mdash mdash mdash mdash mdash mdash mdash mdash mdash

Conflicting rule reasoning mdash mdash mdash mdash mdash mdash mdash mdash mdash mdash

Context-awareness

Formal representation mdash mdash mdash mdash mdash mdash mdash mdash

Holistic mdash mdash

Considers security requirements mdash mdash mdash mdash mdash mdash mdash mdash mdash

Table 2 The list of main security attributes

Integrity Prevention against improper informationmodification

Confidentiality Guarantee of only authorizedinformation access and disclosure

Authentication This is the process of verifying or testingthat the claimed identity is valid

Authorization

Ensures that the requested activity orobject access is possible given the rightsand privileges assigned to theauthenticated identity

Accountability Steps of protocols (access to services) areregistered to restore past threats

Availability Ensuring timely and reliable access toservices and data and use of information

By negation as failure we understand the kind of negationused in the PROLOG language simp is satisfied if it isimpossible to prove that 119901

By defeasible implication we understand a weaker chal-lengeable kind of implication widely used in formal modelsof argumentation (eg in [22]) the utilization of defeasibleimplications allows for defeating one of the conflictingformulae during the inference process

Definition 1 (literals) Facts (negated in a strict way ornonnegated) are literals A set of all literals is denoted as119871 = 1198971 1198972 119897119898

For example if 119865 = 1198911 1198912 is a set of facts then 119871 =1198911 1198912 not1198911 not1198912 is a set of literals

Definition 2 (security attribute) Security attribute is anattribute which describes the system behavior in the case ofinformation security requirements

For example one can enumerate the following securityattributes (Table 2) confidentiality integrity availabilityauthentication authorisation or accountability [3 23]

The security attributes (SA) set consists of unlimited butfinite number of security attributes

33 Security Attributes As described above the securityattributes set SA consists of an unlimited but finite number ofsecurity attributes Each of them has its own evaluation valueexpressed by a positive integer number The measurement

process of security attributes referred to as an evaluation isdiscussed in [24]

Definition 3 (evaluation of security attributes) 119878 is a set ofpairs 119874 = ⟨sa 119900⟩ where sa isin SA is a security attribute and 119900is its evaluation value

For instance we have three security attributes with theirevaluation values

SA = confidentiality integrity authorisation119878 = (confidentiality 10) (integrity 20) (authorisa-tion 30)

By Val(119878 sa119898) we denote function which returns evalu-ation of a given security attribute For example Val(119878confidentiality) = 10

It is important to notice that security attribute can havepositive or negative character in the sense that the biggervalue of security attribute evaluation can mean better (forpositive) or worse (for negative) evaluation

Definition 4 (context) A context is a model of an externaland internal environment in which evaluated system worksand is represented by a set of literals denoted as 119862 = 119897119886119897119887 119897119904 119897119911 which can also be expressed by a set ofpositive or negated facts 119862 = 119891119886 119891119887 not119891119904 not119891119911

Definition 5 (rule) The rule is a formula in the form of

Conditions rarr Conclusion

where

(i) Conditions is a list of rule conditionsList of conditions is in the following form 119908119897119886 func119908119897119887 funcsdot sdot sdot 119908119897119889 where func are the operators fromthe set = or and and 119908119897119886 119908119897119887 119908119897119889 are the literals(nonnegated or negated by a classical negation)

(ii) Conclusion is a rule conclusion in the formConclusion = (119897119909 and 119897119910 and sdot sdot sdot ) where (119897119909 119897119910 ) isin 119871

Conditions and conclusions can be negated by a classical(logical) negation It is forbidden to use negation as failurewhich allows for preservation of monotonicity of inferenceThe set of rules is denoted as RF

The rules allow us to represent relations between variousfacts They also allow us to express which facts are exclusive


in the sense that the existence of one of them causes theinexistence of the others It is important because it helps topreserve consistency of the model

Definition 6 (fact-based inference mechanism) As a fact-based inference mechanism one understands a forwardchaining mechanism As 1198621015840 one denotes a set of conclusionswhose inference mechanism concludes from a context 119862 anda set of rules RF One can also denote it as 119862 ⊢ 1198621015840 The unionof sets 119862 cup 1198621015840 is denote as 119875 and describes the full context

Let us illustrate the mechanism with an exampleSet RF contains the following rules

1199031 1198911 1198916 rarr 11989121199032 1198912 rarr not11989131199033 1198914 rarr 11989151199034 1198917 rarr 11989181199035 1198915 rarr 11989131199036 1198913 rarr not1198912

Set 119862 contains facts 119862 = 1198911 1198914The steps of the forward chaining inference mechanism

will be as follows

(1) In the first step the mechanism checks if the condi-tions of rule 1199031 are satisfied Since 1198916 is not declared((119862 cup 1198621015840) ⊬ 1198916) the mechanism skips the rule andmoves to the next step

(2) Since (119862 cup 1198621015840) ⊬ 1198912 the mechanism skips rule 1199032 andmoves to the next step

(3) On the basis of rule 1199033 the mechanism infers 1198915 andadds 1198915 to set 119862

1015840(4) Since the condition of rule 1199034 is not satisfied ((119862 cup

1198621015840) ⊬ 1198917) the engine does not add 1198918 to set 1198621015840 butmoves to the next step


1015840(6) On the basis of rule 1199036 the mechanism infers not1198912 and

adds not1198912 to set 1198621015840

(7) The system moves to rule 1199031 and checks if its condi-tions are satisfied

(8) The system checks the remaining rules(9) Since there are no possibilities to satisfy the condi-

tions of any other rule (except 1199033 1199035 and 1199036) thesystem returns 119875 = 119862 cup 1198621015840

In the case of inconsistent input data the possibility ofutilization of negation in a rule base RF entails the possibilityof inconsistencies in set 119875 and infinite loops during theinference (by an inconsistency we understand situation inwhich 119875 ⊢ 119891119909 and not119891119909) How do we overcome these problemsand interpret such inconsistencies If we assume that rulesfrom a set RF are well formed and they represent real lifedependencies then inconsistencies in a set 119862 or 119875 suggestthat something is wrong with the sensors or the device has

been hacked and someone is trying to take control over thedevice In both situations the device should alarm the userthat something is wrong and start safety procedure whichshould increase the level of security of the device or switch thedevice into the offline mode In order to detect and preventthe system from such suspicious situations we assume theexistence of the consistency guard themodulewhich controlsconsistency of the contextual data collected by our deviceA more detailed description of the consistency guard will beprovided the next section

34 Consistency Guard A mobile device with context-awaresecurity system can be an object of an attack targeted todeceive sensors of the system Such an attack may lead toa decrease in the level of quality of protection by deceivingsensors in order to convince the device that the context itworks in is safe enough to decrease QoP level

How do we overcome such risk Obviously deceivingall sensors is much more difficult and less plausible thandeceiving only one of them The attack on one of the sensorscan lead to inconsistency in the indications of the devicesensors For example GPS shows that the device is in the safeplace (office) but the temperature is too low (or too high) forthe interior of the office Moreover the device can connect toaccess points which cannot be accessed inside the office Suchinconsistency can suggest that the device has been hackedand someone changed indications of GPS positionerThe keypoint of detection of such kind of attack lies in the analysis ofthe consistency in indications of the devicersquos sensors

Consistency guard will be amodule of the device control-ling whether the sensors indicate facts which cannot be truesimultaneously If coexistence of such facts appears then thesystem should indicate a dangerous state to the user

From a formal point of view if 119875 ⊢ 119891119899 and not119891119899 thenthere is an inconsistency in our sensorsrsquo indications and ourdevice should alarm the user and stop all actions except thepossibility of direct switching the guard off by the user (in thecase of mistaken alarm) The system should not perform therest of context analysis until the conflict disappears or the userswitches the guard off (procedure ALARM)

Unfortunately such model of inconsistency detection isnot sufficient if such incompatible literals appear duringthe inference process then inference engine can fall into aninfinite cycle before the reasoning process terminates Howdo we overcome such a problemWe have assumed the usageof a classical monotonic forward chaining modus ponens-based inference engine Such an engine can fall into infiniteloop in the case of cycles in the set of rules Such a case canbe reduced to a situation in which RF will contain two rules

1198911 rarr not11989121198912 rarr not1198911

If119862 ⊢ 1198911 1198912 then the inference enginewill fall into an infiniteloop The monotonicity of our inference engine gives us animportant property if a set of rules (RF) is well formed andinput data (a list of facts) is consistent then the conclusion ofevery step of inference should be consistent with the declaredand previously inferred list of facts Thereby in order to


overcome the possibility of falling into infinite loops we haveto detect inconsistencies in the conclusions of every step ofreasoning For example if 119862 ⊢ 1198911 1198912 then the first step ofthe inference engine will add to the set 1198621015840 fact not1198912 In thenext step the consistency guard tests if there is inconsistencyin sets 119862 cup 1198621015840 Since 119862 contains 1198912 and 1198621015840 contains not1198912then there is inconsistency the inference engine interruptsits functioning and consistency guard starts the ALARMprocedure

Let us illustrate the mechanism with a more complexexample

Consider set RF from the previous section (RF = 11990311199032 1199033 1199034 1199035 1199036) where


Let us assume that set 119862 contains facts 119862 = 1198911 1198914 1198916One can easy recognize that facts 1198913 and 1198912 are incom-

patible they cannot be simultaneously true For example 1198912means that GPS positioner indicates that the device is in thesafe place (office) 1198913 means that temperature is very low (toolow for the interior of the office) The steps of the forwardchaining inference mechanism will be as follows

(1) In the first step on the basis of rule 1199031 themechanismconcludes 1198912 and adds 1198912 to set 1198621015840 and the consis-tency guard checks if 1198621015840 is consistent Since neither 119862nor 1198621015840 contain conflicting facts ((119862 cup 1198621015840) ⊬ not1198912) theinference engine moves to the next step

(2) On the basis of rule 1199032 the mechanism infers not1198913 andaddsnot1198913 to set119862

1015840The consistency guard checks if thenew conclusion is consistent with existing knowledgeSince (119862cup1198621015840) ⊬ 1198913 the inference enginemoves to thenext step


1015840 The consistency guard checks if thenew conclusion is consistent with existing knowledgeSince (119862 cup 1198621015840) ⊬ not1198915 the inference engine moves tothe next step

(4) Since the condition of rule 1199034 is not satisfied ((119862 cup1198621015840) ⊬ 1198917) the engine does not add 1198918 to set 1198621015840 butmoves to the next step


1015840 The consistency guard checks if thenew conclusion is consistent with existing knowledgeSince (119862 cup 1198621015840) ⊢ 1198913 not1198913 then the consistency guardinterrupts thework of the inference engine and beginsprocedure ALARM

Concluding the above the consistency guard will be a partof a fact-based inference mechanism and it will start theALARM procedure in the case of the incompatibility of factson any step in the process of inference

35 Activity The system behavior can be described by activ-ities which are performed by entities either explicitly by theuser while interacting with the host or implicitly by the hostwhile running various applications

Definition 7 (activity) 119860 is a set of activities

119860 = (1198861 1198862 119886119899) (2)

where 1198861 119886119899 are the activities describing system behavior

As an activity one can enumerate sendingchecking e-mail getting data from the database setting a VPN connec-tion and so forth

351 Requirement Rules The level of security protection fora given activity is regulated by requirement rules

Definition 8 (requirement rule) Requirement rules are for-mulated as follows

Conditions rArr Req119886

where

(i) Conditions is a list of rule conditions in the form119886 and (119908119897119886 func 119908119897119887 func sdot sdot sdot 119908119897119889) where 119886 is activityfunc are the operators from the set = or and and119908119897119886 119908119897119887 119908119897119889 are literals (nonnegated or negatedby a negation as failure)

(ii) Req119886 are security requirements of activity 119886 Req119886 =req1 req2 req119899 where req119897 = (sa119897 relationvalue119897) sa119897 is a security attribute relation is a relationfrom the set lt gt and value119897 is a threshold value

We denote a set of all requirement rules as119877 By RRwe denotea set of requirement rules (RR sub 119877) with satisfied conditions

The requirement rule establishes the desired level ofprotection of a device (requirements Req119886) allowing forthe performance action 119886 in an external environment(context) described by the conditional part of the rule(119908119897119886 func 119908119897119887 func sdot sdot sdot 119908119897119889)

Definition 9 (satisfaction of a requirement) PredicateSat(119878 req119896) denotes that the evaluations of security attributesin set 119878 meet the requirement req119896

If sa119898 is a security attribute evaluated in 119878 req119896 is arequirement (sa119898 relation value119896) and (Val(119878 sa119898) relationvalue119896) is satisfied then Sat(119878 req119896) is true (where value119896 isa threshold value from req119896 and relation is a relation fromreq119896)

Definition 10 (satisfaction of action requirements) If forsecurity evaluation 119878 every req isin Req119886 is satisfied(forallreqisinReq

119886

Sat(119878 req)) then an action 119886 can be performed

Quality of protection evaluation and context-basedrequirement rules are the grounds for a decision whether anaction can be allowed or banned If security requirements


(1) SET 119862(2) SET 1198621015840 larr RES(119862RF)(3) 119875 larr 119862 cup 1198621015840

(4) SET INTENTION(119886)(5) 119878 larr EVAL(6) SET 119877(7) CONTEXT(119875 119886 119878 119877)(8) if VSE = EMPTY then(9) STAT(119886) larr ALLOW(10) EXE(119886)(11) end if(12) if VSE = EMPTY then(13) do(14) foreach req[119894] in VSE do (15) if NOTPOSSIBLE[119894] then(16) STAT(119886) larr DENY(17) EXIT(18) end if(19) INCREASE[119894](20) (21) 119878 larr EVAL(22) CONTEXT(119875 119886 119878 119877)(23) if VSE = then(24) STAT(119886) larr ALLOW(25) end if(26) while (STAT(119886) = ALLOW)(27) end if(28) if STAT(119886) = ALLOW then(29) EXE(119886)(30) end if

Algorithm 1 Security attributes adaptation algorithm

are not met the system should inform the user which of thefacts describing context violate the requirement (such as GPSposition) and which can help the user to change dangerousenvironment (eg to leave an insecure place) The procedureof evaluation of a possibility of performing given action 119886 ispresented in Algorithm 1

36 Conflicts between Rules Requirement rules for a givenactivity establish a minimal level of quality of protectionof the system by means of security attributesrsquo evaluationthresholds Since each of the requirement rules describescomplete requirements of a given action only one of themcan be used to establish requirements In specific conditionsa conflict between such rules can appear

Definition 11 (conflicting rules) There is a conflict betweentwo or more requirement rules if these rules cannot beexecuted together

Such conflicts appear when there are two rules withsatisfied antecedents which establish requirements for thesame action If two rules rr1 and rr2 are in the set RR (rr1 rr2 isinRR) and they establish requirements for the same action 119886then these rules are in conflict

The problem of conflicting and subsuming rules is themain reason for utilization of defeasible implication In this

work as defeasibility of the evaluation rules we understandthe possibility of exclusion from the reasoning process of achosen rule by another rule If antecedents of two conflictingrules are satisfied only one of them can be executed (but sucha rule can also be defeated by another one)

To represent priorities between evaluation rules weassume partial order OR between rules from a set 119877 Suchorder allows us to express that if rr1 gt rr2 and rr1 rr2 isinRR then rules rr1 and rr2 are in conflict and when theconditions of both of these rules are satisfied rule rr1 shoulddefeat rule rr2 Our model of conflict resolution mechanismis built on the basis of theoretical models discussed in thepapers devoted to formal modelling of legal reasoning andargumentation for example in [22 25ndash27]

How does the conflict resolution mechanism work Forexample if set 119875 contains facts 119875 = 1198911 1198912 1198913 set RRcontains two rules with satisfied conditions (rr1 119886 and (1198911 and1198912) rArr Req1198861 and rr2 119886 and (1198911 and 1198912 and 1198913) rArr Req1198862) the useris going to perform action 119886 and rr1 gt rr2 isin OR then rulerr1 defeats rule rr2 (themechanism excludes rule rr2 from thereasoning process)

The issue of ordering of conflicting rules certainlyrequires further discussion We realize that there may be anumber of hardly predictable sources of conflicting rulesrsquoorderings which makes a fully automated mechanism ofordering generation very difficult (or even impossible) toconstruct In ourmodel we assumed that ordering is declaredin advance by the constructor of a system We do not giveany restrictions to the constructors of the ordering assumingtheir rationality and high-quality expert knowledge

However there is one kind of conflict which allows usto detect and recognize a special kind of orders betweenconflicting rules which will be discussed in future workIn some cases two conflicting rules may have subsumingconditions for example if rr1 119886 and (1198911 and 1198912) rArr Req1198861and rr2 119886 and (1198911 and 1198912 and 1198913) rArr Req1198862 then every casewhich satisfies the conditions of rule rr2 also satisfies theconditions of rule rr1 Usually in such a situation a morespecific rule is stronger than a general one because itregulates a specific case of a standard situation regulatedby a more general rule This mechanism comes from thetheory of law and is called lex specialis derogat legi generali(specific act (provision) derogates from (prevails over) thegeneral regulation) Nevertheless the implementation of themechanism in such a complicated matter requires furtherelaboration which will be performed in future work

37 Process of Establishing ofMinimal Requirements of SecurityAttribute Protection Level We assume that the estimationof the quality of protection of security attributes of a givendevice is based on the systemdescribed in [24] Relying on theanalyzed devicersquos parameters the systemmakes an evaluationand returns the set of security attributes with their estimationSince estimation of each security attribute is a positive integernumber the result obtained from the system can be easilytransformed into the set 119878

Themain aim of the current work is to decide if quality ofprotection of the analyzed device (established on the basis of


the system described in [24]) is enough to meet the require-ments Since we have an estimation of a quality of protectionof our device we need to estimate security requirementsfor a given action and resource in a given context Theprocess of establishing the minimal requirements of securityattribute protection level is based on requirement rules Forevery security attribute we assume starting level of qualityof protection and satisfaction of every requirement rulersquoscondition to cause an adequate change of requirement levelThe final level of quality of protection of a chosen securityattribute is a minimal requirement of level of protection ofthis security attribute

If the requirements necessary to perform a given actionare not met then the system returns conditions (securityattributes) which are violated If the system receives securityattributes which do not meet requirements the process ofadaptation of the system begins

38 Adaptation Process The process of adaptation of qualityof protection of a given device is based on the assumption thatevery security attribute has assigned a set of quality of pro-tection parameters and external context factors (facts) thatinfluence its QoP estimation as well as a set of possibilitiesof increasing them Such parameters or facts can be changedin order to increase evaluation of quality of protection (egincrease the key length) or to decrease context requirements(eg to move to a safer place)

4 Algorithms

The implementation of context-aware security system forindustrial applications can be divided into two majorsubalgorithms Algorithm 1 is the general algorithm respon-sible for adaptation process Algorithm 2 represents a specificalgorithm responsible for estimation if the quality of protec-tion of the device meets requirements caused by context inwhich the device is working

The notation used in the algorithms is presented below

(i) SET is indication of making a choice(ii) EXCLUDE is a procedure excluding requirement rule

rr[119896] from the set RR(iii) READ is a reading indication(iv) CONTINUE means processing statement will be

skipped(v) RES(119862RF) is the reasoning function based on a

set of facts 119862 and rules RF (the reasoning functionworks on the basis of inference mechanism describedearlier) The reasoning function contains consistencyguard the procedure controlling consistency of sen-sors which in the case of inconsistency interrupts theinference process and starts procedure ALARM

(vi) ALARM is the procedure of alarm if consistencyguard returns that there are inconsistencies in sensorsrsquoindications (false) the system stops the context analy-sis stops actions and waits for user reaction

(vii) 119862 is a case expressed by a set of facts

(1) RR = 0(2) SET OR(3) ADD(RR SATISFIED(119875 119877 119886))(4)(5) for 119896 = 1 to COUNT(RR) do(6) for 119898 = 1 to COUNT(RR) do(7) if (rr[119896] gt rr[119898]) isin OR then(8) EXCLUDE rr[119898] from RR(9) end if(10) end for(11) end for(12)(13) if COUNT(RR) gt 1 then(14) ERROR(15) end if(16) SET RULE larr RR(17) SET Req119886 larr CONC(RULE)(18) for 119894 = 1 to COUNT(Req119886) do(19) if SAT(119878Req119886 req[119894]) = false then(20) VSE larr req[119894](21) end if(22) end for(23) RETURN VSE

Algorithm 2 Algorithm of the security attributes context evalua-tion CONTEXT(119875 119886 119878 119877)

(viii) 1198621015840 is a set of facts obtained from the inference mech-anism

(ix) 119894 is the index of the current security attribute(x) 119875 is full description of a case(xi) RF is a set of rules(xii) 119886 is activity 119886(xiii) INTENTION(119886) indicates that the device is going to

perform action 119886(xiv) STAT(119886) is the status of an action 119886 which can have

two values allow or deny(xv) 119896119898 119897indicates a current requirement rule(xvi) 119905 indicates a current requirement(xvii) 119877 is a set of all requirement rules(xviii) SATISFIED(119875 119877 119886) is a function which returns set of

requirement rules with satisfied conditions made onthe basis of description of a case 119875 intention 119886 andset of requirement rules 119877

(xix) RR is a set of requirement rules with satisfied condi-tions

(xx) ADD(RR SATISFIED(119875 119877 119886)) is a function whichadds results of SATISFIED(119875 119877) to the set RR

(xxi) rr[119898] is 119898th requirement rule from the set RR(xxii) OR is the order between rules from a set RR(xxiii) Req119886 is conclusion of a given requirement rule which

is a set of requirements concerning activity 119886(xxiv) req[119905] is 119905th requirement in a set Req119886


(xxv) COUNT(RR) is a functionwhich returns a number ofrequirement rules in the set RR

(xxvi) COUNT(Req119886) is a function which returns a numberof requirements in Req119886

(xxvii) 119899 is the quantity of security attributes(xxviii) rr[119909] is requirement rule 119909(xxix) 119878 is the evaluation of security attributes(xxx) EVAL is a procedure which returns evaluation of

security attributes of the device(xxxi) SAT(119878Req119886 req[119905]) is a function which returns true

if evaluation of security attribute in set 119878 meetsrequirements req[119905] from the set Req119886

(xxxii) RULE is a rule which remains after exclusion of theconflicting ones from the set RR[119894]

(xxxiii) CONC(RULE) is a functionwhich returns conclusionof a rule RULE

(xxxiv) EXE(119886) is the execution of action 119886(xxxv) VSE is a list of violated security attributes(xxxvi) NOTPOSSIBLE[119894] is a function which checks if it is

not possible to increase the level of security attribute 119894protection (eg if there are no possibilities to increasekey length)

(xxxvii) INCREASE[119894] means increasing the level of protec-tion of security attribute 119894

(xxxviii) foreach 119894 in VSE do is ldquoforeachrdquo loop for eachsecurity attribute 119894 in the list VSE do

(xxxix) do while( ) is ldquodo-whilerdquo loop

41 Algorithm 1 Adaptation Process The general algorithmresponsible for adaptation process is the main one and can bedivided into eight main steps

Step 1 In the first step the system infers the general descrip-tion of the case (on the basis of the raw facts obtainedfrom the device sensors rules and the fact-based inferencemechanism) During the inference the context guard checksif there are inconsistent indications from the sensors Ifnot the main process of adaptation of security attributesprotection level begins In the case of inconsistency betweenfacts obtained from sensors the ALARM procedure begins(Steps (1)ndash(4) in Algorithm 1)

Step 2 In the second step an estimation of quality ofprotection of a device is performed (Step (5) in Algorithm 1mechanism of QoP evaluation is described in a detailed wayin [24])

Step 3 In the next step the algorithm of the securityattributes context evaluation tests if the security attributesrsquoprotection meets the requirements based on the context inwhich the device is working (Steps (6)-(7) in Algorithm 1)

Step 4 If requirements are met the intended action isallowed If not the system proceeds to another step (Steps(8)ndash(11) in Algorithm 1)

Step 5 In the next step for each security attribute with insuf-ficient protection (failing to meet context requirements) thesystem tries to increase the level of protection of each violatedsecurity attribute (Steps (12)ndash(14) and (19) in Algorithm 1)

Step 6 If there are no possibilities of increasing the levelof protection of any of the violated security attributes thesystem denies the execution of the intended activities (Steps(15)ndash(18) in Algorithm 1)

Step 7 After the process of increasing the level of protectionthe system performs the estimation of quality of protectionand tests whether the security attributes meet the require-ments based on the context in which the device is working(Steps (20)-(21) in Algorithm 1)

Step 8 If the requirements are met the intended action canbe performed If not the system tries to increase the level ofprotection again (Steps (22)ndash(29) in Algorithm 1)

The flowchart of Algorithm 1 is presented in Figure 4

42 Algorithm 2 Security Attributes Context Evaluation Theprocess of estimation if a device working at a certain levelof quality of protection mechanisms in a given context(external and internal environment in which a device iscurrently working) fulfills security requirements of an actionwhich a user intents to perform can be performed on thebasis of described below algorithm Generally speaking themechanism of the estimation can be divided into three mainsteps

Step 1 In the first stage the system adds requirement ruleswith satisfied conditions to the set RR (Steps (1)ndash(4) inAlgorithm 2)

Step 2 In the second stage the system detects which of therequirement rules with satisfied conditions devoted to anaction which the user is going to perform are in conflictFollowing that the system defeats the conflicting rulesleaving themost suitable one (Steps (5)ndash(12) in Algorithm 2)

Step 3 In the next stage the system checks if requirementsderived from requirement rules are satisfied by a given state ofa system (described by quality of protection evaluation from[24]) If yes the algorithm returns an empty set of violatedsecurity attributes requirements If not the algorithm returnsa set of violated security attributes requirements (Steps(13)ndash(23) in Algorithm 2)


5 Case Study Context-AwareSecurity for Mobile Devices

For the purpose of presenting and explaining our modelthe case study will be illustrated by steps described inSection 4 where the algorithms are presented In orderto demonstrate our approach we present two scenarios


Corridor

OfficesProduction hall

Public area 1

Parking

Public area 2

Figure 1 The floor plan of the organizationrsquos seat

The case study incorporates the following actors employeeandmanagerThe events take place inside a working environ-ment (an organizationrsquos headquarters) presented in Figure 1The location consists of 3 rooms managerrsquos office employeesrsquoroom (working quarters) and guest roomcorridor Only themanager and employees are allowed in the manager andemployee rooms The guest roomcorridor is accessible toanyone Each room is equipped with a different access pointfor WiFi connections (signal strength is measured to predictlocation) It is forbidden to take photos in the managerrsquosroom and only managers are allowed to enter The workinghours of the organization are MondayndashFriday from 800 amto 500 pm The IT services provided by the organizationcan only be accessed by the manager and employees duringworking hours and only when located indoors (this includesthe database access) We assume that the manager and eachof the employees and guests possess a smartphone with thefollowing capabilities sensing temperature (sensor) bright-ness level (camera sensor) position (GPS AP) directionalmovement (accelerometer gyroscope) launching applica-tions network connection (WiFi) and time management(calendar clock)

51 Case Study Scenario 1 An employee uses his smart-phone during working hours to access the database (TLSis used to secure the connection) [28] He is connected tothe production hall access point The sequence of steps ofthe context-aware security analysis mechanism is presentedbelow

Algorithm 1

ALG1 Step 1 The following facts belong to the environmentof the case

1198911(user) = employee1198912(user) = guest

1198911(time) = working hours1198912(time) = nonworking hours1198911(APL) = production hall access point (safer)

First we define the facts of the case

Case 1 1198621 = 1198911(user) 1198911(time) 1198911(APL)The fact-based rules set RF

1198911(user) rarr not1198912(user)1198912(user) rarr not1198911(user)1198911(time) rarr not1198912(time)1198912(time) rarr not1198911(time)

The inference engine infers the set 1198621015840

1198621015840 = not1198912(user) not1198912(time)

hence

119875 = 1198911(user) 1198911(time) 1198911(APL) not1198912(user)not1198912(time)

During every step of the inference process the procedureof the facts consistency analysis (by a consistency guard) wasperformed It turned out that there are no conflicts so thealarm was not activated

Then we define the intention as followsThe intention of the device is to allow the employee to

access and gather data from the database (INTENTION(119886) =access and gather data from the database)

ALG1 Step 2 QoP estimation is performedby themechanismdescribed in [24]

sa1 = confidentialitysa2 = integritysa3 = authorisation


sa4 = authenticationsa5 = availabilitysa6 = anonymity

119878

= (sa1 1) (sa2 2) (sa3 3) (sa4 4) (sa5 5) (sa6 6) (3)

ALG1 Step 3 Next we evaluate if the security attributesprotectionmeets the requirements based on context in whichthe device is working Having declared 2 requirement rules

119877 = rr1 rr2rr1 = 119886 and 1198911(user) and 1198911(time) rArr Req1198861rr2 = 119886 and 1198911(time) rArr Req1198862

where

Req1198861 = req1 req2 req3 req4 req5Req1198862 = req6 req7 req8 req9 req10

and

req1 = sa1 gt 0

req2 = sa2 gt 1

req3 = sa3 gt 2

req4 = sa4 gt 3

req5 = sa5 gt 5

req6 = sa1 gt 2

req7 = sa2 gt 3

req8 = sa3 gt 4

req9 = sa4 gt 5

req10 = sa5 gt 6

execution of Algorithm 2 begins

Algorithm 2

ALG2 Step 1 Since both rules have satisfied conditions weobtain the set RR = rr1 rr2

Now we check if the QoP of the device meets require-ments caused by context

ALG2 Step 2 We assume order OR = rr1 gt rr2And therefore rr2 is excluded

RR = rr1

The remaining rule is set to be rr1Requirement rule Req1198861 becomes the binding conclusion

ALG2 Step 3 Now it is the time to check if requirementsderived from requirement rules are satisfied

For every req119909 in Req1198861

req1 in Req1198861 is satisfied since 1 gt 0 (true)




req5 in Req1198861 is not satisfied since 5 gt 5 (false)

req5 is added to the list of violated security attributes VSEReturn to Algorithm 1 with the list of violated security

attributes VSE

Algorithm 1

ALG1 Step 4 Since the requirementswere notmet we cannotallow the action yet and proceed to the next step

ALG1 Step 5 Do the following until the action 119886 is finallyallowed

For each violated security attribute in VSE do the follow-ing

We check whether it is possible to increase the level ofprotection of req5rsquos security attribute and find out that it ispossible and so increase it iteratively to 6

Next we evaluate again the security attributes increasingthe security level of req5rsquos security attribute (which is sa5)

sa1 = confidentiality

sa2 = integrity

sa3 = authorisation

sa4 = authentication

sa5 = availability

sa6 = anonymity

119878 = (sa1 1) (sa2 2) (sa3 3) (sa4 4) (sa5 5) (sa6 6) (4)

ALG1 Step 6We skip this step since it is possible to increasethe security level of req5

ALG1 Step 7 We check again for not meeting requirementsregarding security attributes by executing Algorithm 2 Sinceall the requirements are met we can move to step (8)

ALG1 Step 8 Since we did not find any violated securityattributes we allow the action 119886

The action is allowed therefore the user is finally able toestablish connection with the database and gather the datathat he needs

52 Case Study Scenario 2 An employee tries to take a pic-ture in the production hall The mobile phonersquos clock pointsat 1030 am and the device rapidly switches between twoAPs (production hall and managerrsquos room signal strengthalso switches) indicating whether the constant movementbetween the rooms is malfunction or a possible attack on thedevice


Algorithm 1


1198911(user) = employee1198912(user) = guest1198911(time) = working hours1198912(time) = nonworking hours1198911(APL) = production hall access point1198913(APL) = managerrsquos office access point


Case 2 1198622 = 1198911(user) 1198911(time) 1198911(APL) 1198913(APL)The fact-based rules set RF

1198911(user) rarr not1198912(user)1198912(user) rarr not1198911(user)1198911(time) rarr not1198912(time)1198912(time) rarr not1198911(time)1198911(APL) rarr not1198913(APL)

The inference engine infers the set 1198621015840 At each step of theforward chaining mechanism the consistency guard checksif sets 119862 and 1198621015840 are consistent

First of all the mechanism infers that 1198621015840 = not1198912(user)Since there are no inconsistencies in sets119862 and1198621015840 the enginecontinues with its work

Now the set 1198621015840 consists of two facts 1198621015840 = not1198912(user)not1198912(time) Both sets are consistent

Finally a new fact not1198913(APL) is added to the set 1198621015840

1198621015840 = not1198912 (user) not1198912 (time) not1198913 (APL) (5)

hence a conflict appears in the consistency of 1198913(APL) (itis simultaneously true and false) The ALARM procedure isinvoked and therefore all subsequent steps are omitted Theemployee gets notification about the inconsistency and thesystem lets him decide about the action 119886 (taking the picture)

53 Implementation As part of the project an actual imple-mentation of the mechanisms described in this paper wasdeveloped for the purpose of providing a proof of conceptTo make it accessible for a wide variety of interested usersan application for the most popular mobile operating system(Android) was created The version on which it is targetedis 60 however due to Androidrsquos backward compatibilityit should be functional on most previous versions of theoperating system The applicationrsquos source can be found on[29]

The application strictly follows the algorithms and rules ofthe presentedmodel in order to reason anddecide onwhetherto allow or block certain actions of the user For simplicity wehave added the functionality of preloading the settings of ourdescribed theoretical cases The applicationrsquos architecture isdepicted in Figure 2

The experiments that were performed involved a facilityequippedwith 6APs each in range and forming different net-works For both of the intentions the following experimentalscenarios were conducted

(i) The user intends to open the browser on his devicein order to view a website The intention involved 5experiments which differed by the userrsquos location anddistance to the associated APs When the user was inrange and connected to the trusted network he wasalso able to open the website else he was blockedfrom doing soThree out of five times he was in rangeand at two out of them the application evaluated anddecided successfully in all cases

(ii) The user intends to take a picture with his deviceThisintention involved 5 additional experiments whichalso differed by the same userrsquos location and distanceto the associated APs as the previous intentionWhenever the threshold of minus60 dBm or higher wasreached and the signal was strengthening the appli-cation blocked the users intention of taking a picturesince he was in the vicinity of a photo restrictedarea Four experiments were conducted with varyingdistance to the specific AP that indicated the photo-free area two of themwith better signal strength thanthat of the threshold and two with lower The fifthvariation of the experiment was conducted with anadditional fact indicating that it was simultaneouslytrue and false (another AP in range within the thresh-old) and this time it raised an inconsistency alarm asseen in Figure 3 In all five cases the final evaluationand resulting action of the application were correct

The possible outcomes of such intentions were to getcorrect permissions to the actions and raise the alarmbecauseof the inconsistencies found between facts In the case ofdisallowance of certain actions the application displays thereason and blocks the action The performed tests andevaluations validate proposedmechanisms for context-awaresecurity management for mobile devices

6 Conclusions

In the article we propose themodel of context-aware securityadjusting system which is built on the basis of propositionallogic with the aim of providing an advanced and effectivemethod for balancing the level of security of a system QoPparameters and external context factors influence the securitylevel estimation in the model Thanks to the proposedapproach the decision support system can infer whetherthe actions that the user is going to perform in a particularexternal environment meet security requirements The maincontributions of the proposed approach are summarized asfollows

(i) consistency guard a specialized module for the con-trol of the consistency of sensorycontextual datawhich recognizes and counteracts certain dangerousstates


User intention

Application

Evaluation

Profile

Action

Case loader

Device

SensorsSystem resources

Inference mechanism Consistency checker

Figure 2 Diagram depicting the applicationrsquos architecture

Figure 3 Screenshot of the application


Inference mechanismStep 1

Facts consistent

ALARM

Consistency guard

QoP estimationStep 2

Algorithm 2Step 3

Are the requirementsmet

Step 4Allow action a

Increase the level of protectionStep 5

Does the process of increasing the level

of protection failStep 6

Deny action a


Algorithm 2Step 7


Step 8

Allow action a

No

Yes

Yes

No

Set intention

Set facts Set rules

Set requirement rules

Yes

No

action a

Figure 4 Diagram depicting the subsequent steps of Algorithm 1

(ii) conflicting rules exclusion a mechanism that findscompares and eradicates clashing rules through useof the defeasible implication

(iii) formal representation describing and defining indetail all of the elements and mechanisms of themodel

(iv) holistic taking into account all of the possible con-textual data instead of just a predefined small set offactors

In order to better illustrate the process of reasoning andto provide an overall working example we prepared anddescribed case study scenarios which show various elements

of the model in action under specific circumstances Weexpect that our model will enhance the process of securityevaluation and bring about promising results

Appendix

See Figures 4 and 5

Competing Interests

The authors declare that they have no competing interests


The creation of the set ofrequirement rules with satisfied conditionsStep 1

The process of exclusion of conflicting rules fromthe set of rules with satisfied conditionsThe process returns a set of requirements which should be metStep 2

Case description P Intention action a

Evaluation of quality of protection of the system S

Requirement rules R

Requirement satisfiedStep 3

For each requirementStep 3

Add requirement to VSEStep 3

Return VSEStep 3

The process of checking if the requirementsare met by a given state of the systemStep 3

YesNo


Acknowledgments

This work is supported by the Polish National Science CentreGrant 201205BST603364

References

[1] B Ksiezopolski Z Kotulski and P Szalachowski ldquoAdaptiveapproach to network securityrdquo in Computer Networks vol 39of Communications in Computer and Information Science pp233ndash241 Springer Berlin Germany 2009

[2] B Ksiezopolski Z Kotulski and P Szalachowski ldquoOn QoPmethod for ensuring availability of the goal of cryptographicprotocols in the real-time systemsrdquo in Proceedings of theEuropean Teletraffic Seminar pp 195ndash202 2011

[3] B Ksiezopolski andZ Kotulski ldquoAdaptable securitymechanismfor dynamic environmentsrdquo Computers amp Security vol 26 no3 pp 246ndash255 2007

[4] B Ksiezopolski D Rusinek and AWierzbicki ldquoOn themodel-ing of Kerberos protocol in the Quality of ProtectionModellingLanguage (QoP-ML)rdquo Annales UMCS Informatica AI XII vol4 pp 69ndash81 2012

[5] B Ksiezopolski D Rusinek and A Wierzbicki ldquoOn the effi-ciency modelling of cryptographic protocols by means ofthe Quality of Protection Modelling Language (QoP-ML)rdquoin Information and Communication Technology vol 7804 of

LectureNotes in Computer Science pp 261ndash270 Springer BerlinGermany 2013

[6] C Ntanos C Botsikas G Rovis P Kakavas and D AskounisldquoA context awareness framework for cross-platform distributedapplicationsrdquoThe Journal of Systems and Software vol 88 no 1pp 138ndash146 2014

[7] Y Mowafi D Abou-Tair T Aqarbeh M Abilov V Dmitriyevand JMGomez ldquoA context-aware adaptive security frameworkfor mobile applicationsrdquo in Proceedings of the 3rd Interna-tional Conference on Context-Aware Systems and Applications(ICCASA rsquo14) pp 147ndash153 2014

[8] P Makris D N Skoutas and C Skianis ldquoA survey on context-aware mobile and wireless networking on networking andcomputing environmentsrsquo integrationrdquo IEEE CommunicationsSurveys amp Tutorials vol 15 no 1 pp 362ndash386 2012

[9] E Hayashi S Das S Amini J Hong and I Oakley ldquoCASAcontext-aware scalable authenticationrdquo in Proceedings of theSymposium on Usable Privacy and Security (SOUPS rsquo13) ACMMenlo Park Calif USA 2013

[10] W Li A Joshi and T Finin ldquoCAST context-aware security andtrust framework for mobile ad-hoc networks using policiesrdquoDistributed and Parallel Databases vol 31 no 2 pp 353ndash3762013

[11] A Forkan I Khalil and Z Tari ldquoCoCaMAAL a cloud-orientedcontext-aware middleware in ambient assisted livingrdquo FutureGeneration Computer Systems vol 35 pp 114ndash127 2014


[12] M Miettinen S Heuser W Kronz A Sadeghi and N AsokanldquoConXsense - Automated Context Classification for Context-AwareAccess ControlrdquoComputer andCommunications Security(ASIACCS pp 293ndash304 2014

[13] O Yılmaz and R C Erdur ldquoIConAwamdashan intelligent context-aware systemrdquo Expert Systems with Applications vol 39 no 3pp 2907ndash2918 2012

[14] K Stefanidis E Pitoura and P Vassiliadis ldquoManaging contex-tual preferencesrdquo Information Systems vol 36 no 8 pp 1158ndash1180 2011

[15] S Schefer-Wenzl and M Strembeck ldquoModeling context-awareRBAC models for business processes in ubiquitous computingenvironmentsrdquo in Proceedings of the 3rd FTRA InternationalConference on Mobile Ubiquitous and Intelligent Computing(MUSIC rsquo12) pp 126ndash131 Vancouver Canada June 2012

[16] R Ali F Dalpiaz and P Giorgini ldquoReasoning with contextualrequirements detecting inconsistency and conflictsrdquo Informa-tion and Software Technology vol 55 no 1 pp 35ndash57 2013

[17] M Younas and S Mostefaoui ldquoA new model for context-aware transactions in mobile servicesrdquo Personal and UbiquitousComputing vol 15 no 8 pp 821ndash831 2011

[18] C Perera A Zaslavsky P Christen and D GeorgakopoulosldquoContext aware computing for the internet of things a surveyrdquoIEEE Communications Surveys amp Tutorials vol 16 no 1 pp414ndash454 2014

[19] G J Nalepa and S Bobek ldquoRule-based solution for context-aware reasoning on mobile devicesrdquo Computer Science andInformation Systems vol 11 no 1 pp 171ndash193 2014

[20] L Sliman F Biennier andY Badr ldquoA security policy frameworkfor context-aware and user preferences in e-servicesrdquo Journal ofSystems Architecture vol 55 no 4 pp 275ndash288 2009

[21] A Merlo MMigliardi and L Caviglione ldquoA survey on energy-aware security mechanismsrdquo Pervasive and Mobile Computingvol 24 pp 77ndash90 2015

[22] H Prakken and G Vreeswijk ldquoLogics for defeasible argumen-tationrdquo in Handbook of Philosophical Logic D Gabbay EdKluwer Academic Publisher 2000

[23] ISOIEC ldquoInformation technologymdashsecurity techniquesmdashinformation security management systemsmdashrequirementsrdquoISOIEC 270012005 2005

[24] B Ksiezopolski T Zurek and M Mokkas ldquoQuality of protec-tion evaluation of security mechanismsrdquo The Scientific WorldJournal vol 2014 Article ID 725279 18 pages 2014

[25] H Prakken and G Sartor ldquoA dialectical model of assessingconflicting arguments in legal reasoningrdquo Artificial Intelligenceand Law vol 4 no 3-4 pp 331ndash368 1996

[26] T Zurek ldquoModel of argument from social importancerdquo inLegal Knowledge and Information Systems JURIX 2014 RHoekstra Ed vol 271 of Frontiers in Artificial Intelligence andApplications pp 23ndash28 IOS Press 2014

[27] S Modgil and H Prakken ldquoThe ASPIC+ framework for struc-tured argumentation a tutorialrdquo Argument and Computationvol 5 no 1 pp 31ndash62 2014

[28] IETF ldquoThe transport layer security (TLS) protocol v12rdquo RFC5246 IETF 2008

[29] M Mokkas ldquoThe source code of the context-aware applicationfor mobile devicesrdquo 2016 httpsgithubcomMikeMokkasContsec

Submit your manuscripts athttpwwwhindawicom

Computer Games Technology

International Journal of

Hindawi Publishing Corporationhttpwwwhindawicom Volume 2014


Distributed Sensor Networks


Advances in

FuzzySystems

Hindawi Publishing Corporationhttpwwwhindawicom

Volume 2014


ReconfigurableComputing

Hindawi Publishing Corporation httpwwwhindawicom Volume 2014


Applied Computational Intelligence and Soft Computing

thinspAdvancesthinspinthinsp

Artificial Intelligence

HindawithinspPublishingthinspCorporationhttpwwwhindawicom Volumethinsp2014

Advances inSoftware EngineeringHindawi Publishing Corporationhttpwwwhindawicom Volume 2014


Electrical and Computer Engineering

Journal of

Journal of

Computer Networks and Communications


Hindawi Publishing Corporation

httpwwwhindawicom Volume 2014

Advances in

Multimedia


Biomedical Imaging


ArtificialNeural Systems

Advances in


RoboticsJournal of



Computational Intelligence and Neuroscience

Industrial EngineeringJournal of


Modelling amp Simulation in EngineeringHindawi Publishing Corporation httpwwwhindawicom Volume 2014

The Scientific World JournalHindawi Publishing Corporation httpwwwhindawicom Volume 2014


Human-ComputerInteraction

Advances in

Computer EngineeringAdvances in



been in the focus of many researchers and some of themare described in greater detail in the next section Howeverthe main contribution of our paper is the addition of certainelements in the process of security evaluation based on amodel of propositional logic The main elements which weintroduced and that are missing from similar approaches are

(i) a context consistency analysis mechanism whichinvestigates whether provided contextual data is cor-rectly interpreted and obtained

(ii) a conflicting rule reasoning eradication mechanismto deal with issues that might occur during the rea-soning process

(iii) a holistic approach which takes into account all con-textual factors rather than just a couple of them

(iv) a formal representation of the model with definitionsof its elements and detailed reasoning algorithms

The article is divided into six sections Section 1 is anoverall introduction to the subject of context-aware securitySection 2 focuses on the comparison of similar works brieflysummarizing their main shortcomings which we intend torectify Section 3 introduces our model and familiarizes withthe definitions of its elements Section 4 describes in detailthe algorithm of the procedure while Section 5 illustratesa couple of use case scenarios to thoroughly present thereasoning process Additionally Section 6 briefly describesthe developed implementation of the model that acts as aproof of concept and finally concludes the article In theAppendix the diagrams of the proposed algorithms arepresented

2 Related Work

This section describes the state-of-the-art ideas and conceptswhich are related to the field of study There are quitemany existing models that describe context-awareness insystems However most of them lack mechanisms thatallow dynamic reasoning capable of contextual consistencyanalysis and coping with conflicting rules One of them is[6] which describes a context-awareness framework (webi-nos) allowing webinos-enabled applications to collect andprovide contextual information This information is used toenhance multiple aspects related to human-machine inter-actions of everyday life instead of being limited only toa device-centered model for context deduction There isnot however much detail provided about the mechanismof rule forming and evaluation that our approach relieson

Another article [7] proposes a context-aware securityframework which enforces the execution of mobile applica-tions inside security incubators for the purpose of controllingthe exchange of information between mobile applicationsand mobile device resources The contextual data is gatheredfrom mobile devices equipped with sensors Whenever anapplication requests access the framework analyzes the con-textual information and security configuration to decide onpolicy enforcement The method used for this analysis is the

Analytic Hierarchy Process (AHP) which is a popular choicefor policy selection decision making adaptive learning andrecommendation and feedback systems The main advantageofAHP is its ability to break down complex decision problemsinto smaller ones which enhances the reasoning processUnfortunately the article does not mention any conflicteradication mechanisms

In [8] the authors describe a new emerging researcharea referred to as the Context-Aware Mobile and WirelessNetworking (CaMoWiN) The article is basically a surveyof existing solutions from both networking and computingenvironments where context acts as a form of a ldquoglue-pointrdquothat allows for their integration As part of this work whichdeals with context evaluation (policies decision making)several frameworks are described (through omitting anyconflict solving mechanisms)

The article [9] introduces a context-aware scalableauthentication (CASA) as a means of balancing securityand usability for authentication The idea is to performauthentication by selecting a form of active authenticationbased on a combination of multiple passive factors someof which are contextual (such as location) This procedureuses a probabilistic framework as well as a naive Bayesclassifier to combine many factors calculating risk anddetermining the required level of active authentication Aswith previous solutions there are no conflict eradication orcontext consistency mechanisms involved

The article [10] describes a context-aware security andtrust framework for Mobile Ad hoc Networks (MANET)called CAST Its primary objective is to accurately classifywhether the nodes inMANETs that misbehave do so becauseof a faulty or malicious cause The main addition of thisframework is that it takes into consideration contextual datasuch as communication channel status battery status orweather conditions In addition it uses policies to detectwhether the contextual information is intentionally falsifiedor the current environmental conditions cause their reportingtomalfunction and provide incorrect data Unfortunately thearticle does not mention any methods of detecting contextinconsistencies

In [11] the authors proposed a cloud-oriented context-aware framework for ambient assisted living (AAL) calledCoCaMAAL Their model tries to address issues such as thecomplexity in management of sensor data or the derivationof contextual information as well as the constant monitoringof the activities that are performed by users The procedureis enhanced through the implementation and use of acontext management system (CMS) Similar to other worksit lacks conflicting rule and context consistency analysismechanisms

In [12] an automated context classification for context-aware access control (ConXsense) is proposed The authorsclaim this is the first framework to provide context-awarenessin access control of mobile devices which is based on contextclassification Previous solutions relied toomuch on staticallypredefined policies ConXsense is a probabilistic approachthat overcomes previous deficiencies Context is automati-cally classified throughmachine learning and context sensingrelying on their appropriate security propertiesThe approach



















3 The Model



119865 = 1198911 1198912 1198913 119891119899 (1)



where






Context-awareness








Authorization





















where











will be as follows








adds not1198912 to set 1198621015840











1198911 rarr not11989121198912 rarr not1198911




















119860 = (1198861 1198862 119886119899) (2)






where








119886























4 Algorithms



















































Corridor


Public area 1

Parking

Public area 2




Algorithm 1








1198621015840 = not1198912(user) not1198912(time)

hence









119878

= (sa1 1) (sa2 2) (sa3 3) (sa4 4) (sa5 5) (sa6 6) (3)



where


and

req1 = sa1 gt 0

req2 = sa2 gt 1

req3 = sa3 gt 2

req4 = sa4 gt 3

req5 = sa5 gt 5

req6 = sa1 gt 2

req7 = sa2 gt 3

req8 = sa3 gt 4

req9 = sa4 gt 5

req10 = sa5 gt 6


Algorithm 2




RR = rr1










attributes VSE

Algorithm 1







sa2 = integrity

sa3 = authorisation


sa5 = availability

sa6 = anonymity

119878 = (sa1 1) (sa2 2) (sa3 3) (sa4 4) (sa5 5) (sa6 6) (4)







Algorithm 1


















6 Conclusions




User intention

Application

Evaluation

Profile

Action

Case loader

Device







Facts consistent

ALARM

Consistency guard


Algorithm 2Step 3






Deny action a


Algorithm 2Step 7


Step 8

Allow action a

No

Yes

Yes

No

Set intention

Set facts Set rules


Yes

No

action a







Appendix

See Figures 4 and 5

Competing Interests







Requirement rules R




Return VSEStep 3


YesNo


Acknowledgments


References







































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in





















3 The Model



119865 = 1198911 1198912 1198913 119891119899 (1)



where






Context-awareness








Authorization





















where











will be as follows








adds not1198912 to set 1198621015840











1198911 rarr not11989121198912 rarr not1198911




















119860 = (1198861 1198862 119886119899) (2)






where








119886























4 Algorithms



















































Corridor


Public area 1

Parking

Public area 2




Algorithm 1








1198621015840 = not1198912(user) not1198912(time)

hence









119878

= (sa1 1) (sa2 2) (sa3 3) (sa4 4) (sa5 5) (sa6 6) (3)



where


and

req1 = sa1 gt 0

req2 = sa2 gt 1

req3 = sa3 gt 2

req4 = sa4 gt 3

req5 = sa5 gt 5

req6 = sa1 gt 2

req7 = sa2 gt 3

req8 = sa3 gt 4

req9 = sa4 gt 5

req10 = sa5 gt 6


Algorithm 2




RR = rr1










attributes VSE

Algorithm 1







sa2 = integrity

sa3 = authorisation


sa5 = availability

sa6 = anonymity

119878 = (sa1 1) (sa2 2) (sa3 3) (sa4 4) (sa5 5) (sa6 6) (4)







Algorithm 1


















6 Conclusions




User intention

Application

Evaluation

Profile

Action

Case loader

Device







Facts consistent

ALARM

Consistency guard


Algorithm 2Step 3






Deny action a


Algorithm 2Step 7


Step 8

Allow action a

No

Yes

Yes

No

Set intention

Set facts Set rules


Yes

No

action a







Appendix

See Figures 4 and 5

Competing Interests







Requirement rules R




Return VSEStep 3


YesNo


Acknowledgments


References







































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in







Context-awareness








Authorization





















where











will be as follows








adds not1198912 to set 1198621015840











1198911 rarr not11989121198912 rarr not1198911




















119860 = (1198861 1198862 119886119899) (2)






where








119886























4 Algorithms



















































Corridor


Public area 1

Parking

Public area 2




Algorithm 1








1198621015840 = not1198912(user) not1198912(time)

hence









119878

= (sa1 1) (sa2 2) (sa3 3) (sa4 4) (sa5 5) (sa6 6) (3)



where


and

req1 = sa1 gt 0

req2 = sa2 gt 1

req3 = sa3 gt 2

req4 = sa4 gt 3

req5 = sa5 gt 5

req6 = sa1 gt 2

req7 = sa2 gt 3

req8 = sa3 gt 4

req9 = sa4 gt 5

req10 = sa5 gt 6


Algorithm 2




RR = rr1










attributes VSE

Algorithm 1







sa2 = integrity

sa3 = authorisation


sa5 = availability

sa6 = anonymity

119878 = (sa1 1) (sa2 2) (sa3 3) (sa4 4) (sa5 5) (sa6 6) (4)







Algorithm 1


















6 Conclusions




User intention

Application

Evaluation

Profile

Action

Case loader

Device







Facts consistent

ALARM

Consistency guard


Algorithm 2Step 3






Deny action a


Algorithm 2Step 7


Step 8

Allow action a

No

Yes

Yes

No

Set intention

Set facts Set rules


Yes

No

action a







Appendix

See Figures 4 and 5

Competing Interests







Requirement rules R




Return VSEStep 3


YesNo


Acknowledgments


References







































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in









will be as follows








adds not1198912 to set 1198621015840











1198911 rarr not11989121198912 rarr not1198911




















119860 = (1198861 1198862 119886119899) (2)






where








119886























4 Algorithms



















































Corridor


Public area 1

Parking

Public area 2




Algorithm 1








1198621015840 = not1198912(user) not1198912(time)

hence









119878

= (sa1 1) (sa2 2) (sa3 3) (sa4 4) (sa5 5) (sa6 6) (3)



where


and

req1 = sa1 gt 0

req2 = sa2 gt 1

req3 = sa3 gt 2

req4 = sa4 gt 3

req5 = sa5 gt 5

req6 = sa1 gt 2

req7 = sa2 gt 3

req8 = sa3 gt 4

req9 = sa4 gt 5

req10 = sa5 gt 6


Algorithm 2




RR = rr1










attributes VSE

Algorithm 1







sa2 = integrity

sa3 = authorisation


sa5 = availability

sa6 = anonymity

119878 = (sa1 1) (sa2 2) (sa3 3) (sa4 4) (sa5 5) (sa6 6) (4)







Algorithm 1


















6 Conclusions




User intention

Application

Evaluation

Profile

Action

Case loader

Device







Facts consistent

ALARM

Consistency guard


Algorithm 2Step 3






Deny action a


Algorithm 2Step 7


Step 8

Allow action a

No

Yes

Yes

No

Set intention

Set facts Set rules


Yes

No

action a







Appendix

See Figures 4 and 5

Competing Interests







Requirement rules R




Return VSEStep 3


YesNo


Acknowledgments


References







































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in





















119860 = (1198861 1198862 119886119899) (2)






where








119886























4 Algorithms



















































Corridor


Public area 1

Parking

Public area 2




Algorithm 1








1198621015840 = not1198912(user) not1198912(time)

hence









119878

= (sa1 1) (sa2 2) (sa3 3) (sa4 4) (sa5 5) (sa6 6) (3)



where


and

req1 = sa1 gt 0

req2 = sa2 gt 1

req3 = sa3 gt 2

req4 = sa4 gt 3

req5 = sa5 gt 5

req6 = sa1 gt 2

req7 = sa2 gt 3

req8 = sa3 gt 4

req9 = sa4 gt 5

req10 = sa5 gt 6


Algorithm 2




RR = rr1










attributes VSE

Algorithm 1







sa2 = integrity

sa3 = authorisation


sa5 = availability

sa6 = anonymity

119878 = (sa1 1) (sa2 2) (sa3 3) (sa4 4) (sa5 5) (sa6 6) (4)







Algorithm 1


















6 Conclusions




User intention

Application

Evaluation

Profile

Action

Case loader

Device







Facts consistent

ALARM

Consistency guard


Algorithm 2Step 3






Deny action a


Algorithm 2Step 7


Step 8

Allow action a

No

Yes

Yes

No

Set intention

Set facts Set rules


Yes

No

action a







Appendix

See Figures 4 and 5

Competing Interests







Requirement rules R




Return VSEStep 3


YesNo


Acknowledgments


References







































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in























4 Algorithms



















































Corridor


Public area 1

Parking

Public area 2




Algorithm 1








1198621015840 = not1198912(user) not1198912(time)

hence









119878

= (sa1 1) (sa2 2) (sa3 3) (sa4 4) (sa5 5) (sa6 6) (3)



where


and

req1 = sa1 gt 0

req2 = sa2 gt 1

req3 = sa3 gt 2

req4 = sa4 gt 3

req5 = sa5 gt 5

req6 = sa1 gt 2

req7 = sa2 gt 3

req8 = sa3 gt 4

req9 = sa4 gt 5

req10 = sa5 gt 6


Algorithm 2




RR = rr1










attributes VSE

Algorithm 1







sa2 = integrity

sa3 = authorisation


sa5 = availability

sa6 = anonymity

119878 = (sa1 1) (sa2 2) (sa3 3) (sa4 4) (sa5 5) (sa6 6) (4)







Algorithm 1


















6 Conclusions




User intention

Application

Evaluation

Profile

Action

Case loader

Device







Facts consistent

ALARM

Consistency guard


Algorithm 2Step 3






Deny action a


Algorithm 2Step 7


Step 8

Allow action a

No

Yes

Yes

No

Set intention

Set facts Set rules


Yes

No

action a







Appendix

See Figures 4 and 5

Competing Interests







Requirement rules R




Return VSEStep 3


YesNo


Acknowledgments


References







































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in


































Corridor


Public area 1

Parking

Public area 2




Algorithm 1








1198621015840 = not1198912(user) not1198912(time)

hence









119878

= (sa1 1) (sa2 2) (sa3 3) (sa4 4) (sa5 5) (sa6 6) (3)



where


and

req1 = sa1 gt 0

req2 = sa2 gt 1

req3 = sa3 gt 2

req4 = sa4 gt 3

req5 = sa5 gt 5

req6 = sa1 gt 2

req7 = sa2 gt 3

req8 = sa3 gt 4

req9 = sa4 gt 5

req10 = sa5 gt 6


Algorithm 2




RR = rr1










attributes VSE

Algorithm 1







sa2 = integrity

sa3 = authorisation


sa5 = availability

sa6 = anonymity

119878 = (sa1 1) (sa2 2) (sa3 3) (sa4 4) (sa5 5) (sa6 6) (4)







Algorithm 1


















6 Conclusions




User intention

Application

Evaluation

Profile

Action

Case loader

Device







Facts consistent

ALARM

Consistency guard


Algorithm 2Step 3






Deny action a


Algorithm 2Step 7


Step 8

Allow action a

No

Yes

Yes

No

Set intention

Set facts Set rules


Yes

No

action a







Appendix

See Figures 4 and 5

Competing Interests







Requirement rules R




Return VSEStep 3


YesNo


Acknowledgments


References







































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in





119878

= (sa1 1) (sa2 2) (sa3 3) (sa4 4) (sa5 5) (sa6 6) (3)



where


and

req1 = sa1 gt 0

req2 = sa2 gt 1

req3 = sa3 gt 2

req4 = sa4 gt 3

req5 = sa5 gt 5

req6 = sa1 gt 2

req7 = sa2 gt 3

req8 = sa3 gt 4

req9 = sa4 gt 5

req10 = sa5 gt 6


Algorithm 2




RR = rr1










attributes VSE

Algorithm 1







sa2 = integrity

sa3 = authorisation


sa5 = availability

sa6 = anonymity

119878 = (sa1 1) (sa2 2) (sa3 3) (sa4 4) (sa5 5) (sa6 6) (4)







Algorithm 1


















6 Conclusions




User intention

Application

Evaluation

Profile

Action

Case loader

Device







Facts consistent

ALARM

Consistency guard


Algorithm 2Step 3






Deny action a


Algorithm 2Step 7


Step 8

Allow action a

No

Yes

Yes

No

Set intention

Set facts Set rules


Yes

No

action a







Appendix

See Figures 4 and 5

Competing Interests







Requirement rules R




Return VSEStep 3


YesNo


Acknowledgments


References







































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in




Algorithm 1


















6 Conclusions




User intention

Application

Evaluation

Profile

Action

Case loader

Device







Facts consistent

ALARM

Consistency guard


Algorithm 2Step 3






Deny action a


Algorithm 2Step 7


Step 8

Allow action a

No

Yes

Yes

No

Set intention

Set facts Set rules


Yes

No

action a







Appendix

See Figures 4 and 5

Competing Interests







Requirement rules R




Return VSEStep 3


YesNo


Acknowledgments


References







































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in




User intention

Application

Evaluation

Profile

Action

Case loader

Device







Facts consistent

ALARM

Consistency guard


Algorithm 2Step 3






Deny action a


Algorithm 2Step 7


Step 8

Allow action a

No

Yes

Yes

No

Set intention

Set facts Set rules


Yes

No

action a







Appendix

See Figures 4 and 5

Competing Interests







Requirement rules R




Return VSEStep 3


YesNo


Acknowledgments


References







































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in





Facts consistent

ALARM

Consistency guard


Algorithm 2Step 3






Deny action a


Algorithm 2Step 7


Step 8

Allow action a

No

Yes

Yes

No

Set intention

Set facts Set rules


Yes

No

action a







Appendix

See Figures 4 and 5

Competing Interests







Requirement rules R




Return VSEStep 3


YesNo


Acknowledgments


References







































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in








Requirement rules R




Return VSEStep 3


YesNo


Acknowledgments


References







































Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in





























Advances in

FuzzySystems


Volume 2014












Journal of

Journal of





Advances in

Multimedia


Biomedical Imaging



Advances in


RoboticsJournal of










Advances in



research article on the modelling of context-aware

Documents