LaForge's home page (Posts about mrtd)https://laforge.gnumonks.org/blog/tags/mrtd.atom2022-06-21T07:49:57ZHarald WelteNikolaDoing RFID related research and development againhttps://laforge.gnumonks.org/blog/20100817-doing_rfid_again/2010-08-17T03:00:00+02:002010-08-17T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
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...
</p>Meeting Taiwanese RFID security researchershttps://laforge.gnumonks.org/blog/20090120-meeting_taiwanese_rfid_researchers/2009-01-20T03:00:00+01:002009-01-20T03:00:00+01:00Harald Welte<p>
Today I had the pleasure of being invited to have lunch with by <a href="http://www.iis.sinica.edu.tw/pages/byyang/contact_en.html">Professor
Bo-Yin Yang of Academica Sinica</a>, Chen-Mou Cheng from National Taiwan
University as well as some research assistants.
</p>
<p>
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
</p>
<p>
I hope to stay in touch and am looking forward to any publications in those
respective subjects.
</p>Next generation of OpenPICC in the workshttps://laforge.gnumonks.org/blog/20081105-openpicc_nextgen/2008-11-05T03:00:00+01:002008-11-05T03:00:00+01:00Harald Welte<p>
Yesterday at a brief visit to the <a href="http://berlin.ccc.de/">Chaos Computer Club Berlin</a>, Henryk introduced me to the prototype to the next-generation <a href="http://www.openpcd.org/openpicc.0.html">OpenPICC</a>. 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.
</p>
<p>
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!
</p>All details about mifare crypto1 algorithm and protocol disclosedhttps://laforge.gnumonks.org/blog/20081009-mifare-ploetz/2008-10-09T03:00:00+02:002008-10-09T03:00:00+02:00Harald Welte<p>
Henryk Ploetz has released his <a href="http://sar.informatik.hu-berlin.de/research/publications/SAR-PR-2008-21/SAR-PR-2008-21_.pdf">thesis on mifare protocol and cryptographic weaknesses</a>,
which is to the best of my knowledge the most complete publicly available documentation
about the mifare CRYPTO1 system.
</p>
<p>
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, <a href="http://www.openpcd.org/">OpenPCD and OpenPICC</a> fulfill their duty as
toolkit to enable security research on RFID.
</p>Judge determines NXP has no right to prevent researchers from publicizing about MIFARE insecurityhttps://laforge.gnumonks.org/blog/20080718-nxp_has_list/2008-07-18T03:00:00+02:002008-07-18T03:00:00+02:00Harald Welte<p>
As reported <a href="http://webwereld.nl/articles/51953">here</a> and <a href="http://www.nu.nl/news/1663389/50/Universiteit_mag_publiceren_over_gekraakte_ov-chip.html">here</a>, 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.
</p>
<p>
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.
</p>NXP sues security researchers studying Mifare classichttps://laforge.gnumonks.org/blog/20080712-nxp_sues_mifare_researchers/2008-07-12T03:00:00+02:002008-07-12T03:00:00+02:00Harald Welte<p>
In the last couple of days <a href="http://www.secureidnews.com/news/2008/07/10/nxp-sues-to-prevent-hackers-from-releasing-mifare-flaws/">multiple</a> <a href="http://www.thetechherald.com/article.php/200828/1463/NXP-sues-academic-research-team-what-are-they-afraid-of">reports</a> 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.
</p>
<p>
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.
</p>
<p>
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'.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>Working on ISO15693 support for librfidhttps://laforge.gnumonks.org/blog/20080203-iso15693/2008-02-03T03:00:00+01:002008-02-03T03:00:00+01:00Harald Welte<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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...
</p>proprietary MiFARE [in]security finally fallinghttps://laforge.gnumonks.org/blog/20071230-24c3_mifare/2007-12-30T03:00:00+01:002007-12-30T03:00:00+01:00Harald Welte<p>
At <a href="http://events.ccc.de/congress/2007/Fahrplan/events/2378.en.html">a
presentation entitled "Mifare - Little security, despite obscurity"</a> at the
<a href="http://events.ccc.de/congress/2007/">24C3</a>, Henryk Ploetz and Karsten
Nohl presented about their revelations of the proprietary Philips MiFARE classic
RFID system.
</p>
<p>
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.
</p>
<p>
I'm particularly proud that this security research is exactly what Milosch and
me originally wanted to enable by creating the <a href="http://www.openpcd.org/">OpenPCD and OpenPICC</a> project. We wanted to put
easier accessible and open, documented tools for low-level access to 13.56MHz
RFID systems.
</p>
<p>
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.
</p>
<p>
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.
</p>OpenPICC RFID transponder emulator progresshttps://laforge.gnumonks.org/blog/20061218-openpicc/2006-12-18T03:00:00+01:002006-12-18T03:00:00+01:00Harald Welte<p>
As I've indicated before, the <a href="http://openpcd.org/">OpenPCD</a> 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 <a href="http://openmoko.org/">OpenMoko</a> and other projects.
</p>
<p>
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 :)
</p>RFIDiot - a python-based RFID toolhttps://laforge.gnumonks.org/blog/20061217-rfidiot/2006-12-17T03:00:00+01:002006-12-17T03:00:00+01:00Harald Welte<p>
By accident, I've discovered <a href="http://www.rfidiot.org/">RFIDiot</a>, a
RFID exploration library and tool written in python. There is quite a bit of
overlap with what <a href="http://openmrtd.org/projects/librfid/">librfid</a>
tries to achieve, from a functional point of view (written in C, of course).
</p>
<p>
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.
</p>
<p>
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.
</p>Hacking librfid mifare support in Indian sleeper trainhttps://laforge.gnumonks.org/blog/20061128-sleeper_train-mifare/2006-11-28T03:00:00+01:002006-11-28T03:00:00+01:00Harald Welte<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
Last, but not least, the auto-detection has been enhanced and it an now
correctly distinguish between mifare classic and mifare ultralight.
</p>OpenPCD - A 100% Free 13.56MHz RFID reader designhttps://laforge.gnumonks.org/blog/20060910-openpcd-release/2006-09-10T03:00:00+02:002006-09-10T03:00:00+02:00Harald Welte<p>
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 <a href="http://www.openpcd.org/typo3temp/pics/95ae5d80e1.jpg">photograph</a> of
<a href="http://www.openpcd.org/">OpenPCD</a>, 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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
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 ;)
</p>OpenPCD - A free 13.56MHz RFID reader designhttps://laforge.gnumonks.org/blog/20060803-openpcd/2006-08-03T03:00:00+02:002006-08-03T03:00:00+02:00Harald Welte<p>
Over the last weeks I've been working together with Milosch and Brita from <a href="http://bitmanufaktur.de/">bitmanufaktur.de</a> 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.
</p>
<p>
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.
</p><p>
We now have our first fully functional prototype, happily reading ePassport
samples and the like.
</p>
<p>
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.
</p>
<p>
Also, this device can be used to generate arbitrary modulation patterns, with
full user control on frequency, modulation width, depth, etc.
</p>
<p>
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.
</p>
<p>
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..
</p>
<p>
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 ;)
</p>Last librfid ISO 14443-4 chaining bug eliminatedhttps://laforge.gnumonks.org/blog/20060623-tx_chaining/2006-06-23T03:00:00+02:002006-06-23T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
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).
</p>
<p>
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.
</p>librfid tx chaining fixedhttps://laforge.gnumonks.org/blog/20060621-tx_chainint/2006-06-21T03:00:00+02:002006-06-21T03:00:00+02:00Harald Welte<p>
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.
</p>Some more librfid hackinghttps://laforge.gnumonks.org/blog/20060527-librfid/2006-05-27T03:00:00+02:002006-05-27T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
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...
</p>14443A with higher baudrates supporthttps://laforge.gnumonks.org/blog/20051108-higher-baudrates/2005-11-08T03:00:00+01:002005-11-08T03:00:00+01:00Harald Welte<p>
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.
</p>
<p>
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.
</p>MiFARE Classic Authentication workshttps://laforge.gnumonks.org/blog/20051107-mifare_classic/2005-11-07T03:00:00+01:002005-11-07T03:00:00+01:00Harald Welte<p>
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 }.
</p>
<p>
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.
</p>Philips Pegoda Reader has arrived.https://laforge.gnumonks.org/blog/20051104-pegoda/2005-11-04T03:00:00+01:002005-11-04T03:00:00+01:00Harald Welte<p>
In order to make librfid cover more readers than it currently does, I've obtained a Philips Pegoda (aka MF EV700) reader.
</p>
<p>
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.
</p>Basic Access Control working!https://laforge.gnumonks.org/blog/20051102-bac/2005-11-02T03:00:00+01:002005-11-02T03:00:00+01:00Harald Welte<p>
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.
</p>
<p>
Still remaining on the TODO list is: Passive Authentication, Active Authentication and a nice GUI frontend.
</p>
<p>
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.
</p>Basic Access Controlhttps://laforge.gnumonks.org/blog/20051101-bac/2005-11-01T03:00:00+01:002005-11-01T03:00:00+01:00Harald Welte<p>
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.
</p>
<p>
Padding is such an issue. You always pad for DES en/decryption, _but not_ if
you are in the mutual authenticate command ;)
</p>
<p>
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.
</p>Adding S/M support to libmrtdhttps://laforge.gnumonks.org/blog/20051029-libmrtd-sm/2005-10-29T03:00:00+02:002005-10-29T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
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.
</p>librfid gets native CCID supporthttps://laforge.gnumonks.org/blog/20051029-librfid-ccid/2005-10-29T03:00:00+02:002005-10-29T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
Unfortunately it only works theoretically, must be some minor difference in
device initialization that causes breakage.
</p>ISO 19794-5 parser completedhttps://laforge.gnumonks.org/blog/20051028-iso19794_5/2005-10-28T03:00:00+02:002005-10-28T03:00:00+02:00Harald Welte<p>
The next milestone of the <a href="http://openmrtd.org/projects/libmrtd">libmrtd project</a>, 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.).
</p>
<p>
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.
</p>
<p>
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.
</p>Public launch of the OpenMRTD.org projecthttps://laforge.gnumonks.org/blog/20051024-openmrtd/2005-10-24T03:00:00+02:002005-10-24T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
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 <a href="http://openmrtd.org">OpenMRTD.org</a>.
</p>librfid now deals with Mifare Classichttps://laforge.gnumonks.org/blog/20051022-librfid-mifare-classic/2005-10-22T03:00:00+02:002005-10-22T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
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 ;)
</p>Adding Mifare Ultralight support to librfidhttps://laforge.gnumonks.org/blog/20051019-librfid-mifare/2005-10-19T03:00:00+02:002005-10-19T03:00:00+02:00Harald Welte<p>
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 :(
</p>
<p>
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.
</p>librfid newshttps://laforge.gnumonks.org/blog/20050611-librfid-update/2005-06-11T03:00:00+02:002005-06-11T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
I've now also started work on <a href="http://svn.gnumonks.org/trunk/libmrtd">libmrtd</a>, 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.
</p>SVN repository url has changedhttps://laforge.gnumonks.org/blog/20050601-svn-url-changed/2005-06-01T03:00:00+02:002005-06-01T03:00:00+02:00Harald Welte<p>
I've now given the RFID stack project a new name "librfid". Therefore it now has moved to <a href="http://svn.gnumonks.org/trunk/librfid/">svn.gnumonks.org/trunk/librfid</a>.
</p>
<p>
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.
</p>The difficult task of designing simple and efficient hardwarehttps://laforge.gnumonks.org/blog/20050529-omnikey-lart/2005-05-29T03:00:00+02:002005-05-29T03:00:00+02:00Harald Welte<p>
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?
</p>
<p>
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.
</p>
<p>
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*.
</p>
<p>
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.
</p>My RFID stack now reads the ATS via T=CLhttps://laforge.gnumonks.org/blog/20050528-14443_4-working/2005-05-28T03:00:00+02:002005-05-28T03:00:00+02:00Harald Welte<p>
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 <a href="https://svn.gnumonks.org/trunk/librfid/">svn.gnumonks.org</a>,
for those of you who can't wait.
</p>
<p>
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.
</p>
<p>
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.
</p>CardMan 5121 / RC632 driver and 14443-3 layer workinghttps://laforge.gnumonks.org/blog/20050524-14443_3-working/2005-05-24T03:00:00+02:002005-05-24T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
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.
</p>
<p>
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', ...
</p>
<p>
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.
</p>
<p>
And after all, why would a socket API like interface be so bad?
</p>
<p>
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...
</p>Preliminary RC632 / CardMan 5121 code releasedhttps://laforge.gnumonks.org/blog/20050523-rc632-source-svn/2005-05-23T03:00:00+02:002005-05-23T03:00:00+02:00Harald Welte<p>
For those who are curious: I've made my current state of development on a
Philips CL RC632 driver4 available from <a href="http://svn.gnumonks.org/trunk/librfid/">svn.gnumonks.org</a>.
</p>Rewriting CardMan 5121 RFID driver softwarehttps://laforge.gnumonks.org/blog/20050521-cm5121-rewrite/2005-05-21T03:00:00+02:002005-05-21T03:00:00+02:00Harald Welte<p>
I've been spending quite some time lately to re-implement the host-side driver
for the Omnikey CardMan 5121 RFID part.
</p>
<p>
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.
</p>
<p>
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.
</p>
<p>
So far I think I've written about 60% of what's required to access my <a href="http://www.masktech.com/">MaskTech</a> MTCOS 1.1 (14443A) card.
</p>
<p>
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)...
</p>
<p>
I'm confident that within the next couple of days I'll have the system running.
</p>
<p>
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.
</p>Problems with RFID sniffing due to bad driver?https://laforge.gnumonks.org/blog/20050512-rfid-update/2005-05-12T03:00:00+02:002005-05-12T03:00:00+02:00Harald Welte<p>
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.
</p>
<p>
Nothing seemed to work. Then it turned out to be a driver issue with the <a href="http://www.omnikey.com/">Omnikey 5121</a> 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...
</p>
<p>
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.
</p>