Ein Zertifikat ist nichts anderes, als ein elektronischer Personalausweis in digitaler Form. Mit Hilfe von einem Zertifikat kannst Du sicherstellen, dass Du zum Beispiel wirklich eine EMail von Deinem Freund Bernd bekommen hast und diese auf dem Weg zu Dir auch nicht verändert wurde. Ferner sollen Zertifikate in Zukunft rechtsverbindliche Geschäfte im Internet ermöglichen.

Wie Funktioniert das denn mit den Zertifikaten? Wo krieg ich eins her?

Um Dich eindeutig im Internet anderen Gegenübern auszuweisen, musst Du erst mal ein digitales Zertifikat bei einer anerkannten Zertifizierungsstelle (lokal) beantragen (z. B. beim TC TrustCenter oder bei der Telesec). Die Sache ist für den privaten Gebrauch (zumindest bei oben genannten) kostenlos. Ggf. ist es notwendig, dass Du Dich mit Deinem Personalausweis und dem Antrag irgendwo (z. B. bei der Deutschen Post AG) identifizierst. Später wirst Du dann automatisch Dein eigenes Zertifikat mit Deinem privaten Schlüssel bekommen. Dieses Zertifikat kannst Du dann zum Beispiel in Deinem Emailprogramm einsetzen. 

Aktuell bietet auch das TrustCenter von WEB.DE kostenlose Zertifikate für Emails ohne umständliche Authentifikation für Dich an. Die Authentifikation Deiner Person erfolgt einfach mit der gelben Post und ist für Dich völlig kostenlos (Stand: 24.02.2000). Außerdem geben die wirklich ein fabelhafte Anleitung zur Installation und Nutzung.

Zu Deinem Zertifikat gehört ein privater - (private) und ein öffentlicher- (public) Key. Der öffentliche Schlüssel steht jedem zur Verfügung und ist auch ein Bestandteil Deines Zertifikats. Den geheimen Schlüssel musst Du gut sichern und darfst ihn nicht weitergeben. Dein Freund Bernd kann nun zum Beispiel eine für Dich bestimmte EMail mit Deinem öffentlichen Schlüssel verschlüsseln und Dir zuschicken. Du kannst die Email dann mit Deinem geheimen Schlüssel wieder entschlüsseln. So ist sichergestellt, dass niemand einen Einblick in den Inhalt der EMail bekommt, weil diese nur mit dem geheimen Schlüssel zu entschlüsseln ist.

Ihr könnt euch auch von der Firma http:\\www.kryptokom.de ein PlugIn für Outlook kostenlos runterladen, mit dem Ihr euere EMails verschlüsseln und signieren könnt. Das PlugIn ist echt Klasse! Dein privater Schlüssel wird entweder auf der Diskette oder auf einer Chipkarte gespeichert.

Outlook 98/2000, Outlookexpress und Netscape Messenger verfügen bereits über eine Schnittstelle (S/MIME), um Emails zur signieren und zu verschlüsseln. Weitere Infos dazu findet Ihr auf unserer Seite EMailverschlüsselung!.

Wenn Ihr inzwischen Windows 2000 auf euerem Computer installiert habt, bzw. einen Freund habt, der Windows 2000 hat, könnt Ihr euch selber ein eignes Vollzertifikat (mit privaten Schlüssel) erstellen lassen. Dieses Zertifikat ist zwar nicht von einer CA signiert, aber für den privaten Gebrauch voll einsatzfähig. Windows 2000 legt automatisch für jeden User ein Zertifikat an.

Systemsteuerung

Verwaltung

Lokale Sicherheitseinstellung

Richtlinien öffentlicher Schlüssel

Agenten für Wiederherstellung von verschusselten Daten

Links den User selektieren

doppelklicken

Registrierkarte Details wählen

In Datei kopieren wählen

Den Anweisungen folgen (unbedingt mit Privaten Schlüssel exportieren)

Ist ein Zertifikat wie das andere und kann ich die in jedem Programm einsetzen?

Nein!!! - Es gibt unterschiedliche Zertifikate und nicht jedes Programm unterstützt jedes Zertifikatsformat. Wir (User) können nun nur hoffen, dass sich langsam ein Standard finden wird. Derzeit kristallisieren sich folgende Systeme zur Verschlüsselung und Signatur von Emails raus:
PGP (Pretty Good Privacy), S/MIME, PEM (Privacy Enhanced Mail), MailTrusT (von TeleTrusT Deutschland)

