DE19629192A1

DE19629192A1 - Verfahren und System zur Erzielung eines gesicherten elektronischen Datenaustausches über ein offenes Netz

Info

Publication number: DE19629192A1
Application number: DE19629192A
Authority: DE
Inventors: Lew Jenkins; Emmanuel K Pasetes Jr
Original assignee: Premenos Corp
Current assignee: Premenos Corp
Priority date: 1995-07-19
Filing date: 1996-07-19
Publication date: 1997-01-23
Also published as: GB9614931D0; ITMI961519A1; AU6058696A; JPH09162860A; GB2303525A; NL1003644C2; ITMI961519A0; US5812669A; FR2737067A1; IT1283473B1; CA2181597A1; NL1003644A1

Description

Die vorliegende Erfindung bezieht sich auf Verfahren und Systeme zur Erzielung eines gesicherten elektronischen Datenaustausches (EDI) über ein offenes System-Netz, wie z. B. das INTERNET, und insbesondere auf ein verbessertes Verfahren und System zur Er zielung einer gesicherten EDI-Mailübertragung über ein offenes Netz, das ein Verschlüsselungsschema mit öffentlichen und pri vaten Schlüsseln vom RSA-Typ (Rivest-Schamir-Adleman-Typ) ver wendet, um eine gesicherte Berechtigungsüberprüfung und Nicht-Zu rückweisung sowohl des Ursprungs als auch des Empfangs zu erzielen.

Mit dem Begriff "Mail" wird hierbei die Nachrichtenübertragung über ein Datennetz, d. h. die "elektronische Briefpost" bezeich net

Gesicherte Nachrichtenübertragungssysteme mit öffentlichen und privaten Schlüsseln über ein offenes Netz sind gut bekannt und beispielsweise in den folgenden US-Patentschriften beschrieben:
4 578 531, 4 471 164, 5 268 962, 5 142 577, 4 893 338, 5 222 140, 5 261 002, 5 073 934, 5 303 303, 5 297 208, 5 369 705, 5 351 293, 5 375 169, 5 224 166, 5 253 294 und 5 237 611. Das Verschlüsselungsschema mit öffentlichem und pri vatem Schlüssel vom RSA-Typ ist ein gut bekanntes, mit einem öffentlichen Schlüssel arbeitendes System zur Erzielung ge sicherter Nachrichten über ein offenes Netz, wie z. B. das INTERNET, und dieses Verschlüsselungsschema ist in verschieden erteilten US-Patenten beschrieben, wie zum Beispiel den US-Patenten 4 405 829, 4 424 414, 4 200 770, 4 218 582, 5 073 935 und 4 723 284, deren Inhalt durch diese Bezugnahme hier mit auf genommen wird. Zusätzlich ist das Konzept der Nicht-Zurück weisung oder Nichtabweisung des Ursprungs bekannt, wie dies z. B. in den US-Patentschriften 5 226 709 und 5 367 573 beschrieben ist, und zwar ebenso wie Systeme, bei denen digitale Unter schriften oder Signaturen in mit öffentlichen und privaten Schlüsseln verwendenden Systemen verwendet werden, wie dies bei spielsweise in den US-Patentschriften 5 311 591, 5 214 702, 5 337 360, 4 868 877, 5 001 752, 5 005 200, 5 136 643, 5 018 196, 4 885 777, 4 267 782, 5 351 302, 5 299 263, 5 142 578, 4 987 593, 4 991 210, 5 339 361, 5 373 558 und 4 625 076 beschrieben ist, und weiterhin ist ein derartiges System durch das "Entrust"-System bekannt, das von der Firma Northern Telecom vertrieben wird. Weiterhin wurden verschiedene andere gesicherte Übertragungssysteme über die Jahre in dem Bemühen entwickelt, gesicherte kommerzielle Nachrichtenübertra gungen über öffentliche oder private Netze zu schaffen, wie dies in den US-Patentschriften 5 369 702, 4 876 716, 5 199 074, 4 823 388, 5 268 962, 5 022 080, 5 136 646 und 5 204 961 beschrieben ist. Weiterhin ist die Verwendung des elektronischen Daten- oder Dokumentenaustausches oder EDI zur Übertragung von kommerziellen Kommunikationen von Hauptstation zu Hauptstation bekannt, wie dies beispielsweise in dem US-Patent 5 202 977 der gleichen Anmelder oder in dem oben erwähnten US-Patent 5 337 360 beschrieben ist. Den Anmeldern ist jedoch keine erfolgreiche bekannte Lösung zur Verwendung des INTERNET oder irgendeines anderen weit zugänglichen offenen Netzes, wie z. B. Telefon leitungen oder irgendein TCP/IP-System bekannt, bei dem ein gesichertes System mit öffentlichem und privatem Schlüssel, wie z. B. RSA, erfolgreich mit EDI kombiniert wurde, um eine Berech tigungsüberprüfung oder Authentizierung und Nicht-Zurückweisung sowohl des Ursprunges als auch des Empfängers in einer gesicher ten Hauptstations-zu-Hauptstations-Privattransaktion zu erzie len, die zu einer beliebigen Zeit über das offene Netz erfolgen kann, ohne daß eine Paßwort-Verwaltung erforderlich ist, wobei gleichzeitig eine Überprüfung der Integrität der Nachricht erzielt wird.

Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren und System der eingangs genannten Art zu schaffen, das die vorste hend genannten Nachteile beseitigt und einen gesicherten EDI-Datenaustauch über offene Netze mit einer sicheren Überprüfung des einwandfreien Datenaustausches ermöglicht.

Diese Aufgabe wird durch die im Patentanspruch 1 angegebenen Merkmale gelöst.

Vorteilhafte Ausgestaltungen und Weiterbildungen der Erfindung ergeben sich aus den Unteransprüchen.

Das erfindungsgemäße Verfahren und System beseitigt die Notwen digkeit privater Mehrwert-Netze und anderer privater Drittpar tei-Netze und stellt gleichzeitig die Möglichkeit einer privaten kommerziellen Hauptstations-zu-Hauptstations-Transaktion über ein weit verfügbares offenes Netz unter Verwendung von EDI sicher. Die Gewißheit der Nicht-Zurückweisung und der Berechtigungsüberprüfung beseitigt die Möglichkeit für jede Teilnehmerpartei, zu bestreiten, daß die Transaktion genehmigt wurde, und sie beseitigt weiterhin Zweifel hinsichtlich des Inhaltes des EDI-Dokumentes, das zu der Transaktion führte. Die Fähigkeit des Verfahrens und des Systems gemäß der vorliegenden Erfindung zur Schaffung eines gesicherten EDI-Mail- oder elek tronischen Postdienstes in Kombination mit einem System mit öffentlichem und privatem Schlüssel vom RSA-Typ beseitigt die Nachteile des Standes der Technik.

Das erfindungsgemäße Verfahren und System umfaßt die Verwendung der AUTACK- oder EDI-Bestätigungsmeldung als ein Dokument zur Lieferung der digitalen Unterschrift in einem einen öffentlichen und einen privaten Schlüssel verwendenden System, bei dem die AUTACK durch einen Hash-Code der EDI-Datenaustausch-Kommunika tion unterzeichnet wird, der mit dem privaten Schlüssel des Absenders verschlüsselt wurde, wie z. B. in einem System mit öffentlichem und privatem Schlüssel vom RSA-Typ, und das erfin dungsgemäße System stellt eine Verbesserung gegenüber diesen Systemen dar. Weil die AUTACK oder die funktionelle Bestätigung mit dem privaten Schlüssel des Absenders der funktionellen Bestätigung gesiegelt wird, dem Empfänger der ursprünglichen Nachricht, so ist für den ursprünglichen Absender, wenn er die Anwort-AUTACK-Nachricht mit dem öffentlichen Schlüssel des Empfängers entschlüsselt, sichergestellt, daß der beabsichtigte Empfänger tatsächlich die Antwort-AUTACK oder die Bestätigung gesendet hat und daß die Integrität des Empfanges sichergestellt ist, wenn der richtige Hash-Code festgestellt wird.

Die EDI AUTACK-Nachricht, wie z. B. die EDIFACT AUTACK-Nachricht, ein allgemeiner internationaler Standard für den elektronischen Datenaustausch (EDI) für Verwaltungszwecke, für kommerzielle und Handelszwecke, wird vorzugsweise zur Lieferung der gewünschten gesicherten Berechtigungsüberprüfung, Nicht-Zurückweisung des Ursprunges oder des Empfanges oder die Bestätigung oder Nicht-Be stätigung für eine oder mehrere EDI-Informationsgruppen ver wendet, wie z. B. für die X.12- oder EDIFACT-Informationsgruppen.

