Abkürzung für Zwei-Faktor-Authentisierung.

Mit "AGB-Upgrade" bezeichnen wir das Verfahren, dass Sie als Kunde geänderte AGB für Ihren Container-Vertrag akzeptieren. Es ist auch möglich, dass Sie eine Version der AGB akzeptieren, die schon nicht mehr den aktuellen entspricht, aber neuer ist als die bislang akzeptierten.

Wenn Sie die AGB nicht aktualisieren, läuft der Vertrag unter den bisherigen AGB weiter. Allerdings müssen Sie damit rechnen, dass zu diesen Bedingungen eine Verlängerung des Vertrages (z. B. durch Guthabeneinzahlung) nicht mehr möglich ist.

Damit Sie (und wir) den Überblick behalten, werden die AGB mit einer dreiteiligen Versionsnummer (z. B. "1.2.3")versehen. Der erste Teil (im Beispiel "1"), die Hauptversionsnummer, wird nur geändert, wenn gravierende Änderungen erfolgt sind. Wird sie nicht geändert, so greifen die AGB-Änderungen nach unserem Verständnis nicht in Ihre bestehenden Rechte ein, sondern erweitern diese höchstens. Der zweite Teil (im Beispiel "2") wird geändert, wenn überhaupt inhaltliche Änderungen erfolgt sind. Und nur der dritte Teil wird geändert, wenn die Änderungen den juristischen Inhalt überhaupt nicht berühren, sondern nur die sprachliche Darstellung verbessern.

Mit dem Begriff "Cautiously Knowing Service" entwickeln wir den mit dem "Zero-Knowledge-Server" verbundenen Ansatz weiter:

Wir sprechen von "Cautiously Knowing" (behutsam wissend) anstelle von "Zero-Knowledge" (Null-Wissen), da Ausnahmen auch unter Sicherheitsaspekten sinnvoll sind: Ein Malwarescan von untergeschobenen Dateien wäre für einen Zero-Knowledge-Server nicht möglich. Wenn ein Kennwort kompromittiert ist, ist es wichtig herauszufinden, wo es in Verwendung ist. Dazu muss aber die Suchfunktion auch in angemessener Zeit Ergebnisse liefern.

Wir sprechen von "Service" und nicht nur vom Server, um zu betonen, dass nicht nur der Server betroffen ist, sondern auch der Client (JavaScript-Programmierung des Browsers) ins Visier genommen wird und auch für die Führung und Aufklärung des Benutzers Verantwortung übernommen wird.

Die Forderung, sowenig Wissen über Klartexte und Schlüssel wie möglich zu halten, aber so viel wie nötig zu ermöglichen, gilt beim "Cautiously Knowing Service" auf allen drei Ebenen: Benutzer, Client und Server. Beim Benutzer geht es dabei um die Entlastung, beim Client darum, dass keine ungewollten Spuren von geheimen Daten nach Beendigung (oder Unterbrechung) einer Sitzung im Browser verbleiben und beim Server darum, dass er Benutzer und Client unterstützt, dabei möglichst auf Wissen um streng geheime Benutzerdaten verzichtet, aber weniger geheime Benutzerdaten zumindest wirksam vor dem Zugriff Dritter schützt.

Beim "Cautiously Knowing Service" entscheidet immer der wohlinformierte Benutzer, ob der Server für bestimmte Zwecke (z. B. Malwarescan oder Suchfunktion) auf Klartexte oder Schlüssel kurzzeitig Zugriff erhält oder Einschränkungen in Kauf genommen werden.

Während wir für eine fachliche Diskussion den Begriff "Cautiously Knowing Service" als optimal ansehen, gebrauchen wir für den Einstieg auch den Begriff "Zero-Knowledge+", um deutlich zu machen, dass unser Vorgehen im Ergebnis zu einem Mehr an Sicherheit führt.

Siehe auch den Blog-Artikel Zero-Knowlege+: Der Cautiously Knowing Service.

• Der Besitz: Ein Box-Eigentümer besitzt seine Box, indem er und nur er das Hauptkennwort weiß. Ein Administrator einer Gruppe besitzt den Gruppen-Container (weil nur er ihn verändern kann).
• Das Wissen: Ein Box-Eigentümer kann unverschlüsselte Informationen benennen, die in der Box gespeichert sind.
• Das Bezahlen: Der Eigentümer einer Box- oder eines Gruppen-Containers hat dafür bezahlt.
• Verträge: Der Eigentümer eines Gruppen-Containers kann nachweisen, dass er den Administrator der Gruppe beauftragt hatte, diese für ihn zu erstellen.

Der Eigentümer einer Box ist in der Regel derjenige, der sie angelegt hat, oder derjenige, dem sie vom Voreigentümer freiwillig oder per Erbschaft übertragen wurde.

In der Regel ist der Eigentümer einer Box eine natürliche Person, selbst wenn er Geheimnisse verwaltet, die juristischen Personen oder einer Gemeinschaft von natürlichen Personen gehören.