Nähere Erklärungen zu diesen Systemen geben wir weiter unten. Wichtig ist nur, dass diese Systeme alle ein unterschiedliches Zertifikat verwenden. Das X.509-Zertifikat, dass bei S/MIME verwendet wird, solltet Ihr euch auf jedem Fall schon mal merken. Dieses Zertifikatsformat ist mit am weitesten verbreitet.

Wo kann ich diese Zertifikate den sonst noch gebrauchen?

Im letzten Punkt haben wir den Einsatz von Zertifikaten im Bereich EMail gezeigt. Einige Zertifikate (auch das X.509-Zertifikat) werden sowohl im WorldWideWeb (z. B. SSL) als auch im ECash (z. B. SET) verwendet. Wichtig wird der Einsatz von Zertifikaten auch im Bereich ECommerce, um rechtsverbindliche Geschäfte im Internet zu realisieren!

Wie sieht den so ein Zertifikat jetzt aus?

Wie oben schon erwähnt, werden die PGP CA-Zertifikate und die X.509 CA-Zertifikate am häufigsten eingesetzt. Im folgenden Abschnitt werden wir mal kurz auf den Aufbau eines X.509v3-Zertifikates eingehen (v3 bedeutet Version 3). Die genaue Spezifikation zum X.509v3-Zertifikat wird weiter unten (Zertifikatsaufbau) gezeigt. Wenn Du Dir das mal angesehen hast, wirst Du die Sache vermutlich für tierisch kompliziert halten. Du kannst Dir folgendes zum Zertifikatsaufbau/Inhalt merken:

Ein Zertifikat enthält eigentlich ähnliche Daten wie Dein Personalausweis. In Deinem Zertifikat sind der Aussteller (Zertifizierungsstelle / CA) vergleichbar mit der Behörde, die Gültigkeitsdauer, Dein Name, EMail, Adresse und eine Zertifikatsnummer (vgl. Personalausweisnummer) gespeichert. Ferner beinhaltet Dein Zertifikat auch Deinen PublicKey, mit dem andere Daten für Dich verschlüsseln können. Das ganze ist in einem ASN.1-Kodierten Datenstream in einer Datei auf Deinem PC oder auf Deiner Chipkarte abgespeichert. Falls Du aber mehr darüber wissen willst, solltest Du Dich unbedingt mit der ASN.1-Sprache auseinandersetzen. Ein paar Grundlegende Infos findest Du auf unserer ASN.1-Page.

Kann ich mit fremden Zertifikaten auch signieren / entschlüsseln?

Nur, wenn Du im Besitzt eines Vollzertifikates (d. h. mit privaten Schlüssel) bist. Ein Vollzertifikat (Eigenes Zertifikat) besitzt einen privaten Schlüssel (Signieren / Entschlüsseln) und einen öffentlichen Schlüssel (Verifizieren / Verschlüsseln). Im Gegensatz dazu verfügt ein fremdes Zertifikat nur über einen öffentlichen Schlüssel (Verifizieren / Verschlüsseln).

Zum Beispiel bietet unser Programm (WinCrypt) die folgende fünf Möglichkeiten:

1. Digital Envelope für... 
2. Digital Envelope auspacken
3. Signieren
4. Verifizieren
5. Verschlüsseln
6. Entschlüsseln

Wenn Du nun eine Datei signierst und Deinem Freund schickst, der z.B. auch unser Programm (WinCrypt) installiert hat, dann wird Dein Zertifikat mit Deinem öffentlichen Schlüssel automatisch bei Deinem Freund in die Zertifikatsdatenbank eingetragen. Dein Freund kann dann mit Deinem Zertifikat nur Daten für Dich verschlüsseln und Deine Unterschrift prüfen (verifizieren), jedoch nicht damit signieren (Unterschreiben) oder für Dich bestimmte Daten entschlüsseln. 

Das ist leider etwas kompliziert, aber deshalb auch idiotensicher!!! Wir können euch nur empfehlen, in Zukunft euere EMails etc. nur noch in signierter und verschlüsselter Form abzuwickeln. 