Bei dem derzeit bevorzugten Verfahren und dem System gemäß der vorliegenden Erfindung berechnet bei dem Vorgang der Berechti gungsüberprüfung und Nicht-Zurückweisung des Ursprunges der Absender den gewünschten Hash-Code oder die Mitteilungszusammen fassung aus der EDI, wie z. B. den MD5-Wert für die gesamte Datenaustauschkombination, und setzt diesen Wert in die AUTACK-Nach richt ein. Der Absender berechnet dann vorzugsweise den MD5-Wert (Nachrichtenzusammenfassung Version 5) der AUTACK-Nach richt und unterzeichnet digital die AUTACK-Nachricht durch Verschlüsseln des berechneten MD5-Wertes mit dem privaten Schlüssel des Absenders und fügt diesen Wert in die AUTACK-Nach richt ein. Somit wird die AUTACK- oder EDI-Bestätigungs nachricht vorzugsweise zur Lieferung der Unterschrift oder Signatur verwendet. Der Empfänger entschlüsselt dann nach dem Empfang der Nachricht die elektronische Datenaustauschkommuni kation, wenn diese verschlüsselt ist, und berechnet dem MD5-Wert der empfangenen elektronischen Datenaustauschkommunikation. Wenn eine Nicht-Zurückweisung des Ursprungs gewünscht ist, so entschlüsselt der Empfänger dann die AUTACK-Nachricht mit dem öffentlichen Schlüssel des Absenders. Der bei dieser Entschlüsselung bei diesem Beispiel gewonnene Wert ist der MD5-Wert der AUTACK-Nachricht. Der MD5-Wert der AUTACK-Nach richt wird dann berechnet und mit dem entschlüsselten Wert verglichen. Wenn beide Werte gleich sind, so ist die Integrität der AUTACK-Nachricht überprüft und die Nicht-Zu rückweisung des Ursprunges wird festgelegt. Der MD5-Wert der elektronischen Datenaustauschkommunikation wird dann mit dem MD5-Wert der elektronischen Datenaustauschkommunikation verglichen, die in die AUTACK-Nachricht eingefügt wurde, und wenn die beiden gleich sind, so ist die Integrität des elek tronischen Datenaustausches überprüft und die Nicht-Zurückwei sung des Ursprunges wird festgestellt.

Um dann die Nicht-Zurückweisung des Empfanges festzustellen, nachdem die Integrität und Authentizität der in der vorstehend beschriebenen Weise empfangenen elektronischen Datenaustausch kommunikation sichergestellt wurde, wird eine neue oder Anwort-AUTACK-Nachricht dadurch geschaffen, daß alle Segmente und Elemente in geeigneter Weise besetzt werden, daß der berechnete MD5-Wert digital mit dem privaten Schlüssel des Empfängers unterzeichnet wird, daß der digital unterzeichnete MD5-Wert in die Antwort-AUTACK-Nachricht eingefügt wird, daß geeignete Segmente der Antwort-AUTACK-Nachricht besetzt werden, und daß die so zubereitete Antwort-AUTACK-Nachricht zum Absender über tragen wird. Der ursprüngliche Absender überprüft dann beim Empfang dieser AUTACK-Nachricht die digitale Unterzeichnung oder Signatur von dem Empfänger seiner ursprünglichen Nachricht, indem er sie mit dem öffentlichen Schlüssel des Empfängers ent schlüsselt. Der durch diese Entschlüsselung gewonnene Wert ist der MD5-Wert der empfangenen Antwort-AUTACK-Nachricht. Der ur sprüngliche Absender, der die Antwort-AUTACK-Nachricht von dem Empfänger der Nachricht empfangen hat, berechnet dann den MD5-Wert der empfangenen Antwort-AUTACK-Nachricht, und wenn der berechnete MD5-Wert gleich dem entschlüsselten MD5-Wert ist, so wird die Integrität der AUTACK-Nachricht aufrechterhalten und die Nicht-Zurückweisung des Ursprunges der AUTACK-Nachricht wird festgestellt. Weiterhin ergeben, wenn der MD5-Wert in dem speziellen Segment der empfangenen AUTACK-Nachricht enthalten ist, in das er von dem Absender eingefügt wurde, gleich dem MD5-Wert der vorher übertragenen elektronischen Datenaustausch-Nach richt ist und die Bestätigung positiv ist, was durch Über prüfen des Sicherheitscodes in der AUTACK-Nachricht abgeleitet werden kann, die folgenden Merkmale implizit die Feststellung der Nicht-Zurückweisung des Empfanges: die betreffende elektro nische Datenaustausch-Kommunikation ist sowohl beim Absender als auch beim Empfänger bekannt, weil der MD5-Wert der elektroni schen Datenaustauschkommunikation und die Austauschnummer in der AUTACK-Nachricht enthalten sind und einwandfrei erkannt wurden; die Integrität und Authentizität der elektronischen Datenaus tauschkommunikation beim Empfang wurde überprüft; und der Empfänger bestreitet nicht den Empfang der betreffenden elektronischen Datenaustauschkommunikation.

Die Fähigkeit, auf einer Hauptstations-zu-Hauptstation über ein offenes öffentliches Netz, wie z. B. das INTERNET, Handel zu treiben oder Geschäfte abzuwickeln, und zwar ohne die Notwen digkeit einer Paßwort-Verwaltung, kann in gewünschtem Ausmaß durch die Handelsbeteiligten durch die Verwendung von Handels partner-Vereinbarungen zur Erzielung einer Schlüssel-Austausch zertifikation oder dadurch gesteuert werden, daß man sich auf eine Zertifizierungsautorität verläßt, die öffentliche und pri vate Schlüsselpfade ausgibt und überprüft. Damit können private und gesicherte Transaktionen, die einer Berechtigungsüberprüfung und Nicht-Zurückweisung sowohl des Ursprunges als auch des Emp fanges unterworfen werden, zusammen mit einer Überprüfung der Nachrichtenintegrität unter Verwendung von EDI über ein offenes Kommunikationsnetz ausgeführt werden.

Ausführungsbeispiele der Erfindung werden im folgenden anhand der Zeichnungen noch näher erläutert.

In der Zeichnung zeigen:

Fig. 1 ein funktionelles Ablaufdiagramm des derzeit bevorzugten Verfahrens und Systems gemäß der vorliegenden Erfindung zur Erzielung eines gesicherten EDI-Datenaustausches über ein offenes Netz, wie z. B. das INTERNET, um eine Integrität, Berechtigungsüberprüfung und Nicht-Zurückweisung des Ursprunges und des Empfängers sowie eine Vertraulichkeit unter Verwendung von EDI zu schaffen,

Fig. 2 ein funktionelles Ablaufdiagramm des Teils des Verfahrens und Systems nach Fig. 1, das die Berechtigungsüber prüfung und Nicht-Zurückweisung des Ursprunges unter Verwendung der EDIFACT-AUTACK-Nachricht ergibt,

Fig. 3 ein der Fig. 2 ähnliches funktionelles Ablauf diagramm des Teils des Verfahrens und Systems nach Fig. 1, das die Nicht-Zurückweisung des Empfängers unter Verwendung der EDIFACT-AUTACK-Nachricht ergibt,

Fig. 4 ein funktionelles Ablaufdiagramm des Empfangs einer gesicherten elektronischen Postnachricht über das INTERNET gemäß dem derzeit bevorzugten Verfahren und System der vorliegenden Erfindung,

Fig. 5 ein der Fig. 4 ähnliches funktionelles Ablauf diagramm des Sendens einer gesicherten Postnachricht über das INTERNET gemäß dem derzeit bevorzugten Verfahren und System der vorliegenden Erfindung,

Fig. 6 ein der Fig. 4 ähnliches funktionelles Ablauf diagramm einer Handelspartner-Verwaltung gemäß dem derzeit bevorzugten Verfahren und System der vorliegenden Erfindung,

Fig. 7 ein der Fig. 4 ähnliches funktionelles Ablauf diagramm der Revisions- oder Audit-Protokollverwaltung gemäß dem derzeit bevorzugten Verfahren und System der vorliegenden Erfindung,

Fig. 8 ein der Fig. 4 ähnliches funktionelles Ablauf diagramm der Nachführungsverwaltung gemäß dem derzeit bevor zugten Verfahren und System der vorliegenden Erfindung,

Fig. 9 ein der Fig. 4 ähnliches funktionelles Ablauf diagramm der Auftragsverwaltung gemäß dem derzeit bevorzugten Verfahren und System der vorliegenden Erfindung,

Fig. 10 ein Funktionsdiagramm der Organisation des Systems, das bei der Ausführung des derzeit bevorzugten Ver fahrens der vorliegenden Erfindung verwendet wird,

Fig. 11 bis 13 zusammen ein funktionelles Ablaufdiagramm ähnlich der Fig. 4 des gesamten derzeit bevorzugten Verfahrens und Systems nach den Fig. 1 bis 11, wobei Fig. 11 die Zertifi kat-Überprüfung, Fig. 12 die TPA-Verarbeitung und Fig. 13 die Verarbeitung für den öffentlichen Schlüssel und den privaten Schlüssel zeigt,

Fig. 14 eine schematische Darstellung einer typischen Computerbildschirmanzeige gemäß dem derzeit bevorzugten Ver fahren und System der vorliegenden Erfindung, die die verschie denen funktionellen Optionen zeigt, die von den Benutzern ge steuert werden können, um eine sichere Postübertragung über das INTERNET gemäß dem derzeit bevorzugten Verfahren und System der vorliegenden Erfindung sicherzustellen,

