DE19622629A1 - Verfahren zur kryptographischen Sicherung einer Übertragung mindestens eines Datenpakets von einer ersten Computereinheit zu einer zweiten Computereinheit unter Verwendung des Remote Procedure Call Verfahrens - Google Patents

Verfahren zur kryptographischen Sicherung einer Übertragung mindestens eines Datenpakets von einer ersten Computereinheit zu einer zweiten Computereinheit unter Verwendung des Remote Procedure Call Verfahrens

Info

Publication number
DE19622629A1
DE19622629A1 DE19622629A DE19622629A DE19622629A1 DE 19622629 A1 DE19622629 A1 DE 19622629A1 DE 19622629 A DE19622629 A DE 19622629A DE 19622629 A DE19622629 A DE 19622629A DE 19622629 A1 DE19622629 A1 DE 19622629A1
Authority
DE
Germany
Prior art keywords
computer unit
data packet
cryptographic
xdr
transformation
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
DE19622629A
Other languages
English (en)
Inventor
Martin Euchner
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Priority to DE19622629A priority Critical patent/DE19622629A1/de
Publication of DE19622629A1 publication Critical patent/DE19622629A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/133—Protocols for remote procedure calls [RPC]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

Es sind eine Reihe unterschiedlicher Systeme und Ansätze be­ kannt, die auf dem Prinzip des Remote Procedure Calls (RPC) basieren.
Bei dem Prinzip des Remote Procedure Calls geht es um die Nachbildung des sogenannten Prinzips des "lokalen" Proze­ duraufrufs oder Funktionsaufrufs in verteilten, offenen Sy­ stemen von Computereinheiten. In allen RPC-basierten Systemen wird dabei ein RPC-Aufruf dazu verwendet, Daten zwischen ei­ ner ersten Computereinheit und einer zweiten Computereinheit unidirektional oder bidirektional zu übertragen. Im Rahmen eines Kommunikations-Architektur-Modells ist oberhalb der so­ genannten Transportschicht eine sogenannte RPC-Schicht vorge­ sehen. In der RPC-Schicht wird zum einen der Aufbau der Kom­ munikationsverbindung zwischen der ersten Computereinheit und der zweiten Computereinheit und zum anderen die Codierung und Decodierung der zu übertragenden Daten in eine Darstellung durchgeführt, die der Empfängereinheit bekannt ist. Die Daten werden entweder in einem festen, standardisierten Format für die Übertragung über die Kommunikationsverbindung codiert, dem sogenannte Network Byte Ordering, unabhängig vom jeweils lokal verwendeten Byte Ordering, oder die Empfängereinheit muß ggf. eine entsprechende Decodierung durchführen, falls das Byte Ordering unterschiedlich von demjenigen der Sende­ einheit ist. Dies entspricht einer Berücksichtigung der loka­ len, von der Empfängereinheit verwendeten lokalen Syntax.
Vor allem bei verteilen, offenen Systemen besteht das Bedürf­ nis, zu übertragende Daten vor Mißbrauch jeglicher Art gegen­ über Dritten zu sichern. Hieraus folgt das Erfordernis, die Informationssicherheit bei der Kommunikation von RPC-basierten Systemen zu berücksichtigen.
Es sind verschiedene Möglichkeiten bekannt, wie die Informa­ tionssicherheit bei der Kommunikation von RPC-basierten Sy­ stemen berücksichtigt werden kann [1], [2], [3], [4]. Bei diesen Verfahren geht es in erster Linie um die Vertraulich­ keit und die Integrität der zwischen der ersten Computerein­ heit und der zweiten Computereinheit zu übertragenden Daten. Ferner müssen sich die erste Computereinheit und die zweite Computereinheit gegenseitig authentifizieren, um einen au­ thentischen Sitzungsschlüssel zur Sicherung der zu übertra­ genden Daten auszutauschen. Die in den Dokumenten [1] und [2] beschriebenen Verfahren basieren auf einem reinen symmetrischen Schlüsselmanagement, bei dein allerdings ein sogenanntes zentrales On-Line-Schlüsselmanagement-Center erforderlich ist.
Ferner ist ein RPC-basiertes System, welches den sogenannten Kerberos-Authentifikationsdienst verwendet, bekannt [5], [6]. Bei diesem Verfahren sind bereits Sicherheitsfunktionen für die Sicherheitsdienste Vertraulichkeit, Integrität und Au­ thentifikation vorhanden. Allerdings sind die verwendeten Si­ cherheitsalgorithmen bei diesem Verfahren auf nur einen te­ sten Algorithmus, den sog. Data-Encryption-Standard (DES) be­ schränkt. Ferner weist der Kerberos-Authentifikationsdienst prinzipiell einige Sicherheitsschwächen auf, die ebenso in dem RPC-basierten System, welches das Kerberos-Authenti­ fikationsverfahren verwendet, vorhanden ist. Die Si­ cherheitsschwächen und Nachteile des Kerberos-Authenti­ fikationsdienstes sind beispielsweise aus dem Doku­ ment [7] bekannt.
Ein weiteres RPC-Verfahren, welches sehr große Verbreitung gefunden hat, ist beispielsweise aus den Dokumenten [8], [9] und [10] bekannt. Bei diesen Verfahren existiert lediglich eine Option zur Authentifikation der ersten Computereinheit bzw. der zweiten Computereinheit. Dabei kann zwischen einem sogenannten "schwachen" Authentifikationsmechanismus, bei­ spielsweise einer Paßwortabtrage, oder eines "starken" Au­ thentifikationsmechanismus, bei dem die Authentifikation un­ ter Verwendung des Diffie-Hellmann-Schlüsselaustauschs und dem DES-Verfahren gewählt werden kann. Die Option des starken Authentifikationsmechanismus ist aufgrund von Exportrestrik­ tionen der Vereinigten Staaten nicht außerhalb der USA ver­ fügbar. Desweiteren sind die bei der Verwendung des Diffi-Hellmann-Schlüsselaustauschs verwendeten Schlüssel nach heu­ tigem Stand der Technik wegen der Effizienz von Logarithmen-Attacken nicht mehr sicher, da deren Schlüssel in ihrer Länge auf 192 Bits beschränkt sind. Außerdem sind keine Mechanismen zur Gewährleistung der Datensicherheit, wie beispielsweise der Vertraulichkeit und Integrität der übertragenen Daten, vorgesehen. Somit sind in dem aus den Dokumenten [8], [9] und [10] bekannten Verfahren nur wenige Sicherheitsfunktionen mit beschränkter Sicherheit mit fest vorgegebenen Krypto-Algorithmen vorgesehen.
Der Erfindung liegt das Problem zugrunde, die auf einem aus den Dokumenten [8], [9], [10] bekannten RPC-Verfahren basie­ rende Übertragung von Daten zwischen zwei Computereinheiten zu sichern, ohne daß der Quellcode von den aus den Dokumenten [8], [9], [10] bekannten Verfahren geändert werden muß.
Das Problem wird durch das Verfahren gemäß Patentanspruch 1 gelöst.
Es wird in einer ersten Computereinheit ein Remote Procedure Call (RPC) generiert und von einem Remote Procedure Call Pro­ zeß (RPCP) verarbeitet. Von dem Remote Procedure Call Prozeß (RPCP) wird eine Transformationsfunktion aufgerufen, mit der ein zu übertragendes Datenpaket in eine Network Byte Order Darstellung überführt wird. Im Rahmen dieser Transformation wird ein kryptographisches Verfahren auf das Datenpaket ange­ wendet, wodurch eine beliebige Art kryptographischer Siche­ rung des Datenpakets möglich ist. Nach Übertragung des Daten­ pakets zu-der zweiten Computereinheit wird das Datenpaket ei­ ner zur Transformation inversen Transformation unterzogen. Dabei wird die in der zweiten Computereinheit verwendete lo­ kale Syntax berücksichtigt. Ferner wird bei der inversen Transformation ein inverses kryptographisches Verfahren auf das Datenpaket angewendet, wodurch die kryptographische Si­ cherung der Übertragung gewährleistet wird.
Durch das Verfahren wird es möglich, kryptographische Verfah­ ren in das RPC-Verfahren zu integrieren und somit eine Daten­ übertragung, welche auf dem aus den Dokumenten [8], [9], [10] bekannten RPC-Verfahren beruht, kryptographisch abzusichern, ohne daß dabei der Quelltext (Source-Code) der eigentlichen RPC-Prozedur geändert werden muß. Ferner ist ein Vorteil des Verfahrens darin zu sehen, daß eine kryptographische Absiche­ rung bei einem RPC-Verfahren möglich wird, ohne daß der Quelltext (Source-Code) der jeweiligen Anwendung (Applikation) selbst verändert werden muß.
Ein weiterer Vorteil ist bei diesem Verfahren darin zu sehen, daß die Wahl der zu verwendenden kryptographischen Verfahren völlig frei ist und somit bekannte Schwächen von verschiede­ nen kryptographischen Verfahren dadurch vermieden werden kön­ nen, daß sichere kryptographische Verfahren eingesetzt wer­ den. Ferner können auf diese Weise auch länderspezifische Ex­ portbeschränkungen vermieden werden. Damit wird ein hohes Maß an Unabhängigkeit von spezifischen Verschlüsselungsalgorith­ men wie dem DES-Verfahren und eine erhöhte Flexibilität des Verfahrens erreicht.
Vorteilhatte Weiterbildungen der Erfindung ergeben sich aus den abhängigen Ansprüchen.
Durch Hinzufügen eines Kopffeldes und/oder eines Trailers zu dem Datenpaket, der oder die Informationen für das kryptogra­ phische Verfahren enthält, wird eine einfache Möglichkeit ge­ boten, die kryptographische Sicherung eines Datenpakets im Rahmen der Transformation in eine Network-Byte-Order-Dar­ stellung durchzuführen.
In einer Weiterbildung des Verfahrens ist es vorteilhaft, daß zu Beginn des Verfahrens eine Authentifikation der ersten Computereinheit und/oder der zweiten Computereinheit durchge­ führt wird. Auf Basis einer durchgeführten Authentifikation der Computereinheiten wird dann das Verfahren durchgeführt. Durch diese Weiterbildung wird die kryptographische Sicher­ heit des Verfahrens weiter erhöht.
Ferner ist es in einer Weiterbildung des Verfahrens vorteil­ haft, zu Beginn des Verfahrens einen kryptographisch abgesi­ cherten Schlüsselaustausch der in dem Verfahren zu verwenden­ den kryptographischen Schlüssel durchzuführen. Durch diese Weiterbildung wird die Sicherheit des Verfahrens weiter er­ höht.
Ferner ist es vorteilhaft, eine Sicherheitspolitik zu Beginn des Verfahrens auszuhandeln, die in dem anschließenden Ver­ fahren verwendet werden soll. Durch das Aushandeln der Si­ cherheitspolitik wird eine erhöhte Flexibilität bei der Durchführung des Verfahrens erreicht, da durch diese Weiter­ bildung sowohl die erste Computereinheit als auch die zweite Computereinheit ihre eigene Sicherheitspolitik mit dem jewei­ ligen Kommunikationspartner aushandeln kann.
Der gleiche Vorteil ist bei der Weiterbildung des Verfahrens gegeben, bei der zu Beginn des Verfahrens das zu verwendende kryptographische Verfahren zwischen den Computereinheiten ausgehandelt wird.
In den Figuren ist ein Ausführungsbeispiel der Erfindung dar­ gestellt und wird im weiteren näher erläutert.
Es zeigen
Fig. 1 eine Skizze, in der allgemein das bekannte Remote Procedure Call-Verfahren dargestellt ist;
Fig. 2 eine Skizze, in der die Erweiterung des bekannten RPC-Mechanismus zur kryptographischen Absicherung dargestellt ist;
Fig. 3 ein Ablaufdiagramm, in dem die einzelnen Ver­ fahrensschritte des Verfahrens dargestellt sind;
Fig. 4a bis 4c Skizzen, in denen eine mögliche Einkapselung eines zu übertragenden Datenpakets mit für das kryptographische Verfahren verwendbarer Information dargestellt ist;
Fig. 5 ein Ablautdiagramm, in dem verschiedene Weiter­ bildungen des Verfahrens, die zu Beginn des Verfahrens durchgeführt werden können, darge­ stellt sind.
In Fig. 1 ist das generelle Prinzip eines Remote Procedure Call-Verfahrens RPC dargestellt. Die RPC-Verfahren sind de­ tailliert in den Dokumenten [8], [9], sowie [10] beschrieben.
Es wird in einer ersten Computereinheit C1 ein Remote Proce­ dure Call RPCA generiert. Eine Remote Procedure Call-Prozedur RPCP verwendet den Remote Procedure Call RPCA, um ein Daten­ paket DP von der ersten Computereinheit C1 zu einer zweiten Computereinheit C2 zu übertragen. Das RPC-Verfahren ist zu­ sammen mit einem sog. RPCL-Protokoll-Compiler aus dem Doku­ ment [11] bekannt. Aus dem Dokument [11] ist ferner eine Syn­ taxbeschreibung der sogenannten abstrakten RPCL-Beschreibungssprache für verschiedene Datenstrukturen be­ kannt. Von dem RPCL-Protokoll-Compiler werden Datenstruktu­ ren, die in der RPCL-Beschreibungssprache dem RPCL-Protokoll-Compiler zugeführt werden, in C-Programmfunktionen in einem C-Programm transformiert und liegen in einem C-Programm als Quelltext (Source Code) vor. Die Beschreibung von Datenstruk­ turen in einer RPCL-Beschreibungssprache ist völlig applika­ tionsspezifisch und dem Fachmann anhand der spezifischen An­ wendung bekannt.
Mit dem RPCL-Protokoll-Compiler werden automatisch aus der abstrakten RPCL-Beschreibung sogenannte XDR-Konvertierungsfunktionen XDR generiert. Mit den XDR-Konvertierungsfunktionen XDR werden die zu übertragenden Da­ ten, also das zu übertragende Datenpaket DP von der ersten Computereinheit C1 in eine einheitliche sogenannte Network-Byte-Order-Darstellung transformiert und bei der zweiten Com­ putereinheit C2 wieder in die lokale Darstellung, also die lokale Syntax der zweiten Computereinheit C2 decodiert.
Bei dem Verfahren zur Übertragung des Datenpakets DP unter Verwendung des RPC-Verfahrens werden die zu verwendenden XDR-Konvertierungsfunktionen XDR als C-Funktions-Pointer an den Remote Procedure Call-Prozeß RPCP übergeben. Die XDR-Konvertierungsfunktionen XDR werden von dem Remote Procedure Call-Prozeß RPCP aufgerufen, um das zu übertragende Datenpa­ ket DP, das beispielsweise C-Datenstrukturen aufweist, in ei­ nen Pufferspeicher PS zu speichern, das Datenpaket DP zu transformieren bzw. invers zu transformieren, jeweils abhän­ gig davon, ob sich der Remote Procedure Call Prozeß RPCP in der ersten Computereinheit C1 oder in der zweiten Compu­ tereinheit C2 befindet.
Ein von dem Remote Procedure Call-Prozeß RPCP generierter RPC-Request oder eine RPC-Antwort wird unter Verwendung eines Transportprotokolls T über eine Übertragungsverbindung ÜV zu der zweiten Computereinheit C2 übertragen. In der zweiten Computereinheit C2 wird das Datenpaket DP empfangen und unter Verwendung des Transportprotokolls T decodiert und dem Remote Procedure Call-Prozeß RPCP der zweiten Computereinheit C2 zugeführt. Als Transportprotokoll T kann beispielsweise das Transmission Control Protocol (TCP) oder auch das User-Datagramm-Protocol (UDP) verwendet werden.
In dem Remote Procedure Call Prozeß RPCP in der zweiten Com­ putereinheit C2 werden inverse XDR-Filterfunktionen IXDR auf­ gerufen, mit denen die Transformation der übertragenen Daten, die in der Network-Byte-Order-Darstellung vorliegen, in eine von der zweiten Computereinheit C2 verwendeten lokalen Syntax durchgeführt.
Angenommen, das Datenpaket DP weist folgende beispielhatte aufgeführte C-Datenstrukturen auf, die beispielsweise als RPC-Request oder als RPC-Antwort von der ersten Computerein­ heit C1 oder der zweiten Computereinheit C2 übertragen werden soll:
Es wird mit typei jeweils ein beliebiger Datentyp bezeichnet und mit componenti wird jeweils der Name des Datenstruktur­ elements beschrieben. Mit n wird jeweils die Anzahl der in der in der Datenstruktur NMC_struct enthaltenen Datenstrukturele­ mente bezeichnet.
Eine zu dem Datenpaket DP korrespondierende, von dem RPCL-Protokoll-Compiler generierte XDR- Filter- Funktion XDR hat dann beispielsweise folgenden Aufbau:
Ein Variablentyp xdr_typei kann beispielsweise entweder eine weitere XDR-Filter-Funktion XDR oder eine elementare Filter-Funktion darstellen. In einer Variable einer Datenstruktur xdrs wird eine Transformationsrichtung angegeben, mit der entweder bezeichnet wird, daß das Datenpaket DP von der C-Datenstruktur-Darstellung in die Network-Byte-Oder-Dar­ stellung bei der Codierung transformiert wird oder bei der Decodierung durch Anwendung der inverse Operation invers transformiert wird. Die Datenstruktur xdrs enthält auch eine weitere Variable, mit der der Pufferspeicher PS angegeben ist, in den das Datenpaket DP geschrieben wird bzw. aus dem das Datenpaket DP gelesen wird.
In Fig. 2 ist die Erweiterung des RPC-Verfahrens symbolisch dargestellt, mit der eine kryptographische Sicherung der Übertragung des Datenpaktes DP möglich ist.
Die Erweiterung ist symbolhaft durch eine kryptographisch er­ weiterte XDR-Filter-Funktion XDRK dargestellt.
Für eine beliebige Anzahl von XDR-Filter-Funktionen XDR, die von Stubs aufgerufen werden, die von dem RPCL-Protokoll-Compiler generiert werden, wird eine zusätzliche kryptogra­ phisch erweiterte XDR-Filter-Funktion XDRK hinzugefügt.
In einer Weiterbildung des Verfahrens ist es vorgesehen, nur die XDR-Filter-Funktionen XDR kryptographisch zu erweitern, die unmittelbar von den sog. Client-Stubs oder den sog. Ser­ ver-Stubs aufgerufen werden. Auf diese Weise wird der Imple­ mentierungsaufwand und die bei der Transformation des Daten­ pakets DP in die Network-Byte-Order-Darstellung benötigte Re­ chenzeit erheblich reduziert.
Die Erweiterung erfolgt in der von dem RPCL-Protokoll-Compiler generierten Datei mit der Endung "_xdr.c".
Die kryptographisch erweiterten XDR- Filter- Funktionen XDRK weisen beispielsweise folgende Struktur auf:
Hierbei wird mit XDR_SEC ein C-Preprocessormacro bezeichnet, mit dem Daten von dem Pufferspeicher PS gelesen werden und mit dem Daten in den Pufferspeicher PS geschrieben werden.
Ein Beispiel für das XDR_SEC-Makro ist beispielsweise in ei­ nem am Ende des Dokuments dargestellten C-Programm-Listing zu sehen, wobei mit dem Programm aus einer XDR-Filter-Funktion XDR mit der Bezeichnung xdr_requesttype() eine kryptogra­ phisch erweiterte XDR-Filter-Funktion XDRK mit der Bezeich­ nung sec_xdr_requesttype() erzeugt wird. Das am Ende des Do­ kuments dargestellte Programm stellt lediglich eine Realisie­ rungsmöglichkeit aus einer Vielzahl weiterer Möglichkeiten zur Realisierung dar.
In diesem Ausführungsbeispiel wird sowohl der Anfang als auch das Ende des Datenpakets DP in dem Pufferspeicher PS be­ stimmt. Die Länge und der Anfang des XDR-Frames wird bei dem beispielhaft dargestellten C-Programm durch die Funktionen xdrgetinfo() sowie xdrsetlen() durchgeführt. Mit diesen bei­ den Funktionen ist es möglich, direkt auf das in den Puffer­ speicher PS gespeicherte Datenpaket DP zuzugreiten und das Datenpaket DP zu manipulieren.
Ferner wird in einer von dem RPCL-Protokoll-Compiler gene­ rierten Datei mit der Endung ".h" die jeweilige kryptogra­ phisch erweiterte XDR-Filter-Funktion XDRK hinzugefügt.
In den von dem RPCL-Protokoll-Compiler generierten sogenann­ ten Stubs der ersten Computereinheit C1 mit der Endung "_clnt.c" werden die Aufrufe der XDR-Filter-Funktionen XDR derart geändert, daß anstelle der XDR-Filter-Funktionen XDR die kryptographisch erweiterten XDR-Filter-Funktionen XDRK aufgerufen werden.
In den von dem RPCL-Protokoll-Compiler generierten Stubs mit der Endung "_clnt.c" werden beispielsweise folgende Änderun­ gen durchgeführt, um dies zu realisieren:
In den von dem RPCL-Protokoll-Compiler generierten Protokoll­ dateien mit der Endung "_svc.c" in der zweiten Computerein­ heit C2 werden ebenfalls anstelle der XDR-Filter-Funktionen XDR die kryptographisch erweiterten XDR-Filter-Funktionen XDRK aufgerufen.
In den von dem RPCL-Protokoll-Compiler generierten Stubs mit der Endung "_svc.c" werden beispielsweise folgende Änderungen durchgeführt, um dies zu realisieren:
Ferner werden die kryptographisch erweiterten XDR_Filter-Funktionen XDRK der Header-Datei mit der Endung ".h" zuge­ fügt, beispielsweise durch Hinzufügen der beiden folgenden Ausdrücke:
bool_t sec_xdr_requesttype();
bool_t sec_xdr_replytype();
In Fig. 3 sind in Form eines Ablautdiagramms die einzelnen Verfahrensschritte des Verfahrens dargestellt.
Bei dem Verfahren wird in einem ersten Schritt 301 in der er­ sten Computereinheit C1 der Remote Procedure Call RPCA gene­ riert und von dem Remote Procedure Call-Prozeß RPCP verarbei­ tet.
Ferner wird eine Transformation XDR in den XDR-Filter-Funktionen XDR des zu übertragenden Datenpakets DP in eine Network Byte Order-Darstellung durchgeführt 302.
Bei der Transformation XDR in den kryptographisch erweiterten XDR- Filter- Funktionen XDRK wird auf das Datenpaket DP ein kryptographisches Verfahren angewendet 303.
Das auf diese Weise kryptographisch bearbeitete Datenpaket DP wird von der ersten Computereinheit C1 zu der zweiten Compu­ tereinheit C2 übertragen 304.
Bei der zweiten Computereinheit C2 wird das kryptographisch bearbeitete Datenpaket empfangen und einer zu der Transforma­ tion inversen Transformation IXDRK unterzogen 305.
Bei der inversen Transformation wird eine in der zweiten Com­ putereinheit C2 verwendete lokale Syntax berücksichtigt 306.
Ferner wird bei der inversen Transformation IXDRK ein zu dem kryptographischen Verfahren inverses kryptographisches Ver­ fahren auf das Datenpaket DP angewendet 307.
Die XDR-Filter-Funktionen XDR können um beliebige kryptogra­ phische Verfahren erweitert werden. Die kryptographischen Verfahren können beispielsweise verschiedene Sicherheitsdien­ ste, beispielsweise die Sicherheitsdienste der Sicherung der Integrität des Datenpakets DP, der Authentifikation der er­ sten Computereinheit C1 und/oder der zweiten Computereinheit C2 sowie der Verschlüsselung des Datenpakets DP und/oder ei­ nes dem Datenpaket DP hinzugefügten Kopffeldes KF und/oder Trailers TR, der Informationen für das kryptographische Ver­ fahren enthält, realisieren.
Je nach benötigter Sicherheit bzw. nach vorhandener Rechen­ leistung der Computereinheiten können beliebige kryptographi­ sche Verfahren ausgewählt werden.
Die entsprechenden kryptographischen Verfahren werden bei­ spielsweise an den in der XDR-Filter-Funktion bool_t xdr_Filter mit /* */ markierten Bereichen eingefügt.
Eine keineswegs abschließend zu verstehende Übersicht über kryptographische Verfahren, die verwendet werden können, ist beispielsweise in dem Dokument [12] zu finden.
In einer Weiterbildung des Verfahrens ist es vorgesehen, bei der Transformation den Anfang A und/oder das Ende E des Da­ tenpakets DP der Position zu ermitteln, an der das Datenpaket DP in dem Pufferspeicher PS zwischengespeichert wird (vgl. Fig. 4a bis c).
Das Datenpaket DP wird aus dem Pufferspeicher PS ausgelesen, dem Datenpaket DP wird zusätzliche Information für das je­ weils verwendete kryptographische Verfahren hinzugefügt, und wiederum in den Pufferspeicher PS zur Weiterverarbeitung ab­ gespeichert. Die hinzugefügte Information kann beispielsweise in dem zusätzlichen Kopffeld KF und/oder dem Trailer TR ent­ halten sein. Beispielsweise kann folgende Information in dem Kopffeld KF oder in dem Trailer TR enthalten sein:
  • - eine Angabe SDID einer Sicherheitsdomäne, der die erste Computereinheit C1 zugeordnet ist;
  • - ein kryptographischer Integritätsprüfwert ICV, der beispielsweise durch Bildung einer kryptographischen Hashfunktion über das Datenpaket DP bestimmt wird oder durch Berechnung des sog. Message-Authentification-Codes (MAC) für das Datenpaket DP;
  • - ein Sicherheitskopffeld SK, das beispielsweise folgende sicherheitsspezifischen Angaben enthält:
    • - eine Zeitangabe TI des Sendezeitpunktes des Daten­ pakets DP, mit dem der sog. Zeitstempel gebildet wird,
    • - eine Sequenznummer SN, die das Datenpaket DP eindeutig identifiziert und numeriert,
    • - eine eindeutige Adresse ADRC1 der ersten Computer­ einheit C1,
    • - eine eindeutige Adresse ADRC2 der zweiten Computer­ einheit C2,
