Lotfi Batel
email: lotfi.batel@cea.fr

Antonio Clemente

Christophe Delaveaud

High-Gain Wideband and Superdirective Electronically-Beam-Switchable Antenna for Smart Communication Objects

Keywords: Beam-steering, beam-switching, electrically small antennas, superdirectivity, parasitic arrays. I

This paper proposes the design of a high-gain, wideband, directive, and compact circular array composed of 5 symmetrical radiating elements (1 fed and 4 parasitic elements). The possibility to implement an electronically beam-switching capability over the horizontal plane is studied. Thanks to the superdirectivity principle, the proposed closely spaced parasitic antenna array achieves a maximum gain of 10 dBi steered in four directions on the horizontal plane and a minimum gain of 9 dBi in the whole horizontal plane. The proposed antenna achieves a stable gain > 9dBi in the frequency band 758-803 MHz, which is interesting for sub-GHz 5G applications.

INTRODUCTION

The rapid growth of compact and smart connected objects generates a need of increasingly small and performing antennas. Following the fundamental laws of physics [START_REF] Wheeler | Fundamental limitations of small antennas[END_REF], antenna miniaturization while conserving sufficient radiation and bandwidth performances is a challenge, especially for frequencies below 1 GHz where the wavelengths are large. In this paper, our interest is focused on the design of a high-gain wideband compact parasitic antenna array with electronically beam-switching capabilities in the horizontal plane. This antenna architecture has been optimized to work in the frequency band 753-803 MHz and offers new perspectives for the future sub-GHz wireless communication systems requiring spatial scanning and high-data rates for new services linked to IoT and 5G applications.

Classically, Electrically Steerable Passive Array Radiators (ESPAR) are used to achieve a directive and steerable radiation pattern on the antenna horizontal plane. ESPAR are designed generally considering circular arrays of parasitic radiating elements with the geometry of electrical compact monopoles over a half wavelength ground plane. The ground plane is often used to connect the electronic circuits to control the beam steering and bring the radiofrequency feeding of the antenna without affecting its radiation properties. Nevertheless, those ESPAR antennas have a maximum gain tilted from the horizontal plane due to the finite size of the ground plane [START_REF] Liu | Electrically small and low cost smart antenna for wireless communication[END_REF]- [START_REF] Xing | A circular beam-steering antenna with parasitic water reflectors[END_REF]. Our recent work [START_REF] Batel | Superdirective and compact electronically-beam-switchable antenna for smart communication objects[END_REF] has shown the opportunity to steer the radiation pattern of 9-elements dipolelike symmetrical ESPAR with a maximum gain in the horizontal plane using a floating ground plane. This particular ground plane, which is decoupled at radiofrequency, does not affect the radiation patterns of the symmetrical antenna and has been used to facilitate the integration of the electronic devices required to control the beam switching. Moreover, both beam steering capability and angular resolution of ESPAR in the literature are often constrained by the number of parasitic elements in the array. In classical architectures, each beam is formed by using a linear end-fire sub-array and the number of beams is equal to the number of parasitic elements. When high-directivity beam are required, this classical technique results in a lower gain in the horizontal plane at the intersection of two adjacent beams, especially for ESPAR with a small number of parasitic elements.

In this paper, a 5-element antenna array with beamswitching capability is optimized in the operation frequency bandwidth 758-803 MHz. The array is composed of 4 parasitic elements disposed in a circular geometry around a central fed element. Superdirectivity principle is used to optimize the complex impedance loads of the parasitic radiating elements strongly coupled to the array fed antenna [START_REF] Clemente | Design of a super directive four-element compact antenna array using spherical wave expansion[END_REF] and to obtain a small-sized and directive radiating system. In the proposed architecture, symmetrical radiating elements are chosen to achieve a directive radiation with a maximum directivity and gain in the horizontal plane. To improve the beam steering resolution and achieve a gain higher than 9 dBi in the whole horizontal plane, the possibility to steer the beam with an angular step of 15° is considered and demonstrated using only four parasitic radiating elements.

The paper is organized as follows. In Section II, the geometry of the elementary radiating element of the array is firstly described, then the 5 elements array. Section III deals with antenna directivity optimization and beam steering capability at a single frequency (800 MHz). Then, in Section IV, an analysis of antenna radiation performances in the frequency bandwidth of interest (758-803 MHz) is performed. Finally, conclusions are drawn in Section V.

II. DESCRIPTION OF ANTENNA GEOMETRY

A. Single element description

