Dokumentation der MCard-Bibliothek 1.12.0.0 der bremen

Handbuch 

Governikus - Kartenansteuerung (MCard) 

bremen online services 

GmbH & Co. KG 

Version MCard 1.12.0.0 

25.05.2010 

Dokumentenversion 1.0 

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

Änderungsnachweise 

Version Freigabedatum 

Autor Kapitel Änderungen 

0.1 JP Alle Erstellung 

0.5 07.01.2010 JP Alle Erweiterung 

0.8 25.03.2010 JP Alle Qualitätssicherung 

0.9 10.05.2010 TN Alle Erweiterung und Qualitätssicherung 

1.0 25.05.2010 TN Alle Freigabe


Inhaltsverzeichnis 

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

2 Einleitung.........................................................................................................................5 

2.1 Auflagen für die Nutzung der MCard gemäß Signaturgesetz ...................................5 

3 Varianten der MCard........................................................................................................7 

3.1 Releasezyklen der MCard........................................................................................8 

3.2 Funktionsweise MCard.............................................................................................8 

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

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

4.1.1 Unterstützte Betriebssysteme.......................................................................11 

4.1.2 Abkündigungen von Betriebssystemen.........................................................11 

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

4.2.1 Unterstützte JREs ........................................................................................12 

4.2.2 Abkündigungen von JREs ............................................................................12 

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

4.3.1 Unterstützte Chipkartenlesegeräte ...............................................................14 

4.3.2 Abkündigungen Chipkartenlesegeräte..........................................................15 

4.4 Signaturkarten .......................................................................................................16 

4.4.1 Unterstützte Signaturkarten..........................................................................17 

4.4.2 Abkündigungen Signaturkarten ....................................................................18 

4.4.3 Unterstützte Kombinationen aus Betriebssystem, Chipkartenlesegerät und 

Signaturkarte .........................................................................................................19 

4.4.4 Terminalserver .............................................................................................19 

4.5 Abwärtskompatibilität der MCard zum Governikus SDK.........................................20 

5 Benötigte Bibliotheken ...................................................................................................21 

5.1.1 Third-Party Bibliotheken ...............................................................................21 

5.1.2 Native Bibliotheken.......................................................................................21 

5.1.3 Verwendung unter JWS................................................................................21 

6 Konfiguration der MCard Bibliothek................................................................................22 

7 Austausch der MCard-Bibliotheken in existierenden Anwendungen...............................23 

7.1 Austausch der MCard Bibliothek............................................................................23 

8 Anhang ..........................................................................................................................24 

8.1 Unterstützte Signaturkarten ...................................................................................24 

8.2 Unterstützte Chipkartenlesegeräte.........................................................................27 

8.3 Unterstützte Kombinationen Betriebssystem - Chipkartenlesegerät - Signaturkarte29 

8.4 Unterstützte Terminalserver-Kombinationen ..........................................................36 

3


1 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. 

Wenn Ihnen in diesem Dokument Fehler auffallen oder wenn Sie Verbesserungsvorschläge 

haben, schicken Sie diese bitte per E-Mail an: mailto:technikredaktion@bos-bremen.de. 

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, Govello und erv-d sind eingetragene Marken der bremen online services Entwicklungs- 

und Betriebsgesellschaft mbH & Co. KG, Bremen. 

Das Copyright für die Programmiersprache Java und allen weiteren, frei bei SUN Microsystems 

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


2 Einleitung 

Dieses Handbuch bietet die notwendigen Informationen, um die Governikus Kartenansteuerung 

MCard in Clients, die den OSCI-Client-Enabler des Governikus SDK verwenden, zu 

aktualisieren. 

Es adressiert Entwickler, die auf der Grundlage des Governikus SDK Komponenten eigene 

Client-Anwendungen als Signaturanwendungskomponente entwickeln oder entwickelt haben, 

und Produktmanager, die den Anwendern dieser Clients Informationen zum Portfolio 

der unterstützten Signaturkarten und Chipkartenlesegeräte sowie zu den unterstützten Betriebssystemen 

in Form einer Endanwenderdokumentation zur Verfügung stellen müssen. 

Hinweis: Wichtige Hinweise, vor allem zum signaturgesetzkonformen 

Einsatz der MCard als Teil einer Signaturanwendungskomponente 

(SAK), die in die eigene Endanwenderdokumentation aufgenommen 

werden müssen, werden im Folgenden mit einem Rahmen umgeben. 

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

Das Governikus SDK ist gemäß § 15 Abs. 7 und § 17 Abs. 4 Signaturgesetz (SigG) sowie 

§ 11 Abs. 3 Signaturverordnung (SigV) bestätigt oder herstellererklärt, sodass der OSCI- 

Client-Enabler eine Funktionsbibliothek darstellt, die Teilfunktionalitäten einer Signaturanwendungskomponente 

zur Verfügung stellt. Dazu gehört auch die Governikus Kartenansteuerung 

(MCard) als Teil dieser Funktionsbibliothek. 

Applikationen, die den OSCI-Client-Enabler und die MCard (und damit Kartenleser und Signaturkarten) 

verwenden, können damit Teil einer Signaturanwendungskomponente (SAK) 

sein. 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. Damit sind auch die die Kartenleser und Signaturkarten Bestandteil 

der SAK. Diese ist allerdings nicht per se durch Verwendung dieser Bibliotheken SigGkonform. 

Für einen SigG-konformen Betrieb sind vielmehr 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. 

5


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

Hinweis zur SigG-konformen Nutzung sinngemäß aufgenommen werden: 

Die Nutzung der Clientapplikation als Signaturanbringungskomponente 

(d. h., 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) erforderlich. 

• 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. 

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

Client-Enabler-Entwicklerhandbuch. 

6


3 Varianten der MCard 

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

• mcard.jar für Clientanwendungen 

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

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

SDK entwickeln. Sie wird außerdem in der Governikus Signer Familie (mit entsprechender 

Signaturkarte Stapelsignaturfunktion möglich), im EGVP und Governikus MultiMessenger 

verwendet. Die MCard unterstützt die meisten elektronischen Einzel- und Stapelsignaturkarten, 

die durch deutsche Zertifizierungsdiensteanbieter (ZDA) herausgegeben werden und mit 

denen man eine qualifizierte elektronische Signatur oder eine qualifizierte Signatur mit Anbieterakkreditierung 

erzeugen kann. 

Stapelsignaturkarten erlauben in der Regel 100 mögliche Signaturerzeugungen nach einer 

erfolgreichen Authentifizierung mit der Signatur-PIN. Es ist daher durch die Signaturanwendungskomponente 

(SAK) sicherzustellen, dass keine missbräuchliche Nutzung der 

Stapelsignaturfunktionalität möglich ist. Solange dieses noch nicht gewährleistet werden 

kann, wird die Anzahl der möglichen Signaturerzeugungen durch Stapelsignaturkarten nach 

