Dokumentation der MCard-Bibliothek 1.18.0.0 der bremen-online ...

Handbuch 

Governikus SDK - Kartenansteuerung (MCard) 

bremen online services 

GmbH & Co. KG 

Version MCard 1.18.0.0 vom 18.12.2012 

Dokumentenversion 1.0 

© 2012 bos bremen online services GmbH & Co. KG, Bremen

Handbuch Governikus - Kartenansteuerung (MCard) Version 1.18.0.0 

Änderungsnachweise 

Version 

Freigabedatum 

Autor Kapitel Änderungen 

.90 06.12.2012 JP Alle Tabellen für MCard 1.18 angepasst und hinzugefügt 

0.91 17.12.2012 JP Tabellen aktualisiert 

1.0 18.12.2012 JP Finale Version erzeugt 

Die Änderungsnachweise für Textbausteine und Tabellen befinden sich am Ende dieses 

Dokuments. 

- 2 -


Inhaltsverzeichnis 

Rechtliche Informationen und weitere Hinweise ..................................................................... 4 

1 Einleitung ......................................................................................................................... 5 

2 Governikus Kartenansteuerung ........................................................................................ 6 

2.1 MCard-Varianten...................................................................................................... 6 

2.2 Releasezyklen ......................................................................................................... 7 

2.3 Abwärtskompatibilität der MCard zum Governikus SDK ........................................... 7 

3 Auflagen für die Nutzung der MCard gemäß Signaturgesetz ........................................... 8 

4 Hard- und Softwareanforderungen ................................................................................. 10 

4.1 Betriebssysteme .................................................................................................... 10 

4.2 Java Standard Edition Runtime Environment (JRE) ............................................... 12 

4.3 Chipkartenlesegeräte ............................................................................................. 13 

Unterstützte Chipkartenlesegeräte (Tabellen zum Kopieren) ................................. 16 

4.4 Signaturkarten ....................................................................................................... 17 

5 Technische Informationen zur MCard ............................................................................ 27 

5.1 Nutzung der MCard ................................................................................................ 29 

5.2 Benötigte Bibliotheken ........................................................................................... 31 

Native Bibliotheken ................................................................................................ 31 

Anhang 1: Tabellen der unterstützten Kombinationen Betriebssystem - 

Chipkartenlesegerät – Signaturkarte .................................................................................... 32 

Anhang 2: Änderungsnachweis Tabellen und Textbausteine ............................................... 37 

3


Rechtliche Informationen und weitere Hinweise 

Obwohl diese Produktdokumentation nach bestem Wissen und mit größter Sorgfalt erstellt 

wurde, können Fehler und Ungenauigkeiten nicht vollständig ausgeschlossen werden. Eine 

juristische Verantwortung oder Haftung für eventuell verbliebene fehlerhafte Angaben und 

deren Folgen wird nicht übernommen. Die in dieser Produktdokumentation enthaltenen Angaben 

spiegeln den aktuellen Entwicklungsstand wider und können ohne Ankündigung geändert 

werden. Künftige Auflagen können zusätzliche Informationen enthalten. Technische 

und typografische Fehler werden in künftigen Auflagen korrigiert. 

Diese Produktinformation sowie sämtliche urheberrechtsfähigen Materialien, die mit dem 

Produkt vertrieben werden, sind urheberrechtlich geschützt. Alle Rechte sind der bremen 

online services Entwicklungs- und Betriebsgesellschaft mbH & Co. KG, Bremen, (bos KG) 

vorbehalten. Alle urheberrechtsfähigen Materialien dürfen ohne vorherige Einwilligung der 

bos KG weder ganz noch teilweise kopiert oder auf sonstige Art und Weise reproduziert werden. 

Für rechtmäßige Nutzer des Produkts gilt diese Einwilligung im Rahmen der vertraglichen 

Vereinbarungen als erteilt. Jegliche Kopien dieser Produktinformation bzw. von Teilen 

daraus müssen den gleichen Hinweis auf das Urheberrecht enthalten wie das Original. 

Governikus und Governikus Communicator sind eingetragene Marken der bremen online 

services Entwicklungs- und Betriebsgesellschaft mbH & Co. KG, Bremen. 

Das Copyright für die Programmiersprache Java und alle weiteren, frei bei Oracle verfügbaren 

Technologien, liegt bei SUN Microsystems. Das Copyright für JBoss liegt bei Red Hat, 

Inc. Hierfür sind deren geltenden Markenbestimmungen zu beachten. Andere in diesem Produkt 

aufgeführten Produkt- und/ oder Firmennamen sind möglicherweise Marken weiterer 

Eigentümer, deren Rechte ebenfalls zu wahren sind. 

Sofern in diesem Handbuch für Personen ausschließlich die männliche Form benutzt wird, 

geschieht dies nur aus Gründen der besseren Lesbarkeit und hat keinen diskriminierenden 

Hintergrund. 

4


1 Einleitung 

Dieses Handbuch adressiert in erster Linie Produktmanager, die auf der Grundlage des 

Governikus SDK (OSCI-Client-Enabler, OSCI2-Enabler und eCard-API) eigene Client- 

Anwendungen als Signaturanwendungskomponente entwickeln lassen und eine Anwenderdokumentation 

erstellen müssen und/oder eine Herstellererklärung abzugeben haben. 

Die Governikus Kartenansteuerung (MCard) wird in zwei Varianten erstellt: MCard-Client und 

MCard-Server. Letztere wird ausschließlich für Nutzer des Governikus-NetSigners bereitgestellt. 

Im Kapitel 2 werden beide Varianten ausführlich beschrieben. 

Die MCard wird in der Regel als Service Modul in Applikationen verwendet, um qualifizierte 

Signaturen anzubringen. Damit ist die MCard Teil einer Signaturanwendungskomponente. In 

Kapitel 3 werden daher die Auflagen für die Nutzung der MCard gemäß Signaturgesetz beschrieben. 

In Kapitel 4 folgen die Hard- und Softwareanforderungen der MCard mit folgenden Unterkapiteln: 

Unterstützte Betriebssysteme (Kapitel 4.1), unterstützte JREs (4.2), unterstützte Chipkartenlesegeräte 

(4.3) und unterstützte Signaturkarten (4.4). Kartenleser und Signaturkarten 

sind Bestandteil einer SAK. Unterstützte Signaturkarten bzw. die verwendeten sicheren Signaturerstellungseinheiten 

(SSEE müssen immer SigG-bestätigt sein) und Chipkartenlesegeräte 

(diese müssen SigG-bestätigt oder zumindest herstellererklärt sein) sind in sogenannten 

Positivlisten aufzuführen. Diese Tabellen befinden sich in den entsprechenden Einzelkapiteln. 

Dazu gehört auch die Angabe der unterstützten Einsatzumgebungen (Betriebssysteme, 

JRE etc.). 

In Kapitel 5 wird schließlich ein Überblick über die technische Funktionsweise der MCard 

gegeben. Das Kapitel enthält detaillierte Informationen für Entwickler. 

Das MCard-Handbuch enthält in den meisten Kapiteln Textbausteine, die in die Anwenderdokumentation 

einer SAK aufgenommen werden sollten. Die Textbausteine beschreiben die 

Auflagen zum Einsatz des Service Moduls MCard als Teil einer SAK oder liefern Kontextinformationen 

zu den oben angesprochenen Tabellen. 

Hinweis: Die Textbausteine sind fortlaufend durchnummeriert. Änderungen an Textbausteinen 

werden explizit in der Änderungshistorie für Textbausteine am Ende dieses Dokuments 

aufgeführt. Neben den Textbausteinen unterliegen natürlich auch die Tabellen, die z. B. das 

Portfolio der aktuell unterstützten Kartenleser beschreiben, sowie auch die Tabellen zu Anund 

Abkündigungen einer ständigen Aktualisierung. Auch hier wird jede Änderung in einer 

entsprechenden Tabelle explizit in der Änderungshistorie für Tabellen am Ende des Dokuments 

aufgeführt. 

5


2 Governikus Kartenansteuerung 

2.1 MCard-Varianten 

Die Governikus Kartenansteuerung (MCard) wird in zwei Varianten erstellt: 

 

 

mcard.jar für Clientanwendungen (zukünftig als MCard bezeichnet) 

mcardServer.jar nur für die Verwendung mit dem Governikus-NetSigner (MCard- 

Server) 

Die MCard wird Kunden bereitgestellt, die eigene Anwendungen auf der Basis der Funktionsbibliotheken 

des Governikus SDK entwickeln. Die MCard unterstützt fast alle elektronischen 

Einzel-, Stapel- und Multisignaturkarten, die durch deutsche Zertifizierungsdiensteanbieter 

(ZDA) herausgegeben werden und mit denen man eine qualifizierte elektronische Signatur 

(QES) oder eine QES mit Anbieterakkreditierung erzeugen kann. 

Bei Stapelsignaturkarten und Multisignaturkarten, die zur Erzeugung von maximal 500 Stapelsignaturen 

genutzt werden können, ist durch die SAK sicherzustellen, dass keine missbräuchliche 

Nutzung der Stapelsignaturfunktionalität möglich ist. 

Die MCard übernimmt von PC/SC die Funktionalität von Transactions, d.h. eines temporär 

exklusiven Zugriffs auf Kartenleser und Karte, um die gemeinsame Nutzung des Kartenlesers 

und der Karte für verschiedene, gleichzeitig laufende Anwendungen zu unterstützen. 

Die Ausführung kryptografischer Operationen erfolgt grundsätzlich innerhalb eines Transaction-Blocks, 

der implizit durch die MCard oder explizit durch die Anwendung begonnen und 

beendet wird. Auf diese Weise wird sichergestellt, dass der konkurrierende Zugriff durch andere 

Anwendungen und der Missbrauch der Karte ausgeschlossen sind. Am Ende eines 

Transaction-Blocks wird der Sicherheitszustand der Karte zurückgesetzt. Im Fall komplexer 

kryptographischer Funktionen muss die Anwendung einen Transaction-Block beginnen und 

beenden, damit die vollständige Funktionalität der Karte zur Verfügung steht. Andernfalls 

steht aus Sicherheitsgründen nicht die volle Funktionalität zur Verfügung, Grundsätzlich kann 

ein Transaction-Block nur von der Anwendung beendet werden, die den Transaction-Block 

begonnen hat. 

Zur Verwendung der Stapelsignaturfunktion dieser Karten muss das Erzeugen der Signaturen 

in einem Transaction-Block erfolgen. Eine Karte bleibt bis zum Ende der Transaktion 

„offen“ und kann für Signaturen verwendet werden, falls die maximale Anzahl von Signaturen 

nicht überschritten wird. Falls die maximale Anzahl von Signaturen überschritten wird, wird 

der Transaction-Block beendet und der Sicherheitszustand der Karte zurückgesetzt, d.h. für 

die nächste Signatur ist es notwendig, den Transaction-Block erneut zu beginnen. 

Macht die Applikation keinen Transaction-Block auf, wird die Anzahl der möglichen Signaturerzeugungen 

durch Stapel- und Multisignaturkarten nach einer erfolgreichen Authentifizierung 

mit der Signatur-PIN durch die MCard zur Sicherheit auf 1 begrenzt. 

Für Kunden, die den vollen Funktionsumfang von Multisignaturkarten nutzen möchten, steht 

der Governikus NetSigner als Komponente der Governikus Service Components zur Verfügung. 

Dieser verwendet eine spezielle Variante der MCard, die als MCard-Server aus- 

6


schließlich für Nutzer des Governikus NetSigner bereitgestellt wird und eigene Releasezyklen 

besitzt. 

Kartentyp unterstützt / Anzahl Signaturen nach 

PIN-Eingabe 

MCard-Variante Einzelsignatur Stapelsignatur Multisignatur 

MCard-Client Ja / 1 Ja / 1 Ja / 1 

MCard-Client, verwendet durch eine 

Applikation, die Transaction-Block- 

Handling beherrscht 

MCard-Server für den Governikus- 

NetSigner 

Ja / 1 Ja / max. 100 Ja / max. 500 

Nein / - Nein / - Ja / unbegrenzt 

Tabelle 1: Überblick über die Varianten der MCard und unterstützte Kartentypen 

2.2 Releasezyklen 

Die Governikus Kartenansteuerung wird bei Bedarf aktualisiert und unabhängig von den 

SDK-Releasezyklen zur Verfügung gestellt. 

Bitte informieren Sie sich im bos-Portal, ob eine neuere Version der MCard zur Verfügung 

steht, als im aktuellen Release des Governikus SDK (MCard) bereitgestellt wurde. Verwenden 

Sie bitte immer nur die aktuelle Version der MCard. Nur so können Sie sicherstellen, 

dass auch neue Signaturkarten (neue SSEE) und neue Kartenleser verwendet werden können. 

Hintergrund: Qualifizierte Signaturkarten basieren auf sogenannten sicheren Signaturerstellungseinheiten 

mit SigG-Bestätigung. Diese SigG-Bestätigung sind immer nur befristet 

gültig, da auf den SSEE verwendete Algorithmen „altern“, d.h. ihre Eignung zur Erzeugung 

