NFC - Near Field Communication nach ISO14443

Die Nahfeldkommunikation (NFC - Near field communication) als Spezialform von RFID (Radio Frequency Identification) hat in den letzten Jahren Einzug in viele Bereiche des Alltags genommen und NFC findet inzwischen auch als zusätzliche Funktion von Smartphones Verwendung. Die ersten Android-Handys mit NFC-Unterstützung gibt es seit Anfang diesen Jahres und auch andere Kartenleser sind inzwischen preiswert erhältlich.

Bereits in den 1990er Jahren wurde der Mifare-Standard entwickelt und erlangte, nachdem Philipps Semiconductors (seit 2006 NXP) die Entwicklerfirma 1995 kaufte, eine enorme Marktdurchdringung in verschiedenen Anwendungsbereichen (z.B. Zutrittserfassung, Studentenausweise, Mensacards, Einweg-Fahrscheine, …). Die Massenproduktion der Mifare-Chips sorgte durch die Produktion von inzwischen mehreren Milliarden Stück schnell für günstige Preise. Eine einfache Mifare-1k-Karte mit 1kB Speicher bekommt man selbst in kleinen Stückzahlen für ca. 2 USD zu kaufen.

Neben Mifare gibt es zahlreiche weitere Lösungen am Markt, an denen niemand auf lange Sicht herum kommt. So wird der deutsche Reisepass schon seit 1. November 2007 mit NFC-Chip produziert und auch der zum 1. November 2010 eingeführte neue Personalausweis der BRD bietet zusätzliche (verschlüsselte) Daten via NFC. Die Bundesrepublik ist damit jedoch bei weitem nicht das einzige Land, welches NFC als zusätzliches und schwer fälschbares Sicherheitsmerkmal in Ausweisdokumente eingeführt hat.

Bereits vor einigen Jahren gab es die ersten Handys mit NFC-Unterstützung und seit Anfang diesen Jahres auch Android-Modelle, wobei hier vorrangig die bargeldlose Bezahlung das Ziel ist. NFC kann, z.B. ergänzt durch zusätzliche optische Kommunikation, eines Tages durchaus einen sicheren Ersatz für Geldkarten darstellen. Das Anwendungsgebiet der NFC-Bezahlsysteme konnte sich im Gegensatz zum asiatischen Raum in der Bundesrepublik bisher von Pilotprojekten abgesehen noch nicht durchsetzen. Das wohl derzeit größte deutsche Pilotprojekte “funkender Bezahlsysteme” dürfte das der Deutschen Bahn (Touch & Travel) sein. In diesem Anwendungsfall lassen sich selbige Funktionen allerdings mittels Smartphone und GPS auch ohne NFC nutzen. Etwa seit 2005 ist in der Bahn-Card 100 ein RFID-Chip enthalten, der auch für Mietwagen Verwendung findet - wegen unzureichender Kundeninformation bekam die Bahn dafür im Jahr 2007 den Big Brother Award. Zu diesem Zeitpunkt staubte selbiger bei der Metro bereits ein, denn dort fand der erste Feldversuch mit RFID-Metro-Karten ohne Kundeninformation bereits 2003/2004 statt.

Eines der größten Probleme, welches auch gerne von Datenschützern vorgetragen wird, ist die Tatsache, dass mittels der dabei eingesetzten RFID-Chips eine (theoretisch) eineindeutige Zuordnung möglich ist, da die meisten Chips eine fest eingebrannte einmalige UID enthalten. Lediglich teurere Chips verwenden dynamische UIDs. Auch viele der ganz simplen Warensicherungen (typische Klebe-/Steck-/Hartsicherungen) stellen kein Datenschutzrisiko dar, da diese von ihrem “binären” Resonanzschwingkreis abgesehen über keinerlei auslesbare Daten verfügen.

