Material zum Praktikumsversuch. Grundpraktikum zur IT-Sicherheit. S/MIME zur Verschlüsselung und zum Signieren von s.

Transkript

1 Material zum Praktikumsversuch Stand: 25. November 2007, zusammengestellt von: Jörg Schwenk (Lehrstuhl NDS) Version 0.6 Grundpraktikum zur IT-Sicherheit S/MIME zur Verschlüsselung und zum Signieren von s. Lehrstuhl für Netz- und Datensicherheit Ruhr-Universität Bochum Bitte beachten Sie, dass dieser Versuch im Raum IC4/58 stattfindet. Praktikumsversuch S/MIME Jörg Schwenk 2007 Lehrstuhl Netz- und Datensicherheit 1

2 1 Organisation 1.1 Erforderliche Vorkenntnisse zur Teilnahme an diesem Versuch Vorlesung Kryptographie und Datensicherheit, Prof. Paar. Struktur von Zertifikaten nach X.509. Auszug Sichere aus Jörg Schwenk: Sicherheit und Kryptographie im Internet, Vieweg-Verlag 2002 (in Abschnitt 2 auszugsweise abgedruckt). Abschnitt Using Mail/Signing & Encrypting Messages aus Mozilla Help lesen. 1.2 Kontrollfragen Eingangstestat: Sie sollten folgende Fragen beantworten können (bevor der Versuch beginnt): Aus welchen Teilen besteht eine nach RFC822? Was ist der Unterschied zwischen den Protokollen POP und IMAP? Warum wurde MIME eingeführt? Welche zusätzlichen Header-Felder wurden mit MIME eingeführt? Ist PGP ein MIME-Typ? Wie wird eine WORD-Datei als Attachment einer transportiert? Welche Vorbereitungen müssen Sie treffen, um eine signieren zu können? Welche Vorbereitungen müssen Sie treffen, um eine an Empfänger A verschlüsseln zu können? Was ist der Unterschied zwischen opaque-signed und clear-signed? Wo wird bei Mozilla der private Schlüssel gespeichert? 1.3 Schriftliche Versuchsauswertung Jedes Team fertigt eine schriftliche Auswertung an. Beantworten Sie darin die Fragen, die zu den jeweiligen Teilversuchen gestellt wurden. Bitte geben Sie auch Feedback, ob Sie den Praktikumsversuch als interessant empfunden haben und ob dieses Dokument für Sie bei der Versuchsdurchführung hilfreich war. Verbesserungsvorschläge sind willkommen! Die Versuchsauswertung ist schriftlich beim nächsten Termin mitzubringen! Praktikumsversuch S/MIME Jörg Schwenk 2007 Lehrstuhl Netz- und Datensicherheit 2

3 2 Sichere S/MIME hat sich in der Microsoft-Welt als Standard für sichere weitgehend durchgesetzt; seit er auch vom Mozilla-Projekt unterstützt wird (Mozilla 1.7.3) ist er wieder für alle Plattformen verfügbar. Er soll hier schrittweise anhand seiner Herkunft erläutert werden. Dazu müssen wir das ursprüngliche -Format, wie es in RFC 822 beschrieben ist, und seine Beschränkungen betrachten. Diese Beschränkungen wurden durch den MIME- Standard aufgehoben, indem neue Datentypen und Codierungen eingeführt wurden. Auf dieser Basis ist es möglich, spezielle Datentypen für die sichere -Kommunikation zu definieren nach RFC 822 Im August 1982 wurden zwei Standards verabschiedet, die die Grundlage für den - Dienst im Internet legten: In [RFC 821] wurde ein einfaches, ASCII-basiertes Protokoll definiert, das den Austausch von s zwischen zwei Mailservern beschreibt. In [RFC 822] wird der Aufbau einer beschrieben. Date: Mon, 7 Mai :25:37 (GMT) From: joerg.schwenk@rub.de Subject: RFC 822 To: student@uni.de Hallo. Dieser Abschnitt ist der Inhalt der Nachricht, der durch eine Leerzeile vom Header getrennt ist. Bild 2.1: Eine einfache nach [RFC 822] Eine nach [RFC 822] besteht aus folgenden Teilen (vgl. Bild 2.1): Envelope (Umschlag): Er wird vom Mailsystem während des Transports der mit Hilfe der Header-Information erzeugt und verändert. Header (Kopf): Er enthält Informationen zu Absender und Empfänger, zum Datum, zum Betreff, usw. Jede Zeile besteht aus Schlüsselwort, Doppelpunkt, und Argumenten. Body (Text): Hier wird ein reiner ASCII-Text erwartet, der vom Header durch eine Leerzeile getrennt ist. Diese einfache Datenstruktur wird mit einem einfachen, ASCII-basierten Protokoll übertragen, dem Simple Mail Transfer Protocol (SMTP) [RFC 821]. Bild 2.2 gibt den Ablauf eines SMTP-Protokolls für den Fall wieder, dass eine auf dem Mailserver uni.de zwischengespeicherte des Nutzers student@uni.de an die Mailadresse info@rub.de weitergeleitet werden soll. Dieses Protokoll funktioniert nur zwischen Rechnern, die ständig online sind, und auf denen ein SMTP-Dämon läuft. Um der zunehmenden Zahl von PCs Rechnung zu tragen, wurden zum Abruf der Nachrichten noch das Post Office Protocol (POP) [RFC 1725] und das Internet Message Access Protocol (IMAP) [RFC 1730] definiert, mit denen man auf dem Mailserver zwischengespeicherte s entweder insgesamt oder selektiv laden kann. Eine zunehmend Praktikumsversuch S/MIME Jörg Schwenk 2007 Lehrstuhl Netz- und Datensicherheit 3