Fig. 15 bis 21 der Fig. 14 ähnliche schematische Dar stellungen typischer Computerbildschirmanzeigen gemäß der Handelspartner-Profil-Option in der Bildschirmanzeige nach Fig. 14,

Fig. 22 bis 28 der Fig. 14 ähnliche schematische Dar stellungen typischer Computerbildschirmanzeigen gemäß der Handelspartner-Vereinbarungs-Option in der Bildschirmanzeige nach Fig. 14, wobei Fig. 28 die abgehende Rückübertragungs-Bild schirmanzeige zum Senden einer gesicherten E-Mail gemäß dem derzeit bevorzugten Verfahren und System der vorliegenden Erfindung zeigt,

Fig. 29 bis 33 der Fig. 14 ähnliche schematische Dar stellungen typischer Computerbildschirmanzeigen gemäß der Schlüselverwaltungs-Option in der Bildschirmanzeige nach Fig. 14,

Fig. 34 bis 41 der Fig. 14 ähnliche schematische Dar stellungen typischer Computerbildschirmanzeigen gemäß der Nachführungsoption in der Bildschirmanzeige nach Fig. 14, wobei die Fig. 35 bis 38 Nachführungs-Austauschvorgänge zeigen, während die Fig. 39 bis 41 die Nachführung eines Audit-Protokolls zeigen.

Unter näherer Bezugnahme auf die Zeichnungen und anfänglicher Bezugnahme auf Fig. 1 ist ein funktionelles Ablaufdiagramm des derzeit bevorzugten Systems 100 der vorliegenden Erfindung zur Erzielung eines gesicherten elektronischen Datenaustausches oder EDI über ein übliches offenes Netz, wie das kommerziell verfüg bare INTERNET 102, zu erkennen. Das bevorzugte Verfahren und System gemäß der vorliegenden Erfindung ist gerätemäßig in einem System ausgeführt, das unter der Marke TEMPLAR von der vorlie genden Anmelderin vertrieben wird. Wie dies weiter unten unter Bezugnahme auf die Fig. 2 bis 41 erläutert wird, ergibt das derzeit bevorzugte Verfahren und System der vorliegenden Erfin dung eine Integrität, Berechtigungsüberprüfung, Nicht-Zurück weisung sowohl des Ursprunges als auch des Empfanges und eine Vertraulichkeit unter Verwendung von EDI. Dies wird vorzugs weise dadurch erreicht, daß die AUTACK- oder EDI-Bestätigungs nachricht als Dokument zur Lieferung einer digitalen Signatur in einem System mit öffentlichem und privatem Schlüssel verwen det wird, wobei dieses System vorzugsweise ein System ist, das das übliche RSA-Verschlüsselungsschema mit öffentlichem und privatem Schlüssel verwendet, wie z. B. das Verschlüsselungs system, das in den US-Patenten 4 405 828, 4 424 414, 4 200 770 und 4 218 582 beschrieben ist, wobei der Inhalt dieser Patent schriften durch diese Bezugnahme in ihrer Gesamtheit hier mit aufgenommen wird. Wie dies weiter unten ausführlicher erläutert wird, wird die AUTACK-Nachricht vorzugsweise mit einer digitalen Signatur gesiegelt oder unterzeichnet, die vorzugsweise dadurch geschaffen wird, daß der MD5-Wert (Nachrichtenzusammenfassung Version 5) der AUTACK-Nachricht mit dem privaten Schlüssel des Urhebers der AUTACK-Nachricht verschlüsselt wird, wie z. B. dem privaten Schlüssel des Absenders bei dem bevorzugten Vorgang der Berechtigungsüberprüfung und Nicht-Zurückweisung des Ur sprunges gemäß Fig. 2, oder durch Verschlüsseln mit dem privaten Schlüssel des Empfängers bei dem bevorzugten Vorgang der Nicht-Zu rückweisung des Empfanges gemäß Fig. 3. Die digitale Signatur wird dann vorzugsweise an einer vorgegebenen Position in die AUTACK-Nachricht eingefügt und zu der anderen Partei der Trans aktion übertragen. Weil die AUTACK-Nachricht mit dem privaten Schlüssel des Absenders der AUTACK-Nachricht gesiegelt ist, so wird, wenn der Empfänger dieser AUTACK-Nachricht die AUTACK-Nach richt mit dem öffentlichen Schlüssel des Absenders dieser AUTACK-Nachricht entschlüsselt, sichergesellt, daß der beab sichtigte Empfänger seiner Nachricht tatsächlich diese AUTACK-Nach richt gesandt hat, wobei weiterhin die Integrität des Emp fanges aufgrund der Tatsache sichergestellt ist, daß der rich tige Hash-Code in der nachfolgend zu beschreibenden Weise fest gestellt wird. Gemäß der vorliegenden Erfindung sind der ver schlüsselte private Schlüssel, der zur Verschlüsselung der Nachricht verwendet wurde, sowie die Nachricht selbst in der PKCS-Nachricht erhalten.

Der MD5-Wert ist ein üblicher Wert, der in einer EDI-Nachricht dadurch gewonnen wird, daß in üblicher Weise eine Quantität, wie z. B. ein elektronischer Datenaustausch, Hash-codiert wird. Es besteht eine sehr geringe Wahrscheinlichkeit, daß der MD5-Wert irgendwelcher zweier verschiedener Dokumente gleich ist und entsprechend wird der MD5-Wert vorzugsweise zur Feststellung der Integrität von elektronischen Datenaustauschnachrichten gemäß dem derzeit bevorzugten Verfahren der vorliegenden Erfindung verwendet.

Wie es Nutzern des elektronischen Datenaustausches oder EDI gut bekannt ist, ist eine AUTACK-Nachricht eine UN/EDIFACT-Norm für die Berechtigungsüberprüfung (Authentizierung) und Bestäti gung. Gemäß dem derzeit bevorzugten Verfahren und System der vorliegenden Erfindung besteht die AUTACK-Nachricht vorzugsweise aus dem USH- oder Sicherheitsvorspann, aus USB, USX zur Identi fikation der Nachricht, aus USY zur Aufnahme von Sicherheits informationen hinsichtlich der betreffenden Nachricht, USR und einigen anderen üblichen Segmenten, die sich normalerweise in einer AUTACK-Nachricht finden. Vorzugsweise sind Informationen, wie z. B. die Antwortart, Umfang der Sicherheitsanwendung und Sicherheitsfunktion in dem USH-Segment codiert. Als Beispiel kann das zweite Element des USH-Segmentes vorzugsweise den Wert 2 oder irgendeinen anderen bestimmten Wert enthalten, wenn die AUTACK-Nachricht als ein Dokument dienen soll, das die Nicht-Zurückweisung des Ursprunges überprüft, wobei z. B. das fünfte Feld den Wert 2 oder irgendeinen anderen bestimmten Wert hat, wenn eine Bestätigung erforderlich sein würde. Das USX-Segment enthält vorzugsweise die Austauschnummer des betreffen den EDI-Datenaustausches, wodurch die betreffende Nachricht mit der AUTACK-Nachricht verknüpft wird, und das USR-Segment ist vorzugsweise ein Sicherheitsergebnis-Halter und enthält den digital signierten MD5-Wert der AUTACK-Nachricht gemäß der vorliegenden Erfindung.

Wie dies weiterhin in Fig. 1 gezeigt und bevorzugt ist, hat unter der Annahme lediglich einer Zweipartei-Geschäftstrans aktion zwischen zwei Parteien, die eine Handelspartnerverein barung geschlossen haben, jede der Parteien eine übliche Computer-Arbeitsstation 104, 106, wie z. B. einen RS/6000, einen HP/9000 oder einen SOLARIS-Computer, einen üblichen EDI-Übersetzer 100, 110; einen üblichen integrierten Software-/Hard ware-Server 112, 114, der so programmiert ist, daß er gemäß dem bevorzugten Verfahren und System der vorliegenden Erfindung arbeitet, und der übliche Computer-Anzeigeterminals 116, 118 einschließt, die in der Lage sind, in einer Microsoft- WINDOWS- oder UNIX-X-WINDOWS-artigen Umgebung zu arbeiten, um Nachrichten und Auswahlmöglichkeiten gemäß dem bevorzugten Verfahren der vorliegenden Erfindung sowie Nachrichten und Dokumente anzuzeigen, die über EDI über das INTERNET-Netz 102 bei der Ausführung des Verfahrens nach der vorliegenden Er findung übertragen werden, wobei die Server 112, 114 in der Lage sind, die gewünschte Berechtigungsüberprüfung oder Authen tizierung, die Integrität, die Nicht-Zurückweisung des Ur sprunges und des Empfanges und die Vertraulichkeit gemäß der vorliegenden Erfindung zu schaffen. Wie dies gezeigt und bevor zugt ist, stehen die Server 112, 114 in üblicher Weise über das offene Netz, wie z. B. das INTERNET 102 über eine heterogene Mail-Umgebung 120, 122 in Nachrichtenübertragungsverbindung, wobei diese Post- oder Mail-Umgebung die SMPT-/MIME-, die X400/X435-, die LOTUS-NOTES-/cc:MAIL- und/oder MICROSOFT MAIL/EXCHANGE-Protokolle verwendet. Die Server 112, 114 sind vorzugs weise übliche Rechner, die in üblicher Weise in der C++-Pro grammiersprache programmiert sind, um das derzeit bevorzugte Verfahren der vorliegenden Erfindung auszuführen, wobei diese Programme vorzugsweise so ausgebildet sind, daß sie auf einer der folgenden UNIX-Plattformen laufen: AIX, HPUX, SUN OS oder SOLARIS.

