p205-suomalainen

7/27/2019 p205-suomalainen

1/8

Secure Information Sharing between

Heterogeneous Embedded DevicesJani Suomalainen

1, Pasi Hyttinen

2, Pentti Tarvainen

3

VTT Technical Research Centre of Finland1Vuorimiehentie 3, P.O. Box 1000, FIN-02044 VTT, Espoo

2Microkatu 1, P.O. Box 1199, FIN-70211, Kuopio3Kaitovyl 1, P.O. Box 1100, FIN-90590, Oulu

Finland

{firstname.lastname}@vtt.fi

ABSTRACTSmart spaces are dynamic environments for sharing information

e.g. in personal, building, or public networks. Key challenges for

smart spaces include security and interoperability between hetero-geneous devices, from high-end PCs to embedded gadgets and

sensors. We propose a novel security architecture, which enablesheterogeneous devices to share data in controlled manner. Cen-

tralized information brokering device is used to measure security

level of published information. These measurements are then usedto authorize information access. Hence, the architecture enables

devices to share information with the same security level even

when these devices do not have interoperable security protocols.

We propose policy configuration and deployment models, which

are feasible and usable with embedded devices. We also describe

our practical experiences from implementing the proposed secu-rity solution for smart spaces.

Categories and Subject DescriptorsC.2.0 [Computer Systems Organization]: Computer-

communication networks general.

General TermsDesign, Security

KeywordsArchitecture, communication security, interoperability, accesscontrol, smart space.

1. INTRODUCTIONThe amount of different networked devices which are either per-

sonal or shared either in private buildings and in public spaces is

rapidly increasing. For instance, we have seen networked sensors,cameras, video recorders, high definition televisions, PCs, print-

ers, mobile phones, navigators, game consoles and climate control

equipments. This availability of network gadgets is helping oureveryday life. Further, it has made possible to develop new kinds

of services, which are more autonomous and intelligent. One ma-

jor challenge in this development is the interoperability as there

are different technologies and manufacturers with different mo-tives. In the past, the standardization has been very successful in

solving interconnectivity issues in OSI [32] layers 1- 5. As a re-sult of this success, we now have several communication protocol

standards. However, the standardization of the application-level

interoperability (OSI layer 7) has been a very difficult task [12].As the standardization may not be a sufficient answer to every

possible need and use case at interoperability level, gateways and

semantic interoperability solutions have been introduced.

Smart spaces are based on dynamically created networks of de-

vices. Smart spaces consist of two kinds of architectural elementsthat facilitate information interoperability: Knowledge Processors

(KP) and Semantic Information Brokers (SIB). KPs join to the

smart space and publish and consume information in it. Brokers

provide smart space access, information storage, retrieval and

subscription services. Software for smart spaces have been devel-

oped e.g. in the Smart-M3 project [21]. In order to enable inter-operability, different KPs must know the representation format of

data. Applications may utilize different ontologies, which define

the concepts, properties, and their relations for different use cases.To enable use of ontologies, information is transmitted in eXten-

sible Markup Language (XML) format and stored according to

Resource Description Framework (RDF) specification[31].

Smart spaces have no preference for connectivity and thus may

use any of the existing communication methods including Blue-

tooth (BT), Wireless Fidelity (WiFi) and Internet Protocol (IP).Therefore, there is also a wide range of security mechanisms

available for them. However, the use of existing mechanism to

secure smart spaces is not straightforward. As smart spaces areheterogeneous, we cannot assume availability of one particular

security mechanism. Security mechanism specified for different

communication protocols are not interoperable. Therefore, we

need higher level interoperability solutions for security. These

solutions must be able to cope with publish-retrieve-subscribe

architecture, resource restrictions and complexity due to dynamicnature of communication.

Our main contribution is a secure architecture that guarantees a

controlled means to share information between heterogeneous

devices without a compatible security mechanism. We also de-

scribe how to design and implement the security architecture for

smart spaces. In particular, we show how the information broker

element can measure the security level of connections and thenuse these measurements to control information access. Our access

Permission to make digital or hard copies of all or part of this work for

personal or classroom use is granted without fee provided that copies are

not made or distributed for profit or commercial advantage and that

copies bear this notice and the full citation on the first page. To copy

otherwise, or republish, to post on servers or to redistribute to lists,

requires prior specific permission and/or a fee.ECSA 2010, August 23-26, 2010, Copenhagen, Denmark.

Copyright (c) 2010 ACM 978-1-4503-0179-4/10/08 ...$10.00.

205


2/8

control solution is flexible. The unique measurement system en-

ables the use of various open security standards. Consequently wecan utilize matured and known to be trustworthy security mecha-

nisms in a flexible manner. The proposed security architecture

provides fine-grained access control and thus enables definition of

strict access control policies tied to information. This fine-grained

access control mechanism may then be utilized in different ways.

For instance, users may easily create their own virtual personalsmart spaces by using public or shared information brokers. Secu-

rity architecture is suitable also for embedded resource restricted

devices. Hence, we discuss and propose a model for propagatingaccess control policies in a manner that enables an easy control

over the information published by embedded devices in fine-

grained manner.

The rest of this paper is organized as follows. In section 2.1 in-

formation security threats, risks, vulnerabilities and possible at-tacks in different smart spaces are considered. In Section 2.2 po-

