Sichere E-Mail-Verteiler: Ein praxisorientierter Ansatz

Sichere E-Mail-Verteiler: Ein praxisorientierter Ansatz
Jens Hasselbach
Fraunhofer AEMT – Security for Virtual Goods
Langewiesener Str. 22
98693 Ilmenau
[email protected]
Abstract: Der Nachrichtenverkehr innerhalb von vielen Unternehmen wird zu
einem großen Teil über Mailinglisten abgewickelt. Um die Vertraulichkeit
sensibler Daten zu gewährleisten, ist es notwendig, die Nachrichten zu
verschlüsseln. Ziel dieses Papiers ist es, existierende Konzepte für sichere E-MailVerteiler zu diskutieren und unter Verwendung von zeitgemäßen Technologien
umzusetzen. Ein wichtiger Punkt hierbei ist die Nutzerfreundlichkeit. Es wird ein
System vorgestellt, welches bei minimalem Aufwand auf der Nutzerseite ein hohes
Maß an Sicherheit gewährleistet.
1 Einleitung
Der Datenaustausch mittels E-Mail ist unsicher. Die grundsätzlichen Sicherheitsziele,
Vertraulichkeit und Authentizität, können durch Verschlüsselung und Signierung des
Nachrichtenverkehrs erreicht werden.
•
Vertraulichkeit: Die Nachricht kann nur von dem tatsächlichen Adressaten
gelesen werden. Dies wird durch Verschlüsselung erreicht.
•
Authentizität: Die Nachricht wurde während des Transports nicht verändert
und der Absender ist eindeutig authentifizierbar. Dies wird durch den Einsatz
von Signaturen erreicht.
Gebräuchlich hierfür sind hybride Verfahren, welche symmetrische und asymmetrische
Algorithmen kombinieren (Public Key Kryptografie). Die vorliegende Arbeit beschäftigt
sich mit der Fragestellung, wie die genannten Sicherheitsziele mit der Funktionalität von
E-Mail-Verteilern zu vereinbaren sind, unter der Zielvorgabe, Sicherheit mit
Nutzerfreundlichkeit zu verbinden. Der Aspekt der Nutzerfreundlichkeit ist besonders zu
berücksichtigen, da hiervon zu einem großen Teil die praktische Umsetzbarkeit in einem
realen Umfeld abhängt.
91
Um eine Lösung zu erarbeiten, werden zunächst verschiedene E-Mail-Standards für den
sicheren Nachrichtenaustausch hinsichtlich wichtiger Kriterien, wie z.B. verwendeter
Algorithmen und Unterstützung von Public Key Kryptografie Standards, untersucht. Im
Anschluss daran werden verschiedene Konzepte diskutiert, um sichere Mailinglisten zu
realisieren. Ausgehend von den erarbeiteten Konzepten wird dann eine
Beispielimplementierung vorgestellt.
2 Wahl eines sicheren E-Mail-Standards
Folgende Auswahlkriterien für den zu verwendenden E-Mail-Standard sind zu
berücksichtigen:
(1) Sicherheit: Die verwendeten kryptografischen Algorithmen müssen den
derzeitigen Sicherheitsanforderungen entsprechen, bzw. bei Bedarf flexibel
austauschbar/anpassungsfähig sein.
(2) Nutzerfreundlichkeit: Die Benutzer sollen ihre bisherigen E-Mail-Clients weiter
verwenden können (z.B. Microsoft Outlook (Express), Netscape/Mozilla
Messenger).
(3) Integrationsfähigkeit in bestehende Public-Key-Infrastrukturen: Public Key
Kryptografie Standards (PKCS) müssen unterstützt werden.
PEM (Privacy Enhancement for E-Mail)
PEM ist der älteste Standard für sichere Mail und gilt sowohl im Allgemeinen als auch
hinsichtlich der verwendeten kryptografischen Algorithmen als veraltet. Nachrichten im
PEM-Format sind nicht MIME (Multipurpose Internet Mail Extensions)-konform
[FB96], stattdessen definiert PEM eine eigene Syntax für die Aufteilung einer Nachricht.
PEM unterstützt nur X.509v1-Zertifikate und wird weder von Microsoft Outlook, noch
vom Netscape/Mozilla Messenger unterstützt. Der Einsatz von PEM ist deshalb aus den
genannten Gründen nicht sinnvoll. Als Alternativen bieten sich prinzipiell OpenPGP und
S/MIME an. [Sc01]
S/MIME (Secure MIME) im Vergleich zu OpenPGP (Pretty Good Privacy)
Aus kryptografischer Sicht unterscheiden sich OpenPGP und S/MIME nur unwesentlich.
Die von den beiden Standards verwendeten Algorithmen sind vergleichbar stark. Die
Hauptunterschiede liegen beim Vertrauensmodell, der Unterstützung für PKC-Standards
und der Verfügbarkeit von E-Mail-Client-Software. OpenPGP benutzt als
Vertrauensmodell das „Web of Trust“, welches prinzipiell auf dem gegenseitigen
Vertrauen der Benutzer untereinander basiert. Dieses Modell ist für die Anwendung in
einem größeren Unternehmen kaum geeignet. S/MIME hingegen benutzt das
hierarchische Vertrauensmodell, welches für die Integration in eine bestehende
(Unternehmens)-PKI vorteilhaft ist. S/MIME baut ausschließlich auf bestehende
Standards der Public Key Kryptografie (PKCS) auf, während OpenPGP für Nachrichten
und Zertifikate eigene Formate definiert.
92
Bei den Microsoft und Netscape/Mozilla E-Mail-Clients (sowie bei vielen weiteren
kommerziellen Produkten) gehört S/MIME-Unterstützung (im Gegensatz zu OpenPGPUnterstützung) zum Funktionsumfang, d.h. auf der Client-Seite ist keine zusätzliche
Software notwendig. Interessant sind auch die Features für sichere Mailinglisten (ESSEnhanced Security Services for S/MIME [Ho99]), welche in S/MIME Version 3
spezifiziert sind. Zusammenfassend empfiehlt sich unter Berücksichtigung der
genannten Punkte die Verwendung von S/MIME als E-Mail-Standard. [Sc01]
3 S/MIME
Der MIME-Standard [FB96] spezifiziert ein Format für den Inhalt von E-Mails. Er
erlaubt die zuverlässige Übertragung von Binärdaten und Sonderzeichen mittels
spezieller Kodierungen (z.B. Base64). Der Inhalt einer MIME-Nachricht kann aus
mehreren (auch verschachtelten) Teilen zusammengesetzt sein, welche auf der
Empfängerseite eindeutig getrennt werden können.
Der S/MIME-Standard definiert zusätzliche MIME-Content-Typen (siehe Tabelle 1) für
die Verschlüsselung und Signierung von Nachrichten. Ein verschlüsselter/signierter
MIME-Part wird in einem CMS-Objekt (Cryptographic Message Syntax) gekapselt. Die
von der CMS verwendeten Strukturen werden in der ASN.1 (Abstract Syntax Notation)
beschrieben. [Ra99]
S/MIME type parameter
File
Extension
(x)-pkcs7-mime
signed-data
.p7m
Application
(x)-pkcs7-mime
enveloped-data
.p7m
Application
(x)-pkcs7-mime
certs-only
.p7c
application
(x)-pkcs7-signature
application
(x)-pkcs10-mime
MIME type
MIME subtype
Multipart
Signed
Application
.p7s
Tabelle 1: S/MIME Typen [Ra99]
S/MIME – Unverschlüsselt und signiert
Bei signierten S/MIME-Nachrichten ist zwischen clear-signed Messages und opaquesigned Messages zu unterscheiden.
93
•
Clear-signed Messages bestehen aus einem Klartext-Teil und einem CMSObjekt welches die Signatur enthält. Eine solche Nachricht ist vom Typ
„multipart/signed“. Das CMS-Objekt ist vom Typ „application/pkcs7signature“. Es beinhaltet das Public-Key-Zertifikat des Absenders, Algorithm
Identifiers und die Signatur. Zusätzlich kann das CMS-Objekt weitere
Zertifikate z.B. einer CA enthalten, welche das Public Key Zertifikat des
Absenders signiert hat.
•
Bei opaque-signed Messages ist zusätzlich zu den oben genannten Daten auch
der Klartext im CMS-Objekt gekapselt, so dass der Inhalt der Nachricht nur von
S/MIME-kompatiblen E-Mail-Clients angezeigt werden kann. Der Klartext
kann auf diese Weise vor einer Veränderung durch Message Transfer Agents,
z.B. durch Änderung der Codierung, geschützt werden. Das CMS-Objekt hat in
diesem Fall den Typ „application/pkcs7-mime“ mit dem zusätzlichen Parameter
„signed-data“. [Ra99]
S/MIME – Verschlüsselt und unsigniert
Bei einer verschlüsselten Nachricht ist der symmetrisch verschlüsselte Text, der
asymmetrisch verschlüsselte Session Key, Algorithm Identifiers und der Public Key des
Absenders in einem CMS-Objekt gekapselt (Typ: „application/pkcs7-mime“, Parameter:
„enveloped-data“). Diese Art der Nachricht gewährleistet zwar die Vertraulichkeit,
liefert aber keinen eindeutigen Nachweis der Identität des Absenders und der
Authentizität der Nachricht. Der verschlüsselte Text kann (unter Benutzung des
öffentlichen Schlüssels des Empfängers) beliebig ausgetauscht werden. [Ra99]
Der Aufbau eines Enveloped-Data-Objects (S/MIME type „enveloped-data“) ist in
Abbildung 1 dargestellt:
•
EnvelopedData
version
recipientInfos
•
encryptedContentInfo
recipientInfos:
Per-recipient information
(several recipients possible) including
the encrypted symmetric key
encryptedContent:
encrypted MIME entity
contentType
contentEncryptionAlgorithm
encryptedContent
Abbildung 2: ASN.1 Struktur des EnvelopedData Content Type [Ra99]
94
S/MIME – Verschlüsselt und signiert
Prinzipiell ist es möglich, S/MIME-Entities beliebig zu verschachteln. Gebräuchlich ist
die Methode, Nachrichten zuerst zu signieren und dann zu verschlüsseln. Eine solche
Nachricht unterscheidet sich äußerlich nicht von einer verschlüsselten und unsignierten
Nachricht. Nur der Empfänger ist in der Lage festzustellen, ob die Nachricht signiert ist,
bzw. die Signatur zu prüfen.
Für die Umsetzung sicherer Mailinglisten ist in diesem Zusammenhang das in [Ho99]
beschriebene „Triple Wrapping“ zu erwähnen. Hierbei wird eine Nachricht erst signiert,
dann verschlüsselt und dann nochmals signiert. Die Austeller der Signaturen können
hierbei verschieden sein. Die innere Signatur gewährleistet die Integrität und die
Authentizität des eigentlichen Inhaltes der Nachricht. Die äußere Signatur („outside
signature“) sichert Integrität und Authentizität von Informationen, welche von
verschiedenen Zwischenstationen (z.B. durch Mailverteiler) bearbeitet bzw. hinzugefügt
wurden. Diese Informationen können dann z.B. für Zugriffskontrolle und Filterung
benutzt werden. [Ho99]
S/MIME – Kryptografische Verfahren
Die von S/MIME verwendeten kryptografischen Verfahren sind in Tabelle 2 dargestellt.
Must
Should
Hash Functions
SHA-1 (Secure Hash Standard)
MD5 (Message Digest
Algorithm)
Digital Signatures
DSS (Digital Signature Standard)
RSA (Rivest Shamir
Adleman)
Content Encryption
tripleDES (Data Encryption
Standard)
RC2 (Rivest Cipher)
Key Encryption
DH (Diffie-Hellmann)
RSA (Rivest Shamir
Adleman)
Tabelle 2: S/MIME – Kryptografische Verfahren [Ra99]
95
4 Konzepte für verschlüsselte E-Mail-Verteiler
Ein übliches Verfahren um Nachrichten innerhalb eines definierten Personenkreises
auszutauschen, ist der Einsatz von Mailinglisten. Um die genannten Sicherheitsziele
(primär Vertraulichkeit) mit den Anforderungen einer Mailingliste zu kombinieren, sind
die in RFC1421 [Li93] genannten Methoden anwendbar:
•
Interchange-Key-Per-Recipient-Methode: Jedes Mitglied der Mailingliste kennt
und verwaltet die Zertifikate der anderen Mitglieder. Diese Methode ist nicht
praktikabel, da die individuelle Verschlüsselung für alle Mitglieder der
Mailingliste von jedem Mitglied durchgeführt werden muss und dadurch der
Verwaltungsaufwand für die Zertifikate für jedes einzelne Mitglied sehr hoch
ist. Durch die dezentrale Verwaltung der Zertifikate ist die Gewährleistung der
Konsistenz schwierig.
•
Interchange-Key-Per-List-Methode: Ein Schlüsselpaar wird von allen
Mitgliedern der Mailingliste gemeinsam benutzt. Der Hauptnachteil dieser
Methode ist der hohe Aufwand für ein konsistentes Zertifikatsmanagement,
speziell für den Fall, dass Mitglieder die Liste verlassen. In diesem Fall müssten
die Schlüsselpaare aller restlichen Mitglieder erneuert werden, um die
Vertraulichkeit weiterhin zu gewährleisten. Ein weiterer Nachteil ist die NichtUmsetzbarkeit des Authentizitätsnachweises.
•
Hybrid-Methode: Jedes Mitglied der Mailingliste, sowie die Mailingliste
selbst besitzt ein eigenes Schlüsselpaar. Jedes Mitglied der Liste verfügt über
den Public Key der Mailingliste. Die Mitglieder der Liste verschlüsseln ihre
Nachrichten (genauer: den jeweiligen Session Key, mit dem die Nachricht
verschlüsselt wird) mit dem Public Key der Mailingliste und signieren mit
ihrem eigenen Private Key. Die Mailingliste nimmt nun eine
„Umverschlüsselung“ vor, d.h. der jeweilige Session Key wird mit dem Private
Key der Mailingliste entschlüsselt und mit den Public Keys aller Mitglieder
verschlüsselt. Der Nachteil dieser Methode ist, dass es für den Mailverteiler
theoretisch möglich ist, alle Nachrichten „mitzulesen“. Um dieses Problem zu
entschärfen, kann das Konzept der Aufgabenteilung („Separation of Duty“),
welches Herfert in [He97] vorstellt und im Folgenden erläutert wird, verwendet
werden.
96
Separation of Duty
Um die kryptografischen Abläufe des „Separation of Duty“-Konzepts darzustellen,
werden folgende Notationen eingeführt:
U:
Besitzer eines Schlüsselpaars
Encryption mittels Public Key von U
EU :
DU :
Decryption mittels Private Key von U
Signature (Encryption mittels Private Key von U)
SU :
VU :
Verification (Decryption mittels Public Key von U)
Cdek : Encryption mittels eines symmetrischen Verfahrens
C-1dek : Decryption mittels eines symmetrischen Verfahrens
A:
Absender, Mitglied der Mailingliste
B, C, D: Andere Mitglieder der Mailingliste
M:
Mailingliste
dek = Session Key (symmetrischer Schlüssel, „Data Encrypting Key“)
cipher_text = Cdek(clear_text); C benutzt dek als Schlüssel
signature = SA(h(clear_text)); h ist eine Hash-Funktion
Beispiele:
• Signed: smsg = (clear_text, signature)
• Encrypted: emsg = (EM(dek), Cdek(clear_text))
• Signed and encrypted (siehe Abb. 2): semsg = (EM(dek), Cdek(smsg))
Um das „Mitlesen“ der Nachrichten durch den E-Mail-Verteiler zu erschweren bzw. zu
verhindern, schlägt Herfert in [He97] vor, zwei lokal/organisatorisch getrennte
Komponenten einzusetzen: MDC (Mail Distribution Center) und KMC (Key
Management Center). Nur das KMC verfügt über den Private Key der Mailingliste.
MDC empfängt die Nachricht eines Mitglieds der Mailingliste. Der verschlüsselte
Session Key wird vom Rest der Nachricht getrennt und an KMC gesendet. KMC
entschlüsselt den Session Key und führt die „Umverschlüsselung“ für jedes Mitglied der
Mailingliste durch. Die derart neu verschlüsselten Session Keys werden dann an MDC
gesendet. MDC fügt die „neuen“ Session Keys wieder mit dem Rest Nachricht
zusammen und sendet die Nachricht an die Mitglieder der Liste (siehe Abb. 2). Auf diese
Weise ist es weder für MDC, noch für KMC möglich, den Inhalt der Nachrichten zu
entschlüsseln, da das KMC zwar (zwischenzeitlich) über den unverschlüsselten Session
Key, aber nicht über den verschlüsselten Inhalt verfügt. Das MDC hingegen verfügt
zwar über den verschlüsselten Inhalt, nicht aber über den unverschlüsselten Session Key.
97
Optional kann eine „outside signature“ erstellt werden (Realisierung des in Kapitel 3
beschriebenen „Triple Wrapping“). Dieser Signierungsvorgang könnte vom KMC
durchgeführt werden (siehe Abb. 2), nachdem der Hash-Wert der „umverschlüsselten“
Nachricht von MDC berechnet und an KMC gesendet wurde. Das Zusammenfügen der
neu erstellten Signatur mit der Nachricht könnte dann von MDC realisiert werden.
Alternativ könnte der Signierungsvorgang, unter Verwendung eines ausschließlich für
diesen Zweck bestimmten privaten Schlüssels, von MDC durchgeführt werden.
EM(dek)
EM(dek)
DM
Cdek(smsg)
dek
EB, EC, ED
EB(dek)
EB(dek)
Cdek(smsg)
„Outside Signature“ (optional)
hash
SM(hash)
SM(hash2)
EB(dek)
Cdek(smsg)
Abbildung 3: Kryptografischer Ablauf für eine verschlüsselte Nachricht
98
Fazit
Um sowohl die Vertraulichkeit als auch die Authentizität der Nachrichten innerhalb der
Mailingliste zu gewährleisten, sollten von den Benutzern verschlüsselte und signierte
S/MIME-Nachrichten verwendet werden. Die Problematik der individuellen Verschlüsselung für verschiedene Empfänger wird durch das zentrale „Umverschlüsseln“
durch den E-Mail-Verteiler gelöst. Das „Separation of Duty“-Konzept verhindert das
„Mitlesen“ des Inhaltes der Nachrichten durch den E-Mail-Verteiler. Nach der
Entschlüsselung kann der Empfänger mit dem in der S/MIME-Nachricht enthaltenen
Public-Key-Zertifikat die Signatur des Absenders - und damit die Integrität des Inhaltes
der Nachricht und dessen Authentizität - prüfen.
5 Implementierung
Überblick über verwendete Technologien
Gegenüber der in [He97] vorgestellten Lösung, welche als E-Mail-Standard PEM und
als Implementierungssparche C verwendet, wird im Folgenden eine Implementierung
vorgestellt, welche zeitgemäße Technologien verwendet und in einem aktuellen
Anwendungskontext eingesetzt wird. Die Implementierung des Systems erfolgt mit
Komponenten der Java 2 Platform (SE 1.4)20. Die kryptografischen und S/MIMEspezifischen Funktionalitäten werden unter Verwendung der Bouncy Castle Library
(Version 1.18)21 realisiert. Zur Speicherung der persistenten Daten dient ein MySQL
Datenbank Server22, welcher auf demselben Server wie das KMC laufen kann (siehe
Abb. 2). Die Verwaltung der Zertifikate erfolgt auf einem externen Verzeichnisdienst
(Zertifikate Server (DIR)). Der Mail Server befindet sich im Idealfall auf demselben
Server wie das MDC (siehe Abb. 3). Als Client-Software wird Mozilla23 (ab Version
1.2) eingesetzt.
Anwendungsarchitektur
Die Architektur der Beispielimplementierung besteht aus einer Kombination von Java
Servlets, Java Beans und Java Server Pages (siehe Abb. 3). Die Kernfunktionalität des
Systems wird von Java Beans (KMC) und der MDC-Server-Komponente umgesetzt. Die
Realisierung der Nutzerschnittstelle erfolgt mittels Java Server Pages. Die Interaktionssteuerung wird durch Java Servlets realisiert. Eine sinnvolle Erweiterung der Architektur
für spätere Implementierungen wäre die Integration der MDC-Server-Komponente in
den Mail Server.
20
SUN Java: http://java.sun.com.
Legion of the Bouncy Castle: http://www.bouncycastle.org.
22
MySQL: http://www.mysql.com.
23
Mozilla: http://www.mozilla.org.
21
99
Java Runtime Environment
MDC
Client
Mail
Server
1
2
Server
Server A
3
Java Application Server
KMC
5
DIR
Servlet
Beans
JSP
4
DB
Server B
Abbildung 4: Architektur der Beispielimplementierung
Jedes Mitglied der Mailingliste muss über ein gültiges Schlüsselpaar verfügen und im
Verzeichnisdienst (DIR) erfasst sein (dort sind auch die Zertifikate der Mitglieder
gespeichert). Die Schlüsselpaare werden von der zuständigen Zertifizierungsinstanz
(CA) erstellt. Jedes Mitglied verfügt über das Public-Key-Zertifikat der Mailingliste. Mit
diesem Zertifikat werden die Nachrichten verschlüsselt und mit dem jeweiligen Private
Key signiert. Die Nutzer senden ihre so erstellten Nachrichten an den Mail Server (1).
MDC ruft die Nachrichten vom Mailserver ab (2). Je nach MIME-Type (bzw. Subtype
und S/MIME-Parameter) werden die Nachrichten weitergeleitet bzw. wird das
„Separation of Duty“-Prinzip angewendet:
•
Nicht-S/MIME Nachrichten: unveränderte Weiterleitung
•
MIME-Subtype „signed“: unveränderte Weiterleitung
•
S/MIME-Parameter „signed-data“: unveränderte Weiterleitung
100
•
S/MIME-Parameter „enveloped-data“: MDC extrahiert aus der jeweiligen
Nachricht den verschlüsselten symmetrischen Schlüssel (Session Key) und den
zugehörigen Algorithm Identifier und schickt diese Daten zusammen mit den
Header-Informationen der Nachricht an KMC (3). Die Nachricht wird temporär
auf MDC gespeichert. Um den Session Key aus der Originalnachricht zu
extrahieren wurde die Klasse SMIMEMessage mit den Methoden
getEncryptedSessionKey und getKeyEncryptionAlgorithm implementiert
(analog zu Abb. 1):
import org.bouncycastle.asn1.cms.*;
[…]
this.recipientInfos = envelopedData.getRecipientInfos();
RecipientInfo recipientInfo =
RecipientInfo.getInstance(recipientInfos.getObjectAt(0));
KeyTransRecipientInfo info = (KeyTransRecipientInfo)recipientInfo.getInfo();
this.encryptedSessionKey = info.getEncryptedKey().getOctets();
this.keyEncryptionAlgorithm =
info.getKeyEncryptionAlgorithm().getObjectId().getId();
[…]
KMC ermittelt anhand der Header-Informationen zunächst, welche Mitglieder
für die jeweilige Mailingliste angemeldet sind. Dies geschieht mittels einer
Datenbankanfrage (4). In der Datenbank sind auch die Private Keys der
verschiedenen Mailinglisten gespeichert. Nachdem KMC den verschlüsselten
Session Key entschlüsselt hat, wird dieser mit den vom Verzeichnisdienst
angeforderten Public Keys der Mitglieder verschlüsselt (5). Die Informationen
über die Mitglieder, die Header-Informationen und die neu verschlüsselten
Session Keys werden dann an MDC gesendet (3). MDC ermittelt anhand der
Header-Informationen die passende Nachricht und generiert mittels der neuen
Session Keys (und Recipient Informationen) die entsprechenden Nachrichten
für die Mitglieder. Um aus dem neu erstellten RecipientInfo und dem
verschlüsselten Inhalt der Originalnachricht (EncryptedContentInfo) eine neue
S/MIME-Nachricht (EnvelopedData, siehe Abb. 1) zu erstellen, wurde die
Klasse MimeBodyPartGenerator mit den Methoden getRecipientInfo und
getMimeBodyPart implementiert:
import org.bouncycastle.asn1.cms.*;
import org.bouncycastle.asn1.*;
[…]
RecipientInfo recipientInfo = getRecipientInfo();
KeyTransRecipientInfo keyInf = ((KeyTransRecipientInfo)recipientInfo.getInfo());
DEREncodableVector recipientInfos = new DEREncodableVector();
recipientInfos.add(getRecipientInfo());
DERSet newRecipientInfos = new DERSet(recipientInfos);
EnvelopedData newEnvelopedData = new EnvelopedData(null, newRecipientInfos,
this.encryptedContentInfo, null);
[…]
101
Abschließend werden die Nachrichten an die Mitglieder versendet (2).
6 Zusammenfassung und Ausblick
Verschiedene verteilte Arbeitsgruppen, die über das Internet miteinander verbunden
sind, können über gemeinsame gesicherte E-Mail-Verteiler bequem vertraulich und
integer miteinander kommunizieren. Konkret soll diese Technik für die Kommunikation
zwischen Fraunhofer Arbeitsgruppen an verschiedenen Standorten und angeschlossenen
Projektpartnern außerhalb der Fraunhofer Inhouse-Netze eingesetzt werden. Im
vorliegenden Papier wurde deshalb ein theoretisches Konzept für sichere E-MailVerteiler aus [He97] übernommen, an die Anforderungen für den praktischen Einsatz
angepasst, technisch modernisiert und in einen aktuellen Anwendungskontext eingeführt.
Da auf Nutzerseite kein Aufwand erforderlich ist und Standard-Web-Technologie
eingesetzt wird, kann der Einsatz der erarbeiteten Lösung in den verschiedenen
Kooperationsgruppen zügig erfolgen. Insbesondere aufgrund der Kombination des
datenschutzfreundlichen „Separation of Duty“ - Prinzips mit einem hohen Schutzniveau
und mit minimalem Nutzeraufwand geben wir dieser Lösung eine gute
Zukunftsperspektive. Die Auswertung des praktischen Einsatzes wird in einem späteren
Papier behandelt werden.
Danksagung
Für die Unterstützung beim Schreiben dieses Papiers und bei der praktischen Umsetzung
möchte ich mich bei Prof. Dr. Grimm, sowie bei Katja Franz, Stefan Puchta und Patrick
Aichroth bedanken.
Quellen
[Sc01]
[Ra99]
[He97]
[Ho99]
[FB96]
[Li93]
Schmeh, K.: Kryptografie und Public-Key-Infrastrukturen im Internet, dpunkt-Verlag,
Heidelberg 2001, ISBN 3-93258-90-8.
Ramsdell, B.: S/MIME Version 3 Message Specification , RFC 2633, 1999.
Herfert, M.: Security Enhanced Mailing Lists, IEEE Network Magazine, 1997.
Hoffmann, P.: Enhanced Security Services for S/MIME, RFC2634, 1999.
Freed N., Borenstein N.: Multipurpose Internet Mail Extensions (MIME) Part One:
Format of Internet Message Bodies, RFC2045, 1996.
Linn, J.: Privacy Enhancement for Internet Electronic Mail Part One: Message
Encryption and Authentication Procedures, RFC 1421, 1993.
102