von qualifizierten Signaturen mit der Zeit verlieren. (Aus diesem Grund wird auch jährlich die 

Eignung der Algorithmen durch die Bundesnetzagentur aktualisiert.) D.h. Signaturkarten von 

Zertifizierungsdiensteanbietern (wie z.B. D-Trust) erneuern regelmäßig die SSEE, auf denen 

ihre Signaturkarten basieren. Dieses ist den Signaturkarten meist nicht anzusehen und der 

Nutzer einer Signaturkarte weiß auch in der Regel nicht, auf welcher SSEE seine Karte basiert. 

Deshalb ist es umso wichtiger, dass SAKs immer die aktuellste MCard verwenden. 

2.3 Abwärtskompatibilität der MCard zum Governikus SDK 

Die Abwärtskompatibilität wird für die letzten beiden SDK-Releases (aktuelles Release und 

Vorrelease) sichergestellt. Es wird mindestens auch noch die letzte SigG-bestätigte Version 

des SDK unterstützt. 

7


3 Auflagen für die Nutzung der MCard gemäß Signaturgesetz 

Applikationen, die die eCard-API oder den OSCI-Client-Enabler mit der MCard (und damit 

Kartenleser und Signaturkarten) verwenden sind Signaturanwendungskomponenten (SAK), 

wenn sie qualifizierte Signaturen anbringen oder prüfen oder Prüfergebnisse anzeigen. SAK 

werden in § 1, 11 SigG definiert als “Software- und Hardwareprodukte, die dazu bestimmt 

sind, Daten dem Prozess der Erzeugung oder Prüfung qualifizierter elektronischer Signaturen 

zuzuführen. 

Gemäß § 15 Abs. 7 und § 17 Abs. 4 Signaturgesetz (SigG) sowie § 11 Abs. 3 Signaturverordnung 

(SigV) müssen SAK SigG-bestätigt oder herstellererklärt werden bevor sie bereitgestellt 

werden. Zwar ist der OSCI-Client-Enabler als Funktionsbibliothek herstellererklärt. Dieses 

entbindet aber den Applikationshersteller nicht von seiner Pflicht zumindest eine eigene 

Herstellererklärung für seine Applikation bei der BNetzA einzureichen. 

Kartenleser und Signaturkarten sind Bestandteil einer SAK. Unterstützte Signaturkarten bzw. 

die verwendeten sicheren Signaturerstellungseinheiten (SSEE müssen immer SigG-betätigt 

sein) und Chipkartenlesegeräte (diese müssen SigG-bestätigt oder zumindest herstellererklärt 

sein) sind in sogenannten Positivlisten aufzuführen. Diese Tabellen befinden sich in 

dieser Dokumentation für die durch die MCard-Client unterstützten SSEE und Chipkartenlesegeräte. 

Für den SigG-konformen Betrieb einer SAK sind zudem bestimmte organisatorische und 

technische Maßnahmen erforderlich, die die SAK-Umgebung betreffen. Die organisatorischen 

und technischen Maßnahmen sollen sicherstellen, dass den Ergebnissen der Signaturanwendungskomponente 

auch tatsächlich vertraut werden kann, weil das ganze System 

auf dem die SAK ausgeführt wird, vertrauenswürdig ist. 

Wird die MCard als Teil einer SAK verwendet, muss in der Anwenderdokumentation der 

Applikation der folgende Hinweis zur SigG-konformen Nutzung sinngemäß aufgenommen 

werden: 

Textbaustein zum Kopieren 

Die Nutzung dieser Applikation als Signaturanbringungskomponente (SAK) (z.B. zur Anbringung 

von qualifizierten elektronischen Signaturen nach deutschem Signaturgesetz), 

macht es erforderlich, dass den potenziellen Bedrohungen durch einen unterschiedlichen 

„Mix“ von Sicherheitsvorkehrungen in der SAK selbst und durch die Einsatzumgebung begegnet 

wird. In der Einsatzumgebung „Geschützter Einsatzbereich“ (Einzelplatz-PCs, die 

privat oder in Büros im täglichen Einsatz sind) sind das in der Regel folgende Sicherheitsmaßnahmen: 

 

 

Wenn ein Internetzugang besteht, ist die Verwendung einer Firewall notwendig, um 

einen entfernten Zugriff auszuschließen. 

Um Trojaner und Viren weitestgehend ausschließen zu können, ist die Installation eines 

aktuellen Anti-Virenprogramms (automatisches Update möglichst aktiviert) erfor- 

8


 

derlich. 

Grundsätzlich darf nur vertrauenswürdige Software installiert und verwendet werden. 

Das gilt besonders für das Betriebssystem, es muss sichergestellt werden, dass das 

Betriebssystem bezüglich der Sicherheitspatches und Updates auf dem aktuellen 

Stand ist (Windows: automatisches Update ist zu aktivieren, etwaige Service Packs 

müssen installiert sein) und dass das JRE bezüglich der Sicherheitspatches und Updates 

auf dem aktuellen Stand ist. 

Ebenfalls ist Sorge dafür zu tragen, dass kein unbefugter Zugriff auf Ihr System erlangen 

kann. Hierfür ist die Bildschirm-Sperr-Funktion Ihres Betriebssystems zu aktivieren. Nutzen 

mehrere Nutzer Ihr System, ist für jeden Nutzer ein eigenes Benutzerkonto anzulegen. 

Textbaustein 1: SigG-konformer Einsatz der SAK - Auflagen zur Nutzung 

Beachten Sie in diesem Zusammenhang bitte auch das entsprechende Kapitel im OSCI- 

Client-Enabler-Entwicklerhandbuch. 

Die in dieser Produktdokumentation enthaltenen Angaben zur Eignung von Signaturkarten 

und Chipkartenlesegeräten zur Anbringung einer qualifizierten elektronischen Signatur nach 

deutschem Signaturgesetz wurden veröffentlichten Informationen der Bundesnetzagentur 

(hier: durch die Bundesnetzagentur veröffentlichten Bestätigungen oder Herstellererklärungen) 

entnommen und spiegeln den aktuellen Stand zum Zeitpunkt der Tests und Erstellung 

dieses Releases der MCard wider. Veröffentlichte Bestätigungen oder Herstellererklärungen 

können von der Bundesnetzagentur für ungültig erklärt oder widerrufen werden. Aktuelle 

Informationen hierzu finden Sie in den Übersichten der Bundesnetzagentur. 

9


4 Hard- und Softwareanforderungen 

4.1 Betriebssysteme 

Die MCard unterstützt eine Reihe von Clientbetriebssystemen, die in der Regel solange weiterhin 

unterstützt werden, wie der Hersteller dieses Betriebssystems dafür Sicherheitspatches 

herausgibt. Die Abkündigung für ein unterstütztes Betriebssystem erfolgt rechtzeitig 

unter Beachtung des End-Of-Life Zeitpunkts (nachfolgend EOL genannt) für das Betriebssystem. 

Eine Abkündigung muss allerdings nicht zwingend erfolgen, wenn der Hersteller angekündigt 

hat, keine Sicherheitsupdates ab einem bestimmten Datum mehr bereitzustellen. In 

diesem Fall sollte folgender Warnhinweis aufgenommen werden: 


Der Hersteller des Betriebssystems stellt ab Datum xx.xx.xxxx keine Sicherheitspatches 

mehr bereit. Dieser Umstand kann die für eine SAK geforderte hohe Sicherheit gegen potenzielle 

Bedrohungen beeinträchtigen. 

Textbaustein 2: Bereitstellung Sicherheitspatches Betriebssystem 

Grundsätzlich führend bei der Ankündigung von unterstützten Betriebssystemen ist die 

MCard, da zunächst die Funktionsfähigkeit zumindest eines gewissen Subsets von Kartenlesern 

mit dem neuen Betriebssystem abgewartet werden muss. Hier sind in der Regel die 

Kartenleserhersteller gefordert, ggf. neue Treiber für dieses Betriebssystem zur Verfügung 

zu stellen oder zu aktualisieren. 

Bei Windows-Betriebssystemen wird der folgende Automatismus angestrebt: Eine neue 

Windows-Version (wenn marktverfügbar) wird möglichst mit der nächsten MCard unterstützt, 

vorbehaltlich, dass genügend Kartenleser-Treiber zu Verfügung stehen. 

Dabei gilt grundsätzlich für die Unterstützung von Windows-Betriebssystemen: 

Es werden die aktuelle Windows-Version und möglichst höchstens zwei Vorversionen 

unterstützt, für die EOL noch nicht erreicht ist. Wenn unterstützt, werden (soweit vorhanden) 

die 32- und 64-Bit-Varianten unterstützt. 

Grundsätzlich werden Windows-Betriebssysteme (Client) nur mit den jeweils aktuellen 

Service Packs (SP) und Sicherheitsupdates unterstützt. 

Sollte ein Windows-Betriebssystem in mehreren Ausprägungen verfügbar sein, wird 

grundsätzlich die Professional-Version oder die Premium-Version unterstützt. 

Bei openSUSE wird angestrebt, dass jeweils die (zum Zeitpunkt der Tests der MCard) aktuelle 

Version unterstützt wird. 

Die Abkündigung eines Windows-Betriebssystems erfolgt in der Dokumentation eines 

MCard-Release möglichst ein Jahr im Voraus. Die Abkündigung bedeutet für die MCard, 

dass ab dem kommunizierten Datum oder Release keine Gewährleistung mehr für die Funk- 

10


tionsfähigkeit des Betriebssystems mit der MCard mehr übernommen werden kann und somit 

auch kein Support mehr geleistet werden kann. 

Abkündigungen von Betriebssystemen sollten, soweit durch die Clientanwendung bisher 

unterstützt, in jedem Fall in die Release-Dokumentation der jeweiligen Clientanwendung aufgenommen 

werden. 

Unterstützte Betriebssysteme 

Mit der vorliegenden Version der MCard wurde die Funktionsfähigkeit mit den in der folgenden 

Tabelle aufgeführten Client-Betriebssystemen getestet. Der Tabelle kann außerdem 

entnommen werden, welches Betriebssystem/welche Betriebssysteme für eine spätere Version 

der MCard abgekündigt wurden. Das in der Spalte angegebene Datum bedeutet, dass 

nach diesem Datum bereitgestellte MCard-Version das angegebene Betriebssystem nicht 

mehr unterstützen. Im Umkehrschluss bedeutet dieses aber auch, dass alle bis zu diesem 

Datum bereitgestellte MCard-Clients das Betriebssystem weiter unterstützen werden. 

Tabelle zum Editieren und zum Kopieren 

Unterstützte Betriebssysteme(e) 

 

 

 

 

Windows XP Professional 

32 Bit SP3 

Windows XP Professional 

64 Bit SP3 

Windows Vista Home Premium 

32 Bit SP2 

Windows Vista Home Premium 

64 Bit SP2 

Windows 7 Professional 32 




 

 

openSUSE 12.1 32 Bit 

Mac OS X 10.6.8 Snow 

Leopard 32 Bit 1) 

Getestete und unterstützte 

JRE 

Version(en) 

1.6.0_37 (32 Bit) 

7 Update 9 (32 Bit) 

1.6.0_37 (64 Bit) 


1.6.0_37 (32 Bit) 


1.6.0_37 (64 Bit) 


1.6.0_37 (32 Bit) 


1.6.0_37 (64 Bit) 


1.6.0_37 (32 Bit) 


1.6.0_37 (64 Bit) 


1.6.0_37 (32 Bit) 


1.6.0_37 (32 Bit) 

Abkündigung 

Betriebssysteme abgekündigt für die 

nach dem 01.04.2013 bereitgestellte 

MCard. Unterstützt werden die dann 

aktuellen Versionen der Betriebssysteme. 

1) Einschränkungen in der Funktionsunterstützung des Betriebssystems mit Governikus-Komponenten möglich 

Tabelle 2: Unterstützte Betriebssysteme/abgekündigte Betriebssysteme 

Eine Tabelle mit den unterstützten Betriebssystemen sollte in jedem Fall in die Anwender- 

Dokumentation der jeweiligen Clientanwendung aufgenommen werden. Bei einer Anwendung, 

die eine SAK im Sinne des Signaturgesetzes darstellt (also zur Erzeugung von qualifi- 

11


zierten elektronischen Signaturen verwendet werden kann), muss diese Tabelle veröffentlicht 

werden, da die unterstützten Clientbetriebssysteme in einer Positivliste zu veröffentlichen 

sind. Dabei ist zu beachten, ob ggf. nur ein Subset der durch die MCard unterstützten 

Betriebssysteme unterstützt werden soll. 

4.2 Java Standard Edition Runtime Environment (JRE) 

Grundsätzlich führend bei der Kommunikation der An- und Abkündigungspraxis von JREs ist 

die MCard. Typischerweise erfolgen Abkündigungen innerhalb der Release-Dokumentation 

der jeweiligen Clientanwendung. Dabei ist zu beachten, dass Clients ggf. nur ein Subset der 

durch die MCard unterstützten JREs unterstützen. 

In der Regel sollen die aktuelle JRE-Version und die Vorversion unterstützt werden. Dabei 

