Seit Menschen in aller Welt über Computer und das Internet mit Leichtigkeit kommunizieren können, leben wir angeblich alle in einem globalen Dorf. Nur – anders als in einem echten Dorf kennt nicht jeder jeden. Die Erbauer des globalen Netzwerks hatten im wesentlichen nur vertrauenswürdige Nutzer im Sinn; deshalb können Böswillige relativ einfach vertrauliche Informationen, die im Internet übertragen oder gespeichert werden, lesen und manipulieren (siehe "Piraten im Datennetz" von Paul Wallich, Spektrum der Wissenschaft, Mai 1994, Seite 64).

Bisher konzentrierte sich die öffentliche Diskussion über Computersicherheit hauptsächlich auf aktive Angreifer, die unter Ausnutzung bekannter, aber nicht behobener Schwachstellen eines Netzes Schaden – oder jedenfalls merkliche Effekte – in fremden Maschinen anrichten. Neuerdings wird jedoch der passive, unauffällige Lauschangriff immer bedeutsamer. Es liegt in der Konstruktion der Netzwerke, daß auch das unbefugte Abhören extrem einfach ist: Das Kennwort (password), mit dem sich ein auswärtiger Benutzer gegenüber einem Computer legimitiert, wird im Prinzip wie alle anderen Daten übertragen und ist deswegen abhörbar. Und der Zugriff auf fremde vertrauliche Informationen kann – für die Konkurrenzfirma, einen Kreditkartenbetrüger oder auch einen Erpresser – Gold wert sein.

Um so bemerkenswerter ist, daß die Systemverwalter des Massachusetts Institute of Technology (MIT) in Cambridge mittlerweile seit mehr als zehn Jahren erfolgreich das Datensicherheitsproblem bewältigen. Die Institution fand sich 1983 mit den Computerherstellern IBM und Digital Equipment Corporation (DEC) zu einem Projekt namens Athena zusammen mit dem Ziel, ihren Angehörigen und Studenten fortschrittlichste Computertechnik zur Verfügung zu stellen. Das mittlerweile etablierte System ist Teil des Rechnerverbundes MITnet, der den ganzen Campus überspannt (Bild 1).

Athena arbeitet nach dem Client-Server-Prinzip: Die wesentliche Rechenleistung wird von den Arbeitsplatzrechnern (workstations) der einzelnen Nutzer erbracht; nur für besondere Funktionen, insbesondere Datenspeicherung und Drucken, nehmen die Workstations gewissermaßen als Kunden (clients) spezialisierte Dienstleistungsrechner (servers) in Anspruch. (Auch die Partner einer Verbindung im Internet spielen sehr häufig die Rolle von Client und Server.)

Schon beim Entwurf des Systems war uns das Sicherheitsproblem bewußt. Wir trauten unseren Studenten ohne weiteres zu, ihre Workstations so zu programmieren, daß sie jedes über die Leitung laufende Password mitschreiben und zur weiteren Verfügung abspeichern könnten. Um dieser Gefahr zu begegnen, entwarfen wir das Verifikationssystem Kerberos, unter dem in keinem Falle lesbare Passwords übertragen werden müssen. Das ist das Herzstück der Systemsicherung. Im Gegensatz zu seinem Namensgeber, dem dreiköpfigen Hund, der nach der Vorstellung der alten Griechen den Eingang der Unterwelt bewacht, ist unserem kybernetischen Wachhund noch kein Unbefugter entwischt.


Wo ist die Grenze eines Computers?

In der Datensicherheit ist schon die Klärung der Begriffe nicht einfach, ganz zu schweigen von der praktischen Anwendung von Konzepten. Ein paar Meter Kupfer-, Koaxial- oder Glasfaserkabel verwischen bereits die Grenzen zwischen sicher und unsicher, zumindest in den Köpfen der Beteiligten. Wo fängt ein Computer an, und wo hört er auf?

Die Frage ist nicht trivial, denn seit Jahren unterscheiden die Spezialisten zwischen äußerer und innerer Sicherheit: Wie verhindert man einerseits, daß ein Unbefugter von außen (was immer das ist) in den Computer eindringt, und andererseits, daß ein Benutzer im Inneren die Belange eines anderen oder die allgemeine Sicherheit des Systems beeinträchtigt?