tential security building blocks are surveyed. Section 3 describes

our security architecture for smart spaces. Section 4 provides dis-cussion on the idea and implementation. Then in Section 5 our

architecture is compared to related work. Finally, Section 6 sum-

marizes the paper.

2. BACKGROUND

2.1 Security Threats and RequirementsDevices in smart spaces are vulnerable to several security attacks

such as eavesdropping, denial-of-service, tampering, selective

forwarding, sinkhole attack, wormhole attack, and Sybil attack.

Detailed descriptions of these threats and requirements can be

found for example in [2, 29].

Risks and attacks vary in different smart spaces. In homes and

cars, we may want to give more attention to physical security andsafety issues and, thus need to concentrate on integrity and au-

thenticity of communication. With personal devices, the availabil-

ity of services and privacy of information may be more in the

focus. In public smart spaces, the critical issue is to find authentic

services and protect ourselves from malicious input. In offices, we

need to emphasize confidentiality of communication and businesssecrets.

As the same devices are used in various smart spaces, we mustprovide flexible security solutions. Consequently, service and

communication platforms must enable smart spaces to adopt dif-

ferent security functions. Particularly, the following functionsshould be supported:

1. Authenticated and integrity protected communication. In-formation brokers and smart space devices should be able to

mutually authenticate direct communication parties. Informa-

tion consumers may also need to authenticate information

publishers. However, in some smart spaces information pro-

viders may want to guard their privacy and prevent forward-

ing of their identity.

2. Smart space and information access must be authorized

Information publishers and smart space administrators mayneed to control who can access smart space services and in-

formation. There may be a need to keep information separate

in different granularities. For instance, some information(coming e.g. from particular devices) may be available only

for one or few users. Security or safety critical configuration

data may be available only for some highly trusted users us-ing trustworthy devices, whereas some less critical informa-

tion may be available for every smart space user.

3. Confidentiality of communication should be enabled e.g. for

privacy critical applications.

4. A smart space should provide mechanisms for monitoring

and control over devices security attributes. The amount and

physical restrictions of embedded devices within smartspaces makes it difficult for end-users to control security

level separately for each device. This is particularly difficult

for devices limited I/O capabilities. Therefore, auditing andremote configuration are needed.

Smart space devices have different security characteristics andabilities. Some devices cannot provide all possible security func-

tions e.g. due to battery or communication restrictions. Devices

with limited input and output user interface capabilities are diffi-cult to pair securely and they cannot be configured without a help

from other devices. On the one hand, it is not feasible to imple-

ment every potential security protocol into every device, particu-larly if these devices are memory restricted and/or have a connec-

tivity-specific security protocols. On the other hand, some security

functions (such as heavy algorithms and long security keys) arenecessary for some critical applications. Consequently, as smart

spaces should support different kinds of devices, there is a needfor interoperability and gateway solutions.

Heterogeneity of devices and interoperability solutions in smartspaces imply versatile protocols and messaging formats. Process-

ing and parsing of input and XML documents has been a major

source of security problems and, therefore, attention should be

given for reliable parsing implementations. This issue may bemore critical in smart spaces as many embedded devices do not

have direct Internet access for security patches. Therefore, to

make communication mechanisms resistant against malicious

attackers and malformed content, careful coding practices and

input validation should be utilized as well as mature and securitytested interfaces.

Configuration of appropriate security levels and access controlpolicies is a major challenge for smart space implementations that

are typically administered by typical non-expert users. Particu-

larly, if there is a need to make this control in fine-grained man-ner, the policy configuration and deployment is to be kept as sim-

ple and unambiguous as possible. Furthermore, smart space plat-

forms should be flexible enough for various access control

schemes and policies, customized and deployed for different smartspaces.

2.2 Building Blocks for Smart Space SecurityThere exists a large amount of existing research, standardization

work, and implementations of security mechanisms, which can beutilized in smart spaces. These mechanisms include the use of

cryptography in the different levels of communication, key estab-

lishment and management schemes, access controls and authoriza-tion solutions as well as robust implementation techniques. Figure

1 illustrates how some of these security technologies fit to the

layers of semantic web.

206


3/8

Figure 1. Layers of Semantic Web (left; adapted from Berners

Lee [4]) and essential security elements for smart spaces

(right)

Most communication mechanisms for wired and wireless local

and personal area networks and for sensor networks provide pair-ing and encryption solutions for protecting authenticity, integrity

and confidentiality of messaging. See e.g. [5, 16] for specifica-

tions related to Bluetooth and WiFi security and [23] for a survey

on standardized pairing mechanisms. Middleware standards suchas Universal Plug and Play (UPnP) [11, 28] and Device Profile

for Web Services (DPWS) [7], providing e.g. service discovery

and description means, have also specified custom or Transport

Layer Security (TLS) [10] based mechanisms for securing com-

munication. For web services, the World Wide Web Consortium[30] has specified syntax for XML signatures, encrypted docu-

ments and key management.

Security levels and access control policies must be described by alanguage, which is understandable for remote devices so that cen-

tralized monitoring and control is possible. XML based eXtensi-

ble Access Control Markup Language (XACML) [20] is one ex-

ample of languages describing how to interpret policies. Achiev-

ing a single standard description is not feasible in heterogeneous

smart spaces. However, ontologies can be utilized to ease interop-

