Entwickler-Ecke
Algorithmen, Optimierung und Assembler - Anonymes, abstreitbares Erlangen von Informationen
BenBE - Fr 06.11.09 13:57
Titel: Anonymes, abstreitbares Erlangen von Informationen
Ich weiß, dass dieser Thread eher weniger mit Programmierung an sich zu tun hat und mehr in die Kategorie Kryptographie fällt, aber da ich die letzten Tage mal einen Blick auf OTR geworfen hab, und die Idee dahinter recht gut finde, kam mir die Idee, soetwas ähnliches als Basis für ein anonymes Netzwerk herzunehmen.
Aber im Detail. Nehmen wir einmal an, es existiert ein geschlossenes, anonymes Netzwerk N mit den Mitgliedern Alice, Bob und Charlie. Die Kommunikation innterhalb dieses Netzwerkes verläuft anonym, aber authentifiziert - d.h. Alice und Bob können mit einander Reden, ohne jedoch die Identität des jeweiligen Gegenüber einem Dritten (z.B. Charlie oder Eve) beweisen zu können. Ferner garantiert dieses Netzwerk auf Grund der verwendeten Protokolle, dass im Nachhinein die gesamte Unterhaltung für keinen der Beteiligten nachvollziehbar ist, und Frank sogar ein gefälschtes Protokoll anfertigen kann. Soweit, so ähnlich zu OTR.
Nun möchte Dave dem Netzwerk von Alice, Bob und Charlie beitreten,
- ohne deren Identität zu kennen
- ohne seine Identität an Eve oder Mallory zu offenbahren (auch in Bezug auf Side-Channel-Angriffe)
und dabei dennoch verifizieren zu können, dass
- er im Netzwerk angekommen ist
Hintergrund: Angenommen, dieses Netzwerk dient dem freien Meinungsaustausch in einem Land, in dem eine Zensur stattfindet. Die Autoritäten dieses Landes überwachen die Kommunikationswege, d.h. dass jegliche gesendeten Informationen einsehbar und gespeichert sind. Das verwendete Protokoll und dessen Implementierung sind öffentlich bekannt. Jegliche hinterlassenen Spuren können daher, wenn sie zugeordnet werden, gegen den Nutzer ausgelegt werden. Zentrale Punkte zum Hinterlegen von Informationen sind daher zu vermeiden.
Wie müsste Daves Vorgehen sein, damit er dem Netzwerk beitreten kann?
Erleichterung: Wir nehmen an, dass die Kryptographischen Primitive (Verschlüsslung, Hashes, RNGs, Steganographie, usw.) von den beteiligten Inividuen ohne Einschränkungen eingesetz werden dürfen.
Disclaimer: Ähnlichkeiten mit real existierenden Personen, Netzwerken oder Ländern sind rein zufällig und unbeabsichtigt.
LexXis - So 08.11.09 11:00
Hm.. Interessante Frage :mrgreen:
Wie würdest du "Identität" definieren? Hatte gerade einen Ansatz im Kopf der auf einem Public Key als einzig bekannter Hinweis auf den Empfänger der jeweiligen Nachricht gegeben ist.
Was mir aber noch Kopfzerbrechen bereitet ist folgendes:
 BenBE hat folgendes geschrieben  : |