4 wichtigere Rolle spielt auch der Web-basierte Ansatz, bei dem s über das http- Protokoll gelesen und versendet werden. uni.de Mailserver: uni.de Mailserver: rub.de rub.de POP POP SMTP SMTP SMTP 220 rub.de SMTP server ready HELO uni.de 250 rub.de says hello MAIL FROM: <studedent.uni.de> 250 sender OK RCPT TO: 250 recipient OK DATA 354 send mail including header lines and blank line between header and body; end with. -line From: To: Subject: Hello Hello World!. 250 message accepted QUIT 221 rub.de closing connection Bild 2.2: Die Schritte im SMTP-Protokoll. Diese einfachen, ganz auf einfache englischsprachige Textnachrichten zugeschnittenen E- Mail-Standards RFC 821 und 822 stießen schnell an ihre Grenzen: Binärdaten müssen vor dem Versenden in ASCII umgewandelt werden (z.b. auf UNIX-Systemen mit Programmen wie uuencode). Ein einheitlicher Standard für diese Umwandlung fehlte, und so war das Versenden von Nicht-ASCII-Dateien z.b. von einem UNIX-Rechner auf einen PC eine komplizierte Angelegenheit. Umlaute aus anderen Sprachen und fremde Schriftarten (z.b. Kyrillisch) konnten nicht dargestellt werden. Jedes -Gateway interpretierte die zu übertragende als Folge von ASCII- Zeichen. Fehlerhafte Implementierungen von Gateways hatten zur Folge, dass o Carriage Return oder Linefeed-Zeichen gelöscht, o Zeilen mit einer Länge von mehr als 76 Zeichen abgeschnitten oder umgebrochen, o mehrfache Leerzeichen entfernt und o Tabulatoren in mehrfache Leerzeichen umgewandelt wurden. Praktikumsversuch S/MIME Jörg Schwenk 2007 Lehrstuhl Netz- und Datensicherheit 4

5 Es war bald an der Zeit für eine Erweiterung des Standards, um der weiten Verbreitung des E- Mail-Dienstes Rechnung zu tragen 2.2 Multipurpose Internet Mail Extensions (MIME) Diese Erweiterung des -Standards wird in [RFC 2045 bis 2049] beschrieben. Die wesentlichen Neuerungen sind: Einführung von fünf neuen Header-Feldern, um den transportierten Content besser beschreiben zu können. Festlegung von standardisierten Inhaltsformaten, um ihre Darstellung auf MIMEkonformen Clients zu ermöglichen. Standardisierung von Übertragungscodierungen, die robust gegen Fehler der Mailgateways sind. Da es längst gängige Praxis war, in s nicht nur ASCII-Text, sondern alle möglichen Daten zu versenden, brauchte man eine Möglichkeit, diesen Mail-Inhalt mit Hilfe von Metadaten zu beschreiben. Zu diesem Zweck wurden die folgenden fünf Headerfelder neu eingeführt: MIME-Version: 1.0. Die Versionsnummer muss bei jedem Standard mit angegeben werden, um spätere Änderungen zu ermöglichen. Dies ist also keine Besonderheit von MIME, sondern taucht bei allen Standards auf. Der aktuelle Wert 1.0 verweist auf [RFC 2045] und [RFC 2046]. Content-Type: Dies ist das wichtigste neue Header-Feld. Es beschreibt den angefügten Inhaltstyp ( Content ) und ermöglicht es einem MIME-Client so, das passende Anzeigemodul zu starten. Z.B. bewirkt die Angabe des Mime-Typs text/html, dass nicht das HTML-File in seiner Textform wiedergegeben wird, sondern von einem HTML-Interpreter dargestellt wird. Die standardisierten Content-Typen sind in Bild 2.3 wiedergegeben, die Liste ist aber beliebig erweiterbar. Content-Transfer-Encoding: Da der Inhalt einer weiterhin als Folge von ASCII-Zeilen, die nicht mehr als 76 Zeichen enthalten, übertragen werden muss (RFC 822 bleibt ja weiterhin gültig), stellt MIME eine Auswahl von Standard- Codierungsverfahren bereit, die den Content in diese Form umwandeln. Diese Transportcodierungen können jeweils passend zum Content gewählt werden und sind weiter unten beschrieben. Content-ID: Dies ist ein eindeutiger Bezeichner des Content. Content-Description: Beschreibung des Content. Dies ist hilfreich bei der Fehlersuche, falls der Content nicht (korrekt) wiedergegeben werden kann. Als Übertragungscodierungen wurden folgende Algorithmen festgelegt, die je nach den Fähigkeiten der -Gateways und den Eigenschaften des Content ausgewählt werden: 7 Bit: Der Text der Nachricht enthält nur ASCII-Zeichen. Es wurde keine Codierung vorgenommen. 8 Bit: Der Text der Nachricht enthält nur kurze Zeilen (höchstens 76 Zeichen). Es können aber Nicht-ASCII-Zeichen auftreten. Es wurde keine Codierung vorgenommen. (Hier besteht die Gefahr, dass Mailgateways diese Nicht-ASCII- Zeichen falsch übertragen.) Binary: Lange Zeilen mit Nicht-ASCII-Zeichen treten auf. Es wurde keine Codierung vorgenommen. (Lange Zeilen können hier von alten Mailgateways nach dem 76. Zeichen abgeschnitten werden.) Praktikumsversuch S/MIME Jörg Schwenk 2007 Lehrstuhl Netz- und Datensicherheit 5