Die Nahfeldkommunikation ohne (sichere) Verschlüsselung birgt einige Sicherheitsrisiken, da mit einer entsprechend dimensionierten Antenne und zugehörigem Leser eine Kommunikation unbemerkt mitgeschnitten werden kann. Auch ein aktives Auslesen ist in gewissen Grenzen möglich. Im Fall der weit verbreiteten Mifare-Classic besteht obendrein das Problem, dass der dort verwendete proprietäre Cryptoalgorithmus, der Stromchiffre Crypto-1, offiziell bereits im Jahr 2008 gehackt wurde. Damit ist es möglich, innerhalb weniger Sekunden auch verschlüsselte Bereiche auszulesen. Nutzt man ein hinreichend großes Feld und befinden sich nur wenige (idealer Weise nur die eine gewünschte) Karte(n) in diesem Feld, so kann man durchaus auch aus einigen Metern Entfernung den Inhalt der Karte auslesen und vollständig kopieren - im wahrsten Sinne des Wortes im Vorbeigehen. Hierzu wird neben der NFC-Hardware lediglich ein schneller Prozessor (z.B. ein FPGA) benötigt, der den Schlüssel schnell genug geknackt bekommt, um mit nur minimaler Verzögerung an die nur mit dem richtigen Schlüssel lesbaren Bereiche heranzukommen. Auch die für jeden Chip eindeutige UID stellt kein Hindernis dar. Zwar lässt sich durch deren Einzigartigkeit eine Karte nicht direkt kopieren, allerdings bieten viele für Smartcardreader produzierte NFC-Chips die Möglichkeit, eine Karte zu simulieren und spätestens an der Stelle kann man ansetzen, um die UID der Originalkarte nebst Inhalt als echten Clone zu verwenden.

Mit Hilfe geeigneter Schutzhüllen lässt sich ein unbefugtes Auslesen der Inhalte eindämmen. Für sicherheitsrelevante Bereiche kann man auch mittels einer zweiten Identifikation einen möglichen Mißbrauch weitgehend verhindern. Dafür werden z.B. bei Zutrittskontrollen oftmals Tastenfelder zur zusätzlichen Codeeingabe verwendet. Für die Zukunft halte ich, wie schon oben kurz erwähnt, als zusätzlichen Sicherheitskanal die optische Kommunikation für besonders vielversprechend. Einsatzmöglichkeiten sind hier verschiedene denkbar: Man kann entsprechend dem Stand der Technik schlicht auf dem Display eines Smartphones Bilder anzeigen und diese mittels einer Kamera auslesen und gemeinsam mit den NFC-Daten auswerten lassen. Etwas futuristischer aber technisch auch heute schon realisierbar wären 3D-Fotos (besser noch 3D-Scans) der Person, die gerade das NFC-Gerät nutzt. Diese Daten bieten spätestens in Verbindung mit Wärmeprofilen eine sehr hohe Manipulationssicherheit bei der Gesichtserkennung. Eine einfache Kamera mit Vergleich eines zweidimensionalen statischen Bildes hingegen wäre zu einfach mit einem Foto zu überlisten. Auch eine ergänzende akustische Kommunikation oder eine zusätzliche Funkverbindung z.B. via Bluetooth kann weitere Sicherheit selbst beim Einsatz der für sich genommen nicht mehr sicheren Mifare-Classic-Cards bieten.

