01. February 2013 · 6 comments · Categories: Uncategorized

 

It has been a far from quiet week in library RFID land…

One issue has been exercising librarians on both sides of the pond this week – security.

There were two aspects to these concerns – the inconvenience of false alarms and the possible threat of NFC. I thought it might be useful to summarise the debates for those not currently subscribed to the free and open JISC sponsored listserv.

The false alarms were first raised by Martin Elcock, Clinical Librarian at Walsall Healthcare who had noticed,

“… that items from other libraries (NHS Trust and university libraries) which are using a different supplier appear to be triggering the gate, despite assurances that security has been “turned off” using the staff pad. “

Robin Major from Birmingham City University was the first to offer some suggestions,

“As I understand it there are a number of ways that security can be managed by a Library RFID system. One way is to use an AFI (Application Family Identifier) value to indicate whether an item is on loan or not. AFI is widely used, not just in Libraries, and there are specific values that can be assigned to indicate that an item is, for example a piece of luggage at an airport, as opposed to a coat from M&S.

There’s an AFI value specifically for Library use for an item out on loan (hexadecimal C2); and it’s this value that your system should assign when it issues an item. There is also a more general value for items in stock (hexadecimal 07); again your system needs to be using this when  items are returned.

Another type of security mechanism used by Library RFID suppliers is something called EAS (Electronic article surveillance); perhaps someone else on the list will be able to comment on how this works.

I guess for starters you need to find out how each of your systems is handling security (AFI, EAS, something else). If AFI is used by all of your systems then find out what values are being assigned to issued & in stock items and check that there isn’t a conflict.”

while John Usher from Islington Public pointed out that,

 “There are also transitional issues between tagging and putting in the kiosks and antennae – security will be on and stock will be circulating and triggering alarms in other libraries, and in the home site for weeks (months) after go-live, and until all sites are on kiosks (if they ever will be…)

Not all our libraries are scheduled to have kiosks (all will have staff pads) – but most stock is now coming with pre-programmed tags from suppliers, with  EAS and AFI on, to the suppliers standard.

And we have some small libraries with Kiosks but no antennae – either standalone, or (usually) a separate children’s library in the same building where antennae are deemed not to be necessary/cost effective  for security purposes.

Now – if kiosks (etc) are working fine, then security should be being switched properly.

But if items are being manually handled on a counter, then the security needs to be reset manually – there being no way to switch RFID security in an LMS client via the ‘staff pad’, and no desire on my part (let alone for SIP2 costs) to use an RFID supplier client on the counter. That one seems to be bouncing between all UK RFID and LMS suppliers (I have no favourites – I take no prisoners…) and no-one wants to take ownership.”

There were many more comments (you can read them all here) that discussed the problems of dealing with items manually vs using self-service and the temporary but often irritating false alarms that happen during the initial implementation (when only some stock and some devices may be active) but the message that emerged most strongly from the debate was that not many people actually know how their security is being managed.

I had mentioned that AFI (Application Family Indicator) was the preferred method – and that used by the international data standard ISO 28560 – but even I was surprised to learn that even the major suppliers are still using EAS (Electronic Article Surveillance) instead of or in addition to AFI. The best advice came from 3M’s Andy Fish who suggested that,

“Just how to fix this issue is very much dependent on the hardware capabilities you have and perhaps what your long term strategy is for your stock.

As an example most self-service systems can read multiple data models (e.g. barcode data) but will set one AFI value for secure and one for unsecured.
There are many security systems that can detect multiple AFI values for secure, so your solution may be to ensure that the detection systems are set for both values, equally many systems can read AFI and EAS values simultaneously.

In the longer term you may be considering moving to all stock encoded to the ISO standard and as such all AFI values the same, but even during the course of migration care needs to be taken with the security element of your stock.

I think I discussion with all parties involved will help clear up the details and together we should be able to find the solution.”