einer erfolgreichen Authentifizierung mit der Signatur-PIN durch die MCard daher auf 1 begrenzt. 

Zur Verwendung der Stapelsignaturfunktion einer Karte, entsprechende Verfügbarkeit 

der Signaturkarte vorausgesetzt, muss ab der MCard 1.12.0.0 das Erzeugen der Signaturen 

in einem Transaction-Block erfolgen. D. h., zu Beginn der Signaturen muss eine Transaktion 

begonnen werden und am Ende beendet werden. Eine Karte bleibt bis zum Ende der Transaktion 

„offen“ und kann weiterhin für Signaturen verwendet werden. Dies ist aber ausschließlich 

durch die Applikation, in der die Transaktion gestartet wurde, möglich, hier also die 

MCard. 

Multisignaturkarten erlauben technisch eine unbegrenzte Anzahl von Signaturen nach erfolgreicher 

Authentifizierung mit der Signatur-PIN. Multisignaturkarten dürfen ausschließlich in 

besonders gesicherten Umgebungen und durch entsprechend bestätigte SAK genutzt werden. 

Multisignaturkarten werden nicht durch die MCard getestet und nicht unterstützt. 

Die MCard-Server wird exklusiv nur für Betreiber des Governikus-NetSigner bereitgestellt. 

Diese Variante unterstützt den vollen Funktionsumfang der von deutschen ZDA herausgegebenen 

Multisignaturkarten. 

7


Kartentyp unterstützt / Signaturen nach PIN-Eingabe 

MCard-Variante Einzelsignatur Stapelsignaturen Multisignaturen 

Client Ja / 1 Ja 1 / bis 100 Nein / - 

Server (NetSigner) Nein / - Nein / - Ja / unbegrenzt 

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

3.1 Releasezyklen der MCard 

Die Governikus Kartenansteuerung ist seit der Governikus Version 3.1.0.0 gekapselt. Sie 

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 alle Signaturkarten und unterstützten Kartenleser verwendet werden können. 

3.2 Funktionsweise 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 Javaklasse kapseln, und andererseits die verschiedenen 

CardService-Klassen, welche die unterschiedlichen Funktionen einer Chipkarte in 

entsprechenden Javaklassen 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. 

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

von Kommandos für Karten und Leser regelt, gekapselt. Wie Sie den Provider nutzen, wird 

ausführlich im Entwicklerhandbuch beschrieben. 

Jede kartenspezifische Implementierung erfolgt konform zu OCF 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 

1 Nur in Verbindung mit einer geeigneten Signaturkarte 

8


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. 

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 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. 

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. 

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

