Skip to main content

DRM Security Best Practices

Introduction​

It's no secret that video piracy is a growing threat to the media industry. The digital distribution and widespread popularity of video streaming have significantly increased and globalized the threat of piracy. Every operator of an OTT solution is confronted with the challenge of protecting their content from piracy.

Everybody knows, DRM can help. In a nutshell, it works like this What is DRM?:

  • Generate a content key
  • Encrypt the video with the content key
  • Distribute the video to its consumers via any (unprotected) channel
  • Provide the content key only to a trusted Content Decryption Module (CDM) for authorized users.
  • The CDM enforces content usage policies, controlling what authorized users can do with the video.

"So, I introduced DRM to my solution. Am I now safe?" - people ask.

Not quite. It depends on HOW you implement DRM. DRM must be properly applied to achieve the desired effect. There are too many ways to implement it incorrectly or insufficiently secure. And DRM alone will not help if you don't design, implement, and operate your entire solution in a secure way.

In this article, we will share some best practices to help you get the most out of your DRM solution and to avoid common pitfalls.

Industry Recommendations​

Video security is a collaborative effort and works best if the industry works jointly.

Excellent examples of such collaboration are the documents release by the Security working group of SVTA (Streaming Video Technology Alliance):

Another great source is the document from MovieLabs:

This article aligns well with the recommendations above.

Entitlement vs DRM License​

Let's follow the reference architecture from the SVTA OTT Streaming CDN Security Best Practices:

Architecture of a typical streaming operator (Source: SVTA OTT Streaming CDN Security Best Practices)

DRM interactions are split into two steps:

  • Playback Request - client asks for a permission to play a specific content and receives an authorization token used for a subsequent DRM License Request
  • DRM License Request - client provides the authorization token and receives a DRM License that allows the playback of the content using specific DRM technology

With Axinom DRM, we use the term "Entitlement Service" for a component serving playback requests and performing playback authorization.

It issues entitlement messages wrapped in a signed token (JWT). The token is then used in the DRM License Request to obtain a DRM license. All the rules are defined in the entitlement message, which makes it a crucial part of your security architecture.

Let's look into the entitlement message in more detail.

Best practices for entitlement message / token​

Limit authorization to a specific key (or set of keys)​

Below is the simplest and arguably worst way to create an entitlement message. It doesn't refer to any specific key. This means, with this token, a client can request a DRM license for ANY key, and will get a valid license.

{
    "type": "entitlement_message",
    "version": 2,
    "content_keys_source": {
        "license_request": {}
    }
}

This generally is a bad practice. It's like giving a blank check to a client. Avoid this unless you exactly know what you are doing and ANY license request should actually be granted.

Instead, use specific key ID(s) in the entitlement message:

{
    "type": "entitlement_message",
    "version": 2,
    "content_keys_source": {
        "inline": [
            {
                "id": "11111111-0000-0000-0000-000000000000"
            }
        ]
    }
}

This allows your entitlement service to authorize keys individually. You can authorize multiple keys in one entitlement message.

Use unique content encryption keys for each asset​

It's technically possible to re-use encryption keys across assets. In its extreme form this practice leads to using the same key for all assets. This is another bad practice which is to be avoided. An adversary who gets access to just that one key potentially can decrypt all of your content.

Instead, request a unique encryption key for each asset to maximize protection.

Axinom Key Service provides a number of ways to acquire keys. The generated keys are cryptographically strong. It's recommended to acquire a new key for each new asset to be encrypted.

Limit the duration of the entitlement​

Entitlement is delivered to the client as a signed JWT, where the entitlement message is the payload. The JWT has an expiration time (expiration_date below), which should be set to a reasonably short value (e. g. one minute in the future).

Add a random “id” to each JWT (like below: "id": "c76d9f99-dd53-46a0-8aa0-1dc8a931202d"). This will allow you to identify JWTs later and make debugging and tracking attempts of token reuse easier.

{
    "version": 1,
    "id": "c76d9f99-dd53-46a0-8aa0-1dc8a931202d",
    "begin_date": "2025-02-04T15:22:35+03:00",
    "expiration_date": "2025-02-04T15:23:40+03:00",
    "com_key_id": "cc36e85d-2fdf-462c-b395-030907447afc",
    "message": {ENTITLEMENT MESSAGE}
}

The entitlement message should be used by the client to immediately request a DRM license. It doesn't need a long lifetime. If you set it to a large value, you grant more time to an adversary to experiment with DRM license acquisition.

Bind entitlement message to the client​

