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

Mit "AGB-Upgrade" bezeichnen wir das Verfahren, dass Sie als Kund*in 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 akzeptierte.

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. 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" (Nullwissen), 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. Auch dies kann bei Zero-Knowledge-Servern nicht immer garantiert werden.

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 der Benutzer*in 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*in, Client und Server. Bei der Benutzer*in 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*in und Client unterstützt, dabei möglichst auf Wissen um streng geheime Benutzer*innendaten verzichtet, aber weniger geheime Benutzer*innendaten zumindest wirksam vor dem Zugriff Dritter schützt.

Beim "Cautiously Knowing Service" entscheidet immer die wohlinformierte Benutzer*in, 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.

Siehe auch clientseitige Verschlüsselung und serverseitige Verschlüsselung.

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

Die Eigentümer*in einer Box ist in der Regel diejenige, die sie angelegt hat, oder diejenige, der die Box von der Voreigentümer*in freiwillig oder per Erbschaft übertragen wurde.

In der Regel ist die Eigentümer*in einer Box eine natürliche Person, selbst wenn sie 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. raten wir, solche Eigentumsverhältnisse 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 bezogen auf 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 einer oder mehreren Administrator*innen verwaltet. Hier macht die Eigentümerschaft einer juristischen Person (z. B. einer Firma oder eines Vereins) durchaus Sinn.

Missbraucht eine Administrator*in ihr Recht und entzieht anderen Mitgliedern der Gruppe unberechtigt den Zugriff, könnte die Eigentümer*in die Einsetzung einer anderen Administrator*in, einfordern.

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

Handelt es sich bei der Eigentümer*in um eine einfache Gruppe natürlicher Personen, die sämtlich über Boxen Zugriff auf den Gruppen-Container haben (bzw. vor dem behaupteten Missbrauch der Administrator*in 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 können Indizien sein.

Wichtig ist auch, von welcher Box aus die Gruppe erstellt wurde. Die Eigentümer*in dieser Box gilt zunächst als Eigentümer*in des Gruppen-Containers. 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 die Usurpator*in alleine in ihr verbleibt.

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

Ein "Fingerabdruck" ist bei key.matiq eine lange Zeichenkette, der einem Klartext zuordnet wird und bei Änderung des Klartexts ebenfalls geändert wird. Damit kann bei Übertragung eines verschlüsselten Werts überprüft werden, ob sende- und empfangsseitig der gleiche Klartext-Wert zugrunde liegt.

Der Fingerabdruck ist im Gegensatz zu "Hashes" nicht vom Klartext abgeleitet, sondern wird zum Großteil zufällig gebildet. Er enthält ansonsten nur noch einen Zeitstempel, die ID des erzeugenden Serverprozesses und die Nummer der Formatversion. Daher kann der Fingerabdruck nahezu bedenkenlos offengelegt 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.matiq eine Kund*innennanfrage zum Wiedererlangen einer verloren gegangenen Kontrolle über eine Box oder einer Gruppe. Ein Ticket durchläuft ein komplexes Verfahren, bei dem die Anfragende identifiziert wird und ihr Eigentum 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 der anfragenden Person 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 die Box-Inhaber*in 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 einer neuen Admnistrator*in.

Ein Ticket funktioniert in mancher Hinsicht ähnlich wie eine kleine Box. Die Ersteller*in 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 die Antragsteller*in das Hauptkennwort dort abholen kann.

Dieser Aspekt ist beim Begriff "Ticket-Container" gemeint, auch wenn der allgemeinere Begriff "Container" bei key.matiq 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 ggf. durch einen kostenpflichtigen Vertrag 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 Kund*innentyps für einen Container und den Umzug der Kund*in 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.

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.matiq). Einzahlungen enthalten evtl. Daten über die Bankverbindung. Zumindest kurzzeitig weiß jeder Server die IP-Adresse des Clients (solange letzerer nicht das Tor-Netzwerk benutzt). Er sollte auch nicht mit dem wissenschaftlichen Begriff "Zero-Knowledge-Proof" verwechselt werden.

Bei einigen wichtigen Funktionen (Malwarescan von geteilten Dateien aber auch bei der Suchfunktion) ist die Restriktion auf Nullwissen kontraproduktiv, weshalb hier Ausnahmen, über die allerdings die Benutzer*in 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+"

Bei key.matiq 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 der Box-Eigentümer*in 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.