DE69533953T2

DE69533953T2 - System für signaturlose Übertragung und Empfang von Datenpaketen zwischen Computernetzwerken

Info

Publication number: DE69533953T2
Application number: DE69533953T
Authority: DE
Inventors: Geoffrey Fremont Mulligan; Martin Patterson; Glenn Sunnyvale Scott; Ashar Fremont Aziz
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1994-09-15
Filing date: 1995-09-14
Publication date: 2006-04-06
Anticipated expiration: 2015-09-15
Also published as: JPH0927804A; EP0702477A3; USRE39360E1; EP0702477A2; DE69533953D1; KR960012819A; US5548646A; EP0702477B1; KR100388606B1

Description

Die vorliegende Erfindung betrifft den Bereich der sicheren Übertragung von Datenpaketen und insbesondere ein neues Verfahren und System zum automatischen Verschlüsseln und Entschlüsseln von Datenpaketen zwischen Sites auf dem Internet oder anderen Netzwerken von Computernetzen.
Es wird für Unternehmen in zunehmendem Maße nützlich, vertrauliche Informationen über Netzwerke wie das Internet von einer Site zur anderen zu übertragen, und gleichzeitig wird es immer dringlicher, dass solche Informationen vor unbefugten Augen geschützt werden, während sie über das Verbindungsnetz laufen. Derzeit werden ungesicherte Daten an zahlreichen Sites während des Übertragens zu einem Zielort repliziert, und Handelsgeheimnisse oder andere vertrauliche Informationen werden, wenn sie ungesichert sind, somit der Öffentlichkeit zugänglich gemacht.
Es ist einem Benutzer am sendenden Host möglich, die zu sendenden Daten zu verschlüsseln und den Benutzer, der die Daten empfangen soll, über den verwendeten Verschlüsselungsmechanismus und den zum Entschlüsseln notwendigen Key zu informieren. Dies erfordert jedoch Kommunikationen und einen koordinierten Aufwand seitens des sendenden und des empfangenden Benutzers, und Benutzer werden häufig nicht den nötigen Aufwand betreiben und daher bleiben die Pakete unverschlüsselt.
Aber selbst wenn die Pakete verschlüsselt sind, dann kann selbst die Tatsache, dass sie von Benutzer A zu Benutzer B übertragen werden, vertraulich sein, und es wird ein System benötigt, um auch diese Information geheim zu halten.
1 illustriert ein Netzwerk von Computernetzen, das die Netze N1, N2 und N3 beinhaltet, die über ein öffentliches Netz 10 (wie z.B. das Internet) miteinander verbunden sind. Wenn das Netz N1 auf gewöhnliche Weise aufgebaut ist, beinhaltet es einige bis viele Computer (Hosts), wie z.B. Host A, und zusätzliche Hosts 20 und 30. Ebenso beinhaltet Netz N2 Host B sowie zusätzliche Hosts 40 und 50, während Netz N3 die Hosts 60–90 beinhaltet. Es kann auf jedem Netz viele Hosts und viele weitere individuelle Netzwerke als hier gezeigt geben. Zu Beispielen für solche Netzwerke wird verwiesen auf J. Postel, User Datagram Protocol, RFC 768, 28. August 1980; http://wrvw.rfc-editor.org/rfc/rfc768.txt; Information Sciences Institute, Internet Protocol: DARPA Internet Program Protocol Specification, RFC 791, September 1981; http://www.rfc-editor.org/rfc/rfc791.txt; und T. Socolofsky, A TCP/IP Tutorial, RFC 1180, Januar 1991 http://www.rfc-editor.org/rfc/rfcl180.txt.
Wenn ein Benutzer am Host A eine Datei, eine Email oder dergleichen zu Host B senden möchte, dann wird die Datei in Pakete unterteilt, die jeweils typischerweise eine Struktur wie das in 7 gezeigte Paket 400 hat, einschließlich Daten 410 und Header 420. Zum Senden über das Internet ist der Header 420 ein Internet Protocol (IP) Header, der die Adresse des empfangenden (Ziel-)Hosts B enthält. Herkömmlicherweise wird jedes Datenpaket über das Verbindungsnetz 10 zu dem empfangenden Netz N2 und schließlich zum empfangenden Host B geleitet.
Wie oben angedeutet, lassen sich selbst dann, wenn der Benutzer am Host A die Datei oder die Datenpakete vor dem Senden verschlüsselt und Benutzer B mit dem notwendigen Key zum Entschlüsseln ausgestattet ist, die Identitäten des sendenden und des empfangenden Hosts leicht anhand der Internet Protocol (IP) Adressen in den Headern der Pakete erkennen. Derzeitige Verbindungsnetze bieten keine Architektur oder Methode, um diese Information vertraulich zu halten. Grundsätzlicher, es gibt nicht einmal ein System zum automatischen Verschlüsseln und Entschlüsseln von Datenpaketen, die von einem Host zum anderen gesendet werden.
Es ist bereits bekannt, Pakete von Daten über ein Verbindungsnetz von einem ersten Hostcomputer auf einem ersten Computernetzwerk zu einem zweiten Hostcomputer auf einem zweiten Computernetzwerk zu senden und zu empfangen, wobei das erste und das zweite Computernetz jeweils einen ersten und einen zweiten Brückencomputer beinhalten, wobei der genannte erste und zweite Hostcomputer sowie der genannte erste und zweite Brückencomputer jeweils einen Prozessor und einen Speicher zum Speichern von Anweisungen zur Ausführung durch den Prozessor aufweisen, wobei der genannte erste und zweite Brückencomputer ferner jeweils Speicher zum Speichern von wenigstens einem vorbestimmten Verschlüsselungs-/Entschlüsselungsmechanismus und Informationen speichert, die eine vorbestimmte Mehrzahl von Hostcomputern als Hosts identifizieren, die Sicherheit für zwischen ihnen übertragene Pakete benötigen, wobei das Verfahren mittels der in den genannten jeweiligen Speichern gespeicherten Anweisungen ausgeführt wird. In diesem Zusammenhang wird auf einen Artikel von Forne J. et al. mit dem Titel ‚HARDWARE IMPLEMENTATION OF A SECURE BRIDGE IN ETHERNET ENVIRONMENTS' PROCEEDINGS OF THE GLOBAL TELECOMMUNICATIONS CONFERENCE (GLOBECOM), HOUSTON, 29. November–2. Dezember 1993, Bd. 1, 29. November 1993, Seiten 177–181, XP000428050 INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS, verwiesen.
In den in der letzteren Literaturquelle offenbarten Systemen umfasst jeder Brückencomputer („sichere Brücke") ein kryptografisches Drei-Layer-Protokoll, das in drei Funktionsblöcke unterteilt ist, jeweils als Kommunikationsblock, kryptografischer Block und administrativer Block bezeichnet. Der Kommunikationsblock ist die Schnittstelle zwischen dem Netz und den anderen Blöcken. Der kryptografische Block verschlüsselt/entschlüsselt Frames auf dem Netz mit vertraulichen Informationen mit Hilfe eines Algorithmus. Er erkennt auch Fehler und Attacken und informiert den administrativen Block. Der administrative Block steuert die sichere Brücke und kommuniziert mit einer Überwachungs- und Verwaltungszentrale.
Gemäß einem ersten Aspekt der vorliegenden Erfindung wird ein Verfahren zum Verschlüsseln von Datenpaketen bereitgestellt, die über ein Verbindungsnetz von einem Ursprungshostcomputer auf einem ersten Computernetz mit einer Brücke zu einem Zielhostcomputer gesendet wurden, der potentiell Teil eines zweiten Computernetzes ist, wobei das Verfahren die folgenden Schritte umfasst:
Empfangen eines Datenpakets von dem Ursprungshostcomputer in dem ersten Computernetz an der Brücke für die Übertragung zum Zielhostcomputer, wobei das Datenpaket einen Originalheaderabschnitt und einen Originaldatenabschnitt beinhaltet, wobei der Originalheaderabschnitt eine den Ursprungshostcomputer identifizierende Ursprungskennung und eine den Zielhostcomputer identifizierende Zielkennung beinhaltet;
Ermitteln in der Brücke, wenigstens teilweise auf der Basis der Bezugnahme auf die Ursprungs- und/oder die Zielkennung, ob das Datenpaket verschlüsselt werden soll; und
Verschlüsseln des Datenpakets zum Erzeugen eines verschlüsselten Datenpakets;
wobei das Verfahren dadurch gekennzeichnet ist, dass:
die Verschlüsselung des Datenpakets die Verschlüsselung sowohl des Originaldatenabschnitts als auch des Originalheaderabschnitts beinhaltet;
es den Schritt des Erzeugens eines Encapsulation-Headers und Anhängens des Encapsulation-Headers an das verschlüsselte Datenpaket beinhaltet, um ein modifiziertes Datenpaket zu erzeugen, wobei der Encapsulation-Header eine Verbindungsnetzrundsendeadresse beinhaltet, die mit dem ersten und/oder dem zweiten Netzwerk assoziiert ist, so dass das modifizierte Datenpaket den Encapsulation-Header und einen verschlüsselten Abschnitt hat, der verschlüsselte Versionen des Originalheaderabschnitts und des Originaldatenabschnitts beinhaltet.
Gemäß einem zweiten Aspekt der vorliegenden Erfindung wird ein Verfahren zum Entschlüsseln von Datenpaketen bereitgestellt, umfassend die folgenden Schritte:
Empfangen eines verschlüsselten Datenpakets von einem Ursprung für ein Ziel;
Ermitteln, ob das Datenpaket verschlüsselt ist; und
Entschlüsseln des Datenpakets zum Erzeugen eines entschlüsselten Datenpakets,
dadurch gekennzeichnet, dass:
dem verschlüsselten Datenpaket ein Encapsulation-Header gegeben wird, der eine Ursprungskennung und eine Zielkennung speichert, von denen wenigstens eine eine Rundsendeadresse ist;
der Schritt des Ermittelns, ob das Datenpaket verschlüsselt ist, nach Bezugnahme auf die Ursprungs- und/oder Zielkennung erfolgt;
das verschlüsselte Datenpaket einen verschlüsselten Headerabschnitt und einen verschlüsselten Datenabschnitt beinhaltet; und
der entschlüsselte Headerabschnitt nach dem Entschlüsseln als Header für das entschlüsselte Datenpaket verwendet wird.
Gemäß einem dritten Aspekt der vorliegenden Erfindung wird eine Brücke für die Verwendung in einem Computernetz bereitgestellt, wobei die Brücke die Aufgabe hat, von dem Netzwerk gesendete und empfangene Pakete zu leiten und automatisch durch die Brücke passierende selektierte Pakete zu verschlüsseln, wobei die Pakete einen Headerabschnitt und einen Datenabschnitt haben, wobei die Brücke Folgendes umfasst:
einen Verschlüsselungsmechanismus zum Verschlüsseln selektierter Pakete;
Mittel zum Ermitteln auf der Basis von wenigstens teilweise einem Ursprung und/oder einem Ziel, der/das im Headerabschnitt des gewählten Pakets identifiziert wurde, ob ein durch eine Brücke passierendes selektiertes Paket verschlüsselt werden soll;
dadurch gekennzeichnet, dass:
der Verschlüsselungsmechanismus die Aufgabe hat, ein gesamtes Paket einschließlich Headerabschnitt und Datenabschnitt zu verschlüsseln; und
Mittel zum Anhängen eines Encapsulation-Headers an die verschlüsselten Pakete, wobei der Encapsulation-Header eine Rundsendeadresse für eine Ursprungskennung und/oder eine Zielkennung für das Paket hat, wobei sich die in dem Encapsulation-Header verwendete Rundsendeadresse von der Korrespondenzursprungs- oder -zielkennung in dem selektierten Paket unterscheidet.
Gemäß einem vierten Aspekt der vorliegenden Erfindung wird eine Brücke zur Verwendung in einem Computernetz bereitgestellt, wobei die Brücke die Aufgabe hat, von dem Netzwerk gesendete und empfangene Pakete zu leiten und automatisch durch die Brücke passierende selektierte Pakete zu entschlüsseln, dadurch gekennzeichnet, dass die Brücke die Aufgabe hat, Datenpakete mit einem Encapsulation-Headerabschnitt und einem verschlüsselten Abschnitt zu entschlüsseln, der einen verschlüsselten Header und einen verschlüsselten Datenabschnitt beinhaltet,
Mittel zum Ermitteln, ob ein durch die Brücke passierendes selektiertes Paket entschlüsselt werden soll, auf der Basis von wenigstens einer Ursprungs- und/oder einer Zielkennung in dem Encapsulation-Headerabschnitt des selektierten Pakets, die eine Rundsendeadresse ist;
einen Entschlüsselungsmechanismus zum Entschlüsseln von Paketen, die entschlüsselt werden müssen, wobei der Entschlüsselungsmechanismus den Encapsulation-Header eliminiert und so ein entschlüsseltes Paket bildet, das einen Headerabschnitt und einen Datenabschnitt hat; und
Mittel zum Weiterleiten von entschlüsselten Paketen zur Zieladresse, die in dem entschlüsselten Paket identifiziert ist.
Aufgrund der vorliegenden Erfindung werden alle Meldungen, die als verschlüsselungsbedürftig vorbestimmt sind, z.B. alle Meldungen von einem bestimmten Host A zu einem anderen Host B, automatisch verschlüsselt, ohne jegliche separate Aktion seitens des Benutzers. Auf diese Weise kann niemand auf dem öffentlichen Verbindungsnetz den Inhalt der Pakete feststellen. Wenn der Encapsulation-Header die Ursprungs- und Zieladressen des Netzwerk-IP verwendet, mit verschlüsselten Ursprungs- und Zielhostadressen, dann werden auch die Hostidentitäten verborgen, und ein intervenierender Beobachter kann nur die Identitäten der Netzwerke erfassen.
Der Encapsulation-Header kann ein Feld mit einer Kennung der Ursprungstunnelungsbrücke beinhalten. Dies ist besonders dann nützlich, wenn mehr als eine Tunnelungsbrücke für ein bestimmtes Netz verwendet werden soll (wobei jede Tunnelungsbrücke verschiedene Verschlüsselungsanforderungen und Informationen hat), und in diesem Fall entschlüsselt die empfangende Tunnelungsbrücke die Datenpakete gemäß den lokal gespeicherten Informationen unter Anzeige des Verschlüsselungstyps und des Entschlüsselungskey für alle von der Ursprungstunnelungsbrücke kommenden Pakete.
Nachfolgend werden, jedoch nur beispielhaft, spezifische Ausgestaltungen der vorliegenden Erfindung mit Bezug auf die Begleitzeichnungen beschrieben. Dabei zeigt:
1 ein Diagramm eines Netzwerks von Computernetzen, in Verbindung mit denen das System der vorliegenden Erfindung verwendet werden kann;
2 ein Blockdiagramm eines Hostcomputers A auf einem Computernetz N1 gemäß 1;
3 ein Diagramm eines Netzwerks von Computernetzen mit Tunnelungsbrücken gemäß der vorliegenden Erfindung;
4 ein Blockdiagramm von mehreren Tunnelungsbrücken der vorliegenden Erfindung in einem Netzwerk von Computernetzen N1–N3 gemäß 3;
5 ein Diagramm einer anderen Konfiguration von Netzwerken mit Tunnelungsbrücken gemäß der vorliegenden Erfindung;
6 ein Fließschema, das das Verfahren des signaturlosen Tunnelns der vorliegenden Erfindung illustriert;
7 eine konventionelle Datenstruktur für ein Datenpaket;
8–11 modifizierte Datenstrukturen für die Verwendung in verschiedenen Ausgestaltungen des erfindungsgemäßen Systems;
12 ein Blockdiagramm eines Netzwerks von Computernetzen mit zwei Tunnelungsbrücken der Erfindung auf einem einzigen Computernetz.
Das System der vorliegenden Erfindung ist so ausgelegt, dass es in existierenden Computernetzen implementiert wird, und es verwendet in der bevorzugten Ausgestaltung den Zusatz einer Tunnelungsbrücke an Übergängen zwischen lokalen Computernetzen und öffentlichen oder größervolumigen Netzen wie z.B. dem Internet. Die Mechanismen zum Ausführen des erfindungsgemäßen Verfahrens werden von Computern implementiert, die als diese Tunnelungsbrücken fungieren und Programmanweisungen aufweisen, die in Speichern der Tunnelungsbrücken gespeichert sind, sowie geeignete (standardmäßige) Netzwerkverbindungen und Kommunikationsprotokolle.
3 zeigt ein Netzwerk 100 aus Netzen N1, N2 und N3 gemäß der Erfindung, wobei jedes Netzwerk eine Tunnelungsbrücke – jeweils TB1, TB2 und TB3 – aufweist, die alle Datenpakete von und zu den jeweiligen Netzwerken abfängt. Die Netze N1–N3 können in anderen Hinsichten mit den Netzen N1–N3 in konventionellen Designs identisch sein. In der nachfolgenden Beschreibung sind Verweise auf die Netze N1–N3 oder Hosts A und B als in Bezug auf die in 3 gezeigte Konfiguration anzusehen, wenn nichts Anderes angegeben ist.
In diesem System gibt es mehrere Betriebsarten, nachfolgend nummeriert und erörtert als Betriebsarten 1, 2, 2A, 3 und 3A. Betriebsart 1 verwendet die Konfiguration von 1, während die anderen Betriebsarten alle die Konfiguration von 3 benutzen. Die Merkmale der Tunnelungsbrücken TB1 und TB2 (einschließlich ihrer Programmanweisungen, der getroffenen Maßnahmen usw.) in den Betriebsarten 2–3A sind, in Betriebsart 1, jeweils Merkmale von Host A bzw. B.
Jede der Tunnelungsbrücken TB1–TB3 wird vorzugsweise in einem separaten, herkömmlichen Computer mit einem Prozessor und einem Speicher wie in 4 gezeigt implementiert. Der Speicher kann eine Kombination aus Arbeitsspeicher (RAM), Festwertspeicher (ROM) und anderen Speichermedien wie z.B. Plattenlaufwerken, CD-ROMs usw. sein. Die Programmanweisungen für jede der Brücken TB1–TB3 sind in ihren jeweiligen Speichern gespeichert und werden von ihren jeweiligen Mikroprozessoren ausgeführt. Das Verfahren der vorliegenden Erfindung wird mit einer Kombination von Schritten durchgeführt, die nach Bedarf von jedem der Prozessoren des sendenden Hosts A, der Tunnelungsbrücken TB1 und TB2 und des empfangenen Hosts B durchgeführt werden.
Die Verschlüsselung von Daten ist ein wichtiger Schritt im gesamten Verfahren der Erfindung, aber der im jeweiligen Fall zu verwendende Verschlüsselungsmechanismus ist nicht wesentlich. Es wird daher bevorzugt, einen flexiblen, leistungsstarken Verschlüsselungsansatz wie z.B. die Diffie-Hellman-Methode zu verwenden (siehe W. Diffie und M. Hellman, „New Directions in Cryptography", IEEE Transactions of Information Theory, November 1976). (Die Benutzung von Verschlüsselung in Verbindung mit IP-Datenübertragungen ist relativ ausführlich in der mitanhängigen Patentanmeldung der Anmelderin „Method and Apparatus for Key-Management Scheme for Use with Internet Protocols at Site Firewalls" von A. Aziz, Ser. Nr. 08/258,344, eingereicht am 10. Juni 1994, beschrieben, die hierin durch Bezugnahme eingeschlossen ist). Es ist aber jedes Verschlüsselungsschema geeignet, das die Verschlüsselung durch eine erste Maschine, die die Datenpakete sendet, und die Entschlüsselung durch eine Empfangsmaschine zulasst.
6 illustriert eine Ausgestaltung des erfindungsgemäßen Verfahrens und beginnt mit dem Erzeugen von Datenpaketen am sendenden Host A. Der Benutzer am Host A gibt herkömmliche Befehle zum Senden einer Datei oder dergleichen von Host A zu Host B ein, und der Hostcomputer A führt die Standardvorgänge zum Aufteilen der Dateien in Datenpakete wie in 7 gezeigt aus, die jeweils sowohl die Daten 410 als auch einen Header 400 enthalten. Bei Übertragungen über das Internet handelt es sich hier um den IP-Header. Die derzeitige Erörterung richtet sich zwar größtenteils auf IP-spezifische Implementationen, aber es ist zu verstehen, dass jedes beliebige Netzprotokoll in Verbindung mit der vorliegenden Erfindung verwendet werden kann.
In Box 200 gibt der Benutzer an Host A (siehe 3 und 6) den herkömmlichen Befehl zum Senden der Datei, Email oder dergleichen zu einem Empfänger ein, und Host A erzeugt die Datenpakete zum Senden über das Internet auf normale Weise. Jedes Datenpaket hat zunächst eine Struktur wie die des in 7 gezeigten Datenpakets 400, einschließlich einem Datenfeld 410 und einem Header-Feld 420. Der Header 420 beinhaltet die Zieladresse, in diesem Beispiel die IP-Adresse des Host B.
Die Datenpakete werden vom Host A in Box 210 gesendet, wieder auf herkömmliche Weise. In Box 220 wird jedoch jedes Paket von der Tunnelungsbrücke TB1 (siehe 3 und 4) abgefangen, wenn eine der Betriebsarten 2, 2A, 3 oder 3A verwendet wird (siehe nachfolgende Diskussion). Wenn Betriebsart 1 (nachfolgend beschrieben) verwendet wird, dann fallen die Schritte 220 und 280 weg, da diese Betriebsart keine Tunnelungsbrücken verwendet; stattdessen werden alle von den Tunnelungsbrücken in den Betriebsarten 2–3A getroffenen Maßnahmen von den Ursprungs- und Zielhosts selbst in Betriebsart 1 durchgeführt. Somit ist in der nachfolgenden Erörterung, wo immer TB1 oder TB2 erwähnt wird, zu verstehen, dass im Fall von Betriebsart 1 dasselbe Merkmal jeweils in Host A oder Host B vorhanden ist.
Im Speicher von TB1 (oder Host A, für Betriebsart 1) ist eine Lookup-Tabelle (nicht separat dargestellt) der Adressen von Hosts, beide auf dem Ortsnetz N1 und auf Fernnetzen wie z.B. N2 und N3, und eine Anzeige für jedes Netz gespeichert, ob Datenpakete von oder zu diesem Host zu verschlüsseln sind. In diesem Fall zeigt beispielsweise die Host-Tabelle von TB1 an, dass alle von Host A zu Host B gesendeten Meldungen zu verschlüsseln sind. Somit schlägt die Brücke TB1 (oder Host A) Host A und B in ihren Tabellen nach und ermittelt, dass die zu sendenden Datenpakete zuerst verschlüsselt werden müssen, wie in den Boxen 230 und 240 von 6 angedeutet ist.
Alternativ könnte die Tabelle die Netzwerk Kennungen (z.B. Rundsendeadressen) der Netze N1 und N2 speichern und anzeigen, dass alles, was von Netz N1 zu Netz N2 gesendet wird, zu verschlüsseln ist. In diesem Fall braucht die Tabelle nicht jeden Host in jedem Netz aufzuführen, so dass die Tabelle kleiner und leichter zu führen ist.
Wenn jeder Host aufgeführt ist, dann lässt sich jedoch eine größere Flexibilität erzielen, da es sein kann, dass Meldungen zu oder von bestimmten Hosts nicht verschlüsselt (zu) werden brauchen oder dürfen. In einer alternativen Ausgestaltung führt die Lookup-Tabelle die Netze N1 und N2 als Netze auf, zu und von denen Pakete zu verschlüsseln sind, und beinhaltet auch einen Host-Teil der Tabelle mit Angaben über Ausnahmen zu der normalen Verschlüsselungsregel für diese Netze. Wenn also Netze N1 und N2 in der Lookup-Tabelle aufgeführt sind, dann sollten von N1 zu N2 laufende Pakete normalerweise verschlüsselt werden. Wenn es jedoch eine „Ausnahmen"-Untertabelle gibt, die anzeigt, dass keine Pakete von Host A zu verschlüsselt sind, dann wird die normale Regel außer Kraft gesetzt. Diese Ausnahmen können sich jedoch in zwei Richtungen auswirken: wo die normale Regel darin besteht, dass die Pakete für ein bestimmtes Netzwerkpaar verschlüsselt werden sollen/nicht verschlüsselt werden sollen, und die Ausnahme darin besteht, dass dieser bestimmte Host (Ursprung oder Empfänger) oder dieses Hostpaar das Paket nicht trotzdem zu verschlüsseln ist. In dieser Ausgestaltung wird die geringe Größe und Wartungsfreundlichkeit der Netzwerk Tabellen im Großen und Ganzen beibehalten und die Hosts-Tabelle ist flexibel.
Wenn die von Host A zu Host B (oder Netz N1 zu Netz N2) zu sendenden Daten nicht zu verschlüsseln sind, dann geht das Verfahren direkt zu Schritt 270, und das fragliche Paket wird unverschlüsselt über das Internet (oder ein anderes intervenierendes Netz) zum Ziel gesendet.
In diesem Beispiel werden die Pakete in Box 250 verschlüsselt. Dies wird von der Tunnelungsbrücke TB1 durchgeführt, je nachdem, welches vorbestimmte Verschlüsselungsschema gewählt wurde, wobei die Hauptanforderung darin besteht zu gewährleisten, dass TB2 mit demselben Verschlüsselungsschema ausgestattet wird, so dass sie die Datenpakete entschlüsseln kann. TB2 muss ebenfalls im Voraus mit dem/den entsprechenden Key(s) zur Entschlüsselung ausgestattet werden.
Der Encapsulation-Header

In Box 260 wird ein Encapsulation-Header an das verschlüsselte Datenpaket angehängt. Dieser Header kann eine von mehreren alternativen Formen haben, je nach den Anforderungen des Benutzers. Mehrere Betriebsarten der Paketmodifikation können mit derselben Grunddatenstruktur aufgenommen werden (aber mit Unterschieden in den Informationen, die in den Encapsulation-Header angehängt werden), z.B. wie folgt:

Betriebsart	Angehängte Information
1	Verschlüsselungskey-Managementinformation (selbst unverschlüsselt) Neuer IP-Header mit ursprünglich erzeugten IP-Adressen von Ursprungs- und Zielhosts (unverschlüsselt)
2	Verschlüsselungskey-Managementinformation (in verschlüsselter Form) Tunnelungsbrückenkennung für Sender (unverschlüsselt) Neuer IP-Header mit Broadcast-Adressen von Ursprungs- und Zielnetzen (unverschlüsselt)
2A	(Wie Betriebsart 2, aber ohne Tunnelungsbrückenkennung)
3	Verschlüsselungskey-Managementinformation (verschlüsselt) Bei Bedarf: Tunnelungsbrückenkennung für Sender (unverschlüsselt) Neuer IP-Header mit ursprünglich erzeugten IP-Adressen von Ursprungs- und Zielhosts (unverschlüsselt)
3A	(Wie Betriebsart 3, aber ohne Tunnelungsbrückenkennung)

Datenstrukturen für Betriebsarten 1, 2 und 3 sind jeweils in den 8, 9 und 10 dargestellt, wo gleiche Bezugsziffern gleiche Merkmale bezeichnen, wie nachfolgend beschrieben wird. Die Datenstruktur für Betriebsart 2A ist in 11 illustriert, und Betriebsart 3A kann die Datenstruktur von 8 verwenden.
Die Datenstruktur 402 für Betriebsart 1 ist in 8 dargestellt. Die ursprünglichen Daten 410 und der ursprüngliche Header 420 werden jetzt verschlüsselt, wie mit (410) und (420) angedeutet ist. Verschlüsselungskey-Managementinformation 440 wird als Teil des neuen Encapsulation-Headers 430 zusammen mit einem neuen IP-Header 450 einschließlich der Adressen der Ursprungs- und Zielhosts (in verschlüsselter Form) angehängt. Die Information 430 beinhaltet eine Anzeige, welches Verschlüsselungsschema verwendet wurde.
Keymanagementinformationen können eine Reihe verschiedener Daten beinhalten, je nach den verwendeten Keymanagement- und Verschlüsselungsschemata. So wäre es beispielsweise angemessen, Simple Key-Management for Internet Protocols (SKIP) der Anmelderin zu verwenden.
In den 7–11 sind die Felder mit Bezugsziffern in Klammern verschlüsselt, und die anderen Felder sind unverschlüsselt. So sind beispielsweise in 8 das ursprüngliche Datenfeld 410 und das Adressfeld 420 verschlüsselt, während der neue Encapsulation-Header 430, einschließlich der Keymanagementinformation 440 und des IP-Headers 450, nicht verschlüsselt ist.
In dieser Ausgestaltung werden die Tunnelungsbrücken TB1 und TB2 möglicherweise überhaupt nicht verwendet, und stattdessen könnten die Hosts A und B alle Anweisungen, Tabellen usw. beinhalten, die zum Verschlüsseln, Entschlüsseln notwendig sind, und ermitteln, welche Pakete zu verschlüsseln sind und mit welchem Verschlüsselungsschema. Betriebsart 1 ermöglicht es einem intervenierenden Beobachter, die Ursprungs- und Zielhosts zu identifizieren, und bietet daher nicht das höchste Sicherheitsniveau. Es bietet jedoch effiziente und automatische Verschlüsselung und Entschlüsselung für Datenpakete zwischen Hosts A und B, ohne Notwendigkeit für zusätzliche Computer, die als TB1 und TB2 dienen.
Alternativ könnte Feld 440 in Betriebsart 1 die IP-Rundsendeadressen der Ursprungs- und Ziel-Netzwerke (anstatt von dem der Hosts selbst) beinhalten, und könnte zusätzlich einen Code in der Verschlüsselungskey-Managementinformation beinhalten, der angibt, welches Verschlüsselungsschema verwendet wurde. Diese Information könnte dann von einem abfangenden Computer (wie z.B. einer Tunnelungsbrücke) auf dem Zielnetz verwendet werden, der das Datenpaket entschlüsselt und es zum Zielhost weitersendet.
In Betriebsart 2 wird eine Datenstruktur 404 verwendet, die einen neuen Encapsulation-Header 432 beinhaltet. Sie beinhaltet eine Key-Verschlüsselungs-Managementinformation 440, die an das ursprüngliche Datenpaket 400 angehängt wird, und beide werden verschlüsselt, so dass sich die verschlüsselten Felder (410), (420) und (440) wie in 9 gezeigt ergeben. Ein neuer IP-Header 470 mit den Rundsendeadressen der Ursprungs- und Ziel-Netzwerke (nicht die Adressen der Hosts wie in Feld 450 von 8) ist angehängt. Darüber hinaus wird ein Tunnelungsbrücken-Kennungsfeld 460 als Teil des Encapsulation-Headers 432 angehängt. In dieser Ausgestaltung werden hier alle Felder 410, 420 und 440 verschlüsselt, die Felder 460 und 470 aber nicht.
Die Tunnelungsbrückenkennung identifiziert die Ursprungs-Tunnelungsbrücke, d.h. die Tunnelungsbrücke an dem Netz, das den Host enthält, von dem das Paket gesendet wurde. Die Empfängertunnelungsbrücke enthält eine Tunnelungsbrücken-Lookup-Tabelle, die für jede bekannte Tunnelungsbrücke evtl. benötigte Informationen zur Entschlüsselung anzeigt, insbesondere Verschlüsselungsverfahren und Key.
Eine geeignete Tunnelungsbrückenkennung könnte ein Drei-Byte-Feld sein, so dass sich 2²⁴ oder mehr als 16 Millionen einmalige Tunnelungsbrückenkennungen ergeben. Auf diese Weise kann einer willkürlich großen Zahl von individuellen Tunnelungsbrücken eine eindeutige Kennung gegeben werden, einfach dadurch, dass das Feld möglichst groß gemacht wird, und in der Tat kann das Feld von einer vom Benutzer gewählten willkürlichen variablen Größe sein. Falls gewünscht, kann ein Vier-Byte-Feld verwendet werden, das mehr als 4 Milliarden Tunnelungsbrücken aufnimmt, was die derzeitigen Erfordernisse bei weitem überschreitet.
Bei Verwendung von Betriebsart 2 kann ein beliebiger Beobachter entlang der Schaltung, die von einem bestimmten Datenpaket eingenommen wird, nur die Tunnelungsbrückenkennung und die IP-Rundsendeadressen für die Ursprungs- und Zielnetze erkennen.
Die IP-Rundsendeadresse für das Zielnetz sieht gewöhnlich etwa wie folgt aus: „129.144.0.0", was ein bestimmtes Netz repräsentiert (in diesem Fall „Eng.Sun.COM"), aber keinen spezifischen Host. Somit kann an Zwischenpunkten auf der Route des Pakets erkannt werden, dass eine Nachricht beispielsweise von „washington.edu" zu „Eng.Sun.COM" geht, und die Identifikationsnummer der empfangenden Tunnelungsbrücke kann ermittelt werden, aber das ist auch schon alles; die Ursprungs- und Zielhosts, die Keymanagementinformation sowie der Inhalt des Datenpakets sind alle verborgen.
Betriebsart 2A benutzt die in 11 gezeigte Datenstruktur, bei der die IP-Rundsendeadressen für die Ursprungs- und Empfangsnetze N1 und N2 im Encapsulation-Header-Feld 470 enthalten sind, aber es wird keine Tunnelungsbrückenkennung verwendet. Diese Ausgestaltung ist besonders für Netze geeignet, bei denen es nur eine Tunnelungsbrücke für das gesamte Netz oder sogar für mehrere Netze gibt, wie in 5 illustriert ist.
In 5 wird ein vom Host C zu Host D gesendetes Paket zunächst von Netz N4 zu Netz N5 gesendet und wird dann von der Tunnelungsbrücke TB4 abgefangen, die alle Meldungen abfängt, die in diese beiden Netze eintreten oder diese verlassen. TB4 verschlüsselt das Paket oder auch nicht, je nach Angabe in der Lookup-Tabelle ihrer Hosts. Das Paket durchquert das öffentliche Netz und wird zu Netz N7 geleitet und wird zunächst von der Tunnelungsbrücke TB5 abgefangen (die alle in die Netze N6–N8 eintretenden oder diese verlassenden Meldungen abfängt), und an diesem Punkt bei Bedarf entschlüsselt.
In dieser Ausgestaltung oder einer beliebigen Ausgestaltung, in der ein Paket von einem Host auf einem Netzwerk gesendet wird, wobei eine einzelne Tunnelungsbrücke für das gesamte Ursprungsnetz oder für mehrere Netze verwendet wird, die das Ursprungsnetz beinhalten, ist eine Tunnelungsbrückenkennung kein notwendiges Feld im Encapsulation-Header. Da in diesem Fall nur eine bestimmte Tunnelungsbrücke Pakete von einem bestimmten Host hätte abfangen können (z.B. TB4 für Host C in 5), ist die Identität der Ursprungstunnelungsbrücke eindeutig, und die Zieltunnelungsbrücke TB5 enthält eine Tabelle von Hosts und/oder Netzwerken, mit TB4 querkorreliert. Wenn ermittelt wurde, dass die Tunnelungsbrücke TB4 die Ursprungstunnelungsbrücke war, dann fährt TB5 mit der richtigen Entschlüsselung fort.
Dieser Ansatz hat mehrere Vorteile, nämlich, dass er die Notwendigkeit eliminiert, Tunnelungsbrücken zu „benennen" oder zu nummerieren, und reduziert die Größen der Datenpakete durch Eliminieren eines Feldes. Ein Tunnelungsbrücken-Kennungsfeld bietet jedoch Flexibilität. So sind beispielsweise in 12 die Subnetze N11 und N12 Teile eines größeren Netzes N10, und jedes Subnetz N11 und N12 hat seine eigene zugewiesene Tunnelungsbrücke (jeweils TB7 bzw. TB8). Somit können die Subnetze N11 und N12 automatisch verschiedenen Verschlüsselungstypen unterzogen werden, und diese Verschlüsselung kann nach Bedarf für ein Subnetz geändert werden, während es für das andere unverändert bleibt.
Ein von Host F zu Host E in 12 gehendes Paket beinhaltet eine Ursprungstunnelungsbrückenkennung (TB7), so dass es, wenn es TB6 auf Netz N9 erreicht, korrekt als von TB7 und nicht von TB8 verschlüsselt identifiziert wird. Auf diese Weise braucht die Tunnelungsbrücke TB6 nur eine Tabelle mit Informationen in Bezug auf die Tunnelungsbrücken zu führen, und braucht keine Verschlüsselungs-/Entschlüsselungseinzelheiten für die Host- oder Netzebene zu führen. (Man beachte, dass TB6 weiter Informationen darüber führt, ob Meldungen verschlüsselt werden sollen, die zwischen Host A und Host B oder Netz N1 und Netz N2 gesendet werden, je nachdem, wie oben erörtert.)
Die Tunnelungsbrückenkennung kann für eine Reihe verschiedener anderer Zwecke in Bezug auf die Ursprungstunnelungsbrücke verwendet werden, wie z.B. für Statistiken, die die Zahl der von dieser Tunnelungsbrücke empfangenen Pakete, deren Sendedatum und -uhrzeit, Paketgröße usw. aufzeichnen.
Eine Alternative zur Verwendung von Host- oder Netztabellen in den Speichern der Ursprungs- und Zieltunnelungsbrücken (oder Ursprungs- und Zielhosts, je nachdem) wäre eine beliebige Information, die ein oder mehrere vorbestimmte Kriterien identifiziert, mit denen der Ursprungshost oder die Ursprungstunnelungsbrücke ermittelt, ob ein bestimmtes Datenpaket zu verschlüsseln ist. Solche Kriterien brauchen nicht nur Ursprungs- und Zielinformationen zu sein, sondern könnten auch Paketinhalt, Sendezeit, Gegenstandsheaderinformation, Benutzer-ID, Anwesenheit eines Schlüsselworts (wie z.B. „Verschlüsseln") im Text des Pakets oder andere Kriterien beinhalten.
Betriebsart 3 verwendet eine Datenstruktur 406 wie in 10 gezeigt, die mit der Datenstruktur 402 identisch ist, mit Ausnahme des Zusatzes von Feld 460, das die Tunnelungsbrückenkennung enthält, die dieselbe ist wie die oben in Bezug auf Betriebsart 2 erörterte Tunnelungsbrückenkennung.
In dieser Ausgestaltung, wie in Betriebsart 1, beinhaltet Feld 450 die ursprünglichen Host-IP-Adressen für die Ursprungs- und Ziel-Hosts (nicht die Adressen der Netzwerke wie in Betriebsart 2), und somit kann ein Beobachter eines Pakets in Betriebsart 3 sowohl den ursprünglichen Sender des Datenpakets als auch den beabsichtigten Empfänger ermitteln. Beide Betriebsarten enthalten genügend Informationen zum Leiten von Paketen durch ein Internet zur Tunnelungsbrücke eines Empfängernetzes zur Entschlüsselung und schließlich zur Lieferung zum Empfangshost.
Betriebsart 3A kann die in 8 gezeigte Datenstruktur in Zusammenhang mit einer Netzkonfiguration wie der in den 3 oder 12 gezeigten verwenden. Die Mechanismen und relativen Vorteile sind mit den oben für Betriebsart 2A beschriebenen identisch, während die Struktur die Ursprungs- und Zielhostadressen offenbart.
Welcher Encapsulation-Header in Box 260 auch hinzukommt (siehe 6), das Paket wird in Box 270 zum Zielnetz gesendet. In Box 280 fängt die Tunnelungsbrücke (hier TB2 wie in 3 gezeigt) des Zielnetzes das Paket ab, was mit einer Anweisungsroutine geschieht, mit der alle Pakete abgefangen und auf Encapsulation-Header-Informationen untersucht werden, die Verschlüsselung anzeigen.
Somit wird in Box 290 der Encapsulation-Header des Pakets gelesen und in Box 300 wird ermittelt, ob das Paket verschlüsselt war. Wenn eine Tunnelungsbrückenkennung einen Teil des eingekapselten Pakets bildet, dann werden das Verschlüsselungsverfahren und der Entschlüsselungskey anhand der lokalen Tabellen der Zieltunnelungsbrücke (oder der Zielhosts, im Fall von Betriebsart 1) ermittelt.
Wenn am Paket keine Verschlüsselung durchgeführt wurde, dann wird es ohne weitere Maßnahme zum richtigen Host weitergesendet, wie in Box 340 angedeutet ist. Ansonsten wird das Verschlüsselungsverfahren ermittelt (Box 320) und das Paket wird entsprechend entschlüsselt (Box 330) und dann weitergesendet (Box 340).

Claims

Verfahren zum Verschlüsseln von Datenpaketen, die über ein Verbindungsnetz von einem Ursprungshostcomputer (A) auf einem ersten Computernetz (N1) mit einer Brücke (TB1) zu einem Zielhostcomputer (B) gesendet wurden, der potentiell Teil eines zweiten Computernetzes (N2) ist, wobei das Verfahren die folgenden Schritte umfasst: Empfangen eines Datenpakets (400) von dem Ursprungshostcomputer (A) in dem ersten Computernetz (N1) an der Brücke für die Übertragung zum Zielhostcomputer (B), wobei das Datenpaket (400) einen Originalheaderabschnitt (420) und einen Originaldatenabschnitt (410) beinhaltet, wobei der Originalheaderabschnitt (420) eine den Ursprungshostcomputer (A) identifizierende Ursprungskennung und eine den Zielhostcomputer identifizierende Zielkennung beinhaltet; Ermitteln in der Brücke (TB1), wenigstens teilweise auf der Basis der Bezugnahme auf die Ursprungs- und/oder die Zielkennung, ob das Datenpaket (400) verschlüsselt werden soll; und Verschlüsseln des Datenpakets (400) zum Erzeugen eines verschlüsselten Datenpakets; wobei das Verfahren dadurch gekennzeichnet ist, dass: die Verschlüsselung des Datenpakets die Verschlüsselung sowohl des Originaldatenabschnitts (410) als auch das Originalheaderabschnitts (420) beinhaltet; es den Schritt des Erzeugens eines Encapsulation-Headers (430, 432, 434) und Anhängens des Encapsulation-Headers an das verschlüsselte Datenpaket beinhaltet, um ein modifiziertes Datenpaket (402, 404, 406) zu erzeugen, wobei der Encapsulation-Header eine Verbindungsnetzrundsendeadresse beinhaltet, die mit dem ersten und/oder dem zweiten Netzwerk (N1, N2) assoziiert ist, so dass das modifizierte Datenpaket (402, 404, 406) den Encapsulation-Header (430, 432, 434) und einen verschlüsselten Abschnitt hat, der verschlüsselte Versionen des Originalheaderabschnitts und des Originaldatenabschnitts beinhaltet.
Verfahren nach Anspruch 1, wobei der Encapsulation-Header die Verbindungsnetzrundsendeadresse des ersten Computernetzes (N1) als Ursprungskennung für den Ursprungshostcomputer (A) beinhaltet.
Verfahren nach Anspruch 1 oder 2, wobei der Encapsulation-Header (430, 432, 434) die Verbindungsnetzrundsendeadresse des zweiten Computernetzes (N2) als Zielkennung für den Zielhostcomputer (B) beinhaltet.
Verfahren nach einem der vorherigen Ansprüche, wobei die Ursprungskennung im Originalheaderabschnitt (420) die Adresse des Ursprungshostcomputers (A) ist.
Verfahren nach einem der vorherigen Ansprüche, wobei die Zielkennung im Originalheaderabschnitt (420) die Adresse des Zielhostcomputers (B) ist.
Verfahren nach einem der vorherigen Ansprüche, ferner umfassend: Empfangen des modifizierten Datenpakets (402, 404, 406) an einer zweiten Brücke (TB2); Ermitteln in der zweiten Brücke (TB2), nach Bezugnahme auf die Ursprungs- und/oder Zielkennung im Encapsulation-Header (432, 434, 436), ob das Datenpaket verschlüsselt ist; und Entschlüsseln des Datenpakets in der zweiten Brücke (TB2), um ein entschlüsseltes Datenpaket zu erzeugen, wobei der entschlüsselte Originalheaderabschnitt nach dem Entschlüsseln als Header für das entschlüsselte Datenpaket verwendet wird; und Weiterleiten des entschlüsselten Pakets zum Zielhostcomputer (B).
Verfahren nach einem der vorherigen Ansprüche, wobei der Encapsulation-Header (432, 434, 436) ferner Key-Management-Informationen (440) beinhaltet, die den Verschlüsselungsmechanismus identifizieren, der zum Verschlüsseln des Datenpakets verwendet wurde.
Verfahren nach einem der vorherigen Ansprüche, wobei die Ermittlung, dass das Datenpaket (400) verschlüsselt werden soll, wenigstens teilweise auf einer Bezugnahme auf eine Datenstruktur basiert, die Ursprünge und/oder Ziele identifiziert, für die Sicherheit erforderlich ist.
Verfahren zum Entschlüsseln von Datenpaketen, umfassend die folgenden Schritte: Empfangen eines verschlüsselten Datenpakets (400) von einem Ursprung (A) für ein Ziel (B); Ermitteln, ob das Datenpaket (400) verschlüsselt ist; und Entschlüsseln des Datenpakets (400) zum Erzeugen eines entschlüsselten Datenpakets, dadurch gekennzeichnet, dass: dem verschlüsselten Datenpaket ein Encapsulation-Header (430, 432, 434) gegeben wird, der eine Ursprungskennung und eine Zielkennung speichert, von denen wenigstens eine eine Rundsendeadresse ist; der Schritt des Ermittelns, ob das Datenpaket verschlüsselt ist, nach Bezugnahme auf die Ursprungs- und/oder Zielkennung erfolgt; das verschlüsselte Datenpaket einen verschlüsselten Headerabschnitt (420) und einen verschlüsselten Datenabschnitt (410) beinhaltet; und der entschlüsselte Headerabschnitt (420) nach dem Entschlüsseln als Header für das entschlüsselte Datenpaket (400) verwendet wird.
Verfahren nach Anspruch 9, wobei die Empfangs-, Ermittlungs- und Verschlüsselungsschritte alle von einer Brücke (TB2) ausgeführt werden, die mit einem Netzwerk (N2) assoziiert ist, das das Ziel (B) beinhaltet, wobei das Verfahren ferner das Weiterleiten des entschlüsselten Datenpakets (400) zum Ziel umfasst.
Verfahren nach Anspruch 9 oder Anspruch 10, wobei der Encapsulation-Header (430, 432, 434) ferner Key-Management-Informationen beinhaltet, die den Verschlüsselungsmechanismus identifizieren, der zum Verschlüsseln des Datenpakets verwendet wurde.
Brücke (TB1) für die Verwendung in einem Computernetz (N1), wobei die Brücke die Aufgabe hat, von dem Netzwerk (N1) gesendete und empfangene Pakete (400) zu leiten und automatisch durch die Brücke (TB1) passierende selektierte Pakete (400) zu verschlüsseln, wobei die Pakete (400) einen Headerabschnitt (420) und einen Datenabschnitt (410) haben, wobei die Brücke Folgendes umfasst: einen Verschlüsselungsmechanismus zum Verschlüsseln selektierter Pakete (400); Mittel zum Ermitteln auf der Basis von wenigstens teilweise einem Ursprung und/oder einem Ziel, der/das im Headerabschnitt (420) des gewählten Pakets (400) identifiziert wurde, ob ein durch eine Brücke passierendes selektiertes Paket (400) verschlüsselt werden soll; dadurch gekennzeichnet, dass: der Verschlüsselungsmechanismus die Aufgabe hat, ein gesamtes Paket (400) einschließlich Headerabschnitt (420) und Datenabschnitt (410) zu verschlüsseln; und Mittel zum Anhängen eines Encapsulation-Headers (430, 432, 434) an die verschlüsselten Pakete, wobei der Encapsulation-Header (430, 432, 434) eine Rundsendeadresse für eine Ursprungskennung und/oder eine Zielkennung für das Paket (400) hat, wobei sich die in dem Encapsulation-Header verwendete Rundsendeadresse von der Korrespondenzursprungs- oder -zielkennung in dem selektierten Paket (400) unterscheidet.
Brücke nach Anspruch 12, ferner umfassend Sicherheitsinformationen, die im Speicher in der Brücke (TB1) gespeichert sind und spezifische Ursprünge und/oder Ziele identifizieren, für die Sicherheit erforderlich ist, wobei die Sicherheitsinformationen zum Ermitteln verwendet werden, ob ein selektiertes Paket (400) verschlüsselt werden soll.
Brücke nach Anspruch 12 oder 13, die ferner Folgendes umfasst: Mittel zum Ermitteln, nach Bezugnahme auf die Ursprungs- und/oder Zielkennung in dem Encapsulation-Header (430, 432, 434), ob ein empfangenes Datenpaket (400) verschlüsselt ist; einen Entschlüsselungsmechanismus zum Entschlüsseln eines empfangenen Paketes; und Mittel zum Weiterleiten eines entschlüsselten Paketes zu einem Rechenknoten (B) auf der Basis einer entschlüsselten Zieladresse.
Brücke nach einem der Ansprüche 12 bis 14, ferner umfassend Mittel zum Einsetzen von Key-Management-Informationen in den Encapsulation-Header, die das zum Verschlüsseln des Pakets (400) verwendete Verschlüsselungsverfahren identifizieren.
Brücke nach einem der Ansprüche 12 bis 15, die ferner eine Tabelle beinhaltet, die Ursprungs- und Zieladressen identifiziert, die verschlüsselt werden müssen.
Erstes Netzwerk (N1) mit einer Mehrzahl von Rechenknoten und einer Brücke (TB1) nach einem der Ansprüche 12 bis 16.
System, umfassend ein erstes Netzwerk nach Anspruch 17 und ein zweites Netzwerk (N2) mit einer zweiten Brücke (TB2) und einer zweiten Mehrzahl von Rechenknoten, wobei die zweite Brücke (TB2) Folgendes umfasst: Mittel zum Ermitteln nach Bezugnahme auf die Ursprungs- und/oder Zielkennung in dem Encapsulation-Header, ob ein empfangenes Datenpaket (430, 432, 434, 400) verschlüsselt ist; einen Entschlüsselungsmechanismus zum Entschlüsseln des empfangenen Pakets; und Mittel zum Weiterleiten des entschlüsselten Pakets (400) zu einem Rechenknoten in dem zweiten Netzwerk (N2) auf der Basis einer entschlüsselten Zieladresse.
Brücke (TB2) für die Verwendung in einem Computernetz, wobei die Brücke (TB2) die Aufgabe hat, von dem Netzwerk gesendete und empfangene Pakete (400) zu leiten und automatisch durch die Brücke passierende selektierte Pakete zu entschlüsseln, dadurch gekennzeichnet, dass die Brücke die Aufgabe hat, Datenpakete (400) mit einem Encapsulation-Headerabschnitt (430, 432, 434) und einem verschlüsselten Abschnitt zu entschlüsseln, der einen verschlüsselten Header (420) und einen verschlüsselten Datenabschnitt (410) beinhaltet; und dadurch, dass die Brücke ferner Folgendes umfasst: Mittel zum Ermitteln, ob ein durch die Brücke passierendes selektiertes Paket (400) entschlüsselt werden soll, auf der Basis von wenigstens einer Ursprungs- und/oder einer Zielkennung in dem Encapsulation-Headerabschnitt (430, 432, 434) des selektierten Pakets, die eine Rundsendeadresse ist; einen Entschlüsselungsmechanismus zum Entschlüsseln von Paketen (400), die entschlüsselt werden müssen, wobei der Entschlüsselungsmechanismus den Encapsulation-Header (430, 432, 434) eliminiert und so ein entschlüsseltes Paket bildet, das einen Headerabschnitt (420) und einen Datenabschnitt (410) hat; und Mittel zum Weiterleiten von entschlüsselten Paketen (400) zur Zieladresse, die in dem entschlüsselten Paket identifiziert ist.
Brücke nach Anspruch 19, wobei der Entschlüsselungsmechanismus Pakete mit einer Mehrzahl von verschiedenen Verschlüsselungsalgorithmen entschlüsseln kann, wobei die Brücke ferner Mittel zum Erfassen von Key-Informationen in dem Encapsulation-Header (430, 432, 434) umfasst, um den zum Entschlüsseln des Pakets zu verwendenden Entschlüsselungsalgorithmus zu identifizieren.