DRM: From Software Secrets to Hardware

Protection

Rod Schultz Adobe Primetime DRM

Adobe Primetime

Interesting DRM

lessons

What is DRM?

Digital Rights Management is not security

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

Public perception of DRM:

And this:

Technology created to control the usage of a device or

content after its sale

What is it really?

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

A DRM is intended to slow down the

commoditization of the object or thing it is

protecting

Why use a DRM?

Downloaded music has now gone DRM free

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?

• 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

The impact of changing availability

The changing face of music revenue

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

DRM Architecture

Lessons on single points of failure from WW II

• The French thought an attack through the forest in the north was impossible

• That defense was neutralized by German tanks

Key takeaways for DRM

• Motivated attackers are smarter than you

• They will find your weakest defense

• Single points of failure are really bad

DRMs are designed like biological systems

RenewabilityDiversityRevocation

Lessons from the Masai: Design for confusion

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

• 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

Protect your assets with a castle, not a single wall

DRM$Key

The castle concept for a DRM: Keys protecting keys protecting keys

Device&Key

Content&Key

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

Both built with the same blocks

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

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:

Translate text to ASCIIThis: 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

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

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

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

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

The NSA shifts the trust boundaries

The DRM threat model

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

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

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

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

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

How do you hide something in plan sight?

How do you hide something like this?

Defenses of the DRM trade

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

Defense 2: Code Obfuscation

• A defense against reverse engineering

• Modified source and machine code that is difficult for a human to understand

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%0x\n", 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]; }

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;

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

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

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:

Defense 4: Data Transforms (Creating islands of trust in an

untrusted system)

• 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

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

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

Lesson from elementary school: Lookup tables are more powerful

than you think

An example with multiplication:

Just find the intersection4 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

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)

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

Huge lookup tables allow us to hide our key

Let’s take a look under the hood of AES

White-box AESAES

S"box

Shi(

Mix

Add

Input

AES)Output

White&Box*AES

S1 S2

MC1 MC2

A1 A2

S3

MC3

A3

Input

AES*Output

Shi*

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*

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)

Now we have a really nice binary tank

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

Hardware DRM

• No need to use white-box encryption

• Keys and algorithms are protected inside of hardware

• Faster decrypt performance

Adobe Primetime DRM on AMD Hardware

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

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

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?

Why does this work?

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

Video Playback Engine(Flash Player, AIR, AVE)

Machine Key

SOC

Adobe Access DRMHW Crypto

Audio Codec

Access Indiv Server

A/V Sync

Composite Display Controller

Content Server

1

4

7

DiskStorage

Video Codec

Video Player

2 3

License Server

89

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

Questions