Sichere -Verteiler: Ein praxisorientierter Ansatz

Transkript

1 Sichere -Verteiler: Ein praxisorientierter Ansatz Jens Hasselbach Fraunhofer AEMT Security for Virtual Goods Langewiesener Str Ilmenau 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 - Verteiler 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 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 -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

2 Um eine Lösung zu erarbeiten, werden zunächst verschiedene -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 -Standards Folgende Auswahlkriterien für den zu verwendenden -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 -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 ) 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 -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

3 Bei den Microsoft und Netscape/Mozilla -Clients (sowie bei vielen weiteren kommerziellen Produkten) gehört S/MIME-Unterstützung (im Gegensatz zu OpenPGP- Unterstützung) zum Funktionsumfang, d.h. auf der Client-Seite ist keine zusätzliche Software notwendig. Interessant sind auch die Features für sichere Mailinglisten (ESS- Enhanced 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 -Standard. [Sc01] 3 S/MIME Der MIME-Standard [FB96] spezifiziert ein Format für den Inhalt von s. 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] MIME type MIME subtype S/MIME type parameter File Extension Multipart Signed Application (x)-pkcs7-mime signed-data.p7m Application (x)-pkcs7-mime enveloped-data.p7m Application (x)-pkcs7-mime certs-only.p7c application (x)-pkcs7-signature.p7s application (x)-pkcs10-mime 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

4 Clear-signed Messages bestehen aus einem Klartext-Teil und einem CMS- Objekt welches die Signatur enthält. Eine solche Nachricht ist vom Typ multipart/signed. Das CMS-Objekt ist vom Typ application/pkcs7- signature. 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 -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 contenttype contentencryptionalgorithm encryptedcontent recipientinfos: Per-recipient information (several recipients possible) including the encrypted symmetric key encryptedcontent: encrypted MIME entity Abbildung 2: ASN.1 Struktur des EnvelopedData Content Type [Ra99] 94

5 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

6 4 Konzepte für verschlüsselte -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 Nicht- Umsetzbarkeit 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

7 Separation of Duty Um die kryptografischen Abläufe des Separation of Duty -Konzepts darzustellen, werden folgende Notationen eingeführt: U : Besitzer eines Schlüsselpaars E U : Encryption mittels Public Key von U D U : Decryption mittels Private Key von U S U : Signature (Encryption mittels Private Key von U) V U : Verification (Decryption mittels Public Key von U) C dek : Encryption mittels eines symmetrischen Verfahrens C -1 dek : 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 = C dek (clear_text); C benutzt dek als Schlüssel signature = S A (h(clear_text)); h ist eine Hash-Funktion Beispiele: Signed: smsg = (clear_text, signature) Encrypted: emsg = (E M (dek), C dek (clear_text)) Signed and encrypted (siehe Abb. 2): semsg = (E M (dek), C dek (smsg)) Um das Mitlesen der Nachrichten durch den -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

8 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. E M (dek) C dek (smsg) E M (dek) D M dek E B, E C, E D E B (dek) E B (dek) C dek (smsg) Outside Signature (optional) hash S M (hash) S M (hash2) E B (dek) C dek (smsg) Abbildung 3: Kryptografischer Ablauf für eine verschlüsselte Nachricht 98

9 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 -Verteiler gelöst. Das Separation of Duty -Konzept verhindert das Mitlesen des Inhaltes der Nachrichten durch den -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 -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 Server 22, 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 Mozilla 23 (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: 21 Legion of the Bouncy Castle: 22 MySQL: 23 Mozilla: 99

10 Java Runtime Environment MDC Client 1 Mail 2 Server Server Server A KMC 3 Java Application Server DIR 5 Servlet Beans JSP 4 Server B DB 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

11 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

12 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 -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 - Verteiler 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] Schmeh, K.: Kryptografie und Public-Key-Infrastrukturen im Internet, dpunkt-verlag, Heidelberg 2001, ISBN [Ra99] Ramsdell, B.: S/MIME Version 3 Message Specification, RFC 2633, [He97] Herfert, M.: Security Enhanced Mailing Lists, IEEE Network Magazine, [Ho99] Hoffmann, P.: Enhanced Security Services for S/MIME, RFC2634, [FB96] Freed N., Borenstein N.: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC2045, [Li93] Linn, J.: Privacy Enhancement for Internet Electronic Mail Part One: Message Encryption and Authentication Procedures, RFC 1421,