Harald Welte's blog


Harald's Web




Other Bloggers
David Burgess
Dieter Spaar
Michael Lauer
Stefan Schmidt
Rusty Russell
David Miller
Martin Pool
Jeremy Kerr
Tim Pritlove (German)
fukami (German)
fefe (German)
Bradley M. Kuhn
Lawrence Lessig
Kalyan Varma


Ohloh profile for laforge
Linked in

Creative Commons License
Articles on this blog/journal are licensed under a Creative Commons Attribution-NoDerivs 2.5 License.



Tue, 17 Aug 2010
Doing RFID related research and development again

More or less a bit surprising to me, I got again involved in RFID research, on which I hadn't really done much ever since my involvement in the OpenPCD and OpenPICC projects some five-to-four years ago.

It's a lot of fun, and I didn't seem to forget much. What really bothers me a bit is that the OpenPCD / librfid / OpenPCD integration never really was completed, and that libnfc doesn't work with OpenPCD. Let's hope I'll somehow find some time to change this. It just feels wrong that OpenPCD was the first hardware project created to encourage (security) research into RFID, and now all the current tools only run on the Proxmark or on proprietary readers...

[ /linux/mrtd | permanent link ]

Tue, 20 Jan 2009
Meeting Taiwanese RFID security researchers

Today I had the pleasure of being invited to have lunch with by Professor Bo-Yin Yang of Academica Sinica, Chen-Mou Cheng from National Taiwan University as well as some research assistants.

It was good to hear that they are working among other things on RFID security, and that they're excited about analyzing actual real-world systems. They also seemed pretty excited about the open source efforts in the GSM world, being a key milestone towards enabling more practical security research in that area

I hope to stay in touch and am looking forward to any publications in those respective subjects.

[ /linux/mrtd | permanent link ]

Wed, 05 Nov 2008
Next generation of OpenPICC in the works

Yesterday at a brief visit to the Chaos Computer Club Berlin, Henryk introduced me to the prototype to the next-generation OpenPICC. After co-initiating the project with Milosch and Brita some years ago, I unfortunately had to drop out of it due to time constraints. I've heard rumours about plans for a next generation OpenPICC, but now it seems like Milosch actually found some time to get it done.

The result is really the über-OpenPICC. No shortage of anything. I don't want to reveal any information that's not out in the public already. Nonetheless, I can say: Stay tuned, stay excited. It rocks!

[ /linux/mrtd | permanent link ]

Thu, 09 Oct 2008
All details about mifare crypto1 algorithm and protocol disclosed

Henryk Ploetz has released his thesis on mifare protocol and cryptographic weaknesses, which is to the best of my knowledge the most complete publicly available documentation about the mifare CRYPTO1 system.

Congratulation to him and his peers (starbug, Karsten Nohl and others) on this great work. I still hope I could have played a more active role in the security research on mifare. But it's good to see that as imperfect as they are, OpenPCD and OpenPICC fulfill their duty as toolkit to enable security research on RFID.

[ /linux/mrtd | permanent link ]

Fri, 18 Jul 2008
Judge determines NXP has no right to prevent researchers from publicizing about MIFARE insecurity

As reported here and here, NXP has apparently not been able to convince a Judge that the researchers at the University of Nijmegen should be restrained from publicizing about weaknesses in their MIFARE RFID products.

This is really good news. And it came so quick! Sometimes, I can still believe that there is some good left in this world. Almost too good to be true.

[ /linux/mrtd | permanent link ]

Sat, 12 Jul 2008
NXP sues security researchers studying Mifare classic

In the last couple of days multiple reports stated that NXP has filed a lawsuit against security researchers from a Dutch university who were looking at security flaws of their proprietary MIFARE Classic products.

This is so ridiculous. I'm surprised that this still happens! We live in the 21st century, and IT security has become a well-established field within computer science. Furthermore, systems based on security by obscurity should be long gone.

