Distributed Central Directory (and List) Service

Es hört sich etwas widersprüchlich an: Ein "Zentraler Directory Service" der verteilt arbeitet. Mir ist gerade die Idee gekommen, dass man so etwas braucht.

Was ist der DiCeDiSe?

Er ist eine Mischung aus Mailboxsystem, auszugsweise gespeichertem ewigem Logfile und PKI basiertem Synchronisations-Library

• Er besteht aus 3 Komponenten:
  
  • Clients, die Anfragen stellen oder Informationen updaten.
  • Servern, die die Anfragen annehmen und die Antworten geben.
  • Einem Datenbankservice der auf Kademlia basiert.
    
• Dazu sind folgende Software-Stacks notwendig:
  
  • PKI, ein Wrapper um die OpenSSL-Funktionen. Kann auf Clients oder Servern verwendet werden.
  • Das Server-Library für die Formulierung von Anfragen und Antworten. Diese können auch auf der Client-Seite verwendet werden.
  • Einer Kademlia-Implementierung die das Backend bildet. Diese kommt auf der Server-Seite zum Einsatz wenn es notwendig ist.
  • Einer Referenzimplementierung einer Synchronisation, eine per direkter Datenkommunikation und eine per indirekter Datenkommunikation
• Als Kommunikationsprotokoll wird sinnvollerweise HTTP verwendet
• Die Information wird LRU-mäßig gespeichert, d. h. alte Information kann veralten oder verloren gehen
• Folgende Referenzimplementierungen wären sinnvoll:
  • Ein Voll-Client der sich über das Protokoll direkt synchronisiert. Er enthält PKI und Server, kann also Online wie Offline arbeiten.
  • Ein Rumpf-Client der sich über das Protokoll indirekt synchronisiert.
  • Ein Proxy-Server der den Rumpf-Client bedient, das PKI bereitstellt aber keinen Datenbankservice bereitstellt sondern diesen über das Netz holt. Er stellt auch eine Offline-Sync-Komponente zur Verfügung.
  • Ein Web-Server als Frontend für das Backend.
    
  • Das Backend (im wesentlichen Kademlia) das unabhängig vom Web-Server läuft.
  • Ein DNS-Gateway, das die Informationen per DNS-Requests zur Verfügung stellt.

Welche Infrastruktur bietet DiCeDiSe?

Die zentrale Idee hinter diesem Verzeichnis ist, dass man verteilt, also überall verfügbar, Statusinformationen speichern und alte Referenzen auf Stati veralten kann. Das System stellt folgende Informationen zur Verfügung:

• Client-Groups: (Dies ist ein Directory) Die Clients können sich per PKI einer Gruppe zuordnen. Dadurch können sich Clients gegenseitig finden und autorisieren, ohne dass sie sich gegenseitig bekanntmachen müssen. Die Schlüssel werden daran erkannt dass sie von einem gemeinsamen Schlüssel (z. B. CA) zertifiziert sind. Außerdem werden die Schlüssel noch gegenseitig (in der Art eines Web of Trust) zertifiziert um Gültigkeit zu erlangen (nachdem sie hinzugefügt wurden). Die Kommunikation innerhalb einer Gruppe ist wiederum mit einem Gruppenschlüssel verschlüsselt, auf den man nach der Gültigkeitserteilung Zugriff bekommt. Selbst wenn dieser Gruppenschlüssel kompromitiert wird erhält man keinen Zugriff auf wichtig Informationen, sondern nur die Statusmitteilungen in der Gruppe, die wiederum ja keine Informationen enthalten, sondern nur den Hinweis dass etwas zu synchronisieren wäre.
• Status-Hash: Dies sind individuelle Informationen, die wie ein ewiges Logfile das ab einem bestimten älteren Datum abgeschnitten wurde gespeichert sind. Neue Information wird am Kopf angehängt, so dass man ältere Informationen als älter erkennen kann. Dies oder die alten Informationen sind nicht da. Bei einem Sync marschiert man dann "auf dem ewigen Logfile" von dem bisher bekannten Status-Hash zur neuesten Information. Ein Status-Hash enthält eine Sequenznummer, ein Timestamp und ein Freiformat-Textfeld in das beliebige Informationen eingetragen werden können. Die Gesamtinformation übersteigt aber 512 Byte niemals. Der Status-Hash gehört zu einem Client und ist von einem bestimmten Typ. Dieser Header ist ebenfalls nicht größer als 512 Byte.
• Client-Notify: Dies ist ein Online-Service der über Änderungen in den Status-Hashes oder Clients-Groups berichtet.
• Online-Sync: Es wird das Aufbauen eines verschlüsselten Kommunikationskanals über das Internet unterstützt. Das bedeutet, zwei Clients bauen eine Verbindung zu ihren (nicht notwendigerweise denselben) Servern auf und übertragen die Informationen zwischeneinander, indem die Server gegenseitig Kontakt aufnehmen (ggf. über weitere Server).
• Offline-Sync: (Genaugenommen geschieht dies bei Abwesenheit der Infrastruktur) Dabei wird auf einem Offline-Medium (USB-Stick) die Sync-Information vorgehalten die man dann bei Bedarf in andere Clients einspielen kann. Dies können Clients sein die gar nichts mit dem eigentlichen Client zu tun haben oder ganz andere Daten vorhalten. Diese anderen Clients übertragen dann die Statusinformationen an DiCeDiSe und erlauben auch einen Sync mit diesen Informationen.

