E-Mail Sicherheit1 - Ruhr

Transcription

Grundpraktikum Netz- und Datensicherheit
Thema:
1
E-Mail Sicherheit
Lehrstuhl für Netz- und Datensicherheit
Ruhr-Universität Bochum
Versuchdurchführung: Raum ID 2/168
Zusammengestellt von: Pavol Sovis, Florian Bache, Patrick Meier
Stand: 25. September 2013
Version: 1.1
1
Dieses Dokument basiert auf die Versuchsbeschreibung von Jörg Schwenk: S/MIME zur Verschlüsselung und zum
Signieren von E-Mails., Version 0.6, 15 Nov. 2007
1 Organisation
1 Organisation
1.1 Erforderliche Vorkenntnisse zur Teilnahme an diesem Versuch
•
Vorlesung Kryptographie und Datensicherheit, Prof. Paar.
•
Struktur von Zertikaten nach X.509.
•
Auszug Sichere E-Mail aus Jörg Schwenk: Sicherheit und Kryptographie im Internet, ViewegVerlag 2002 (in Abschnitt 2 auszugsweise abgedruckt).
•
Abschnitt Using Mail/Signing & Encrypting Messages aus Mozilla Help lesen
•
Internet Draft Header Protection for S/MIME, Lijun Liao und Jörg Schwenk.
ietf.org/html/draft-liao-smimeheaderprotect-05
http://tools.
1.2 Kontrollfragen
Sie sollten folgende Fragen beantworten können (bevor der Versuch beginnt):
•
Aus welchen Teilen besteht eine E-Mail nach RFC822?
•
Welche Vorbereitungen müssen Sie treen, um eine E-Mail signieren zu können?
•
Was ist der Unterschied zwischen opaque-signed und clear-signed?
•
Welche Information in Header von signierten S/MIME E-Mails ohne Header-Protection-Erweiterung
sind geschützt, und unter welchen Voraussetzungen?
•
Wie werden Header-Felder in signierten S/MIME E-Mails mit Header-Protection-Erweiterung
geschützt?
•
Was ist POP, SMTP, IMAP?
•
Wie kommt eine E-Mail vom Absender zum Empfänger?
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!
Grundpraktikum NDS - E-Mail Sicherheit
2
25. September 2013
2 Sichere E-Mail
2 Sichere E-Mail
S/MIME hat sich in der Microsoft-Welt als Standard für sichere E-Mail weitgehend durchgesetzt; seit
er auch vom Mozilla-Projekt unterstützt wird (Mozilla 1.7.3) ist er wieder für fast alle Plattformen
verfügbar. Er soll hier schrittweise anhand seiner Herkunft erläutert werden. Dazu müssen wir das
ursprüngliche E-Mail-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
E-Mail-Kommunikation zu denieren.
2.1 E-Mail nach RFC 822
Im August 1982 wurden zwei Standards verabschiedet, die die Grundlage für den E-Mail-Dienst im
Internet legten: In RFC 821 wurde ein einfaches, ASCII-basiertes Protokoll deniert, das den Austausch von E-Mails zwischen zwei Mailservern beschreibt. In RFC 822 wird der Aufbau einer E-Mail
beschrieben.
Date: Mon, 5 Mai 2008 11:25:37 (GMT)
From: pc113@netz1.test
Subject: RFC 822
To: pc115@netz1.test
Hallo. Dieser Abschnitt ist der Inhalt der Nachricht
der durch eine Leerzeile vom Header getrennt ist.
Abbildung 1: Eine einfache E-Mail nach RFC 822
Eine E-Mail nach RFC 822 besteht aus folgenden Teilen (vgl. Abb. 1):
•
Envelope (Umschlag): Er wird vom Mailsystem während des Transports der E-Mail mit Hilfe
der Header-Information erzeugt und verändert.
•
Header (Kopf ): Er enthält Informationen zu Absender und Empfänger, zum Datum, zum Betre, 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). Abb. 2 gibt den Ablauf eines SMTP-Protokolls
für den Fall wieder, dass eine auf dem Mailserver uni.de zwischengespeicherte E-Mail des Nutzers
dent@uni.de
an die Mailadresse
info@rub.de
stu-
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
Oce Protocol (POP) (RFC 1725) und das Internet Message Access Protocol (IMAP) (RFC 1730)
deniert, mit denen man auf dem Mailserver zwischengespeicherte E-Mails entweder insgesamt oder
selektiv laden kann. Eine zunehmend wichtigere Rolle spielt auch der Web-basierte Ansatz, bei dem
E-Mails über das http-Protokoll gelesen und versendet werden.
3
25. September 2013
2 Sichere E-Mail
student@
uni.de
Mailserver:
uni.de
Mailserver:
rub.de
SMTP
info@
rub.de
SMTP
SMTP
POP
POP
IMAP
IMAP
HELO rub.de
-->
MAIL FROM: <student@uni.de>
-->
RCPT TO: <info@rub.de>
-->
DATA
-->
From: student@uni.de
To: info@rub.de
Subject: Hello
Hello World!
.
-->
-->
-->
-->
-->
-->
QUIT
-->
<--
220 rub.de SMTP server ready
<--
250 rub.de says hello
<--
250 sender OK
<--
250 recipient OK
<--
354 send mail including header
lines and blank line between
header and body; end with
“.“-line
<--
250 message accepted
<--
221 rub.de closing connection
Abbildung 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 E-Mail-Gateway interpretierte die zu übertragende E-Mail als Folge von ASCII-Zeichen.
Fehlerhafte Implementierungen von Gateways hatten zur Folge, dass
Carriage Return oder Linefeed-Zeichen gelöscht,
Zeilen mit einer Länge von mehr als 76 Zeichen abgeschnitten oder umgebrochen,
mehrfache Leerzeichen entfernt und
Tabulatoren in mehrfache Leerzeichen umgewandelt wurden.
Es war bald an der Zeit für eine Erweiterung des Standards, um der weiten Verbreitung des E-MailDienstes Rechnung zu tragen.
4
25. September 2013
2 Sichere E-Mail
2.2 Multipurpose Internet Mail Extensions (MIME)
Diese Erweiterung des E-Mail-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 MIME-konformen Clients zu ermöglichen.
•
Standardisierung von Übertragungscodierungen, die robust gegen Fehler der Mailgateways sind.
Da es längst gängige Praxis war, in E-Mails 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 Abb. 2.3 wiedergegeben, die Liste ist aber beliebig erweiterbar.
• Content-Transfer-Encoding :
Da der Inhalt einer E-Mail 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
E-Mail-Gateways und den Eigenschaften des Content ausgewählt werden:
• 7 Bit :
Der Text der Nachricht enthält nur ASCII-Zeichen. Es wurde keine Codierung vorgenom-
men.
• 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 vorgenom-
men. (Lange Zeilen können hier von alten Mailgateways nach dem 76. Zeichen abgeschnitten
werden.)
• 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.
Die Beispielnachricht aus Abb. 3 besteht aus drei Teilen: Dem Header mit den neuen MIME-Feldern
und einer Warnmeldung für nicht MIME-fähige E-Mail-Clients, einer deutschsprachigen Textnachricht
5
25. September 2013
2 Sichere E-Mail
Typ
text
Subtyp
Beschreibung
plain
Unformatierter Text, z.B. ASCII
enriched
Mit bestimmten Formatierungen
mixed
Unabhängige Teile, die zusammen übertragen und in der
übertragenen Ordnung dargestellt werden sollen
multipart
parallel
Unterschied zu Mixed: Hier ist keine Ordnung deniert
qlternative
Alternative Versionen derselben Information
digest
Wie
Mixed,
aber
als
Default-Typ/Subtyp
wird
Messa-
ge/rfc822 angenommen
rfc822
Der Body der Nachricht ist selbst eine E-Mail
partial
Zeigt eine Fragmentierte E-Mail an
external-body
Pointer auf ein Objekt, das woanders liegt
jpeg
JPEG-Format, JFIF-Encodierung
gif
GIF-Format
video
mpeg
Video im MPEG-Format
audio
basic
Einkanal 8 Bit ISDN, 8kHz
postscript
Adobe Postscript
message
image
application
octet-stream
Binärdaten aus 8-bit-Bytes
Tabelle 1: Standardisierte MIME-Datentypen
Base64 -Codierung. Die einzelnen Teile werden durch einen eindeutigen Separator, der hinter boundary=
mit Umlauten in
quoted-printable -Codierung,
und einer MS-Word-Datei als binärem Anhang in
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 Abb. 3 die
Wurzel multipart/mixed, und unter dieser Wurzel hängen die beiden Blätter text/plain (der E-MailText) 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 Abb. 3 charset=iso-88591), und das Ende einer Zeile muss durch die 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.
An das jeweilige Transportsystem angepasst werden müssen die Transportcodierungen. Im E-MailBereich 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.
6
25. September 2013
2 Sichere E-Mail
Date: Mon, 5 Mai 2008 11:25:37 (GMT)
From: PC113 <pc113@netz1.test>
Subject: MIME
Mime-Version: 1.0
Content-Type: multipart/mixed;
boundary="----_=_NextPart_000_01BDCC1E.A4D02412"
Content-Length: 817808
Hier kann eine Fehler- oder Warnmeldung stehen, die nur von nicht-MIMEfaehigen Clients dargestellt wird.
------_=_NextPart_000_01BDCC1E.A4D02412
Content-Type: text/plain; charset="iso-8859-1"
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
pc113
------_=_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.A4D02412-Abbildung 3: MIME-E-Mail, bestehend aus MIME-Header, ASCII-Fehlertext, dem eigentliche Text in quoted-printable-Codierung,
und einem (gekürzten) base64-Attachment einer Binärdatei
2.3 Secure/MIME
Der Standard Secure/MIME erweitert die MIME-Datentypen um Konstrukte für signierte und verschlüsselte Nachrichten (siehe Tabelle 3). Er ist im Wesentlichen in den RFCs 2311-2315 (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-Algorithmus, als einziger zwingend vorgeschriebener Public-Key-Algorithmus, eine Schlüsselrolle, und die Public Key Cryptography
Standards PKCS#1, PKCS#7 und PKCS#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 betreen die verwendeten kryptographi-
7
25. September 2013
2 Sichere E-Mail
schen Algorithmen und sind in der Tabelle 2 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, ndet 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 Zertikat in die Signatur mit eingebunden
werden können.
Algorithmus
S/MIME Version 2
S/MIME Version 3
vorgeschrieben
vorgeschrieben
optional
Hash
MD5, SHA-1
optional
SHA-1
MD5
Signatur
RSA
DSA
RSA
Public-Key-Verschlüsselung
RSA
Die-Hellman (RFC 2631)
RSA
Tabelle 2: Die unterschiedliche Verwendung von kryptographischen Algorithmen in den S/MIME Versionen 2 und 3
2.3.1 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 E-Mail 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. Abb. 4
gibt ein Beispiel für die komfortable Auswertung und Signalisierung von Sicherheitseigenschaften, bei
sehr komplexem Quelltext (Abb. 5).
Abbildung 4: Darstellung einer nach S/MIME signierten E-Mail im Mozilla Thunderbird
Da der S/MIME-Standard überwiegend von der Firma RSA Security Inc. vorangetrieben wurde, stützen sich die vorgeschlagenen Datentypen auch weitgehend auf die von RSA publizierten Public Key
Cryptography Standards (PKCS). 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-Zertikats.
•
PKCS#12: Format zur sicheren Speicherung kryptographischer Schlüssel.
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.
2.3.2 Verschlüsselung
Abb. 6 gibt eine S/MIME-verschlüsselte Nachricht wieder. Sie hat den MIME-Typ
application/pkcs7-mime. 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
8
25. September 2013
2 Sichere E-Mail
Message-ID: <4926E52F.9070608@netz1.test>
Date: Fri, 21 Nov 2008 17:43:27 +0100
From: pc113 <pc113@netz1.test>
Content-Type: multipart/signed; protocol=``application/x-pkcs7-signature``;
micalg=sha1; boundary=``=_server1-1110-1227285767-0001-2``
To: pc115 <pc115@netz1.test>
Subject: test mit einer digitalen Unterschrift
This is a MIME-formatted message. If you see this text it means that your
E-mail software does not support MIME-formatted messages.
--=_server1-1110-1227285767-0001-2
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
...Inhalt...
--=_server1-1110-1227285767-0001-2
Content-Type: application/x-pkcs7-signature; name=``smime.p7s``
Content-Disposition: attachment; filename=``smime.p7s``
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACA...GrHGMKS1MujSelBAAAAAAAAA=
--=_server1-1110-1227285767-0001-2-Abbildung 5: Gekürzter Quelltext zu Abb. 4
der Nachricht benötigten Informationen enthält, und den Beginn der verschlüsselten Nachricht in Hexadezimalnotation.
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üs-
selung des symmetrischen Schlüssels der öentliche Schlüssel aus dem Zertikat Nummer 716 des
angeführten Herausgebers verwendet wurde.
• Key-Encryption-Algorithm :
Der Sitzungsschlüssel wurde mit dem RSA-Algorithmus verschlüs-
selt.
• Encrypted-Key :
Hier steht der mit dem RSA-Algorithmus und dem angegebenen öentlichen
Schlüssel verschlüsselte symmetrische Schlüssel.
• Encryption-Algorithm : Hier steht der verwendete symmetrische Algorithmus (TripelDES im CBCModus) und der Initialisierungsvektor.
• Encrypted-Data :
Hier steht die eigentliche verschlüsselte Nachricht.
Beim Sender wurde diese Nachricht wie folgt generiert: Der Absender teilte seinem S/MIME-fähigen EMail-Client mit, dass die Nachricht an den im To Feld angegebenen Empfänger verschlüsselt werden
soll. Der Client durchsuchte daraufhin seine interne Zertikatsdatenbank, ob ihm ein X.509-Zertikat
vorliegt, das die angegebene E-Mail-Adresse enthält. Fand er keines, so musste er sich erst ein solches
Zertikat beschaen ... und den Absender mit einer Warnmeldung darüber informieren, dass eine
Verschlüsselung nicht möglich ist. War hingegen ein Zertikat vorhanden, so wendete er das in Kapitel
1 beschriebene hybride Verschlüsselungsverfahren an, und zwar mit dem öentlichen Schlüssel, der in
dem passenden Zertikat 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.
9
25. September 2013
2 Sichere E-Mail
Typ
Subtyp
multipart
signed
S/MIME Para- File
meter
Beschreibung
Eine signierte Nachricht in zwei Teilen: Der erste Teil ist die unveränderte Originalnachricht, der zweite
die Signatur (clear-signed)
pkcs7-mime
signed-data
.p7m
Ein signierter S/MIME-Datensatz
pkcs7-mime
enveloped-data
.p7m
Ein
verschlüsselter
S/MIME-
Datensatz
pkcs7-mime
certs-only
.p7c
pkcs7-
-
.p7s
-
.p10
application
Der Datensatz enthält nur X.509Zertikate
signature
pkcs10-
Der Content-Typ des Signaturteils
der multipart/signed-Nachricht
mime
Ein Request zur Generierung eines
Zertikats nach PKCS#10
Tabelle 3: S/MIME-Datentypen
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 Zertikat
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.
2.3.3 Signatur
Zur Signatur einer Nachricht stehen in S/MIME zwei verschiedene Datentypen zur Verfügung:
• application/pkcs-mime, smime-type=signedData.
Der Body der E-Mail besteht aus einem ein-
zigen 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, Zertikate). 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äug vor.
•
Steht vor allen die Integrität und Authentizität der Nachricht im Vordergrund, so muss
10
25. September 2013
2 Sichere E-Mail
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:...
...
Date: Mon, 5 May 2008 10:15:12 +0200
From: PC 113 <pc113@netz1.test>
MIME-Version: 1.0
Subject: S/MIME
Content-Type: application/x-pkcs7mime; name="smime.p7m"
Content-Description: S/MIME Encrypted
Message
MIAGCSqGSIb3DQEHA6CAMIACAQAxgcwwgckCAQ
AwczBtMQswCQYDVQQGEwJERTEcMBoGA1UE
ChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEdMBsGA1
UECxMUVGVsZVNlYyBUcnVzdCBDZW50ZXIx
...
ITAfBgNVBAMTGERldXRzY2hlIFRlbGVrb20gVG
VzdCBDQQICAswwDQYJKoZIhvcNAQEBBQAE
QJtWSHPh+l2D+3UqW0itsjOKE1oyAkAz+wtmH/
u42STjeEYhxKJINThw0rRkHtf07fq7puS5
Abbildung 6: Aufbau einer verschlüsselten S/MIME-Nachricht
application/pkcs-mime, smime-type=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.
Die Generierung einer opaque_signed-Nachricht ist ähnlich wie die einer verschlüsselten Nachricht.
Die verschiedenen Kapselungen sind in Abb. 7 dargestellt.
In Abb. 8 ist eine multipart/signed Nachricht dargestellt. Entfernt man die Transport- und
PKCS#7-Codierung, so kann man die Informationen sehen, die zu Verikation der digitalen Signatur
erforderlich sind:
• Digest-Algorithm :
Hier steht, welcher Hash-Algorithmus zur Bildung des Hashwerts der voran-
gegangenen Teile benutzt wurde.
• Certicates :
Hier beginnt eine Kette von Zertikaten, die zur Verikation benötigt werden: Das
Client-Zertikat wird benötigt, um die Echtheit der Signatur zu verizieren. Das CA-Zertikat
wird benötigt, um die Echtheit des Client-Zertikats zu überprüfen, usw.
• SignerInfo :
Hier steht, aus welchem Zertikat der öentliche Schlüssel zur Überprüfung der Si-
gnatur verwendet werden muss. (Hier das Zertikat mit der Seriennummer 549.)
• Signature :
Hier steht die Signatur der vorangegangenen Teile.
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 Zertikatskette folgen
muss.
11
25. September 2013
3 Header Protection in signierten S/MIME-Nachrichten
Mime-Version: 1.0
Content-Type: application/pkcs-mime, smimeType=signedData
PKCS#7-Version: 1.0
PKCS#7-Header:
Algorithms:
Certificates:
Signature:
Content:
Mime-Version: 1.0
multipart/mixed
text/plain
application/msword
ASCII
Abbildung 7: Struktur einer opaque-signed Nachricht
3.1 S/MIME Einschränkung
In den älteren S/MIME-Spezikationen(bis zu der 3.0 Version inklusive) gab es keinen Header-Schutz.
Der Header-Schutz wurde also erst in der S/MIME 3.1 Spezikation eingeführt.
In der bestehenden S/MIME 3.1 Spezikation wird der Header-Schutz dadurch erreicht, dass man die
ganze Nachricht als ein message/RFC822-MIME-Objekt betrachtet.
Die Header-Felder, die im RFC822 deniert wurden, beinhalten sicherheitskritische Informationen, die
nicht kryptographisch geschützt werden. Die einzigen Ausnahmen sind From und Sender HeaderFelder, denn diese müssen von einem Mail-Agent überprüft werden, solange in dem Sender-Zertikat
eine E-Mail Adresse vorhanden ist. Wenn dieser Vergleich fehlschlägt, ist eine andere Verarbeitung der
E-Mail für den Client vorgesehen (z.B. Anzeige einer ungültigen Signatur). Alle anderen Header-Felder,
wie z.B. To, Date, Reply-To oder Subject können nicht überprüft werden.
Die bestehende S/MIME 3.1 Version erzielt den Schutz von Header-Feldern indem sie alle HeaderFelder, generiert von einem Sender-Mail Client, zusammen mit dem Inhalt der Nachricht in einem
message/rfc822 Objekt einschlieÿt ,welches dann durch S/MIME geschützt werden kann. Es hängt von
dem empfangenden Client ab, wie eine solche Nachricht dem Benutzer präsentiert wird.
Dieses Verfahren hat folgende Nachteile:
•
Alle Header-Felder, die in der inneren Nachricht vorhanden sind, müssen auch in der äuÿeren
Nachricht vorhanden sein (d.h. diese Felder müssen doppelt vorhanden sein), damit die Nachricht
RFC2822 konform ist und damit der Mail-Server und die betroenen Systeme die Nachricht
weiterleiten können.
•
Nur die inneren Header-Felder werden geschützt, nicht die äuÿeren. Wie in (RFC3851) erwähnt,
hängt es von dem empfangenden Client ab. Es ist ihm überlassen, wie die inneren Header-Felder
zusammen mit den ungeschützten äuÿeren Header-Feldern dargestellt werden. Normalerweise
werden folgende, wenn vorhanden, Header-Felder in den Clients angezeigt: From, Sender, To,
CC, Date, und Subject. Falls ein Header-Feld in beiden Headern vorhanden ist, wird das
12
25. September 2013
...
From:
To:
Subject:
Date:
...
MIME-Version: 1.0
Content-Type: multipart/signed;
protocol=”application/x-pkcs7signature“; micalg=SHA-1;
boundary=“boundary”
PKCS#7:
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-Certificat
Certificate:
Client-Certificat (549)
SignerInfos:
SignerInfo:
Serial-Number: 549
...
Signature:
0F:9B:46:5B:....:99:BC:44
...
--boundary
Eigentliche MIME-E-Mail
(ggf. mit Attachments)
--boundary
Content-Type: application/
x-pks7-signature;
name=”smime.p7s“;
Content-Transfer-Encoding:
Base64
MIAGCSqGSIb3DQEH.....Jx9cS
9WPmbxEkAAAA==
--boundary--
Abbildung 8: Aufbau einer clear-signed S/MIME-Nachricht
innere Header-Feld angezeigt. Falls ein Header-Feld nur in dem äuÿeren Header vorhanden ist,
dann wird dieses angezeigt. Viele Nachrichten beihnaltet keine Sender und CC Header-Felder,
demzufolge könnte man diese Header-Felder nachträglich in den äuÿeren Header hinzufügen, um
die Empfänger zu verwirren.
3.2 Header Protection nach dem vom Lehrstuhl NDS entwickelten Mechanismus
Um einen ezienteren Header-Schutz zu erreichen, wurde von dem Lehrstuhl für Netz- und Datensicherheit ein neues Verfahren vorgeschlagen - Header Protection for S/MIME. Diese Methode wird
als Internet Draft in IETF veröentlicht. Im Folgenden nden Sie nur einen Auszug. Für detailierte Information bitte wenden Sie sich an die IETF-Seite
draft-liao-smimeheaderprotect/.
https://datatracker.ietf.org/drafts/
2. S/MIME Header Protection Entity
A smime header protection entity contains names of header fields to
be protected, the canonicalization algorithm, the digest algorithm
and the corresponding digest value.
2.1. Fieldname List
The fieldname-list is a colon-separated list of header field names
that identify the header fields presented to the digest algorithm; it
13
25. September 2013
is defined as follows:
fieldname-list = lowercase-field-name *(":" lowercase-field-name)
lowercase-field-name = field-name in lowercase
The fieldname-list MUST contain the complete list of header fields in
the order presented to the digest algorithm. The field name MUST be
lowercase. The field MAY contain names of header fields that do not
exist when digested; nonexistent header fields do not contribute to
the digest value computation (that is, they are treated as the null
input, including the header field name, the separating colon, the
header field value, and any CRLF terminator).
The fieldname-list is compared against actual header field names in a
case insensitive manner.
Signers choosing to protect an existing header field that occurs more
than once in the message (such as "Resent-From") MUST protect the
physically last instance of that header field in the header block.
Signers wishing to protect multiple instances of such a header field
MUST include the header field name multiple times and MUST protect
such header fields in order from the bottom of the header field block
to the top. The signer MAY include more instances of a header field
name than there are actual corresponding header fields to indicate
that additional header fields of that name SHOULD NOT be added.
...
3.2. SMIME Header Protection
The smime-header-protection attribute type specifies the S/MIME
header protection entity. It MUST be a signed attribute or an
authenticated attribute; it MUST NOT be an unsigned attribute,
unauthenticated attribute, or unprotected attribute in CMS signature.
...
The attrValues of the smime-header-protection attribute contains
only one value that has ASN.1 type SMIMEHeaderProtectionEntity:
SMIMEHeaderProtectionEntity ::= SEQUENCE {
canonAlgorithm
CanonAlgorithmIdentifier,
digestAlgorithm
DigestAlgorithmIdentifier,
headerfieldNames
PrintableString,
digest
Digest
}
The canonAlgorithm field specifies the canonicalization algorithm.
The digestAlgorithm field specifies the digest algorithm. The format
14
25. September 2013
of an headerfieldNames is a "headername-list" field specified in
Section 2.1. The headerfieldNames field specifies the list of
header field names. The digest field carries the the digest value.
4. Creating Signed S/MIME Messages with Header Protection
The signed S/MIME messages with header protection are created same as
in [RFC3851] except the followings:
o Before computing the digest value over the signedAttrs, the
smime-header-protection attribute MUST be prepared (see Section
4.1) and added to the signedAttrs.
o All header fields that are protected MUST be prepared before the
preparing the smime-header-protection.
4.1. Preparing an SMIME-Header-Protection Attribute
An smime-header-protection attribute is prepared as follows:
Step 1. Choose the canonicalization algorithm, the digest algorithm,
and the list of names of message header fields to be digested. The
digest algorithm SHOULD be the same as the digest algorithm in the
SignerInfo which the smime-header-protection attribute should be
added to.
Step 2. Retrieve the message header fields from the message according
to the protected header fields from Step 1.
Step 3. Canonicalize the retrieved header fields from Step 2
according to the canonicalization algorithm.
Step 4. Compute the digest value over the canonicalization result in
Step 3 according to the digest algorithm.
Step 5. Create an smime-header-protection attribute. Store the chosen
canonicalization algorithm, the digest algorithm, and the list of
names from Step 1 in ASN.1 fields canonAlgorithm, digestAlgorithm,
and headerfieldNames, respectively. Store the digest value from Step
4 in the ASN.1 field digest.
5. Verifying Signed S/MIME Message with Header Protection
The signed S/MIME message with header protection are verified first
same as in [RFC3851], then the smime-header-protection attribute is
verified as stated in Section 5.1.
5.1. Verifying an SMIME-Header-Protection Attribute
15
25. September 2013
4 Programme
An smime-header-protection attribute is verified as follows:
Step 1. Retrieve the canonicalization algorithm, the digest
algorithm, and the list of names of message header fields, and the
digest value from the smime-header-protection attribute.
Step 2. Retrieve the message header fields from the message according
to the protected header fields from Step 1.
Step 3. Canonicalize the retrieved header fields from Step 2
according to the canonicalization algorithm.
Step 4. Compute the digest value over the canonicalization result in
Step 3 according to the digest algorithm.
Step 5. Compares the computed digest value from Step 4 and the stored
one from Step 1. If both digest values are different, then the
verification fails; otherwise the verification successes.
4 Programme
In diesem Versuch werden SeaMonkey (Browser, Mail & Newgroups), Thunderbird mit Header-ProtectErweiterung (siehe Kapitel 4.2), und MITM-Programm (siehe Kapitel 4.3) benutzt.
4.1 SeaMonkey
Durch Start-Menü
Internet -> Seamonkey (bin) wird das Programm SeaMonkey Browser gestartet.
Window -> Mail & Newsgroups starten.
Sie können den SeaMonkey Mail-Client durch das Menü
4.2 Thunderbird mit Header-Protect-Erweiterung
2
Das Programm Thunderbird mit Header-Protection-Erweiterung
wurde im Lehrstuhl NDS entwi-
ckelt. Es bendet sich unter dem Verzeichnis /home/praktikum/EmailSicherheit/thunderbird und kann
thunderbird gestartet werden. Bitte beachten Sie, dass durch
Mozilla Thunderbird (bin) das andere Thunderbird gestartet wird.
durch die durchführbare Datei
Menü
Internet
->
Start-
Das Thunderbird (HPE) kann E-Mails mit Header-Protection signieren und verzieren. Die HeaderProtection-Erweiterung für das Senden signierter E-Mails können Sie aktivieren bzw. deaktivieren und
einstellen: Menü
Edit
>
Preferences
>
HeaderProtect
(Siehe die Screenshots in Abb. 9).
4.3 MITM-Programm
Für diesen Versuch wurde ein MITM-Programm im Lehrstuhl NDS entwickelt. Dieses MITM-Programm
bendet sich unter dem Verzeichnis /home/praktikum/EmailSicherheit/mitm und kann durch die
durchführbare Datei
2
mitm
gestartet werden. Es hat folgende Syntax:
zur Vereinfachung wird Thunderbird mit Header-Protection-Erweiterung im Rest dieser Beschreibung durch Thunderbird (HPE) bezeichnet.
16
25. September 2013
4 Programme
Abbildung 9: Konguration von Header-Protection in Thunderbird (HPE)
This program is only for use in the NDS Netlab!
Usage: mitm [OPTION VALUE]
OPTION
VALUE-TYPE (Options with * are required)
-i/-I Ethernet Device (DEFAULT: eth0)
-s/-S Source IP Address (IPv4) *
-d/-D Destination IP Address (IPv4) *
-p/-P Transport Protocol (DEFAULT: tcp)
-n/-N Destination Port Number (DEFAULT: 80)
-l/-L Delay between ARP-Packets in Seconds (DEFAULT: 10)
-r/-R Modification: Direction {BOTH/FORTH/BACK} (DEFAULT: BOTH)
-f/-F Modification: Search String (REGEXP) *
-t/-T Modification: Replace String *
-?
This Help
Ein Beispiel:
mitm -s 192.168.1.12 -d 192.168.1.11 -n 25
-f "Subject: test" -t "Subject: TEST"
Das MITM-Programm mit den oben gegebenen Parametern ersetzt die Zeichenkette Subject: test
durch Subject: TEST in allen E-Mails, die von 192.168.1.12 (Mail Client) nach 192.168.1.11 (Mail
Server) mit dem Protokoll SMTP gesendet werden. Damit wird der Betre einer E-Mail von test
nach TEST geändert.
Die gesuchte Zeichenkette kann auch eine reguläre Darstellung (RegExp) sein. Die folgende RegExpDarstellung ist für die
Date-Zeile:
Date:[ a-zA-Z0-9.:,;?=<>+-@]*
Und das folgende Kommando ändert das Absendedatum einer E-Mail.
mitm -s 192.168.1.12 -d 192.168.1.11 -n 25 -r f
17
25. September 2013
5 Versuche
-f "Date:[ a-zA-Z0-9.:,;?=<>+-@]*"
-t "Date: Fri, 14 Nov 2008 14:14:14 +0100"
Hinweise: Falls das geänderte Paket die maximal erlaubte Länge überschreitet, funktioniert das vorhandene MITM-Programm leider nicht mehr. Falls sich der Versand einer E-Mail verzögert, bitte
korrigieren Sie die Ersatzzeichenkette, so dass sie nicht länger als die gesuchte Zeichenkette ist.
5 Versuche
5.1 Netzwerkkomponenten
Alle Mail Server sind als SMTP- und IMAP-Server konguriert.
•
Gruppe 0 (in Subnetz 0):
•
Clients: pc012, pc013, pc014, pc015.
∗
Konto: pcxxx (wobei xxx ein Platzhalter ist)
∗
E-Mail-Adresse: pcxxx@netz0.test
∗
Passwort: pcxxx
Gruppe 1 (in Subnetz 1: Rechner pc112, pc113, pc114):
•
Mailserver: server0.netz0.test
Clients: pc112, pc113, pc114.
∗
∗
∗
Passwort: pcxxx
Gruppe 2 (in Subnetz 2):
Clients: pc212, pc213, pc214, pc215.
∗
∗
∗
Passwort: pcxxx
5.2 Ohne MITM-Angrie
5.2.1 Aufgabe 1: Kongurieren Sie Ihren E-Mail-Client SeaMonkey
Kongurieren Sie Ihren Mozilla SeaMonkey E-Mail-Client mit der E-Mail-Adresse pcZXY@netzZ.test
nach der im Kapitel 5.1 denierten Struktur.
Önen Sie mit dem SeaMonkey-Browser http://pc111.netz1.test und importieren Sie zunächst das
Zertikat Ihrer CA. Beantragen Sie dann ein Zertikat für Ihre E-Mail-Adresse. Kongurieren Sie
dieses Zertikat in Mozilla SeaMonkey Mail.
Versuchsauswertung:
Screenshot der Detailansicht des geladenen Zertikats. Screenshot der Sea-
Monkey Mail-Konguration.
18
25. September 2013
5 Versuche
Hinweis:
Um die Zertikate anderer Personen identizieren zu können, müssen die entsprechende
Vertrauenseinstellungen in dem Zertikat-Manager angekreuzt werden (Zertikat-Manager -> Zertizierungsstellen -> Ihre CA auswählen -> bearbeiten).
5.2.2 Aufgabe 2: Senden einer signierten E-Mail an Mailadressen in ihrer Gruppe
Senden Sie eine signierte E-Mail an alle Mailadressen in ihrer Gruppe. Ist diese Clear-Signed oder
Opaque-Signed?
Versuchsauswertung:
Relevante Ausschnitte der PKCS#7-Struktur der Mails, jeweils mit Erläute-
rungen.
Anmerkung: Zur Darstellung der PKCS#7-Struktur einer Mail gehen Sie wie folgt vor:
•
Speichern Sie die E-Mail als Datei (File (bzw. Datei)->Save As->File).
•
Starten Sie eine Konsole und führen Sie folgendes Kommando aus:
xmail <Email-Datei> <Ziel Verzeichnis>.
•
Analysieren Sie die resultierende XMaiL.
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 Identier unter
http://asn1.elibel.tm.fr/oid/index.htm näher.
Hinweis:
Object Identier (OID) ist ein weltweit eindeutiger Bezeichner, der benutzt wird, um ein
Informationsobjekt zu benennen. Zum Beispiel:
XMail-Quelltext: <DigestAlgorithm Algorithm=1.3.14.3.2.26/>
Bedeutung: 1.3.14.3.2.26 - Hash algorithm identier SHA-1 (Secure Hash Algorithm, Revision 1)
5.2.3 Aufgabe 3: Senden einer verschlüsselten Nachricht
Senden Sie eine verschlüsselte E-Mail an eine Mailadresse in ihrer Gruppe. Ist das ohne Probleme
möglich?
Versuchsauswertung:
Relevante Ausschnitte der PKCS#7-Struktur der Mails, jeweils mit Erläute-
rungen.
5.3 Mit MITM-Angrien
Ab jetzt müssen alle Teams in einer Gruppe zusammen arbeiten. Zu Beginn wird jedem Team eine der
Rollen (Empfänger, Sender oder MITM-Angreifer) zugeordnet. Jedes Team muss anschlieÿend alle der
Rolle zugeordneten Aufgaben abarbeiten. Anschlieÿend werden die Rollen unter den Teams rotieren,
bis schlieÿlich jedes Team einmal jede Rolle gespielt hat.
5.3.1 Aufgabe 5: Kongurieren Sie Ihren E-Mail-Client Thunderbird (HPE)
Kongurieren Sie ihren E-Mail-Client Thunderbird (HPE) wie SeaMonkey in Aufgabe 1.
Versuchsauswertung: nicht nötig in dieser Aufgabe.
19
25. September 2013
5 Versuche
5.3.2 Aufgabe 6: Senden einer signierten Nachricht mit SeaMonkey
Der Sender sendet mehrere signierte E-Mails an den Emfänger. Der Angreifer soll das Header-Feld
Subject während des Absendens ändern. Der Empänger soll dann die Signatur verizieren (einmal in
SeaMonkey und einmal in Thunderbird (HPE)).
Versuchsauswertung (Zum Ansehen des Quelltextes einer Nachricht: Menü View > Message Source):
•
Für den Sender: Message-ID und Titel (Subject) der Nachricht.
•
Für den MITM-Angreifer: Gesuchte Zeichenkette (RegExp) und Ersetzte Zeichenkette.
•
Für den Empfänger: Message-ID und Titel (Subject) der Nachricht. Die Gültigkeit der Signatur
in SeaMonkey und in Thunderbird (HPE).
5.3.3 Aufgabe 7: Senden einer signierten Nachricht mit Thunderbird (HPE)
Wie in Aufgabe 6, aber der Absender soll signierte E-Mails mit Thunderbird (HPE) abschicken.
Der Sender soll sicherstellen, dass die Header-Protection-Funktion aktiviert ist und die vordenierte (Default) Fieldname List benutzt wird.
Hinweis: Sie können Aufgabe 6 und 7 auch kombiniert durchführen. Dazu muss der Sender jeweils eine
signierte Mail mit Seamonkey und eine mit Thunderbird HPE versenden. Der Angreifer muss beide
Mails verändern und der Empfänger muss
beide Mails jeweils mit beiden Clients verizieren.
20
25. September 2013

E-Mail Sicherheit1 - Ruhr

Transcription

Similar documents

Auslösekennlinien einstellungsspezifisch darstellen

Cellopoint Anti

New Title - Deutsche Messe

G Data Business

1 Prozessbeschreibung / technischer Vorgang der

there will be blood - Akademie der Bildenden Künste München

MIMEsweeper™ Email Appliance FACTSHEET