In der nachfolgenden Tabelle A sind die verschiedenen Skripten aufgeführt, die ohne weiteres von einem Programmierer mit durchschnittlichen Kenntnissen verwendet werden können, um die erforderliche Programmierung in C++ zu schaffen, wobei C++ eine objektorientierte Programmiersprache ist und diese Pro gramme auf den Servern 112, 114 laufen sollen, um das derzeit bevorzugte Verfahren der vorliegenden Erfindung auszuführen. Es ist zu erkennen, daß sich die verschiedenen Skripten auf die Aussendung eines EDI-Dokumentes, die erneute Aussendung eines EDI-Dokumentes, den Empfang eines gültigen EDI-Dokumentes, den Empfang einer Bestätigungs-AUTACK-Nachricht, den Empfang eines neuen öffentlichen Schlüssels eines Handelspartners, die Ver teilung des eigenen neben öffentlichen Schlüssels an verbundene Handelspartner, die Aktivierung des Zertifikat-Verwaltungs-Haupt menüs, die Schaffung des eigenen privat/öffentlichen Schlüsselpaares, die Änderung eines Zertifikates (des eigenen öffentlich/privaten Schlüsselpaares), die Beseitigung des eige nen privaten/öffentlichen Schlüsselpaares, das Kopieren des eigenen öffentlichen Schlüssels in eine Plattendatei, das Aus drucken des Zertifikates für den eigenen öffentlichen Schlüssel, des Speicherns des eigenen privaten/öffentlichen Schlüssels in einer Plattendatei, das Wiederherstellen des eigenen privaten/ öffentlichen Schlüssels von einer Plattendatei zum Ersetzen des vorhandenen privaten/öffentlichen Schlüssels, des Wiederherstel lens des eigenen privaten/öffentlichen Schlüssels von einer Plattendatei auf einen neuen Schlüssel, das Aktivieren des Ver waltungshauptmenüs für den öffentlichen Schlüssel der Handels partner, das Hinzufügen eines öffentlichen Handelspartners, das Ändern des öffentlichen Schlüssels eines Handelspartners, das Entfernen des öffentlichen Schlüssels eines Handelspartners, das Kopieren des öffentlichen Schlüssels des Handelspartners von einer Plattendatei zum Ersatz des vorhandenen öffentlichen Schlüssels des Handelspartners, das Kopieren des öffentlichen Schlüssels des Handelspartners von der Plattendatei auf einen neuen Schlüssel, das Aktivieren des Handelspartner-Vereinba rungs-Verwaltungshauptmenüs, das Hinzufügen einer Handelspart nervereinbarung, das Ändern der Handelspartnervereinbarung, die Entfernung einer Handelspartnervereinbarung, das Kopieren der Handelspartnervereinbarung in eine Plattendatei, das Kopieren der Handelspartnervereinbarung von einer Plattendatei, die MIME-Paketbildung (üblicher MIME-Maildienst), die MIME-Entpackung, die PKCS-Paketbildung (übliches PKCS-Verfahren), die PKCS-Ent packung, das Arbeiten mit den Nachführaufzeichnungen, die Über wachung von Server-Aufträgen, den Empfang eines ungültigen EDI-Dokumentes mit einem Integritätsproblem, den Empfang einer AUTACK-Nachricht mit einem Integritätsproblem, den Empfang einer nichtunterstützten Postnachricht, den Empfang eines EDI-Daten austausches ohne AUTACK-Nachricht, während eine Nicht-Zurückwei sung des Ursprunges erwartet wird, und den Empfang einer unerwarteten AUTACK-Nachricht beziehen.

TABELLE A

Skripten

Sende ein EDI-Dokument

Wiederaussendung eines EDI-Dokumentes

Empfang eines gültigen EDI-Dokumentes

Empfang einer Betätigungs-AUTACK-Nachricht

Empfange den neuen öffentlichen Schlüssel eines Handelspartners

Vorteile neuen eigenen öffentlichen Schlüssel an verbundene Handelspartner

Aktiviere Zertifikat-Verwaltungs-Hauptmenü

Schaffe eigenes Paar von privatem/öffentlichem Schlüssel Der Benutzer muß sich einloggen und das Zertifikat-Verwaltungs-Hauptmenü aktivieren, bevor er zu dieser Funktion gelangt.

Ändere Zertifikat (eigenes Paar von privaten und öffentlichem Schlüssel)

Der Benutzer muß sich einloggen und das Zertifikat-Verwaltungs-Hauptmenü aktivieren, bevor er zu dieser Funktion gelangt.

Lösche Paar von eigenem privaten/öffentlichen Schlüssel

Kopiere eigenen öffentlichen Schlüssel in Plattendatei

Drucke Zertifikat für eigenen öffentlichen Schlüssel

Speichere den eigenen privaten und öffentlichen Schlüssel in Plattendatei der Benutzer muß sich einloggen und das Zertifikat-Verwaltungs-Hauptmenü aktivieren, bevor er zu dieser Funktion gelangt.

Speichere den eigenen privaten und öffentlichen Schlüssel in Plattendatei

Wiederherstellen des eigenen privaten/öffentlichen Schlüssels von der Plattendatei zum Ersatz der vorhandenen Schlüssel

Wiederherstellen des eigenen privaten/öffentlichen Schlüssels von einer Plattendatei auf einen neuen Schlüssel

Aktiviere das Verwaltungs-Hauptmenü für die öffentlichen Schlüssel der Handelspartner

Hinzufügen des öffentlichen Schlüssels eines Handelspartners

Der Benutzer muß sich einloggen und das Verwaltungs-Hauptmenü für das öffentliche Zertifikat der Handelspartner aktivieren, bevor er zu dieser Funktion gelangt.

Ändere den öffentlichen Schlüssel eines Handelspartners

Entferne den öffentlichen Schlüssel eines Handelspartners

Kopiere den öffentlichen Schlüssel für Handelspartner von der Plattendatei, um den vorhandenen Schlüssel zu ersetzen

Es sei angenommen, daß die Datei das X.509-Format aufweist.

Kopiere den öffentlichen Schlüssels eines Handelspartners von der Plattendatei aufeinen neuen Schlüssel

Es sei angenommen, daß die Datei das X.509-Format aufweist.

Aktiviere Handelspartner-Vereinbarungs-Verwaltungs-Hauptmenü

Füge Handelspartner-Vereinbarung hinzu

Der Benutzer muß sich einloggen und das Handelsparther-Verwaltungs-Haupt menü aktivieren, bevor er zu dieser Funktion gelangt.

Ändere Handelspartner-Vereinbarung

Der Benutzer muß sich einloggen und das Handelspartner-Verwaltungs-Hauptmenü aktivieren, bevor er zu dieser Funktion gelangt.

Lösche Handelspartner-Vereinbarung

Kopie Handelspartner-Vereinbarung in Plattendatei

Der Benutzer muß sich einloggen und das Handelspartner-Verwaltungs-Menü aktivieren, bevor er zu dieser Funktion gelangt.

Kopiere Handelspartner-Vereinbarung von Plattendatei

Der Benutzer muß sich einloggen und das Handelsparther-Vereinbarungs-Hauptmenü aktivieren, bevor er zu dieser Funktion gelangt.

MIME-Packung

MIME-Entpacken

PKCS-Packung

PKCS-Entpackung

Arbeit mit der Nachführaufzeichnung

Überwachung von Server-Aufträgen

Empfang eines ungültigen EDI-Dokumenten mit einem Integritätsproblem

Es sei angenommen, daß der Anfang des Skriptes der gleiche ist, wie "Empfang eines gültigen EDI-Dokumentes". Nach der Überprüfung, ob die Zusammenfassung der Teil-AUTACK-Nachricht gleich der entschlüsselten signierten Zusammenfassung in der AUTACK ist, stellt der Berechtigungs agent fest, daß die Zusammenfassung in der AUTACK-Nachricht nicht mit der Zusammenfassung des EDI-Austausches übereinstimmt.

Empfang einer AUTACK-Nachricht mit einem Integritätsproblem Es sei angenommen, daß der Anfang des Skriptes der gleiche ist, wie das Skript für den "Empfang eines gültigen EDI-Dokumentes". Der Berechtigungsagent stellt fest, daß die Zusammenfassung der Teil-AUTACK-Nachricht nicht gleich der ent schlüsselten signierten Zusammenfassung in der AUTACK-Nachricht ist.

Empfang nichtunterstützter Mail