Without binding to a requesting client, an entitlement message could be used by another client or on another device. You can include three types of information within an entitlement message: IP address, device ID, user ID.

IP Address​

Here is an example of how to bind the entitlement message to an IP address (both IP v4 and v6 addresses are supported):

{
    ...
    "license_server": {
        "access_control": {
            "allowed_ip_addresses": [
                "80.237.132.164",
                "2a01:488:42:1000:50ed:84a4:43:1f85"
            ]
        }
    }
}
note

When using IP-binding, ensure that requests to both the entitlement service and the DRM license service originate from the same IP address. The use of proxies can interfere with this process. Be aware that client devices can inadvertently change their IP addresses (as an example: this can happen when a mobile device switches from WLAN to LTE and in many other cases). Implement a robust retry mechanism that can request a new authorization token if a license request is denied due to an IP address mismatch.

Device ID​

Here is an example of how to bind the entitlement message to a device ID, which is specific to the DRM technology used (Widevine, FairPlay, PlayReady):

{
    ...
    "license_server": {
        "access_control": {
            "playready":
            {
                "allowed_device_ids":
                [
                    "ed85e2bc-63d8-4a26-8ad0-18c382c12dd9",
                    "0d268a04-ca6e-4e9e-8412-e05344817cf5"
                ]
            },
        }
    }
}
note

Usually, you don't know the device ID of the client before the license request arrives at the DRM license service. Check further consideration in Device-specific restrictions.

User ID​

You can include a user ID in the entitlement message in the following way:

{
    ...
    "session": {
        "user_id": "fe92j4nxgu522fe37h"
    }
}

A User ID is any string that your application uses to uniquely identify users. For privacy reasons don't put plain user IDs in the entitlement messaage, but rather use encrypted or hashed values. The DRM license service does not reject license requests based on the presence or absence of this property. However, the user_id is stored in logs and can assist in troubleshooting by identifying misused tokens.

note

This is the same user_id property used in the Active Users billing model for user counting. However, you can pass a user ID and still use the license request-based billing model. It's your choice.

Understanding CDMs and device security levels​

A Content Decryption Module (CDM) is a secure component in a DRM client device that decrypts protected media while enforcing content usage policies, such as playback restrictions, output controls, and copy protection. CDMs ensure that only authorized users using compliant devices can access encrypted content, preventing unauthorized distribution and piracy. They work by securely handling decryption keys and applying DRM policies.

Security Levels in CDMs indicate the level of protection a device offers against attacks. Lower security levels typically rely on software-based decryption, which is more vulnerable to tampering, making it potentially easier for attackers to extract encryption keys. In contrast, higher security levels often require hardware-backed protection, such as Trusted Execution Environments (TEE) or Secure Media Paths (SMP), which provide stronger resistance against reverse engineering and key extraction. Content providers often mandate minimum security levels for accessing premium content, such as requiring hardware-backed CDMs for HD or UHD playback while allowing software-based CDMs for lower-value content like SD.

Apply proper DRM policies​

DRM policies (or content key usage policies) define how a client can use the received DRM licenses. In the examples above, there were no policies defined. This will lead to default values being applied to all policy settings.

You should define policies so that your scenario is best served and content optimally protected. Here is a sample entitlement message that shows how you can attach a policy to a key:

{
    "type": "entitlement_message",
    "version": 2,
    "content_keys_source": {
        "inline": [
            {
                "id": "11111111-0000-0000-0000-000000000000",
                "usage_policy": "Policy A"
            }
        ]
    },
    "content_key_usage_policies": [
        {
            "name": "Policy A",
            "fairplay": {
                "hdcp": "TYPE1_STRICT",
                "allow_airplay": false,
                "allow_av_adapter": false
            },
            "widevine": {
                "device_security_level": "HW_SECURE_ALL",
                "cgms-a": "never",
                "hdcp": "NO_DIGITAL_OUTPUT"
            },
            "playready": {
                "min_device_security_level": "3000",
                "analog_video_opl": 200,
                "compressed_digital_audio_opl": 300,
                "uncompressed_digital_audio_opl": 300,
                "compressed_digital_video_opl": 500,
                "uncompressed_digital_video_opl": 300,
                "digital_video_output_protections": [
                    {
                        "id": "2076ECD5-044F-4047-BFCF-7A75D0E4E269",
                        "config_data": "AAAAAQ=="
                    }
                ]
            }
        }
    ]
}

DRM policies are DRM technology-specific. Check documentation for supported options.