Was ist den jetzt so geil an diesem Zertifikat?

Nun - Wie im letzten Punkt beschrieben, stehen Deine persönlichen und noch andere Daten in Deinem Zertifikat. Dieses Zertifikat wird von einer zugelassenen Zertifizierungsstelle ausgestellt, bei der Du Dich eindeutig identifizieren musstest. Die Zertifizierungsstelle hat nun über die Daten Deines Zertifikats "tbsCertificate" einen HASH-Wert gebildet, der je nach Verfahren bis zu 160 Bit lang sein kann. Dieser HASH-Wert ist wie ein Fingerabdruck und ist eindeutig dem Inhalt Deines Zertifikats zugeordnet. Wenn Du auch nur 1 Bit an Deinem Zertifikat änderst, ist der HASH-Wert anders! Damit Du aber nicht in Versuchung kommst irgendwas zu ändern, wird dieser HASH-Wert von der Zertifizierungsstelle verschlüsselt (Signiert) und Deinem Zertifikat hinzugefügt "signature". Wenn Du jetzt Deinen Namen oder andere Zertifikatsdaten änderst, stimmt die Signatur bei Deinem Zertifikat nicht mehr und es ist wertlos. Damit sind Deine Personalien eindeutig und fälschungssicher in digitaler Form abgelegt - Und das ist doch GEIL - oder?

Nun kannst Du Dich bei anderen Freunden oder Firmen mit Deinem Zertifikat eindeutig identifizieren (ähnlich Deiner Unterschrift). Du kannst z. B. übers Internet einen Vertrag abschließen, der mit hoher Wahrscheinlichkeit (SigG) rechtswirksam ist. "Hohe Wahrscheinlichkeit" bedeutet, dass es noch keinen Präzedenzfall gibt und niemand genau sagen kann, wie die Richter urteilen werden.

Ich kann mir doch selber ein Zertifikat machen und/oder die Angaben fälschen - oder?

Ja! - Aber Du stehst mit Deinem Zertifikat dann ganz alleine auf dieser großen Welt. Niemand wird Dein Zertifikat anerkennen. Der Trick ist, dass die Zertifizierungsstelle Dein Zertifikat mit einen sehr sehr geheimen RSA-Schlüssel verschlüsselt (Signiert) hat und Du nicht über diesen Schlüssel verfügst. Zu diesem geheimen RSA-Schlüssel gibt es noch einen öffentlichen Schlüssel, den die Zertifizierungsstelle veröffentlicht. Mit diesem öffentlichen Schlüssel kann jeder Dein Zertifikat auf Authentizität prüfen. 

Allerdings kannst Du Dir auch ein Zertifikat selber ausstellen, dass Du dann aber nur für den privaten Gebrauch nutzen kannst. Wenn Deine Freunde nun Dein Zertifikat manuell akzeptieren, dann ist es zumindest im privaten Rahmen im vollen Umfang einsetzbar.

Die Theorie war ja ganz nett, aber wie sieht's in der Praxis aus?

Dafür gibt's ab dem 11.08.1999 die PraxisPage!(findet Ihr auf der ITSicherheit)

Außerdem könnt Ihr euch auch unter Windows mal die Zertifikate ansehen. Dafür geht einfach unter Start - Einstellungen - Systemsteuerung in die Internetoptionen und schaut euch auf Inhalte die Installierten Zertifikate an. Evtl. verfügt Ihr ja schon über ein eigenes Zertifikat. Das findet Ihr dann unter "Eigene".

Fazit:

Falls euch noch Fragen und/oder Informationen bzgl. Zertifikaten interessieren, so schreibt uns bitte eine EMail und wir werden versuchen so schnell wie möglich diese Dinge hier noch mit einzubauen.

Darauf sind wir grob schon weiter oben eingegangen. Im Internet kommen verschiedene Protokollformen für die sichere Übertragung zum Einsatz. Du musst dabei zwischen folgenden Einsatzgebieten unterscheiden:

• WWW (WorldWideWeb)
• EMail (Private Nachrichten)
• ECash (Bezahlen im Internet)

Welche Protokolle kommen für eine verschlüsselte Übertragung zum Einsatz? (SSL)

