Privacy Enhancing Data Access Control for Ambient Assisted Living

Hendrik Kuijs

, Timo Bayer

, Christoph Reich

, Martin Knahl

and Nathan Clarke

Institute for Cloud Computing and IT Security, Furtwangen University, Furtwangen, Germany

Centre for Security, Communications and Network Research, Plymouth University, Plymouth, U.K.

Keywords:

Privacy, Data Flow, OSGi, Access Control, Context Aware, Ambient Assisted Living.

Abstract:

As private data is key to applications in the ﬁeld of Ambient Assisted Living, access control has to be in place

to regulate data ﬂows within the environment and to preserver the privacy of a user. We present a data access

control system based on an easy to understand policy language with the ability to be extended by context

information. Context information are enabling applications in the ﬁeld of Ambient Assisted Living to adapt

their behaviour to temporal, emergency or environmental conditions. The system is able to monitor and control

data ﬂows in OSGi environments by proxy services, without the need of modifying the core platform or the

service logic of bundles. This is necessary to inform data subjects, to enable the data subject to control the

environment and to enforce data access policies that are compatible with legal requirements.

1 INTRODUCTION

Ambient Assisted Living (AAL) emerged out of tech-

nologies which are known as Ambient Intelligence

(AMI), the technological foundation for sensitive and

adaptive environments that have the ability to respond

to actions of persons or real world objects and cater

for their needs. This development is fostered by two

social and political phenomena: The increasing aver-

age life expectancy and a decrease of birth-rate leads

to a continuously shrinking proportion of the young

working population in developed countries world-

wide (United Nations, 2001). Politics try to compete

with this trend by introducing programs for new nurs-

ing or day-care facilities (Llena-Nozal et al., 2011).

But without trained personnel and already existing

facilities one key concept is to minimize the needed

time-span for professional care facilities by introduc-

ing technology in the known living environment of

the target group. Surveys show that this trend is sup-

ported by elderly people who want to stay at home as

long as possible (Grauel and Spellerberg, 2007). With

the introduction of supporting systems in the home of

the elderly, new concerns arise about the protection of

privacy. Focus groups and users are feeling observed

and do not want an uncontrollable surveillance sys-

tem which they don’t trust incorporated in their liv-

ing environment (Dario and Cavallo, 2014, pp. 89

ff.)(Rosencrantz et al., 2015).

In our work we show a system that can raise trans-

parency and hand over the control on the private data

collected and processed in an AAL system back to the

user.

Section 2 presents related work in the ﬁeld of pri-

vacy for AAL and data security in OSGi, the main

middleware for platforms in AAL. In Section 3 a new

solution for data access management is presented in

three parts: A new module for monitoring and con-

trol in OSGi, the access control system and the ba-

sics of the new privacy policy. An evaluation of the

main concepts of the policy language and access con-

trol system is shown in Section 4, followed by con-

clusions and remarks on future work in Section 5.

2 RELATED WORK

The AALIANCE (Broek et al., 2010) determined in

their AAL Roadmap of 2010 that in existing AAL

systems a huge amount of data is collected by sen-

sors in the living environment to assist the user in his

daily life. These data (vital data, location data) is then

aggregated with other information (from communica-

tion systems, organizational tools, or household ap-

pliances) to draw conclusions about the current situ-

ation, the health state and the well-being of the user.

In many cases this information is made available to

relatives and informal caregivers (primary group of

stakeholders in AAL (Dario and Cavallo, 2014)), or

professional care providers, e.g. doctors or nurses

(secondary group of stakeholders).

448

Kuijs, H., Bayer, T., Reich, C., Knahl, M. and Clar ke, N.

Privacy Enhancing Data Access Control for Ambient Assisted Living.

DOI: 10.5220/0007735804480455

In Proceedings of the 9th International Conference on Cloud Computing and Services Science (CLOSER 2019), pages 448-455

ISBN: 978-989-758-365-0

2.1 Privacy in Ambient Assisted Living

According to (Memon et al., 2014) privacy preserva-

tion is not yet seen as a quality attribute of AAL sys-

tems. Although security (encryption and access con-

trol) is of importance for acceptability among the end-

users, other major quality attributes are usability, re-