Part of the difficulty comes from inconsistent use of the AFI codes before the ISO standard set the values in stone, and partly from the complex ways in which many libraries want to manage their stock. Suppliers have been very creative in finding solutions to meet the demands of their clients – but sometimes exposure to the wider world – such as when someone brings an item from another library into yours – can cause unexpected problems. It’s a highly competitive world and woe betide the supplier who dares say ‘no’ to a librarian that wants a solution unique to his library…

For the sake of clarity ISO 28560-1 (which governs the use of elements in both 28560-2 and 28560-3) mandates specific hexadecimal values for setting the AFI values. It also has five pages of suggestions (in an addendum) for coping with different scenarios. The best way to begin a discussion with your suppliers (and your neighbouring library authorities) is probably by reading what it has to say. You can buy a copy of the standard from one of the national standards agencies or the ISO – or of course borrow it from your library.

The other big topic of the week was NFC (Near Field Communication). This debate was, inadvertently, begun by Catriona MacIsaac of Glasgow University who asked on the UK’s Public Library listserv  LIS-PUBLIBS,

“Do any of you use Near Field Communcation (NFC) technology in your libraries for self-issue or for any other purpose? We are investigating it for use here at Glasgow and would appreciate any feedback from people who have experience of using it.”

I saw her message and initially referred her to my report of the 5th Wildau Symposium in 2012 where I had seen Sebastian Krautz give the first demonstration of an NFC enabled android smartphone altering RFID tag data. Sebastian had scanned the tag, decoded the data, worked out which bits represented the security check and altered its status.

Sebastian’s presentation weighed the many advantages and exciting developments that were possible (and being planned) for using smartphones with library stock against the small but significant risk that someone might want to use their smartphone for entirely malicious purposes.

Since then I have heard occasionally from people in the industry (and have raised concerns myself) about the true scale of the problem. So far there are no recorded instances of anyone actually using a smartphone in this way but after receiving another message – posted via the blog – last week I felt it would be irresponsible not to mention that a risk, however small, DOES exist.

The message that made me reach this conclusion included the following,

“…I actually work at a library that uses these tags so this is how I’ve been playing with them. I don’t know a whole lot about NFC or RFID from the programming side. When I first started, I knew that I could read the tags from the books but couldn’t write to them with any of the apps that were commonly used. Earlier this week I found some blank pre-used tags and thought I’d try again and found that I could write to them with my phone so I started playing with that.  I eventually had to use the tags for some books so tried writing to them with my phone and then testing whether the software would pick it up, it didn’t and I wrote the library book information to them. This resulted in not being able to write to them on my phone again. I eventually noticed that the software does something to the NDEF blocks when it writes to the tags, making it unwriteable by the phone. The search was then to find something that could recover or bring back those blocks for writing.

This is what brought me to StartNFC Expert. From the Tag Actions menu you can select Unformat ndef and that action will wipe the tag allowing you to pass through security as it apparently wipes the whole tag, not just the ndef blocks. You can then format the ndef and use it as you’d like.

Nfc-V reader has somewhat the same functionality but for a different purpose. I found this one to be the only app that allows you to write to the SL2 blocks. I haven’t tested it, but I suspect you may be able to write to the SL2 blocks with it. I just hate hex and figuring out what I’d have to modify to test it successfully. Though it would be interesting to see if you could write to the security bits so that you could appear to have a valid book and just checked out, if questioned.

I’ve talked to a few people here about it and they mentioned that it was a known potential (problem) but the overall discussion was that they never thought NFC would’ve been so accessible in such a short amount of time, especially mobile.

One thing I’ve started doing a bit of research on is what information the gates pull when tags go through….If a tag is wiped in this fashion, I wanted to see if the gates were at least able to record the uid of tags that appeared blank either for asset recovery at a later time or for on the spot notification. Though the latter seems unlikely based on the apparent limitations of the gate functionality.

One thing I’m unfortunately unable to confirm is whether the act of unformatting the ndef blocks could be prevented by locking or write protecting the tags. None of the software we have has been configured or appear to allow for this. Again, I’m by no means an expert on this sort of thing (I started reading about it Monday) but it would appear that it may not be preventable. Hopefully the proposed solution in my last paragraph would be feasible.”

