RFID Guardian Software:Library:Core modules:SSL

From RFID Guardian

RFID Guardian Software / Library / Core modules / SSL

SSL

We incorporated a checkout of OpenSSL into the RFID Guardian software, even though one may question this choice: OpenSSL is a very large library, due to its flexibility, the large number of supported ciphers, and the possibly heavy load on the RFID Guardian's processor. On the other hand, this very flexibility allows to use SSL over RFID communication channels with relatively little effort, and one can configure it to use only mean-and-lean ciphers. It can be massaged into compiling for eCos with relatively few code changes. The RFID Guardian checkout comes with a few patches and a configuration script to compile OpenSSL for eCos.

OpenSSL has a BIO type that abstracts from communication channels. All cryptographic activity goes on in the OpenSSL library on top of BIOs. OpenSSL allows to incorporate custom BIO implementations for networks that are not natively supported by OpenSSL (unlike e.g. sockets). The way to run SSL over RFID is by creating an RFID BIO.

RFID communication is essentially asymmetrical. The reader poses the request, the tag sends the response. The messages for requests and responses are of different types, see the section on RFID frames . The handling of incoming frames is very different: a reader knows when to expect a response to a request so it can just poll its port, but a tag will use the filter mechanism to receive upcalls for incoming frames. Therefore, separate RFID BIOs are needed for the reader side and for the tag side.

15693 SSL BIO

The 15693 BIO uses WRITE_MULTIPLE_BLOCK and READ_MULTIPLE_BLOCK frames to send or receive packets. It implements message fragmentation and a stop/go retransmit mechanism for lost packets. Since RFID communication is reader-driven, writes by the tag are implemented by a READ_MULTIPLE_BLOCK exchange from the reader.

The 15693 reader BIO sends requests directly to the RFID port , and then polls the port for the response.

Since communication is initiated by the reader that therefore controls the timing of the conversation, any tag-side activity must use message buffers, either to receive packets from the reader, or to have data ready when a packet is requested by the reader.

The 15693 tag BIO registers a callback with its port 's filter at the pre stage that services both reads and writes. In all cases, the BIO callback has its filter send a response: an acknowledgement for a WRITE_MULTIPLE_BLOCK request, and a response packet for a READ_MULTIPLE_BLOCK request.

When an application thread calls via SSL into the tag BIO to send a message, it registers its data and waits on a condition variable until a BIO filter callback comes by and reads the data away, a packetload at a time. When the message has been sent out completely, the thread returns. If the BIO filter callback finds no pending data, it returns an error message.

When an application thread calls via SSL into the tag BIO to receive a message, it registers a pointer to its data buffer, and waits on a condition variable. That variable is signalled by the BIO filter callback when it has data to deliver. The thread waits until the BIO filter callback has completely filled the message (read-fully semantics).

14443-A SSL BIO

To be implemented As of the time of writing, this BIO must still be implemented. It will use 14443-A T=CL data blocks for packets. Much of the mechanism (fragmentation, timeouts, buffering, synchronization) will be identical to the 15693 SSL BIO.

To be implemented It is conceivable that a lot of the 15693 BIO implementation can be generalized, with much smaller specialization routines for 15693 and 14443-A.

API	include/ssl/mrg_ssl.h , include/ssl/mrg_frame_bio.h
Source	[ src/ssl/common/ ], [ src/ssl/rfid-frame-bio/common/ ], [ src/ssl/rfid-frame-bio/15693/ ]