Es ist leicht, die äußere Begrenzung eines traditionellen Großrechners (meist mainframe genannt) zu definieren. Die zentrale Recheneinheit, der Speicher und die Laufwerke sind innen, alles andere ist außen. Ein-/Ausgabe-Einheiten wie Terminals, Magnetbandgeräte und Drucker bilden die Begrenzung, und alles, was hineinkommt, muß sie passieren. Ein Benutzer an einem Terminal muß sich mittels eines Passwords ausweisen, das im Idealfall nur ihm selbst bekannt ist und somit ausreichende Sicherheit bietet.

Wichtig ist, sich klarzumachen, daß umgekehrt das System gegenüber dem Benutzer sich nur implizit identifiziert. Dieser geht davon aus, daß er mit dem Computer verbunden ist, den er im Sinn hat. Ist das Terminal fest an eine bestimmte Maschine angeschlossen, so kann seine Erfahrung aus früheren Sitzungen diese Annahme stützen. Kommt die Verbindung über ein Modem zustande, vertraut er darauf, daß die Telephongesellschaft den Anruf zu dem Computersystem mit der gewählten Nummer durchstellt (und daß ihm vor dem ersten Kontakt mit dem System die richtige Nummer bekanntgegeben wurde).

Es entsteht also eine Art ungeschriebener, auf Vertrauen basierender Vertrag zwischen Mainframe und Benutzer. Das System nimmt an, daß alle Tastenanschläge, die es empfängt, vom befugten Benutzer selbst eingetippt oder zumindest gutgeheißen werden; umgekehrt vertraut der Benutzer darauf, daß alles, was auf dem Bildschirm erscheint, vom richtigen Computer stammt. Der Vertrag gilt, bis sich der Benutzer vom System abmeldet, und wird auch eingehalten – solange das System nicht manipuliert ist.

Diese Prinzipien versagen jedoch, sowie Workstations und Netzwerke ins Spiel kommen. An die Stelle eines leicht abgrenzbaren großen Kastens treten viele voneinander unabhängige Systeme, die durch Leitungen mit unklarer Vertrauenswürdigkeit und Zuverlässigkeit verbunden sind. Man spricht von verteilten Rechnerumgebungen (distributed computing environments).

Die meisten Netzwerke sind räumlich ausgedehnt und schwierig abzusichern. Am MIT sind die Leitungen über das gesamte Hochschulgelände bis in die Studentenwohnheime verlegt; es wäre einfach zu teuer, sie alle in Panzerschränke und alarmgesicherte Rohre zu legen.

Zudem arbeiten die meisten Netze nach dem Rundfunkprinzip (broadcast): Jeder beteiligte Computer kann auf alle Daten zugreifen, die durch die Leitung fließen, ist jedoch so programmiert, daß er nur das liest, was an ihn adressiert ist. Wer jedoch die Kontrolle über einen der Computer hat, kann ihn leicht dazu bringen, daß er alle im Netz zirkulierenden Daten empfängt oder selektiv diejenigen, die an einen bestimmten anderen Computer adressiert sind. Außerdem kann er Daten mit falscher Absenderangabe versenden.

Aus diesem Grunde wäre es widersinnig, in Übertragung der Mainframe-Sicherheitsphilosophie das gesamte Netz als innerhalb der Systemgrenzen zu definieren. Vielmehr ist jedes Datenpaket, das zwischen Workstation und Server transportiert wird, als grenzüberschreitend anzusehen: Es muß für den Weg gegen Eingriffe geschützt werden und vor dem Eintritt in die Zielmaschine eine Art Ausweiskontrolle bestehen.


Kerberos: die Paßbehörde

Im System Athena ist beides – Ausstellung und Überprüfung dieser Ausweise sowie Verschlüsseln zum Schutz der Daten – die Sache des Programmsystems Kerberos, das auf jedem der beteiligten Rechner installiert ist. Während die Ausgabe von Ausweisen einem speziell dafür vorgesehenen Rechner vorbehalten ist, betreiben die auf verschiedenen Computern des Netzes ansässigen Exemplare des Programms die übrigen Funktionen: Sie tauschen eine Reihe von verschlüsselten Informationen aus, bevor sie einem Benutzer den Zugriff zu einem Server gewähren, und überprüfen eingehende verschlüsselte Daten darauf, ob sie verfälscht wurden – durch Defekte, fahrlässig oder gar vorsätzlich.

