Cautiously Knowing Service

In den Versionen 2.* bauen wir Zug um Zug key.matiq in einen Cautiously Knowing Service um.

Die Definition dafür ist in den Blog-Artikeln Zero-Knowledge+ (1): Der "Cau­tious­ly Know­ing Ser­vice" und Zero-Knowledge+ (4): Schutzniveaus beschrieben.

CKS-Version

Angetrebte Cautiously Knowing Service Version: 0.4 (neueste Version)

CKS-Schutzniveaus

Wir verwenden die Standard CKS-Schutzniveaus PL-2, PL-3 und PL-5, benutzen dafür aber die Bezeichnungen "PL-low", "PL-medium", "PL-high"

• PL-low: Sämtliche Nutzer*innen-Daten, soweit kein anderes Schutzniveaus spezifiziert ist (insbesondere Begleitdaten von Geheimnissen).
• PL-medium: Vor der Umstellung auf clientseitige Verschlüsselung: Sämtliche Kerngeheimnisse. Nach der Umstellung auf clientseitige Verschlüsselung: Kerngeheimnisse, für die die Nutzer*in "kurzfristiges Serverwissen" genehmigt hat (bis zum Abschluss der jeweiligen Aktion).
• PL-high: Das Hauptkennwort und sämtliche Kerngeheimnisse nach der Umstellung auf clientseitige Verschlüsselung. Dazu gehören auch über ein Ticket das wiedererlangte aktuelle Hauptkennwort und frühere Hauptkennworte.
• Spezialisierte Schutznivaus
  • PL-3+ (PL-medium+): Personenbezogene Daten in einem Ticket zur Wiedererlangung des Besitzes einer Box oder eines Gruppencontainers werden während der aktiven Phase des Tickets unter dem Schutzniveau PL-medium gehalten. Im Dokumentations-Modus wird der Schutz auf PL-high erhöht. Lesen Sie auch im Abschnitt "Vertretbare Ausnahmen" den Punkt "Datenschlüssel in Tickets"

Vertretbare Ausnahmen

An manchen Stellen werden personenbezogene Daten weniger gut geschützt als es theoretisch möglich wäre. Grund ist, dass das Aufwand-Nutzen-Verhältnis zu gering ist, diesen Problemen eine höhere Priorität einzuräumen. Wir haben jedoch diese Punkte für eine Bearbeitung zu einem späteren Zeitpunkt vorgemerkt.

• E-Mails: Da normale E-Mails unverschlüsselt sind, besteht hier immer die Gefahr der Offenlegung. Allerdings achten wir darauf, dass der Informationsgewinn für Lauscher*innen minimal ist.
  Es wäre jedoch möglich, E-Mail-Verschlüsselungen zu unterstützen. Da hierbei ein zusätzlicher nutzer*innenseitiger Aufwand erforderlich wäre, stellt sich die Frage, ob eine solche Möglichkeit in breitem Maße in Anspruch genommen würde.
• Querbezüge zwischen Geheimnissen und Komponenten einerseits und von diesen verwendeten Teilgeheimnissen (Komplemente und Komponenten) andererseits: Diese Querbezüge stehen derzeit unter dem Schutzniveau PL-low. Es wäre mit einigem Aufwand möglich, das Niveau of PL-high anzuheben.
  Der Informationsgewinn über die Geheimnisse durch Kenntnis der Querbezüge ist jedoch für eine Angreifer*in recht gering, solange sie nicht einzelne Teilgeheimnisse oder Kerngeheimnisse kennt.
• Datenschlüssel in Tickets: Einige der Angaben in Tickets stellen persönliche Daten dar, die sicherlich ein hohen Schutzniveau verdienen. Da aber diese Daten den Entscheider*innen über das Ticket zugänglich gemacht werden müssen, evtl. aber vorher noch die Supportgruppe ins Spiel kommt, um die richtige Zuordnung des Containers zu treffen, haben wir uns vorerst mit dem spezialisierten Schutzniveau PL-3+ zufriedengegeben. Tickets betreffen schließlich nur seltene Ausnahmesituationen.
  Vorgemerkt ist die Suche nach einer Lösung, um das Schutzniveau auf PL-high zu erhöhen.

Derzeitiger Stand der Umstellung