The single element of the antenna array is a wideband dipolar wire-plate antenna described in Fig. 1. It consists of symmetrical double crossed elliptical shape metallic plates top loaded by two metallic circular "hats". In order to lower the height of the antenna, the two "hats" are connected to each other by mean of four shorting wires. The antenna is fed at the center by an ideal balanced port. The two hats have a diameter of 66 mm (0.18 and the height of the antenna is 80 mm (0.21 . Where is the wavelength computed at 800 MHz. As shown in Fig. 2-a, the single element antenna achieves a wideband frequency response with -10 dB frequency bandwidth of 27 % in the band 730-962 MHz. The compact antenna has a symmetrical dipolar-shape radiation pattern with a gain of 1.7 dBi and an efficiency close to 100% (Fig. 2-b). As shown in [START_REF] Batel | Superdirective and compact electronically-beam-switchable antenna for smart communication objects[END_REF], the symmetrical radiation pattern of the single element is important to establish a directive radiation pattern, with a maximum directivity in the horizontal plane when the antenna is combined to other elements in the ESPAR geometry.

B. Five-element array description

The wideband single element described previously is used to build the small-size 5-element circular array shown in Fig. 3. The antenna located at the center of the array is the only one fed. The other antennas are parasitic and loaded with optimized complex impedance loads. These loads are computed using the procedure presented [START_REF] Clemente | Design of a super directive four-element compact antenna array using spherical wave expansion[END_REF] to achieve a directive beam in the direction of interest ( 0°, 90° . The parasitic antennas are spaced by 0.2 λ0 from the central antenna. Two adjacent parasitic antennas are spaced by 0.28 . The designed array is low profile with a height of 80 mm (0.2 λ0) and a diameter of 216 mm (0.57 λ0).

III. DIRECTIVITY OPTIMIZATION

A. Spherical wave expansion optimization procedure

The directivity of the 5-element array has been optimized in the direction 0°, 90° using the synthesis procedure based on the spherical wave expansion theory [START_REF] Clemente | Design of a super directive four-element compact antenna array using spherical wave expansion[END_REF]. Main steps of this method are summarized in Fig. 4. Starting from the active radiation pattern of each element of the array ( ( , , ) p r θ ϕ E in the STEP 1), the spherical wave coefficients are calculated (STEP 2). Then, solving a maximization problem the objective function is defined and a linear system is considered to calculate the optimal complex excitation coefficients associated to the array elements (STEP 3). Finally, using the complete scattering matrix, the equivalent parasitic complex loads are extracted (STEP 4).

B. Single frequency radiation optimization at 800 MHz

The directivity of the 5-element array has been optimized in the direction of interest at 800 MHz. The 3D radiation pattern and the associated optimized impedance loads computed with the procedure presented in the previous section 0.28 are shown respectively in Fig. 5 and Table 1. A maximum directivity of 10 dBi and a maximum gain of 9.8 dBi are achieved in the end-fire direction with a half beam width of 67°.

Fig. 5. 3D gain pattern optimized in the direction 0°, 90°.

We notice in Table 1 that the optimal load connected at the port 2 has a negative resistor, needed to enforce antenna's radiation in the optimized direction. Replacing this negative equivalent resistor by a 0 Ω resistor has a very slight effect. The beam is still shaped in the direction of interest with a drop of less than 0.1 dB on the gain and directivity, since the antenna array is not as sensitive (electrical distance of 0.28 between two adjacent parasitic antennas). Optimal loads connected to the ports 4 and 5 are almost equal as the antenna geometry is symmetric. The difference is mainly due to computational error. Thanks to antenna symmetry, the same optimal set of loads can be used in permutations in order to achieve the optimized gain of 9.8 dBi in four different directions of the horizontal plane as shown in Fig. 6. Nevertheless, the antenna gain drops at 5 dBi at the intersection of two different beams in the horizontal plane. The classical method to avoid this significant drop is to increase the number of parasitic antennas of the array, which leads to increase the size of the ESPAR antenna. In the next paragraph, we propose another approach to solve this issue.

C. Beam switching capability improvement in the horizontal plane

In order to keep a sufficient gain in the whole horizontal plane, we propose to increase the number of optimization angles. Typically, using four different sets of loads leads to optimize antenna's directivity and gain with a step angle of 15° compared to 90° with one set of loads. This method leads to reduce significantly the drop of gain, and to guarantee a minimum gain of 9 dBi in the whole plane. The gain patterns are plotted in polar coordinates from =0° to =90° with a step of 15° in Fig. 7. As mentioned in the previous paragraph, the permutation of the four sets of loads computed at the directions 0°, 15°, 30° and 45° will lead to cover the entire horizontal plane, as the antenna geometry is symmetric.

IV. WIDEBAND DIRECTIVITY OPTIMIZATION (758-803 MHZ)

In the previous section, a single frequency optimization at 800 MHz has been performed on the 5-element array. In this section, the same optimization method is applied with a step of 1 MHz from 758 MHz to 803 MHz to maximize antenna's directivity in the end-fire direction ( 0°, 90° . Real and imaginary parts of the frequency dependent optimal impedance loads are respectively plotted in Fig. 8-a Considering the real part of the impedance (Fig. 8-a), we notice that a quite flat negative equivalent resistor about -3 Ω is expected on port 2 to achieve the maximum directivity in the direction of interest. This kind of resistor can be achieved with an active circuit and have to be carefully designed in order to avoid instabilities in antenna system [START_REF] Batel | Sensitivity of negative impedance converter circuit with respect to PCB design effects[END_REF]. The other equivalent resistors are positive and those of port 4 and 5 are very close as the antenna is symmetric. If we look at the imaginary parts of the optimal loads, we observe a particular behavior. Typically, at port 2 and 3, the imaginary part is decreasing with frequency. This means that two Non-Foster equivalent capacitances are required to achieve a broadband Superdirective antenna [START_REF] Batel | Superdirective and broadband compact antenna array using non-foster elements[END_REF].

Antenna directivity and gain optimized in end-fire direction following the superdirectivity principle are plotted against frequency in Fig. 9. The red curves correspond to radiation properties of the antenna loaded with the broadband optimal impedances shown in Fig. 8. In this case, directivity and gain are almost flat in the band of interest and they are respectively close to 10 dBi and 9.8 dBi. The blue curves correspond to the case where the parasitic antennas are loaded with the optimal impedance computed at the central frequency of the considered frequency band 783MHz (Table 2). In this case, the antenna array achieves the maximum directivity and gain at 783 MHz and a drop of less than 1 dB is observed on the rest of the band. Finally, the green curves represent the case where the antenna is loaded with the optimal impedance computed at 783 MHz and the negative equivalent resistor is enforced to 0 Ω . We clearly observe that the negative resistor is not mandatory to achieve a gain higher than 9 dBi in our frequency band of interest. Meaning that the antenna array is not as sensitive, since the elements of the array are not so close (0.2 ).

V. CONCLUSION

This work has proposed the design of a high gain wideband compact and directive antenna with beam switching capability for subGHz IoT and 5G applications. The use of balanced antennas with a controlled radiation pattern led us to consider the super directivity principle to achieve both small size and directive antenna with a low profile (λ0/5 x λ0/2). An approach consisting in increasing the number of optimization angles rather than the number of antennas in the array led us to reduce the drop of gain while switching the radiation pattern of a 5-element ESPAR in the horizontal plane without changing antenna geometry. Thanks to the symmetry of antenna architecture, a gain greater than 9 dBi is obtained over the entire horizontal plane using only four different sets of optimal loads (24 beams of 15° resolution). Finally, an analysis of the optimized radiation properties of the antenna array in the frequency band 758-803 MHz has shown a tradeoff between antenna properties and the complexity of the frequency dependent loads. Thanks to the low sensitivity of the antenna, a gain greater than 9 dBi can be achieved in the frequency band of interest with simple discrete component loads.

Fig. 1 .

 1 Fig. 1. Single element Dipolar wire-plate antenna.

Fig. 2 .

 2 Fig. 2. (a) Frequency response of the single antenna and (b) radiation patterns in E-and H-planes.

Fig. 3 .

 3 Fig. 3. Schematic view of the 5-element circular array.

Fig. 4 .

 4 Fig. 4. Main steps of directivity optimization method.

Full

Fig. 6 .

 6 Fig. 6. Optimal gain pattern steered in 4 directions of the horizontal plane.

Fig. 7 .

 7 Fig. 7. Gain drop improvement in the horizontal plane with beam switching capability.

  and Fig.8-b.

  0

Fig. 8 .

 8 Fig. 8. (a) Real part and (b) imaginary part of the frequency dependent optimal impedance loads.

Fig. 9. 5 -

 5 Fig. 9. 5-element array directivity and gain in the band 758-803 MHz.

ACKNOWLEDGMENT

  This work is partially supported by public grant overseen by the French National Research Agency (ANR-19-CE24-0010-01, COMET5G project).

TABLE 1 :

 1 OPTIMIZED LOADS FOR A MAXIMUM DIRECTIVITY AT 800 MHZ

	Z	R (Ω)	C/L
	Port 1	50	-
	Port 2	-2.7	2 nH
	Port 3	3.8	40.5 pF
	Port 4	53	7.8 nH
	Port 5	52	7.6 nH

TABLE 2 :

 2 OPTIMIZED LOADS FOR A MAXIMUM DIRECTIVITY AT 783 MHZ

	Z	R (Ω)	C/L
	Port 1	50	-
	Port 2	-2.2	3.1 nH
	Port 3	4	0.1 nH
	Port 4	49	8 nH
	Port 5	47	7.8 nH


Gwendal Patat
email: gwendal.patat@irisa.fr

Mohamed Sabt
email: mohamed.sabt@irisa.fr

Pierre-Alain Fouque
email: pierre-alain.fouque@irisa.fr

WideLeak: How Over-the-Top Platforms Fail in Android

Keywords: Android, Digital Right Management, Over-The-Top, Widevine

Nowadays, most content providers rely on DRM (Digital Right Management) to protect media from illegal distribution. Becoming a major platform for streaming, Android provides its own DRM framework that does not comply with existing DRM standards. Thus, OTT (over-the-top) platforms need to adapt their apps to suit Android design, despite a fragmented ecosystem and little public documentation. Unfortunately, the security implications of how OTT apps leverage Widevine, the most popular Android DRM, have not been studied yet.

In this paper, we report the first experimental study on the state of Widevine use in the wild. Our study explores OTT compliance with Widevine guidelines regarding asset protection and legacy phone support. With the evaluation of premium OTT apps, our experiments bring to light that most apps adopt weak and potentially vulnerable practices. We illustrate our findings by showing how to easily recover media content from many OTT apps, including Netflix.

I. INTRODUCTION

The world almost fully moved over earlier days of owning media. Instead, many people watch videos on over-the-top platforms (OTT), such as Netflix and Amazon Prime, that distribute multimedia content over the Internet. Today, the most prevalent model is subscription-based services, where media can be played as often as the user wishes, but becomes unavailable when a user stops paying for the service. The large distribution of media in what can sometimes be hostile environments, like untrusted devices, creates challenges for content producers. The main challenge remains piracy; in 2020, the OTT market size was estimated at $13.9 billion and expected to reach $139 billion by 2028 [START_REF]Over The Top services market to reach USD 139.00 billion in 2028; emergence of Smart TVs by various companies to bolster growth[END_REF].

Thus, content providers rely on DRM (Digital Right Management), which is a technology that aims to protect media from illegal distribution. Modern DRMs ship content in an encrypted form, and then control their decryption through authorized players on users' devices. DRM systems are often cried out because of their insecurity. However, the recent surge of OTT platforms has led to ongoing adoption and evolution of such systems. For instance, World Wide Web Consortium (W3C) has published, despite being criticized [START_REF] Halpin | The crisis of standardizing DRM: the case of W3C encrypted media extensions[END_REF], the Encrypted Media Extensions (EME) [START_REF] Dorwin | Encrypted media extensions[END_REF], as the first official Web standard for DRM. Android devices have become a major platform for streaming content consumption. This has drawn interests from OTT platforms to develop mobile apps in order to reach a large number of audience in a thriving business ecosystem. Android has anticipated such a trend, and provided a DRM framework allowing the decryption of protected media streams. This framework supports many DRM systems; which DRM a device supports varies regarding the device manufacturer. The most dominant one is Widevine [START_REF] Widevine | Widevine[END_REF], which is also deployed on web browsers (eg., Chrome and Firefox), and smart TVs among others.

The ecosystem of DRM in smartphones is quite peculiar. First of all, starting from Android 7, Widevine takes advantage of hardware-backed security, such as TrustZone-based Trusted Execution Environment (TEE) [START_REF] Sabt | Trusted execution environment: What it is, and what it is not[END_REF]. In the past decade, much work has been done to evaluate the security of softwareonly DRM solutions based on obfuscation and cryptographic whiteboxes [START_REF] Wang | Steal this movie: Automatically bypassing DRM protection in streaming media services[END_REF], [START_REF] Chau | Why johnny can't make money with his contents: Pitfalls of designing and implementing content delivery apps[END_REF]. TEE-based Widevine arguably provides stronger protection, despite some successful attacks in the literature [START_REF] Zhao | Wideshears: Investigating and breaking widevine on QTEE[END_REF]- [START_REF] Machiry | BOOMERANG: exploiting the semantic gap in trusted execution environments[END_REF]. Second, the Android DRM API, is quite different from the standardized EME specifications that are defined for the Web. Therefore, apps developers need to rewrite a large part of their code, which may lead to inconsistency in security practices. This is especially true given that Widevine public documentations are sparse, which limits community discussions and sharing. Third, any DRM system has a long history of hacking and patching. Thus, they require to be updated in a regular basis. Unfortunately, it is not common that smartphones receive a long-term support from their manufacturers. Even Google used to only guarantee a three-year support for their Pixels [START_REF] Google | Learn when you'll get software updates on Google Pixel phones[END_REF], before Pixel 6.

In order to address such concerns, Widevine has issued a set of guidelines and recommendations to follow by OTT apps. However, little has been done to explore how these apps actually implement Widevine recommendations to protect their contents. In this paper, we focus on whether the security features offered by Widevine are properly leveraged. For instance, we empirically study if apps actually encrypt their contents with Widevine keys. One might argue about the relevance of such a question, especially that OTT developers are well aware of piracy threats. However, our evaluation shows that, for example, Netflix, which is the leader app with more than one billion installations, does not even encrypt audio tracks and just delivers them in clear. Our goal is to identify missing conformance of OTT apps regarding three Widevine security guidelines: content protection, usage of encryption keys, and support of discontinued devices.

We performed our evaluation on premium OTT apps. One might expect that Android has defined their DRM API, while taking into account Widevine guidelines, since both is owned by Google. A surprising result of our work is to uncover that there is some gap between actual implementation practices and what Widevine wants. By switching to TEE-based by default, the hope was that content piracy becomes old news. Nevertheless, we show that OTT apps might introduce new attack vectors rendering Widevine protection ineffective. We demonstrate the practical impact of our dire observations by obtaining DRM-free contents from six popular OTT apps, including Netflix, Hulu and Showtime. We insist that we do not look to introduce yet-another attack against DRM systems, but to better frame the misunderstood pitfalls of the rapidly growing Android DRM. We assess their prevalence, showing a rather concerning scenario.

Our contributions can be summarized as follows:

1) New findings and understandings. We conducted the first empirical study on how OTT apps leverage Widevine in Android. Notably, we automate apps monitoring by intercepting all calls to the Widevine process related to the DRM API. Our study reveals that almost no OTT app follows the Widevine recommendations in terms of cryptographic operations and revocation policy. 2) Real-world impact. To confirm the potential threats of our findings, we shed light on how certain practices allow an easy long-term compromise. We show that old still supported Widevine can be easily broken by recovering their software-only root of trust. Then, we reverseengineered the proprietary cryptographic operations of Widevine to automatically obtain the decryption keys of any media. Our work results in CVE-2021-0639. 3) Our automated monitoring tool and Proof-of-Concept source code are available online 1 for reproducibility purpose and to assist future work on this topic. Roadmap. The rest of the paper is organized as follows: section II presents the background information for our study. In section III, we present the research questions that we explore and that are related to Widevine security guidelines. Our findings and their practical impacts can be found in section IV. Section V details the limitations and future directions of this work. Section VI surveys the prior related research.