Es sei angenommen, daß der Anfang des Skriptes der gleiche ist, wie das Skript für "Empfange ein gültiges EDI-Dokument". Der Berechtigungsagent stellt fest, das die Mail kein EDI-Dokument, keine AUTACK-Nachricht und kein Zertifikat ist.

Empfange einen EDE-Austausch ohne AUTACK-Nachricht, wobei eine Nicht-Zurück weisung des Ursprunges erwartet ist. Es sei angenommen, daß der Anfang des Skriptes gleich dem Skript "Empfange ein gültiges EDI-Dokument" ist. Der Berechtigungsagent stellt fest, daß sich keine AUTACK-Nachricht in der Mail befindet.

Empfang einer unerwarteten AUTACK-Nachricht

Es sei angenommen, daß der Anfang des Skriptes gleich dem Skript "Empfange ein gültigen EDI-Dokumentes" ist. Der Berechtigungsagent stellt fest, daß sich eine AUTACK-Nachricht in der Mail findet, doch legt die Handelspartner-Vereinbarung keine Nicht-Zurückweisung des Ursprunges fest.

Die Fig. 14 bis 41 zeigen die verschiedenen Bildschirmdarstel lungen in einer üblichen Umgebung vom "WINDOWS"-Typ, die vor zugsweise auf den typischen Computer-Bildschirmen 116, 118 angezeigt werden können, die mit den Servern 112, 114 verbunden sind, wenn das vorstehende Verfahren unter der Steuerung des Programms ausgeführt wird, das auf den Skripten der Tabelle A beruht. In dieser Hinsicht zeigt Fig. 14 die Gesamt-Bildschirm darstellung, die den Parteien an dem Netz dargeboten wird, die an Hauptstations-zu-Hauptstations-, Rechner-zu-Rechner, Geschäfts-EDI-Transaktionen über das INTERNET teilnehmen können. Wie dies beispielsweise in Fig. 14 gezeigt ist, kann dem Be nutzer beispielsweise die Möglichkeit gegeben werden, Fenster für HANDELSPARTNERPROFILE, HANDELSPARTNERVEREINBARUNGEN, SCHLÜSSELVERWALTUNG und NACHFÜHRUNG in der üblichen WINDOWS-Umgebung auszuwählen, die vorzugsweise verwendet wird.

Die Fig. 15 bis 21 zeigen verschiedene Computer-Bildschirmdar stellungen, die dem Benutzer dargeboten werden können, nachdem das HANDELSPARTNERPROFILE-Fenster in der Bildschirmdarstellung nach Fig. 14 ausgewählt wurde. Fig. 15 zeigt ein Beispiel mit drei möglichen Handelspartnern, die als CCISCO, SEARS und ME bezeichnet sind, wobei ME den Benutzer selbst darstellt. Fig. 16 zeigt eine mögliche Dialogbox oder ein Dialogfenster zur Erzeu gung des Handelspartnerprofils direkt auf dem Computer-Bild schirm 116, 118. In ähnlicher Weise zeigt Fig. 17 eine mögliche Dialogbox oder ein Dialogfenster zur Erzeugung von Kontakt information für den Handelspartner direkt auf dem Computer-Bild schirm 116, 118. Fig. 18 zeigt eine mögliche Dialogbox zur Erzeugung der SDI-Qualifikator-Information direkt auf dem Computer-Bildschirm 116, 118. Fig. 19 zeigt eine mögliche Dia logbox für Handelspartner-gebundene Schlüssel, die dargestellt und direkt auf dem Computer-Bildschirm 116, 118 geändert werden können, wobei zwei Optionen für BIND und UNBIND gezeigt sind. Fig. 20 zeigt die Computer-Bildschirmdarstellung 116, 118, wenn die BIND KEYS- (Binde Schlüssel-) Option in der Darstellung nach Fig. 19 ausgewählt wurde, um einen bestimmten Schlüssel mit einem bestimmten Handelspartner zu verbinden. Fig. 21 zeigt die Computer-Bildschirmdarstellung 116, 118 für die Schlüssel hinzufügung, um beispielsweise ein formatiertes Zertifikat an zuzeigen, das mit dem Handelspartner zusammen mit dem Schlüssel verbunden werden kann.

Die Fig. 22 bis 28 zeigen verschiedene Computer-Bildschirmdar stellungen, die dem Benutzer dargeboten werden können, nachdem er das HANDELSPARTNER-VEREINBARUNGS-Fenster in der Bildschirm darstellung nach Fig. 14 ausgewählt hat. Fig. 22 zeigt einen Fall mit den gleichen drei Handelspartnern wie in Fig. 15. Fig. 23 zeigt eine Dialogbox zur Erzeugung einer Handelspartner-Ver einbarung für das vorstehende Beispiel zwischen dem Benutzer ME, der die lokale ID (Identifikation) ist, und SEARS, der die entfernte ID ist, direkt auf dem Computer-Bildschirm 116, 118. Fig. 24 zeigt ein Dialogfenster zur Erzeugung der Befehle für die Lenkung oder das "Routen" von ankommenden Nachrichten für die Handelspartner-Vereinbarung direkt auf dem Computer-Bild schirm 116, 118. In ähnlicher Weise zeigen die Fig. 25 bis 27 verschiedene Dialogfenster zur Erzeugung der Befehle für die Lenkung abgehender Nachrichten für die Handelspartner-Verein barung direkt auf den Computer-Bildschirm 116, 118. Fig. 28 zeigt ein Dialogfenster zur Auswahl der abgehenden erneuten Aussendung direkt auf dem Computer-Bildschirm 116, 118.

Die Fig. 29 bis 33 zeigen verschiedene Computer-Bildschirm darstellungen, die dem Benutzer dargeboten werden können, nachdem er das SCHLÜSSELVERWALTUNGS-Fenster in der Bildschirm darstellung nach Fig. 14 ausgewählt hat. Fig. 29 zeigt wiederum einen Fall mit den gleichen drei Handelspartnern wie in Fig. 15. Fig. 30 zeigt ein mögliches Dialogfenster, das der lokalen Schlüssel-ID zugeordnet ist, Fig. 31 zeigt ein mögliches Dialog fenster für die dem entfernten Partner zugeordnete Schlüssel-ID, während Fig. 32 eine Möglichkeit für ein Dialogfenster zeigt, das Schlüssel-Einzelheiten zugeordnet ist. Fig. 33 zeigt ein mögliches Dialogfenster, das sich auf die Übertragung des öffentlichen Schlüssels auf eine andere Datei bezieht.

Die Fig. 34 bis 41 zeigen verschiedene Computer-Bildschirmdar stellungen, die dem Benutzer dargeboten werden können, nachdem er das NACHFÜHR-Fenster in der Bildschirmdarstellung nach Fig. 14 ausgewählt hat. Fig. 34 zeigt eine Bildschirmdarstellung auf dem Computer-Bildschirm 116, 118, bei dem zwei EDI-Nachrichten ausgesandt wurden, eine zwischen SEARS und CISCO, und eine zwischen ME und THEM, wobei dieses lediglich ein Beispiel darstellt. Fig. 35 zeigt eine mögliche Darstellung auf dem Computer-Bildschirm 116, 118 des elektronischen Datenaustausches zwischen den Handelspartnern und zeigt die Nicht-Zurückweisung des Empfanges in Form der AUTACK-Nachricht, wobei der AUTACK-Status auf dem Computer-Bildschirm 116, 118 gemäß der vorliegen den Erfindung dargestellt wird. Fig. 36 zeigt eine mögliche Dar stellung der EDI-Daten auf dem Computerbildschirm 116, 118, nachdem das BETRACHTE-EDI-DATEN-Dialogfenster in der Bildschirm-Dar stellung nach Fig. 35 ausgewählt wurde. Die Fig. 37, 38 zeigen mögliche Bildschirmdarstellungen auf dem Computer-Bild schirm 116, 118 zur Auswahl von Nachführkriterien. Fig. 39 zeigt eine mögliche Bildschirmdarstellung auf dem Computer-Bildschirm 116, 118 eines Audit-Protokolls, wobei die Fig. 40, 41 mögliche Bildschirmdarstellungen auf dem Computer-Bildschirm 116, 118 zur Auswahl von Audit-Protokoll-Auswahlkriterien zeigen.

