I have recently, just out of pure curiosity, picked up a Phidgets RFID Kit which consisits of an RFID scanner, a set of RFID tags (key chain, card, coins) and a disc with some software on it. After booting up their various sample code and seeing the thing in action (it works great by the way and has a nice java api) i couldn’t help but come up with a little project for myself (at the time i was watching spooks on tv and looking forward to the new James Bond film, so was thinking about cool spy gadgets). How great would it be if you could send someone a file that was encrypted, but they needed a physical key to open it?

What follows is my experince with the RFID kit and how I managed to get this up and running!

Overview

The basic idea of this system is that it will show a proof of concept of using RFID’s as a security key in encryption, as such ill just encrypt some text for now. What im aiming to achieve is that I can enter some text into a GUI, choose my encrypt or decrypt option, swipe my card and instantly see my data get encrypted!

To make life easier ill just use some standard DES encryption in java and a pretty simple GUI to tie it all together, obviously we can add some nice touches to the GUI to make it a little bit of a filthy rich client.

The Basics

Now what cool spy program would be complete without a cool spy GUI? Rather than spend all my time on the GUI, which was quite tempting I used a few tricks to speed things up. First I set the window to undecorated (for no real reason) then I used some overlayable components from the Jide Common Library to get a progress icon as things were encrypted and finally 2 radio buttons to choose encrypt or decrypt with only an exit button to press (that should confuse people trying to access your data!). The end result is this:

Encryption

For the encryption I plan to use some simple java cryptography using a DES Cypher and a key that is orignally hard coded, later on we will use the RFID chip as the key.

Generating the key is pretty easy, with a given string you need to get the bytes of the string (most encryption you will find works at a byte level), after that we need to create a key spec based on those bytes and finally get a secret key for our type of cypher with that key spec. It all sounds a bit complicated but in reality is 4 lines of code from string to SecretKey

String encryptionKey = "IAMTHEKEY";

 byte[] keyAsBytes = encryptionKey.getBytes("UTF-8");

 KeySpec keySpec = new DESKeySpec(keyAsBytes);

 SecretKey key = SecretKeyFactory.getInstance("DES").generateSecret(keySpec);

The second stage of encryption, once all the objects are set up, is just a case of converting the data you want to encrypt to bytes and encrypting it, in our example we also encode those bytes as a string so we can use them in the GUI. 3 lines of code later and you will have an encrpyted string.

byte[] bytes = str.getBytes("UTF8");

 byte[] encrypted = ecipher.doFinal(bytes);

 return new BASE64Encoder().encode(encrypted);

Im sure you can figure out how to do the reverse (or just grab the source from the bottom of the page).

RFID Addon

At this point we can encrpyt strings and decypt them, I have plugged all of that into my GUI and the final stage is just to react to RFID events from the phidgets device. At this point you could panic about having to do some low level IO coding, JNI or god knows what to get access to the RFID input, but thankfully Phidgets come with a nice java API.

To set up the reader all we need to do is the following, create an RFID reader and attach a listener for the RFID tag being placed onto the reader at that point we will call our internal encrpyt or decrypt methods based on the current radio button.

rfid = new RFIDPhidget();

rfid.addTagGainListener(new TagGainListener(){

void tagGained(TagGainEvent e){

//here we can start the encryption based on the tags ID

}

});

Summary

Ok before anyone starts having a go saying the RFID value isn’t a long enough key to use etc, this is just for fun!

What this does show is that seemingly complex functionality is very acessible these days. Ok RFID cards can be copied, but what if I also add a password to the system? What if I scan the area for bluetooth devices and check my phone is about?

Its a pretty fun little project and if I get some time ill hook into my laptops bluetooth to improve the key and maybe stop encrypting strings but actually encrypt files instead! Heres some pics of it running, and how it was all set up.

Source Code for this project is here and released under my usual terms. Note you wil need to download Jide and get phidgets installed on your platform.

Java exceptions are a powerful tool for making sure that your code completes successfully and that issues are handled tidily by your code. The problem that I often see is that people don’t often design their exception handling policies so that they are dealt with in a uniform manor and that when things do go wrong they don’t translate coding problems into something the user can understand. Here ill go over a solid design principle for exception handling, some good tips on how to code tidily with custom exceptions and how to finally report these to the users.

Exception Design

When planning your exception handling there is one principle to follow above all others
“UI code shows errors and everything else follows the Chain-of-responsibility_pattern to deligate the exceptions”. So what does this mean in real world situations? This means that when designing your code you consider if you are working on logical code or user interface code (I hope your design means that there is a divide between these types of objects) and if your working on logical code then throw the exception back up! This means that all exceptions should end up being dealt with by UI code where they can be displayed to the user very easily. Lets consider an example using the classic Caesar cypher as an example.

Just looking at this (very rough) overview of the classes you can see that the UI is handled seperately to the logic of the encrypting of the data, which has a custom exception incase something goes wrong during encryption. When something goes wrong the logical classes deligate the responsibility of informing the user to the user interface objects that called the encrypt method. This simple change means that the only things that know about user interface details are a subset of all your classes, making proper threading of user interaction, a tidy code base and scaling the application logic much easier.

Tip: Catching Exception is not a good way of dealing with problems, often information is missed from the lower level exceptions. Using this pattern it is possible that you catch all the named exceptions at the UI and as a final case you can catch Exception itself (make sure its the last case so it doesn’t block the other methods) and you can report errors back to base etc to make sure your software is stable.

OK so following this you now know how to plan your exceptions out, making sure that they always land back to the UI to be dealt with, you also know a cool way of making sure you can even catch things you didn’t plan for! Now what do you do with the exception when you have it at the UI?

Reporting to Users

Reporting errors to users is really simple, you just need to remember one rule:

Users are not computer programmers, null pointers mean nothing to them, array index out of bounds is alien talk and they have no idea about IO errors.

You need to talk to users in their language, the language of the software (often called the domain language) so rather than saying null pointer maybe you can tell them that they need to select an item in the table, or they did not fill in a box etc. Help them to understand the problem so they can fix it themselves.

In odd cases you can’t help the user fix the problem, if a database lookup has failed maybe the user can’t do anything. Thats where error codes come in so that no error is ever completely fatal, they can find out more infromation about the problem. My personal favourite way of dealing with such issues is to to give name number pairs so that users can look up the problem and find suggestions, a lot like oracle errors handling system.

You can use an internal system to make sure that no 2 codes are the same, and provide users a simple website to lookup these codes. This means that users are never without some form of help for their problems, it also means if you look at the web stats you can find out what the most serious issues are for your users.

Summary

So there we have it, if you design your error handling properly you can make sure you always get the problems to the UI and when they do get there you have 3 options to handle them by displaying them in domain language, reporting them back to base or providing the user error codes.

If you follow these tips it will no doubt make life a lot easier for you in the long run and result in more stable software and happier users.