6 Quoted-printable: Nicht-ASCII-Zeichen wurden durch eine Folge von ASCII- Zeichen ersetzt. Falls der codierte Inhalt viel ASCII-Text enthält, bleibt er so lesbar. Diese Codierung eignet sich z.b. für deutschsprachigen Text, in dem die Umlaute dann durch ASCII-Zeichenfolgen ersetzt werden. Base64: Je 3*8 Bit werden als 4*6 Bit-ASCII-Zeichen übertragen. Diese Codierung wird auf Binärdaten angewendet. Typ Subtyp Beschreibung Text Plain Unformatierter Text, z.b. ASCII. Enriched Mit bestimmten Formatierungen. Multipart Mixed Unabhängige Teile, die zusammen übertragen und in der übertragenen Ordnung dargestellt werden sollen. Parallel Alternative Digest Unterschied zu Mixed: Hier ist keine Ordnung definiert. Alternative Versionen derselben Information. Wie Mixed, aber als Default-Typ/Subtyp wird Message/rfc822 angenommen. Message Rfc822 Der Body der Nachricht ist selbst eine . Partial External-body Typ Subtyp Beschreibung Zeigt eine Fragmentierte an. Pointer auf ein Objekt, das woanders liegt. Image Jpeg JPEG-Format, JFIF-Encodierung Gif GIF-Format Video Mpeg Video im MPEG-Format Audio Basic Einkanal 8 Bit ISDN, 8kHz Application Postscript Adobe Postscript Octet-stream Binärdaten aus 8-bit-Bytes Bild 2.3: Standardisierte MIME-Datentypen Die Beispielnachricht aus Bild 2.4 besteht aus drei Teilen: Dem Header mit den neuen MIME-Feldern und einer Warnmeldung für nicht MIME-fähige -Clients, einer deutschsprachigen Textnachricht mit Umlauten in quoted-printable-codierung, und einer MS-Word-Datei als binärem Anhang in Base64-Codierung. Die einzelnen Teile werden durch einen eindeutigen Separator, der hinter boundary= angegeben ist, voneinander getrennt. Eine MIME-Nachricht ist ein verschachtelter Datentyp. Sie kann daher als Baumstruktur dargestellt werden, mit den eigentlichen Inhalten als Blätter. So hat z.b. die MIME-Nachricht aus Bild 2.4 die Wurzel multipart/mixed, und unter dieser Wurzel hängen die beiden Blätter text/plain (der -Text) und application/msword (das angefügte Word-Dokument). Eine MIME-Nachricht wird in drei Schritten erzeugt: 1. Die Reihenfolge der einzelnen Objekte, und die Baumstruktur selbst wird vom Sender-Client gemäß seiner Konventionen festgelegt. 2. Die Nachrichten-Inhalte (die Blätter) werden kanonisiert (s.u.). 3. Auf die kanonisierten Nachrichten-Inhalte wird eine passende Transport-Codierung angewendet. Für die sich anschließenden kryptographischen S/MIME-Operationen sind die Schritte 2 und 3 wichtig. Mit der Darstellung der Daten in einer kanonischen Form wird im MIME-Standard sichergestellt, dass die Daten im Sende- und Zielsystem dieselbe Bedeutung haben. Das ist am einfachsten am Typ text zu erläutern: Der verwendete Zeichensatz muss mit angegeben werden (z.b. in Bild 2.4 charset="iso "), und das Ende einer Zeile muss durch die Praktikumsversuch S/MIME Jörg Schwenk 2007 Lehrstuhl Netz- und Datensicherheit 6