So we have a company that in 1994 first ships a allegedly secure RFID technology. They developed a proprietary algorithm that did not receive public peer review in the cryptographic community, and used weak random number generation as well as made some mistakes in the protocol/system design. They ship this even back then questionable product without any fix/update for 14 years, irrespective the advances in technology and cryptographic research. During all that time, NXP marketing material claimed the product was fit for 'high security applications'.

Any reasonably skilled person in IT security could determine that the public statements "proprietary cipher" and "48 bit key length" did certainly not sound like high security at all. Thus, it's not surprising that in the last two years, some people, mostly friends of mine, started to look closer at what MIFARE classic is and what it does.

They should be honored and rewarded for their public service in demonstrating the irresponsible behavior of mostly NXP's customers (system integrators) and NXP itself. And exactly those companies are the ones that should be sued for continuing to milk a known-insecure cash cow for more than a decade.

I'd be more than happy to see somebody actually standing on their feet and demanding damages from those vendors. Imagine a small system integrator for a vertical market who wants to look for a secure/safe electronic wallet system and believes in the vendor promises. Now he gets defrauded because some criminal energy - not the ethical researchers at universities - exploit some weakness.

The only reason why large technology companies rarely get sued over the massive security problems they cause in their proprietary products is the fact that almost nobody (even the system integrators and developers) really understand that very technology enough. I sincerely hope that this changes at some point, and we see all those lame promises about alleged (but completely unverified) security go away.

If people would just use publicly disclosed, well-known, well-studied and well-analyzed cryptographic algorithms and implementations thereof, this world would be a much more secure place.

[ /linux/mrtd | permanent link ]

Sun, 03 Feb 2008
Working on ISO15693 support for librfid

It's really been bugging me for a long time that librfid was lacking support for the ISO15693 protocol. The supported reader hardware ASIC can do it, but librfid always was lacking the respective code. It has been on my agenda even three years ago, but there were always higher priority items to pre-empt it.

In December 2007, Bjoern Riemer submitted a long patch to add partial ISO15693 support to librfid. The size of the patch reflected the huge amount of work that must have went in that code. So I couldn't really afford to let all that work bit-rot. I went through several iterations of code cleanup, starting with cosmetic issues, and digging deeper and deeper. I think it now doesn't really look all that similar to what Bjoern originally did, but at least now we have a working and fairly well-organized ISO15693 anti-collision implementation in librfid.

However, ISO15693 has many different options with regard to speed, modulation, coding, etc. All those combinations have to be carefully tested. What's also missing is a way how to iteratively cycle through all available ISO15693 tags within range, similar to what we do with ISO14443A and B.

Once that work has been finished, the actual higher-level standard commands, as well as the nxp I*Code2 and TI Tag-it vendor-specific extensions can be implemented on top. This can probably be done on one or two more days of additional work. Stay tuned...

[ /linux/mrtd | permanent link ]

Sun, 30 Dec 2007
proprietary MiFARE [in]security finally falling

At a presentation entitled "Mifare - Little security, despite obscurity" at the 24C3, Henryk Ploetz and Karsten Nohl presented about their revelations of the proprietary Philips MiFARE classic RFID system.

As everyone in the IT industry suspected, the level of security provided by such a cheap, low-gate and completely undisclosed system is in fact very limited.

I'm particularly proud that this security research is exactly what Milosch and me originally wanted to enable by creating the OpenPCD and OpenPICC project. We wanted to put easier accessible and open, documented tools for low-level access to 13.56MHz RFID systems.

With a bit of luck, at some point in 2008, it should once again become clear that security by obscurity doesn't work. This lesson seems to be well-understood in the Internet world, but apparently has little penetration into the RFID sphere so far. There are still many proprietary systems whose security relies solely on the secrecy. Once a single person reveals that secret, the system is broken.

I can only hardly imagine the amount of economic damage imposed by the perpetrators of such systems. There are a couple of hundred million MiFARE classic tags on this planet, particularly in public transport ticketing and access control. The vendors of such systems should be blamed for their false claims. And anyone who bought it should be blamed for their blind belief in the claims of profit-oriented corporations without any independent validation or verification.

