schmittlauch
/
surveypaper-drm-tee
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

open system downsides mostly finished

master
Trolli Schmittlauch 2018-09-21 19:01:40 +02:00
parent 52a9a703b8
commit b301b06bc2
3 changed files with 51 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
glossary.tex
View File

@ -19,4 +19,5 @@
\acro{LD}{License Distributor} \acro{LD}{License Distributor}
\acro{VC}{Version Controller} \acro{VC}{Version Controller}
\acro{DC}{DRM Controller} \acro{DC}{DRM Controller}
\acro{MMU}{Memory Management Unit}
%\acro{ %\acro{

17
main.tex
View File

@ -251,6 +251,10 @@ As fTPM requires additional hardware components to be included already during sy
\subsection{shortcomings on open systems} \subsection{shortcomings on open systems}
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.
\subsubsection{authentication at license server}
Both the WiDevine architecture \cite{googleWidevineDRMArchitecture2017} and the \ac{TEE}-backed HTML5 \ac{EME} approach leave an important attack vector uncovered: It's not specified how \acp{CDM} authenticate against the license server they get the decryption key from. While all information between the \ac{CDM} and the license server is encrypted and thus meaningless to the browser or other software in the middle of the communication, on an open system it should be possible to read, reverse-engineer and even manipulate the \ac{CDM} binary\footnote{under the \ac{WIPO} copyright treaty or the \ac{DMCA} this is illegal, but still technically possible}, as they have to be stored somewhere (SGX and TrustZone don't provide secure permanent storage) or transmitted to the computer for installation. Livshitz et al. even mention reverse-engineering and manipulation in the security objectives of their paper \cite{livshitsSecurityNativeDRM2015}, but don't provide any countermeasures. \\ Both the WiDevine architecture \cite{googleWidevineDRMArchitecture2017} and the \ac{TEE}-backed HTML5 \ac{EME} approach leave an important attack vector uncovered: It's not specified how \acp{CDM} authenticate against the license server they get the decryption key from. While all information between the \ac{CDM} and the license server is encrypted and thus meaningless to the browser or other software in the middle of the communication, on an open system it should be possible to read, reverse-engineer and even manipulate the \ac{CDM} binary\footnote{under the \ac{WIPO} copyright treaty or the \ac{DMCA} this is illegal, but still technically possible}, as they have to be stored somewhere (SGX and TrustZone don't provide secure permanent storage) or transmitted to the computer for installation. Livshitz et al. even mention reverse-engineering and manipulation in the security objectives of their paper \cite{livshitsSecurityNativeDRM2015}, but don't provide any countermeasures. \\
Although encrypting the communication between \ac{CDM} and license server without parties in the middle being able to eavesdrop on the license key transferred is indeed possible, e.g. using a Diffie-Hellman key exchange for generating a session key\footnote{although this could become a bit cumbersome in HTML5 EME as the browser has to relay all steps of the key exchange before actual payload information can be sent}, the license server can't check the authenticity of the \ac{CDM} it's communicating with. Including a private authentication key into the \ac{CDM} binary is insecure as the key could be recovered from attackers by reverse engineering. And if there's no need to authenticate the \ac{CDM} against the license server or modified \acp{CDM} are still able to do that using an extracted private key, a modified \ac{CDM} can either deliberately leak the key or the decrypted content to the untrusted \ac{OS}. Although encrypting the communication between \ac{CDM} and license server without parties in the middle being able to eavesdrop on the license key transferred is indeed possible, e.g. using a Diffie-Hellman key exchange for generating a session key\footnote{although this could become a bit cumbersome in HTML5 EME as the browser has to relay all steps of the key exchange before actual payload information can be sent}, the license server can't check the authenticity of the \ac{CDM} it's communicating with. Including a private authentication key into the \ac{CDM} binary is insecure as the key could be recovered from attackers by reverse engineering. And if there's no need to authenticate the \ac{CDM} against the license server or modified \acp{CDM} are still able to do that using an extracted private key, a modified \ac{CDM} can either deliberately leak the key or the decrypted content to the untrusted \ac{OS}.
@ -259,6 +263,17 @@ As a countermeasure we suggest the usage of attestation mechanisms provided e. g
The Android DRM framework seems to put emphasis on locking down the whole system with a trusted boot chain instead, as stated in the Android documentation: ``The combination of hardware security functions, a trusted boot mechanism, and an isolated secure OS for handling security functions is critical to providing a secure device.'' \cite{AndroidDRMFramework} \\ The Android DRM framework seems to put emphasis on locking down the whole system with a trusted boot chain instead, as stated in the Android documentation: ``The combination of hardware security functions, a trusted boot mechanism, and an isolated secure OS for handling security functions is critical to providing a secure device.'' \cite{AndroidDRMFramework} \\
This is also apparent in the light of several apps using the Android DRM framework not being available on rooted devices. One example is the Netflix app, which uses the WiDevine DRM scheme. \cite{corvindavenportNetflixConfirmsIt2017} This app can not be installed from the Play Store\footnote{Google's app store for the Android platform, by far the most popular one and default on Google-certified devices} on rooted Android devices, though already installed apps or ones installed through side-loading still continue to function. This is the case because installation from Play Store for this app is tied to the device's \textit{SafetyNet} status, which tries to detect tampering with the device's software. The Android DRM framework itself though also offers \acp{API} for getting the security status of a DRM plugin (see \ref{sec:AndroidDRM}), including whether a DRM plugin fully uses the \ac{TEE} of a device. Due to the ambiguous restriction enforcement it remains unclear whether banning the store installation of such apps on rooted devices is a sign of Google not fully trusting the security of \ac{TEE}-backed DRM even on open devices or if this is just a side effect of administrational policies of the store. But at least this is not a sign pointing towards the acceptance of \ac{DRM} on open platforms. This is also apparent in the light of several apps using the Android DRM framework not being available on rooted devices. One example is the Netflix app, which uses the WiDevine DRM scheme. \cite{corvindavenportNetflixConfirmsIt2017} This app can not be installed from the Play Store\footnote{Google's app store for the Android platform, by far the most popular one and default on Google-certified devices} on rooted Android devices, though already installed apps or ones installed through side-loading still continue to function. This is the case because installation from Play Store for this app is tied to the device's \textit{SafetyNet} status, which tries to detect tampering with the device's software. The Android DRM framework itself though also offers \acp{API} for getting the security status of a DRM plugin (see \ref{sec:AndroidDRM}), including whether a DRM plugin fully uses the \ac{TEE} of a device. Due to the ambiguous restriction enforcement it remains unclear whether banning the store installation of such apps on rooted devices is a sign of Google not fully trusting the security of \ac{TEE}-backed DRM even on open devices or if this is just a side effect of administrational policies of the store. But at least this is not a sign pointing towards the acceptance of \ac{DRM} on open platforms.
\subsubsection{size of the \acl{TCB}}
The advantage of the approaches where \aclp{CDM} run inside a \ac{TEE} is that, given the \ac{TEE} technology itself is secure, authentication issues like the ones just described can be overcome and the cryptographic primitives used are semantically secure, only the \ac{TEE} running the (proprietary) CDM itself is part of the \ac{TCB}. All other software on the untrusted (virtual) processor, even the operating system, might be modified freely as all sensitive data (plain content, cryptographic keys) are never accessible outside of the secured environment. When using ARM TrustZone though, care needs to be taken of other code running within the secure world. As there is only one secure world available, all programs running within the \ac{TEE} have to share the same environment, on top of a special purpose operating system like the Trusty \ac{OS} \cite{TrustyTEE} used on Android devices. There, processes running on top of the \ac{OS} are isolated from each other via address space separation, utilizing the \ac{MMU}. So at least the \ac{CDM} and the trusted \ac{OS} it is running on are part of the \ac{TCB}. In the case of Trusty, even all processes running on top are bundled with the \ac{OS}, signed, and then verified by the firmware at boot similarly to Secure Boot. And still all vulnerabilities in code belonging to the \ac{TCB} are potentially security critical if exploitable, one example of it shown with a vulnerability in the \ac{TEE} \ac{OS} itself. \cite{shenExploitingTrustzoneAndroid2015}
For the TBDRM approach though the size of the \ac{TCB} is even larger, including the whole kernel and TBDRM's userland components. Firmware and bootloader are part of the trust chain and must not be modified for the DRM system to work, but are not a crucial part of the \ac{TCB} as the kernel running on top is measured by the \ac{TPM} independently. All of this requires a trustworthy \ac{TPM} implementation. \\
As measured boot is used, modified software components are not prevented from running but the DRM functionality would not work on systems not identified as trustworthy. Thus a dual-boot system can be imagined, where in one of the systems the kernel can be freely modified while loosing the ability to play DRM secured content, while the unchanged other system retains the ability of DRM-protected playback.
\subsubsection{media output on peripherals}
With the master key having leaked and decryption hardware being available \cite{DBLP:conf/reconfig/LombG11}, HDCP can be considered as broken.
\subsection{further downsides of DRM} \subsection{further downsides of DRM}
What parts need to be locked down? What parts need to be locked down?
@ -269,6 +284,8 @@ WiDevine/ Netflix ban from rooted devices
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." 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
\section{Summary} \section{Summary}
% % % % % %
% Theory (probably) % Theory (probably)

33
mybib.bib
View File

@ -358,4 +358,37 @@ This paper's contributions are a summary of the Intel-specific architectural and
doi = {10.1007/978-1-4302-6584-9} doi = {10.1007/978-1-4302-6584-9}
} }
@inproceedings{shenExploitingTrustzoneAndroid2015,
title = {Exploiting {{Trustzone}} on {{Android}}},
language = {en},
author = {Shen, Di},
year = {2015},
pages = {7},
file = {/home/spiollinux/Zotero/storage/52TAB5M2/Shen - Exploiting Trustzone on Android.pdf}
}
@inproceedings{DBLP:conf/reconfig/LombG11,
title = {Decrypting {{HDCP}}-Protected {{Video Streams Using Reconfigurable Hardware}}},
doi = {10.1109/ReConFig.2011.24},
url = {https://doi.org/10.1109/ReConFig.2011.24},
booktitle = {2011 {{International Conference}} on {{Reconfigurable Computing}} and {{FPGAs}}, {{ReConFig}} 2011, {{Cancun}}, {{Mexico}}, {{November}} 30 - {{December}} 2, 2011},
author = {Lomb, Benno and G\"uneysu, Tim},
year = {2011},
pages = {249-254},
crossref = {DBLP:conf/reconfig/2011},
biburl = {https://dblp.org/rec/bib/conf/reconfig/LombG11},
bibsource = {dblp computer science bibliography, https://dblp.org}
}
@book{DBLP:conf/reconfig/2011,
title = {2011 {{International Conference}} on {{Reconfigurable Computing}} and {{FPGAs}}, {{ReConFig}} 2011, {{Cancun}}, {{Mexico}}, {{November}} 30 - {{December}} 2, 2011},
isbn = {978-1-4577-1734-5},
url = {http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=6126158},
publisher = {{IEEE Computer Society}},
editor = {Athanas, Peter M. and Becker, J\"urgen and Cumplido, Ren\'e},
year = {2011},
biburl = {https://dblp.org/rec/bib/conf/reconfig/2011},
bibsource = {dblp computer science bibliography, https://dblp.org}
}