Windowsversion (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 max. 2 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 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 für den Privatkonsumentenbereich 

unterstützt, da für diese in der Regel am längsten Sicherheitsupdates 

zur Verfügung gestellt werden. 

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

aktuelle Version unterstützt wird und die openSUSE-Version des letzten Releases der 

MCard. Somit werden in der Regel zwei openSUSE-Versionen unterstützt. Sollte es keinen 

Versionswechsel zwischen zwei MCard-Releases geben, bleibt es bei der Unterstützung 

der bisher unterstützten Versionen von openSUSE. 

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. 

4.1.1 Unterstützte Betriebssysteme 

Mit der vorliegenden Version der MCard wurde die Funktionsfähigkeit mit folgenden Client- 

Betriebssystemen getestet: 

Betriebssystem 

• Windows XP Professional 32 Bit SP3 X 

• Windows XP Professional 64 Bit SP3 X 

• Windows Vista Home Premium 32 Bit SP2 X 

• Windows Vista Home Premium 64 Bit SP2 X 

• Windows 7 Professional 32 X 

• Windows 7 Professional 64 X 

• openSUSE 11.x 32 Bit X 

Tabelle 2: Unterstützte Betriebssysteme und JREs 

Unterstützte JRE 

Version 

1.6_20 

Eine Tabelle mit den unterstützten Betriebssystemen ist in jedem Fall in die Release- 

Dokumentation der jeweiligen Clientanwendung aufzunehmen. Bei einer Anwendung, die 

eine SAK im Sinne des Signaturgesetzes darstellt (also zur Erzeugung von qualifizierten 

elektronischen Signaturen verwendet werden kann), ist diese Tabelle zwingend erforderlich, 

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.1.2 Abkündigungen von Betriebssystemen 

Mit der vorliegenden Version der MCard werden folgende, bereits seit Längerem abgekündigte 

Betriebssysteme nicht mehr unterstützt: 

nicht mehr unterstützte Betriebssysteme: 

• openSUSE 10.3 32 Bit 

Mit der nächsten Version der MCard bzw. ab dem angegebenen Datum werden folgende 

Betriebssysteme durch die MCard abgekündigt: 

Abgekündigte Betriebssysteme Abgekündigt zu Version/Datum 

• Keine Abkündigung 

11


4.2 SUN 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 SUN ankü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 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. 

4.2.1 Unterstützte JREs 

Die beiden MCard-Varianten unterstützen SUN Java Standard Edition Runtime Environment 

(JRE) in den in der Tabelle 2 angegebenen Versionen und Updates. Empfohlen werden die 

jeweils aktuellen Updates. 

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

• JRE 1.6_20 

Bitte beachten Sie: 

Am 30. Oktober 2009 endete die Unterstützung des JRE 1.5 durch SUN Microsystems, Inc. 

(Java Technology End of Life (EOL) transition period). Die MCard wird weiterhin mit dem 

JDK 1.5 lauffähig bleiben, um die Abwärtskompatibilität zum Governikus-OSCI-Clientenabler 

der Governikus Version 3.3 und zum SDK 1.1 sicherzustellen. Berücksichtigen Sie jedoch 

bitte, dass SUN ab diesem Datum keine Sicherheits-Updates mehr für das JRE 1.5 bereitstellen 

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

Bedrohungen beeinträchtigen. Diese Warnung sollte in die Anwenderdokumentation 

aufgenommen werden. 

4.2.2 Abkündigungen von JREs 

Mit der vorliegenden Version der MCard wird folgende, bereits abgekündigte JRE-Version 

nicht mehr unterstützt: 

12


nicht mehr unterstützte JRE-Versionen 


Mit dem nächsten Release der MCard bzw. ab dem angegebenen Datum werden folgende 

JRE-Versionen abgekündigt: 

Abgekündigte JRE-Versionen Abgekündigt zu Version/Datum 


4.3 Chipkartenlesegeräte 

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 die international sehr weit verbreitete plattformunabhängige Schnittstelle 

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

unter Windows, Linux und Mac OS verwendet werden kann (bei 

MacOS bis Version 10.5 mit Einschränkungen). Im Dezember 1997 wurde die Version 

PC/SC 1 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 bieten 

keine Möglichkeit, PIN-Pad und Display eines Kartenlesers zu verwenden. Dieses ist erst 

seit der Erweiterung der PC/SC 2 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 

13


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 zwar den SHARED-Modus, die beschriebenen Probleme treten aber 

ab der Version 1.12.0.0 der MCard nicht mehr auf. Ab der genannten Version verwendet die 

MCard die in PC/SC definierten Transaction-Funktionalität des PC/SC-Resource Manager. 

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. 

4.3.1 Unterstützte Chipkartenlesegeräte 

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

werden, die gem. deutschem Signaturgesetz (SigG) bestätigt sind und wenn diese Bestätigung 

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 

MCard-Version genügen die in der Tabelle 6 benannten Chipkartenlesegeräte diesen Anforderungen. 

Diese Liste ist die sogenannte Positivliste der unterstützten Kartenleser. Diese ist 

im Rahmen des Bestätigungsprozesses gemäß SigG oder bei einer Herstellererklärung zusammen 

mit der SAK zu veröffentlichen. Jede Änderung in der Liste bedingt dabei einen 

Nachtrag zur Bestätigung oder Herstellererklärung, der zu veröffentlichen ist. 

Die Funktionsfähigkeit der in der Positivliste benannten Chipkartenlesegeräte wurde jeweils 

für die oben benannten Betriebssysteme getestet. Verwendet werden jeweils bei den Herstellern 

verfügbare und aktuelle Treiber - auch generische Linux-Treiber - sowie die zum 

Testzeitpunkt aktuelle Firmware. Detailinformationen zu den getesteten Treiber- und Firmwareversionen 

siehe Tabelle 8 bis 14. Es kann keine Gewährleistung dafür übernommen werden, 

• dass die Chipkartenlesegeräte auch mit älteren Treiberversionen, anderer Firmware 

oder anderen als den genannten Betriebssystemen funktionieren und 

• dass andere als die explizit benannten Chipkartenlesegeräte unterstützt werden. 

Es werden nur die in der Tabelle angegebenen Versionen unterstützt. 

Bitte beachten Sie, dass für den Anwender daher der folgende Hinweis in der Anwenderdokumentation 

aufgenommen werden sollte: 

14


Die Funktionsfähigkeit der Chipkartenlesegeräte mit der >Name der Applikation< 

wurde für die oben angegebenen Betriebssysteme getestet. Verwendet werden 

jeweils die bei den Herstellern verfügbaren aktuellen Treiber bzw. generischen 

Linux-Treiber sowie die zum Testzeitpunkt aktuelle Firmware. Es kann keine Gewährleistung 

dafür übernommen werden, dass die Chipkartenlesegeräte auch mit 

älteren Treiberversionen oder anderen als den oben genannten Betriebssystemen 

funktionieren. Es werden nur die in der Tabelle angegebenen Versionen 

unterstützt. 

Die Tabelle der unterstützten Chipkartenlesegeräte hat den Status eines Textbausteins. Sie 

kann als Grundlage verwendet werden, um die eigene Anwenderdokumentation um eine 

Übersicht über die unterstützten Chipkartenleser zu ergänzen. Hat die Anwendung den Status 

einer SAK (d. h., es können mit ihr qualifizierte Signaturen angebracht werden), muss 

eine Liste der unterstützten, SigG-bestätigten Chipkartenleser zusammen mit der Software 

veröffentlicht werden. 

Wenn ein bei der Bundesnetzagentur geführtes bestätigtes Chipkartenlesegerät mit PIN das 

nicht in der Tabelle gelistet ist, oder ein Gerät mit PIN-Pad, welches sich noch im Bestätigungsprozess 

nach SigG befindet, verwendet wird, wird die MCard nicht als Teil einer Signaturanwendungskomponente 

(SAK) verwendet, mit der qualifizierte Signaturen erzeugt werden 

dürfen. 

Die MCard unterstützt auch die in der Tabelle 7 benannten 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 externe USB-Kartenleser oder interne Kartenleser 

in Notebooks der HBCI-Klasse 1 verwendet werden. Natürlich muss der Hersteller für 

das verwendete Betriebssystem einen PC/SC-Treiber zur Verfügung stellen. Eine Gewährleistung 

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

Da die MCard grundsätzlich auch die Verwendung von Kartenlesern ohne PIN-Pad ermöglicht 

oder von Geräten, die sich noch im Bestätigungsprozess befinden, muss immer der folgende 

Hinweis in die Anwenderdokumentation einer SAK aufgenommen werden: 

Die Client-Anwendung >Name der Applikation< unterstützt auch Chipkartenlesegeräte, 

die keine sichere PIN-Eingabe erlauben. 

Auch kann es vorkommen, dass nicht in der Liste aufgeführte, bei der Bundesnetzagentur 

geführte SigG-bestätigte Geräte oder Chipkartenlesegeräte mit PIN- 

Pad, die sich noch im Bestätigungsprozess befinden, verwendet werden können. 

Wenn Sie ein solches Chipkartenlesegerät verwenden, nutzen Sie die >Name 

der Applikation< nicht als Teil einer Signaturanwendungskomponente (SAK), mit 

der qualifizierte Signaturen erzeugt werden dürfen. 

4.3.2 Abkündigungen Chipkartenlesegeräte 

Bei der An- und Abkündigungspraxis von Kartenlesern ist die MCard führend. Clients unterstützen 

daher maximal das angegebene Set von Kartenlesern. Eine gesonderte Ankündigung 

neuer Kartenleser erfolgt nicht. Diese werden in der Regel zeitnah unterstützt, sobald 

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

15


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. 

Mit der vorliegenden Version der MCard werden folgende, bereits abgekündigte, Kartenleser 

nicht mehr unterstützt: 

nicht mehr unterstützte Kartenleser 


Mit der nächsten Release der MCard bzw. ab dem angegebenen Datum werden folgende 

Kartenleser abgekündigt: 

Abgekündigte Kartenleser Abgekündigt zu Version/Datum 


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. Eine besondere Ankündigung der Unterstützung neuer Signaturkarten erfolgt nicht. 

Vielmehr wird angestrebt, dass eine neue Signaturkarte oder eine neue SSEE-Version einer 

bereits unterstützten Signaturkarte vier bis 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. 

Die MCard unterstützt neben „normalen“ Signaturkarten für Einzelsignaturen auch sogenannte 

Stapelsignaturkarten. Es ist daher durch die Signaturanwendungskomponente (SAK) 

sicherzustellen, dass keine missbräuchliche Nutzung der Stapelsignaturfunktionalität möglich 

ist. Solange dieses noch nicht gewährleistet werden kann, wird die Anzahl der möglichen 

Signaturerzeugungen durch Stapelsignaturkarten nach einer erfolgreichen Authentifizierung 

mit der Signatur-PIN durch die MCard daher auf 1 begrenzt. Zur Verwendung der Stapelsignaturfunktion 

einer Karte, entsprechende Verfügbarkeit der Signaturkarte vorausgesetzt, 

muss ab der MCard 1.12.0.0 das Erzeugen der Signaturen in einem Transaction-Block erfolgen. 

D. h., zu Beginn der Signaturen muss eine Transaktion begonnen werden und am Ende 

beendet werden. Eine Karte bleibt bis zum Ende der Transaktion „offen“ und kann weiterhin 

für Signaturen verwendet werden. Dies ist aber ausschließlich durch die Applikation, in der 

die Transaktion gestartet wurde möglich, hier also die MCard. 

Multisignaturkarten werden nur durch die separat bereitgestellte MCard-Server unterstützt, 

die für den Governikus NetSigner relevant ist. Sollte trotzdem eine Multisignaturkarte erkannt 

werden, wird aus Sicherheitsgründen die Anzahl der möglichen Signaturerzeugungen 

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

16


In die Anwenderdokumentation von Anwendungen oder SAKs, die die MCard ohne die Stapelsignaturfunktion 

verwenden, ist deshalb der folgende Hinweis aufzunehmen: 

Die Client-Anwendung >Name der Applikation< 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 Stapelsignaturkarten. Aus Sicherheitsgründen ist bei Stapelsignaturkarten 

die Anzahl der möglichen Signaturerzeugungen nach einer erfolgreichen 

Authentifizierung mit der Signatur-PIN auf 1 begrenzt. 

In die Anwenderdokumentation von Anwendungen oder SAKs, die die MCard mit der Stapelsignaturfunktion 

verwenden, ist der folgende Hinweis aufzunehmen: 

Die Client-Anwendung >Name der Applikation< 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. 

Es wird auch bei Stapelsignaturkarten der volle Funktionsumfang gewährleistet, 

d. h., nach einer erfolgreichen Authentifizierung mit der Signatur-PIN können – je 

nach Hersteller – bis zu 100 Signaturen erzeugt werden. 

4.4.1 Unterstützte Signaturkarten 

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 

manchmal auch von mehreren ZDA/Trustcentern verwendet (personalisiert). Unterstützt werden 

nur die in den Tabellen aufgeführten Kombinationen von herausgebenden ZDA und 

SSEE. Der folgende Hinweis sollte daher in die Anwenderdokumentation aufgenommen 

werden, da er das Verständnis der Tabellen erleichtert: 

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

sicheren Signaturerstellungseinheiten (SSEE). Für eine Signaturkarte 

werden von einem ZDA manchmal mehrere unterschiedliche SSEE-Versionen 

(z. B. unterschiedlicher Hersteller) verwendet. Soweit nichts anderes angegeben 

ist, werden alle vom ZDA verwendeten SSEE-Versionen für eine Signaturkarte 

unterstützt, solange mit einer SSEE-Version vom Anwender qualifizierte Signaturen 

erzeugt werden können. 

Eine SSEE wird manchmal von mehreren ZDA verwendet und personalisiert. Unterstützt 

werden nur die in der Tabelle xxx aufgeführten Kombinationen von ZDA 

und SSEE. 

Detailinformationen zu den unterstützten elektronischen Signaturkarten entnehmen Sie bitte 

den Tabellen 3 bis 5 im Anhang dieses Dokuments. Die Tabelle hat den Status eines Textbausteins. 

Sie kann als Grundlage verwendet werden, um eine eigene Endanwenderdoku- 

17


mentation um eine Übersicht über die unterstützten Signaturkarten zu ergänzen. Bei einer 

Anwendung, die eine SAK im Sinne des Signaturgesetztes ist (also zur Erzeugung von qualifizierten 

elektronischen Signaturen verwendet werden kann), ist die Tabelle der unterstützten 

Signaturkarten zwingend erforderlich, da die unterstützten Signaturkarten in einer Positivliste 

zu veröffentlichen sind. 

In der Tabelle ist für jede unterstützte Signaturkarte, mit der eine qualifizierte elektronische 

Signatur erzeugen kann, angeben: 

• der herausgebende Zertifizierungsdiensteanbieter (ZDA) mit dem von der Bundesnetzagentur 

vergebenen Gütezeichen (nur bei qualifizierter Signatur mit Anbieterakkreditierung), 

• der Handelsname der Signaturkarte und 

• die Namen der SSEE in der Bestätigungsurkunde, die für diese Signaturkarte verwendet 

werden mit der Registrierungsnummer der Bestätigungsurkunde der SSEE. 

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

Zertifikate mit der benötigten KeyUsage (extended Keyusage) auf der Signaturkarte vorhanden 

sind: 

• die Erzeugung von qualifizierten elektronischen Signaturen 

• die Ent-/Verschlüsselung von Daten und die 

• die Authentisierung (in der Regel damit auch die Anbringung einer fortgeschrittenen 

Signatur). 

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 

das KeyUsage bit nonRepudiation (oder neu: 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 

das Bit digital signature (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 das Keyusage bit dataEncipherment gesetzt. Häufig finden 

sich auch Zertifikate, die zur Verschlüsselung und Authentisierung verwendet werden können. 

4.4.2 Abkündigungen Signaturkarten 

Soweit nichts anderes angegeben ist, werden alle vom ZDA verwendeten SSEE-Versionen 

für eine Signaturkarte unterstützt, solange mit einer SSEE-Version vom Anwender qualifizierte 

Signaturen erzeugt werden können. Eine gesonderte Abkündigung gibt es nicht. 

18


4.4.3 Unterstützte Kombinationen aus Betriebssystem, Chipkartenlesegerät und 

Signaturkarte 

Aus technischen Gründen kann es in Ausnahmefällen vorkommen, dass eine elektronische 

Signaturkarte/SSEE mit einer bestimmten Chipkartenleser-Betriebssystem-Kombination nicht 

funktioniert. Häufigste Ursache ist die Nichtbereitstellung des notwendigen PC/SC-Treibers 

durch den Hersteller des Kartenlesers. Die Detailinformationen, welche Kombinationen nicht 

unterstützt werden, ist den Tabellen 8 bis 14 im Anhang zu entnehmen. 

Die Tabellen haben den Status eines Textbausteins. Sie können als Grundlage verwendet 

werden, um eine eigene Anwenderdokumentation um eine Übersicht über die unterstützten 

Kombinationen von Signaturkarte, Chipkartenleser und Betriebssystem zu ergänzen. 

Bitte beachten Sie, dass für den Anwender der folgende Hinweis in der Anwenderdokumentation 

sinnvoll ist, da er das Verständnis der Tabelle erleichtert: 

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

elektronische Signaturkarte/SSEE mit einer bestimmten Chipkartenleser- 

Betriebssystem-Kombination nicht funktioniert. Häufigste Ursache ist die Nichtbereitstellung 

des notwendigen PC/SC-Treibers durch den Hersteller des Kartenlesers. 

Prüfen Sie daher bitte, ob Ihre Kombination von Betriebssystem, Signaturkarte 

und Chipkartenlesegerät unterstützt wird. 

4.4.4 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 den Tabellen 8 bis 14 zu entnehmen. Die Tabelle hat den Status 

eines Textbausteins. Er kann als Grundlage verwendet werden, um eine eigene Anwender- 

19


dokumentation um eine Übersicht über die unterstützten Kombinationen zu ergänzen. Bei 

einer Anwendung, die eine SAK (also zur Erzeugung von qualifizierten elektronischen Signaturen 

verwendet werden kann) im Sinne des Signaturgesetztes darstellt, ist die Tabelle mit 

den benannten Kombinationen von Signaturkarte, Chipkartenleser, Terminalserversoftware, 

Serverbetriebssystem und Clientbetriebssystem zwingend erforderlich, da die unterstützten 

Chipkartenlesegeräte in einer Positivliste zu veröffentlichen sind. 

Bitte beachten Sie, dass für den Anwender der folgende Hinweis in der Anwenderdokumentation 

sinnvoll ist, da sie das Verständnis der Tabelle erleichtert: 

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 

>Name der Applikation


5 Benötigte Bibliotheken 

5.1.1 Third-Party Bibliotheken 

Das MCard.jar enthält das OpenCard-Framework und den PC/SC Wrapper von IBM. 

5.1.2 Native Bibliotheken 

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

Systemen/Java unter Windows/Linux verwendet. Ein Update der DLLs/SO ist daher zwingend 

erforderlich, sollte die aktuelle MCard eine Version kleiner MCard 1.9.0 ersetzen. 

Seit der Version 1.9.0 heißt die native Bibliothek jetzt konform zu Konventionen JNI 

OCFPCSC1.dll. Sie unterstützt auch die notwendigen Erweiterungen für PC/SC 2.0. Mit der 

MCard-Version 1.12.0.0 werden neue Versionen der nativen Bibliotheken zur Verfügung gestellt, 

die zwingend ab dieser Version verwendet werden müssen. Hintergrund ist die neue 

Unterstützung der PC/SC Funktion transaction für den synchronisierten Zugriff auf den Kartenleser. 

5.1.3 Verwendung 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. 

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

zur Verfügung. Für bestimmte Linux-Distributionen kann es notwendig sein, die native 

Bibliothek für das Zielsystem entsprechend zu kompilieren und selbst zu signieren. Dies 

hängt davon ab, inwieweit die ausgelieferte Version mit den Versionen von PC/SC-Lite und 

anderen Komponenten des Systems kompatibel sind. 

Als Java-Bilbiotheken werden die Standard-Logging-Bilbiotheken für commons-logging und 

log4j von Apache, der JCA/JCE-Provider von Bouncy Castle und der GovernikusCryptoprovider 

von bremen online services benötigt. 

21


6 Konfiguration der MCard Bibliothek 

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

Ausführungen im Handbuch "OSCI-Client-Enabler allgemeine Funktions- und Schnittstellenbeschreibung", 

besonders das Kapitel 2.3.10 „Kryptografische Operationen“. 

22


7 Austausch der MCard-Bibliotheken in existierenden Anwendungen 

7.1 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. 

Zum Einsatz der neuen Bibliothek muss eine neue Version der nativen Bibliothek eingesetzt 

werden. Es muss außerdem eine kompatible Version des ci.jar (Certificate Interpreter) ab 

1.5.0 eingesetzt werden. Sollte die MCard in einem eigenen Projekt genutzt werden, wird 

ggf. das ci.jar benötigt. Bitte wenden Sie sich in diesem Fall an unseren Servicedesk 

(Servicedesk@bos-bremen.de). 

23

8 Anhang 

8.1 Unterstützte Signaturkarten 

Tabelle 3: Deutsche Zertifizierungsdiensteanbieter, qualifizierte elektronische Signatur mit Anbieterakkreditierung 

Zertifizierungsdiensteanbieter 

(Gütezeichen BNetzA) 

Produktzentrum Tele- 

Sec der Deutschen 

Telekom AG (Z0001) 

Bundesnotarkammer, 

Zertifizierungsstelle 

(Z0003) 

DATEV eG Zertifizierungsstelle 

(Z0004) 

Handelsname der 

Signaturkarte 

1 TeleSec NetKey 3.0 mit PKS 

3 Bundesnotarkammer, Zertifizierungsstelle 

qual. elektronische 

Signatur 

- Stapelsignaturkarte - 

QES 1) C 1) A 1) Name der SSEE in der Bestätigungsurkunde 

