Übersicht zu Secure RPC

Durch Secure RPC (Remote Procedure Call) werden Remote-Verfahren durch einen Authentifizierungsmechanismus geschützt. Durch den Diffie-Hellman-Authentifzierungsmechanismus werden sowohl der Host als auch der Benutzer, der eine Anforderung für einen Service stellt, authentifiziert. Der Authentifizierungsmechanismus verwendet eine DES-Verschlüsselung (Data Encryption Standard). Zu den Anwendungen, die Secure RPC verwenden, zählen NFS und die Naming Services NIS und NIS+.

NFS-Services und Secure RPC

Durch NFS können mehrere Hosts Dateien über das Netzwerk gemeinsam verwenden. Bei einem NFS-Service speichert ein Server die Daten und Ressourcen für mehrere Clients. Die Clients verfügen über Zugriff auf die Dateisysteme, die der Server gemeinsam mit den Clients verwendet. Benutzer, die an den Clientsystemen angemeldet sind, können auf die Dateisysteme zugreifen, indem sie die Dateisysteme über den Server einhängen. Für den Benutzer im Clientsystem sieht es aus, als ob die Dateien lokal auf dem Client vorhanden wären. Bei einer der häufigsten Verwendungen von NFS können Systeme in Büros installiert werden, während alle Benutzerdateien an einem zentralen Ort gespeichert werden. Durch einige Funktionen des NFS-Service, wie der Option -nosuid für den Befehl mount, kann verhindert werden, dass Geräte und Dateisysteme durch unberechtigte Benutzer geöffnet werden.

Der NFS-Service verwendet Secure RPC für die Authentifizierung der Benutzer, die Anforderungen über das Netzwerk stellen. Dieser Prozess wird als Secure NFS bezeichnet. Der Diffie-Hellman-Authentifizierungsmechanismus (AUTH_DH) verwendet DES-Verschlüsselung, um einen berechtigten Zugriff zu ermöglichen. Der AUTH_DH-Mechanismus kann auch als AUTH_DES bezeichnet werden. Weitere Informationen finden Sie hier:

• Einrichten und Verwalten von Secure NFS: Verwalten des Secure NFS-Systems in Systemverwaltungshandbuch: Netzwerkdienste

• Einrichten von NIS+-Tabellen und Eingeben von Namen in der Tabelle cred: System Administration Guide: Naming and Directory Services (NIS+)

• Übersicht der Transaktionen bei der RPC-Authentifizierung: Implementierung der Diffie-Hellman-Authentifizierung

DES-Verschlüsselung mit Secure NFS

Die Funktionen der DES-Verschlüsselung (Data Encryption Standard) verwenden einen 56-Bit-Schlüssel zum Verschlüsseln der Daten. Wenn zwei Benutzer mit Berechtigungen oder zwei Hauptelemente denselben DES-Schlüssel kennen, können sie eine private Kommunikation durchführen, indem sie mit dem Schlüssel Text verschlüsseln und entschlüsseln. DES ist ein relativ schneller Verschlüsselungsmechanismus. Ein DES-Chip ermöglicht eine weitere Beschleunigung der Verschlüsselung. Wenn der Chip jedoch nicht vorhanden ist, wird er durch eine Softwareimplementierung ersetzt.

Wenn nur der DES-Schlüssel verwendet wird, besteht das Risiko, dass ein Eindringling einen ausreichenden Umfang an Verschlüsselungstextmeldungen erfassen kann, die mit dem gleichen Schlüssel verschlüsselt wurden, und so den Schlüssel feststellen und die Meldungen entschlüsseln kann. Daher müssen Sicherheitssysteme wie Secure NFS die Schlüssel häufig ändern.

Kerberos-Authentifizierung

Kerberos ist ein Authentifizierungssystem, das vom MIT entwickelt wurde. Die Verschlüsselung in Kerberos basiert in einigen Fällen auf DES. Die Unterstützung für Kerberos V4 wird im Rahmen von Secure RPC nicht mehr zur Verfügung gestellt. Eine client- und serverseitige Implementierung von Kerberos V5, die RPCSEC_GSS verwendet, ist jedoch in dieser Version enthalten. Weitere Informationen erhalten Sie unter Kapitel 21Einführung zum Kerberos-Service.

Diffie-Hellman-Authentifizierung und Secure RPC

Die DH-Methode (Diffie-Hellman) zur Authentifizierung eines Benutzers ist nicht trivial und für einen Eindringling nur schwer zu entschlüsseln. Der Client und Server verfügen über einen eigenen privaten Schlüssel, der zusammen mit dem öffentlichen Schlüssel zum Erstellen eines allgemeinen Schlüssels verwendet wird. Der private Schlüssel wird auch als der geheime Schlüssel bezeichnet. Der Client und Server verwenden den allgemeinen Schlüssel für die gemeinsame Kommunikation. Der allgemeine Schlüssel wird durch eine vereinbarte Verschlüsselungsfunktion (z. B. DES) verschlüsselt.