Das Datenpaket DP wird bei Bedarf verschlüsselt, wobei die Verschlüsselung mit einem beliebigen Verschlüsselungsverfah­ ren, beispielsweise einem symmetrischen Verschlüsselungsver­ fahren oder einem asymmetrischen Verschlüsselungsverfahren durchgeführt werden kann.
Mit dem Zeitstempel sowie der Sequenznummer SN werden einem Angriffe durch Wiedereinspielen des Datenpakets DP entdeckt.
Der Trailer TR weist beispielsweise folgende Komponenten auf:
  • - eine beliebige Anzahl von Füllfeldern PAD zum sog. Paketpadding, sowie
  • - beispielsweise einen nichtkryptographischen Integri­ tätsprüfwert CRC, der beispielsweise durch Durchführung des sog. Cycling-Redundancy-Checks (CRC) beispielsweise mittels des Prinzips der rückgekoppelten Schieberegister ermittelt wird.
Im Rahmen dieser Erfindung ist der Begriff des kryptographi­ sche Verfahrens in einer Weise zu verstehen, daß sowohl alle kryptographische Verfahren als auch die nichtkryptographische Verfahren zur Integritätsprüfung des Datenpakets DP, bei­ spielsweise der Cycling-Redundancy Check (CRC) mit dem Be­ griff kryptographisches Verfahren bezeichnet werden.
In Fig. 4c ist der Pufferspeicher PS skizziert, in dem das kryptographische gesicherte Datenpaket DP nach der Einkapse­ lung gemäß Fig. 4b wieder abgespeichert wird, um im Rahmen des RPC-Verfahrens zu der zweiten Computereinheit C2 gesendet zu werden.
In einer Weiterbildung des Verfahrens ist es vorteilhaft, ei­ nige Sicherheitserweiterungen für das Verfahren vorzusehen, die zu Beginn des Verfahrens, beispielsweise bei dem Verbin­ dungsaufbau im Rahmen des RPC-Verfahrens durchgeführt wird.
Dabei ist es vorteilhaft, zu Beginn des Verfahrens zwischen der ersten Computereinheit C1 und der zweiten Computereinheit C2 eine Authentifikation entweder lediglich der ersten Compu­ tereinheit oder der zweiten Computereinheit C2 oder aber auch eine gegenseitige Authentifikation durchzuführen. Zur Authen­ tifikation können beliebige Authentifikationsmechanismen ver­ wendet werden.
Ein Beispiel zur möglichen Authentifikation ist in Fig. 5 dargestellt, bei dem von der ersten Computereinheit C1 ein erstes Zertifikat CertA, welches einen vertrauenswürdigen, von einer vertrauenswürdigen dritten Instanz, der Zertifizie­ rungseinheit zertifizierten, öffentlichen Schlüssel der er­ sten Computereinheit C1 enthält.
Ferner wird von der ersten Computereinheit C1 zusätzlich zu dem ersten Zertifikat CertA eine erste Signaturnachricht S1 gebildet, die durch eine digitale Unterschrift über eine er­ ste Nachricht N1 mit einem geheimen Schlüssel SK_A der ersten Computereinheit C1 gebildet wird.
Die erste Nachricht N1 enthält beispielsweise einen ersten Zeitstempel TA, eine erste Zufallszahl RA, die im Rahmen die­ ses Verfahrens eindeutig ist, eine Identitätsangabe der zwei­ ten Computereinheit IB, bei Verwendung des X.509-Authentifikationsmechanismus beispielsweise die eindeutige Identitätsangabe der zweiten Computereinheit C2, bei einer im weiteren beschriebenen Aushandlung einer zu verwendenden Si­ cherheitspolitik, die sich über eine ganze Domäne erstreckt, eine Domänenangabe SDID, der die zweite Computereinheit C1 zugeordnet wird, sowie eine mit einem öffentlichen Schlüssel PK_B der zweiten Computereinheit C2 verschlüsselte Authenti­ fikationsreferenz ARA der ersten Computereinheit C1, die ei­ nem Pseudoschlüssel der ersten Computereinheit C1 entspricht Die geheimen Pseudoschlüssel in Funktion der Authentifikati­ onsreferenz ARA der ersten Computereinheit C1 und der Authen­ tifikationsreferenz ARB der zweiten Computereinheit C2 dienen im weiteren Protokollablauf dazu, nachfolgende Protokollpha­ sen und Protokollnachrichten kryptographisch an die Authenti­ fikationsphase zu koppeln.
Das erste Zertifikat CertA sowie die erste Signaturnachricht S1 wird an die zweite Computereinheit C2 übertragen.
Nach Auswertung (Verifizierung) der ersten Signaturnach­ richt S1, welche zur Abwehr von kryptographischen Angriffen unterschiedlicher Art dient, wird in der zweiten Computerein­ heit C2 eine zweite Signaturnachricht S2 gebildet und an die erste Computereinheit C1 übertragen.
Die zweite Signaturnachricht S2 enthält beispielsweise fol­ gende Komponenten:
  • - einen zweiten Zeitstempel TB,
  • - eine zweite, eindeutige Zufallszahl RB,
  • - eine Identitätsangabe IA der ersten Computereinheit C1,
  • - die erste Zufallszahl RA,
  • - eine mit einem öffentlichen Schlüssel PK_A der ersten Computereinheit C1 verschlüsselte Authentifika­ tionsreferenz ARB der zweiten Computereinheit C2.