Unter Bezugnahme auf Fig. 2 wird nunmehr das bevorzugte Ver fahren der Berechtigungsüberprüfung oder Authentizierung und der Nichtzurückweisung des Ursprunges gemäß dem derzeit bevorzug ten Verfahren der vorliegenden Erfindung beschrieben. Wie dies in Fig. 2 gezeigt und bevorzugt wird, stellt ein Block 200 einen typischen elektronischen Datenaustausch oder EDI-Austausch gemäß der vorliegenden Erfindung dar. Der Block 202 stellt die bevor zugte Aktion des Servers am senderseitigen Ende bezüglich dieses EDI-Austausches gemäß dem Verfahren der vorliegenden Erfindung dar. Wie dies gezeigt ist und bevorzugt wird, berechnet der sendeseitige Server vorzugsweise den MD5-Wert für den gesamten EDI-Austausch, wie z. B. von ISA bis zum letzten Zeichen von IEA (als MD5EDIINTERCHANGE) bezeichnet. Dieser Wert wird dann vorzugsweise in eine vorgegebene Position in der AUTACK-Nach richt eingefügt, wie z. B. vorzugsweise in das zweite Element des Segmentes USY in der AUTACK-Nachricht. Der sendeseitige Server berechnet dann vorzugsweise den MD5-Wert der AUTACK-Nach richt, beispielsweise vorzugsweise von dem ersten Zeichen von USH bis zum ersten Zeichen von UST. Der sendeseitige Server signiert dann vorzugsweise die AUTACK-Nachricht, indem er den MD5-Wert mit dem privaten Schlüssel des Senders verschlüsselt. Dieser berechnete Wert wird dann vorzugsweise an eine vorge gebene Stelle in der AUTACK-Nachricht eingefügt, z. B. vorzugs weise als das erste Element des Segmentes USR in der AUTACK-Nach richt. Der Block 204 stellt eine typische AUTACK-Nachricht gemäß dem bevorzugten Verfahren der vorliegenden Erfindung dar, nachdem der sendeseitige Server die in dem Block 202 angegebene Aktion ausgeführt hat. Die AUTACK-Nachricht 204 wird dann vor zugsweise zum empfängerseitigen Server übertragen, an dem die in dem Block 206 gezeigte Empfänger-Aktion und Überprüfung vor zugsweise erfolgt. Wenn der EDI-Austausch verschlüsselt ist, so entschlüsselt der empfängerseitige Server ihn vorzugsweise und berechnet den MD5-Wert des empfangenen EDI-Austausches. Unter der Annahme, daß eine Nichtzurücksweisung des Ursprunges gewünscht oder beantragt ist, so entschlüsselt der empfänger seitige Server dann vorzugsweise unter Verwendung des öffent lichen Schlüssels des Absenders den Inhalt des ersten Elementes des USR-Segmentes in der AUTACK-Nachricht 204, was die Stelle ist, an der der sendeseitige Server den MD5-Wert der AUTACK eingefügt hat. Der auf diese Weise durch die Entschlüsselung gewonnene Wert ist der MD5-Wert der AUTACK-Nachricht, in dem vorstehenden Beispiels von dem ersten Zeichen von USH bis zum ersten Zeichen von UST. Der empfängerseitige Server berechnet dann vorzugsweise den MD5-Wert der AUTACK-Nachricht und ver gleicht den berechneten Wert von MD5 mit dem Wert von MD5, der durch Entschlüsseln des Inhaltes des ersten Elementes des USR-Segmentes in der AUTACK-Nachricht gewonnen wurde. Wenn beide Werte vom MD5 gleich sind, so weiß der empfängerseitige Server, daß die Integrität der AUTACK-Nachricht aufrechterhalten wurde und daß eine Nichtzurückweisung des Ursprunges festgestellt wird. Der empfängerseitige Server vergleicht dann vorzugsweise den MD5-Wert des EDI-Austausches mit dem MD5-Wert in dem USY-Segment der AUTACK-Nachricht, was die Stelle darstellt, an der der sendeseitige Server den MD5-Wert des EDI-Austauches einge setzt hat, und wenn die beiden MD5-Werte gleich sind, so weiß der empfängerseitige Server, daß die Integrität des EDI-Daten austausches aufrechterhalten wurde, die Authentizität wird verifiziert, und die Nichtzurückweisung des Ursprunges wird festgestellt.

Unter Bezugnahme auf Fig. 3 wird nunmehr der bevorzugte Vorgang der Nichtzurückweisung des Empfanges gemäß dem derzeit bevor zugten Verfahren der vorliegenden Erfindung beschrieben. Wie dies im Block 208 gezeigt und bevorzugt ist, ist die Aktion des empfängerseitigen Servers bei der Überprüfung der Integrität und Authentizität bzw. Berechtigung des empfangenen EDI-Daten austausches vorzugsweise so, wie sie weiter oben anhand des Blockes 206 nach Fig. 2 beschrieben wurde. Danach erzeugt der empfängerseitige Server vorzugsweise eine neue AUTACK-Nachricht, wie z. B. die AUTACK-Nachricht, die im Block 210 dargestellt ist, und überträgt die neue AUTACK-Nachricht 210 an den sendeseitigen Server zur Überprüfung durch den ursprünglichen sendeseitigen Server, wie dies durch den Block 212 dargesellt ist. Wie dies in Fig. 3 gezeigt und bevorzugt wird, besetzt der empfänger seitige Server bei der Erzeugung der neuen AUTACK-Nachricht vorzugsweise alle Segmente und Elemente in geeigneter Weise, wie z. B. alle Segmente und Elemente bis zu und einschließlich von USD. Der empfängerseitige Server berechnet dann vorzugsweise den MD5-Wert der neuen AUTACK-Nachricht, wie z. B. von USH bis zum ersten Zeichen von UST, und signiert den berechneten MD5-Wert mit dem privaten Schlüssel des Empfängers. Der empfänger seitige Server fügt dann vorzugsweise den digital signierten MD5-Wert an eine vorgegebene Stelle in der neuen AUTACK-Nach richt ein, beispielsweise als das erste Element des USR-Segmen tes. Der empfängerseitige Server besetzt dann vorzugsweise die UNT- und UNZ-Segmente der neuen AUTACK-Nachricht in geeigneter Weise und überträgt die so erzeugte neue AUTACK-Nachricht an den ursprünglichen sendeseitigen Server. Der ursprüngliche sendeseitige Server überprüft dann vorzugsweise die digitale Signatur der empfangenen neuen AUTACK-Nachricht, indem er diese mit dem öffentlichen Schlüssel des Empfängers entschlüsselt, wobei der durch diese Entschlüsselung gewonnene Wert der MD5-Wert der empfangenen neuen AUTACK-Nachricht ist. Der ursprüng liche sendeseitige Server berechnet dann den MD5-Wert der emp fangenen neuen AUTACK-Nachricht und vergleicht diesen mit dem Wert von MD5, der durch den Entschlüsselungsvorgang gewonnen wurde. Wenn die beiden Werte von MD5 gleich sind, so weiß der ursprüngliche sendeseitige Server, daß die Integrität der neuen AUTACK-Nachricht aufrechterhalten wurde, und die Nichtzurück weisung des Ursprunges der neuen AUTACK-Nachricht wird festge stellt. Der ursprüngliche sendeseitige Server weiß weiterhin, daß, wenn der MD5-Wert, der in dem USY-Segment der empfangenen neuen AUTACK-Nachricht in dem vorstehenden Beispiel enthalten ist, gleich dem MD5-Wert des vorher übertragenen EDI-Austausches ist und die Bestätigung positiv ist (wie dies vorzugsweise durch Überprüfen des Sicherheitscodes in der neuen AUTACK-Nacricht festgestellt wird) der betreffende EDI-Austausch sowohl bei dem Absender als auch beim Empfänger bekannt ist, weil der MD5-Wert des Austausches und die Austauschnummer in der AUTACK-Nachricht enthalten sind und in richtiger Weise erkannt wurden. Zusätzlich wurde die Integrität und Authentizität des EDI-Austausches bei dem Empfang überprüft, und der empfängerseitige Server bestrei tet nicht, den betreffenden EDI-Austausch empfangen zu haben.

In den Fig. 4 und 5 ist ein Prozeß-Ablaufdiagramm des derzeit bevorzugten Verfahrens des Empfangens bzw. Sendens von E-Mail gemäß dem derzeit bevorzugten Verfahren der vorliegenden Er findung gezeigt. In dieser Hinsicht ist TEMPLAR, das Steuer gerät zur Ausführung des derzeit bevorzugten Verfahrens der vorliegenden Erfindung vorzugsweise zwischen dem üblichen "Mailer", d. h. dem Gerät zur eigentlichen E-Mail-Übertragung, und der von dem Benutzer angegebenen rohen EDI-Datei auf den sende- und empfangsseitgen Systemen angeordnet, wobei das übliche Sendmail-Programm, das sowohl für UNIX-x-WINDOW-Systeme oder MICROSOFT-WINDOWS-Betriebssysteme erhältlich ist, vorzugs weise zum Senden und Empfangen von Mail verwendet wird, wobei die Mail, die abgesandt und empfangen wird, vorzugsweise dem MIME-Protokoll gehorcht, und wobei das bekannte PKCS-Programm vorzugsweise zum Verschlüsseln und Entschlüsseln der MIME- codierten Hauptteile verwendet wird. Vorzugsweise werden die MIME-Identifikatoren nicht verschlüsselt. Wie dies weiter oben erwähnt wurde, wird vorzugsweise die EDIFACT-AUTACK-Nachricht zur Lieferung einer sicheren Authentizierung, Nichtzurückweisung des Ursprunges und/oder des Empfanges und Bestätigung oder Ver weigerung der Bestätigung oder Verweigerung der Bestätigung für eine oder mehrere X.12- oder EDIFACT-Umschläge verwendet. Vor zugsweise werden mehrfache EDI-Umschläge als ein Datenblock in dem System der vorliegenden Erfindung betrachtet. Vorzugsweise wird, wenn die Nachrichtenintegrität einer empfangenen AUTACK-Nachricht nicht gegeben ist, eine Bestätigung des Empfanges nicht an den ursprünglichen Absender der Nachricht zurückge sandt, obwohl das System ohne weiteres so modifiziert werden kann, daß dies durchgeführt wird, wenn es erwünscht ist.