[ /linux/mrtd | permanent link ]

Mon, 18 Dec 2006
OpenPICC RFID transponder emulator progress

As I've indicated before, the OpenPCD team is working on a free 13.56MHz RFID emulator, mainly for ISO 14443 A+B, but also ISO 15693. This project has been dragged on for quite a lot of time, both because of its complexity, and of my unavailability due to my involvement in OpenMoko and other projects.

Anyway, our latest generation of prototypes has now arrived, and we're proceeding nicely (but slowly) again. With some luck, the ISO 14443A anti-collision could work at the end of this day :)

[ /linux/mrtd | permanent link ]

Sun, 17 Dec 2006
RFIDiot - a python-based RFID tool

By accident, I've discovered RFIDiot, a RFID exploration library and tool written in python. There is quite a bit of overlap with what librfid tries to achieve, from a functional point of view (written in C, of course).

So on the one hand, there's a lot of functional overlap on the high-level like mifare reading/writing, ePassport reading, ... - but on the other hand, all the lower levels seem to be missing in RFIDiot. I guess that's the price you have to pay for vendor-lock-in with a proprietary serial protocol like the ACG readers.

Once I find some time again (next year, feb/march), I'd definitely like to see whether there can be some kind of integration/cooperation between RFIDiot and librfid/libmrtd.

[ /linux/mrtd | permanent link ]

Tue, 28 Nov 2006
Hacking librfid mifare support in Indian sleeper train

I'm currently on a train ride from Bangalore to Sangli(Miraj Jn), which is a 15 hour ride. Since there's quite a bit of noise from other passengers, and the bed (berth?) is not all that comfortable, I didn't get more than some five hours of sleep.

For librfid users this is good news, since I managed to get quite a bit of work done. First of all, mifare classic authentication is now way more reliable than it was before. With regard to the CL RC632, apparently you have to first issue the LOAD_KEY command before filling the FIFO with the key, rather than the other way around.

Also, mifare classic data block (16 byte) writes are now fixed, so you can finally actually read and write data blocks. Next I've implemented parsing (and compiling) functions for the obnoxious mifare permission bit encoding.

Last, but not least, the auto-detection has been enhanced and it an now correctly distinguish between mifare classic and mifare ultralight.

[ /linux/mrtd | permanent link ]

Sun, 10 Sep 2006
OpenPCD - A 100% Free 13.56MHz RFID reader design

Finally, after a lot of delays, I am happy to announce - not yet the public release of the schematics, PCB layouts, and firmware source code - but at least a homeapge and photograph of OpenPCD, the completely free 13.56MHz RFID reader design. You can use it to talk to ISO 14443 A+B, ISO 15693 and related 13.56MHz transponders. We're still busy cleaning up the code and fixing the bugs in the schematics, but expect them to be released within this week.

This reader design is particularly interesting in everyone interested in RFID protocols and security, because of its many interfaces. You can modulate arbitrary waveforms onto the 13.56MHz carrier by bypassing the RC632 modulator/encoder and using the PWM (Pulse Width Modulation) or SSC (Synchronous Serial Controller) of the AT91SAM7 micro-controller. On the RX side, you can also bypass the RC632 decoder and use the SSC to sample arbitrary data, provided it is on a ISO-ocnformant sub-carrier frequency.

Many of the internal signals can be routed to U.FL connectors on the PCB, e.g. if you want to look at certain intermediate signals on an oscilloscope, spectrum analyzer or even sample it with some high-speed ADC like the USRP SDR.

So far we have only produced some five readers of this latest design. But for those of you not interested in re-building it from scratch, we will obviously be offering the ready-built reader in a web store soon.

Meanwhile, the openpcd.org team is constantly working on producing the counterpart, a 100% Free and Open RFID transponder simulator for 13.56MHz. Progress is steady [but slow]. Expect some more exciting news soon ;)