Der wichtigste NFC-Standard ist in den Regelwerken nach ISO/IEC 14443, meist kurz nur als ISO14443 bezeichnet, definiert. Die Verbreitung der Mifare-Classic-Familie trug und trägt immer noch entscheidend dazu bei, dass dieser ISO-Standard der wichtigste im NFC-Bereich ist. Auch die deutschen Ausweisdokumente arbeiten grundlegend (bis zur Schicht 3) nach diesen Standards, weshalb man zumindest den Verbindungsaufbau (UID-Abfrage, Anticollision-Loop) ebenso leicht durchführen kann, wie bei einer Mifare-Karte. Der ISO14443 liegen die ISO7816-Normungsreihe über kontaktbehaftete Chipkarten und die Definitionen zur Datenübertragung bei der Near Field Communication aus ISO18092 sowie ISO21481 zu Grunde. Die ISO18092 NFC - Interface and Protocol (NFCIP-1) definiert absolute NFC-Grundlagen und die ISO21481 (NFCIP-2) bildet eine Art Schnittstelle zwischen der ISO18092 und der ISO14443. Bei der Arbeit mit Smartcards und Readern genügt meist jedoch die Kenntnis der ISO14443. Die gängigste Form ist die als Scheckkarte bekannte ID-1-Card, deren einfachste physikalische Eigenschaften, wie bspw. die Größe, bereits in der ISO/IEC 7810 definiert sind. Auch die ISO14443-1 verweist dorthin, ergänzt um spezifische Eigenschaften von Chipkarten. Für Testverfahren ist auch die ISO/IEC 10373 von Relevanz. Es gibt aber noch weitere ISOs (z.B. ISO23917 Protocol Test Methods, ISO22536 RF Interface Test Methods), die sich mit dieser Thematik befassen.

Die Wikipedia fasst die ISO14443-Reihe sehr übersichtlich wie folgt zusammen:

Innerhalb der Norm wird die Leseeinheit als PCD (proximity coupling device) und die Karte als PICC (proximity integrated circuit card) bezeichnet. […] Die Normenreihe Identification cards — Contactless integrated circuit cards besteht aus folgenden Teilen:

  • Teil 1: Physical characteristics (2008, Erstausgabe 2000)
  • Teil 2: Radio frequency power and signal interface (2010, Erstausgabe 2001)
    • Typ A: Bei diesen Karten wird für den Downlink (PCD -> PICC) 100% ASK (amplitude shift keying) mit modifizierter Millercodierung verwendet. Für den Uplink (PICC -> PCD) kommt Lastmodulation mit ASK-moduliertem 847,5kHz Hilfsträger in Manchestercodierung zum Einsatz.
    • Typ B: Als Modulationsverfahren für den Downlink (PCD -> PICC) wird hier 10% ASK (amplitude shift keying) mit NRZ (non return to zero) Codierung verwendet. Der Uplink (PICC -> PCD) ist als Lastmodulation mit BPSK (binary phase shift keying) moduliertem 847,5kHz Hilfsträger in NRZ-Codierung realisiert.
  • Teil 3: Initialization and anticollision (2008, Erstausgabe 2001)
  • Teil 4: Transmission protocol (2008, Erstausgabe 2001)

Während Mifare Classic ausschließlich den Typ A (alias: ISO14443A) nutzt, werden beim deutschen Personalausweis teilweise auch Typ-B-Chips eingesetzt. Da entsprechende PCD-Chips die Kommunikation übernehmen, muss man sich in der Regel nicht um die Modulation kümmern. Jedoch ist der Kommunikationsaufbau beim Typ B deutlich komplizierter und wird von einigen (älteren) NFC-Reader-Chips nicht unterstützt.

Viele der großen Chiphersteller produzieren eigene NFC-Chips für PCDs. Einige Beispiele dafür sind: NXP RC530/PN532/PN544/RC632/PN65/CLRC663, Infineon SLE 66/77/78, Samsung SENHRN1, Broadcom BCM2079x, STMicroelectronics ST21NFCA - diese kleine Auswahl war mittels Suchmaschine in kurzer Zeit auffindbar. Bei intensiverer Recherche sollten sich noch einige weitere finden lassen. Wer einen eigenen Reader bauen möchte, wird ohnehin allein für die Suche nach dem “richtigen” Chip, der alle geforderten Standards unterstützt und möglichst einfach zu handhaben ist, reichlich Zeit investieren müssen.