II. BACKGROUND A. DRM Systems

Modern DRM systems allow content providers to encrypt their media, and control who can decrypt them. The related architecture involves three parties: a Content Delivery Network (CDN) supplying encrypted content, a License Server providing the necessary keys to decrypt such a content, and a DRM module on the user device to retrieve these keys. For flexibility purposes, the part performing sensitive operations, such as decryption and license request, is implemented separately and called CDM or Content Decryption Module. Obviously, CDMs are required to protect the keys while using them. To this end, they mostly rely on closed-source proprietary protection mechanisms. Thus, every DRM system provides its custom CDM with its own interface.

B. Android DRM API

In order to cope with this fragmented ecosystem, Android offers a unified API in Java/Kotlin for DRM systems. Starting from API level 18, this is implemented by some HAL (Hardware Abstraction Layer) module called Media DRM Server that abstracts the actual running DRM from the programming interface used by OTT apps. The Android DRM API mainly consists of two modules: Media DRM and Media Crypto. The Media DRM is used to communicate with License Servers and to manage keys for a given media. As for Media Crypto, it is used to perform decryption. The DRM APIs support the ISO/IEC 23002-7: Common Encryption standard (CENC) [START_REF] Iso/Iec | Common encryption in ISO base media file format files[END_REF], but implement other encryption schemes.