Die oben beschriebenen Komponenten bilden eine zweite Nach­ richt N2, die durch Bildung einer digitalen Unterschrift un­ ter Verwendung eines geheimen Schlüssels SK_B der zweiten Computereinheit C2 bestimmt wird.
Nach Empfang und Auswertung, d. h. Verifizierung der zweiten Signaturnachricht S2 in der ersten Computereinheit C1 wird von der ersten Computereinheit C1 eine dritte Signaturnach­ richt S3 gebildet und an die zweite Computereinheit C2 über­ tragen.
Die dritte Signaturnachricht S3 wird gebildet unter Verwen­ dung des geheimen Schlüssels SK_A der ersten Computerein­ heit C1, mit dem eine dritte Nachricht N3 verschlüsselt wird.
Die dritte Nachricht N3 enthält-mindestens die Identitätsan­ gabe IB der zweiten Computereinheit C2 sowie die zweite Zu­ fallszahl RB.
Mit diesem Protokoll wird eine gegenseitige Authentifikation der ersten Computereinheit C1 und der zweiten Computereinheit C2 ermöglicht.
Ferner ist es in einer Weiterbildung des Verfahrens vorgese­ hen, eine im weiteren Verfahren zu verwendende Sicherheitspo­ litik, mit der beispielsweise die zu verwendenden Sicher­ heitsmechanismen, kryptographische Verfahren sowie Sicher­ heitsparameter testgelegt werden, auszuhandeln.
Die Sicherheitspolitik kann sich beispielsweise über eine ganze Sicherheitsdomäne erstrecken, womit eine Gruppe von Rechnern bezeichnet wird, die sich einer gemeinsamen Sicher­ heitspolitik unterordnen.
Die Sicherheitspolitik kann sich jedoch auch nur auf die ak­ tuell aufzubauende Verbindung zwischen der ersten Compu­ tereinheit C1 und der zweiten Computereinheit C2 erstrecken.
Es wird bei dieser Weiterbildung des Verfahrens beispielswei­ se ein Sicherheitspolitikvorschlag SPA, der die zu verwenden­ de Sicherheitspolitik, die von der ersten Computereinheit C1 vorgeschlagen wird, enthält, gebildet.
Der Sicherheitspolitikvorschlag SPA wird mit dem öffentlichen Schlüssel PK_B der zweiten Computereinheit C2 verschlüsselt, wodurch der sensitive Sicherheitspolitikvorschlag SPA vor ei­ nem unbefugten Abhören geschützt wird.
Ferner wird mindestens auf den Sicherheitspolitikvorschlag SPA, die Identitätsangabe IB der zweiten Computereinheit C2 sowie die Authentifikationsreferenz ARB der zweiten Compu­ tereinheit C2 eine Hash-Funktion h(.) angewendet wird, mit der ein erster Hash-Wert h(SPA, IB, ARB) gebildet wird.
Mit dem ersten Hash-Wert h (SPA, IB, ARB) wird die Authentizi­ tät der ersten Computereinheit C1 sowie des Sicherheitspoli­ tikvorschlags SPA gewährleistet für die zweite Computerein­ heit C2.
Auch wenn es an dieser Stelle möglich ist, eine asymmetrische digitale Unterschrift zu verwenden, so ist es in diesem Fall vorteilhaft, die Bildung eines Hash-Wertes durchzuführen, da die Ermittlung des Hash-Wertes mittels symmetrischer Krypto­ verfahren erheblich schneller durchgeführt werden kann als die Bildung einer digitalen Unterschrift.
Es können beliebige Hash-Funktionen im Rahmen dieses Verfah­ rens eingesetzt werden, beispielsweise das MD4-Verfahren, das MD5-Verfahren, oder der Hash-Algorithmus ISO10118. Das Hash-Verfahren ISO10118 ist besonders vorteilhaft einsetzbar für den Fall, wenn eine Hardwareimplimentierung des symmetrischen sog. DES-Verschlüsselungsverfahrens (Data Encryption Stan­ dard) vorhanden ist.
Der verschlüsselte Sicherheitspolitikvorschlag SPA sowie der erste Wert h (SPA, IB, ARB) werden zu der zweiten Computerein­ heit C2 übertragen und dort verifiziert.
Als Antwort wird eine Sicherheitspolitikbestätigung SPAB zu der ersten Computereinheit C1 übertragen, die mit dem öffent­ lichen Schlüssel PK_A der ersten Computereinheit C1 ver­ schlüsselt wird. Ferner wird ein zweiter Hash-Wert h(SPAB, IA, ARA) in der zweiten Computereinheit C2 gebildet und zu der ersten Computereinheit C1 übertragen, wobei der zweite Hash-Wert h(SPAB, IA, ARA) mindestens über die Sicherheitspo­ litikbestätigung SPAB, die Identitätsangabe IA der ersten Computereinheit C1 sowie die Authentifikationsreferenz ARA der ersten Computereinheit C1 gebildet wird.
Die Sicherheitspolitikbestätigung SPAB enthält beispielsweise entweder eine Bestätigung der Akzeptanz des von der ersten Computereinheit C1 gesendeten Sicherheitspolitikvorschlags SPA, oder aber einen eigenen, von der zweiten Computereinheit C2 gebildeten Sicherheitspolitikvorschlag. Weicht der von der zweiten Computereinheit C2 gebildete Sicherheitspolitikvor­ schlag von dem Sicherheitspolitikvorschlag SPA der ersten Computereinheit C1 ab, so muß auf entsprechende Weise die er­ ste Computereinheit C1 den weiteren Sicherheitspolitikvor­ schlag verarbeiten, verifizieren, überprüfen und eine weitere Sicherheitspolitikbestätigung zu der zweiten Computereinheit C2 senden.
Die Inhalte der Nachrichten sind entsprechend dem oben be­ schriebenen Verfahren. Dieses Verfahren kann iterativ solange weitergeführt werden, bis sich die erste Computereinheit C1 und die zweite Computereinheit C2 auf eine einheitliche, von beiden Computereinheiten C1, C2 unterstützte Sicherheitspoli­ tik "geeinigt" haben.
Ferner ist es in einer Weiterbildung des Verfahrens vorgese­ hen, zu Beginn des Verfahrens einen Schlüsselaustausch der zu verwendenden kryptographischen Schlüssel zwischen der ersten Computereinheit C1 und der zweiten Computereinheit C2 durch­ zuführen. Dies kann beispielsweise in einer Weise erfolgen, daß von der ersten Computereinheit C1 eine erste Schlüssel­ austauschnachricht SA1 zu der zweiten Computereinheit C2 übertragen wird. Die erste Schlüsselaustauschnachricht SA1 enthält beispielsweise folgende Komponenten:
  • - eine Angabe P einer zu verwendenden Verbindung, mit der eine von mehreren verschiedenen gleichzeitig aktiven Verbindungen repräsentiert wird,
  • - einen Zählwert CAB der ersten Computereinheit C1 für die Schlüsselverteilung und/oder eine Verbindungs­ abbruchsnachricht,
  • - einen mit dem öffentlichen Schlüssel PK_B der zweiten Computereinheit C2 verschlüsselten, im weiteren Verfahren zu verwendenden Sitzungsschlüssel k, wobei der Sitzungs­ schlüssel k vorteilhafterweise ein symmetrischer Sitzungs­ schlüssel ist, der im Rahmen der Verbindung P eingesetzt wird,
  • - ein dritter Hash-Wert h (k, P, CAB, IB, ARB), der gebildet wird mindestens über den Sitzungsschlüssel k, die Verbin­ dung P, den Zählwert CAB, die Identitätsangabe IB der zweiten Computereinheit C2 sowie die Authentifikationsre­ ferenz ARB der zweiten Computereinheit C2.