liability, maintainability, efﬁciency, safety, accuracy,

and dependability.

Braun et al. show in their study that the target

audience emphasize that they have a sense of shame

when confronted with a video system, but are at the

same time willing to accept sharing of personal data

with other entities in AAL environments (Braun et al.,

2016). In their view this could be due to the abstract

nature of the term data privacy, but the immediate

feeling of shame. However a loss of data to criminal

subjects is seen as a real threat by the target audience.

J. van Heek et. al directly focus on data security

and privacy in their study (van Heek et al., 2017). Al-

though the average needs for data security and pri-

vacy were on a moderate level with regard to all in-

terviewed participants, they stated that they wanted to

have control over the access of their data, see data se-

curity as an important attribute for AAL, and realize

the possibility of abuse of leaked data. The own pri-

vacy of the participants is as important to them as the

privacy of others and they want to control their own

privacy.

Stutz et al. deﬁne measures that have to be imple-

mented by system developers and providers to sup-

port data protection and information security in AAL

systems (Stutz et al., 2016). Their work is based on

the approach of Privacy by Design and by Default

(Cavoukian, 2010), that is also included as a central

concept in the EU General Data Protection Regulation

(The European Parliament and the Council of the Eu-

ropean Union, 2016). They propose a consent based

system where a user has to be informed about the data

usage and no data is allowed to be transferred, stored

or processed without the consent of the user.

In this work a model and a ﬁrst implementation for

data protection and data ﬂow control in AAL systems

is presented based on OSGi.

2.2 Data security in OSGi

The AALIANCE consortium recommends using a

modular and open approach for new services and soft-

ware in the context of AAL (AALIANCE, 2010). For

remote management for software upgrades and in-

stalling new software to an existing platform, OSGi

is seen as the most adopted middleware in AAL en-

vironments The central feature of OSGi is the pos-

sibility to include, update, start and stop services as

modular bundles during runtime without the need for

a restart of the whole environment. Existing systems

based on OSGi are among others universAAL (Sadat

et al., 2013), openAAL (Wolf et al., 2010) or Soprano

(Schmidt et al., 2009).

The downside to the ﬂexible extensibility and

adoptability of OSGi based systems is the vulnera-

bility to malicious software extensions that can vi-

olate security concepts or disrupt the whole system.

Huang et al. propose an Advanced OSGi Security

Layer (AOSL) to audit bundles and detect anomalies

during runtime (e.g. denial-of-service attacks by ex-

ceeding load or thread-duration) (Huang et al., 2007).

A similar way of anomaly detection is presented by

Wang et al. (Wang et al., 2012): By using a Service

Monitor and JVM Monitor and service proxies they

keep track of the execution time and memory con-

sumption of services to provide assistance in ﬁnding

anomalies. Although the presented work does not fo-

cus in anomalie detection, service proxies are used to

intervene in the platform processes without the need

of modifying the deployed bundles.

A solution of Security-by-Contract (SxC) in OSGi

(Gadyatskaya et al., 2012) is presented by Gady-

atskaya et al. The manifest-ﬁle of each bundle is ex-

tended by a contract that contains information about

the functional requirements and the accessibility by

other bundles of the OSGi environment and is evalu-

ated during deployment by the Platform Security Pol-

icy. If the evaluation fails and contracts are incom-

patible with the current platform policy, the bundle

will not be deployed. Putting initial requirements and

further descriptive entries in the manifest-ﬁle is also

of interest in the presented approach to further detail

the purpose and the implications of a new installed

service. Parrend et al. present a Privacy-Aware Ser-

vice Integration (Parrend et al., 2007). They propose a

framework for ensuring privacy policy compliant ser-

vices and a metadata language for privacy checks in

an OSGi environment. The service provider has to

ensure that all offered services are secure and tested

prior installation and that they provide the informa-

tion needed by the platform during deployment and

for privacy evaluations. Service restrictions are then

realized by so called RestrictedContext: Bundles are

only able to access other bundles they are allowed to

discover by policy.

Due to the believe that it is not easy to control

both, the service provider and the client, in a way

to guarantee a sound, secure and privacy consistent

platform, the presented solution has lesser necessary