Playing encrypted content when leveraging DASH (Dynamic Adaptive Streaming over HTTP) is summarized in Figure 1 and works as follows. First, the app constructs a Media DRM object and opens a new session. A Media Crypto object is then constructed and bound to the opened session. Next, Media DRM retrieves keys (aka licenses) from the License Server. The obtained keys are only accessible through Media Crypto. Indeed, the encrypted content is decrypted by a Media Codec instance to which the Media Crypto object was registered. Thus, MovieStealer as defined in [START_REF] Wang | Steal this movie: Automatically bypassing DRM protection in streaming media services[END_REF] does not work anymore, since the app has never access to the decrypted buffer. In addition to the DASH mode, the DRM APIs provide the ability to establish a secure session to protect arbitrary data.

C. Google Widevine

Widevine is a DRM solution acquired by Google in 2010. Its earlier version (supported up to Android 5.1) worked only with the proprietary format .wmv. The current version, called Widevine Modular, implements various standards, including MPEG-DASH and CENC. Widevine Modular, or henceforth simply Widevine, is supported on several platforms: Android (4.4+), Android TVs, Smart TVs, and Web Browsers (e.g., Chrome, Firefox and Edge). Widevine defines three security levels: L1, L2 and L3, where L1 is considered for playing HD videos. At L1, all operations take place inside a TEE. L2 and L3 are used when the TEE is not available. Android Widevine does not propose. For L3, the CDM is processed outside the TEE. Being less secure, L3 can only play sub-HD content.

In Android, Widevine comes as a dynamically loadable HAL plugin. Widevine is not open-source; only provided as binary code. In a top down architecture, Widevine-backed Android DRM works as follows. All calls to the DRM API go through some Java Native Interface (JNI) layer via the libmedia_jni.so library. Instantiated by the mediadrmserver process, the Media DRM Server receives these calls, and accordingly, reaches Widevine using HAL. Any communication with Widevine first goes to its specific library such as libwvdrmengine.so or libwvhidl.so. In L3, no further component is involved. As for L1, whenever CDM is required, this library calls liboemcrypto.so that sends the related requests to the Widevine TEE trustlet.

