|
|
 |
 |
|
 Kontaktlose Chipkarten
| Smart Card Kommunikation
|
Smart Card Betriebssysteme |
| |
|
|
|
Für Smart Card Betriebssysteme hat sich die Bezeichnung COS (Card Operating System) eingebürgert, was vielfach auch Namensbestandteil der Betriebssysteme bestimmter Hersteller wurde. Die ersten Systeme waren eher strukturierte Bibliotheksammlungen im ROM, wohingegen heute mehrere Anwendungen unabhängig voneinander auf einer Smart Card betrieben und verwaltet werden können.
|
Dateiorganisation |
Die Speicher einer Smart Card haben unterschiedliche Eigenschaften, das statische ROM kann nur während der Herstellung als Maske programmiert werden, das RAM verliert den Inhalt mit Absetzen der Spannung wogegen das EEPROM ohne äußere Spannungszufuhr Daten speichern kann, mit dem Nachteil, das Zugriffe eher lange dauern (1 ms) und die Lebensdauer begrenzt ist.
Der Zugriff auf Dateien in einer Smart Card ist mit Bedingungen verknüpfbar. Die Speicherverwaltung fällt minimalst aus, sodass bei Initialisierung und Personalisierung meist alle Dateien erstellt werden und Änderungen sich lediglich auf den Dateiinhalt beschränken.
Auf Smart Cards sind nur die genormten Dateistrukturen verwendbar, d.h. es gibt 2 unterschiedliche Kategorien von Dateien.
Die "Dedicated Files" (DF) oft auch "Directory Files" genannt, sind die Verzeichnisdateien, das Root-Verzeichnis ist ein Sonderfall eines DF und wird Master File (MF) genannt. Bei UICC (UMTS Smart Cards) wurden die "Application Dedicated Files" definiert, die nicht unter dem MF angeordnet werden und sozusagen eine eigene Art von MF darstellen.
Die Elementary Files (EF) enthalten die Nutzdaten, sie weisen interne Datenstrukturen auf, um speicherplatzminimierend und logisch optimal aufgebaut zu sein. Aus diesem Grund gibt es keine anwendungsspezifischen EF. Sie können noch in "working EF" und "internal EF" unterschieden werden. Die working EF werden vom Terminal gelesen und geschrieben, wohingegen die internal EF Systemdaten enthalten, auf die nur das Betriebssystem zugreift, wie Schlüssel, Anwendungscode, etc. Die zu einer Anwendung gehörenden EFs werden in einem DF zusammengefasst.
Die Dateien auf Smart Cards werden logisch über den 2 Byte großen "File Identifier" (FID) adressiert, wobei bestimmte FID reserviert sind. Für die implizite Selektion einer Datei in einem Kommando kann auch die "Short FID" (SFI) verwendet werden, wobei diese aber nur optional ist.
Da der für FID zur Verfügung stehende Adressraum möglicherweise nicht ausreicht wurde für DF die Erweiterung des DF-Name (zw. 1 und 16 Byte) spezifiziert. Da durch die freie Auswahl trotzdem weltweit keine Kollisionfreiheit sichergestellt ist, wird der DF-Name nur in Verbindung mit dem "Application Identifier" (AID) verwendet. Ein bestimmtes EF enthält die AIDs der auf der Smart Card befindlichen Anwendungen.
Der in ISO/IEC 7816-5 definierte AID hat eine Länge von 5 bis 16 Byte und besteht aus 2 Teilen. Das erste Element ist der Registered Identifier (RID) mit der festen Länge von 5 Byte und wird von einer nationalen oder internationalen Registrierungsstelle vergeben. RIDs sind vertraulich und werden nicht veröffentlicht. Der RID enthält einen Ländercode ein Kennzeichen für die Kategorie der Anwendung und eine Nummer für den Anwendungsanbieter. Das zweite Element ist die optionale "Proprietary Application Identifier Extension" (PIX) die der Anwendungsanbieter der RID nachstellen kann.
Siehe zu diesem Thema auch: "Inside Smartcards" [134 KB]
Cryptoshop Artikel im deutschen IT-Security Magazin
|
Ablaufsteuerung |
Kommandos werden über die I/O Schnittsstelle vom I/O-Manager entgegengenommen und geprüft. Wenn Fehlererkennung und Korrektur durchgelaufen sind kann vom Secure Messaging Manager die Entschlüsselung vorgenommen werden und die Integrität geprüft werden. Danach kann der Logical Channel Manager auf den angewählten Kanal schalten, bzw. dessen Zustände umschalten. Somit kann geprüft werden, ob das Kommando im aktuellen Zustand ausgeführt werden darf. Zugriffe auf Daten geschehen über die Dateiverwaltung mithilfe des Speichermanagers. Der Antwortcode wird jeweils vom Returncodemanager gesteuert.
|
Programmcode und Algorithmen |
Weil Speicherplatz auf Smart Cards immer knapp bemessen ist, sind oft nicht alle genormten Kommandos und Dateistrukturen umgesetzt. Die deswegen in ISO 7816-4 eingeführten Profile sind daher Untermengen von Kommandos und Strukturen der Norm. Vielfach müssen bestimmte Transaktionen atomar sein, sprich entweder ganz oder gar nicht durchgeführt werden. APIs für Smart Card Betriebssysteme wurden erst mit Einführung der Möglichkeit selbsterstellten Code nachzuladen eingeführt, Stichwort Javacard und Multos.
|
|
|
bekannte Kartenbetriebssysteme |
ACOS
ACOS |
Austria Card
Advanced Card System |
STARCOS
SECCOS |
G & D |
|
MULTOS |
Maosco |
|
TCOS |
Telesec |
|
CARDOS |
Siemens |
|
Micardo |
ORGA |
|
SiCrypt |
Infineon |
|
SETCOS |
SETEC (Finnland) |
|
SCCOS |
Safenet |
|
GPK |
Gemplus |
|
ACOS / ACOS2 |
Advanced Card Systems (ACS) |
|
 |
 |
|
|
 |
|
Linktipps |
|
Cryptoshop Tipps |
|
Handbuch der Chipkarten
Rankl/Effing bei Amazon
Das Buch bietet einen praxisorientierten umfassenden Überblick über die Chipkartentechnik. Zunächst werden die erforderlichen Grundlagen, wie Kartenaufbau, elektrische und physikalische Eigenschaften, verwendete Microcontroller dargestellt. Darauf aufbauend werden die für die Entwicklung von Chipkartensystemen wichtigen Techniken, wie Sicherheits- und Informationstechnik, Betriebssystemarchitektur und Befehlssätze, ausführlich behandelt. |
|
Chipkarten-Anwendungen
von Wolfgang Rankl bei Amazon
Die meisten Chipkarten-Systeme beruhen auf ähnlichen Lösungen. Dennoch wird häufig viel Zeit investiert, um längst bekannte Mechanismen, Abläufe und Prinzipien neu zu erfinden. Dieses Buch zeigt, dass das nicht sein muss, und stellt eine Vielzahl von Entwurfsmustern und Ideen zur Realisierung von Chipkarten-Anwendungen vor. Zwei Chipkarten inclusive: Testen Sie die vorgestellten Lösungen direkt mit der im Buch enthaltenen Java Card oder der BasicCard |
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|
|
|
|
|
|
|
|
|
Impressum