diff options
Diffstat (limited to '2005/rfid-ccc_ds2005/rfid-datenschleuder-gliederung.txt')
| -rw-r--r-- | 2005/rfid-ccc_ds2005/rfid-datenschleuder-gliederung.txt | 145 |
1 files changed, 145 insertions, 0 deletions
diff --git a/2005/rfid-ccc_ds2005/rfid-datenschleuder-gliederung.txt b/2005/rfid-ccc_ds2005/rfid-datenschleuder-gliederung.txt new file mode 100644 index 0000000..05646e2 --- /dev/null +++ b/2005/rfid-ccc_ds2005/rfid-datenschleuder-gliederung.txt @@ -0,0 +1,145 @@ + +- different types of RFID + - serial-number-only + - read/writeable memory + - read/writeable memory with authentication + - processor chip cards (like contact-based) + +- physical/electrical characteristics + - old 125kHz systems + - current 13.56MHz systems + - ISO 14443-A + - ISO 14443-B + - ISO 15693 + - both 125kHz and 13.56MHz are magnetic H-field systems + - reader provides strong magnetic field to provide power to PICC + - data from reader to PICC is modulated onto carrier. + - PICC uses load modulation to send back replies to reader + +- ISO 14443 + - 14443-1 + - defines physical layer (e.g. field strength, ...) + - 14443-2 + - 14443-3 A + - 100% ASK from reader to PICC + - binary search tree anticollision + - 14443-3 B + - 10% ASK from reader to PICC + - slotted aloha anticollision + - 14443-4 + - also called T=CL + - datagram-based transport protocol + - handles retransmission, ack/nack + - optional signal strength signalling + - data rates between 106 and 848 kbps + +- Mifare + - proprietary system by philips + - requires philips circuits in tag and reader + - authentication using two 40bit? keys + - proprietary encryption algoritm + - brute-force of 40bit not possible due to slow devices + +- ISO 15693 + - only used by tags, not by smart cards + +- STm + +- Legic + +- Available readers + - generally based on either Philips or STM reader ASIC + - reader ASIC integrates analogue RF and digital part + - typically offer SPI and/or parallel bus interface + - host interface either serial or USB (planned: ethernet, see also + IETF working group on this subject) + - serial readers speak either proprietary protocol or sometimes + emulate serial contact-based readers for 14443-4 (T=CL) + - stupid readers + - only connect reader ASIC to host pc + - protocol stack implemented on host pc + - intelligent readers + - handle protocol stack in firmware of microcontroller in the + reader + - sometimes even parts of the application are embedded in the + reader firmware + - problem: often only support very specific + protocols/applications + +- librfid + - implements 14443-1234 and 15693 stack + - has hooks for mifare and other proprietary RFID protocols + - implements fairly generic driver for Philips CL RC632 ASIC + - currently only supports Omnikey CardMan 5121 + - currently only offers non-standard API for higher-level apps + - scheduled to provide OpenCT backend (OpenCT supports CT-API and PC/SC) + +- Problems + - T=CL looks almost like a layer 4 network protocol, 14443 supports + operation of multiple PICC's simultaneously (by using CID + addressing). Therefore it looks like a master/slave network + protocol. + - Current API's for contact based cards (like PC/SC) cannot deal well + with multiple PICC's coming and going. + +- Passive Sniffing of 14443 + - dream: ethereal-like program for RFID + - h-field decreases tremendously with distance + - h-field antennas required + - reader -> picc signal strong and easily detected, beyon 10m + - picc -> reader signal very weak (60-70dB below reader->picc). so far + barely recognizable beyond 3m, even with 1m-loop-antenna + - various hardware approaches + - using software defined radio (gnuradio) + - quite expensive, unless you happen to already have one + - flexible, since everything can be done in software + - gnuradio-implementation of 14443 on my TODO list + - using dedicated demodulation hardware + - way cheaper than SDR + - 13.56MHz low enough for DIY-hardware + - under development by Milosch + - using existing reader ASIC, put it in read-only mode + - might be feasible, but operation is unlikely due to + lack of phase and clock synchronization with external + source + +- ICAO compliant MRTDs + - ICAO already regulates MRZ on current travel documents in Doc 9303 + - Working group created standards for new MRTD with biometric data + - Specifications publicly available + - 14443 A or B PICC + - ISO 7816-4 (inter-industry commands) + - LDS (Logical Data Structure) + - DG1 + - data as printed on passport + - DG2 + - facial JPEG, min 80pixels between eyes + - EF.SOD + - signature of DG1, DG2 + - DG_FIXME + - optional fingerprint data + - Security + - passive auth + - basic access control + - prevents unauthorized reading by refusing + access until key derived from MRZ is + presented to PICC + - probably weak, since key is derived only from + DOB, document expiry date and document number + - provides session key generation for SM + encrypted transport layer + - active auth + - TR-PKI + - each country operates its own root CA + - intermediate document signer certificates + - country root certificates available via public LDAP + - certificates of all recognized countries need to be + stored in every inspection system + - certificate chain of EF.SOD signature can be verified + - specifies CRL polling intervals, etc. + +- libicao + - aims to implement all required functions for access to ICAO MRTD + - basic access control present, but no secure messaging yet + - can use OpenCT or PC/SC as underlying API + |