import of old now defunct presentation slides svn repo

10 files changed, 1765 insertions, 0 deletions

diff --git a/2005/rfid-lk2005/abstract.txt b/2005/rfid-lk2005/abstract.txt
new file mode 100644
index 0000000..d1ea304
--- /dev/null
+++ b/2005/rfid-lk2005/abstract.txt
@@ -0,0 +1,26 @@
+RFID, Biometric Passports and Linux
+
+Numerous countries around the globe are in the process of introducing passports
+with biometric information stored on RFID chips, so-called ICAO MRTD's (Machine
+Readable Travel Documents).  The German authorities coincidentially plan to
+issue the first such passports at the time of LK2005 in October 2005.
+
+As part of the CCC (Chaos Computer Club) working group on biometric passprots,
+the author of this paper has followed the technical development and
+standardization process very closely.  In order to gather first-hand experience
+with this new technology, he has implemented a GPL-licensed, Linux-based RFID
+stack.  
+
+The stack includes a device driver for the common Philips CL RC632 reader
+chipset, an implementation of the ISO 14443-1, 2, 3 and 4 protocols, as well as
+an example "border control application" that is able to read and verify
+information stored on an ICAO MRTD compliant passport.
+
+The paper covers some high-level introduction into the technical standards, as
+well as a description of the "libmrtd" and "librfid" projects and a live
+demonstration with some passport samples.
+
+Due to the complexity of the subject matter, it will be hard to fit even a
+basic explanation of the standards and protocol _and_ an actual description of
+the librfid / libmrtd projects _and_ a technical demonstration into a single
+timeslot
diff --git a/2005/rfid-lk2005/biography.txt b/2005/rfid-lk2005/biography.txt
new file mode 100644
index 0000000..21758e7
--- /dev/null
+++ b/2005/rfid-lk2005/biography.txt
@@ -0,0 +1,27 @@
+  Harald Welte is the chairman of the netfilter/iptables core team.
+
+  His main interest in computing has always been networking.  In the few time
+left besides netfilter/iptables related work, he's writing obscure documents
+like the "UUCP over SSL HOWTO" or "A packet's journey through the Linux network
+stack".  Other kernel-related projects he has been contributing to are random
+netowrking hacks, some device driver work and the neighbour cache.
+
+  He has been working as an independent IT Consultant working on projects for
+various companies ranging from banks to manufacturers of networking gear.
+During the year 2001 he was living in Curitiba (Brazil), where he got
+sponsored for his Linux related work by Conectiva Inc.
+
+  Starting with February 2002, Harald has been contracted part-time by
+Astaro AG, who are sponsoring him for his current netfilter/iptables work.
+Aside from the Astaro sponsoring, he continues to work as a freelancing kernel
+developer and network security consultant.
+
+  He licenses his software under the terms of the GNU GPL.  Sometimes users of
+his software are not compliant with the license, so he started enforcing the
+GPL with his gpl-violations.org project.
+
+  During the last year, Harald has started development of a free, GPL-licensed
+Linux RFID and electronic passport software suite.
+
+Harald is living in Berlin, Germany.
+
diff --git a/2005/rfid-lk2005/brainstorm.txt b/2005/rfid-lk2005/brainstorm.txt
new file mode 100644
index 0000000..07074e3
--- /dev/null
+++ b/2005/rfid-lk2005/brainstorm.txt
@@ -0,0 +1,33 @@
+- RFID confusion
+	- passive 1-bit tags
+	- ro/rw memory
+	- state machines for permission checking
+	- contactless smartcards (processor chip cards, ...)
+
+- processor chip cards
+	- typically 8bit micrprocessor (e.g. 8051 based)
+	- MMU (!)
+	- typical configuration: 1k RAM, 32k Flash, 70k mask ROM
+
+
+- ISO 14443 "proximity cards"
+	- 14443-1 (physical specification)
+		- 13.56 MHz
+	- 14443-2 (radio interface)
+		- power transmission from reder (PCD) to card (PICC)
+			- 13.56MHz +- 7kHz
+			- field strength 1.5A/m to 7.5A/m (rms)
+		- channel from reader to card
+			- Type A: carrier modulation with 100% ASK, modified miller code
+			- Type B: carrier modulation with 10% ASK, NRZ-L code
+		- channel from card to reader
+			- Type A: load modulation on subcarrier fc/16, OOK, manchester code
+			- Type B: load modulation on subcarrier fc/16, BPSK, NRZ-L code
+	- 14443-3 (anti collision)
+		-
+
+
+- biometric passport
+	- technical view
+		- iso 7816-4 command based processor chip card
+		- iso 14443-{1,2,3,4} based RFID interface
diff --git a/2005/rfid-lk2005/libmrtd.xml b/2005/rfid-lk2005/libmrtd.xml
new file mode 100644
index 0000000..4f01956
--- /dev/null
+++ b/2005/rfid-lk2005/libmrtd.xml
@@ -0,0 +1,15 @@
+
+<section>
+<title>libmrtd - A free software library for ICAO MRTDs</title>
+<para>
+The libmrtd project intends to provide a free software 
+implementation of common operations related to ICAO compliant MRTD's, such as 
+verification of an ePassport (border control application).
+</para> 
+<para>
+Unfortunately, at the time of writing of this paper, progress of libmrtd was
+limited.  Nevertheless, the author is confident to show a live demonstration of
+ePassport verification when this paper is presented at Linux Kongress 2005.
+</para>
+
+</section>
diff --git a/2005/rfid-lk2005/librfid.xml b/2005/rfid-lk2005/librfid.xml
new file mode 100644
index 0000000..d4788db
--- /dev/null
+++ b/2005/rfid-lk2005/librfid.xml
@@ -0,0 +1,221 @@
+
+<section>
+<title>librfid - A free software RFID stack</title>
+<para>
+The librfid project intends to provide a free software reader-side
+implementation of common RFID protocols such as ISO 14443, ISO 15693.
+</para> 
+<para>
+Careful design and various abstraction layers should enable it to include
+support for various readers and protocols, even though as of now only a single
+reader and ISO 14443(A+B) is implemented.
+</para>
+
+
+
+<section>
+<title>Data Structures</title>
+<para>
+The librfid codebase is very modular and therefore data-centric.  It is
+therefore important to understand the various data structures and how they
+interact.
+</para>
+
+<section>
+<title>struct rfid_asic</title>
+<para>
+A struct rfid_asic is the integral part of every supported reader.  
+</para>
+<para>A
+separation between ASIC and reader makes sense, since almost all of the
+existing readers use one of the few available ASIC solutions from Philips, TI
+and the like.
+</para>
+</section>
+
+<section>
+<title>struct rfid_asic_transport</title>
+<para>
+A struct <structname>rfid_asic_transport</structname> connects a struct rfid_asic to librfid.  
+</para>
+<para>
+This transport is usually limited to very few essential primitives. With the
+Philips CL RC632, the asic transport has to provide four primitives: read/write
+register, and read/write FIFO.
+</para>
+</section>
+
+<section>
+<title>struct rfid_reader</title>
+<para>
+A struct <structname>rfid_reader</structname> contains information about the
+specific configuration of the ASIC as well as the transport.  
+</para>
+</section>
+
+<section>
+<title>struct rfid_layer2</title>
+<para>
+A struct <structname>rfid_layer2</structname> implements the anticollision procedure, such as ISO
+14443-3.
+</para>
+</section>
+
+<section>
+<title>struct rfid_protocol</title>
+<para>
+A struct <structname>rfid_protocol</structname> implements a transport protocol, such as ISO 14443-4
+</para>
+</section>
+
+<section>
+<title>Runtime handles</title>
+<para>
+Each of the structures described above, have a _handle structure.  The _handle
+(e.g. rfid_layer2_handle) saves instance-local state and allows the stack to
+identify the user.
+</para>
+</section>
+
+</section> <!-- data structures -->
+
+<section>
+<title>Protocol Stack</title>
+<para>
+In the typical current setup (CardMan 5121 reader, ISO14443-123A, ISO14443-4),
+those data structures are stacked on top of each other like this:
+<screen>
+rfid_protocol_tcl
+rfid_layer2_iso14443a
+CM5121 reader
+CL RC632 asic
+PC_to_RDR_Escape transport
+USB-CCID
+libusb
+</screen>
+</para>
+</section>
+
+<section>
+<title>Interaction with OpenCT</title>
+
+<section>
+<title>What is OpenCT</title>
+<para>
+OpenCT is a free software smart card reader driver package, originally
+developed for the OpenSC (http://www.opensc.org) project.  As of now, it only
+supports contact based smart cards.
+</para>
+</section>
+
+<section>
+<title>Integration with OpenCT</title>
+<para>
+First of all, why use OpenCT at all?  Because like other "consumer" RFID
+readers, the 5121 supports contact based and contactless operation.  Its
+contact based operation is already supported by the OpenCT ifd-ccid driver.
+</para>
+<para>
+Also, many "legacy" smart card applications expect to talk to a PC/SC or CT-API
+interface.  OpenCT already provides a "ifdehandler" backend for pcsc-lite, as
+well as a CT-API wrapper.  In addition, OpenCT suports a client/server
+architecture where readers can be shared in a network. If librfid was
+integrated with OpenCT, it could directly benefit from those features.
+</para>
+<para>
+On the other hand, there are many usage cases, where neither dual-interface
+operation nor a PC/SC API is applicable.  This includes usage of passive (state
+machine) tags that do not speak sophisticate transport protocols such as
+14443-4.  Therefore, OpenCT integration on both backend and frontend can only
+be provided optionally, ant not made mandatory.
+</para>
+
+<para>
+The overall integration with OpenCT is:
+</para>
+<para>
+Export the PC_TO_RDR_ESCAPE based interface to the RFID Reader ASIC (Philips
+RC632) as a virtual slot (always the last slot number 2 of the cm5121).  This
+virtual slot supports only one special protocol: The "ESCAPE" protocol.
+</para>
+<para>
+The RFID software stack opens this virtual slot to talk to the RFID
+Reader ASIC using the OpenCT API (CT_Card_Transact).
+</para>
+<para>
+The RFID software stack implements the various protocols and protocol layers
+</para>
+<para>
+The RFID software stack registers a number of slots as ifd-handler with
+OpenCT.  The slots provide access to protocols like T=CL.                       </para>
+</section>
+
+</section>
+
+<section>
+<title>Application Interfaces</title>
+
+<section>
+<title>Native API</title>
+<para>
+The native API is the API that librfid uses internally.  It reflects all 
+features, and by it's very nature not compatible to any standard.
+Also, it is the only API that is fully supported at the time this paper was written.
+</para>
+<para>
+The API is not very comfortable, as many calls have to be made, and everything is explicit.  There is no support for advanced features such as auto-detecting the standard/protocol a given tag supports.
+</para>
+<para>
+An application will likely start with <function>rfid_init()</function>,
+followed by <function>rfid_reader_open()</function>, <function>rfid_layer2_init()</function>, <function>rfid_layer2_open()</function>,
+<function>rfid_protocol_init()</function> and <function>rfid_orotocol_open()</function>.
+</para>
+<para>
+Data is transcieved to and from the tag by calling <function>rfid_protocol_transcieve()</function>.
+</para>
+<para>
+For an example on how to use the API, please look at the
+<filename>librfid/openct-secape.c</filename> program in the librfid source
+tree.
+</para>
+
+<section>
+<title>OpenCT, CT-API, PC/SC</title>
+<para>
+librfid will not by itself provide any of those interfaces, but rather
+implement an OpenCT backend driver (ifd-librfid). 
+</para>
+<para>
+At the time of writing, such a backend did not yet exist.
+</para>
+</section>
+
+</section> <!-- API's -->
+
+<section>
+<title>Future Development</title>
+<para>
+librfid is currently in an early alpha/beta state.  It is not yet ready for
+production use.  Apart from a hand full of minor fixes from MaskTech GmbH, 
+it's a one-man project.  It's also not a project that I can focus on, because
+its main author has many other project and considers librfid more or less a
+"pet project".
+</para>
+<para>
+Therefore, skilled developers are needed.  If you want to experiment with RFID
+technology, and really learn about the protocols instead of just using
+something ready-built, librfid should provide you with a good basis.
+</para>
+<para>
+The initial code is there, you can do something useful (namely: Talk to
+ISO14443-A and -B cards using T=CL protocol).  If you feel like adding support
+for some other reader device, or further protocols, any help is appreciated.
+</para>
+<para>
+There's now also a development mailinglist at <email>librfid-devel@lists.gnumonks.org</email>.
+</para>
+</section>
+
+</section>
+
+</section>
diff --git a/2005/rfid-lk2005/mrtd.xml b/2005/rfid-lk2005/mrtd.xml
new file mode 100644
index 0000000..4db57c3
--- /dev/null
+++ b/2005/rfid-lk2005/mrtd.xml
@@ -0,0 +1,257 @@
+
+
+<section>
+<title>ePassports - Electronic Passports</title>
+
+<section>
+<title>Introduction</title>
+<para>
+Electronic passports that are deployed arond the world (including Germany) will
+be based on RFID technology.
+</para>
+<para>
+Technically speaking, ePassports are ICAO[1] compliant MRTD[2]'s.  ICAO is an
+international body that already specifies the current OCR readable lines on
+travel documents.  The ICAO MRTD specifications are publicly available from the
+ICAO homepage.
+</para>
+<para>
+From a technical point of view, ePassports are ISO 14443-1,2,3,4 compliant
+contactless smart cards.  On top of 14443-4 transport layer protocol, APDU's
+according to ISO 7816-4 are exchanged.
+</para>
+<para>
+For those readers who are not familiar with smart card technology: ISO 7816-4
+(tries to) specify interindustry commands for interchange with ID cards.
+</para>
+<para>
+The ISO 7816-4 smartcard provides a filesystem based interface to the
+information stored on the ePassport.  The Application software issues
+high-level commands such as "SELECT FILE", "READ BINARY" to the MRTD.
+</para>
+<para>
+The ICAO recommends a minimum memory size of 32kBytes.  However, it recommends
+as much memory as possible, and indicates 512kBytes as a target.
+</para>
+<para>
+As of now, the MRTD chip has to operate in a write once, read many fashion.
+After the document is issued, it must not be allowed to change any data.
+Future standards may include the possibility to store electronic visa data.
+</para>
+</section>
+
+<section>
+<title>Organization of Data</title>
+
+<para>
+Data on the ePassport is organized according to a specification called LDS
+(logical data structure).  LDS specifies a number of DG's (Data Groups), as
+well as the encoding of the data.
+</para>
+
+<para>
+The most important data groups are:
+</para>
+
+<para>
+DG1 is mandatory and contains the same data as printed on the cover page like
+name, date of birth, expiration date, document number, nationality, etc.
+</para>
+<para>
+DG2 (mandatory) contains the JPEG2000 encoded facial image and corresponding biometric data
+</para>
+<para>
+DG3 (optional) contains biometric fingerprint data - not in German passports
+</para>
+<para>
+DG4 (optional) contains biometric iris data - not in German passports
+</para>
+
+<para>
+ICAO requires data in DG1 and DG2 to be stored unencrypted, since it only
+resembles the data that is human-readable on the printed pages of the passport.
+Additional biometric data such as iris and/or fingerprint information may be
+stored in an encrypted format.  As of now, this is up to the issuing country.
+Any form of encryption is outside the ICAO MRTD specifications and will thus not
+work interoperable on an international level.
+</para>
+<para>
+All biometric information stored within LDS is further encoded according to
+CBEFF (Common Biometric Exchange File Format, NISTIR 6529-A), a common file
+format that facilitates exchange and interoperablity of biometric data.
+</para>
+<para>
+Each data group is cryptographically signed.  The signature is stored in EF.SOD
+(Security Object Data).
+</para>
+</section>
+
+<section>
+<title>Security Features</title>
+
+<section>
+<title>Randomization of unique serial number</title>
+<para>
+All ISO14443 compatible RFID chips disclose a unique serial number during the
+anticollision procedure.  This poses the potential threat of pseudonymised
+tracking.  The German BSI therefore requires this randomization of the
+serial number.
+</para>
+</section>
+
+<section>
+<title>Passive Authentication (mandatory)</title>
+<para>
+Passive authentication performs verification of the EF.SOD signature(s).  This
+assures that the content of the data groups is signed by the issuing country.
+However, passive authentication does not prevent copying of a MRTD.
+</para>
+</section>
+
+<section>
+<title>Active Authentication (optional)</title>
+<para>
+Ative authentication can be employed to verify that the chip has not been
+substituted.  It is based on a challenge response protocol.
+The MRTD chip contains an active authentication public key Pair (KPrAA and
+KPuAA). A hash representation of KPuAA is stored in EF.SOD and therefore
+authenticated by the issuing country certifiate.  KPrAA is stored in on-chip
+secure memory.  
+</para>
+</section>
+
+<section>
+<title>Basic Access Control (optional, implemented in Geman ePassports)</title>
+<para>
+Basic access control denies access to the MRTD chip until the inspection system
+proves that it is authorized to access the chip.  This proof of authorization
+is done by deriving a pair of keys (Kmac and Kenc) from the OCR-read machine
+readable zone (MRZ).  BAC can therfore prevent unauthorized "harvesting" of
+passport data without being noticed by the passport holder.  BAC also mandates
+that any communication following-up to BAC has to be encrypted via ISO 7816-7/8
+secure messaging (SM).  This transport level security can be somewhat compared
+to running TLS on top of a TCP session.
+</para>
+</section>
+
+<section>
+<title>Extended Access Control (optional)</title>
+<para>
+Extended Access Control prevents unauthorized access to additional biometrics.
+It is similar to Basic Access Control, but requires separate keys and key
+management.  There is no ICAO MRTD standard on how it is implemented or used,
+and therefore subject to the issuing state.
+</para>
+</section>
+
+</section> <!-- security architecture -->
+
+<section>
+<title>The Public Key Hierarchy</title>
+<para>
+The PKI hierarchy is obviously nothing that directly affects the passport
+itself.  However, it is integral to the security of the system, so this paper provides a quick overview:
+</para>
+<para>
+All keys are issued in the familiar form of X.509 certificates.
+</para>
+<para>
+Each issuing state operatesits own "Country Singing CA".  There is no
+supernational Root CA.  This is neccessary, since every country decides on its
+own if it recognizes a particular other country.  This also means that every
+reader ("inspection system") has to store the Document Signer Certificate of
+every recognized issuing country.
+</para>
+<para>
+The individual ePassports are signed using Document Signer Keys.  The Document
+Signer Keys are in turn signed by the Country Signing CA.  Document Signer keys
+have limited lifetime, and it is recommended that issuing countries delete the
+private key after the last passport for that key has been issued.
+</para>
+<para>
+Issuing countries have to provide certificate revocation lists (CRLs) at least
+every 90 days, but not more often than every 48 hours
+</para>
+<para>
+The ICAO operates a "public key directry" which will be set up as X.500
+directory, updates are performed over LDAP.  All communication with the PKD is
+SSL authenticated.  The PKD stores Document Signer Certificates, but not
+Country signing CA certificates.  ICAO verifies signatures of all incoming
+Certificates and CRL's before making them available.  The PKD has public read
+access on the internet.
+</para>
+<para>
+Country signing CA certificates will be provided bilaterally between countries.
+</para>
+
+</section>
+
+<section>
+<title>Crypto Algorithms</title>
+<para>
+The ICAO MRTD specification allows RSA, DSA and Elliptic Curve DSA with various
+minimal key lengths:
+</para>
+
+<informaltable border="1" width="90%">
+<tgroup cols="4">
+<thead>
+<row><entry>Algorithm</entry><entry>Active Auth</entry><entry>Document Signer</entry><entry>Country Signing CA</entry></row>
+</thead>
+<tbody>
+<row>
+  <entry>RSA</entry><entry>1024</entry><entry>2048</entry><entry>3072</entry>
+</row>
+<row>
+  <entry>DSA</entry><entry>1024/160</entry><entry>2048/224</entry><entry>3072/256</entry>
+</row>
+<row>
+  <entry>ECDSA</entry><entry>160</entry><entry>224</entry><entry>256</entry>
+</row>
+</tbody>
+</tgroup>
+</informaltable>
+
+</section>
+
+<section>
+<title>Security threats</title>
+
+<section>
+<title>Small Keyspace of basic access control</title>
+<para>
+The entropy of the MRZ data used to derive Kenc and Kmac for basic access
+control is very limited.  The nine digit document number is concatenated with
+the date of birth and the expiration date of the document.  
+</para>
+<para>
+Since ICAO MRTD specifications recommend ePassports not to be valid for more
+than five years, the expiration date can only be one out of (365*5 = 1325)
+values.  
+</para>
+<para>
+The date of birth can realistically assume only values between 18 and 90 years
+old (365*72 = 26280).  Also, in case of a specific person, the range of the DOB
+can often be estimated to a certain range.
+</para>
+<para>
+Document Numbers are issued sequentially in some countries, and can therefore
+be reduced to certain ranges.  In Germany, the first four digits specify the
+issuing department, and the following five digits increment sequentially.
+</para>
+</section>
+
+<section>
+<title>Grandmaster Chess Attack</title>
+<para>
+The Active Authentication mechanism is meant to prevemt chip substitution (e.g.
+carbon copying).  However, it cannot prevent a "grandmaster chess attack",
+where the inspection system talks to a "proxy" chip that would temporarily
+communicate with the original MRTD.
+</para>
+</section>
+
+
+</section> <!-- security -->
+
+</section> <!-- passports -->
diff --git a/2005/rfid-lk2005/rfid-lk2005.tex b/2005/rfid-lk2005/rfid-lk2005.tex
new file mode 100644
index 0000000..97939da
--- /dev/null
+++ b/2005/rfid-lk2005/rfid-lk2005.tex
@@ -0,0 +1,307 @@
+\FOT{2}\Seq%
+{\def\HeadingLevel%
+{0}\def\PageNumberFormat%
+{1}\def\PageNumberRestart%
+{0}\def\PageNColumns%
+{1}\def\PageColumnSep%
+{36\p@}\def\PageBalanceColumns%
+{0}\def\WritingMode%
+{lefttoright}\def\InputWhitespaceTreatment%
+{collapse}\def\LeftMargin%
+{72\p@}\def\RightMargin%
+{72\p@}\def\PageWidth%
+{612\p@}\def\PageHeight%
+{792\p@}\def\MinLeading%
+{2\p@}\def\MinLeadingFactor%
+{0}\def\TopMargin%
+{72\p@}\def\BottomMargin%
+{96\p@}\def\HeaderMargin%
+{48\p@}\def\FooterMargin%
+{48\p@}}\Node%
+{}\Node%
+{\def\Label%
+{rfid_introduction-ds}}\Seq%
+{}\SpS%
+{\def\PageNColumns%
+{1}\def\PageNumberRestart%
+{0}\def\PageNumberFormat%
+{1}\def\StartIndent%
+{48\p@}\def\StartIndentFactor%
+{0}\def\InputWhitespaceTreatment%
+{collapse}\def\Quadding%
+{start}\def\fSize%
+{10\p@}\def\fWeight%
+{medium}\def\fPosture%
+{upright}\def\fFamName{Times-New-Roman}\def\LineSpacing%
+{13\p@}\def\LineSpacingFactor%
+{0}}
+\SpSOtherBackLeftFooter%
+{}
+\SpSOtherBackLeftHeader%
+{}
+\SpSOtherBackCenterFooter%
+{}
+\SpSOtherBackCenterHeader%
+{}
+\SpSOtherBackRightFooter%
+{\Seq%
+{\def\fPosture%
+{italic}}\insertPageNumber%
+{}\endSeq{}}
+\SpSOtherBackRightHeader%
+{\Seq%
+{\def\fPosture%
+{italic}}\Node%
+{\def\Element%
+{2}\def\ProcessingMode%
+{hf-mode}}\Seq%
+{}RFID, Biometric Passports and Linux\endSeq{}\endNode{}\endSeq{}}
+\SpSFirstBackLeftFooter%
+{}
+\SpSFirstBackLeftHeader%
+{}
+\SpSFirstBackCenterFooter%
+{}
+\SpSFirstBackCenterHeader%
+{}
+\SpSFirstBackRightFooter%
+{\Seq%
+{\def\fPosture%
+{italic}}\insertPageNumber%
+{}\endSeq{}}
+\SpSFirstBackRightHeader%
+{}
+\SpSOtherFrontLeftFooter%
+{}
+\SpSOtherFrontLeftHeader%
+{}
+\SpSOtherFrontCenterFooter%
+{}
+\SpSOtherFrontCenterHeader%
+{}
+\SpSOtherFrontRightFooter%
+{\Seq%
+{\def\fPosture%
+{italic}}\insertPageNumber%
+{}\endSeq{}}
+\SpSOtherFrontRightHeader%
+{\Seq%
+{\def\fPosture%
+{italic}}\Node%
+{\def\Element%
+{2}\def\ProcessingMode%
+{hf-mode}}\Seq%
+{}RFID, Biometric Passports and Linux\endSeq{}\endNode{}\endSeq{}}
+\SpSFirstFrontLeftFooter%
+{}
+\SpSFirstFrontLeftHeader%
+{}
+\SpSFirstFrontCenterFooter%
+{}
+\SpSFirstFrontCenterHeader%
+{}
+\SpSFirstFrontRightFooter%
+{\Seq%
+{\def\fPosture%
+{italic}}\insertPageNumber%
+{}\endSeq{}}
+\SpSFirstFrontRightHeader%
+{}\Seq%
+{}\Seq%
+{}\Seq%
+{}\Node%
+{\def\Element%
+{2}\def\ProcessingMode%
+{article-titlepage-recto-mode}}\Par%
+{\def\fSize%
+{24.883\p@}\def\LineSpacing%
+{32.348\p@}\def\LineSpacingFactor%
+{0}\def\Quadding%
+{center}\def\fFamName{Arial}\def\fWeight%
+{bold}\def\sbNom%
+{18.662\p@}\def\sbMin%
+{18.662\p@}\def\sbMax%
+{18.662\p@}\def\sbConditional%
+{1}\def\KeepWithNext%
+{1}}RFID, Biometric Passports and Linux\endPar{}\endNode{}\Seq%
+{}\Node%
+{\def\Element%
+{3}\def\ProcessingMode%
+{article-titlepage-recto-mode}}\DisplayGroup%
+{}\Node%
+{\def\Element%
+{4}\def\ProcessingMode%
+{article-titlepage-recto-mode}}\Seq%
+{}\Par%
+{\def\fSize%
+{17.28\p@}\def\LineSpacing%
+{22.464\p@}\def\LineSpacingFactor%
+{0}\def\Quadding%
+{center}\def\fFamName{Arial}\def\fWeight%
+{bold}\def\sbNom%
+{10.8\p@}\def\sbMin%
+{10.8\p@}\def\sbMax%
+{10.8\p@}\def\sbConditional%
+{1}\def\KeepWithNext%
+{1}}Harald Welte\endPar{}\endSeq{}\endNode{}\endDisplayGroup{}\endNode{}\Seq%
+{}\Node%
+{\def\Element%
+{14}\def\ProcessingMode%
+{article-titlepage-recto-mode}}\Par%
+{\def\Quadding%
+{center}\def\fFamName{Arial}\def\fWeight%
+{bold}\def\fSize%
+{12\p@}}
+		\$Revision: 1.4 \$
+	\endPar{}\endNode{}\Seq%
+{}\Node%
+{\def\Element%
+{9}\def\ProcessingMode%
+{article-titlepage-recto-mode}}\Par%
+{\def\Quadding%
+{center}\def\fFamName{Arial}\def\fWeight%
+{bold}\def\fSize%
+{12\p@}\def\sbNom%
+{10.8\p@}\def\sbMin%
+{10.8\p@}\def\sbMax%
+{10.8\p@}\def\sbConditional%
+{1}}Copyright © \Node%
+{\def\Element%
+{10}\def\ProcessingMode%
+{article-titlepage-recto-mode}}\Seq%
+{}2005 \endSeq{}\endNode{}\Node%
+{\def\Element%
+{11}\def\ProcessingMode%
+{article-titlepage-recto-mode}}\Seq%
+{}Harald Welte <\/laforge@gnumonks.org>\/ \endSeq{}\endNode{}\endPar{}\endNode{}\Seq%
+{}\Node%
+{\def\Element%
+{15}\def\ProcessingMode%
+{article-titlepage-recto-mode}}\DisplayGroup%
+{\def\Quadding%
+{start}\def\StartIndent%
+{65.5\p@}\def\StartIndentFactor%
+{0}\def\EndIndent%
+{17.5\p@}\def\EndIndentFactor%
+{0}\def\fFamName{Times-New-Roman}}\DisplayGroup%
+{\def\StartIndent%
+{65.5\p@}\def\StartIndentFactor%
+{0}\def\sbNom%
+{10\p@}\def\sbMin%
+{10\p@}\def\sbMax%
+{10\p@}\def\sbConditional%
+{1}\def\saNom%
+{10\p@}\def\saMin%
+{10\p@}\def\saMax%
+{10\p@}\def\saConditional%
+{1}}\Node%
+{\def\Element%
+{16}\def\ProcessingMode%
+{article-titlepage-recto-mode}}\Par%
+{\def\FirstLineStartIndent%
+{0\p@}\def\FirstLineStartIndentFactor%
+{0}\def\Quadding%
+{start}\def\Hyphenate%
+{0}\def\Language%
+{EN}\def\sbNom%
+{20\p@}\def\sbMin%
+{20\p@}\def\sbMax%
+{20\p@}\def\sbConditional%
+{1}\def\saNom%
+{1.25\p@}\def\saMin%
+{1.25\p@}\def\saMax%
+{1.25\p@}\def\saConditional%
+{1}}
+Starting with October 2005, the federal goverment of Germany will be issuing
+eplectronic passports, containing digitally signed biometric information on the
+passport holder.  Those passports use RFID technology to communicate with the
+inspection system.
+\endPar{}\endNode{}\Node%
+{\def\Element%
+{17}\def\ProcessingMode%
+{article-titlepage-recto-mode}}\Par%
+{\def\FirstLineStartIndent%
+{0\p@}\def\FirstLineStartIndentFactor%
+{0}\def\Quadding%
+{start}\def\Hyphenate%
+{0}\def\Language%
+{EN}\def\sbNom%
+{20\p@}\def\sbMin%
+{20\p@}\def\sbMax%
+{20\p@}\def\sbConditional%
+{1}\def\saNom%
+{1.25\p@}\def\saMin%
+{1.25\p@}\def\saMax%
+{1.25\p@}\def\saConditional%
+{1}}
+In order to do security research on ePassports and RFID in general, the author
+of this paper has started a free implementation of the required RFID stack
+(librfid) and an ICAO MRTD verification application (libmrtd).
+\endPar{}\endNode{}\Node%
+{\def\Element%
+{18}\def\ProcessingMode%
+{article-titlepage-recto-mode}}\Par%
+{\def\FirstLineStartIndent%
+{0\p@}\def\FirstLineStartIndentFactor%
+{0}\def\Quadding%
+{start}\def\Hyphenate%
+{0}\def\Language%
+{EN}\def\sbNom%
+{20\p@}\def\sbMin%
+{20\p@}\def\sbMax%
+{20\p@}\def\sbConditional%
+{1}\def\saNom%
+{1.25\p@}\def\saMin%
+{1.25\p@}\def\saMax%
+{1.25\p@}\def\saConditional%
+{1}}
+This task can be compared to the task of developing a network driver, network
+stack and ssl-\/enabled ftp client just to be able to capture a ftp data session.
+Therefore progress of the librfid and libmrtd projects was quite slow.
+\endPar{}\endNode{}\Node%
+{\def\Element%
+{19}\def\ProcessingMode%
+{article-titlepage-recto-mode}}\Par%
+{\def\FirstLineStartIndent%
+{0\p@}\def\FirstLineStartIndentFactor%
+{0}\def\Quadding%
+{start}\def\Hyphenate%
+{0}\def\Language%
+{EN}\def\sbNom%
+{20\p@}\def\sbMin%
+{20\p@}\def\sbMax%
+{20\p@}\def\sbConditional%
+{1}\def\saNom%
+{1.25\p@}\def\saMin%
+{1.25\p@}\def\saMax%
+{1.25\p@}\def\saConditional%
+{1}}
+However, the project has by now reached a stage where it can actually do
+something reasonable: Reading and decoding data from an ePassport.
+\endPar{}\endNode{}\endDisplayGroup{}\endDisplayGroup{}\endNode{}\endSeq{}\endSeq{}\endSeq{}\endSeq{}\endSeq{}\endSeq{}\endSeq{}\Node%
+{\def\Element%
+{1}}\endNode{}\Node%
+{\def\Element%
+{20}}\Seq%
+{\def\ColorRed%
+{255}\def\ColorGreen%
+{0}\def\ColorBlue%
+{0}}\endSeq{}\endNode{}\Node%
+{\def\Element%
+{21}}\Seq%
+{\def\ColorRed%
+{255}\def\ColorGreen%
+{0}\def\ColorBlue%
+{0}}\endSeq{}\endNode{}\Node%
+{\def\Element%
+{22}}\Seq%
+{\def\ColorRed%
+{255}\def\ColorGreen%
+{0}\def\ColorBlue%
+{0}}\endSeq{}\endNode{}\Node%
+{\def\Element%
+{23}}\Seq%
+{\def\ColorRed%
+{255}\def\ColorGreen%
+{0}\def\ColorBlue%
+{0}}\endSeq{}\endNode{}\endSpS{}\endSeq{}\endNode{}\endNode{}\endSeq{}\endFOT{}
\ No newline at end of file
diff --git a/2005/rfid-lk2005/rfid-lk2005.tpp b/2005/rfid-lk2005/rfid-lk2005.tpp
new file mode 100644
index 0000000..a495fac
--- /dev/null
+++ b/2005/rfid-lk2005/rfid-lk2005.tpp
@@ -0,0 +1,303 @@
+--author Harald Welte <laforge@gnumonks.org>
+--title RFID, Biometric Passports and Linux
+--date 13 Oct 2005
+Starting in November, the German federal government will be issuing epectronic passports with RFID interface.  
+
+This presentation covers technical background about the RFID technology, the ICAO MRTD specification, and the authors' efforts to develop a free software stack to use Linux to communicate with those passports.
+--footer This presentation is made with tpp http://synflood.at/tpp.html
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header Overview
+Introduction into RFID
+	What is RFID
+	Components of RFID System
+	Protocols and Standards
+	Security ISsues
+librfid - A free software RFID stack
+	Data Structures
+	Protocol Stack
+	Interaction with OpenCT
+ePassports - Electronic Passports
+	Organization of Data
+	Security Features
+	PKI
+	Crypto Algorithms
+	Security Threats
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header Introduction into RFID
+Definition of term RFID
+	Radio Frequency IDentification
+	
+RFID is one of the recent buzzwords in lots of industries, such as
+	transportation
+	retail sector
+	governments
+
+Like most buzzwords, it's not very clearly defined.  There is no such thing as "the RFID System. There are lots of different Systems, some standardized, most proprietary.  Each of them uses it's own frequency, modulation, encoding and protocol combination.  Often, systems of multiple vendors can not be used interchangibly.
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header Components of an RFID system
+Tag (Transponder)
+	Serial Number Tags
+		Replacement for EAN/UPC Barcodes
+	WORM Tags
+		Can be written once by Issuer
+	Read/Write Tags
+		Can be re-written many times
+	Read/Write Tags with "passive" security
+		Have state-machine based crypto for access control
+	Cryptographic smartcards with RF Interface
+		Like other crypto smartcards, just with RF interface
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header Reader
+Readers (Coupling Device)
+	Readers are always called readers, even if they can write ;)
+	Usually connected to a host computer via RS-323, USB or alike
+	Unfortunately no standard, for API, Hardware and/or Protocol :(
+	Most applications are written to vendor-provided device-specific API's
+	One exception: Readers for Smartcards with RF-Interface (use PC/SC)
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header RF Interface
+The RF interface is the key attribute of any RFID system.
+Parameters that determine the RF interface are
+	frequency
+	modulation
+	operational principle
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header RF Interface
+Magnetic Coupling
+	used by many of todays RFID deployment
+	rely on the magnetic coupling ("transformer") principle
+	Tag/Transponder has a coil antenna to pick up RF-Field of Reader
+	Power for Tag/Transponder is drawn from the magnetic field
+	Common systems use 125kHz (old) or 13.56MHz (current)
+	Operational range often small, since high magnetic field strengh needed
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header RF Interface
+Backscatter
+	Used by many RFID systems under current development
+	Operate typically in UHF range (868 to 956 MHz)
+	Use electric field of the reader, employ backscatter modulation
+	Higher operational range (within tens of metres)
+
+Surface Accoustic Wave
+	SAW tags use low-power microwave radio signals
+	Tag/Transponder converts it to untrasonic signals (piezo crystal)
+	Variations of the reflected signal used to provide a unique number
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header Protocols and Standards
+Apart from the various vendor proprietary protocols, there are some ISO standards
+ISO 11784 / 11785
+	Identification of Animals
+	134.2kHz, magnetic coupling, load modulation, 4191 bps
+ISO 14223
+	Extension of 11784/11785 and allows for more data
+ISO 10536
+	"close coupling" smart cards, range up to 1cm
+	Inductive or capacitive coupling at 4.9152MHz
+	Never attained any significant market share
+ISO 18000 series
+	Current development of international "Auto-ID" standard
+	Includes operation on 13.56MHz, 2.4GHz, 868/956MHz
+	Not yet deployed
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header Protocols and Standards
+ISO 14443
+	"proximity coupling ID cards"
+	Range of up to 10cm
+	Two variants: 14443-A and 14443-B
+	Both use 13.56MHz, but different parameters (see paper for details)
+	Specifies physical layer, link-layer (anticollision)
+	Specifies an optional transport level protocol (ISO 14443-4)
+	Speed up to 848kbits/sec
+
+ISO 15693
+	"vicinity coupling", range up to 1m
+	Like ISO 14443, operates on 13.56MHz, magnetic coupling
+	Data rate 1.65kbits/sec or 26.48kbits/sec
+	Because of long distance, very little power
+	Therefore only used for passive tags
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header Closer look on Readers
+There's a variety of readers for the 13.56MHz world
+Usually they all use one of the (small number of) available ASIC's
+Reader ASIC's integrate analog and digital part and have standard bus interface
+End-User Reader products contain such an ASIC plus a microcontroller
+
+Active Readers
+	e.g. "Philips Pegoda"
+	Run the RFID protocol stack on the microcontroller
+
+Passive Readers
+	e.g. "Omnikey CardMan 5121"
+	Run the RFID protocol on the host system
+
+Passive readers obviously provide higher flexibility and are cheaper.
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header Security Issues
+Eavesdropping
+	Channel from reader to tag can be easily sniffed (even > 10m)
+	Channel from tag to reader is difficult (Author has managed 3m)
+
+Denial of Service
+	Anti-collision mechanism used to distinguish between multiple tags
+	Using a "fake tag" you can create Denial of Service
+	Products such as "blocker tags" have already been presented
+
+Authenticity/Confidentiality
+	None of the existing standards offers any kind of crypto
+	Standards-compliant systems like passports use crypto at layer 5
+	Lots of proprietary "closed algorithm" vendor products with questionable security
+
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header librfid - A Free Software RFID stack
+The librfid project intends to provide a free software reader-side implementation of common RFID protocols such as ISO 14443 and ISO 15693
+
+Various abstraction layers and plugin interface allows for later addition of new protocols an readers.
+
+Optionally integrates with OpenCT.
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header librfid - A Free Software RFID stack
+struct rfid_asic
+	Contains all routines for a specific reader asic
+	Currently only Philips CL RC 632 supported
+struct rfid_asic_transport
+	A transport that gives access to the ASIC registers
+struct rfid_reader
+	A container for rfid_asic and rfid_asic_transport
+struct rfid_layer2
+	An anticollision protocol such as ISO 14443-3A/B
+struct rfid_protocol
+	A transport protocol suhc as ISO 14443-4
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header librfid - A Free Software RFID stack
+
+Typical Protocol Stack
+	rfid_protocol_stack
+	CM5121 Reader
+	CL RC632 ASIC
+	PC_to_RDR_Escape transport
+	USB-CCID driver of OpenCT
+	libusb
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header librfid - A Free Software RFID stack
+Application Interface
+
+Native API
+	librfid-specific API
+	quite low-level
+	requires application to know a lot about the stack
+
+OpenCT, PC/SC, CT-API
+	OpenCT integration provides PC/SC and CT-API for crypto smarcards
+	Is currently under development
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header Electronic Passports
+Electronic Passports (ePassports) are officially called MRTD
+MRTD: Machine Readable Travel Document
+Specifications by ICAO (International Civil Aviation Organization)
+Basic idea 
+	store passport data and additional biometrics on Transponder
+	alternate storage methods such as 2D barcodes covered, too
+	common standard for interoperability
+	some features required, others optional (up to issuing country)
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header Electronic Passports
+Organization of Data
+	According to LDS (Logical Data Structure) specification
+	Data is stored in DG (Data Groups)
+		DG1: MRZ information (mandatory)
+		DG2: Portrait Image + Biometric template (mandatory)
+		DG3-4: fingerprints, iris image (optional)
+	EF.SOD: Security Object Data (cryptographic signatures)
+	EF.COM: Lists with Data Groups Exist
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header Electronic Passports
+Security Features
+	Randomization of Serial Number
+	Passive Authentication (mandatory)
+		Inspection System verifies signature of DG's
+	Active Authentication (optional)
+		Verifies that chip has not been substituted
+	Basic Access Control (optional, implemented in .de passports)
+		Denies Access to the chip until inspection system is authorized
+		Authorization is performed by deriving keys from MRZ
+	Extended Access Control (optional)
+		Prevents unauthorized access to additional bimetrics
+		Similar to Basic Access Control, but different keys
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header Electronic Passports
+Public Key Hierarchy
+	X.509 Certificates
+	Every country operates it's own CA
+	Document signer keys derived from CA root
+	Document signer public keys are distributed publicly via ICAO PKD
+	Everyone can verify
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header libmrtd - Free Software library for MRTD's
+libmtrd provides functions for
+	reading out and decoding data on MRTD
+	verifying data stored on MRTD
+	cryptograpy compliant with MRTD specs
+		basic access control
+		passive authentication
+		extended access control (planned)
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header libmrtd - Free Software library for MRTD's
+API towards the lower level (transport)
+	PC/SC (to work with readers/drivers other than librfid)
+	native librfid API
+API towards the application
+	not really finished yet, lots of flux
+
+--newpage
+--footer RFID, Biometric Passports and Linux
+--header libmrtd - Free Software library for MRTD's
+libmrtd status
+	parsing functions for LDS
+	parsing functions for DG1
+	parsing functions for DG2 (CBEFF)
+	basic access control
+	still very early alpha stage
+	contributors welcome
+	no program
diff --git a/2005/rfid-lk2005/rfid-lk2005.xml b/2005/rfid-lk2005/rfid-lk2005.xml
new file mode 100644
index 0000000..99ed200
--- /dev/null
+++ b/2005/rfid-lk2005/rfid-lk2005.xml
@@ -0,0 +1,72 @@
+<?xml version='1.0' encoding='ISO-8859-1'?>
+<!DOCTYPE article PUBLIC '-//OASIS//DTD DocBook XML V4.3//EN' 'http://www.docbook.org/xml/4.3/docbookx.dtd'>
+
+<article id="rfid_introduction-ds">
+
+<articleinfo>
+	<title>RFID, Biometric Passports and Linux</title>
+	<authorgroup>
+		<author>
+			<personname>
+				<firstname>Harald</firstname>
+				<surname>Welte</surname>
+			</personname>
+		<!--
+			<personblurb>Harald Welte</personblurb>
+				<affiliation>
+					<orgname>netfilter core team</orgname>
+					<address>
+						<email>laforge@netfilter.org</email>
+					</address>
+				</affiliation>
+
+			-->
+			<email>laforge@gnumonks.org</email>
+		</author>
+		</authorgroup>
+	<copyright>
+		<year>2005</year>
+		<holder>Harald Welte &lt;laforge@gnumonks.org&gt; </holder>
+	</copyright>
+	<date>Sep 21, 2005</date>
+	<edition>1</edition>
+	<!-- <orgname>netfilter core team</orgname> -->
+	<releaseinfo>
+		$Revision: 1.4 $
+	</releaseinfo>
+
+	<abstract>
+
+<para>
+Starting with October 2005, the federal goverment of Germany will be issuing
+eplectronic passports, containing digitally signed biometric information on the
+passport holder.  Those passports use RFID technology to communicate with the
+inspection system.
+</para>
+<para>
+In order to do security research on ePassports and RFID in general, the author
+of this paper has started a free implementation of the required RFID stack
+(librfid) and an ICAO MRTD verification application (libmrtd).
+</para>
+<para>
+This task can be compared to the task of developing a network driver, network
+stack and ssl-enabled ftp client just to be able to capture a ftp data session.
+Therefore progress of the librfid and libmrtd projects was quite slow.
+</para>
+<para>
+However, the project has by now reached a stage where it can actually do
+something reasonable: Reading and decoding data from an ePassport.
+</para>
+	</abstract>
+
+</articleinfo>
+
+<xi:include  href="rfid.xml"  parse="xml" xmlns:xi="http://www.w3.org/2003/XInclude"/>
+
+<xi:include  href="librfid.xml"  parse="xml" xmlns:xi="http://www.w3.org/2003/XInclude"/>
+
+<xi:include  href="mrtd.xml"  parse="xml" xmlns:xi="http://www.w3.org/2003/XInclude"/>
+
+<xi:include  href="libmrtd.xml"  parse="xml" xmlns:xi="http://www.w3.org/2003/XInclude"/>
+
+</article>
diff --git a/2005/rfid-lk2005/rfid.xml b/2005/rfid-lk2005/rfid.xml
new file mode 100644
index 0000000..84b384d
--- /dev/null
+++ b/2005/rfid-lk2005/rfid.xml
@@ -0,0 +1,504 @@
+
+
+
+<section>
+<title>Introduction into RFID</title>
+<para>
+During the last couple of years, various different sectors of industry and
+event government organizations started to advertise and deploy RFID technology.
+</para>
+<para>
+The RFID industry makes huge promises, according to which RFID will penetrate
+our everyday life in the very close future.  As an example, RFID is used in the
+ICAO-compliant electronic passports, for electronic ticketing in the public
+transport sector and for tickets to events such as the soccer world
+championships in 2006.  Studies have been performed on the feasability of putting
+RFID circuitry into every Euro bill. 
+</para>
+<para>
+Contrary to those industry promises, there is a growing opposition among civil
+liberties groups and the data protection community.  The fear of abuse of this
+technology to invade privacy even further is big. 
+</para>
+<para>
+The public debate on RFID is mostly on a very high and therefore abstract
+level.  Even within the technical community, there's a severe lack of knowledge
+when it comes to really understanding RFID.
+</para>
+<para>
+This article tries to give a technical introduction into RFID,
+summarizing what the author has learned throughout the last year during his
+research and development.
+</para>
+
+
+<section>
+<title>What is RFID?</title>
+<para>
+A lot of the ambuguity related to RFID comes from the unclear terminology.
+Strictly speaking, "RFID" means "Radio Frequency IDentification" and therefore
+refers to any technology facilitating identification of items using radio
+frequency.
+</para>
+<para>
+However, in reality the term "RFID" is used for meny different technologies and
+concepts. 
+</para>
+<para>
+Another frequent misconception is that most RFID systems in use today are based
+on standards.  To the opposite: In fact they're mostly proprietary systems
+produced by specific vendors, who obviously all proclaim to have invented an
+'industry standard".  Even those few RFID protocols that have been standardized
+by international standardization bodies such as ISO/IEC reflect the usual
+"either it's done way A, if not it's done way B" paradigm that seems to
+dominate the whole smart card industry.  But that's enough of a rant for now.
+</para>
+</section>
+
+<section>
+<title>Components of an RFID system</title>
+<para>
+A RFID system is usually composed of a reader device (which is always called
+reader, even if it can write) and some (RF)ID tag, sometimes referred to as
+transponder.
+</para>
+
+<section>
+<title>Tag (or Transponder)</title>
+
+<section>
+<title>1-bit Tags</title>
+<para>
+1-bit tags don't really provide any form of identification.  A 1-bit RFID
+system can only tell whether (at least) one tag is within reach of the reader.
+While this is quite limited, it still has one very popular application:
+Preventing theft of items from a store. 
+</para>
+</section>
+
+<section>
+<title>Serial Number Tags</title>
+<para>
+The most simplistic RFID systems come with read-only "serial number" tags.
+This basically means that the tag has a vendor-defined serial number (much like
+a barcode on product packaging), that can only be read.  Such systems generally
+don't employ any form of authentication.
+</para>
+</section>
+
+<section>
+<title>WORM Tags</title>
+<para>
+Instead of vendor-programmed serial numbers, WORM(write once read many) tags
+can be written once (usually at the customer site) and read many times.
+</para>
+</section>
+
+<section>
+<title>Read/Write Tags</title>
+<para>
+Read/Write tags can be read and written a large number of times.  r/w tags can be
+seen analogous to synchronous memory chip cards in the contact-based world.
+</para>
+</section>
+
+<section>
+<title>Read/Write with "passive" security</title>
+<para>
+This variant of tags employ read/writable memory plus some state machines that
+allow for (mutual) authentication of reader and tag, and/or encryption of the
+transferred data.
+</para>
+</section>
+
+<section>
+<title>Cryptographic Smartcards with RF Interface</title>
+<para>
+The lateset generation of "tags" are not really tags anymore, but rather
+cryptographic smart cards with an RF interface.   This means that you have a
+whole computer (sometimes called RFIC), including CPU, RAM, ROM, EEPROM,
+hardware random number generator, hardware crypto, etc. inside the "tag".
+Since such devices originate from the contact-based smart card world, they
+sometimes even are available as "dual interface smart cards", i.e. employ both
+contact-based and contactless (RFID) interface.
+</para>
+</section>
+
+</section>
+
+
+<section>
+<title>Reader</title>
+<para>
+Readers (sometimes called proximity coupling devices, PCDs) are usually
+connected to some computer or network, using standard interfaces such as RS232
+ports, serial interfaces, USB, or Ethernet.  Unfortuantely, there is no
+standard either on hardware nor on software level.  This means that most RFID
+applications will be written against specific vendor-rprovided driver or
+library API's.  
+</para>
+<para>
+There's one notable exception: Reader systems employing cryptographic
+smartcards with RF interface often emulate API's from the contact-based smart
+card world such as PC/SC or CT-API.
+</para>
+</section>
+
+
+<section>
+<title>RF Interface</title>
+<para>
+Between reader and tag there is some form of an RF interface.  The RF interface
+differs from system to system in many parameters, such as frequency,
+modulation and operational principle.
+</para>
+
+<section>
+<title>Magnetic Coupling</title>
+<para>
+Most of todays RFID systems use a magnetic coupling principle.  In such a
+system, the reader provides a strong magnetic field (H-field).  This field is
+picked up by the antenna of a tag, and used to power the tag.  Common
+frequencies for such magnetically coupled RFID systems are 125kHz and 13.56MHz.
+Magnetic systems often employ amplitude shift keying for the reader to tag
+communications channel, and load modulation from tag to the reader.
+</para>
+<para>
+The strong magnetic field only exists in the proximity of the readers' antenna.
+Thus, magnetically coupled RFID systems are sometimes referred to as "proximity
+or vicinity RFID", often with operational ranges less than 10cm.
+</para>
+<para>
+The remaining article will focus on magnetic coupling RFID systems only, since
+backscatter systems are not widely deployed yet, and therefore of little
+practical relevance.
+</para>
+</section>
+
+<section>
+<title>Backscatter</title>
+<para>
+A lot of RFID systems under current developemnt operate in the UHF frequency
+range (868 to 956 MHz, depending on the regulatory domain).  They use the
+electric field of the reader, and employ backscatter modulation from tag to
+reader.   The electrical field extends over longer distance than the magnetic
+field.  Therefore, the operational range of backscatter systems are within tens
+of metres.
+</para>
+</section>
+
+<section>
+<title>Surface Accoustic Wave</title>
+<para>
+SAW tags use low-power microwave radio signals.  The tag converts them to
+ultrasonic accoustic signals using a piezoelectric crystalline material.
+Variations of the reflected signal can be used to provide a unique identity
+such as a serial number.
+</para>
+</section>
+
+</section> <!-- rf interface -->
+
+</section> <!-- overview -->
+
+
+<section>
+<title>Protocols and Standards</title>
+<para>
+For the commonly-used 13.56MHz based systems, there are two major protocols in
+use, ISO 14443 and ISO 15693.  ISO 15693 seems only be used for "dumb" tag
+applications, whereas ISO 14443 is used frequently with RF interfaced processor
+smart cards.
+</para>
+
+<para>
+Besides the "physical layer" issues such as modulation, coding, bit timing,
+and frequency, there are some other important tasks of an RFID protocol.
+</para>
+
+<para>
+One of the funamental effects of RFID is the possibility of multiple tags
+within the operating range of a reader, just like in any other shared medium
+communication channel.
+</para>
+
+<para>
+In order to cope with multiple tags, an anticollision procedure has to be
+specifieid.  Some sophisticated protocols (as 14443-4 )even allow a reader to
+assign logical addresses to individual tags in order to communitace with
+multiple tags.
+</para>
+
+<section>
+<title>ISO 11784 / 11785</title>
+<para>
+The ISO 11784 / 11785 series of standards are used for identification of animals.
+This family of standards operates at 134,2 kHz and uses the magnetic coupling
+operational principle.  It uses load modulation with no subcarrier and employs
+a bi-phase-code for transmission of 64bit transponder data at 4194 bits/sec.
+</para>
+</section>
+
+<section>
+<title>ISO 14223</title>
+<para>
+ISO 14223 is an extension of 11784/11785 and allows for more data stored on the
+tag/transponder.
+</para>
+</section>
+
+<section>
+<title>ISO 10536</title>
+<para>
+ISO 10536 describes "close coupling" smart cards, with an operational range of
+up to 1cm.  It employs inductive or capacitive coupling at 4.9152 MHz. Due to
+this low operational range, they never appeared in widespread use on the market.
+</para>
+</section>
+
+<section>
+<title>ISO 14443</title>
+<para>
+ISO 14443 describes "proximity coupling identification cards".  As opposed to
+ISO 10536, this standard has an operational range of up to 10cm.
+</para>
+
+<para>
+ISO 14443 has two variants: ISO 14443-A and ISO 14443-B.  They both operate
+on the same frequency, but with different parameters.
+</para>
+
+
+<informaltable border="1" width="90%">
+  <tgroup cols="3">
+    <thead>
+      <row>
+        <entry>Parameter</entry>
+	<entry>ISO 14443-A</entry>
+	<entry>ISO 14443-B</entry>
+      </row>
+   </thead>
+   <tbody>
+<row><entry>Modulation Reader->Tag</entry><entry>100% ASK</entry><entry>10% ASK</entry></row>
+<row><entry>Modulation Tag->Reader</entry><entry>load modulation at 847kHz subcarrier, ASK</entry><entry>load modulation at 847kHz subcarrier, BPSK</entry></row>
+<row><entry>Code Reader->Tag</entry><entry>Modified Miller</entry><entry>NRZ</entry></row>
+<row><entry>Code Tag->Reader</entry><entry>Manchester</entry><entry>NRZ</entry></row>
+<row><entry>Anticollision</entry><entry>Binary Search</entry><entry>Slotted ALOHA</entry></row>
+   </tbody>
+  </tgroup>
+</informaltable>
+
+<para>
+ISO 14443-4 specifies an (optional) transport level protocol on top of the lower
+three layers of the ISO 14443 protocol.  This transport protocol is sometimes
+referred to as "T=CL" (transport=contactless).  This designation bears its
+origin in the smart card world, where other protocols such as "T=0" and "T=1"
+are in widespread use for decades.
+</para>
+<para>
+The remaining paper will mostly look at ISO 14443, since it is in widespread use
+today and also used by the electronic Passport system specified by ICAO.
+</para>
+</section>
+
+<section>
+<title>ISO 15693</title>
+<para>
+ISO 15693 describes "vicinity coupling" RFID, with an operational range of up
+to 1m.  Like ISO 14443, it operates on 13.56 MHz and employs magnetic near-field
+inductive coupling.
+</para>
+<para>
+This standard again supports various modes, such as 10% or 100% ASK, 1.65kb/s
+or 26.48kb/s data rate, ASK or FSK based load modulation.
+</para>
+<para>
+Given the big distance between reader and tag, it is very unlikely that high
+power consumption processor smart cards will be developed for this standard.
+</para>
+</section>
+
+<section>
+<title>ISO 18000 series</title>
+<para>
+This ISO series is under current development.  It intends to specify unique
+world wide standards for item management.  Specifications include operation
+on 13.56MHz, 2.45GHz, 5.8GHz and the 868 to 956 MHz UHF band.
+</para>
+</section>
+
+</section>
+
+
+
+
+<section>
+<title>A closer look on Readers</title>
+<para>
+There's a variety of readers for the 13.56MHz world, ranging from embedded
+reader modules to PC-connected readers for USB and serial connections,
+Ethernet-connected readers as well as readers for handheld devices with
+CompactFlash interface.
+</para>
+
+<para>
+As opposed to the contact-based smartcard world where most readers now support
+the USB CCID standard (to my surprise even non-usb devices!), there is no
+standardization.  Neither does any of the readers - to the best of the authors'
+knowledge - have any publicly and/or freely available documentation.  A similar
+lack is observed for Linux drivers.  If they are available, then often for an
+extra charge, and in proprietary x86-only format.
+</para>
+
+<para>
+On the electrical level, a lot of readers are surprisingly equal.  Almost all
+of them seem to use readily available "reader ASICs" of vendors such as TI or
+Philips.  Those ASIC's usually integrate both the analogue RF part (including
+modulation/demodulation) and the digitial part.  They are interfaced by serial
+(SPI) or parallel address/data bus.  As you could have guessed by now, there's
+again no publicly/freely available documentation on any of the chipsets.
+</para>
+
+<para>
+After doing some research and re-engineering on commonly-available existing
+readers, there seems to be a two different basic architectures:
+</para>
+
+<section>
+<title>Active Readers</title>
+<para>
+Active readers do all the 14443/15693 processing within a microcontroller of
+the reader.  Advantages of an active design are low latency, high speed and
+applicability in embedded or remotely connected environments where no host
+computer could do protocol processing.
+</para>
+</section>
+
+<section>
+<title>Passive Readers</title>
+<para>
+Passive readers simply include the most basic logic to interface the reader
+ASIC with the external interface.  Therefore all protocol processing has to be
+done on the host system.
+</para>
+<para>
+For obvious reasons, the passive architecture allows for cheaper development
+and total product cost.  The author anticipates that all PC-based readers will
+eventually become passive.  A commonly-available passive reader (Omnikey
+CardMan 5121) was chosen for the development of librfid.
+</para>
+</section>
+
+
+<section>
+<title>Omnikey CardMan 5121</title>
+
+<para>
+On the first glance, the cm5121 is a USB CCID contact based smartcard reader.
+It can be used with vendor-supplied proprietary drievers, or with various
+freely available CCID reader drivers, such as the OpenCT project.
+</para>
+<para>
+However, the RFID part is simply a Philips CL RC632 reader asic that can be
+accessed transparently by issuing read/write_byte and read/write_fifo commands
+via CCID PC_to_RDR_Escape usb messages.
+</para>
+<para>
+The author further obtained a (publicly available, but encrypted) detailed data
+sheet of the Philips CL RC632 reader asic, which magically decrypted itself by
+using a couple of days worth of CPU power.
+</para>
+<para>
+The CL RC632 is a multi-protocol reader asic, supporting 14443-A, 14443-B,
+15693 as well as the proprietary 14443A-based Mifare system.
+</para>
+<para>
+Using the data sheet, a free and GPL licensed RFID stack could be implemented
+from scratch.
+</para>
+</section>
+
+</section> <!-- closer look on readers -->
+
+
+<section>
+<title>Security Issues</title>
+
+<section>
+<title>Eavesdropping</title>
+<para>
+Like any RF interface, the magnetic RFID interface can be passively sniffed.
+Due to the use of the H-field in 125kHz and 13.56MHz systems, the possible
+surveillance range is very slow.   Also, given the enormous power constraints
+within the tag, the power put into the tag->reader channel is very low.
+Furthermore, the main carrier and the subcarrier are very close in the radio
+spectrum - while their signal strength differs some 60 to 80 dB.
+</para>
+
+<para>
+Measurements conducted by the author do not suggest that passive surveilance of
+ISO 14443 compliant systems is not possible outside a range of 4-5 metres - at
+least not with DIY equipment.
+</para>
+</section>
+
+<section>
+<title>Denial of Service</title>
+<para>
+ISO 14443-A and -B anticollision systems are subject to denial of service
+attacks. 
+</para>
+<para>
+For 14443-A, such an attack could simply cause one collision for every bit in
+the address, thus preventing the reader to complete its binary search algoritm
+and fully select one of the available tags.
+</para>
+<para>
+There have already been public demonstrations of "blocker tags" which employ
+such a technique to prevent other tags in the vicinity of the blocker tag from
+being read.
+</para>
+</section>
+
+<section>
+<title>Authenticity/Confidentiality</title>
+<para>
+ISO 14443-A doesn't provide any form of security.  Any kind of authentication
+and/or encryption has to be employed at a higher level, such as ISO 7816 secure
+messaging.  Compare the system with a TCP/IP stack (level 1..4) with SSL/TLS on
+top.
+</para>
+</section>
+
+<section>
+<title>Proprietary Security</title>
+<para>
+The security of vendor-speciifc proprietary systems such as Mifare are based on
+security by obscurity.  The encryption alogorithm is not publicly documented,
+and only implemented in vendor-supplied hardware, usually the reader ASIC and
+inside the tag itself.  Keys are stored on the tag and in the reader ASIC.
+</para>
+<para>
+Security by obscurity within the software industry generally doesn't work.
+However, in the hardware world vendors still seems to assume it as a valid
+paradigm.
+</para>
+<para>
+The key lengths used in many proprietary systems seem extermely small (40bit,
+sometimes even only 24 bit).  Should the algorithm ever be uncovered, it is
+expected to compromise the security of the whole system.  The arithmetic
+complexity of the algorithm can only be low, given it's implementation in
+lowest-cost state-machine-only tags.  Therefore it is expected that once
+somebody has performed the difficult task of re-engineering a reader ASIC, the
+system security will be compromised.
+</para>
+<para>
+Brute-force attacks on tags themselves seem very unlikely, due to the extremely
+slow hardware.   However, after a successful (legitimate) conversation between
+reader and tag has been sniffed, brute forcing can be done on fast computers.
+</para>
+</section>
+
+</section> <!-- security -->
+
+</section> <!-- rfid -->