7 Zeichenfolge <CR><LF> beschrieben werden. Dadurch kann ein Text, der auf einem UNIX- System erstellt wurde, auch auf einem PC in genau der gleichen Form wiedergegeben werden. Der signierte Text hat also auf beiden Systemen die gleiche Bedeutung. Date: Mon, 7 Mai :25:37 (GMT) From: joerg.schwenk@fh-nuernberg.de Subject: MIME To: student@uni.de Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_nextpart_000_01bdcc1e.a4d02412" Content-Length: Hier kann eine Fehler- oder Warnmeldung stehen, die nur von nicht-mime-faehigen Clients dargestellt wird _=_NextPart_000_01BDCC1E.A4D02412 Content-Type: text/plain; charset="iso " Content-Transfer-Encoding: quoted-printable Ein deutschsprachiger Text wurde hier als quoted-printable codiert, um m=f6glichst viel Text f=fcr nicht-mime-clients lesbar zu halten. Mit freundlichen Gr=FC=DFen J=F6rg Schwenk _=_NextPart_000_01BDCC1E.A4D02412 Content-Type: application/msword; name="sicherheitskonzept.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sicherheitskonzept.doc" Content-Location: ATT-0-B028877FBC37D211B3CD00A0C981DBBA-ANGEBO%7E1.DOC 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAABAAAAAAAAAAA EAAAFAAAAAEAAAD+////AAAAAAUAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// dgv3yxkglsbtexn0zw1ldq1ezwzpbml0aw9uihzvbibty2h1dhptyd9uywhtzw4gzvxyog1dbgll bnqglsbtb2z0d2fyzq1xaw5kb3dzifzlcnnpb24gwa1nywnpbnrvc2gnu2vydmvyc3lzdgvtzq1o _=_NextPart_000_01BDCC1E.A4D Bild 2.4: MIME- , bestehend aus MIME-Header, ASCII-Fehlertext, dem eigentliche Text in quoted-printable-codierung, und einem (gekürzten) base64- Attachment einer Binärdatei. An das jeweilige Transportsystem angepasst werden müssen die Transportcodierungen. Im E- Mail-Bereich muss hier darauf geachtet werden, dass das resultierende MIME-Objekt alle Forderungen aus RFC 822 erfüllt, also z.b. nur aus ASCII-Zeichen besteht. Wird ein MIME- Objekt dagegen über HTTP übertragen, so sind beliebige Bytes erlaubt. 2.3 Secure/MIME Der Standard Secure/MIME erweitert die MIME-Datentypen um Konstrukte für signierte und verschlüsselte Nachrichten (siehe Bild 2.8). Er ist im Wesentlichen in den RFCs (Version 2), 2630, 2632 und 2633 (Version 3) beschrieben [SMIME]. Der Wechsel von Version 2 zu Version 3 ist weniger durch technische Notwendigkeiten begründet, als vielmehr mit der Geschäftspolitik rund um das RSA-Patent. In S/MIME Version 2, der unter maßgeblicher Beteiligung der Firma RSA Inc. entstand, spielt der RSA- Praktikumsversuch S/MIME Jörg Schwenk 2007 Lehrstuhl Netz- und Datensicherheit 7

8 Algorithmus, als einziger zwingend vorgeschriebener Public-Key-Algorithmus, eine Schlüsselrolle, und die Public Key Cryptography Standards (PKCS) 1, 7 und 10 dieser Firma werden in den RFCs namentlich erwähnt. Warum dies von der IETF nicht weiter unterstützt wurde, ist unbekannt. Jedenfalls wurde in Version 3 der RSA-Algorithmus zur Option degradiert, und die PKCS-Standards zu einem Cryptographic Message Syntax (CMS) - Dokument [RFC 2630] zusammengefasst. Die wesentlichen Unterschiede zwischen den beiden Versionen betreffen die verwendeten kryptographischen Algorithmen und sind in Bild 2.5 zusammengefasst. Abgesehen von diesen Unterschieden basieren Version 2 und 3 auf der gleichen Technologie. Da die PKCS- Standards auch außerhalb der S/MIME-Welt bedeutsam sind, gehen wir in einem eigenen Abschnitt anhand von [RFC 2630] näher auf sie ein. Eine Beschreibung neuer Sicherheitsfunktionalitäten, die mit Hilfe des S/MIME-Standards implementiert werden können, findet man im Dokument Enhanced Security Services for S/MIME [RFC 2634]. Dort ist beschrieben, wie man signierte Empfangsbestätigungen und Sicherheitslabel erzeugen kann, wie die Verschlüsselung einer Nachricht an eine große Mailingliste in sicherer Art und Weise einem Mail Agent überlassen werden kann, und wie Informationen zum Zertifikat in die Signatur mit eingebunden werden können. Algorithmus S/MIME Version 2 S/MIME Version 3 vorgeschrieben optional vorgeschrieben optional Hash MD5, SHA-1 SHA-1 MD5 Signatur RSA DSA RSA Public-Key- Verschlüsselung RSA Diffie-Hellman [RFC 2631] RSA Bild 2.5: Die unterschiedliche Verwendung von kryptographischen Algorithmen in den S/MIME Versionen 2 und 3. Einleitung Der große Vorteil der Verwendung des MIME-Standards für Sicherheitsfunktionen liegt darin, dass Verschlüsselung und Signatur genauso einfach zu bedienen sind, wie z.b. die HTML-Formatierung einer oder das Anfügen eines Attachments. Dass dies in den vorliegenden Clients noch nicht so reibungslos funktioniert, liegt an der Art der Implementierung, nicht am S/MIME-Konzept. Bild 2.6 gibt ein Beispiel für die komfortable Auswertung und Signalisierung von Sicherheitseigenschaften, bei sehr komplexem Quelltext (Bild 2.7). Bild 2.6: Darstellung einer nach S/MIME verschlüsselten und signierten im Netscape Messenger. Praktikumsversuch S/MIME Jörg Schwenk 2007 Lehrstuhl Netz- und Datensicherheit 8