Die aktuelle Version von Kerberos verwendet zum Verschlüsseln den DES (data encryption standard; vergleiche Spektrum der Wissenschaft, Januar 1989, Seite 6, und Mai 1993, Seite 19). Dieses Verfahren zerlegt eine Nachricht in kleine (64 Bit oder 8 Zeichen lange) Blöcke und wandelt jeden mit Hilfe einer 56 Bit langen, geheimzuhaltenden Zeichenkette, des Schlüssels, in einen Chiffretext um. Derselbe Schlüssel dient auch zur Rückverwandlung in Klartext. Bevor eine Workstation also ein Paket sendet, kann sie dieses mit Hilfe eines Schlüssels codieren, der nur ihr und dem legitimen Empfänger bekannt ist. Das Abhören des Netzverkehrs wird somit nutzlos, denn ohne Schlüssel kann man jedem Paket nur digitales Kauderwelsch entnehmen.

Außerdem ist jede Verfälschung derart verschlüsselter Information leicht zu erkennen. Praktisch jeder, auch der kleinste Eingriff hat zur Folge, daß das Dekodieren eines Pakets nur noch Datensalat ergibt – irgendwelche zufälligen Zeichen, die in keinerlei Bezug zum Original stehen. In diesem Falle kann die Empfängermaschine das Datenpaket verwerfen und beim Absender die Botschaft nochmals anfordern.

Die Verschlüsselung zum Zweck der sicheren Übertragung ist jedoch nur die Grundlage von Kerberos. Darauf aufbauend haben wir ein System von Protokollen installiert, durch die das System identifizieren kann, wer jeweils eine Dienstleistung anfordert. Über diese Protokolle können sich auch je ein Server und eine Workstation die Voraussetzung für die sichere Datenübertragung verschaffen: einen geheimen Schlüssel, der nur den beiden beteiligten Rechnern bekannt ist.

Jeder neue Benutzer erhält zunächst einen geheimen 56-Bit-Schlüssel. Da sich kaum jemand eine zufällige Bitfolge von 56 Zeichen (entsprechend einer 20stelligen Zahl) merken kann, darf sich der Benutzer ein Password von sechs bis 128 Zeichen Länge aussuchen. Ein zusätzlicher Codierschritt wandelt dieses in einen DES-Schlüssel um. Jedem Server im Netz ist ebenfalls ein solcher Schlüssel zugeordnet.

Alle Schlüssel – sowohl für die Benutzer als auch für die Server – sind nur einem speziellen Rechner bekannt, der als Ausweis-Ausgabestelle (key-distribution center, KDC) fungiert. Entgegen seinem Namen gibt er niemals einen Schlüssel selbst heraus, sondern immer nur das digitale Äquivalent eines Berechtigungsscheins zur Nutzung von Serverdiensten, ein sogenanntes Ticket.

Die Interaktion beginnt damit, daß ein Benutzer sich an eine Workstation setzt und sich beim System anmeldet, indem er seinen Login-Namen eingibt; das ist der Name, unter dem er dem System bekannt ist. In der Urform von Kerberos löst das eine Kette von Kommunikationen zwischen Workstation und KDC aus, an deren Ende dieses ein Ticket zur Nutzung eines bestimmten Dienstes ausgibt.

Mit Ausnahme des KDC kennt jeder Beteiligte an diesem Prozeß – Benutzer/Workstation und Server – nur seinen eigenen Geheimschlüssel. Trotzdem weist er sich gegenüber seinem Partner dadurch aus, daß er ihm dessen Geheimschlüssel vorzeigt – in einer Form, mit der weder der Vorzeigende noch ein unbefugter Lauscher etwas anfangen kann. Damit das funktioniert, muß das KDC beispielsweise dem Benutzer das Ticket für den Server gleichsam im versiegelten Umschlag aushändigen, so daß nur der Server das Siegel öffnen kann. Ein Ticket, das mehrere Stationen durchläuft, muß entsprechend oft versiegelt werden. Ein versiegelter Umschlag kann auch einen Schlüssel zur späteren Benutzung enthalten.

Im ersten Schritt teilt die Workstation dem KDC mit, daß der Benutzer eine Leistung anfordert - beispielsweise eine Datei von einem Server kopieren möchte. Daraufhin erzeugt das KDC ein Datenpaket, das Ticket, in der Rohform; es enthält den Namen des Benutzers, Datum und Uhrzeit der Ausstellung, eine Gültigkeitsdauer, den Namen der Workstation sowie eine geheime, nach dem Zufallsprinzip erzeugte Bit-Kette, den sogenannten Sitzungsschlüssel (session key). Das KDC verschlüsselt dann das so zusammengestellte Ticket mit dem geheimen Schlüssel des Servers, dessen Dienste angefordert wurden. Also kann nur dieser Server es lesen.