Es sind zwar andere juristische Eigentumsverhältnisse (z. B. nach Vererbung an eine Erbengemeinschaft, nach Erstellung einer Box im Auftrag eines Dritten oder vertraglicher Übertragung) denkbar, aber wir raten davon ab, bzw. dazu, diese baldmöglichst aufzulösen.

Denn: Praktische Bedeutung hat die Eigentümerschaft nur, um die Kontrolle über eine Box wiederzuerlangen (siehe Ticket). Die Prüfung der Eigentümerschaft ist bei natürlichen Personen weitaus einfacher, und entsprechend sind die Erfolgsaussichten höher.

Einen Wert hätte die Eigentümerschaft für juristische Personen oder Gemeinschaften ohnehin nur für die gespeicherten Geheimnisse. Diese lassen sich aber besser über Verteiler und Gruppen auf mehrere Personen verteilen als den Besitz über die Reklamation des juristischen Eigentums sicherzustellen.

Anders als bei einer Box stellt sich das Eigentum an Gruppen-Containern dar. Diese werden von einem oder mehreren Administratoren verwaltet. Hier macht die Eigentümerschaft einer juristischen Person (z. B. einer Firma oder eines Vereins) durchaus Sinn.

Missbraucht ein Administrator sein Recht und entzieht den anderen Mitgliedern der Gruppe unberechtigt den Zugriff, könnte der Eigentümer, in dessen Auftrag die Administratoren handelten, die Zuordnung zu einem anderen, legitimierten Administrator, einfordern.

Der Eigentümer kann darum den key.matique-Support bitten, indem er ein Gruppen-Ticket anlegt (Menü "Support", Punkt "Gruppe verloren"). Das wird allerdings nur bewilligt, wenn die juristische Lage eindeutig ist.

Handelt es sich bei dem Eigentümer um eine einfache Gruppe natürlicher Personen, die sämtlich über Boxen Zugriff auf den Gruppen-Container haben (bzw. vor dem behaupteten Missbrauch des Administrators hatten), so dürfte eine Willensbekundung der absoluten Mehrheit dieser Gruppe entscheidend für die Beurteilung der Lage sein.

Auch Verträge können die Eigentümerschaft beweisen, Einzahlungen und der Name der Gruppe Hinweise geben.

Wichtig ist auch, von welcher Box aus die Gruppe erstellt wurde. Der Eigentümer dieser Box gilt zunächst als Eigentümer der Gruppe. Andere Eigentumsansprüche unterliegen der Beweispflicht.

Schließlich gibt es noch eine pragmatische Alternative: Alle anderen Mitglieder verlassen die Gruppe und bilden eine neue, während der Usurpator alleine in ihr verbleibt.

Bei größeren und mittleren Bildschirmen, wird die Ordner- bzw. Listen-Ansicht in der "Explorer-Ansicht" dargestellt. Wir meinen damit, dass links der Baum- bzw. Listen-Bereich dargestellt wird und rechts daneben Details des ausgewählten Objekts angezeigt oder bearbeitet werden.

Dieses Kennwort dient sowohl dazu, den Zugang zur Box zu erlangen, als auch die in der Box enthaltenen Geheimnisse zu ver- und entschlüsseln.

Das ist für key.matique eine Kundenanfrage zum Wiedererlangen einer verloren gegangenen Kontrolle über eine Box oder einer Gruppe. Ein Ticket durchläuft ein komplexes Verfahren, bei dem der Anfragende identifiziert wird und seine Eigentümerschaft an der Box bzw. am Gruppen-Container geprüft wird. Die dabei erhobenen Daten werden über einen längeren Zeitraum für die mit dem Ticket befassten Stellen dokumentiert. Dabei werden persönliche Daten des Anfragenden verschlüsselt gespeichert (Schlüssel nur den befassten Stellen zugänglich), damit für Außenstehende selbst bei einem Zugriff auf die Datenbank (neben den unverschlüsselten Anteilen der Box, über deren Umfang ja der Box-Inhaber die alleinige Kontrolle hat) keine zusätzlichen Anhaltspunkte für den Bezug einer Box zu einer Person entdeckt werden können.

Bei einem Box-Ticket geht es meist um die Wiedererlangung eines hinterlegten Hauptkennworts oder um das Setzen eines neuen Hauptkennworts.

Bei einem Gruppen-Ticket geht es meist um das Einsetzen von einem neuen Admnistrator.

Ein Ticket funktioniert in mancher Hinsicht ähnlich wie eine kleine Box. Der Ersteller legt dafür ein Kennwort fest und das Ticket erhält, wenn es um die Wiedererlangung des Hauptkennworts einer Box geht, die Hauptkennwortteile von den Hinterlegungsstellen (nach Prüfung der Anfrage) "eingeworfen", so dass schließlich der Antragsteller das Hauptkennwort dort abholen kann.