werden grundsätzlich die jeweils aktuellen Updates zum Zeitpunkt der Tests der MCard verwendet. 

Abkündigungen von JRE-Versionen sollen grundsätzlich in der Dokumentation eines Release 

der MCard möglichst ein Jahr im Voraus erfolgen, wenn z. B. das EOL bekannt wird. Typischerweise 

erfolgen Abkündigungen innerhalb der Release-Dokumentation der jeweiligen 

Clientanwendung. Ab Abkündigungstermin kann keine Gewährleistung mehr für die Funktionsfähigkeit 

des JREs mit der MCard mehr übernommen werden und somit auch kein Support 

mehr geleistet werden. 

Eine Abkündigung sollte erfolgen, wenn ORACLE angekündigt hat, keine Sicherheitsupdates 

ab einem bestimmten Datum mehr bereitzustellen (EOL). Wird diese Version über das EOL 

hinaus unterstützt, sollte folgender Warnhinweis aufgenommen werden: 


Der Hersteller des JRE stellt ab Datum xx.xx.xxxx keine Sicherheitspatches mehr bereit. 

Dieser Umstand kann die für eine SAK geforderte hohe Sicherheit gegen potenzielle Bedrohungen 

beeinträchtigen. 

Textbaustein 3: Bereitstellung Sicherheitspatches JRE 

Unterstützte JREs 

Die beiden MCard-Varianten unterstützen ORACLE Java Standard Edition Runtime Environments 

(JRE von ORACLE/SUN) in den in der Tabelle 5 angegebenen Versionen und 

deren Updates. Empfohlen werden die jeweils aktuellen Updates. Der Tabelle kann außerdem 

entnommen werden, welche JRE-Version zwar noch in der aktuellen Version der MCard 

unterstützt wird aber abgekündigt wurde. Das angegebene Datum bedeutet, dass nach diesem 

Datum bereitgestellte MCard-Versionen die angegebene JRE-Version nicht mehr unterstützen. 

Im Umkehrschluss bedeutet dieses aber auch, dass bis zu diesem Datum bereitgestellte 

MCard-Clients die Version weiter unterstützen werden. 

Mit dem vorliegenden Release der MCard wurden folgende Update-Versionen getestet: 

12


Tabelle zum Editieren und zum Kopieren 

Unterstützte Java Runtime 

Environment (JRE) 

Update 

1.6.0 37 

1.7.0 9 

Abkündigung 

Tabelle 3: Unterstützte JRE/abgekündigte JRE 

Bitte beachten Sie: 

Ende Februar 2013 endet die Unterstützung für Java 6 SE durch Oracle (siehe Java SE 6 

End-Of-Life (EOL) Notice). Die MCard bleibt zwar bis auf weiteres mit Java 6 SE lauffähig, 

berücksichtigen Sie jedoch bitte, dass Oracle ab diesem Zeitpunkt keine Sicherheitsupdates 

mehr bereitstellen wird. Dieser Umstand kann die für eine Signaturanwendungskomponente 

(SAK) geforderte hohe Sicherheit gegen potentielle Bedrohungen maßgeblich beeinträchtigen. 

Die bos KG empfiehlt daher, rechtzeitig auf Java 7 SE umzustellen. 

4.3 Chipkartenlesegeräte 

Die MCard unterstützt fast alle Chipkartenlesegeräte, die für die Erzeugung einer qualifizierten 

elektronischen Signatur (QES) geeignet sind. Dieses sind Chipkartenlesegeräte, die gemäß 

den Anforderungen des deutschen Signaturgesetzes bestätigt oder herstellererklärt 

sind und deren Bestätigung oder Herstellererklärung bei der Bundesnetzagentur (BNetzA) 

veröffentlicht wurde. 

Es handelt sich dabei ausschließlich um Geräte, die eine sichere PIN-Eingabe über das PIN- 

Pad des Chipkartenlesers erlauben (Geräte der sogenannten HBCI-Klassen 2 und 3). Außerdem 

werden ausgewählte Chipkartenlesegeräte ohne PIN-Pad unterstützt, die nicht für 

die Erzeugung einer QES verwendet werden dürfen. Die Listen mit den unterstützten Chipkartenlesegeräten 

befinden sich in Tabelle 4, Tabelle 5 und Tabelle 6. Wird eine Clientapplikation 

als SAK, also zur Anbringung von qualifizierten elektronischen Signaturen verwendet, 

müssen die Listen der durch die Clientapplikation unterstützten, SigG-bestätigten und herstellererklärten 

Chipkartenlesegeräte in der Anwenderdokumentation veröffentlicht als sogenannte 

„Positivliste“ werden. 

Die Funktionsfähigkeit der in dieser Liste benannten Chipkartenlesegeräte wurde jeweils für 

die angebenden Betriebssysteme getestet. Getestet wurde jeweils mit den bei den Herstellern 

verfügbaren aktuellen Treibern bzw. mit dem generischen Linux-Treiber unter Verwendung 

der zum Testzeitpunkt aktuellen Firmware der Chipkartenlesegeräte, soweit diese Geräte 

updatefähig sind. Detailinformationen zu den getesteten Treiber- und Firmware Versionen 

finden Sie in den Tabellen am Ende dieses Dokuments. 

Es kann keine Gewährleistung dafür übernommen werden, dass 

 

 

 

andere Versionen der unterstützten Chipkartenlesegeräte verwendet werden können, 

die unterstützten Chipkartenlesegeräte auch mit älteren Treiberversionen, anderer 

Firmware oder anderen als den genannten Betriebssystemen funktionieren und 

andere als die explizit aufgeführten Chipkartenlesegeräte unterstützt werden. 

13


In die Anwenderdokumentation sollte daher der folgende Hinweis aufgenommen werden: 


Die MCard unterstützt fast alle Chipkartenlesegeräte für die Erzeugung einer qualifizierten 

elektronischen Signatur (QES). Dieses sind Chipkartenlesegeräte, die gemäß den Anforderungen 

des deutschen Signaturgesetzes (SigG) bestätigt sind und deren Bestätigung oder 

Herstellererklärung bei der Bundesnetzagentur (BNetzA) veröffentlicht wurde. Es handelt 

sich dabei ausschließlich um Geräte, die eine sichere PIN-Eingabe über das PIN-Pad des 

Chipkartenlesers erlauben (Geräte der sogenannten HBCI-Klassen 2 und 3). Außerdem 

werden ausgewählte Chipkartenlesegeräte ohne PIN-Pad unterstützt. 

Die Funktionsfähigkeit der unterstützten Chipkartenlesegeräte mit dieser Clientapplikation 

wurde für die angegebenen Betriebssysteme und JRE getestet. Getestet wurde jeweils mit 

den bei den Herstellern verfügbaren aktuellen Treibern bzw. mit dem generischen Linux- 

Treiber unter Verwendung der zum Testzeitpunkt aktuellen Firmware der Chipkartenlesegeräte. 

Es kann keine Gewährleistung dafür übernommen werden, 

 

 

dass die unterstützten Chipkartenlesegeräte auch mit älteren Treiberversionen 

oder anderen als den genannten Betriebssystemen funktionieren. 

andere als die explizit aufgeführten Chipkartenlesegeräte verwendet werden können. 

Textbaustein 4: Erläuterung zu den unterstützten Chipkartenlesegeräten 

Die MCard unterstützt auch Chipkartenlesegeräte der HBCI-Klasse 1 ohne PIN-Pad. Es 

handelt sich ausschließlich um externe Geräte mit USB-Schnittstelle, die über einen PC/SC- 

Treiber angesprochen werden. Neben diesen explizit benannten Geräten können auch viele 

weitere Chipkartenlesegeräte mit USB-Schnittstelle ohne PIN-Pad (HBCI-Klasse 1) oder interne 

Chipkartenlesegeräte in Notebooks verwendet werden. Natürlich muss der Hersteller 

für das verwendete Betriebssystem einen Treiber zur Verfügung stellen. Eine Gewährleistung 

für die Funktionsfähigkeit kann gleichwohl nicht übernommen werden. 

Die MCard ermöglicht somit auch die Verwendung von Chipkartenlesegeräten ohne PIN- 

Pad. Weiterhin kann es vorkommen, dass bereits Chipkartenlesegeräte, die sich noch im 

Bestätigungsprozess oder noch nicht herstellererklärt sind, unterstützt werden. Außerdem 

können veröffentlichte Bestätigungen oder Herstellererklärungen für Chipkartenlesegeräte 

von der Bundesnetzagentur für ungültig erklärt werden. Wenn der Anwender ein solches 

Chipkartenlesegerät (obwohl in den Listen „Unterstützte Chipkartenlesegeräte mit veröffentlichter 

Bestätigung durch die Bundesnetzagentur“ und „Unterstützte Chipkartenlesegeräte 

mit Herstellererklärung, veröffentlicht durch die Bundesnetzagentur“ geführt) verwendet, 

nutzt er die MCard nicht als Teil einer Signaturanwendu0ngskomponente (SAK), mit der qualifizierte 

Signaturen erzeugt werden dürfen. Wird eine Clientapplikation als SAK, also zur 

Erzeugung von qualifizierten elektronischen Signaturen verwendet, muss daher der folgende 

Hinweis in die Anwenderdokumentation Ihrer Clientapplikation aufgenommen werden: 

14



Für die Erzeugung einer qualifizierten Signatur dürfen nur Chipkartenlesegeräte verwendet 

werden, die gemäß den Anforderungen des deutschen Signaturgesetzes (SigG) bestätigt 

sind und wenn diese Bestätigung oder Herstellererklärung bei der Bundesnetzagentur 

(BNetzA) veröffentlicht wurde. Dieses sind ausschließlich Geräte, die eine sichere PIN- 

Eingabe über das PIN-Pad des Chipkartenlesers erlauben (Geräte der sogenannten HBCI- 

Klassen 2 und 3). 

Zum Zeitpunkt des Inverkehrbringens dieser Clientapplikation genügen die in den Listen 

„Unterstützte Chipkartenlesegeräte mit veröffentlichter Bestätigung durch die Bundesnetzagentur“ 

und „Unterstützte Chipkartenlesegeräte mit Herstellererklärung, veröffentlicht 

durch die Bundesnetzagentur“ aufgeführten Chipkartenlesegeräte diesen Anforderungen. 

Diese Clientapplikation unterstützt auch Chipkartenlesegeräte, die keine sichere PIN- 

Eingabe erlauben (HBCI-Klasse 1) und daher keine bei der Bundesnetzagentur veröffentliche 

Bestätigung oder Herstellererklärung besitzen. Wenn Sie ein solches Chipkartenlesegerät 

verwenden, nutzen Sie diese Clientapplikation nicht als Teil einer Signaturanwendungskomponente 

(SAK), mit der qualifizierte Signaturen erzeugt werden dürfen. 

Dieses gilt auch für Chipkartengeräte mit PIN-Pad, die noch nicht in den beiden Listen aufgeführt 

sind, weil sie sich zum Zeitpunkt der Erstellung dieser Listen noch im Bestätigungsprozess 

befanden oder deren Herstellerklärung noch nicht durch die Bundesnetzagentur 

veröffentlicht war. 

Veröffentlichte Bestätigungen oder Herstellererklärungen für Chipkartenlesegeräte können 

von der Bundesnetzagentur für ungültig erklärt werden. Wenn Sie ein solches Chipkartenlesegerät 

verwenden, nutzen Sie diese Clientapplikation nicht als Teil einer Signaturanwendungskomponente 

(SAK), mit der qualifizierte Signaturen erzeugt werden dürfen, obwohl 

die Geräte in den Listen „Unterstützte Chipkartenlesegeräte mit veröffentlichter Bestätigung 

durch die Bundesnetzagentur“ und „Unterstützte Chipkartenlesegeräte mit Herstellererklärung, 

veröffentlicht durch die Bundesnetzagentur“ aufgeführt wurden. Aktuelle Informationen 

hierzu finden Sie in den Übersichten bei der Bundesnetzagentur. 

Textbaustein 5: Verwendung nicht SigG-bestätigter oder nicht herstellererklärter 

Chipkartenlesegeräte bei Nutzung der Clientapplikation als SAK 

Neue Kartenleser der durch die MCard in der Regel zeitnah unterstützt, sobald die SigG- 

Bestätigung bei der BNetzA veröffentlicht wurde und Treiber für die unterstützten Betriebssysteme 

zur Verfügung stehen. Eine Abkündigung eines unterstützten Kartenlesers erfolgt in 

der Regel, wenn der Hersteller das Gerät abgekündigt hat und absehbar ist, dass auch keine 

Treiberaktualisierung mehr erfolgen wird oder eine Befristung in der Bestätigung vorliegt. 

15


Unterstützte Chipkartenlesegeräte (Tabellen zum Kopieren) 

Handelsname 

des unterstützten 

Geräts 

Angaben aus der veröffentlichten Bestätigung bei der 

BNetzA 

CardMan 3621 OMNIKEY GmbH SAK Chipkartenterminal der 

Familie CardMan Trust 

CM3621, Firmware-Version 

6.00 

