Diskussion:High-bandwidth Digital Content Protection

Annahmen

moin, da langfristig zu erwarten ist, dass nach Einführung der Technik keine privaten TV Mitschnitte mehr möglich sein werden auf welchen statistischen erhebung beruht diese aussage? ich kann schwer davon ausgehen, dass das der unregistrierte user wus das verfasst hat. auch wenn ich da falsch liegen sollte hätt eich dazu gerne eine antwort. wenn nicht werd ich das anpassen. es wird hier in letzter zeit in dem bereich kopierschutz und HDTV/SDTV vom selben user auf das äusserste schwarz gemalt und gegen diese technik gehetzt. ich persönlich mag die auch nicht, aber es gibt andere wege das ausserhalb der enzyklopädie kund zu tun. macht dazu nen blog auf oder so aber lasst das hier aussen vor. macrovision war auch als unknackbar angesehen und was ist nun? jeder hat sich munter kopien von vhs gezogen ohne das man dagegen etwas tun konnte. so wird es wieder sein, grüße, ---horn- 14:57, 30. Jun 2005 (CEST)

Ich glaube Du übersiehst da eine Kleinigkeit: Umgehung von Kopierschutzen - egal wie simpel - ist mittlerweile strafbar. In diesen Artikel hier gehört eine gehörige Portion Kritik. Ich werde mich die Tage darum kümmern.

Einfache Überlegung: Angenommen Hinz und Kunz haben zu 70% HDCP-komp. Geräte (Lobby machts bestimmt schnell möglich), wird irgendwann der Erste aus der Content-Industrie hergehen und seinen Film-Verleih an HDCP knüpfen. Dann müssen die Sender folgen.... und schon kann der Privatmann die Sendung nicht mehr aufnehmen. -cljk 7. Jul 2005 00:34 (CEST)

PS - und nochwas... Schwarzmalerei in Bezug auf DRM und Kopierschutzkram allgemein wie die Gängelung der Content-/Film-/Musikindustrie finde ich nur zu verständlich, wer mal die Entwicklung verfolgt.... (ohne die Beiträge von WUS zu kennen)

Spontan noch ein Beispiel dazu: Überall wird die Globalisierung gefordert... Arbeitnehmer sollen Lohn einsparen, da Polen billiger Arbeiten etc. Geht es aber um die Industrie, sieht alles anders aus. VW möchte keine EG-Import Autos und die Film-Industrie schützt DVDs per Regionalcode vor Verkäufen in andere Kontinente. Noch was: Privatkopie ist erlaubt - wurde desöfteren gerichtlich bestätigt. Durch DRM an allen Ecken und Enden (z.B. gibt´s nur OnlineShops mit DRM) wird die Privatkopie dank der strafbarkeit der Umgehung des Kopierschutzes elegant abgeschaltet. Jajaaa... Aber Kopierschutz ist ja vollkommen normal und zum Vorteil des Kunden - wird ja dann alles billiger... cljk 7. Jul 2005 00:43 (CEST)

Anmerkung noch: HDCP ist nur eine von verschiedenen Forderungen der Rechteinhaber, wenn es um eine "Sicherung" von hochauflösenden Inhalten geht. Ziel scheint es tatsächlich zu sein, Privatpersonen die Aufnahme von (Kino-)Filmen in hochauflösender Qualität verbieten zu können, insbesondere die Diskussionen in Amerika um das sogenannte Broadcast Flag zeigen das deutlich. Eine weitere Sicherung kommt jetzt zum Vorschein, das ist der Vorstoß der amerikanischen Filmindustrie in Washington, ähnlich wie seinerzeit beim DAT zwingend ein Rechtemanagement für hochauflösende, digitale Videoaufnahmegeräte vorzuschreiben und dort explizit AACS zu verlangen. Es wird mitnichten so sein, daß private Aufnahmen sofort völlig verboten werden sollen, nur ist die Zielrichtung der Rechteinhaber, hochauflösende Inhalte als "Premium-Content" zu platzieren, für den man Geräte mit speziellen Anforderungen benötigt und der auch stärkeren Restriktionen unterliegt als "normaler Content". Mit anderen Worten: Der Kunde soll für neue Geräte bezahlen, für das komplizierte DRM dieser Geräte und dann zusätzlich noch einmal ordentlich für die Filme in der tollen Auflösung - HDTV ist nicht etwa als Ersatz für das niedrig auflösende Fernsehen der Gegenwart geplant, sondern soll ein gutes Zusatzgeschäft werden. Damit das alles nicht durch private Aufnahmen bei Fernsehausstrahlungen verwässert werden kann, sollen gefälligst alle Ausgabegeräte noch zusätzlich HDCP-gesicherte Bildausgänge besitzen, damit der kleine Mann wenn überhaupt dann privat nur in niedriger Auflösung aufnehmen kann. Hochauflösend soll gar keiner mehr irgend etwas aufnehmen dürfen - wenn es nicht per AACS gesichert ist, da wird dann alles nur noch direkt vom Rechteinhaber geliefert. AACS benötigt aber zur Aufnahme sinnvollerweise eine digitale, verschlüsselte Verbindung ähnlich dem verschlüsselten Firewire, hier ist noch alles völlig Zukunfsmusik, da bislang nur sehr, sehr wenige Geräte existieren, die diese Schnittstelle mit DRM unterstützen.Axel Farr 15.11.2005