Der Zählwert CAB zwischen der ersten Computereinheit C1 und der zweiten Computereinheit C2 dient dazu, zwischen verschie­ denen Protokolldurchläufen für die gleiche Verbindung P zwi­ schen der ersten Computereinheit C1 und der zweiten Compu­ tereinheit C2 zu unterscheiden. Indem der jeweils empfangene Zählwert CAB stets größer sein muß als der zuletzt gespei­ cherte Zählwert CAB, können Replay-Attacken, d. h. Angriffe durch Wiedereinspielung abgehörter Daten, entdeckt werden.
Die erste Schlüssselaustauschnachricht SA1 wird von der zwei­ ten Computereinheit C2 anhand des dritten Hash-Wertes h (k, P, CAB, IB, ARB) verifiziert, der Sitzungsschlüssel k wird unter Verwendung des geheimen Schlüssels SK_B der zweiten Compu­ tereinheit C2 entschlüsselt, und es wird eine zweite Schlüs­ selaustauschnachricht SA2 gebildet, mit der der Empfang und die weitere Verwendung des Sitzungsschlüssels k für die Ver­ bindung P der ersten Computereinheit C1 bestätigt wird.
Die zweite Schlüsselaustauschnachricht SA2 enthält beispiels­ weise folgende Komponenten:
  • - die Verbindung P,
  • - einen vierten Hash-Wert h (P, k, CA, IA), der gebildet wird mindestens über die Verbindung P, den Sitzungsschlüs­ sel k, den ersten Zählwert CA, sowie die Identitätsangabe IA der ersten Computereinheit C1.