III. RESEARCH QUESTION

Despite the recent surge of streaming on Android devices, little has been done to understand how Android most popular DRM, namely Widevine, is used in practice within the Android DRM framework. Our paper takes the first step in this direction and explores the implementation choices of OTT apps regarding Widevine security guidelines. To better frame the scope of our study, we also quantify the usage of Widevine in the wild. Our goal is to gain insights into how do OTT apps follow Widevine recommendations to protect content? By addressing this question, we show OTT apps would introduce new attacks vectors that render DRM protection ineffective while leveraging Widevine. Accordingly, we aim to answer the following four questions: Q1: How often do OTT apps rely on Widevine? The main benefit of the unified Android DRM API is that developers can effortlessly rely on Widevine, or any Android integrated DRM, to protect content. The first question we intend to answer is how effective this API is for Widevine adoption.

In particular, we intend to quantify the OTT apps leveraging Widevine or custom DRM implementation like in Indian music industry [START_REF] Dabholkar | Looney tunes: Exposing the lack of DRM protection in indian music streaming services[END_REF]. Because most apps do not disclose whether Widevine is supported (an official list can be found in [START_REF] Widevine | Widevine[END_REF]), we need to fill this gap by conducting several experiments for both L1 and L3. The support for L1 is an important security trait, since it resists most attacks against software-based DRM. Q2: Do OTT apps encrypt their media contents using Widevine? In any DRM ecosystem, CDN servers deliver media contents to OTT apps. In a standard work flow, these contents are encrypted, and DRM modules in users' devices (aka CDM) require to decrypt them first. Nevertheless, the prevailing way of media consumption makes this operation less straightforward. Indeed, in most OTT apps, users are allowed to change the language (i.e., audio and subtitles) at any moment without negatively impacting users' experience. Thus, video tracks are obtained only once, while subtitles or audio are downloaded again for each language selection. In practice, these parts are sent separately, and thus might be differently protected depending on the OTT app that might choose for instance to only protect the video and not the audio. Moreover, the Android documentation of DRM API does not clearly explain this common scenario, which might inadvertently lead to unprotected contents. Our work investigates whether all media assets are DRM-protected for OTT apps: video, audio and subtitle tracks. Q3: Do OTT apps use multiple keys for content encryption? Widevine has issued a set of recommendations concerning DRM cryptographic key usage [START_REF] Widevine | Widevine News[END_REF] (similar ones are defined by W3C DRM standard EME [START_REF]Encrypted media extensions[END_REF] adopted by Widevine [START_REF] Widevine | Widevine DRM Overview[END_REF]). These recommendations state that video with different quality settings should be encrypted using a different key, and that audio files should be protected by an additional key. Obviously, such guidelines are defined to minimize the impact of a content key recovery, and therefore should be enforced. However, the use of multiple keys might make the code to manage more complex if no external media playback library is used, such as ExoPlayer [START_REF] Google | Exoplayer[END_REF]. Consequently, there might be some tension between Widevine recommendations about using multiple keys and apps implementations. In this paper, we intend to quantify the DRM keys received for each media. If an app does not encrypt audio tracks, or does not use distinct keys, we note such a practice as minimal. Q4: Do OTT apps still support L3 outdated devices? Widevine regularly updates their software. For instance, the release cadence for Android CDM is annual (per Android release). In order to keep away some vulnerable implementations, Widevine may revoke devices due to non-compliance with their security rules, e.g. no longer receiving security update. Nevertheless, OTT apps can ignore such revocation and deliver content keys to users [START_REF] Widevine | Widevine News[END_REF]. This practice is not recommended, since old Widevine implementations could be broken at some point without any security patch. The problem of outdated devices is not straightforward, because following revocation rules restricts the number of OTT potential clients. Here, we identify to which extent OTT apps still support potentially vulnerable Android devices to underline the delicate trade-off between availability and security. We emphasize that this problem is quite different from the fact that Widevine, by design, supports L3 that is inherently bypassable [START_REF] Github | DMCA[END_REF]. Indeed, breaking into legacy L3 should be easier than the latest L3 version. In addition, it should have longer impact, because no vulnerability will be patched.

IV. EXPERIMENTAL EVALUATION

As stated previously, our goal is to analyze the implementation choices of OTT apps while leveraging Widevine. In this section, we first describe our experiment setup to address our research questions, and review the methodology that we used to perform our evaluation. Then, we present our findings. Finally, we show how some of the existing practices can be abused to bypass DRM by targeting its weakest link.

A. Evaluated Apps

In our work, we evaluate the following Android OTT apps (with their number of installation in millions at the time of writing): Netflix (1,000M+), Disney+ (100M+), Amazon Prime Video (100M+), Hulu (50M+), HBO Max (10M+), Starz (10M+), myCANAL (10M+), Showtime (5M+), OCS (1M+), and Salto (1M+).

The selection was based on the list of Widevine clients [START_REF] Widevine | Widevine[END_REF] as well as their popularity on the Google Play Store. Unfortunately, we could not extend our study to more apps because of platforms restricting their client to register with a bank account in a particular country. However, our code can be easily applied for other apps.

B. Methodology

