DRM conformance audit for compliance and robustness rules
Our solution engineers are experts in robustness rules and conformance criteria.
We help assess conformance of devices to Robustness & Compliance Rules certification for various DRM licenses including Marlin, OMA, PlayReady, WMDRM-PD, WMDRM-ND and more. Our DRM conformance audit service is specifically designed to target DRM implementations and provide documentation that the robustness rules are being followed. Ultimately, our DRM Conformance Audit reports include a robustness rules conformance matrix which highlights the various threats to the major assets found in the Robustness Rules. Where appropriate, we will also highlight and detail specific mitigations suggested and/or mandated by the Robustness Rules and current industry best practices.
- Jennifer Skinner-Gray, Worldwide Manager, Software and Channel Marketing, Texas Instruments
Our DRM conformance audit report focuses on four key areas:
Assets
Assets are targets of attack which could include protected content or any other data (such as keys or code) which an attacker could use to their advantage (i.e. by discovery, replacement, reverse-engineering, or modification). Specific assets and the degree to which they must be protected are identified in specific DRM Robustness Rules for each licensable DRM standard.
Attack trees
Attack trees are a well known mechanism for analyzing how an attacker might attack a particular asset, such as stealing a hidden key from a particular device implementation. For example, if a key were in the clear in memory for prolonged periods of time, and the attacker had a tool which could read device memory at run-time, it would be relatively easy to discover that key. A pure attack tree which analyzes every path by which every major asset might be attacked tends to be very large and repetitious, because some steps, such as "read memory at run-time", appear over and over and are essentially the same regardless of the target. Therefore, to make the analysis easier to understand, we apply the further notion of a "threat surface" which summarizes the various ways that the system could be penetrated.
Threat surfaces
It is rarely the case that an attacker breaches the system using a method entirely specific to the particular asset being attacked, such as a private key. Rather, the attacker breaches a boundary point, and starts poking around in the hope of discovering something valuable inside. The attacker usually breaches through some part of the Threat Surface - so the larger the threat surface, the more places there are to breach. For example, having access to a debugger, or the ability to create and run arbitrary applications on the device, or the ability to easily statically analyze the device's binary code, all significantly increase the attack surface and give an attacker many more places to “break in”.
Tool classes
In most published Robustness Rules, Tool Classes are a mechanism that supports a rational classification of the “degree of difficulty” of any given attack. Other things being equal, an attack which can be accomplished with, for example, a file editor, is much more threatening than one which requires a logic analyzer. However, these definitions are primarily legal in nature, somewhat dated, and do not reflect differences between platforms. For example, a tool which is placed in the “Professional” category in a particular Robustness Rule document, such as a dissasembler, might in fact be “Widely Available”, in common-sense terms, on a platform such as a PC. For this reason, our judgments rely on knowledge of the domain in addition to the Rules, including these tool classifications.
Contact us today to learn how our DRM Conformance Audit Services can help reduce your risk by ensuring your DRM implementation meets contractual obligations.