Wie man sieht hält das Verzeichnis selber gar keine Informationen (Dateien) bereit, sondern nur Informationen, wo etwas zu finden ist. Eben wie ein Verzeichnis. Dazu kommt noch ein Inter-Server-Protokoll über das man Verbindungen schalten kann, was bei allgemein öffentlichen Servern aber auch abgeschaltet werden kann um den Traffic zu minimieren.

Wer sich fragt, wo die Buddy-Liste ist (Online-Status abfragen): Es ist ein Status-Hash. Genauso sind auch die Log-Informationen beschaffen, diese transportieren in ihrem Datenfeld allerdings die Logging-Informationen.

Generell (und das ist wichtig) gibt es nur die Funktion des Hinzufügens von Information. Gelöscht wird lokal durch veralten, wobei die Regel sehr einfach ist:

• Status-Hashes: Bei diesen wird die Information immer von hinten nach vorne gelöscht.
• Client-Groups: Bei diesen wird der älteste Eintrag verworfen.

Vielleicht sollte Status-Hashes "Lists" nenen und Client-Groups "Directory".

Zusätzliche Notizen

• Das Verfahren arbeitet auch vollständig offline. Der Datentransport geschieht dann über Offline-Medien (USB-Stick oder auch CD-R). Der Nachteil ist, dass sich Clients dann ohne Benutzereingriff nicht automatisch finden, bzw. Updates anderer Clients erst sehen können, wenn der manuelle offline-Sync stattgefunden hat. Für diese Art des Syncs sind entweder lokale Services oder ein aufwendiger Full-Client notwendig.

Zugrundeliegende Idee

Ich bin ein Schlamper.

Ich bin mal hier, mal dort. Ich tue mal dies, mal das. Und immer fallen Statusinformationen an:

• Das sind Updates die ich mache und ich mir notieren muss, wie z. B. Passworte, die ich danach 4 Jahre lang nimmer brauche, aber dann fehlen sie mir und machen ärger.
• Das sind kurze Snippets was zu tun ist, also Dinge, die ich nicht vergessen will aber nach 2 Jahren vergessen habe, wodurch mir wieder irrsinnig Aufwand entsteht es nochmals nachzuvollziehen.
• Das sind Einstellungen, die ich nur temporär vornehme, die aber wieder zurückfallen sollen, aber eben nur dann, wenn ich es will, aber die verloren gehen wenn die Kiste (was alle 2-3 Jahre mal so der Fall ist) rebootet, und dann ist guter Rat teuer wie diese Einstellung nun wieder aussah.

Also lauter kleiner täglicher (stündlicher, minütlicher) Mist, der irgendwie notiert gehört, aber eben nicht notiert wird. Und wenn er notiert wird, vergisst man ihn sofort. Natürlich vergisst man auch, wo man es sich notiert hat. Und man hat auch niemals die Zeit, diese Notizen zu sichten, da sich diese eben nicht magisch an einem zentralen Ort zusammenfassen.

Und genau diese Magie soll DiCeDiSe leisten.