[ /linux/mrtd | permanent link ]

Thu, 03 Aug 2006
OpenPCD - A free 13.56MHz RFID reader design

Over the last weeks I've been working together with Milosch and Brita from bitmanufaktur.de on OpenPCD, a Free Software and Free Hardware design of an RFID reader for popular 13.56MHz based protocols such as ISO 14443 and ISO 15693.

The hardware design will be released under a CC attribution share-alike license, the reader firmware and drivers (librfid glue code, plus some extras) will be released under GNU GPL.

We now have our first fully functional prototype, happily reading ePassport samples and the like.

In addition to being free (and being able to controlling the bare hardware because of the firmware source code) this reader gives an unique opportunity to study RFID signalling, since various analogue and digital test signals are available on headers or (currently BNC, later U.FL) receptacles.

Also, this device can be used to generate arbitrary modulation patterns, with full user control on frequency, modulation width, depth, etc.

We're currently too busy to release the code and docs in an appropriate way, but my hope is that you'll be able to check out a first release within the next two weeks.

The next goal is a similarly 100% free RFID PICC (transponder side) simulator. We're already working on this for some time, but I don't want to blow too much of the good news weeks before you will be able to actually check out the code and hw design. Stay tuned..

Oh, and not to cause misunderstandings: Some time ago I was mentioning that I'd be working on an incredibly cool Linux project in China. This RFID stuff is _not_ what I was talking about, even though I still think it is extremely cool ;)

[ /linux/mrtd | permanent link ]

Fri, 23 Jun 2006
Last librfid ISO 14443-4 chaining bug eliminated

Ok, I finally found the [hopefully] last bug of librfid's ISO 14443-4 PCD side tx side chaining bug. It only occurred in combination with WTX reception.

I also tested CID (card-id) support for multi-activation. If anyone has ever seen a 14443-4 PICC that actually offers NAD (node address) support, please do let me know (samples even more welcome).

To my surprise I discovered, that higher baudrates are actually already negotiated between PCD (reader) and PICC (transponder). Thought there was some practical problem, but it actually worked all the time.

[ /linux/mrtd | permanent link ]

Wed, 21 Jun 2006
librfid tx chaining fixed

After a couple of hours restructuring the ISO 14443-4 (T=CL) transceive code of librfid, we now have working TX chaining support. Quite embarrassing that this fundamental mode of operation was broken for so long. Seems like people have been mostly running read-intensive applications, where no larger chunks of data are sent to the PICC.

[ /linux/mrtd | permanent link ]

Sat, 27 May 2006
Some more librfid hacking

Today I fixed a number of long-standing bugs in librfid, resulting mainly from the conversion to autoconf/automake. Now, finally, users can actually use the native CCID driver again, rather than using OpenCT.

Also updated the README, added a udev rules file and started to make the librfid-tool program (formerly OpenCT-escape) a bit more flexible and user-accessible. It's my sincere hope that some other users (i.e. from the CCC) will write the missing user interface stuff and fix some remaining bugs...

[ /linux/mrtd | permanent link ]

Tue, 08 Nov 2005
14443A with higher baudrates support

I've managed to add support for 212, 424 and 848 kBps 14443A support. 214 and 424 seem to be running quite stable, 848 is not very stable. I'm not sure whether there's something wrong with my configuration, or whether this combination of reader and smartcard just are instable at 848k.

Fixed some data corruption bugs in libmrtd as well, and made both librfid and libmrtd use autoconf. There's still lots of cleanup work to be done, but basically one could now start to write a GUI application on top.

[ /linux/mrtd | permanent link ]

Mon, 07 Nov 2005
MiFARE Classic Authentication works

While working on librfid support for the Pegoda Reader (which is basically 50% done now), I've discovered what my problem with librfid's MiFARE classic support was: I was using the wrong keys. Apparently Transponders issued by Philips have { 0xa0, 0xa1, 0xa2, 0xa3, 0xa4, 0xa5 } as their default key, whereas Transponders from Infineon have { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff }.