preparatory work and basic assumptions.

Privacy Enhancing Data Access Control for Ambient Assisted Living

449

3 DATA ACCESS MANAGEMENT

The security and privacy enhanced cloud infrastruc-

ture for Ambient Assisted Living (SpeciAAL) is a

Platform as a Service (PaaS) approach for an AAL en-

vironment that is based on OSGi. (Kuijs et al., 2015;

Kuijs et al., 2016). As personal information about the

user is the key data for AAL, security measures for

data protection (e.g. data access, access roles and pri-

vacy policies) have to be implemented to secure and

monitor data access and data transfer at all time.

To protect privacy, design strategies can be used

when designing a system from scratch. In gen-

eral, a design strategy describes an abstract approach

to achieving a particular design goal. A listing of

eight different strategies is presented by the European

Union Agency for Network and Information Security

(ENISA) (Danezis et al., 2015). In addition, each

strategy identiﬁes design patterns for implementation.

In our approach we focus on three deﬁned strategies:

• Inform: Data subjects should always be informed

about which information is processed, for what

purpose, and by which means when using a sys-

tem. This necessary information includes the

ways of data protection, the overall security of a

system, possible sharing of data with third parties,

and personal data access rights. This strategy is

supported by different policy languages, mecha-

nisms, and frameworks.

• Control: To gain user consent for processing of

personal data the user has to have agency to view,

update or delete personal data at any given time.

Above this a user can control and deﬁne the data

that is processed and whether to use a certain sys-

tem. Design Patterns for establishing consent are

a user centric identity management, and end-to-

end encryption support control. An example for

intervenability is a sensor in a smart home envi-

ronment that can be deactivated during a visit of

friends for privacy reasons.

• Enforce: To ensure that a privacy policy is in

place, there should be always be one enforced by

default that is compatible with legal requirements.

This strategy can be implemented by access con-

trol, or privacy rights management.

The described architecture is based on two main com-

ponents. A OSGi component that is enabling the user

to monitor and control the environment and the autho-

rization system. On top of these we developed a pol-

icy language that is (as described earlier) able to be

enriched with context conditions to support the spe-

cial needs of users in AAL environments.

3.1 Monitoring

In order to protect the potentially personal data in-

side the platform, monitoring has to be initially im-

plemented at all critical points. It must take place

between installed bundles, between bundles and the

database, but also at interfaces to other parts of the

AAL system (e.g., web-interfaces or interfaces to ex-

ternal services). In the presented approach this is re-

alized by a central protection bundle, that automati-

cally creates a proxy service during the deployment

of a bundle in OSGi that mirrors the original bundle

with all its methods. By injecting logging facilities

inside the proxied bundles it is possible to log access

to the data source of the service but also indirect ac-

cess between bundles and to external interfaces. The

gathered information of the logging implementation

can then be stored and presented to the user in a sim-

pliﬁed and non-technical way. In a second step these

proxies can be extended by decision logic to allow or

deny communication with other services within the

platform. This enables us to have detailed control

over the data ﬂows inside the environment without

the need to have full control of all installed bundles

before deployment or doing security checks and code

inspections of all bundles to whitelist them for use in

the AAL environment.

The OSGi-Core speciﬁcation describes an Event

Listener Hook, to respond to events in the Service

Registry (The OSGi Alliance, 2014, Chapter 55.4).

This hook is used to inject program code in the service

registration process. The automatic generation of the

proxy is triggered and by the use of Java Reﬂection

(Glen McCluskey, 1998) a proxy class is generated

that acts on behalf of the actual class and accepts their

calls. It offers the same methods as the original class

and can be extended by code functionality to log its

activities and control its behaviour. To ensure that the

proxy and not the original bundle is called by other

bundles in the OSGi environment, the proxy is pri-

oritized higher in the Service Registry of OSGi (The

OSGi Alliance, 2014).

This is realized by implementing a Component

Protection Bundle within the OSGi environment and

allows us to apply the generated access rules to the

system. Figure 1 shows the sequence diagram of the

access between a caller bundle and the service bun-

dle through the presented proxy mechanism. In this

example the requested name is only accessible if the

access is authorized inside the Proxy Service.

