2. DRM: From Software
Secrets to Hardware
Protection
Rod Schultz
Adobe Primetime DRM

3. Adobe Primetime

4. Interesting
DRM
lessons

5. What is DRM?

6. Digital Rights Management
is not security

7. Security and DRM are
made of the same blocks
• Same Encryption algorithms
• Same Protocols
• Same Key exchange mechanisms
• Environments each run in (security vs
DRM) are very different
• What they are designed to protect are
different

8. Public perception of DRM:

9. And this:

10. Technology created to control
the usage of a device or
content after its sale
What is it really?

11. Companies don’t want their
products to be thought of like this

12. A DRM is intended to
slow down the
commoditization of the
object or thing it is
protecting

13. Why use a DRM?

14. Downloaded music has
now gone DRM free

15. Why have we not seen
this in the movie industry?
• Different types of content have different
business models
• What movie won the best picture in 2010?
• When’s the last time you watched it?

17. • Movies are usually watched once
• Music is listened to over and over
• Music has transitioned from scarcity of product
(CDs and tracks) to scarcity of experience
(concerts)
• Music artists have switched to a new revenue
stream
• The movie industry still relies on scarcity of
product and delivers that to you via different
mechanisms
Consumption of music and movies
is different

18. The impact of changing
availability

19. The changing face of music revenue

20. 2011 US vs European Bandwidth Usage
(Give users choice, reduce piracy)

21. DRM Architecture

22. Lessons on single points
of failure from WW II

23. • The French thought an attack through the
forest in the north was impossible
• That defense was neutralized by German
tanks

24. Key takeaways for DRM
• Motivated attackers are smarter than you
• They will find your weakest defense
• Single points of failure are really bad

25. DRMs are designed like biological
systems
RenewabilityDiversityRevocation

26. Lessons from the Masai:
Design for confusion

27. Key Takeaway for DRM:
Good software design is not
necessarily good DRM design
Module 1 Module 2 Module 3
Module 4 Module 5 Module 6
Module 1
Module 2
Module 3
Module 4
Module 5
Module 6

28. • The fundamental building block of
protection in a DRM is encryption/
decryption
• Mathematically protect the assets you want
to control
To build a DRM
you need cryptography

29. Protect your assets with
a castle, not a single wall

30. DRM$Key
The castle concept for a DRM:
Keys protecting keys protecting keys
Device&Key
Content&Key

31. To understand the
DRM threat, let’s first
look at the traditional
crypto security threat

32. Both built with the same blocks

