Hallo, die Frage mag etwas komisch sein - aber gibt es irgendwelche Tools, Filesysteme, Container, ... womit man eine Verschlüsselung realisieren kann, bei der der notwendige Key nach einer gewissen Zeit ungültig wird? Also in etwa so wie LUKS ... nur das einzelne Keys ab einem definierbaren Zeitpunkt nicht mehr nutzbar sind.
Ich denke nicht, weil man einfach die Uhr zurückdrehen kann.
Peter II schrieb: > Ich denke nicht, weil man einfach die Uhr zurückdrehen kann. Dann speichert man minütlich die größte Zeit und kontrolliert so ein zurück stellen bzw betreibt einen NTP-Server...
Was möchtest du erreichen? Niemand hält dich davon ab zu einem Schlüssel noch ein Ablaufdatum zu hinterlegen.
Informatiker schrieb: > Dann speichert man minütlich die größte Zeit und kontrolliert so ein > zurück stellen bzw betreibt einen NTP-Server... dann kopiere ich das tool auf einen PC wo die zeit nicht gespeicher ist und ich meinen eigenen NTP betreibe.
nein geht nicht, zumindest nicht wirklich sicher. evtl könnte man hardware bauen (einen usb-dongle z.b.) die eine interne uhr hat, und an die verschlüsselte daten gesendet werden muss um sie zu entschlüsseln - praktisch eine entschlüsselungs-blackbox. aber selbst das ist nur eine hürde die "sicher" ist weil die meißten sowas nicht reverse-engineeren können. was ist denn dein einsatzgebiet? von der pullerei beschlagnahmte platten die nach einem halben jahr in der aservatenkammer nicht mehr entschlüsselbar sein sollen?
Läubi .. schrieb: > Was möchtest du erreichen? Niemand hält dich davon ab zu einem Schlüssel > noch ein Ablaufdatum zu hinterlegen. Ziel wäre es, eine Möglichkeit zu haben, mit der man eine Datei weitergeben kann ... die für den Empfänger ab einen gewissen Zeitpunkt wertlos, weil nicht mehr öffenbar, wird.
hm. jetzt denk doch mal nach. wenn der empfänger den container öffnen kann und dateien daraus lesen kann... dann kann er die dateien auch kopieren bevor dein container ungültig würde.
Stefan schrieb: > Ziel wäre es, eine Möglichkeit zu haben, mit der man eine Datei > weitergeben kann ... die für den Empfänger ab einen gewissen Zeitpunkt > wertlos, weil nicht mehr öffenbar, wird. und wenn er sich noch den öffnen kopiert? Dann muss er später auch nicht noch mal entschlüsseln. - es geht nicht!
Hallo, das geht nur mit Tonbändern, die sich in Rauch auflösen wie in Mission Impossible, und auch da nur im Film - ich würde halt beim Abhören eine Audioaufnahme mitlaufen lassen. Auch ein Sprengsatz in der Festplatte, der durch Inaktivität gezündet wird, würde nur was nützen, wenn keiner damit rechnet, aber ein forensisches Labor z.B. sollte als allererstes eine Kopie eines Datenträgers anlegen, weil man nicht mit dem Original arbeitet wenn möglich. Gruss Reinhard
Unsere Regierung hat doch neuerlich mal viel Geld in so einen Schwachsinn gesteckt, obwohl man von allen Seiten die Hinfälligkeit des Konzeptes bestätigt hat. http://de.wikipedia.org/wiki/X-pire! http://www.backes-srt.de/produkte/x-pire/ Tragisch ist immer nur, wie viele sich von sowas blenden lassen.
Sven P. schrieb: > Unsere Regierung hat doch neuerlich mal viel Geld in so einen > Schwachsinn gesteckt, obwohl man von allen Seiten die Hinfälligkeit des > Konzeptes bestätigt hat. Naja ... gaaaaanz so blöd kann's ja nicht sein. das ganze Kindle Zeugs, Spotify, ... basiert letztlich auf sowas ... Die Frage (für mich) wäre nur, gibt es dafür ein Standard-Dateiformat - oder geht das nur mir spezieller Software und Clients ...
echt jetzt... nachdenken, links lesen, nachschauen was DRM ist, vergleichen mit verschlüsselten containern, und nochmal nachdenken. wenn du dein konkretes problem schilderst kann dir vielleicht geholfen werden.
Es ginge schon wenn man eine nicht angreifbare zentrale Stelle hätte die Teil des Verschlüsselungsweges wäre und zu gegebener Zeit inaktiv gesetzt würde.
Andy D. schrieb: > Es ginge schon wenn man eine nicht angreifbare zentrale Stelle hätte die > Teil des Verschlüsselungsweges wäre und zu gegebener Zeit inaktiv > gesetzt würde. und auch damit kann man nicht verhindert, das eine kopie der entschlüsselten daten rechtzeitig gespeichert wird. Oder sogar der Schlüssel von der Zentralen stelle sich gemerkt wird.
Peter II schrieb: > Andy D. schrieb: >> Es ginge schon wenn man eine nicht angreifbare zentrale Stelle hätte die >> Teil des Verschlüsselungsweges wäre und zu gegebener Zeit inaktiv >> gesetzt würde. > > und auch damit kann man nicht verhindert, das eine kopie der > entschlüsselten daten rechtzeitig gespeichert wird. Oder sogar der > Schlüssel von der Zentralen stelle sich gemerkt wird. man könnte einen vnc zugang ohne datenaustauschmöglichkeit gewähren. kommt halt darauf an was der TO eigentlich will.
c. m. schrieb: > man könnte einen vnc zugang ohne datenaustauschmöglichkeit gewähren. > kommt halt darauf an was der TO eigentlich will. dann kann ich immer noch ein Screenshot machen oder abfotografieren oder Bildschirm auf Kopierer legen.
richtig. aber z.b. datenbanken kopieren ginge erheblich schwerer datensatzweise anstatt die datafiles rüber zu ziehen.
Wonach du fragst ist eigentlich "nur" ein neuer Aufguss von DRM mit all seinen Problemen. Sobald jemand die Datei einmal rechtzeitig entschlüsselt hat kann dein DRM in nicht mehr behindern. Darüber hinaus müsste die Zeit von einem vertrauenswürdigen Dritten (Notar) kontrolliert werden. Versuche eine andere Lösung für dein Problem zu finden. DRM ist eine Sackgasse.
Stefan schrieb: > Die Frage (für mich) wäre nur, gibt es dafür ein Standard-Dateiformat - > oder geht das nur mir spezieller Software und Clients ... Die Frage ist schon falsch - eine Softwarelösung, die einen Key X vor dem Zeitpunkt Y akzeptiert und danach nicht mehr, ist im Prinzip eine freiwillige Lösung, man kann die Software ja jederzeit dahingehend ändern, dass sie den Schlüssel ohne Zeitbegrenzung verwenden kann. Per Software allein ist das Problem daher unlösbar. Eben das sieht man auch an der DRM-Problematik: Software und auch Hardware, die DRM nicht beachtet (z.B. Video-Ausgabe an einen einfachen Monitor oder Festplattenrekorder), ist technisch jederzeit möglich, wird aber vertraglich oder gesetzlich verboten. Der Erfolg ist ziemlich ungewiss. Schon die einfache Frage, ob ein Laufwerk CDs/DVDs kopiert, hängt nur von einer Konvention ab, solche Geräte nicht anzubieten. Gruss Reinhard
Reinhard Kern schrieb: > Eben das sieht man auch an der DRM-Problematik: Software und auch > Hardware, die DRM nicht beachtet (z.B. Video-Ausgabe an einen einfachen > Monitor oder Festplattenrekorder), ist technisch jederzeit möglich, wird > aber vertraglich oder gesetzlich verboten. Der Erfolg ist ziemlich > ungewiss. Schon die einfache Frage, ob ein Laufwerk CDs/DVDs kopiert, > hängt nur von einer Konvention ab, solche Geräte nicht anzubieten. Und selbst das treibt mittlerweile irrsinnige Blüten. So von wegen vollverschlüsselter Videoübertragung vom Laufwerk über die Graphikkarte zum Monitor. Das alles ist auch ein verdammt guter Grund, mir keine DVDs und Musik-CD mehr zu kaufen. Wenn die nicht wollen, dass ich die Dinger abspiele, dann will ich sie auch nicht mehr bezahlen. Ich hab die Schnauze voll davon, mich pauschal kriminalisieren zu lassen. Es ist doch lachhaft, dass ich als 'gesetztestreuer', zahlender Kunde mehr Sch** am Bein hab, um ne dämliche CD ans Laufen zu kriegen, als mit einer Raubkopie.
Stefan schrieb: > bei der der notwendige Key nach einer gewissen Zeit ungültig wird? Nimm eine übliche Diskette! Die ist in wenigen Jahren nicht mehr lesbar. Im Endeffekt ist die ganze Geheimnsituerei ein Schuss ins eigene Knie weil es die Verbreitung, Bearbeitung und Datensicherung nur behindert. Nützlicher als eine Gängelung der Kunden ist ein sinnvoller Service, der die Kunden mit frischer Ware versorgt. Dann landen die veralteten Sachen automatisch im Abfall (Beispiel Diskette).
Alexander Bröcker schrieb im Beitrag #3000848: > Das ganze ist nur mit sehr viel Aufwand möglich und auch dann gibt es > immer noch Schwachstellen. Eine mögliche Lösung die ich mal gebaut habe > war eine Server - Client Variante. Der Server gibt nur mit AES > verschlüsselte Daten an den Client über eine SSL gesicherte Verbindung. > Dieser benutzt nur die Daten im RAM und speichert sie nicht. Im Client > gibt es ein paar nette Fallen für die üblichen Hacktools die im RAM > rumstöbern. Und der Server hat die Info ob dieser Client die Daten noch > abrufen darf. Und bei jeder Übertragung werden neue Schlüssel > vereinbart. Das gibt ein Stück Sicherheit. Und im RAM liegen die Daten natürlich schön. Hat man nur nicht allzuviel davon. Kopierschutz war schon immer, ist und wird auch immer eine Totgeburt bleiben. Egal, mit welchen krampfhaften Krücken die Musi^W^W^W^WIndustrie sich am Gegenteil versucht. Tragisch ist nur, wie viele Leute tatsächlich bereit sind, sich davon diktieren zu lassen, was sie mit ihrem (bezahlten) Eigentum machen.
>> rumstöbern. Und der Server hat die Info ob dieser Client die Daten noch >> abrufen darf. Und bei jeder Übertragung werden neue Schlüssel >> vereinbart. Das gibt ein Stück Sicherheit. ... und wer solchen Mist kauft, kann auch seine Firma damit gründlich ruinieren wenn das hochgelobte Programm aus irgendeinem Grund mal nicht mehr funktioniert. Ähnlich schon erlebt mit verstorbenen SW-Hersteller.
Also zusammengefasst * Ja, man kann Files verschlüsseln. * Nein, du kannst nicht dem File an sich sagen, dass es nicht mehr geöffnet werden kann. Ein File ist kein aktives Element. Aktives Element ist ein Programm und das kann Information im File benutzen um es als abgelaufen zurückzuweisen * Ja, man kann den Aufwand beliebig hoch treiben * Nein, in letzter Konsequenz kann man keinen 100% Schutz erreichen. In dem Moment, in dem die Daten prinzipiell lesbar wären, gibt es auch eine Möglichkeit an allen Schutzmechanismen vorbei an die Daten ranzukommen. * Schutzmechanismen halten nur Greti und Pleti davon ab, die Daten missbräuchlich zu verwenden (und in vielen Fällen noch nicht mal das). Jemanden, der sein Handwerk versteht und keine Angst vor Bits und Bytes hat, kannst du damit auf Dauer nicht aufhalten. Es ist wie bei Viren. Die einzige Möglichkeit garantiert keinen Virus einzufangen ist es, keinerlei Datentransfer von/nach aussen zuzulassen. Kein Internet, keine Disketten, kein USB Stick, keine CD, kein gar nichts. Der Rechner wird einmalig aufgesetzt und dabei bleibt es auch. In dem Moment, in dem es ein Tor 'nach draussen' gibt, gibt es auch eine Möglichkeit Viren einzuschleusen. Die einzige Möglichkeit niemals zu sterben ist es, niemals geboren worden zu sein. Und wer will das schon.
Karl Heinz Buchegger schrieb: > Die einzige Möglichkeit niemals zu sterben ist es, niemals geboren > worden zu sein. ja, das leben ist ein scheiß computerspiel - die grafik ist einfach super, aber am ende stirbt man - ganz egal was man macht...
@oszi40 Fail-Safe vs Fail-Deadly .. Beides kann erwünscht/notwendig sein. Schlüsselmanagement - und wie mit den unverschlüsselten Daten umgegangen wird, zB ob von diesen eine nicht oder anders geschützte Kopie erstellt wird - sind kein Problem des Kryptosystems an sich.
Andy D. schrieb: > sind kein Problem des Kryptosystems an sich. Krypto ist nur solange nützlich, wie man SELBST bestimmen kann, wann was wie verschlüsselt wird. Bei mir besteht jedoch der Verdacht, daß wir in 20 Jahren ziemlich viele wertvolle Daten damit vergraben haben, die dann auf dem Müllplatz der Geschichte landen (Digitale Demenz). Beispiel dafür sind zahlreiche verschlüsselte .pdf , die heute für Studenten bereitgestellt werden. Im Gegensatz zu Büchern wird in wenigen Wochen das PW für diese Daten vergessen/verloren sein. Ähnliches wird z.B. in der Autoindustrie mit zahlreichen "geschützten" Steuergeräten zu erwarten sein ...
Du könntest in Deinem Programm einen wesentlichen Teil weglassen, und diese Funktion nur online, bspw. per Internetaccess verfügbar machen. Sozusagen als Blackbox, der Parameter übergeben werden, und die Ergebnisse liefert. Als Betreiber des Blackbox-Servers bestimmst Du, ob die Anfagen bedient werden, oder wegen abgelaufener Lizenz nicht mehr. Oder auch gleich mit "pay per use" abrechenen. Ist der Algorithmus dieser Blackbox hinreichend nicht-trivial und der machinenbezogen identifizierbar, wird sich niemand um den Aufwand reißen, deren Funktion Deinem Programm als Crack lokal zur Verfügung zu stellen.
Puppenspieler schrieb: > Sozusagen als Blackbox, der Parameter übergeben werden, und die > Ergebnisse liefert. Als Betreiber des Blackbox-Servers bestimmst Du, ob > die Anfagen bedient werden, oder wegen abgelaufener Lizenz nicht mehr. > Oder auch gleich mit "pay per use" abrechenen. > > Ist der Algorithmus dieser Blackbox hinreichend nicht-trivial und der > machinenbezogen identifizierbar, wird sich niemand um den Aufwand > reißen, deren Funktion Deinem Programm als Crack lokal zur Verfügung zu > stellen. wie so ein "geniale" Idee die sinnlos ist. Sobald die Daten von der Blackbox zum client geschickt wurden liegen sie dort im RAM und könnnen (einfach) gespeichert werden. Dann brauche ich die Blackbox nicht mehr.
Noch viel schöner: Jemand kauft dein Programm und du schaltest irgendwann die Server ab. Guck dich nur mal um, wie das mit Computerspielen ist, die nur mit Internetverbindung laufen. Meine Nintendo64-Spiele steck ich heute noch in die Kiste und spiele damit. Aber in zehn Jahren wird man so manchen Regalmeter an Spielen restlos entsorgen können, weil es irgendwelche Server nicht mehr gibt.
Peter II schrieb: > Sobald die Daten von der > Blackbox zum client geschickt wurden liegen sie dort im RAM und könnnen > (einfach) gespeichert werden. Ja das Ergebnis der Berechnung für einen Satz Parameter, aber nicht der Algorithmus selbst... setzen 6.
D. I. schrieb: > Ja das Ergebnis der Berechnung für einen Satz Parameter, aber nicht der > Algorithmus selbst... setzen 6. warum soll ich den Algorithmus wissen, wenn ich das ergebniss habe? (ist ja nicht wie inder schule wo ich den Rechenweg zeigen muss)
Peter II schrieb: > D. I. schrieb: >> Ja das Ergebnis der Berechnung für einen Satz Parameter, aber nicht der >> Algorithmus selbst... setzen 6. > > warum soll ich den Algorithmus wissen, wenn ich das ergebniss habe? (ist > ja nicht wie inder schule wo ich den Rechenweg zeigen muss) Naja. Weil sich die Eingaben dauernd ändern könnten und der Algo der Clou an der Sache ist und dir ein einziges Ergebniss nicht lange Freude macht. z.B. Berechnungen a la Wolfram Alpha. Da kann der Betreiber entscheiden wie lange du es nutzen kannst. Sobald er will kann er abschalten. Es gibt tausende Anwenungsbeispiele wo sowas sinnvoll ist. Aber dem TE gings darum eine Datei weiterzugeben. Und in diesem Szenario gehts halt nicht. gruß cyblord
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.