Another message (as I now know from Canada) arrived a little later,

“Further investigation reveals, from using NFC Taginfo to save scans of checked-in and checked-out tags, as well as information online that the security bit is located in the AFI value (“da” is locked, “d7″ is unlocked”). Tooling around with Nfc-V Reader I wasn’t able to write to those values and I’m not sure if there’s an application out there yet that could. I did confirm that Nfc-V could be used to properly write to the SL2 blocks so an app could be written to “clone” other tags.

I should mention that I’m using a Samsung Galaxy S3 with Jelly Bean. I know that there were issues formatting the NDEF with Galaxy Nexus devices with ICS prior to 4.03, which is the thread that got me looking for NDEF formatting utilities.”

My first thought was, “thank goodness this guy works in a library”. My second “That’s some progress for someone who only started thinking about this a week earlier”.

So we certainly have a problem. How big is difficult to assess – as is the possible solution. Locking down the tags would prevent some functionality from being delivered and put an end to any of the developments that plan to use the dynamic nature of tags to re-write data. Which would be, to say the least, disappointing.

The key phrase for me is “they never thought NFC would’ve been so accessible in such a short amount of time” – none of us did.

Now we do – what are we going to do about it?

6 Comments

  1. Good article,

    Obviously I don’t want to play down your concerns, but I am sort of wondering if being able to write to these tags is going to make much of a difference. I work for an RFID supplier in the library world and I can tell from experience that if people want to steal materials from a library, they will. Actually, formatting or changing the tags is still quite a lot of work when you compare it to other tricks that you often see. Such as: taking out the tag all together, or sticking the book under your armpit while walking through the security gates (your body contains a lot of water, so that often works).

    That being said, there are two things one could do in order to make tag manipulation less of a problem. One of those things is locking parts of the tags. Once the data blocks are locked you can no longer manipulate them. However, many data models do not allow this. We are mostly active in the Dutch-speaking world, and we use a different data model. I can say for sure the Dutch model does not allow this. And it is probably for the better, because some features of the data model (such as ILL) require us to be able to write to certain blocks of the tag at all times. I am not completely sure what ISO 28560 says about locking blocks, I would have to look into it.

    The other thing you could do is make use of tags that allow you to secure your security mechanism. I haven’t seen any tags that can do this with AFI, but I have seen tags that can password protect EAS. However, this has obvious drawbacks. The tags are more expensive and you are limited to certain tag manufacturers. Also, your supplier could lock you in by not giving you the password. But the later could probably be avoided.

    Something else that I personally think is interesting about your article is the short debate of EAS against AFI. I personally prefer to use AFI, but I have to admit that using EAS has certain elegance to it. That way you can leave AFI on the correct setting, and still have a working security mechanism, without having to resort to the “in-stock”-value trick. But as far as I know EAS is not part of the ISO15693 standard, so it might not be so elegant after all.

  2. …and I don’t wan’t to be alarmist either(!) but working on the principle that if something can happen, it will, it seemed worthwhile mentioning that the problem exists. There are, as you suggest, many different ways in which libraries have implemented RFID and not everyone will be vulnerable. If tags don’t use ISO 15693 they can’t be altered by NFC as far as I am aware. So older installations may be safe. However older installations won’t be able to use new services being developed for 15693 compliant tags either!

    What I was trying to encourage was some kind of risk assessment by librarians, and some kind of response from the tag manufacturers and standards agencies (to which I belong myself!).

    It’s interesting that most of the comments I’ve seen in other places – blogs and forums – from RFID suppliers are also focused on theft, Interestingly the few Systems Librarians left are more concerned about other tag data being re-written or wiped – rather than either AFI or EAS. That would make lending problematic and could have a rather adverse effect on the library’s automated management system.

    So far as I know neither the Danish, Dutch or any of the other data models that preceded ISO 28560 support locking – and as you say ILL would suffer if they did. As would other functionality now being developed for 28560 models. The authors of 28560 have written to reassure me that there ARE ways to solve the problem – we just need to agree how. Which will take a little time. In the meantime librarians should be dusting off their disaster recovery plans – just in case…

  3. You make a very valid point on the data-wiping/rewriting. One of my nightmares is that someone would enter one of our customer’s sites with a long range reader and makes a good old mess out of things. I have the equipment lying around to do so. So it’s not unimaginable anyone else could do it…

    Luckily most phones have a reading range that does not exceed more than one or two inches, so my nightmare scenario is not going to happen any time soon. Any phone-based damage would be limited. But you are right, hardware is improving every day, and perhaps this is the perfect time to take a closer look at this issue.

    I am really curious how other manufacturers will solve this. I don’t have any tricks up my sleeve right now, but we’ll see. Thanks for the reaction, I’m going to keep an eye on this blog 🙂

  4. I would love to have confirmation of this statement:

    > If tags don’t use ISO 15693 they can’t be altered by NFC as far as I am aware.

    in order to know that migrating to 28560 would resolve these security concerns. In the meantime, with a little messing around, I was unable to alter the AFI field with any of the half-dozen apps I tried. Can we hope that it is outside the limits of the NFC standards?

  5. Hi Lucien

    I’ve been receiving a steady stream of communications on this topic (as you might imagine!). The general consensus appears to be that if all the right conditions exist then your system may be vulnerable. I’ve had emails from the USA, Canada, Australia, Germany, Holland and even some from the UK 🙂 and from suppliers, technologists, industry experts and geeks. None of them have said that there’s no threat at all and many are working (as I am) with our professional and standards bodies to try and find a solution that can readily be rolled out globally.

    At the same time I have been advised of work being done to develop an app that can scan a tag (if it’s 15693 compliant), read and decode the data (which is generally wide open but sometimes hard to decode) and rewrite or wipe values on tags. I should stress that this is being done by library people, for library people and not for any malicious intent – merely to prove it’s possible (although I have little doubt that it is).

    In the meantime the best advice is to ask your RFID supplier to tell you if they believe you may be vulnerable. They are, after all, the experts in their field and best know what kind of tags you have in your library.

    I know it CAN happen – because I saw it demonstrated with my own eyes last year – but how big a problem this may be isn’t clear – to anyone I’ve been in contact with right now. No need to lock down the library I would think. Whatever else I know I can tell you that an NFC phone has be in direct contact with an item to scan the tag so a large scale attack is unlikely – and would be noticed I think?

    If you want the details of the programs my informant has used I’ll be happy to send them by email, but it’s probably best not to spread the word too far?

  6. Hi – super article
    In the city of Aarhus our Libraries has just implemented RFID instead of barcodes
    We are therefore investigating NFC for reading our chips.

    Our focus was at first to improve our android app “indhold+”, which scans a book, and displays info about the book, shows other books by same writer, theme and so on. The pictures in this site will give you an idea of the project although its in danish:
    http://itklik.wordpress.com/2012/11/21/indhold-scanpunkt/

    The app used a rather expensive retailer-build scanner, so we thought we could use NFC instead. And so our NFC research began.

    We quickly found that making an android app that reads data from a 15693 chip is easy. Its like 20 lines of java code. We are now improving “Indhold+” with NFC support. Our problem is the there a no NFC tablets available in Denmark 🙁 – yet

    Our research also showed that changing the AFI value from 0x07 to 0xC2 and back again is possible. It took our data-engineer about 10 hours to make an app, that can read the chip, and change AFI value, so the tread against the libraries is real.

    An alternative idea is to make a check-out/In kiosk for smaller libraries. It wound decrease costs of kiosks in DK from 6.000€ to 500€. With NFC its possible. The biggest challenge is to a proof of concept is, that the NFC antenna in android devises has too short range and only work on the back of the devise. That gives user interaction problems. Does anyone have a solution to that problem?

    In danish libraries we try to use Open Source and share our code when we can. If any Library people want to see our code, or cooperate in making NFC apps to RFID 15693 chips just write. mvel@aarhus.dk

Have a view? Please share!