Wie funktioniert DRM genau?
-
Da das Ganze auf Verschleierung basiert nehmen die bestimmt nicht RSA, RSA kann jeder. Zumal RSA asynchron ist, was für DRM nicht sinnvoll ist.
Ich würde sowas wie Solitär nehmen. Das ist zwar nicht kryptografisch sicher aber dafür DRM-sicher, weil man keine X-beliebige Cryptolib benutzen kann um das zu entschlüsseln und auch Wiki nicht erklärt wie es funktioniert. Dann muss man selber ein Programm tippen ohne zu wissen was man eigentlich genau will und daher stehen die Chancen besser, dass man darauf keine Lust hat. Man kann noch zusätzlich AES draufklatschen, damit die Leute zwar AES entschlüsseln, aber dann trotzdem nichts lesen können und aufgeben. Oder man packt alle Cryptoverfahren, die die Cryptolib des Vertrauens anbietet, übereinander und die Reihenfolge der Verfahren ist der eigentliche Schlüssel. Da kann man sich viel ausdenken. Und am Ende findet jemand die Decryptfunktion im Programm und benutzt einfach die statt selbst was zu schreiben...
-
nwp3 schrieb:
Zumal RSA asynchron ist, was für DRM nicht sinnvoll ist.
Erzähl mehr.
-
nwp3 schrieb:
Da das Ganze auf Verschleierung basiert nehmen die bestimmt nicht RSA, RSA kann jeder. Zumal RSA asynchron ist, was für DRM nicht sinnvoll ist.
Ich würde sowas wie Solitär nehmen. Das ist zwar nicht kryptografisch sicher aber dafür DRM-sicher, weil man keine X-beliebige Cryptolib benutzen kann um das zu entschlüsseln und auch Wiki nicht erklärt wie es funktioniert. Dann muss man selber ein Programm tippen ohne zu wissen was man eigentlich genau will und daher stehen die Chancen besser, dass man darauf keine Lust hat. Man kann noch zusätzlich AES draufklatschen, damit die Leute zwar AES entschlüsseln, aber dann trotzdem nichts lesen können und aufgeben. Oder man packt alle Cryptoverfahren, die die Cryptolib des Vertrauens anbietet, übereinander und die Reihenfolge der Verfahren ist der eigentliche Schlüssel. Da kann man sich viel ausdenken. Und am Ende findet jemand die Decryptfunktion im Programm und benutzt einfach die statt selbst was zu schreiben...Dir ist doch hoffentlich klar, dass dieser Solitär-Algorithmus vollständig beschrieben ist, oder? Hier ist die Hauptseite:
https://www.schneier.com/solitaire.html
Da ist alles genau beschrieben. Am Ende der Seite finden sich sogar Bibliotheken in vielen verschienen Programmiersprachen!
Es wäre also SEHR einfach, irgendwas mit Solitär zu entschlüsseln, weil der Entwickler bereits alles mitliefert, was man braucht (Beschreibung, Bibliotheken usw.). Einfacher gehts nicht!
-
Was sind denn das für verschlüsselungs-Ansätze ?
Wenn man das prinzip kennt, darf doch eine verschluesselung nicht obsulete werden ^^ Das vorhandensein von RSA bibliotheken macht dochdie verschluesselung nicht "schlecht" / "Angreifbar" sondern das sind andere Faktoren.
Das A und O bei der Verschluesselung ist der Schluesselaustausch. Sicherer Schluesselaustausch und Schnell wechselnde Schluessel, da beist sich der Kracker die Zaehne aus.
Nur ham wir das in der Praxis meist ned ^^
Online Zwang kommt halt bei Ebooks und Bluray Medien nicht so toll, deshalb sind auch die DRM's entsprechend schwach.Juristisch gesehen ist das auch gar nicht so das Problem, da kommts nur drauf an, das es eine nicht mit "ueblichen Mitteln zu umegehende Sperre" handelt, damit man auch den Nutzer und wenig- hacker juristisch zu fassen kriegt.
Ob jetzt das umbenennen auspacken einer zip datei drunter faellt, darueber kann man streiten ^^DRM ist auch mehr nen konzept, als eine bestimmte Umestzung.
Es gibt zig Möglichkeiten DRM umzusetzen ...Ciao ...
-
Solitär- naja schrieb:
Dir ist doch hoffentlich klar, dass dieser Solitär-Algorithmus vollständig beschrieben ist, oder? Hier ist die Hauptseite:
https://www.schneier.com/solitaire.html
Da ist alles genau beschrieben. Am Ende der Seite finden sich sogar Bibliotheken in vielen verschienen Programmiersprachen!
Es wäre also SEHR einfach, irgendwas mit Solitär zu entschlüsseln, weil der Entwickler bereits alles mitliefert, was man braucht (Beschreibung, Bibliotheken usw.). Einfacher gehts nicht!Auch sehr genau beschrieben im (lesenswerten) Roman "Cryptonomicon" von Neil Stephenson,
für den Bruce Schneier den Solitär-Algorithmus entwickelt hat.
-
volkard schrieb:
nwp3 schrieb:
Zumal RSA asynchron ist, was für DRM nicht sinnvoll ist.
Erzähl mehr.
Mir fällt keine Anwendung für DRM ein, wo asynchrone Verschlüsselung sinnvoll wäre. Vielleicht bin ich nur zu unkreativ. Man könnte das E-Book signieren, aber dann kann es ja trotzdem jeder lesen. Und dem Anwender den private Key zu geben ist irgendwie kontraproduktiv.
Solitär- naja schrieb:
Da ist alles genau beschrieben. Am Ende der Seite finden sich sogar Bibliotheken in vielen verschienen Programmiersprachen!
Es wäre also SEHR einfach, irgendwas mit Solitär zu entschlüsseln, weil der Entwickler bereits alles mitliefert, was man braucht (Beschreibung, Bibliotheken usw.). Einfacher gehts nicht!Ich meine AES ist einfacher, weil man da eher dran denkt. Auf die Idee, dass in dem E-Book Solitair benutzt wird muss man erst mal kommen, AES wäre jedenfalls mein erster Tipp.
RHBaum schrieb:
Was sind denn das für verschlüsselungs-Ansätze ?
Wenn man das prinzip kennt, darf doch eine verschluesselung nicht obsulete werden ^^ Das vorhandensein von RSA bibliotheken macht dochdie verschluesselung nicht "schlecht" / "Angreifbar" sondern das sind andere Faktoren.
Die Verschlüsselung (von AES) ist sicher. Nur nützt das leider nichts, da ja der Schlüssel mitgeliefert wird. Das ist ja das paradoxe an DRM, einerseits soll es so sicher verschlüsselt sein, dass der Anwender das nicht einfach so lesen kann, gleichzeitig muss er es aber lesen können.
RHBaum schrieb:
DRM ist auch mehr nen konzept, als eine bestimmte Umestzung.
Es gibt zig Möglichkeiten DRM umzusetzen ...Es gibt nur keine Umsetzung die funktioniert. Ein E-Book, was man für eine Woche lesen kann und danach nicht mehr geht einfach nicht ansatzweise durchzusetzen.
-
nwp3 schrieb:
volkard schrieb:
nwp3 schrieb:
Zumal RSA asynchron ist, was für DRM nicht sinnvoll ist.
Erzähl mehr.
Mir fällt keine Anwendung für DRM ein, wo asynchrone Verschlüsselung sinnvoll wäre.
Mir fällt es schwer, sich ein DRM vorzustellen, welches nur auf synchroner Verschlüsselung basiert. Schließlich sind die zur Authentifizierung berechtigter Nutzer/Endgeräte notwendigen Signaturen immer asymmetrische Kryptosysteme.
Ciao, Allesquatsch
-
Allesquatsch schrieb:
Schließlich sind die zur Authentifizierung berechtigter Nutzer/Endgeräte notwendigen Signaturen immer asymmetrische Kryptosysteme.
Wer authentifiziert denn? Den Server haben wir ausgeschlossen wegen Onlinepflicht und das Programm wo das Ebook drin ist lässt sich auch leicht austricksen, indem man zum Beispiel den Publickey im Programm in seinen eigenen ändert. Zumal das auch die Daten nicht schützt.
Man könnte Hardware bauen, die sagt "Wenn im Ebook Verfallsdatum < Jetzt steht, dann zeige es nicht an" und hoffen, dass niemand ein Bit verdreht und da ein > oder gar ein == draus macht. Andere Hardware kann das Ebook dann nicht lesen, weil es den Schlüssel nicht hat, und man muss weiterhin darauf hoffen, dass niemand den Schlüssel oder die entschlüsselten Daten extrahiert.
Egal was man sich ausdenkt, es gibt immer die gigantische Lücke, dass das Endgerät zumindest vorübergehend berechtigten Zugriff hat und man den Zugriff nicht zurück nehmen kann. Ein nicht manipulierbares Endgerät halte ich für nicht realisierbar.
-
nwp3 schrieb:
Allesquatsch schrieb:
Schließlich sind die zur Authentifizierung berechtigter Nutzer/Endgeräte notwendigen Signaturen immer asymmetrische Kryptosysteme.
Wer authentifiziert denn? Den Server haben wir ausgeschlossen wegen Onlinepflicht
Warum eigentlich? Bei der Onleihe gibt es Onlinepflicht. Siehe http://userforum.onleihe.de/index.php?page=LexiconItem&id=19
-
Anmerker schrieb:
Warum eigentlich? Bei der Onleihe gibt es Onlinepflicht. Siehe http://userforum.onleihe.de/index.php?page=LexiconItem&id=19
Ja, es herrscht (laut der verlinkten Webseite) Onlinepflicht, wenn man die Lizenzen verlängern (und nur dann) will.
Aber das eigentliche Problem an DRM wurde hier ja schon beschrieben:
Die Schlüssel müssen irgendwo auf dem Lesegerät abgespeichert sein, d.h. ich als Leser, bzw. Besitzer dieses Readers habe (theoretisch) den vollen Zugriff auf diese Schlüssel.
Der normale Leser wird damit nichts anfangen können, aber es gibt bestimmt irgendwo einen interessierten Ingenieur, der seinen Reader auseinanderbaut, um die Schlüssel zu extrahieren (oder wie sollen sonst diese ganzen "Tools", nennen wir sie mal so, entstanden sein?).Wenn die Lizenzen abgelaufen sind, dann passiert wahrscheinlich garnichts. Das ebook ist weiterhin aufm Speicher des Lesegeräts. Entweder hat das Lesegerät irgendwo eine kleine Batterie, die dafür sorgt, dass Zeit/Datum richtig sind (auch wenn der Reader aus ist) oder die Zeit wird online synchronisiert (ich denke mal, dass die meisten Reader beides haben/machen).
In diesem Schlüssel muss irgendwo ein genaues "Ablaufdatum" gespeichert sein, wenn das überschritten ist, weigert sich der Reader einfach, das ebook anzuzeigen. Das ist, sofern ich das jetzt richtig verstanden habe, des Pudels kern.
Nicht das DRM schützt das ebook, sondern der Reader.
-
nwp3 schrieb:
Allesquatsch schrieb:
Schließlich sind die zur Authentifizierung berechtigter Nutzer/Endgeräte notwendigen Signaturen immer asymmetrische Kryptosysteme.
Wer authentifiziert denn?
Zwangsweise muss sich das berechtigte Gerät oder der berechtigte Benutzer in irgendeiner Weise authentifizieren, damit ein Rechte-Management überhaupt Sinn macht. Eine Rechtevergabe baut immer darauf auf, dass man eine berechtigte Klasse authentifizieren kann.
Ciao, Allesquatsch
-
ja, aber......... schrieb:
Aber das eigentliche Problem an DRM wurde hier ja schon beschrieben:
Die Schlüssel müssen irgendwo auf dem Lesegerät abgespeichert sein, d.h. ich als Leser, bzw. Besitzer dieses Readers habe (theoretisch) den vollen Zugriff auf diese Schlüssel.
Der normale Leser wird damit nichts anfangen können, aber es gibt bestimmt irgendwo einen interessierten Ingenieur, der seinen Reader auseinanderbaut, um die Schlüssel zu extrahieren (oder wie sollen sonst diese ganzen "Tools", nennen wir sie mal so, entstanden sein?).Jepp, dass ist der Casus Kancktus.
Wird meist in separater Hardware realisiert, dass der Schlüssel selbst gar nicht im Zugriff ist, sonderm mur die Funktion zum Entschlüsseln exportiert wird. Damit liegt der Schlüssel nicht offen im Code des Gerätes herum, sondern muss aus Hardware extrahiert werden.
Das wird dann auch gemacht. Die c't hatte mal beschrieben, wie man den entsprechenden Chip so abgeschliffen hat, dass das Schaltungsschema sichtbar wurde und daraus dann der Schlüssel extrahiert werden konnte. Seitenkanalangriffe sind eine weitere beliebte Methode, bei der aus Stromverbrauch oder Laufzeit entschlüsselt wird, was in der Blackbox passiert.Reine Softwarelösungen sind natürlich gut angreifbar.
Ciao, Allesquatsch