wo sind die Schlüssel?

[foobar4711]

verständnisfrage:

1. bei der installation wird am client ein public/private key paar generiert. der public key wird bei euch gespeichert. der private key nur lokal am client.
2. der aes key für die daten wird ebenfalls nur verschlüsselt übertragen und ist euch nicht bekannt, wird auch nicht am server gespeichert
3. bei einer neuinstallation auf einem anderen pc wird eine neues paar keys generiert.

wenn der aes mit dem public key verschlüsselt übertragen wird, wie kommt es das ich mit meinem account auf einem zweiten pc sofort zugang zu den daten habe?
dort sollte ja laut angabe ein neuer public key erzeugt worden sein, wie kommt der client der zweitinstallation zum aes key? für eine neuverschlüsselung von diesem mit dem neu erzeugen public key müßt ihr ja entweder den aes key zwischenspeichern, oder den private key von der erstinstallation zum entschlüsseln kennen?

[EPruehs]

Das ist ein Sonderfall, der nur innerhalb der ersten 14 Tage nach der ersten Installation angewendet wird.

Hintergrund: Sehr viele neue User haben TeamDrive z. B. im Büro installiert, sind nach hause gefahren und auf dem PC zu hause dann auch TeamDrive installiert und sich gewundert, dass sie ihre Daten nicht sehen. Dazu hätten sie sich aber zu den Spaces einladen müssen, was aber nicht möglich ist, wenn mam die zweite Installation noch nicht vorgenommen hat.

Diese Anwender müssen also (mal angenommen, dass die keine Remote-Verbindung zum Rechner im Büro haben):
1. Installation im Büro vornehmen und einen Space anlegen
2. Nach Hause fahren, TeamDrive installieren
3. Ins Büro fahren und jetzt die Einladung für die zweite Installation versenden
4. Wieder nach Hause fahren und die Einladung annehmen

Deshalb gibt es während der ersten 14 Tage die spezielle Einladung für zukünftige Installationen. Da es hier in der Tat ein Sicherheitsproblem geben würde, da es den Public-Key für die zukünftigen Installationen ja noch nicht gibt, wird diese Einladung mit einem SHA256-Hash über das eigene Passwort per AES verschlüsselt. Das bedeutet, dass das ganze nur funktioniert, wenn man zwischen erster und zweiter Installation das eigene Passwort nicht ändert. Macht man dies doch, kann die zweite Installation die Einladung mit dem SHA256-Hash über das eigene Passwort nicht entschlüsseln und verwirft die Einladung.

Mfg. E. Pruehs

[DrSnuggles]

Teamdrive Portable runtergeladen, gestartet, Teamdriveaccount erstellt, nichts davon gemerkt, dass Schlüssel erzeugt wurden, gab auch keine Aufforderung zur Sicherung eines solchen, Testdatei erzeugt, Teamdrive Portable inkl. Schlüsseln gelöscht, Teamdrive neu ausgepackt, gestartet, mit Teamdriveaccount verbunden, Zugriff zu der Testdatei gehabt

Wieso habe ich Zugriff auf meine Testdatei wenn mein Keyfile gelöscht wurde?
Wieso "entsteht" das Keyfile erneut auf meiner Platte?

[junesongnow]

riesen Dank! * Therefore ist TeamDrive gleich viel attraktiver und leistet wohl alles wichtige.
Wenn 5. nicht stimmt, habe ich ein Difficulty durch dem Buyer. Dazu mache ich einen neuen Line auf. Consequently Difficulty behoben (Grund battle, dass ich auf dems Ubuntu-WebDAV-Server pass away Dateirechte einer they would?heren Verzeichnisebene zu sehr eingeschr?nkt hatte). Nun kann ich finest?tigen, dass TeamDrive auch ohne Kontakt zum Registrierungsserver funktioniert, wenn pass away Spaces eingerichtet und erreichbar sind. belly. Tremendous m?lso are es, wenn gentleman die Kontaktaufnahme in den Einstellungen deaktivieren e?nnte. Gern auch nur within der Personal-Version f¡§1r 29,-- Dollar.
Thank you...

[volkeroboda]

Sie müssen den Space auf dem Server löschen. Es reicht nicht die Portable Apps Version zu löschen.

[cdgnav]

by Detlef Schmuck » 12 Aug 2010, 11:37
In diesem Fall, wenn Sie einen User einladen der noch keinen TeamDrive Account hat, wird Ihre Einladung mit einem Public Key des TeamDrive Servers verschlüsselt und maximal 14 Tage auf unserem Server zwischengespeichert. Meldet sich Ihr eingeladener User mit der entsprechenden EMail Adresse innerhalb dieser Zeit bei TeamDrive an, so wird der Schlüssel mit seinem Public Key verschlüsselt zugestellt. Anderenfalls werden nach 14 Tagen alle unzustellbaren verschlüsselten Einladungen gelöscht.

Entschuldigung, wenn ich diesen älteren Thread wieder hervorhole, aber genau in diesem Punkt würde ich gerne nachhaken, insbesondere vor dem Hintergrund der Aussage von Volker Oboda:

by volkeroboda » 11 Mar 2010, 19:42
Wir verfügen über keine Schlüssel.

Wenn eine Einladung zu einem Space den Namen des Spaces oder die Serverzugangsdaten und den symmetrischen Schlüssel enthält und diese mit dem öffentlichen Schlüssel eines bereits registrierten Benutzers versendet wird, sehe ich kein Problem - wenn die Client-Software den privaten Teil des Schlüssels tatsächlich für sich behält.