9 X-Mozilla-Status: 0001 X-Mozilla-Status2: Message-ID: Date: Wed, 12 Apr :15: From: =?iso ?q?j=f6rg?= Schwenk Reply-To: X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Subject: S/MIME Content-Type: application/x-pkcs7-mime; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" Content-Description: S/MIME Encrypted Message MIAGCSqGSIb3DQEHA6CAMIACAQAxgcwwgckCAQAwczBtMQswCQYDVQQGEwJERTEcMBoGA1UE ChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEdMBsGA1UECxMUVGVsZVNlYyBUcnVzdCBDZW50ZXIx ITAfBgNVBAMTGERldXRzY2hlIFRlbGVrb20gVGVzdCBDQQICAswwDQYJKoZIhvcNAQEBBQAE QJtWSHPh+l2D+3UqW0itsjOKE1oyAkAz+wtmH/u42STjeEYhxKJINThw0rRkHtf07fq7puS5 GMzeyBLDhdbv9+ZsvOrW79URmz600QSOzARIWSN6wg1Zqs2pjtTWm4fiXyMS7oOlBa76oGYX mvvnxkrw+4dhsmywizijl62yx+fsyip0qlmqrx66i8mc7y3zoqsajislg0gubdbngyif0rxy 4PMrG3gw2DqD7qCvRMqcPCyYgVugEGLokMjjx7xeu+uaE7UCgbufdH4ECGgFZvC7qt/PAAAA AAAAAAAAAA== Bild 2.7: Gekürzter Quelltext zu Bild 2.6. Typ Subtyp S/MIME Parameter Beschreibung multipart signed Eine signierte Nachricht in zwei Teilen: Der erste Teil ist die unveränderte Originalnachricht, der zweite die Signatur ( Clear-signed ). application File- Erweiterung pkcs7- mime pkcs7- mime pkcs7- mime pkcs7- signature pkcs10- mime signeddata.p7m Ein signierter S/MIME-Datensatz. enveloped Data Bild 2.8: S/MIME-Datentypen.p7m Ein verschlüsselter S/MIME-Datensatz. certs-only.p7c Der Datensatz enthält nur X.509-Zertifikate -.p7s Der Content-Typ des Signaturteils der Multipart/Signed- Nachricht. -.p10 Ein Request zur Generierung eines Zertifikats nach PKCS#10. Da der S/MIME-Standard überwiegend von der Firma RSA Security Inc. [RSA] vorangetrieben wurde, stützen sich die vorgeschlagenen Datentypen auch weitgehend auf die von RSA publizierten Public Key Cryptography Standards (PKCS) [12]. Die drei wichtigsten Standards aus dieser Reihe sind PKCS#7: Festlegung eines Datenformats für verschlüsselte und/oder signierte Datensätze PKCS#10: Festlegung eines Datenformats zur Beantragung eines X.509-Zertifikats. PKCS#12: Format zur sicheren Speicherung kryptographischer Schlüssel. Praktikumsversuch S/MIME Jörg Schwenk 2007 Lehrstuhl Netz- und Datensicherheit 9