| Jegliche hinterlassenen Spuren können daher, wenn sie zugeordnet werden, gegen den Nutzer ausgelegt werden. |
Wie streng ist unser fiktives Regime denn? Können die Teilnehmer schon allein wegen ihrer
Teilnahme am Netzwerk belangt werden, unabhängig davon was für Informationen sie dort getauscht haben?
mfg
Delete - So 08.11.09 12:11
| LexXis hat folgendes geschrieben : |
...Wie streng ist unser fiktives Regime denn? Können die Teilnehmer schon allein wegen ihrer Teilnahme am Netzwerk belangt werden, unabhängig davon was für Informationen sie dort getauscht haben?
mfg |
Davon ist auszugehen!
BTW: Die Mitgliedschaft in einer *** Vereinigung ist strafbar.
Da kann jeder autoritärer Staat, jede Legislative reinschreiben, was ihr passt.
BenBE - So 08.11.09 12:40
| LexXis hat folgendes geschrieben : |
Hm.. Interessante Frage :mrgreen:
Wie würdest du "Identität" definieren? Hatte gerade einen Ansatz im Kopf der auf einem Public Key als einzig bekannter Hinweis auf den Empfänger der jeweiligen Nachricht gegeben ist.
Was mir aber noch Kopfzerbrechen bereitet ist folgendes:
| BenBE hat folgendes geschrieben : | | Jegliche hinterlassenen Spuren können daher, wenn sie zugeordnet werden, gegen den Nutzer ausgelegt werden. |
Wie streng ist unser fiktives Regime denn? Können die Teilnehmer schon allein wegen ihrer Teilnahme am Netzwerk belangt werden, unabhängig davon was für Informationen sie dort getauscht haben?
mfg |
Von dieser Strenge ist durchaus auszugehen. Wie
hathor ja schreibt: **** Vereinigungen usw.
Für den Einstieg können wir aber gerne auch mit vereinfachten Anforderungen beginnen.
| hathor hat folgendes geschrieben : |
| LexXis hat folgendes geschrieben : | ...Wie streng ist unser fiktives Regime denn? Können die Teilnehmer schon allein wegen ihrer Teilnahme am Netzwerk belangt werden, unabhängig davon was für Informationen sie dort getauscht haben?
mfg |
Davon ist auszugehen!
BTW: Die Mitgliedschaft in einer *** Vereinigung ist strafbar.
Da kann jeder autoritärer Staat, jede Legislative reinschreiben, was ihr passt. |
Ich sagte ja: Ähnlichkeiten mit real existierenden Staaten sind rein zufällig...
Bliebe aber immer noch der Punkt, wie man in einem überwachten Netz Information erlangen kann, ohne dass jemand, der meine Kommunikation mitschneidet, belastbare Informationen darüber erhält, dass ich z.B. zu einem Darknet Kontakt aufnehme. Die Side-Channel-Angriffe sind in solch einer Umgebung das gefährlichere ...
LexXis - Mo 09.11.09 21:47
Puh, haarige Angelegenheit :(
Um das Ganze etwas in Gang zu halten poste ich hier einfach mal meine erste Idee und die Lücken, die sich noch in ihr befinden. Evtl kann ja jemand ergänzen, um diese zu schließen.
Grundsätzliches:
- Gegeben ist eine Menge von Knoten, die sich untereinander kennen (IP-basiert).
- Jeder Teilnehmer besitzt ein asymetrisches Schlüsselpaar
- Versendete Pakete haben eine feste Größe, um diese als Ansatz zur Paketverfolgung / -identifikation auszuschließen.
- Im Paketheader befindet sich ein TTL-Feld, welches vor jeder Übertragung um 1 reduziert wird. Ist TTL bei 0 wird das Paket verworfen.
- Will ein Knoten einem anderen Daten senden, so fordert er davor von diesem einen anderen, zufälligen Schlüssel zur asymetrischen Verschlüsselung an.
Zur Kommunikation zwischen zwei Konten: Alice möchte eine Nachricht an Bob versenden
- Alice ist im Besitz von Bobs öffentlichem Schlüssel und
- verschlüsselt damit die Nachricht.
- Von seinen bekannten Knoten Charlie, Eve und Florence fordert er jeweils einen temporären Schlüssel an,
- verschlüsselt den Paketheader und Bobs Nachricht damit und
- sendet diese Pakete an die Drei.
- Diese entschlüsseln das Paket mit dem temporären Schlüssel und die Nachricht noch einmal mit ihrem private key.
- Sie stellen fest, dass sie mit der Nachricht nichts anfangen können (diese ist nur für Bob lesbar!) und
- versenden nach dem selben Procedere Header und Nachricht wiederum an all ihre Bekannten.
Irgendwann sollte das Paket bei Bob angekommen sein. Dieser kann die Nachricht problemlos entschlüsseln, da er den richtigen private key besitzt. Um jedoch keinen Verdacht aufkommen zu lassen, verschickt er das Paket auch selbst weiter.
Wie bereits erwähnt handelt es sich hierbei nur um einen groben Abriss. Beim Anfordern der temporären Schlüssel ist das System anfällig für MITM-Angriffe, es erfordert massiv Rechenzeit beim ständigen Erstellen selbiger und ist aufgrund des Mangels an Routing höhst ineffizient. Gerade hier liegt jedoch eine der Stärken: Es ist von außen nicht ersichtlich, wer der Empfänger war. Angesichts der drohenden Side-Channel-Attacken verflüchtigt sich dieser Punkt aber auch recht schnell wieder.
| hathor hat folgendes geschrieben : |
BTW: Die Mitgliedschaft in einer *** Vereinigung ist strafbar.
Da kann jeder autoritärer Staat, jede Legislative reinschreiben, was ihr passt. |
Ich nehme mal an, dass besagter Staat auch was dagegen hat, wenn man offenkundig Datenmüll (=verschlüsselte Daten) durch seine Infrastruktur jagt ;) Von daher wird mein jetziger Ansatz wohl in keinster Weise BenBEs Rahmenbedingungen gerecht.
Aber das Thema ist einfach zu spannend, um nicht dazu beizutragen :)
BenBE, schwebt dir schon was vor? Wie wäre es mit in Bildern versteckten Daten (Steganographie) in einem Imageboard a la /b/?
mfg
BenBE - Mo 09.11.09 23:26
| LexXis hat folgendes geschrieben : |
Puh, haarige Angelegenheit :(
Um das Ganze etwas in Gang zu halten poste ich hier einfach mal meine erste Idee und die Lücken, die sich noch in ihr befinden. Evtl kann ja jemand ergänzen, um diese zu schließen. |
Das ist doch immerhin schon mal ein Ansatz; beschreibt aber die Arbeitsweise innerhalb des Netzwerkes nicht ganz. Zum besseren Verständnis, wie man ohne mehr als nötig Overhead zu produzieren Daten senden kann, würde ich einen Blick in Richtung Onion Routing bzw. Garlic Routing werfen. Dazu aber gleich mehr.
| LexXis hat folgendes geschrieben : |
Grundsätzliches:
- Gegeben ist eine Menge von Knoten, die sich untereinander kennen (IP-basiert).
|
Nicht wirklich anonym ...
Beispiel: Bei I2P kennen die Knoten zwar untereinander auch ihre IP, die Kommunikation läuft aber nicht über die IP, sondern über die Knoten-IP. Insbesondere muss dem Absender einer Nachricht nicht bekannt sein, welche IP der Empfänger hat. Dies sollte auch wenn möglich nicht auf direktem Wege über das Netzwerk ermittelbar sein. Man braucht zwar die IP, um einen anderen Knoten zu erreichen, es reicht aber, wenn jeder Knoten eine kurze Liste von Knoten überhaupt kennt (mit deren ID), um mit diesen zu reden.
| LexXis hat folgendes geschrieben : |
| Jeder Teilnehmer besitzt ein asymetrisches Schlüsselpaar |
Jeder Teilnehmer besitzt ein asymmetrisches Schlüsselpaar sowie eine Knoten-ID. Beide müssen nichts gemeinsam haben; sollten sogar wenn möglich aus verschiedenen Quelldaten generiert worden sein.
| LexXis hat folgendes geschrieben : |
| Versendete Pakete haben eine feste Größe, um diese als Ansatz zur Paketverfolgung / -identifikation auszuschließen. |
Der Satz erscheint mir grad unlogisch, da eine feste Paketgröße ein Identifikationsmerkmal der Pakete wäre. Viel mehr würde ich vorschlagen, eine Mischung aus OTR und dem RC4-160-Enc-Protokoll von Vuze zu sprechen: OTR garantiert die (Weak) Deniability, während das Protokoll von Vuze dafür sorgt, dass die Daten für DPI "unsichtbar" werden. Auch hierzu sollte man aber ggf. später noch mehr erklären.
| LexXis hat folgendes geschrieben : |
| Im Paketheader befindet sich ein TTL-Feld, welches vor jeder Übertragung um 1 reduziert wird. Ist TTL bei 0 wird das Paket verworfen. |
Vgl. mit I2P: TTL wird für Ausgangswert nur in X% der Fälle dekrementiert, um zu verhindern, dass der erste Knoten sich sicher sein kann, wer die Quelle des Pakets ist.
| LexXis hat folgendes geschrieben : |
Will ein Knoten einem anderen Daten senden, so fordert er davor von diesem einen anderen, zufälligen Schlüssel zur asymetrischen Verschlüsselung an.
|
Siehe Key Exchange Protokoll von OTR. In einem solchen, anonymen System sollte die Lebensdauer von Schlüsseln möglichst kurz sein.
| LexXis hat folgendes geschrieben : |
Zur Kommunikation zwischen zwei Konten: Alice möchte eine Nachricht an Bob versenden
- Alice ist im Besitz von Bobs öffentlichem Schlüssel und
|
k, nehmen wir jetzt mal an, Möglichkeiten, wie Alice da ran kommt, könnten später diskutiert werden.
| LexXis hat folgendes geschrieben : |
| verschlüsselt damit die Nachricht. |
Bitte bei OTR in den Design Goals nachlesen, warum DAS eine ganz schlechte Idee ist.
Besser: Alice handelt mit Bob eine Kommunikationssitzung über ein OTR-ähnliches Protokoll aus. Dabei wird (im Gegensatz zu OTR) ein asymmetrischer Schlüssel generiert (von dem Alice UND Bob beide Teile kennen*)
*Ja, das mein ich ernst :P Grund: OTR nutzt AES128-CTR für die Verschlüsslung, was durchaus reicht, ABER da es symmetrisch verschlüsselt ist, sofort bei Bekanntgabe des Symmetrischen Schlüssels den Plaintext verriete. Mit einem Assymetrischen Schlüsselpaar kann Florence ein gefälschtes Transcript anfertigen, was vollkommen gültig ist UND korrekt validiert werden kann (vgl. OTR).
| LexXis hat folgendes geschrieben : |
Von seinen bekannten Knoten Charlie, Eve und Florence fordert er jeweils einen temporären Schlüssel an,
verschlüsselt den Paketheader und Bobs Nachricht damit und
sendet diese Pakete an die Drei. |
Vorschlag: Hier machen wir Garlic Routing: Er leitet generell sowieso Pakete weiter und streut sein Paket nur in den Datenstrom mit ein.
| LexXis hat folgendes geschrieben : |
| Diese entschlüsseln das Paket mit dem temporären Schlüssel und die Nachricht noch einmal mit ihrem private key. |
Garlic Routing, vgl. I2P.
| LexXis hat folgendes geschrieben : |
| Sie stellen fest, dass sie mit der Nachricht nichts anfangen können (diese ist nur für Bob lesbar!) und |
Und haben Bandbreite verschwendet ;-)
| LexXis hat folgendes geschrieben : |
versenden nach dem selben Procedere Header und Nachricht wiederum an all ihre Bekannten.
|
Da ist Garlic Routing wirklich effizienter ;-) Zumal man bei Garlic Routing auch Chaffing and Winnowing einsetzen könnte.
| LexXis hat folgendes geschrieben : |
| Irgendwann sollte das Paket bei Bob angekommen sein. Dieser kann die Nachricht problemlos entschlüsseln, da er den richtigen private key besitzt. Um jedoch keinen Verdacht aufkommen zu lassen, verschickt er das Paket auch selbst weiter. |
Entfällt IMHO bei Garlic Routing, auch wenn man es einbauen könnte - wäre aber Traffic-Verschwendung.
| LexXis hat folgendes geschrieben : |
| Wie bereits erwähnt handelt es sich hierbei nur um einen groben Abriss. Beim Anfordern der temporären Schlüssel ist das System anfällig für MITM-Angriffe, es erfordert massiv Rechenzeit beim ständigen Erstellen selbiger und ist aufgrund des Mangels an Routing höhst ineffizient. |
Jap. Wurde bei I2P bereits besser gelöst, weshalb ich das für Netz-Interne Kommunikation bevorzugen würde.
| LexXis hat folgendes geschrieben : |
| Gerade hier liegt jedoch eine der Stärken: Es ist von außen nicht ersichtlich, wer der Empfänger war. |
Doch: Einer der vier, von denen Alice einen temporären Key angefordert hat. Und das ist, dank Paket-Vorratsdatenspeicherung durchaus nachvollziehbar.
| LexXis hat folgendes geschrieben : |
| Angesichts der drohenden Side-Channel-Attacken verflüchtigt sich dieser Punkt aber auch recht schnell wieder. |
Erklärung zu diesem Punkt bitte?
| LexXis hat folgendes geschrieben : |
| hathor hat folgendes geschrieben : |
BTW: Die Mitgliedschaft in einer *** Vereinigung ist strafbar.
Da kann jeder autoritärer Staat, jede Legislative reinschreiben, was ihr passt. |
Ich nehme mal an, dass besagter Staat auch was dagegen hat, wenn man offenkundig Datenmüll (=verschlüsselte Daten) durch seine Infrastruktur jagt ;) Von daher wird mein jetziger Ansatz wohl in keinster Weise BenBEs Rahmenbedingungen gerecht.
Aber das Thema ist einfach zu spannend, um nicht dazu beizutragen :) |
Och, da kann der Staat leider nicht viel machen, da:
1. Das Verbieten von Kryptographie nichts bringt (vgl. Chaffing and Winnowing)
2. Viele kryptographische Primitiva (z.B. Hashes, HMACs) essentiell für das Funktionieren der Infrastruktur sind.
ABER: Er kann einschränken, WELCHE kryptographischen Primitiva genutzt werden dürften (vgl. Frankreich bis Mitte der 1990er.
| LexXis hat folgendes geschrieben : |
| BenBE, schwebt dir schon was vor? Wie wäre es mit in Bildern versteckten Daten (Steganographie) in einem Imageboard a la /b/? |
Selbst wenn /b/ eine Möglichkeit darstellen würde, würde Steganographie hier nicht viel bringen (vgl. oben: Der Source ist offen).
Wem die beiden Begriffe Onion Routing und Garlic Routing nix sagen:
Onion Routing: Alice verschlüsselt Datenpaket an Bob der Reihe nach an Bob, Charlie, Dave, Eve, Florence, Trent, Vera und sendet es an Vera. Vera an Trend, usw. U.a. bei Tor eingesetzt (Daher der Name :P)
Garlic Routing: Datenpaket an Bob ist mit einem Session-Schlüssel verschlüsselt. Zusätzlich wird Point-to-Point zwischen Charlie, Dave, Eve, Florence, Trend und Vera der jeweilige Hop mit dem Next-Hop-Schlüssel gesichert. Bei jedem Hop werden aber ANDERE Datenpakete (oder Fragmente) mit Bobs Paket zusammen in einer Hülle gepackt. (Bei I2P eingesetzt).
Ach ja, zum Thema Vuze-Protokoll und Verschleierung, eine Grobfassung:
Vuze nutzt für die Aushandlung eines Session-Keys ein modifiziertes DH-Kex, bei dem beide Parteien am Anfang der Verbindung eine vorgegebene Menge an "Zufallsdaten" senden, gefolgt von einer zufälligen Menge Datenmüll, der ignoriert wird. Da beide Parteien ein "Shared Secret" haben (meist der Torrent-Hash), können beide nach der Übertragung des Datenmülls Problemlos wieder in den Datenstrom der Gegenseite synchronisieren. Problem bei Vuze ist dabei, dass das Verfahren für MITM anfällig ist. Hier bessert aber OTR mit seinem Protokoll recht gut nach, da bei OTR anhand der Schlüssel zusätzlich Authentifiziert wird. Da empfehl ich für Details einfach mal einen Blick in die beiden Specs, die lesen sich beide recht angenehm (im Vgl. zu anderen crypt. Doc).
Um die Frage dieses Threads scheinen wir uns aber irgendwie noch zu drücken :mrgreen:
Delete - Mo 09.11.09 23:57
Ich gehe davon aus, dass ein autoritärer Staat nur den Datenverkehr zulässt, den er kontrollieren, d.h. "verstehen" kann. Alles Andere wird herausgefiltert.
BenBE - Di 10.11.09 00:02
| hathor hat folgendes geschrieben : |
| Ich gehe davon aus, dass ein autoritärer Staat nur den Datenverkehr zulässt, den er kontrollieren, d.h. "verstehen" kann. Alles Andere wird herausgefiltert. |
Tor sieht nach außen wie SSL aus, ist's aber nicht ;-) Nur so BTW.
Wenn man das aber ins Extreme treibt: Ja ^^
Ich geh aber für diese Frage mal davon aus, dass wir ein neutrales Netz haben, in dem jedoch alle Kommunikation protokolliert wird. Wenn man dafür nämlich eine Lösung hat, ist die Folgerung für restriktivere Systeme nämlich relativ einfach vollziehbar.
Sirke - Di 10.11.09 01:37
Was verstehst du genau unter Anonymität und gleichzeitiger Authentizität der Teilnehmer? Welche Eigenschaften SOLLEN geschaffen werden?
Grundsätzlich sind OTPs bzw Stromchiffren und MACs dazu in er Lage abstreitbar Daten zu verschlüsseln und deren Autentizität und Integrität zu schützen. DH in Verbindung mit Signaturen schaffen am Protokollbeginn die nötigen symmetrischen Schlüssel und ein authentisches Gespräch. Für eine anonyme Kommunikation kann man zudem noch Coverd-Channels nutzen.
Ich finde das Thema sehr interessant und habe viele Ideen und würde daher gerne weiter mit diskutieren?!
BenBE - Di 10.11.09 08:09
| Sirke hat folgendes geschrieben : |
| Was verstehst du genau unter Anonymität und gleichzeitiger Authentizität der Teilnehmer? Welche Eigenschaften SOLLEN geschaffen werden? |
Anonymität: Es ist nicht (gezielt) möglich, eine Zuordnung von Kommunikations-IDs zu realen (Side-Channel-)Daten herzustellen
Authentizität: Es ist sichergestellt, dass wenn Alice mit Bob reden möchte, beide Parteien feststellen können, dass sie mit dem jeweils anderen reden, OHNE dies gegenüber einem anderen beweisen zu können.
| Sirke hat folgendes geschrieben : |
| Grundsätzlich sind OTPs bzw Stromchiffren und MACs dazu in er Lage abstreitbar Daten zu verschlüsseln und deren Autentizität und Integrität zu schützen. |
ACK.
| Sirke hat folgendes geschrieben : |
| DH in Verbindung mit Signaturen schaffen am Protokollbeginn die nötigen symmetrischen Schlüssel und ein authentisches Gespräch. |
Wobei man bei Signaturen vorsichtig sein sollte bzgl. Abstreitbarkeit, da Signaturen u.U. auch die Identität nicht nur für den Empfänger, sondern für alle Beteiligten offenbaren. HMACs dürften da hier besser sein.
| Sirke hat folgendes geschrieben : |
| Für eine anonyme Kommunikation kann man zudem noch Coverd-Channels nutzen. |
Details?
| Sirke hat folgendes geschrieben : |
| Ich finde das Thema sehr interessant und habe viele Ideen und würde daher gerne weiter mit diskutieren?! |
Dann immer zu ;-)
Sirke - Di 10.11.09 12:46
| BenBE hat folgendes geschrieben : |
| Anonymität: Es ist nicht (gezielt) möglich, eine Zuordnung von Kommunikations-IDs zu realen (Side-Channel-)Daten herzustellen |
Okay, dies bedeutet aber, dass man einen Anonymisierungsdienst benötigt, da man sonst (1) die IP-Adressen zuordnen kann und (2) sogar die Kommunikation beider oder mehrere Adressen verbinden kann. Generell ist die Verlinkbarkeit die größte Hürde, weil nur Redundanz dies in einem größeren Maß verhindern kann. Eine mögliche Lösung wäre, dass jede Partei
n Pakete mit verschiedenen IDs an einen zentralen Punkt sendet und dort jede Partei
k Pakete abholt, wovon nur ein Paket das gewünscht ist und alle anderen Pakete nur zufälliger Datenmüll. Wobei auch dies nicht das Problem vollständig löst, weil Onlinezeiten und Abrufzeiten eine Verbindung ermöglichen.
| BenBE hat folgendes geschrieben : |
| Authentizität: Es ist sichergestellt, dass wenn Alice mit Bob reden möchte, beide Parteien feststellen können, dass sie mit dem jeweils anderen reden, OHNE dies gegenüber einem anderen beweisen zu können. |
Diesen Punkt habe ich schon oft mit Komilitonen diskutiert, weil wenn beide einander beweisen, dass sie miteinander kommunizieren, kann jede Partei diesen Beweis anderen vorlegen und damit dies auch anderen beweisen. Dieses Problem besteht nämlich bei der Voraussetzung "KÖNNEN", weil dies einen unehrlichen Kommunnikationspartner als Möglichkeit enthält, der alle seine geheimen Schlüssel offen legt.
| BenBE hat folgendes geschrieben : |
| Wobei man bei Signaturen vorsichtig sein sollte bzgl. Abstreitbarkeit, da Signaturen u.U. auch die Identität nicht nur für den Empfänger, sondern für alle Beteiligten offenbaren. HMACs dürften da hier besser sein. |
Auf jeden Fall sind symmetrische Verfahren besser geeignet, weil hierbei die andere Partei immer eine Fälschung erstellen kann und somit eine Abstreitbarkeit gegeben bleibt. Gleichzeitig muss jedoch jede Partei mit allen Kommunikationspartnern einen symm. Schlüssel teilen, was ein großen Problem bereitet. Daher bräuchte man eher asymm. Krypto.
ODER: Gibt es eine Möglichkeit einen DH Schlüsselaustausch in irgend einer Weise abzusichern OHNE dass ein Langzeitschlüssel benötigt wird? Die Folge wäre jedoch wieder, dass man keine Zusicherung schaffen kann, mit wem man Kommuniziert.
| BenBE hat folgendes geschrieben : |
| Details? |
Coverd-Channels sind ja grundsätzlich Kanäle, welche in andere Kanäle eingebettet werden. So soll/wird bei Online-Rollenspielen in den Nutzdaten vertrauliche/geheime Informationen versendet, indem Steganogrphie zum Einsatz kommt. Hierbei könnte man ähnliches machen:
Eine Partei sendet ein
k-fach verschlüsseltes Paket (mit
k verschiedenen öffentlichen Schlüsseln) an eine Partei, welche die äußere Hülle abnimmt und dort die Infos zum Weitersenden findet. In irgendeiner "Schale" befindet sich dann ein eingebettetes Paket, wovon die Partei weiß und diese extrahiert und die "Schalen" weitersendet:
Mit
E(PKi,m) sein eine Verschlüsselung mit einem öffentlichen Schlüssel von
i der Nachricht
m gemeint und + bezeichnet eine Verknüpfung irgendeiner Form:
Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
| E(PK1, E(PK2, E(PK3, E(PK4, E(PK5, E(PK6, m' ) ) ) + m ) ) ) = C
1.) C an 1 senden:
D(SK1, C ) = E(PK2, E(PK3, E(PK4, E(PK5, E(PK6, m' ) ) ) + m ) ) = C
2.) C an 2 senden:
D(SK2, C ) = E(PK3, E(PK4, E(PK5, E(PK6, m' ) ) ) + m ) = C
3.) C an 3 senden:
D(SK3, C ) = E(PK4, E(PK5, E(PK6, m' ) ) ) + m = C
-> Er weiß von der Nachricht und kann diese extrahieren:
Ex( C ) = m
4.) C an 4 senden:
D(SK4, C ) = E(PK5, E(PK6, m' ) ) = C
.
.
. |
EDIT: Folgenden Kreis könnte man sich in der Schalen-Verkapselung vorstellen, indem das Paket wieder beim Absender X ankommt. In weiteren Kreisläufen kann dann Y in diese Pakete seine Nachricht an X anfügen:
Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
| /-O------O--\
/ \-----Y--\
| |
O |
\---O\ O
\ |
O |
\---X------O---O-/ |
BenBE - Di 10.11.09 13:06
| Sirke hat folgendes geschrieben : |
| BenBE hat folgendes geschrieben : | | Anonymität: Es ist nicht (gezielt) möglich, eine Zuordnung von Kommunikations-IDs zu realen (Side-Channel-)Daten herzustellen |
Okay, dies bedeutet aber, dass man einen Anonymisierungsdienst benötigt, da man sonst (1) die IP-Adressen zuordnen kann und (2) sogar die Kommunikation beider oder mehrere Adressen verbinden kann. Generell ist die Verlinkbarkeit die größte Hürde, weil nur Redundanz dies in einem größeren Maß verhindern kann. Eine mögliche Lösung wäre, dass jede Partei n Pakete mit verschiedenen IDs an einen zentralen Punkt sendet und dort jede Partei k Pakete abholt, wovon nur ein Paket das gewünscht ist und alle anderen Pakete nur zufälliger Datenmüll. Wobei auch dies nicht das Problem vollständig löst, weil Onlinezeiten und Abrufzeiten eine Verbindung ermöglichen. |
Garlic Routing. Angriff dabei sind Vloume\Timing-Attacken, aber das kann man recht gut eingrenzen.
| Sirke hat folgendes geschrieben : |
| BenBE hat folgendes geschrieben : | | Authentizität: Es ist sichergestellt, dass wenn Alice mit Bob reden möchte, beide Parteien feststellen können, dass sie mit dem jeweils anderen reden, OHNE dies gegenüber einem anderen beweisen zu können. |
Diesen Punkt habe ich schon oft mit Komilitonen diskutiert, weil wenn beide einander beweisen, dass sie miteinander kommunizieren, kann jede Partei diesen Beweis anderen vorlegen und damit dies auch anderen beweisen. Dieses Problem besteht nämlich bei der Voraussetzung "KÖNNEN", weil dies einen unehrlichen Kommunnikationspartner als Möglichkeit enthält, der alle seine geheimen Schlüssel offen legt. |
Authentifizierung nicht mit einer Signatur, sondern mit einem HMAC. Damit kann man die Authentizität zwar nachweisen, aber nicht beweisen, weil man selber ja den Schlüssel auch hat und daher das Paket fälschen könnte. Vgl. Auth bei OTR.
| Sirke hat folgendes geschrieben : |
| BenBE hat folgendes geschrieben : | | Wobei man bei Signaturen vorsichtig sein sollte bzgl. Abstreitbarkeit, da Signaturen u.U. auch die Identität nicht nur für den Empfänger, sondern für alle Beteiligten offenbaren. HMACs dürften da hier besser sein. |
Auf jeden Fall sind symmetrische Verfahren besser geeignet, weil hierbei die andere Partei immer eine Fälschung erstellen kann und somit eine Abstreitbarkeit gegeben bleibt. Gleichzeitig muss jedoch jede Partei mit allen Kommunikationspartnern einen symm. Schlüssel teilen, was ein großen Problem bereitet. Daher bräuchte man eher asymm. Krypto. |
Bzw. eine Mischung daraus. Oft wird zur Lösung dieses Problems mit vielen kleinen Session-Schlüsseln gearbeitet, was die Arbeit stark erleichtert.
| Sirke hat folgendes geschrieben : |
| ODER: Gibt es eine Möglichkeit einen DH Schlüsselaustausch in irgend einer Weise abzusichern OHNE dass ein Langzeitschlüssel benötigt wird? Die Folge wäre jedoch wieder, dass man keine Zusicherung schaffen kann, mit wem man Kommuniziert. |
Spannende Frage. Soweit ich das bisher gesehen hab: Jain. OTR authentifiziert seinen DH-like Kex mit einem Public Key, ohne dass dieser für Dritte beweisbar ist. Dürfte also da durchaus Möglichkeiten geben.
| Sirke hat folgendes geschrieben : |
| BenBE hat folgendes geschrieben : | | Details? |
Coverd-Channels sind ja grundsätzlich Kanäle, welche in andere Kanäle eingebettet werden. So soll/wird bei Online-Rollenspielen in den Nutzdaten vertrauliche/geheime Informationen versendet, indem Steganogrphie zum Einsatz kommt. Hierbei könnte man ähnliches machen:
Eine Partei sendet ein k-fach verschlüsseltes Paket (mit k verschiedenen öffentlichen Schlüsseln) an eine Partei, welche die äußere Hülle abnimmt und dort die Infos zum Weitersenden findet. In irgendeiner "Schale" befindet sich dann ein eingebettetes Paket, wovon die Partei weiß und diese extrahiert und die "Schalen" weitersendet:
Mit E(PKi,m) sein eine Verschlüsselung mit einem öffentlichen Schlüssel von i der Nachricht m gemeint und + bezeichnet eine Verknüpfung irgendeiner Form:
Quelltext 1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
| E(PK1, E(PK2, E(PK3, E(PK4, E(PK5, E(PK6, m' ) ) ) + m ) ) ) = C
1.) C an 1 senden:
D(SK1, C ) = E(PK2, E(PK3, E(PK4, E(PK5, E(PK6, m' ) ) ) + m ) ) = C
2.) C an 2 senden:
D(SK2, C ) = E(PK3, E(PK4, E(PK5, E(PK6, m' ) ) ) + m ) = C
3.) C an 3 senden:
D(SK3, C ) = E(PK4, E(PK5, E(PK6, m' ) ) ) + m = C
-> Er weiß von der Nachricht und kann diese extrahieren:
Ex( C ) = m
4.) C an 4 senden:
D(SK4, C ) = E(PK5, E(PK6, m' ) ) = C
.
.
. | |
Das wäre eine Idee, funktioniert im konkreten Fall doch aber nicht, wenn jemand frisch ins Netzwerk joinen möchte?
Delphi-Laie - Di 10.11.09 13:36
Mein Ansinnen ist es nicht, diese interessante Diskussion zu torpedieren, erlaube mir aber, sie als ziemlich akademisch einzustufen.
Es wäre nämlich völlig inkonsequent, daß ein Staat massive Überwachung, Zensur und Repression auf der einen Seite betriebe, jedoch eine kryptische Tarnung in Informationsnetzwerken auf der anderen Seite zuließe.
Nur mal zwei Beispiele: Das sog. Vermummungsverbot in der BRD (wo sonst noch?) und das ernsthafte Ansinnen der USA, Computer ohne Palladium zu verbieten, dienen nur dazu, den Ermittlungsaufwand zu minimieren und die Ermittlungswahrscheinlichkeit zu maximieren. Gut, der sog. Palladiumcomputer war vor allem erst einmal kommerziellen Bedürfnissen gechuldet, hätte aber auch die totale Überwachung(smöglichkeit) nach sich gezogen. Zum Glück hat sich das erst einmal wieder zerschlagen.
Die Vorratsdatenspeicherung zeigt doch klar, wohin der Weg geht: Zur totalen Überwachung, die Orwell literarisch prognostizierte - eine total(itär)e Diktatur wird die Spätfolge, die finale Konsequenz dieser Entwicklung und dieses Begehren sein.
Die Stasi 2.0, die hierzulande längst gang und gäbe ist (und mit ihren technischen Möglichkeiten die Stasi 1.0 in den Schatten stellt und diese im nachhinein neidisch werden läßt), hat ja ihr Haupteinsatzfeld längst im Bereich der elektronischen (Massen-)Kommunikation. Man wird sich doch selbst den Sitzast nicht absägen...?!
Sirke - Di 10.11.09 13:37
| BenBE hat folgendes geschrieben : |
| Das wäre eine Idee, funktioniert im konkreten Fall doch aber nicht, wenn jemand frisch ins Netzwerk joinen möchte? |
Auf jeden Fall nicht ohne großen Overhead! Entweder man hat IMMER einen vollständigen Ring um alle teilnehmenden Parteien, was jedoch dazu führen kann, dass die Wege und Zeiten sehr lang werden.
Eine andere Lösung wären viele kleine Ringe: Alice hat einen Ring mit
n (vllt so um die 10) Parteien und kommuniziert in diesem Ring mit Bob. Carol die deren Kommunikation beitreten möchte bildet nun einen Ring mit Bob und/oder Alice und einer von beiden dient als Verteiler der Teilnehmer in seinem Ring. Eine Verbesserung wäre evtl eine Veröffentlichung alle bestehenden Ringe, sodass Carol einen Ring über mehrere Parteien in dem Ring aufbauen kann, sodass ein Schnittpunkt nicht ermittelt werden kann.
Auch könnte man alle Ringe über einen zentralen Dienst laufen lassen, sodass eben dier Verteiler immer der selbe ist. Leider hat man dann wieder den Single-Point-of-Failure. Für diesen Fall kann aber immernoch eine Notfalllösung mit vielen kleinen Ringen als Ersatz folgen!
Das Problem hinter einer solchen Struktur ist es auszuschließen, dass Verbindungen mit Hilfe von Schnittpunkten der Ringe o.ä. erkannt werden können.
EDIT:
@Delphi-Laie: Klar ist diese Frage rein theoretisch und hätte in vielen Fällen durch die Krypto Probleme, aber dann könnte man das ganze von einer Massangerstruktur zu einer Forenstuktur verändern und dann mit Steganographi die gesamte Kommunikation im Verborgenen halten! Dies schafft nur die Grundlage falls das Verborgene gefunden wird keinen Grund für einen Beweis zu schaffen! ... aber um Rechtslagen zu verwendeter Software geht es hierbei nicht, sondern um Möglichkeiten durchzuspielen.
BenBE - Di 10.11.09 14:10
Ich denke mal, die Möglichkeiten für die Kommunikation innerhalb des Netzwerkes sind eigentlich eher sekundär, da es hier bereits (Speziell für geschlossene Netzwerke / Darknets) recht gute Lösungen gibt. Klar, man kann hier mit verschiedenen Teilnetzen operieren, aber praktisch ist das nur bedingt.
Zumal: Nehmen wir einmal die Authentifizierung. Reicht es nicht, wenn man für einen Schlüssel folgendes weiß:
Festlegung:
- Eine Identität besteht aus einem key (asymm.), einer ID (Hash)
- Zu einer Identität können 0 bis * Locations zugeordnet sein (Multihomed-Systeme z.B., aber das ist hier unwichtig)
- Die ID einer Identität ist HMAC, den jeder Node für sich beliebig ändern kann, solange er die history seiner früheren Knoten-IDs reproduzieren kann
- Zur Bestimmung der Identität der Gegenstelle werden Zero Knowledge-Proofs verwendet, die basierend auf privaten Informationen des Empfängers die Identität (ausschließlich für die Kommunikationspartner) offenlegen können.
Wenn nun Alice mit Bob reden möchte, kann Alice ALLE bisherigen IDs von Bob verwenden, und dieser kann sich Authentifizieren, indem er nach einem Key-Exchange-Verfahren und einem Festlegungs-Verfahren (Bob muss vor der Bekanntgabe der neuen ID, diese an Alice unveränderbar bekanntgeben) Alice beweist, dass er Informationen hat, mit der er neue (Sitzungs-)Schlüssel aus seinem Private Key erzeugen kann.
@Sirke: Ein Ring ist nicht wirklich dezentral und zudem skaliert das nicht ;-) P2P allerdings schon ;-)
Sirke - Di 10.11.09 18:59
Die idee klingt nicht schlecht, aber wenn wir schon asymm Krypto nutzen und mit einem HMAC individuelle IDs generieren, dann kann man doch eher folgende Variante nehmen:
Man definiere eine Primzahl p und zufällig x aus Z_p*, sowie g und h Generatoren aus Z_p*. Der geheime Schlüssel ist dann x und der öffentliche y = g^x * h^r mod p, wobei r zufällig aus Z_p*. Hierbei kann jedes r einen neuen öffentlichen Schlüssel erzeugen, welcher gleichzeitig die ID ist bzw der gehasht die ID ist.
Mittels deiner Idee des Zero-Knowlege Proofs kann der Besitzer die Kenntnis von x und r beweisen und damit die Zugehörigkeit zu diesem Schlüssel. Gleichzeitig kann man mit diesen Werten einen DH absichern, indem man die DH Werte signiert. Evtl kann man auch ohne DH aus den beiden öffentlichen Schlüsseln einen SessionKey berechnen...
BenBE - Di 10.11.09 22:50
| Sirke hat folgendes geschrieben : |
Die idee klingt nicht schlecht, aber wenn wir schon asymm Krypto nutzen und mit einem HMAC individuelle IDs generieren, dann kann man doch eher folgende Variante nehmen:
Man definiere eine Primzahl p und zufällig x aus Z_p*, sowie g und h Generatoren aus Z_p*. Der geheime Schlüssel ist dann x und der öffentliche y = g^x * h^r mod p, wobei r zufällig aus Z_p*. |
Das sieht mir jetzt aber verdammt nach ECC aus ;-) Ginge sicherlich auch, ist im Endeffekt aber doch sicherlich eher ein reines Implementationsdetail ;-)
| Sirke hat folgendes geschrieben : |
| Hierbei kann jedes r einen neuen öffentlichen Schlüssel erzeugen, welcher gleichzeitig die ID ist bzw der gehasht die ID ist. |
Hmmm, klingt interessant. Ich sehe: Im Netzwerk kommunizieren wäre schon mal erledigt ;-)
| Sirke hat folgendes geschrieben : |
| Mittels deiner Idee des Zero-Knowlege Proofs kann der Besitzer die Kenntnis von x und r beweisen und damit die Zugehörigkeit zu diesem Schlüssel. Gleichzeitig kann man mit diesen Werten einen DH absichern, indem man die DH Werte signiert. Evtl kann man auch ohne DH aus den beiden öffentlichen Schlüsseln einen SessionKey berechnen... |
Der DH Kex sollte auf vollständig zufälligen Daten basieren und erstmal unabhängig von der Auth sein. Wichtig ist doch, dass die Identität für keinen Außenstehenden nachprüfbar wird. Und da haben wir ja mehr oder weniger schon die Werkzeuge.
Gehen wir jetzt aber wirklich mal zu dem Punkt, dass Alice, Bob und Charlie untereinander reden können.
1. Was muss Dave von Alice, Bob ODER Charlie in Erfahrung bringen, um einen der anderen Leute kontaktieren zu können? (Wir gehen von dynamischen IPs aus)
2. Wie könnte er diese Daten "automatisierbar" erhalten, ohne dass Verdacht entsteht? (Einen Zettel von Trent oder Vera zu erhalten ist nicht automatisiert, auch wenn es gehen würde ;-))
3. WIE sollte die erste Kontaktaufnahme gestaltet werden?
Zu 1. vielleicht eine Idee, auch wenn die recht unpraktikabel ist:
Gegeben Dave hat die ID von Alice, sowie eine Subnetz-Angabe (von z.B. einem /16, so könnte Dave versuchen, für alle IPs auf einem, von der IP+ID abhängigen Portnummer ein UDP-Paket zu senden, in dem eine zufällige Menge an Daten enthalten ist (warum zufällige Menge, siehe oben; Bedeutung: Daten sind Teil der ersten Nachricht eines DH-Kex). Antwort wäre dann wiederum eine Zufällige Menge von Daten (2. Schritt). Danach sendet jede Seite eine Zufällige Menge an Daten noch nach, bis
1. die für den DH-Kex nötige Datenmenge da ist
2. n zusätzliche Bytes übertragen wurden.
Dabei gilt: Das Paket, was die Mindest-Datenmenge der ersten beiden Schritte abschließt, beendet den Schritt für den jeweiligen Teilnehmer. Danach wird ganz normal weiter geredet (ähnlich Vuze oder OTR).
Dieses Vorgehen ist in der Form aber, trotz der Shared Knowledge (die ID von Alice) doch aber sicherlich nicht für 3. akzeptabel? Angriffe?
Sirke - Di 10.11.09 23:51
Befinden wir uns bereits in einem anonymen o.ä. Netzwerk oder soll es grundsätzlich auch übers WAN möglich sein?
Eine Möglichkeit die mir einfällt wäre folgende - wobei ich auch die Schwachpunkte schon kenne:
- Alice kontaktiert Bob und teilt ihm über irgendeinen Kanal seine ID mit, falls Bob mal mit Alice reden möchte! - Ist dies noch erwünscht oder könnte dies schon Probleme mit sich bringen?
- Bob möchte Alice kontaktiere und Broadcastet die ID ins Netz, was entweder ein klassisches Broadcast sein kann (was natürlich nur in kleinen Subnetzten möglich ist) oder ein Rundruf über alle bekannten Kontakte alle im Netz teilnehmenden Personen.
- Alice kontaktiert daraufhin Bob und beweißt ihm dass ihm wirklich die ID gehört.
- Danach DH Key-Exchange und Kommunikation...
Evtl könnte man auch überlegen ob es möglich ist an jeden eine andere zufällige ID zu verteilen und es polynominell prüfbar ist, ob diese ID zum eigenen Schlüssel gehört => Viele verschiedene IDs der selben Partei!
An sich müssen wir hierbei noch klären, was genau die Ziele sind:
- Abstreibare, Vertrauliche, Authentische und Integre Kommunikation von zwei Parteien!
- Darf bekannt sein wer mit wem kommuniziert hat oder nur dass zwei Parteien miteinander kommuniziert haben?
- Forward-Secrecy! (wird durch DH ja erreicht)
- ...weitere Ziele?
BenBE - Mi 11.11.09 00:24
| Sirke hat folgendes geschrieben : |
Befinden wir uns bereits in einem anonymen o.ä. Netzwerk oder soll es grundsätzlich auch übers WAN möglich sein?
Eine Möglichkeit die mir einfällt wäre folgende - wobei ich auch die Schwachpunkte schon kenne:
- Alice kontaktiert Bob und teilt ihm über irgendeinen Kanal seine ID mit, falls Bob mal mit Alice reden möchte! - Ist dies noch erwünscht oder könnte dies schon Probleme mit sich bringen?
|
Könnte man ggf. beide Fälle betrachten. Einfacher dürfte aber sein, wenn dies nicht als strafbar betrachtet wird, obgleich das eigentlich schon sehr stark eine Mitgliedschaft vermuten lässt.
| Sirke hat folgendes geschrieben : |
| Bob möchte Alice kontaktiere und Broadcastet die ID ins Netz, was entweder ein klassisches Broadcast sein kann (was natürlich nur in kleinen Subnetzten möglich ist) oder ein Rundruf über alle bekannten Kontakte alle im Netz teilnehmenden Personen. |
Spätestens hier dürfte Traffic entstehen, der suspekt erscheinen könnte ...
| Sirke hat folgendes geschrieben : |
| Alice kontaktiert daraufhin Bob und beweißt ihm dass ihm wirklich die ID gehört. |
k, ACK.
| Sirke hat folgendes geschrieben : |
| Danach DH Key-Exchange und Kommunikation...Evtl könnte man auch überlegen ob es möglich ist an jeden eine andere zufällige ID zu verteilen und es polynominell prüfbar ist, ob diese ID zum eigenen Schlüssel gehört => Viele verschiedene IDs der selben Partei! |
So in der Form ECC ... Durchaus vorstellbar.
| Sirke hat folgendes geschrieben : |
An sich müssen wir hierbei noch klären, was genau die Ziele sind:
- Abstreibare, Vertrauliche, Authentische und Integre Kommunikation von zwei Parteien!
- Darf bekannt sein wer mit wem kommuniziert hat oder nur dass zwei Parteien miteinander kommuniziert haben?
- Forward-Secrecy! (wird durch DH ja erreicht)
- ...weitere Ziele?
|
Jain. Abstreitbar, ja. Genauso Vertraulich, Authentisch (für die Kommunikationspartner - UND NUR für diese), Integre, Fälschbar (vgl. OTR).
Wer mit wem kommuniziert hat, darf nur für die beteiligten beiden Parteien ersichtlich sein, darf/sollte also für Relay-Knoten nicht ersichtlich sein.
Ziel ist auch Forward Secrecy, jap.
Weitere Ziele fallen mir jetzt grad nicht ein, sind aber glaube auch erstmal nicht zwingend notwenidg - ist ja schon so schwer genug, sowas unter diesen Maßgaben umzusetzen ;-)
Sirke - Mi 11.11.09 10:05
| BenBE hat folgendes geschrieben : |
Spätestens hier dürfte Traffic entstehen, der suspekt erscheinen könnte ...
(...)
Wer mit wem kommuniziert hat, darf nur für die beteiligten beiden Parteien ersichtlich sein, darf/sollte also für Relay-Knoten nicht ersichtlich sein. |
In meinen Augen liegt hier das größte Problem! Die übertragenen Pakete müssen Informationen transportieren und gleichzeitig dürfen sie keine suspekten Strukturenaufweisen.
Aus diesem Grund müsste man bekannte Protokolle wie HTTP, POP oder SMTP nutzen: Sofern SSL/TLS nicht eingeschränkt sind, kann man die zufällige Struktur dieser Pakete nutzen um Daten darin zu kapseln. Sollte SSL/TLS jedoch eingeschränkt sein, muss man die Daten in der gernellen Struktur der Protokolle kapseln. Dann stehen als Fake Webserver, Mailserver und Webservices zur Verfügung, welche Implementiert werden und korrekt reagieren müssen.
Die erwähnten Relay-Knoten sind als kompromittiert bzw überwacht anzusehen?
| BenBE hat folgendes geschrieben : |
| Jain. Abstreitbar, ja. Genauso Vertraulich, Authentisch (für die Kommunikationspartner - UND NUR für diese), Integre, Fälschbar (vgl. OTR). |
Diese Punkte wurden ja schon geklärt: AES-CTR dessen SessionKey geheim bleibt und MACs deren SessionKeys offen gelegt werden. Dadurch kann jeder nach dem offen legen der MAC-Keys einen eigenen anderen SessionKey erzeugen und die Nachrichten verändern, sodass sie entschlüsselbar sind und dessen MAC sie selbst erstellen.
| BenBE hat folgendes geschrieben : |
| Wer mit wem kommuniziert hat, darf nur für die beteiligten beiden Parteien ersichtlich sein, darf/sollte also für Relay-Knoten nicht ersichtlich sein. |
Dies bedeutet entweder die beiden Parteien kommunizieren offen über einen Dienst welcher nicht auffällt oder deren Kommunikation muss über eine dritte Partei laufen, sodass immer nur eine Partei mit dieser dritten kommuniziert. Diese dritte Partei ist aber dann wieder schwachpunkt des Systems. Daher bleibt nur das Weiterleiten der Pakete über andere Teilnehemer des Systems (vgl TOR), wobei dieses Weiterleiten in öffentlichen Protokollen ohne ersichtliche Inhalte stattfinden muss.
| BenBE hat folgendes geschrieben : |
| Ziel ist auch Forward Secrecy, jap. |
Wird durch korrekten DH ja erreicht! ;-)
| BenBE hat folgendes geschrieben : |
| So in der Form ECC ... Durchaus vorstellbar. |
Denke ECC wäre nicht die sinnvollste Idee, da bisher noch wenig zu Zero-Knowlegde Proofs und anderem im ECC veröffentlicht wurden. Besser wären zur Berechnung prime Gruppen - ja, auch Berechnungen in ECC findet in einer Gruppe statt!
BenBE - Mi 11.11.09 10:49
| Sirke hat folgendes geschrieben : |
| BenBE hat folgendes geschrieben : | Spätestens hier dürfte Traffic entstehen, der suspekt erscheinen könnte ...
(...)
Wer mit wem kommuniziert hat, darf nur für die beteiligten beiden Parteien ersichtlich sein, darf/sollte also für Relay-Knoten nicht ersichtlich sein. |
In meinen Augen liegt hier das größte Problem! Die übertragenen Pakete müssen Informationen transportieren und gleichzeitig dürfen sie keine suspekten Strukturenaufweisen.
Aus diesem Grund müsste man bekannte Protokolle wie HTTP, POP oder SMTP nutzen: Sofern SSL/TLS nicht eingeschränkt sind, kann man die zufällige Struktur dieser Pakete nutzen um Daten darin zu kapseln. Sollte SSL/TLS jedoch eingeschränkt sein, muss man die Daten in der gernellen Struktur der Protokolle kapseln. Dann stehen als Fake Webserver, Mailserver und Webservices zur Verfügung, welche Implementiert werden und korrekt reagieren müssen. |
Jap. So macht es zumindest Tor. Dort wird SSL nachgeahmt ...
| Sirke hat folgendes geschrieben : |
| Die erwähnten Relay-Knoten sind als kompromittiert bzw überwacht anzusehen? |
Da das netz anonym ist, sollten wir auch den Trustlevel in seine Teilnehmer möglichst gering halten. Bei Betrachtungen dürfen aber beide Fälle angenommen werden; ggf. mit Erwähnung dessen, was sich ändern würde.
| Sirke hat folgendes geschrieben : |
| BenBE hat folgendes geschrieben : | | Jain. Abstreitbar, ja. Genauso Vertraulich, Authentisch (für die Kommunikationspartner - UND NUR für diese), Integre, Fälschbar (vgl. OTR). |
Diese Punkte wurden ja schon geklärt: AES-CTR dessen SessionKey geheim bleibt und MACs deren SessionKeys offen gelegt werden. Dadurch kann jeder nach dem offen legen der MAC-Keys einen eigenen anderen SessionKey erzeugen und die Nachrichten verändern, sodass sie entschlüsselbar sind und dessen MAC sie selbst erstellen. |
Wäre die Fälschung dann nicht als solche erkennbar?
| Sirke hat folgendes geschrieben : |
| BenBE hat folgendes geschrieben : | | Wer mit wem kommuniziert hat, darf nur für die beteiligten beiden Parteien ersichtlich sein, darf/sollte also für Relay-Knoten nicht ersichtlich sein. |
Dies bedeutet entweder die beiden Parteien kommunizieren offen über einen Dienst welcher nicht auffällt oder deren Kommunikation muss über eine dritte Partei laufen, sodass immer nur eine Partei mit dieser dritten kommuniziert. Diese dritte Partei ist aber dann wieder schwachpunkt des Systems. Daher bleibt nur das Weiterleiten der Pakete über andere Teilnehemer des Systems (vgl TOR), wobei dieses Weiterleiten in öffentlichen Protokollen ohne ersichtliche Inhalte stattfinden muss. |
ACK hierbei.
| Sirke hat folgendes geschrieben : |
| BenBE hat folgendes geschrieben : | | Ziel ist auch Forward Secrecy, jap. |
Wird durch korrekten DH ja erreicht! ;-) |
Nicht zwingend DH, aber korrekte Nutzung von kurzlebigen Session-Keys.
Delete - Mi 11.11.09 11:17
Folgendes Szenario wäre auch möglich:
A will B eine Nachricht senden:
A schickt B eine Email im Klartext, die einen ganz normalen, unverfänglichen Text enthält.
Dieser Text enthält aber einen Schlüssel (den ein Dritter nicht sieht!) und einen Link z.B. auf ein Foto, das die eigentliche, geheime Nachricht enthält z.B. einen weiteren Link auf ein verschlüsseltes RAR-File oder ein weiteres Foto mit steganographischer "Nachbearbeitung".
Der unverfängliche Text könnte ganz banal sein und kein Dritter käme auf die Idee, etwas zu suchen...
Der beste Schutz ist der, der nicht wie ein Schutz aussieht!
Vorgestern war ich im Neuen Museum und habe mir nach über dreissig Jahren mal wieder die Nofretete angeschaut. Du wirst es nicht glauben, aber diese schöne Frau ist kein bisschen älter geworden. Wenn Du das Foto sehen willst, hier ist der Link:
http://lh3.ggpht.com/_wWJnQ85FDn4/RvaHRPH8CzI/AAAAAAAABD0/1gPWWOjY1aU/M+%C3%84gyptisches+Museum+009.JPG
Der Schlüssel für die geheime Botschaft wäre nun beispielsweise aus der Länge der Wörter zusammenzusetzen, beginnend in einer bestimmten Zeile ("Vorgestern") oder einem bestimmten Wort (Datum=11).
Phantasie ist ein guter Kryptograf.
BenBE - Mi 11.11.09 11:34
Das ist korrekt, lässt sich aber nicht wirklich automatisieren, wenn das Verfahren bekannt ist (vgl. oben zwecks Anforderungen). Sicherlich: Wenn ein geheimer Schlüssel eingeht, könnte es wieder machbar wären, das könnte man ggf. ja mal genauer betrachten.
Sirke - Mi 11.11.09 16:17
@hathor: Das Einfügen von Daten in ein Bild kann schnell zu Problemen führen. Die einfachste Variante wäre, dass man in jedem Pixel in den Farbwerten das LSB nimmt dieses als Schlüsselbits benutzt. Am Ende erhielte man dann zwei Bilder welche sich durch den Text unterschieden. ABER: Sobald man das veränderte Bild analysiert, fällt der Zufall als Unregelmäßigkeit auf, da Bilder normalerweise weiche Übergange haben und diese dadurch zufällig werden. Weiteres Problem würde die Authentizität bereiten, weil dazu ein "Dialog" von nöten ist!
| BenBE hat folgendes geschrieben : |
| Jap. So macht es zumindest Tor. Dort wird SSL nachgeahmt ... |
Bekommt man jedoch Probleme, sobald TLS/SSL verboten würde! Ansonsten wäre dieses Projekt lediglich TOR und OTR zu verbinden.
| BenBE hat folgendes geschrieben : |
| Da das netz anonym ist, sollten wir auch den Trustlevel in seine Teilnehmer möglichst gering halten. Bei Betrachtungen dürfen aber beide Fälle angenommen werden; ggf. mit Erwähnung dessen, was sich ändern würde. |
Welches Netz nehmen wir denn an? ...sonst kann man auch dadurch schon Probleme bekommen, dass das Netz nicht möglichist, weil es gefiltert wird!
| BenBE hat folgendes geschrieben : |
| Wäre die Fälschung dann nicht als solche erkennbar? |
Nur für die beiden Kommunikationsteilnehmer:
Wir schreiben
AES-CTR{K}(m) als die AES Verschlüsselung um Counter-Mode unter dem Schlüssel
K ohne beachtung des Counters (weil hier irrelevant) der Nachricht
m. Der MAC wird geschrieben als
MAC{K}(m) und bedeutet der MAC unter dem Schlüssel
K der Nachricht
m Zudem berechnet
XOR die XOR-Verknüpfung von Byte-Strings. Dann sähe die Kommunikation zwischen Alice (A) und Bob(B) wie folgt aus:
A<->B:
n = ( c = AES{Ke}(m), d = MAC{Km}(m) ), mit zuvor ausgetauschten Schlüssel
Ke zur Ver/Entschlüsselung und
Km zum Berechnen des MACs.
Am Ende der Kommunkation tauschen beide Parteien den MAC-Schlüssel
Km im Klartext aus.
Ein Angreifer würde die Nachricht
n = (c,d) und den MAC-Schlüssel
Km abfangen und könnte nichts mit diesen Werte anfangen, um die orignial Kommuniikation zu erfahren. Bei einer Fälschung würde er folgendes brechnen:
Er erzeugt eine gefälschte Nachricht
m' und berechnet
AES-CTR{K'}(m') = c' und
d' = MAC{Km}(m') und erzeugt dadurch die gefälschte Nachricht
n' = (c',d')! Nur die beiden Kommunikationspartner wissen, dass
K' nicht
Ke ist und die grundlage der Kommunikation ist grundsätzlich, dass dieses Fälschen IMMER möglich ist und keiner sagen kann, ob eine Nachricht
n Original oder Fälschung ist.
| BenBE hat folgendes geschrieben : |
| Sirke hat folgendes geschrieben : | | BenBE hat folgendes geschrieben : | | Ziel ist auch Forward Secrecy, jap. |
Wird durch korrekten DH ja erreicht! ;-) |
Nicht zwingend DH, aber korrekte Nutzung von kurzlebigen Session-Keys. |
Na dann mal raus, wie du Forward Secrecy OHNE DH erreichen möchtest... ;-) Wir dürfen den Session Key dazu NICHT vom Langzeitschlüssel ableiten!
Dann ist das Sinnvollste bisher wohl wirklich das Einbetten in ein bisher bestehendes Protokoll, welches auf jeden Fall legal ist und zur Not SSL/TLS unterstützt, aber auch ohne dieses Feature zufällige Daten enthalten kann. Anschließend kann man an das Protokoll im einzelnen Denken, wie man die Auth und den Key-Ex umsetzt!
>M@steR< - Mi 11.11.09 16:59
Gelöscht
elundril - Mi 11.11.09 20:47
| >M@steR< hat folgendes geschrieben : |
Hi,
Man könnte ja einen Binärcode im Bild speichern, so das z.B. jeder ungrade farbwert einer 0 und jeder grade farbwert einer 1 entspricht. Der geringe unterschied von + - 1 dürfte im Bild nicht auffallen oder? |
genau das macht man beim LSB verfahren afaik. Da ändert man nur ein Bit, deswegen wird binär gespeichert. Aber, es gibt analysetools, die erkennen ob ein bild einen Text oder so in den Bytes enthält.
Man korregiere (oder erschlage) mich sollte ich bullshit geredet haben.
lg elundril
>M@steR< - Do 12.11.09 03:55
Gelöscht
BenBE - Do 12.11.09 21:19
| Sirke hat folgendes geschrieben : |
| @hathor: Das Einfügen von Daten in ein Bild kann schnell zu Problemen führen. Die einfachste Variante wäre, dass man in jedem Pixel in den Farbwerten das LSB nimmt dieses als Schlüsselbits benutzt. Am Ende erhielte man dann zwei Bilder welche sich durch den Text unterschieden. ABER: Sobald man das veränderte Bild analysiert, fällt der Zufall als Unregelmäßigkeit auf, da Bilder normalerweise weiche Übergange haben und diese dadurch zufällig werden. |
Setzt man die richtige Vorschrift zum Verändern der Pixel an (z.B. Daten nur entlang bestehender Kanten ändern) an, kann man diese Auffälligkeit jedoch stark reduzieren. Problematisch dürfte es aber sein, wenn 2 oder mehr Varianteen eines Bildes auftauchen, die zwar gleich aussehen, aber sich in eben diesen Mustern unterscheiden. JEDOCH begründet diese Auffälligkeit nicht zwangsläufig eine Mitgliedschaft, SOFERN die Art der Änderungen nicht auf das Ausgangswerkzeug zurückgeführt werden kann (Wir gehen mal von einem Rechtsstaat aus, bei dem ein Gericht soetwas glaubhaft beweisen muss).
| Sirke hat folgendes geschrieben : |
| Weiteres Problem würde die Authentizität bereiten, weil dazu ein "Dialog" von nöten ist! |
Das ist doch aber für das Bild auch nur bedingt nötig, wenn man anhand der darin enthaltenen Informationen zeigen kann, dass der Autor Informationen über das Netzwerk hat, die Mitglieder im Netzwerk zeigen können, und dabei aber von der Nutzung der Nachricht an sich nicht abhängig sind.
Beispiel:
Ich erhalte Nachricht M' aus steganographischem Bild M unter Verwendung von Schlüssel K (z.B. dem Extraktionsverfahren). Die Nachricht M' ist mit Authentifizierungsverfahren (z.B. HMAC) dessen Schlüssel K' mir nicht bekannt ist, den ich aber beim Kommunizieren mit beliebigen Mitgliedern des Netzwerkes erhalten kann. M' enthält eine Art "Knotenverzeichnis" mit nur wenigen Knoten (die an sich nicht direkt ausreichen für eine Verifikation.
Nehme ich nun diese Nachricht her, kontaktiere davon Knoten und führe mit diesen ein Protokoll P aus, über dass ich mir ein "Teilgeheimnis" hole, so kann ich nach einer bestimmten Anzahl an Antworten, die ich durch dieses Protokoll erhalten habe, den Schlüssel berechnen (Group Signatures bzw. Ring Signatures äwren hier z.B. ein Weg).
| Sirke hat folgendes geschrieben : |
| BenBE hat folgendes geschrieben : | | Jap. So macht es zumindest Tor. Dort wird SSL nachgeahmt ... |
Bekommt man jedoch Probleme, sobald TLS/SSL verboten würde! Ansonsten wäre dieses Projekt lediglich TOR und OTR zu verbinden. |
I2P mit OTR wäre glaube die bessere Wahl. Onion Routing erzeugt nachvollziehbare Wege. Side Channel Attacke wäre hier mit ner Traffic-Messung möglich (Abwehr dadurch, dass sich das Netz intern anonym über die Traffic-Sitation unterhält und gegensteuert).
| Sirke hat folgendes geschrieben : |
| BenBE hat folgendes geschrieben : | | Da das netz anonym ist, sollten wir auch den Trustlevel in seine Teilnehmer möglichst gering halten. Bei Betrachtungen dürfen aber beide Fälle angenommen werden; ggf. mit Erwähnung dessen, was sich ändern würde. |
Welches Netz nehmen wir denn an? ...sonst kann man auch dadurch schon Probleme bekommen, dass das Netz nicht möglichist, weil es gefiltert wird! |
Als Transportnetz nehmen wir ein weitestgehend neutrales Netzwerk an. Dies rührt schon daher, dass keine Filterung perfekt ist und daher solch ein Netz entsprechend gegensteuern können dürfte.
| Sirke hat folgendes geschrieben : |
| BenBE hat folgendes geschrieben : | | Wäre die Fälschung dann nicht als solche erkennbar? |
Nur für die beiden Kommunikationsteilnehmer:
Wir schreiben AES-CTR{K}(m) als die AES Verschlüsselung um Counter-Mode unter dem Schlüssel K ohne beachtung des Counters (weil hier irrelevant) der Nachricht m. Der MAC wird geschrieben als MAC{K}(m) und bedeutet der MAC unter dem Schlüssel K der Nachricht m Zudem berechnet XOR die XOR-Verknüpfung von Byte-Strings. Dann sähe die Kommunikation zwischen Alice (A) und Bob(B) wie folgt aus:
A<->B: n = ( c = AES{Ke}(m), d = MAC{Km}(m) ), mit zuvor ausgetauschten Schlüssel Ke zur Ver/Entschlüsselung und Km zum Berechnen des MACs.
Am Ende der Kommunkation tauschen beide Parteien den MAC-Schlüssel Km im Klartext aus.
Ein Angreifer würde die Nachricht n = (c,d) und den MAC-Schlüssel Km abfangen und könnte nichts mit diesen Werte anfangen, um die orignial Kommuniikation zu erfahren. Bei einer Fälschung würde er folgendes brechnen:
Er erzeugt eine gefälschte Nachricht m' und berechnet AES-CTR{K'}(m') = c' und d' = MAC{Km}(m') und erzeugt dadurch die gefälschte Nachricht n' = (c',d')! Nur die beiden Kommunikationspartner wissen, dass K' nicht Ke ist und die grundlage der Kommunikation ist grundsätzlich, dass dieses Fälschen IMMER möglich ist und keiner sagen kann, ob eine Nachricht n Original oder Fälschung ist. |
Stimmt, hatte ich übersehen.
| Sirke hat folgendes geschrieben : |
| BenBE hat folgendes geschrieben : | | Sirke hat folgendes geschrieben : | | BenBE hat folgendes geschrieben : | | Ziel ist auch Forward Secrecy, jap. |
Wird durch korrekten DH ja erreicht! ;-) |
Nicht zwingend DH, aber korrekte Nutzung von kurzlebigen Session-Keys. |
Na dann mal raus, wie du Forward Secrecy OHNE DH erreichen möchtest... ;-) Wir dürfen den Session Key dazu NICHT vom Langzeitschlüssel ableiten! |
DH ist 1. nicht das einzige Kex-Protokoll und 2. kann man DH auch mit reinen Zufallszahlen machen. So macht es z.B. Vuze.
Ach ja: Ein OTP besitzt Forward Secrecy - nur ist das etwas unhandlich :P
| Sirke hat folgendes geschrieben : |
| Dann ist das Sinnvollste bisher wohl wirklich das Einbetten in ein bisher bestehendes Protokoll, welches auf jeden Fall legal ist und zur Not SSL/TLS unterstützt, aber auch ohne dieses Feature zufällige Daten enthalten kann. Anschließend kann man an das Protokoll im einzelnen Denken, wie man die Auth und den Key-Ex umsetzt! |
Sollte man nicht erstmal wissen, welchen Ablauf man bzgl. Nachrichten benötigt, bevor man anfängt, zu planen, wie diese auf den physischen Layer gelegt werden?
Sirke - Fr 13.11.09 14:50
| BenBE hat folgendes geschrieben : |
| I2P mit OTR wäre glaube die bessere Wahl. Onion Routing erzeugt nachvollziehbare Wege. Side Channel Attacke wäre hier mit ner Traffic-Messung möglich (Abwehr dadurch, dass sich das Netz intern anonym über die Traffic-Sitation unterhält und gegensteuert). |
Ich kenne mich nicht soo gut mit den vielen Möglichkeiten für anonyme Netze aus, aber der erste Blick auf I2P ist schon mal nicht schlecht! Die genau Funktionsweise ist mir jedoch zur zeit nicht bekannt, aber auch irrelevant da meine Annahmen zur Zeit darauf beruhen, dass die Daten die richtigen Sender und Empfänger anonym erreichen.
Jede Partei kann
* viele asymmetrische Schlüsselpaare besitzen, welche für eine Partei
A mit
pkAi und
skAi, wobei
i eine Nummer des veröffentlichen Schlüsselpaares darstellt, bezeichnet werden. Mit
ID(Ai) wird die dazugehörige ID, dh Pseudionym bzw Zufallszahl (Hash) bezeichnet. Zu beachten ist, dass
i keine öffentlich bekannte Nummer sein sollte, sondern lediglich hier zur Unterscheidung angewendet werden soll! Die Verschlüsselung unter einem
pkXi oder
skXi einer Nachricht
m wird mit
E{pkXi}( m ) bezeichnet!
Dann läuft die Authentifizierung der beiden Parteien ( A und B ) wie folgt ab:
Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
| A --> B: ID(Bi), E{pkBi}( ID(Bi), ID(Aj), nA, g^xA ) // Teilt B die ID des zu verwendenden
// Schlüsselpaares mit!
A <-- B: E{pkAj}( ID(Aj), ID(Bi), nB, g^xB ) // Antwort an As gewünschte ID
A --> B: MAC{K'}( ID(Bi), ID(Aj), g^xA, g^xB ) // K' = Hash( nA, nB )
A <-- B: MAC{K'}( ID(Aj), ID(Bi), g^xB, g^xA ) // K' = Hash( nA, nB )
A <-> B: E{EncKey}( m ), MAC{MacKey}( m ) // EncKey = Hash( 0xAB || g^(xA*xB) )
// MacKey = Hash( 0xCD || g^(xA*xB) ) |
Die
ID(Xi) können verschiedene Formen haben z.B. nur der Hash des Schlüsselpaares, welches zwischen A und B bereits ausgetauscht wurde oder ein Zertifikat, welches bereits ausgetauscht wurde oder ein Zertifikat, welches noch nicht ausgetauscht wurde, aber dann von einer dritten vertrauenswürdigen Partei signiert sein muss.
Hierbei wird Anonymität gehalten, weil JEDE Partei, welche mindestens einen pkAi, pkBj kennt, diese Nachrichten erzeugen kann! Gleichzeitig kann A und B sicher sein, wenn die MACs korrekt ankommen, dass die Nachrichten bei dem Besitzer der zugehörigen sk's angekommen ist. Um einen Key-Imper-Attack auszuschließen, MUSS eine Verbindung von den IDs zu den gewünschten Pseudonymen herzustellen sein! Hierzu stehen viele verschiedene Verfahren zur Verfügung ;-)
Diese Auth mit den in eingen Posts zuvor vorgestellten Counter Mode Verschlüsselungen in einem anonymen Netz (I2P) müsste ein anonymes OTR ermöglichen! Gerade weil ALLE Nachrichten gefälscht werden können! Denkfehler? Angriffe?
PS: Zur Auth Fälschung! In dem Netz sollte die Möglichkeit bestehen, dass jeder Relay-Knoten diese Nachrichten als Man-In-The-Middle erzeugen und an A und B senden kann ohne dass diese beiden Parteien dies wollen! Sprich: Die Nachrichten zwischen allen Relay-Knoten und den Empfängern DARF NICHT signiert sein! Denke mal hier liegt das größte Problem von I2P. ABER BEACHTE: Wie genau die Pakete in I2P aussehen ist mir nicht bekannt und konnte ich auch noch niewo gut finden!
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!