Auf einen Blick
Referenz für Architektur und Schlüsselverwaltung. Die Konformität eines Bausteins garantiert keine vollständige Systeminteroperabilität.
Drei Punkte vor der Entscheidung:
- im Projekt genutztes Profil und Version
- Anwendungsbereiche und Schlüsselverwaltung
- vollständiger Austausch zwischen Karte, Terminal und Dienst
CIPURSE definiert mehrere Profile und gemeinsame Mechanismen; gewähltes Profil, Applikationsdomänen, Schlüssel und Terminals werden eindeutig benannt. Offenheit ersetzt keine Interoperabilitätsprüfung. Die vollständige Abnahme umfasst Personalisierung, Transaktion, Fehlerbehandlung und Administration auf der Projektinfrastruktur.
Architektur nach ISO/IEC 7816-4
Dieser Standard nutzt die Datei- und Befehlsstruktur nach ISO/IEC 7816-4 und überträgt sie über die kontaktlose Schnittstelle nach ISO/IEC 14443-4. Anwendungen liegen in eigenen Verzeichnissen mit Binär-, Datensatz- und Wertdateien. Karte und Terminal authentisieren sich gegenseitig mit AES-128; danach läuft der Datenverkehr über gesicherte Nachrichten, wahlweise mit Prüfsumme oder zusätzlich verschlüsselt. Ein Transaktionsmechanismus stellt sicher, dass eine abgebrochene Buchung keine halb geschriebenen Werte hinterlässt. Für Wertdateien sieht der Standard Befehle zum Erhöhen und Vermindern vor, die erst mit dem Abschluss der Transaktion wirksam werden. Schlüssel werden je Anwendung verwaltet, sodass etwa ein Verkehrsbetrieb und ein Parkhausbetreiber getrennte Bereiche auf derselben Karte führen.
Profile und Trägerplattform
Die Spezifikation beschreibt Profile mit unterschiedlichem Funktionsumfang, vom schlanken Profil für eine einzelne Anwendung bis zum Profil mit mehreren Anwendungen und Wertdateien. Umgesetzt wird der Standard entweder als eigener Baustein oder als Anwendung auf einer programmierbaren Chipkartenplattform. Diese Wahl beeinflusst Speicher, Transaktionsdauer und die Möglichkeit, später weitere Anwendungen nachzuladen, und gehört deshalb zur Kartenspezifikation, nicht erst zur Terminalplanung. Da die Spezifikation offen ist, bieten verschiedene Plattformhersteller eigene Umsetzungen an. In der Kartenspezifikation halten wir deshalb fest, welche Umsetzung verbaut wird, damit Nachlieferungen dasselbe Verhalten zeigen.
Personalisierung und Kartenkörper
In der Fertigung legen wir nach der Strukturvorgabe Ihres Systemanbieters Verzeichnisse und Dateien an, schreiben Schlüssel und Startwerte; Musterkarten lassen sich anschließend über eine gesicherte Sitzung zurücklesen. Da die Kodierung Befehlsfolgen des Standards verwendet, benötigen wir das Personalisierungsskript oder eine vollständige Strukturbeschreibung vorab, um sie an Mustern zu erproben.
Der Kartenkörper entspricht dem anderer 13,56-MHz-Karten: ID-1 aus PVC oder PET, bedruckt, auf Wunsch mit Magnetstreifen oder mit Kontaktmodul für Dualinterface-Anwendungen, bei denen dieselbe Anwendung kontaktlos und über Kontakte erreichbar ist. Für Fahrgastkarten mit langer Nutzungsdauer bietet sich PET an, das sich weniger verformt als PVC. Kartennummer oder Fahrgastname drucken und kodieren wir aus derselben Datenzeile, sodass Aufdruck und Chipinhalt übereinstimmen.
Offene Sicherheitsarchitektur mit Nischenrealität
Dieser Standard bietet eine offen spezifizierte, moderne Sicherheitsarchitektur – attraktiv für Ausschreibungen, die Herstellerunabhängigkeit fordern. Die Spezifikation ist frei zugänglich; die Marktversorgung mit Karten, Lesern und Systemunterstützung ist jedoch deutlich schmaler als bei den verbreiteten Familien.
Wer ihn erwägt, prüft deshalb zuerst die Lieferkette über die Projektlaufzeit: mindestens zwei belastbare Bezugsquellen, bestätigte Systemunterstützung, realistische Musterverfügbarkeit. Ohne diese Basis wird aus der eleganten Architektur ein Beschaffungsrisiko.
Primärquellen
Nächster Prüfschritt
01 / BAUSTEINEM4100 Kennung, Datenrahmen und Anzeigeformate
Die LF-Kennung mit Nur-Lese-Prinzip, ihre Anzeigeformate und typische Grenzen werden im Zusammenhang erklärt.
02 / BAUSTEINWichtige ISO-Normen für RFID-Karten und Tags
Eine Landkarte zentraler Normfamilien im Zusammenhang mit Protokoll und Anwendung.
03 / PRODUKTRFID-Karten 13,56 MHz mit Kodierung nach Vorgabe
HF bezeichnet eine breite Technologiefamilie; die Frequenz allein bestätigt keine Interoperabilität.
Häufige Fragen
Kann ein Terminal eines anderen Anbieters Karten dieses offenen Standards lesen?
Nur wenn es dasselbe Profil unterstützt und die Schlüssel der Anwendung kennt. Die offene Spezifikation sorgt für gleiche Befehle und gleiche Sicherheitsmechanismen, ersetzt aber nicht die Freigabe im jeweiligen System. Für diesen Nachweis liefern wir auf Wunsch Musterkarten mit Testschlüsseln, die der Terminalanbieter vor der Serie prüfen kann.
Lassen sich auf eine Karte dieses offenen Standards später weitere Anwendungen laden?
Das hängt von der Umsetzung ab. Ein eigener Baustein mit ausreichend Speicher erlaubt das Anlegen weiterer Verzeichnisse, sofern der Kartenhauptschlüssel dies zulässt. Auf programmierbaren Plattformen kann zusätzlich Programmcode nachgeladen werden. Beides muss bei der Erstpersonalisierung vorgesehen sein, sonst ist die Karte nach der Ausgabe geschlossen.
Welche Unterlagen braucht die Personalisierung einer Kartenserie nach offenem Sicherheitsstandard?
Wir benötigen das verwendete Profil, die Verzeichnis- und Dateistruktur mit Zugriffsrechten, die Startwerte, das Schlüsselkonzept samt Übergabeweg und die Angabe, welche Daten auf den Kartenkörper gedruckt werden. Idealerweise stellt der Systemanbieter ein Personalisierungsskript bereit, das wir an Musterkarten ausführen und gemeinsam freigeben.