10 Die besondere Komplexität von S/MIME liegt im Wechselspiel zwischen 7-Bit ASCII-Code und 8-Bit Binärcode. Während der Generierung oder Auswertung einer S/MIME-Nachricht kann es erforderlich sein, mehrmals zwischen 7-Bit- und 8-Bit-Darstellung umzurechnen. Verschlüsselung Bild 2.10 gibt eine S/MIME-verschlüsselte Nachricht wieder. Sie hat den MIME-Typ application/pkcs7-mime (das vorangestellte x ist eine Netscape-Besonderheit). Der Text der Nachricht ist Base64 -codiert. Nach Entfernen dieser Codierung sieht man im rechten Fenster den (gekürzten) PKCS#7-Vorspann, der alle zur Entschlüsselung der Nachricht benötigten Informationen enthält, und den Beginn der verschlüsselten Nachricht in Hexadezimalnotation. From: Schwenk <schwenk@tzd.telekom.de> MIME-Version: 1.0 To: schwenk@tzd.telekom.de Subject: S/MIME Content-Type: application/xpkcs7-mime; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7m" Content-Description: S/MIME Encrypted Message MIAGCSqGSIb3DQEHA6CAMIACAQAxgcww gckcaqawczbtmqswcqydvqqgewjertec MBoGA1UE ChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEd MBsGA1UECxMUVGVsZVNlYyBUcnVzdCBD ZW50ZXIx mvvnxkrw+4dhsmywizijl62yx +fsyip0qlmqrx66i8mc7y3zoqsajislg 0GuBDBNgYif0RXY 4PMrG3gw2DqD7qCvRMqcPCyYgVugEGLo kmjjx7xeu +uae7ucgbufdh4ecggfzvc7qt/paaaa AAAAAAAAAA== Message-Body: Envelope: PKCS7: Content-Type: pkcs7-envelopeddata Version: 0 RecipientInfos: RecipientInfo: Version: 0 Serial-Number: 716 Issuer: Key-Encryption-Algorithm: Algorithm: rsaencryption Parameter: Encrypted-Key: Length: 64 Bytes 9B:56:48:73:E1:FA:5D:83: Encrypted-Content: Content-Type: pkcs7-data Encryption-Algorithm: Algorithm: des-ede3-cbc Parameter: Octet-String: Length: 8 Bytes C4:FB:D7:05:A9:84:83:75 Encrypted-Data: Length: 3608 Bytes 3A:DB:98:08:1C:2E:C0:6B:41: Bild 2.10: Aufbau einer verschlüsselten S/MIME-Nachricht. Das PKCS#7-Objekt enthält folgende Informationen: Content-Type: Hier wird angegeben, dass es sich um verschlüsselte Daten handelt. RecipientInfo/Serial-Number und RecipientInfo/Issuer: Hier wird angegeben, dass zur Verschlüsselung des symmetrischen Schlüssels der öffentliche Schlüssel aus dem Zertifikat Nummer 716 des angeführten Herausgebers verwendet wurde. Key-Encryption-Algorithm: Der Sitzungsschlüssel wurde mit dem RSA- Algorithmus verschlüsselt. Encrypted-Key: Hier steht der mit dem RSA-Algorithmus und dem angegebenen öffentlichen Schlüssel verschlüsselte symmetrische Schlüssel. Encryption-Algorithm: Hier steht der verwendete symmetrische Algorithmus (TripelDES im CBC-Modus) und der Initialisierungsvektor. Praktikumsversuch S/MIME Jörg Schwenk 2007 Lehrstuhl Netz- und Datensicherheit 10

11 Encrypted-Data: Hier steht die eigentliche verschlüsselte Nachricht. Beim Sender wurde diese Nachricht wie folgt generiert: Der Absender teilte seinem S/MIMEfähigen -Client mit, dass die Nachricht an den im TO Feld angegebenen Empfänger verschlüsselt werden soll. Der Client durchsuchte daraufhin seine interne Zertifikatsdatenbank, ob ihm ein X.509-Zertifikat vorliegt, das die angegebene - Adresse enthält. Fand er keines, so musste er sich erst ein solches Zertifikat beschaffen und den Absender mit einer Warnmeldung darüber informieren, dass eine Verschlüsselung nicht möglich ist. War hingegen ein Zertifikat vorhanden, so wendete er das in Kapitel 1 beschriebene hybride Verschlüsselungsverfahren an, und zwar mit dem öffentlichen Schlüssel, der in dem passenden Zertifikat enthalten ist. Zum Schutz gegen eine unbeabsichtigte Veränderung der Daten durch einen Mailserver, die eine Entschlüsselung unmöglich machen würde, wurde die Nachricht noch base64 -codiert. Der S/MIME-Client auf Empfängerseite entfernt zunächst die base64 -Codierung. Er kann eine solche Nachricht entschlüsseln, indem er zunächst prüft, ob er das unter RecipientInfo angegebene Zertifikat und den dazu gehörenden privaten Schlüssel (noch) besitzt. In der Regel wird dies der Fall sein. Er entschlüsselt dann mit seinem privaten Schlüssel den hinter Encrypted-Key angegebenen Datensatz, entnimmt daraus den symmetrischen Schlüssel und entschlüsselt mit diesem und dem angegebenen Encryption-Algorithm die eigentliche Nachricht. Signatur Zur Signatur einer Nachricht stehen in S/MIME zwei verschiedene Datentypen zur Verfügung: application/pkcs-mime signeddata. Der Body der besteht aus einem einzigen Objekt, und zwar einem PKCS#7-Objekt vom Typ signeddata. Dieses Objekt enthält die signierten Daten, die Signatur und alle Zusatzinformationen, die zur Überprüfung der Signatur notwendig sind (verwendete Algorithmen, Zertifikate). Da auch die signierten Daten im PKCS#7-Binärformat codiert sind, können sie nur von einem S/MIME-fähigen Client, der ein entsprechendes PKCS#7- Modul enthält, dargestellt werden. Auf jedem anderen Client ist die Nachricht überhaupt nicht darstellbar. Nachrichten dieser Art werden auch als opaque-signed bezeichnet. multipart/signed. Der Body dieses Typs besteht aus zwei Teilen: Der erste Teil, die signierten Daten, sind als (ggf. in sich geschachteltes) MIME-Objekt codiert. Sie können also von jedem MIME-fähigen Client angezeigt werden. Der zweite Teil ist die dazu gehörende digitale Signatur, die als PKCS#7-Objekt codiert ist. Sie kann nur von S/MIME-fähigen Clients ausgewertet werden ( clear-signed ). Die Entscheidung zwischen den beiden Formaten hängt davon ab, welche Clients die Empfänger verwenden, und welche Prioritäten gesetzt werden: Sollen alle Empfänger (auch die mit nicht S/MIME-fähigen Clients) die Nachricht lesen können, so muss multipart/signed verwendet werden. Nachteil dieses Formats ist es, dass durch Veränderungen an der ggf. recht komplexen MIME-Struktur der E- Mail durch ein Mail-Gateway die Signatur ungültig gemacht werden kann. Dies kommt in der Praxis häufig vor. Steht vor allen die Integrität und Authentizität der Nachricht im Vordergrund, so muss application/pkcs-mime signeddata verwendet werden. Die Mailgateways sehen nur einen großen MIME-Block, den sie nicht verändern können, da die interne MIME- Struktur der Nachricht in PKCS#7 gekapselt ist. Nicht S/MIME-fähige Clients können mit dieser Darstellung nichts anfangen. Praktikumsversuch S/MIME Jörg Schwenk 2007 Lehrstuhl Netz- und Datensicherheit 11