erability. Security ontologies describe security concepts and their

relationships, typically using XML based notation. Individualdevices may then adopt relevant parts of ontology and use it to

describe their security properties. Hence, devices do not need to

implement completely the same protocols before they are able to

understand each others. Existing security ontologies include e.g.

[9, 18, 27]. These ontologies may not cover all potential security

concepts but they can be extended by using established securityterminology and classifications to be suitable for smart spaces.

Some general ontologies, which are targeted for smart spaces,

such as Standard Ontology for Ubiquitous and Pervasive Applica-tions [8], have also adopted elements for defining access control

policies.

The challenge of configuring complex access control policies hasbeen addressed with different access control models. These mod-

els classify access control objects and subjects into groups. For

example, a prominent model is the classification of subjects ac-cording to the role based access control model [13]. Also, the

privacy and contextual questions have gained attention. For in-stance, the concept of virtual walls [17] was introduced to ease

configuration by making private information hidden from devices,

which are configured to be behind a virtual wall. These models

may be applied in different smart space environments.

3. SECURITY ARCHITECTUREOur proposed security solution protects confidentiality and au-

thenticity of information exchange between the heterogeneous

information providers and consumers as well as information bro-

ker. Furthermore, remote monitoring and control of systems secu-

rity state are enabled as well as different (fine and coarse-grained)

access control and authorization solutions over smart space andinformation access. The proposed security architecture for smart

space is illustrated in Figure 2. The key component is the RDF

Figure 2. Smart space security architecture - Security relationships between different actors in smart space are illustrated

with light blue arrows. Blue arrows illustrate actual information flow and green ovals exchanged security information

(C=credentials, PD=policy directive, KP ID= identifier of information publisher).

Information

Consumer KPs

Security

Monitors

Security

Administ rators

Information

Publisher KPs

RIBS(Information Broker)

- Measure Security Level

- Enforce Security Policies

Author ize informati on access

Authent icate publ isher KP

INFORMATION

INFORMATION

Authenticate/ProtectConfidentiality

Authenticate/ProtectConf

identiality

ControlSmart

SpaceAccess

Control

SecurityLevel

Author izeInformation

AccessControl Inf.Access

KP

ID

Control Smart

Space Access

Security

attiributes

Status,

aler

ts

Control SmartSpace Access

PD

PD C

PD

CC CC

C C

Information

Consumer KPs

Security

Monitors

Security

Administ rators

Information

Publisher KPs

RIBS(Information Broker)

- Measure Security Level

- Enforce Security Policies

Author ize informati on access

Authent icate publ isher KP

INFORMATION

INFORMATION

Authenticate/ProtectConfidentiality

Authenticate/ProtectConf

identiality

ControlSmart

SpaceAccess

Control

SecurityLevel

Author izeInformation

AccessControl Inf.Access

KP

ID

Control Smart

Space Access

Security

attiributes

Status,

aler

ts

Control SmartSpace Access

PD

PD C

PD

CC CC

C C

207


4/8

Information Base Solution (RIBS), which is used to broker and

protect information produced by knowledge processors (KP).Further, we have software entities for administrating as well as for

monitoring security.

3.1 Communication SecurityRIBS is a server, which is used by KPs to store, retrieve, manipu-late and subscribe information. There may be several servers

within network. In open networks clients may use those servers

they trust on to provide a sufficient security level and to protectaccess to information they provide. All data communication be-

tween RIBS and KPs can be mutually authenticated and en-

crypted.

The solution is not tied to any specific security mechanism and,

thus, any key management scheme, pairing model, security proto-

col, or encryption algorithm could be integrated to the system andused as long as both RIBS and at least one KP support it. An own

network security layer has been provided as we cannot assume

availability of security in the connectivity layer. Smart space de-ployments may utilize this layer or may opt to use some another

customized security solution.

When a KP is first introduced to smart space, it is given smart

space credentials enabling it to authenticate to RIBS and other

KPs later on. Credentials may be given e.g. in a form of X.509

certificate [15]. Trust in certificate delivery is based on availablepairing mechanisms. This trust information (i.e. what pairing

mechanism, algorithms and key sizes were used) is included in

credentials. KPs get credentials from any trusted device in smartspace. Therefore, these administrator devices should provide

strong pairing capabilities and act as certification authorities.

When a KP joins to a smart space or subscribes to particular in-

formation, it negotiates a security session with RIBS. During this

handshake both parties verify that the peer has valid smart spacecredentials. Further, RIBS enforces that the communication ses-

sion fulfils the minimum security level requirements set for the

smart space. In addition to parameters of security protocol, RIBSalso verifies the other security attributes affecting to the security

level, like the strength of (pairing) mechanism used to deliver

smart space credentials and platform trustworthiness information.

Security sessions are kept alive until KP leaves the smart space or

unsubscribes smart space information updates. This connection

oriented messaging minimizes the amount of heavy handshakeprocedures.

The solution enables consuming KPs to identify KPs, which have

provided information. When data is inserted, the broker may storeidentities of information publishers and forward this information

to consumers. Security properties and state resolved from KP

during smart space join operation can also be stored and pub-

lished for monitoring applications. These features may be disabled

in order to protect privacy of publishers.

3.2 Profiling Security LevelsDifferent security characteristics within smart space devices causean interoperability challenge. RIBS does not dictate that every KP

