Browse Source

problems of DRM + overview

Trolli Schmittlauch 2 years ago
2 changed files with 62 additions and 18 deletions
  1. +19
  2. +43

+ 19
- 15
main.tex View File

@ -16,7 +16,7 @@
\newcommand{\documenttitle}{Here be dragons}
\newcommand{\documenttitle}{Hardware Support for DRM: Can Trusted Execution Environments save us from System Lockdown?}
\newcommand{\abstracttext}{Abstract goes here}
@ -115,7 +115,7 @@ So right now we are in a situation, where all major publishers of e.g. video\foo
But in recent years modern CPU architectures have introduced special hardware-backed \acp{TEE} to provide a secured environment for security-critical code to be executed in isolation from the main \textit{untrusted} \ac{OS}. Can these TEEs and other special hardware trust-anchors provide the possibility to present \ac{DRM}-secured content in an otherwise open and open source system, not having to lock it down completely?
In \ref{sec:background} we first give an overview of common technologies used for providing trust anchors for running systems or isolating software into a trusted environment. Afterwards, \ref{sec:hw_DRM} covers existing DRM architectures already utilizing \acp{TEE}. Aiming for the usage on systems as open as possible, \ref{sec:shortcomings} looks at the security of the presented architectures on such systems and at last takes a look at other problematic effects of DRM usage.
% % %
% Literature Survey and Background
@ -169,7 +169,7 @@ Additionally, \ac{SGX} includes attestation of code running within an enclave si
As only userland code running in ring 3 can be run inside enclaves, relying on the \ac{OS} for scheduling and resource management, \ac{SGX} is vulnerable to side-channel attacks \cite{peinadom.ControlledChannelAttacksDeterministic2015}.
\section{Hardware Support for DRM systems}
\section{Hardware Support for DRM systems}\label{sec:hw_DRM}
So how can these hardware security mechanisms be used to support DRM mechanisms and make them run securely within a still open platform?
@ -249,7 +249,7 @@ As fTPM requires additional hardware components to be included already during sy
\subsection{shortcomings on open systems}
\subsection{shortcomings on open systems}\label{sec:shortcomings_open}
As the aim of this paper is to evaluate the feasibility of providing \ac{DRM} protection on otherwise open platforms, in this section we look at what security challenges arise for the presented DRM architectures, which parts of the system need to be secured and which of these can remain open.
@ -275,24 +275,28 @@ As measured boot is used, modified software components are not prevented from ru
The secured rendering pipeline used in \ref{sec:HTML5_EME} only reaches to the GPU. But how to transfer the decoded audio and video data to the actual display device and speakers? \\
For directly attached screens on devices like smartphones, tablets or laptops relying on the display bus being physically hard to eavesdrop on might be a valid compromise. But as soon as it comes to attaching external display devices over standardized connectors (HDMI, DVI, DisplayPort) direct output grabbing becomes a threat. With these video output standards transmitting digital data, the quality loss during grabbing is neglectable. The state-of-the-art mechanism for DRM protection during transmission is \ac{HDCP}, which encrypts the content on its way to the display device. But with the master key having leaked and decryption hardware being available \cite{DBLP:conf/reconfig/LombG11}, \ac{HDCP} can be considered as broken.
\subsection{further downsides of DRM}
\subsection{Further Downsides of DRM}
What parts need to be locked down?
While the usage of \acp{TEE} can indeed increase the security of \ac{DRM} schemes while at the same tame taking away the need for total system lockdown, there are quite a number of other issues with the usage of DRM protection for media. Most of them are less purely technical but concern the social and political effects of its technical properties.
WiDevine/ Netflix ban from rooted devices
The designed purpose of \ac{DRM} systems is to restrict the usage of protected media files to follow the exact policies of the publisher -- and that is exactly what it does. The problem here: The outlined policies of the publisher do not always cover legal or legitimate use cases of the media. In their campaign leaflet on DRM and its downsides \cite{freesoftwarefoundationeuropeDRMStrangeBroken2012}, the Free Software Foundation Europe outlines several problems of DRM usage: \\
DRM protection of media content undermines several copyright exemption and customer rights. While most jurisdiction know exemptions for lending works out to friends and family or making private copies for them, this copyright exception is not granted when so-called \textit{effective measures} of copy protection are taken by the publisher. All DRM mechanisms are considered as such and are illegal to circumvent, taking away these user rights. At the same time we notice that, at least in Germany, collector societies are still charging and collecting remuneration fees for this exception customers are not allowed to use anymore. A similar copyright exemption is the liberty of quotation. But with DRM protection, it is not possible to e. g. cut a certain video sequence from a movie to embed it into your own work. \\
In the United States, there is even the concept of \textit{fair use} allowing the remix of existing works to create new works of art. As DRM systems prevent editing and further processing of the content, this right is also prevented from being executed. \\
In DRM systems only certain pieces of software are allowed to process the protected content -- in the case of TBDRM these are the players trusted by the license distributor. Often publishers forget the reliance of disabled people on certain assistance software. Such screen readers, image or audio enhancers are rarely on the list of trusted software able to process the protected content and thus can not enable disabled people access to the content.
- remaining other problems: cultural heritage, inflexibility, tied to a certain technological platform
DRM protection is also a threat to the availability of content, both in the short and in the long term. Recently, an anecdote \cite{bergmayerItAlwaysDRM2018} rased awareness for this again: After moving from Australia to Canada, a person lost their ability re-download several purchased movies. This happened due to regionally-limited licensing deals of the publisher. While already downloaded movie files could still be played back, because of DRM protection they were tied to a single device only. Playback of the legally bought films on other devices would have required a re-download, which was not possible in that jurisdiction. \\
This illustrates the downsides of DRM protected content always being bound to something out of the control of the consumer who bought it: For acquiring the required decryption keys, license servers need to be online, reachable and supporting the technology required for the media to be played back. Additionally, these proprietar DRM schemes are always bound to a certain technology platform (e. g. ARM TrustZone and Android) with only their vendor having the ability to make content bought for a previous technology available on a new platform. While the \textit{Common Encryption} standard is a step into the right direction, we are still in a situation where content regularly becomes unavailable because of companies going out of business, deciding not to make old content available on new platform or switching off licensing servers\footnote{example: in 2008 Microsoft switched off their ``Plays for Sure'' licensing servers \cite{sterlingDeadMediaBeat2008}}. This is also a threat to preserving cultural heritage, as even personal backups of the media files are useless without the non-exportable respective keys.
valid copyright exceptions (private copy, quotation) are prevented
Doctorows Law: "Anytime someone puts a lock on something you own, against your wishes, and doesn't give you the key, they're not doing it for your benefit."
tracking, Mozilla
The seemingly endless possibilities of restrictions motivated companies to also offer business options requiring heavy user tracking. For example, \textit{node locking} -- binding content to a specific computer only -- causes several DRM schemes to create detailed profiles of the computer it is running on and the user's activities. Because of that Mozilla decided in their implementation of the HTML5 EME standard to run \acp{CDM} only sandboxed, limiting tracking and privacy intrusion. \cite{andreasgalReconcilingMozillaMission2014} \\
As \acp{CDM} are proprietary\footnote{The WiDevine architecture overview even mentions this as a key security concept: ``This unique mix of open source and protected source
enables Widevine DRM to make it easy to create custom playback applications that are
encrypted and secure.'' \cite{googleWidevineDRMArchitecture2017}}, both the amount of user tracking they do and their security can not be evaluated, as under the WIPO agreement reverse-engineering copy-protection mechanisms is heavily restricted. With the availability of \aclp{TEE} and the usage of attestation, not requiring \acp{CDM} to contain secret data anymore, it should be possible to create open source \acp{CDM} which can be built reproducibly.
% % %
% Theory (probably)
As presented on the examples of the covered \ac{DRM} schemes, the usage of hardware support mechanisms -- especially of \aclp{TEE} -- can enable reliable content protection on systems without having to lock them down completely. All presented approaches had shortcomings in different security properties, but when combining ideas from these different schemes the result is more resilient to threats.
However, the usage of \ac{DRM} implies several other problems that are not solved by the usage of hardware support.

