Secure streaming from backend to app: A holistic approach for OTT and PayTV services
In the fast-evolving realm of streaming services, safeguarding digital content from piracy and cyber threats has become a never-ending battle. While Digital Rights Management (DRM) once stood as the sentinel of content protection, today’s landscape demands a broader, more sophisticated security approach. As hackers continually refine their tactics, the quest for secure OTT and PayTV streaming applications transcends DRM, venturing into uncharted territory where attackers target app infrastructure, device hardware, and operating systems.
This article delves into the pursuit of excellence in OTT and PayTV app safety, exploring both proven and new security best practices and strategies that stretch far beyond conventional content protection. By embracing a security-first mindset and orchestrating a symphony of backend and app-based defenses, streaming service providers can raise the bar against cyber threats, ensuring their content is protected to the highest standards and viewers’ data remains out of harm’s reach.
Current streaming security landscape
Streaming providers face multiple cybersecurity threats, from content pirates to malware and exploits. It’s imperative that their apps and backend services are implemented with security in mind, and incorporate proper defense and attack mitigation techniques. Unfortunately, state-of-the-art content protection alone isn’t enough anymore. Advances in tooling for hackers make it easier than ever before to deploy malware and compromise device hardware, its operating system, applications, and services.
Service providers must be aware of risks associated with their backend and app infrastructure and adopt a security-first mindset. It’s necessary to adopt the principles of the zero-trust security model to adequately prepare for the worst-case scenario – which is statistically inevitable. Threats that can’t be fully mitigated, such as insecure endpoints (e.g.: devices and apps), should be recognized, and a strategy to limit the “blast radius” of potential exploits should be developed and documented in a security concept. The goal is not only to raise the cost and complexity of an attack but also to limit its effectiveness and value by making success short-lived and restricting the amount of extractable data.
A strong security approach involves analyzing the entire service for potential vulnerabilities and data exfiltration targets, and tailoring defenses to safeguard valuable data effectively. For instance, the threat landscape differs between a banking app and a game, with the former containing more sensitive personal data. Similarly, a video streaming platform manages personal information, billing details, and user profiles, alongside instructions for accessing premium content through a CDN and obtaining DRM licenses for decryption. Potential threats encompass malware seeking personal info and account credentials, as well as unauthorized users attempting to download extensive content, extract decryption keys, and access decrypted material.
Backend-based defenses and mitigations
Several threats can be mitigated through backend protection measures. For example, APIs mustn’t grant access to credit card details, even for authenticated users. It’s advisable for applications to avoid local storage of personal or sensitive data, including API keys. Such information ought to be fetched from backends dynamically. These backends should evaluate device trustworthiness, potentially restricting data access and prompting users for re-authentication of sensitive information. This could ideally involve biometrics or a secondary factor like a One-Time Password (OTP).
Authentication should typically use a second factor and ideally replace username/password with logins via trusted external identities and biometrics. These measures make stolen usernames or passwords less effective for attacks. If possible, the service should eliminate passwords altogether to prevent theft from the outset.
Authentication tokens must be short-lived, replay-protected, and encrypted when stored. They should be linked securely to keys managed by the device’s key store. For the most secure content access, hardware-backed keys should be used, irrespective of the need for hardware-based DRM during playback. The service must monitor cryptographic key identities tied to devices to detect potentially stolen key data being used in unusual situations. Ideally, techniques like OAuth DPoP or mutual TLS should be employed to cryptographically tie authentication tokens to the requesting device. This notably reduces the potential for exploiting stolen API access tokens.
Content access should be fine-granularly controlled on title and quality level (limiting quality according to device security guarantees), linked to active playback sessions (revoking access across all systems when playback stops), limited in concurrency, and geo-fenced. Suspicious activity (e.g. attempted access to all qualities of a title at once, or multiple titles at once) should be rate-limited, blocked, or even lead to account suspension.
The content itself should be DRM-protected with different keys for each rendition quality to securely enable dynamic device or account-based quality limits by restricting key access, and ideally marked with a session-based forensic watermark to aid forensic analysis (for identifying leaking account and device). Such a mark should be implemented at the CDN level to avoid manifest manipulation which can be easily detected and exploited. However, attacks are still possible, and watermarks might be corrupted or rendered unreadable.
Multi-key delivery restricts key access based on video quality
Concurrent stream limiting restrains the number of simultaneous users
Forensic watermarking provides another layer of protection
Combining all mentioned backend-based defenses offers a comprehensive set of controls that go a long way towards a zero-trust architecture, potentially restricting content access to regular patterns (such as download limits). When account usage aligns with limits on concurrent access, geolocation, account-bound devices, and device security guarantees; impersonating users via stolen authentication tokens becomes considerably challenging – this is in addition to the initial token theft hurdle. Moreover, this impersonation holds limited value due to account-level constraints and rapidly expiring access tokens. Finally, when content access is tightly controlled and linked to active playback sessions (potentially with download speed and range limits), stealing content would become a painstakingly slow process.
For attackers, this could lead to increased value in reverse engineering an app to either remote control it or replicate its behavior in a programmatic environment to enable scripted automation. Employing code obfuscation and anti-debugging tools then becomes crucial to heighten the challenge. However, an attacker who manages to obtain working credentials can briefly access and potentially pirate content, much like a regular user, especially when using the original app on a device they control. This remains an inevitable threat, emphasizing the need to apply the zero-trust security model to devices and apps, viewing them as inherently untrustworthy.
It is essential to focus on reducing the blast radius by, for example, requiring access tokens to be refreshed within minutes, and by limiting the amount of accessible content to the furthest extent possible. Furthermore, implementing methods for pinpointing vulnerabilities, detecting active exploits, and supporting forensic analysis with data to identify and counter the attack vector is crucial.
App and device-based defenses and mitigations
When the previously detailed backend security controls are in place, only a few of the mentioned threats directly concern the app or device, most of those falling into one of two categories:
- Malware extracting user data like account credentials (e.g. via keyloggers) and/or modifying app behavior to trick users into doing or revealing something of value to the attacker (e.g. purchasing something).
- Pirates reverse engineering and instrumenting the app and/or device to gain access to content, decrypt it if needed, and potentially attack a forensic watermark.
Malware attacks usually happen remotely on devices in the field. Attackers must rely on social engineering and/or certain Android version exploits or device types to intrude, perform a privilege escalation, and gain access to a targeted app or launch a man-in-the-middle attack. Though challenging, this is feasible. However, assuming all backend measures above are deployed, including a login process that requires two-factor authentication, it would become questionable what sensitive data would be left to extract from an app. When adhering to best practices, the worst-case scenario would involve a short-lived access token, granting only a few minutes of content download capability.
Pirates, however, while sometimes relying on stolen credentials stemming from malware attacks, typically perform hacks on devices that they can physically access. It opens a much wider attack surface than malware attacks, and it’s much harder – up to probably impossible – to mitigate.
There are different tools and strategies available to mitigate various attack vectors for apps and devices. Here is, without aiming at completeness, an overview:
- Encryption and cryptographic proofs to protect data at rest and in motion from direct access and manipulation. Great care in handling key material, preferably locking private keys into hardware modules.
- The device, app, and key attestation: modern media consumption device platforms can provide guarantees (an “attestation”) about their identity, their hardware-stored keys, and their configuration. Additionally, they can provide a comprehensive security status determined through cryptographic signatures of the code they run and whether said signatures are trusted, from the earliest boot code all the way up to the app. This is also increasingly backed by secure hardware. App stores offer signals, including hardware-backed attestation results if available, to help inform a judgment by backend APIs whether an app is likely unmodified and runs on an unmodified device, and how trustworthy that information may be.
- Hardware-backed keys and Secure Execution Environments promise a trusted device state with a secure boot, robust confidentiality for secrets and cryptographic calculations, and a hardware-secured media path on some devices. These promise to keep sensitive data confidential in a “secure world”, physically (at least in terms of CPU cores) physically separated from the OS and application code. However, hardware vulnerabilities and exploits are not uncommon, prompting firmware/microcode patches. In some instances, hardware patches may be necessary, rendering devices irreparable and requiring service access denial. Notably, side-channel attacks in recent years highlight the potential manipulation of hardware, often demanding advanced skills to exploit. The prevalence of such attacks underscores the accessibility and sophistication of available attack tools.
- Classifying devices and apps based on their security guarantees and security patch levels, while denying or limiting access to sensitive data/valuable content based on that classification. Only fully-trusted hardware platforms should have access to the highest-quality content versions.
- Malware scanners and intrusion detection can be deployed on service-provided devices to monitor suspicious activity.
- Traditional software security solutions like code signing, code obfuscation, anti-debug measures, self-monitoring and self-repairing code, emulation detection, whitebox cryptography, etc., can be applied to apps. A range of open-source and commercial tools offer diverse protection levels. For the utmost security, critical parts of an app should be written in native code, intensifying app development complexity.. Unfortunately, this approach has limitations as code modifications from security solutions merely complicate reverse engineering without providing secure memory locations: there’s no safe place for secrets in memory that can be dumped one way or another. Any software security solution ultimately tries to conceal secrets in plain sight of attackers, rendering determined attackers likely to succeed, given the array of hacking tools available. Despite this, the process can be convoluted enough to deter average hackers. Thus, adopting some form of code obfuscation is advisable, along with attempts to reverse engineer and deobfuscate to comprehend the remaining attack surface.
- Cloud-based app security and monitoring services provide agents or SDKs that can be added to an app. They often employ previously discussed measures to bolster apps and collect runtime data, sent to a backend for analysis. Device or app trustworthiness is determined from this data, forming attestations that guide APIs in access decisions. While additional data enhances accuracy, incorporating third-party capabilities enlarges the attack surface, possibly introducing vulnerabilities and supply chain risks. This also fosters similarity between apps, increasing susceptibility to exploits. Before integrating third-party services, services must balance value and risk. Alternatively, a streaming service could gather its unique signals (based on usage patterns and previous measurements) for similar judgment calls.
A backend with a solid security and authentication architecture can reduce the attack surface of the app significantly, leaving media playback and content protection the largest remaining targets. Nonetheless, apps should prioritize leveraging app-based defenses to safeguard secrets and sensitive data, however short-lived it is. Often a combination of small vulnerabilities can lead to a large exploit. For instance, a misconfigured server might generate access tokens with prolonged validity, underscoring the value of cryptographically binding tokens to devices to reduce the blast radius of such a configuration error. It will help the service provider to gain time to identify the error and invalidate all affected tokens server side. This means that even in that scenario, relying on trustworthy devices can never be the last or only line of defense.
Zero trust for apps!
The mentioned software security tools, and app protection and monitoring services, help to improve protection against specific attack vectors and increase the complexity of reverse engineering. Nonetheless, this comes with its own set of trade-offs. When adhering to the security best practices outlined in this article, it becomes evident that there’s limited incentive for reverse engineering or direct app attacks. This is primarily due to the comprehensive backend security controls essentially treating the app with “zero trust,” as long as the backend remains uncompromised and avoids excessive access grants. The same analysis might look different for other types of apps that need much stronger protection from intrusive modifications that could change values or extract PII – like e.g. a banking app.
In the realm of OTT/PayTV service and app security, the path to resilience requires a multi-dimensional strategy. By bolstering backend defenses with app- and device-based fortifications, and most importantly, by cultivating a security-focused mindset, streaming service providers can craft a robust shield against a diverse array of cyber threats. The evolving battle calls for a dynamic security approach, where device attestation, encryption, classification, and vigilant monitoring combine forces to thwart attacks and mitigate vulnerabilities. As the content streaming landscape continues to morph, the quest for improvement in security remains steadfast, leaving no room for complacency. In this perpetual journey toward fortification, streaming providers remain poised to secure their digital ecosystems and offer viewers an experience founded on trust, resilience, and uncompromised quality.
*A shorter version of this article was originally published on the IBC 365 website on September 8th, 2023.