must utilize particular security mechanism. In our security ap-

proach, RIBS only dictates that KPs are using sufficiently strong

mechanisms. A KP providing information may utilize different

security mechanisms than a KP that is consuming the information,

but only if these mechanisms are strong enough.

Measuring whether particular mechanisms are strong enough is

done by using security levels. Security levels are coarse grainedmeasurements of devices security capabilities. In practice, RIBS

collects information about methods and algorithms that KPs are

using and how they use it. Measurements can be made from fol-lowing categories:

1. Pairing method i.e. devices smart space deployment in-

formation (i.e. information on what pairing mechanism was

used when the device was associated to the smart space andcertified). This information is given for KP during smart

space association and carried e.g. in X.509 certificates.

2. Authentication i.e. mechanisms for user and device identi-

fication for protecting the authenticity of communication.This mechanism is negotiated during security protocols

handshake.

3. Keying i.e. the used protocol for changing of the network

keys. This mechanism is negotiated during security proto-

cols handshake.

4. Cipher i.e. mechanisms for encrypting communication.

This mechanism is negotiated during security protocolshandshake.

5. Platforms trust parameters - RIBS may resolve run-time trustinformation (e.g. OS version, protocol implementations, state

of antivirus software tec.) from the requesting KP device. For

instance, RIBS may query this information directly from theKP using e.g. Trusted Network Connect protocol.

RIBS uses these security measurements to determine securitylevels for each communication session. The security level can be

defined in numeric manner. For example, security properties can

be profiled to four levels e.g. No-Low-Medium-High as de-scribed in Table 1. Derived final security level is a union of the

security levels of each separate category so that the the weakest

link will be the final security level.

Evaluating the strength of a particular security mechanism is not

straightforward as different kinds of attacks are applicable against

different mechanisms and because we cannot predict what attacksare feasible in arbitrary smart space. Therefore, the evaluations are

somewhat subjective. They can be, however, adjusted both in time

and for each smart space. When new algorithms and implementa-

tions are evaluated, existing (e.g. cryptological) analyses and in-

formation from vulnerability databases may be utilized.

Table 1. An example of security level classification.

Security

Level DescriptionMatching Security

Standards

NoSecurity is not provided

at all

Low

Pairing methods without

authentication, authenti-

cation algorithm

BT v2.1 just-connectpairing,

Medium

Authenticated pairing,authentication & encryp-

tion based on asym-

metrical cryptography

BT v2.0 pairing (PIN

based),

TLS-DES

High

Authenticated trusted

pairing, authentication

and encryption (that

, WUSB numeric asso-

ciation, BT v2.1. out-

of-band pairing, TLS,

208


5/8

shall endure two years,

e.g.)

RSA, AES

For example, consider a case where a device is first paired with

security control device using Bluetooth v2.0 pairing with 4-digitPINs (personal identification numbers). The device gets smart

space credentials from this control device and can then connect to

information broker. The connection to information broker occursover WiFi and TLS. TLS utilizes RSA (Rivest-Shamir-Adleman)

and AES (Advanced Encryption Standard) or 3DES (Triple-DataEncryption Standard) algorithms with key lengths 2048 and 128

or 168 bits, respectively. Optional platform trustworthiness checks

are not made as they are not required in this smart space. Thesecurity level is considered to be medium as the weakest link was

Bluetooth pairing with the medium level. If, however, pairing had

utilized more secure WPS (WiFi Protected Setup) in-band model

or numeric association of WUSB (Wireless Universal Serial Bus),

the final security level would had been high.

The presented coarse and one-dimensional security level example(No-Low-Medium-High) provides sufficient control over secu-

rity but is also usable enough for end-users to understand. How-

ever, it is possible to define different security levels for differentsmart spaces. For instance, in a smart space that has none needs

for typical end-users to control security, we may have multi-

dimensional security levels (e.g. dimensions for strength of au-

thenticity and confidentiality). In the future, it might also be pos-

sible to define to describe security levels as a part of a security

ontology.

Run-time changes to the security level provide some challenges.

When the RIBS wishes to tighten up the security level, it sends

the leave indication to KPs. After that a KP must join to the RIBSagain. If changes are allowed, a KP querying data cannot know if

that data has been inserted by a trusted KP. Also a KP insertingdata should be able to know how data is protected and that there

wont be changes to the protection level. Therefore, in these cases,

RIBS is required to keep track of which information has been

stored with a particular security level and protect informationaccordingly.

3.3 Information Level Access ControlIn some smart spaces, access to information must be controlled in

a more fine-grained manner than the smart space level. Particu-

larly, we need to control which end-users, programs, or devices

with different roles can access particular information elements.Also, we need to control what security level is required to get

access to a particular piece of information. Definition of access

control policies is a sum of different factors. These factors (con-cepts and elements) are illustrated in Figure 3.

Access control policies define which subjects are allowed to ac-

cess which objects. In proposed architecture, subjects are authen-

ticated using identifiers given (in credentials) by security author-ity. These identifiers are unique numbers identifying both the KP

and potentially also end-user (in case of personal devices) andgroups (e.g. roles given for end user or KP).

RIBS enforces that authenticated subjects are authorized to access

to the smart space or a particular piece of information. Authoriza-

tion also depends on the security level of a requester. The security

level may be required to be the same as the security level of in-