In einem dritten Schritt fügt das KDC dem bereits verschlüsselten Ticket ein weiteres Exemplar des Sitzungsschlüssels hinzu, chiffriert das Ganze mit dem geheimen Schlüssel des Benutzers und sendet das Ergebnis an dessen Workstation. Diese fordert daraufhin den Benutzer zur Eingabe seines Passwords auf, wandelt die eingegebenen Zeichen in einen DES-Schlüssel um und dechiffriert damit die vom KDC eingegangene Nachricht. Nur wenn der Benutzer an der Workstation tatsächlich das korrekte Password eingegeben hat, entsteht in der Workstation wieder das – jetzt nur noch einfach verschlüsselte – Ticket.

Dieses reicht die Workstation nunmehr an den Server weiter, dessen Dienste angefordert wurden, zusammen mit einem weiteren Datenpaket, dem sogenannten Echtheitsnachweis (authenticator). Dieser besteht aus der Uhrzeit, dem Namen des Benutzers und dem der Workstation. Das sind alles bekannte und deshalb leicht nachzumachende Daten; aber als Nachweis der Echtheit taugen sie, weil sie mit dem Sitzungsschlüssel chiffriert sind. Diesen kann aber nach Konstruktion des Verfahrens nur der Inhaber des Benutzer-Geheimschlüssels kennen – abgesehen vom KDC selbst.

Der Server seinerseits entschlüsselt mit seinem eigenen Geheimschlüssel das Ticket und gewinnt daraus den Sitzungsschlüssel, mit dessen Hilfe er dann den Echtheitsnachweis dekodiert. Wenn alles richtig funktioniert hat, liegen dem Server jetzt sowohl das Ticket als auch der Echtheitsnachweis im Klartext vor. Er überprüft nun, ob die Namen von Benutzer und Workstation in beiden Dateien übereinstimmen und ob die Zeitangabe im Echtheitsnachweis innerhalb der Gültigkeitsgrenzen des Tickets liegt. Wenn ja, akzeptiert er das Ticket und erfüllt die Anforderung des Benutzers.

Durch dieses Verfahren hat sich der Server gleichsam die Gewißheit verschafft, daß der Benutzer beim KDC akkreditiert ist, und das, obgleich er alle Informationen aus den – zunächst nicht vertrauenswürdigen – Händen des Benutzers empfängt, keine unabhängigen Kenntnisse über den Benutzer hat und keine Bestätigung beim KDC einholt. (Eine solche Rückfrage könnte ja abgefangen und die zugehörige Antwort gefälscht werden.)

Abgesehen vom Namen des Benutzers sind alle Daten, die während dieser Transaktionen das Netz durchlaufen, verschlüsselt und somit vor Neugierigen geschützt. Über seine Ausweisfunktion hinaus kann der Sitzungsschlüssel dem Benutzer auch dazu dienen, die Daten, die zwischen seiner Workstation und dem Server hin und her fließen, zu verschlüsseln.

Wenn Daten nicht vertraulich sind, man aber sichergehen möchte, daß sie nicht verfälscht werden, ist die Totalverschlüsselung möglicherweise übermäßig aufwendig. Für solche Fälle ist in Kerberos ein weniger belastender Echtheitstest vorgesehen: Aus den Klartext-Daten und einem Schlüssel, der nur den an der Kommunikation beteiligten Maschinen bekannt ist, errechnet der Absender eine Bit-Kette und hängt sie an die übermittelten Daten an. Dieser sogenannte message authenticity check (MAC) ist üblicherweise 128 Bits lang. Der Empfänger berechnet aus den erhaltenen Daten ebenfalls einen MAC; wenn beide Ergebnisse übereinstimmen, kann man sicher sein, daß die Daten unterwegs nicht verändert worden sind.


Ein Berechtigungsschein zum Empfang eines Berechtigungsscheins

In dieser elementaren Form ist das Kerberos-Protokoll zwar sicher, aber für den durchschnittlichen Benutzer wenig geeignet. Jede weitere Anforderung eines Dienstes erfordert ein neues Ticket, so daß der Benutzer während einer Sitzung immer wieder zur Eingabe seines Passwords aufgefordert wird. Das könnte man zwar automatisieren, indem man das Password für die Dauer der Sitzung in der Workstation speichert und auf Anforderung herausgibt. Nur gibt es zahlreiche Anlässe, die Workstation für einen Moment zu verlassen, ohne sich abzumelden (und damit das Password zu löschen). Ein Eindringling könnte sich einfach an die Workstation setzen und das Password stehlen.