x x x 

x 3) x x 

Signaturerstellungseinheit TCOS 3.0 Signature 

Card, Version 1.0, Version 1.1 

Registrierungsnr. der Bestätigungsurkunde 

der SSEE 

TUVIT.93119.TE.09.2006 

TUVIT.93146.TE.12.2006 

Signaturerstellungseinheit STARCOS 3.2 BSI.02114.TE.12.2008 

4 zertifizierte Signaturkarte für Berufsträger 

der DATEV x x x Signaturerstellungseinheit STARCOS 3.2 BSI.02114.TE.12.2008 

D-Trust GmbH (Z0017) 5 D-TRUST Card 2.02c, 2.2, 2.3, 24 

Deutsche Post Com 

GmbH Geschäftsfeld 

Signtrust (Z0002) 

TC TrustCenter 

TrustCenter GmbH 

(Z0032) 

S-Trust, Deutscher 

Sparkassen Verlag 

GmbH (Z0035) 

x x x 

SEE „Chipkarte mit Prozessor SLE66CX322P, 

CardOS V4.3B mit Applikation für digitale 

Signatur“ 

T-Systems.02122.TE.05. 2005 

6 SIGNTRUST CARD x x x Signaturerstellungseinheit STARCOS 3.2 BSI.02114.TE.12.2008 