formation provider, the security level specified separately or the

default smart space security level. An access control policy maybe tied to identifiers, which may be also group identifiers. Group

identifiers can be given either according to subject groups (e.g.roles are given ids) or according to object group (e.g. climate

information producer id may be given for every thermometer).

Trusted RIBS devices, which are used in multiuser environments,

can provide Virtual Personal Smart Spacesfor the end-users. In

this case, the broker assures that information coming from de-vices, which belong to a specific end-user, is accessible only for

the devices of this same user. The concept may ease burden of

privacy and security configuration as the end-user must only de-fine, which devices are personal. At the same time end-users may

utilize existing brokers in homes and offices. This privacy con-

figuration model can be implemented, if the i.e. owner of particu-

lar devices can be authenticated. The concept may also improveusability as list of available services can be filtered according to

this information.

3.4 Policy DeploymentWhen new KP or RIBS devices are introduced to the smart space,

security policies controlling their access permissions and securitylevels must be set. These policies can be configured and deployed

in various manners. Our centralized solution is focused on re-

source and UI-restricted, embedded devices, operating in dynamic

Figure 3. Essential authorization elements, attributes, and their relations. - Policy specifies how subjects are allowed to access

objects. Policies may be tied to different security relevant attributes.

Subject classes(roles...)

Object class(domain)

Subject ObjectAct ion

End-userKnowledge

processor Broker (smart

space)

Information

processed by broker

Act ion class

onhas permission to do

is categorizedto is categorized to is categor ized to

requires particular

sec-level &

privileges

Policy

Origin (KPs ID)come

from

Privileges

Identityhas

has

Security level

Achieves

with current

mechanismsInformation

stored in broker

was

protected

with

requires protection with

has

209


6/8

smart space environment. Therefore, we propose a solution, which

does not require end-users to directly configure information pro-vider devices. Neither, does our solution require information bro-

kers to be directly configured. Hence, brokers may be changed to

new devices without requiring reconfiguration.

When a new KP device is introduced to a smart space for the firsttime, it is given policy directives, which instruct how RIBS

should protect information produced by this KP. KPs forward this

directive to RIBS, which will then enforce these policies. Advan-tage of this scheme is that each KP carries its security policies.

RIBS does not need to know the preferences of each KP.

Policies may directly dictate how access is controlled (e.g. wri-table only for it and readable for particular roles with particular

security state). Alternatively, access control may depend on the

security context i.e. on publishers security level. If KP is usingmechanisms that give it a particular security level, RIBS will also

protect that information with the same level. It is not necessary to

require RIBS for tighter security levels as an attacker who is ableto break lower security level was able to do that already when data

was inserted.

In the case of embedded devices, requirements for access policiesare typically tied to the type of system, device or application. For

instance, all information produced by thermometers may be read-

able for every device within smarts space. Therefore, a singlepolicy directive is sufficient for these devices. In case a device has

more versatile security needs, it may utilize several policy direc-

tives (if directives are delivered with certificates it must also rene-gotiate TLS session).

Challenges are met in those smart spaces, where RIBS devices can

be changed dynamically, and in those smart spaces, where multi-ple authorities may exist. In smart spaces where RIBS devices are

changed and information is migrated, also policies must be mi-grated. In smart spaces with multiple authorities, RIBS is requiredto map certifier identities, from KPs certificates, to policies,

which are coming from different authorities.

4. DISCUSSIONThe proposed approach differs from typical communication secu-rity solutions in a sense that the communicating end-points are not

communicating with each other in real time and may not have

interoperable security mechanisms. Security is based on the bro-

kering RIBS device, which must be trustworthy. In the case that

RIBS cannot be trusted to provide sufficient security level, infor-

mation stored to RIBS must be signed or encrypted and commu-nicating KPs must have their own interoperable means for validat-

ing or decrypting this information. In this, applications may utilizesmart space credentials and, hence, separate key managementsolution is not needed. However, this additional protection would

prevent RIBS from further processing the information. Also, in

several scenarios, providing separate KP-to-KP specific authenti-

cation and encryption scheme would not increase the security at

all. This is because in many smart spaces, the RIBS device actsalso as security administrator device (i.e. it is the certification

authority). In these cases, RIBS would anyhow be able to mas-

querade as any KP.

Information brokered by RIBS can be any application specificdata. For instance, RIBS may distribute credentials and crypto-

graphic keys providing access to application specific services or

data. Hence, RIBS may be utilized as a building block in different

domain specific security and access control solutions.

RIBS and KPs communicate through Smart Space Access Proto-

col (SSAP) (see e.g. [14, 21]). The security layer was imple-mented below the SSAP protocol in order to maintain compatibil-

ity with existing SSAP implementations and to enable the use of

different security protocols. In the current implementation SSAP

applications communicate using a socket layer, which provides

also security services. Currently, the socket layer operates on topof TCP/IP (Transmission Control Protocol/Internet Protocol)

stack but may also use other transportation layers in the future.

The first version of the implementation uses the TLS and X.509standards due to their wide acceptance, availability, and high se-

curity level. The socket layer negotiates TLS sessions and routes

communication to TLS sockets. Future implementations may sup-

port a set of protocols as security properties and metrics can be

collected from any security protocol. However, in these cases,

X.509 independent mechanisms for carrying policy directives,pairing information and identifiers are additionally needed.