12 Die Generierung einer application/pkcs-mime signeddata-nachricht ist ähnlich wie die einer verschlüsselten Nachricht. Die verschiedenen Kapselungen sind in Bild 2.11 dargestellt. Mime-Version: 1.0 Content-Type: application/pkcs-mime Parameter : signeddata PKCS#7-Version: 1.0 PKCS#7-Header: Algorithms: Certificates: Signature: Content: Mime-Version: 1.0 multipart/ mixed text/plain application /msword ASCII Bild 2.11: Struktur einer opaque-signed Nachricht. In Bild 2.12 ist eine multipart/signed Nachricht dargestellt. Entfernt man die Transport- und PKCS#7-Codierung, so kann man die Informationen sehen, die zu Verifikation der digitalen Signatur erforderlich sind: Digest-Algorithm: Hier steht, welcher Hash-Algorithmus zur Bildung des Hashwerts der vorangegangenen Teile benutzt wurde. Certificates: Hier beginnt eine Kette von Zertifikaten, die zur Verifikation benötigt werden: Das Client-Zertifikat wird benötigt, um die Echtheit der Signatur zu verifizieren. Das CA-Zertifikat wird benötigt, um die Echtheit des Client-Zertifikats zu überprüfen, usw. SignerInfo: Hier steht, aus welchem Zertifikat der öffentliche Schlüssel zur Überprüfung der Signatur verwendet werden muss. (Hier das Zertifikat mit der Seriennummer 549.) Signature: Hier steht die Signatur der vorangegangenen Teile. Praktikumsversuch S/MIME Jörg Schwenk 2007 Lehrstuhl Netz- und Datensicherheit 12

13 From: To: Subject: Date: MIME-Version: 1.0 Content-Type: multipart/signed; protocol= application/x-pkcs7- signature ; micalg=sha-1; boundary= Eigentliche MIME- (ggf. mit Attachments) Content-Type: application/xpks7-signature; name= smime.p7s ; Content-Transfer-Encoding: Base64 MIAGCSqGSIb3DQEH..Jx9cS9WPmbx EkAAAA== PKCS7: Content-Type: pkcs7-signeddata Version: 1 Digest-Algorithms: Digest-Algorithm: Algorithm: sha1 (2B:0E:03:02:1A) Parameter: Content: PKCS7: Content-Type: pkcs7-data Certificates: Certificate: CA-Zertifikat Certificate: Client-Zertifikat (549) SignerInfos: SignerInfo: Serial-Number: 549 Signature: 0F:9B:46:5B:.:99:BC:44 Bild 2.12: Aufbau einer clear-signed S/MIME-Nachricht Der empfangende Client kann mit Hilfe des micalg-algorithmus den Hashwert über den ersten Teil der multipart/signed-nachricht bilden. Dieser Wert wird dann verwendet, um zunächst die Gültigkeit der Signatur zu überprüfen, der dann noch die Überprüfung der Gültigkeit der Zertifikatskette folgen muss. 3 Versuche 3.1 Netzwerkkomponenten Mailserver: Die Rechner server0.netz0.test, server1.netz1.test und server2.netz2.test sind als SMTP- und POP3-Server konfiguriert. Die Kontonamen für die adressen sind identisch mit den Rechnernamen: pc011, pc012, pc013, pc014, pc015 im Subnetz netz0.test pc112, pc113, pc114, pc115, pc116, pc117, pc118 im Subnetz netz1.test pc211, pc212, pc213, pc214, pc215 im Subnetz netz2.test Die Passwörter sind identisch mit den Kontonamen bzw. Rechnernamen. Jeder Rechner besitzt somit eine eigene adresse. Die Einträge für die POP3- und SMPT-Server im Seamonkey-Mailclient lauten: server0.netz0.test server1.netz1.test server2.netz2.test Mailclients: Verwenden Sie die Mozilla Seamonkey-Software, die Seamonkey Mail in den Seamonkey Browser integriert. Praktikumsversuch S/MIME Jörg Schwenk 2007 Lehrstuhl Netz- und Datensicherheit 13

