Diese Website verwendet ausschließlich technisch erforderliche Cookies, um Ihnen den bestmöglichen Service zu gewährleisten. Weitere Informationen finden Sie in den Datenschutzhinweisen.
Alle Fragen und Antworten in der Übersicht! Sind bei Ihnen noch Fragen offen? Viele Antworten auf Ihre Fragen können wir bestimmt direkt hier in unseren FAQ-Bereichen beantworten.
Ja. Die Aktivierung von JavaScript ist Voraussetzung für die Benutzung des Server.ID Serviceportals.
Alle Server.ID Produktvarianten haben eine Laufzeit von einem Jahr. Die Kulanzzeit beträgt bis zu fünf Tage.
Ja, mit Server.ID Wildcard und Server.ID Multidomain stehen SSL/TLS-Zertifikate mit Wildcardzeichen (*) zur Verfügung.
Für die Beauftragung eines Server.ID Multidomain melden Sie sich am Serviceportal "myServer.ID" an.
Wählen Sie den Menüpunkt "Zertifikat beauftragen", „Beauftragen Sie hier“ und anschließend: "Beauftragen Sie Ihre Multidomain Zertifikate hier“.
Der Unterzeichner, die Laufzeit sowie die Verwendung von Certificate Transparency sind bereits voreingestellt. In das Feld "Mein PKCS#10 Zertifikats-Request" kopieren Sie Ihren Zertifikats-Request (CSR) hinein.
Der CSR selbst kann im Webserver oder mit einem Zusatzprogramm wie OpenSSL oder Java-Keytool erzeugt werden. Die Erzeugung des CSR ist in den entsprechenden Anleitungen dokumentiert.
Sie können die SAN-Einträge direkt mit dem eingefügten CSR beauftragen. Der eingefügte Request wird automatisch untersucht.
Anschließend werden die ermittelten Feldeinträge dargestellt und Sie erhalten die Möglichkeit, weitere Servernamen (= SAN) hinzuzufügen. Der hinzugefügte Eintrag wird automatisch überprüft und Sie können weitere Servernamen hinzufügen. Wird ein Eintrag als ungültig erkannt, so muss er wieder entfernt werden.
Bei der Registrierung legen Sie Ihr Login-Passwort fest. Unmittelbar nach Abschließen der Registrierung durch die Bestätigung der Mailadresse mittels Link ist der Zugang freigeschaltet.
Das für ein Zertifikat gültige Service-Passwort wird der technischen Kontaktperson nach der Ausstellung des Zertifikats in Form einer Auftragsbestätigung per E-Mail zugesandt.
Ein Google-Projekt für Zertifikatstransparenz: Ausgestellte Zertifikate werden in öffentlich überprüfbare, manipulationsgeschützte Logserver geschrieben, um missbräuchlich oder fehlerhaft ausgestellte TLS/SSL-Zertifikate schneller ermitteln und blockieren zu können. Während dem Zertifikatsausstellungsprozess werden erforderliche CT Logserver kontaktiert. Diese wiederum liefern in ihrer Antwort je einen signierten Zeitstempel (SCT) zurück, die dann im Zertifikat hinterlegt werden und nachweisen, dass das Zertifikat auf einem Logserver registriert wurde.
Die CT-Erweiterung ist nicht abwählbar. Das Zertifikat wird in mehrere CT-Log-Server eingetragen.
CAA ist eine zusätzliche Sicherheitsmaßnahme der Baseline Requirements des CA/Browserforums, um Missbrauch bei der Zertifikatsausstellung zu verhindern.
Die domaininnehabende Person kann durch die Hinterlegung von CAA Einträgen (Certification Authority Authorization DNS Resource Record) für jeden FQDN (Fully Qualified Domain Name) festlegen, welche Zertifizierungsstelle er für die Zertifikatsausstellung autorisiert. Im Rahmen der Auftragsvalidierung prüft die Zertifizierungsstelle alle FQDN des Zertifikatsrequests auf vorhandene CAA Einträge im DNS (CAA Records for Fully Qualified Domain Names).
Die Server.ID Zertifizierungsstelle darf das Zertifikat nur dann ausstellen, wenn für jeden FQDN eines Zertifikatauftrags ein CAA Eintrag gefunden wird, dessen issue- bzw. issuewild-Property „telesec.de“ beinhaltet oder kein CAA Eintrag hinterlegt wurde.
Wenn kein CAA Resource Record hinterlegt wurde oder dessen issue- bzw. issuewildProperty "telesec.de" enthält, dann dürfen wir das Zertifikat ausstellen und der Prüfprozess wird fortgesetzt.
Alle anderen Eintragungen, führen zur Nichtausstellung des Zertifikats.
Es werden keine SSL/TLS-Zertifikate für interne Hostnamen (z.B. CN=test) oder für IP-Adressen aus einem reservierten Adressbereich (z.B. 192.168.*.*) ausgestellt.
Solche Zertifikate wären nicht einzigartig, da sie gleichermaßen in vielen privaten Netzwerken eingesetzt werden könnten. Auch kann keine Eindeutigkeit bescheinigt werden, da die Nutzung keinerlei Registrierung voraussetzt.
Die Allgemeinen Geschäftsbedingungen (AGB) regeln die Vertragsgrundlagen zwischen den Vertragsparteien.
Alle AGB, Leistungsbeschreibungen und Preislisten haben wir für Sie im Bereich "Service > Produkt-Support > Allgemeine Geschäftsbedingungen" zusammengestellt.
Das Dokument CPS Public beschreibt in Ergänzung zu den Allgemeinen Geschäftsbedingungen die Tätigkeiten des Trust Centers der Deutschen Telekom Security GmbH in der Funktion als Zertifizierungs- und Registrierungsstelle. Es ermöglicht die qualitative Beurteilung der angebotenen Dienstleistung und dient als Entscheidungsgrundlage für eine Anerkennung der ausgestellten SSL/TLS-Zertifikate.
SAN Einträge müssen im Request mit der SAN Extension OID=2.5.29.17 kodiert sein.
Microsoft Server verwendet teilweise ein anderes Format. Im Microsoft-Technet gibt es dazu unter:
http://technet.microso ft.com/de-de/library/ff625722(v=ws.10).aspx eine ausführliche Anleitung, wie das passende Format erzeugt werden kann.
Beim CSR (Certificate Signing Request) oder Server-Zertifikat-Request handelt es sich um eine Zertifizierungsanfrage des Servers, auf dem das SSL Zertifikat installiert werden soll. Der CSR wird in der Regel von der technischen Kontaktperson auf der entsprechenden Maschine erstellt und dann manuell in die Beauftragungsseite eingefügt. Die Syntax wird durch den Standard PKCS#10 beschrieben. Die Serverapplikationen stellen für die Erstellung geeignete Tools zur Verfügung. Die produktspezifischen Eigenarten sind bei der Erstellung des Requests zu beachten.
Beim Erzeugen des Requests werden u.a. folgende Felder (Common Name, Domain Name bzw. IP-Adresse, Organization - Organisation oder Firma, Locality - Ort, State or Province - Bundesland, Country -Land) abgefragt.
Es ist zu beachten, dass diese Daten unwiderrufbar den Zertifikatsinhalt darstellen! Eine Änderung kann später nur durch eine Neubeauftragung erfolgen. Die wichtigste Angabe ist der Common Name. Hier ist die vollständige (https-)Adresse des zu zertifizierenden Servers einzutragen, z.B. www.musterfirma.de.
Hintergrund ist, dass jeder Browser seine angewählte Adresse mit der Angabe des Common Name im Zertifikat vergleicht. Stimmen diese nicht überein, so erscheint ein Sicherheitshinweis.
Der verwendete Zertifikatsrequest (CSR) muss für Neubeauftragungen/Erneuerungen eine Schlüssellänge von 2048 Bit, 3072 Bit und 4096 Bit bei RSA, bzw. 256 Bit (prime256v1) oder 384 Bit (secp384r1) bei ECC aufweisen. Andere Schlüssellängen werden nicht akzeptiert.
Bei den Ortsangaben wird auf die offizielle Schreibweise und auf die Konsistenz Land/Bundesland/Stadt/PLZ geprüft. Fehlerhafte Ortsangaben müssen korrigiert werden.
Nach der Anmeldung im Server.ID Serviceportal werden unter dem Menüpunkt "Meine Zertifikate" alle Ihre Zertifikate aufgelistet. Durch einen Klick auf die Referenznummer oder den Common Name des Zertifikats, werden Ihnen die Zertifikatdetails eingeblendet.
Für alle verlängerbaren Zertifikate steht dann der Button "Erneuern (neues Zertifikat)" zur Verfügung.
Das erneuerte Zertifikat wird in der Regel sofort ausgestellt und ist - unabhängig von der Laufzeit des zu erneuernden Zertifikats - per sofort gültig!
Um durchgehend authentische und sichere elektronische Kommunikation zu gewährleisten, muss die Erneuerung vor Ablauf der Gültigkeit erfolgen.
Die Möglichkeit der Erneuerung wird vier Wochen und eine Woche vor Ablauf des Zertifikates der technischen Kontaktperson, den Bearbeitern und ggf. weiteren mit angegebenen Kontakten aus der Rubrik „Technische Kontaktperson“ per E-Mail mitgeteilt. Die Erneuerung ist mittels vereinfachter Beauftragung über das Server.ID Serviceportal möglich.
Die Server.ID hat eine Gültigkeit von einem Jahr (+ bis zu 5 Tage).
Bei der Erneuerung wird ein neues Zertifikat mit neuer Gültigkeit, jedoch mit den Zertifikatsangaben des zu erneuernden Zertifikates generiert.
Bei der Erneuerung und auch dem Re-Issue wird nur der öffentlichen Schlüssel aus dem CSR verwendet.
Um die Erneuerung nutzen zu können, wird in vielen Webservern die Option "Verlängerung bzw. Erneuerung des Zertifikats" angeboten. Hierbei entsteht ein neuer Request, der dann auf der Website in das entsprechende Feld kopiert wird. Bietet Ihr Webserver die oben angesprochene Option nicht, muss i. d. R. ein neuer Schlüssel und damit auch ein neuer Request erzeugt werden. Einige Zusatzprogramme, wie OpenSSL können Requests mit einem bereits vorhandenen Schlüssel erzeugen.
Bitte beachten Sie die jeweiligen Betriebsdokumentationen, da die Vorgehensweisen zum Teil stark voneinander abweichen!
Bei einer Zertifikatserneuerung (Renewal) wird auf Basis des gleichen Subject-DN ein neues Zertifikat generiert, das einen neuen Gültigkeitszeitraum und eine neue Seriennummer besitzt. Es kann ein neuer öffentlicher Schlüssel eines neu generierten Schlüsselpaares oder der öffentlicher Schlüssel des Vorgängerzertifikats verwendet werden.
Eine Wiederausstellung eines Zertifikats (Re-Issue) entspricht einer Zertifikatserneuerung mit der einen Ausnahme, dass das Ablaufdatum des Vorgängerzertifikats eingetragen wird. DIESE OPTION IST KOSTENLOS.
Der Grund dafür sind technische und organisatorische Pflege- und Prüfarbeiten, die wir aus wirtschaftlicher Sicht nicht für alle Länder aufwänden können.
Durch eine Handlungsvollmacht bevollmächtigt die ausstellende Organisation / Firma eine aufgeführte Person im Namen der Firma bei EV-SSL-Zertifikaten in der Rolle als zeichnungsberechtigter, administrativer oder technischer Ansprechpartner tätig zu sein.
Die Vollmacht muss von der im Organisations-Feld des Zeritifkats aufgeführten Firma ausgestellt sein. Die Vollmacht muss von einem Geschäftsführer oder Prokuristen unterzeichnet sein. Wenn offizielle Quellen, wie bspw. das Handelsregister in der allgemeinen Vertreterregelung für Gesellschafter, Geschäftsführer, Vorstand, Vertretungsberechtigte vorgeben, dass die Firma (Gesellschaft) beispielsweise
vertreten wird, dann ist für eine rechtskräftige EV-Handlungsvollmacht zu prüfen, ob die oben genannten Regelungen eingehalten werden. (Doppelzeichnung bzw. Mehrfachzeichnung)
Im Rahmen eines Auftrags für ein EV Zertifikat können per anwaltlicher Stellungnahme alle für die Beauftragung notwendigen Nachweise erbracht werden. Eine anwaltliche Stellungnahme bestätigt:
Die folgenden Felder müssen im Subject enthalten sind: O (Organization), C (Country), ST (State), L (Locality). Optional sind die Felder STREET und PostalCode.
Die Schreibweise der Organisation muss mit der offiziellen Schreibweise, wie sie z.B. im Handelsregister aufgeführt ist, identisch sein. Bei der Angabe des O-Feldes können nicht irreführende und gebräuchliche Abkürzungen (bspw. Weglassen der Rechtsform) verwendet werden.
Bei den Adressinformationen sollte vorzugweise die physikalische Adresse des Geschäftssitzes der Organisation benutzt werden. Alternativ kann auch eine, über offizielle Quellen nachprüfbare Adresse einer Niederlassung o.ä. genutzt werden. Eine Angabe von Postfächern o.ä. ist nicht erlaubt.
Bei der Beauftragung eines sind folgende Punkte zu beachten oder wichtig:
Folgen Sie auf der Anmeldeseite zum Serviceportal dem Link "Haben Sie Ihr Passwort vergessen?"Hier können Sie nun unter Angabe der entsprechenden E-Mailadresse sowie des angegebenen Sicherheitscode ein neues Passwort anfordern. Weitere Informationen zur Zurücksetzung Ihres Passwortes werden an die von Ihnen angegebene E-Mailadresse gesendet.
Bitte nehmen Sie mit unserem Service-Desk Kontakt auf.
Die Registrierung für das Serviceportal ist für Sie kostenfrei.
Sobald das Zertifikat genehmigt und ausgestellt wurde, wird es im Serviceportal unter dem Menüpunkt "Meine Zertifikate" aufgelistet. Ein Klick auf die Referenznummer oder den Common Name des Zertifikats blendet die Zertifikatdetails ein. Etwas weiter unten besteht dann die Möglichkeit des Downloads in mehreren Formaten.
Sobald das Zertifikat ausgestellt wurde, wird zudem die technische Kontaktperson und die Bearbeiter per E-Mail informiert.
Im Serviceportal unter dem Menüpunkt "Meine Zertifikate" finden Sie nur Zertifikate, die genehmigt und ausgestellt wurden. Zertifikate, die noch nicht genehmigt und ausgestellt wurden, finden Sie unter "Auftragsstatus".
Es stehen zwei Möglichkeiten zur Auswahl:
Nach der Anmeldung am Magenta Security Server.ID Serviceportal werden unter dem Menüpunkt "Meine Zertifikate" alle Ihre Zertifikate aufgelistet. Für alle verlängerbaren Zertifikate steht dann der Button "Verlängern" zur Verfügung.
Die bestehende technische Kontaktperson ist im Serviceportal unter einer Organisation angemeldet. Er kann durch eine „Accountübertragung“ seine Berechtigung an dieser Organisation auf eine neue technische Kontaktperson übertragen.
Einzige Voraussetzung ist, dass sich die neue technische Kontaktperson am Serviceportal registriert hat. Sobald die bestehende technische Kontaktperson die E-Mailadresse im Abschnitt -Technische Kontaktperson - ändert, erscheint ein Abfrage nach der „Art der E-Mail Adressänderung“ (Übergabe des Accounts / Nur Änderung der E-Mail-Adresse) und es wird ein Informationstext mit der Beschreibung der Übergabe-Prozedur angezeigt. Außerdem wird ein Sitzungs-Passwort angezeigt. Dieses einmalige Sitzungspasswort ist zu notieren und sicher an die neue technische Kontaktperson zu übermitteln. Eine Änderung der E-Mail-Adresse auf eine bereits im Serviceportal bekannte E-Mail-Adresse ist nicht möglich. Verwenden Sie in diesem Fall die Option „Übergabe des Accounts“. Das System versendet eine Nachricht an die neu vergebene E-Mail-Adresse. Hierin besteht die Möglichkeit die neue Zuordnung zu akzeptieren oder abzulehnen.
Verschiedene Vorgehensweisen:
1. Übergabe des Accounts:
a) Die neue E-Mail-Adresse ist bereits im System bekannt: Bei Akzeptanz kann sich die neue technische Kontaktperson mit ihren eigenen Accountdaten am Serviceportal anmelden, mit dem Sitzungs-Passwort autorisieren und hat damit unmittelbar Zugang zu den Zertifikaten dieser Organisation übernommen.
b) Die neue E-Mail-Adresse ist nicht im System bekannt: Bei Akzeptanz muss sich die neue technische Kontaktperson mit dem Sitzungs-Passwort autorisieren und kann sich danach ein eigenes Login-Passwort vergeben und hat damit unmittelbar Zugang zu den Zertifikaten dieser Organisation übernommen.
2. Änderung der E-Mail-Adresse:
Bei Akzeptanz muss sich die neue technische Kontaktperson mit dem Sitzungs-Passwort autorisieren und kann sich danach ein eigenes Login-Passwort vergeben und hat damit unmittelbar Zugang zu den Zertifikaten dieser Organisation übernommen.
Hat die bestehende technische Kontaktperson noch weitere Organisationen die er verwaltet, so kann er dies weiterhin durchführen. Ansonsten muss die Übergabe-Prozedur für jede verwaltete Organisation angestoßen werden, die übertragen werden soll.
Wenn die Übergabe an eine neue technische Kontaktperson im Vorfeld nicht erfolgt ist (beispielsweise steht ein ausgeschiedener Mitarbeiter nicht mehr zur Verfügung), hat man folgende zwei Möglichkeiten:
Ja. Die Aktivierung von JavaScript ist Voraussetzung für die Benutzung des Magenta Security Server.ID Serviceportals.
Eine Übersicht der Root-/Sub-CA-Zertifikate finden Sie im Bereich "Root Programm".
Eine Übersicht der Applikationen und Betriebssysteme, in denen die Server.ID Root-Zertifikate implementiert sind, finden Sie hier.
Beim Aufruf einer Internetseite per https prüft der Webbrowser eine Vertrauenskette von Zertifikaten.
Diese besteht in der Regel aus dem eigentlichen Webserver-Zertifikat, dem Zwischenstellen-Zertifikat (Sub-CA) sowie dem Root-Zertifikat (Vertrauensanker) der ausstellenden Instanz. Während das Root-Zertifikat ein Bestandteil des Webbrowsers ist, müssen sowohl das Webserver- als auch das Sub-CA-Zertifikat im Server installiert werden. Diese werden beim Seitenaufruf vom Webserver an den Browser übermittelt. Nach erfolgreicher Prüfung wird das Webserver-Zertifikat vom Browser als vertrauenswürdig eingestuft.
Sobald das Zertifikat genehmigt und ausgestellt wurde, wird es im Serviceportal unter dem Menüpunkt "Meine Zertifikate" aufgelistet. Ein Klick auf die Referenznummer oder den Common Name des Zertifikats blendet die Zertifikatdetails ein.
Dort können Sie über den Button "Download (inkl. Zertifikatskette)" das Zertifikat mit dem dazugehörigen Sub-CA-Zertifikat herunterladen.
Nein, das Sub-CA-Zertifikat muss nur einmal installiert werden und verbleibt danach im Zertifikatsspeicher des Webservers.
Tipp: Installieren Sie neben dem Webserver-Zertifikat immer auch das Sub-CA-Zertifikat. Bei einem Austausch des Sub-CA-Zertifikats ist resultierend immer gewährleistet, dass das Webserver-Zertifikat fehlerfrei verwendet wird.
Sie können Ihr Serverzertifikat im Serviceportal jederzeit herunterladen.
Der geheime Schlüssel und das Serverzertifikat bilden eine untrennbare Einheit. Geht der geheime Schlüssel verloren, wird das Serverzertifikat unbrauchbar und muss sofort von Ihnen gesperrt werden.
Vor der Sperrung können Sie das bestehende Zertifikat per Re-Issue mit einem neuen Schlüsselpaar kostenlos für die Restlaufzeit neu ausstellen lassen.
Wichtig ist: Wenn Sie ein Re-Issue gestartet haben, dürfen Sie erst nach Neuausstellung des beauftragten Zertifikates das Ursprungszertifikat sperren.
Der ausgedruckte und unterschriebene Onlineauftrag und falls:
Ja, auch die Zertifizierung einer IP-Adresse ist möglich.
Server.ID liefert alle Zertifikate im PEM-Format aus (Base64 kodiert X.509), wahlweise mit Zertifikatskette oder ohne.
Typische Tools zur Umwandlung von Zertifikaten sind z.B. certutil unter Windows oder OpenSSL unter Linux und Windows. Für certutil finden Sie passende Anleitungen unter https://docs.microsoft.com/de-de/windows-server/administration/windows-commands/certutil
OpenSSL ist verfügbar unter https://openssl.org. Dort finden Sie auch Hinweise, Manuals und Anleitungen.
Eine exzellente Einführung mit vielen Beispielen finden Sie auch unter https://www.feistyduck.com/books/openssl-cookbook/
Als Kurzreferenz finden Sie im weiteren Verlauf einige Beispiele:
PEM zu DER
openssl x509 -outform der -in zertifikat.pem -out zertifikat.der
PEM zu P7B
openssl crl2pkcs7 -nocrl -certfile zertifikat.pem -out zertifikat.p7b -certfile CACert.cer
Privaten Schlüssel aus pfx extrahieren
Um Ihren private key aus Ihrem alten pfx File (certname.pfx) zu extrahieren, benutzen Sie folgendes Kommando:
openssl pkcs12 -in zertifikat.pfx -nocerts -out key.pem -nodes
Ihr privater Schlüssel befindet sich jetzt in der Datei key.pem.
Sollten Sie den private key noch im Zugriff haben, können Sie diesen auch direkt verwenden.
CER zu PEM (Binary nach ASCII)
openssl x509 -inform der -in CACert.cer -out CACert.pem
PFX aus PEM erstellen
openssl pkcs12 -export -in ServerPass.pem -inkey key.pem -out zertifikat.pfx -certfile CACert.pem
ServerPass.pem ist Ihr Serverpass welchen Sie aus dem Portal heruntergeladen haben.key.pem ist der private Schlüssel.zertifikat.pfx ist Ihr fertiges Zertifikat.CACert.pem stellt hierbei das Intermediate Zertifikat einer CA dar.
Es werden RSA-Schlüssel mit einer Schlüssellänge von 2048 Bit, 3072 Bit oder 4096 Bit, sowie ECC-Schlüssel mit 256 Bit (prime256v1) oder 384 Bit (secp384r1) zertifiziert.
Das Telekom Trust Center erstellt in regelmäßigen Abständen Sperrlisten (Certificate Revocation List, CRL), in der alle gesperrten Zertifikate eingetragen werden. Die Sperrlisten sind über die Webseite abrufbar.
Zusätzlich können die Server.ID-Zertifikate auch via OCSP-Protokoll geprüft werden.
Nähere Angaben hierzu finden Sie in der CPS Public.
Es wird NIE der Secret Key mittels CSR an uns übermittelt. Deshalb muss das von uns ausgestellte Zertifikat erst mit dem von Ihnen bei der Erstellung des CSR generierten Secret Key zusammengeführt werden.
Wir empfehlen zur Signaturprüfung die Verwendung einer Signatursoftware aus dem Bereich Software. Die hier genannten Hersteller sind bei uns als Partner registriert. Sie erhalten frühzeitig Informationen über Neuerungen bzgl. der Nutzung unser qualifizierten Signaturkarte. So ist sichergestellt, dass deren Software immer mit den neuesten Signaturkarten funktioniert. Für Sie als Nutzer ist es besonders wichtig Ihre Signatursoftware immer aktuell zu halten. Nur so ist gewährleistet, dass notwendige Anpassungen an der Signaturkarte oder unseren Services nicht zu Fehlern führen. Falls Sie Nutzer einer Plattform mit integrierter Signatursoftware sind, so gilt diese Pflicht ebenso für den Betreiber Ihrer Fachanwendung.
Die EU bietet einen Service für die schnelle Online Prüfung einer qualifiziert signierten Datei an. Sie erreichen diesen Service unter der URL https://ec.europa.eu/cefdigital/DSS/webapp-demo/validation.
Andere Hersteller unterstützen unsere Signaturkarte ebenfalls.
Fragen zur Kompatibilität einer Signatursoftware mit einem bestimmten Anwendungszweck oder einer Fachanwendung richten Sie bitte an den Hersteller der Software oder den Betreiber der Fachanwendung.
Auf Grund der Verwendung eines Signaturformats, welches durch das deutsche Bundesamt für Sicherheit in der Informationstechnik (BSI) spezifiziert wurde, kommt es bei Nutzung unserer Signaturkarte mit Software von nicht europäischen Herstellern teilweise zu Fehlern. Weitere Informationen erhalten Sie unter dem Stichwort "Welches Signaturformat verwendet Qualified.ID?". Dies betrifft insbesondere die Nutzung der qualifizierten Signaturfunktion mit Adobe Produkten sowie die Nutzung der Verschlüsselungsfunktion mit Thunderbird. Dies gilt ebenso für die Nutzung unserer Signaturkarte innerhalb von Fachanwendungen innerhalb der EU.
Wenn Sie eine qualifiziert signierte Datei an einen Empfänger senden und dieser die Prüfung wegen obiger Fehler ablehnt, dann können Sie ihn zusätzlich auf die folgenden unabhängigen Informationsquellen hinweisen:
Das Dateiformat der zu signierenden Datei hat für Qualified.ID keine Bedeutung. Sie können also jedes beliebige Dateiformat signieren.
Genaugenommen „sieht“ die Signaturkarte Ihre Datei nicht einmal. Die Karte verarbeitet einen Hashwert, der von Ihrer Signaturanwendung erstellt und an Ihre Karte übertragen wird. Dies ist genau der Moment in dem Sie die PIN eingeben.
Es kann von Ihrer Signaturanwendung abhängig sein, welches Dateiformat Sie signieren können. Wir empfehlen zur Signaturerstellung die Verwendung von Signatursoftware deutscher Hersteller. Nach unserem Kenntnisstand sind diese auch in vielen Signaturanwendungen integriert.
Bei Signatursoftware von anderen Herstellern (z.B. wenn Sie an EU-weiten Plattformen teilnehmen) können die Signaturen von Qualified.ID manchmal nicht verarbeitet werden. Dies liegt an der Verwendung der noch nicht so weit verbreiteten ECDSA Signatur (siehe Welches Signaturformat verwendet Qualified.ID?).
Die Anleitung zur Aktivierung/Inbetriebnahme Ihrer Signaturkarte im PDF Format finden Sie im Downloadbereich.
Die Fehlermeldung UnknownHostException oder ConnectTimeoutException bei der Inbetriebnahme der Signaturkarte im letzten Schritt "Empfang bestätigen und Karte freischalten" bedeutet wahrscheinlich, dass Sie Ihre Signaturkarte in einem Firmennetzwerk nutzen über das Sie keinen direkten Internetzugang haben. Stattdessen nutzen Sie wahrscheinlich einen Proxy zur Verbindung ins Internet.
Ihre SignLive Toolbox ist von uns auf direkte Internetverbindung voreingestellt. Bitte klicken Sie im Hauptfenster der SignLive Toolbox auf "Erweitert" und anschließend auf "Einstellungen". Im Bereich "Internetverbindung" können Sie nun den Proxy einstellen. In den meisten Fällen ist die Einstellung "Systemeinstellungen verwenden" die richtige Auswahl.
Nach Durchführung dieser Einstellung können Sie den Inbetriebnahmeassistenten erneut starten und jetzt im letzten Schritt auch online den Empfang der Karte bestätigen.
Bitte wenden Sie sich an den Hersteller der Software.
Sie benötigen einen PC mit einem Chipkartenleser und geeigneter Anwendungssoftware. Wir empfehlen die Verwendung von Signatursoftware unserer Partnerfirmen. Bitte beachten Sie dazu den Punkt Signatursoftware auf unserer Webseite.
Zur Nutzung der Signaturkarte bieten wir Treiber für unterschiedliche Standardschnittstellen an:
Bitte beachten Sie, dass es sich bei den oben beschriebenen Treibern ausschließlich um Möglichkeiten für die Einbindung der Karte in andere Programme handelt. Diese Treiber beinhalten nicht den Funktionsumfang, den eine vollständige Signatursoftware benötigt. Insbesondere beinhalten diese Treiber nicht die Möglichkeit zur Prüfung einer qualifizierten Signatur.
Auf Grund der Verwendung eines durch das deutsche Bundesamt für Sicherheit in der Informationstechnik spezifizierten Signaturalgorithmus unterliegt die Nutzung der qualifizierten Signatur in verschiedenen Anwendung gewissen Einschränkungen. Bitte beachten Sie dazu unsere FAQ "Welches Signaturformat verwendet Qualified.ID?".
Unsere Auftragsprozesse unterstützen die Verwendung des Zeichensatzes ISO/IEC 8859-1. Dieser Standard ist auch als Latin-1 bekannt. ISO/IEC 8859-1 versucht, möglichst viele Zeichen westeuropäischer Sprachen abzudecken. In diesen beiden Tabellen finden Sie welche Zeichen erlaubt sind
Leider sind beispielsweise einige im Französischen verwendete Zeichen und das Euro-Symbol in diesem Zeichensatz nicht enthalten. Bitte beachten Sie dazu die folgende Vorgehensweise:
Insbesondere für die Emailadresse gibt es weitere Einschränkungen. Im Feld Emailadresse lassen wir keine Umlaute oder Sonderzeichen anderer Sprachen zu.
Mit einem Folgeauftrag können Besitzer einer gültigen und funktionsfähigen Qualified.ID eine neue Signaturkarte beauftragen. Sie benötigen dabei keine erneute Identifikation oder Nachweise für ggf. in Ihrem Zertifikat enthaltene Zusatzinformationen (z.B. Handelsregisterauszug bei Geschäftsführer oder Bestätigung durch Ihre Kammer bei Ärzten, Anwälten, usw.).
Bitte beachten Sie, dass auf Grund der eIDAS Verordnung Folgekartenaufträge nur bearbeitet werden dürfen, wenn diese direkt auf einer persönlichen Identifikation von Ihnen beruhen. Es darf kein Folgekartenauftrag bearbeitet werden, der bereits mit einer Folgekarte signiert wird. In diesem Fall ist eine Neubeauftragung notwendig!
Den Folgeauftrag führen Sie komplett online aus. Bitte starten Sie den Vorgang hier. Wenn Sie Ihre aktuelle Signaturkarte über einen Kooperationspartner des Trust Centers erworben haben, so bitten wir Sie, dass Sie sich an diesen Kooperationspartner wenden. Insbesondere können wir die zusätzlichen Serviceleistungen Ihres Kooperationspartners nicht erbringen.
Zur Erzeugung eines Folgeauftrags müssen Sie Ihre Kontaktdaten, die Versandadresse der Signaturkarte sowie die Rechnungsadresse erneut eingeben. Den Folgeauftrag können Sie nicht verwenden wenn sich in der Zwischenzeit Ihr Name oder der Inhalt von Zusatzinformationen im Zertifikat geändert hat. In diesen Fällen benötigen wir von Ihnen einen Neuauftrag.
Mit der Signatur des Folgeauftrags bestätigen Sie uns, dass sich Ihr Name nicht geändert hat und das Sie eine neue Signaturkarte, zu den zu diesem Zeitpunkt gültigen, AGB beauftragen.
Bitte beachten Sie vor der Verwendung des Folgeauftrages unsere Anleitung im folgenden Dokument: > Installation Universal Smartcard Browser Gateway.
Bevor Sie den Folgeauftrag starten, sollten Sie alle anderen Programme, die die Signaturkarte nutzen, beenden, da diese den Zugriff auf die Signaturkarte behindern könnten. Achten Sie dabei auch auf Hintergrundprogramme.
Wir benötigen zur Ausstellung eines qualifizierten Zertifikates auf jeden Fall eine Ausweiskopie von Ihnen.
Wenn Sie möchten, dann können Sie auf der Kopie die Felder Augenfarbe, Größe und die Zugangssnummer so wie das Bild schwärzen. Alle anderen Angaben auf dem Ausweis benötigen wir jedoch.
Sollte ein Registrierungsmitarbeiter von Ihnen jedoch die Herausgabe Ihres Ausweises, zum Zweck des Kopierens, verlangen, so können Sie dies ablehnen. Es ist gesetzlich festgelegt, das Sie niemand dazu zwingen darf Ihren Ausweis an ihn abzugeben oder bei ihm zu hinterlegen.
Sie sollten in diesem Fall den Registrierungsmitarbeiter zum Kopierer begleiten so dass er die Kopie in Ihrem Beisein ausführt.
Eine genaue Beschreibung und den notwendigen PostIdent-Coupon finden Sie in unserem Download-Bereich.
Ihren Qualified.ID Auftrag senden Sie immer im Original an die im Auftrag angegebene Adresse.
Bei CAdES, PAdES und XAdES handelt es sich um technische Spezifikationen von Signaturformaten, die über die allgemein genutzten Signaturformate hinausgehen.
Für Ihre Signaturkarte haben diese speziellen Erweiterungen keine Bedeutung. Die Erweiterungen der Signaturformate werden von Ihrer Signaturanwendung erzeugt. Falls Sie eine Signatur in einem der obigen Formate erzeugen müssen prüfen Sie bitte ob Ihre Signaturanwendung das Format unterstützt.
Bevor Sie mit Ihrer Karte rechtsverbindlich signieren können, ist die Durchführung der Empfangsbestätigung zwingend erforderlich! Erst danach kann der Status Ihres Zertifikats im Verzeichnisdienst überprüft werden. Die Empfangsbestätigung können Sie uns bequem online übermitteln.
Nutzen Sie dafür den folgenden Link Online-Empfangsbestätigung.
Sie haben die Möglichkeit, ein frei wählbares Pseudonym auf dem Auftrag anzugeben. Das Pseudonym wird im Zertifikat als solches gekennzeichnet (mit einem Zusatz „:PN“). Ihr Name ist im Zertifikat nicht vorhanden. Bei einer Prüfung einer mit diesem Zertifikat erstellten elektronischen Signatur wird das Pseudonym als Signaturersteller angezeigt. Das Zertifikat ist Ihnen persönlich trotzdem zweifelsfrei zugewiesen. In Rechtsfällen sind wir verpflichtet, berechtigten Stellen Auskunft über den Inhaber der Zertifikate zu geben.
Diese Überprüfung ist auf Grund von Anforderungen der Browser Hersteller (Microsoft, Mozilla), des CABrowser Forums und der daraus erforderlichen ETSI Zertifizierung erforderlich. Damit wird sichergestellt, dass nur Sie als Eigentümer Ihrer Emailadresse eine Signaturkarte bekommen können, die diese Emailadresse enthält.
Sollten Sie keine Email mit der Prüfnummer erhalten, so sehen Sie bitte in Ihrem SPAM-Filter nach oder warten Sie einen Moment. Die Zustellung einer Email kann einige Minuten dauern. Bitte wenden Sie sich ggf. an unseren Support. Die Kollegen dort können Ihnen die Email mit der Prüfnummer erneut zusenden.
Wir informieren Sie etwa 6 Wochen vor Ablauf des Zertifikats per eMail. Wir empfehlen Ihnen dann eine neue Qualified.ID zu beauftragen. Die einfachste Möglichkeit zur Beauftragung einer neuen Signaturkarte für Bestandskunden ist der Folgeauftrag.
Falls Ihr Zertifikat im öffentlichen Verzeichnis nicht auffindbar ist, kann dies folgende Ursachen haben:
Für die Nutzung des EGVP werden zwei verschiedene Zertifikate benötigt. Zum einen wird ein qualifiziertes Signaturzertifikat für das Signieren von Nachrichten verwendet. Mit diesem Erfordernis wird den Anforderungen aus den Verfahrensverordnungen (insbesondere Schriftformerforderniss) Rechnung getragen. Darüber hinaus ist die Nutzung eines weiteren Zertifikates für die Ende-zu-Ende-Verschlüsselung des Transportweges erforderlich.
Mit diesem Zertifikat werden das Postfach geöffnet und die Nachrichten (für Sie unbemerkt) ver- und entschlüsselt. Seit der Version 2.6.0 von EGVP werden an dieses Zertifikat besondere Anforderungen gestellt. Es muss sich dabei um ein sog. Kombinationszertifikat (ein Zertifikat mit dem gleichzeitig signiert, ver- und entschlüsselt werden kann) handeln. Ein Zertifikat, dass diese Anforderungen erfüllt ist auf Ihrer Qualified.ID Signaturkarte nicht enthalten. Die Anforderungen an Kombinationszertifikate werden durch Softwarezertifikate erfüllt.
Das EGVP bietet die komfortable Möglichkeit Softwarezertifikate zu erstellen und in die Anwendung einzubinden. Dabei handelt es sich um die von EGVP empfohlene Art der Nutzung Ihres Postfachs. Einzelheiten sind in der Anwenderdokumentation des EGVP unter Punkt 6.1.1.2.1 beschrieben.
Diese Zertifikate haben unterschiedliche Einsatzzwecke.
Wenn von Ihrer Anwendung eine "qualifizierte Signatur" gefordert wird und Sie das falsche Zertifikat zur Signaturerstellung verwenden, so wird diese Signatur von der Gegenseite abgelehnt.
Ein "qualifiziertes Signaturzertifikat" erkennen Sie am einfachsten an seinem Aussteller. Alle qualifizierten Signaturzertifikate, die von der Deutschen Telekom AG ausgestellt wurden, verwenden einen Aussteller dessen Name mit TeleSec PKS eIDAS QES CA oder TeleSec PKS SigG CA beginnt. Danach folgt eine Nummer.
Achten Sie hier unbedingt auf eIDAS QES oder SigG im Namen des Ausstellers.
Die Bereitstellung von Sperrlisten zu qualifizierten Zertifikaten wurde am 02.07.2015 eingestellt.
Das Trust Center wurden schon vor Jahren durch die Aufsichtsbehörde für die qualifizierte Signatur -der Bundesnetzagentur- gebeten, die Veröffentlichung der CRL einzustellen.
Hintergrund ist einfach der, dass eine korrekte Prüfung lediglich aufgrund einer Sperrliste nicht ausreichend sei, um die Anforderungen des Signaturgesetzes zu erfüllen. Da die Existenz des Zertifikats im Verzeichnisdienst nachgewiesen werden muss, ist eine OCSP-Abfrage bzgl. dieses Zertifikats durch die Signaturanwendungskomponente zwingend erforderlich. Die OCSP Antwort fungiert als Nachweis über den aktuellen Status des Zertifikats.
Wir haben dann, nachdem auch die Bundesnetzagentur die Veröffentlichung ihrer CRL eingestellt hat und keine negativen Erfahrungen bei den Kunden und Softwareherstellern bekannt wurden, uns auch entschlossen dieser Aufforderung nachzukommen.
Bitte nutzen Sie zur Prüfung der Gültigkeit qualifizierter Zertifikate die Online-Prüfung mit OCSP in Ihrer Signatursoftware.
Qualified.ID verwendet den Signaturalgorithmus ECDSA. Diese Art der Kryptografie kommt, bei gleicher Sicherheit, mit deutlich kürzeren Schlüssellängen aus wie die RSA Kryptografie und ist somit auch deutlich performanter.
Bei diesem Signaturalgorithmus handelt es sich um eine Anwendung der Kryptografie mit elliptischen Kurven. Hier muss neben dem Algorithmus auch noch die verwendete Kurve angegeben werden. Solche Kurven wurden von mehreren Organisationen spezifiziert. Weltweit am stärksten verbreitet sind die elliptischen Kurven, die durch das US amerikanische NIST (National Institute of Standards and Technology) spezifiziert wurden.
Der Signaturalgorithmus RSA (genauer RSA mit PKCS#1 Version 1.5 Padding) wurde von der Bundesnetzagentur im Jahr 2016 als nicht mehr empfohlen für qualifizierte Signaturen ab dem Jahr 2018 eingestuft. Wir nehmen an, dass manche Signaturplattformen ihre Nutzer deswegen informiert haben, dass nur noch RSASSA-PSS Signaturen zugelassen werden. Dabei handelt es sich ebenfalls um Signaturen gemäß RSA Standard, jedoch mit modernerem Padding (genauer PKCS#1 Version 2.1).
Beim Padding handelt es sich um eine Vorschrift wie der während der Signatur erzeugte Hashwert des Dokuments auf die gleiche Länge wie der RSA Schlüssel (also meistens 2048 Bit) gebraucht wird. Hashwerte sind üblicherweise nur 256 Bit lang. Dies ist für die Rechenoperation mit dem RSA Schlüssel erforderlich.
Die Qualified.ID erzeugt keine RSA Signatur. Sie kann somit auch keine RSASSA-PSS Signatur erzeugen. Die Qualified.ID verwendet einen Signaturalgorithmus, der eine andere mathematische Basis hat (siehe Welches Signaturformat verwendet Qualified.ID?). Bei der ECDSA Signatur ist kein Padding erforderlich.
Sowohl RSA als auch ECDSA sind gemäß der EU Vorschriften geeignete Signaturalgorithmen für die Erstellung qualifizierter Signaturen. Daher erwarten wir, dass die von den Signaturplattformen herausgegebenen Informationen also nur für Signaturkarten gelten, die RSA Signaturen erzeugen und Sie Qualified.ID weiterhin nutzen können.
Die Dateiformate P12 oder PFX sind international spezifiziert als PKCS#12 Format. Dieses Dateiformat enthält neben Ihrem Zertifikat auch den dazugehörigen privaten Schlüssel. Aufgrund der Anforderungen an qualifizierte Signaturzertifikate darf der zugehörige private Schlüssel nicht ausgelesen werden. Aus diesem Grund ist es nicht möglich von der Qualified.ID Signaturkarte Dateien im P12- oder PFX-Format zu erstellen.
Falls Sie Nutzer des Betriebssystems Windows sind, fahren Sie fort wie in der FAQ "Wie importiere ich meine Signaturkarte in den Windows-Zertifikatsspeicher?" beschrieben.
Als Nutzer eines anderen Betriebssystems nutzen Sie bitte die von uns angebotenen PKCS#11-Treiber an.
Falls Ihr Zertifikat online nicht nachprüfbar ist, kann dies folgende Ursachen haben: Sie haben die Empfangsbestätigung noch nicht zurück geschickt. Ist dies der Fall, so verfahren Sie bitte wie bei "Was bedeutet die Freischaltung des Zertifikats (Verzeichnisdienst)?" beschrieben und holen Sie die Freischaltung des Zertifikats nach. Es ist auch möglich, dass Ihr Zertifikat gesperrt wurde.
Das Zertifikatsprofil können Sie in unserem Downloadbereich herunterladen.
Wir bieten Ihnen die Möglichkeit an, alle unsere CA Zertifikate in einem Paket herunterzuladen. Darin enthalten sind neben den aktuell genutzten Zertifikate für die Ausstellung qualifizierter Signaturzertifikate auch ehemals genutzte Zertifikate für die Ausstellung qualifizierter Signaturzertifikate und Ausstellerzertifikate für andere Zwecke.
Unsere Chipkarten werden von den gängigen Chipkartenlesern am Markt unterstützt. Jedoch wird oft ein gewisser Firmwarestand vorausgesetzt. Details hierzu sind in der Beschreibung des Kartenlesers zu finden.
Die Sperrung Ihrer Signaturkarte können Sie jederzeit, online unter dem unten angegebenen Link veranlassen.
Zusätzlich können Sie die Sperrung entweder telefonisch 24 Stunden am Tag nach Identifikation durch Ihr Telepasswort bzw. TelePIN oder schriftlich beauftragen.
Die Kontaktdaten für alle Möglichkeiten und die OnlineSperrung finden Sie unter Sperrservice.
Zur Nutzung dieser Funktion müssen Sie Ihre Ergänzungszertifikate auf der Signaturkarte installiert haben. Danach gehen Sie wie folgt vor.
Der Firefox bietet die Möglichkeit einen Treiber für eine Signaturkarte direkt zu laden. Dazu wird das PKCS#11 Modul von unserer Webseite (im bereich Secure Elements & Smartcards) benötigt. Hier ist darauf zu achten die Version (32 Bit oder 64 Bit) zu verwenden für die der Browser erstellt wurde. Die Information findet man in Firefox über Hilfe -> Über Firefox. Meistens wird heutzutage die 64 Bit Version benötigt. Danach in den Einstellungen von Firefox unter dem Punkt "Datenschutz & Sicherheit" den Button "Zertifikate anzeigen" auswählen und im Tab "Zertifizierungsstelle" die CA "TeleSec PKS CA 9" aus importieren. Dieses Zertifikat ist in einem Paket enthalten. Beim Import die beiden Häkchen "Webseite identifizieren" und "E-Mail nutzer identifizieren" anklicken. Danach den Button "Kryptografie Module" auswählen. Dort dann P11TCOS3NetKey64.dll oder P11TCOS3NetKey.dll aus dem Download des PKCS#11 Moduls laden. Spätestens jetzt die Karte einlegen und darauf achten das beim einlegen die grüne LED kurzzeitig blinkt. Jetzt wieder "Zertifikate anzeigen" und da auf das Tab "Ihre Zertifikate" gehen. In dem Moment wird wahrscheinlich jetzt schon die PIN am Kartenleser abgefragt.
Einige Webseitenbetreiber (z.B. das Unified Patent Court) fordern für die Authentisierung an Ihrer Plattform die Nutzung des qualifizierten Zertifikats. Das qualifizierte Zertifikat der Qualified.ID besitzt jedoch nicht die notwendigen Zertifikatsinhalte damit ein Browser damit eine Authentisierung machen würde. Derzeit ist Qualified.ID für den geforderten Zweck nicht einsetzbar.
Grundsätzlich erlauben die europäischen Richtlinien die dafür notwendigen Inhalte zwar in einem qualifizierten Zertifikat, sie verweisen jedoch gleichzeitig auf dadurch entstehende Sicherheitsprobleme. Aus diesem Grund haben wir uns dafür entschieden den Zertifikatsinhalt so festzulegen das damit keine Authentisierung möglich ist.
Diese Zertifikate werden von uns als Ergänzungszertifikate bezeichnet. In Ihrer Fachanwendung werden sie möglicherweise auch als „nicht qualifizierte Zertifikate“ bezeichnet. Sie erhalten diese – optional – kostenlos zu Ihrer Qualified.ID und sie sind nicht Bestandteil des Qualified.ID Vertrags.
Voraussetzung zum Erhalt dieser Zertifikate ist die Angabe einer gültigen E-Mail-Adresse im Feld „E-Mail zur Aufnahme ins Zertifikat“ bei der Beauftragung der Signaturkarte. Sollten Sie hier keine oder eine falsche Angabe getätigt haben, können Ihnen keine Ergänzungszertifikate zur Verfügung gestellt werden. Eine nachträgliche Aufnahme Ihrer E-Mail-Adresse ins Zertifikat ist nicht möglich, dies bedingt eine Neubeauftragung!
Nach Durchführung der Empfangsbestätigung (Freigabe Ihrer Signaturkarte) erhalten Sie nach ca. 2 Stunden eine Mail, welche den Link und die Zugangsdaten/Kennwort für die Erzeugung dieser Ergänzungszertifikate beinhaltet.
Bitte folgen sie der Anleitung > Installation-PKS-Ergänzungszertifikate für die Erzeugung und Installation der Ergänzungszertifikate.
Sollten Sie trotz korrekter Angabe Ihrer E-Mail-Adresse keine Zugangsdaten erhalten haben, prüfen Sie bitte den Spam-Ordner Ihres E-Mail-Postfachs. Sollte sich auch hier keine Mail mit den Zugangsdaten befinden, so nutzen Sie bitte unser > Kontaktformular.
Als Thema wählen sie bitte „Qualified.ID“ für die Anfrage aus.
Bitte beachten Sie:
Dieser Fehler kann im Zusammenhang mit der PIN Eingabe am Kartenleser auftreten. Dies betrifft sowohl den Signaturvorgang als auch die PIN Änderung bzw. PIN Zurücksetzung.
Für die Eingabe der PIN an der Tastatur des Kartenlesers haben Sie, je nach verwendeter Software, 30 Sekunden bis eine Minute Zeit. In dieser Zeit muss die PIN vollständig eingegeben und mit der Taste OK am Kartenleser bestätigt sein. Im Falle der PIN Änderung müssen die alte PIN, die neue PIN und die Wiederholung der neuen PIN in der geforderten Zeit eingegeben werden. Bitte achten Sie außerdem auf das betätigen der Taste OK nach der Eingabe jedes Teils. Sollte dieser Fehler Zeitüberschreitung bei Ihnen aufgetreten sein, können Sie den Signatur- oder PIN-Änderungsvorgang normalerweise einfach erneut starten.
Bitte achten Sie darauf das Sie nicht mit der PIN Eingabe beginnen ehe der Kartenlser bereit dazu ist. Ihr Kartenleser zeigt diese Bereitschaft entweder auf seinem Display oder durch eine LED mit Schlosssymbol an. Wenn Sie zu früh mit der Eingabe beginnen, wird Ihre Karte die PIN ablehnen weil sie unvollständig und damit falsch ist.
Da Ihre Qualified.ID Karte unterschiedliche Anwendungen mit unterschiedlichen Sicherheitsanforderungen enthält, werden diese durch separate PINs geschützt.
Ihre Chipkarte wird mit einem elektronischen Siegel ausgeliefert. Dieses Verfahren wird als NullPIN-Verfahren bezeichnet. Wie jedes herkömmliche Siegel verhindert auch dieses Siegel nicht den Zugriff auf Ihre Karte, ermöglicht aber eine verlässliche Kontrolle der Unversehrtheit der Karte. Eine nicht mehr gesetzte NullPIN ist ein sicheres Indiz, dass die Karte (ggf. von einem Dritten) bereits benutzt wurde. Ein solches Vergehen kann also vom Karteninhaber verlässlich erkannt und auch beanstandet werden.
Sie können die PIN1 Ihrer Signaturkarte mit der PIN2 zurücksetzen. Für die Nutzung dieser Funktion empfehlen wir Ihnen unser kostenloses Programm SignLive! Toolbox, welches Sie in unserem Downloadbereich herunterladen können. Nach dem Start des Programms wählen Sie die Funktion PIN Management, es öffnet sich folgendes Fenster.
Ihre persönliche Identifikationsnummer (PIN) schützt die Karte vor missbräuchlicher Nutzung.
Die TelePIN identifiziert Sie gegenüber dem Trust Center. Sie benötigen es zur Freischaltung Ihres Zertifikats sowie zur Sperrung Ihres Zertifikates auf telefonischem Wege. In bestimmten Fällen wird die TelePIN zusätzlich für die Entschlüsselung verschlüsselt übermittelter Zertifikate benötigt.
Dazu benötigen Sie eine entsprechende Anwendungssoftware, die die NullPIN erkennt und den Karteninhaber zur Eingabe bzw. Wahl einer eigenen PIN auffordert.
Wenn Sie dazu kein eigenes Programm haben empfehlen wir Ihnen unser kostenloses Programm SignLive! Toolbox, welche Sie im Downloadbereich finden.
Wahrscheinlich hat der Leser die Karte über die kontaktlose Schnittstelle angesprochen. Bei Verwendung eines Reiner SCT cyberJack RFID Kartenlesers erkennen Sie dies an der Farbe der Duo-LED. Leuchtet diese blau, so hat der Kartenleser die Karte mittels der RFID Schnittstelle angesprochen. Die Verwendung der SigG-PINs ist jedoch ausschließlich über die kontaktbehaftete Verbindung realisiert. Bei kontaktloser (RFID-)Verbindung stehen lediglich die Globalen PINs zur Verfügung.
Die Fehlermeldung "Die SigG PIN 1 (für qualifizierte Signatur) kann nicht initialisiert werden. Der Vorgang kann leider nicht fortgesetzt werden" hat die gleiche Ursache. Diese Fehlermeldung erscheint, wenn Sie den Menüpunkt "Karte in Betrieb nehmen" verwendet haben.
Falls Sie die RFID Funktion des Kartenlesers nicht benötigen (z.B. für den neuen Personalausweis), so empfehlen wir Ihnen diese Abzuschalten.
Die qualifizierten Signaturzertifikate Ihrer Signaturkarte sind nicht primär für die Nutzung mit Windows vorgesehen. Dies liegt insbesondere an den Anforderungen der EIDAS Verordnung. Diese schreibt beispielsweise bei der Zertifikatsprüfung einen Abgleich mit der Vertrauensliste der EU vor. Dieser Abgleich kann von Windows nicht durchgeführt werden.
Abhängig von den vorhandenen Einstellungen kann die Aussage von Windows zu Ihrem Zertifikat unterschiedlich ausfallen. Die Aussage wird vermutlich "Dieses Zertifikat kann nicht bis zu einer Zertifizierungsstelle verifiziert werden" oder "Es liegen keine ausreichenden Informationen vor um dieses Zertifikat zu verifizieren". Bitte beachten Sie auch die weiteren Artikel in unserer FAQ im Bereich "Qualified.ID-Zertifikate unter Windows". Bei der Nutzung der Zertifikate sind unter Umständen weitere Besonderheiten zu beachten.
Ihre Zertifikate werden von Windows in der Standardeinstellung nicht als gültige Zertifikate anerkannt weil Windows das verwendete Ausstellerzertifikat nicht kennt bzw. den verwendeten Signaturalgorithmus nicht verarbeiten kann.
Wenn Sie möchten, dann können Sie die Ausstellerzertifikate, das ist derzeit "TeleSec PKS eIDAS QES CA 1" und "TeleSec qualified Root CA 1" in Windows installieren. Die Zertifikate finden Sie in unserem Downloadbereich unter Technische Dokumentation in einer ZIP-Datei "CA-Zertifikate.zip". Wenn Sie eine aktuelle (regelmäßig aktualisierte) Windows Version ab Windows 7 verwenden werden die qualifizierten Zertifikate jetzt als gültig angezeigt. Wenn Windows die Zertifikate als gültig anerkennt, so können Sie diese trotzdem nicht nutzen ohne weitere Software zu installieren.
Informationen welche Möglichkeiten wir empfehlen die qualifizierte Signatur mit Ihrer Signaturkarte zu nutzen finden Sie in unserer FAQ "Welche Systemvoraussetzungen benötigt mein Computer?".
Wir empfehlen Ihnen die Verwendung der Adressbuch Funktion Ihres Email Programms um ein Zertifikat / eine Person im Verzeichnisdienst zu suchen. Entsprechende Funktionen werden zum Beispiel von Microsoft Outlook zur Verfügung gestellt. Nachfolgend erklären wir Ihnen die Nutzung von Outlook zur Suche im Qualified.ID (PKS) Verzeichnisdienst.
Öffnen Sie Konfiguration Ihres Email Kontos mittels der Systemsteuerung. Wählen Sie danach die Registerkarte Adressbücher aus. Fügen Sie ein neues Adressbuch mit einen Klick auf den Button "Neu" hinzu. Wählen Sie im nachfolgenden Dialog den Typ "Internetverzeichnisdienst (LDAP)". Geben Sie als Servername den Namen pks-ldap.telesec.de ein.
Öffnen Sie danach Outlook und das Adressbuch. Wählen Sie im Adressbuch Ihr neu erstelltes Adressbuch pks-ldap.telesec.de aus. Klicken Sie auf "Erweiterte Suche". Geben Sie hier im Feld Anzeigename Ihr Suchkriterium ein. Nachdem Outlook den gewünschten Eintrag gefunden hat wählen Sie bei diesem Eintrag im Kontextmenü die Funktion "Zu den Kontakten hinzufügen". Es wird Ihnen jetzt die Outlook - Visitenkarte des Eintrags angezeigt. Wählen Sie hier unter Anzeigen den Punkt Zertifikate.
Diese Fehlermeldung wird nicht von der Chipkarte erzeugt sondern vom Kartenverwaltungssystem von Windows. Dieses regelt den Zugriff auf die Chipkarte von mehreren Anwendungen.
Die Fehlermeldung SCARD_E_SHARING_VIOLATION bedeutet, dass in diesem Moment mehrere Anwendungen gleichzeitig auf Ihre Signaturkarte zugreifen möchten und sich dabei gegenseitig behindern. Bestimmte Aktionen, wie zum Beispiel die Änderung einer PIN erfordern einen exklusiven Zugriff auf die Chipkarte. Dieser exklusive Zugriff ist aktuell nicht möglich.
Um den Fehler zu lösen beenden Sie bitte alle Programme, die auf die Chipkarte zugreifen könnten. Achten Sie dabei auch auf Programme, die im Hintergrund laufen und zum Beispiel nur im Informationsbereich der Taskleiste (neben der Uhr) mit einem Icon sichtbar sind. Nachdem der konkurrierende Zugriff auf die Chipkarte gelöst wurde tritt dieser Fehler nicht mehr auf.
Die Einbindung der Karte in den Windows-Zertifikatsspeicher ermöglicht Standard-Software (z. B. Outlook oder Adobe Acrobat) die Nutzung Ihrer Zertifikate zur Signatur und Verschlüsselung.
Diese Anleitung setzt eine Signaturkarte der neuen Generation voraus. Sie erkennen eine solche Karte an dem großen N vor der Kartennummer ihrer Karte.
Diese Anleitung richtet sich ausschließlich an erfahrene Anwender und Administratoren mit sehr guten Kenntnissen von Windows.
Wenn Sie bereits eine Signatursoftware wie zum Beispiel OpenLimit CC Sign oder Intarsys SignLive! oder den SecSigner von SecCommerce installiert haben so wurde der Crypto Service Provider wahrscheinlich bereits installiert. In solchen Fällen raten wir von einer Installation des „Read-Only-Cardmoduls zur Signaturcard“ ab.
Bitte stecken Sie jetzt Ihre Signaturkarte in den Kartenleser. Sollte von Windows nun die Aufforderung zur Installation eines Treibers angezeigt werden so haben Sie noch keinen CSP installiert. In diesem Fall können Sie einen kompatiblen CSP von unserer Webseite herunterladen. Bitte laden Sie die Datei Read Only Cardmodul zur "Signature Card 2.0" - Mit ECC-Unterstützung 32Bit oder 64Bit (entsprechend Ihrer Betriebssystemarchitektur) aus dem Downloadbereich herunter. Installieren Sie den Treiber in dem Sie die Datei ausführen. Öffnen Sie den Gerätemanager von Windows über die Systemsteuerung → System → Gerätemanager. Dort sollte jetzt in der Baumansicht unter Smartcards ein Eintrag für Ihre Chipkarte angezeigt werden.
Bitte entfernen Sie jetzt Ihre Signaturkarte aus dem Kartenleser, warten Sie 10 Sekunden und stecken Sie sie danach wieder ein. Durch diesen Vorgang merkt der neu installierte Treiber die neu eingesteckte Chipkarte und liest sie aus. Die Aufforderung zur Installation eines Treibers sollte jetzt nicht mehr erscheinen. Bitte beachten Sie, dass der Zugriff auf Ihre Signaturkarte mehrere Sekunden dauern kann.
Starten Sie das Programm certmgr.msc in dem Sie das Startmenü öffnen und dort im Eingabefeld certmgr.msc eingeben und die Eingabetaste drücken. Erweitern Sie in dem Programm die Ansicht unter dem Punkt „Eigene Zertifikate“. Dann erscheint der Unterpunkt „Zertifikate“. Klicken Sie auf den Unterpunkt Zertifikate. Jetzt sollten im rechten Teil des Fensters die Zertifikate Ihrer Signaturkarte angezeigt werden.
Öffnen Sie Ihr qualifiziertes Zertifikat in dem Sie darauf einen Doppelklick ausführen. Dieses ist das Zertifikat mit der Bezeichnung „EIDAS“ im Namen des Ausstellers.
Im unteren Teil des Fensters sollte die Aussage stehen „Sie besitzen einen privaten Schlüssel zu diesem Zertifikat“. Ist dies nicht der Fall schließen Sie das Zertifikat, klicken es mit der rechten Maustaste an und wählen Sie löschen. Bitte löschen Sie keine Zertifikate aus dem Windows-Zertifikatsspeicher, die Sie nicht auf Ihrer Signaturkarte gespeichert haben. Den gleichen Vorgang machen Sie für Ihre weiteren Zertifikate. Diese weiteren Zertifikate sind nur sichtbar, wenn Sie bereits die Ergänzungszertifikate auf Ihrer Signaturkarte installiert haben. Danach schließen Sie das Programm, entfernen die Chipkarte aus dem Kartenleser, warten Sie 10 Sekunden und stecken Sie die Chipkarte erneut. Dadurch wird die Signaturkarte neu eingelesen.
Nachdem Sie im vorherigen Punkt sichergestellt haben, dass die Zuordnung des Zertifikats zu Ihrer Signaturkarte funktioniert, prüfen Sie ob Windows das Zertifikat als ein gültiges Zertifikat erkennt. Dazu öffnen Sie Ihr Zertifikate im Programm certmgr.msc. Möglicherweise wird dort jetzt angezeigt „Es liegen keine ausreichenden Informationen vor, um dieses Zertifikat zu verifizieren“. In diesem Fall müssen die Ausstellerzertifikate installiert werden. Installieren Sie das zu ihre Zertifikat gehörige Aussteller Zertifikat. In dem obigen Beispiel ist das das Zertifikat mit dem Namen „TeleSec PKS eIDAS QES CA 5“. Anschließend installieren Sie noch das zugehörige Root-Zertifikat „TeleSec qualified Root CA 1“
Sie finden diese Zertifikate in der Datei CA-Zertifikate.zip im Download Bereich unserer Webseite unter dem Punkt tech. Dokumentation.
Wenn Sie Ihr Zertifikat im Programm certmgr.msc unter „Eigene Zertifikate“ → „Zertifikate“ jetzt erneut öffnen und dort im Reiter „Zertifizierungspfad“ auf den Inhalt des Feldes „Zertifizierungsstatus“ achten, sollte dort jetzt stehen „Dieses Zertifikat ist gültig“.
Sollte nach der Installation Ihres qualifizierten Zertifikates im Windows-Zertifikatsspeicher nicht möglich sein ein Dokument mit Adobe zu signieren Prüfen Sie bitte in den Einstellungen die Nutzung der EU-Trusted-List.
Gehen Sie dazu in Bearbeiten / Einstellungen in die Kategorie „Vertrauensdienste“ und setzten das Häkchen bei dem Punkt „Automatisches Updates für Europan Union Trusted Lists“.
Damit Sie Ihre Signaturkarte mit Outlook nutzen können ist es erforderlich das Sie bei der Beauftragung die Emailadresse des Email-Kontos welches Sie nutzen möchten in Ihre Signaturkarte eingetragen und mittels der Prüfnummer bestätigt haben.
Die Vorgehensweise dieser Anleitung ist nicht mit Mozilla Thunderbird kompatibel.
Binden Sie zuerst Ihre Signaturkarte in Windows ein. Dies ist in der FAQ “Wie Importiere ich mein Zertifikat in den Windows-Zertifikatsspeicher?“ beschrieben.
Zur Einbindung des Zertifikats in Outlook öffnen Sie bitte das Vertrauensstellungscenter. Dieses finden Sie im Menü Extras. Wählen Sie im linken Teil des Fensters die Kategorie „E-Mail Sicherheit“. Klicken Sie anschließend im rechten Teil des Fensters, unter der Überschrift „Verschlüsselte E-Mail Nachrichten auf den Button „Einstellungen“. Klicken Sie in dem sich jetzt neu geöffneten Fenster „Sicherheitseinstellungen“ auf den Button „Auswählen“ neben der Anzeige „Signaturzertifikat“ und auf den Button „Auswählen“ neben der Anzeige „Verschlüsselungszertifikat“. Wählen Sie dann jeweils ein Zertifikat von Ihrer Signaturkarte aus. Es ist empfehlenswert den Haken bei „Signierten Nachrichten diese Zertifikate hinzufügen“. Schließen Sie dieses Fenster und das Vertrauensstellungscenter.
Die Nutzung der Signaturkarte mit Outlook zum Signieren und Verschlüsseln von Email sollte jetzt funktionieren.
Falls Sie für jemand anderes Verschlüsseln möchten, ist es empfehlenswert, dass Sie denjenigen bitten Ihnen eine signierte Email zukommen zu lassen. Mit den oben beschriebenen Einstellungen können Sie diese Person anschließend in Ihr Adressbuch übernehmen. Dabei wird auch das Zertifikat des Empfängers gespeichert. Anschließend können Sie für ihn verschlüsseln, in dem Sie den Eintrag aus Ihrem Adressbuch verwenden. Falls jemand anderes für Sie verschlüsseln möchte gehen Sie umgekehrt vor. Senden Sie demjenigen eine signierte Email und bitten Sie ihn das er Sie als Empfänger in sein Adressbuch aufnimmt. Anschließend kann er für Sie verschlüsseln.
MS Windows erwartet in CA-Zertifikaten eine Zertifikatserweiterung namens "BasicConstraints", die ein Zertifikat als CA-Zertifikat ausweist. Diese Zertifikatserweiterung ist in manchen alten TeleSec CA-Zertifikaten nicht enthalten. Diese Zertifikate wurden von der Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen ausgestellt und unterliegen nicht unserem Einfluss.
In Qualified.ID Zertifikaten wird ein Signaturalgorithmus verwendet, der von Windows ohne zusätzliche Software nicht unterstützt wird.
Bitte beachten Sie außerdem das zur Gültigkeitsprüfung eines qualifizierten Zertifikats eine Onlineprüfung zwingend erforderlich ist. Windows kann eine solche Prüfung nicht vornehmen.
Für den korrekten Umgang mit qualifizierten Zertifikaten benötigen Sie einen Crypto Service Provider (CSP) oder eine Signatursoftware, die die verwendeten Algorithmen und die erforderlichen Onlineprüfungen unterstützten. Alle für den Einsatz zur Erzeugung qualifizierter elektronischer Signaturen geeigneten Signaturanwendungskomponenten enthalten diese Funktionen.
Bitte achten Sie darauf immer die aktuellsten Versionen Ihrer Signatursoftware zu verwenden, da diese ständig an Stand der Technik angepasst werden müssen.
Wir empfehlen E-Mails nicht qualifiziert zu signieren. E-Mailprogramme haben nicht die notwendigen Funktionen um eine Signatur mittels der von der EU herausgegebenen Vertrauensliste zu prüfen.
Aus sicherheitstechnischer Sicht empfehlen wir, statt einer signierten E-Mail, eine signierte Datei, die Sie als Anhang zu einer E-Mail versenden können.
Zur Nutzung dieser Funktion müssen Sie Ihre Ergänzungszertifikate auf der Signaturkarte installiert haben. Danach gehen Sie weiter vor wie in der FAQ Wie importiere ich meine Signaturkarte in den Windows-Zertifikatsspeicher? beschrieben.
Danach können Sie die gewünschte Webseite öffnen. Falls es die Webseite unterstützt wird ihr Browser Ihnen jetzt das Zertifikat Ihrer Qualified.ID Signaturkarte zur Authentisierung anbieten.
Einige Webseitenbetreiber (z.B. das Unified Patent Court) fordern für die Authentisierung an Ihrer Plattform die Nutzung des qualifizierten Zertifikats. Das qualifizierte Zertifikat der Qualified.ID Signaturkarte besitzt jedoch nicht die notwendigen Zertifikatsinhalte damit ein Browser damit eine Authentisierung machen würde. Derzeit ist die Qualified.ID Signaturkarte für den geforderten Zweck nicht einsetzbar.
Informationen zur Energy.ID Test Schnittstelle:
Informationen zur Schnittstelle der Energy.ID (Wirkumgebung):
Grundsätzlich werden im Rahmen der Registrierung die Ansprechpartner der Endkunden registriert und sind somit der Energy.ID bekannt. Der Support-Anspruch gilt somit gegenüber nur dem jeweils hinterlegten Ansprechpartner des Endkunden. In Ausnahmefällen wird der Support auch gegenüber Dritten geleistet. Hierzu ist eine entsprechende Information seitens des registrierten Ansprechpartner per S/MIME notwendig.
Die Formulare sind im Service / Downloads / Produkte & Lösungen zu finden.
Die Energy.ID stellt in Ihrer Funktion einer Sub-CA folgende Endnutzer-Tripel Zertifikate aus:
Der GWH ist neben seinem eigenen Zertifikat noch für die SMGW-Gütesiegelzertifikate verantwortlich.
Der GWA ist neben seinem eigenen Zertifikat noch für die SMGW-Wirkzertifikate verantwortlich.
Die Zuordnung der einzelnen Zertifikatstypen sind der nachfolgenden Tabelle zu entnehmen:
Mandanten
SMGW Güte-siegel Zertifikate
SMGW Wirk-Zertifikate
AdministratorZertifikate
SMGW HerstellerZertifikate
EMTZertifkate
SMGW Hersteller
SMGWAdmin
EMT
Jedes in der SM-PKI verwendete Zertifikat besitzt eine Gültigkeitszeit und eine Verwendungszeit für den zugehörigen privaten Schlüssel, welche im Zertifikat angegeben werden.
Die folgende Tabelle gibt die Zertifikatslaufzeiten bei alle Zertifikaten - außer denen der SM-PKI Root - laut TR 3109-4 ( Tabelle 11) verbindlich vor:
Root-CRL-Signer Zertifikat
4 Jahre
Root-TLS-Signer Zertifikat
Sub-CA (Energy.ID) Zertifikat
5 Jahre
TLS Zertifikate der Root CA und der Sub-CA (Energy.ID)
2 Jahre
GWA Zertitifkate (Sign, ENC, TLS)
3 Jahre
Andere Endnutzerzertifikate (Sign, ENC, TLS)
Nein, die Zertifikate werden immer gemeinsam ausgestellt und gesperrt. Bei einem notwendigen Folgezertifikat sind auch immer drei neue Zertifikate zu beantragen.
Nein, nach der TR 3109-4 sind immer Folgezertifikate mit neuem Schlüsselmaterial zu erstellen. Eine Verlängerung würde eine Änderung der Laufzeit bei gleichem Schlüsselmaterial bedeuten.
Wenn neben der Energy.ID auch eine andere Sub-CA aus der Smart-Metering PKI beteiligt ist, ist zu beachten, dass im Request immer die komplette Zertifikatskette enthalten sein muss. Nur so kann die Energy.ID - vorausgesetzt die andere Sub-CA ist aus dem TC erreichbar - die Zertifikatskette prüfen. Beispiel: Ein GWA der Energy.ID möchte in einem SMGW das „fremde“ Gütesiegelzertifikat aus einer andere Sub-CA durch ein Wirkzertifikat aus der Energy.ID ersetzen.
Unter "Suspendierung" versteht man die temporäre Sperrung eines Zertifikates. Dieses kommt in der Energy.ID nur bei SMGW Zertifikaten vor und muss vom GWA bzw. vom GWH (nur Gütesiegelzertifikate) durchgeführt werden.
Die Suspendierung MUSS über die Web-Service-Schnittelle der Sub-CA beantragt werden. Im Ausnahmefall (z.B. Web-Service-Schnittstelle steht nicht zur Verfügung) kann dies auch über einen entsprechend abgesicherten, etablierten Kommunikationskanal (z.B. signierte E-Mail) durchgeführt werden. Eine Suspendierung eines SMGW MUSS immer als Paket (enthält Zertifikatstripel) erfolgen, siehe [TR-03109-4].
Eine Suspendierung des jeweiligen Zertifikats MUSS über die Sperrliste der CA veröffentlicht werden. Der Zertifikatsinhaber (GWA) MUSS über den abgeschlossenen Sperrprozess informiert werden.
Nicht systemrelevante Zertifikate können vom Inhaber selbst gesperrt werden. Das geht direkt über das Kunden-Frontend oder die API der Energy.ID. Um das im Kunden-Frontend zu machen, muss man sich erfolgreich anmelden. Dafür ist ein spezielles Kunden (TLS) Zertifikat nötig. Dieses Zertifikat bekommt man auf Anfrage vom Energy.ID Support. Bei EMT-Zertifikaten, die vom Zertifikatsservice ausgestellt wurden, geht die Sperrung nur über den Energy.ID Support. Alternativ ist dies auch über die API möglich, falls die Kundensoftware dies unterstützt.
NetKey / IDKey eignet sich z.B. für
Diese Liste ist beispielhaft und nicht vollständig.
Im ersten Schritt wird eine Identität definiert. Am Beispiel einer Person ist schnell zu erkennen, dass diese nach der Geburt im Familienkontext über Mutter und Vater identifiziert wird. Durch die Vergabe eines Namens und die Eintragung in ein Melderegister entsteht eine neue Identität. Bei technischen Komponenten vergibt zum Beispiel der Hersteller eines Produktes eine Seriennummer.
Im einfachsten Fall kann der Inhaber eines NetKey / IDKey sich selbst ein Zertifizikat ausstellen. Hierbei handelt es sich dann um ein sogenanntes „selfsigned Certificate“. Streng genommen behauptet der Inhaber also lediglich, eine bestimmte Identität und einen bestimmten Schlüssel zu besitzen.
Technisch gesehen können solche Zertifikate für alle Zwecke eingesetzt werden, bei denen das Zertifikat als berechtigt akzeptiert wird.
Die Identitätsprüfung erfolgt in solchen Fällen meist vorab z.B. per Telefon oder durch persönliche Begegnung, wobei man sich auf eine Zusammenarbeit auf dieser Basis einigt.
Die Identität einer Person wird bei Bedarf üblicherweise durch die Präsentation eines Ausweisdokumentes nachgewiesen. Dazu werden sichtbare Identitätsmerkmale wie Lichtbild, Augenfarbe oder besondere Merkmale wie Narben abgeglichen.
Im Falle des Verlustes eines solchen Ausweises muss die Person sich ggf. durch z.B. Vorlage eines Familienstammbuches beim Melderegister ausweisen, um einen neuen Ausweis zu bekommen.
Vor der Ausstellung des Zertifikates kann der Zertifizierungsdienst ggf. durch Abgleich gegen ein vorgelegtes Ausweisdokument die Identität des Auftraggebers prüfen. Die Qualität dieser Prüfung ist die Basis für die Qualität des Zertifikats.
Eine E-Mail-Adresse kann z. B. nur dann als Identitätsmerkmal genutzt werden, wenn gewährleistet ist, dass das zugehörige E-Mail-Konto unter der Kontrolle des Auftraggebers ist. Diese Prüfung kann mittels Zusendung und Beantwortung einer Bestätigungs-E-Mail erfolgen.
In diesem Fall muss sich der Inhaber des NetKey / IDKey dem Registrierungsprozess eines anerkannten Zertifizierungsdienstes unterziehen. Hierbei muss die eigene Identität nach den jeweiligen Anforderungen des Zertifizierungsdienstes z.B. auf Basis einer persönlichen Vorstellung mit Vorlage eines Ausweisdokumentes nachgewiesen werden.
Der Zertifizierungsdienst stellt ein Zertifikat erst nach positiver Prüfung der vorgelegten Identitätsnachweise aus.
Der Zertifizierungsdienst stellt eine sogenannte „dritte Instanz“ dar. Somit ist das ausgestellte Zertifikat nicht mehr bloß eine Behauptung, sondern eine nachprüfbare Identität. Zertifizierungsdienste stellen darüber hinaus üblicherweise Prüfmöglichkeiten in Form von standardisierten Verzeichnis- und Sperrservices bereit.
Die Personalisierung des NetKey / IDKey erfolgt durch die Zuordnung eines öffentlichen Schlüssels aus dem NetKey / IDKey zu Identitätsmerkmalen des NetKey-/IDKey-Inhabers innerhalb eines Zertifikats.
Diese Zuordnung geschieht in der Regel als Versiegelung mittels elektronischer Signatur dieser Verknüpfung. Durch diese Versiegelung entsteht aus einer Ansammlung von Identitätsmerkmalen ein Zertifikat. Der öffentliche Schlüssel wird dabei zu einem weiteren Identitätsmerkmal.
Die Verbindung zum NetKey / IDKey liegt in der Verknüpfung zwischen öffentlichem und geheimem Schlüssel.
Der geeignete Zertifizierungsdienst ergibt sich in der Regel aus dem Anwendungskontext. Weltweit bieten verschiedene Zertifikatsaussteller ihre Dienste über das Internet an.
In großen Firmen oder Organisationen existieren oft eigene Public Key Infrastrukturen (PKI) zur Ausstellung und zum Management von fortgeschrittenen Zertifikaten. Das heißt, die Registrierung der Teilnehmer erfolgt nach den Regeln des jeweiligen Anbieters.
Darüber hinaus sind in den letzten Jahren in verschiedenen Ländern Zertifizierungsdiensteanbieter (ZDA) entstanden, die sogenannte qualifizierte Zertifikate anbieten. Für die Ausstellung eines qualifizierten Zertifikats beschreibt das jeweilige Land bestimmte Anforderungen hinsichtlich der Qualität der Registrierung. Ebenso wird die Qualität der Sicheren Signatur-Erstellungseinheit (SSEE) vorgeschrieben.
Ob der TeleSec NetKey / IDKey als SSEE geeignet ist, muss im Einzelfall mit dem zuständigen ZDA abgestimmt werden.
Fertig initialisierte TeleSec NetKey / IDKey sind anonym und mit dem durch die Deutsche Telekom AG patentierten Null-PIN-Verfahren geschützt.
Vor der Zuordnung eines NetKey / IDKey aus einer Menge neuer Karten zu einer Person oder einem System kann die Unversehrtheit der Karte durch Überprüfung des Null-PIN-Status gewährleistet werden.
Eine Kartennutzung verbunden mit der Vergabe einer kundenindividuellen PIN durch die Person oder das System zerstört dieses Schutzsiegel und bindet die Karte an den PIN-Inhaber (Wissen).
Ab diesem Zeitpunkt ermöglicht NetKey die sogenannte Zwei-Faktor-Autorisierung durch Besitz und Wissen.
Vorteile:
Der Endanwender sucht sich selbst ein Passwort (PIN) aus, das für ihn nach seinem individuellen Denkmuster leicht zu merken ist. (Ein solches Passwort kann aus dem kompletten ASCII-Satz in einer empfohlenen Passwortlänge von bis zu 64 Zeichen bestehen. Der Einsatz von z.B. PIN-Tastaturen sicherer Kartenleser kann es erforderlich machen, dabei nur die Ziffern 0 bis 9 zu verwenden.)
Ein Schlüsselpaar wird üblicherweise innerhalb des Browsers in Software erzeugt, der öffentliche Teil wird in den Zertifikatsrequest eingebaut und dieser wird mit dem geheimen Teil signiert, um die Authentizität des öffentlichen Schlüssels nachzuweisen. Der Secret Key wird anschließend passwortgeschützt im Rechner abgelegt (meist innerhalb eines PKCS#12-Containers).
Der TeleSec NetKey / IDKey hingegen bringt Schlüsselpaare mit, die innerhalb des Trust Centers der Telekom in einem hochsicheren Schlüsselgenerator entstanden sind. Dieser Schlüsselgenerator kann diese Schlüssel nur in geeignete TCOS-Chips exportieren. Dieser Export erfolgt kryptografisch derart gesichert, dass ein Mitlesen der Schlüssel ausgeschlossen ist. Somit können keine Schlüsselkopien existieren.
Eine Middleware integriert den NetKey / IDKey so in die Betriebssystemplattform, dass beim Anfordern eines Schlüsselpaares durch eine Anwendung das öffentliche Schlüsselmaterial der TCOS Smartcard benutzt wird.
Nach Fertigstellung eines NetKey / IDKey können die geheimen Schlüssel nur noch innerhalb des TCOS-Chips für Kryptooperationen herangezogen werden. Die Nutzung der geheimen Schlüssel ist PIN-gesichert, d. h. nur berechtigte Benutzer können geheime Schlüssel anwenden.
Der Schlüsselgenerator im TeleSec Trust Center speichert keine Schlüssel; die Übertragung der Schlüssel an die Smartcard erfolgt über verschlüsselte Leitungen innerhalb des sicherheitszertifizierten Trustcenters der Telekom. Somit ist die Existenz von Doppeln völlig ausgeschlossen, der geheime Schlüssel liegt somit ausschließlich im TCOS-Chip
Für Testzwecke wird für den TCOS Cardmanager ein PlugIn zur Verfügung gestellt, mit dem selbstsignierte Test-Zertifikate generiert und auf die auf die Karte geschrieben werden können. Hierzu muss zusätzlich die OpenSource-Bibliothek OpenSSL installiert werden.
Das Plugin unterstützt nur Netkey 3.0 und IDKey TCOS 3.0 Chipkarten. Diese Zertifikate verwenden nicht die bei der Produktion auf den TCOS 3.0 Smartcards vorpersonalisierten Schlüsselpaare. Für diese Zertifikate existierert keine vertrauenwürdige Root oder nicht die Möglichkeit zur Zertifikatsprüfung (LDAP/OCSP).
Aus diesem Grund können in einigen Anwendungen diese selbstgenerierten Zertifikate nur eingeschränkt genutzt werden. Wir empfehlen immer hochwertige Zertifikate von einer entsprechenden CA mit einer vertrauenwürdigen Root und Verzeichnisdiensten zur Überprüfung der Vertrauenswürdigkeit und Gültigkeit der Zertifikate zu verwenden.
Unter Microsoft Windows existiert ein sogenannter BaseCSP zur Einbindung von Hardware-Token. Die Schnittstelle zur Einbindung eines Card Moduls ist beschrieben. Zum NetKey / IDKey steht ein solches Card Modul bereit, welches ab Windows 7 über Windowsupdate.com zur Verfügung stehen wird. Dies bedeutet, dass sobald ein NetKey / IDKey erkannt wird, im Bedarfsfall das TCOS Card Modul automatisch geladen wird.
Nach Installation des Card Moduls wird NetKey / IDKey wie ein PKCS#12 Container behandelt. Der Benutzer kann zur Anforderung eines Zertifikates den Public Key aus NetKey / IDKey präsentieren. Die Krypto-Middleware von Windows handelt alles Weitere mit dem TCOS-Chip aus. Das sonst übliche Passwort zur Nutzung des geheimen Schlüssels aus einem PKCS#12-Container wird durch die Abfrage der NetKey-/IDKey-PIN ersetzt.
Für andere Betriebsysteme wie z. B. Linux steht eine PKCS#11-Bibliothek zur Verfügung, die im Rahmen eines Software-Setup installiert werden kann.
Für embedded Systeme können NetKey über speziell entwickelte Treiber integriert werden. Das Chipkartenbetriebssystem ist vollständig dokumentiert und stellt ein zu ISO 7816-4 konformes Interface bereit.
TCOS Card Module für den MS BaseCSP
Mit dem Card Module steht die Funktionalität der TCOS Smartcard allen Anwendungen über die MS CryptoAPI zur Verfügung. Das heißt, E-Mail Sicherheit wie Signatur und Ver-/Entschlüsselung in Outlook oder die Signatur ab Microsoft Word 2003 sind damit Basisbestandteile. Wenn durch den Webseitenbetreiber vorgesehen, kann Smartcard-Login und damit mehr Sicherheit für Anwender und Betreiber genutzt werden.
Windows-Logon lässt sich in verschiedenen Arten realisieren, je nachdem ob ihr System in einer Windows-Domäne eingebunden ist oder nicht.
PKCS#11
Das PKCS#11 SDK bietet die Möglichkeit, einfach höhere Datensicherheit zu integrieren. So z.B. in Lotus Notes oder Mozilla für E-Mail-Signatur und Ver-/Entschlüsselung für mehr Sicherheit und Vertrauen beim allgemeinen E-Mail Austausch.
Weitere Anwendungen sind der evidian SSO-Client, cryptovision, (utimaco und pgp sind in Planung).
Windows:
TCOS Card Module zur Netkey-/IDKey-Applikation mit dem MS BaseCSP für Windows 2000 und XP (mit MSDN Software Update 909520 für MS BaseCSP: http://support.microsoft.com/kb/909520/de).
Unter Windows XP ist der BaseCSP bereits Bestandteil des SP 1 und unterstützt auch die sichere PIN-Eingabe über ein PIN-Pad am Kartenleser.
PKCS#11 SDK zur Integration der SigG-Applikation (für qualifizierte Signaturen), Netkey-Applikation (für fortgeschrittene Signaturen, Entschlüsselung und Authentifikation) und ein ELSTER Modul*) für die ELSTER-Steuersoftware.
*) nur wenn der Zertifikatsaussteller ELSTER zugelassen ist
Linux:
Für einen einfachen Zugriff auf die Kartenfunktionalität wird für LINUX (SO-File) und OpenBSD das PKCS#11 SDK zur Verfügung gestellt.
MacOS:
Für einen einfachen Zugriff auf die Kartenfunktionalität wird für MacOS ab 10.x das PKCS#11 SDK zur Verfügung gestellt.
Gängige moderne Computerbetriebssysteme stellen Schnittstellen und Middleware für die Anschaltung und Ansteuerung von Chipkartenlesern zur Verfügung. Für die Benutzung des NetKey / IDKey benötigen Sie einen geeigneten Chipkartenleser, der über diese Middleware die Verbindung zwischen den Kontakten der NetKey-/IDKey-Smartcard und dem Betriebssystem Ihres Rechners herstellt.
Das Plugin unterstützt nur Netkey 3.0 und IDKey TCOS 3.0 Smartcards. Diese Zertifikate verwenden nicht die bei der Produktion auf den TCOS 3.0 Smartcards vorpersonalisierten Schlüsselpaare. Für diese Zertifikate existierert keine vertrauenwürdige Root oder nicht die Möglichkeit zur Zertifikatsprüfung (LDAP/OCSP). Aus diesem Grund können in einigen Anwendungen diese selbstgenerierten Zertifikate nur eingeschränkt genutzt werden. Wir empfehlen immer hochwertige Zertifikate von einer entsprechenden CA mit einer vertrauenwürdigen Root und Verzeichnisdiensten zur Überpfüfung der Vertrauenswürdigkeit und Gültigkeit der Zertifikate zu verwenden.
Dies ist die Aufgabe von Identitätsmanagement-Systemen. Hier wird die Sammlung der Attribute verwaltet und bestimmten Identitäten zugeordnet. In der Regel kann die Zuordnung von Identitätsmerkmalen in Abwesenheit der Person oder des Systems erfolgen.
Systeme und Anwendungen, die eine Nutzung aufgrund der Präsentation von Attributen anbieten, erhalten diese direkt vom Identitätsmanagement-Service. Die Berechtigung zur Nutzung eines Attributs weist der berechtigte Inhaber mit seinem NetKey / IDKey nach.
Im Leben und/oder im Beruf sind Personen in der Regel mehreren Rollen mit unterschiedlichen Aufgaben und Berechtigungen zugeordnet. Zur Wahrnehmung der Aufgaben und Berechtigungen ist jeweils ein Nachweis der rechtmäßigen Zuordnung erforderlich. Hierzu erhält die Person z.B. zu jeder Rolle ein separates Zertifikat oder es existiert ein Rollen- und Rechteverwaltungssystem, welches die Berechtigungen auf Basis eines übergeordneten Zertifikats verwaltet. Somit muss die Person entweder nachweisen, dass sie zum jeweiligen Zertifikat den richtigen Secret Key besitzt oder am Rollen- und Rechteverwaltungssystem nachweisen, dass sie die richtige Person zur jeweiligen Rolle ist. Hierbei wird dann wiederum verlangt, den richtigen geheimen Schlüssel zum übergeordneten Zertifikat verwenden zu können.
Da der NetKey / IDKey lediglich nachweist, dass der Inhaber eine Rolle mit dem zugehörigen Zertifikat benutzen darf, muss auf allen Rechnersystemen, an denen die Person ihre Rolle wahrnehmen soll, das Zertifikat zur Rolle installiert oder im Zugriff sein. Die Smartcard wird nur jeweils zur Autorisierung von Aktionen im Zusammenspiel mit dem Zertifikat benötigt. Aufgrund der Zwei-Faktor-Sicherheit des NetKey muss dieser für den mobilen Einsatz mitgeführt werden und bleibt somit unter der Kontrolle des Inhabers.
Die Anzahl möglicher Rollen wird durch TeleSec NetKey / IDKey nicht beschränkt. Überall dort, wo Identitätsdaten mit dem öffentlichen Schlüssel des NetKey / IDKey in Verbindung gebracht werden, lässt sich diese Verbindung mittels des NetKey rechtmäßig nutzen.
Zertifikate sind Bestandteil sogenannter Public Key Infrastrukturen und Services. Ein elementarer Bestandteil einer PKI ist der Directory Service. Eine Hauptaufgabe von Directory Services ist die Verbreitung und Verteilung von Zertifikaten.
Systeme und Anwendungen können über standardisierte Protokolle Zertifikate am Directory Service abfragen.
Darüber hinaus können Zertifikate durch die Inhaber selbst verteilt werden.
Die Validierungsdienste einer PKI ermöglichen jederzeit eine Gültigkeitsprüfung von Zertifikaten mittels standardisierter Protokolle.
Die tatsächliche Identität eines NetKey-/IDKey-Inhabers kann durch die Wahl der Attribute während der Registrierung für die Ausstellung eines Zertifikates erreicht werden.
Nach der Vorlage der Identifizierungsdaten gegenüber dem Zertifizierungsdienst wird ein pseudonymes Attribut als Zertifikatsinhaber eingetragen.
Im Rahmen eines Streitfalles kann die tatsächliche Identität hinter dem Pseudonym reproduziert werden.
Die Voraussetzungen für eine Reproduktion ergeben sich aus den Grundsätzen des Zertifizierungsdienstes und ggf. aus gesetzlichen Anforderungen.
Es entsteht eine pseudonyme Rolle.
Bei Public Key Systemen werden die Identitätsmerkmale üblicherweise in Form von Zertifikaten mit dem öffentlichen Schlüssel zusammen versiegelt. Das Gegenstück, der geheime kryptografische Schlüssel, befindet sich in sicherer Verwahrung durch die Karte.
Das Betriebssystem der Smartcard verhindert einerseits, dass der Schlüssel aus der Karte gelesen und damit kopiert werden kann. Die Hauptaufgabe der Karte besteht andererseits in der Abwicklung des kryptografischen Rechenprozesses unter Anwendung des geheimen Schlüssels. Um diese Leistungen auf eine Person oder ein System zu beschränken, erwartet die Karte vor der Nutzung die Präsentation eines gültigen individuellen Passwortes (PIN) durch die Person oder Komponente. Das Betriebssystem der Smartcard legt mit der Initialisierung und Codierung der Karte fest, welche Aktionen der Karte PIN-geschützt sein sollen. So ist es z.B. möglich, Bereiche so zu kodieren, dass sie nur nach PIN-Prüfung gelesen werden können.
Damit entstehen „abgestufte Geheimnisse“, die entsprechend den Anforderungen der geschützten Systeme preisgegeben oder angewendet werden können. Einmal ist es das Rechnerpasswort, welches nach PIN-Prüfung durch eine Chipkarte übergeben wird. In einem anderen Fall wird ein digitales Zertifikat erwartet, welches den Inhaber als Bürger eines Staates oder als Mitarbeiter einer Firma oder Institution ausweist. Im ersten Fall liefert die Karte das Passwort nach PIN-Prüfung. Im zweiten Fall erwartet das geschützte System den Nachweis, dass der Karteninhaber das präsentierte Zertifikat benutzen darf. Hierzu wird der Karte ein zufälliger Wert zur Verschlüsselung mit dem internen geheimen kryptografischen Schlüssel übergeben. Kann das Ergebnis nach der Entschlüsselung mit dem öffentlichen Schlüssel aus dem Zertifikat positiv verglichen werden, passt die Karte zum Zertifikat.
Da vor der Aktion die PIN abgefragt wurde, kann und muss davon ausgegangen werden, dass der Karteninhaber die gewünschte Person oder das vorgegebene System ist.
Der TeleSec NetKey / IDKey beinhaltet verschiedene Applikationen für symmetrische Authentifikationen. Insbesondere die Applikation OTP soll hier näher erläutert werden. Es handelt sich um eine Anwendung zur Erzeugung von dynamischen Einmallpasswörtern.
Im Rahmen der Trust Center Dienstleistungen bietet die Telekom den Service OneTimePass an. Dieser kann vom NetKey / IDKey erzeugte Einmalpasswörter auf Korrektheit prüfen. Die Anbindung von Kundensystemen an OneTimePass erfolgt über die Standardprotokolle RADIUS und SOAP.
Die vollständigen Informationen finden Sie unter: OneTimePass
Zwei weitere Applikationen, ZTRT und GLAZ beinhalten ebenso symmetrischen Schlüssel zu denen das Trust Center den Schlüssel ebenfalls kennt. Diese werden nur zur Vollständigkeit hier aufgeführt, sind jedoch meist für Einzelanwender uninteressant.
Der Einsatz moderner Informations- und Kommunikationstechnologien ermöglicht eine sehr weit gehende Prozessoptimierung in weiten Teilen des gesellschaftlichen und geschäftlichen Zusammenlebens.
Viele Bereiche des täglichen Lebens erfordern, dass sich der Mensch zu entfernten Orten bewegt, um mit anderen Menschen oder Institutionen Transaktionen abzuwickeln oder Verträge zu schließen.
Der Einsatz der vorgenannten Informations- und Kommunikationstechnologien ermöglicht theoretisch die Fernabwicklung solcher Transaktionen. Auf den zweiten Blick scheitert diese Möglichkeit jedoch schnell an der Notwendigkeit, die Beteiligten sicher zu identifizieren.
Eine Vor-Ort-Prüfung der Identität mittels z. B. eines Abgleichens gegenüber einem Personalausweis ist dabei aufgrund der räumlichen Trennung meist nicht möglich. Diese Feststellung macht den Bedarf an digitalen Identitäten deutlich. Bedingt durch die nicht vorhandene persönliche Präsenz müssen technische Alternativen geschaffen werden, die das Zusammenwirken auf die Ferne gegebenenfalls auch global verbindlich und nachprüfbar machen.
In den letzten Jahren haben sich weltweit einheitliche Verfahren etabliert, die digitale Identitäten zum Beispiel in Form von Zertifikaten erzeugen und verwalten. Ein Zertifikat ist eine elektronische Sammlung von Identitätsmerkmalen wie Name, Anschrift, Geburtsdaten.
International existieren verschiedene Institutionen, die die Glaubwürdigkeit solcher Zertifikate besiegeln. Unter dem Oberbegriff Trust Center bestätigen diese Stellen, dass die Identitätsmerkmale auf den Nutzer zutreffen. Hierzu wird entweder durch die Trust Center selbst oder durch von ihnen anerkannte Registrierungsstellen ein Abgleich gegen ein physikalisches Ausweisdokument vorgenommen.
Das zu Grunde liegende Prinzip ist meist ein so genanntes Public Key Verfahren. Hierbei werden für alle Beteiligten Schlüsselpaare erzeugt von denen ein Teil zum öffentlichen Schlüssel erklärt wird. Der zweite, geheime Teil sollte idealerweise so sicher aufbewahrt werden dass er nicht kopiert und somit die Anwendung des Schlüssels kontrolliert werden kann. Der erste Teil des Schlüssel ermöglicht wiederum die Prüfung, ob der geheime Schlüssel, wie behauptet, auf bestimmte Informationen angewendet wurde. Der öffentliche Schlüssel kann im einfachsten Fall zusammen mit dem Namen oder als Alias des Inhabers als digitale Identität verteilt werden.
Mit den TCOS Smartcards erhalten Sie besonders hochwertige digitalen Schlüssel, die es Ihnen ermöglichen, sich gegen viele Ärgernisse des Internet zu schützen und gleichzeitig Ihre Präsenz in der „virtuellen Welt“ aufzuwerten. Und diese Möglichkeiten liegen, im wörtlichen Sinne, alleine in Ihrer Hand! Sie erhalten eine Chipkarte, wie Sie sie aus vielen Anwendungen wie der Krankenversichertenkarte oder der Geldkarte kennen. Bei TCOS Smartcards handelt es sich um speziell für Sicherheitsanwendungen entwickelte Chipkarten. Im Chip dieser Karten werden im Herstellungsprozess nach modernsten Erkenntnissen erzeugte geheime Schlüssel abgelegt. Von diesen Schlüsseln existieren keine Kopien und es ist nach dem Stand der Technik unmöglich, die Schlüssel aus der Karte auszulesen.
Zur Anwendung kommen diese Schlüssel nur, wenn der Karte gegenüber das gültige Passwort, im üblichen Sprachgebrauch die PIN, präsentiert wird. Die Anwendung geheimer Schlüssel ermöglicht die eindeutige Zuordnung von Aktionen zu einer Person oder einem System, für welche die Chipkarte registriert wurde.
TCOS Smartcards ermöglichen darüber hinaus einen vertraulichen Informationsaustausch oder verschlüsselte Datenablage. Alle Daten, die unter Zuhilfenahme öffentlicher Schlüssel aus einer TCOS Smartcard verschlüsselt wurden, lassen sich nur mit dem zugehörigen geheimen Schlüssel, also einer TCOS Smartcard wieder entschlüsseln.
Die Zuordnung einer Aktion zu einer bestimmten Person oder einem bestimmten System (Identität) erfolgt meist in zwei Schritten. Zunächst behauptet der Verursacher einer Aktion, eine bestimmte Identität zu besitzen und die Aktion ausführen zu dürfen (Identifizierung). Im zweiten Schritt wird überprüft, ob die Aktion tatsächlich dieser Identität zugeordnet werden kann (Authentifizierung).
Die oben genannten Funktionen basieren auf der Nutzung bestimmter digitaler Identitätsmerkmale. An verschiedenen Systemen werden gegebenenfalls unterschiedliche Identitätsmerkmale verlangt. Diese unterschiedlichen Identitätsmerkmale (Attribute) präsentieren die verschieden Rollen, in denen der Inhaber unterwegs ist. So ist ein Mensch in der Regel ein Bürger mit Namen, Vornamen und Geburtsdatum. In einer anderen Rolle Mitarbeiter eines Unternehmens oder Prokurist desselben, in der Freizeit engagiert als Vorsitzender eines Vereins oder ehrenamtlich in einer anderen gesellschaftlichen Rolle. Je nach Rolle kommen Attribute hinzu, die allein oder in Kombination mit dem Namen Verwendung finden können. Im englischen Sprachgebrauch werden solche Attribute auch als Claims bezeichnet.
Eine geeignete Form für die Zusammenfassung solcher Identitätsmerkmale stellt z.B. ein X.509 Zertifikat dar. Hier werden diese Identitätsmerkmale zusammen mit dem öffentlichen Teil eines kryptografischen Schlüssels derart versiegelt, dass wiederum durch Anwendung des öffentlichen Teils des Siegelschlüssels das Siegel geprüft werden kann. Der öffentliche Teil des Benutzer-Schlüssels wird dadurch zu einem weiteren, einem digitalen Identitätsmerkmal des Zertifikatsinhabers. Technisch gibt es verschiedene Möglichkeiten, digitale Identitätsmerkmale geeignet zusammenzufassen. So kann z.B. ein authentischer Server ebenfalls eine Zusammenfassung von Identitätsmerkmalen präsentieren. Zur Vereinfachung der Betrachtung nutzen wir an der Stelle nur die Variante der X.509 Zertifikate.
Geht es nun um die Identifizierung einer Person oder einer technischen Komponente, weisen sich diese mittels eines Zertifikats aus. Die Prüfinstanz kann hierbei jedoch bis jetzt nur feststellen, ob es sich um ein gültiges Zertifikat handelt. Damit ist nur nachgewiesen, dass die Person oder Komponente existiert. Das heißt, eine Zertifizierungsinstanz hat das Vorhandensein der Person oder Komponente und damit die Identitätsmerkmale überprüft und das Zertifikat gültig erzeugt.
Eine TCOS Smartcard mit ihren hochwertigen Schlüsseln gibt dem Inhaber die Möglichkeit sich auszuweisen. Die Karte weist nach, dass präsentierte Identitätsmerkmale, die die jeweilige Rolle widerspiegeln, benutzt werden dürfen. Der Beweis entsteht durch die technische Verknüpfung von Identitätsmerkmalen und dem Nachweis eines Geheimnisses. Hier bieten TCOS Smartcards verschiedene Applikationen, die je nach Einsatzgebiet Verwendung finden können.
TCOS Smartcards beinhalten je nach Produkt verschiedene Applikationen für symmetrische Authentifikationen. Insbesondere die Applikation OTP soll hier näher erläutert werden.
Es handelt sich um eine Anwendung zur Erzeugung von dynamischen Einmalpasswörtern. Im Rahmen der Trust Center Dienstleistungen bietet die Telekom Security den Service OneTimePass an. Dieser kann von TCOS Smartcards erzeugte Einmalpasswörter auf Korrektheit prüfen. Die Anbindung von Kundensystemen an OneTimePass erfolgt über die Standardprotokolle RADIUS und SOAP.
Zwei weitere Applikationen, ZTRT und GLAZ, beinhalten ebenso symmetrischen Schlüssel, zu denen das Trust Center den Schlüssel ebenfalls kennt. Diese werden nur zu Vollständigkeit hier aufgeführt, sind jedoch meist für Einzelanwender uninteressant.
Bei Public Key Systemen werden die Identitätsmerkmale üblicherweise in Form von Zertifikaten mit dem öffentlichen Schlüssel zusammen versiegelt. Das Gegenstück, der geheime kryptografische Schlüssel, befindet sich in sicherer Verwahrung durch die Karte. Das Betriebssystem der Chipkarte verhindert einerseits, dass der Schlüssel aus der Karte gelesen und damit kopiert werden kann. Die Hauptaufgabe der Karte besteht andererseits in der Abwicklung des kryptografischen Rechenprozesses unter Anwendung des geheimen Schlüssels.
Um diese Leistungen auf eine Person oder ein System zu beschränken, erwartet die Karte vor der Nutzung die Präsentation eines gültigen individuellen Passwortes (PIN) durch die Person oder Komponente.
Das Betriebssystem der Chipkarte legt mit der Initialisierung und Codierung der Karte fest, welche Aktionen der Karte PIN-geschützt sein sollen. So ist es z.B. möglich, Bereiche so zu kodieren, dass sie nur nach PIN-Prüfung gelesen werden können. Damit entstehen „abgestufte Geheimnisse“, die entsprechend den Anforderungen der geschützten Systeme preisgegeben oder angewendet werden können.
Einmal ist es das Rechnerpasswort, welches nach PIN-Prüfung durch eine Chipkarte übergeben wird. In einem anderen Fall wird ein digitales Zertifikat erwartet, welches den Inhaber als Bürger eines Staates oder als Mitarbeiter einer Firma oder Institution ausweist.
Im ersten Fall liefert die Karte das Passwort nach PIN-Prüfung. Im zweiten Fall erwartet das geschützte System den Nachweis, dass der Karteninhaber das präsentierte Zertifikat benutzen darf. Hierzu wird der Karte ein zufälliger Wert zur Verschlüsselung mit dem internen geheimen kryptografischen Schlüssel übergeben. Kann das Ergebnis nach Entschlüsselung mit dem öffentlichen Schlüssel aus dem Zertifikat positiv verglichen werden, passt die Karte zum Zertifikat.
Wie bereits beschrieben, liegen den TCOS Smartcards Kenntnisse modernster Verschlüsselungstechnik (Kryptologie) zugrunde. Verschlüsselung wird immer dann benötigt, wenn es darum geht, Informationen vor unberechtigtem Lesen oder Verarbeiten zu schützen.
Dazu wird zwischen einem Autor oder Absender einer Nachricht (A) und dem Verarbeiter oder Empfänger (B) ein Schlüssel ausgetauscht. Damit ist es A möglich, die Information so zu verschlüsseln, dass nur B sie wieder lesen oder verarbeiten kann.
Möchte man nun in einer größeren Gruppe von Teilnehmern Daten so austauschen, dass jeder mit jedem so verschlüsselt kommuniziert, dass kein Dritter mitlesen kann, wird das notwendige Schlüsselmanagement schnell sehr aufwendig. So genannte Public Key Kryptologie vereinfacht das Schlüsselmanagement sehr stark. Jeder Teilnehmer benötigt genau ein Schlüsselpaar bestehend aus einem öffentlichen (public) Schlüssel und einem geheimen (secret) Schlüssel.
Öffentliche Schlüssel können über öffentliche Verzeichnisse verteilt werden. Somit ist es möglich, jedem Teilnehmer aus dem Verzeichnis Informationen vertraulich zukommen zu lassen. Dazu sind diese Informationen lediglich mithilfe des öffentlichen Schlüssels zu verschlüsseln. Nur der Inhaber des zugehörigen geheimen Schlüssels kann die Klardaten wieder reproduzieren.
Bei verschlüsselter Datenablage kann z.B. der Autor selbst seine Daten mit seinem eigenen öffentlichen Schlüssel verschlüsselt ablegen. Damit sind diese Daten vor dem Zugriff durch Dritte geschützt.
Die TCOS Smartcards der Telekom Security bestehen aus zwei entscheidenden Komponenten, deren Qualität die Alleinstellung der TCOS Smartcards ausmachen: die Qualität des Betriebssystems und die Qualität der internen Schlüssel.
TCOS Smartcards basieren auf dem TeleSec Chipcard Operating System (TCOS), welches seit vielen Jahren unter ständiger Begleitung durch neutrale Sicherheitsevaluatoren entwickelt und gepflegt wird.
So bildet TCOS zum Beispiel die Basis für die qualifizierten Signaturkarten der Deutschen Telekom AG oder auch für den Chip im deutschen Reisepass oder dem neuen deutschen Personalausweis.
Dies sind nur zwei Beispiele in denen TCOS die jeweils notwendige Qualitäts- und Vertrauensstufe erreicht hat.
Die Generierung der Schlüssel für TCOS Smartcards erfolgt innerhalb des Trust Centers der Telekom Security. Ausgesuchte TCOS Smartcards, wie die TCOS 3.0 Signature Card, enthalten eine gesonderte Applikation (SigG), die als sogenannte Sichere Signatur Erstellungseinheit (SSEE) nach dem deutschen Signaturgesetz evaluiert und bestätigt ist. Das Schlüsselmaterial dieser Applikation stammt von einem ebenfalls evaluierten und bestätigten Schlüsselgenerator. Diese Bestätigung stellt sicher, dass die Schlüssel eines Generators nur in geeignete TCOS Module geschrieben werden können. Diese SSEE kann somit im Zusammenspiel mit einem geeigneten Zertifizierungsdiensteanbieter für qualifizierte elektronische Signatur eingesetzt werden.
Andere Applikationen beinhalten ggf. mehrere ebenfalls im Trust Center erzeugte asymmetrische Schlüssel, die von einem technologisch gleichen Schlüsselgenerator erzeugt wurden. Diese Schlüssel erfüllen die Bedingungen für sogenannte fortgeschrittene Zertifikate.
Gängige moderne Computerbetriebssysteme stellen Schnittstellen und Middleware für die Anschaltung und Ansteuerung von Chipkartenlesern zur Verfügung. Für die Benutzung von TCOS Smartcards benötigen Sie einen geeigneten Chipkartenleser, der über solche Middleware die Verbindung zwischen den Kontakten der Chipkarte oder der Funkantenne und dem Betriebssystem Ihres Rechners herstellt.
Für Testzwecke wird für den TCOS CardManager ein Plug-In zur Verfügung gestellt, mit dem selbstsignierte Test-Zertifikate generiert und geeignete Karten geschrieben werden können. Hierzu muss zusätzlich die OpenSource-Bibliothek OpenSSL installiert werden. Das Plug-In unterstützt nur TeleSec Netkey 3.0 und TeleSec IDKey Smartcards. Diese Zertifikate verwenden nicht die bei der Produktion auf den TCOS Smartcards vorinstallierten Schlüsselpaare. Für diese Zertifikate existiert keine vertrauenwürdige Root oder nicht die Möglichkeit zur standardisierten Zertifikatsprüfung (LDAP/OCSP). Aus diesem Grund können in einigen Anwendungen diese selbstgenerierten Zertifikate nur eingeschränkt genutzt werden. Wir empfehlen immer hochwertige Zertifikate von einer entsprechenden CA mit einer vertrauenswürdigen Root und Verzeichnisdiensten zur Überprüfung der Vertrauenswürdigkeit und Gültigkeit der Zertifikate zu verwenden.
Aktualisieren Sie Ihren Browser, um diese Website korrekt anzuzeigen.
×
