The Architecture of RFID Systems

RFID readers are generally connected to the middleware using modular drivers, much like Windows uses device drivers to communicate with a graphics card. This allows different readers to be used with the middleware, without having to modify the middleware.

In addition to event-processing, the middleware handles different kinds of user interfaces. A user interfaces is generally provided for system-management purposes, for example to modify the series of filters through which an events is passed. There will also be user interfaces that allow regular users to access the system and use it. For example, in a supermarket distribution center, there will be a user interface that provides information on the current stock levels.

The middleware also communicates with other software systems, which implement the application's business logic. To stay with the supermarket example, it is likely that the supermarket RFID system is connected to a stock management system, which orders new stock from suppliers before it runs out.

Test-Platform Architecture

To be able to test different kinds of exploits, we created a modular test platform, whose architecture is similar to that of a normal RFID middleware system. This architecture is illustrated in Figure  1.
 

Figure  1 - Back-end architecture

The RFID reader interface connects to a Philips MIFARE/I.Code Pegoda RFID reader, with I.Code SLI HF tags. The tags are accessed using the ISO-15693 API.

The middleware connects to these databases, using the specified APIs:
 

MySQL		MySQL C API
Oracle		OCI 10.2.0
		iSQL*Plus
PostgreSQL		libpq API
SQL Server		SQL Distributed Management Objects

More information on the databases and APIs can be found here.

The management interface uses PHP and connects to the databases using standard APIs that are supplied with PHP.