Die Fig. 6 bis 9 sind Prozeßablaufdiagramme bezüglich der Handelspartner-Verwaltung, der Audit-Protokollverwaltung bzw. der Auftragsüberwachung gemäß dem derzeit bevorzugten Verfahren der vorliegenden Erfindung. Diese Diagramme sind aus sich heraus verständlich, wenn sie in Verbindung mit der vorstehenden Er läuterung betrachtet werden, so daß sie hier nicht ausführlicher erläutert werden.

Fig. 10 ist ein funktionelles Diagramm der Organisation des derzeit bevorzugten Verfahrens der vorliegenden Erfindung, wie es durch die Skripten der Tabelle A und die vorstehende Erläuterung dargesellt ist, und dieses Diagramm wird aus diesem Grunde nicht näher erläutert.

Schließlich bilden die Fig. 11 bis 13 ein Prozeßablaufdiagramm des derzeit bevorzugten Verfahrens der vorliegenden Erfindung gemäß der vorstehenden Beschreibung, wobei die Fig. 11 ver schiedene Schritte der Überprüfung der Integrität der AUTACK-Nachricht, des EDI-Austausches und des Zertifikates zeigen, wobei NRO die Nichtzurückweisung des Ursprunges und NRR die Nichtzurückweisung des Empfanges darstellt. Fig. 12 zeigt den Teil des Verfahrens, der auf die TPA-Verarbeitung bezogen ist. Fig. 13 zeigt den Teil des Verfahrens der vorliegenden Erfin dung, der sich auf die Verarbeitung der öffentlichen und pri vaten Schlüssel sowie von TPA bei der Ausführung des Verfahrens gemäß der vorliegenden Erfindung in der vorstehend beschriebenen Weise bezieht.

Somit wird durch die Verwendung der AUTACK-Nachricht als ein Dokument für die digitale Unterzeichnung oder Signatur, die auf der Grundlage eines Systems mit einem öffentlichen und einem privaten Schlüssel signiert wird, wie z. B. RSA, ein wirkungsvolles, äußerst sicheres Mailverfahren für den elek tronischen Datenaustausch über ein offenes Netz, wie z. B. das INTERNET, geschaffen, bei dem die Handelspartner sehr einfach eine sichere Verifikation und Authentizierung und eine Nicht-Zu rückweisung sowohl des Ursprunges als auch des Empfanges erzielen können, was bei sich schnell bewegenden elektronischen Geschäftstransaktionen über einen weit verstreuten geographi schen Bereich von Bedeutung ist, in dem ein offenes Netz das am besten geeignete Kommunikationsmedium darstellt.

Claims

1. Kommunikationssystem zum selektiven Verbinden einer Vielzahl von Computern über ein offenes öffentliches Netz, über das die Computer gesicherte digitale Nachrichten zwischen einem jeweiligen senderseitigen Rechner und einem jeweiligen empfän gerseitigen Rechner der Vielzahl von Computern austauschen, wobei der senderseitige Computer einen ersten zugehörigen öffentlichen Schlüssel und einen ersten zugehörigen privaten Schlüssel aufweist, wobei der empfängerseitige Computer einen zweiten zugehörigen öffentlichen Schlüssel und einen zweiten zugehörigen privaten Schlüssel aufweist und die digitalen Nachrichten eine EDI-(elektronische Datenaustausch-) Kommunika tion zwischen dem senderseitigen Computer und dem empfänger seitigen Computer umfassen und wobei die EDI-Datenaustausch-Kom munikation eine zugehörige EDI-Bestätigungsnachricht aufweist, gekennzeichnet durch:
Einrichtungen zur Berechnung eines ersten Hash-Codes für die EDI-Datenaustausch-Kommunikation von dem senderseitigen Computer,
Einrichtungen zur Einfügung des ersten Hash-Codes an einer vorgegebenen Stelle in der zugehörigen EDI-Bestäti gungsnachricht,
Einrichtungen zur Berechnung eines zweiten Hash-Codes der zugehörigen EDI-Bestätigungsnachricht;
Einrichtungen zum digitalen Signieren der zugehörigen EDI-Bestätigungsnachricht, die Einrichtungen zum Verschlüsseln des zweiten Hash-Codes mit dem privaten Schlüssel des sender seitigen Computers umfassen;
Einrichtungen zum Einfügen des zweiten Hash-Codes an einer vorgegebenen Stelle in der zugehörigen EDI-Bestätigungs nachricht,
Einrichtungen zur Übertragung der EDI-Datenaustausch-Kom munikation zusammen mit der digital signierten zugehörigen EDI-Bestätigungsnachricht an den empfangsseitigen Computer über das offene öffentliche Netz, und
dem empfangsseitigen Computer zugeordnete Einrichtungen zum Empfang und zur Verarbeitung der empfangenen EDI-Daten austausch-Kommunikation und der digital signierten EDI-Bestätigungsnachricht zur Erzielung einer Authentizierung und Nicht-Zurückweisung der EDI-Datenaustausch-Kommunikation von dem senderseitigen Computer, wobei diese Einrichtungen Einrichtungen zum Entschlüsseln des verschlüsselten zweiten Hash-Codes mit dem öffentlichen Schlüssel des senderseitigen Computers umfassen, so daß gesicherte private EDI-Daten austausch-Kommunikationen über ein offenes öffentliches Netz erfolgen können, während gleichzeitig eine Authentizie rung und Nicht-Zurückweisung der EDI-Datenaustausch-Kommu nikationen erzielt wird.

2. Kommunikationssystem nach Anspruch 1, dadurch gekennzeichnet, daß die dem empfängerseitigen Computer zugeordneten Einrichtungen weiterhin Einrichtungen zur Berechnung eines dritten Hash-Codes der empfangenen EDI-Bestätigungsnachricht und Einrichtungen zum Vergleich des dritten Hash-Codes mit dem entschlüsselten zweiten Hash-Code von der empfangenen EDI-Bestätigungsnachricht umfassen, wobei die Vergleichereinrichtungen Einrichtungen zur Lie ferung einer Anzeige der Integrität der EDI-Bestätigungs-Nach richt und der Nicht-Zurückweisung des Ursprunges um fassen, wenn der entschlüsselte zweite Hash-Code und der dritte Hash-Code übereinstimmen.

3. Kommunikationssystem nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die dem empfängerseitigen Computer zugeordneten Einrichtungen weiterhin Einrichtungen zur Berechnung eines vierten Hash-Codes der empfangenen EDI-Datenaustausch-Kommunikation und Einrichtungen zum Vergleich des vierten Hash-Codes der empfangenen EDI-Datenaustausch-Kom munikation mit dem ersten Hash-Code in der empfangenen EDI-Bestätigungsnachricht umfassen, wobei die Vergleichereinrich tungen Einrichtungen zur Lieferung einer Anzeige der Integrität und zur Überprüfung der Authentizität der EDI-Datenaustausch-Kom munikation und der Nicht-Zurückweisung des Ursprunges umfassen, wenn der erste und der dritte Hash-Code übereinstimmen.

4. Kommunikationssystem nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß die dem empfängerseitigen Computer zugeordneten Einrichtungen weiterhin Einrichtungen zur Er zeugung einer Antwort-EDI-Bestätigungsnachricht und zur Über tragung der Antwort-EDI-Bestätigungsnachricht an den sender seitigen Computer über das offene öffentliche Netz umfassen, wobei die Einrichtungen zur Erzeugung einer Antwort-EDI-Be stätigungsnachricht Einrichtungen zur Berechnung eines fünften Hash-Codes der Antwort-EDI-Bestätigungsnachricht und zur digitalen Signierung des fünften Hash-Codes durch Verschlüsseln des fünften Hash-Codes mit dem privaten Schlüssel des empfängerseitigen Computers sowie Einrichtungen zum Einfügen des digital signierten fünften Hash-Codes an eine vorgegebene Stelle in der übertragenen Antwort-EDI-Be stätigungsnachricht umfassen.

5. Kommunikationssystem nach Anspruch 4, dadurch gekennzeichnet, daß weiterhin dem sendeseitigen Computer Einrichtungen zum Empfang der übertragenen Ant wort-EDI-Bestätigungsnachricht und zum Entschlüsseln des ver schlüsselten fünften Hash-Codes mit dem öffentlichen Schlüssel des empfängerseitigen Computers zugeordnet sind, um die digitale Signatur der Antwort-EDI-Bestätigungsnachricht zu verifizieren, und daß Einrichtungen zur Berechnung eines sechsten Hash-Codes der empfangenen Antwort-EDI-Bestätigungsnachricht und Einrich tungen zum Vergleich des sechsten Hash-Codes mit dem entschlüsselten fünften Hash-Code vorgesehen sind, wobei die Vergleichereinrichtungen Einrichtungen zur Lieferung einer Anzeige der Integrität der empfangenen Antwort-EDI-Be stätigungsnachricht und der Nichtzurückweisung des Ursprunges der Antwort-EDI-Bestätigungsnachricht umfassen, so daß die Nichtzurückweisung des Empfanges der EDI-Datenaustausch- Kommunikation durch den senderseitigen Computer festgestellt wird.