CLOSER 2019 - 9th International Conference on Cloud Computing and Services Science

450

Figure 1: Sequence diagram for access control.

3.2 Access Control

To realize the design strategies ”control” and ”en-

force” (Danezis et al., 2015) the presented approach

is an access control system based on the established

XACML reference architecture (Kafura, 2004). The

Figure 2: Architecture overview of the access control sys-

tem.

structure of the developed system, as shown in Figure

2, is divided into two responsibilities, the creation and

administration of authorization policies and the secur-

ing of the access patterns deﬁned during a request for

stored data. A particular focus of the developed plat-

form was to ensure the highest possible interoperabil-

ity for the integration of a large number of individual

services. In order to keep it simple to operate for the

target audience, the system also has a central user in-

terface for administering the policies. The purpose of

the user interface is to provide the user with the high-

est possible level of transparency and comprehensive

control over the granted authorizations while abstract-

ing the technical details. Thus, the user is always

able to manipulate existing permissions, remove them

when deactivating a service or grant new permissions.

The PolicyManagement module contains the sub-

components for creating and managing authorization

policies. The creation of a policy can be done via

user-friendly input forms within the user interface

or by importing pre-deﬁned XML ﬁles. In the case

of form-based authoring, the information about the

authorizations to be granted is provided via HTTP

endpoints of the sub-component PolicyCreator. Us-

ing the subcomponent PolicyValidator, these are ﬁrst

checked for their semantic correctness and then a cor-

responding XML ﬁle is generated. However, a par-

ticular focus of the implementation of this compo-

nent is the ability to integrate pre-deﬁned authoriza-

tion policies by allowing services to provide them di-

rectly to the user during service deployment. To pre-

serve transparency and control for the user, the access

rules deﬁned within the XML ﬁles are initially inter-

preted by the platform and presented in a readable

form within the user interface. The user thus has the

option of easily disabling individual rules or adapting

them to his wishes. One speciality of the user inter-

face is the possbility of adding context to the access

rules, that may permit the access of data or function-

ality only at a special time, a special location or in

special occasions. If new policies are inserted in this

way as an XML ﬁle, an additional review of syntactic

correctness will take place.

The created policies are stored within the Policy-

Store, in which the contents of the authorization poli-

cies are transferred to a relational data model for high-

performance and targeted querying. Due to the de-

ﬁned interfaces, the platform supports both local and

remote database systems, which can be used individ-

ually depending on the desired form of the platform.

Since the allowed access patterns can also change

over time, an additional option for manipulating ex-

isting policies has been integrated into the platform.

This is done via the component PolicyUpdater. Ma-

nipulating existing policies is equivalent to creating

them by updating existing information either through

user interface forms or directly within the correspond-

ing XML ﬁles. Such a case has relevance both in the

delivery of a new version of the service concerned and

in the need for manual adaptation of the rules by the

user. The associated component also provides this

functionality via HTTP endpoints, which, after suc-

cessful completion, result in an update of PolicyStore

data. Because of the resulting interfaces, it is also pos-

sible to integrate this functionality into higher-level

applications, such as a central instance for managing

all permissions within a given domain.

The other part of the system is responsible for

the enforcement of the created authorization policies

within the module PolicyEnforcement. An entity at-

tempts to access the stored and protected data within

the DataStore by specifying its own identity, the de-

sired resource and the respective access pattern by

Privacy Enhancing Data Access Control for Ambient Assisted Living

451

calling the deﬁned HTTP endpoints of the Request-

Validator. The indication of the identity has particu-

lar relevance to counteract possible abuse. For this,

a certiﬁcate-based matching of the identities within

the RequestValidator takes place. If the given identity

can be conﬁrmed, the request is forwarded to the Poli-

cyEnforcer component. Using the stored policies, this

component checks whether the requested access cor-

responds to the deﬁned authorizations and, if positive,

responds with the requested data. In the negative case,

access to the data is denied. The veriﬁcation of the

permitted access patterns is done in a similar way to a

conventional ﬁrewall systems in decreasing granular-

ity. As soon as a corresponding rule has been found,

access is immediately permitted or denied. This al-

lows for efﬁcient processing of data access by consid-

ering only a subset of all rules. If the data access is