7 SIGNTRUST MCARD 100 

- Stapelsignaturkarte - x 3) x x 

9 TC QSign (limited) 

dgnservice (Z0033) 11 dgnservice Card 

x x x 

10 SparkassenCard oder kontounabhängige 

GeldKarte x x 4) x 4) 

x x x 

Signaturerstellungseinheit STARCOS 3.2 BSI.02114.TE.12.2008 

SEE „Chipkarte mit Prozessor SLE66CX322P, 

CardOS V4.3B mit Applikation für digitale 

Signatur“ 

SEE ZKA Banking Signature Card, Version 

6.6 der Giesecke & Devrient GmbH 

T-Systems.02122.TE.05. 2005 

TUVIT.93130.TU.05.2006, 2. Nachtrag 

vom 18.10.2006 

Signaturerstellungseinheit STARCOS 3.0 TUVIT.93100.TE.09.2005 

Nachträge vom 08.08.2006, 

20.10.2006 und 07.12.2006


Tabelle 4: Deutsche Zertifizierungsdiensteanbieter, qualifizierte elektronische Signatur 


Handelsname der 

Signaturkarte 

D-Trust GmbH 12 D-TRUST Card 2.02c 2.2, 2.3, 2.4 

S-Trust, Deutscher 

Sparkassen Verlag 