6. Kommunikationssystem nach Anspruch 4 oder 5, dadurch gekennzeichnet, daß die Einrichtungen zur Erzeugung der Antwort-EDI-Bestätigungsnachricht weiterhin Einrichtungen zum Einfügen des vierten Hash-Codes an einer vorgegebenen Stelle in die übertragene Antwort-EDI-Bestätigungsnachricht umfassen, und daß die dem sendeseitigen Computer zugeordneten Einrichtungen weiterhin Einrichtungen zum Vergleich des vierten Hash-Codes in der empfangenen Antwort-EDI-Bestäti gungsnachricht mit dem ersten Hash-Code umfassen, wobei die Vergleichereinrichtungen eine Anzeige der Integrität und Authentizität des EDI-Datenaustausches liefern, wenn der ersten und vierte Hash-Code übereinstimmen.

7. Kommunikationssystem nach Anspruch 1, dadurch gekennzeichnet, daß die dem empfängerseitigen Computer zugeordneten Einrichtungen weiterhin Einrichtungen zur Er zeugung einer Antwort-EDI-Bestätigungsnachricht und zur Über tragung der Antwort-EDI-Bestätigungsnachricht an den sender seitigen Computer über das offene öffentliche Netz umfassen, wobei die Einrichtungen zur Erzeugung einer Antwort-EDI-Be stätigungsnachricht Einrichtungen zur Berechnung eines dritten Hash-Codes der Antwort-EDI-Bestätigungsnachricht und zur digitalen Signierung des dritten Hash-Codes durch Verschlüsseln des dritten Hash-Codes mit dem privaten Schlüssel des empfängerseitigen Computers sowie Einrichtungen zum Einfügen des digital signierten dritten Hash-Codes an eine vorgegebene Stelle in der übertragenen Antwort-EDI-Be stätigungsnachricht umfassen.

8. Kommunikationssystem nach Anspruch 7, dadurch gekennzeichnet, daß weiterhin dem senderseitigen Computer Einrichtungen zum Empfang der übertragenen Ant wort-EDI-Bestätigungsnachricht und zum Entschlüsseln des ver schlüsselten dritten Hash-Codes mit dem öffentlichen Schlüssel des empfängerseitigen Computers zugeordnet sind, um die digitale Signatur der Antwort-EDI-Bestätigungsnachricht zu verifizieren, und daß Einrichtungen zur Berechnung eines vierten Hash-Codes der empfangenen Antwort-EDI-Bestätigungsnachricht und Einrich tungen zum Vergleich des vierten Hash-Codes mit dem entschlüsselten dritten Hash-Code vorgesehen sind, wobei die Vergleichereinrichtungen Einrichtungen zur Lieferung einer Anzeige der Integrität der empfangenen Antwort-EDI-Be stätigungsnachricht und der Nichtzurückweisung des Ursprunges der Antwort-EDI-Bestätigungsnachricht umfassen, so daß die Nichtzurückweisung des Empfanges der EDI-Datenaustausch-Kom munikation durch den senderseitigen Computer festgestellt wird.

9. Kommunikationssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die EDI-Bestätigungsnachricht eine AUTACK-Nachricht umfaßt.

10. Kommunikationssystem nach einem oder mehreren der Ansprüche 4 bis 9, dadurch gekennzeichnet, daß die Antwort-EDI-Bestätigungs nachricht eine AUTACK-Nachricht umfaßt.

11. Kommunikationssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß jeder der Hash-Codes einen MD5-Wert bildet.

12. Kommunikationssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die öffentlichen und privaten Schlüssel ein verschlüsseltes Kommunikationssystem vom RSA-Typ bilden.

13. Kommunikationssystem nach einem oder mehreren der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß das offene öffentliche Netzwerk das Internet ist.

14. Kommunikationssystem nach einem der vorhergehenden Ansprüche, gekennzeichnet durch Einrichtungen zur Erzeugung einer Handels partner-Vereinbarungs-Kommunikation zwischen dem senderseitigen Computer und dem empfängerseitigen Computer, wobei der sender seitige Computer und der empfängerseitige Computer die Handels partner bilden und wobei die Handelspartner-Vereinbarungs-Kom munikation die öffentlichen Schlüssel in der EDI-Datenaus tausch-Kommunikation umfaßt, um es den Handelspartnern zu er möglichen, einander eine Zertifizierung und Bestätigung zu liefern.

15. Verfahren zum selektiven Verbinden einer Vielzahl von Computern über ein offenes öffentliches Netz zur Erzielung eines Computer-Datenaustausches von privaten gesicherten digitalen Nachrichten zwischen einem jeweiligen senderseitigen Computer und einem jeweiligen empfängerseitigen Computer der Vielzahl von Computern, wobei der senderseitige Computer einen ersten zugehörigen öffentlichen Schlüssel und einen ersten zugehörigen privaten Schlüssel und der empfängerseitige Computer einen zweiten zugehörigen öffentlichen Schlüssel und einen zweiten zugehörigen privaten Schlüssel aufweist, und wobei die digitalen Nachrichten eine EDI-Datenaustausch-Kom munikation zwischen dem senderseitigen Computer und dem empfängerseitigen Computer umfassen, wobei die EDI-Daten austausch-Kommunikation eine zugehörige EDI-Bestätigungs-Nach richt aufweist, dadurch gekennzeichnet, daß das Verfahren die folgenden Schritte umfaßt: digitales Signieren der zugehörigen EDI-Bestätigungsnachricht mit dem privaten Schlüssel des sender seitigen Computers, Übertragen der EDI-Datenaustausch-Kom munikation zusammen mit der zugehörigen digital signier ten EDI-Bestätigungsnachricht über das offene öffentliche Netzwerk an den empfängerseitigen Computer und Verarbeiten der empfangenen digital signierten EDI-Bestätigungsnachricht zur Lieferung einer Authentizierung und Nichtzurückweisung der EDI-Datenaustausch-Kommunikation von dem senderseitigen Computer, wobei der Verarbeitungsschritt den Schritt der Verarbeitung der empfangenen digital signierten zugehörigen EDI-Bestätigungs-Nachricht mit dem öffentlichen Schlüssel des Senders umfaßt, so daß gesicherte private EDI-Datenaus tausch-Kommunikationen über ein offenes öffentliches Netz werk erfolgen können, während sich eine Authentizierung und Nichtzurückweisung der EDI-Kommunikationen unter Ver wendung der zugehörigen EDI-Bestätigungsnachricht ergibt.

16. Verfahren nach Anspruch 15, gekennzeichnet durch die Schritte der Erzeugung einer Antwort-EDI-Bestätigungsnachricht von dem empfängerseitigen Computer, digitales Signieren der Antwort-EDI-Bestätigungsnachricht mit dem privaten Schlüssel des empfängerseitigen Computers; Übertragen der digital signierten Antwort-EDI-Bestätigungs nachricht über das offene öffentliche Netzwerk an den sender seitigen Computer, wobei der senderseitige Computer die digital signierte Antwort-EDI-Bestätigungsnachricht empfängt, und Verarbeiten der empfangenen digital signierten Ant wort-EDI-Bestätigungsnachricht zur Erzielung einer Nichtzurück weisung des Empfanges der EDI-Datenaustausch-Kommunikation durch den senderseitigen Computer, wobei der Verarbeitungs schritt den Schritt der Verarbeitung der empfangenen digi tal signierten Antwort-EDI-Bestätigungsnachricht mit dem öffentlichen Schlüssel des empfängerseitigen Computers um faßt, so daß die Nichtzurückweisung des Empfanges der EDI-Datenaustausch-Kommunikation durch den senderseitigen Com puter festgestellt wird.

17. Verfahren nach Anspruch 15 oder 16, dadurch gekennzeichnet, daß der Verarbeitungsschritt weiter hin den Schritt der Lieferung einer Nichtzurückweisung des Ursprungs an dem empfängerseitigen Computer aus der empfan genen EDI-Bestätigungsnachricht umfaßt.

18. Verfahren nach einem der Ansprüche 15 bis 17, dadurch gekennzeichnet, daß das offene öffentliche Netz werk das Internet ist.

19. Verfahren nach einem der Ansprüche 15 bis 18, dadurch gekennzeichnet, daß die EDI-Bestätigungsnachricht eine AUTACK-Nachricht ist.

20. Verfahren nach einem der Ansprüche 16 bis 19, dadurch gekennzeichnet, daß die Antwort-EDI-Bestätigungs nachricht eine AUTACK-Nachricht ist.

21. Verfahren nach einem der Ansprüche 15 bis 20, dadurch gekennzeichnet, daß die öffentlichen und privaten Schlüssel ein verschlüsseltes Kommunikationssystem vom RSA-Typ bilden.