permitted, the data can be queried by use of the con-

nector component of the respective persistence media.

3.3 Privacy Policy

The privacy policies that are currently discussed, are

the Platform for Privacy Preferences (P3P) (Cranor

et al., 2006), S4P (Becker et al., 2010), and SIMple

Privacy Language (SIMPL)(le M

etayer, 2009). P3P

describes privacy information of websites, such as ed-

itor information, collected data, dispute scenarios and

retention time of data. S4P on the other hand is used

for privacy descriptions of services and what personal

information is used for what purpose. SIMPL is used

to specify preferences and policies with a small sub-

set of English. Only a small part is already speciﬁed

for future use and it is not easy to comprehend for hu-

mans. To keep the policies in a natural language and

Figure 3: Proposed privacy policy based on 5W1H ques-

tions.

easy to understand for the target group of AAL the

approach is to give answers to the 5W1H questions

(shown in Figure 3). On the left side the questions are

listed (each followed by a corresponding example),

divided in a service description and access description

part. On the right side the technical implementations

and corresponding conﬁguration options are shown.

Title and Description can be found in the manifest-

ﬁle of a bundle, data deﬁnes the accessed data cate-

gory of the information to be processed by the ser-

vice, and the Access-Rights are based on the CRUD

acronym. Special to our use case in AAL is the possi-

bility to add context to each policy. In this early stage

we are supporting environment based and temporal

context, where environment considers the location of

the user, external inﬂuences, or emergency situations.

Temporal context-based access could be periodic, e.g.

during working hours on week-days, to preserver the

users privacy during night and on weekends.

To put it in natural language:

An entity is given access to data for some deﬁned task,

if the particular context applies - otherwise access is

forbidden.

This ﬂexibility leads to very ﬁne granular access

control mechanisms that can be applied by applying

our policy language.

The basis of our proposed access control system is

the deﬁnition of the authorization policy. The chosen

structure of the policy is based on the lightweight rep-

resentation of the eXtensible Access Control Markup

Language (XACML) (Kafura, 2004). XACML is a

declarative, attribute-based markup language for the

presentation of authorization policies and is charac-

terized in particular by its high interoperability, ex-

tensibility and the resulting general validity. The main

aspect of the deﬁnition of an authorization policy are

the data to be protected, which vary depending on the

speciﬁc application scenario, the sensitivity and pur-

pose. To efﬁciently map this variability, the deﬁnition

of an authorization policy is based on the requesting

entity. This design choice results in increased ﬂexibil-

ity in which new services can be added or their priv-

ileges can be revoked or manipulated without global

impact.

Figure 4: Monitoring data access in a distributed OSGi en-

vironment.

CLOSER 2019 - 9th International Conference on Cloud Computing and Services Science

452

This is depicted by the attribute Subjects shown

in Figure 4. In addition to deﬁning the services in-

volved, a policy includes a variable set of rules that

are used to determine the desired access permissions.

A rule always refers to a concrete resource that can

be further restricted by specifying a Category for ﬁne

granular authorization assignment. In a ﬁrst attempt

to categorize the data, the main concepts of the im-

plemented ontology are used (Fredrich et al., 2014):

Personal information, contacts, capabilities, prefer-

ences, interests, activities, health information, educa-

tion and environment. The heart of such a deﬁned rule

is the attribute Actions. Within this the permitted ac-

cess patterns can be deﬁned (according to the CRUD

acronym).

To ensure context-sensitive access authorizations,

the deﬁned rules can be supplemented with additional

conditions by means of the Context attribute. The

available conditions are deﬁned by the Privacy Policy

and include, for example, mapping time- or location-

dependent access patterns. In the presented authoriza-

tion policy includes a location restriction of the per-

mitted accesses.

The default behavior of the developed solution

prevents any data access without an appropriate pol-

icy, which is why all access patterns of a service must

be deﬁned within a corresponding rule. The indi-

vidual rules are interpreted sequentially and therefore

have to be deﬁned in descending access granularity.

The described structure of an authorization policy can

be arbitrarily extended to represent more complex ac-

cess authorizations and has the possibility to be con-

verted into a format conforming to the XACML spec-

iﬁcation that provides complete interoperability with