We could have answered all our research questions by looking directly into OTT apps. However, we did not consider such an option for two main reasons. First, they are closed-source, and their design and implementation differ considerably. This would have required substantial amount of reverse engineering that is specific for each app. Second, most evaluated OTT apps apply anti-debugging techniques such as time checking [START_REF] Xue | Happer: Unpacking android apps via a hardware-assisted approach[END_REF], or rely on SafetyNet [START_REF]Protect against security threats with SafetyNet[END_REF] to hinder any dynamic analysis. Therefore, we preferred to focus on the Widevine HAL plugin. In particular, we precisely identify the work flow for each app regarding Figure 1, by monitoring all Widevine activities involved in the DRM API. This approach presents multiples advantages. Indeed, it bypasses all protection mechanisms implemented by apps to block dynamic analysis. Moreover, it can be easily automated. Nevertheless, in order to address some of our questions, we will still need to note OTTspecific information. Accordingly, we design our methodology considering a human in the loop, which also implies to limit the number of evaluated apps. Furthermore, the lack of documentation on Widevine made the manual analysis necessary before implementing our monitoring tool. DRM API Monitoring. Here, we take a two-pronged methodology. First, we decompile the Java classes of the evaluated OTT apps to identify some of the included Android classes. More specifically, we scan all calls to MediaDrm and MediaCrypto methods that are required within a Widevine session. However, we are aware that some apps might include some dead code. Thus, in order to err on the side of soundness (i.e., low false positives), we monitored Widevine component functions linked to the Android Media DRM framework while playing protected content. Indeed, for both L1 and L3 security levels, we intercept and note any function called within the CDM process linked to the Widevine protocol (namely _oeccXX functions), loaded in mediadrmserver starting from Android 7 and mediaserver otherwise. To this end, we leverage Frida [START_REF] Ravnås | Frida[END_REF] to hook CDM calls. The use of L1 is confirmed whenever the control flow reaches liboemcrypto.so, since L3 is characterized by the fact that all calls stay within libwvdrmengine.so (the Widevine library name can differ between devices). In our Github 2 , we provide a Frida script that automates OTT app monitoring. Moreover, to allow more in-depth analysis, we dumped input and output buffers related to various functions, including non DASH mode (e.g., generic encrypt and decrypt). Content Protection. By protection, we mean cryptographic encryption by Widevine. When an OTT app asks for some media, the related CDN server does not deliver it directly. Instead, it sends several URI links that are used by apps to download all required video, audio and subtitle tracks. Contents might come encrypted or clear. Our approach mainly consists of obtaining these URI links for each OTT app, to determine whether the downloaded contents are protected or not. For this purpose, we just rely on video or audio players to read the downloaded files. As for subtitles, we check whether they contain ascii characters for English ones.

The main challenge in our approach is that apps also protect these URI links, and thus we have to find them. First, we keep monitoring all function calls to the CDM process, and more particularly non DASH mode, as it might be used as a secure channel to protect arbitrary data. In addition, we intercept the received network packets when selecting and displaying protected content to recover media URI and Media Presentation Description (MPD) files. Because of the use of TLS, we require to implement SSL repinning technique using Burp [START_REF] Portswigger | Burp suite[END_REF] and Frida. Moreover, we note the used key IDs for each content by parsing the MPD files and their related OTTspecific metadata. Finally, we perform our experiments for L1 and L3 to assess that it does not depend on security level. Outdated Device. Our approach is straightforward: we use Nexus 5 phone to display content. Released in 2013, it did not receive an official Android 7.0 in 2016, and thus Android 6.0.1 becomes its last update. It runs Widevine in L3 mode with CDM version 3.1.0. This is quite old, as the current CDM version is 15.0 in 2021. In our experiments, we attempt to display some media content on Nexus 5. We also keep monitoring all calls to Widevine. We distinguish two cases:

(1) the app can display Widevine protected content, and (2) the app uses Widevine, but no content can be displayed.

C. Results

Our results are summarized in Table I. Q1. All the evaluated apps depend on Widevine for content playback, and not on some custom app-specific DRM solution. One exception is Amazon Prime Video using an embedded Widevine library when just the L3 software-only mode is available. We also find that the L1 TEE-based mode is popular, unlike what was predicted in [START_REF] Chau | Why johnny can't make money with his contents: Pitfalls of designing and implementing content delivery apps[END_REF]. This is an important trend, since TEE becomes mandatory starting from Android 7. Q2. Based on our findings about Widevine usage, we check whether OTT apps protect their contents. We first look for URI links related to content assets: video, audio and subtitles. First, using public Frida resources, we succeeded in bypassing SSL repinning on all OTT apps, which shows how ineffective such a security mechanism is. Then, we analyzed the network packets for each app. Once we found the URI links for a given media, we downloaded the associated assets and checked their protection status. A notable exception is Netflix that creates a secure channel between Widevine and the CDN to protect URIs through the non DASH Widevine API. This protection does not prevent us from recovering Netflix links by intercepting the output of some Widevine functions. Overall, we obtained all URI links for all OTT apps, except the subtitles URI for Hulu and Starz. Our investigation finds that video tracks are always encrypted, contrary to subtitles that are always in clear (we could not confirm this for Hulu and Starz). The case of audio tracks is more peculiar. Most OTT apps encrypt their audio, except for Netflix, myCanal and Salto.

In fact, for these apps, audio in any language can be played anywhere without any OTT account. Q3. As noted in Q2, most OTT apps protect their video and audio. Here, we explore whether they are encrypted with different keys. Of course, we cannot tell by just looking into the encrypted files. Thus, as explained previously, we analyzed some metadata indicating the identifier for every decryption keys. Our observations show that all evaluated OTT apps properly encrypt their videos with different keys depending on the resolution. This implies that we cannot trivially recover HD resolution, while breaking L3 mode. However, given the same resolution and the same content, many OTT apps are confirmed to use the same key for both video and audio, which is not recommended for DRM solutions by Widevine or EME. As for apps that do not protect audio, namely Netflix, myCanal and Salto, Widevine also considers this practice as a minimal recommendation setting. Only Amazon Prime Video strictly follows Widevine recommendation by always using distinct keys. For Hulu and HBO Max, we were unfortunately not able to conclude our analyses due to some regional restrictions. Q4. On our Nexus 5 with its Android 6, the installation process succeeds for all OTT apps. Connected to a valid OTT account, we attempted to display some media. We notice that Disney+, HBO Max and Starz reject to provision Widevine with valid licenses, implying that Nexus 5 is actually revoked. Thus, media contents and their decryption keys were not even delivered to our Nexus 5. However, the remaining seven apps do provision Nexus 5 as a valid device, and therefore display the required media. One restriction was on the video quality, since Nexus 5 only supports L3, hence no HD video. Insights and Learned Lessons. Our evaluation highlights the large adoption of Widevine by OTT apps on Android devices. More importantly, we find that TEE-backed Widevine is widely leveraged thanks to the unified Android DRM API. This shows that OTT apps are aware of piracy threats, and therefore look to rely on modern security technologies, such as TEE. However, we also find that this does not prevent developers from opting for bad security practices. Indeed, OTT apps do not protect subtitles. There might be two reasons for this. First, OTT frameworks do not consider subtitles as a valuable asset to protect. Second, there is no API to deal with encrypted subtitles in the Android DRM API. This might also uncover the rational behind why most apps do not follow Widevine recommendation to use distinct keys for video and audio. The case of subtitles is more special though. Indeed, we notice that many apps call DRM API through ExoPlayer as recommended by Widevine [17]. This playback library proposes some API allowing developers to provide encrypted audio and video, but not subtitles. However, this API is not yet widely used with different keys. We highlight an unexpected result in our study: Netflix does not protect audio tracks. During our responsible disclosure, we discovered that Netflix was not even aware of that, because they believed that non-Dash mode was sufficient. App developers should not take all the blame, since the Android API does not make it easy to implement Widevine guidelines. However, we think that our results are surprising, since Widevine recommends ExoPlayer providing a demo app with best practices [START_REF] Google | Exoplayer[END_REF].