I seem to have Infineon samples, and I always tried with the Philips key. After fixing this, reading sectors off a MiFARE classic card seems to be working.

[ /linux/mrtd | permanent link ]

Fri, 04 Nov 2005
Philips Pegoda Reader has arrived.

In order to make librfid cover more readers than it currently does, I've obtained a Philips Pegoda (aka MF EV700) reader.

It's based on the CL RC500, one of the predecessors of the CL RC632 (which librfid supports natively). However, the low level protocol processing is implemented on a Infineon C161U (C166 core with USB interface), so the interface towards the reader will be on a very different level than for the Omnikey one.

[ /linux/mrtd | permanent link ]

Wed, 02 Nov 2005
Basic Access Control working!

After some massive hacking session yesterday, BAC is now working. I can now establish an authenticated and encrypted session to my passport samples, and read data off them.

Still remaining on the TODO list is: Passive Authentication, Active Authentication and a nice GUI frontend.

I have lots of netfilter and OpenEZX work pending, so it's unlikely that I'll continue with libmrtd during the next couple of days.

[ /linux/mrtd | permanent link ]

Tue, 01 Nov 2005
Basic Access Control

It seems like even though the specification looks quite verbose upon first sight, there are many tiny pitfalls in implementing basic access control according to the TR-PKI 1.1 specification.

Padding is such an issue. You always pad for DES en/decryption, _but not_ if you are in the mutual authenticate command ;)

I now have the key derivation, authentication and setup of session keys working. Secure Messaging still has some problems with regard to the DES retail MAC. Let's hope I get this finished soon.

[ /linux/mrtd | permanent link ]

Sat, 29 Oct 2005
librfid gets native CCID support

To my surprise, Werner Koch (author of gnupg) has jumped into the 'librfid' project by contributing his USB CCID low-end driver to it. Using this driver, it should be possible to use librfid directly on the reader, instead of going via OpenCT. There's nothing wrong with OpenCT, as it is the only way to support contact-based and contactless operation at the same time. However, for development and testing, most people don't really need that feature.

Unfortunately it only works theoretically, must be some minor difference in device initialization that causes breakage.

[ /linux/mrtd | permanent link ]

Adding S/M support to libmrtd

If you've now thought about something sexual, I have to disappoint you. At least this time I'm talking about ISO/IEC 7816-4 SM (secure messaging) ;) For those not familiar with cryptographic smart cards: SM is similar to what SSL/TLS do for TCP.

The code for re-formatting the 7816-4 APDU's into further levels of ASN.1, including padding rules, encrypting, authentication, ... has become quite complex. It's also not finished yet, and I already fear testing/debugging of that beast.

[ /linux/mrtd | permanent link ]

Fri, 28 Oct 2005
ISO 19794-5 parser completed

The next milestone of the libmrtd project, a ISO/IEC 19794-5 parser. ISO/IEC 19794-5 is titled "Biometric Data Interchange Formats - Part 5: Face Image Data" and provides an international standard for facial images and related information (such as angle of the face, MPEG4 feature animation point, encoded information about medical glasses, eye patches, etc.).

Using this parser it is possible to extract all the image metadata plus the JPEG image itself from DataGroup2 of an ePassport. I've tested it with two passport samples from different vendors, and it works fine.

The next milestone are cryptographic routines for checking the document signature (Passive Authentication) and Active Authentication. Also, Basic Access Control needs a lot of testing.

[ /linux/mrtd | permanent link ]

Mon, 24 Oct 2005
Public launch of the OpenMRTD.org project

Readers of this blog will already know it since quite some time: I've been working on a RFID stack, a library for accessing electronic (biometric) passports, as well as a matching frontend application.

anyway, since librfid now has stable support for ISO14443A and B (both used for ePassports), and libmrtd now successfully parses EF.COM, EF.DG1 and EF.DG2, I think it was about time to do a public announcement and a homepage for OpenMRTD.org.