deviating implementations.

4 EVALUATION

This section is divided in two parts. First, the applica-

tion of the policy language is clariﬁed with three ex-

amples. After this it is examined if the overall system

meets the functional and non functional requirements

for an access control system in AAL.

4.1 Application of Policy

The ﬁrst example is an online medication plan, that is

connected with an drug dispenser. The three informa-

tion that are accessible for this service are: the sched-

ule for the drug ingestion, the information whether

or not the drugs have been taken, and the reason for

the medication. The user always has the full access

on his own data. Informal caregivers (e.g. a neigh-

bor) may have access to the schedule (name and time

to take the drug), professional caregivers (e.g. nurses

or doctors) also know the reason for the medication

and are allowed to control the taking of the drugs, but

only (context dependency) if they are visiting the pa-

tient. Figure 5 shows the example and the granularity

of access rights, where the ”if...” icon is indicating the

described context based attribute to the access policy.

Figure 5: Examples for policies based on three groups of

stakeholders.

In our second example a nursing service has the

right to access all values of a heart rate sensor only

when accessing the system from within the users

home (e.g. at the users own terminal during a daily

visit). Otherwise the access rights only permit the ac-

cess of average values. The informal caregiver has no

rights to access the data, but this can be overridden

by critical values. In this case the contextual portion

of the access right could be set to in emergency situa-

tions (see Figure 5).

Our third example is based on a location tracking

service, that is able to indicate, if the user is at home,

moving inside his home, and can show his location. in

this example all stakeholders have the right to see if

the user is at home, professional caregiver are allowed

to know if the user is moving during weekdays, and

informal caregivers are allowed to access the location

of the user in case of an emergency.

These brief examples show the ﬂexibility of our

developed data access policy language.

4.2 Compliance with Requirements

The Access Control component is able to meet differ-

ent functional (F1 - F5) and non-functional require-

ments (NF1- NF3) that are brieﬂy described below:

Privacy Enhancing Data Access Control for Ambient Assisted Living

453

F1 Introduction of a Central Control Authority

for the Regulation of Access: The main focus

of the development of the access control system

is the possibility to control all access to the stored

data of the user. To make this possible, the plat-

form is extended by a unit to control all data ac-

cess. Since the accesses are made exclusively

via the deﬁned interfaces of the system, the data

stores and data sources can be completely decou-

pled from the serving services.

F2 Uniﬁed Integration of Variable Data Sources:

The variety of possible data sources, such as

health gauges or recording the user’s temporary

environmental conditions, requires the deﬁnition

of common interfaces for the persistence of the

information. Thus, the data sources may use

the functionality of the platform to store their

recorded data, regardless of the persistence tech-

nology used. In addition to increased interoper-

ability, this enables a ﬂexible exchange of tech-

nologies

F3 Possibility of Finely Granular Deﬁnition of the

Permitted Access Patterns: Since the access

management on the basis of the data categories of-

ten has no satisfactory granularity, it is necessary

to subdivide these further. Thus, the deﬁned pol-

icy language always offers the possibility of as-

signing individual subcategories.

F4 Deﬁnition of Context based Allowed Accesses:

The allowed data accesses can vary greatly de-

pending on the service in their requirements. The

high ﬂexibility of the authorization policies used

to regulate the access allows an individual deﬁni-

tion of speciﬁc access rules, which go far beyond

the usual CRUD operations in this environment.

F5 User-friendly Deﬁnition and Manipulation of

Authorization Policies: According to the target

group of the developed system, the simple usage

is another requirement. Since the used structure of

the authorization policies is primarily optimized

for efﬁcient machine readability, the system is ex-

tended by a natural language deﬁnition of the per-

mitted access patterns.

NF1 Lightweight: When operating on resource-poor

hardware, it must not be restricted in its function-

ality. This requirement is fulﬁlled by the stream-

lined structure of the authorization policies as well

as a lightweight and individual implementation

for machine processing.

NF2 Interoperability: The Access Control compo-

nent enables the integration of versatile data

sources and intelligent systems, as well as the con-

sistent use of the platform by the requesting ser-

vices. The services can access the platform via

deﬁned HTTP endpoints, creating a variety of in-

