Daniel Stone leitet den Grafikbereich bei Collabora. In einem Blogpost beruhigt er nun Linux-Anwender, die sich Sorgen über HDCP machen: Für Nutzer freier Systeme ziehe die Einführung der High-bandwidth Digital Content Protection keine praktischen Nachteile mit sich.

HDCP verschlüsselt hochaufgelöste Inhalte für den Transport von einer Quelle zu einem Empfänger via HDMI oder Displayport. So ein Empfänger kann zum Beispiel ein TV-Gerät oder Rechner sein. Schlagen die Verhandlungen über einen HDCP-Link zwischen Quelle und Ziel fehl, sendet die Quelle ihre Audio und/oder Videodaten gewöhnlich als Fallback einfach in schlechterer Auflösung.

“DRM für DRM”

Diese Art von Inhaltsschutz gehöre zum Digital Rights Management (DRM). Dass HDCP neuerdings im freien Intel-Treiber i915 stecke, ziehe aber für Linux-Nutzer keinerlei Nachteile nach sich, erklärt Stone in dem Blogpost und versucht zu erläutern, warum das so sei. Kritik käme vor allen Dingen von Nutzern, die Digital Rights Management (DRM) mit dem analog abgekürzten Direct Rendering Manager (DRM) durcheinander werfen. Bei letzterem handelt es sich um das Display Management Framework des Kernel. Tatsächlich geben es mit dem HDCP Intel-Code nun erstmals “DRM für DRM” scherzt der Wayland-Entwickler.

Tatsächlich stecke der HDCP-Support hauptsächlich in der Hardware und werde erst aktiv, wenn der Nutzer explizit einen verschlüsselten Link auswähle. Dann versuche das Kernel-Feature die Verschlüsselung in der Hardware zu aktivieren und berichtet von seinen Ergebnissen. Ein User muss also aktiv HDCP auswählen, um es zu bekommen. Geräte können nicht von sich aus HDCP bei einer Quelle anfordern.

Auf letzter Ebene

HDCP funktioniere zudem nur auf der letzten Ebene. Es verschlüssele das Signal beim lokalen Encodieren von einem ohnehin nicht mehr lesbaren CRTC-Pixel-Stream in ein HDMI- oder Displayport-Signal. Zuvor müsse das Signal aber unverschlüsselt vorliegen. Die Framebuffer, die beim DRM/KMS ankommen, seien zum Beispiel unverschlüsselt, ebenso die von Open GL und Vulkan angebotenen Buffer für das GPU Compositing und die vom Display Controller aufbereiteten Daten.

Zudem wende sich HDCP laut Stone dem Zielgerät zu und nicht umgekehrt: Das Anzeigegerät erfahre also lediglich, dass eine HDCP-Authorität der mit ihm verbundenen HDCP-Quelle vertraue. HDCP beschneide nicht die Freiheit der User oder die Nutzungsmöglichkeiten für ein Gerät.

Um tatsächlich eine sichere Pipeline zum Dekodieren von Inhalten einzurichten, bräuchte es eine verifizierte Bootsequenz, müsse also die Hardware selbst Teil der HDCP-Pipeline werden und etwa die Schlüssel zum Dekodieren enthalten. Das sei auf mehreren Wegen möglich (vermutlich denkt Stone hier an TPM), aber die aktuellen Codepatches zur Verschlüsselung über die Kabel würden dabei keine Rolle spielen.