Und wer sich fragt: Wenn ich unterwegs bin habe ich zwar eigentlich immer meine Geldbörse dabei, aber keinen Stift zur Hand. Und selbst wenn, dann verschwinden diese kleinen Merkzettel flugs in irgendwelchen Dimensionsfalten des Universums (hat es jedenfalls den Anschein). Wenn sie dann doch irgendwo materialisieren, dann werfe ich sie oft achtlos weg, da diese Informationen nicht indiziert sind und so in keinem semantischen Web mehr stehen.

Ja, ich habe meistens ein Handy dabei. Mit "ein" meine ich eigentlich "irgendein". Denn ich habe derzeit 3 Handys (es waren auch schonmal 5), und alle haben mehr oder minder irgendwelche Daten in sich die ich mir mal notiert habe. Syncen der Teile ist nicht - der Teil, in denen man Infos gesichert speichern kann synct nicht! Welches Handy das ist ist auch unklar, da ich mein Haupthandy nicht selten vergesse und dann halt so lange das aus dem Auto verwende (meine Handys leiten alle aufeinander um, so reicht es, mit dem falschen Handy das Haupthandy anzurufen und denjenigen, der drangeht, zu bitten, das Teil auszuschalten. Aber auch das werde ich demnächst über eine Asterisk verautomatisieren sobald ich mal Zeit dazu habe).

Was haben wir also:

Man hat zillionen kleiner Devices die alle zillionen möglicher Speichermöglichkeiten bieten so dass man zillionen von Informatioen erfassen kann die danach aber total desorganisiert ist. DiCeDiSe sollen diese dezentral gespeicherte Informationsflut sichten, ordnen und zentral verfügbar machen.

Beispiel: Passwortmanager

Man hat 2 Laptops und an verschiedenen Orten 3 Arbeitsplatzrechner. Alles für eine Person. Ist bei mir normal, ich bin Externer und habe so folgende Infrastruktur:

• Derzeit sogar 3 Laptops, wobei einer aktuell ist (gestern gekauft) und einer uralt (über den tippe ich gerade).
• Ein Wohnsitz mit gesichertem Intranet (also ohne VPN-Zugriff von außen)
• Eine Arbeitswohnung (z. B. Border-House) in der ein PC steht, nur ist der aus wenn ich nicht da bin (momentan bin ich dort, allerdings ziehe ich aus, also nur der Laptop)
• Und ein oder mehrere Arbeitsplatzrechner (momentan bin ich allerdings zwischen Projekten)

Allen gemeinsam ist, dass diese Kisten mehr oder minder oft am Internet hängen, aber eben leider nicht gleichzeitig. Außerdem verbieten die Firewalls eine direkte Kommunikation, man kann also nicht direkt zwischen den Kisten kommunizieren auch wenn sie gleichzeitig online sind. Eine direkte offene Kommunikation ist sowieso wegen prinzipieller Überlegungen unerwünscht, d. h. es soll niemals irgendwo irgendeine Information zwischengespeichert werden, so dass diese irgendwo anders landen kann. Einzig der Aufbau eines indirekten verschlüsselten Datenkanals über einen Vermittler ohne MITM-Fähigkeit ist das allerschlimmste das solch eine Infrastruktur erlauben soll.

Während ich arbeite fallen immer mal wieder Passwortinformationen an. Die Passwörter sind bei mir in einem verschlüsselten Passwort-Manager auf einem Master-USB-Stick gespeichert. Von dem ziehe ich mir bei Bedarf aber kopien, da ich den Master-Stick meistens nicht dabei habe.

Das Problem: Arbeite ich mit einer Kopie, so ist diese Read-Only. Und wenn nicht dann entsteht Chaos, da man mehrere Passwortmanager nicht syncen kann. Also gilt immer nur der Master, die Kopien werden niemals "zurücksynchronisiert" in den Master.

Hier wäre wünschenswert, wenn man die Kopien zurücksichern kann. Aber das ist mühsam. Welche Kopie wurde aktuallisiert? Welche Version von zwei Kopien die dieselben Informationen mit verschiedenen Ständen enthalten sind richtig? Habe ich alles synchonisiert oder was vergessen?