tegration options, such as the use of mobile device

applications or web applications.

NF3 Extensibility: Due to the generic structure of the

platform, a variety of application areas are pos-

sible. In order to meet the speciﬁc requirements

of the respective domains, the implementation is

based on a modular structure. This provides clear

interfaces between the modules, which can thus

be extended by adaptation or additional modules.

5 CONCLUSION AND FUTURE

WORK

The presented work is an access control component

in a platform for AAL that consists out of three main

parts: An OSGi mechanism to intervene in the com-

munication process of bundles and have the ability to

monitor and control data ﬂows on service level, an ac-

cess control system to manage access rights based on

rules, and a policy language to deﬁne these rules, that

is extended by context to better suit the requirements

of AAL use cases.

Although ﬁrst tests of the presented implemen-

tation seem promising, a larger ﬁeld test with focus

groups and thorough performance tests are still to be

carried out. One still missing part is the preparation of

user friendly logging information to further enhance

transparency of data ﬂows.

REFERENCES

AALIANCE (2010). Ambient Assisted Living Roadmap -

AALIANCE Project - Deliverable 2.7. chapter En-

abling T, pages 95–96.

Becker, M., Malkis, A., and Bussard, L. (2010). S4P: A

generic language for specifying privacy preferences

and policies. Microsoft Research, pages 0–35.

Braun, A., Kirchbuchner, F., and Wichert, R. (2016). Ambi-

ent Assisted Living. In eHealth in Deutschland, pages

203–222. Springer Berlin Heidelberg, Berlin, Heidel-

berg.

Broek, G. v. d., Cavallo, F., Odetti, L., and Wehrmann,

C. (2010). AALIANCE Ambient Assisted Living

Roadmap. In Ambient Intelligence and Smart Envi-

ronments, volume 6, page 110.

Cavoukian, A. (2010). The 7 Foundational Principles - Im-

plementation and Mapping of Fair Information Prac-

tices.

Cranor, L., Dobbs, B., Egelman, S., Hogben, G., Humphrey,

J., Langheinrich, M., Marchiori, M., Presler-Marshall,

M., Reagle, J., Schunter, M., Stampley, D. A., and

CLOSER 2019 - 9th International Conference on Cloud Computing and Services Science

454

Wenning, R. (2006). The Platform for Privacy Prefer-

ences 1.1 (P3P1.1) Speciﬁcation.

Danezis, G., Domingo-Ferrer, J., Hansen, M., Hoepman,

J.-H., Le M

etayer, D., Tirtea, R., and Schiffner, S.

(2015). Privacy and Data Protection by Design - from

policy to engineering. Technical report, European

Union Agency for Network and Information Security

(ENISA), Heraklion, Greece.

Dario, P. and Cavallo, F. (2014). Ambient Assisted Liv-

ing Roadmap - September 2014. Technical report,

AALIANCE2.

Fredrich, C., Kuijs, H., and Reich, C. (2014). An Ontology

for User Proﬁle Modeling in the Field of Ambient As-

sisted Living. In Koschel, A. and Zimmermann, A.,

editors, SERVICE COMPUTATION 2014, The Sixth

International Conferences on Advanced Service Com-

puting, volume 5, pages 24–31. IARIA.

Gadyatskaya, O., Massacci, F., and Philippov, A. (2012).

Security-by-Contract for the OSGi Platform. pages

364–375. Springer, Berlin, Heidelberg.

Glen McCluskey (1998). Using Java Reﬂection.

Grauel, J. and Spellerberg, A. (2007). Akzeptanz neuer

Wohntechniken f

ur ein selbstst

andiges Leben im Al-

ter. In Zeitschrift f

ur Sozialreform, volume Heft 2 Jg.,

pages 191–215.

Huang, C.-C., Wang, P.-C., and Hou, T.-W. (2007). Ad-

vanced OSGi Security Layer. In 21st International

Conference on Advanced Information Networking and

Applications Workshops (AINAW’07), pages 518–523.

IEEE.

Kafura, D. (2004). OASIS eXtensible Access Control

Markup Language (XACML) TC.

Kuijs, H., Reich, C., Knahl, M., and Clarke, N. (2016). A