CardMan 3821 OMNIKEY GmbH SAK Chipkartenterminal der 

Familie CardMan Trust 

CM3821, Firmware-Version 

6.00 

Cherry Smartboard 

G83-6744 

Cherry SmartTerminal 

2000 U 

CyberJack e-com 

CyberJack e-com 

plus 

CyberJack pinpad 

Version 3 

Cyberjack RFID 

komfort 

Cyberjack RFID 

standard 

CyberJack secoder 

Fujitsu Siemens 

Chipkartenleser- 

Tastatur KB SCR 

Pro 


Chipkartenleser- 

Tastatur Smartcase 

KB SCR eSIG 

Kobil KAAN Advanced 

Kobil KAAN 

TrB@ank, EMV- 

TriCAP Reader und 

SecOVID Reader 

III 

SPR 332 usb 

(Chipdrive pinpad 

pro) 

Cherry GmbH 

Cherry GmbH 

Reiner SCT Kartenlesegeräte 

GmbH 


GmbH 


GmbH 


GmbH 


GmbH 


GmbH 



Kobil Systems GmbH 

Kobil Systems GmbH 

SCM Microsystems 

GmbH 

Chipkartenterminal der Familie 

SmartBoard xx44 Firmware- 

Version 1.04 

Chipkartenterminal der Familie 

SmartTerminal ST-2xxx, 

Firmware Version 6.01 

CyberJack e-com, Version 3.0 

CyberJack e-com plus, Version 

3.0 

Chipkartenleser, cyberJack 

pinpad, Version 3.0 

Cyberjack RFID komfort Version 

2.0 

Cyberjack RFID standard 

Version 1.2 

Chipkartenleser CyberJack 

secoder Version 3.0 

Chipkartenleser-Tastatur 

KB SCR Pro, Sachnummer 

S26381-K329- 

V2xx HOS:01, Firmware 

Version 1.06 

SmartCase KB SCR eSIG 

(S26381-K529-Vxxx) Hardware 

Version HOS:01, Firmware-Version 

1.20 

Firmwareversion 1.21 gemäß 

Nachtrag vom 04.02.2011 

Chipkartenterminal KAAN 

Advanced, Firmware Version 

1.02, Hardware Version 

K104R3, 

Firmware 1.19 gemäß Nachtrag 

zur Bestätigung 

Signatur-Modul für die KOBIL 

Chipkartenterminals KAAN 

TriB@nk (FW 79.23), EMV- 

TriCAP (FW 82.23)und SecO- 

VID Reader III (FW 82.23) 

Chipkartenleser SPR332 

Firmware Version 6.01 

BSI.02057.TE. 

12.2005 

BSI.02057.TE. 

12.2005 

BSI.02048.TE. 

12.2004 

BSI.02124.TE. 

09.2010 

TUVIT.93155.T 

E.09.2008 

TUVIT.93156.T 

E.09.2008 

TUVIT.93107.T 

U.11.2004 

TUVIT.93180.T 

U.12.2011 

TUVIT.93188.T 

U.07.2011 

TUVIT.93154.T 

E.09.2008 

BSI.02082.TE. 

01.2007 

BSI.02107.TE. 

03.2010 

Nachtrag zur 

Bestätigung 

BSI.02107.TE. 

03.2010 

vom 

04.02.2011 

BSI.02050.TE. 

12.2006 

Nachtrag zur 

Bestätigung 

vom 

07.04.2008: T- 

Systems. 

02207.TU.04.2 

008 

T-Systems 

02246.TE. 

10.2010 

BSI.02117.TE. 

02.2010 

PC/SC USB ja 

PC/SC USB ja 

PC/SC USB ja 

PC/SC USB ja 

PC/SC USB ja 

PC/SC USB ja 

PC/SC USB ja 

PC/SC USB ja 

PC/SC USB ja 

PC/SC USB ja 

PC/SC USB ja 

PC/SC USB ja 

PC/SC USB ja 

PC/SC USB ja 

PC/SC USB ja 

Standard 

Schnittstelle 

PIN- 

Pad 

Tabelle 4: Unterstützte Chipkartenlesegeräte mit veröffentlichter Bestätigung durch 

die Bundesnetzagentur 

16


Handelsname 

des unterstützten 

Geräts 

CARD STAR/ 

medic Version 2 

Angaben aus der veröffentlichten Herstellererklärung bei 

der BNetzA 

celectronic GmbH 

CARD STAR /medic2, Version M1.50G 

Herstellererklärung vom 01.09.2010 

Version M1.53G gemäß 1. Nachtrag vom 

15.04.2011 

eHealth 8751 LAN Omnikey eHealth-BCS-Kartenterminal Omnikey eHealth 

8751 LAN Version 2.06, FW 1.32 


eHealth BCS 200 

SCM Microsystems 

GmbH 

eHealth Kartenterminal eHealth 200 BCS Version 

02.00 


1. Nachtrag zur Herstellererklärung vom 

20.01.2011 

GT900 BCS german telematics Chipkartenterminal eHealth GT900 BCS mit der 

Firmwareversion: 1.0.10 und der 

Hardwareversion: 2.0 / 2.0 SI / 2.0 SW 


medCompact 

eHealth 

ORGA 6041 Version 

2.07 

Verifone (ehemals 

Hypercom) 

medCompact eHealth BCS Version 02.00 


Nachtrag 1 zur Herstellererklärung vom 

20.01.2011 

Sagem Monetel GmbH ORGA 6041 Version 2.07 


CT-API USB ja 

Standard 

Schnittstelle 

PIN- 

Pad 

CT-API USB Ja 

PC/SC 

CT-API 

USB 

Ja 

CT-API USB Ja 

CT-API USB Ja 

PC/SC 

CT-API 

USB 

Ja 

Tabelle 5: Unterstützte Chipkartenlesegeräte mit veröffentlichter Herstellererklärung 

durch die Bundesnetzagentur 

Handelsname des unterstützten 

Geräts 

Hersteller 

Schnitt 

stelle 

CardMan 3121 Omnikey PC/SC USB nein 

Omnikey Cardman 5321 RFID 1) Omnikey PC/SC USB nein 

SCM SDI011 RFID 1) SCM Microsystems GmbH PC/SC USB nein 

SCR 3310 SCM Microsystems GmbH PC/SC USB nein 

SCR 3311 (Chipdrive desktop pro) SCM Microsystems GmbH PC/SC USB nein 

SCR 335 (Chipdrive micro pro) SCM Microsystems GmbH PC/SC USB nein 

Cherry ST-1044U ZF Electronics GmbH PC/SC USB nein 

Cherry ST-1275 1) ZF Electronics GmbH PC/SC USB nein 

1) Nur die Nutzung des kontaktbehafteten Interfaces möglich 

Tabelle 6: Unterstützte Chipkartenlesegeräte (nicht für eine QES in Deutschland geeignet) 

Standard 

PIN- 

Pad 

Handelsname des Geräts Hersteller Abkündigung 

Tabelle 7: Abgekündigte Chipkartenlesegeräte 

4.4 Signaturkarten 

Die MCard unterstützt die meisten elektronischen Signaturkarten, die durch deutsche Zertifizierungsdiensteanbieter 

(ZDA) herausgegeben werden und mit denen man eine qualifizierte 

elektronische Signatur oder eine qualifizierte Signatur mit Anbieterakkreditierung erzeugen 

kann. Ausgewählte Signaturkarten europäischer Zertifizierungsdiensteanbieter werden durch 

die MCard ebenfalls unterstützt. Eine besondere Ankündigung der Unterstützung neuer Signaturkarten 

erfolgt nicht. Vielmehr wird angestrebt, dass eine neue Signaturkarte oder eine 

17


neue SSEE-Version einer bereits unterstützten Signaturkarte sechs Wochen nach Marktverfügbarkeit 

durch ein neues MCard-Release unterstützt wird. Dieses Verfahren gilt nicht für 

Signaturkarten, die ausschließlich für geschlossene Nutzergruppen herausgegeben werden. 

Bei Stapelsignaturkarten und Multisignaturkarten, die zur Erzeugung von maximal 500 Stapelsignaturen 

genutzt werden können, ist durch die SAK sicherzustellen, dass keine missbräuchliche 

Nutzung der Stapelsignaturfunktionalität möglich ist. Zur Verwendung der Stapelsignaturfunktion 

dieser Karten, muss das Erzeugen der Signaturen in einem Transaction- 

Block erfolgen. Macht die Applikation keine Transaction-Block auf, wird die Anzahl der möglichen 

Signaturerzeugungen durch Stapel- und Multisignaturkarten nach einer erfolgreichen 

Authentifizierung mit der Signatur-PIN durch die MCard zur Sicherheit auf 1 begrenzt. In die 

Anwenderdokumentation von Clientapplikationen, die die MCard ohne die Stapelsignaturfunktionalität 

verwenden, muss deshalb der folgende Hinweis aufgenommen werden: 


Diese Clientapplikation unterstützt die meisten elektronischen Signaturkarten, die durch 

deutsche Zertifizierungsdiensteanbieter (ZDA) mit oder ohne Anbieterakkreditierung herausgegeben 

werden und mit denen eine qualifizierte elektronische Signatur erzeugt werden 

kann. Dazu gehören auch Stapel- und Multisignaturkarten. Aus Sicherheitsgründen 

wurden bei Stapel- und Multisignaturkarten die Anzahl der möglichen Signaturerzeugungen 

nach einer erfolgreichen Authentifizierung mit der Signatur-PIN auf 1 begrenzt. 

Textbaustein 6: Erläuterung unterstützte Signaturkarten bei Applikationen ohne Stapelsignaturfunktionalität 

In die Anwenderdokumentation von Clientapplikationen, die die MCard mit Stapelsignaturfunktionalität 

verwenden, muss deshalb der folgende Hinweis aufgenommen werden: 


Diese Clientapplikation unterstützt die meisten elektronischen Signaturkarten, die durch 

deutsche Zertifizierungsdiensteanbieter (ZDA) herausgegeben werden und mit denen man 

eine qualifizierte elektronische Signatur oder eine qualifizierte Signatur mit Anbieterakkreditierung 

erzeugen kann. Dazu gehören auch Stapel- und Multisignaturkarten. Bei Stapelsignaturkarten 

wird der volle Funktionsumfang gewährleistet, d. h., nach einer erfolgreichen 

Authentifizierung mit der Signatur-PIN können - je nach Hersteller - bis zu 250 Signaturen 

erzeugt werden. Bei Multisignaturkarten wird die Stapelsignaturfunktionalität unterstützt 

und aus Sicherheitsgründen nach einer erfolgreichen Authentifizierung mit der Signatur- 

PIN die Anzahl der möglichen Signaturen auf maximal 500 begrenzt. 

Textbaustein 7: Erläuterung unterstützte Signaturkarten bei Applikationen mit Stapelsignaturfunktionalität 

Signaturkarten, mit denen man qualifiziert signieren kann, basieren auf sogenannten sicheren 

Signaturerstellungseinheiten (SSEE). Für eine Signaturkarte werden von einem ZDA 

häufig mehrere unterschiedliche SSEE verwendet und personalisiert. Eine SSEE wird 

18


manchmal auch von mehreren ZDA/Trustcentern verwendet. Unterstützt werden nur die den 

folgenden Tabellen aufgeführten Signaturkarten. 

Unterstützt wird bei jeder Signaturkarte, soweit entsprechende Schlüssel und entsprechende 

Zertifikate auf der Signaturkarte vorhanden sind: 

 

 

 

die Erzeugung von qualifizierten und/oder fortgeschrittenen elektronischen Signaturen 

die Ver-/Entschlüsselung von Daten und 

die Authentisierung. 

Die Klassifizierung der Eignung des öffentlichen Schlüssels im Zertifikat für die Prüfung einer 

qualifizierten elektronischen Signatur, die Ent-/Verschlüsselung bzw. Authentisierung beruht 

auf der Zuordnung in der CommonPKI-Spezifikation Version 2.0. Für die Prüfung der qualifizierten 

elektronischen Signatur mit dem öffentlichen Signaturprüfschlüssel im Zertifikat muss 

die KeyUsage „contentCommitment“ gesetzt sein. Andere KeyUsages dürfen gemäß der 

CommonPKI-Spezifikation Version 2, Part 9, SigG-Profil nicht gleichzeitig mit diesem Bit 

verwendet werden. Für die Authentisierung wird demgegenüber „digitalSignature“ (zusätzlich 

z. T. auch die extended KeyUsage „clientAuthentication“) gesetzt, die eine Signaturverifizierung 

erlaubt, die sich nicht auf die Verifizierung einer Signatur einer Willenserklärung bezieht 

und für eine fortgeschrittene Signatur verwendet wird. Für die Datenentschlüsselung wird die 

Keyusage „dataEncipherment“ gesetzt. Häufig finden sich auch Zertifikate, die zur Verschlüsselung 

und Authentisierung in Form eines Kombizertifikates verwendet werden können. 

Wird eine Clientapplikation als SAK, also zur Erzeugung von qualifizierten elektronischen 

Signaturen verwendet, müssen die Listen mit den unterstützten Signaturkarten für die Erzeugung 

