|
 Contactless chip card
| Smart Card communication
|
Please note, that the Knowledge Base isn't translated to english completely at the moment. You will still find some german texts - we are translating permanently the outstanding parts! Thank you for understanding! |
Smart Card operating systems |
| |
|
|
|
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.
|
file organisation |
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.
|
flow control |
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.
|
code and algorithms |
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.
|
|
|
well known card operating systems |
ACOS
ACOS |
Austria Card
Advanced Card System |
STARCOS
SECCOS |
G & D |
|
MULTOS |
Maosco |
|
TCOS |
Telesec |
|
CARDOS |
Siemens |
|
Micardo |
ORGA |
|
SiCrypt |
Infineon |
|
SETCOS |
Schweden |
|
SCCOS (former DKCCOS) |
Safenet |
|
GPK (not available anymore) |
Gemplus |
|
 |
 |
 |
|
 |
|
Linktipps |
|
Cryptoshop Tipps |
|
Handbuch der Chipkarten
Rankl/Effing at Amazon
This book provides an overview in the field of chipcards, but is very detailed. It describes basics like electrical and physical characteristics, security techniques, operating systems and commands. |
|
|
|
|
|
|
|
|
|
Legal notice