Es gibt zum Glück eine überschaubare Menge an Protokollen, die für einen oder mehrere Einsatzgebiete möglich sind. Im Bereich WWW, EMail und ECash und auch alle anderen Sockets (z. B. FTP), dient das SSL-Protokoll (SecuritySocketLayer). SSL baut eine sichere Kommunikationsleitung zwischen Client (Dir) und einem Server (z. B. Deine Bank) auf. Dabei wird in der Regel zur Verschlüsselung des DatenStreams die RC4-Kodierung eingesetzt. Es ist jedoch auch eine DES bzw. 3DES-Verschlüsselung möglich. SSL wird von den heutigen Browsern (u. a. Netscape Communicator und Microsoft Internetexxplo.) auf der Clientseite standardmäßig unterstütz. Selbstverständlich muss auch der Webserver (Serverseite) die SSL-Verbindung anbieten. Dies ist aber bei den handelsüblichen Modellen (Apache Webserver, MS Information Server, JavaWebserver, uvm.) heute fast immer der Fall.

Du wirst bestimmt schon mal bewusst oder unbewusst eine SSL (z. B. beim Internetbanking oder beim Internetshoping) genutzt haben.

Für die Entwickler unter euch wird sicher auch interessant sein, dass SSL bei Inprise Corba (verteilte Systeme) unterstützt wird. Dies ermöglichst eine sehr leichte und sichere Implementation von verteilten Systemen.

Achtung:

Die USA haben eine Exportbeschränkung auf die Schlüsselalgorithmen gelegt. D.h., dass z. B. die Browser bzw. Windows in anderen Staaten nur max. eine 40bit-Verschlüsselung unterstützen. Dies ist z. B. einigen Banken (Sparkassen) zu wendig und sie bieten einen extra SSL-Client an, der die 128bit-Verschlüsselung unterstützt.

Wie läuft das bei SSL nun ab?

Wenn Du z. B. mit Deinem Browser auf eine sichere Internetseite gehst, fordert dieser beim Server ein X.509-Zertifikat an. Dieses Zertifikat beinhaltet u.a. den PublicKey des Servers und die von ihm unterstützen Verschlüsselungsverfahren. Wenn das ServerZertifikat von einer eingetragenen CA (z. B. der Telekom bei Netscape Navigator Version 4.51) unterschrieben ist, informiert Dich der Server kurz in einem Dialog davon, dass Du im Begriff bist eine sichere HTTPs-Verbindung aufzubauen. (der Präfix s steht für security) Sofern das Webserverzertifikat nicht von einer eingetragenen CA unterschrieben ist, wird Dich der Browser mit einer sehr umfangreichen Sicherheitswarnung informieren. Dann musst Du selber entscheiden, ob Du das Zertifikat und damit den Anbieter akzeptierst oder nicht.

Nachdem Du alles akzeptiert hast, erzeugt Dein Browser einen SessionKey für den Verschlüsselungsalgorithmus. Auf unserer WebserverAufbauPage (ITBeispiele) zeigen wir ein SSL-Beispiel von der Serverseite aus betrachtet.

Gibt es noch andere SecurityProtokolle?

Ja! - Nur haben die sich und werden sich vermutlich auch nicht durchsetzen. Die Entwicklung von SHEN ist zum Beispiel schon eingestellt worden. AuchSHTTP (Terisa Systems) wird auf der Clientseite (Browsern) kaum unterstütz. Es ist im Gegensatz zu SSL auch nur im HTTP-Protokoll verwendbar. Auch Microsoft versuchte sich an einem neuen Modell Namens STLP, dassPCT (PrivateCommunicationsTechnology) und SSL (SecuritySocketLayer) zusammenführen soll. Die Working Group für Transport Layer Security hat sich aber am 6. März auf SSL 3.0 geeinigt.

Wie läuft das nun mit der Sicherung bei EMails?

Bei Emails setzt sich wohl das S/MIME-Verfahren (auch mit einem X.509-Zertifikat) durch. In diesem Fall wird die gesamte EMail incl. der Attachments vor der Übertragung verschlüsselt und ggf. signiert. Ein Beispiel findet Ihr auf unserer ITSicherheitspage / EMails! Weiter oben haben wir bereits schon das Beispiel EMail erwähnt.