Auf diese Weise ist es möglich, auf einfache Art schnell und verläßlich in dem Verfahren zu verwendende Sitzungsschlüssel zwischen der ersten Computereinheit C1 und der zweiten Compu­ tereinheit C2 auszutauschen, ohne die gegenseitige Authenti­ fikationsphase und die Aushandlung der Sicherheitspolitik wiederholen zu müssen.
Dies ist nur aufgrund des modularen Aufbaus des oben beschrie­ benen Verfahrens möglich, da bei dem modularen Aufbau einzel­ ne Phasen des Verfahrens weggelassen oder in beliebiger Weise miteinander kombiniert werden können.
Ferner ist es in einer Weiterbildung vorgesehen, einen Ver­ bindungsabbruch auch auf eine kryptographische Weise abzusi­ chern. Dies kann beispielsweise dadurch erfolgen, daß von der ersten Computereinheit C1 eine Verbindungsabbruchsnachricht VAN gebildet wird und an die zweite Computereinheit C2 gesen­ det wird.
Die Verbindungsabbruchsnachricht VAN enthält beispielsweise folgende Komponenten:
  • - die Verbindung P,
  • - eine Angabe zur Identifizierung der Verbindungsabbruchs­ nachricht VAN,
  • - den Zählwert CAB,
  • - einen fünften Hash-Wert h (P, DR, CAB, IB, ARB), der bei­ spielsweise über die Verbindung P, die Angabe DR der Verbindungsabbruchsnachricht VAN, den Zählwert CAB, die Identitätsangabe IB der zweiten Computereinheit C2, und die Authentifikationsreferenz ARB der zweiten Computereinheit C2 gebildet wird.