The implementation of the TLS layer is based on the GnuTLS

library [25]. It was selected as the library can be considered suffi-ciently mature and trustworthy from the security point of view. Its

development started ten years ago (2000) and it has not struggled

with security vulnerabilities too much (e.g. there are only five

Ubuntu Security Notices, which correct GnuTLS security bugs in

the current Ubuntu Linux releases [26]).

The TLS layer causes overhead, particularly, due to heavy hand-shake. However, when the amount of messages increases, also the

relative penalty of TLS decreases.

Security polices specify who are allowed to access to what infor-mation and what is the minimum security level for this access. In

addition to identifiers of authorized users, the policies includeinformation on the certification authority. This enables RIBS to

enforce information from devices, which are trusted by different

authorities. RIBS can also store information on the origin of in-

formation. This identity and security level information can bequeried by KPs, which need to authenticate the source of informa-

tion and which trust RIBS.

When a new device is for the first introduced to a smart space, itgets the X509 certificates and private keys from security adminis-

trators device (certification authority). Certificates of KP devices

carry also policy directives and pairing information (identifying

by how a trustworthy manner the device has gained its creden-

tials). Certificates are used to carry this information to maintain

compatibility with other SSAP implementations. Downside of

using certificates is that the solution is less flexible as a devicewith several applications with different access control needs, re-

quires several certificates. When new information is stored toRIBS, a related security policy is either derived from the policy

directives and sessions security state or, if directives are not avail-

able, from RIBS default policies.

Message handlers on top of the TLS/Socket layer enforce access

to information. They query the authorization service within RIBS

for access control decisions. The TLS/Socket layer is responsibleof resolving security parameters from TLS sessions and certifi-

cates. In RIBS, these security parameters are also mapped to secu-

rity strength information in order to derive security levels. Imple-mentation controls currently read and write operations over in-

210


7/8

formation. However, the modular implementation can be easily

extended to support other services and different actions.

5. RELATED WORKAccess control and authorization solutions applied in personal andhome networks typically have a very coarse-grained access con-

trol. Only office environments embody more detailed access con-

trols. With some technologies the management of fine-grainedaccess control is service or device specific, restricted e.g. to file

system or web server. These systems may require client to use

particular security algorithms and thus they enforce particularsecurity level. However, these solutions do not enable use of dif-

ferent security protocols; instead they are tied to particular ones

such as TLS. Also, they are not able to require different security

levels for different pieces of shared information.

There exists various security architectures where access control

policy deployment has been centralized. Prominent candidates for

smarts spaces are, Kerberos tokens [19] used e.g. in Windowsnetworks and authorization certificates [11] used in UPnP. We

utilize these platform specific credentials to deliver credentials.However, additionally we propose the use of these mechanisms to

carry access control policy directives. Also, support for various

security mechanisms makes our solution more flexible and usable

for heterogeneous environments than e.g. Kerberos and UPnP

based solutions.

Several solutions have been proposed for security middleware.These middleware solutions either utilize and complement or

replace transportation layer specific security protocols. For in-

stance, Secure Middleware for Embedded Peer-to-Peer Systems(SMEPP) [6] has focused on the secure cooperation between em-

bedded devices. Like our solution, SMEPP is able to adapt secu-

rity levels according to devices capabilities and needs. Anotherapproach, OpenHouse [22], provided a secure platform for homes.

It addressed access control within UPnP service level. The use ofTLS enabled security level to be adapted into devices capabili-

ties. OpenHouse addressed the interoperability challenge with

domain-specific adapter devices, which were positioned betweennetwork and legacy appliances. Our security solution is used un-

der middleware layer (SSAP) but it is not middleware itself as

compatible security software are not required for each smart spacedevice. Our solution also enables centralized control over shared

information. This cannot be enforced with middleware solutions,

where devices communicate directly with each others.

Security work has also been done within sensor network middle-

ware. For instance, the researches in POBICOS (Platform for

Opportunistic Behavior in Incompletely speCified, heterogeneousObject CommunitieS) project propose [24] an approach to im-

plement secure network management and confidentiality in a dis-

tributed low capacity sensor networks. The solution enables theuser to manage such a system in a straightforward way and

achieves sufficient data confidentiality at the application level.

The proposed security solution offers two levels of security: a OneNetwork Key Approach and an Identity-based Cryptography Ap-

proach. The approaches are alternative and selectable by applica-

tion developer. The security of the approach is based on utiliza-

tion of network specific security cards, withholding the sensitive

configuration data and network keys. Delivery of the network

keys into the devices can be performed by means of the securitycard with close proximity. The approach does not consider secu-

rity policy configuration and deployment models as our proposal

does.

Security and access control has been integrated also to other pub-

lish and subscribe architectures. For example, role-based accesscontrol has been integrated [3] to Hermes architecture. The

GEMOM project has proposed messaging oriented middleware

[1]. GEMOM also propose mechanisms for adapting securityaccording to peers requirements. However, their proposal does

not discuss how to enable clients to use different transport specific

security mechanisms. The measurement based security levelingand support for heterogeneous security technologies make our

proposal unique.

6. CONCLUSIONSWe have designed and implemented a flexible security architec-

ture, which enables heterogeneous devices to share data in con-

trolled manner. The architecture is based on measuring security