Ein simpel aufgebauter und mit knapp 30 USD extrem günstiger Reader mit OpenSource-Bibliothek wird von SeeedStudio als NFC Shield für Arduino vermarktet. Inklusive einem passenden Arduino-Board erhält man so für unter 50€ einen einfachen Smartcard-Reader. Allerdings bietet die verfügbare Arduino-Bibliothek zum dort verwendete NXP-Chip PN532 nur Unterstützung für ISO14443A und Mifare-Karten. Die Firmware des Chips bietet hingegen schon seit längerem auch ISO18092 (aktiv/passiv) und ISO14443B. Für den im asiatischen Raum weit verbreiteten Kartenstandard Felica benötigt man ISO18092. Der PN532 kann auch Karten in verschiedenen Modi emulieren. Mehr dazu in einem folgenden Artikel.

Der Verbindungsaufbau und die weitere Kommunikation nach ISO14443 finden wie im folgenden Schema dargestellt statt:

State Machine nach ISO 14443-A

Quelle: Diplomarbeit von Henryk Plötz S.11

Das AC in der Abbildung steht für die Anticollision-loop, welche dazu dient, die gewünschte PICC zu selektieren. Befindet sich nur eine PICC im Feld, erhält man unmittelbar die UID zurück, sind allerdings mehrere PICCs im Feld, so muss man sich mittels eines Binärfilters zur gewünschten PICC schrittweise durcharbeiten. Zwei Karten sind im Normalfall kein Problem, bei drei Karten kommt es je nach Position der Karten im Feld hingegen oft schon zu Problemen, die ein Selektieren unmöglich machen. Detaillierte Informationen zum Kommunikationsaufbau findet man in der ISO14443-3 (englisch) auf den Seiten 6-18 oder der Diplomarbeit (deutsch), aus welchem das obige Schema entnommen wurde, auf den Seiten 10-15. In der ISO-Spezifikation wird detaillierter auf kaskadierte UIDs eingegangen. Auch im Anschluss an das nächste Beispiel finden sich einige Erklärungen hierzu.

Im einfachsten Fall findet eine Selektion mittels folgender Schritte statt:

Sender Wert in hex Bedeutung
Reader 26 REQA - Request type A
PICC 04 00 ATQA - Answer to Request A
Reader 93 20 SEL - Select, Beginn der Antikollision
PICC 11 22 33 44 16 hier 4 Byte UID + 1 Byte BCC, keine Kollision
Reader 93 70 11 22 33 44 16 xx xx SEL UID (xx steht für den CRC_A)
PICC 08 B6 DD SAK - Select acknowledge

Bei den meisten SmartCards ist ATQA = 0×0400. Entsprechend der Bit frame anticollision können je nach Karte aber auch andere Werte (genau 1 Bit aus den Bits 1-5, also z.B. 0×0800) zurückgeliefert werden. Außerdem sollten PICCs mit 7 bzw. 10 Byte UID die Bits 7/8 dem Standard entsprechend setzen. Wichtiges Detail hierbei ist die Tatsache, dass in sämtlichen Dokumentationen zu diesem Thema analog zur ISO die Zählung von Bits IT-untypisch bei 1 beginnt und nicht bei 0, während im Gegensatz dazu die UIDx-Zählung bei 0 beginnt. Wer Tiefergehendes direkt in der ISO nachlesen möchte, sollte auch beachten, dass dort die grafische Darstellung mittels MSB/LSB andersherum erfolgt, also als 00 04.
Die bei der UID-Übermittlung übertragene BCC-Checksumme ist ein einfaches XOR der ersten vier Bytes, also mit Hilfe folgender simpler Routine überprüfbar:

unsigned char d[256];  // Achtung bei extended APDUs!
unsigned char CheckBCC(void){
 return d[0]^d[1]^d[2]^d[3]^d[4];
}