In the example above, there are policies defined, but the selected values are very permissive. You should carefully select the values depending on your business case, balancing between content protection and user experience.

Proper configuration of the DRM policies helps protecting against screen recording or other popular attack types.

Use unique content encryption keys for each video profile​

A video asset typically includes multiple video profiles (SD, HD, UHD) and audio. It’s considered a best practice to apply different DRM policies for different video profiles, i. e. setting stricter requirements for more valuable content, e. g. for HD / UHD resolutions or HDR versions.

To achieve this, you must encrypt each video profile (and audio) with a separate key. In the entitlement message, you will include multiple policies and refer for each key to the respective policy. You should restrict in the entitlement service which keys you provide to a given user depending on the properties of the user and their device (for example, only deliver HD to a user with premium subscription or only deliver UHD keys to devices which actually support UHD).

Now imagine, you allow software CDM for SD content and only hardware CDM for HD content and above. A software CDM is easier to break. An adversary, who executed a successful attack against the software CDM and got the encryption key, can now decrypt your SD content. But this key won't work for HD content. And breaking hardware CDM is way more complicated.

Same with audio. Imagine, you use the same key to encrypt audio and video. Audio and video decryption processing on the client side is separated. For an adversary, it's enough to break the audio decryption to get the key and decrypt the video with the same key. Hence the best practice is to use separate keys for audio and video, even if there is only one video key used for all quality levels.

Axinom DRM fully supports this approach.

Further DRM security best practices​

Implement Authorization Logic​

The Entitlement Service is a part of your solution which plays a fundamental role in the overall content security. Put time into its proper design and implementation.

First of all, do implement authorization logic. Don't grant a license to everyone who asks. It may sound obvious, but some systems fail already here.

Here are some initial criteria you should consider before granting access:

  • Does the requested asset exist?
  • Is the licensing period for the asset valid?
  • Is the requesting user authenticated? (You will not always have this, but mostly you will have some kind of authentication)
  • If the content is premium, does the user fulfil the criteria (such as, a valid subscription)?
  • Is user's region valid for the requested content?
  • What are device capabilities of the client? (For example, restrict provided keys to only SD content for a browser-based client)

Protect Communication Key​

Communication key is a shared secret used between your entitlement service and Axinom DRM license service to sign and verify the tokens. You have to protect the key properly. If it leaks, an adversary can create valid entitlement messages / tokens on your behalf.

You can always replace a communication key with a new one if the old key is compromised.

In particular, it means that you have to implement the entitlement logic on the server. You can't include it within your client application (e.g. with React), because this will mean sharing the communication key to each client's browser. This sounds like a basic hygiene advice, but we've seen violations of this already. It's just too tempting to prioritize simplicity over security. Such decision can turn out to be very pricy if you are dealing with premium content.

DRM Proxy Mode​

Using a Proxy Mode, you can put your entitlement service between the client and the DRM license service and gain more control over the license issuing process. You hide the entitlement messages from the client completely. You also have an additional decision point: once the DRM license service issued a license, you can still decide to reject the client request based on additional information from the DRM license service.

Log analysis​

DRM license service keeps records of each license request within a defined retention period. These logs provide a valuable information source for troubleshooting if you suspect a security incident.

Axinom provides to all DRM users certain level of log access via our service portal (https://portal.axinom.com). This includes also all logged errors. Users with a Standard support level and above can get direct log access via tools like Kibana.

When implementing your entitlement service, we highly recommend to maintain a log of requests as well. This log should be used for investigations in combination with the license service logs.

Conclusion​

Implementing DRM is a crucial step in protecting your content from piracy, but it is not a silver bullet. The effectiveness of DRM depends on how well it is implemented and integrated into your overall security strategy. By following the best practices outlined in this article, such as limiting authorization to specific keys, using unique encryption keys for each asset, binding entitlement messages to clients, and applying proper DRM policies, you can significantly enhance the security of your DRM solution.

Additionally, it is important to implement robust authorization logic, protect communication keys, and utilize DRM proxy mode to gain more control over the license issuing process. Regularly analyzing license request logs can also help you detect and respond to potential security incidents.

Remember, DRM is just one part of a comprehensive content protection strategy. Ensure that your entire solution is designed, implemented, and operated securely to effectively combat piracy and protect your valuable content.

By adhering to these best practices, you can maximize the benefits of your DRM solution and minimize the risks associated with content piracy.

To see all the above in action, start your free trial of Axinom DRM now and don't hesitate to turn to Axinom Support if you have any questions.