The VIRTUS Middleware: an XMPP based
architecture for secure IoT communications
Davide Conzon, Thomas Bolognesi, Paolo Brizzi, Antonio Lotito, Riccardo Tomasi, Maurizio A. Spirito
Istituto Superiore Mario Boella
Torino, Italy
{conzon, bolognesi, brizzi, lotito, tomasi, spirito}@ismb.it
Abstract— Before a wider adoption of the Internet of Things
(IoT) vision occurs, many urgent technological and social
challenging issues still need to be addressed, including device
interoperability, systems autonomy, privacy and security
concerns, which could have a significant impact on several
aspects of everyday-life or potential end-user. Due to the very
large number of technologies normally in place within the IoT
paradigm, some type of middleware layer is employed to enforce
seamless integration of devices and data within the same
information network. Within such middleware, data must be
exchanged respecting strict protection constraints. Both the
networking and security issues have driven the design and the
development of the VIRTUS Middleware, an IoT middleware
relying on the open XMPP protocol to provide secure event-
driven communications within an IoT scenario. Leveraging the
standard security features provided by XMPP, the middleware
offers a reliable and secure communication channel for
distributed applications, protected with both authentication
(through TLS protocol) and encryption (SASL protocol)
mechanisms. The proposed architecture provides the possibility
to isolate an instance of VIRTUS, allowing the exchange of data
only within a private network. This paper presents an overview
of VIRTUS, providing an overall platform description and details
regarding its security features.
Keywords-component;Internet of Things, VIRTUS Middleware,
XMPP, OSGi, Security, TLS(SASL).
I. INTRODUCTION
Current research roadmaps ([1], [2]) define the IoT as a
physical and logical extension of the current internet, populated
by billions of intelligent networked devices or “things”. Within
this vision, devices will cooperate through open standards
providing ubiquitous and pervasive services, useful in many
application scenarios such as electronic payments, monitoring,
industrial applications, e-health solutions, and many more.
Due to the heterogeneity of existing networked devices in
terms of communication protocols and hardware features, as
well as computational models and exposed services, the IoT
concept is commonly associated with the idea of an
intermediate middleware layer handling miscellaneous data.
The term “middleware” is mostly tied to integration tasks and
covers a broad spectrum of roles, including networking and
communication, authentication, encryption, interoperability,
data processing, service support, context management as well
as horizontal issues (like security and privacy management)
[1].
This article is part of the work carried out within the regional project
“Piattaforma Tecnologica Innovativa per l’Internet of Things”, co-funded by
the Regione Piemonte (2009-2012).
978-1-4673-1544-9/12/$31.00 ©2012 IEEE
Regarding communication and networking features,
middleware solutions mostly deal with the goal of supporting
seamless communication among devices, based on various and
often unreliable communication channels (with intermittent
connectivity due to mobility or interference). From the
transport point of view, middleware solutions need to cope with
non-traditional communication models and opportunistic
techniques to provide services like data time-stamping, data
sorting, caching or flow-oriented information management.
Middleware solutions satisfy the need for interoperability,
providing unified data models and enabling resource sharing
between data providers and consumers. This is normally
achieved through open interfaces and protocols, usually with
links to technology-neutral standards such as XML or web
services. This issue also involves the need to support a variety
of programming languages, running on different hardware.
Communication support and enhanced interoperability are
normally exploited to support both data-oriented and service-
oriented communication paradigms, which can be both used to
support context management and more advanced features in the
area of artificial intelligence (e.g.: context reasoning, pattern
recognition, planning, semantic mapping or discovery). Among
the horizontal issues assurance of trust among devices and
infrastructures and proper access control to resources must be
provided. Contextually, as indicated by Fabian, B. et al. [3],
data-sensitive operations must be handled in a privacy-savvy
manner.
In order to address some of the aforementioned challenges,
this paper discusses both the VIRTUS architecture (as an
event-driven middleware leveraging on existing open standard
such as XMPP [4] and OSGi [5]) and its security aspects. The
security in IoT is essential, indeed, as analyzed by Atzori et al.
[6] there is general reluctance to adopt the IoT paradigm as
long as there are reliability risks that could represent serious
threats to security and privacy of data. In order to tackle this
double problem, the section II introduces main security issues
in IoT and, for the completeness of the whole discussion, it
briefly treats the main privacy issues. Section III introduces the
VIRTUS architecture, while section IV describes details about
the VIRTUS security approach. The last two sections provide a
practical sample application and draw conclusions.
A. Security & Privacy
IoT applications are vulnerable to security attacks for
several reasons: first, devices are physically vulnerable and are
often left unattended; second, is difficult to implement any
security countermeasure due to the large scale and the
decentralized paradigm; finally, most of the IoT components
are devices with limited resources, that can’t support complex
security schemes. The main security problems concern
authentication and data integrity. Authentication approaches
are difficult to implement, since they usually require
appropriate infrastructure and several exchanged messages
(unfeasible in most resource-constrained devices). Existing IoT
security solutions can be applied when a group of sensor nodes
are considered as unique entity (part of a more complex sensor
network), connected to the Internet through some gateways [7],
but, in the ideal scenario, a single sensor must be seen as a
single node of the entire IoT network. Finally, the existing
solutions don’t help to address the proxy attack problem [6].
Regarding data integrity protection, some preliminary
results exist for sensor networks (e.g., [8]), but new problem
should be raised: data can be modified by adversaries while it
is stored in the node, or when it travels through the network. To
protect data against the first type of attack, the solution is to
protect devices’ memory (e.g. EPCglobal Class-1 Generation-2
and ISO/IEC 18000-3 tags protect read and write operations
with a password). To address the second type of attack,
messages may be protected using some encryption method.
Although existing standards, such as AES, are already
implemented in some IoT devices, researchers are designing
new faster cryptographic mechanisms for constrained devices.
Sony’s CLEFIA is a block cipher that supports 128-bit keys
and the eSTREAM project has studied the robustness of stream
ciphers such as Salsa20/12 and Trivium. There is also research
on lightweight dedicated hash functions, as evidenced by the
SHA-3 competition [42]. An alternative to hash simplification
is offered by existing optimizations in operational modes,
which help to make data processing more efficient (e.g. data
integrity and confidentiality provided by AES-CCM and AES-
GCM). Another open point is to implement internet standards
security features: 6LowPAN and ROLL can be used for IP
connectivity, CoRE for lightweight web service and CoAP as
web protocol, but O. Garcia-Morchon et al. [9] stated the
difficulty in achieving security using Internet standards. The
IPsec protocol can be adapted to provide network-layer security
between Internet hosts and the devices with constrained
resources (S. Raza et al. [10]), but many other challenges are
hardly addressable [11]. It is necessary to underline that this
paper doesn’t treat low level security (e.g. ZigBee node to node
communication protection), supposing to rely on both
proprietary communication features and, when those features
are lacking, on other higher level technique (e.g. on algorithms
based on filters or reputation).
Privacy is recognized in most of all legislations and
worries about its protection represent a barrier against the
diffusion of the IoT paradigm. Many new occasions for
collecting personal information exist, considering that the cost
of information storage decreases constantly and the amount of
“attractive” private data increases. Hence, privacy must be
protected by ensuring that persons can control which of their
data is being collected, from who, and when this is happening.
Moreover, the personal data collected should support only
authorized services by authorized providers (e.g.: relying on
privacy broker [12]) and data must be stored only while strictly
necessary. Furthermore, to control the level of personal details
made public, the user should configure his preferences about
privacy, but this is not always feasible.
B. Existing solutions
In the last few years, many different middleware solutions,
for Internet of Things environment, have been designed and
developed, as the result of different research initiatives.
UBIWARE [15] aims at integrating all types of resources
found in an enterprise: smart devices, web services and
humans. UBIROAD [16], an extension of UBIWARE,
addresses interoperability between the in-car and roadside
devices. Both use Semantic Web and agent technologies to
define reusable security and privacy policies. SAI (Service
Application Integration) [17] is a message-oriented middleware
supporting context-aware application development, which
validates system’s components identity, controlling the access
to SAI-managed resources and guaranteeing messages integrity
and privacy. The SOCRADES project [18] uses SOA to enable
enterprise-level applications to interact with and consume data
from a wide range of networked devices, using a high-level
abstraction that features web services standards. It provides
devices authentication and access control. The SMEPP [20]
project develops a secure and general purpose middleware,
based on a network centric abstract model for Embedded Peer-
to-Peer Systems (EP2P), which deals authentication,
encryption, decryption, digital signature and infrastructure
security. The Hydra middleware [13] (also known as
LinkSmart) aims the Context-Awareness [14] through a
Service-Oriented Architecture (SOA). Hydra architecture
handles security features at application level, including as core
components the Network Manager, the Crypto Manager and
the Trust Manager (for secure networking), and an Access
Control Policy Framework (for resource control) [41]. The
Sensor Andrew project [19], the closest to the proposed
solution, provides a middleware designed to host a wide range
of sensors, actuators and distributed applications in the campus
of the Carnegie Mellon University. Devices are modeled as
event nodes within a publish-subscribe architecture adopting
the XMPP protocol, using encryption, authentication and
access control for security and privacy. Other interesting IoT
oriented middleware (such as Aspire, ubiSOAP, GSN or
WhereX) do not provide enough in-depth details regarding the
security issue.
C. Architectural Requirements in IoT
The main distinguishing features of the aforementioned
solutions have been identified in the orientation of middleware
to either services or data/events. Many solutions leverage on
Service Oriented Architectures. Although introducing clear
advantages, the SOA approach forces developers to focus on
features of each specific device. This makes the harmonization
that is needed to better support seamless autonomous
coordination among multiple entities more complicated.
Additionally, web-service driven architectures could introduce
a number of limitations, including stricter link with the physical
location of the devices/services, or at least their IP address and
high processing overhead, when large number of services must
be coordinated together. For such a reason, middleware
solutions such as [13] usually overcome limitations of
traditional SOA approaches by introducing additional
paradigms in conjunction. Middleware solutions, which are
focused on data and events, are instead usually more
lightweight and scalable, but underestimate more complex
features (including both the security, the discovery and the
services orchestration). Beyond this classification, assuming to
respect the basic IoT requirements (regarding complex
environment, heterogeneity in data representation, data
structure and semantic, operating systems and programming
abstractions), some capabilities are considered necessary: the
unique authentication of every single sensor/data source, the
communications encryption to ensure data integrity and the
existence of mechanisms to protect nodes’ memory when left
unattended. The first two have been taken into account while
designing VIRTUS, the third one has been skipped because
considered as node-level constraint.
II. INTRODUCING THE VIRTUS MIDDLEWARE
VIRTUS is characterized by a number of architectural
choices: the adoption of an existing Instant Messaging protocol
(easy-to-manage, large-scale and secure communication), the
use of Java-based architecture as core (portability issue) and the
use of OSGi (ensuring modular and dynamic architecture).
A. Instant messaging protocol analysis
Analysing the identified requirements, it has been observed
that the adoption of standard Instant Messaging protocols could
provide relevant support, concerning easy data and system
management and due to implicit security mechanisms offered.
A number of Instant Messaging protocols currently available
have been analyzed, including SIMPLE, JMS, IMPS and
XMPP.
SIMPLE, managed by IETF, is an open extension of SIP
(Session Initiation Protocol), the signaling protocol through
which is possible to start, configure and manage many
multimedia sessions (including voice and video). SIP offers
limited built-in security, but many recommended security
aspects of the protocol are lacking in existing implementations
[21]. It uses not only TCP but also UDP, and this can lead to
data loss and security problems. JMS [22] is a messaging
standard (extension of the JEE platform) that enables
applications to create, send, receive and read messages,
handling a loose-coupled, reliable and asynchronous
communication, but doesn’t provide features for controlling or
configuring message integrity and privacy. IMPS, defined by
Open Mobile Alliance, is widely distributed and tested
(although not used as messaging protocol) but doesn’t define a
security model and for this reason different implementations
vary greatly [23]. The IETF standard XMPP (eXtensible
Messaging and Presence Protocol), also known as Jabber, is
based on XML for the real-time messaging, for the exchange of
presence information and for request-response services. XMPP
supports a wide range of applications: instant messaging,
presence notification, multi-party chat, audio-video call and,
most generally, XML routing. XMPP is an open protocol and,
thus, is free and open-source, over the long period an open
standard provides stronger security, greater extensibility, and
more open to innovations than legacy technologies. XMPP is
proven and mature: after more than 10 years of development,
there are thousands of Jabber servers on internet and millions
users (e.g. while using Google Talk) and a large number of
applications have been developed using the IM functionalities,
in very different application fields. XMPP is fully
decentralized: everyone can use its XMPP server and manages
independently its network. XMPP is extensible: using the
potential of the XML, everyone can add features to the core
functions. XMPP offers interoperability features, such as:
HTTP binding, service discovery, file transfer, server
federation. Finally, XMPP natively provides a number of
security features, better discussed in section IV.
B. VIRTUS Architecture
The choice of the XMPP protocol provides VIRTUS with a
seamless communication layer to support its operations.
VIRTUS combines XMPP features with OSGi as a reference
framework (specifically using Knopflerfish [24]). OSGi
technology is a dynamic module management system for Java
and provides standardized primitives that allow applications to
be composed of small, reusable and collaborative components
(bundles or modules). OSGi provides functionalities for run-
time modules management and has been exploited in VIRTUS
in order to support the dynamic modules combination, to deal
with automatic management of dependencies and updates and,
finally, to simplify the configuration and the deployment. For
scalability reasons, the standard OSGi bundles communication
methods, based on Service Registry, have been considered not
suitable for IoT application and so replaced with XMPP and its
extensions. In particular the following communication
primitives have been used in the Middleware implementation:
<Message/> for getting information asynchronously from one
place to another; InfoQuery (or <IQ/>), for request-response
interactions, and <Presence/> to share the entities network
availability. In addition to these primitives, VIRTUS uses some
XMPP Extensions (XEPs) [25], including: the XEP-0030
(Service Discovery), needed to discover what entities are on the
network and exactly which XMPP features those entities
implement; the XEP-0050 (Ad-Hoc Command), which
provides workflow capabilities for any structured interaction
between two XMPP entities; the XEP-0060 (Publish-
Subscribe), that allows to subscribe to an information node and
then to receive a notification, only when an entity publishes an
item to that node, providing a scalable and real-time alternative
to constant and expensive polling for updates. Each module is
associated with an application logic and an XMPP account,
enabling each module to share its availability (through
presence) and to communicate with other modules (through
Message, InfoQuery, Pub/Sub and Ad-hoc Commands). This
account is used to authenticate, uniquely identify and
dynamically address every entity in the middleware, regardless
its physical location.
The core entities of a VIRTUS Middleware based solution
are (Fig. 1): an XMPP server (in the presented solution,
VIRTUS has been validated with the OpenFire [26] server, a
real time collaboration server, licensed under the Open Source
GPL license). A Manager module, which has the complete
knowledge of all the modules inside an instance (via its roster)
and is able to appropriately connect the different bundles. The
Manager provides a list of available modules (filtering by
namespace) and manages dependences. A Gateway module
acts as an interface to remote instances of the middleware and
to any external software requiring connection with local
instance. Any external communication has to pass through the
services provided by this entity. Because of its role of
“intermediary”, it has two active connections: one on the local
XMPP server, to communicate with internal modules, and one
to a public XMPP server, to communicate with other
middleware instances. Any other “custom” modules could be
developed to handle specific task (e.g. to manage an RFID
reader, to interface with a specific sensor), to implement ad-hoc
algorithms (e.g. for filtering purpose) or to connect to
databases, etc. This approach enables to flexibly build a
customized deployment of the middleware, adapted for each
specific purpose and context. In the VIRTUS architecture, there
are three different types of devices:
• Resource rich devices (like PC): can host the entire SW
architecture (OSGi, XMPP Server, SW modules).
• Resource-constrained devices (like Smartphones): use
the XMPP client library to connect to the XMPP
Server, interacting with other modules.
• Simple devices (like sensors or RFID reader): use a
“custom entry module”, hosted on a less poor device,
to encapsulate their data in an XMPP message. In
typical IoT platforms like TinyOS and Contiki, or
sensor middleware like LooCI, RUNES or Gridkit,
interacting with simple devices, means to develop
some specific bundle to handle a specific interface
(Fig. 2).
Concerning this hierarchical architecture, sensors nodes are
not able to autonomously interact with other entities in the IoT,
but need to encapsulate their XMPP messages through less
resource constrained devices. In the future, when sensors will
be more performing, they may directly communicate via
XMPP (as already developed for Contiki OS devices in [27]),
breaking down this partial limitation.
VIRTUS uses only XMPP for the entire communication
both intra-domain and inter-domain, but, to preserve
interoperability with other solutions (a very important aspect in
the world of distribute applications), mechanisms allowing to
exchange data with application using different communication
protocol have been developed (e.g. for traditional SOA
architectures using web services). VIRTUS, according to the
Hurwitz’s classification [28], fits into the group of
publish/subscribe middleware, but its architecture allows to
address most of the problems identified for these solutions (like
messages ack and device presence).
Figure 1. Virtus MW Architecture Layers
Figure 2. Simple Devices Management principle
III. THE VIRTUS SECURITY APPROACH
The XMPP communications security has been formalized
with the publication of the core XMPP specifications plus RFC
3920 and RFC 3921 [29], where main relevant extensions are
security, authentication, privacy and access control. The
VIRTUS middleware security approach, aimed at obtain a
secure decentralized client-server architecture, exploits these
relevant built-in security policies (such as user authentication,
channel encryption and prevention of address spoofing), and
achieves an intrinsic safety due to the chosen architecture.
A. Session Negotiation and client to server XML Stream
security
The negotiation actually starts after the DNS XMPP
Service lookup and the opening of a TCP (duplex) connection.
The client sends an initial stream header and the server opens a
response stream by sending an opening tag, containing unique
stream ID specifically generated for the session. Then, the
server sends a list of supported features for securing and
compressing the connection. After the authentication and
further negotiations, the communication starts. The client, to be
compliant, must support both TLS and SASL (Fig. 3).
TLS (Transport Layer Security – RFC 2246 [30]) provides
a reliable mechanism to ensure the confidentiality and data
integrity, encrypting XML streams as defined along a
"STARTTLS" extension (RFC 2595 [31]). The extension
allows: to prove the identity of the server, to prove the identity
of the user (optional), stream encryption and data integrity
transmission. SASL (Simple Authentication and Security Layer
- RFC 4422 [32] and RFC 2222 [33]) guarantees server
validation through an XMPP-specific profile, by means of
authentication, optional encryption (rarely used) and pluggable
(e.g.: passwords, Kerberos, X.509, SAML, etc.). General steps
in TLS/SASL negotiation are: 1) XML streams are opened and
TLS is negotiated, 2) a new stream is opened, and SASL is
negotiated and 3) a new stream is opened for the application-
domain specific communications.
Figure 3. TLS and SASL connection
B. Multidomain Server Federation
In order to allow systems interconnections XMPP provides
a server federation support. One of the issues of these
interconnections is the resource accesses control, thereby
implying the identity management interoperability. XMPP
offers a solution to connect identity management system of
different information systems, but, being service provisioning a
matter of policy, federation support is optional. Depending on
the type of application and security requirements, the federation
could be Weak or Strong. The first one provides only fragile
identity verification of a peer server, without confidentiality or
integrity support (as defined in XEP 0220 [25] - Server
Dialback). This widespread practice allows the downgrade
attack, if an attacker can gain control of the channel and,
therefore, convince the initiating server that the receiving
server doesn’t support TLS or does not have an appropriate
certificate. To prevent this attack, the parties must protect the
channel using TLS even if the presented certificates are self-
signed or otherwise untrusted. Instead, we talk about strong
federation if server enables full federation, guaranteeing both
authentication and confidentiality through TLS + SASL
EXTERNAL, as defined by Saint-Andre [29].
C. Architectural Security
Despite all the security features offered by the XMPP protocol
(including the upon mentioned servers federation), when data is
exchanged over the internet, the risk that it may be intercepted
or modified by malicious entities is always present. For this
reason, the VIRTUS architecture has been designed to allow
the insulation of one or more instances from internet in the case
of higher security requirements (Fig. 4). Keeping sensible data
inside the private network is a way to reduce security and
privacy risks. Another reason of this choice is that usually, in
some "sensible application", the third party operator (the actual
service provider) doesn’t want to circulate his data outside his
private network, simply to totally reset attack risks. The
insulation is possible because, in the VIRTUS architecture,
every instance uses a different XMPP server. If this server is
located inside a private network, all the modules of the
instance, connected to that server, can communicate with each
other, without exposing their data on internet. In this special
case, the architecture of the solution is different than the
original described in section III, because the Gateway is not
needed (no connections with external entities exist) and for this
reason, it can be not installed in the instance. In case of less
strict security requirements, the VIRTUS architecture enables
to choose what data must be available from outside of a
VIRTUS instance, and what data must be hidden.
Figure 4. Multi-instances VIRTUS architecture
In fact, each middleware module (each OSGI bundle) can
be configured through an XML file, specifying (besides other
parameters) if produced data and ad-hoc commands offered are
available or not, outside of the VIRTUS instance, where the
bundle is deployed. In this way, the user can choose which data
is available from other domains (or software). This
configuration can be changed at run-time, without restarting the
module or the entire solution. For example, the manager of an
instance of VIRTUS can configure a temperature sensor to
publish periodically its data, also to other domains, and make
publically available an ad-hoc command to force a detection; at
the same time, he can provide, only locally, a set of commands
to manage the sensor (stop/restart of the sensor, change of the
period of detection). In this way, the sensor has two interfaces:
one public that can be used to access to its data and one private,
available only for local users, who can manage the sensor
configuration. Another sensor can be configured to publish data
and to provide ad-hoc command only locally, making its data
available only within the instance of VIRTUS, where the
sensor is deployed.
IV. CASE STUDY
VIRTUS has been validated in several application scenarios,
ranging from energy consumption monitoring, to logistics, to
intelligent mobility. The case study here analyzed is a
homecare solution developed inside the project “Piattaforma
Tecnologica Innovativa per l’Internet of Things” (Innovative
technology platform for the Internet of Things). This
development brings out the full potential of VIRTUS,
leveraging on its feature to design a modular, secure and high-
scalable homecare system. Within the project, VIRTUS has
been integrated with a different web-service based middleware.
Namely the Hi Reply system [34]. The resulting solution uses
different medical instruments to detect the patients’ vital signs;
every instrument measures a different parameter and has a
proprietary communication protocol. Through the middleware
bundles, all data is encoded in a XML format and included in
standard XMPP messages. In this way, data can be received
and parsed from all the others middleware bundles. The system
can be remodeled for every instance, installing only the drivers
for the devices needed by the patient. Thanks to the XMPP
protocol, the solution can scale, managing a high number of
patients. Those XMPP scalability performances were measured
by the Openfire developers’ team (as shown by tests analysis
[35]). Finally, the data can be exchanged over the internet, in a
reliable way, and are available only for authorized people. The
solution uses the following modules: a set of wireless medical
devices to detect vital signs of the patients (Fig. 5) with their
driver bundles, a module that controls an embedded database to
store the data, and an interface used by the caregivers to
monitor the patients. As explained in section III, there are two
possible levels of security and privacy provided by VIRTUS: in
case of multi-domain solutions, with the patients located in
their homes and the caregivers that monitor them from remote,
the architecture guarantees that: only the patients data,
configured as public, is published over the internet, all the other
data remains in the local instance; the data exchanged is
available only by authorized people, that must be authenticated
before to access to the resources.

