nexenio / kbls-pqc-demonstrator-overview Goto Github PK
View Code? Open in Web Editor NEWSecurity Concept for a PQC Demonstrator
Home Page: https://www.forschung-it-sicherheit-kommunikationssysteme.de/projekte/kbls
License: MIT License
Security Concept for a PQC Demonstrator
Home Page: https://www.forschung-it-sicherheit-kommunikationssysteme.de/projekte/kbls
License: MIT License
Jedes Post-It wird von einem Client (eindeutig) gewählt, dieser generiert eine UUID (die heuristisch eindeutig ist).
Gefahr benennen für die Alternative, dass der Server die ID wählt.
Kontext:
Das Konzept macht nicht klar, woher die ID eines Post-Its kommt, da es nur die Veränderung darstellt. Käme die ID vom Server, kann dieser gezielter Inhalte mehrere Post-Its vertauschen.
Kontext:
key_encryption_key = HKDF(secret1, secret2)
: Welche Inputs sind das? Auf was sind weitere Inputs gesetzt? Soll ,
hier die Konkatenation des Input Key Material (IKM) sein oder wird eins der Geheimnisse etwa in den info
-Paramter geschoben?iv = sha256(board_id)
: Vermutlich wieder getrimmt auf 12 Byte? GCM akzeptiert auch längere IVs als Input, daher ist hier wichtig, dass die Spezifikation konkret ist. Entsprechende Frage stellt sich häufiger im Kontext mit sha256
.encrypted_postit_content = aes256gcm(postit_content, board_key, sha256(postit_id + ts))
stellt sich auch die Frage, was mit postit_id + ts
gemeint ist. Bei Addition oder simpler Konkatenation (10 || 123 == 1 || 0123) kann dies ebenfalls zur Wiederholung des IVs und damit zum fatalen Scheitern von GCM führen.Basierend auf der Version aus Mattermost vom 5.12.22
board_key
neu für den eigentlichem Empfänger verschlüsseln. Weiter kann dem Sender für den einen Empfänger und dem Empfänger für den einen Sender immer der ServerKey ausgegeben werden (also klassischer MitM). Das braucht der Server nur einmal pro board_key
machen, d.h. es ist auch kein wirklich komplexer Split State.
encryption_key
für die verschlüsselten privateKeys des Users wird das user_password
genutzt, dass beim Login auch an den Server gesendet wird. Entsprechend hat der Server auch als passiver Angreifer alle Informationen, um das Board mitzulesen.
encryption_key = pbkdf2(user_password, salt)
user_password
durch den Server oder jemanden, der den Server/die Datenbank kompromittiert. Die anschließende Verschlüsselung encrypted private key = aes256gcm(private key, encryption key, iv)
erlaubt, ebenfalls offline, eine Überprüfung des geratenen Passworts. Ein PAKE, beispielsweise OPAQUE, könnte hier Abhilfe schaffen. Wird hier der serverseitige-OPRF-Schlüssel gemeinsam mit der Passwortdatenbank geleakt, besteht das Problem allerdings trotzdem weiter (der Server kann immer einen Client mit Passwort X simulieren, wenn dessen einziges Geheimnis dieses Passwort ist).info
-Paramter.key_encryption_key = HKDF(secret1, secret2)
: Welche Inputs sind das? Auf was sind weitere Inputs gesetzt? Soll ,
hier die Konkatenation des Input Key Material (IKM) sein oder wird eins der Geheimnisse etwa in den info
-Paramter geschoben?iv = sha256(board_id)
: Vermutlich wieder getrimmt auf 12 Byte? GCM akzeptiert auch längere IVs als Input, daher ist hier wichtig, dass die Spezifikation konkret ist. Entsprechende Frage stellt sich häufiger im Kontext mit sha256
.boardKeyId
geregelt zu sein. Wird dabei geprüft, ob der entsprechende BoardKey zu diesem Board gehört? Ansonsten kann der Server Post-Its von anderen Boards auf dem entsprechenden Board anzeigen. Dies könnte insbesondere problematisch sein, wenn verschiedene Boards unterschiedliche Vertraulichkeitsstufen haben. Szenario: Öffentliche Video-Präsentation eines öffentlichen Boards und der Server zeigt ein Post-It eines vertraulichen Boards an und erfährt den Inhalt über den Video-Stream.encrypted_postit_content = aes256gcm(postit_content, board_key, sha256(postit_id + ts))
stellt sich auch die Frage, was mit postit_id + ts
gemeint ist. Bei Addition oder simpler Konkatenation (10 || 123 == 1 || 0123) kann dies ebenfalls zur Wiederholung des IVs und damit zum fatalen Scheitern von GCM führen.encrypted private key = aes256gcm(private key, encryption key, iv)
genutzt, so könnte der Server gegebenenfalls aus dem Verhalten des Clients (weitergehenden Anfragen vs Abbruch vs neue Anfrage an den Endpunkt) ableiten, ob die Entschlüsselung des private key
funktioniert hat. In dem Fall würden dies wahrscheinlich ein Partitioning Oracle darstellen. Derzeit ist dies kein valider Angriff, da der Server das Passwort bereit Offline angreifen kann (oder sogar passiv beim Login erhält).Kontext:
Wie wird "Passwort vergessen" umgesetzt, sodass der Server diese Funktionalität nicht missbrauchen kann, um einen von ihm kontrollierten Schlüssel zu provisionieren?
"gut genug" mit ausreichend vielen Iterationen (100k+), als Implementierungsdetail anmerken
Anzahl Iterationen muss im Code angepasst werden (aktuell 10k)
Alternativen: OPAQUE, Argon2
Kontext:
user_password
durch den Server oder jemanden, der den Server/die Datenbank kompromittiert. Die anschließende Verschlüsselung encrypted private key = aes256gcm(private key, encryption key, iv)
erlaubt, ebenfalls offline, eine Überprüfung des geratenen Passworts. Ein PAKE, beispielsweise OPAQUE, könnte hier Abhilfe schaffen. Wird hier der serverseitige-OPRF-Schlüssel gemeinsam mit der Passwortdatenbank geleakt, besteht das Problem allerdings trotzdem weiter (der Server kann immer einen Client mit Passwort X simulieren, wenn dessen einziges Geheimnis dieses Passwort ist).encrypted private key = aes256gcm(private key, encryption key, iv)
genutzt, so könnte der Server gegebenenfalls aus dem Verhalten des Clients (weitergehenden Anfragen vs Abbruch vs neue Anfrage an den Endpunkt) ableiten, ob die Entschlüsselung des private key
funktioniert hat. In dem Fall würden dies wahrscheinlich ein Partitioning Oracle darstellen. Derzeit ist dies kein valider Angriff, da der Server das Passwort bereit Offline angreifen kann (oder sogar passiv beim Login erhält).Kontext:
"Will ein Nutzer beispielsweise ein RSA Schlüsselpaar durch ein EC Schlüsselpaar ablösen, wird das aktuelle Kyber-Schlüsselpaar zusammen mit dem neuen EC Schlüsselpaar registriert": Die Folgen sind hier nicht angerissen. Wenn User A von (RSA, Kyber) zu (EC, Kyber) wechselt, wird dann das (RSA, Kyber)-Paar gesperrt? Wie findet das Lesen von an das (RSA, Kyber)-Paar adressierten Ciphertexten statt? Wie wird verhindert, dass neue Ciphertexte für das alte Paar angelegt werden? Wie verhält sich User B mit (RSA, Kyber)-Paar, der bei aKEMs nicht mit dem neuen (EC, Kyber)-Paar interagieren kann?
Kontext:
Die Entschlüsselung eines Post-Its (bzw. zugehörigem Event) scheint über die boardKeyId
geregelt zu sein. Wird dabei geprüft, ob der entsprechende BoardKey zu diesem Board gehört? Ansonsten kann der Server Post-Its von anderen Boards auf dem entsprechenden Board anzeigen. Dies könnte insbesondere problematisch sein, wenn verschiedene Boards unterschiedliche Vertraulichkeitsstufen haben. Szenario: Öffentliche Video-Präsentation eines öffentlichen Boards und der Server zeigt ein Post-It eines vertraulichen Boards an und erfährt den Inhalt über den Video-Stream.
Kontext:
"Technisch lässt sich auch RSA mit EC kombinieren, aber dies hat keinen praktischen Nutzen": Nicht ganz korrekt. Ähnlich wie PQC wäre die Möglichkeit ein Kryptosystem zu kreieren, dass standhält, wenn eines der beiden Verfahren noch sicher ist. Für beide Verfahren ist sicher, dass die nicht post-quanten-sicher sind, aber ein Bruch von RSA ohne signifikante Fortschritte bei der Faktorisierung und entsprechend beim diskreten Logarithmus auf elliptischen Kurver wäre denkbar.
Angriffsszenario beschreiben und ggf. feststellen, dass bei bereits leicht erhöhter Aktivität (3+ Post-Its) der Angriff auffällt
Alternative: CTR + HMAC
Kontext:
Inhaltsdaten sind mit GCM verschlüsselt. GCM ist nicht key-committing, d.h. ein Ciphertext kann unter mehreren Schlüsseln erfolgreich entschlüsselt werden und diese Schlüssel können von einem bösen Angreifer effizient berechnet werden. Dabei steht ein Großteil der anschließend entschlüsselten Nachrichten unter Angreiferkontrolle. Siehe etwa Paper, Paper oder Blog. Das würde einem User erlauben für andere User verschiedene Versionen unter dem gleichen symmetrischen Ciphertext zu erstellen, sodass für User A und User B ein Post-It unterschiedlichen Inhalt hat. Man beachte, dass dies ohne Beteiligung des Servers funktioniert und von diesem nicht erkennbar ist.
info
-Paramter.Kontext:
"gewinnt die Verwendung von Kyber über die Zeit an Sicherheit": Kyber gewinnt nicht an Sicherheit, sondern die Erwartungshaltung gegenüber Kyber wird besser (falls es keine neuen Angriffe gibt).
Derzeit spricht das Konzept von 16 Byte AES-Schlüssellänge: new_board_key = prng(16)
. An sich ist AES mittels Grover's algorithm von Quantencomputer ebenfalls betroffen, jedoch nur quadratisch im Sicherheitsparameter, dh die Suche nach dem korrekten Schlüssel kann in O(2^(n/2)) statt O(2^n) funktionieren. Damit wäre AES-128 "asymptotisch" nicht mehr sicher genug bei einem angestrebten Sicherheitslevel von >=100bit.
Wenn AES-256 performance-technisch einfach gewählt werden kann, dann sollten wir das vermutlich machen. Ansonsten müssten wir nochmal genauer auf die anderen relevanten Faktoren schauen (NIST erwartet, dass AES-128 noch deutlich länger ok ist; Grover ist nicht wirklich parallelisierbar, dh 2^64 ist viel; siehe auch https://crypto.stackexchange.com/questions/102671/is-aes-128-quantum-safe/102672#102672 oder https://security.stackexchange.com/questions/48022/what-kinds-of-encryption-are-not-breakable-via-quantum-computers/48027#48027)
Kontext:
Nicht-Ziele sollten formuliert werden, um die Sicherheitsgarantien des Systems klar zu benennen.
Akzeptiertes Risiko, Schutzziel konkretisieren zu "Integrität jedes einzelnen Post-Its"
Kontext:
Jedes Post-It wird separat verschlüsselt, ohne im Kontext der anderen zu stehen und ohne dessen Metainformationen wie Position festzuhalten. Deshalb kann der Server die Post-Its austauschen, indem er die Positionen ändert. Des Weiteren kann er jeden Post-It unabhängig von den anderen auf einen beliebigen alten Stand bringen, d.h. das Gesamtsystem hat keine Integrität, nur die einzelnen Post-Its für sich alleine.
Kontext:
Im E2EE-Konzept haben Public Links keinen Sinn ergeben. Mit dem neuen Sicherheitsziel von PQ-Sicherheit, sind sie aber durchaus denkbar und sollten konzeptuell eingeführt werden: #24 (comment)
Von der Idee her:
Public Links bedeuten insb., dass der Server die Inhalte jedes Post-Its auf dem nun öffentlichen Board lesen kann. Dies wird wie folgt realisiert: Der Server hat eigenes Board-spezifisches Schlüsselmaterial und wird ins Board eingeladen. Nutzer mit Zugang zum Public Link erhalten Zugriff zum Board-spezifischen Schlüsselmaterial des Servers und damit zu den Inhalten des Boards. Wenn der Public Link deaktiviert wird, entspricht dies dem Workflow für "Zugriffsrechte für ein Board entziehen", wobei hier dem Server Zugriffsrechte entzogen werden. Wir können E2EE in Aussicht stellen und dabei anmerken, dass dann Public Links nicht mehr zweckmäßig sind.
Lösungsansatz: Schutzziel umformulieren von "E2EE / Server kann Daten nicht lesen" zu "externer Angreifer kann Daten nicht lesen, selbst wenn TLS fällt"
Kontext:
Kontext:
"Anschließend verhindert der Server das Hinzufügen von Änderungen, die unter einem anderen Board key verschlüsselt wurden": Das heißt es gibt keine Umschlüsselung für existierende Ciphertexte? Gibt es einen Modus, der dies erlaubt, wenn beispielsweise der alte BoardKey kompromittiert wurde? Heißt das, dass alle alten BoardKeys für neue Nutzer verschlüsselt werden (Prozess zum Teilen des Boards erwähnt nur einen Key)?
Konkrete Bsp. für
Szenario: Alice teilt Schlüsselmaterial mit Bob
Formulierung + API-Spezifikation anpassen.
Kontext:
"Aus der Post-It ID und dem Zeitstempel ergibt sich der IV für die Verschlüsselung des Inhalts" bedeutet, dass wenn 2 Clients gleichzeitig ein Post-It bearbeiten, kann es zur erneuten Nutzung eines Initialisierungsvektors kommen. Re-use vom IV ist unter GCM fatal und ermöglicht die Rekonstruktion des GHASH-Schlüssels und jede Integrität geht verloren.
inputs:
salt
: emptyinfo
: "aes-key"
encoded (UTF-8)secret1 || secret2
: concatenation of byte arraysPrüfen, wo im Konzept dies als Implementierungsdetail angemerkt werden sollte - ggf. auch in der Readme für die Client-Implementierung.
Kontext:
Domain separation für Hashfunktionen, zum Beispiel bei Generierung von IDs oder IVs, sodass gleicher Input nicht zu gleichen Werten führt.
Kontext:
Wie wird das gleichzeitige Entfernen von User X durch User A und Hinzufügen von User Y durch User B gelöst?
Entfernen rotiert den aktuellen BoardKey, aber der neue Schlüssel wird nicht für User Y hinzugefügt, weil Y aus Sicht von A nicht Teil des Boards ist.
Hinzufügen teilt den aktuellen Schlüssel, der User B aber nicht bekannt ist, weil er zeitgleich rotiert wird. Dadurch erhält User Y den Schlüssel weder von A noch B.
Kontext:
Bei der Berechnung des encryption_key
für die verschlüsselten privateKeys des Users wird das user_password
genutzt, dass beim Login auch an den Server gesendet wird. Entsprechend hat der Server auch als passiver Angreifer alle Informationen, um das Board mitzulesen.
Kontext: #22 (comment)
objectId
erklärenA declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.