Currently the architectures of other products may be similar to the architecture of TagCentric and Ubiquity.. The problem focused on in this paper is to identify the weaknesses of the cu
Trang 1RFID 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]
Trang 2While 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
Trang 3The 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
Trang 4may 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
Trang 5Tasks (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
Trang 6Anthony 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, http://www.csce.uark.edu/~cwt/COURSES/2007-01 CSCE-490-590 RFID-Agent-Middleware/DOCS/2006-08 Ubiquity-Architecture.doc
[2] TagCentric, http://www.csce.uark.edu/~cwt/COURSES/2007-01 CSCE-490-590 RFID-Agent-Middleware/DOCS/2006-08 TagCentric-Architecture.doc
[3] Eclipse Plug-In Architecture,
http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html
[4] Adobe – Acrobat Development Center, http://www.adobe.com/devnet/acrobat/plugins.html [5] IBM, DB2 Plug-in Architecture,
http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?
topic=/com.ibm.db2.udb.doc/admin/c0006185.htm
[6] AUTO-ID Internet of Things, http://autoid.mit.edu/cs/
[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,
http://www.dzi.tu-darmstadt.de/fileadmin/content/veranstaltungen/20060606-09_etrics/braun_sikora.pdf
[9] Unix Host and Network Security Tools, http://csrc.nist.gov/tools/tools.htm
[10] TCP Wrappers for Security, http://linux.omnipotent.net/article.php?article_id=6962
[11] Wietse’s collection of tools and papers, ftp://ftp.porcupine.org/pub/security/index.html [12] Top 100 Network Security Tools, http://sectools.org/
[13] VPN Technologies: Definitions and Requirements,
http://www.vpnc.org/vpn-technologies.html