[ /linux/mrtd | permanent link ]

Sat, 22 Oct 2005
librfid now deals with Mifare Classic

After having finished Mifare ultralight support (and being able to read out a champions league ticket from last year), I've now implemented Mifare Classic support (i.e. Mifare 1k/4k) for librfid. Authentication and reading seems to work, I haven't looked into write/inc/dec support yet.

It seems like librfid is doing quite fine at the moment, I'll continue working on the ePassport related libmrtd tomorrow. So I hope there will be another interesting announcement tomorrow ;)

[ /linux/mrtd | permanent link ]

Wed, 19 Oct 2005
Adding Mifare Ultralight support to librfid

Since (as opposed to MiFARE Classic) the Philips proprietary MiFARE Ultralight RFID Transponder is actually documented quite well, I've added support for it to librfid. In theory it should work (I've implemented it just like the data sheet says), but unfortunately the transponder doesn't reply to READ/WRITE commands yet :(

The reason for implementing MiFARE ultralight is mainly to have a closer look at the Champions League Tickets from last year, since they are the "beta test" for the Soccer World Championship here in Germany next year.

[ /linux/mrtd | permanent link ]

Sat, 11 Jun 2005
librfid news

After yet another break I'm now back at some librfid hacking. I've compiled the code from svn on my ppc notebook, and it worked straight ahead (as far as it is implemented). Quite surprising, since I didn't even think once about endianness so far. I suppose this will change when implementing the upper layers.

I've now also started work on libmrtd, which is to be a library implementing the functions typically required at a "border control application" of an ICAO-compliant MRTD (passport). This includes basic access control, encrypted communication with the MRTD, and parsing of the data (DG1, DG2) stored on the MRTD.

[ /linux/mrtd | permanent link ]

Wed, 01 Jun 2005
SVN repository url has changed

I've now given the RFID stack project a new name "librfid". Therefore it now has moved to svn.gnumonks.org/trunk/librfid.

Not much progress over the last couple of days, had other work to do... but I've now a not-yet-committed T=CL transceive function including support for chaining and ack/nack retransmissions.

[ /linux/mrtd | permanent link ]

Sun, 29 May 2005
The difficult task of designing simple and efficient hardware

Imagine you have a RFID reader ASIC that can deliver interrupts at certain events (like transmit timeouts, FIFO watermarks, ...) like the CL RC632. Imagine, you have a USB-attached micro-controller with an IRQ input, like the 89C5122. Now why in god's name would you _NOT_ connect the IRQ output pin of one chip with the IRQ input pin of the other?

That would be too good for this world. The device would be able to signal the interrupt on an USB interrupt endpoint, just like we all know and love.

But there goes the hardware vendor (Omnikey in this case). He doesn't connect those two pins (though there is plenty of space on the PCB, and therefore the driver has to poll the ASIC's status registers all the time. *sigh*.

If the RFID stack (now called librfid) is finished and I still get upset enough about this broken hardware design, I'll connect the two pins myself and use FLIP to flash a different firmware image into the 89C5122.

[ /linux/mrtd | permanent link ]

Sat, 28 May 2005
My RFID stack now reads the ATS via T=CL

Lots of T=CL features such as chaining are still missing, but the code evolves constantly, as is the API (which now starts to become easy and nice). I'm constantly committing to svn.gnumonks.org, for those of you who can't wait.

I'm now also in (temporary) possession of two other readers, as well as a 14443 B-type passport sample (in addition to my 14443 A) sample.

Meanwhile I've also confirmed that the Omnikey 5121 windows reader driver has the same (or a similar) bug as the Linux driver, too. It also refuses to work with any MTCOS based card. I hope the MTCOS sample card I sent them will help them debugging - even though I don't need their proprietary drivers anymore at this point.

[ /linux/mrtd | permanent link ]

Tue, 24 May 2005
CardMan 5121 / RC632 driver and 14443-3 layer working