level of joined smart space nodes. Information brokering compo-nent utilizes this measured information to authorize information

access. Hence, the architecture enables devices to share informa-

tion with the same security level even when these devices do not

have interoperable security protocols. We have also proposed pol-

icy configuration and deployment models, which are feasible and

usable with embedded devices.

7. ACKNOWLEDGMENTSWe thank Eila Ovaska for valuable feedback. This work was done

within EU/ARTEMIS project SOFIA (Smart Objects For Intelli-gent Applications), which has been co-funded by Tekes (the Fin-

nish Funding Agency for Technology and Innovation) and the

consortium partners.

8. REFERENCES[1] Abie, H., Dattani, I., Novkovic, M., Bigham, J., Topham, S.

and Savola, R. 2008. GEMOM - Significant and MeasurableProgress beyond the State of the Art. In Systems and Net-

works Communications, 2008. ICSNC '08. 3rd International

Conference. (Sliema, Malta, Oct. 26-31). IEEE ComputerSociety, Los Alamitos, California, 191-196.

DOI=10.1109/ICSNC.2008.33.

[2] Baronti, P., Pillai, P., Chook, V. W. C., Chessa, S., Gotta, A.

and Hu, Y. F. 2007. Wireless sensor networks: A survey on

the state of the art and the 802.15.4 and ZigBee standards.

Comput. Commun., 30, 7, (May 26), 1655-1695.

[3] Belokosztolszki, A., Eyers, D. M., Pietzuch, P. R., Bacon, J.

and Moody, K. 2003. Role-based access control for pub-

lish/subscribe middleware architectures. In The 2nd interna-tional workshop on Distributed event-based systems. (San

Diego, California, June 8). ACM, New York, NY, USA, 1-8.

DOI=http://doi.acm.org/10.1145/966618.966622.

[4] Berners Lee, T. 2000. Semantic web. Keynote speech,

XML2000 conference. Available:

http://www.w3.org/2000/Talks/1206-xml2k-tbl/.

[5] Bluetooth Special Interest Group. 2007. Bluetooth 2.1 Speci-

fications. Available:

http://www.bluetooth.com/NR/rdonlyres/F8E8276A-3898-4EC6-B7DA-E5535258B056/6545/Core_V21__EDR.zip.

211
http://www.w3.org/2000/Talks/1206-xml2k-tbl/http://www.bluetooth.com/NR/rdonlyres/F8E8276A-3898-http://www.bluetooth.com/NR/rdonlyres/F8E8276A-3898-http://www.w3.org/2000/Talks/1206-xml2k-tbl/


8/8

[6] Caro Benito, R. J., Garrdio Marquez, D., Plaza Tron, P.,

Roman Castro, R., Sanz Martin, N. and Serrano Martin, J. L.2009. SMEPP: A Secure Middleware For Embedded P2P. In

ICT-MobileSummit 2009. (Santander, Spain, June 10 - 12).

[7] Chan, S., Conti, D., Kaler, C., Kuehnel, T., Regnier, A., Roe,

B., Sather, D., Schlimmer, J., Sekine, H., Thelin , J., Walter,D., Weast, J., Whitehead, D., Wrigth, D. and Yarmosh, Y.

2006. Devices profile for web services. Public consultation

draft release. Available:http://specs.xmlsoap.org/ws/2006/02/devprof/.

[8] Chen, H., Perich, F., Finin, T. and Joshi, A. 2004. SOUPA:

standard ontology for ubiquitous and pervasive applications.In Mobile and Ubiquitous Systems: Networking and Ser-

vices, 2004. MOBIQUITOUS 2004. The First Annual Inter-

national Conference. (Boston, Massachusetts, USA, Aug. 22-26). IEEE Computer Society, 258-267.

[9] Denker, G., Kagal, L. and Finin, T. 2005. Security in the

Semantic Web using OWL. Information Security TechnicalReport, 10, 1, 51-58.

DOI=http://dx.doi.org/10.1016/j.istr.2004.11.002 .

[10] Dierks, T. and Rescorla, E. 2006. The Transport Layer Secu-rity (TLS) Protocol. Version 1.1. IETF Specification. Avail-

able: http://tools.ietf.org/html/rfc4346.

[11] Ellison, C. 2002. Home network security. Intel TechnologyJournal, 6, 4, 37-48.

[12] Farrell, J. and Saloner, G. 1985. Standardization, Compati-

bility, and Innovation. Rand J. Econ., 16, 1, (Spring), 70-83.

[13] Ferraiolo, D. and Kuhn, R. 1992. Role-Based Access Con-trol. In The 15th National Computer Security Conference.

(Baltimore, Maryland, Oct. 13-16). Storming Media, U.S.A,

554-563.

[14] Honkola, J., Laine, H., Brown, R. and Oliver, I. 2009. Cross-

Domain Interoperability: A Case Study. In Smart Spaces and

Next Generation Wired/Wireless Networking. S. Balandin,D. Y. Moltchnov and Y. Koucheryavy eds. Springer-Verlag,

Berlin, Heidelberg, 22-31.

[15] Housley, R., Ford, W., Polk, W. and Solo, D. 1999. InternetX.509 Public Key Infrastructure, Certificate and CRL Pro-

file. IETF Standard. Available:

http://www.ietf.org/rfc/rfc2459.txt.

[16] IEEE. 2004. 802.11i. IEEE Standard. Available:

http://standards.ieee.org/getieee802/download/802.11i-

2004.pdf.

[17] Kapadia, A., Henderson, T., Fielding, J. J. and Kotz, D.2007. Virtual Walls: Protecting Digital Privacy in Pervasive

Environments. In The 5th International Conference on Per-

vasive Computing. (Toronto, Ontario, Canada, May 13-16).Springer, Berlin, Heidelberg, 162-179.

DOI=http://dx.doi.org/10.1007/978-3-540-72037-9_10.

[18] Kim, A., Luo, J. and Kang, M. 2005. Security Ontology forAnnotating Resources. In Confederated International Con-

ferences, CoopIS, DOA, and ODBASE. R. Meersman and Z.

Tari eds. Springer-Verlag Berlin, Heidelberg, 1483-1499.

[19] Neuman, C., Yu, T., Hartman, S. and Raeburn, K. 2005. The

Kerberos Network Authentication Service (V5). IETF speci-fication. Available: http://www.ietf.org/rfc/rfc4120.txt.

[20] OASIS. 2005. XACML 2.0 Core: eXtensible Access ControlMarkup Language (XACML) Version 2. Available:

http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-core-spec-os.pdf.

[21] Smart-M3 project. Smart-M3 www-pages at SourceForge.

2010, 05/07, Available: http://sourceforge.net/projects/smart-m3/.

[22] Suomalainen, J., Moloney, S., Koivisto, J. and Keinnen, K.

2008. OpenHouse: a Secure Platform for Distributed HomeServices. In The Sixth Annual Conference on Privacy, Secu-

rity and Trust. L. Korba, S. Marsh and R. Safavi-Naini eds.

IEEE Computer Society, Los Alamitos, California, 15-23.

[23] Suomalainen, J., Valkonen, J. and Asokan, N. 2009. Stan-

dards for Security Associations in Personal Networks: A

Comparative Analysis. International Journal of Security and

Networks, 4, 1/2, 87-100.

DOI=http://dx.doi.org/10.1504/IJSN.2009.023428.

[24] Tarvainen, P., Ala-Louko, M., Jaakola, M., Uusitalo, I., Spy-ros Lalis, S., Paczesny, T., Taumberger, M. and Savolainen,

P. 2009. Towards a Lightweight Security Solution for User-

Friendly Management of Distributed Sensor Networks. InSmart Spaces and Next Generation Wired/Wireless Network-

ing. S. Balandin, D. Moltchnov and Y. Koucheryavy eds.

Springer-Verlag, LNCS 5764, Berlin, Heidelberg, 97-109.

[25] The GNU Project. The GNU Transport Layer Security Li-brary. WWW pages. 2010, 5/7, Available:

http://www.gnu.org/software/gnutls/.

[26] The Ubuntu Community. Ubuntu Security Notices. 2010,4/21, Available: http://www.ubuntu.com/usn/.

[27] Tsoumas, B., Dritsas, S. and Gritzalis, D. 2005. An Ontol-

ogy-Based Approach to Information Systems Security Man-agement. In MMM-ACNS 2005. V. Gorodetsky, I. Kotenko

and V. Skormin eds. Springer, Berlin, Heidelberg, 151-164.

[28] UPnP Forum. 2003. UPnP Security Ceremonies DesignDocument for UPnP Device Architecture 1.0. Available:

http://www.upnp.org/.

[29] Walters, J. P., Liang, Z., Shi, W. and Chaudhary, V. 2006.

Wireless sensor network security: A survey. In Distributed,

Grid, and Pervasive Computing. Y. Xiao ed. Auerbach Pub-

lications, CRC Press, Broken Sound Parkway, NW, 1-849.

[30] World Wide Web Consortium. W3C - Security. 2010, 05/07,Available: http://www.w3.org/standards/xml/security.

[31] World Wide Web Consortium. 2004. Resource Description

Framework (RDF): Concepts and Abstract Syntax. W3CRecommendation. Available:

http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/.

[32] Zimmermann, H. 1980. OSI Reference Model The ISOModel of Architecture for Open Systems Interconnection.

IEEE Transactions on Communications, 28, 4, (April 1980),

425-432.

212
http://specs.xmlsoap.org/ws/2006/02/devprof/http://tools.ietf.org/html/rfc4346.http://www.ietf.org/rfc/rfc2459.txt.http://standards.ieee.org/getieee802/download/802.11i-http://www.ietf.org/rfc/rfc4120.txt.http://docs.oasis-open.org/xacml/2.0/access_control-xacml-http://sourceforge.net/projects/smart-http://www.gnu.org/software/gnutls/http://www.ubuntu.com/usn/http://www.upnp.org/http://www.w3.org/standards/xml/security.http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/http://www.w3.org/standards/xml/security.http://www.upnp.org/http://www.ubuntu.com/usn/http://www.gnu.org/software/gnutls/http://sourceforge.net/projects/smart-http://docs.oasis-open.org/xacml/2.0/access_control-xacml-http://www.ietf.org/rfc/rfc4120.txt.http://standards.ieee.org/getieee802/download/802.11i-http://www.ietf.org/rfc/rfc2459.txt.http://tools.ietf.org/html/rfc4346.http://specs.xmlsoap.org/ws/2006/02/devprof/

Documents

p205-suomalainen