Secure Information Sharing between Heterogeneous Embedded Devices

Jani Suomalainen1, Pasi Hyttinen2, Pentti Tarvainen3

1

VTT Technical Research Centre of Finland Vuorimiehentie 3, P.O. Box 1000, FIN-02044 VTT, Espoo 2 Microkatu 1, P.O. Box 1199, FIN-70211, Kuopio 3 Kaitovyl 1, P.O. Box 1100, FIN-90590, Oulu Finland

{firstname.lastname}@vtt.fi ABSTRACT
Smart 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 heterogeneous devices, from high-end PCs to embedded gadgets and sensors. We propose a novel security architecture, which enables heterogeneous devices to share data in controlled manner. Centralized information brokering device is used to measure security level of published information. These measurements are then used to 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 security solution for smart spaces. of services, which are more autonomous and intelligent. One major challenge in this development is the interoperability as there are different technologies and manufacturers with different motives. In the past, the standardization has been very successful in solving interconnectivity issues in OSI [32] layers 1- 5. As a result 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 devices. Smart spaces consist of two kinds of architectural elements that 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 developed e.g. in the Smart-M3 project [21]. In order to enable interoperability, 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 eXtensible 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 Bluetooth (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 are heterogeneous, 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 dynamic nature 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 describe 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 then use these measurements to control information access. Our access

Categories and Subject Descriptors

C.2.0 [Computer Systems Organization]: communication networks general. Computer-

General Terms
Design, Security

Keywords
Architecture, communication security, interoperability, access control, smart space.

1. INTRODUCTION
The amount of different networked devices which are either personal 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, printers, mobile phones, navigators, game consoles and climate control equipments. This availability of network gadgets is helping our everyday life. Further, it has made possible to develop new kinds
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

control solution is flexible. The unique measurement system enables the use of various open security standards. Consequently we can utilize matured and known to be trustworthy security mechanisms 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 personal smart spaces by using public or shared information brokers. Security architecture is suitable also for embedded resource restricted devices. Hence, we discuss and propose a model for propagating access control policies in a manner that enables an easy control over the information published by embedded devices in finegrained manner. The rest of this paper is organized as follows. In section 2.1 information security threats, risks, vulnerabilities and possible attacks in different smart spaces are considered. In Section 2.2 potential security building blocks are surveyed. Section 3 describes our security architecture for smart spaces. Section 4 provides discussion on the idea and implementation. Then in Section 5 our architecture is compared to related work. Finally, Section 6 summarizes the paper.

for one or few users. Security or safety critical configuration data may be available only for some highly trusted users using trustworthy devices, whereas some less critical information may be available for every smart space user. 3. 4. Confidentiality of communication should be enabled e.g. for privacy critical applications. A smart space should provide mechanisms for monitoring and control over devices security attributes. The amount and physical restrictions of embedded devices within smart spaces 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 and remote configuration are needed.

2. BACKGROUND 2.1 Security Threats and Requirements

Devices 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 and safety issues and, thus need to concentrate on integrity and authenticity of communication. With personal devices, the availability 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 business secrets. As the same devices are used in various smart spaces, we must provide flexible security solutions. Consequently, service and communication platforms must enable smart spaces to adopt different security functions. Particularly, the following functions should be supported: 1. Authenticated and integrity protected communication. Information brokers and smart space devices should be able to mutually authenticate direct communication parties. Information consumers may also need to authenticate information publishers. However, in some smart spaces information providers may want to guard their privacy and prevent forwarding of their identity. Smart space and information access must be authorized Information publishers and smart space administrators may need to control who can access smart space services and information. 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

Smart space devices have different security characteristics and abilities. Some devices cannot provide all possible security functions e.g. due to battery or communication restrictions. Devices with limited input and output user interface capabilities are difficult to pair securely and they cannot be configured without a help from other devices. On the one hand, it is not feasible to implement every potential security protocol into every device, particularly if these devices are memory restricted and/or have a connectivity-specific security protocols. On the other hand, some security functions (such as heavy algorithms and long security keys) are necessary for some critical applications. Consequently, as smart spaces should support different kinds of devices, there is a need for interoperability and gateway solutions. Heterogeneity of devices and interoperability solutions in smart spaces imply versatile protocols and messaging formats. Processing 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 be more 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 security tested interfaces. Configuration of appropriate security levels and access control policies is a major challenge for smart space implementations that are typically administered by typical non-expert users. Particularly, if there is a need to make this control in fine-grained manner, the policy configuration and deployment is to be kept as simple and unambiguous as possible. Furthermore, smart space platforms should be flexible enough for various access control schemes and policies, customized and deployed for different smart spaces.

2.2 Building Blocks for Smart Space Security

There exists a large amount of existing research, standardization work, and implementations of security mechanisms, which can be utilized in smart spaces. These mechanisms include the use of cryptography in the different levels of communication, key establishment and management schemes, access controls and authorization solutions as well as robust implementation techniques. Figure 1 illustrates how some of these security technologies fit to the layers of semantic web.

2.

206

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 pairing and encryption solutions for protecting authenticity, integrity and confidentiality of messaging. See e.g. [5, 16] for specifications related to Bluetooth and WiFi security and [23] for a survey on standardized pairing mechanisms. Middleware standards such as 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 communication. For web services, the World Wide Web Consortium [30] has specified syntax for XML signatures, encrypted documents and key management. Security levels and access control policies must be described by a language, which is understandable for remote devices so that centralized monitoring and control is possible. XML based eXtensible Access Control Markup Language (XACML) [20] is one example of languages describing how to interpret policies. Achieving a single standard description is not feasible in heterogeneous smart spaces. However, ontologies can be utilized to ease interopPD

erability. Security ontologies describe security concepts and their relationships, typically using XML based notation. Individual devices 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 security terminology 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 Applications [8], have also adopted elements for defining access control policies. The challenge of configuring complex access control policies has been addressed with different access control models. These models classify access control objects and subjects into groups. For example, a prominent model is the classification of subjects according to the role based access control model [13]. Also, the privacy and contextual questions have gained attention. For instance, 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 ARCHITECTURE
Our proposed security solution protects confidentiality and authenticity of information exchange between the heterogeneous information providers and consumers as well as information broker. Furthermore, remote monitoring and control of systems security state are enabled as well as different (fine and coarse-grained) access control and authorization solutions over smart space and information access. The proposed security architecture for smart space is illustrated in Figure 2. The key component is the RDF

RIBS
(Information Broker) - Measure Security Level - Enforce Security Policies
Security attiributes
PD C

Authenticate / Protect Confidentiality

Authenticate / Protect Confidentiality

INFORMATION

INFORMATION

Control Security Level

Security Monitors
Status, alerts

Control Smart Space Access

Control Smart Space Access Control Inf. Access

Security Administrators

Control Smart Space Access Authorize Information Access

C

KP ID

PD

Information Publisher KPs

Authorize information access Authenticate publisher KP

Information Consumer KPs

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).