Bei der Authentifizierung kann das sendende System mit dem allgemeinen Schlüssel die aktuelle Uhrzeit verschlüsseln. Anschließend kann das empfangende System den Schlüssel entschlüsseln und mit der eigenen aktuellen Uhrzeit vergleichen. Die Uhrzeiten auf dem Client und Server müssen synchronisiert sein. Weitere Informationen erhalten Sie unter Verwalten von Network Time Protocol (Aufgaben) in Systemverwaltungshandbuch: Netzwerkdienste.

Die öffentlichen und privaten Schlüssel werden in einer NIS- oder NIS+-Datenbank gespeichert. Bei NIS werden die Schlüssel in der Map publickey gespeichert. Bei NIS+ werden die Schlüssel in der Tabelle cred gespeichert. Diese Dateien enthalten den öffentlichen und privaten Schlüssel für alle potenziellen Benutzer.

Der Systemadministrator ist verantwortlich für die Einrichtung der NIS-Maps oder NIS+-Tabellen und für das Generieren eines öffentlichen und privaten Schlüssels für die einzelnen Benutzer. Der private Schlüssel wird zusammen mit dem Passwort des Benutzers in verschlüsselter Form gespeichert. Dadurch kennt nur der Benutzer den privaten Schlüssel.

Implementierung der Diffie-Hellman-Authentifizierung

Im diesem Abschnitt werden eine Reihe von Transaktionen in einer Client-Server-Sitzung beschrieben, in der die Diffie-Hellman-Authentifizierung (AUTH_DH) verwendet wird.

Generieren der öffentlichen und geheimen Schlüssel für Secure RPC

In einigen Fällen führt der Administrator vor einer Transaktion entweder den Befehl newkey oder nisaddcred aus, um einen öffentlichen und geheimen Schlüssel zu generieren. Jeder Benutzer erhält einen eindeutigen öffentlichen und geheimen Schlüssel. Der öffentliche Schlüssel wird in einer öffentlichen Datenbank gespeichert. Der geheime Schlüssel wird in der gleichen Datenbank in verschlüsselter Form gespeichert. Durch den Befehl chkey wird das Schlüsselpaar geändert.

Ausführen des Befehls keylogin für Secure RPC

Normalerweise entspricht das Passwort für die Anmeldung dem Passwort für Secure RPC. In diesem Fall ist der Befehl keylogin nicht erforderlich. Wenn die Passwörter jedoch unterschiedlich sind, müssen sich die Benutzer anmelden und anschließend den Befehl keylogin ausführen.

Durch den Befehl keylogin wird der Benutzer zur Eingabe eines Passworts für Secure RPC aufgefordert. Der Befehl verwendet anschließend das Passwort zum Entschlüsseln des geheimen Schlüssels. Anschließend leitet der Befehl keylogin den entschlüsselten geheimen Schlüssel an das Programm keyserver weiter. Der Schlüsselserver (Keyserver) ist ein RPC-Service mit einer lokalen Instanz auf jedem Computer. Der Schlüsselserver speichert den entschlüsselten geheimen Schlüssel und wartet, bis der Benutzer eine Secure RPC-Transaktion mit einem Server startet.

Wenn das Passwort für die Anmeldung und das Passwort für RPC identisch sind, leitet der Anmeldeprozess den geheimen Schlüssel an den Schlüsselserver weiter. Wenn die Passwörter unterschiedlich sein müssen, muss der Benutzer jedes Mal den Befehl keylogin ausführen. Wenn der Befehl keylogin in der Konfigurationsdatei der Benutzerumgebung enthalten ist (z. B. Datei ~/.login, ~/.cshrc oder ~/.profile), wird der Befehl keylogin bei jeder Anmeldung des Benutzers automatisch ausgeführt.

Generieren des Dialogschlüssels für Secure RPC

Wenn der Benutzer eine Transaktion mit einem Server startet, geschieht Folgendes:

1. Der Schlüsselserver generiert einen zufällig erzeugten Dialogschlüssel.

2. Der Kernel verwendet den Dialogschlüssel sowie weiteres Material, um den Zeitstempel des Clients zu verschlüsseln.

3. Der Schlüsselserver sucht den öffentlichen Schlüssel des Servers in der Datenbank für öffentliche Schlüssel. Weitere Informationen erhalten Sie auf der Manpage publickey(4).

4. Der Schlüsselserver verwendet den geheimen Schlüssel des Clients und den öffentlichen Schlüssel des Servers, um einen gemeinsamen Schlüssel zu erstellen.

5. Der Schlüsselserver verschlüsselt den Dialogschlüssel mit dem allgemeinen Schlüssel.

Anfängliche Kontaktaufnahme des Servers mit Secure RPC

Die Übertragung, die den verschlüsselten Zeitstempel und den verschlüsselten Dialogschlüssel enthält, wird anschließend an den Server gesendet. Die Übertragung enthält einen Berechtigungsnachweis und Verifikator. Der Berechtigungsnachweis weist drei Bestandteile auf:

• Den Netzwerknamen des Clients

• Den Dialogschlüssel, der durch den allgemeinen Schlüssel verschlüsselt wird

• Ein "Fenster", das durch den Dialogschlüssel verschlüsselt wird

Das Fenster ist der Zeitunterschied, den der Client zwischen dem Takt des Servers und dem Zeitstempel des Clients zulässt. Wenn der Unterschied zwischen dem Takt des Servers und dem Zeitstempel größer als das Fenster ist, weist der Server die Clientanforderung zurück. Unter normalen Umständen geschieht keine Zurückweisung, da der Client zuerst eine Synchronisierung mit dem Server durchführt, bevor die RPC-Sitzung gestartet wird.

Der Verifikator des Clients enthält Folgendes:

• Den verschlüsselten Zeitstempel

• Einen verschlüsselten Verifikator des angegebenen Fensters, der dekremental um den Wert von 1 verringert wird

Der Fensterverifikator wird benötigt, falls ein Benutzer einen anderen Benutzer imitieren möchte. Der Imitator kann ein Programm schreiben, das nicht die verschlüsselten Felder des Berechtigungsnachweises und Verifikators ausfüllt, sondern nur zufällige Bits einfügt. Der Server entschlüsselt den Dialogschlüssel in einen zufällig erzeugten Schlüssel. Der Server verwendet anschließend den Schlüssel, um das Fenster und den Zeitstempel zu entschlüsseln. Das Ergebnis sind zufällig erzeugte Zahlen. Nach einigen tausend Versuchen erreicht das zufällig erzeugte Fenster/Zeitstempel-Paar möglicherweise einen Zugriff am Authentifizierungssystem. Durch den Fensterverifikator verringert sich die Möglichkeit, dass ein gefälschter Berechtigungsnachweis authentifiziert wird.

Entschlüsseln des Dialogschlüssels mit Secure RPC

Wenn der Server die Übertragung vom Client erhält, geschieht Folgendes:

1. Der Schlüsselserver, der sich lokal am Server befindet, sucht den öffentlichen Schlüssel des Clients in der Datenbank für öffentliche Schlüssel.

2. Der Schlüsselserver verwendet den öffentlichen Schlüssel des Clients und den geheimen Schlüssel des Servers, um den allgemeinen Schlüssel abzuleiten. Der allgemeine Schlüssel ist der gleiche allgemeine Schlüssel, der vom Client berechnet wird. Nur der Server und Client können den allgemeinen Schlüssel berechnen, da für die Berechnung einer der geheimen Schlüssel bekannt sein muss.

3. Der Kernel verwendet den allgemeinen Schlüssel zum Entschlüsseln des Dialogschlüssels.

4. Der Kernel ruft den Schlüsselserver auf, um den Zeitstempel des Clients mit dem entschlüsselten Dialogschlüssel zu entschlüsseln.

Speichern der Informationen auf dem Server mit Secure RPC

Nachdem der Server den Zeitstempel des Clients entschlüsselt hat, speichert der Server vier Arten von Informationen in einer Berechtigungsnachweistabelle:

• Den Computernamen des Clients

• Den Dialogschlüssel

• Das Fenster

• Den Zeitstempel des Clients

Der Server speichert die ersten drei Elemente, um sie zu einem späteren Zeitpunkt zu verwenden. Der Server speichert den Zeitstempel des Clients, um Wiederholungen zu vermeiden. Der Server akzeptiert nur Zeitstempel, die chronologisch nach dem letzten angezeigten Zeitstempel liegen. Daher werden wiederholte Transaktionen auf jeden Fall zurückgewiesen.

Zurückgeben des Verifikators an den Client mit Secure RPC

Der Server gibt einen Verifikator an den Client zurück, der Folgendes enthält:

• Die Index-ID, die der Server im zugehörigen Berechtigungsnachweis-Cache aufzeichnet

• Den Zeitstempel des Clients abzüglich des Werts von 1, der durch den Dialogschlüssel verschlüsselt wird

Der Wert 1 wird deshalb vom Zeitstempel des Clients abgezogen, um sicherzustellen, dass der Zeitstempel veraltet ist. Ein veralteter Zeitstempel kann nicht erneut als Clientverifikator verwendet werden.

Authentifizieren des Servers mit Secure RPC

Der Client erhält den Verifikator und authentifiziert den Server. Der Client ist darüber informiert, dass nur der Server den Verifikator gesendet haben kann, da nur der Server darüber informiert ist, welchen Zeitstempel der Client gesendet hat.

Verarbeiten von Transaktionen mit Secure RPC

Bei jeder Transaktion nach der ersten Transaktion gibt der Client die Index-ID an den Server zurück. Der Client sendet ebenfalls einen anderen verschlüsselten Zeitstempel. Der Server sendet den Zeitstempel des Clients abzüglich des Werts von 1 zurück, der durch den Dialogschlüssel verschlüsselt wird.