Finally, we shed light into the problem of license distribution. We notice that many OTT apps care more about reaching more clients than applying the revocation rules of Widevine: they allow the playback of protected content on devices no longer receiving security update. Note that most Android devices have short security update support period with for instance three years for Google Pixels [START_REF] Google | Learn when you'll get software updates on Google Pixel phones[END_REF] and five only for the latest model. This might seem anecdotal, but we will show in subsection IV-D how an attacker might exploit a weak Widevine implementation to recover media contents.

D. Practical Impact

We argue that discontinued phones constitute one of the weakest link in the DRM ecosystem. Indeed, the threat model of DRM includes attackers that have full control on their devices. This is due to the fact that the same media, with different resolution, is played everywhere, and the only incentive of an attacker is to recover that media, regardless of the targeted device. We demonstrate the practical impact of our results by obtaining DRM-free contents from all OTT apps still supporting old devices (except Amazon). To do so, we first analyzed Widevine internal key ladder from its root of trust to content decryption key. By reverse engineering, we found three main keys:

• Keybox: 128-byte structure including a magic number and a 128-bit AES Device Key. This key is installed by the manufacturer, and constitutes the root of trust (RoT). • Device RSA Key: 2048-bit private RSA key. This key is installed when needed by the Provisioning Server. The installation process is protected by the keybox. This RSA key protects the Content Key sent by the License Server. • Content Key: 128-bit AES key for media decryption. During our reverse engineering. we find that the keybox is used to initiate the key ladder. By dynamically monitoring memory regions that are used during obfuscated cryptographic operations within libwvdrmengine.so, we searched for specific keybox structure (e.g., magic number). Thus, we succeeded in recovering the L3 keybox on our deprecated Nexus 5 due to an insecure storage of sensitive information (CWE-922), that lead to our CVE-2021-0639. 3Once we recovered the keybox, we were able to obtain the provisioned Device RSA Key. Then, we mimic the rest of the key ladder by intercepting Widevine function arguments to recover derivation buffers and encrypted keys. We implement this key ladder to automatically recover the media-related Content Key. During our experiments, we found out that OTT apps use the same keys for all their subscribers for a given media. Finally, we use MPEG-CENC [START_REF] Iso/Iec | Common encryption in ISO base media file format files[END_REF] to decrypt all protected contents. With some processing, we reconstruct the pirated media and play it on another device (i.e., personal computer) without any OTT account. Since keys depend on the required quality and all media in our experiments was requested from Widevine L3, the best quality that we get is unsurprisingly 960x540, which is qHD (quarter high definition).

Our PoC (proof of concept) of the key ladder can be found in our GitHub 4 . Following our ethical approach, we only provide the implementation of the key ladder without the associated Device RSA Key, nor keybox. Thus, nobody can use it to actually pirate OTT contents. Note that our PoC works for both L1 and L3. However, we only applied it on Widevine L3. Our purpose is not to define yet another attack against DRM systems, but to show that some outdated L3 security protection can lead to a simple long-term compromise because of discontinued devices. We stress the fact that there is currently no clear solutions to the upgradeability of deprecated phones, even if the situation might be improved in the future. For this reason, we believe that OTT apps must strictly abide to Widevide revocation rules to avoid piracy.

V. DISCUSSION

A. Responsible Disclosure

Our findings have been timely reported to all concerned parties following their responsible disclosure process. Netflix was quite responsive and we got rewarded via their bug bounty program. Regarding Google Widevine, our security report was assigned with the highest priority within the Google Vulnerability Reward Program (VRP). The Widevine security team investigated our findings and issued a patch to mitigate our identified flaws. Google assigned the CVE ID 'CVE-2021-0639' for us, and acknowledged us in the Google Hall of Fame and the Android Security Acknowledgments. Our goal is to improve the state-of-the-art knowledge of DRM internals and not to provide copyright infringement tools.

B. Not Just Another Attack

We insist that our work does not present a new attack against DRM solutions. Instead, we show that bad implementation practices imply new attack vectors that can be abused to recover DRM-free contents in Android smartphones.

In particular, we show that OTT apps do not use Widevine protection to the fullest, and this might be due to lack of public documentation (therefore community discussion) and complex proprietary design. Moreover, we show that DRM protection is quite brittle if we include all the supported, yet outdated, versions. We successfully demonstrate that deprecated phones create more risks than benefits. Note that no SafetyNet or antiscreen recording techniques can be of any use, since attackers only need to monitor Widevine that runs in a different process.

C. Limitation & Future Work

As any study, our work is not exempt from limitations. Our paper focuses on the most popular DRM solution on Android smartphones, namely Widevine. However, Huawei's devices offer their custom DRM solution, called WisePlay. Moreover, outside the smartphone ecosystem, Widevine is present on Android TVs, web browsers on different operating systems, and small devices (e.g., Chromecast). Studying similarities and differences among these different implementations constitutes the main future direction of this work. We hope that our tools will encourage more work on these topics to reach other platforms and CDMs with fully automated approches.