14 3.2 Versuch 1: Konfigurieren Sie Ihren -Client Konfigurieren Sie Ihren Mozilla Seamonkey -Client mit der -Adresse pczxy ist dabei der Name des Rechners, an dem Sie gerade arbeiten (Beschriftung beachten!), und netzz ist das Netzwerksegment, in dem Ihr Rechner angeschlossen ist. Diese Angaben können Sie auch dem Übersichtsplan im Netzwerklabor entnehmen. Lesen Sie dazu Using Mail aus der Seamonkey-Hilfe. Versuchsauswertung: Dokumentieren Sie die von Ihnen vorgenommene Konfiguration durch den Screenshot des abschließenden Bestätigungsfensters und eine kurze Beschreibung. 3.3 Versuch 2: Senden einer gefälschten über Telnet Öffnen Sie ein Shell-Fenster und stellen Sie mit dem Befehl > telnet serverz.netzz.test 25 eine Verbindung zu dem Mailserver her, der sich in Ihrem LAN befindet. Dabei ist Z durch die Nummer des Netzes zu ersetzen, in dem Sie sich befinden. Verwenden Sie jetzt die SMTP-Befehle, um eine plausible, gefälschte Nachricht an einen Empfänger Ihrer Wahl und an Sie selbst zu senden. Versuchsauswertung: Dokumentieren Sie die von Ihnen verwendeten SMTP-Befehle und die empfangene Versuch 3: Abruf eines X.509-Zertifikats Öffnen Sie mit dem Seamonkey-Browser und importieren Sie zunächst das Zertifikat Ihrer CA. Beantragen Sie dann ein Zertifikat für Ihre -Adresse. Konfigurieren Sie dieses Zertifikat in Mozilla Seamonkey Mail. Versuchsauswertung: Screenshot der Detailansicht des geladenen Zertifikats. Screenshot der Seamonkey Mail-Konfiguration. 3.5 Versuch 4: Senden einer signierten an alle Mailadressen im NWL Senden Sie eine signierte an alle Mailadressen im NWL. Ist diese Clear-Signed oder Opaque-Signed? Versuchsauswertung: Relevante Ausschnitte der PKCS#7-Struktur der Mails, jeweils mit Erläuterungen. Anmerkung: Zur Darstellung der PKCS#7-Struktur der Mail gehen Sie wie folgt vor: Speichern Sie die als File (File->Save As->File). Starten Sie eine Konsolen und führen Sie den Kommando xmail <gespeicherte Datei> <Verzeichnis zum Speichern der erzeugten XMaiL>. Analysieren Sie die resultierende XMaiL. Praktikumsversuch S/MIME Jörg Schwenk 2007 Lehrstuhl Netz- und Datensicherheit 14

15 o o Versehen Sie den gekürzten XMaiL-Quelltext mit Anmerkungen (gern auch handschriftlich). Der gekürzte Quelltext sollte dabei nicht mehr als 2 Din A4- Seiten umfassen. Bestimmen Sie einige ausgewählte Object Identifier unter näher. 3.6 Versuch 5: Senden einer verschlüsselten Nachricht Senden Sie eine verschlüsselte an eine Mailadresse im NWL. Ist das ohne Probleme möglich? Welche Schritte müssen Sie vorher durchführen? Versuchsauswertung: Relevante Ausschnitte der PKCS#7-Struktur der Mails, jeweils mit Erläuterungen. 3.7 Versuch 6: Reply einer verschlüsselten Nachricht Senden Sie eine direkte Antwort ( Reply ) an den Absender einer verschlüsselten Nachricht. (Sie müssen sich natürlich vorher eine verschlüsselte Nachricht zusenden lassen.) Wie sollte diese Nachricht gesichert sein? Ist das der Fall? Versuchsauswertung: Screenshot des Reply aus dem Ordner Gesendete Nachrichten. 3.8 Versuch 7: Forward einer verschlüsselten Nachricht Leiten Sie eine verschlüsselte Nachricht an eine andere Versuchsgruppe weiter. Wie sollte sich der -Client hier verhalten? Wie verhält er sich tatsächlich? (Tipp: Prüfen Sie auch nach, was passiert, wenn Sie die unverschlüsselt weiter versenden.) Versuchsauswertung: Screenshot des Forward aus dem Ordner Gesendete Nachrichten. Praktikumsversuch S/MIME Jörg Schwenk 2007 Lehrstuhl Netz- und Datensicherheit 15