Background: What is digital rights management? What inspired this post?
Digital rights management (or DRM for short) refers to translating legal rights into technical measures. Examples include license keys to install software, software activation to verify authenticity of an installation with a remote server or region locking media storage such as DVDs. Often enough, such measures can be overreaching, making it more difficult or outright impossible to exercise rights permitted by applicable law. While DRM is certainly an interesting field of study from both a legal and an economic perspective, this text instead focuses on technical aspects: I believe that DRM can be æsthetic. But what makes it so? That is what I wish to explore in this post.
This post was inspired by a recent blog article by Mateusz Radomski, entitled Local license key verification - Theory. It explores various theoretical ways to implement DRM such that you have a method of validating whether a “license” is genuine in a purely local manner. The theoretical problem – is interesting in and of itself, but none of the presented solutions seem to truly feel æsthetic to me. This is not meant to discredit the aforementioned post or its author; rather, I am expressing a highly subjective belief of mine. I expect nothing and nobody to truly relate to this. That is alright. I am writing this post entirely for self-satisfaction, not for any practical real-world value.
For the purposes of this post, I will focus on the problem statement outlined in Mateusz Radomski's article: Local verification of genuineness of a license. A license shall be defined as a technical representation in textual or binary form, a manifestation of sorts, of a relationship that arises from a (legal) license grant in the form of a contractual agreement or – possibly absent thereof in the case of shrink-wrapped software sold through third-party resellers – from usage rights granted immediately by applicable copyright law itself pertaining to a specific software, perhaps at a specific version as well. An example of such are Microsoft Windows product keys. Information encoded in this representation could be a unique license identifier, the (natural or legal) person the (legal) license is granted to, a core or CPU limit or other run-time limits.
What purpose should DRM serve?
I believe that DRM is meant to ultimately serve both the user and the author or publisher of software. Legal compliance is difficult, as any open source developer who has ever spent a non-trivial amount of time can attest. The goal of DRM should thus be to keep honest people honest by deterring absolutely trivial piracy, but not to get genuinely in the way of exercising rights granted by applicable law or by contract, especially and particularly when the author or publisher ceases support for the software in question (or worse, is dissolved with no trace being left of where the intellectual property assets ended up).
Secondly, once DRM has been introduced into a system, it has been turned into a capture-the-flag (CTF) game. This is not an opinion, this is a fact. The flag is making the software work. It is intrinsically rewarding. In fact, it should be intrinsically rewarding. It trains a new generation of reverse engineers and infosec experts since most people appear to pick these skills up at a relatively young age. I believe that there are only two kinds of people in infosec: felons and failures, with rare exceptions confirming the rule on either end.
Finally, as DRM should proactively help with compliance. Limits should not be strictly enforced. Doing so is deeply unæsthetic. Warnings can and should be printed, readily made visible, such as to encourage and simplify returning to compliance. For example, if a 20-user license has been purchased and 25 users routinely access the system, the users should be shown that the system is in a non-compliant state. This must not be intrusive as to obstruct workflows, but should be noticeable enough for them to inquire with the administrator. Software encumbered with DRM must assume that the people in charge are not malicious as much as they are negligent and forgetful for the daily operative business often takes priority over compliance with minute details of any particular vendor's software. In doing so, an adequate compromise between the interests of the licensee and the interests of the author or publisher is reached, which is æsthetic.
Remote or local?
As cats are broadly divided into shorthairs and longhairs, so can DRM as defined for the purposes of this post be divided into two broad categories: It is either remote or local. In the remote scenario, the application checking license validity reaches out to a remote server. In doing so, the server acts as the ultimate arbiter, as a single source of truth. In the local scenario, however, the application has no source of truth other than itself.
Remote DRM is generally not æsthetic. As a CTF exercise and to prevent obstruction of lawful use after the disappearance of the vendor, there must be an escape hatch outside of modifying the code. However, a remote DRM often involves pinned certificates for Transport Layer Security (TLS) or similar means of securing the server connection. In this case, there is no escape hatch. That is deeply unæsthetic and reprehensible.
A compromise between remote and local DRM may be to have the option of running an on-premise server. In this case, however, it must still be reasonably possible to run an unauthorized on-premises server: After all, it is as much of a CTF exercise as it is a way to enable aid with compliance. But as the lifespan of a product nears its end, keeping it operational even without the vendor's cooperation becomes a critical necessity. A shining example of an on-premise server is Microsoft's Key Management Service (KMS) technology, which has been successfully reverse engineered and involves only symmetric secrets.
On difficulty
For similar reasons, local-only DRM that involves asymmetric cryptography is generally unæsthetic. The cryptography must be chosen to be of such strength that a small cluster of modern desktop computers or one fairly strong instance of a cloud-computing can recover the private key in less than 24 hours. This is necessary a CTF point of view (as the threat model of “bored teenager” generally does not have access to greater resources than that), but also aids greatly in ensuring that the software in question can be brought up quickly, assuming a reverse engineer is on staff or readily available. It is æsthetic if and only if it is keygennable with limited resources.
However, making it too easy is also unæsthetic. There should be a sense of reward for breaking your DRM scheme. If reasonable success can be found just by randomly generating keys and validating them, the element of a CTF exercise is too weak and for all but the most novice reverse engineers, there will be no sense of satisfaction as much as there will be a sense of disappointment how you did not even try. For example, when using a simple check digit, success may easily be found when choosing strings of allowed letters randomly. Yet that is not to say check digits should not be employed. State-of-the-art check digit algorithms can meaningfully guard against human entry errors in ways that validation software can differentiate and give a more useful error message because they mathematically guarantee that some kinds of errors are entirely excluded. Humans tend to make specific kinds of errors in transcription overwhelmingly often, albeit this is less of a concern in digital distribution as the license information will most often be copied directly from the source in the first place.
Generally, DRM takes a legal fight to the technical level. The larger the customer base, the more effort spent on obfuscation and technical protection can be justified from a business perspective. In no event shall it be made impossible to avoid the restrictions imposed by DRM without modifying the code. But it is entirely fair game to make a large customerbase (and thus also a large amount of Internet randos) spend an inordinate amount of effort to uncover the secrets of its operation. On the other hand, if the software is sold only to a handful of B2B customers, then an average sysop should be able to figure out within reasonable time how to generate license information; all else is unæsthetic. Therefore, æsthetics in the concrete case may change over time.
On visibility
As DRM impairs the functioning of the software as a feature, it is of the utmost importance that it is visible. Opaque strings of information are fine when they are genuinely opaque and contain only the minimum information like the product type. However, if they contain meaningful information, such as limits or the licensee, that information should be visible. For instance, assume license information is distributed digitially (such that human entry is not a real concern). It could perhaps look something like this (as a payload intended for use with JWT or PASETO):
{
"sub": "ACME, Inc.",
"product": "Super Duper Meme Network Manager",
"license_id": "629eec8b-5fbe-4a11-96c0-57dcf5c46166",
"max_users": 16,
"max_cores": 2,
"iat": "2023-04-20T13:37:00+00:00",
"iss": "Core License Issuer H1"
}In this example, the use of JWT or PASETO was suggested. Of course, these are meant to be used with symmetric secrets, not with asymmetric ones, else it would be unæsthetic for relying on asymmetric cryptography that cannot be bypassed without modifying the code as neither of these formats allow for sufficiently insecure asymmetric cryptography.
What matters is how visible the limits are. The user does not need to run the application to check. They see—immediately—what they are licensed to use. This is invaluable for inventorizing license information.
Summary
To summarize, DRM is æsthetic when:
- it aids both the user and the author/publisher in matters of compliance;
- it works in such a way that functionality can be restored even without cooperation of the vendor if need be; and
- it is a feasible exercise for reverse engineering, the difficulty level of which is a function of the customerbase.