-
Die
Erfindung betrifft die Verschlüsslung
von elektronisch übermittelten
Nachrichten im Geschäftsverkehr.
-
Für Sicherung
elektronischer Nachrichten in Bezug auf Vertraulichkeit und Integrität wird mit
Erfolg Kyptographie mit Schlüsselpaaren
aus öffentlichen
und privaten Schlüsseln
eingesetzt und ist vielfach ausführlich
beschrieben.
-
Für den Versand
von persönlicher
elektronischer Post (eMail) sind zwei Systeme verbreitet. Zum einen
sind dies die Anwendungen nach dem Standard X.509, wie sie beispielsweise
im Netscape Navigator verfügbar
ist. Zum anderen ist dies der unter dem Acronym PGP bekannte und
u.a. im RFC 2440 spezifizierte Standard. Beide Systeme sind entweder in
die Programme zur Verwaltung elektronischer Post integriert oder über Zusatzmodule
verfügbar.
Dabei sind die Implementationen nach X.509 meist einfacher handhabbar,
weil sie eine feste Zuordnung des Empfängerschlüssels zu der in der Nachricht
benutzten Empfängeradresse
verwenden.
-
In
dem Artikel "Transparent
Internet E-mail Security" von
R. Levien, L. McCarthy, M. Blaze, datiert 1996, erhältlich über 'http://crypto.com/papers/email.pdf', wird beschrieben,
daß die
Verschlüsslung
von eMail auch durch ein zentrales Programm zur Weitervermittlung
erfolgen kann. Dabei wird auch hier der Empfängerschlüssel aus der Emfängeradresse
bestimmt. Es wird automatisch alle ausgehende eMail verschlüsselt, für die ein
Empfängerschlüssel ermittelbar
ist.
-
In
der Offenlegungsschrift
DE
199 24 726 A1 ist ein Verfahren zur vertraulichen Nachrichtenübermittlung
beschrieben, das eine Umschlüsselungszentrale
verwendet, in der sowohl für
den Absender als auch den Empfänger
ein gemeinsamer geheimer Schlüssel
in einer Datenbasis gespeichert ist. Der Absender verschlüsselt eine
Nachricht mit seinem Schlüssel,
schickt die Nachricht einschließlich
Empfängerkennung
an die SVZ, die mit der Empfängerkennung
den Schlüssel
des Empfängers
in der Datenbasis aufsucht, die Nachricht umschlüsselt und an den Empfänger verschickt.
Die Empfängerkennung KE
eindeutig der Identität
des Empfängers
zugeordnet, ohne daß dies
notwendigerweise die digitale Adresse des Empfängers ist.
-
Zwar
wird mittlerweile die Kommunikation via eMail im Geschäftsverkehr
in großem
Umfang genutzt; die Sicherung der Vertraulichkeit dieser teilweise
sensitiven Daten durch die genannten Lösungen erfolgt jedoch nur zögerlich.
Dies ist nicht nur eine Folge der vormals sehr restriktiven Gesetz gebung
in den USA und Frankreich. Vielmehr ergeben sich folgenen Probleme,
zu deren Lösung
die Erfindung beiträgt:
Zum
einen legen die bisherigen Lösungen,
bei denen der Empfängerschlüssel immer
einer auf eine Person bezogenen Empfängeradresse zugeordnet ist,
eine personenbezogene Verschlüsslung
nahe. Geschäftliche
Nachrichten sind zwar häufig
an eine bestimmte Person adressiert, müssen aber bei deren Abwesenheit
auch von einem Stellvertreter bearbeitet werden können. Dies
führt dazu,
daß sich
der Stellvertreter den Systemen gegenüber als adressierter Mitarbeiter ausgibt,
indem beispielsweise dessen Kennwörter benutzt. Dies steht in
direktem Gegensatz zu dem Prinzip, daß ein Kennwort zur Identifizierung
genau einer Person dient. Zwar ist es möglich, die Nachricht so zu
verschlüsseln,
daß sie
von mehreren individuellen Empfängern
entschlüsselt
werden können;
die Stellvertreter sind aber meist dem Absender nicht bekannt. Insbesondere
Verschlüsslungsprogramme nach
X.509 erfordern, daß die
anderen Empfänger
in der Empfängerliste
aufgeführt
sind und damit die Nachricht auch dann erhalten, wenn ihre Stellvertreterfunktion
nicht benötigt
wird.
-
Zum
anderen kommt es gerade duch die Einfachheit der Auswahl eines Empfängers "durch einen Mausklick" dazu, daß vertrauliche
Nachrichten an den falschen Empfänger
geschickt werden. zwar sichert die Verschlüsslung der Nachricht diese
dagegen, daß ein anderer als der angegebene
Empfänger die
Nachricht lesen kann; die herkömmlichen
Lösungen
bestimmen jedoch den Schlüssel
an Hand der Empfängeradresse
und bieten daher keine Sicherheit gegen diese Fehler. Auch ist bei
falscher Auswahl der Empfängeradresse
die psychologisch bedingte Wahrscheinlichkeit hoch, daß auch bei
manueller Zuordnung des Empfängerschlüssels dieser gleichermaßen falsch
ausgewählt
wird.
-
Die
Erfindung benutzt die Beobachtung, daß bei geschäftlichen Nachrichten im Betreff
oder der eigentlichen Nachricht immer auch ein empfängerbezogener
Code, beispielsweise eine Kundennummer, enthalten ist.
-
Die
Lösung
gemäß der Erfindung
verwendet ein solches in der Nachricht enthaltenes Vorgangskennzeichen,
mit dessen Hilfe entweder die Empfängeradresse verifiziert oder
der öffentliche
Schlüssel ermittelt
wird.
-
Es
handelt sich um eine Einrichtung und ein Verfahren zum Versenden
von elektronischen Nachrichten, bei dem aus der Nachricht inhaltsbezogene Vorgangskennzeichen
wie Kunden- oder
Auftragsnummern ermittelt werden und mittels einer Datenbank ein
Abgleich mit der Empfängeradresse
und einem Empfängerschlüssel für die Verschlüsslung der Nachricht
erfolgt.
-
Im
folgenden werden die üblichen
Abkürzungen
verwendet; das sind MUA ('mail
user agent') für ein Zugangsprogramm,
mit dem der Anwender auf seiner Arbeitsstation elektronische Nachrichten
erstelle, versendet und empfängt,
sowie MTA ('mail transfer
agent') für ein Transportprogramm,
welches elektronische Nachrichten von einem MUA oder anderen MTA
empfängt
und an einen weiteren MTA weiterleitet oder in einer Datenbasis
ablegt, aus der der MUA sie abrufen kann. Sowohl der MUA als auch der
MTA versenden und empfangen elektronische Nachrichten, so daß ein Einrichtung
zum Versenden von (elektronischen) Nachrichten sowohl ein MUA als
auch ein MTA sein kann.
-
In
einer ersten Ausführungsform
wird die Erfindung entsprechend dem o.g. Artikel von Levien in einem
MTA eines Servers eingesetzt. In größeren Firmen, die ohnehin über ein
Firewall-System verfügen,
wird der gesamte eMail-Verkehr über
einen solchen zentralen MTA abgewickelt. Dies ist beispielsweise
ein Linux-Server, auf dem das Programm 'sendmail' als MTA eingesetzt wird und den Port
und das Protokoll SMTP bedient. 'sendmail' erlaubt eine Vielzahl
von Parametern und Filtern, so daß die im folgenden beschriebenen
Funktionen integriert werden können.
Alternativ kann auch ein eingenständiges Filter eingesetzt werden,
das entweder den SMTP-Port
oder einen speziellen Port bedient und die Nachrichten dann an den
ursprünglichen
MTA weiterleitet. Eine solcher Filter kann auch auf der Arbeitsstation
des MUA eingesetzt werden, insbesondere wenn ein externer MTA verwendet
wird.
-
Auf
einer Arbeitsstation wird mittels eines beliebigen MUA, beispielsweise
mittels des eMail-Clients 'Netscape
Messenger', an den
MTA eine Nachricht unverschlüsselt übermittelt.
Dieser bzw. der vorgeschaltete Filter bestimmt in einer ersten Ausführungsform
aus den Kopfzeilen zunächst
die Empfängeradresse.
-
Ist
die Empfängeradresse
im eigenen Unternehmen oder Unternehmensbereich und wird für die Übermittlung
die interne, sichere Umgebung nicht verlassen, dann kann die Nachricht
unverschlüsselt weitergesendet
werden.
-
Ist
das Ziel eine Einrichtung, für
die eine kryptographisch sichere Verbindung, z.B. nach RFC 2487, "SMTP Service Extension
for Secure SMTP over TLS",
verwendet wird, dann wird die Nachricht auch in diesem Fall unverschlüsselt weitergeleitet werden.
Durch Optionen kann diese Funktion auch gezielt abgeschaltet werden.
Alternativ kann diese Entscheidung auch der folgenden nachgeordnet
und dann von dem Vorgangskennzeichen abhängig sein.
-
Andernfalls
wird die Nachricht selbst einschließlich der Betreff-Zeile untersucht.
Hierbei wird nach einem Ordnungskriterium, im folgenden als Vorgangskennzeichen
bezeichnet, gesucht. Dies kann ein Aktenzeichen, eine Kunden- oder
Auftragsnummer oder, bei einer Bank, eine Kontonummer sein. Über die
Position bzw. die Art der Kennzeichnung der Position ist je nach
Einsatzfall zu entscheiden. Am einfachsten ist es, daß dieses
Vorgangskennzeichen als erstes im Betreff zu stehen hat, also an
einer festen Position. Eine andere Möglichkeit besteht darin, daß in den
ersten Zeilen der eigent lichen Nachricht ein Bezeichner wie 'Kunden-Nr.', gefolgt von einem Doppelpunkt,
gefolgt von dem Vorgangskennzeichen, steht. Allgemein sind für die Bestimmung
des Vorgangskennzeichens reguläre
Ausdrücke
gut verwendbar.
-
Wird
ein solches Vorgangskennzeichen gefunden, dann wird eine Zuordnung
zu der Empfängeradresse
vorgenommen. Hierzu sind zwei im Detail unterschiedliche, im Endeffekt ähnliche
Vorgehensweisen vorgesehen:
In einer Variante wird über eine
Tabelle oder Datenbank aus dem Vorgangskennzeichen eine Empfängeradresse
bestimmt. Bevorzugt wird eine Datenbank verwendet, die entweder
einen Anschluß an
die ohnehin vorhandene Vorgangsverwaltung des Unternehmens darstellt,
oder, falls dies aus Sicherheitsgründen unerwünscht ist, mit letzterer synchronisiert wird.
Je nach dem Aufbau des Vorgangskennzeichen kann dieses zuvor durch
eine vorbestimmte Transformation in einen Suchausdruck geändert werden;
im einfachsten Fall bestimmen beispielsweise die ersten 9 Stellen
einer Kontonummer den Inhaber, so daß auch nur diese in der Suche
signifikant sind. Die so gefundenen Empfängeradresse wird mit der in
der Nachricht enthaltenen verglichen. Sind sie gleich, wird der
Empfängerschlüssel mittels
einer weiteren entsprechenden Datenbank oder eines öffentlichen Servers
bestimmt und für
die Verschlüsslung
verwendet.
-
Alternativ
wird der Empfängerschlüssel aus der
Datenbank, in der mit dem Vorgangskennzeichen gesucht wurde, entnommen.
In diesem Fall kann auch der Vergleich mit der angegebenen Empfängeradresse
entfallen, da der falsche Adressat die verschlüsselte Nachricht nicht wird
entziffern können. Auch
kann in diesem Fall die Empfängeradresse
leer sein oder, falls der MUA das nicht zuläßt, mit einem Platzhalter wie 'auto@auto' versehen sein. Die
richtige Empfängeradresse
wird dann eingefügt.
Da dann jedoch im Postausgang des MUA keine gültige Empfängeradresse enthalten ist,
wird diese Lösung
weniger häufig
einsetzbar sein.
-
In
einer anderen Variante wird die Empfängeradresse in einem von dem
Server des MTA erreichbaren Tabelle oder Datenbank gesucht. Wird
sie nicht gefunden, wird die Nachricht (im Gegensatz zu dem Vorschlag
von Levien, der ein unverschlüsseltes Versenden
vorsieht,) in der Regel als unzustellbar zurückgeschickt werden, da damit
ein irrtümliches
Exponieren an Betriebsfremde vermieden wird. Wird sie gefunden,
so enthält
die Datenbank nicht nur den Empfängerschlüssel, sondern
auch einen Vergleichswert für
das Vorgangskennzeichen. Dies kann wie zuvor das ganze Vorgangskennzeichen,
ein Teil davon oder oder auch ein regulärer Ausdruck hierfür sein.
Ist der Vergleich positiv, wird die Nachricht mit dem Empfängerschlüssel verschlüsselt und
verschickt. Wie zuvor wird andernfalls die Sicherheitspolitik des
Unternehmens in der Regel ein Zurückweisen vorsehen. Diese Lösung ist
insbesondere bei kleinem, manuell gepflegtem Datenbestand einer MUA
gut anwendbar.
-
Bei
dem Empfänger
sind zwei Möglichkeiten zur
Entschlüsslung
vorgesehen. Ist wieder ein zentraler Mailserver vorhanden, der ohnehin
alle eintreffende Mail ablegt bzw. im Unternehmen weiterleitet, dann
kann dieser die eintreffenen Nachrichten entschlüsseln, wenn ihm die Schlüssel vorliegen,
und sodann unverschlüsselt
weiterleiten. Damit wird die Schlüsselverwaltung vereinfacht.
-
Nachrichten,
für die
kein zentraler Schlüssel vorhanden
ist, werden nach der zweiten Möglichkeit behandelt,
d.h. dem Adressaten zugestellt. Dessen eMail-Client kann dann, wenn
im privaten Schlüsselspeicher
der passende Schlüssel
vorhanden ist, die Nachricht individuell entschlüsseln. Dies gilt insbesondere
für an
Privatleute adressierte Nachrichten.
-
Denn
auch hier erlaubt es die Erfindung, bespielsweise aus der Konto-
oder Versicherungsnummer den privaten Schlüssel zu bestimmen. Dies ist günstig, wenn
ein Sachbearbeiter individuelle Nachrichten an Kunden schickt, z.B.
aus der Wertpapierabteilung einer Bank. Für automatisch erzeugte und direkt
digital aus der Anwendung verschickte Nachrichten ist die Gefahr
einer Adressverwechselung gering; es wird jedoch durch die Erfindung
die Handhabung wesentlich vereinfacht, weil die Anwendung nicht
mehr um die Sicherheitskomponente ergänzt werden muss, sondern einfach
die Nachricht im Klartext an den MTA übermittelt; dieser übernimmt
dann die Verschlüsslung
einheitlich für
alle Anwendungen und Benutzer.
-
Optional
fügt der
Mailserver, der die Verschlüsslung
bewirkt, in bekannter Art den öffentlichen Schlüssel des
Unternehmens bzw. der absendenden Abteilung an die Nachricht an,
sofern dieser durch vertrauenswürdige
Dritte zertifiziert ist, wie dies bei X.509 vorausgesetzt wird.
Denn der Privatmann kann in herkömmlicher
Art den öffentlichen
Schlüssel mit
der eMail-Adresse der Firma zusammen abspeichern, weil eine Verwechselungsgefahr
weniger gegeben ist. Damit arbeitet die Erfindung problemlos mit
einem herkömmlichen
MUA zusammen.
-
Die
Erfindung kann anstelle in einem MTA oder dem vorgeschalteten Filter
auch in der Verschlüsselungs-Komponente
des MUA verwendet werden. Dazu muss dann im Adressverzeichnis ein weiteres
Feld vorgesehen sein, in dem das Vorgangskennzeichen, also die Kundennummer
o.ä., der
eMail-Adresse zugeordnet wird. Dies kann, wie oben, auch ein (regulärer) Vergleichsausdruck
sein. Beim Versenden wird dann gemäß der Erfindung geprüft, ob Empfängeradresse,
Vorgangskennzeichen und öffentlicher
Schlüssel
zueinander passen. Passen sie nicht, ist in diesem Fall eine interaktive
Auflösung
möglich;
der MTA eines Servers hingegen kann nur die Nachricht zurücksenden. Über Optionen
kann festgelegt werden, ob das Vorgangskennzeichen oder die Empfängeradresse
Vorrang haben, wo bzw. wie das Vorgangskennzeichen im Text der Nachricht aufzufinden
ist und wie nicht passende Fälle
zu behandeln sind.
-
Der
Unterschied zu der o.g. Serverlösung
in einem MTA besteht darin, daß bei
einer integrierten Lösung
im MUA dessen Adressdatenbank alle benötigten Daten speichert. Weiterhin
wird bereits frühzeitig
und interaktiv der Anwender auf Fehler aufmerksam gemacht und kann
ggf. vor dem Absenden der Nachricht die Fehler bereits korrigieren.
Auch sind heuristische Suchverfahren möglich, da der Anwender die
gefundene Auswahl bestätigen
kann.
-
In
Fällen,
in denen die Erfindung im MUA integriert ist, wird häufig mit
einem auf dem Rechner lokal gespeicherten Adress- bzw. Schlüsseldatenbank gearbeitet werden.
Da jedoch auch Schlüsselserver vorgesehen
sind, genügt
für die
Erfindung eine Tabelle, die eine Zuordnung von Empfängeradresse
und Vorgangskennzeichen zu dem Index in der Schlüsseldatenbank bewirkt. Der
Index in der Schlüsseldatenbank
ist bevorzugt die Empfängeradresse.
Gerade im Zusammhang mit PGP jedoch hat jeder Schlüssel auch
eine 'key-id' von 8 Hexadezimalziffen, mit
der der Schlüssel
in den öffentlichen
Schlüsseldatenbanken
gesucht werden kann, so daß dem
Vorgangskennzeichen auch eine 'key-id' zugeordnet werden
kann.
-
Um
Sonderfälle
behandeln zu können,
ist es vorgesehen, durch einen Indikator in der Nachricht die Funktionen
ganz oder teilweise ausser Kraft setzen zu können. Diese Funktion wird bevorzugt
nicht frei zu Verfügung
gestellt, sondern entweder von der Absenderadresse abhängig sein
oder durch eine Transaktionsnummer freigeschaltet werden. Zukünfigte Versionen
der Erfindung können
hierzu Kopfzeilen vorsehen.
-
Im
Sinne der Erfindung wird der Inhalt des Betreffs ('subject'), obwohl formal
eine Kopfzeile, der eigentlichen Nachricht zugeordnet. Dies ist
insofern berechtigt, als diese Zeile nur deshalb eine Kopfzeile ist,
damit ein MUA bei einer langsamen Verbindung zunächst nur die Kopfzeilen herunterladen
kann und dann erst nach Anweisung durch den Benutzer die eigentlichen
Nachrichten selbst überträgt. Da der
Inhalt der Kopfzeile nach bisherigem Verständnis jedoch nicht zum Versenden
der Nachricht benötigt
wird, sonderen ein Kommentar zum Inhalt darstellt, wird er als zur
Nachricht gehörig
betrachtet. Umgekehrt ist es ohne weiteres denkbar, dass zukünfig eine
weitere Kopfzeile definiert wird, die einem Vorgangskennzeichen
vorbehalten ist, und dann diese im Sinne der Erfindung zu dem Inhalt
der Nachricht gerechnet wird.
-
Um
das genannte Problem eines Stellvertreters zu lösen, sind zwei Varianten möglich. In
einer ersten Variante werden vom Empfänger keine persönlichen öffentlichen
Schlüssel
verwendet. Vielmehr wird ein und dasselbe Schlüsselpaar für mehrere Empfängeradressen
verwendet; alle diese Empfänger
können
einander vertreten. Diese Lösung
wird durch die Organisation des Empfängers bereitgestellt.
-
Falls
dieses nicht möglich
ist, kann im Rahmen der Erfindung eine Lösung wie folgt erfolgen:
Aus
dem Vorgangskennzeichen oder der Empfängeradresse werden mehrere öffentliche
Empfängerschlüssel bestimmt
und die Nachricht so verschlüsselt,
daß sie
mit jedem der zugehörigen
privaten Schlüssel
einzeln entschlüsselt
werden kann. Die Nachricht wird also ohne Zutun des Absenders für mehrere
Empfänger
verschlüsselt.
Zwar ist dies auch für
bisherige MUA implementierbar; der Aufwand zur Schlüsselpflege
wird damit jedoch weiter erhöht.
-
Ein
digitale Unterschrift, die von einer Einrichtung gemäß der Erfindung
hinzugefügt
würde,
ist nicht vorgesehen. Denn die digitale Unterschrift soll ja, entsprechend
einer herkömmlichen
Unterschrift, die Identität
des Unterschreibenden verifizieren und ist daher von dem eMail-Client
des jeweiligen Benutzers zu leisten. Bei kombinierter Unterschrift
und Verschlüsslung
wird nach RFC 2440 ohne erst unterschrieben und dann verschlüsselt.
-
Das
oben angesprochene Problem der Stellvertretung wird durch die Erfindung
nicht originär
gelöst,
aber wesentlich leichter handhabbar gemacht. Indem die Erfindung
die Verschlüsselung
an den Geschäftsvorgang
anbindet und zentralisert, erfolgt die Verwaltung transparent für den Sachbearbeiter,
ohne daß dieser
aufwendig für
jeden Adressaten seine Adressdatenbank pflegen muss. Insbesondere
können
Abteilungsschlüssel
verwendet werden, obwohl für
den Empfänger
auch ein individueller Schlüssel definiert
ist:
Verschlüsselt
der Sachbearbeiter eine Nachricht bereits in seinem MUA mit einem
personenbezogenen Schlüssel,
so wird eine persönliche
Nachricht gesendet. Ist die Erfindung vor oder in einem MTA auf
einem zentralen Server installiert, so wird die bereits verschlüsselte Nachricht
nicht verändert;
entweder, weil kein Vorgangskennzeichen zu finden ist oder weil – bevorzugt – bereits
verschlüsselte
Nachrichten erkannt und nicht verändert werden. Andernfalls wird die
Nachricht im zentralen Server mit dem Abteilungsschlüssel verschlüsselt.
-
In
einer Weiterbildung der Erfindung wird, wenn das gefunden Vorgangskennzeichen
kein Versenden erlaubt, mit einem alternativen Suchverfahen ein
weiteres Vorgangskennzeichen gesucht und dieses wie zuvor verwendet.
Ob diese Erweiterung praktikabel ist, hängt von dem Einsatzfall und
der dort erzielten Erfahrung ab.
-
Das
Vorgangskennzeichen kann auch durch einen Empfängerkreis ergänzt sein,
der in der Bestimmung der Empfängeradressen
mit einbezogen wird. In einem Patentverwaltungssystem eines Unternehmens
werden zu einem internen Aktenzeichen sowohl Nachrichten an die
Erfinder als auch an den beauftragten Anwalt geschickt. Da auch
externe Erfinder beteiligt sein können, ist eine Nachricht an
die Erfinder nicht automatisch eine interne Nachricht, sondern muss
dann verschlüsselt
werden. Daher wird in diesem Fall in das Vorgangskennzeichen ein Code
für den
Empfängerkreis
aufgenommen.
-
Somit
ergibt sich durch die Erfindung, daß nicht ausdrücklich verschlüsselte Nachrichten
automatisch und zum Vorgang passend verschlüsselt werden, während weiterhin
ein individuelle persönliche
Verschlüsslung
möglich
ist. Wird ein Server zur Weitersenden verwendet, kann das Verschlüsslungsverfahren,
sei es nach X.509 oder PGP, unabhängig vom eMail-Client gewählt werden.
Dies bedeutet, daß kein
spezieller eMail-Client benötigt
wird. Weiterhin sind die Kopien der versendeten Nachrichten auf dem
MUA unverschlüsselt
und daher auch dann nachvollziehbar, wenn der private Schlüssel des
Mitarbeiters unbrauchbar geworden ist. Zudem können vorhandene Anwendungen,
die elektronisch Nachrichten per SMTP schicken können, unverändert bleiben und dieselbe
Infrastruktur wie zum Versenden von individuell erstellten Nachrichten
verwenden.