GmbH 

Deutsche Rentenversicherung 

Bund 5) 

14 SparkassenCard oder kontounabhängige 

GeldKarte 

QES 1) C A 2) Name der SSEE in der Bestätigungsurkunde 

x x x 

x x 4) x 4) 

15 Signaturkarte der Deutschen Rentenversicherung 

Bund x x x 

SEE „Chipkarte mit Prozessor 

SLE66CX322P, CardOS V4.3B mit Applikation 

für digitale Signatur“ 

SEE ZKA-Signaturkarte, Version 5.02 der 

Gemplus-mids GmbH 


6.2b NP und 6.2f NP, Type 3 der Giesecke & 

Devrient GmbH 


6.31 NP, Type 3 der Giesecke & Devrient 

GmbH 


6.32 NP, Type 3 der Giesecke & Devrient 

GmbH 





SEE ZKA-Signaturkarte, Version 5.10 der 

Gemplus-mids GmbH 

ZKA-Signaturkarte, Version 5.11 Gemplus 

GmbH (Gemalto) 

Signaturerstellungseinheit ZKA SECCOS Sig 

v1.5.3 der Sagem Orga GmbH 

Signaturerstellungseinheit ZKA Banking 

Signature Card, Version 7.1.2 der Giesecke & 

Devrient GmbH 

SEE „Chipkarte mit Prozessor 

SLE66CX322P, CardOS V4.3B mit Applikation 

für digitale Signatur“ 



T-Systems.02122.TE.05. 2005 

TUVIT.09385.TU.09.2004 

TUVIT.09395.TU.01.2005 

TUVIT.09397.TU.03.2005 

TUVIT.93125.TU.12.2005 

TUVIT.93123.TU.12.2006 

TUVIT.93130.TU.05.2006, 1. 

Nachtrag vom 28.08.2006 und 2. 

Nachtrag vom 18.10.2006 

TUVIT.93132.TU.06.2006 

TUVIT.93138.TU.11.2006 

BSI.02076.TE.08.2006 

TUVIT.93166.TU.06.2008 

T-Systems.02122.TE.05. 2005 

25


1) QES = qualifizierte elektronische Signatur, C = Chiffrierung, A = Authentisierung, X = unterstützt 0 = nicht unterstützt, - Funktionalität nicht vorhanden 

2) Die verwendete KeyUsage des Zertifikats „digital signature“ ermöglicht es auch, eine fortgeschrittene elektronische Signatur zu erzeugen 

3) Solange die Signaturerzeugung nicht im Transaction-Block erfolgt, ist die Anzahl der möglichen Signaturerzeugungen nach einer erfolgreichen Authentifizierung mit der Signatur-PIN 

bei der MCard auf 1 begrenzt. 

4) ein Zertifikat für Verschlüsselung und Authentisierung 

5) Die Signaturkarte der Deutschen Rente Bund wird nur an Mitarbeiter dieser Behörde ausgegeben. 

Tabelle 5: unterstützte elektronische Signaturkarten, fortgeschrittene elektronische Signatur 

Trustcenter Handelsname der 

Signaturkarte 

TESTA-CA (unter der 

PKI-1 Verwaltung) 2) 

Hessen-PKI (unter der 

PKI-1 Verwaltung) 3) 

Europäisches Patentamt 

– European Patent 

Office (EPO) 

18 Signaturkarte der T-System Netkey 

3.0 und 3.01 -- x x 

19 Signaturkarte der T-System Netkey 

3.0 und 3.01 mit Hessen-PKI- 

Zertifikat 

QES 1) F, A 2) C 2) Name der SSEE in der Bestätigungsurkunde 

x 4) x -- 

19 Online Services Smart Card Epoline 

-- x 5) -- 

Signaturerstellungseinheit TCOS 3.0 

Signature Card, Version 1.0, Version 1.1 

Signaturerstellungseinheit TCOS 3.0 

Signature Card, Version 1.0, Version 1.1 



TUVIT.93119.TE.09.2006 

TUVIT.93146.TE.12.2006 

TUVIT.93119.TE.09.2006 

TUVIT.93146.TE.12.2006 

-- -- 

1) QES = qualifizierte elektronische Signatur, F = fortgeschrittene Signatur, C = Chiffrierung, A = Authentisierung, X = unterstützt 0 = nicht unterstützt, 

- Funktionalität nicht vorhanden 

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

3) Die Signaturkarte wird nur an Mitarbeiter Hessischer Behörden ausgegeben. 

4) Diese Signaturkarte kann zusätzlich auch mit einem qualifizierten Signaturzertifikat (mit Anbieterakkreditierung) des Public Key Service des Produktzentrum TeleSec 

der Deutschen Telekom AG (Gütezeichen des ZDA: Z0001) personalisiert werden. Siehe Tabelle 1, lfd. Nummer 1. 

5) Unterstützt wird nur die fortgeschrittene Signatur 

26


8.2 Unterstützte Chipkartenlesegeräte 

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

Handelsname des unterstützten 

Geräts 

Angaben aus der veröffentlichten Bestätigung bei der BNetzA Schnittstelle 

CardMan 3621 OMNIKEY GmbH SAK Chipkartenterminal der Familie CardMan Trust 

CM3621, Firmware-Version 6.00 

BSI.02057.TE.12.2005 USB ja 

CardMan 3821 OMNIKEY GmbH SAK Chipkartenterminal der Familie CardMan Trust 

CM3821, Firmware-Version 6.00 

BSI.02057.TE.12.2005 USB ja 

Cherry Smartboard G83-6744 Cherry GmbH Chipkartenterminal der Familie SmartBoard xx44 Firmware-Version 

1.04 

BSI.02048.TE.12.2004 USB ja 

Cherry SmartTerminal 2000 U Cherry GmbH Chipkartenterminal der Familie SmartTerminal ST-2xxx, 

Firmware Version 5.11 

BSI.02059.TE.02.2006 USB ja 

CyberJack e-com Reiner SCT Kartenlesegeräte 

GmbH 

CyberJack e-com, Version 3.0 TUVIT.93155.TE.09.2008 USB ja 

CyberJack e-com plus Reiner SCT Kartenlesegeräte 

GmbH 

CyberJack e-com plus, Version 3.0 TUVIT.93156.TE.09.2008 USB ja 

CyberJack pinpad Version 3 Reiner SCT Kartenlesegeräte 

GmbH 

Chipkartenleser, cyberJack pinpad, Version 3.0 TUVIT.93107.TU.11.2004 USB ja 

CyberJack secoder Reiner SCT Kartenlesegeräte 

GmbH 

Chipkartenleser CyberJack secoder Version 3.0 TUVIT.93154.TE.09.2008 USB ja 

Fujitsu Siemens Chipkartenleser- 

Tastatur KB SCR Pro 

Kobil EMV-TriCAP Reader Kobil Systems 

GmbH 

Kobil KAAN Advanced Kobil Systems 

