Das Agile-Schlüsselbund-Design
Das Ziel des Agile-Schlüsselbunds ist es, auf den Erfolgen des OS X-Schlüsselbunds aufzubauen, jedoch die Flexibilität und Portabilität des Schlüsselunddesigns zu erhöhen. Zusätzliche Flexibilität wird benötigt, um neue Funktionen, die über den OS X-Schlüsselbund hinausgehen, zu ermöglichen und es leichter zu machen, den Schlüsselbund auf anderen Plattformen wie iPhone OS, Linux und Windows zu integrieren.
Die spezifischen Anforderungen, für die der Agile-Schlüsselbund geschaffen wurde, sind in der Geschichte der OS X-Schlüsselbund-Integration in 1Password dokumentiert. Dieses Dokument behandelt die Anforderungen des Agile-Schlüsselbunds und beschreibt, wie es diese durch sein Design erfüllt.
Anforderungen
Das Design des neuen Agile-Schlüsselbunds muss folgendes unterstützen:
- Es darf nicht eine einzige Code-Zeile für die Verschlüsselung zu schreiben sein. Verschlüsselungscode ist kniffelig und man überlässt das am besten Experten.
- Der ganze Veschlüsselungs- und Schlüsselerzeugungs-Code muss Open Source sein und von Millionen Leuten verwendet werden. Die große Anwenderbasis ist wichtig, damit der Code robust, gut getestet und von der Gemeinschaft gut unterstützt wird.
- Automatisches Sperren, einschließlich bei Ruhezustand, Bildschirmschoner und nach einer einstellbaren Zeitspanne von Inaktivität.
- Er muss auf vielen Plattformen erreichbar sein, wie z.B. iPhone/iPod Touch, Linux und Windows.
- Hohe Geschwindigkeit, die nicht abnimmt, wenn die Schlüsselbundgröße wächst.
- Verschiedene Sicherheitslevel sollten möglich sein, von Einträgen geringerer Wichtigkeit, die immer verfügbar sind bis hin zu äußerst wichtigen Einträgen, die ein Kennwort bei jeder Verwendung erfordern und nach Verwendung automatisch gesperrt werden.
- Er muss aus mehreren Programmen erreichbar sein, aber nicht jedes Programm soll den Schlüsselbund selbst entsperren müssen.
- Die Möglichkeit zu synchronisieren, ohne auf MobileMe zu setzen. Das Design sollte die Grundursachen gängiger Synchronisationsprobleme minimieren, wie Z.B. doppelte Einträge, die erzeugt werden, Einträge, die ohne erkennbaren Grund gelöscht werden und die Erzeugung defekter Einträge, auf die nicht zugegriffen werden kann.
Design-Entscheidungen
Die folgenden Design-Entscheidungen wurden getroffen, um die obigen Anforderungen zu erfüllen.
AES-Verschlüsselung unter Verwendung von OpenSSL
Wie immer wollten wir keine einzige Zeile Verschlüsselungscode schreiben. Der Agile-Schlüsselbund verwendet daher die OpenSSL-Bibliothek für die Verschlüsselung und Schlüsselerzeugung.
OpenSSL ist Open Source, wird auf der Mehrzahl der Server weltweit verwendet, wird bei jedem Mac mitgeliefert und wird aktiv von einer riesigen Gemeinschaft unterstützt. Es ist außerdem mit den Standards FIPS 140-1 und FIPS 140-2 konform.
OpenSSL wird zum Verschlüsseln aller vertraulichen Informationen durch AES (Advanced Encryption Standard) unter Verwendung von 128-Bit-Verschlüsselungsschlüsseln verwendet und im Cipher Block Chaining-Modus (CBC) ausgeführt, zusammen mit einem zufälligen Initialisierungsvektor.
Auch wenn es möglich wäre, 256-Bit-Schlüssel zu verwenden, verwendet der Agile-Schlüsselbund stattdessen 128 Bit, da dies auf absehbare Zeit sehr sicher ist und kurz genug, damit Geräte wie das iPhone und Web-Browser die Inhalte schnell genug entschlüsseln können. Die zusätzliche Berechnung, die für eine 256-Bit-Verschlüsselung nötig ist, ist der Aufwand nicht wert. Hier ein Ausschnitt von der National Institute of Standards and Technology-Webseite AES: Questions and Answers:
Wie groß ist die Chance, dass jemand eine „DES-Cracker“-artige Hardware verwendet, um einen AES-Schlüssel zu knacken?
!n den späten 1990ern wurden spezielle „DES-Cracker“-Maschinen gebaut, die einen DES-Schlüssel in ein paar Stunden wiederherstellen konnten. Anders gesagt konnte die Hardware durch Ausprobieren der möglichen Schlüsselwerte ermitteln, welcher Schlüssel zum Verschlüsseln einer Nachricht verwendet wurde.
Angenommen, jemand könnte eine Maschine bauen, die einen DES-Schlüssel in einer Sekunde wiederherstellen könnte (das sind 255-Schlüsselversuche pro Sekunde), dann würde es ungefähr 149 Billionen Jahre dauern, um einen 128-Bit-AES-Schlüssel zu knacken. Das Universum ist übrigens weniger als 20 Milliarden Jahre alt.
Wir sind daher der Meinung, dass das Hinzufügen weiterer 128 Bit, das wäre eine Multiplikation der 149 Billionen Jahre mit 3,4 * 1038 es nicht wert wäre, was es an Geschwindigkeit kosten würde. Bei 128 Bit ist es sehr viel wahrscheinlicher, dass ein Angreifer nach einer Schwachstelle im darunterliegenden System sucht, als dass er die Berechnung des AES-Algorithmus angreift.
Erzeugung des Verschlüsselungs-Schlüssels
Die wichtigste Komponente bei der Verschlüsselung, was oft übersehen wird, ist die Art, wie Schlüssel erzeugt werden. Das muss auf eine Weise erfolgen, die sicherstellt, dass die Berechnungen des AES-Algorithmus' nicht umgangen werden können und er außerdem Brute-Force-Angriffen standhält.
Der Agile-Schlüsselbund verwendet den Standard PBKDF2-Algorithmus (Password-Based Key Derivation Function), um Schlüssel aus Ihrem Kennwort zu erzeugen. PBKDF2 wurde von der Internet Engineering Task Force in der RFC 2898 veröffentlicht.
Wir wollten natürlich verhindern, diesen Code in den Agile-Schlüsselbund zu schreiben und wählten die OpenSSL-Funktion PKCS5_PBKDF2_HMAC_SHA1 aus, um die Schlüssel zu erzeugen. Schlüsselerzeugung ist einfach ein zu wichtiger Schritt, als dass man ihn nicht Experten überlassen sollte. Um Möchtegern-Angreifer zu behindern und den Schlüssel zu sichern, wählten wir 1000 Wiederholungen im PBKDF2-Algorithmus.
Warum ist es so wichtig, den Verschlüsselungs-Schlüssel zu sichern? Es gibt Werkzeuge, die auf das Knacken von Kennwort-Hashcodes spezialisiert sind. Zum Beispiel der Lighting Hash Cracker kann 608 Millionen Kennwörter pro Sekunde testen. Wenn ein einfacher Schlüsselerzeugungs-Algorithmus zum Erzeugen des Schlüssels verwendet wurde, der das Kennwort nur einmal „hasht“, können Angreifer ein System wie dieses verwenden, um das Kennwort mit roher Gewalt herauszufinden. Durch die Verwendung von 1000 Wiederholungen in der PBKDF2-Funktion ist ein Brute-Force-Angriff effektiv tausendmal schwieriger.
Hierarchie der Verschlüsselungs-Schlüssel
Damit Sie Ihr Kennwort ändern können, ohne dass der gesamte Agile-Schlüsselbund entschlüsselt und wieder verschlüsselt werden muss, wurde eine Verschlüsselungs-Schlüssel-Hierarchie erzeugt. Statt dass die Daten mit dem Kennwort direkt verschlüsselt werden, wird ein zufälliges Kennwort der Länge 1024 Bytes verwendet. Das Kennwort wird mit /dev/random erzeugt und in der Datei encryptionKeys.js gespeichert, verschlüsselt unter Verwendung des Kennworts, das der Anwender angegeben hat.
Durch die Verwendung eines solch riesigen Schlüssels, der über /dev/random erzeugt wurde, kann Ihr Kennwort einfach durch Entschlüsseln und Verschlüsseln der Schlüssel, die in encryptionKeys.js gespeichert sind, geändert werden. Zusätzlich können Sie verschiedene Kennwörter auf verschiedenen Geräten verwenden. Das Master-Kennwort auf dem Desktop-Rechner kann dann z.B.schwieriger zu tippen sein als auf einem iPhone.
Ein anderer Vorteil dieser Einrichtung ist, dass es erlaubt, mehrfache Sicherheitslevels anzulegen. Jedesmal, wenn ein Sicherheitslevel erzeugt wird, erzeugen wir einfach einen weiteren Schlüssel, um Objekte zu verschlüsseln, die dieses Sicherheitslevel verwenden. Ein Beispiel dafür ist das iPhone, auf dem eine einfache PIN verwendet werden kann, um weniger wichtige Objekte zu sichern, wohingegen das Master-Kennwort für sensible Anmeldungen benötigt wird.
Speicherung im Dateisystem
Jeder Eintrag im Agile-Schlüsselbund wird in einer separaten Datei gespeichert. Durch die Verwendung einzelner Dateien kann die Synchronisierung des Agile-Schlüsselbunds mit einer der Myriarden Dateisynchronisationslösungen erfolgen, die es für Mac OS X gibt. Viele Synchronisationslösungen wie z.B. DropBox erlauben, die Dateien zwischen Mac, Windows und Linux zu synchronisieren.
Inhalt einzelner Einträge
Der Agile-Schlüsselbund ist nahezu identisch mit dem OS X-Schlüsselbund in der Hinsicht, was verschlüsselt wird und was als reiner Text verbleibt. Dieser Unterschied ist ein wichtiger Kompromiss zwischen Sicherheit und Bequemlichkeit. Je mehr verschlüsselt ist, auf desto weniger kann ein möglicher Dieb zugreifen. Es ist aber auch wichtig, genug Informationen unverschlüsselt zu lassen, damit Programme auf bestimmte Einträge frei zugreifen können, ohne dass sie jedes Mal jeden einzelnen Eintrag entschlüsseln. Der OS X-Schlüsselbund verfolgt einen guten Kompromisse aus Sicherheit und Bequemlichkeit und der Agile-Schlüsselbund folgt diesem Beispiel.
Hier ist ein Beispiel-Eintrag aus dem Agile-Schlüsselbund:
{
"title" : "dave @ AWS login",
"keyID" : "7291B8B58CB641BA931217C73696C5C5",
"locationKey" : "perfora.net",
"encrypted" : "...",
"typeName" : "webforms.WebForm",
"openContents" : {
"folder" : "A90D66D1A4E34481BDF03DDEA9F511AC",
"createdAt" : 1216012929,
"passwordStrength" : 100,
"updatedAt" : 1216012929,
"usernameHash" : "...",
"passwordHash" : "..."
},
"location" : "https://webmailcluster.perfora.net:443/xml/webmail/Login",
"uuid" : "0A522DFCAE6442D991145BC76E55D343",
"folderUuid" : "A90D66D1A4E34481BDF03DDEA9F511AC"
}
Wie Sie sehen können, sind nicht alle Informationen verschlüsselt. Vor allem der Name/Titel jedes Eintrags (hier dave @ AWS login) und Ort/URL sind unverschlüsselt. Dadurch, dass diese nicht verschlüsselt sind, kann 1Password Ihre Daten organisieren und anzeigen, ohne dass die Geschwindigkeit leidet, weil es jeden Eintrag entschlüsseln muss. Alle wirklich vertraulichen Informationen sind im verschlüsselten Abschnitt der Datei gespeichert.
Das obige Dateiformat basiert auf JSON (JavaScript Object Notation). Es ist eine einfache Notation für strukturierte Daten, ohne den Overhead, der mit Formaten wie XML verbunden ist. Als Zusatzvorteil können diese Dateien direkt in einen Web-Browser geladen werden; mehr dazu später.
Der Name der Datei basiert auf dem UUID (Universally Unique Identifier) des Eintrags. Das garantiert, dass der Name eindeutig ist und immer gleich bleibt, auch wenn Einträge umbenannt werden.
Zusammenfassung
Die gefällten Design-Entscheidungen bei der Entwicklung des Agile-Schlüsselbunds führen zu folgenden Vorteilen:
- Synchronisierung: Durch das Speichern jedes Eintrags in eine eigene Datei können Daten zwischen Computern (Mac oder anderen) mit einem beliebigen Synchronisationsprogramm synchronisiert werden.
- Verringerte potenzielle Synchronisationsprobleme: Konflikte bei der Synchronisierung werden minimiert, da nicht eine einzige, gigantische Datei verwendet wird. Konflikte können nur auftreten, wenn der gleiche Eintrag auf mehreren Rechnern gleichzeitig geändert wird. Hilfsmittel wie DropBox synchronisieren Dateien innerhalb von Sekunden nach Änderungen, so dass es fast unmöglich ist, solche Konflikte hervorzurufen. Außerdem können durch die Verwendung der UUID für den Dateinamen keine Duplikate erzeugt werden, selbst wenn der Name des Eintrags geändert wurde.
- Pattformübergreifende Unterstützung: Durch die Verwendung des einfachen JSON-Datenformats kann jedes Programm auf jeder Plattform die Datei lesen und den Inhalt analysieren.
- Web-aktiviert: Durch das JSON-Format sind eigenständig lauffähige Web-Programme in der Lage, die Dateien zu laden. Dadurch können Sie Ihren Agile-Schlüsselbund über einen Service wie DropBox veröffentlichen und mit jedem Web-Browser sicher darauf zugreifen.
- Geschwindigkeit: Dadurch, dass sich jeder Eintrag in einer eigenen Datei befindet, wird die Geschwindigkeit von der Größe des gesamten Schlüsselbunds nicht beeinflusst. Dateisysteme unterstützen tausende Dateien und wir verlassen uns darauf. Anhänge werden ebenso in eigenen Dateien untergebracht, damit die Geschwindigkeit einzelner Einträge nicht beeinflusst wird.