Die Verbindungsabbruchsnachricht VAN wird von der zweiten Computereinheit C2 verifiziert, die Verbindung wird abgebro­ chen, und es wird eine Verbindungsabbruchbestätigungsnach­ richt VACKN in der zweiten Computereinheit C2 gebildet und an die erste Computereinheit C1 übertragen.
Die Verbindungsabbruchbestätigungsnachricht VACKN enthält beispielsweise folgende Komponenten:
  • - die Verbindung P,
  • - eine Angabe DA zur Identifizierung der Verbindungsabbruch­ bestätigungsnachricht VACKN,
  • - einen sechsten Hash-Wert h (P, DA, CAB, IA, ARA), der beispielsweise über die Verbindung P, die Angabe DA zur Identifizierung der Verbindungsabbruchbestätigungs­ nachricht VACKN, den Zählwert CAB, die Identitäts­ angabe IA der ersten Computereinheit C1, sowie die Authen­ tifikationsreferenz ARA der ersten Computereinheit C1 gebildet wird.
Mit den Angaben DR, DA zur Identifizierung der Verbindungsab­ bruchsnachricht VAN bzw. der Verbindungsabbruchbestätigungs­ nachricht VACKN ist es möglich, Mißbrauch der Hash-Werte bei zukünftigen Erweiterungen dieser oben beschriebenen Verfahren für andere Zwecke zu verhindern. Die Verbindungsabbruchsnach­ richt VAN und/oder die Verbindungsabbruchbestätigungsnach­ richt VACKN enthalten zusätzlich die Angabe über die verwen­ dete Verbindung P.
Die oben beschriebenen und in Fig. 5 dargestellten einzelnen Weiterbildungen des Verfahrens zur Authentifizierung, zur Aushandlung der Sicherheitspolitikvorschlag, zum Schlüssel­ austausch, sowie zum Verbindungsabbruch können in beliebiger Kombination miteinander durchgeführt werden.
Das Verfahren kann während einer Verbindungsaufbauphase bzw. während einer Verbindungsaufbauphase einer Verbindung zwi­ schen der ersten Computereinheit C1 und der zweiten Compu­ tereinheit C2 durchgeführt werden.
Des weiteren können die einzelnen Nachrichten selbst in sog. RPC-Datenpakete übertragen werden.
Beispiel für XDR_SEC-Makro in der Programmiersprache C:
In diesem Dokument wurden folgende Veröffentlichungen zi­ tiert:
[1] Satyanarayanan, Integrating Security in a Large Distributed System, ACM Transactions on Computer Systems, Vol. 7, Nr. 3, S. 247-280, August 1989
[2] Birreli, Secure Communication Using Remote Procedure Calls, ACM Transactions on Computer Systems, Vol. 3, Nr. 1, S. 1-14, Februar 1985
[3] Kuo, Lin, New Design Considerations of Secure RPC for Future High-Speed Network-Based Distributed Environment, IEEE Globecom, IEEE Global Conf. Record, Vol. 1, Houston, USA, S. 182-187, 29. November - 2. Dezember 1993
[4] Safford et al, Secure RPC Authentication (SRA) for TELNET and FTP, Proceedings of the Fourth USENIX Security Symposium, S. 63-67, 1993
[5] Rosenberry et al, Understanding DCE, O′Reilly & Ass., OSF Distributed Computing Environment, ISBN-Nr. 1-56592-005-8, S. 39-54 und S. 61-70, 1992
[6] Open Sottware Foundation, Introduction to OSF DCE, Revision 1.0, S. 3-9 - 3-65, Dezember 1991
[7] Bellovin et al, Limitations of the Kerberos Authentication Systems, USENIX, S. 253-267, 1991
[8] RPC: Remote Procedure Call Protocol Specification, Request for Comments (RFC) 1057, 1988
[9] RPC: Remote Procedure Call Protocol Specification Version 2, Request for Comments (RFC) 1831, 1995
[10] An Agreement between the Internet Society and Sun Micro­ systems, Inc. in the Matter ONC RPC and XDR Protocols, Request tor Comments (RFC) 1790, 1995
[11] Dateien, im Internet unter folgendem Verzeichnis am 28.5.1996 erhältlich:
ttp://bcm/tmc.edu/nts/secure_rpc.01.shar
ftp://bcm/tmc.edu/nts/secure_rpc.02.shar
ftp://bcm/tmc.edu/nfs/secure_rpc.03.shar
ftp: //bcm/tmc.edu/nts/secure_rpc.04.shar
[12] S. Muftic, Sicherheitsmechanismen für Rechnernetze, Carl Hanser Verlag, München, ISBN 3-446-16272-0, S. 34-70, 1992.

