Auf einen Blick
Für Migrationen oder neue HF-Architekturen. Nicht ohne Prüfung von Lesern, Schlüsseln und Software migrieren.
Drei Punkte vor der Entscheidung:
- von Bestandslesern unterstützte Modi
- Sektor-, Applikations- und Schlüsselstruktur
- Pilotmigration bei weiterlaufendem Altbestand
Der grundlegende Unterschied liegt nicht nur im Algorithmus: hier Sektoren und Blöcke, dort Applikationen und Dateien mit getrennten Rechten. Eine Migration erfasst Leserbestand, Schlüsselstrategie, Personalisierung und Ausgabesoftware. Eine Pilotgruppe wird getestet, während ein Rückweg in den Altbestand erhalten bleibt.
Sektoren und Blöcke gegen Applikationen und Dateien
Die erste Familie teilt ihren Speicher in feste Sektoren. Bei der verbreiteten 1-KB-Variante sind es 16 Sektoren mit je vier Blöcken zu 16 Byte; der letzte Block jedes Sektors enthält zwei Schlüssel mit je 48 Bit und die Zugriffsbits. Das proprietäre Verschlüsselungsverfahren gilt seit Langem als gebrochen, Inhalte lassen sich daher mit verbreiteten Werkzeugen kopieren. Die zweite Familie organisiert ihren Speicher in Applikationen mit eigenen Schlüsseln und mehreren Dateien, darunter Wertdateien und zyklische Protokolldateien. Sie authentifiziert mit 3DES oder AES-128 und kommuniziert nach ISO/IEC 14443-4.
Eine Anwendung der ersten Familie kennt also eine Sektornummer und einen Schlüssel, eine Anwendung der zweiten eine Applikationskennung, eine Dateinummer und Zugriffsrechte je Datei. Software, die fest auf Sektoren programmiert ist, kann die zweite Familie deshalb nicht einfach mitlesen, auch wenn der Leser beide Kartentypen erkennt.
Was wir für die Vorkodierung in der Fertigung brauchen
Beide Familien personalisieren wir auf Wunsch schon in der Produktion. Für die erste genügen Sektorbelegung, Schlüssel, Zugriffsbits und die Daten je Karte. Für die zweite legen wir Applikationen nach einer Spezifikation mit Applikationskennung, Dateistruktur, Zugriffsrechten und Schlüsselnummern an; zum Schluss wird der Kartenhauptschlüssel auf den Wert des Betreibers oder einen vereinbarten Transportschlüssel geändert. Schlüssel übernehmen wir verschlüsselt und getrennt von den Kartendaten.
Die zweite Familie kann eine bei jeder Anfrage wechselnde Zufallskennung ausgeben. Anlagen, die bisher nur die UID auswerten, erkennen solche Karten nicht mehr. Soll die feste UID weiter genutzt werden, bleibt diese Option in der Fertigung deaktiviert, und wir vermerken das in den Lieferunterlagen, damit spätere Nachbestellungen gleich konfiguriert werden.
Beide Familien im selben Ausweisbestand unterscheiden
Während einer Umstellung liegen Karten beider Familien oft nebeneinander im Ausweisschrank und sehen äußerlich gleich aus. Auf Wunsch versehen wir die neuen Karten mit einem abweichenden Farbfeld im Druckbild oder einem eigenen Nummernkreis, damit Ausgabe und Rücknahme sie ohne Leser unterscheiden und die Verwaltungssoftware sie filtern kann. Für Besucher- und Ersatzkarten, die an beiden Leserarten funktionieren müssen, sind Kombikarten mit zwei getrennten Chips möglich.
Alt bewährt gegen neu strukturiert
Dieser Vergleich steht in vielen Projekten für eine Grundsatzfrage: beim einfachen, weit verbreiteten Bestandstyp bleiben oder auf die stärker strukturierte, moderner abgesicherte Familie wechseln. Die Antwort hängt weniger am Datenträger als an Lesern und Software – beide müssen den moderneren Typ vollständig unterstützen, sonst bleibt sein Mehrwert ungenutzt.
Ein pragmatischer Mittelweg ist die vorbereitete Migration: Neue Leser beherrschen beide Typen, Neuausgaben erfolgen bereits im Zielformat, Altbestand läuft kontrolliert aus. So wird aus der Systemfrage ein Zeitplan statt eines Stichtagsrisikos.



Primärquellen
Marken. MIFARE und DESFire sind eingetragene Marken von NXP B.V. MIFARE und MIFARE Classic sind Marken von NXP B.V.
Die Namen dienen ausschließlich der technischen Bauteilbezeichnung. Eine Verbindung, Lizenz oder Freigabe durch NXP wird nicht beansprucht.
Häufige Fragen
Kann ein Leser beide Kartenfamilien parallel verarbeiten?
Viele aktuelle 13,56-MHz-Leser beherrschen beide, entscheidend ist aber die Firmware und die Konfiguration. Der Leser muss für die erste Familie Sektoren mit 48-Bit-Schlüsseln und für die zweite Applikationen mit AES-Schlüsseln lesen dürfen. Prüfen Sie am Gerät, welche Kartentypen freigeschaltet sind, bevor gemischte Bestände ausgegeben werden.
Warum erkennt der Leser die neue Karte, die Software findet aber keine Daten?
Der Leser meldet zunächst nur die Kennung. Sucht die Software anschließend einen bestimmten Sektor, findet sie auf einer Karte mit Applikationsstruktur nichts, weil dort Daten unter Applikationskennung und Dateinummer liegen. Die Software braucht dann eine Anpassung auf das Applikationsmodell oder die Karte eine Applikation, die genau diese Daten bereitstellt.
Kann eine Karte der zweiten Familie die Sektoren der ersten nachbilden?
Nicht von sich aus. Ihr Speichermodell kennt keine Sektoren, und Bestandsleser, die nur Sektorbefehle senden, erhalten keine passende Antwort. Für einen Übergang gibt es eigene Kartenfamilien mit umschaltbarem Betriebsmodus oder Kombikarten mit zwei getrennten Chips, die wir auf Anfrage in einem Kartenkörper verbauen.