33. Traditional Cryptography:
• Design of algorithms and protocols to
protect a communication channel (secret
messages, credit cards...)
• End points are assumed to be trusted and
safe
• Attacker has access to what it can capture
on the wire
• Delivery of key to end points is very hard
Trusted(End(
Point
Trusted(End(
Point
Untrusted(World(/(
Untrusted(Network
Secret&Key Secret&Key

35. Dear NSA,
Please stop listening to my fu**ing phone calls.
Love,
Angela Merkel ....................../´¯/) !
....................,/¯../ !
.................../..../ !
............./´¯/'...'/´¯¯`·¸ !
........../'/.../..../......./¨¯ !
........('(...´...´.... ¯~/'...') !
..........................'...../ !
..........''............. _.·´ !
..........................( !
..............................!
Let’s create a secret message and see
how it would be traditionally
attacked:

36. Translate text to ASCII
This:
Dear NSA, Please stop listening to my fu**ing
phone calls. Love,Angela Merkel
Becomes this:
44 65 61 72 20 4E 53 41 2C 20 50
6C 65 61 73 65 20 73 74 6F 70 20
6C 69 73 74 65 6E 69 6E 67 20 74
6F 20 6D 79 20 66 75 63 6B 69 6E
67 20 70 68 6F 6E 65 20 63 61 6C
6C 73 2E 20 4C 6F 76 65 2C 20 41
6E 67 65 6C 61 20 4D 65 72 6B 65

37. Now we need to encrypt it
• Can encrypt with any algorithm that both
the sender and receiver have
• We will use the NIST algorithm:AES
• Use a standard encryption algorithm so
that only the key needs to be exchanged
between the sender and receiver

38. Details of AES
• Advanced Encryption System
• Symmetric key algorithm that comes in
three flavors: 128, 192, and 256 bit
• Those bit lengths represent the length of
the keys
• Would take 1 billion billion years to force
break 128 bit AES

39. Now encrypt the message with 128 bit AES
(Operates on 16 byte blocks)
Plain Text:
44 65 61 72 20 4E 53 41 2C 20 50 6C 65 61 73 65
Key:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
Cipher Text:
0D 1E 8A C7 87 B2 14 9D 47 A2 71 3D 2D 27 1F 5E
Plain&Text
Key
Cryptographic&
Algorithm Ciphertext
Message&
to&encrypt
Encrypted&
Message

40. How would the NSA
attack this?
• Attacker lives in the untrusted world
• Assume the message is intercepted
• The more messages the secret key is used
to protect, the more at risk the key is for
discovery
Trusted(End(
Point
Trusted(End(
Point
Untrusted(World(/(
Untrusted(Network

41. The NSA shifts the trust boundaries

42. The DRM threat model

43. DRM Threat:
The person who purchased the
device or content is attacking it

44. The DRM threat model:
• Attacker has total visibility into the system
and cryptographic algorithm
• Binary is completely visible to an attacker
• Attacker has full control over the
execution environment (CPU calls, memory
registers...)
• If you want a point of trust in the system,
you must build

45. Components of an
encryption algorithm
• Code that defines the algorithm
• Variables and constants of the algorithm
• Encryption/Decryption key (a special type
of variable)
• The key determines the behavior of the
algorithm

46. At any time the algorithm that is running in software is in one
of three states:
!
1. Stored on disk
2. Loaded into memory
3. Executing
On#Disk In#Memory Execu3ng

47. On#Disk In#Memory Execu3ng
State of the algorithm determines the best way to protect it
• The closer you get to the CPU with the algorithm,
the harder it is to protect it
• As you move to the CPU, you can’t just protect, you
also need to hide things
Cryptographic,
Program
Code
(Algorithm)
Variables/
Constants
Key

48. How do you hide something in plan
sight?

49. How do you hide
something like this?

50. Defenses of the DRM trade

51. Defense 1:
Disk Encryption
• Very secure, as long as you never need to
actually run the algorithm
• The algorithm can’t be run in its encrypted
form (CPU won’t understand it)
• Only effective at static analysis attacks

52. Defense 2:
Code Obfuscation
• A defense against reverse engineering
• Modified source and machine code that is
difficult for a human to understand

53. Take code that looks like this:
{
toSub = (y<<4 ^ y>>5) + y ^ sum + k[sum>>11 & 3];
if(toSub > z)
{
// printf("Underflow toSub: 0x%0x current: 0x%0xn", toSub, z);
z = (MAX - toSub) + (z + 1);
}
else
z-= (y<<4 ^ y>>5) + y ^ sum + k[sum>>11 & 3];
sum -= delta;
toSub = (z<<4 ^ z>>5) + z ^ sum + k[sum & 3];
if(toSub > y)
y = (MAX - toSub) + (y + 1);
else
y-= (z<<4 ^ z>>5) + z ^ sum + k[sum & 3];
}

54. And make it look like this:
L_6qy :
r_6zj = r_6qz;
r_7jB = (r_7Fv + (int)2025346621) % (int)2147483647;
r_7Fv = ((int)((av_7Eh & (int)64) == (int)0) * r_7jB) + ((int)!(((av_7Eh & (int)64) == (int)0)) * r_7Fv);
r_7jB = r_7GO ^ (int)1371670574;
r_7GO = ((int)((av_7Eh & (int)64) == (int)0) * r_7jB) + ((int)!(((av_7Eh & (int)64) == (int)0)) * r_7GO);
r_7jB = (r_7Gn + (int)1943683037) % (int)2147483647;
r_7Gn = ((int)((av_7Eh & (int)64) == (int)0) * r_7jB) + ((int)!(((av_7Eh & (int)64) == (int)0)) * r_7Gn);
r_7jB = r_7HG ^ (int)901639918;
r_7HG = ((int)((av_7Eh & (int)64) == (int)0) * r_7jB) + ((int)!(((av_7Eh & (int)64) == (int)0)) * r_7HG);
r_7jB = (r_7Hf + (int)-972842542) % (int)2147483647;
r_7Hf = ((int)((av_7Eh & (int)64) == (int)0) * r_7jB) + ((int)!(((av_7Eh & (int)64) == (int)0)) * r_7Hf);
r_7jB = r_7I8 ^ (int)1359792831;
r_7I8 = ((int)((av_7Eh & (int)64) == (int)0) * r_7jB) + ((int)!(((av_7Eh & (int)64) == (int)0)) * r_7I8);
r_7jB = r_7Ly ^ (int)1790006316;
r_7Ly = ((int)((av_7Eh & (int)64) == (int)0) * r_7jB) + ((int)!(((av_7Eh & (int)64) == (int)0)) * r_7Ly);
r_7jB = r_7Mq ^ (int)832772716;
r_7Mq = ((int)((av_7Eh & (int)64) == (int)0) * r_7jB) + ((int)!(((av_7Eh & (int)64) == (int)0)) * r_7Mq);
r_7jB = (r_7NF + (int)230490512) % (int)2147483647;
r_7NF = ((int)((av_7Eh & (int)64) == (int)0) * r_7jB) + ((int)!(((av_7Eh & (int)64) == (int)0)) * r_7NF);
r_7jB = r_7Ni ^ (int)2059133929;
r_7Ni = ((int)((av_7Eh & (int)64) == (int)0) * r_7jB) + ((int)!(((av_7Eh & (int)64) == (int)0)) * r_7Ni);
r_7jB = (r_7O7 + (int)1830422574) % (int)2147483647;
r_7O7 = ((int)((av_7Eh & (int)64) == (int)0) * r_7jB) + ((int)!(((av_7Eh & (int)64) == (int)0)) * r_7O7);
r_7jB = r_7Oa ^ (int)20264946;
r_7Oa = ((int)((av_7Eh & (int)64) == (int)0) * r_7jB) + ((int)!(((av_7Eh & (int)64) == (int)0)) * r_7Oa);
r_7jB = (r_7gp + (int)-827978944) % (int)2147483647;
r_7gp = ((int)((av_7Eh & (int)64) == (int)0) * r_7jB) + ((int)!(((av_7Eh & (int)64) == (int)0)) * r_7gp);
r_7jB = (r_7hK + (int)1387135918) % (int)2147483647;
r_7hK = ((int)((av_7Eh & (int)64) == (int)0) * r_7jB) + ((int)!(((av_7Eh & (int)64) == (int)0)) * r_7hK);
av_7Eh = (av_7Eh | (int)64);
switch(r_6zc)
{
case (int)0: goto L_6qx;
case (int)1: goto L_6rJ;
case (int)2: goto L_6rK;

55. Defense 3:
Code Flattening
• Inputs and outputs of the algorithm are the
exact same
• Binds blocks of code into a single and very
difficult to understand monolithic block
• Used to force the attacker into spending
time pruning down the call tree

56. Block&1
Block&2
Block&5
Block&4Block&3
if(x&>10&)
else&
if(x&==&10)
else
Input
Output
Normal
Control
Flow
Graph
Before
Obfusca8on
and
Fla:ening
Change the code flow logic:
if (x > 10)
do Block 2
!
if (x == 10)
do Block 3
!
if none of those:
do Block 4

57. Switch
Block+1 Block+2 Block+3 Block+4 Block+5 Block+6 Block+7 Block+8
Condi7on
Input
Output
Control
Flow
Graph
A>er
Obfusca8on
and
Fla:ening
Have
Been
Added
To something much harder to
understand by a human:

58. Defense 4: Data Transforms
(Creating islands of trust in an
untrusted system)

59. • Map your data from one value to another (think
about it like changing the color of a number)
• Creates a mathematical barrier for the attacker
• That barrier is the boundary between your trusted
and untrusted world.
• Attacker must reverse engineer the transform
before they can get access to the true values
• Attacked by watching the CPU add and remove
transform values

60. When the attacker has
access to everything:
• Hiding a key in software is almost
impossible
• Hiding a standard cryptographic algorithm
in software is almost impossible
• Hiding a key + a standard cryptographic
algorithm is something that mathematicians
have figured out how to do

61. Defense 5:
White-box Cryptography
• A technique that allows you to hide a key
inside an algorithm
• First published in late 2002
• The breakthrough mathematical technique
that makes software DRMs possible

62. Lesson from elementary school:
Lookup tables are more powerful
than you think

63. An example with
multiplication:
Just find the intersection
4 X 3
0 1 2 3 4
0
1
2
3
0 0 0 0 0
0 1 2 3 4
0 2 4 6 8
0 3 6 9 12
0 4 8 16124

64. What is this really doing?
• It applies a mathematical transform to our
numbers
• Multiplication:The mathematical operation
of scaling one number by another
• Generally taught to children using a lookup
table (the times tables)

65. Why is this so cool?
• It allows us to ‘embed’ a mathematical
transform into a lookup table
• As we do our lookup, the transform is
magically applied
• Map numbers into different spaces, while
executing the encryption algorithm
• We don’t even need to know the math

66. Huge lookup tables allow us to hide our
key

67. Let’s take a look under the hood of AES

69. White-box AES
AES
S"box
Shi(
Mix
Add
Input
AES)Output
White&Box*AES
S1 S2
MC1 MC2
A1 A2
S3
MC3
A3
Input
AES*Output
Shi*

70. As we move from box to box, we apply
transforms and then migrate to new ones
White&Box*AES
S1 S2
MC1 MC2
A1 A2
S3
MC3
A3
Input
AES*Output
Shi*

71. There is one very important
dependency
• For white-boxing to really work, the input
needs to have a transform already on it
• This works well for DRM, content already
has a transform on it (encryption)

72. Now we have a really nice
binary tank

73. Costs of using these
DRM defenses
• White-box cryptography increases the
binary size
• Obfuscation increases the binary size
• Execution of a cryptographic algorithm in
white-box form is very slow
• When viewed in context of video, slow
decryption can slow the video decode

74. Hardware DRM
• No need to use white-box encryption
• Keys and algorithms are protected inside of
hardware
• Faster decrypt performance

75. Adobe Primetime DRM
on AMD Hardware

76. What we get
• A trust point has been created in the
system using AMD hardware protection
• Hide secrets inside of the hardware instead
of hiding them in white-boxes
• Execution of crypto algorithms in hardware
is much faster than white-box

77. The most important step
is seeding the root key
• AMD provisions the root DRM key into
the the HW
• The root key is used as the base protection
for all keys

78. Hardware Protection
DRM Key
(AES, RSA, ECC)
Machine Key
(1024 bit RSA)
Domain Key
(1024 bit RSA)
Key Encryption
Key(128 bit AES)
Content Encryption
Key
(128 bit AES)
Rotation Key
(128 bit AES)
Shared Domain
Keys
(1024 RSA)
Adobe Primetime HW DRM on AMD
Hardware
Remember keys protecting keys protecting
keys?

79. Why does this work?

80. Some gory details on HW DRM
• Software pushes encrypted keys down into
hardware
• Software pushes down encrypted content +
an index to get back decrypted content
• Because the root key is protected all the way
down to the HW, no key is exposed in SW

81. Video Playback Engine
(Flash Player, AIR, AVE)
Machine Key
SOC
Adobe Access DRM
HW Crypto
Audio Codec
Access Indiv Server
A/V Sync
Composite
Display
Controller
Content
Server
1
4
7
Disk
Storage
Video Codec
Video Player
2 3
License
Server
8
9
Machine Key
License
License
11
12
13
5
6
10
14
Decrypted
Video Samples
Decrypted
Audio Samples
15
16
License
Translation
Machine Key
Provisioned
DRM Key
Machine Key
Overall
Architecture

82. Questions