einer elektronischen Signatur in die Anwenderdokumentation Ihrer Clientapplikation 

aufgenommen werden, da die unterstützten Signaturkarten in einer Positivliste zu veröffentlichen 

sind. 

Aus technischen Gründen kann es in Ausnahmefällen vorkommen, dass die Signaturanbringung, 

Chiffrierung oder Authentisierung mit einer elektronischen Signaturkarte/SSEE in 

Kombination mit einem bestimmten Chipkartenleser und einem bestimmten Betriebssystem 

nur eingeschränkt oder nicht funktioniert, weil z. B. auf der Signaturkarte kein Verschlüsselungszertifikat 

vorhanden ist, weil für eine neue Signaturkarte noch kein geeigneter PC/SC- 

Treiber durch den Hersteller des Chipkartenlesegeräts bereitgestellt wurde oder eine Inkompatibilität 

von Kartenleser (elektrisch, Firmware oder Treiber) und Karte vorliegt. Detailinformationen 

hierzu sind den Tabellen im Anhang zu entnehmen. Sie sollten in die Anwenderdokumentation 

Ihrer Clientapplikation aufgenommen werden. Bitte beachten Sie, dass ggf. 

nicht alle Tabellen erforderlich sein könnten, sollten Sie beabsichtigen, nicht alle Betriebssysteme 

für die Nutzung freizugeben. Der folgende Hinweistext sollte in die Anwenderdokumentation 

aufgenommen werden: 


Aus technischen Gründen kann es in Ausnahmefällen vorkommen, dass die Signaturanbringung, 

Chiffrierung oder Authentisierung mit einer elektronischen Signaturkarte/SSEE in 

Kombination mit einem bestimmten Chipkartenleser und einem bestimmten Betriebssys- 

19


tem nur eingeschränkt oder nicht funktioniert, weil z. B. auf der Signaturkarte kein Verschlüsselungszertifikat 

vorhanden ist, weil für eine neue Signaturkarte noch kein geeigneter 

PC/SC-Treiber durch den Hersteller des Chipkartenlesegeräts bereitgestellt wurde oder 

eine Inkompatibilität von Kartenleser (elektrisch, Firmware oder Treiber) und Karte vorliegt. 

Prüfen Sie daher bitte, ob Ihre Signaturkarte in Kombination mit Ihrem Chipartenlesegerät 

und Ihrem Betriebssystem Ihre Anforderungen erfüllt. 

Textbaustein 8: Hinweis zu unterstützten Kombinationen aus Betriebssystem, Chipkartenlesegerät 

und Signaturkarte 

20


Unterstützte Signaturkarten (Tabellen zum Kopieren) 

Zertifizierungsdiensteanbieter 

(Gütezeichen 

BNetzA) 

Produktzentrum 

TeleSec der Deutschen 

Telekom AG 

(Z0001) 

Bundesnotarkammer, 

Zertifizierungsstelle 

(Z0003) 

DATEV eG Zertifizierungsstelle 

(Z0004) 

D-Trust GmbH 

(Z0017) 

Deutsche Post Com 

GmbH Geschäftsfeld 

Signtrust (Z0002) 

TC TrustCenter 

TrustCenter GmbH 

(Z0032) 

S-Trust, Deutscher 

Sparkassen Verlag 

GmbH (Z0035) 

dgnservice (Z0033) 

Handelsname der 

Signaturkarte 

TeleSec NetKey 3.0 

mit PKS 

TeleSec Netkey 3.0M 

- Multisignatur - 

TeleSec NetKey 3.0 

mit PKS (Signature- 

Card 2.0) 

Bundesnotarkammer, 

Zertifizierungsstelle 

qual. elektronische 

Signatur 

- Stapelsignatur - 

zertifizierte Signaturkarte 

für Berufsträger 

der DATEV 

D-TRUST Card 2.4 2) 

D-TRUST Card 3.0 2) 

D-TRUST Card 3.0 

Multicard 100 

- Stapelsignatur – 2) 


Multicard 

- Multisignatur – 2) 

SIGNTRUST CARD 

SIGNTRUST MCARD 

100 

- Stapelsignatur - 

SIGNTRUST MCARD 


TC QSign (limited) 

TC QSign 

(unlimited) 


S-TRUST Card, SparkassenCard 

oder 

kontounabhängige 

GeldKarte 

dgnservice Card 

QES 

Chiffrierung 

Authentisierung 

 

 

nur QES 

kontaktbehaftet 

1) 

 

 

 

 

 

 

 

 

 

Name der SSEE in der 

Bestätigungsurkunde 

Signaturerstellungseinheit 

TCOS 3.0 Signature Card, 

Version 1.1 


TCOS 3.0 Signature Card, 

Version 2.0 Release 

1/SLE78CLX1440P 


STARCOS 3.2 QES Version 2 




„Chipkarte mit Prozessor 

SLE66CX322P (oder 

SLE66CX642P), Software 

CardOS V4.3B Re_Cert with 

Applikation for Digitale Signature“ 

Sichere Signaturerstellungseinheit 

STARCOS 3.4 Health 

QES C1 

Die Nachfolgeversion 

STARCOS 3.4 Health QES C2 

(siehe Nachtrag) wird auch 

unter dem Vertriebsnamen D- 

TRUST Card V3.0 geführt. 


STARCOS 3.2 QES Version 

2 









Signaturerstellungseinheit ZKA 

Banking Signature Card, 

Version 6.6 der Giesecke & 

Devrient GmbH 



1) Es wird nur die qualifizierte elektronische Signatur im kontaktbehafteten Modus unterstützt. 

2) Die Signaturkarte wird nur im Rahmen von Projekten angeboten 

Registrierungsnr. der 


der SSEE 

TUVIT.93146.TE.12.2006 

Nachtrag 1 vom 07.05.2010 

SRC.00016.TE.11.2012 

BSI.02114.TE.12.2008 


BSI.02114.TE.12.2008 


T-Systems.02182.TE.11. 

2006 



BSI.02120.TE.05.2009 


BSI.02114.TE.12.2008 


BSI.02114.TE.12.2008 


T-Systems.02182.TE.11. 

2006 



TUVIT.93130.TU.05.2006 




BSI.02114.TE.12.2008 

1. Nachtrag vom 08.03.2010 

Tabelle 8: Unterstützte Signaturkarten, dt. ZDA, QES mit Anbieterakkreditierung 

21




Signaturkarte 

QES 

Chiffrierung 





Bestätigungsurkunde der 

SSEE 

D-Trust GmbH 

D-TRUST Card 

2.4 qualified 

D-TRUST 

Multicard 


 







T-Systems.02182.TE.11. 2006 





Multicard 100 

- Stapelsignatur – 1) 


Multicard 


 

Sichere Signaturerstellungseinheit 

STARCOS 3.4 Health 

QES C1 

Die Nachfolgeversion 

STARCOS 3.4 Health QES C2 

(siehe Nachtrag) wird auch 

unter dem Vertriebsnamen D- 

TRUST Card V3.0 geführt. 

BSI.02120.TE.05.2009 


S-Trust, Deutscher 

Sparkassen Verlag 

GmbH 

S-TRUST Card 

 

SEE ZKA Banking Signature 

Card, Version 6.6 der Giesecke 

& Devrient GmbH 

TUVIT.93130.TU.05.2006 




Deutsche Rentenversicherung 

Bund 

(DRV) 2) 

Bundesagentur für 

Arbeit 2) 

S-TRUST Card 


Signaturkarte der 

Deutschen Rentenversicherung 

Bund 

(DRV) 

Multisignaturkarte der 

Deutschen Rentenversicherung 

Bund 

(DRV) 

Signaturkarte der 

Bundesagentur für 

Arbeit (BA) 

 

 

 

 

 

SEE ZKA-Signaturkarte, 

Version 6.32 der Gemalto 

GmbH 


ZKA Banking Signature Card, 

Version 7.1.2 der Giesecke & 

Devrient GmbH 


ZKA-Signaturkarte, Version 

6.32 M 













TUVIT.93184.TU11.2010 


TUVIT.93166.TU.06.2008 



TUVIT.93176.TU.05.2011 

T-Systems.02182.TE.11. 2006 



T-Systems.02182.TE.11. 2006 



1) Die Signaturkarte wird nur im Rahmen von Projekten angeboten 

2) Die Signaturkarte wird nur an Mitarbeiter der jeweiligen Behörde ausgegeben (geschlossene Nutzergruppe). 

Tabelle 9: Unterstützte Signaturkarten, dt. ZDA, QES 

22


Trustcenter 

Deutschland-Online 

Infrastruktur (DOI) 

CA 1) 


Signaturkarte 

Signaturkarte der T- 

Systems Netkey 3.0 

Fortg. 

Signatur 

Chiffrierung 


 

Hessen-PKI 2) Signaturkarte der T- 

Systems Netkey 3.0 

und 3.01 mit Hessen- 

PKI-Zertifikat 

3) 

Europäisches Patentamt 

- European 

Patent Office (EPO) 

VR Bank 

Online Services Smart 

Card Epoline 

VR-BankCard 

VR-NetworldCard 

 

 



SEE TCOS 3.0 Signature 

Card, Version 1.1 

SEE TCOS 3.0 Signature 

Card, Version 1.1 

-- -- 

-- -- 


Bestätigungsurkunde der 

SSEE 

TUVIT.93146.TE.12.2006 


TUVIT.93146.TE.12.2006 


1) Die Signaturkarte wird nur an Mitarbeiter von Behörden im Kontext DVDV ausgegeben. 

2) Die Signaturkarte wird nur an Mitarbeiter hessischer Behörden ausgegeben. 

3 Keine Chiffrierung möglich. Diese Signaturkarte kann zusätzlich auch mit einem qualifizierten Signaturzertifikat (mit Anbieterakkreditierung) 

des Public Key Service des Produktzentrum TeleSec der Deutschen Telekom AG personalisiert werden. 

Die QES wird dann unterstützt. 

Tabelle 10: Unterstützte Signaturkarten, fortgeschrittene elektronische Signatur 

Trustcenter 

A-Trust GmbH 5) 

InfoNotary 

SwissSign AG 

QuoVadis Trustlink 

Schweiz AG 

Swisscom Schweiz 

AG 


Signaturkarte 

A-TRUST premium 

InfoNotary QSign 

PostSuisseID 

QuoVadis SuisseID 

Qualified Certificate 

Diamant 4) 

InfoCert S.P.A InfoCert S.P.A 4) 

CertiNomis Commercial 

Service 

Person @ Poste 4) 

Qualifizierte 

Signatur 

1) 

 

 

 

 

 

 

 

Staat 

Österreich 2) 

Betriebssystem des 

Kartenchips (CardOS) 

ACOS EMV 

Bulgarien 2) Siemens CardOS 4.3b 

Schweiz 3) Siemens CardOS 4.3b 



Italien 2) -- 

Frankreich 2) -- 

1) unterstützt wird nur QES (QES nach dem national geltenden Signaturgesetz) 

2) nach EU-Direktive innerhalb der EU als QES anerkannt 

3) nach EU-Direktive außerhalb der Schweiz nicht als QES anerkannt 

4) lag zum Zeitpunkt der Karteneinbindung nur als Testkarte vor 

5) Einschränkungen in der Verwendung der Karte mit Governikus-Komponenten möglich 

Tabelle 11: Unterstützte Signaturkarten ausgewählter Trustcenter aus dem europäischen 

Ausland 

23


Terminalserver 

Die MCard-Varianten unterstützen den PC/SC-Standard. Dieser bietet zur Ansteuerung von 

Kartenlesern eine einheitliche Schnittstelle. Die unterstützten Betriebssysteme bieten einen 

Smartcard-Dienst, der von der MCard unter Verwendung dieses Standards adressiert wird. 

Die Treiber der Chipkartenlesegeräte (diese werden im Falle von Windows in der Regel vom 

Hersteller des Lesers bereitgestellt) stehen dann zwischen diesem Smartcard-Dienst und 

dem eigentlichen Chipkartenlesegerät. Hier kann auf weitere Treiber, etwa USB-Treiber, zurückgegriffen 

werden. So kann die MCard eine Vielzahl von Lesern unterstützen, so diese 

den PC/SC-Standard unterstützten. Wenn die Chipkartenlesegeräte-Treiber auch die Version 

2 dieses Standards im vollen Umfang beherrschen, können in der Regel auch PIN-Pad 

und Display der Chipkartenlesegeräte genutzt werden. 

Heutige Terminalserver-Software spielt über virtuelle USB-Schnittstellen dem Treiber eines 

Chipkartenlesegerätes vor, dass sich dieses am lokalen Rechner (dem Terminalserver) befindet, 

obwohl es sich tatsächlich an der Arbeitsstation des Nutzers befindet. Dies funktioniert 

häufig sehr gut, bedeutet aber auch, dass für die Funktionsfähigkeit der einzelnen Konstellationen 

die Hersteller der jeweils zum Einsatz kommenden Treiber und der Terminalserver- 

Software verantwortlich sind. D. h., es liegt in der Regel nicht in der Verantwortung der 

