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 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 – 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 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 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 Architecture/Wrapper comparison Tasks (as executed) Understand/gain background to the architectures of Ubiquity and TagCentric and other architectures which designs can be compared and contrasted Design of possible problems and fixes to current architecture design Demonstrate and show the problems and fixes to the current architecture Document architectures and problems Schedule (as executed) Semester Year Understanding … Design … Demonstrate 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 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, http://www.csce.uark.edu/~cwt/COURSES/2007-01 CSCE-490-590 RFIDAgent-Middleware/DOCS/2006-08 Ubiquity-Architecture.doc [2] TagCentric, http://www.csce.uark.edu/~cwt/COURSES/2007-01 CSCE-490-590 RFIDAgent-Middleware/DOCS/2006-08 TagCentric-Architecture.doc [3] Eclipse Plug-In Architecture, http://www.eclipse.org/articles/Article-Plug-inarchitecture/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.tudarmstadt.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/vpntechnologies.html