Einleitung

" Nur wenn in beiden miteinander verbundenen Komponenten HDCP implementiert ist funktionieren die Schnittstellen."

Das ist IMHO falsch. Nur wenn der Player HDCP fordert, das Display (oder anderes Abspielgerät) das aber nicht kann, verweigert der Player die Informationen - bzw. der Player kann nichts damit anfangen..... -cljk 7. Jul 2005 00:54 (CEST)

Nein, das ist korrekt. Grund ist folgender: HDCP ist gedacht gewesen als Sicherung für _hochauflösende_ Inhalte, es war nie für SDTV gedacht. Um aber die Verbreitung von HDCP zu pushen, haben die Rechteinhaber im DVD-Konsortium darauf bestanden, daß der digitale Ausgang bei DVD-Playern zwingend mit HDCP ausgestattet sein muß. Die DVD selbst besitzt aber keinen Schalter, um HDCP ein- oder auszuschalten. Theoretisch ließe sich das mit dem Vorhandensein von CSS-Kodierung und/oder Macrovision-Steuerbefehlen auf einer eingelegten DVD verbinden, de Facto ist es aber so, daß ein DVD-Player mit digitalem Ausgang und HDCP dieses immer "scharf" geschaltet hat, auch wenn nur der Setup-Bildschirm des DVD-Players angezeigt wird.

Es ist interressanterweise auch so, daß es nicht immer reicht, wenn beide verbundenen Komponenten HDCP implementiert haben, z.T. kommt es auch wegen HDCP zu Kommunikationsschwierigkeiten von Geräten untereinander. Beispiel: Pioneer-DVD-Player der Oberklasse mit DVI und Projektor PT-AE500 von Panasonic.

Hinzu kommt, daß die Hersteller von Wiedergabegeräten zwar keine Probleme haben, anzugeben, daß ihr Gerät HDCP am Ausgang hat. Hersteller von Ausgabegeräten aber schon. Das ist wohl erst durch das HD-ready-Logoprogramm etwas besser geworden. Besagter Projektor hat zwar laut Prospektangaben HDCP am DVI-Eingang, aber im Benutzerhandbuch und den technischen Daten wird kein HDCP erwähnt - bei Nichtfunktion könnte ja ein Kunde einen Mangel diagnostizieren. -Axel Farr 15.11.2005

Einsatz im Computer

Den Absatz über den Einsatz im Computer hat jemand total verwurstet, dass er a) falsch ist und b) IMHO unsinnig. -cljk 09:33, 22. Aug 2005 (CEST)

Lik-Sang?????

Was bitte hat der Import von Spielen mit HDCP zu tun?????? Bitte entfernen o. umbauen - sonst mach ich es (entfernen) -cljk 16:06, 13. Sep 2005 (CEST)

AES????

Aus welcher Quelle stammt den diese Behauptung? Ich mußte mich aufgrund eines Seminarvortrages über HDCP mit der Spezifikation auseinander setzen und habe dort kein Wort über AES gefunden. Zur Verschlüsselung wird ein Pixel (24 Bit) mit einem 24 Bit breiten Wert aus einem Pseudozufallsgenerator xor-verknüpft. Das war es schon. Keine aufwendigen Mehrrunden-Verfahren, die ja auch aufgrund der hohen Geschwindigkeit bei HDMI kaum möglich wären.

Wenn du's genauer weisst, sei mutig! Ich vermute, dass hier in letzter Zeit viel Mist in den Artikel reingekommen ist, kann das aber leider inhaltlich nicht beurteilen. --Eike 00:15, 28. Nov 2005 (CET)