MCard, wenn Kombinationen nicht funktionieren. Auch kann eine Funktionsfähigkeit nicht 

durch Änderungen in der MCard herbeigeführt werden. Dieses gilt insbesondere für nicht 

aufgeführte Client-Betriebssysteme, die keine dynamische Kartenlesererkennung unterstützen. 

Freigeben zur Nutzung wird daher nur ein Subset der grundsätzlich mit der MCard unterstützten 

Betriebssysteme-Kartenleser-Kombinationen. Ob eine Kombination von Signaturkarte, 

Chipkartenleser, Terminalserversoftware, Serverbetriebssystem und Clientbetriebssystem 

unterstützt wird, ist der zu entnehmen. Bei einer Clientapplikation, die eine SAK (also zur 

Erzeugung von qualifizierten elektronischen Signaturen verwendet werden kann) im Sinne 

des Signaturgesetztes darstellt, muss diese Tabelle in die Anwenderdokumentation aufgenommen 

werden, da die benannten Einsatzumgebungen und unterstützten Chipkartenlesegeräte 

in einer Positivliste zu veröffentlichen sind. 

In diesem Fall sollte der folgende Hinweis in die Anwenderdokumentation aufgenommen 

werden, da er das Verständnis für die Unterstützungsproblematik erleichtert: 

24



Heutige Terminalserver-Software spielt über virtuelle USB-Schnittstellen dem Treiber eines 

Chipkartenlesegerätes vor, dass sich dieses am lokalen Rechner (dem Terminalserver) 

befindet, obwohl es sich tatsächlich an der Arbeitsstation des Nutzers befindet. Dies funktioniert 

häufig sehr gut, bedeutet aber auch, dass für die Funktionsfähigkeit der einzelnen 

Konstellationen die Hersteller der jeweils zum Einsatz kommenden Treiber und der Terminalserver-Software 

verantwortlich sind. D. h., es liegt in der Regel nicht in der Verantwortung 

der Client-Anwendung, wenn Kombinationen nicht funktionieren. Auch kann eine 

Funktionsfähigkeit nicht durch Änderungen in der der Client-Anwendung herbeigeführt 

werden. Dieses gilt insbesondere für nicht aufgeführte Client-Betriebssysteme, die keine 

dynamische Kartenlesererkennung unterstützen. 

Freigeben zur Nutzung wird daher nur ein Subset der insgesamt durch diese Clientapplikation 

unterstützten Betriebssystem-Kartenleser-Kombinationen. Ob eine Kombination von 

Signaturkarte, Chipkartenleser, Terminalserversoftware, Serverbetriebssystem und Clientbetriebssystem 

unterstützt wird, ist der Tabelle „Unterstützte Einsatzumgebungen Terminalserver“ 

zu entnehmen. 

Textbaustein 9: Erläuterung unterstützte Einsatzumgebungen Terminalserver 

25

TeleSec 

DP-Com 

Datev 

BNotK 

TC-Trust 

D-Trust 

S-Trust 

DRV-Bund 

DGN 

Hessen-PKI 

TeleSec 

DP-Com 

Datev 

BNotK 

TC-Trust 

D-Trust 

S-Trust 

DRV-Bund 

DGN 

Hessen-PKI 

TeleSec 

DP-Com 

Datev 

BNotK 

TC-Trust 

D-Trust 

S-Trust 

DRV-Bund 

DGN 

Hessen-PKI 


Clientbetriebssystem: 

Serverbetriebssystem: 

Windows XP Prof. SP3 32 Bit 

Windows 2003 Server R2 SP2 64 Bit 

Terminalserver: Citrix Metaframe Presentation Server 4.5 

Windows Terminal Server 2003 

Handelsname 

des 

Chipkartenlesegeräts 

Schnitt 

-stelle 

Firmware Treiber Zertifizierungsdiensteanbieter 

Cherry® Smart- 

Terminal 2000 U 

CyberJack® 

e-com 

Kobil KAAN 

Advanced 

USB 6.01.00.00 4.45.0.0 

USB 3.0.69 6.10.0.SP2 

USB 1.19 2011.12.19.4 

Omnikey 3821 USB 6.00 1.2.6.5 



- 1) 

- 1) 

-1) 

- 1) 

Windows XP Prof. SP3 32 Bit 

Windows 2008 Server Enterprise 32 Bit 

Terminalserver: Windows Terminal Server 2008 

Handelsname 

des 


Schnittstelle 

Firmware Treiber Zertifizierungsdiensteanbieter 

Cherry® Smart- 

Terminal 2000 U 

CyberJack® 

e-com 


USB 6.01.00.00 4.45.0.0 

USB 3.0.69 6.10.0.SP2 

USB 1.19 2011.12.19.4 

Omnikey 3821 USB 6.00 1.2.6.5 



- 1) 

- 1) 

- 1) 

- 1) 

Thin Client elux RL V3.7.1-1 mit PC/SC lite V2.1.6.4-5 

und CCID V1.4.0-1 

Windows 2003 Server R2 SP2 64 Bit 

Terminalserver: Windows Terminal Server 2003 

Handelsname 

des 


Schnittstelle 

Firmware 

Treiber 

PC/SC lite 

V2.1.6.4-5 



CyberJack® e-com 

plus 

CyberJack® RFID 

komfort 

USB 1.19 

USB 3.0.7 

USB 2.0.7 

2) -1) - 

2) -1) - 

2) -1) - 

1) Die Karte wird nur an Mitarbeiter der Deutschen Rentenversicherung Bund ausgegeben. 

2) die neue Signaturkarte der TeleSec (NetKey 3.0 SignatureCard 2.0) basierend auf der Signaturerstellungseinheit TCOS 3.0 

Signature Card, Version 2.0 Release 1/SLE78CLX1440P wird nicht unterstützt. 

Tabelle 12: Unterstützte Einsatzumgebungen Terminalserver 

26


5 Technische Informationen zur MCard 

Die MCard ist eine Funktionsbibliothek in der Programmiersprache Java, die die Verwendung 

von Kartenlesern über das OpenCard-Framework (OCF) und den Zugriff auf Signaturkarten 

durch einen speziellen JCE/JCA-Kryptoprovider ermöglicht. 

Das OCF unterteilt sich in zwei Teile: einerseits die CardTerminal-Klassen, welche die Funktionalität 

des Kartenterminals in einer Java-Klasse kapseln, und andererseits die verschiedenen 

CardService-Klassen, welche die unterschiedlichen Funktionen einer Chipkarte in 

entsprechenden Java-Klassen kapseln. OCF kennt konzeptionell schon Klasse-3-Terminals 

und bietet für einen Großteil der Funktionen von Chipkarten bereits vordefinierte Schnittstellen. 

Der Provider ermöglicht eine einheitliche Behandlung von Signaturkarten, indem er 

Signatur-, Chiffrierungs- und Authentisierungsdienste zur Verfügung stellt. Der vom Provider 

bereitgestellte KeyStore enthält alle gefundenen Schlüssel aller erkannten Signaturkarten. Im 

Fall spezieller Karten ist es ggf. notwendig, den korrekten Sicherheitszustand herzustellen, 

damit der Schlüssel mit seinem Zertifikat durch den Provider im KeyStore bereitgestellt werden 

kann. 

Zu diesem Zweck wird das OCF, das den Zugriff auf Kartenleser verwaltet und das Absetzen 

von Kommandos für Karten und Leser regelt, gekapselt. Die Benutzung des Providers wird 

ausführlich im Entwicklerhandbuch beschrieben. 

Jede kartenspezifische Implementierung erfolgt in einer von CardService abgeleiteten Klasse. 

Die Erkennung erfolgt in einer MCard spezifischen Implementierung der Klasse CardServiceFactory 

des OCF. Die Schnittstelle der CardService-Kartenimplementierungen enthält 

sowohl Funktionen zur Erkennung und Struktur einer Karte als auch die Funktionen für das 

Signieren, Entschlüsseln, Authentisieren, Verifizieren und Ändern einer PIN. Die OCF spezifischen 

Fehlermeldungen werden in den JCE/JCA-Provider-Klassen in konforme Fehlermeldungen 

umgesetzt. 

Der PIN-Dialog wird dem Benutzer angezeigt, wenn eine PIN für einen Schlüssel eingegeben 

werden muss. Über die Implementierung des PIN-Dialogs kann die Kommunikation mit 

dem Benutzer in unterschiedlicher Weise gestaltet werden. Dies beinhaltet die Beeinflussung 

des Aussehens, die Anzeige von Informationen über den verwendeten Schlüssel und Eingabeaufforderungen. 

Für Klasse 1-Kartenleser erfolgt über den Dialog auch die Eingabe der 

PIN. Bei der PIN-Dialog-Schnittstelle handelt sich um ein Java-Interface, das je nach Anforderung 

zum Anzeigen einer sichtbaren Java-Komponente, wie einem JDialog, benutzt werden 

kann, aber auch die Steuerung über die Konsole ermöglicht. Der letzte Fall ist insbesondere 

für Server interessant, die unter Umständen nur über eine Kommandozeile verfügen. 

Die genaue Implementierung ist im OSCI-Client-Enabler-Handbuch beschrieben. 

Ein Chipkartenleser ist ein Peripheriegerät. Wie bei jedem anderen Gerät wird seine Funktionalität 

dem PC über einen entsprechenden Treiber zur Verfügung gestellt. Hier gibt es viele 

unterschiedlich komplexe Treiberkonzepte, die auf unterschiedlichen Standards beruhen. 

Die MCard verwendet als Default den international sehr weit verbreiteten plattformunabhängigen 

PC/SC-Standard zur Kommunikation mit Chipkartenlesern, die in Form einer C- 

basierten Betriebssystemschnittstelle unter Windows, Linux und Mac OS verwendet werden 

kann (bei MacOS mit Einschränkungen). Die meisten für die qualifizierte elektronische Signatur 

in Deutschland zugelassenen Chipkartenlesegeräte verwenden PC/SC, nur einige we- 

27


nige Chipkartenlesegeräte unterstützen ausschließlich den CT-API-Standard (unter Verwendung 

des Basic Command Set -BCS). Für diesen Fall existiert eine Konfigurationsmöglichkeit, 

um auch diese Kartenlesegeräte verwenden zu können. 

PC/SC-Standard 

Im Dezember 1997 wurde die Version PC/SC 1.0 der aus acht Teilen bestehenden „Interoperability 

Specification for ICCs and Personal Computer Systems“ veröffentlicht. PC/SC 

ist komplex und spricht als Version 1.0. konzeptionell nur Klasse 1-Chipkartenterminals an, 

d. h., Treiber auf Basis von PC/SC 1.0 bieten keine Möglichkeit, PIN-Pad und Display eines 

Kartenlesers zu verwenden. Dieses ist erst seit der Erweiterung der PC/SC 2.0 Spezifikation 

möglich, die die alte Spezifikation um den Part 9 und 10 ergänzen. Diese beschreiben die 

Abfrage und Verwendung von speziellen Funktionen eines Kartenlesers und die darauf basierende 

Unterstützung eines Chipkartenterminal–PIN-Pads. 

PC/SC teilt sich in drei Teile auf: den Resource Manager, die Service Provider und die Interface 

Device Handler (IFD-Handler). Der IFD-Handler stellt den entsprechenden Gerätetreiber 

zur Anbindung des Kartenterminals dar. Sämtliche Funktionalitäten des Kartenterminals 

werden hier in einem C++ Objekt gekapselt, sodass diese ohne Kenntnis der zugrunde liegenden 

Schnittstelle genutzt werden können. Die Funktionalitäten einer Chipkarte werden in 

einem Service Provider Objekt abgebildet. Da gleichzeitig mehrere Chipkarten und Kartenterminals 

angemeldet und betrieben werden können, müssen diese zentral verwaltet werden. 

Diese Aufgabe übernimmt der Resource Manager. Die MCard ist im Sinne von PC/SC ein 

ICC-ServiceProvider. 

PC/SC ist sehr weit verbreitet und wird häufig auch als Basis anderer Treiberstandards verwendet, 

wobei herstellerspezifische Erweiterungen über den PC/SC-Standard hinaus weitere 

Funktionalitäten zur Verfügung stellen. Meldungen können allerdings in PC/SC 2.0 nur aus 

einem vorher festgelegten Satz von Meldungen für verschiedene Sprachen gewählt werden. 

Die Treiber-Schnittstelle von PC/SC sieht die Möglichkeit vor, den Zugriff auf Kartenleser in 

zwei Modi zu ermöglichen. Im Modus EXCLUSIVE erhält die Anwendung den exklusiven 

Zugriff auf den Kartenleser und sperrt den Kartenleser für alle anderen Anwendungen und 

SAKs. Im Modus SHARED können alle Anwendungen und SAK gleichzeitig den Kartenleser 

verwenden. Dabei tritt das Problem auf, dass zwei Anwendungen sich gegenseitig blockieren 

können und im schlimmsten Fall dazu, dass eine Karte teilweise oder ganz unbrauchbar 

wird. Häufig passiert es, dass meist nur eine Anwendung die Karte korrekt erkennt und damit 

korrekt verwenden kann. Dies geschieht, weil der Zugriff der Anwendungen nicht synchronisiert 

