The Many Facades of DRM
Author: Rod Schultz [email protected]
1. INTRODUCTION
In February 2007, Apple's CEO Steve Jobs wrote an open letter to the world denouncing DRM and its use in the music industry. In this letter Jobs stated, "DRMs haven’t worked, and may never work, to halt music piracy". The world took notice of this statement, and blogs all over the Internet were devoted to interpreting his message and meaning. The debate over DRM and its value began even before that, and has raged for over a decade now. Over time more and more people have developed a mental picture of what DRM is and what it does.
But what do people really know about DRM?
Most people only understand that a DRM prevents them from sharing or copying music and movies. Very few understand the intricate nature of this technology, how it enables business models, how it is built, and how it can be attacked. Even fewer understand the sheer mathematical complexity needed to create a DRM, and the cost of maintaining it.
In this article I will discuss the many facades of DRM, including its multiple layers, their construction, and the functionality they provide. I will expand on DRM techniques and how they can fail based on my experiences at Apple (iTunes and iPod protection) and Adobe (Flash Player RTMPe protection).
2. BUSINESS MODEL
Perhaps the most interesting thing about the Steve Jobs DRM letter to the world was the timing. When it was written, I was a member of the Apple FairPlay team (the engineering group at Apple that creates its DRM) and we were already working on a software update to iTunes that would allow the purchase and playback of DRM free music. Jobs was astute enough to realize the negative reaction the public had to DRM, and he successfully painted the picture that Apple hated DRM, and that Apple wanted music to be freely shared. On April 2nd, 2007 EMI Music announced an agreement with Apple to sell DRM free music on the iTunes store, with all other major labels to follow in January of 2009. The music industry finally gave in to Steve Jobs, giving him—and the consumer—a victory in the music war on DRM.
Maybe there was another motive.
Maybe Steve Jobs was really trying to spin a pending decision by the music industry into a public perception victory for Apple. The truth was that with the power of its DRM Apple was locking the majority THE MANY FACADES OF DRM 1 of music downloads to its devices, the most import of which was the iPod. The music industry didn't go DRM free because they hated DRM; they went DRM free because they were fearful of the leverage Apple was gaining with their iTunes + FairPlay + iPod combination. Apple’s DRM created this lock, and it became so successful that the music industry went with the lesser of two evils (songs locked to Apple’s iPod monopoly vs. the distribution of DRM-free music) and chose to distribute DRM-free music.
These actions, taken only a few years after the disastrous impact of Napster, illustrate that DRM is an instrumental technology in creating and shaping business models for digital content distribution. Without DRM the iTunes store would never have been born. No music label would have licensed content to Apple, and the majority of the general public would not have purchased iTunes content that didn't come from a major label. It was only after the service became mature and too powerful that the music labels changed the rules of the game and went DRM-free.
The same content protection needs apply for movies as well. DRM provides the digital security that studios (Disney, Fox, Warner Brothers) require a digital content distributer (Apple, Amazon, Netflix) to provide. For video, DRM is even more important, and the studios can still set the rules without yielding to a public demand for DRM-free movies. Until the world evolves to a point where this digital security impacts the revenue or future growth of the studio, DRM will be required. When the cost of creating a movie like Avatar ranges between $300 million and $500 million, the studios naturally want their money back. They want protections in place that will give them confidence to release digital copies to the world.
Video is consumed very differently than music. A good song is something you listen to multiple times, over months, years, and sometimes decades. It is something you share with others. The best songs have an extremely long lifetime in the consumer space. Movies are more expensive to produce and are usually viewed once. So studios have to be strategic about how they release movies to consumers.
Studios break the licensing and release of their content into distribution windows. The majority of movie revenue is generated at the box-office release window, the VOD (video on demand) window, and the home video window (DVD and Blu-ray sales). These windows were created to segment the market and generate as much revenue as possible for a product that can easily cost hundreds of millions of dollars to produce, and is usually viewed only once.
Each of these widows (there are at least six, and potentially more if you count airline, hotel, and foreign distribution) provides an opportunity for the studio to distribute to different segments. Each window also provides a unique opportunity for a consumer to steal the content, and forces the content distributer to deploy a DRM.
The paradigm that exists is one where the content creator wishes to get the maximum revenue for its content for each distribution window. Each window has different DRM requirements, with current and future revenue impacting the mandated strength of the protection for each window. This DRM approval gives the content providers the ability to influence the DRM features and its corresponding design.
2 THE MANY FACADES OF DRM
3. CONTROL ARCHITECTURE
When architecting any security system it is critical to identify points of failure and design around them whenever possible. Security systems are barriers, and when barriers are created they are attacked. A DRM is no different. The very nature of a DRM system--preventing the user from accessing something that is completely under their control--makes it extremely vulnerable to attack. Due to this vulnerability one feature studios look for is something called renewability.
Renewability is a channel that the DRM provider can utilize to update key software modules in the field. This allows the security of the DRM to be renewed and restored if there is a breach. It is analogous to changing the engine or tire on a car if it breaks. The entire car doesn't need to be replaced; only the area that has failed. The difference is that a car must be taken to a mechanic for repair; a DRM is updated in place.
It is this concept of a secure system that is critical to the durability of a DRM. It is extremely difficult to predict how detrimental a flaw in the design will be to the integrity of what the DRM is protecting, so it must be designed to withstand attacks, adapt to attacks, and avoid catastrophic failure when it is attacked. On the surface it seems obvious that the DRM would be designed this way, but the execution of this concept is not as simple as it sounds.
Modular software systems are designed to be broken into independent pieces. Each piece has a clear boundary and well-defined interface for 'hooking' into other pieces. Progress in most technologies accelerates once systems have achieved this state. But clear boundaries and well-defined interfaces also make a technology easier to attack, break, and reverse engineer. Well-designed DRMs have very fuzzy boundaries and are designed to have very non-standard interfaces.
THE MANY FACADES OF DRM 3
!"##$%"&'()"*$+,-./0"$+1&2"34 !"##$%"&'()"*$%67$+1&2"34 5,,0#1$%"&'()"*$%67$+1&2"3$ 5,,0#1$%"&'()"*$+,-./0"$+1&2"3$
Module 1 Module 2 Module 3 Module 1 Module 3
Module 4 Module 5 Module 6 Module 4 Module 6 Module 2
Module 5
8'(90"$:$;$+1&2"3$%"&'()
These non-standard interfaces make it harder to reverse engineer, but also much more difficult to upgrade in the field.
To minimize the cost of failures that cannot be fixed with a software update (renewability), DRMs are designed to be revoked. Revocation can occur at different levels of device and content granularity. This means that entire device classes can effectively be prevented from playing protected content, or a specific users device can be turned off to prevent it from playing back content (it should be noted that I have never seen user level revocation done in the real world). It is also possible to revoke specific movie titles if the content provider feels that there has been a breach on the content.
To further defend itself against the cost of breach, DRMs are also designed to have binary diversity. This is the equivalent of a biological immune system. In this case the immune system is not protecting an individual but rather an entire DRM ecosystem. Just as it is impossible to predict what viruses will infect the human population, it is impossible to predict what attacks will be levied against a DRM. The diversity of each person’s immune system helps prevent global pandemics, and the binary diversity of a DRM helps prevent global breaches.
The attack on the DRM can be modeled as a virus. Here the DRM breach is the virus, and the vector is the downloading and replaying of the attack. Building diversity into a DRM is designed to isolate an attack to as few devices as possible by distributing DRM systems that have the exact same functionality but different binary plumbing. With certain attacks this can greatly minimizes the revenue impact of the attack as well as the pressure the DRM provider gets from a studio to fix the attack.
4 THE MANY FACADES OF DRM
4. CRYPTOGRAPHIC KEY ARCHITECTURE
The most basic function of a video DRM is to prevent a user from gaining access to a key that is used to decrypt a video. Just as a castle is designed with multiple barriers of defense, DRMs have a similar design. A castles defense was generally in the form of multiple walls (outer wall, inner wall, castle keep). Similarly, DRMs are defended using keys that protect other keys.
)-.&'%(
)%*+,%&'%(
!"#$%#$&'%(
!"#$%&'(')'*&+',%-.&/0-1
Each DRM system is different, but the most basic key types are:
• DRM master key - a global, or semi-global key that is allocated at DRM birth of the device
• Device key - a device specific key that is allocated when the DRM begins playing content
• Content key - a key that is used to encrypt/decrypt a movie
The keys are conceptually stored as boxes inside of boxes (or keys that are protected by other keys). The importance of the key is inversely proportional to the time it spends in memory; with the theory being the less it is used the less vulnerable it is. The DRM is designed to protect all keys, with the intent of keeping the DRM key as safe as possible. The Russian doll nesting of keys is intended to minimize the cost of a key attack, and provides the ability to turn off the DRM at different layers (an entire device class, a specific device) or upgrade the DRM at different modules.
5. THREAT ARCHITECTURE
The threats that DRMs address are very different from the threats that classic cryptography was designed to handle. With classic cryptography (symmetric and asymmetric) the end points of the system are trusted, the encryption and decryption of data is being done in a secure environment. The trust is established by performing these cryptographic operations in a secure location. These islands of trust are
THE MANY FACADES OF DRM 5 the foundation for where keys are stored and where they are used. The challenge with this model has always been secure and guaranteed delivery of an encryption key (how do you generate a key and delivery it safely to both Trusted End Points).
.*%"#$%&'(/,"0'(1( !"#$%&'()*'( !"#$%&'()*'( .*%"#$%&'(2&%3,"4 +,-*% +,-*%
@&;"&%(A&< @&;"&%(A&< 5-6#"&(7(8(90:$$-;:0(9"<=%,6":=><(!>"&:%(?,'&0
DRM has the same threats as classic cryptography, but new ones as well. These new threats arise because, today, nothing in the system can be trusted. With this model, the user of the system is the attacker, and has full access to the machine, they can install whatever they want, can observe whatever they want. This threat model (Brecht Weyser refers to this as the White-box attack context in his corresponding article) changes all the rules. What has been done for hundreds of years with classic encryption and decryption techniques can no longer be done.
The trick with a DRM is creating an island of trust inside of this system. How this is done, and how securely it is done defines the DRM industry. Hundreds of millions of U.S. dollars a year are spent around the world by public and private institutions in an attempt to protect digital assets with DRM. A good encryption algorithm or security protocol can last for decades, sometimes even longer. A good DRM can last a few years, if you are lucky. Let’s take a closer look at the conditions a DRM must execute in, how some of the protection is done, and how it can fail.
6. DATA EXECUTION ARCHITECTURE
The easiest way to think of an encryption algorithm is to imagine a black box. This box takes two things, an encryption key and the message you want to encrypt (plain text). The output of the encryption algorithm is the altered/encrypted message (ciphertext). In the case of DRM, the process is usually running in reverse, the data comes in as encrypted ciphertext (an encrypted movie) and is returned as decrypted plain text (the decrypted movie that is then decoded and displayed on the screen).
+
(
,
-.,/*01.#/2$3& !"#$%&'()* -$/2(.*()* 4"10.$*25 6(77#1(&*0&(%3.,/* 8%3.,/*(9&6(77#1(
!"#$%&'(')'*+,-.'/"0#%01',2'03'43-%567,3'8+#,%"9:1
6 THE MANY FACADES OF DRM
When written as software the encryption/decryption program has three primary components:
• Code that defines the algorithm
• Variables and constants of the algorithm
• Encryption/decryption key (a special type of variable)
It is no different from any other software application, and at any time it is in one of three states: stored on disk, loaded into memory, or executing (running on the CPU).
!"#$%&' ("#)*+,-. /0*123"4
!"#$%&'"($)*+, -"&'"(.
5,6* 7894,-%:;+<
=>-%>?9*&@ 5,"&:>":&
A*.
!"#$%&'(')*+,-.%&'*/./&0
Each state presents an opportunity for attacking the key and each state has unique conditions that favor different protection techniques. Some of these techniques are more robust than others. They all come with tradeoff. They are all however designed with one objective, to keep the key out of the hands of the attacker.
7. PROTECTION TECHNIQUES
A DRM can be attacked in many ways, but all attacks can be classified as either static or dynamic. Static attacks focus on the software when it is on disk or in memory. Dynamic attacks are much more difficult and focus on the program while it is executing. The protection techniques are presented in the order that I have observed them to be effective in protecting an attack on real world DRMs.
7.1 DISK ENCRYPTION
The most secure protection a program can have is obtained by encrypting it on disk. The challenge being that the program is completely unusable in this state and must be decrypted and loaded into memory by a secure loader. Disk encryption prevents a direct reverse engineering of the program while it is on disk and simply forces the attacker to grab the program from memory (where it must be decrypted before execution) and begin analysis from there.
THE MANY FACADES OF DRM 7
7.2 OBFUSCATION AND CODE FLATTENING
Obfuscation is the process of taking source or machine code and making in difficult for a human to understand. Code obfuscation is used to take source code that looks like this:
X[(lswlen>>2)&15] ^= (uint32_t)1 << (8*(lswlen&3) + 7);
if ((lswlen & 63) > 55) { compress(MDbuf, X, keyIndex); memset(X, 0, 16*sizeof(uint32_t)); }
And turn it into code that looks like this:
r_1hwufd508eype190t1g6l11714decwg1697qiq_lwr_PNm = (unsigned long)(((unsigned)1257253745u * (unsigned)r_0m3sjxz1oz1gp68b01surr6g0aimd610s219xj_lwr_PNs) + (unsigned)447382896u); r_0yssssg1e68m4t90u02kwdxj1895j841da0zbt_lwr_PNn = r_0zwwez910hyj5v8b31plgrk209izysy1m3yfop_lwr_PNt; r_04aq7e501zvy8090r1wqizc21nojuvt1bl1eei_lwr_PNo = (unsigned long)(((unsigned)2593010305u * (unsigned)r_1k76dup1wbup938b20jvdlkm1wsbt2z03slss1_lwr_PNu) + (unsigned)3766929696u); r_1ir0lu31gdyfpg90k0xv7zry1w0t1vj0a5djrw_lwr_PNp = (unsigned long)(((unsigned)4120121601u * (unsigned)r_0pj8wcy15d228m8ax0v0zrni0fnhls801666ln_lwr_PNv) + (unsigned)527965408u); r_05i401o06dq21o90h12wbi1t07r476x1kux58h_lwr_PNq = (unsigned long)(((unsigned)1894216001u * (unsigned)r_1fibrwk1ilh13f8aw1b4klu31lta4520r0pzti_lwr_PNw) + (unsigned)1814032320u); s_av_71849_av_71905_av_96209_lwr_PRO)) + ((unsigned)3606861121u * r_P20)); ((MDbuf)[(int)4]) = (unsigned long)((((r_P21 + ((unsigned)1197587841u * (int)984361464);
The inputs and outputs to the software are the same, but the size and complexity of the code is orders of magnitude harder to follow and understand by the attacker. Variable names are scrambled; data that was originally stored in a single variable will be split into multiple variables and recombined at execution time. Obfuscation can be very effective at hiding algorithms and provides adequate protection for the code, but zero protection for any encryption key used by the code.
Often coupled with obfuscation is a technique called code flattening. Any software program can be represented as a graph of all decision points and paths a program may traverse as it executes. Code flattening introduces extra paths, and smashes the graph to a non-descript flow that makes it inherently difficult to analyze with a disassembler.
The code is transformed from a graph that looks like this:
8 THE MANY FACADES OF DRM
6789:
!"#$%&'
,-./&0'1&2 3"43& 3"43 ,-./&55&'12
!"#$%&( !"#$%&+ !"#$%&*
!"#$%&)
;9:89: !"#$%&'(')*+%,-.'/+01%+.'!.+2'3%-45'6&7+%&'897$:;-<+0'-0='!.->&0"0#
To something that looks like this:
859:$
!"#$%&
'()%*+, '()%*+- '()%*+. '()%*+/ '()%*+0 '()%*+1 '()%*+2 '()%*+3
4)56#7)5
;:$9:$ !"#$%&'(')*+,-%+.'!.+/'0%123'45&%'678$9:1;+,'1,<'!.1=&,",#'>1?&'@&&,'4<<&<
Both flow graphs transform the input in exactly the same way; they are functionally equivalent. After the THE MANY FACADES OF DRM 9 flattening and obfuscation have been added, the attacker must deal with the artificial complexity that is now created when analyzing the software. Again, the protection does nothing to hide a key; only the logic of the program is altered. This technique is effective at binding multiple different code blocks into a single and very difficult to understand monolithic block. The goal is to force the attacker to spend time ‘boiling’ out the original program. All obfuscation and code flattening can be defeated, but it comes with a huge time cost.
7.3 DATA TRANSFORMATIONS
As I mentioned previously, islands of trust must be created for a DRM to safely execute. These islands are built using data transformations. These transformations are the foundation and glue for most DRMs. In concept they are very simple: map a value X into a value Y, and then make sure you can map it back. The easiest way to picture this is as a boundary. The untrusted world is on the outside of the boundary; the trusted world is on the inside.
The door to this world is through a mathematical transformation where the data is mapped from one value to another. Transformations are applied to the variables and keys of the software program. The most basic usage of a transform could be simply applied to a key; the most robust usage would be applying the transform to all variables. The only rule is that data must interact with data that has the same transform. This is analogous to only being able to speak to people who speak your own language. If you want to communicate across the boundary (between data on different sides), you must migrate the data to one side or the other.
In the following code example, the secret key has a transform on it (represented by the purple box), but the encryptedMovie parameter that is passed in does not. In this example, the secret key is protected on disk and in memory, but as soon as it must execute and decrypt encryptedMovie then one of two things must happen: either the transform on the key is removed or the transform must be applied to the encryptedMovie. This makes the movie double transformed--once with the DRM key that encrypted it, and once with the mathematical transform that is used to protect the data.
void DRM_Deccrypt(uint8_t *encryptedMovie, uint32_t dataSize, uint8_t *decryptedMovie) {
uint8_t SecretKey[16] = { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F };
DecryptWithKey(SecretKey, encryptedMovie, dataSize, decryptedMovie);
} !"#$%&'(')'*+$%,&'-+.&'/"01'2'3%2456+%7'899:"&.'0+'2';&<
In reality neither of these choices is good because an attacker will watch this (using dynamic analysis of the program) and eventually reverse engineer the transform (therefore destroying the island of trust that has been created) and finally get to the secret key. The solution to this is to apply a transform to all variables inside of the function and all data going in and out of the function.
This is the crux of the data transform problem. To operate on data the transform must be moved into the secure boundary. Moving data into the secure boundary at runtime provides an opportunity to watch the transform as it is applied or removed. With enough data sent through the system, an attacker will eventually determine the transform and compromise its protection.
1 THE MANY FACADES OF DRM 0
Data transforms can be incredibly secure, but only if they are used properly, and only if the dynamics of the system lend themselves to this technique. The strength of the transform is directly related to the transform space (transforming over a four byte word is much stronger than transforming over a single byte) and correlates to how difficult it is to break.
7.4 WHITE-BOX CRYPTOGRAPHY
White-box cryptography is the breakthrough technology that enables modern day software DRM systems. (first published by Stanley Chow, Phil Eisen, Harold Johnson, and Paul van Oorschot in late 2002). Without this technique digital media distribution from iTunes, Amazon, and others using software DRM protection would simply not exist.
The first few versions of iTunes were released without using white-box cryptography and they were famous for being broken by Jon Lech Johansen (DVD John) in a matter of days. Once Apple began using white-box cryptography the level of difficulty in breaking FairPlay was raised, breaches to the DRM were stopped, and they were able to secure contracts with the Hollywood studios. Apple began selling movies on iTunes in 2005.
White-box cryptography allows a movie to be decrypted without directly revealing any portion of the content key. It works by combining the power of data transformations (as discussed above) with the clever usage of what are called lookup tables (please see Brecht Wyseur’s article on White-box Cryptography for a much more detailed overview). A lookup table is a concept most people have known since grade school, specifically in the form of a multiplication table. When doing multiplication, the simple equation of A x B can be represented in a table form:
0 1 2 3 4
0 0 0 0 0 0
1 0 1 2 3 4
2 0 2 4 6 8
3 0 3 6 9 12
4 0 4 8 12 16
!"#$%&'(')'*$+,-+"./,01'2&31&4'/5'/'6007$-'8/9+&
While this seems very mundane and basic, it is extremely powerful. An entire mathematical function, A x B, and the corresponding rules associated with multiplication, have been laid out in table form. Rather than see the assembly for the multiplication of two variables in the binary, an attacker sees a massive lookup table, and inputs will be mapped to corresponding outputs (2 x 3 = 6);
The example shown is very simple to understand and anyone reverse engineering the DRM will determine that this is a multiplication table. But let’s imagine that it is instead a much more complex equation. Now imagine that a data transform has been applied to all the elements of the table. This opens up the possibility of creating a software program that does the bulk of its crypto functionality as lookup tables,
THE MANY FACADES OF DRM 1 1 and those tables now have transforms on them that prevent an attacker from knowing what function the table represents.
Again, the critical detail is making sure that the entire white-box algorithm is running inside of a transformed boundary, and that all data entering the boundary must have a transform applied. This technique allows you to break an encryption algorithm into pieces, turn the functionality into tables, and apply transforms to those tables.
White-box techniques can be applied to most encryption algorithms (AES, RSA, ECC), below is an example of a possible implementation of white-box AES.
./01' ./01'
!"# $%&'()*+,-!"# !, !- !/ !0 !"#$%
!&'(
!&'( )., ).- )./ ).0
)'% *, *- */ *0
*++ !"#-21'01'
1'23456,76"6*6.$89:4';$<6$=6>$48:?6*@!6:<+6A&'B5"#$%6*@!C
!"#$% !"#-21'01' !"#$#!%&#'(()*+#,-./01#,2-,#-30#4*567(5-//8#09*:;-/05,#,(#<=!#!$.(>#3(*5? !2:@&#A2:1#(+03-7(5#:1#5(,#?(50#-1#-#,-./0#/(()*+#?*0#,(#:,1#5-,*30# BC"#$#BC%&#'(()*+#,-./01#,2-,#-30#4*567(5-//8#09*:;-/05,#,(#B:>C(/#3(*5? <"#$#<%&#'(()*+#,-./01#,2-,#-30#4*567(5-//8#09*:;-/05,#,(#
The lookup tables above (represented as different boxes) have different colors that represent different transform spaces that the data inside must be mapped to. When transitioning from one color to another (from S1 to S2 for instance), the data is transitioned to the new transform. The strongest white-boxes libraries have the requirement that the input data already has a transform on it. This is a very difficult constraint, but with data that is going to be decrypted we have an automatic transform that comes in the form of the encryption itself.
Sending known inputs across a transform boundary is the biggest challenge. This is a known need with white-box, and the white-box will apply transforms to the inputs and immediately begin migrating the data to other transforms. This creates confusion for the attacker and requires them to trace data through 1 THE MANY FACADES OF DRM 2 a very complex mathematical computation.
8. PROTECTION TECHNIQUE FAILURES
Having worked on several different content protection solutions, I’ve had the pleasure of watching my work get broken many times. Failure is an opportunity to learn, and each breach has lead to a greater understanding of a technique’s strengths and the appropriate context to deploy them. The attacks I will describe are a result of weaknesses in the protection technique or the application of the technique.
8.1 OBFUSCATION AND CONTROL FLOW FLATTENING FAILURE
In 2007 Apple decided to prevent iPods from syncing with operating systems that didn’t support iTunes, specifically Linux. The entire iPod database had already been reverse engineered, and until this time Apple had no problem with this. The task of ‘fixing’ this fell to me. To prevent the syncing from happening on these non-supported operating systems I decided to create an authentication protocol between the two sides, iTunes and the iPod.
Due to a feature that allows an iPod to sync to multiple computers, I needed to base this authentication on non-volatile data on the iPod, and I chose the iPod serial number. The authentication was a basic challenge/response: the iPod would send its serial number to iTunes, iTunes would transform the data using a secret algorithm that both sides knew and send the response back to the iPod. If the serial number is transformed correctly then iTunes authenticates itself to the iPod, and the iPod allows iTunes to write a database to its disk.
The algorithm calculated the LCM (least common multiple) between neighboring digits of the serial number, two different 256 byte lookup tables, and a constant variable (essentially a static key) that was appended to a result, and then hashed using SHA1 (a common hashing algorithm). A block diagram of the algorithm looked like this:
THE MANY FACADES OF DRM 1 3
,2%3$4'-,(;$5=8.'-
6-(71&%-8$ !"#$%&$'()*$ 9,0*$09%$ +(,-$%&$./0'1$ 3,:'-'70$ %&$,2%3$45 ;%%<=+$ 0(.;'1
6-(71&%-8'3$4'-,(;$5=8.'-
4>?@A40(B)$C'/$D$6-(71&%-8'3$4'-,(;$5=8.'-E$F$?=0*'7B)(B%7$"%3'$.'09''7$,2%3$(73$,6=7'1$
G,H=-'$@@$I$,2%3$?=0*'7B)(B%7$?;H%-,0*8
This entire algorithm was obfuscated and had control flow flattening. After being released to the world in an iTunes and corresponding iPod update it was fully reverse engineered in 72 hours (it actually may have been a bit faster than that) and posted on a server so that everyone could break the authentication algorithm. The attack on this algorithm could have been done completely with static analysis.
8.2 DATA TRANSFORMATION FAILURE
In 2009 I was asked to create a new version of authentication for Adobe’s RTMPe protocol. Before this, RTMPe used no anti-reverse engineering (DRM) techniques. The protocol had two purposes: transport encryption of a video across the network and authentication between an Adobe Flash Media Server and an Adobe Flash Player.
For this project the updated RTMPe protocol needed to scale to many different platforms, I decided to take an encryption algorithm and build 16 keys into it. The encryption algorithm I chose was XTEA. I randomly generated a set of 16 byte keys, applied a cryptographic transform to the keys, obfuscated and flattened the code.
The intent of this upgrade was to break a breach of the RTMPe protocol that had been published as source code by the rtmpdump online source project. This group of developers had broken the protocol so they could make copies of video on demand (VOD) content (mostly Amazon and Hulu VOD). This was the first time this set of developers had ever seen these types of protection techniques, and they proved to be rather effective. The protection mechanism lasted for almost 18 months before the encryption algorithm source code and all they keys were published in an update to rtmpdump.
The developers of the rtmpdump project used dynamic analysis of Flash Player while it was exercising the RTMPe protocol. Because the transform was only applied to the keys in the code (and not all of the XTEA source code), the transform was removed at execution time, and the real keys were revealed.
1 THE MANY FACADES OF DRM 4
8.3 WHITE-BOX FAILURE
In early 2008 an extremely sophisticated attack of Apple’s FairPlay was posted for the entire world to see. For the first time in over two years the DRM that was used to secure iTunes music and movies had been compromised. A group calling itself Brahms performed the attack, and they called their software program Requiem.
The program came in the form of source code, and examining it shows that Brahms attacked the Achilles Heel of white-box cryptography, the data transforms. Like most DRMs, Apple’s FairPlay was using keys to encrypt other keys. Requiem took the transform from a white-box content key and used it to discover the transform on a device key. This data transform was applied to all the keys. Once the content key was decrypted by the device key, Requiem applied the inverse of the data transform, extracted the key, and proceeded decrypting the content using OpenSSL (a free software crypto library).
The attack was much more involved than simply reversing a data transform, but that was the doorway into the system. Once Brahms understood how to ‘talk’ to the white-boxes keys FairPlay was using, they were able to control the system and turn it around. Then they could decrypt music and movies and write them to disk. The DRM keys were the weapons, and Brahms found out how to control them. The attack did not reveal the keys themselves.
This was the beginning of a secret war between the FairPlay team and Brahms, costing millions of dollars, thus raising the question of why someone would persist an attack for so long, and who was funding it. It has been almost a year since Requiem has released an updated attack in this battle.
9. CONCLUSION
In December of 2011, the MPAA (Motion Picture Association of America) released a memo expressing their support for the Stop Online Piracy Act (SOPA). In this memo the MPAA makes the following claim: “According to the Institute for Policy Innovation, more than $58 billion is lost to the U.S. economy annually due to content theft, including more than 373,000 lost American jobs, $16 billion in lost employees earnings, plus $3 billion in badly needed federal, state and local governments’ tax revenue.” These numbers might seem inflated, but it shows you the interest content creators and providers have in shutting down piracy, and this directly impacts the demand for DRM.
The state of online video distribution is actually pretty strong, but it could definitely be better. The movie industry is searching for a way to provide a better business model that will allow consumers to purchase or rent content and play it back on different vendor DRMs. The solution that is pushed by the industry, Ultraviolet, is gaining momentum because Apple is very dominant in online video distribution. This time, instead of removing DRM from the content, the industry is pushing for a standard that will allow DRMs to interoperate.
The techniques discussed in this article are the foundation of software DRM, with white-box cryptography easily being the most effective. Their effectiveness is limited if the attacker can watch the execution of the DRM program. has spurred momentum in creating anti-debugging and disassembler detection techniques. Adding hardware protection to the equation has proven to be extremely effective, but the added cost this adds to a device makes it impractical.
Also, it is important to remember that DRM is not just a solution for content. The governments of many countries are investigating these techniques to prevent their technology from being stolen and reverse THE MANY FACADES OF DRM 1 5 engineered when it falls in the hands of their enemies. As the battlefield of combat transitions from humans to machines the problem space becomes larger, and DRM will be used as digital lock.
DRM is the weapon of choice in the digital fight against piracy. It protects intellectual property and enables digital distribution business models. DRM is hated by the masses and understood by few. But until people are willing to put their money in banks with no vaults, it is very necessary.
ACKNOWLEDGMENTS
The original version of this article has been written in English, and can be retrieved at www.whiteboxcrypto.com. I would like to thank Fred Raynal for translating to French for me.
I would like to thank Jennifer Rowe for her expert editing of this article, and Filip Paun for his expert advice on white-box cryptography.
1 THE MANY FACADES OF DRM 6