Alternativ zum S/MIME-Verfahren gibt es hier noch folgende weitere Protokolle:

• Das relativ weit verbreitete PGP  (Pretty Good Privacy)
• PEM (Privacy Enhanced Mail)
• MailTrusT  (von TeleTrusT Deutschland  )

Bei MailTrustT (MTT) handelt es sich sicherlich auch um ein recht gut spezifiziertes und durchdachtes System. Genauso wie S/MIME arbeitet MTT auf der Basis von X.509-Zertifikaten. Die Spezifikationen sind frei verfügbar und im Gegensatz zu S/MIME sehr gut dokumentiert. Die Firma Kryptokom (www.kryptokom.de) bietet inzwischen auch ein PlugIN für Outlook nach dem MTT-Verfahren an.

Wie ist es nun mit dem Bezahlen im Internet - Was steht mir da zur Verfügung? (ECash)

Auch hier stehen uns mehrere Protokolle zur Verfügung. Ein sehr vielversprechender Ansatz ist das SET-Protokoll (Secure Encryption Transaction-Protokoll), dass eine Verbindung zwischen STT (Visa/Microsoft) undSEPP (Mastercard/IBM/Netscape/GTE/CyberCash) ist. Die Unternehmen verfolgen mit diesem Ansatz eine sicheres Verfahren zur Identifizierung zwischen Kunde und Händler sowie eine abhörsichere Übertragung der Kreditkartennummer bzw. der Zahlungsdaten. Wie bei SSL, S/MIME wird auch bei SET das X.509-Zertifikat verwendet. Leider sind die Zertifikate in ihren Inhalten unterschiedlich, so dass nicht unbedingt eine SSL Zertifikat z. B. für S/MIME verwendet werden kann. Jedoch ist eine Integration aller Zertifikatsdaten möglich. In diesem Fall kann der USER mit einem Zertifikat alle wichtigen SecurityTransaktionen im Internet durchführen.

SET ist bereits im Internetexxplo. 5.0 fest integriert (Start->Systemsteuerung->Internetoptionen->Inhalt->Wallet) und vermutlich auch in Netscape! Sofern Dein Browser SET nicht unterstützt, kannst Du Dir ein PlugIN runterladen.

Gibt es auch im ECash neben SET noch andere Techniken?

Ja!

Es gibt z. B. das CAFE-Projekt, indem verschiedene Länder das Ziel einer elektronischen Geldbörse verfolgen oder das PMTP-Verfahren (elektronisches Online Cash System) zum Schluss sei noch das MPTP -Verfahren genannt. Ob sich eines dieser Verfahren durchsetzen wird, ist äußerst zweifelhaft und auch nicht unbedingt wünschendwert. Schließlich ist es für den Endverbraucher (User) immer von Vorteil, wenn er nach einem einheitlichen Verfahren Weltweit bezahlen kann.

Fazit!

Gemeinsame Schnittstelle in allen drei großen Bereichen ist das X.509-Zertifikat, welches sich wohl auch mit großer Wahrscheinlichkeit durchsetzen wird. Aus diesem Grund wollen wir auch noch etwas Näher auf dieses Zertifikatsformat eingehen.

Wie oben bereits schon erwähnt, könnt Ihr euch unter Windows (Internetoptionen) die installierten Zertifikate ansehen. Diese Zertifikate sind alle nach dem X.509-Format aufgebaut.

So ein X.509v3-Zertifikat besteht aus folgendem ASN.1 kodierten Format:

Certificate  ::= SEQUENCE {

    tbsCertificate      TBSCertificate,

    signatureAlgorithm AlgorithmIdentifier,

    signature           BIT STRING }

Die Struktur "tbsCertificate" beinhaltet euere Daten (z. B. Name), die mit den Signaturalgorithmus "signatureAlgorithm" signiert werden. Die signierten Daten werden dann in dem Feld "signature" abgelegt.

In der Struktur "tbsCertificate" sind nun folgende Informationen ASN.1 kodiert abgelegt:

TBSCertificate :: = SEQUENCE {

    version               [0] EXPLICIT Version DEFAULT v1,

    serialNumber          CertificateSerialNumber,

    signature             AlgorithmIdentifier,

    issuer                Name,

    validity              Validity,

    subject               Name,

    subjectPublicKeyInfo SubjectPublicKeyInfo,

    issuerUniqueID        [1] IMPLICIT UniqueIdentifier OPTIONAL

    subjectUniqueID       [2] IMPLICIT UniqueIdentifier OPTIONAL

    extensions            [3] EXPLICIT Extensions OPTIONAL } 

Feld	Bedeutung
version	Beinhaltet die Versionsnummer des verwendeten Zertifikats Version ::= INTEGER { v1(0), v2(1), v3(2) }
serialNumber	Identifiziert dieses Zertifikat entsprechend der CA Aussteller CertificateSerialNumber ::= INTEGER
signature	Dieses Feld enthält den Signaturalgorithmus, mit dem die Signatur gebildet wird
Name	Bezeichnung der CA (Zertifizierungsstelle) nach X.500-DistinguishedNames
Validity	Ist der Gültigkeitszeitraum des Zertifikats Validity ::= SEQUENCE {   notBefore Time,   not After Time } Time ::= CHOICE {   utcTime          UTCTime,   generalizedTime GeneralizedTime }
subject	Daten des Zertifikatsinhabers nach X.500-DistinguishedNames
subjectPublicKeyInfo	public Key des Zertifikatsinhabers SubjectPublicKeyInfo ::= SEQUENCE {   algorithm         AlgorithmIdentifier,   subjectPublicKey BIT STRING }
issuerUniqueID subjectUniqueID	Optionale Parameter
extensions	Optionale Zertifikatserweiterungen

Format des X.500-DistinguishedNames:

Name ::= CHOICE { RDNSequence }

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

RelativeDistinghuishedName ::= SET OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {

  AttributeType,

  AttributeValue }

AttributeType ::= OBJECT IDENTIFIER

AttributeValue ::= ANY DEFINED BY AttributeType

Extensions sind im Prinzip frei definierbare Felder in einem X.509-Zertifikat. Jeder Zertifikatsaussteller kann sich im Rahmen gewisser Formatvorschriften zusätzliche Informationen ins Zertifikat (Extensions) einbringen. 

Extensions sind ab der Version 3 im X.509-Zertifikat zugelassen. Damit die Software die Extensions richtig auswerten kann, muss die Versionsnummer des Zertifikats auf 3 gesetzt werden (intern 0, 1 oder 2).

Existieren bereits Extensions?

Es gibt schon vordefinierte Standard- und Private-Extensions bei denen noch unter den Critical und Non-Critical Typen unterschieden wird. 

Als Critical gesetzte Extensions müssen in jedem Fall von der Software ausgewertet werden. Ist dies nicht möglich, darf das Zertifikat nicht verwendet werden. Non-Critical Extensions können aber müssen nicht unbedingt berücksichtigt werden.

Achtung:

Wenn Du eigene CriticalExtensions definierst, wird jede andere Software Dein Zertifikat mit einem Fehler zurückweisen. In der Regel solltest Du Extensions immer als Non-Critical definieren, damit auch andere Programme Dein Zertifikat verarbeiten können.

Wenn Ihr euch mal ein X.509-Zertifikat in verschiedenen Versionen (1, 2 oder 3) ansehen wollt, könnt Ihr unter Windows95/98/NT unter dem Menüpunkt Start->Einstellungen->Systemsteuerung->Internetoptionen->Inhalt->Zertifikate euch ein paar Zertifikate mit verschiedenen Extensions betrachten.

Folgende Tabelle gibt einen Überblick über die vordefinieten Extensions, die in dieser Form nicht nochmals definiert werden dürfen: 

Standardextensions		PrivateExtensions
Authority Key Identifiert Subject Key Identifier Key Usage Private Key Usage Period Certificate Policies Policy Mappings Subject Alternative Name Issuer Alternative Name Subject Directory Attributes Basic Constraints Name Constraints Policy Constraints CRL Distributions Points Extended Key Usage Field		Authority Information Access

• Zertifikatsformate SigG.DOC 
• Zertifikatsformate PKS II.DOC 

(c) 1998/1999/2000 LogoSecProduction - created 06.05.1999 your Webmaster!

Last Update / Stand 20.05.2000