Jeder, der Anwendungen auf typischen Servern betreibt oder entwickelt, steht vor demselben Problem: Er schafft einen kritischen Angriffspunkt. Denn üblicherweise liegen heutzutage Authentifizierungs-Passwörter oder zumindest davon abgeleitete Informationen in einer zentralen Datenbank. Erlangt ein Angreifer auf diesem System Administratorrechte, so kann er sämtliche dort verwalteten Daten nutzen. Selbst mit starker Verschlüsselung und sicherer Hardware kann man diesem grundlegenden Problem kaum begegnen, da ein erfolgreicher Angreifer mit denselben Rechten auf die Schlüssel oder die Hardware zugreifen kann wie der Server "selbst".
Auch "äußere Schützhüllen" um die Server sind keine Garantie für die Unantastbarkeit der Daten: Egal ob Viren, Trojaner, interne Angreifer oder Hacker auf der Suche nach Software-Schwachstellen – immer wieder gelingt es, die Schutzmechanismen von Unternehmensnetzen auszuhebeln oder zu unterlaufen. Mit Zugriff auf eine Passwortdatenbank lassen sich jedoch üblicherweise "schlechte" Passwörter durch Wörterbuchangriffe oder kurze PINs durch vollständiges Ausprobieren (offline) ermitteln, selbst wenn diese Informationen nur als Hashwert oder in anderer abgeleiteter Form gespeichert sind.
Auf der anderen Seite machen die Gewohnheiten von Anwendern, die beschränkte menschliche Merkfähigkeit für komplizierte Passwörter sowie die zunehmende Zahl mobiler Geräte mit eingeschränkter Rechenleistung genau solche schwachen Passwörter mehr oder weniger erforderlich; anders ausgedrückt benötigt man in etlichen Anwendungsszenarien "kurze Geheimnisse" zur Authentifizierung, die einer Datenbank-Attacke nicht standhalten. Ein sicheres Auslagern persönlicher Zugangsdaten oder Authentifizierungszertifikate auf Smartcards oder vergleichbare Speichermedien scheitert zudem noch immer an der nicht existenten Verfügbarkeit über Systemgrenzen hinweg.
Die üblichen Protokolle zur gegenseitigen Authentifizierung erfordern jedoch für den Server genau den kritischen Klartextzugriff auf die Passwörter (oder abgeleitete Daten). Meist kommen dabei so genannte Secure-Password-Authenticated-Key-Agreement-Protokolle (SPAKA) zum Einsatz, die zwar schwache Passwörter beim Anmeldevorgang über den Kommunikationskanal schützen, aber zumeist nicht auf die Serverproblematik eingehen. Viele Kryptologen haben hierzu in den letzten Jahren geforscht (s. [3]).
Einen in gewisser Weise komplementären Ansatz haben John Brainard, Ari Juels, Burt Kaliski und Michael Szyllo, vier Krypto-Spezialisten der RSA Laboratories, im letzten Jahr vorgestellt [1]. Dabei werden Passwörter – oder andere schutzwürdige Daten – auf (mindestens) zwei Server in spezieller Weise aufgeteilt, sodass kein System alleine über dieses "Geheimnis" verfügt. Selbst wenn einer der Server einem Angriff zum Opfer fällt, erhält der Angreifer also kein unmittelbar verwertbares Wissen: Die Kenntnis einer Teilkomponente enthüllt noch nicht einmal die Hälfte der Daten, sondern offenbart keinerlei relevante Informationen (s. u.).
Derartige Aufteilungen sind in der Kryptologie als Secret Sharing bekannt und im Prinzip nichts Neues. Das Besondere an dem neuen Verfahren, das RSA mittlerweile unter dem Namen Nightingale auch als kommerzielles Krypto-Toolkit angekündigt hat (vgl. Kasten), ist jedoch, dass es einerseits nur sehr geringe Anforderungen an die Rechenleistung des Clients stellt und sich somit gut für mobile Systeme eignet. Zum anderen muss das verteilte Geheimnis bei seinem Einsatz zur Authentifizierung nicht wieder zusammengeführt werden, sodass es zu keiner Zeit im Klartext vorliegt. Und nicht zuletzt kann ein Angreifer selbst mit völliger Kontrolle über einen der beiden beteiligten Server das Protokoll nicht austricksen und dem anderen Server sein "Wissen" abluchsen.
----------Anfang Textkasten----------
Das Nightingale Software Development Kit (SDK) von RSA Security wird derzeit vollständig in Java entwickelt und sollte sich daher später ohne Schwierigkeiten in die meisten Plattformen integrieren lassen. Die zugrunde liegenden kryptografischen Protokolle und Vorgänge stehen Entwicklern dann in Form von leicht zugänglichen APIs zur Verfügung (vgl. [2]). Auf Rechnern in einem mit Nightingale geschützten Netzwerk kann jeder gängige Web-Browser für den Zugriff verwendet werden, da das System vollständig transparent arbeitet. Eine zusätzliche Software auf den Clients ist nicht erforderlich. Nightingale setzt auf dem RSA BSAFE Verschlüsselungs-Toolkit auf. Da es im Back-End des Netzwerks arbeitet, ist auch die Anbindung über gängige Standardsschnittstellen für sicheren Datenaustausch wie X.509, SAML und SASL möglich.
----------Ende Textkasten----------
Um das zu gewährleisten, bedient sich Nightingale der folgenden Grundidee: Bei der Benutzerregistrierung haben die beiden Server eine bestimmte "Stückelung" des Passworts erhalten und gespeichert. Zur Anmeldung errechnet der Client eine zufällig ausgewählte andere Zerteilung, von der jeweils ein Teil an jeden Server geht. Mithilfe der gespeicherten Werte berechnen die beiden Server jeder für sich einen Wert, der genau dann übereinstimmt, wenn der Client das korrekte Passwort benutzt hat. Nun müssen die beiden Systeme also nur noch feststellen, ob ihre beiden Berechnungen übereinstimmen, wozu – als Kern des Verfahrens – ein spezieller Gleichheitstest benutzt wird, der den Servern keine Rückschlüsse auf die Eingaben des jeweils anderen Systems ermöglicht (Details siehe Kasten Kryptographischer Ablauf).
Die Gleichheit der geteilten Werte soll also mit einem Minimum an zusätzlichen Informationen getestet werden. Verschlüsselungsexperten bezeichnen das als Problem der "Socialist Millionaires": Dieser Begriff leitet sich von der Idee ab, dass zwei Millionäre lediglich wissen möchten, ob sie finanziell gleichgestellt sind, aber dabei nicht preisgeben möchten, wie viel Geld sich auf ihren Konten befindet. Die Forschung kennt verschiedene Ansätze für dieses Problem und beschäftigt sich außerdem eindringlich damit, ein Recht auf Fairness sicherzustellen: Das heißt beide Parteien sollten entweder vollständige oder aber gar keine Kenntnis des Sachverhalts haben. Da bei Nightingale ein (möglicherweise vorteilhafter) Abbruch des Protokolls durch den jeweils anderen Server entdeckt würde, kann dieser ihn gleichermaßen "ahnden" wie den Versuch sich mit einem "geratenen" Passwort anzumelden: entweder per Fehlbedienungszähler mit anschließender Sperre oder durch zunehmende Verzögerung der Antwortzeit (engl.: throttling).
Mit dem erfolgreichen Gleichheitstest entscheiden die beiden beteiligten Server somit gemeinsam über die Richtigkeit des Kennworts, das vom Client zur Anmeldung verwendet wurde. Ist die Authentifizierung erfolgreich, können sie beliebige Funktionen auslösen, um dem Benutzer Anmeldeprivilegien einzuräumen: Jeder Server könnte beispielsweise zur mobilen Rekonstruktion eines Benutzer-Zertifikats (Certificate Roaming) einen Teil des Krypto-Schlüssels zum Dechiffrieren eines geschützt übertragenen Zertifikats schicken oder die Server können gemeinsam eine signierte Anmeldebestätigung ausstellen...
Als Voraussetzungen für ihr Verfahren nennen die RSA-Kryptologen eine serverseitig authentifizierte, geschützte Verbindung vom Client zum (Anmelde-)Server sowie eine gegenseitig authentifizierte geschützte Verbindung zwischen den beiden beteiligten Server-Systemen. Die Nightingale-Autoren beschreiben als Ablaufsystem ein Szenario, in dem der Client lediglich per SSL Kontakt zum ersten (Application-)Server aufnimmt und dabei ein Java-Applet übermittelt bekommt, das die kryptographische Zerteilung des eingegebenen Passworts vornimmt und außerdem den Anteil für den zweiten Server asymmetrisch verschlüsselt – dazu enthält das Client-Applet einen Public Key des nachgeordneten (Nightingale-)Servers (vgl. Abb.). Das Paper der Kryptologen [1] enthält etliche weitere Überlegungen zu denkbaren Schwachstellen und Gegenmaßnahmen des Systems.
![[Illustration]](04-1-021-1.jpg)
Im Nightingale-Key-Sharing werden Passwort-Informationen derart auf zwei Server verteilt, dass ein erfolgreicher Angriff auf eines der beiden Systeme keine Rückschlüsse auf die Anmeldedaten erlaubt. Im praktischen Einsatz reicht der "blaue" Server die vom Client verschlüsselten Daten für den "roten" Server an diesen weiter, sodass das Nightingale-System in einem völlig anderen und gesondert abgeschotteten Netzwerksegment stehen kann.
----------Anfang Textkasten----------
An dieser Stelle soll noch einmal ausführlich auf das Gebilde hinter dem wesentlichen kryptografischen Algorithmus des Systems eingegangen werden: auf den Gleichheitstest. Die grundlegende Idee ist, dass der Anwender sein Kennwort P registriert, indem er nach dem Zufallsprinzip generierte Teile auf beide Server verteilt. Beim Login wird jeweils eine zufällige andere Zerteilung an die Server geschickt. Beide Server prüfen dann gemeinsam anhand des nachfolgend beschriebenen Verfahrens, ob die übermittelten Teile und die ursprünglichen, registrierten Teile von demselben Kennwort stammen. Diese beiden Server sollen der Einfachheit halber als "blau" und "rot" bezeichnet werden.
Sei H eine große Gruppe (von ca. 160 Bit) und + der entsprechende Operator. Sei ƒ eine kollisionsfreie Hash-Funktion ƒ :{0, 1}* → H. Um das Kennwort bei der Registrierung teilen zu können, wählt der Anwender nach dem Zufallsprinzip ein Gruppenelement R ∈U H und wählt beziehungsweise berechnet die zwei Kennwort-Shares wie folgt:
Pblau = ƒ (P) + R Prot = R
Man beachte, dass die einzelnen Teile beider Server keine Informationen über P enthalten.
Nutzt der Anwender zur Authentifizierung das Kennwort P', wird die Teilung auf Basis eines neuen, zufällig gewählten Gruppenelements R' ∈U H ermittelt. Dabei werden die Werte P'blau = ƒ (P') + R' und P'rot = R' wiederum an die jeweiligen Server übermittelt.
Die Server kombinieren beide registrierten Werte auf einfache Weise mit den zur Authentifizierung übermittelten Daten. Server "blau" errechnet:
Qblau = Pblau - P'blau = (ƒ(P) - ƒ((P')) + (R - R')
Server "rot" berechnet ähnlich:
Qrot = Prot - P'rot = R - R'
Wenn der Benutzer das korrekte Kennwort eingegeben hat, also P = P' ist, dann gilt auch ƒ(P) = ƒ(P'). Daraus folgt Qblau = Qrot. Bei einem abweichenden Kennwort P' differieren jedoch auch die beiden Q-Werte (mit Ausnahme einer Kollision der Hash-Funktion ƒ). Um also das Benutzerkennwort für die Authentifizierung auf Korrektheit zu testen, müssen beide Server lediglich überprüfen, ob Qblau = Qrot ist, ohne dabei "eigene" Informationen preiszugeben (damit im Falle eines kompromittierten Servers dieser das Geheimnis nicht ergründen kann).
Für diesen Gleichheitstest ist eine zweite, große Gruppe G der Ordnung q notwendig, für die die Multiplikation die Gruppenoperation bezeichne. Der diskrete Logarithmus der Gruppe G sollte schwierig sein. Wir nehmen an, dass beide Server sich im Vorfeld auf diese Gruppe und einen Generator g für G geeinigt und dies verifiziert haben. Außerdem ist ein kollisionsfreies Mapping w : H → G erforderlich. Für den Gleichheitstest der Werte Qrot und Qblau führen die beiden Server einen Schlüsselaustausch ähnlich dem Diffie-Hellman-Algorithmus durch. Bei dieser Variante sind die beiden Q-Werte jedoch durch verschiedene Diffie-Hellman-Keys verdeckt ("masked").
In der folgenden Darstellung steht "|| " für die Zeichenkettenverknüpfung (Konkatenation). Die mit Fragezeichen versehenen Relationen bewirken bei Nicht-Zutreffen einen Protokoll-Abbruch.
![[Ablauf in math. Formeln]](04-1-021-2.jpg)
Dieses Protokoll kann als technisch vereinfachte Variante des PET-Protokoll [4] betrachtet werden. Allerdings wird lediglich eine Komponente des ElGamal-Chiffres verwendet, statt des im PET üblichen Komponentenpaares. Das Protokoll weist außerdem einige Ähnlichkeiten zu SPAKA-Protokollen, wie etwa dem Encrypted Key Exchange (EKE), auf.
Man beachte, dass der Client bei diesem Protokoll keine kryptographischen Berechnungen durchführen muss, sondern nur eine einzige Addition in H. Zwar führt der Client ein gewisses Maß kryptographischer Berechnungen durch, um sichere Verbindungen zu den Servern herzustellen; dies kann allerdings über RSA-Verschlüsselung mit niedrigen Exponenten (z. B. in SSL) erfolgen, die nur eine geringe Anzahl von Modulo-Multiplikationen benötigen. Hat der Client diesen Teil beigesteuert, ist er fortan nicht mehr am Authentifizierungsprozess beteiligt.
----------Ende Textkasten----------
Das beschriebene Secret Splitting beseitigt die Gefahr eines zentralen Angriffspunkts bei der zentralen Speicherung von Passwörtern oder anderen schutzbedürftigen Daten. Solange nicht beide beteiligten Systeme kompromittiert sind, bleiben die gespeicherten Geheimnisse sicher geschützt. Da man die zwei Server in verschiedenen Netzwerksegmenten und an verschiedenen Standorten aufstellen kann, ist sowohl auf logischer als auch physischer Ebene ein verbesserter Schutz möglich: Während unterschiedliche Betriebssysteme, Firewalls und andere Sicherheitssysteme die Resistenz gegen einen unberechtigen Fernzugriff erhöhen, verbessert eine räumliche Trennung auch den Schutz gegen Innentäter, die direkten Zugang zu Computersystemen haben. Zudem erhält man durch die mehreren beteiligten Systeme mit unabhängiger Protokollierung eine verbesserte Audit-Fähigkeit.
Vorrangige Einsatzgebiete könnten unter anderem im Identity Management, Outsourcing und Hosting (Aufteilung von Zugangsdaten zwischen Kunde und Auftragnehmer) sowie in allen anderen Bereichen liegen, wo keiner der Beteiligten durch die Kontrolle eines Servers gleichzeitig die alleinige Kontrolle über schutzwürdige Daten erhalten soll. Insofern verwirklicht das vorgestellte System auch eine besondere Art des Vier-Augen-Prinzips.
Norbert Olbrich ist Technical Manager (Germany, Austria, Switzerland) Strategic Accounts bei der RSA Security GmbH.
![[externer Link]](../../../../images/link.gif)
http://developer.rsasecurity.com/labs/nightingale/files/nightingale-paper.pdf http://developer.rsasecurity.com/labs/nightingale/ www.integritysciences.com/links.html
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2004#1, Seite 21
| 