wird. 

Die MCard verwendet den SHARED-Modus. Die beschriebenen Probleme treten ab der 

Version 1.12.0.0 der MCard nicht mehr auf, da ab dieser Version die in PC/SC definierte 

Transaction-Funktionalität des PC/SC-Resource Managers verwendet wird. Dadurch erfolgt 

ein temporär exklusiver Zugriff auf Karte und Kartenleser. Diese Synchronisation funktioniert 

auch bei gleichzeitiger Installation einer Anwendung oder SAK eines anderen Herstellers 

oder bei der Verwendung einer älteren MCard. Nach dem Ende der Transaktion ist es einer 

anderen Anwendung wieder möglich, die Karte zu verwenden. Sowohl die Erkennung einer 

Karte als auch die Verwendung einzelner Funktionen der Karte sind synchronisiert. 

28


CT-API-Standard 

Das Card Terminal Application Program Interface, CT-API, ist ein NUR in Deutschland verbreiteter 

Standard. Der Herausgeber der Spezifikation ist Teletrust Deutschland. Ein CT-API 

Treiber ist als eine Funktionsbibliothek realisiert, die nur drei Funktionen kennt: CT_INIT, 

CT_DATA und CT_CLOSE. Mit CT_INIT wird die Schnittstelle initialisiert und die Verbindung 

zum Chipkartenterminal hergestellt. Mit CT_DATA können Daten, z.B. Kommandos (APDU – 

Application Protocol Data Unit), zum Chipkartenterminal oder zur Chipkarte gesendet und die 

zugehörigen Antworten empfangen werden. CT_CLOSE beendet schließlich die Kommunikation. 

Im Bankenbereich und Gesundheitsbereich wird zurzeit in Deutschland ausschließlich CT- 

API (Interfaces für C++) in Kombination mit dem MKT-Standard (siehe unten) verwendet, 

wobei der MKT-Standard die Inhalte der Übertragung festlegt, während die CT-API eine einfache 

Kommunikation zum Kartenleser über einen Port bietet. Über CT-API können sowohl 

synchrone als auch asynchrone Protokolle verwendet werden. Die Verwendung von Pinpad 

und Display ist möglich, wobei sowohl Standardmeldungen (meist nur in einer Sprache) als 

auch frei bestimmbare Meldungen möglich sind. Der Zeichensatz ist dabei aber auf den 

ASCII-Zeichensatz begrenzt. 

Ein Nachteil von CT-API ist, dass die Verbindung zum Kartenleser und Karte für jede Verwendung 

auf- und abgebaut wird. Dies ist aber software-technisch ebenso lösbar, wie die 

Benachrichtigung über Einstecken und Entfernen von Karten. 

Die MCard baut beim Start eine Verbindung zum Kartenleser auf. Der Zugriff ist exklusiv, 

d.h. andere Anwendungen können den Kartenleser nicht verwenden. Durch ein Polling des 

Kartenleserstatus werden das Einstecken und Entfernen von Karten automatisch erkannt. 

5.1 Nutzung der MCard 

Konfiguration der MCard-Bibliothek 

Zur Konfiguration der MCard-Bibliothek im OSCI-Client-Enabler lesen Sie bitte die Ausführungen 

zur Kartenansteuerung in den Handbüchern "OSCI-Client-Enabler allgemeine Funktions- 

und Schnittstellenbeschreibung" und „Governikus-OSCI-Enabler-Entwicklerhandbuch“. 

Austausch der MCard Bibliothek 

Zum Austausch der MCard gehen Sie bitte wie folgt vor: 

a) Bitte entpacken Sie das Archiv GOVERNIKUS_3_MCARD_x_xx_x_x.zip. 

b) Entfernen Sie das alte Java-Archiv mcard.jar in Ihrer Applikation. 

c) Das neue mcard.jar befindet sich im Ordner \MCard\Software des Archivs. 

d) Kopieren Sie bitte das neue Java-Archiv in Ihre Applikation. 

e) Optional: Kopieren Sie bitte die nativen Bibliotheken in den Java-Suchpfad für native Bibliotheken 

(Java-SystemProperty: „java.library.path“, Hinweis: der Suchpfad kann zur Laufzeit 

nicht geändert werden). 

29


Zum Einsatz der neuen Bibliothek muss eine neue Version der nativen Bibliothek (ab MCard 

1.15.0.0) eingesetzt werden. 

Von der MCard verwendete Bibliotheken 

Als Java-Bibliotheken werden die Standard Logging Bibliotheken für commons-logging, log4j 

von Apache, der JCA/JCE-Provider von Bouncy Castle und der Governikus Crypto Provider 

von bremen online services benötigt. 

Bei Verwendung des Standard-PIN-Eingabedialoges der MCard muss außerdem eine kompatible 

Version des ci.jar (Certificate Interpreter) ab 1.5.0 eingesetzt werden. Dies auch der 

Fall wenn die MCard in einem eigenen Projekt genutzt wird. Bitte wenden Sie sich in diesem 

Fall an unseren Servicedesk (servicedesk@bos-bremen.de). 

Konfiguration von Treibern (Bundles) unter Linux/MacOS 

Die MCard unterstützt unter Linux und MacOS sowohl Treiber der Hersteller als auch den 

generischen CCID-Treiber des PC/SC Lite Projektes (http://pcsclite.alioth.debian.org/). Die 

Treiber Bundles müssen für die Unterstützung der sicheren PIN-Eingabe unterschiedlich 

angesteuert werden. Bei Verwendung des generischen Treiber-Bundles „ifd-ccid.bundle“ ist 

im Verzeichnis „Contents“ die XML-Datei „Info.plist“ muss daher angepasst werden. Hierzu 

sind im Abschnitt „ifdFriendlyName“ ein ‚*‘ am Anfang der Namen ergänzen. 

Die Treiber/Bundles befinden sich bei MacOS im Verzeichnis: 

„/usr/libexec/SmartCardServices/drivers“. 

Unter Linux befinden sich die Treiber normalerweise im Order usr/lib/pcsc/drivers“ für ein x86 

(32bit) und „/usr/lib64/pcsc/drivers“ für ein x86_64 (64bit) System. 

Verwendung der CT-API Schnittstelle 

In dem MCard-Verzeichnis befindet sich für die Nutzung von CT-API Kartenlesern eine Konfigurationsdatei 

namens userConf.xml. Die Datei muss bei Verwendung der CT-API Schnittstelle 

in das User-Verzeichnis des Betriebssystems kopiert und konfiguriert werden. Dieser 

Schritt ist nicht notwendig, wenn Sie einen PC/SC Kartenleser verwenden. Wenn Sie die CT- 

API Schnittstelle verwenden möchten, wenden Sie bitte zwecks Konfiguration an den Servicedesk 

der bos KG (servicedesk@bos-bremen.de). 

Verwendung der MCard unter JWS 

Der Einsatz der MCard in einer Application über Java Web Start setzt einen Standard Web 

Server, die Definition geeigneter JNLP-Dateien und Java-Bibliotheken voraus. 

30


Die nativen Bibliotheken stehen in der Auslieferung als signierte Jars namens jnijsb.jar zur 

Verfügung. Die nativen Bibliotheken können für das Zielsystem selbst signiert werden, sollte 

dies notwendig sein. 

Installation Citrix 

Die Installation für Citrix Metaframe 4.5 Standard und Windows-Terminalserver ist jeweils in 

der benannten Reihenfolge vorzunehmen: 

1. Server-Betriebssystem mit allen Servicepacks und allen Patches installieren 

2. Citrix Metaframe 4.5 Standard bzw. die Option Windows-Terminalserver installieren 

3. Client-Betriebssystem mit aktuellem Servicepack und allen aktuellen Patches installieren 

4. Treiber für das Chipkartenterminal installieren 

5. Clientanwendung über den Citrix-Administrator freigeben. Die benötigten Ports werden 

automatisch gemappt. 

5.2 Benötigte Bibliotheken 

Third-Party Bibliotheken 

Das MCard.jar enthält das OpenCard-Framework. 

Native Bibliotheken 

Seit der MCard 1.15.0.0 werden neue native Bibliotheken zur Unterstützung von 32bit/64bit- 

Systemen/Java unter Windows und Linux verwendet. Ein Update der dll/so ist daher zwingend 

erforderlich, sollte die aktuelle MCard eine Version kleiner als MCard 1.15.0.0 ersetzen. 

Seit der Version 1.15.0.0 heißen die native Bibliotheken jsb.dll für Windows, libjsb.so für 

Linux und libjsb.jnilib für MacOS (ab 10.6 Snow Leopard). Sie unterstützen die Erweiterungen 

für PC/SC 2.0 und CT-API. Es werden die Funktionen „beginTransaction“ und „end- 

Transaction“ für einen synchronisierten Zugriff auf Kartenlesegeräte unterstützt. 

31


Anhang 1: Tabellen der unterstützten Kombinationen Betriebssystem 

- Chipkartenlesegerät – Signaturkarte 

Tabellen zum Kopieren auf den folgenden Seiten. 

32

TeleSec 

DP-Com 

Datev - 

BNotK 

BA 

TC-Trust 

D-Trust 

S-Trust 

DRV- 

Bund 

DGN 

Hessen- 

PKI 


Handelsname des 


bestätigt/ 

HE nach 

SigG 

Windows XP Prof. SP 3 (32 und 64 Bit) 

Windows Vista Home Premium SP2 (32/64) 

Windows 7 Professional (32/64) 

Signaturkarten deutscher ZDA: 

Firmware 

Treiber 

Cherry® Smartboard G83-6744 ja 01.04.00.00 PC/SC: 1.2.6.5 2) 

Cherry® SmartTerminal 2000 U ja 6.01.00.00 PC/SC: 4.53.0.0 2) 

CyberJack® e-com/ e-com plus ja 3.0.69/3.0.4 PC/SC: 6.10.0.SP2 2) 

CyberJack® pinpad Version 3/ secoder ja 3.0.12/3.0.14 PC/SC: 6.10.0.SP2 2) 

CyberJack® RFID standard 1) ja 1.2.16 PC/SC: 6.10.0.SP2 2) 

CyberJack® RFID komfort 1) ja 2.0.7 PC/SC: 6.10.0.SP2 2) 

Fujitsu Siemens KB SCR eSIG ja 1.20 PC/SC: 1.9.0.0 2) 

Fujitsu Siemens KB SCR Pro ja 1.06 PC/SC: 1.2.6.5 2) 

Kobil KAAN Advanced ja 1.19 PC/SC: 2011.12.19.4 2) 

Kobil SecOVID 3, EMV-TriCap/ Trib@nk ja 82.23/79.23 PC/SC: 2011.12.19.4 2) 

Omnikey CardMan 3121 nein 2.03 PC/SC: 1.2.6.5 2) 

Omnikey CardMan 3621, 3821 ja 6.00 PC/SC: 1.2.6.5 2) 

Omnikey Cardman 5321 RFID 1) nein 5.10 PC/SC: 1.2.9.2 2) 

ORGA 6041 Version 2.07 ja 2.07 PC/SC: 2.0.0.6 2) 

SCM SCR 3310 nein nicht bekannt PC/SC: 4.58.0.0 2) 

SCM SCR 3311 (Chipdrive desktop pro) nein nicht bekannt PC/SC: 4.58.0.0 2) 

SCM SDI011 RFID 1) nein 7.36 PC/SC: 5.21.0.0 2) 

SCM SPR 332 usb (Chipdrive pinpad) ja 6.01 PC/SC: 4.53.0.0 2) 

SCR 335 (Chipdrive micro pro) nein 5.3.2 PC/SC: 4.58.0.0 2) 

eHealth BCS 200 ja 2.01 PC/SC: 1.2.0.0 2) 

CARD STAR/ medic Version 2 ja M1.53G WinUSB 2.51 und CTAPI 2.70, 

ct_api_com.dll 3) 2) 

medCompact eHealth ja 02.00 CTAPI 0300, cthyc32.dll 3) 

2) 

GT900 BCS ja 1.0.10 ctgt900.dll von Support-CD 1.3 3) 

2) 

Omnikey 8751 e-Health LAN ja 1.3.2 ct8751com.dll von Support-CD 3) 

2) 

1) unterstützt wird nur das kontaktbehaftete Interface 

2) bei der neuen Signaturkarte der TeleSec (NetKey 3.0 SignatureCard 2.0) basierend auf der Signaturerstellungseinheit TCOS 3.0 Signature Card, Version 2.0 Release 

1/SLE78CLX1440P wird nur die qualifizierte elektronische Signatur im kontaktbehafteten Modus unterstützt. 

3) nur ct-api, dll nur 32 Bit Java 

Tabelle 13: Unterstützte Kombinationen Windows XP, Vista, 7 (32 und 64 Bit) - Chipkartenlesegerät – Signaturkarte 

- 33 -

TeleSec 

DP-Com 

Datev - 

BNotK 

BA 

TC-Trust 

D-Trust 

S-Trust 

DRV- 

Bund 

DGN 

Hessen- 

PKI 




bestätigt/ 

HE nach 

SigG 