Claims (9)

1. Verfahren zur kryptographischen Sicherung einer Übertra­ gung mindestens eines Datenpakets (DP) von einer ersten Com­ putereinheit (C1) zu einer zweiten Computereinheit (C2) unter Verwendung des Remote Procedure Call-Verfahrens (RPC),
  • - bei dem in der ersten Computereinheit (C1) für das Datenpa­ ket (DP) ein Remote Procedure Call (RPCA) generiert wird und von einem Remote Procedure Call-Prozeß (RPCP) verarbeitet wird,
  • - bei dem eine Transformation (XDR) in eine Network-Byteorder-Darstellung durchgeführt wird,
  • - bei dem bei der Transformation ein kryptographisches Ver­ fahren auf das Datenpaket (DP) angewendet wird,
  • - bei dem das kryptographisch bearbeitete Datenpaket (DP) von der ersten Computereinheit (C1) zu der zweiten Computerein­ heit (C2) übertragen wird,
  • - bei dem das in der zweiten Computereinheit (C2) empfangene Datenpaket (DP) einer zu der Transformation (XDR) inversen Transformation (IXDR) unterzogen wird,
  • - bei dem bei der inversen Transformation (IXDR) eine in der zweiten Computereinheit (C2) verwendete lokalen Syntax be­ rücksichtigt wird, und
  • - bei dem bei der inversen Transformation (IXDR) ein zu dem kryptographischen Verfahren inverses kryptographisches Ver­ fahren auf das Datenpaket (DP) angewendet wird.
2. Verfahren nach Anspruch 1,
  • - bei dem bei der Transformation (XDR) der Anfang und/oder das Ende des Datenpakets (DP) der Position, an der das Daten­ paket (DP) in einem Pufferspeicher (PS) zwischengespeichert wird, ermittelt wird,
  • - bei dem bei der Durchführung des kryptographischen Verfah­ rens dem Datenpaket (DP) ein Kopffeld und/oder ein Trailer hinzugefügt wird, der oder die Informationen für das krypto­ graphische Verfahren enthält.
3. Verfahren nach Anspruch 1 oder 2, bei dem das kryptographische Verfahren derart ausgestaltet ist, daß mindestens einer der folgenden Sicherheitsdienste gewährleistet wird:
  • - Integrität des Datenpakets (DP),
  • - Authentifikation der ersten Computereinheit (C1) und/oder der zweiten Computereinheit (C2),
  • - Verschlüsselung des Datenpakets (DP) und/oder eines dem Da­ tenpaket (DP) hinzugefügten Kopffeldes und/oder Trailers, der oder die Informationen für das kryptographische Verfahren enthält.
