shortcomings of Android DRM and EME on open platforms

master
Trolli Schmittlauch 2018-09-19 17:04:01 +02:00
parent 894181bc22
commit 9573c8ce69
2 changed files with 74 additions and 31 deletions

View File

@ -136,7 +136,7 @@ Earlier versions of the requirements mandated an option to disable Secure Boot o
\acp{TPM} are dedicated hardware components offering a variety of security services to a system \cite{197213}: \\
\acp{TPM} provide \textbf{secure storage} inside the module to store sensitive data like cryptographic keys in such a way that it can't be leaked to or stolen from processes running on the main CPU. \\
These stored keys can be used to execute cryptographic operations on behalf of the system, without the keys getting transfered to the outside of the module. \\
These stored keys can be used to execute cryptographic operations on behalf of the system, without the keys getting transferred to the outside of the module. \\
The \textbf{attestation} functionality can attest the identity of software by calculating a hash sum of the supplied binary, signing it with its internal key to prove a certain system configuration or software version to third parties having a corresponding verification key. When pre-deployed with a unique key, all previously mentioned functionality can be combined to provide a \textbf{unique machine identity} and form a hardware trust anchor for running systems. \\
A \textbf{continuous trust chain} can be built from the boot-up on if all software components, starting from the firmware on, let the \ac{TPM} attest the processes to be launched and compare these attestations with the ones stored previously in the module's secure storage. A similar boot policy is \textit{authenticated booting}, where the \ac{TPM} calculates the checksum of each boot stage but doesn't enforce any signature checks but only stores the results inside its secure internal registers, from where the system status can be queried later on.\cite{hartigLateralThinkingTrustworthy2017} In contrast to UEFI Secure Boot (\ref{sec:SecureBoot}), it is also possible to securely attest and launch code using special \textit{late-launch} CPU instructions introduced into AMD and Intel chipsets without providing a continuous trust chain from the firmware on \cite{hartigLateralThinkingTrustworthy2017}. \\
Additionally, \acp{TPM} provide important support functionality cryptographic algorithms like \textbf{secure counters}, a \textbf{secure clock} for peripherals and a \textbf{secure source of entropy}. \cite{197213}
@ -175,14 +175,13 @@ As only userland code running in ring 3 can be run inside enclaves, relying on t
So how can these hardware security mechanisms be used to support DRM mechanisms and make them run securely within a still open platform?
\subsection{Android DRM architecture}
\subsection{Android DRM architecture}\label{sec:AndroidDRM}
The Android platform provides its own DRM framework\cite{AndroidDRMFramework}, providing an API for applications to communicate with a \textit{DRM manager} over \ac{IPC}. This DRM manager then runs plug-ins managing the actual DRM schemes as separate processes for isolation purposes. \\
The level of protection provided by the DRM plugin varies depending on the plugin itself and on the capabilities of the hardware platform. Plugins may rely on secure boot for a verified chain of trust from the firmware level on, use protected output mechanisms provided by the hardware platform and even run the programs inside a \ac{TEE}.
Plugins are automatically loaded when they are placed into the \texttt{/system/lib/drm/plugins/native/} directory. \\
One issue we see here is that there's no mention of authenticity checking of plug-ins mentioned in the documentatiion. \cite{AndroidDRMFramework} This can enable DRM plugins to claim to be able to decrypt a certain stream and thus at least result in the user not being able to decrypt their media with the proper add-on. Additionally it might also open up attack vectors for the communication with a license server, as shown later. \\
This might be the reason for the Android documentation to state that ``[t]he 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}
One cross-platform DRM plugin solution is \textbf{WiDevine} \cite{googleWidevineDRMArchitecture2017}, currently owned by Google. It provides native solutions for the Android, iOS and HTML5 platform. Thus the \ac{DRM} decryption process is very similar to the one specified in HTML5 \acs{EME} and will be covered in section \ref{sec:HTML5_EME} in more detail. \\
The reason we look at the example of the WiDevine Android plugin is that it supports different security levels, depending on the use of hardware security mechanisms \cite{googleWidevineDRMArchitecture2017}: For security level 1, ``[a]ll content processing, cryptography, and control is performed within the Trusted Execution
@ -218,19 +217,22 @@ The audio pipeline isn't mentioned, but with combined transmission of audio and
On platforms with \textit{ARM TrustZone}, memory sections can be dedicated to the secure world only and device's access to these sections can be limited to certain devices. This ability is used to store raw video frames, decoded in software running inside the \ac{TEE}, to be accessed by the GPU only. Additionally, a session between the \ac{CDM} inside the TEE and the GPU can be authenticated with certificates, enabling video decoding directly on the GPU similarly to the approach taken on \ac{SGX} systems.
- WiDevine quote \\
- attacker model supposed to protect against reverse engineering/ tampering but no countermeasures mentioned
- how to identify against the licens server? -> attestation required
\subsection{TBDRM}
\subsection{TBDRM}\label{sec:TBDRM}
Android DRM, EME DRM arch, TBDRM (-> fTPM), InkTag?
\section{shortcomings}
\section{shortcomings}\label{sec:shortcomings}
\subsection{shortcomings on open systems}
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. \\
Encrypting the communication between \ac{CDM} and license server without parties in the middle being able to eavesdrop on the license key transfered 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.
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}.
As a countermeasure we suggest the usage of attestation mechanisms provided e. g. remote attestation of \ac{SGX} or (f)\ac{TPM} to verify the integrity of the used \ac{CDM}. Especially for SGX though this is only a starting point and special care needs to be taken for remote attestation to be successful, as pointed out in \cite{swamiyogeshIntelSGXRemote2017}.
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.
\subsection{further downsides of DRM}