• Verteilung und Minimierung des Wissens auf die Ebenen Nutzer*in, Client und Server:
  • Soviel Wissen wie nötig, sowenig wie möglich: In Arbeit (für Registrierung, Ticketerstellung und -bearbeitung, Hauptkennwortänderung, Anmeldung und Abholung von Ticket-Ergebnissen Import von Backups und den Klartext-Export implementiert, für andere Funktionen geplant).
  • Minimierung der Angriffsfläche: In Arbeit (für Registrierung, Ticketerstellung, Hauptkennwortänderung und Anmeldung implementiert, für andere Funktionen geplant)
  • Schutz vor Datenverlust: Implementiert
• Abwehr von Erkundungsangriffen auf Boxnamen (oder mit Boxen verbundene E-Mail-Adressen) und aktive Ticket-Nummern: Implementiert.
  • Bei Anmeldung (Boxen und Tickets): Implementiert.
  • Bei Registrierung (Boxen): Geplant.
  • Bei Ticket-Erstellung: Implementiert.
  • Bei Änderung des Boxnamens: Geplant.
• Clientseitige Verschlüsselung mit expliziten Ausnahmen:
  • Clientseitige Verschlüsselung für Standard-Funktionen: In Arbeit, für
    • Registrierung einer Box, Anmeldung an diese, Sperrung und Entsperrung einer Box-Sitzung, Wechsel des Hauptkennworts,
    • Hinterlegungen des Hauptkennworts,
    • Anti-Spam-Kennwörter für Verbindungswünsch,
    • Klartext-Export von Objekten oder ganzen Ordnern,
    • Wiederherstellung von Box-Hauptschlüsseln nach Import von älteren Backups (vor letzter Hauptkennwort-Änderung) oder Neusetzen des Hauptkennworts,
    • Erstellung, Bearbeitung und Erledigung von Tickets,
    • Hauptschlüssel von Gruppencontainern für Gruppengeheimnisse (betrifft vor allem Hinterlegungen im Gruppencontainer),
    • Übertragung von Geheimnissen
    implementiert, für
    Erstellung und Bearbeitung von
    • Kerngeheimnissen und
    • Komponenten
    geplant.
  • Clientseitige Verschlüsselung für HIBP-Abfrage: In Arbeit,
    • In "Extras > HIBP" implementiert,
    • bei der Hauptkennwort-Änderung von Boxen und Tickets implementiert,
    • bei der Geheimnis-Eingabe geplant.
  • Ausnahme für Key-Stretching beim Übergang von serverseitiger zu clientseitiger Verschlüsselung und für langsame Geräte: Implementiert.
  • Ausnahme für Malwarescan von hochgeladenen Dateien: Geplant
  • Ausnahme für Import von Export-Dateien (mit Klartext-Geheimnissen): Implementiert.
  • Ausnahme für Suchfunktion: Implementiert.
  • Abfrage der Genehmigung von der Nutzer*in für Ausnahmen: Prinzipiell implementiert aber noch in Arbeit (z. T. noch provisorische Lösung durch "Blanko-Genehmigung" bei Anmeldung und Registrierung, die durch Einzelgenehmigungen abgelöst werden soll.)
• Löschung der Sitzungsdaten vom Client nach Sitzungsende
  • Vermeidung der Speichung von Geheimnissen im Browser-Cache: Implementiert.
  • Verschlüsselung von Sitzungsdaten des Clients und automatischer Verlust dieses Schlüssels bei Beendigung/Sperrung/Abbruch der Sitzung: Sichergestellt
• Transparenz, welche Daten mit Hauptkennwort verschlüsselt werden: Implementiert.
• Möglichkeit der Benutzer*in, Begleitdaten von Kerngeheimnissen selbst als Kerngeheimnisse einzustufen, d. h. mit dem Hauptkennwort verschlüsseln zu lassen: Implementiert (Benutzer*in kann Struktur von Geheimnissen ändern und eigene Vorlagen erstellen.)
• Kerngeheimnisse und Schlüssel für diese werden, soweit diese noch auf dem Server benötigt werden, jeweils nur solange wie nötig im Klartext gemerkt und auch nur im RAM gehalten. Es ist sichergestellt, dass kein Speicherabzug auf der Platte entstehen kann: Implementiert.
• Begleitdaten von Kerngeheimnissen werden auf dem Server nur im RAM und auf verschlüsselten Platten gehalten (deren Schlüssel beim Hochfahren des Systems von außen her eingegeben wird): Implementiert.