Wenn ich arbeite bin ich aber eigentlich immer Online. Was also fehlt ist ein Directory, das die Änderungen der Informationen aufnimmt und mitprotokolliert, so dass ich im Master in dieses Directory gehen kann und dieser mir mitteilt, woher ich noch was syncen muss.

Wer die Problematik nicht versteht und meint, das kann man auch so erledigen, der hat die Idee offensichtlich falsch verstanden. Natürlich kann man alles mit "Hirn" erledigen. Aber es gibt Prozesse, die ähnlich ablaufen, aber vollautomatisch! Da ist also kein Mensch involviert, oder nur stark am Rande. Da müssen ähnliche Sync-Prozesse wie in einem Passwortmanager ablaufen, nur eben ohne direkten Benutzereingriff. Irgendwo aber sitzt ein Mensch (z. B. eine Sekretärin) die die Informationen dann sichten und verarbeiten muss. Die Informationen selber aber fallen von verschiedenen Chefs an die sich eben nicht untereinander absprechen, sondern die Koordination diesem Menschen überlassen.

Die Informationen sind oft nicht unbedingt instant überall notwendig, es kann mehrere Minuten bis Stunden dauern bis diese zentral erfasst sind. Wichtig ist nur, dass sie zentral erfasst werden´können, und dass man sicher sein kann, einen bestimmten Stand zu reproduzieren.

Dazu muss der Inforamtionsmanger auf die Status-Informationen aller Clienten zugreifen können, also sehen können, wie der letzte berichtete Status ist. Und wenn ein Status fehlt kann man den dann gezielt holen und dann ist man sicher, alle relevanten Informationen zu haben.

DiCeDiSe ist in diesem Fall das Tool, mit dem man die Informationen prüfen kann. Das Protokoll ist so beschaffen, dass man sieht, ob man die letzte gültige Information hat oder ob noch etwas fehlt. Die Information selber wird dabei nicht übertragen, es geht nur um den Status der Information!

Und daraus entsteht ein rundum-sorglos-Passwortmanager. Man fummelt hier, man fummelt da, und der Master sieht alle Stati und klopft einem so lange auf die Griffel, bis man alle Infos auch endlich zusammengetragen hat.

Beispiel: ToDo-Liste

Man kauft ein neues Handy. Vorsorglich installiert man sein Java-Programm mit der ToDo-Liste auf dem Handy. Aber man synchronisiert es noch nicht, weil man momentan keine Zeit oder Lust dazu hat. Danach vergisst man das ganze.

Bei der Installation hat das Java-Programm aber vom PKI einen Schlüssel ausgeteilt bekommen. Da das PKI nicht weiß, wofür dieser Schlüssel Verwendung finden soll, ist das Handy jetzt noch in keiner Client-Group, also auch nicht sichtbar für andere Clients.

Ein paar Monat später hat man nur das Handy dabei und notiert sich etwas in der ToDo-Liste. Da die Information nicht besonders wichtig ist löst man keine Internetverbindung aus um die Informationen an DiCeDiSe zu übertragen. Also bleibt die Information im Handy liegen und man vergisst sie wieder.

Wieder ein paar Monate später steckt man die Speicherkarte vom Handy in den Laptop, da man ein mit der Kamera aufgenommenes Bild übertragen will. Dabei stolpert man über die Offline-Sync-Datei die die ToDo-Liste vom Handy dort gespeichert hat.

Man doppelklickt die Datei und die DiCeDiSe-Infrastruktur auf dem Laptop nimmt die Information auf. Zuerst ist diese Information wertlos, da die Infrastruktur nichts mit den Clients zu tun hat.

Beim nächsten Sync-Vorgang, also wenn die DiCeDiSe-Infrastruktur vom Laptop Zugang zum Internet hat, wird auch der Status der vom Handy aufgenommene Information an das Directory übermittelt.

Zuhause auf dem Arbeitsrechner (der nicht der Laptop ist aber über das Intranet permanent online) wird das Handy automatisch als neuer Client in der Client-Group erkannt (da er Informationen ins Verzeichnis eingetragen hat und zur PKI-Gruppe gehört) und der Client erkennt, dass im Handy Informationen sind, die noch nicht gesynct sind. Auch kann der Client berichten, dass die Information inzwischen auf dem Laptop rumliegt.

