abstract + tags

achtung, müde!
master
Trolli Schmittlauch 2018-09-22 01:01:33 +02:00
コミット 77571bebf9
2個のファイルの変更5行の追加4行の削除

バイナリ
figures/tbdrm_high_level_arch.png Normal file

バイナリファイルは表示されません。

変更後

幅:  |  高さ:  |  サイズ: 39 KiB

ファイルの表示

@ -18,7 +18,8 @@
\newcommand{\documenttitle}{Hardware Support for DRM: Can Trusted Execution Environments save us from System Lockdown?}
\newcommand{\abstracttext}{Abstract goes here}
\newcommand{\abstracttext}{Nowadays, all major publishers of popular media content mandate the usage of DRM copy protection for their published works. But as preventing digital content from being copied is a difficult problem, the current approches for copy protection involve locking down systems, criticized as endangering general computation and user freedom. \\
This survey looks at the available hardware support technologies for providing hardware trust anchors or trusted execution environments, ranging from Secure Boot and TPM to Intel SGX and TrustZone, and evaluates their usage in the DRM architectures of Android and the HTML5 EME browser stack. Showing shortcomings in authenticity checking of components, different levels of required lockdown, and output protection of all covered architectures, we find that the usage of trusted execution environments reduces the required system lockdown for DRM protection. But many other negative effects of DRM can not be solved with this approach.}
% set pdf metadata
\usepackage[
@ -95,7 +96,7 @@
% Are NOT: Peer-To-Peer, Anonymity, Privacy.
% BUT TAKEN FROM THIS LIST:
% http://www.ieee.org/organizations/pubs/ani_prod/keywrd98.txt
Security, DRM, Trusted Execution Environments, SGX,
Security, DRM, Trusted Execution Environments, SGX, TrustZone, TPM, HTML5 EME
\end{IEEEkeywords}
% }
@ -111,7 +112,7 @@ But these attempts were mostly based on obscuring the protection mechanism used,
Doctorow warns that all countermeasures trying to ensure copy protection of digital content are going to result in creating ``appliances'', which are still general purpose computers, but locked down with ``some combination of rootkits, spyware, and code-signing to prevent the user from knowing which processes are running, from installing her own software, and from terminating processes that she doesn't want.'' \cite{corydoctorowComingWarGeneral2011} \\
Additionally, international agreements based on the \ac{WIPO} Copyright Treaty \cite{worldinternationalcopyrightorganizationWIPOCopyrightTreaty1996}, its most prominent implementation being the US-American \ac{DMCA}, make the circumvention of ``technical protection measures'' such as \ac{DRM} illegal.
So right now we are in a situation, where all major publishers of e.g. video\footnote{all Hollywood movie publishers require adhering to certain protec standards like \cite{movielabsinc.MovieLabsSpecificationEnhanced2018}} and audio\footnote{although legal music file purchases are mostly \ac{DRM}-free, the consumption model of streaming has brought back DRM to platforms like Spotify or Deezer} content, and video games\footnote{Valve's Steam platform integrates its own DRM into sold games; other publishers as well as gaming consoles have their own DRM systems as well}. Thus right now, all software using this content has to be proprietary and whole platforms are being locked down more and more. This development is most apparent in non-PC platforms like mobile devices, where unlocking the bootloader (if even possible) results in deletion of \ac{DRM} keys of the device. \cite{sonydeveloperworldUnlockBootloaderOpen}
So right now we are in a situation, where all major publishers of e.g. video\footnote{all Hollywood movie publishers require adhering to certain protec standards like \cite{movielabsinc.MovieLabsSpecificationEnhanced2018}} and audio\footnote{although legal music file purchases are mostly \ac{DRM}-free, the consumption model of streaming has brought back DRM to platforms like Spotify or Deezer} content, and video games\footnote{Valve's Steam platform integrates its own DRM into sold games; other publishers as well as gaming consoles have their own DRM systems as well} require the usage of \ac{DRM} for protecting their published works. Thus right now, all software using this content has to be proprietary and whole platforms are being locked down more and more. This development is most apparent in non-PC platforms like mobile devices, where unlocking the bootloader (if even possible) results in deletion of \ac{DRM} keys of the device. \cite{sonydeveloperworldUnlockBootloaderOpen}
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?
@ -294,7 +295,7 @@ encrypted and secure.'' \cite{googleWidevineDRMArchitecture2017}}, both the amou
\section{Summary}
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.
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 the areas of authentication and authenticity checking, size of the locked-down system base (\ac{TCB}) or actual output mechanisms, 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.