Dieser Aspekt ist beim Begriff "Ticket-Container" gemeint, auch wenn der allgemeinere Begriff "Container" bei key.matique nur Boxen und Gruppen-Container einschließt und nicht Ticket-Container.

Verträge können für die Nutzung eines Containers oder die Prüfung und Ausführung eines Tickets abgeschlossen werden.

Bei der Erstellung eines Containers (Box oder Gruppe) wird zunächst ein nicht-kostenpflichtiger Vertrag abgeschlossen, der durch ggf. durch einen kostenpflichtigen Verträge abgelöst werden kann.

Bei einem Container-Vertrag (für Box oder Gruppe) handelt es sich immer um einen befristeten Vertrag, der jedoch durch Einzahlung von Guthaben, Abgabe oder Annahme von Guthaben sowie Upgrade und Downgrade des Speicherkontingents in seiner Laufzeit immer wieder verändert werden kann. Für die Verlängerung der Laufzeit ist jedoch in der Regel die Akzeptanz der jeweils aktuellen AGB erforderlich.

Tickets werden wenn möglich als Kulanzleistung kostenlos erbracht. Sollte die Prüfung aber aufwändig werden, so kann ein kostenpflichtiger Vertrag nötig werden, um die Abarbeitung zu ermöglichen.

Ein Verfahren, um die Übertragung von Guthaben zwischen verschiedenen Containern zu ermöglichen. Es erlaubt auch die Umwandlung des Kundentyps für einen Container und den Umzug des Kunden in anderes Land. Auch die Änderung der Mehrwertsteuer wird über dieses Verfahren behandelt.

Im Normalfall wird die Nutzung von Containern über Nettoguthaben abgerechnet. Lediglich bei Einzahlung, Rückzahlung und in den oben Ausnahmefällen wird zwischen Nettoguthaben und einem Ein- oder Auszahlungsbetrag umgerechnet. Siehe auch Übertragungswert.

Bei key.matique ist der erste Faktor das auswendig gelernte und/oder im Browser (über ein Hauptpasswort sicher) gespeicherte Hauptkennwort. Der zweite Faktor ist im Regelfall der unaufdringliche Nachweis über ein Cookie, dass das anmeldende Gerät dem Box-Eigentümer gehört. Im Ausnahmefall dient ein Anmeldeschlüssel als zweiter Faktor.

Da die Überprüfung des Cookies automatisch erfolgen kann, ist diese Art der Zwei-Faktor-Authensierung vergleichsweise unaufdringlich und erfordert nur bei Einrichtung, neuen Geräten, Sperrung oder Aussperrung einen jeweils so gering wie möglich gehaltenen Aufwand.

Wir unterscheiden zwischen der "starken Zwei-Faktor-Authentisierung" und der "schwachen" Variante. Die "starke" Variante gibt Anmeldeschlüssel nur über sichere Kanäle heraus, die "schwache" versendet dagegen unter bestimmten Bedingungen auch Anmelschlüssel per E-Mail.

Mit "Zero-Knowledge+" bezeichnen wir unsere Weiterentwicklung der von anderen Onlne-Passwortmanagern als "Zero-Knowlege-Server" bezeichneten Vorgehensweise. Wir wollen damit deutlich machen, dass im Ergebnis ein Mehr an Sicherheit herauskommt, auch wenn wir vom strikten Nullwissen des Servers (das es in Wahrheit auch bei sogenannten "Zero-Knowledge-Servern" in aller Regel nicht gibt) abrücken und stattdessen einen "Cautiously Knowing Service" präsentieren.

Der Marketing-Begriff "Zero-Knowledge-Server" wird von vielen Online-Passwortmanagern verwendet und bedeutet, dass der Server freiwillig den Hauptschlüssel, Einzelschlüssel und die Klartexte der Geheimnisse nicht kennt. Insbesondere kennt der Server das Hauptkennwort nicht.

Der Begriff kann irreführend sein: Auch ein "Zero-Knowledge-Server" weiß in der Regel nicht "nichts". Meist ist die Angabe einer E-Mail-Adresse obligatorisch (wenn auch nicht bei key.matique). Einzahlungen enthalten evt. Daten über die Bankverbindung. Zumindest kurzzeitig weiß jeder Server die IP-Adresse des Clients (solange er nicht das Tor-Netzwerk benutzt). Er sollte auch nicht mit dem wissenschaftlichen Begriff "Zero-Knowledge-Beweis" verwechselt werden.

Bei einigen wichtigen Funktionen (Malwarescan von geteilten Dateien aber auch bei der Suchfunktion) ist die Restriktion auf Null-Wissen kontraproduktiv, weshalb hier Ausnahmen, über die allerdings der Benutzer entscheiden müsste, sinnvoll sind. Deshalb haben wir das Konzept unter dem neuen Begriff "Cautiously Knowing Service" weiterentwickelt. Als griffige Bezeichnung verwenden wir dafür "Zero-Knowledge+"