Figure 5. Medical devices used
All the internet communications use the XMPP protocol
and its security features. Instead, in other systems, like the
monitoring of the patients of a nursing home, is possible to
“isolate” the instance, making data available only inside the
private network of the structure, with higher levels of security
and privacy.
V. CONCLUSION
The paper has presented VIRTUS, a middleware solution
for management of applications in Internet of Things
environments adopting open standards such as XMPP and
OSGi. The use of the “publish & subscribe” paradigm and the
native XMPP security features (instead of other typical
middleware approach, based on SOAP-WS mechanisms and
custom security capabilities), simplify the IoT deployment.
Furthermore, the possibility to totally isolate a VIRTUS
instance adds another built-in network security level. The
VIRTUS development has been inspired by previous research
works ([36], [37]); it has been already employed in a number of
practical application scenarios [38] and is objective of current
national (see section IV) and international research project [39].
Ongoing activities are covering integration with other
platforms (e.g.: ICE [40]), while future research will be focused
on reasoning and filtering features, objects’ discovery and
semantic addressing.
REFERENCES
[1] Vermesan, O., Friess, P., Guillemin, P., Gusmeroli, S., Sundmaeker, H.,
Bassi, A., Jubert, I., S., Mazura, M., Harrison, M., Eisenhauer,M.,
Doody, P., “Internet of Things Strategic Research Roadmap. s.l.”,
European Commission, 2009.
[2] Cooperating Objects NoE. “Research Roadmap on Cooperating
Objects”, Bruxelles, European Commission, 2009.
[3] Fabian, B., Gunther, O., “Distributed ONS and its Impact on Privacy”, in
ICC 2007 proceedings, Scotland, 2007.
[4] XMPP Standards Foundation. XMPP. [Online] http://xmpp.org/.
[5] OSGi Alliance. OSGi main. [Online] http://www.osgi.org
[6] Atzori, L., Iera, A., B., Morabito, G., “The Internet of Things: A survey
Computer Networks”, in: The International Journal of Computer and
Telecommunications Networking. Volume 54 Issue 15, October, 2010.
[7] Eschenauer, L., Gligor, V., D., “A key-management scheme for
distributed sensor networks”, in: Proceedings of the Ninth ACM
Conference on Computer and Communications Security, USA, 2002.
[8] R. Acharya, K. Asha, Data integrity and intrusion detection in wireless
sensor networks, in: Proceedings of IEEE ICON 2008, New Delhi, India,
December 2008.
[9] O. Garcia-Morchon et al., “Security Considerations in the IP-Based
Internet of Things,” IETF, Mar. 2011.
[10] S. Raza, T. Voigt, and U. Roedig, “6LoWPAN Extension for IPsec,”
Proc. Workshop Interconnecting Smart Objects with the Internet,
Internet Architecture Board, Mar. 2011.
[11] Rodrigo Roman, Pablo Najera, and Javier Lopez, Securing the Internet
of Things, IEEE Computer, vol. 44, no. 9, pp. 51-58, September 2011
[12] Lioudakis, G.,V at all, “A proxy for privacy: the discreet box”, in:
EUROCON 2007, Poland, 2007.
[13] Project Hydra. [Online] http://www.hydramiddleware.eu/news.php.
[14] Hoffmann M. at al., “Trust and Privacy supported by Context-Aware
Middleware”, in: 18th WWRF Meeting, Finland, 2007.
[15] University of Jyväskylä, FINLAND. UBIWARE. [Online]
http://www.cs.jyu.fi/ai/OntoGroup/UBIWARE_details.htm.
[16] Terziyan, V., Kaykova, O., Zhovtobryukh, D., “UbiRoad: Semantic
Middleware for Context-Aware Smart Road Environments”, in: ICIW
naFifth International Conference, 2010.
[17] Parlanti, D., Paganelli, F., Giuli, D., Longo, A., “A Scalable Grid and
Service-Oriented Middleware for Distributed Heterogeneous Data and
System Integration in Context-Awareness-Oriented Domains”, The
Internet of Things - part 2. 2010.
[18] SOCRADES Project.[Online] http://www.socrades.eu.
[19] Carnagie Mellon University. Sensor Andrew. [Online]
http://www.ices.cmu.edu/censcir/sensor-andrew.
[20] SMEPP. [Online] http://www.nics.uma.es/projects/smepp.
[21] Mark Collier, 2005, “Basic Vulnerability Issues for SIP Security”
[22] Java Message Service, [Online]
http://www.oracle.com/technetwork/java/jms.
[23] Mäkeläinen, S., I., Michael, M., P., “Instant Messaging and Presence-
seminar”, OMA IMPS, Helsinki, 2005
[24] Knopflerfish Project, [Online] http://www.knopflerfish.org/.
[25] XMPP Extenstions, [Online] http://xmpp.org/xmpp-protocols/xmpp-
extensions.
[26] Ignite Realtime. Openfire Project. [Online]
http://www.igniterealtime.org/projects/openfire.
[27] XMPP for Contiki. [Online] freaklabs.org/index.php/Blog/News/XMPP-
for-Contiki.html
[28] Hurwitz, J., “Sorting Out Middleware”, DBMS magazine 11.1, 1998
[29] Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol
(XMPP): Instant Messaging and Presence,” [RFC3920-3921], 2004.
[30] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A., and P. Kocher,
“The TLS Protocol Version 1.0”, [RFC 2246], January 1999.
[31] Newman, C., “Using TLS with IMAP, POP3 and ACAP”, [RFC 2595],
June 1999.
[32] Melnikov, A. and Zeilenga, K., “Simple Authentication and Security
Layer (SASL)”, [RFC 4422], June 2006
[33] Myers, J., “Simple Authentication and Security Layer (SASL),” [RFC
2222], October 1997
[34] The Reply Research and Development centre for the Internet of Things, ,
[Online] http://www.reply.it/en/practices/iot/.
[35] Ignite Realtime. Openfire Scalability [online]
http://www.igniterealtime.org/about/OpenfireScalability.pdf
[36] Pastrone,C., Spirito, A., M., Tomasi, R., Rizzo, F., “A Jabber-Based
Management Framework for Heterogeneous Sensor”, in: International
Journal of Software Engineering and Its Applications, July, 2008.
[37] Forno, F., Sciarappa, A., “RFID in the Internet of Things: from Static to
the Real-Time”, in: RFIDDays 08 Proceedings. s.l., 2008.
[38] Brizzi, P., Lotito, A., Ferrera, E.,, Conzon, D., Tomasi, R., Spirito, A.,
M., “Enhancing traceability and industrial process automation through
the VIRTUS middleware”, Middleware ‘11, Portugal, 2011.
[39] The PigWise Project, [Online] www.pigwise.eu.
[40] ICE, Internet Communications Engine, [Online] http://www.zeroc.com
[41] Badii, A., “Future Internet Architectural Layers to Support Secure
Pervasive Technologies”, in: proceedings of IoT2010, Japan, 2010
[42] SHA-3 competition, [Online] csrc.nist.gov/groups/ST/hash/sha-3