2007-05--Similar-Architecture--and--Security--Anthony-Loftin

University of Arkansas – CSCE Department
RFID Agent Middleware – Final Report – Spring 2007
Architecture/Wrapper Comparisons
Anthony Lofton
Abstract
TagCentric is a collection of java classes that wrap RFID related devices (such as readers and
printers) and allows users to control them via XML messages. It is an application written on top
of the Ubiquity architecture, which is an open-source framework that provides system-level
support for the rapid construction of software agents. It provides basic services such as network
support, SML translation for agent communication, agent recovery, and GUI support. This paper
presents a comparison of the TagCentric and Ubiquity architectures to similar architectures.
These comparisons include plugin sources for message passing, security aspects, and
advantages/disadvantages. In addition, other ideas for implementing security in message passing
are presented.
Problem
TagCentric and Ubiquity will be released soon and ensuring their marketability is the next big
step. Knowledge of currently known software that do or use similar tasks need to be looked at to
ensure that this software is marketable and customers will find it to be beneficial to them.
Currently the architectures of other products may be similar to the architecture of TagCentric and
Ubiquity. Each of the individual software however will have their benefits and weaknesses. The
problem focused on in this paper is to identify the weaknesses of the current architecture of
TagCentric and Ubiquity and compare it to other similar architectures.
Objective
The objective of this project is to research architectures that already exist and ones that are
similar to the current architecture for TagCentric and Ubiquity. Wrappers or designs of wrappers
that could be used to enhance the current architecture are also researched.
Design
Background
The University of Arkansas RFID center opened in the spring of 2005. A group of RFID students
decided to work on a project to design and implement RFID and control software. Deciding to
start with the control software, the students realized that there was no “glue”, no “backbone” to

start working on for the project. Ubiquity is software that was created in order to act as the
framework for an RFID control center [1].

Page 1 – October 21, 2022


Architecture/Wrapper comparison

While the Ubiquity Architecture was crafted to fill a need for the RFID application, it is designed
to be applicable to any agent system [1]. This architecture allows not only RFIDs to be capable
of being used but also any other type of system such as TVs, toasters, sprinklers, as long as the
item made use of the agent system of the software.
TagCentric is currently being used by the University of Arkansas RFID Research Center – an
EPC Global accredited RFID testing and training facility – to manage RFID readers. The
research center provides businesses with information about RFID technology. One of their most
important services is to test RFID readers and tags on pallets of merchandise in order to discover
the best tag and replacement location on the pallet. TagCentric serves as one tool that the lab uses
in this process.
The TagCentric software was built on top of the Ubiquity architecture. The general goal of this
software effort is to provide a simple, open-source application capable of integrating RFID
readers, RFID tag printers, and a database of the user’s choosing [2].
Messages of both Ubiquity and TagCentric are being sent using XML over UDP/IP.
Related Work
The eclipse architecture is based on ideas similar to that of Ubiquity in the fact that they are both
plugin-type software. The idea of plugin software is to allow multiple devices the ability to
communicate to a “hub” using a similar language and allow communication between them. In
eclipse, the devices are IDEs. Their goal is to provide a core of services for controlling a set of
tools working together to support programming tasks [3].
Like the TagCentric and Ubiquity architectures, the eclipse architecture uses XML for plugin
identification. The eclipse plugin identification is based on the Eclipse Platform Plugin Manifest