Also müßte man darauf bestehen, daß der Benutzer wirklich jedesmal das Password eintippt. Das würde den obigen Einwand erledigen, wäre aber wegen der üblichen menschlichen Nachlässigkeit ebenfalls riskant. So benötigt man für den Zugang zum Server für die elektronische Post (e-mail) ein besonderes Ticket, und zwar jedesmal, wenn man eine neu eingetroffene Nachricht empfangen möchte. Es ist, als müßte man, bevor man den Telephonhörer abheben darf, stets seinen Personalausweis vorzeigen.

Das würden die Benutzer von Athena kaum gutwillig mitmachen. Aber selbst dann würden sie sich angewöhnen, auf jede Anforderung gedankenlos ihr Password einzugeben. Dadurch fiele der eine oder andere leicht auf ein betrügerisches Programm (etwa ein Computerspiel) herein, das nach dem Password fragt und es für späteren Mißbrauch abspeichert.

Die Lösung des Problems ist der Ticket-Ausgabeschalter (ticket-granting service, TGS). Dieses Programm läuft auf demselben System wie das KDC und hat Zugriff auf dessen Benutzer-, Maschinen- und Schlüsselliste. Vom Benutzer aus gesehen ist es jedoch ein weiterer, vom KDC getrennter Server, dessen Dienste eben darin bestehen, Tickets auszugeben. Also braucht man auch für den TGS ein Ticket. Das bekommt der Benutzer zu Beginn der Sitzung vom KDC in der oben beschriebenen Weise, indem er sich mit dem Password legitimiert. Nachfolgende Anforderungen für Tickets zu anderen Servern gehen an den TGS. Dieser verschlüsselt seine Tickets jedoch nicht mit dem Benutzer-Password, sondern mit dem Sitzungsschlüssel, der dem ursprünglichen Ticket für den TGS beigegeben war (Bild 2).

Deshalb muß das Password des Benutzers nicht in der Workstation gespeichert werden. Sie benötigt es nur, um das erste Ticket zu dechiffrieren, und löscht es dann. Verläßt ein Benutzer vorübergehend seine Workstation, kann ein Eindringling zwar auf das Ticket und den Sitzungsschlüssel zugreifen und damit auch Dienste anderer Server in Anspruch nehmen; der Schaden hält sich jedoch in Grenzen, denn die Tickets sind nur von dieser Workstation aus verwendbar, weil sie deren Namen enthalten, und nur beschränkte Zeit gültig (höchstens zehn Stunden in der Version des MIT).


Die Paßbehörde in den Panzerschrank

Die beschriebenen Maßnahmen allein garantieren noch keine absolute Sicherheit. Kerberos bietet zwar den Computern einer verteilten Rechnerumgebung die Möglichkeit, ihre Benutzer zuverlässig zu identifizieren. Aber ein Server ist auch nur ein Computer und kann deshalb im Prinzip dazu umprogrammiert werden, seine Daten auch ohne Vorlage eines gültigen Tickets herauszugeben; es lassen sich jedoch viele Server so konfigurieren, daß nur der System-Administrator – genauer: derjenige, der dessen Password kennt – direkten (ticket-freien) Zugang zu ihm hat.

Von entscheidender Bedeutung aber ist, daß das KDC selbst physikalisch gesichert ist. Schließlich sind darin die Schlüssel aller Benutzer und Maschinen gespeichert. Wer auf das KDC zugreifen kann, hat das ganze Netz in seiner Hand. Er muß nicht einmal die Daten im KDC ändern; es genügt, sie (oder die Magnetbänder mit den Sicherungskopien) zu lesen. Wir haben mit Software-Mitteln ein direktes Lesen der DES-Schlüssel sehr erschwert. Gleichwohl müssen sowohl das KDC als auch Bänder mit den Sicherungskopien sorgfältig eingesperrt werden (Bild 3).