GREAT NEWS! The generic RC632 driver and the CM5121 backend is working, as is the ISO 14443-3 Type A (anti-collision)layer. This means that I'm actually talking to cards, etc.

The next big step is to code the 14443-4 (also known as T=CL) protocol, which is the last element in the chain to use industry standard ISO 7816-4 commands to talk to the chip.

I've also been thinking of what might be an appropriate interface for applications to interface the stack. It's probably because I'm having so much of a kernel-level networking background... but where is that whole RFID stack different from a network? You have packets being sent back and forth, you have anti-collision, you have multiple devices sharing a single 'ether', ...

The whole "7816-4 on top of 14443-4 on top of 14443-3 on top of 14443-2" issue also resembles the OSI model quite a lot, so this could actually map onto the different SOL (socket layers) in the stack.

And after all, why would a socket API like interface be so bad?

Of course this all comes with a severe disadvantage: who wants to have all this stuff in the kernel, if it also works from userspace? Well, the same was true for the first TCP implementations when they were in userspace...

[ /linux/mrtd | permanent link ]

Mon, 23 May 2005
Preliminary RC632 / CardMan 5121 code released

For those who are curious: I've made my current state of development on a Philips CL RC632 driver4 available from svn.gnumonks.org.

[ /linux/mrtd | permanent link ]

Sat, 21 May 2005
Rewriting CardMan 5121 RFID driver software

I've been spending quite some time lately to re-implement the host-side driver for the Omnikey CardMan 5121 RFID part.

The 5121 is an Atmel AT89C5122 based USB CCID reader, extended by a Philips CL RC632 RFID reader ASIC. The RC632 is a quite common reader ASIC found in many ISO 14443 A/B and ISO 15693 readers of today.

Since the RC632 is common, I'm actually writing a generic RC632 driver. Below the driver there is a "transport layer" that is specific to the CardMan 5121. It's my hope that over time it will be possible to support other readers by adding device-specific transport layers. Above the RC632 driver, there are implementations of the ISO14443 A and B anti-collision algorithms, as well as some code specific to the I*CODE and Mifare proprietary transponders.

So far I think I've written about 60% of what's required to access my MaskTech MTCOS 1.1 (14443A) card.

One of my major obstacles was not related to the RFID stuff at all. I've never learned as much about ELF PIC (position independent code) in its x86 incarnation. For some reason IDA Pro's code analyzer doesn't fully recognize the PIC format of the proprietary driver. It always works for any other .so file I open, but not for ifdokrfid.so from Omnikey. Maybe they're using some strange compiler (or compiler options)...

I'm confident that within the next couple of days I'll have the system running.

As an interesting side note, the RC632 seems to be able to just passively receive, too. I didn't have a chance to confirm this yet, but looking at the docs I have, it should be possible to demodulate/decode without actually sending the main carrier or any commands to the PICC / tag. I always thought that vendors would build their chipsets in a way that no easy eavesdropping was possible. Well, we'll see.

[ /linux/mrtd | permanent link ]

Thu, 12 May 2005
Problems with RFID sniffing due to bad driver?

I've now started to write some code for the ICAO MRTD LDS and PKI. If you know what that is, stop reading here. If you don't know: It's the crypto and data structures that are going to be present on the new "RFID passports" that will be issued in Germany (and elsewhere) soon.

Nothing seemed to work. Then it turned out to be a driver issue with the Omnikey 5121 proprietary Linux driver. Did I tell you that I hate proprietary software, especially drivers? Well, I'm on my way to re-implement that driver (actually, a generic Philips RC632 driver), too. But I better wait until it works before I start to re-implement the broken one...

So getting back to our RFID sniffing tests, I think the card was probably not even transmitting as expected. All the responses we got from the driver were bogus. This obviously results in no sub-carrier being broadcasted, and would explain why it was impossible for us to catch it in the spectrum analysis.

[ /linux/mrtd | permanent link ]