Specification. The identifier is used to refer to a plugin inside of the manifest of other related
plugins [3].
There seems to be many similar ideas when comparing the Eclipse to the Ubiquity architecture.
Both seem to be control centers or frameworks for a collaboration of different items to come
together into one similar field. The thing that separates them the most seems to be that Eclipse is
more software-based where as Ubiquity is more physical hardware-based. Software-based
applications usually don’t have to worry too much about secure message passing because they
are generally on the same workstation. Ubiquity will have to worry more about this because of
the greater possibility that the hardware could be physically at great distances from each other.
Since Ubiquity was an idea to be a framework for RFIDs, secure message transport is a very
important concept. Without it, private information could be read and misused.
There are other companies who are introducing their plug-in architecture idea in which they will
connect many devices together in one common language or standard. These companies include
but not limited to Adobe [4], IBM [5], and MIT [6]. All of these architectures seem to use similar
ideas but don’t have any highly innovative ideas when related with one another.
Looking at the security aspect of the current system, ideas for security will have to be considered
due to the fact that the current architecture does not have security for message passing. A
conference paper was found that showed ideas for the wrapper architecture to a heterogeneous
data source [7]. The architecture also used XML for message passing and also introduced an
idea for security.

2


Architecture/Wrapper comparison

The focus of the wrapper in the paper [7] focuses on communication. It focuses on extracting
data from data sources such as databases, sending data to data sources, and detecting schema
changes from a data source. To allow for locally safe message passing, they divided the data into
two different types: local and global. This allows for message passing is done locally and

securely to take place instantly where as the global will have messages converted before
anything is sent.
Security in the paper [7] focuses on an agent that is in charge of reading and sending messages.
This agent detects if the message is sent is local or global and does what is required for the
message before sending it. If it receives a message, it again determines if the message is local or
global before performing what needs to be done to the message.
Another paper focused on the embedding SSL for security [8]. The paper itself focused on many
different types of network security approaches using SSL. The main difference between this
paper and TagCentric and Ubiquity is that they focus on TCP/IP instead of UDP. SSL-based
VPNs have many advantaged to embedded systems by providing sever authentication using SSL,
providing a variety of encryption standards that might be implemented, accessible by standard
software such as a web browser, and allows client authentication without storing passwords [8].
In terms of Ubiquity, and TagCentric, communication does not heavily rely on a response thus
adding these architectures could provide high network traffic if there are many devices and
readers that need to work with one another.
Another disadvantage that was mentioned in the paper [8] deals with key generation. The
symmetric key generator is computationally intense and cannot be easily and efficiently soured
out in hardware [8]. If RFID tags are to be used, implementing these key generators could raise
the price of the tags themselves.
Use Cases/Risks
Currently message passing inside of Ubiquity and TagCentric are unsecured. Most testing for the
software currently has been in a controlled local environment. Using this software in an
environment such as this does not usually contain any security threats that need to be addressed
as a result of message passing. However if this software will be used in more unsecure
environments, then security may be a higher concern.
The software may also be used to communicate across the network to locations in physically
different places. This shows a much greater threat of security since now anyone can sniff and
possibly read the messages being sent if there is not a proper amount of security.
Wrappers are code that can be placed on top of already existing code to allow easily extendable
features. In the case of message passing, a wrapper could be placed on top of the messages to add

security to the already existing software. Wrappers whose purpose is to accomplish the task of
message transport could technically be added to the design right now. However adding at the top
level could produce a lot of overhead and end up sending very big messages.
High Level Design Idea
There are a few approaches that could be implemented to provide a good level of security on the
current design.
Network Security Wrappers is code that can be placed on top of messages being sent and provide
a safe way for the messages to be transported across a network and generally use UDP or TCP. A
major problem with using these types of wrappers is their methods for encrypting the messages
3


Architecture/Wrapper comparison

may not be secure enough to trust for high level applications. Most of these types of wrappers
tend to be open source which can allow for some tweaks to be added to the current code enabling
more security to the original wrapper as a whole. A few available open source security wrappers
or explanations on how to use currently existing ones are given in the references [9], [10], [11],
[12].
Another approach to security could be to change the Transport agent inside of the Ubiquity
architecture. According to the Ubiquity architecture [1], all of communication is handled through
the Transport agent. Currently messages are translated to XML before they are sent across the
network via UDP.
Focusing on the ideas of the conference paper [7], the architecture seems to be rather easily
implemented as a replacement or add on to the current transport layer. The focus of the security
mentions having devices marked as local or global. Local devices communicating with other
local devices would require little to no security in terms of message passing while local devices
communicating with global devices would require more security to ensure safely transmitting
information.
The wrapper architecture is the basis for communication in this architecture described [7]. The