View File

@ -5,6 +5,8 @@
doi = {10.1109/ICDCS.2017.29},
abstract = {The growing computerization of critical infrastructure as well as the pervasiveness of computing in everyday life has led to increased interest in secure application development. We observe a flurry of new security technologies like ARM TrustZone and Intel SGX, but a lack of a corresponding architectural vision. We are convinced that point solutions are not sufficient to address the overall challenge of secure system design. In this paper, we outline our take on a trusted component ecosystem of small individual building blocks with strong isolation. In our view, applications should no longer be designed as massive stacks of vertically layered frameworks, but instead as horizontal aggregates of mutually isolated components that collaborate across machine boundaries to provide a service. Lateral thinking is needed to make secure systems going forward.},
language = {en},
urldate = {2018-08-01},
url = {http://ieeexplore.ieee.org/document/7980129/},
publisher = {{IEEE}},
author = {Hartig, Hermann and Roitzsch, Michael and Weinhold, Carsten and Lackorzynski, Adam},
month = jun,
@ -18,6 +20,7 @@
address = {Austin, TX},
title = {{{fTPM}}: {{A Software}}-{{Only Implementation}} of a {{TPM Chip}}},
isbn = {978-1-931971-32-4},
url = {https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/raj},
booktitle = {25th {{USENIX Security Symposium}} ({{USENIX Security}} 16)},
publisher = {{USENIX Association}},
author = {Raj, Himanshu and Saroiu, Stefan and Wolman, Alec and Aigner, Ronald and Cox, Jeremiah and England, Paul and Fenner, Chris and Kinshumann, Kinshuman and Loeser, Jork and Mattoon, Dennis and Nystrom, Magnus and Robinson, David and Spiger, Rob and Thom, Stefan and Wooten, David},
@ -50,7 +53,8 @@
@misc{TrustyTEE,
title = {Trusty {{TEE}}},
language = {en},
howpublished = {https://source.android.com/security/trusty/},
urldate = {2018-08-01},
url = {https://source.android.com/security/trusty/},
journal = {Android Open Source Project},
keywords = {unread,Android},
file = {/home/spiollinux/Zotero/storage/BFQ6MRNT/trusty.html}
@ -59,7 +63,8 @@
@misc{AndroidDRMFramework,
title = {Android {{DRM Framework}}},
language = {en},
howpublished = {https://source.android.com/devices/drm},
urldate = {2018-08-01},
url = {https://source.android.com/devices/drm},
journal = {Android Open Source Project},
keywords = {unread,Android,DRM},
file = {/home/spiollinux/Zotero/storage/B8JG6YAS/drm.html}
@ -67,7 +72,8 @@
@misc{NetflixDefectiveDesign,
title = {Netflix | {{Defective}} by {{Design}} - Www.Defectivebydesign.Org/},
howpublished = {https://www.defectivebydesign.org/netflix},
urldate = {2018-08-01},
url = {https://www.defectivebydesign.org/netflix},
keywords = {unread,DRM},
file = {/home/spiollinux/Zotero/storage/7IHY4HRL/netflix.html}
}
@ -87,7 +93,8 @@
@misc{googleWidevineDRMArchitecture2017,
title = {Widevine {{DRM Architecture Overview}} v1.2},
howpublished = {https://storage.googleapis.com/wvdocs/Widevine\_DRM\_Architecture\_Overview.pdf},
urldate = {2018-08-01},
url = {https://storage.googleapis.com/wvdocs/Widevine_DRM_Architecture_Overview.pdf},
author = {{Google}},
month = mar,
year = {2017},
@ -95,14 +102,17 @@
file = {/home/spiollinux/Zotero/storage/JVFPCN6B/Widevine_DRM_Architecture_Overview.pdf}
}
@misc{NetflixUseGoogle2017,
@misc{andyNetflixUseGoogle2017,
title = {Netflix {{Use}} of {{Google DRM Means Rooted Android Devices Are Banned}}},
abstract = {Netflix customers who previously viewed the service using a 'rooted' Android device are no longer able to do so, at least officially. The development has been confirmed by Netflix, who say that the company's reliance on Google's Widevine DRM standards means that modified and/or non-certified devices will be excluded from the service.},
language = {en},
urldate = {2018-08-01},
url = {https://torrentfreak.com/netflix-use-of-google-drm-means-rooted-android-devices-are-banned-170515/},
journal = {TorrentFreak},
author = {{andy}},
month = may,
year = {2017},
keywords = {unread,Android,DRM},
keywords = {Android,DRM},
file = {/home/spiollinux/Zotero/storage/KG8VAWB8/netflix-use-of-google-drm-means-rooted-android-devices-are-banned-170515.html}
}
@ -123,7 +133,8 @@
title = {Reconciling {{Mozilla}}'s {{Mission}} and {{W3C EME}} \textendash{} {{Mozilla Hacks}} - the {{Web}} Developer Blog},
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},
howpublished = {https://hacks.mozilla.org/2014/05/reconciling-mozillas-mission-and-w3c-eme},
urldate = {2018-08-01},
url = {https://hacks.mozilla.org/2014/05/reconciling-mozillas-mission-and-w3c-eme},
journal = {Mozilla Hacks \textendash{} the Web developer blog},
keywords = {unread,DRM},
file = {/home/spiollinux/Zotero/storage/JVLYK79M/reconciling-mozillas-mission-and-w3c-eme.html}
@ -136,6 +147,8 @@
doi = {10.1109/CSE.2009.15},
abstract = {Digital Rights Management (DRM) is the technological solution to control the distribution and usage of digital assets. However, existing solutions are vulnerable to various attacks in the context where the consumer can control the platform totally. To improve the security of DRM solutions the paper proposes a secure DRM architecture based on TPM which is called TBDRM. It ensures that content is always under the control of the license and such license is secure and fresh during its lifecycle. Compared with other DRM solutions, TBDRM can prevent replay attack and improper access enforced through cracked software.},
language = {en},
urldate = {2018-08-04},
url = {http://ieeexplore.ieee.org/document/5283799/},
publisher = {{IEEE}},
author = {Yu, Aimin and Feng, Dengguo and Liu, Ren},
year = {2009},
@ -152,25 +165,18 @@ This paper analyzes Intel SGX, based on the 3 papers that introduced it, on the
This paper's contributions are a summary of the Intel-specific architectural and micro-architectural details needed to understand SGX, a detailed and structured presentation of the publicly available information on SGX, a series of intelligent guesses about some important but undocumented aspects of SGX, and an analysis of SGX's security properties.},
number = {086},
urldate = {2018-08-05},
url = {https://eprint.iacr.org/2016/086},
author = {Costan, Victor and Devadas, Srinivas},
year = {2016},
keywords = {unread},
file = {/home/spiollinux/Zotero/storage/LBT3GU9H/Costan und Devadas - 2016 - Intel SGX Explained.pdf;/home/spiollinux/Zotero/storage/HD68AJ9F/086.html}
}
@misc{NetflixUseGoogle2017a,
title = {Netflix {{Use}} of {{Google DRM Means Rooted Android Devices Are Banned}}},
abstract = {Netflix customers who previously viewed the service using a 'rooted' Android device are no longer able to do so, at least officially. The development has been confirmed by Netflix, who say that the company's reliance on Google's Widevine DRM standards means that modified and/or non-certified devices will be excluded from the service.},
language = {en},
journal = {TorrentFreak},
month = may,
year = {2017},
file = {/home/spiollinux/Zotero/storage/DWM7DMMX/netflix-use-of-google-drm-means-rooted-android-devices-are-banned-170515.html}
}
@misc{w3cEncryptedMediaExtensions2017,
title = {Encrypted {{Media Extensions}} - Www.W3.Org/},
howpublished = {https://www.w3.org/TR/encrypted-media/},
urldate = {2018-09-03},
url = {https://www.w3.org/TR/encrypted-media/},
author = {{W3C}},
month = sep,
year = {2017},
@ -179,7 +185,8 @@ This paper's contributions are a summary of the Intel-specific architectural and
@misc{WhatEMEHsivonen,
title = {What Is {{EME}}? - Hsivonen.Fi/},
howpublished = {https://hsivonen.fi/eme/},
urldate = {2018-09-04},
url = {https://hsivonen.fi/eme/},
file = {/home/spiollinux/Zotero/storage/YKJLEHEM/eme.html}
}
@ -189,6 +196,8 @@ This paper's contributions are a summary of the Intel-specific architectural and
issn = {2056-9785, 2056-9793},
language = {English},
number = {9},
urldate = {2018-09-04},
url = {https://www.ceeol.com/search/article-detail?id=496202},
journal = {Journal of Media Critiques},
author = {Daubs, Michael S.},
year = {2017},
@ -214,6 +223,8 @@ This paper's contributions are a summary of the Intel-specific architectural and
type = {Keynote},
title = {The Coming War on General Computation},
language = {English},
urldate = {2018-09-05},
url = {https://media.ccc.de/v/28c3-4848-en-the_coming_war_on_general_computation},
author = {{Cory Doctorow}},
month = dec,
year = {2011},
@ -222,7 +233,8 @@ This paper's contributions are a summary of the Intel-specific architectural and
@misc{bruceschneierCryptoGramMay152001,
title = {Crypto-{{Gram}}: {{May}} 15, 2001 - {{Schneier}} on {{Security}}},
howpublished = {https://www.schneier.com/crypto-gram/archives/2001/0515.html\#3},
urldate = {2018-09-05},
url = {https://www.schneier.com/crypto-gram/archives/2001/0515.html\#3},
author = {{Bruce Schneier}},
month = may,
year = {2001},
@ -242,6 +254,8 @@ This paper's contributions are a summary of the Intel-specific architectural and
@misc{movielabsinc.MovieLabsSpecificationEnhanced2018,
title = {{{MovieLabs Specification}} for {{Enhanced Content Protection}}, v1.2},
urldate = {2018-09-05},
url = {http://www.movielabs.com/ngvideo/MovieLabs_ECP_Spec_v1.2.pdf},
author = {{MovieLabs Inc.}},
month = aug,
year = {2018},
@ -250,7 +264,8 @@ This paper's contributions are a summary of the Intel-specific architectural and
@misc{sonydeveloperworldUnlockBootloaderOpen,
title = {Unlock {{Bootloader}} - {{Open Devices}} - {{Sony Developer World}}},
howpublished = {https://developer.sony.com/develop/open-devices/get-started/unlock-bootloader/},
urldate = {2018-09-05},
url = {https://developer.sony.com/develop/open-devices/get-started/unlock-bootloader/},
author = {{Sony Developer World}},
file = {/home/spiollinux/Zotero/storage/CRIW7H7S/unlock-bootloader.html}
}
@ -266,6 +281,7 @@ This paper's contributions are a summary of the Intel-specific architectural and
@misc{MicrosoftHardwareCertification2014,
title = {Microsoft {{Hardware Certification Policies}} and {{Processes}}},
url = {download.microsoft.com/download/4/D/D/4DD894CD-62C8-488F-944D-4E5F8BA40114/hardware-certification-policies-processes-hck2-1.docx},
year = {2014}
}
@ -273,7 +289,8 @@ This paper's contributions are a summary of the Intel-specific architectural and
title = {Is {{Microsoft Blocking Linux Booting}} on {{ARM Hardware}}?},
copyright = {Copyright 2018 IDG Communications Ltd},
abstract = {Back in September last year, there was a bit of a to-do about Microsoft's UEFI Secure Boot technology in Windows 8, when a Red Hat engineer posted the following:Microsoft requires that machines conforming to the Windows 8 logo program and...},
howpublished = {https://www.computerworlduk.com/it-business/is-microsoft-blocking-linux-booting-on-arm-hardware-3569162/},
urldate = {2018-09-05},
url = {https://www.computerworlduk.com/it-business/is-microsoft-blocking-linux-booting-on-arm-hardware-3569162/},
journal = {ComputerworldUK},
author = {Moody, Glyn},
file = {/home/spiollinux/Zotero/storage/Q9TQHLHG/is-microsoft-blocking-linux-booting-on-arm-hardware-3569162.html}
@ -282,7 +299,8 @@ This paper's contributions are a summary of the Intel-specific architectural and
@misc{matthewgarrettAnnouncingShimReview,
title = {Announcing the {{Shim}} Review Process},
language = {en},
howpublished = {https://mjg59.dreamwidth.org/47438.html},
urldate = {2018-09-05},
url = {https://mjg59.dreamwidth.org/47438.html},
author = {{Matthew Garrett}},
file = {/home/spiollinux/Zotero/storage/FGYE9G6G/47438.html}
}
@ -303,4 +321,27 @@ This paper's contributions are a summary of the Intel-specific architectural and
year = {2015}
}
@inproceedings{swamiyogeshIntelSGXRemote2017,
address = {Las Vegas},
title = {Intel {{SGX Remote Attestation}} Is Not Sufficient},
urldate = {2018-09-18},
url = {https://www.blackhat.com/docs/us-17/thursday/us-17-Swami-SGX-Remote-Attestation-Is-Not-Sufficient-wp.pdf},
author = {{Swami Yogesh}},
year = {2017},
file = {/home/spiollinux/Zotero/storage/GBNIS3SZ/us-17-Swami-SGX-Remote-Attestation-Is-Not-Sufficient-wp.pdf}
}
@misc{corvindavenportNetflixConfirmsIt2017,
title = {Netflix Confirms It Is Blocking Rooted/Unlocked Devices, App Itself Is Still Working (for Now)},
abstract = {Earlier today, Netflix started showing up as 'incompatible' on the Play Store for rooted and unlocked Android devices. However, the app itself continued to... by Corbin Davenport in Applications, News},
language = {en-US},
urldate = {2018-09-19},
url = {https://www.androidpolice.com/2017/05/13/netflix-confirms-blocking-rootedunlocked-devices-app-still-working-now/},
journal = {Android Police},
author = {{Corvin Davenport}},
month = may,
year = {2017},
file = {/home/spiollinux/Zotero/storage/TVBERLMS/netflix-confirms-blocking-rootedunlocked-devices-app-still-working-now.html}
}