Man schaltet also den Laptop ein, dieser bucht sich ins häusliche wLAN ein. Da das wLAN aber in der DMZ liegt kann er keine Verbindung zum Arbeitsrechner im Intranet aufbauen, da die Intranet-Firewall das blockt. Da der Laptop aber über die Windows-Firewall geschützt ist kann vom Arbeitsrechner auch keine Verbindnung zum Laptop aufgebaut werden.

Auf dem Arbeitsrechner klickt man nun auf Sync von der fehlenden Information. Auf dem Laptop erscheint von der DiCeDiSe-Infrastruktur der Hinweis, dass der Arbeitsrechner eine Sync-Verbindung wünscht. Nachdem man das bestätigt hat, wird über den DiCeDiSe-Server automatisch eine verschlüsselte Verbindung zwischen Arbeitsrechner und Laptop aufgebaut, so dass die fehlende Information ausgetauscht werden kann.

Der DiCeDiSe-Server steht sinnvollerweise in der DMZ und nicht im Internet. Da das System dezentralisiert arbeiten kann ist es ja egal welchen DiCeDiSe-Server man anspricht.

Wer dieses Beispiel wieder nicht versteht hier die Hinweise:

• Die Information ist vollkommen unwichtig, z. B. eine Telefonnummer von jemanden, den man kennengelernt hat, aber vielleicht nie wieder sieht.
• Die Information wandert aber fast vollautomatisch dort hin, wo hin sie soll. Das einzige was man im Beispiel machen muss ist ein Doppelklick, den Laptop einzuschalten, den Sync auszulösen und die Sync-Anforderung zu bestätigen.
• Das Einschalten des Laptops kann auch "ausversehen" passieren, ist also keine besondere Aktion. Das Auslösen des Sync kann auch automatisch passieren, über eine Art "Buddy-Liste" wenn sich der Status einer bekannten Maschine von "Offline" auf "Online" wechselt (auch diese Information kann im Directory stecken). Die Bestätigung des Syncs kann man bei bekannten Gegenstellen auch automatisieren.
• Selbst der Sync-Vorgang mit dem Handy kann automatisch geschehen, sofern man das Handy synct. Im Beispiel aber fand das niemals statt.

Somit läuft der Vorgang in der Regel vollkommen unbemerkt, aber sicher, im Hintergrund ab.

Ein Eindringen ist wegen der PKI sehr schwer, jemand müsste erst einmal Zugriff auf die PKI-Infrastruktur erhalten, die aber nicht auf dem Server liegt, sondern individuell irgedwo. Man kann die PKI auch abkoppeln, d. h. sie steckt z. B. auf einem USB-Stick den man nicht immer eingesteckt hat. Da aber Zertifikate erst aktiv werden sobald man sie verwendet kann man sich Zertifikate auf Vorrat herstellen. Sobald sich ein Zertifikat einer Client-Gruppe anschließt muss es erst (Web of Trust) durch einen anderen Client gegengezeichnet werden, d. h. es wird vor seiner Verwendung erst einmal manuell autorisiert.

Infiltriert jemand nur einen Client so kann er nur den Schlüssel des Client kompromitieren. Da DiCeDiSe aber die Sync-Vorgänge protokolliert würde automatisch bei der Verwendung des Clients der Mismatch auffallen, d. h. der Client sieht von sich einen Sync-Vorgang den er nicht kennt.

Die Server selber halten nur die Status-Informationen vor. Man kann durch ein Infiltrieren keinerlei wichtigen Daten selber erhalten, lediglich die Statusinfos über die Daten sind verfügbar, und das auch noch per PKI verschlüsselt. Das Einschleusen von Falschinformationen verhindert das PKI, das Löschen von wichtigen Informationen ist normal, Sequenzfehler (vortäuschen eines alten Standes, warum auch immer) kann man durch "3rd Party Review" erkennen, d. h. ein Client veröffentlicht nicht nur seinen Status, sondern den Status deren, die er sieht, der Sync zu einem anderen Client ist dann erfolgreich, wenn beide Statusinformationen gegenseitig matchen.

