Upload
amd-developer-central
View
655
Download
0
Tags:
Embed Size (px)
Citation preview
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