GmbH 

Kobil SecOVID Reader III Kobil Systems 

GmbH 

Kobil TriB@ank Kobil Systems 

GmbH 

SPR 532 usb (Chipdrive pinpad pro) SCM Microsystems 

GmbH 

Fujitsu Siemens Chipkartenleser-Tastatur Sachnummer S26381-K329- 

V2xx Firmware Version 1.06 

EMV-TriCAP Reader (Art.-Nr. HCPNCKS/A03, Firmware 

69.18) 

Chipkartenterminal KAAN Advanced, Firmware Version 

1.02, Hardware Version K104R3, 

Firmware 1.19 Nachtrag zur Bestätigung 

SecOVID Reader III (Art.-Nr. HCPNCKS/B05, Firmware 

69.18) 

KAAN TriB@nk (Art.-Nr. HCPNCKS/C05, Firmware 

79.23) 

Chipkartenleser SPR132, SPR332, SPR532, Firmware 

Version 4.15 

BSI.02082.TE.01.2007 USB ja 

BSI.02096.TE.12.2008 

Nachtrag Nr. 1 vom 03.04.2009 

USB ja 

BSI.02050.TE.12.2006 

Nachtrag zur Bestätigung vom 

07.04.2008: T- 

Systems.02207.TU.04.2008 

USB ja 

BSI.02096.TE.12.2008 


USB ja 

BSI.02096.TE.12.2008 


USB ja 

TUVIT.09370.TE.03.2003 USB ja 

Sichere 

PIN- 

Eingabe 

27


Tabelle 7: Auswahl unterstützter Chipkartenlesegeräte ohne PIN-Pad 


Geräts 

Hersteller Schnittstelle 

CardMan 3121 Omnikey USB 

Omnikey Cardman 5321 RFID 1 Omnikey USB 

SCM SDI010 RFID 1 SCM Microsystems GmbH USB 

SCR 3310 SCM Microsystems GmbH USB 

SCR 3311 (Chipdrive desktop pro) SCM Microsystems GmbH USB 

SCR 335 (Chipdrive micro pro) SCM Microsystems GmbH USB 

1 Nur die Nutzung des kontaktbehafteten Interfaces möglich 

28


8.3 Unterstützte Kombinationen Betriebssystem - Chipkartenlesegerät - Signaturkarte 

Tabelle 8: Unterstützte Kombinationen Windows XP Professional SP3 (32 Bit) - Chipkartenlesegerät - Signaturkarte 


Chipkartenlesegeräts 

bestätigt 

nach SigG 

Schnittstelle 

Windows XP Prof. SP 3 Zertifizierungsdiensteanbieter 1 

Sichere 

PIN- 

Firmware Treiber Eingabe 

Cherry® Smartboard G83-6744 ja USB 01.04.00.00 1.2.2.8 ja � � � � � � � � � 

Cherry® SmartTerminal 2000 U ja USB 6.01.00.00 4.45.0.0 ja � � � � � � � � � 

CyberJack® e-com ja USB 3.0.69 6.9.6 ja � � � � � � � � � 

CyberJack® e-com plus ja USB 3.0.2 6.9.6 ja � � � � � � � � � 

CyberJack® pinpad Version 3 ja USB 3.0.12 6.9.6 ja � � � � � � � � � 

CyberJack® secoder ja USB 3.0.14 6.9.6 ja � � � � � � � � � 

Fujitsu Siemens KB SCR Pro ja USB 1.06 1.2.2.8 ja � � � � � � � � � 

Kobil KAAN Advanced ja USB 1.19 2010.1.12.1 ja � � � � � � � � � 

Kobil SecOVID 3, EMV-TriCap, Trib@nk ja USB 69.18/79.23 4 2010.1.12.1 ja � � � � � � � � � 

Omnikey CardMan 3121 nein USB nicht bekannt 1.2.2.8 nein 2 � � � � � � � � � 

Omnikey CardMan 3621 ja USB 6.00 1.2.2.8 ja � � � � � � � � � 


Omnikey Cardman 5321 RFID 3 nein USB 5.10 1.2.2.7 nein 2 � � � � � � � � � 

SCM SCR 3310 nein USB nicht bekannt 4.49.0.0 nein 2 � � � � � � � � � 

SCM SCR 3311 (Chipdrive desktop pro) nein USB nicht bekannt 4.49.0.0 nein 2 � � � � � � � � � 

SCM SDI010 RFID 3 nein USB 7.33 5.18.0.0 nein 2 � � � � � � � � � 

SCM SPR 532 usb (Chipdrive pinpad) ja USB 5.1.0 4.45.0.0 ja � � � � � � � � � 

SCR 335 (Chipdrive micro pro) nein USB 5.3.2 4.49.0.0 nein 2 � � � � � � � � � 

1 unterstützte Signaturkarten (SSEE) siehe Tabellen 3 bis 5 

2 keine sichere PIN-Eingabe möglich da nur HBCI-Klasse 1 

3 unterstützt wird nur das kontaktbehaftete Interface 

4 Firmware 79.23 nur Kobil Trib@ank 

TeleSec 

DP-Com 

Datev 

BNotK 

TC-Trust 

D-Trust 

S-Trust 

Deutsche 

Rente 

Hessen- 

PKI 

29


Tabelle 9: Unterstützte Kombinationen Windows XP Professional SP3 (64 Bit) - Chipkartenlesegerät - Signaturkarte 



bestätigt 

nach SigG 

Schnittstelle 

Windows Vista Home 

Premium SP2 

Firmware Treiber 

Sichere 

PIN- 

Eingabe 

Zertifizierungsdiensteanbieter 1 



















1 unterstützte Signaturkarten (SSEE) siehe Tabelle 3 bis 5 




TeleSec 

DP-Com 

Datev 

BNotK 

TC-Trust 

D-Trust 

S-Trust 

Deutsche 

Rente 

Hessen- 

PKI 

30


Tabelle 10: Unterstützte Kombinationen Windows Vista Home Premium SP2 (32 Bit) - Chipkartenlesegerät - Signaturkarte 



bestätigt 

nach SigG 

Schnittstelle 


Premium SP2 


Sichere 

PIN- 

Eingabe 
























TeleSec 

DP-Com 

Datev 

BNotK 

TC-Trust 

D-Trust 

S-Trust 

Deutsche 

Rente 

Hessen- 

PKI 

31


Tabelle 11: Unterstützte Kombinationen Windows Vista Home Premium SP2 (64 Bit) - Chipkartenlesegerät - Signaturkarte 



bestätigt 

nach SigG 

Schnittstelle 


Premium SP2 


Sichere 

PIN- 

Eingabe 
























TeleSec 

DP-Com 

Datev 

BNotK 

TC-Trust 

D-Trust 

S-Trust 

Deutsche 

Rente 

Hessen- 

PKI 

32


Tabelle 12: Unterstützte Kombinationen Windows 7 Professional (32 Bit) - Chipkartenlesegerät - Signaturkarte 