207

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 Security

RIBS is a server, which is used by KPs to store, retrieve, manipulate 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 protect access to information they provide. All data communication between RIBS and KPs can be mutually authenticated and encrypted. The solution is not tied to any specific security mechanism and, thus, any key management scheme, pairing model, security protocol, or encryption algorithm could be integrated to the system and used 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 deployments 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 available pairing 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 smart space. 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 information, it negotiates a security session with RIBS. During this handshake both parties verify that the peer has valid smart space credentials. Further, RIBS enforces that the communication session fulfils the minimum security level requirements set for the smart space. In addition to parameters of security protocol, RIBS also 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 handshake procedures. The solution enables consuming KPs to identify KPs, which have provided information. When data is inserted, the broker may store identities 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 published for monitoring applications. These features may be disabled in order to protect privacy of publishers.

Measuring whether particular mechanisms are strong enough is done by using security levels. Security levels are coarse grained measurements 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 following categories: 1. Pairing method i.e. devices smart space deployment information (i.e. information on what pairing mechanism was used when the device was associated to the smart space and certified). This information is given for KP during smart space association and carried e.g. in X.509 certificates. Authentication i.e. mechanisms for user and device identification for protecting the authenticity of communication. This mechanism is negotiated during security protocols handshake. Keying i.e. the used protocol for changing of the network keys. This mechanism is negotiated during security protocols handshake. Cipher i.e. mechanisms for encrypting communication. This mechanism is negotiated during security protocols handshake. Platforms trust parameters - RIBS may resolve run-time trust information (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 the KP using e.g. Trusted Network Connect protocol.

2.

3.

4.

5.

RIBS uses these security measurements to determine security levels 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 described 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 attacks are 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 implementations are evaluated, existing (e.g. cryptological) analyses and information from vulnerability databases may be utilized. Table 1. An example of security level classification. Security Level No Low Description Security is not provided at all Pairing methods without authentication, authentication algorithm Authenticated pairing, authentication & encryption based on asymmetrical cryptography Authenticated trusted pairing, authentication and encryption (that Matching Security Standards

3.2 Profiling Security Levels

Different security characteristics within smart space devices cause an interoperability challenge. RIBS does not dictate that every KP must utilize particular security mechanism. In our security approach, 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. Medium

BT v2.1 just-connect pairing, BT v2.0 pairing (PIN based), TLS-DES , WUSB numeric association, BT v2.1. outof-band pairing, TLS,

High

208

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-digit PINs (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 occurs over WiFi and TLS. TLS utilizes RSA (Rivest-Shamir-Adleman) and AES (Advanced Encryption Standard) or 3DES (Triple-Data Encryption 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. The security 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 security but is also usable enough for end-users to understand. However, it is possible to define different security levels for different smart spaces. For instance, in a smart space that has none needs for typical end-users to control security, we may have multidimensional security levels (e.g. dimensions for strength of authenticity and confidentiality). In the future, it might also be possible 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 RIBS again. If changes are allowed, a KP querying data cannot know if that data has been inserted by a trusted KP. Also a KP inserting data 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 information accordingly.

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 (concepts and elements) are illustrated in Figure 3. Access control policies define which subjects are allowed to access which objects. In proposed architecture, subjects are authenticated using identifiers given (in credentials) by security authority. These identifiers are unique numbers identifying both the KP and potentially also end-user (in case of personal devices) and groups (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. Authorization also depends on the security level of a requester. The security level may be required to be the same as the security level of information provider, the security level specified separately or the default smart space security level. An access control policy may be 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 Spaces for the end-users. In this case, the broker assures that information coming from devices, 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 define, which devices are personal. At the same time end-users may utilize existing brokers in homes and offices. This privacy configuration model can be implemented, if the i.e. owner of particular devices can be authenticated. The concept may also improve usability as list of available services can be filtered according to this information.

3.4 Policy Deployment

When new KP or RIBS devices are introduced to the smart space, security policies controlling their access permissions and security levels must be set. These policies can be configured and deployed in various manners. Our centralized solution is focused on resource and UI-restricted, embedded devices, operating in dynamic
Action class Object class (domain)

3.3 Information Level Access Control

In some smart spaces, access to information must be controlled in a more fine-grained manner than the smart space level. Particuhas Subject classes (roles...) is categorized to has Policy requires particular sec-level & privileges

Privileges has Identity

is categorized to

is categorized to

Subject

has permission to do

Action

on

Object

requires protection with End-user Knowledge processor Achieves with current mechanisms Security level

Broker (smart space) was protected with

Information processed by broker

Origin (KPs ID)

come from

Information stored in broker

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.

209

smart space environment. Therefore, we propose a solution, which does not require end-users to directly configure information provider devices. Neither, does our solution require information brokers 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 first time, 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. Advantage 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. writable 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 using mechanisms 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 able to break lower security level was able to do that already when data was inserted. In the case of embedded devices, requirements for access policies are typically tied to the type of system, device or application. For instance, all information produced by thermometers may be readable for every device within smarts space. Therefore, a single policy directive is sufficient for these devices. In case a device has more versatile security needs, it may utilize several policy directives (if directives are delivered with certificates it must also renegotiate TLS session). Challenges are met in those smart spaces, where RIBS devices can be changed dynamically, and in those smart spaces, where multiple authorities may exist. In smart spaces where RIBS devices are changed and information is migrated, also policies must be migrated. In smart spaces with multiple authorities, RIBS is required to map certifier identities, from KPs certificates, to policies, which are coming from different authorities.

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 Protocol (SSAP) (see e.g. [14, 21]). The security layer was implemented below the SSAP protocol in order to maintain compatibility 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 top of 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.509 standards due to their wide acceptance, availability, and high security level. The socket layer negotiates TLS sessions and routes communication to TLS sockets. Future implementations may support 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 sufficiently 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 handshake. However, when the amount of messages increases, also the relative penalty of TLS decreases. Security polices specify who are allowed to access to what information and what is the minimum security level for this access. In addition to identifiers of authorized users, the policies include information 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 information. This identity and security level information can be queried by KPs, which need to authenticate the source of information and which trust RIBS. When a new device is for the first introduced to a smart space, it gets the X509 certificates and private keys from security administrators 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 credentials). 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 device with several applications with different access control needs, requires several certificates. When new information is stored to RIBS, a related security policy is either derived from the policy directives and sessions security state or, if directives are not available, 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 responsible of resolving security parameters from TLS sessions and certificates. In RIBS, these security parameters are also mapped to security strength information in order to derive security levels. Implementation controls currently read and write operations over in-

4. DISCUSSION
The proposed approach differs from typical communication security 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 brokering RIBS device, which must be trustworthy. In the case that RIBS cannot be trusted to provide sufficient security level, information stored to RIBS must be signed or encrypted and communicating KPs must have their own interoperable means for validating or decrypting this information. In this, applications may utilize smart space credentials and, hence, separate key management solution 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 authentication and encryption scheme would not increase the security at all. This is because in many smart spaces, the RIBS device acts also as security administrator device (i.e. it is the certification authority). In these cases, RIBS would anyhow be able to masquerade as any KP. Information brokered by RIBS can be any application specific data. For instance, RIBS may distribute credentials and cryptographic keys providing access to application specific services or

210

formation. However, the modular implementation can be easily extended to support other services and different actions.

rity policy configuration and deployment models as our proposal does. Security and access control has been integrated also to other publish and subscribe architectures. For example, role-based access control has been integrated [3] to Hermes architecture. The GEMOM project has proposed messaging oriented middleware [1]. GEMOM also propose mechanisms for adapting security according to peers requirements. However, their proposal does not discuss how to enable clients to use different transport specific security mechanisms. The measurement based security leveling and support for heterogeneous security technologies make our proposal unique.

5. RELATED WORK
Access control and authorization solutions applied in personal and home networks typically have a very coarse-grained access control. Only office environments embody more detailed access controls. With some technologies the management of fine-grained access 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 particular security level. However, these solutions do not enable use of different 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 Windows networks 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 instance, Secure Middleware for Embedded Peer-to-Peer Systems (SMEPP) [6] has focused on the secure cooperation between embedded devices. Like our solution, SMEPP is able to adapt security levels according to devices capabilities and needs. Another approach, OpenHouse [22], provided a secure platform for homes. It addressed access control within UPnP service level. The use of TLS enabled security level to be adapted into devices capabilities. OpenHouse addressed the interoperability challenge with domain-specific adapter devices, which were positioned between network and legacy appliances. Our security solution is used under middleware layer (SSAP) but it is not middleware itself as compatible security software are not required for each smart space device. 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 middleware. For instance, the researches in POBICOS (Platform for Opportunistic Behavior in Incompletely speCified, heterogeneous Object CommunitieS) project propose [24] an approach to implement secure network management and confidentiality in a distributed low capacity sensor networks. The solution enables the user 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 One Network Key Approach and an Identity-based Cryptography Approach. The approaches are alternative and selectable by application developer. The security of the approach is based on utilization 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 security card with close proximity. The approach does not consider secu-

6. CONCLUSIONS
We have designed and implemented a flexible security architecture, which enables heterogeneous devices to share data in controlled manner. The architecture is based on measuring security level of joined smart space nodes. Information brokering component utilizes this measured information to 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 have also proposed policy configuration and deployment models, which are feasible and usable with embedded devices.

7. ACKNOWLEDGMENTS
We thank Eila Ovaska for valuable feedback. This work was done within EU/ARTEMIS project SOFIA (Smart Objects For Intelligent Applications), which has been co-funded by Tekes (the Finnish 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 Measurable Progress beyond the State of the Art. In Systems and Networks Communications, 2008. ICSNC '08. 3rd International Conference. (Sliema, Malta, Oct. 26-31). IEEE Computer Society, 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 publish/subscribe middleware architectures. In The 2nd international 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 Specifications. Available: http://www.bluetooth.com/NR/rdonlyres/F8E8276A-38984EC6-B7DA-E5535258B056/6545/Core_V21__EDR.zip.

211

[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 Services, 2004. MOBIQUITOUS 2004. The First Annual International Conference. (Boston, Massachusetts, USA, Aug. 2226). IEEE Computer Society, 258-267. [9] Denker, G., Kagal, L. and Finin, T. 2005. Security in the Semantic Web using OWL. Information Security Technical Report, 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 Security (TLS) Protocol. Version 1.1. IETF Specification. Available: http://tools.ietf.org/html/rfc4346. [11] Ellison, C. 2002. Home network security. Intel Technology Journal, 6, 4, 37-48. [12] Farrell, J. and Saloner, G. 1985. Standardization, Compatibility, and Innovation. Rand J. Econ., 16, 1, (Spring), 70-83. [13] Ferraiolo, D. and Kuhn, R. 1992. Role-Based Access Control. 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. CrossDomain 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. Internet X.509 Public Key Infrastructure, Certificate and CRL Profile. 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.11i2004.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 Pervasive 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 for Annotating Resources. In Confederated International Conferences, 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 specification. Available: http://www.ietf.org/rfc/rfc4120.txt. [20] OASIS. 2005. XACML 2.0 Core: eXtensible Access Control Markup Language (XACML) Version 2. Available: http://docs.oasis-open.org/xacml/2.0/access_control-xacml2.0-core-spec-os.pdf. [21] Smart-M3 project. Smart-M3 www-pages at SourceForge. 2010, 05/07, Available: http://sourceforge.net/projects/smartm3/. [22] Suomalainen, J., Moloney, S., Koivisto, J. and Keinnen, K. 2008. OpenHouse: a Secure Platform for Distributed Home Services. In The Sixth Annual Conference on Privacy, Security 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. Standards 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., Spyros Lalis, S., Paczesny, T., Taumberger, M. and Savolainen, P. 2009. Towards a Lightweight Security Solution for UserFriendly Management of Distributed Sensor Networks. In Smart Spaces and Next Generation Wired/Wireless Networking. 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 Library. 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 Ontology-Based Approach to Information Systems Security Management. In MMM-ACNS 2005. V. Gorodetsky, I. Kotenko and V. Skormin eds. Springer, Berlin, Heidelberg, 151-164. [28] UPnP Forum. 2003. UPnP Security Ceremonies Design Document 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 Publications, 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. W3C Recommendation. Available: http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/. [32] Zimmermann, H. 1980. OSI Reference Model The ISO Model of Architecture for Open Systems Interconnection. IEEE Transactions on Communications, 28, 4, (April 1980), 425-432.

212