Windows 8 Professional (32 und 64 Bit) 

Firmware 

Treiber 


Cherry® Smartboard G83-6744 ja 01.04.00.00 PC/SC: 1.2.12.12 2) 

Cherry® SmartTerminal 2000 U ja 6.01.00.00 PC/SC: 4.53.0.0 2) 

CyberJack® e-com/ e-com plus ja 3.0.69/3.0.4 PC/SC: 6.10.0.SP2 2) 

CyberJack® pinpad Version 3/ secoder ja 3.0.12/3.0.14 PC/SC: 6.10.0.SP2 2) 

CyberJack® RFID standard 1) ja 1.2.16 PC/SC: 6.10.0.SP2 2) 

CyberJack® RFID komfort 1) ja 2.0.7 PC/SC: 6.10.0.SP2 2) 

Fujitsu Siemens KB SCR eSIG ja 1.20 PC/SC: 1.9.0.0 2) 

Fujitsu Siemens KB SCR Pro ja 1.06 PC/SC: 1.2.12.12 2) 

Kobil KAAN Advanced ja 1.19 PC/SC: PC/SC: 2011.12.19.4 2) 

Kobil SecOVID 3, EMV-TriCap/ Trib@nk ja 82.23/79.23 PC/SC: 2011.12.19.4 2) 

Omnikey CardMan 3121 nein 2.03 PC/SC: 1.2.6.5 2) 

Omnikey CardMan 3621, 3821 ja 6.00 PC/SC: 1.2.6.5 2) 

Omnikey Cardman 5321 RFID 1) nein 5.10 PC/SC: 1.2.9.2 2) 

ORGA 6041 Version 2.07 ja 2.07 PC/SC: 2.0.0.6 2) 

SCM SCR 3310 nein nicht bekannt PC/SC: 4.58.0.0 2) 

SCM SCR 3311 (Chipdrive desktop pro) nein nicht bekannt PC/SC: 4.58.0.0 2) 

SCM SDI011 RFID 1) nein 7.36 PC/SC: 5.21.0.0 2) 

SCM SPR 332 usb (Chipdrive pinpad) ja 6.01 PC/SC: 4.53.0.0 2) 

SCR 335 (Chipdrive micro pro) nein 5.3.2 PC/SC: 4.58.0.0 2) 

eHealth BCS 200 ja 2.01 PC/SC: 1.2.0.0 2) 

CARD STAR/ medic Version 2 ja M1.53G Keine Treiber verfügbar - - - - - - - - - - 

medCompact eHealth ja 02.00 CTAPI 0300, cthyc32.dll 3) 2) 

GT900 BCS ja 1.0.10 Keine Treiber verfügbar - - - - - - - - - - 

Omnikey 8751 e-Health LAN ja 1.3.2 Keine Treiber verfügbar - - - - - - - - - - 



1/SLE78CLX1440P wird nur die qualifizierte elektronische Signatur im kontaktbehafteten Modus unterstützt. 

3) nur ct-api, dll nur 32 Bit Java 

Tabelle 14: Unterstützte Kombinationen Windows 8 (32 und 64 Bit) - Chipkartenlesegerät – Signaturkarte 

34

TeleSec 

DP-Com 

Datev - 

BNotK 

BA 

TC-Trust 

D-Trust 

S-Trust 

DRV- 

Bund 

DGN 

Hessen- 

PKI 




bestätigt/ 

HE nach 

SigG 

OpenSUSE 12.1 (32 Bit) 

Firmware 

Treiber für Daemon- PCSClite 

Version 1.8.3 3) 


Cherry® Smartboard G83-6744 ja 01.04.00.00 ifdokccid-lnx-3.7.0 2) 2) 

Cherry® SmartTerminal 2000 U ja 6.01.00.00 scmccid 5.0.21 4) 

CyberJack® e-com/ e-com plus ja 3.0.69/3.0.4 ifd-cyberjack 3.9.9.5 4) 

CyberJack® pinpad Version 3/ secoder ja 3.0.12/3.0.14 ifd-cyberjack 3.9.9.5 4) 

CyberJack® RFID standard 1) ja 1.2.16 ifd-cyberjack 3.9.9.5 4) 

CyberJack® RFID komfort 1) ja 2.0.7 ifd-cyberjack 3.9.9.5 4) 

Fujitsu Siemens KB SCR eSIG ja 1.20 Keine Treiber verfügbar - - - - - - - - - - 

Fujitsu Siemens KB SCR Pro ja 1.06 CCID 1.4.6 3) 4)5) 2) 2) 2) 

Kobil KAAN Advanced ja 1.19 CCID 1.4.6 3) 4) 

Kobil SecOVID 3, EMV-TriCap/ Trib@nk ja 82.23/79.23 CCID 1.4.6 3) 4) 

Omnikey CardMan 3121 nein 2.03 ifdokccid-lnx-3.7.0 4)5) 

Omnikey CardMan 3621, 3821 ja 6.00 ifdokccid-lnx-3.7.0 4)5) 

Omnikey Cardman 5321 RFID 1) nein 5.10 ifdokrfid_lnx-2.9.1 4)5) 

ORGA 6041 Version 2.07 ja 2.07 V 1.7 4) 

SCM SCR 3310 nein nicht bekannt CCID 1.4.6 3) 4) 

SCM SCR 3311 (Chipdrive desktop pro) nein nicht bekannt CCID 1.4.6 3) 4) 

SCM SDI011 RFID 1) nein 7.36 scmccid 5.0.21 4) 

SCM SPR 332 usb (Chipdrive pinpad) ja 6.01 CCID 1.4.6 3) 4) 

SCR 335 (Chipdrive micro pro) nein 5.3.2 scmccid 5.0.21 4) 

eHealth BCS 200 ja 2.01 V 1.04 4) 

CARD STAR/ medic Version 2 ja M1.53G libctapi-celectronic.so.0.0.0 

von Support-CD 2.3 6) 4) 

 

 

medCompact eHealth ja 02.00 libcthyc-01.04.so 6) 2)4) 

GT900 BCS ja 1.0.10 Keine Treiber verfügbar - - - - - - - - - - 

Omnikey 8751 e-Health LAN ja 1.3.2 Keine Treiber verfügbar - - - - - - - - - - 


2) keine Entschlüsselung mit der TeleSeckarte TeleSec NetKey 3.0 mit PKS basierend auf Signaturerstellungseinheit TCOS 3.0 Signature Card, Version 1.1 möglich 

3) Bei generischen CCID-Treibern muss der Name des Lesers mit * angeführt werden 


1/SLE78CLX1440P wird nur die qualifizierte elektronische Signatur im kontaktbehafteten Modus unterstützt 

5) keine Unterstützung der TeleSeckarte TeleSec NetKey 3.0 mit PKS basierend auf Signaturerstellungseinheit TCOS 3.0 Signature Card, Version 1.1. 

6) nur ct-api 

Tabelle 15: Unterstützte Kombinationen OpenSUSE 12.1 (32 Bit) - Chipkartenlesegerät – Signaturkarte 

35

TeleSec 

DP-Com 

Datev - 

BNotK 

BA 

TC-Trust 

D-Trust 

S-Trust 

DRV- 

Bund 

DGN 

Hessen- 

PKI 




bestätigt/ 

HE nach 

SigG 

Mac OS X 10.6.8 (32 Bit) 1) 

Firmware 

Treiber für Daemon- PCSClite 

Version 1.4.0 


Cherry® Smartboard G83-6744 ja 01.04.00.00 Ifdokccid_mac 3.1.0.2 

Cherry® SmartTerminal 2000 U ja 6.01.00.00 scmccid 5.0.21 3) 

CyberJack® RFID komfort 2) ja 2.0.7 ifd-cyberjack 3.9.9.5 3) 

Omnikey CardMan 3121 nein 2.03 Ifdokccid_mac 3.1.0.2 

Omnikey CardMan 3621, 3821 ja 6.00 Ifdokccid_mac 3.1.0.2 

SCM SPR 332 usb (Chipdrive pinpad) ja 6.01 scmccid 5.0.21 3) 

Kobil KAAN Advanced ja 1.19 CCID 1.4.6 3) 

1) Einschränkungen in der Funktionsunterstützung des Betriebssystems mit Governikus-Komponenten möglich 

2) unterstützt wird nur das kontaktbehaftete Interface; PC/SC-Daemon bitte nicht manuell starten 

3) die neue Signaturkarte der TeleSec (NetKey 3.0 SignatureCard 2.0) basierend auf der Signaturerstellungseinheit TCOS 3.0 Signature Card, Version 2.0 Release 

1/SLE78CLX1440P wird nicht unterstützt 

Tabelle 16: Unterstützte Kombinationen Max OS X 10.6.8 Snow Leopard (32 Bit) - Chipkartenlesegerät - Signaturkarte 

36


Anhang 2: Änderungsnachweis Tabellen und Textbausteine 

Hinweis. Bitte beachten Sie: Die Liste der Tabellen und Textbausteine wird hiermit in der Form eines Änderungsnachweises geführt. Änderungen der Tabellen im Vergleich 

zur Vorversion dieses Dokuments sind aufgenommen, da neue Tabellen eingefügt wurden bzw. Tabellennummerierungen sich geändert haben. 

Tabellen: Änderungen im Vergleich zur Vorversion 

ja Tabelle 1: Überblick über die Varianten der MCard und unterstützte Kartentypen ........................................................................................................................................... 

ja 

ja 

ja 

ja 

ja 

ja 

ja 

ja 

ja 

ja 

ja 

ja 

ja 

ja 

ja 

Tabelle 2: Unterstützte Betriebssysteme/abgekündigte Betriebssysteme ........................................................................................................................................................ 

Tabelle 3: Unterstützte JRE/abgekündigte JRE ................................................................................................................................................................................................ 

Tabelle 4: Unterstützte Chipkartenlesegeräte mit veröffentlichter Bestätigung durch die Bundesnetzagentur ................................................................................................ 

Tabelle 5: Unterstützte Chipkartenlesegeräte mit veröffentlichter Herstellererklärung durch die Bundesnetzagentur .................................................................................... 

Tabelle 6: Unterstützte Chipkartenlesegeräte (nicht für eine QES in Deutschland geeignet) .......................................................................................................................... 

Tabelle 7: Abgekündigte Chipkartenlesegeräte ................................................................................................................................................................................................ 

Tabelle 8: Unterstützte Signaturkarten, dt. ZDA, QES mit Anbieterakkreditierung ........................................................................................................................................... 

Tabelle 9: Unterstützte Signaturkarten, dt. ZDA, QES ...................................................................................................................................................................................... 

Tabelle 10: Unterstützte Signaturkarten, fortgeschrittene elektronische Signatur ............................................................................................................................................ 

Tabelle 11: Unterstützte Signaturkarten ausgewählter Trustcenter aus dem europäischen Ausland .............................................................................................................. 

Tabelle 12: Unterstützte Einsatzumgebungen Terminalserver ......................................................................................................................................................................... 

Tabelle 13: Unterstützte Kombinationen Windows XP, Vista, 7 (32 und 64 Bit) - Chipkartenlesegerät – Signaturkarte .................................................................................. 

Tabelle 14: Unterstützte Kombinationen Windows 8 (32 und 64 Bit) - Chipkartenlesegerät – Signaturkarte................................................................................................... 

Tabelle 15: Unterstützte Kombinationen OpenSUSE 12.1 (32 Bit) - Chipkartenlesegerät – Signaturkarte...................................................................................................... 

Tabelle 16: Unterstützte Kombinationen Max OS X 10.6.8 Snow Leopard (32 Bit) - Chipkartenlesegerät - Signaturkarte ............................................................................. 

37


Textbausteine: Änderungen im Vergleich zur Vorversion 

ja Textbaustein 1: SigG-konformer Einsatz der SAK - Auflagen zur Nutzung ...................................................................................................................................................... 

ja 

ja 

ja 

ja 

ja 

ja 

ja 

ja 

Textbaustein 2: Bereitstellung Sicherheitspatches Betriebssystem .................................................................................................................................................................. 

Textbaustein 3: Bereitstellung Sicherheitspatches JRE .................................................................................................................................................................................... 

Textbaustein 4: Erläuterung zu den unterstützten Chipkartenlesegeräten ....................................................................................................................................................... 

Textbaustein 5: Verwendung nicht SigG-bestätigter oder nicht herstellererklärter Chipkartenlesegeräte bei Nutzung der Clientapplikation als SAK ................................... 

Textbaustein 6: Erläuterung unterstützte Signaturkarten bei Applikationen ohne Stapelsignaturfunktionalität ................................................................................................ 

Textbaustein 7: Erläuterung unterstützte Signaturkarten bei Applikationen mit Stapelsignaturfunktionalität ................................................................................................... 

Textbaustein 8: Hinweis zu unterstützten Kombinationen aus Betriebssystem, Chipkartenlesegerät und Signaturkarte ................................................................................ 

Textbaustein 9: Erläuterung unterstützte Einsatzumgebungen Terminalserver ............................................................................................................................................... 

38

Dokumentation der MCard-Bibliothek 1.18.0.0 der bremen-online ...

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?