eine der letzten c´t s ... -cljk 00:56, 28. Nov 2005 (CET)

Ich vermute, daß HDCP gar nichts mit AES zu tun hat, deswegen hatte ich auch schon AES generell aus dem Text herausgenommen, der die Verschlüsselung der Inhalte beschreibt. Ich habe im Moment leider nicht die Zeit, mir die HDCP-Spezifikation noch einmal durchzulesen, da steht der Algorithmus exakt drin. Die gegenseitige Überprüfung der Partner auf HDCP-Verfügbarkeit und das Aushandeln der verwendeten Keys geht jedoch etwas anders als die Verschlüsselung der Inhalte. Auch in der c't steht nicht immer nur das richtige drin (vielleicht lesen die Autoren auch Wiki)?

Für mich sah der Verschlüsselungsalgorithmus für die Inhalte so aus, als ob es 3DES wäre - das würde auch angesichts der Übertragungsraten und der verfügbaren Rechenleistung Sinn machen. Nach dem Desaster mit CSS ist nicht anzunehmen, daß Intel (die bei den Algorithmen wohl federführend waren) sich etwas neues aus den Fingern gesogen hätten, das noch keiner kryptografischen Analyse standgehalten hat. Leider wird nirgend in der Dokumentation der Name des Verschlüsselungsverfahrens erwähnt.

Ob und wie HDCP angreifbar ist hat aber nur sehr eingeschränkt mit dem verwendeten Verschlüsselungsalgorithmus zu tun: Der Grundgedanke bei der Angreifbarkeit ist eher der, daß man (wenn es eine obere Grenze an sicher in den Geräten gebunkerten Schlüsseln und eine bestimmte Schlüssellänge gibt) es einfach aufgrund der linearen Algebra irgendwo eine Anzahl an (verschiedenen) Gerätekombinationen gibt, die man zusammen mit den Ausgaben eines definierten, schwarzen (oder weißen) Bildinhaltes untersuchen muß, um die nötigen Informationen über die gewählten Schlüssel zu finden.

Ich war am überlegen, ob ich einen Aspekt noch in den Text hineinschreiben sollte: Intel hat HDCP so designed, daß es sich mit einer halbwegs schnellen CPU wie z.B. einem P-III auch komplett in Software mit einer DDI-fähigen Grafikkarte implementieren ließe (Grund: Die HDCP-relevante Kommunikation findet über den DDI-Bus zwischen Grafikkarte und Display statt, der Bildinhalt könnte statt in Hardware auch direkt durch die Software des Grafiktreibers verschlüsselt werden). Allerdings hat man dieses Vorhaben nie irgendwie weiter in Erwägung gezogen, denn das wäre die einfachste Art, HDCP zu hacken: Man bräuchte nur in Ruhe die Verschlüssellung des Bildinhaltes durch den Grafikkartentreiber zu untersuchen, dann hätte man die nötigen Schlüssel gefunden. Axel Farr 28.11.05

Ich kann nur sagen, was in der C´t stand...und der glaube ich in technischen Fragen im allgemeinen. Aber bei einer Sache muss ich mal spontan widersprechen. Die Anspielung, dass AES unbekannt/nicht ausreichend geprüft wäre. Zitat aus dem Artikel:

AES wird u. a. vom Verschlüsselungsstandard 802.11i für Wireless LAN und seinem Wi-Fi-Äquivalent WPA2 sowie bei SSH und bei IPsec genutzt. Außerdem wird der Algorithmus zur Verschlüsselung diverser komprimierter Dateiarchive verwendet. Des Weiteren nutzt Skype laut eigenen Angaben AES. Das Datenkomprimierungsprogramm 7-Zip verwendet AES zur Verschlüsselung der Archive. In PGP (und natürlich auch GnuPG) findet AES auch einen großen Anwendungsbereich.

Aber in der anderen Sache könntest Du Recht haben: der benötigte Rechenaufwand für diese Datenrate dürfte nicht ohne sein. -cljk 13:54, 28. Nov 2005 (CET)