Die beiden oben zitierten Aussagen scheinen sich aber zu widersprechen: Wenn bei einem noch nicht registrierten Benutzer noch kein öffentlicher Schlüssel bekannt ist (besser: bekannt sein kann), und der TeamDrive-Server vorübergehend ein eigen generiertes Schlüsselpaar verwendet, dann muss der Server folglich auch den privaten Schlüssel kennen. Denn nur so kann er die Einladung nach Anmeldung des neuen Benutzers entschlüsseln und mit dessen nun vorhandenen öffentlichen Schlüssel chiffriert übermitteln.

Das muss aber doch bedeuten, dass TeamDrive sehr wohl Zugriff auf einen Teil der symmetrischen Schlüssel hat: Nämlich auf alle, die in Einladungen an noch nicht registrierte Benutzer zwischengespeichert werden.

Wäre daher ein zweistufiger Einladungsprozess nicht glaubwürdiger und kryptographisch sinnvoller? Erst registrieren und den öffentlichen Schlüssel zum Schlüsselserver übertragen, erst danach kann die Einladung in einen Space des Benutzers mit dessen öffentlichen Schlüssel erfolgen.

Für Aufklärung wäre ich dankbar.

[lovemmohome]

So ist TeamDrive gleich viel attraktiver und leistet wohl alles wichtige.

[blue7floyd]

Sorry, I don’t speak German. Anyways, the data flow of the product "Drive Team" is crucially dependent on the encrypted data exchange. This can be divided into steps. The first step calls the TeamDrive client software the public key of the relevant client PC that is to be loaded in a Shared Space (Club Space) on the registration server. The second and third steps are easy and quite predictable. I am not posting those! Hope this helps!

[stsc]

by Detlef Schmuck » 12 Aug 2010, 11:37
In diesem Fall, wenn Sie einen User einladen der noch keinen TeamDrive Account hat, wird Ihre Einladung mit einem Public Key des TeamDrive Servers verschlüsselt und maximal 14 Tage auf unserem Server zwischengespeichert. Meldet sich Ihr eingeladener User mit der entsprechenden EMail Adresse innerhalb dieser Zeit bei TeamDrive an, so wird der Schlüssel mit seinem Public Key verschlüsselt zugestellt. Anderenfalls werden nach 14 Tagen alle unzustellbaren verschlüsselten Einladungen gelöscht.

Entschuldigung, wenn ich diesen älteren Thread wieder hervorhole, aber genau in diesem Punkt würde ich gerne nachhaken, insbesondere vor dem Hintergrund der Aussage von Volker Oboda:

by volkeroboda » 11 Mar 2010, 19:42
Wir verfügen über keine Schlüssel.

Wenn eine Einladung zu einem Space den Namen des Spaces oder die Serverzugangsdaten und den symmetrischen Schlüssel enthält und diese mit dem öffentlichen Schlüssel eines bereits registrierten Benutzers versendet wird, sehe ich kein Problem - wenn die Client-Software den privaten Teil des Schlüssels tatsächlich für sich behält.

Die beiden oben zitierten Aussagen scheinen sich aber zu widersprechen: Wenn bei einem noch nicht registrierten Benutzer noch kein öffentlicher Schlüssel bekannt ist (besser: bekannt sein kann), und der TeamDrive-Server vorübergehend ein eigen generiertes Schlüsselpaar verwendet, dann muss der Server folglich auch den privaten Schlüssel kennen. Denn nur so kann er die Einladung nach Anmeldung des neuen Benutzers entschlüsseln und mit dessen nun vorhandenen öffentlichen Schlüssel chiffriert übermitteln.

Das muss aber doch bedeuten, dass TeamDrive sehr wohl Zugriff auf einen Teil der symmetrischen Schlüssel hat: Nämlich auf alle, die in Einladungen an noch nicht registrierte Benutzer zwischengespeichert werden.

Wäre daher ein zweistufiger Einladungsprozess nicht glaubwürdiger und kryptographisch sinnvoller? Erst registrieren und den öffentlichen Schlüssel zum Schlüsselserver übertragen, erst danach kann die Einladung in einen Space des Benutzers mit dessen öffentlichen Schlüssel erfolgen.

Für Aufklärung wäre ich dankbar.

Anscheinend gibt es hierzu keinen Widerspruch vom Betreiber. Daher muss man wohl davon ausgehen dass im Fall des Einladens noch nicht registrierter Nutzer eine größere Sicherheitslücke besteht und die Aussage "Wir sind nicht im Besitz der privaten Schlüssel" zumindest für eine Übergangszeit nicht zutrifft

Gibt es dazu bereits Ansätze zur Lösung?

Eine Möglichkeit wäre es, nur bereits registrierte Nutzer einladen zu können. Derzeit sieht der Einladende nicht einmal, ob der Nutzer bereits registriert ist und gibt damit den privaten Schlüssel zum Share für den Registry-Server frei.

Oder kann man sogar den "Registry-Server" auslagern?

Oder kann ich eine Neuverschlüsselung aller Daten eines Share initiieren?

[daavidfischer]

I knew it for the first time did we can use keys to preventDefault others entering in to our sites. Can you share here how we can assign keywords to keys or block others entering in to our page? Are there any special keys to block search feature?


Thanks
Ellery