Hallo.
Erst einmal: Ich bin mir nicht sicher wo das hin gehört.
Ich habe eine grundsätzliche Frage:
Wenn ein Benutzer übers Web/Android Daten in einer Datenbank hinterlegt und der DB-Betreiber Zugriff auf alle Daten sämtlicher Benutzer hat, aber selber nicht wissen darf, wem die jeweiligen Daten zugeordnet werden. Wie könnte das realisiert werden?
Die Schwierigkeit wird noch dadurch gesteigert, dass die Verknüpfung zwischen Benutzer und Daten (die wie gesagt nur von Seiten des Benutzers erfolgen darf) als jährliches Abo gelöst werden können soll.
Ich hoffe, ich habe mich verständlich genug ausgedrückt.
Verschlüsselung / Datenbankzugriff
-
BlackJack
@meego: Ich würde mal sagen das geht nicht, denn wenn die Zuordnung nicht auf dem Server erfolgt, wie soll man dann wenn ein Benutzer seine Daten haben möchte, herausfinden welche Daten das sind die man ihm ausliefern darf/soll!? Und das nächste ist das der Betreiber ja die Zugriffs-/Verbindungsdaten überwachen kann und dadurch sehen kann wer was ablegt und abruft.
Da im Betreff auch Verschlüsselung steht: Man kann die Daten eines Benutzers auf dem Client ver- und entschlüsseln, so das der Betreiber nur verschlüsselte Daten sieht. Dann kann er zwar die Daten dem Benutzer zuordnen, weiss aber nicht was in den Daten drin steht. Dann muss man dem Benutzer nur noch sagen das er auf seinen Schlüssel aufpassen muss, wenn der verloren geht, gibt es keine Möglichkeit mehr an seine Daten heran zu kommen. Vorausgesetzt es wird ordentlich Verschlüsselt.
Da im Betreff auch Verschlüsselung steht: Man kann die Daten eines Benutzers auf dem Client ver- und entschlüsseln, so das der Betreiber nur verschlüsselte Daten sieht. Dann kann er zwar die Daten dem Benutzer zuordnen, weiss aber nicht was in den Daten drin steht. Dann muss man dem Benutzer nur noch sagen das er auf seinen Schlüssel aufpassen muss, wenn der verloren geht, gibt es keine Möglichkeit mehr an seine Daten heran zu kommen. Vorausgesetzt es wird ordentlich Verschlüsselt.
@meego: Du mußt Dir genau überlegen, welchen Angriff auf die Daten Du verhindern willst.
Man kann jedem Datensatz eine eindeutige Nummer geben und es gibt Verzeichnisse die Nummern zu Namen mappen. Der Client könnte dann aus seinem Passwort die Root-Verzeichnissnummer berechnen. Jetzt kann natürlich jeder Nutzer beliebige Daten anfordern, aber nur seine eigenen Entschlüsseln. Damit hat jemand, der die Datenbank durchsucht, nur Nummernsalat aber keine Zuordnung zu Usern. Wer aber die Zugriffe mitprotokolliert kann natürlich diese Zuordnung vornehmen.
Dafür könntest Du den Server als Tor-Hidden-Service aufsetzen. Damit wäre dann jede Anfrage nicht mehr rückverfolgbar
Man kann jedem Datensatz eine eindeutige Nummer geben und es gibt Verzeichnisse die Nummern zu Namen mappen. Der Client könnte dann aus seinem Passwort die Root-Verzeichnissnummer berechnen. Jetzt kann natürlich jeder Nutzer beliebige Daten anfordern, aber nur seine eigenen Entschlüsseln. Damit hat jemand, der die Datenbank durchsucht, nur Nummernsalat aber keine Zuordnung zu Usern. Wer aber die Zugriffe mitprotokolliert kann natürlich diese Zuordnung vornehmen.
Dafür könntest Du den Server als Tor-Hidden-Service aufsetzen. Damit wäre dann jede Anfrage nicht mehr rückverfolgbar
Was du suchst nennt sich Dropbox. Die Anwendung läuft dann als Android Anwendung, verschlüsselt alles und schiebt es in die "Cloud" und holt sich die Daten auf Bedarf (komplett) wieder. Android statt Web weil sich ein Webfrontend dass vom nicht-vertrauenswürdigen Server Betreiber ausgeliefert wird praktisch nicht überprüfbar ist.
Sobald du auf dem Server irgendwas mit den verschlüsselten Daten machen willst, bräuchtest du Homomorphic Encryption. Letzteres ist leider mehr Science Fiction als Realität.
Sobald du auf dem Server irgendwas mit den verschlüsselten Daten machen willst, bräuchtest du Homomorphic Encryption. Letzteres ist leider mehr Science Fiction als Realität.
Bitte anfängerfreundlich bleiben.
Was wäre, wenn man dem Benutzer einen USB-Stick schicken würde. Auf dem USB-Stick ist Code drauf, der das Erstellen einer persönlichen ID mit Passwort zulässt. Mit diesen Daten greift er stets auf denselben Container mit seinen Daten in der DB zu. Ginge das?
Also auf dem Server muss man die Daten mit anderen Daten vergleichen können. Und daraus Berechnungen anstellen können (ist vermutlich mit einer verschlüsselten DB nicht mehr schnell möglich, oder?). Was verschlüsselt gehört ist sicherlich die Übertragung. Und die Zuordnung sollte unbekannt sein (die Privatsphäre des Benutzers soll auf jeden Fall erhalten bleiben).
Was wäre, wenn man dem Benutzer einen USB-Stick schicken würde. Auf dem USB-Stick ist Code drauf, der das Erstellen einer persönlichen ID mit Passwort zulässt. Mit diesen Daten greift er stets auf denselben Container mit seinen Daten in der DB zu. Ginge das?
Kann man das wie Sirius3 (via Tor) sagt für den Benutzer plausibel umgehen? Denkt mal zur besseren Illustration kurz den Gedanken Google euren Fingerabdruck auszuhändigen. Was müsste Google dafür tun, um eure Bedenken auszuräumen?Und das nächste ist das der Betreiber ja die Zugriffs-/Verbindungsdaten überwachen kann und dadurch sehen kann wer was ablegt und abruft.
Man kann die Daten eines Benutzers auf dem Client ver- und entschlüsseln, so das der Betreiber nur verschlüsselte Daten sieht.
Dann kann er zwar die Daten dem Benutzer zuordnen, weiss aber nicht was in den Daten drin steht.
Also auf dem Server muss man die Daten mit anderen Daten vergleichen können. Und daraus Berechnungen anstellen können (ist vermutlich mit einer verschlüsselten DB nicht mehr schnell möglich, oder?). Was verschlüsselt gehört ist sicherlich die Übertragung. Und die Zuordnung sollte unbekannt sein (die Privatsphäre des Benutzers soll auf jeden Fall erhalten bleiben).
Das wäre die Folge aus diesem Modell daraus, ja. Man wüsste zwar, wem man einmal einen USB-Stick versendet hat, aber nicht welche Daten zum Kunden gehören. Leider auch nicht, ob der Kunde noch vorhanden ist (wäre gut das zu wissen, aber hier habe ich keine Idee, wie das realisierbar wäre).Dann muss man dem Benutzer nur noch sagen das er auf seinen Schlüssel aufpassen muss, wenn der verloren geht, gibt es keine Möglichkeit mehr an seine Daten heran zu kommen.
Das ist mir noch etwas unverständlich. Wen der Benutzer also via USB-Stick mit seinem Benutzernamen und Passwort eine Berechnung anstellt, entspricht das der Datensatznummer seines Datensatzes in der DB? Aber du schlägst vor, dass dabei noch irgendwo eine Zuordnung stattfinden sollte?Man kann jedem Datensatz eine eindeutige Nummer geben und es gibt Verzeichnisse die Nummern zu Namen mappen. Der Client könnte dann aus seinem Passwort die Root-Verzeichnissnummer berechnen.
Ich dachte Dropbox arbeitet im Bedarfsfall mit den Staatsbehörden zusammen. Ich weiss nicht, ob ich den letzten Satz richtig verstehe: Der Benutzer weiss nicht, ob der Betreiber ihn doch zu seinen Datensätzen zuordnen kann? Warum ist das bei der Androidanwendung nicht auch der Fall?Was du suchst nennt sich Dropbox. Die Anwendung läuft dann als Android Anwendung, verschlüsselt alles und schiebt es in die "Cloud" und holt sich die Daten auf Bedarf (komplett) wieder. Android statt Web weil sich ein Webfrontend dass vom nicht-vertrauenswürdigen Server Betreiber ausgeliefert wird praktisch nicht überprüfbar ist.
@meego:
Du müsstest IMHO erstmal genau klarstellen, welche Angriffsszenarien existieren und welche Du davon vereiteln möchtest. Dazu gehört es auch, die Vertrauenswürdigkeit aller Teile Deiner Infrastruktur zu benennen und ensprechend die Aufgaben zu verteilen bzw. die Infrastruktur anzupassen.
Z.B. wird im Gesundheitswesen häufig auf PKI gesetzt, um eine einfache Zuordnung von Patientendaten zu Personen zu vereiteln. Dazu gibt es eine Authorität, welche das Mapping vornimmt und Nutzerschlüssel für die Daten rausgibt. Die Authorität muss unbedingt vertrauenswürdig sein, ist sie das nicht oder wurde kompromitiert, fällt das System wie ein Kartenhaus zusammen. U.a. deswegen sind die PKI-Authoritäten nicht im Internet gehostet, sondern auf Intranetservern der Kliniken/Kassen hinter vergitterten Fenstern und zig Firewalls/Honeypots gesichert.
Wenn selbst zentrale PKI mit temporärer Freigabe zu unsicher ist, hilft nur noch direkte End-zu-Endverschlüsselung.
Du müsstest IMHO erstmal genau klarstellen, welche Angriffsszenarien existieren und welche Du davon vereiteln möchtest. Dazu gehört es auch, die Vertrauenswürdigkeit aller Teile Deiner Infrastruktur zu benennen und ensprechend die Aufgaben zu verteilen bzw. die Infrastruktur anzupassen.
Z.B. wird im Gesundheitswesen häufig auf PKI gesetzt, um eine einfache Zuordnung von Patientendaten zu Personen zu vereiteln. Dazu gibt es eine Authorität, welche das Mapping vornimmt und Nutzerschlüssel für die Daten rausgibt. Die Authorität muss unbedingt vertrauenswürdig sein, ist sie das nicht oder wurde kompromitiert, fällt das System wie ein Kartenhaus zusammen. U.a. deswegen sind die PKI-Authoritäten nicht im Internet gehostet, sondern auf Intranetservern der Kliniken/Kassen hinter vergitterten Fenstern und zig Firewalls/Honeypots gesichert.
Wenn selbst zentrale PKI mit temporärer Freigabe zu unsicher ist, hilft nur noch direkte End-zu-Endverschlüsselung.
@meego: Deine jetzt beschriebenen Aufgaben sind ja völlig anders, als im ersten Post. Also beschreib doch mal konkret, was Du erreichen willst. Wer ist zu welchem Zeitpunkt vertrauenswürdig? Gibt es Gateways dehnen man vertrauen kann?
-
noisefloor
- User
- Beiträge: 3856
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
Ein konkretes, simples Beispiele zwecks Veranschaulichung wäre echt gut
Gruß, noisefloor
Ohne dich demotivieren zu wollen: Also nachdem was du bist beschrieben hast, schließt sich "Anfänger" und dein Problem schon gegenseitig aus...meego hat geschrieben:Bitte anfängerfreundlich bleiben.
Ein konkretes, simples Beispiele zwecks Veranschaulichung wäre echt gut
Gruß, noisefloor
Angriffsszenarien:jerch hat geschrieben:@meego:
Du müsstest IMHO erstmal genau klarstellen, welche Angriffsszenarien existieren und welche Du davon vereiteln möchtest. Dazu gehört es auch, die Vertrauenswürdigkeit aller Teile Deiner Infrastruktur zu benennen und ensprechend die Aufgaben zu verteilen bzw. die Infrastruktur anzupassen.
Irgendwer könnte die Zuordnungen der Benutzer zu den Datensätzen herauszufinden versuchen.
Irgendwer könnte die Benutzer ausfindig machen wollen.
Irgendwer könnte die DB komplett auslesen (die Datensätze sollen zwar zum Download bereit gestellt werden, aber eben nicht die ganze DB und keine identitätsrelevanten Benutzerdaten).
Vertrauenswürdigkeit (wenn ich das so richtig verstehe):
Auf dem USB-Stick könnte vielleicht ein vertrauenswürdiges Zertifakt oder ähnliches programmiert werden. Damit wäre der Benutzer vertrauenswürdig.
Der DB Server müsste gemietet werden.
Das würden die Benutzer wohl nicht für genug vertrauensvoll halten. Also wenn mir Google sagen würde, das dieses Mapping bei Google stattfindet, würde ich das nicht für vertrauensvoll halten. Es könnte auch wenn das eine vertrauenswürdigere Stelle macht gehackt werden.Z.B. wird im Gesundheitswesen häufig auf PKI gesetzt, um eine einfache Zuordnung von Patientendaten zu Personen zu vereiteln. Dazu gibt es eine Authorität, welche das Mapping vornimmt und Nutzerschlüssel für die Daten rausgibt.
Dann ist es wohl das.Wenn selbst zentrale PKI mit temporärer Freigabe zu unsicher ist, hilft nur noch direkte End-zu-Endverschlüsselung.
-
BlackJack
@meego: Du hast den interessantesten Einwand übergangen: Anfänger und so etwas umsetzen zu wollen schliessen sich aus. Alleine hier zu fragen ist schon ein Fehler und die einzige wirklich sinnvolle Antwort bei der Paranoia die Du in den (Nach)fragen zum Ausdruck bringst ist: überlass das erfahrenen Programmierern *und* Kryptologen.
Den Benutzern einen USB-Stick zu schicken ist doch auch schon problematisch. Die müssen Dir vertrauen das da nichts drauf ist was dann in der Kommunikation mit dem Server wieder die Verbindung zwischen der Adresse an die Du den USB-Stick geschickt hast und den Daten die sie mit dem Server austauschen ermöglicht.
Auch musst Du Dir klarmachen das *alles* gahackt/geknackt werden kann. Man kann es Angreifern nur *schwerer* machen. Dazu muss man genau festlegen wer alles mitspielt, welche Geheimnisse die jeweils wissen dürfen, und was man als tolerable Unsicherheit akzeptiert, denn sicher ist nichts.
Das Irgendwer in Deinen Szenarien musst Du präzisieren. Was kann dieser Irgendwer, welche Ressourcen hat der, und welche legitimen Zugriffe sind ihm möglich, und was genau soll für ihn schwerer gemacht werden.
Den Benutzern einen USB-Stick zu schicken ist doch auch schon problematisch. Die müssen Dir vertrauen das da nichts drauf ist was dann in der Kommunikation mit dem Server wieder die Verbindung zwischen der Adresse an die Du den USB-Stick geschickt hast und den Daten die sie mit dem Server austauschen ermöglicht.
Auch musst Du Dir klarmachen das *alles* gahackt/geknackt werden kann. Man kann es Angreifern nur *schwerer* machen. Dazu muss man genau festlegen wer alles mitspielt, welche Geheimnisse die jeweils wissen dürfen, und was man als tolerable Unsicherheit akzeptiert, denn sicher ist nichts.
Das Irgendwer in Deinen Szenarien musst Du präzisieren. Was kann dieser Irgendwer, welche Ressourcen hat der, und welche legitimen Zugriffe sind ihm möglich, und was genau soll für ihn schwerer gemacht werden.
Ein Kunde (Peter) kann ein Abo lösen. An den USB-Stick dachte ich, weil ich so besser eingrenzen kann, dass Peter tatsächlich physisch existiert. So lange dieses Abo gültig ist, hat er Zugriff auf seinen Datensatz in einer DB. Als Betreiber muss ich wissen, das Peter mein Kunde ist und ich muss auch Zugriff auf die Datensätze sämtlicher abstrakter Benutzer in der DB haben. Ich darf aber nicht wissen, dass Peter der Datensatz, wo er 2 Äpfel eingetragen hat, gehört.Sirius3 hat geschrieben:@meego: Deine jetzt beschriebenen Aufgaben sind ja völlig anders, als im ersten Post. Also beschreib doch mal konkret, was Du erreichen willst. Wer ist zu welchem Zeitpunkt vertrauenswürdig? Gibt es Gateways dehnen man vertrauen kann?
Ich glaube die Vertrauenswürdigkeit besteht, wenn obiges irgendwie garantiert werden kann.
Da hast du bestimmt recht. Ich werde sowas bestimmt nicht programmieren können.noisefloor hat geschrieben: Ohne dich demotivieren zu wollen: Also nachdem was du bist beschrieben hast, schließt sich "Anfänger" und dein Problem schon gegenseitig aus...
Siehe oben.Ein konkretes, simples Beispiele zwecks Veranschaulichung wäre echt gut
-
noisefloor
- User
- Beiträge: 3856
- Registriert: Mittwoch 17. Oktober 2007, 21:40
- Wohnort: WW
- Kontaktdaten:
Hallo,
Geht's hier eigentlich um ein Hobby, willst du ein Geschäft betreiben, ist das ein Gedankenmodell für eine Semesterarbeit an der Uni, ...?
Gruß, noisefloor
Das wäre doch wohl auch ein absolutes no-go bei dieser Sicherheitsparanoia. Bei einem gemieteten Server hast du doch _keinerlei_ Kontrolle darüber und Einfluss darauf, wer wann physichen Zugriff auf den Server hat. Der Betreiber des Rechenzentrums kann sich jederzeit ein Kopie deiner DB ziehen und offline knacken. Plus Backdoors etc. auf dem Server installieren, von denen du nichts mit bekommst.meego hat geschrieben:Der DB Server müsste gemietet werden.
Geht's hier eigentlich um ein Hobby, willst du ein Geschäft betreiben, ist das ein Gedankenmodell für eine Semesterarbeit an der Uni, ...?
Gruß, noisefloor
Aber ich muss doch wenigstens das Prinzip kennen, wenn ich jemanden programmieren lassen will.BlackJack hat geschrieben:Alleine hier zu fragen ist schon ein Fehler und die einzige wirklich sinnvolle Antwort bei der Paranoia die Du in den (Nach)fragen zum Ausdruck bringst ist: überlass das erfahrenen Programmierern *und* Kryptologen.
Auch wieder wahr. Scheint plausibel. Also ein Schreiben, wie bei einem Bankkonto?Den Benutzern einen USB-Stick zu schicken ist doch auch schon problematisch. Die müssen Dir vertrauen das da nichts drauf ist was dann in der Kommunikation mit dem Server wieder die Verbindung zwischen der Adresse an die Du den USB-Stick geschickt hast und den Daten die sie mit dem Server austauschen ermöglicht.
Kann man einen potentiellen Angreifer und seine Ressourcen denn überhaupt kennen? Der Angreifer darf nichts über die Zuordnung erfahren. Ich als Betreiber darf das nicht einmal erfahren. Der Angreifer darf keine Identitäten der Benutzer ausfindig machen können (verschlüsselte Kundendatenbank?).Das Irgendwer in Deinen Szenarien musst Du präzisieren. Was kann dieser Irgendwer, welche Ressourcen hat der, und welche legitimen Zugriffe sind ihm möglich, und was genau soll für ihn schwerer gemacht werden.
-
BlackJack
@meego: Auch wenn Du ein Schreiben schickst weisst Du was Du dem Benutzer geschickt hast, und wenn der das was Du geschickt hast braucht um mit dem Server zu kommunizieren kannst Du am Server dann auch wieder sehen wer der Benutzer ist. Das ist jedenfalls das was der Benutzer denkt was Du machen kannst, wenn Du ihm gegenüber also sagst Du könntest das nicht, müsstest Du das irgendwie beweisen können.
Du musst ja von irgendeinem Angreifer ausgehen können gegen Du Dich schützen willst. Du kannst also sagen $GOTT kann alles, also kann man sich gegen den nicht schützen. Das kannst Du akzeptieren, und Dir weiter Gedanken machen, oder Du kannst sagen gegen den soll es auch sicher sein. Dann kannst Du aufhören und das Projekt begraben. Ersetzen wir $GOTT durch die NSA oder vielleicht etwas allgemeiner gegen die Geheimdienste die da alle zusammenarbeiten. Da wäre mir so etwas wie Tor zum Beispiel schon nicht mehr sicher genug, denn das geht davon aus das niemand den Traffic von allen an einer Route beteiligten Nodes gleichzeitig abhört. Wenn es gegen NSA und Co wirklich sicher sein soll, dann wäre ich mal pessimistisch und würde einem anderen Projekt oder Hobby zuwenden. Und so weiter. Du musst eben genau abgrenzen gegen wen mit welchem Mitteln das noch sicher sein muss, und ab wo Du sagst, das ist ein Risiko das akzeptiere ich.
Anscheinend bist Du selbst ja auch ein sehr potenter Angreifer gegen den Du Dich schützen willst. Da Du die Kunden kennen musst um abzurechnen, und Zugriff auf die gespeicherten Daten und die Verkehrsdaten hast von den Zugriffen der Kunden auf ihre Daten, ist das alleine schon mal eine interessante Nuss.
Du musst ja von irgendeinem Angreifer ausgehen können gegen Du Dich schützen willst. Du kannst also sagen $GOTT kann alles, also kann man sich gegen den nicht schützen. Das kannst Du akzeptieren, und Dir weiter Gedanken machen, oder Du kannst sagen gegen den soll es auch sicher sein. Dann kannst Du aufhören und das Projekt begraben. Ersetzen wir $GOTT durch die NSA oder vielleicht etwas allgemeiner gegen die Geheimdienste die da alle zusammenarbeiten. Da wäre mir so etwas wie Tor zum Beispiel schon nicht mehr sicher genug, denn das geht davon aus das niemand den Traffic von allen an einer Route beteiligten Nodes gleichzeitig abhört. Wenn es gegen NSA und Co wirklich sicher sein soll, dann wäre ich mal pessimistisch und würde einem anderen Projekt oder Hobby zuwenden. Und so weiter. Du musst eben genau abgrenzen gegen wen mit welchem Mitteln das noch sicher sein muss, und ab wo Du sagst, das ist ein Risiko das akzeptiere ich.
Anscheinend bist Du selbst ja auch ein sehr potenter Angreifer gegen den Du Dich schützen willst. Da Du die Kunden kennen musst um abzurechnen, und Zugriff auf die gespeicherten Daten und die Verkehrsdaten hast von den Zugriffen der Kunden auf ihre Daten, ist das alleine schon mal eine interessante Nuss.
@meego:
Wenn ich Dich richtig verstehe, gehts Dir hauptsächlich um die Verschleierung des Ursprungs der Daten. Im Prinzip kollidiert das mit der Art und Weise, wie unsere heutige Netzwerkinfrastruktur aufgebaut ist, welche auf schnelle, kurze Routen zwischen Absender und Empfänger optimiert ist.
Du bräuchtest eine Art Subnetz-Struktur/Protokoll, welche die Daten in einem Peer-to-Peer-Netzwerk zirkulieren lässt und ein Datum nur noch über ein Hashtag identifizierbar ist. Wenn jeder Knoten zufällig exit- oder entry-Knoten sein kann, ist nicht mehr ersichtlich, welcher Knoten die Daten generiert hat. Nach diesem Prinzip arbeitet z.B. das vielgescholtene Freenetprojekt, Tor als eine Art Proxy-Kaskade arbeitet ähnlich. Nur wer garantiert Dir, dass das Netz/die Knoten nicht selbst unterwandert sind? Der Ansatz steht und fällt quasi mit der Anzahl vertrauenswürdiger Knoten, die ich als Nutzer vom entry bis exit im Mittel durchlaufen kann.
Wenn die Daten nur noch per Hashtag identifizierbar sind, kennst auch Du als "Betreiber" die Person nicht mehr - vorausgesetzt, der Inhalt der Daten lässt keine weiteren Rückschlüsse zu.
Wenn ich Dich richtig verstehe, gehts Dir hauptsächlich um die Verschleierung des Ursprungs der Daten. Im Prinzip kollidiert das mit der Art und Weise, wie unsere heutige Netzwerkinfrastruktur aufgebaut ist, welche auf schnelle, kurze Routen zwischen Absender und Empfänger optimiert ist.
Du bräuchtest eine Art Subnetz-Struktur/Protokoll, welche die Daten in einem Peer-to-Peer-Netzwerk zirkulieren lässt und ein Datum nur noch über ein Hashtag identifizierbar ist. Wenn jeder Knoten zufällig exit- oder entry-Knoten sein kann, ist nicht mehr ersichtlich, welcher Knoten die Daten generiert hat. Nach diesem Prinzip arbeitet z.B. das vielgescholtene Freenetprojekt, Tor als eine Art Proxy-Kaskade arbeitet ähnlich. Nur wer garantiert Dir, dass das Netz/die Knoten nicht selbst unterwandert sind? Der Ansatz steht und fällt quasi mit der Anzahl vertrauenswürdiger Knoten, die ich als Nutzer vom entry bis exit im Mittel durchlaufen kann.
Wenn die Daten nur noch per Hashtag identifizierbar sind, kennst auch Du als "Betreiber" die Person nicht mehr - vorausgesetzt, der Inhalt der Daten lässt keine weiteren Rückschlüsse zu.
@BlackJack: Stimmt, wenn ich ihm Benutzername und Passwort schicke, wäre das wohl so. Aber was wenn ich ihm nur eine Anleitung der Benutzernamen und Passwortvorgaben schicke?
Gegen den NSA wird man sich nicht schützen können. Ich denke, der existenzbedrohende Albtraum für dieses Gedankenexperiment wäre wohl, wenn jemand die Nutzer ihren Daten zuordnen könnte und dann den Betreiber damit erpresst oder sie an einen Dritten verkauft. Eigentlich wäre schon die reine Tatsache, dass das einer geschafft hat existenzbedrohend. Stell' dir mal vor (um ein extremes Beispiel zu nehmen) jemand würde beim DNA-Service 23andme DNA-Daten den Kunden zuordnen und beispielsweise an eine Krankenkasse verkaufen. Die Firma wäre morgen weg vom Fenster. Hmm.. vielleicht wäre es interessant zu gucken, wie die das machen und sich offenbar nicht viele daran stören.
Ich persönlich nicht, aber wenn man das Gedankenexperiment weiter denkt, könnte der Angreifer ja auch ein interner Mitarbeiter sein. Kommt in den besten Schweizer Banken vor.
Gegen den NSA wird man sich nicht schützen können. Ich denke, der existenzbedrohende Albtraum für dieses Gedankenexperiment wäre wohl, wenn jemand die Nutzer ihren Daten zuordnen könnte und dann den Betreiber damit erpresst oder sie an einen Dritten verkauft. Eigentlich wäre schon die reine Tatsache, dass das einer geschafft hat existenzbedrohend. Stell' dir mal vor (um ein extremes Beispiel zu nehmen) jemand würde beim DNA-Service 23andme DNA-Daten den Kunden zuordnen und beispielsweise an eine Krankenkasse verkaufen. Die Firma wäre morgen weg vom Fenster. Hmm.. vielleicht wäre es interessant zu gucken, wie die das machen und sich offenbar nicht viele daran stören.
Ich persönlich nicht, aber wenn man das Gedankenexperiment weiter denkt, könnte der Angreifer ja auch ein interner Mitarbeiter sein. Kommt in den besten Schweizer Banken vor.
@Jerch
Was ist mit einem vermaschten Netz, wie es in Sachen Hongkongproteste (https://de.wikipedia.org/wiki/Firechat) zu vernehmen war? Gibt es das nur Wireless?
Oder eine zweite öffentlich überprüfbare Instanz der Firma aufbauen, die nur für diese Randomierung aus Datenschutzgründen verantwortlich ist und die Pakete dann an die eigentliche Firma weitersendet? Damit könnte ein potenter Angreifer auch davon abgehalten werden Knoten zu besetzen.
Was versteht man unter einem Hashtag? (Ich kenne den Begriff nur im Sinne von Twitter/Facebook.)
Was ist mit einem vermaschten Netz, wie es in Sachen Hongkongproteste (https://de.wikipedia.org/wiki/Firechat) zu vernehmen war? Gibt es das nur Wireless?
Oder eine zweite öffentlich überprüfbare Instanz der Firma aufbauen, die nur für diese Randomierung aus Datenschutzgründen verantwortlich ist und die Pakete dann an die eigentliche Firma weitersendet? Damit könnte ein potenter Angreifer auch davon abgehalten werden Knoten zu besetzen.
Was versteht man unter einem Hashtag? (Ich kenne den Begriff nur im Sinne von Twitter/Facebook.)
@meego:
Ein Tag ist ein Etikett, ein Hashtag halt ein Etikett mit einem Hash-Wert. Die Bezeichnung Hashtag für die Twitterkürzel finde ich eher verwirrend
Für Deine Ansprüche an ein solches Netz ist es wichtig, dass die Route durch das Netz ( entry - xy-random-Knoten - exit) nicht vorbestimmt ist bzw. nicht rückwirkend nachvollzogen werden kann. Prinzipiell können vermaschte Netze das leisten, wenn das Routingprotokoll von dem Normalanspruch "bringe auf möglichst kurzem schnellen Wege die Info zum Ziel" abweicht und die Daten keine Info über den Ersteller mittragen. Letzteres ist schwierig, da solche Netze auch den Rückkanal möglichst einfach vorhalten sollen. Mit verschlüsselten Nachrichten, welche nur noch über den Hash vom Ersteller identifiziert werden können, wird dann das Routing sehr aufwendig, da im Zweifelsfalle alle Knoten durchlaufen werden müssen, um dem Absender eine Antwort zu präsentieren. Zusätzlich müssten die Knoten in Unkenntnis darübergelassen werden, ob es in der Nachbarschaft einen Treffer gab. Der Traffic durch einen Knoten würde damit exponentiell steigen.
Die Bündelung in eine "öffentliche" Instanz widerspricht Deinem Anspruch, da jedwede zentrale Struktur eine Steilvorlage für Angriffe darstellt.
Ein Tag ist ein Etikett, ein Hashtag halt ein Etikett mit einem Hash-Wert. Die Bezeichnung Hashtag für die Twitterkürzel finde ich eher verwirrend
Für Deine Ansprüche an ein solches Netz ist es wichtig, dass die Route durch das Netz ( entry - xy-random-Knoten - exit) nicht vorbestimmt ist bzw. nicht rückwirkend nachvollzogen werden kann. Prinzipiell können vermaschte Netze das leisten, wenn das Routingprotokoll von dem Normalanspruch "bringe auf möglichst kurzem schnellen Wege die Info zum Ziel" abweicht und die Daten keine Info über den Ersteller mittragen. Letzteres ist schwierig, da solche Netze auch den Rückkanal möglichst einfach vorhalten sollen. Mit verschlüsselten Nachrichten, welche nur noch über den Hash vom Ersteller identifiziert werden können, wird dann das Routing sehr aufwendig, da im Zweifelsfalle alle Knoten durchlaufen werden müssen, um dem Absender eine Antwort zu präsentieren. Zusätzlich müssten die Knoten in Unkenntnis darübergelassen werden, ob es in der Nachbarschaft einen Treffer gab. Der Traffic durch einen Knoten würde damit exponentiell steigen.
Die Bündelung in eine "öffentliche" Instanz widerspricht Deinem Anspruch, da jedwede zentrale Struktur eine Steilvorlage für Angriffe darstellt.