Falls es zu einer Kollison gekommen ist, muss die bereits erwähnte Anticollision-loop hier einsetzen. Dabei wird für die UID1 weiterhin die 0×93 gesendet, gefolgt von 0×20 + Bit-Position der Kollision und darauf folgend müssen die bekannten Bits (also exakt die Anzahl der mittels der Bit-Position definierten Bits) übertragen werden. Hat man die vollständige UID ermittelt, so erfolgt die Aktivierung der zugehörigen PICC wie in Zeile 5 zu sehen mittels 0×93 70 [4 UID-Bytes] [2 CRC-A-Bytes].
Falls die UID damit allerdings nicht vollständig ist, gibt die PICC ein Kaskade-Bit (SAK-Bit3=1) zurück, wodurch unter Umständen die Anticollision-loop auch noch auf die anderen beiden Kaskadelevel angewendet werden muss. Werden lange UIDs verwendet, so erfolgt die Definition des gerade übertragenen Kaskade-Levels mittels eines modifizierten SEL-Bytes. Hierbei entspricht das erste Level dem bereits bekannten 0×93, das zweite Level wird mit 0×95 und das dritte Level mit 0×97 ausgewählt. Bei einer standardkonformen Implementierung ist die UID-Länge bereits aus der ATQA ablesbar und weiterhin sollte außer im letzten Kaskadelevel das erste Byte stets 0×88 sein. Dieses Byte wird nicht zur eigentlichen UID hinzugezählt, fließt aber in die BCC-Checksumme ein. Dadurch bedingt ergeben sich bei jeweils fünf übertragenen Bytes die Gesamtlängen der möglichen UIDs mit (3+ (3+)) 4 Bytes, wodurch Werte von 4, 7 und 10 Bytes Länge möglich sind. Eine weitere vordefinierte Besonderheit für single-size-UIDs hat man für den Fall UID0=0×08. Dafür ist definiert, dass die UID1-UID3 dynamisch generiert werden, was z.B. bei unseren neuen Ausweisdokumenten der Fall ist.
Die Verbindungsbestätigung SAK ist bei Mifare-One-Karten wie im obigen Beispiel 0×08 (nicht kompatibel zu ISO14443-4) mit der CRC-A-Checksumme 0xB6DD. Für Mifare-Classic/Plus-Karten mit 4kB ist der SAK-Wert 0×18 mit entsprechendem CRC-A. Der CRC-A berechnet sich mittels des Polynoms x^16 + x^12 + x^5 + 1 mit dem Startwert 0×6363. Implementierungsbeispiele sowohl für Typ-A als auch für Typ-B finden sich in der ISO14443-3 und überall im Netz.
Mit dem SAK und Bit3=0 geht die PICC vom Status Ready in den Status Active über. Ist das Bit6=1, so entspricht die PICC dem Standard ISO14443-4, sonst nicht.

Anschließend kann man mittels entsprechender APDUs Daten aus der Karte lesen oder in sie hineinschreiben.

Eine Reaktion zu “NFC - Near Field Communication nach ISO14443”

  1. admin

    Quellen:

    • NXP (verschiedene Datenblätter; u.a. zum PN532, und zu MIFARE Classic/Pro)
    • Diplomarbeit von Henryk Plötz, Humboldt-Universität zu Berlin, Thema Mifare Classic – Eine Analyse der Implementierung (10/2008)
    • Emanuel Koziolek, Uni Freiburg, Thema Sicherheitsaspekte von RFID am Beispiel von Mifare (07/2011)
    • ISO14443-3
    • Wikipedia
    • diverse Googleanfragen (meist reicht die Vorschauübersicht für nötige Infos)

    Update, weiterführende Artikel:

    • Arduino NFC Shield - SmartCardReader mit Bibliothek für Mifare Classic nach ISO/IEC 14443-A; Erweiterung auf ISO/IEC 14443-B und ISO/IEC 18092 (also auch FeliCa) ist seitens der Firmaware des NFC-Chips möglich

Einen Kommentar schreiben