scalable architecture for distributed OSGi in the cloud.

In CLOSER 2016 - Proceedings of the 6th Interna-

tional Conference on Cloud Computing and Services

Science, volume 2.

Kuijs, H., Rosencrantz, C., and Reich, C. (2015). A

Context-aware, Intelligent and Flexible Ambient As-

sisted Living Platform Architecture. In Cloud Com-

puting 2015: The Sixth International Conference on

Cloud Computing, GRIDs and Virtualization. IARIA.

le M

etayer, D. (2009). A Formal Privacy Management

Framework. Formal Aspects in Security and Trust,

5491:162–176.

Llena-Nozal, A., Mercier, J., Tjadens, F., and Colombo, F.

(2011). Help Wanted? OECD Health Policy Studies.

OECD Publishing.

Memon, M., Wagner, S. R., Pedersen, C. F., Aysha Beevi,

F. H., and Hansen, F. O. (2014). Ambient Assisted

Living healthcare frameworks, platforms, standards,

and quality attributes.

Parrend, P., Frenot, S., and Hohn, S. (2007). Privacy-Aware

Service Integration. In IEEE International Conference

on Pervasive Services, pages 397–402. IEEE.

Rosencrantz, C., Kuijs, H., Reich, C., Weber-Fiori,

B., and Winter, M. H.-J. (2015). Entwicklung

einer Informations- und Kommunikationsplattform

altere Menschen. ENI 2015, IT im Gesundheits-

, Pﬂege- und Sozialbereich: Qualit

at und Efﬁzienz

durch IT.

Sadat, R., Koster, P., Mosmondor, M., Salvi, D., Girolami,

M., Arnaudov, V., and Sala, P. (2013). Part III: The

universAAL Reference Architecture for AAL. In Sa-

dat, R., editor, Universal Open Architecture and Plat-

form for Ambient Assisted Living. SINTEF.

Schmidt, A., Schmidt, A., Wolf, P., Wolf, P., Klein, M.,

Klein, M., Balfanz, D., and Balfanz, D. (2009). SO-

PRANO Ambient Middleware: Eine offene, ﬂexible

und markt-orientierte semantische Diensteplattform

ur Ambient Assisted Living. 2. Deutscher Kongress

Ambient Assisted Living, Berlin, Januar 2009.

Stutz, O., Todt, S., Venzke-Caprarese, S., Boll, S., Heuten,

W., and Wallbaum, T. (2016). Implementing Data Pro-

tection and Information Security in AAL. pages 59–

68. Springer, Cham.

The European Parliament and the Council of the Euro-

pean Union (2016). REGULATION (EU) 2016/679

OF THE EUROPEAN PARLIAMENT AND OF THE

COUNCIL of 27 April 2016 on the protection of nat-

ural persons with regard to the processing of personal

data and on the free movement of such data, and re-

pealing Directive 95/46/EC.

The OSGi Alliance (2014). The OSGi Alliance OSGi Core,

release 6. OSGi Seciﬁcation, (June):161.

United Nations (2001). World Population Ageing: 1950-

2050. Technical report, UN: Department of Eco-

nomics and Social Affairs - Population Division.

van Heek, J., Himmel, S., and Zieﬂe, M. (2017). Privacy,

data security, and the acceptance of AAL-systems – A

user-speciﬁc perspective. In Lecture Notes in Com-

puter Science (including subseries Lecture Notes in

Artiﬁcial Intelligence and Lecture Notes in Bioinfor-

matics), volume 10297 LNCS, pages 38–56. Springer,

Cham.

Wang, T., Wei, J., Zhang, W., and Zhong, H. (2012). A

framework for detecting anomalous services in OSGi-

based applications. In Proceedings - 2012 IEEE

9th International Conference on Services Computing,

SCC 2012, pages 250–257. IEEE.

Wolf, P., Schmidt, A., Otte, J. P., Klein, M., Rollwage, S.,

onig-Ries, B., Dettborn, T., and Gabdulkhakova, A.

(2010). openAAL - The Open Source Middleware for

Ambient Assisted Living (AAL). AALIANCE confer-

ence, (March):1–5.

Privacy Enhancing Data Access Control for Ambient Assisted Living

455