wrapper organizes all of the messages and routes them to the appropriate section. The main parts
of the architecture include a translator, XML wrapper, and an answer cleaner. The translator is in
charge of changing the message to the transport format depending on whether the device is local
or global. The XML wrapper is in charge of changing the translated message to XML. The
answer cleaner is an attempt to lower the total number of bits being sent across a network.
The transport agent inside of the Ubiquity architecture could add these elements to the current
architecture and allow for added security features. Underlining work may need to be done to
allow for the local or global status of devices to ensure their authenticity.
The final approach would be to allow for a Virtual Private Network (VPN) based on the
strategies given in the paper [8]. A VPN is a private data network that makes use of the public
telecommunication infrastructure, maintaining privacy through the use of a tunneling protocol
and security procedures [12].
Integrating a VPN type of software would easy since like a wrapper it would go on top of the
underlining code. There are many factors to consider when adding this type of network. First and
foremost would be the increase in network traffic. Due to the amount of possible devices that
could be using the VPN and the amount of possible messages that need to be sent, the overhead
may be too high to implement on a global scale.
Another possible problem would be the implementation of VPNs inside of hardware for message
passing. Either it would be done inside the hardware itself, or it would have to have an external
interface that it could be connected to for allowing the feature.
The final problem would be if it should be implemented outside of the software before hand or if
it should be integrated with the software itself. Leaving such a requirement could be a hassle for
customers interested to start using the software right away. Integrating the VPN in the software
may be possible by changing the Transport agent in Ubiquity alone however there could be other
things that need changing in order to allow key passing to be handled.

4


Architecture/Wrapper comparison

Tasks (as executed)
1. Understand/gain background to the architectures of Ubiquity and TagCentric and other
architectures which designs can be compared and contrasted.
2. Design of possible problems and fixes to current architecture design
3. Demonstrate and show the problems and fixes to the current architecture.
4. Document architectures and problems.
Schedule (as executed)
Semester Year
1. Understanding …
2. Design …
3. Demonstrate
4. Document …
Implementation
To be done next semester
Test Plan
To be done next semester.
Results and Analysis
To be done next semester.
Conclusions
TagCentric and Ubiquity seem to meet architectural standards based on current existing
architectures. The focus for the future of software needs to deal with security between message
passing inside of the two software architectures.
Future Work
The implementation of security features on message passing in TagCentric and Ubiquity should
be focused on in the future.
Deliverables
•

Final Paper – This paper contains information and references on similar architectures to

TagCentric and Ubiquity. It also gives reasoning to start focusing on the security of
message passing in the current architecture. Some design ideas for security are also
included.

Key Personnel

5


Architecture/Wrapper comparison

Anthony Lofton – Lofton is a PhD Candidate Computer Engineering major in the Computer
Science and Computer Engineering Department at the University of Arkansas. He has completed
relevant courses.
Acxiom Internship
Network Security
Computer Security
Database Management Systems
Lofton was responsible for research on other architectures/wrappers and to gather information
which could help the project.
References
[1] Ubiquity, />[2] TagCentric, />[3] Eclipse Plug-In Architecture, />[4] Adobe – Acrobat Development Center, />[5] IBM, DB2 Plug-in Architecture,
/>topic=/com.ibm.db2.udb.doc/admin/c0006185.htm
[6] AUTO-ID Internet of Things, />[7] Hongzhi Wang, Jianzhong Li, Zhenying He, “An Effective Wrapper Architecture to
Heterogeneous Data Source, Conference, IEEE, 2003
[8] Design Strategies for Secure Embedded Networks, />[9] Unix Host and Network Security Tools, />[10] TCP Wrappers for Security, />[11] Wietse’s collection of tools and papers, />[12] Top 100 Network Security Tools, />[13] VPN Technologies: Definitions and Requirements, />
6