4. Verfahren nach einem der Ansprüche 1 bis 3, bei dem zu Beginn des Verfahrens zwischen der ersten Compu­ tereinheit (C1) und der zweiten Computereinheit (C2) eine Au­ thentifikation der ersten Computereinheit (C1) und/oder der zweiten Computereinheit (C2) durchgeführt wird.
5. Verfahren nach einem der Ansprüche 1 bis 4, bei dem zu Beginn des Verfahrens ein Schlüsselaustausch kryp­ tographischer Schlüssel zwischen der ersten Computereinheit (C1) und der zweiten Computereinheit (C2) durchgeführt wird.
6. Verfahren nach einem der Ansprüche 1 bis 5, bei dem zu Beginn des Verfahrens eine Sicherheitspolitik zwi­ schen der ersten Computereinheit (C1) und der zweiten Compu­ tereinheit (C2) ausgehandelt wird, die in dem anschließenden Verfahren verwendet werden soll.
7. Verfahren nach einem der Ansprüche 1 bis 6, bei dem zu Beginn des Verfahrens das zu verwendende krypto­ graphische Verfahren zwischen der ersten Computereinheit (C1) und der zweiten Computereinheit (C2) ausgehandelt wird.
8. Verfahren nach einem der Ansprüche 1 bis 7, bei dem das Verfahren während einer Verbindungsaufbauphase bzw. während einer Verbindungsaufbauphase einer Verbindung zwischen der ersten Computereinheit (C1) und der zweiten Com­ putereinheit (C2) durchgeführt wird.
9. Verfahren nach einem der Ansprüche 1 bis 8, bei dem die einzelnen Nachrichten selbst in RPC-Datenpakete übertragen werden.
DE19622629A 1996-06-05 1996-06-05 Verfahren zur kryptographischen Sicherung einer Übertragung mindestens eines Datenpakets von einer ersten Computereinheit zu einer zweiten Computereinheit unter Verwendung des Remote Procedure Call Verfahrens Withdrawn DE19622629A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE19622629A DE19622629A1 (de) 1996-06-05 1996-06-05 Verfahren zur kryptographischen Sicherung einer Übertragung mindestens eines Datenpakets von einer ersten Computereinheit zu einer zweiten Computereinheit unter Verwendung des Remote Procedure Call Verfahrens

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE19622629A DE19622629A1 (de) 1996-06-05 1996-06-05 Verfahren zur kryptographischen Sicherung einer Übertragung mindestens eines Datenpakets von einer ersten Computereinheit zu einer zweiten Computereinheit unter Verwendung des Remote Procedure Call Verfahrens

Publications (1)

Publication Number Publication Date
DE19622629A1 true DE19622629A1 (de) 1997-12-11

Family

ID=7796258

Family Applications (1)

Application Number Title Priority Date Filing Date
DE19622629A Withdrawn DE19622629A1 (de) 1996-06-05 1996-06-05 Verfahren zur kryptographischen Sicherung einer Übertragung mindestens eines Datenpakets von einer ersten Computereinheit zu einer zweiten Computereinheit unter Verwendung des Remote Procedure Call Verfahrens

Country Status (1)

Country Link
DE (1) DE19622629A1 (de)

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
BIRRELL, Andrew D.: Secure Communication Using Remote Procedure Calls, In: ACM Transactions on Computer Systems, Vol.3, Nr.1, S.1-14, Febr.1985 *
KUO, G.S., LIN, Jing-Pei: New Design Considera- tions of Secure RPC for Future High-Speed Net- work-Based Distributed Environment, In: IEEE Globecom, IEEE Global Conf. Record, Vol.1, HoustonUSA, S. 182-187, 29. Nov. - 2. Dez. 1993 *
Open Software Foundation, Introduction to OSF DCE, *
ROSENBERRY, W. et al: Understanding DCE, O'Reilly & Ass., In: OSF Distributed Computing Environment,ISBN-Nr.1-56592-005-8, S.39-54 u. S.61-70, 1992 *
SAFFORD, David R. et al: Secure RPC Authentica- tion (SRA) for TELNET and FTP, Proceedings of the Fourth USENIX Security Symposium, S.63-67, 1993 *
SATYANARAYANAN, M.: Integrating Security in a Large Distributed System, In: ACM Transactions on Computer Systems, Vol.7, Nr.3, S.247-280, August 1989 *

Similar Documents

Publication Publication Date Title
EP0903026B1 (de) Verfahren zur Aushandlung einer Sicherheitspolitik zwischen einer ersten Computereinheit und einer zweiten Computereinheit
DE60209475T2 (de) Datensicherungs-kommunikationsvorrichtung und -verfahren
DE19741246C2 (de) Vorrichtung und Verfahren zur Erhöhung der Sicherheit in Netzwerken
DE69433771T2 (de) Verfahren und Vorrichtung zur Geheimhaltung und Authentifizierung in einem mobilen drahtlosen Netz
EP1595420B1 (de) Verfahren zum bilden und verteilen kryptographischer schlüssel in einem mobilfunksystem und entsprechendes mobilfunksystem
DE60124367T2 (de) Verfahren zur übertragung von hochrätigen datenströmen über internet zwischen einem server und einem chipkartenterminal
DE602004010703T2 (de) Eine persistente und zuverlässige sitzung, die neztwerkkomponenten unter verwendung eines verkapselungsprotokolls sicher durchläuft
EP1289227B1 (de) Verfahren, System und Rechner zum Aushandeln einer Sicherheitsbeziehung auf der Anwendungsschicht
DE60302276T2 (de) Verfahren zur ferngesteuerten Änderung eines Kommunikationspasswortes
DE60201522T2 (de) Ermöglichen legales abfangen von ip-verbindungen
DE112006000618T5 (de) System und Verfahren zur Verteilung von Schlüsseln in einem drahtlosen Netzwerk
DE69918026T2 (de) Gesicherte "keep alive" Nachricht über das Internet
EP2014010B1 (de) Verfahren, vorrichtungen und computerprogrammprodukt zum ver- und entschlüsseln von mediendaten
EP0903027A1 (de) Verfahren zum gruppenbasierten kryptographischen schlüsselmanagement zwischen einer ersten computereinheit und gruppencomputereinheiten
WO2001054371A2 (de) Verfahren, system zur übermittlung von daten von einem sender zu einem empfänger und sender bzw. empfänger hierzu
AT504634B1 (de) Verfahren zum transferieren von verschlüsselten nachrichten
DE69636513T2 (de) System zur sicherung des flusses und zur selektiven veränderung von paketen in einem rechnernetz
DE102017210721A1 (de) Verfahren und Kommunikationssystem zum effizienten Aufbau einer sicheren Datenverbindung zwischen einem Client-Rechner und einem Server-Rechner
DE102017212474A1 (de) Verfahren und Kommunikationssystem zur Überprüfung von Verbindungsparametern einer kryptographisch geschützten Kommunikationsverbindung während des Verbindungsaufbaus
WO2005074189A1 (de) Schaltungsanordnung und verfahren zur kommunikationssicherheit innerhalb von kommunikationsnetzen
DE19622629A1 (de) Verfahren zur kryptographischen Sicherung einer Übertragung mindestens eines Datenpakets von einer ersten Computereinheit zu einer zweiten Computereinheit unter Verwendung des Remote Procedure Call Verfahrens
EP2245834A1 (de) Sichere datenkommunikation
DE19548387C1 (de) Verfahren zur kryptographischen Sicherung der rechnergestützten digitalen Kommunikation zwischen einem Programm und mindestens einer Benutzereinheit
DE102006038599B3 (de) Verfahren zur Wiederaktivierung einer sicheren Kommunikationsverbindung
EP3955511B1 (de) Gesicherte datenübertragung innerhalb eines qkd-netzwerkknotens

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
8136 Disposal/non-payment of the fee for publication/grant