Der einzige valide Angriff den ich sehe ist, sich Zugang zu einem Client zu verschaffen, sich dort ein vorliegenes Client-Zertifikat zu klauen um dieses dann einer Gruppe hinzuzufügen. Dem kann man begegnen, indem ein Zertifikat erst durch die Gegenzertifizierung von mehreren Clients vertraut wird (oder man nur die eigne Zertifizierung akzeptiert). In diesem Fall wird der Aufwand etwas höher um den Sync auszulösen, aber dafür auch viel sicherer, aber nicht besonders viel komplizierter. Also ist dieser Weg empfohlen.

Insgesamt kann ich nur sagen, dass DiCeDiSe die Sicherheit nicht schlechter werden lässt. Mit einer ordentlich geschriebenen Datentransfer-Option, die z. B. keine Binärdaten sondern immer nur Text überträgt, dazu noch stark begrenzt in der Länge, und außerdem nur Verbindungen zu bekannten Clients erlaubt, sollte auch gegen typische Buffer-Overruns ein Mittel vorhanden sein.

Ein derartiges Design, das keine zusätzlichen Sicherheitslücken öffnet, ist mir sehr wichtig, da es keinen Ansatzpunkt für Hacking aus der Ferne bietet.

Beispiel: Out-Of-Band Login

Hier mal ein etwas exotischeres Beispiel was diese Infrastruktur leisten könnte.

Wenn man online remote arbeiten möchte sind oft Autorisationen notwendig. Ein direkter Login wie bei SSH ist zwar häufig, aber oft kommt ein indirekter Login zustande, d. h. man will sich über SSH mit einem SSH-Host verbinden.

Das hat einen großen Nachteil: Die Login-Information muss irgendwie übertragen werden. Kennt man den Sicherheitsstand des zwischenliegenden Systems (1. Hop) nicht, ist man eigentlich außen vor:

Passwort kann man nicht verwenden, das geht im 1. Hop in Klartext über um dann verschlüsselt weiterübertagen zu werden. So besteht die Gefahr eines Mitlauschens.

Auth-Daemon kommt eigentlich auch nicht in Frage. Das Problem ist dasselbe: Der Auth-Daemon meldet nicht (jedenfalls kenne ich keine SSH-Implementierung in der er das tut!), wenn die Information generiert wird. So ist es dem 1. Hop also möglich, einfach so die Autorisierungsinformation zu missbrauchen. Das bedeutet, diese Methode ist genauso schlecht wie ein Passwort, da der Auth-Daemon so lange er läuft alles autorisiert.

Mit einem Out-Of-Band Login lässt sich das aber lösen. Wenn man sich einloggt wird das Resultet des Challenge über DiCeDiSe übertragen und dieser somit autorisiert. Da es sich um ein verteiltes System handelt ist es vollkommen egal, welchen Server man dafür verwendet. Da ein PKI vorhanden ist, kann die Autorisierung auch nicht verfälscht werden. Außerdem kann man identifizieren, wer anfragt.

Hat man es nicht explizit automatisiert kommt also ein Popup das die Anfrage vom Login-Service beim Client bestätigen lässt. Die Auslösung ist die Übertragung des Challenge. Selbst wenn jemand dieses Verfahren infiltriert protokolliert die Infrastruktur den Vorgang und speichert den Statuswechsel.

Ein Angriff ist nur möglich wenn jemand den Client unter Kontrolle hat. Wenn er das hat kann er sowieso alles tun. Der Alternativangriff wäre, dass er den Server unter Kontrolle haben muss. Das bringt ihm aber wenig, denn er hat den Server ja schon unter Kontrolle.

Die DiCeDiSe Infrastruktur selber birgt wieder keinerlei zusätzliche Unsicherheit, da das PKI nicht von dieser abhängt. Wer das PKI infiltriert hat, der könnte unter Umständen ein Problem erzeugen, aber indem man den Vorgang vorsichtig definiert, z. B. indem man ein Client-Zertifikat nur dann zulässt wenn es entsprechend zertifiziert ist (wofür es mehrere Möglichkeiten gibt, z. B. eine Liste zulässiger Zertifikate auf dem Server) ist auch der Angriff aus dieser Richtung unwahrscheinlich.

Alles was man bräuchte wäre eine weitere Autorisierungsebene in SSH. Evtl. reicht sogar PAM dafür aus (und ein entsprechend modifizierter SSH-Client).

-Tino, 2007-03-20