Des weiteren muß das KDC ununterbrochen in Betrieb sein, weil zu jeder Zeit eine Benutzeranforderung eintreffen kann. Für kritische Funktionen dieser Art stellt man üblicherweise mehrere Maschinen bereit, die füreinander einspringen können – zweckmäßig an verschiedenen Orten, damit zum Beispiel ein lokaler Stromausfall nicht alle trifft. Doch jedes zusätzliche KDC muß ebenso gut gesichert werden wie das erste; man erhöht also die Verfügbarkeit auf Kosten der Sicherheit.

Theoretisch scheint Kerberos ein unfehlbar scharfer Wachhund zu sein, aber wie bewährt sich dieses Programmsystem in der Praxis? Wir benutzen es am MIT seit 1986; die gegenwärtige Version 4 läuft seit 1987 auf vielen Rechnern des Hochschulgeländes. Wir wissen von keinem Zwischenfall, in dem die Sicherheitsmechanismen wegen eines Systemfehlers unterwandert worden wären.

Dennoch bleiben einige altbekannte Probleme bestehen: Benutzer verwenden leicht zu erratende Passwords, ein listiger Eindringling könnte einen System-Verwalter täuschen oder dieser selbst seine exklusiven Zugangsrechte mißbrauchen. Die beiden letzteren auszumerzen ist fast unmöglich. Immerhin haben wir 1991 ein Programm installiert, das schlecht gewählte Passwords wie etwa den eigenen Namen des Benutzers oder ein gebräuchliches Wort ablehnt.

Viele andere Einrichtungen haben Kerberos übernommen. Bemerkenswerterweise hat die Open Software Foundation (eine Organisation, die sich für standardisierte Betriebssysteme einsetzt) die neue, jetzt in der Testphase befindliche Version 5 zu einem Kernstück ihres Standards für eine verteilte Rechnerumgebung gemacht. Diese Version ist unter anderem weniger abhängig von speziellen Eigenschaften des Betriebssystems Unix und damit leichter an andere Rechnernetze anpaßbar.

Innerhalb des Internet diskutiert man ebenfalls über eine Version von Kerberos zur Sicherung der weltweiten Datenübertragung. Wir arbeiten an neuen Protokollen, mit denen verteilte Systeme wie Athena Hunderttausende von Benutzern anstelle der zur Zeit etwa 25000 bedienen können. Wahrscheinlich werden Chiffriersysteme mit veröffentlichtem Schlüssel (public-key cryptosystems) dabei eine Hauptrolle spielen; diese Systeme benötigen zwei Schlüssel, von denen aber nur einer geheimgehalten werden muß (Spektrum der Wissenschaft, Oktober 1979, Seite 92). Mit ihnen würde möglicherweise auch die Notwendigkeit entfallen, das KDC physisch zu sichern.

Der gegenwärtige Erfolg von Kerberos hat verschiedene Ursachen. Eine ist offensichtlich Erfahrung, denn Athena war das erste vielgenutzte verteilte Computersystem, in dem die Probleme Sicherheit und Benutzerüberprüfung ernsthaft angegangen wurden.

Eine weitere ist Einfachheit: Ein Benutzer, der sich bei Athena anmeldet, sieht dieselben Mitteilungen wie in jedem anderen Mehrbenutzersystem; viele merken überhaupt nicht, daß Kerberos arbeitet.

Und schließlich ist Kerberos offen für alle. Das MIT verbreitet seine Software grundsätzlich kostenlos (wie auch schon das fenster-orientierte Betriebssystem X-Windows für Workstations), so daß der Quellcode von Kerberos für Computerwissenschaftler und potentielle Benutzer verfügbar ist. Viele haben ihre Fachkenntnisse und ihr Geschick angeboten, um das Konzept weiter zu verbessern oder Fehler und mögliche Schwächen auszumerzen; wir hoffen, daß sie dies auch in Zukunft tun werden.

Literaturhinweise

- Using Encryption for Authentication in Large Networks of Computers. Von R. M. Needham und M. D. Schroeder in: Communications of the ACM, Band 21, Heft 12, Seiten 993 bis 999, 1978.

– Kerberos: An Authentication Service for Open Network Systems. Von J. G. Steiner, B. C. Neuman und J. I. Schiller in: Usenix Conference Proceedings, Dallas (Texas), Februar 1988, Seiten 191 bis 202.

– Distributed Computing, Implementation and Management Strategies. Herausgegeben von Raman Khanna. Prentice Hall, 1993.


Aus: Spektrum der Wissenschaft 1 / 1995, Seite 50
© Spektrum der Wissenschaft Verlagsgesellschaft mbH