Wie funktioniert DRM genau?
-
Hallo,
ich interessiere mich sehr für ebooks, und auch für das DRM, das die meisten Bücher, die man im Internet kaufen kann, haben.
Ich habe schon schon versucht, über Google, bzw. Wikipedia genaueres über DRM herauszufinden, aber alles was ich finde, sind "Noob-Beschreibungen" ("Was ist DRM?", "Was bedeutet DRM für mich?" usw.), also Beschreibungen für Leser ohne weiteres Interesse, bzw. technische Fähigkeiten.
http://upload-magazin.de/buch-zukunft/drm-286/
http://de.wikipedia.org/wiki/Digitale_Rechteverwaltung#Technische_UmsetzungVor allem der Wikipedia Artikel gibt nicht sonderlich viel her.
Es wird nur gesagt, dass die meisten DRM-Systeme auf "kryptografischer Verfahren" basieren.Meine Fragen sind:
1. Welche Verschlüsselung, bzw. welches "kryptografischer Verfahren" wird hier genau angewandt? Ich nehme mal stark an, dass das ganze über irgendwelche RSA-Zertifikate/RSA-Schlüssel läuft?2. Wie genau wird das mit der eventuellen zeitlichen Begrenzung gemacht? Ich habe gelesen, dass es auch schon Büchereien gibt, die ebooks zum ausleihen anbieten. Anscheinend ist es so, dass das ebook nach einer gewissen Zeit "abläuft" und dann nicht mehr gelesen werden kann.
Wie wird das gemacht? Verfällt irgendwann der Schlüssel?Ich bedanke mich schonmal im Voraus für Antworten.
-
Weiß denn keiner was zu dem Thema?
-
http://en.wikipedia.org/wiki/Digital_rights_management
Ich hab nicht reingeguckt, aber allgemein sollte dir eine englische Suche bei dem Thema mehr helfen (auch außerhalb von Wiki).
-
DRM ist eigentlich technisch nicht möglich. Es gibt keine Zertifikate die ablaufen oder überhaupt irgendeine Möglichkeit DRM zu implementieren. DRM basiert darauf, dass die Anzeigesoftware sagt "Ich habe kein Zertifikat, also zeige ich den Inhalt nicht an". Es reicht häufig ein einziges Bit zu ändern um die Software in "Ich habe kein Zertifikat, also zeige ich den Inhalt an" zu wechseln. Es gibt Ansätze wie Debuggerfallen, um die Stelle zu verstecken, aber das ist keine echte Sicherheit.
Die Verschlüsselung ist nur Verschleierung, denn das Anzeigeprogramm selbst muss ja den Schlüssel haben, also ist die Verschlüsselung wertlos.
Eine andere Möglichkeit wäre, dass sich die Software den Schlüssel von einem Server holt. Wenn der Server den Schlüssel nicht rausgibt kann der Inhalt nicht angezeigt werden, Hack hin oder her. Das Problem daran ist, dass findige Menschen einfach den Schlüssel während legitimer Benutzung mitlesen und nach Ablauf der Zeit den Server fälschen und das mitgeschnittene Passwort übergeben und es gibt nichts wirkungsvolles was man dagegen tun kann.Eigentlich basiert DRM nur darauf das Knacken so anstrengend zu machen, dass man dafür ein paar Stunden oder Tage braucht und sich dann entscheidet, dass 10 Stunden Arbeit * 20€/Stunde um DRM zu umgehen teurer ist als einfach das E-Book (erneut) zu bezahlen.
Du wirst auch keine Dokumentation zu einem DRM-Verfahren finden, denn in dem Moment wo es eine Dokumentation gibt ist es trivial zu knacken und damit kein DRM-Verfahren mehr.
-
@nwp3: Wird da teilweise nicht bereits auf End-To-End-Verschlüsselung bis in den Bildschirm hinein spekuliert? Nur noch "trusted devices" dürfen in der Kette hängen und die einzige Möglichkeit wäre es den Bildschirm abzufilmen?
MfG SideWinder
-
Und wie funktionieren die "Trusted Devices"? Da ist ein Schlüssel drin. In dem Device. Das da vor mit steht. Ist doch klar dass da irgendwer zum Schraubenzieher greift und den Schlüssel da raus holt oder den Videostream nach der Entschlüsselung abgreift oder oder oder. Und hoffentlich gibt es genug Leute, die sowas nicht kaufen, auch wenns nur einen Euro kostet und man alles umsonst kriegt (die ersten Jahre, bis die Konkurrenz tot ist).
Es ist auch mehr eine gesellschaftliche Frage. Wem gehört das Produkt dass man kauft. Wenn ich ein iPod kaufe, gehört der mir oder gehört der Apple? Wenn der mir gehört, warum schreibt mir dann Apple vor was ich installieren darf und was nicht? Wenn er Apple gehört, warum habe ich dann Geld dafür bezahlt? Darf Amazon Bücher von meinem Kindle löschen?
Aber vielleicht ist das alles auch Wunschdenken von mir. Mit Appstores steuern wir nämlich gerade darauf zu, dass Großunternehmen entscheiden was wir mit Geräten tun. Selbst Windows 8 hat einen Appstore. Und vom "Internet der Dinge" will ich gar nicht anfangen. Aber naja, hoffentlich ist die Zukunft besser als das was ich befürchte.
-
Das sind ganz andere Fragen, aber bzgl. "trusted devices": es gibt durchaus Chips die sich selbst zerstören beim Versuch die Schlüssel auf "unkovnentionelle Art" auszulesen.
MfG SideWinder
-
SideWinder schrieb:
und die einzige Möglichkeit wäre es den Bildschirm abzufilmen?
Man könnte die entschlüsselten Bits auch über den Bildschirm übertragen, in dem man sich so etwas baut, wie man es beim Online Banking bei Tan Generatoren wiederfindet.
D.h. der Bildschirm ist der bitgenaue Überträger und der Empfänger hat ein paar Fotodioden.
-
nwp3 schrieb:
DRM ist eigentlich technisch nicht möglich. Es gibt keine Zertifikate die ablaufen oder überhaupt irgendeine Möglichkeit DRM zu implementieren. DRM basiert darauf, dass die Anzeigesoftware sagt "Ich habe kein Zertifikat, also zeige ich den Inhalt nicht an". Es reicht häufig ein einziges Bit zu ändern um die Software in "Ich habe kein Zertifikat, also zeige ich den Inhalt an" zu wechseln. Es gibt Ansätze wie Debuggerfallen, um die Stelle zu verstecken, aber das ist keine echte Sicherheit.
Die Verschlüsselung ist nur Verschleierung, denn das Anzeigeprogramm selbst muss ja den Schlüssel haben, also ist die Verschlüsselung wertlos.
Eine andere Möglichkeit wäre, dass sich die Software den Schlüssel von einem Server holt. Wenn der Server den Schlüssel nicht rausgibt kann der Inhalt nicht angezeigt werden, Hack hin oder her. Das Problem daran ist, dass findige Menschen einfach den Schlüssel während legitimer Benutzung mitlesen und nach Ablauf der Zeit den Server fälschen und das mitgeschnittene Passwort übergeben und es gibt nichts wirkungsvolles was man dagegen tun kann.Eigentlich basiert DRM nur darauf das Knacken so anstrengend zu machen, dass man dafür ein paar Stunden oder Tage braucht und sich dann entscheidet, dass 10 Stunden Arbeit * 20€/Stunde um DRM zu umgehen teurer ist als einfach das E-Book (erneut) zu bezahlen.
Du wirst auch keine Dokumentation zu einem DRM-Verfahren finden, denn in dem Moment wo es eine Dokumentation gibt ist es trivial zu knacken und damit kein DRM-Verfahren mehr.
Deswegen hab ich mich auch schon gewundert.
Nehmen wir als Beispiel mal das epub-Format.
Das epub-Format ist (wie z.b. das Open-Document-Format von Open- /Libre-Office) eine (umbenannte) zip-Datei, in der xml und (x)html Dateien sind.
Bei epub ist es so, dass der Inhalt, also der Buchtext in einer xhmtl-Datei ist, das DRM ist auch in einer extra-Datei.
Was genau hindert mich also, das epub mit einem Archivprogramm (z.b. 7zip) zu öffnen, und die Inhalts-Datei zu extrahieren, bzw. gleich das DRM aus der zip-Datei zu löschen? Das ganze dauert 5 Sekunden!!!
Wie genau das bei Adobes und Amazons ebook-Format ist, weiß ich nicht.Aber kommen wir nochmal zu DRM selbst:
Von welchen "Schlüsseln" reden wir hier? Sind das jetzt RSA-Schlüssel?Es ist echt komisch, man findet im Internet mal so überhaupt nix zu dem Thema.
Soweit ich weiß, ist es auch möglich, diesen Schlüssel zu exportieren und ...
naja ihr wisst schon.Ich hätte gerne mehr Informationen.
-
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