Hallo, da hast Du mich vermutlich falsch verstanden: AES ist sehr wohl gut untersucht, aber ich zielte darauf ab, daß der in HDCP verwendete Algorithmus das vermutlich auch ist - der letzte Versuch, ein "geheimes" Verschlüsselungsverfahren zu etablieren ist ja in Form von CSS ziemlich in die Hose gegangen. Da AES aber 128, 192 oder 256 Bit Blockgröße verwendet (=Schlüssellänge) paßt es nicht zu den 56 Bit, die bei HDCP verwendet werden. DES hat eben besagte 56 Bit (eigentlich Blocklänge 64, aber 8 Bit dieser Blocklänge stehen nicht mehr für den Schlüssel zur Verfügung). DES war aber schon zu der Zeit, als HDCP definiert wurde als zu schwach bekannt, so daß Intel vermutlich auf einen der Nachfolgealgorithmen gegangen ist - und der dafür am ehesten prädestinierte war 3DES, der sich darstellt als eine Kombination von drei DES-Verschlüsselungen, die sich zyklisch abwechseln. Vom Rechenaufwand her ist es eine 64-Bit-Verschlüsselung, von der Sicherheit her aber deutlich besser (auch wenn es vermutlich schlechter ist als 192 Bit AES). Und diese drei 64-Bit-Blockoperationen die 3DES macht findet man auch bei HDCP, wenn man sich die Verschlüsselung der Bildinhalte anschaut.

Rijndal wurde erst 2001 als AES für den "offiziellen" Nachfolger von DES gekührt. Die Anfänge von HDCP reichen aber bis etwa ins Jahr 1998/99 zurück, so daß anzunehmen ist, daß Intel keinen der Anwärter auf die "offizielle" DES-Nachfolge für HDCP verwendet hat, sondern eher einen der empfohlenen Ersatzalgorithmen für DES.

Wie geschrieben ist der Algorithmus, der für die Authentifizierung verwendet wird noch ein anderer Schuh. Das sah für mich aus wie eine Art von Challenge-Response-Verfahren, das z.B. auch für die Initiierung einer SSH-Verbindung verwendet wird - nur daß eben noch eine Signatur ins Spiel kommt, die von der das HDCP verwaltenden Organisation herausgegeben wird. Hier ist die Wahl noch wesentlich freier, was die verwendeten Algorithmen sein können, aber aus Gründen der Effizienz (es soll möglichst wenig Chipfläche verbraten werden) ist eher damit zu rechnen, daß es kein allzu komplexer Algorithmus sein dürfte. -Axel Farr 29.11.05

Security through Obscurity

Im Abschnitt "technisches" wird der Begriff Security through Obscurity verwendet, obwohl er meiner Meinung nach dort nicht angemessen ist. Der Begriff trifft auf Techniken wie CSS zu, wo man versucht hat, Schlüssel UND Algorithmen geheim zu halten. In der HDCP-Doku steht der Verschlüsselungsalgorithmus und das Verfahren zur Authentifizierung drin, also ist das nicht zutreffend. Daß Chips, die für HDCP verwendbar sind und sogar schon die richtigen Schlüssel enthalten nur an Vertragspartner der HD LLC verkauft werden dürfen ergibt sich einfach aus den Lizenzbedingungen, an die sich Unternehmen halten wollen, die HDCP-relevante Produkte verkaufen wollen. Das ist durchaus nichts ungewöhnliches, auch DVD-Player, die CSS-DVDs abspielen sollen müssen sich an Richtlinien halten, die das DVD-Konsortium für Vertragsunternehmen fordert. Und ohne Vertrag kommt man legal nicht an den Algorithmus und an die für die CSS-Entschlüsselung nötigen Schlüssel heran.

Eine Alternative für HDCP wäre es gewesen, die Chips ohne Schlüssel zu verkaufen, dann hätte allerdings der Hersteller der Geräte die Schlüssel einprogrammieren müssen. Man kann sich jetzt Gedanken darüber machen, was unsicherer wäre und was mehr Aufwand und Kosten bedeutet. Axel Farr 28.11.05

Verschlüsselung

Hallo an alle ...

Schaut euch doch mal folgendes PDF an: http://www.digital-cp.com/home/HDCPSpecificationRev1_1.pdf

Auf Seite 34 steht dann folgendes: "HDCP Encryption is applied at the input to the T.M.D.S. Encoder and decryption is applied at the output of the T.M.D.S. Decoder (Figure 3-1). HDCP Encryption consists of a bit-wise exclusive-or (XOR) of the HDCP Content with a pseudo-random data stream produced by the HDCP Cipher. In dual-link implementations the Audiovisual Content is 48-bits wide and requires two HDCP Ciphers to produce the required pseudo-random streams."

--> Nach diesem Dokument wäre es weder 3DES noch AES...