+ 43
- 3
mybib.bib View File

@ -129,13 +129,16 @@
file = {/home/spiollinux/Zotero/storage/UGELIEJS/Livshits et al. - 2015 - Towards Security of Native DRM Execution in HTML5.pdf;/home/spiollinux/Zotero/storage/BN7T2F8R/7442370.html}
title = {Reconciling {{Mozilla}}'s {{Mission}} and {{W3C EME}} \textendash{} {{Mozilla Hacks}} - the {{Web}} Developer Blog},
title = {Reconciling {{Mozilla}}'s {{Mission}} and {{W3C EME}}},
abstract = {May 19 Update: We've added an FAQ below the text of the original post to address some of the questions and comments Mozilla has received regarding EME. With most competing ...},
language = {en-US},
urldate = {2018-08-01},
url = {},
journal = {Mozilla Hacks \textendash{} the Web developer blog},
journal = {Mozilla Hacks},
author = {{Andreas Gal}},
month = may,
year = {2014},
keywords = {unread,DRM},
file = {/home/spiollinux/Zotero/storage/JVLYK79M/reconciling-mozillas-mission-and-w3c-eme.html}
@ -391,4 +394,41 @@ This paper's contributions are a summary of the Intel-specific architectural and
bibsource = {dblp computer science bibliography,}
title = {It's {{Always DRM}}'s {{Fault}}},
language = {en},
urldate = {2018-09-21},
url = {},
journal = {Public Knowledge},
author = {Bergmayer, John},
month = sep,
year = {2018},
file = {/home/spiollinux/Zotero/storage/QS27QQQM/its-always-drms-fault.html}
title = {{{DRM}}: {{The Strange}}, {{Broken World}} of {{Digital Rights Management}}},
language = {English},
urldate = {2018-09-21},
url = {},
author = {{Free Software Foundation Europe} and {Joe McNamee}},
year = {2012},
file = {/home/spiollinux/Zotero/storage/DEJSZ2XE/paper04_web_20120205.pdf}
title = {Dead {{Media Beat}}: {{Microsoft Plays}} for {{Sure}}},
issn = {1059-1028},
shorttitle = {Dead {{Media Beat}}},
language = {en-US},
urldate = {2018-09-21},
url = {},
journal = {Wired},
author = {Sterling, Bruce},
month = apr,
year = {2008},
keywords = {Dead Media Beat},
file = {/home/spiollinux/Zotero/storage/59E39BSH/dead-media-be-3-2.html}