bestätigt 

nach SigG 

Schnittstelle 

Windows 7 Professional Zertifizierungsdiensteanbieter 1 

Sichere 

PIN- 
























TeleSec 

DP-Com 

Datev 

BNotK 

TC-Trust 

D-Trust 

S-Trust 

Deutsche 

Rente 

Hessen- 

PKI 

33


Tabelle 13: Unterstützte Kombinationen Windows 7 Professional (64 Bit) - Chipkartenlesegerät - Signaturkarte 



bestätigt 

nach SigG 

Schnittstelle 

Windows 7 Professional Zertifizierungsdiensteanbieter 1 

Sichere 

PIN- 
























TeleSec 

DP-Com 

Datev 

BNotK 

TC-Trust 

D-Trust 

S-Trust 

Deutsche 

Rente 

Hessen- 

PKI 

34


Tabelle 14: Unterstützte Kombinationen openSUSE 11.2 (32 Bit) - Chipkartenlesegerät - Signaturkarte 



bestätigt 

nach SigG 

Schnittstelle 

OpenSUSE 11.2 Zertifizierungsdiensteanbieter 1 

Sichere 

Firmware 

Treiber für 

Daemon- 

PCSC-light 

Version 1.5.5 8 

PIN- 

Eingabe 

Cherry® Smartboard G83-6744 ja USB 01.04.00.00 ifdokccid-lnx-3.5.1 ja �� 5 � 5 � 5 � � � � �� 

Cherry® SmartTerminal 2000 U ja USB 6.01.00.00 scmccid_5.0.11 ja � 7 � 7 � 7 � 7 � 7 � 7 � 7 � 7 � 7 

CyberJack® e-com ja USB 3.0.69 ifd-cyberjack 3.3.5.1 ja � � � � � � � � � 

CyberJack® e-com plus ja USB 3.0.2 ifd-cyberjack 3.3.5.1 ja � � � � � � � � � 

CyberJack® pinpad Version 3 ja USB 3.0.12 ifd-cyberjack 3.3.5.1 ja � � � � � � � � � 

CyberJack® secoder ja USB 3.0.14 ifd-cyberjack 3.3.5.1 ja � � � � � � � � � 

Fujitsu Siemens KB SCR Pro ja USB 1.06 ifdokccid-lnx-3.5.1 ja � � 5 � 5 � 5 � � � � � 

Kobil KAAN Advanced ja USB 1.19 CCID 1.3.11 6 ja �� 5 � 5 � 5 � 4 � 4 � � �� 

Kobil SecOVID 3, EMV-TriCap, Trib@nk ja USB 69.18/79.23 9 CCID 1.3.11 6 ja �� 5 � 5 � 5 � 4 � 4 � � �� 

Omnikey CardMan 3121 nein USB nicht bekannt ifdokccid-lnx-3.5.1 nein 2 �� 5 � 5 � 5 � � � � �� 

Omnikey CardMan 3621 ja USB 6.00 ifdokccid-lnx-3.5.1 ja �� 5 � 5 � 5 � � � � �� 

Omnikey CardMan 3821 ja USB 6.00 ifdokccid-lnx-3.5.1 ja �� 5 � 5 � 5 � � � � �� 

Omnikey Cardman 5321 RFID 3 nein USB 5.10 ifdokrfid_lnx-2.7.0 nein 2 � � � � � � � � � 

SCM SCR 3310 nein USB nicht bekannt scmccid 5.0.11 nein 2 � � � � � � � � � 

SCM SCR 3311 (Chipdrive desktop pro) nein USB nicht bekannt scmccid 5.0.11 nein 2 � � � � � � � � � 

SCM SDI010 RFID 3 nein USB 7.33 scmccid 5.0.11 nein 2 � � � � � � � � � 

SCM SPR 532 usb (Chipdrive pinpad) ja USB 5.1.0 scmccid_5.0.11 ja � 7 � 7 � 7 � 7 � 7 � 7 � 7 � 7 � 7 

SCR 335 (Chipdrive micro pro) nein USB 5.3.2 scmccid 5.0.11 nein 2 � � � � � � � � � 

1 

unterstützte Signaturkarten (SSEE) siehe Tabelle 3 bis 5 

6 

Der Name des Lesers muss in Info.plist gekürzt werden (ifd-ccid.bundle) 

2 

keine sichere PIN-Eingabe möglich da nur HBCI-Klasse 1 

7 

eine stabile PIN-Eingabe ohne Nutzung des PinPad möglich 

3 

unterstützt wird nur das kontaktbehaftete Interface 

8 

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

4 

Siemens Card OS 4.3b kein entschlüsseln und authentisieren möglich 

9 

Firmware 79.23 nur Kobil Trib@ank 

5 StarCos 3.2 kein entschlüsseln möglich 

TeleSec 

DP-Com 

Datev 

BNotK 

TC-Trust 

D-Trust 

S-Trust 

Deutsche 

Rente 

Hessen- 

PKI 

35


8.4 Unterstützte Terminalserver-Kombinationen 

Tabelle 15: Unterstützte Einsatzumgebungen 

Clientbetriebssysteme: 

Serverbetriebssysteme: 

Handelsname des 

Chipkartenterminals 

Cherry® SmartTerminal 

2000 U 

Windows XP Prof. SP3 32 Bit 

Windows 2003 Server SP2 32 Bit 


Schnittstelle 

Firmware Treiber Terminalserver 

USB 6.01.00.00 4.55.0.0 • Citrix Metaframe Presentation Server 4.5 

• Windows Terminal Server 2003/2008 

CyberJack® e-com USB 3.0.69 6.0.8.0 • Citrix Metaframe Presentation Server 4.5 


Kobil KAAN Advanced USB 1.19 2008.7.1.1 • Citrix Metaframe Presentation Server 4.5 


Omnikey 3821 USB 6.00 1.1.24 • Citrix Metaframe Presentation Server 4.5 

Clientbetriebssysteme: 

Serverbetriebssysteme: 

Handelsname des 

Chipkartenterminals 

elux RL V 2.6.0-1 


Schnittstelle 

Kobil KAAN Advanced USB 1.19 PC/SC Lite 

V2.1.3.1-3-5 


Firmware Treiber Terminalserver 

Windows Terminal Server 2003 

TeleSec 

DP-Com 


Datev 

BNotK 

TC-Trust 

D-Trust 

S-Trust 

Deutsche 

Rente 

� � � � � � � - � 

� � � � � � � - � 

� � � � � � � - � 

� � � � � � � - � 

TeleSec 

DP-Com 


Datev 

BNotK 

TC-Trust 

D-Trust 

S-Trust 

Deutsche 

Rente 

Hessen-PKI 

Hessen-PKI 

- � � � � � � - � 

36


37

Dokumentation der MCard-Bibliothek 1.12.0.0 der bremen

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

Template löschen?

Als Template speichern?