Another limitation is that our PoC can only recover video with sub-HD quality. It is not clear how Widevine enforces the control on video transmission regarding the security level. On PCs, the Github project netflix-1080p [START_REF] Truedread | netflix-1080p[END_REF] explains how to get HD quality on L3 by just modifying the profiles to be sent to the CDN. This implies that there is no strong verification for web browsers. An interesting future work is to adapt this exploit to Android in order to get the license keys of HD contents without breaking into the Widevine L1.

VI. RELATED WORK

A. DRM Researches and DMCA

Despite the widespread of Widevine, surprisingly, no much attention has been given to the security of its underlying protocol. The main reason behind such a lack of public security analysis is the DMCA's 1201 clause that makes it illegal to circumvent controls preventing access to copyrighted material. Consequently, researchers cannot investigate and discover security vulnerabilities if doing so requires reverse engineering or circumventing controls such as obfuscated code. This law has already been used against security researchers to censor their work, as shown by Hewlett-Packard against Snosoft in 2002 [START_REF] Mccullagh | Security warning draws DMCA threat[END_REF]. Unfortunately, over fifty court-cases have been launched against security research as of 2016 [START_REF]Reported case list[END_REF].

Nevertheless, restrictions have been partially lifted recently. Indeed, in October 2018, the American Library of Congress and the Copyright Office have expanded the exemptions to DMCA. Therefore, in theory, researchers can now freely investigate and publish security flaws on DRM solutions.

B. Bypassing DRM & Widevine Keys Recovery

In the past decades, multiple techniques have been developed to circumvent now outdated DRM solutions without having to break the underling scheme, like MovieStealer [START_REF] Wang | Steal this movie: Automatically bypassing DRM protection in streaming media services[END_REF] targeting content decryption to recover decrypted buffers within the decoder when no TEE is available. Analog loophole was also used to capture analog signals of the protected content by screen-recording or through connectors.

In 2019, David Buchanan claimed to have broken Widevine L3 DRM on Linux Chrome browsers. In a tweet [START_REF] Buchanan | Breaking Widevine L3 on Linux Chrome browser[END_REF], which is the only available information about this attack, Buchanan mentioned that Widevine L3 relies on AES-128 Whitebox to protect the keybox. This attack gets a large number of articles on the web, all of which relied merely on the tweet of Buchanan who has never provided any further detail.

In October 2020, Tomer Hadad released widevine-l3decryptor in Github. This project is a Chrome extension on Windows that contains a hard-coded value of an RSA key pair used by Widevine L3 unique for all Windows devices. Hadad mentioned that he extracted the RSA private key "by applying some mathematical tricks to Arxan's whitebox algorithm". In November 2020, Google issued a DMCA takedown request against widevine-l3-decryptor and all its forks [START_REF] Github | DMCA[END_REF]. This proves that Google still views L3 security as a serious matter.

In May 2021, Zhao [START_REF] Zhao | Wideshears: Investigating and breaking widevine on QTEE[END_REF] broke into the Widevine L1 trusted app to recover the Widevine keybox of a Pixel 4. However, he did not show how a recovered keybox can be used to decrypt protected contents. In our work, we took this further step and implemented the cryptographic mechanisms of Widevine.

C. Closed Source API Analysis

Our work inspects the misusage of the Widevine API by OTT apps. Similarly, other works have been made to analyze closed source proprietary API on Android. For instance, Bianchi et al. [START_REF] Bianchi | Broken fingers: On the usage of the fingerprint API in android[END_REF] have inspected the fingerprint API and its misuage by app developers, leading to multiple attacks ranging from confused deputy problem to full fingerprint bypass. In their work, Ibrahim et al. [START_REF] Ibrahim | Safetynot: on the usage of the safetynet attestation API in android[END_REF] looked at the SafetyNet Attestation API used to detect if an app is running in a non compromised Android environment. Their findings point out that more than half of analyzed apps were using trivially bypassable checks while none were correctly using the SafetyNet API.

VII. CONCLUSION

In this paper, we report on an empirical evaluation of the protection mechanisms used by content providers within Android to protect their media assets. Our study shows that OTT apps relies on Widevine using TEE protection when available but do not comply with Widevine recommendations in encrypting video and audio with distinct keys or regarding revocation of old devices. We investigate the OTT apps support of Android legacy devices running the software-only Widevine DRM no longer receiving security updates. We expose that by choosing large content distribution over security, OTT apps have extended the device attack surface. We show that such vector can be trivially exploited to recover DRM-free movies from six OTT apps including Netflix, Hulu and Showtime. We hope that this paper will push research forward in this domain and encourage furture works.

  using custom DRM if only Widevine L3 is available. Minimum: Audio in clear or using the same encryption key as the video. Recommended: Audio and Video are encrypted with different keys.

				TABLE I
		WIDEVINE USAGE AND ASSET PROTECTIONS BY OTTS
	OTT	Widevine used (Q1)	Content Protection (Q2) Video Audio Subtitles	Widevine Key Usage (Q3)	Playback on L3 (Q4) discontinued phones
	Netflix		Encrypted	Clear	Clear	Minimum
	Disney+		Encrypted Encrypted	Clear	Minimum
	Amazon Prime Video	†	Encrypted Encrypted	Clear	Recommended	†
	Hulu		Encrypted Encrypted	-	-
	HBO Max		Encrypted Encrypted	Clear	-
	Starz		Encrypted Encrypted	-	Minimum
	myCanal		Encrypted	Clear	Clear	Minimum
	Showtime		Encrypted Encrypted	Clear	Minimum
	OCS		Encrypted Encrypted	Clear	Minimum
	Salto		Encrypted	Clear	Clear	Minimum
	Widevine fails during provisioning phase.

†

https://github.com/Avalonswanderer/widevinel3 Android PoC

https://github.com/Avalonswanderer/widevinel3 Android PoC

https://www.cve.org/CVERecord?id=CVE-2021-0639

https://github.com/Avalonswanderer/widevinel3 Android PoC