Password-Keeper

Ein brauchbarer Password-Keeper wird für mich immer wichtiger. Leider habe ich bisher keinen gefunden. Hier sind die Notwendigkeiten für solch ein Ding:

  • Die Daten werden mit einem asymmetrisches Verfahren (PKI) verschlüsselt gespeichert, hinzufügen von Daten ist ohne Passphrase mögich.
  • Es gibt Clients für Windows, Linux, PDAs, Handys (sozusagen alles was eine Tastatur besitzt)
  • Man kann auf jedem Client Daten erfassen und ändern, jederzeit und parallel
  • Die Clients kann man über eine beliebige mögliche Datenverbindung synchronisieren
  • Die Synchronisation kann Asynchron geschehen (eMail, Internet, etc.)
  • Die Synchronisation ist gegen Lauscher gesichert (OTP usw.)
  • Die Datenhaltung ist gegen Datenfehler gesichert
  • Es müssen Datenmengen im Bereich um 500 MB problemlos verarbeitet werden können
  • Es gibt eine Open-Source-Referenzimplementierung, damit man die Korrektheit der Datenhaltung usw. verifizieren kann
Tatsächlich werden nur kleine Datenmengen gespeichert. Dazu können verschlüsselte Dokumente kommen, wobei die notwendigen Schlüssel im Password-Keeper gespeichert werden.

Gründe:

  • Für die Synchronisation werden OTPs verwendet, die von Quelle und Ziel abhängig sind. Deshalb braucht man ziemlich viel Speicherplatz.
  • Die OTPs müssen auf irgendeine Weise sicher übertragen werden, z. B. indem man sie direkt auf die Speicherkarte kopiert.
  • Datenfehler in verschlüsselten Bereichen sind problematisch, weil man diese Bereiche eben nicht lesen kann. Deshalb muss es unmöglich sein, dass Bitfehler unerkannt bleiben. Dies geht z. B. indem die Daten in Form eines ewigen Logfiles gespeichert werden.
  • Verschlüsselungsverfahren können geknackt werden. Nur OTPs sind hinreichend sicher. Dazu müssen die OTPs geheim gehalten werden, weswegen zusätzlich ein asymmetrisches Verfahren mit einem kryptologischen Pseudo-Random-Generator zum Einsatz kommen muss. Anderenfalls kann man die Update-Files nicht auf öffentliche Wege bringen.
  • Updates werden in Dateiform eingelesen, so dass man in beliebiger Reihenfolge von beliebigen Systemen einlesen kann. So ergibt sich ein Update-Mesh, indem man Änderungen an andere Clients weiterleiten kann. Dazu muss jeder Client tracken, welcher Client wie weit synchronisiert sind.
  • Durch dateiartig geblockte Updates kann man diese beliebig übertragen. Jede Datei muss dabei eigenständig und unabhängig sein, d. h. niemals nur partielle Informationen enthalten die man getrennt voneinander updaten kann. Da die Dateien mehrstufig verschlüsselt sind, kann man sie auch über ungesicherte Kanäle übertragen. Die Dateien müssen aber gegen Replay- und Änderungsattacken gesichert sein.
  • Jeder Client ist gleichberechtigt, dadurch kann auch jeder neue Informationen erfassen oder diese verändern. Jeder Client muss deshalb einen Zeitstempel und inkrementierte Seriennummer haben, damit man einerseits herausfinden kann, dass nichts fehlt, und andererseits weiss, wann in etwa etwas überschrieben wurde sofern etwas überschrieben wurde. Wenn etwas überschrieben wird, muss man außerdem leicht an die ältere Information kommen.
  • Es sollte eine Referenz-Implementierung in Java für den Client geben, damit man diesen auf jedem beliebigen Java-Device laufen lassen kann. Die GUI sollte dabei möglichst einfach gehalten sein, damit man sie leicht und schnell bedienen kann.
  • Die Datenhaltung auf dem Datenträger muss so verschlüsselt sein, dass man ohne Kenntnis der Passphrase nicht an die Daten kommt. Es muss aber verschiedene zusätzlich gesicherte Bereiche geben, so dass die Kompromittierung der Master-Passphrase nicht alle Passworte herausrückt.
-Tino, 2008-09-23