Insecurity in Software II
CS 3IS3
Ryszard Janicki
Department of Computing and Software, McMaster University, Hamilton, Ontario, Canada
Acknowledgments: Material based on Information Security by Mark Stamp (Chapter 12.3)
Ryszard Janicki
Insecurity in Software II 1/31
Digital Rights Management (DRM)
DRM is a good example of limitations of doing security in software
What is DRM?
“Remote control” problem
Distribute digital content
Retain some control on its use, after delivery
Digital book example
Digital book sold online could have huge market
But might only sell 1 copy!
Trivial to make perfect digital copies
A fundamental change from pre-digital era
Similar comments for digital music, video, etc.
Ryszard Janicki
Insecurity in Software II 2/31
Persistent Protection
“Persistent protection” is the fundamental problem in Digital Rights Management (DRM)
How to enforce restrictions on use of content after delivery? Examples of such restrictions
No copying
Limited number of reads/plays Time limits
No forwarding, etc
What Can be Done?
The honour system?
Give up? Internet sales? Regulatory compliance? etc. Lame software-based DRM?
The standard DRM system today Better software-based DRM?
There are some attempts, nothing really well known Tamper-resistant hardware?
Closed systems: Game Cube, and others
Open systems: TCG/NGSCB for PCs, and others
Ryszard Janicki
Insecurity in Software II 3/31
Is Crypto the Answer?
Is Cryptography the Answer?
AttacAktetarc’skegro’salgoisaltios rtoecreocvoevrerththeekey
In staIndstaarndacrrdycprtyoptsocescneanrairoio, ,aatttackerrhhaas s
o CipheCrtipexhte,rtseoxmte, spolaminetepxlat,instidexet-,chsiadnen-eclhiannfon,eelticn.fo, etc. In DRInMDsRcMenascreinoa, raiot,tatctkaeckrehr ahsas
o EveryEthveinrgytihnitnhgeinbotxhe(atbolexas(ta)t least)
Crypto Cwraysptnoogtradpehsyigwnaesdnoftordetshiginsepdrfobrltehmis!problem!
But cryptography is necessary To securely deliver the bits
Part 4 Software 143 To prevent trivial attacks
Then attacker will not try to directly attack cryptography Attacker will try to find keys in software
DRM is “hide and seek” with keys in software!
Ryszard Janicki
Insecurity in Software II 4/31
Current State of DRM and DRM Limitations
At best, security by obscurity A derogatory term in security
Secret designs
In violation of Kerckhoffs Principle
Over-reliance on cryptography The analog hole
When content is rendered, it can be captured in analog form DRM cannot prevent such an attack
Human nature matters
Absolute DRM security is impossible
Want something that “works” in practice What works depends on context
DRM is not strictly a technical problem!
Ryszard Janicki
Insecurity in Software II 5/31
Software-based DRM
Strong software-based DRM is impossible Why?
We can’t really hide a secret in software
We cannot prevent SRE
User with full admin privilege can eventually break any anti-SRE protection
Bottom line: The killer attack on software-based DRM is SRE
Ryszard Janicki
Insecurity in Software II 6/31
DRM for PDF Documents
Two parts to the system
Server – Secure Document Server (SDS)
Protecting a Document
Client – PDF Reader “plugin” software
Protecting a Document
encrypt
persistent protection
Alice
SDS
Bob
Alice creates PDF document
Alice creates PDF document Document encrypted and sent to SDS
Document encrypted and sent to SDS SDS applies desired “persistent protection”
SDS applies desired “persistent protection”
Document sent to Bob
Document sent to Bob
Part 4 Software
Ryszard Janicki
Insecurity in Software II 149 7/31
Accessing a Document
Accessing a Document
Bob authenticates to SDS Bob requests key from SDS
Bob authenticates to SDS
Request key key
Alice SDS
Bob
Bob requests key from SDS
BobBcoabncatnhethnenacacceess dooccumumenetn, tb,utbountlyotnhlryoutghrsupecial
specDiRalMDsRofMtwasroeftware
Part 4 Software 150
Ryszard Janicki
Insecurity in Software II 8/31
Security Issues
Server side (SDS)
Protect keys, authentication data, etc. Apply persistent protection
Client side (PDF plugin)
Protect keys, authenticate user, etc. Enforce persistent protection
Remaining discussion concerns client
Ryszard Janicki
Insecurity in Software II 9/31
Security Overview
Security Overview
Tamper-resistance Obfuscation
A tamper-resistant outer layer A tamper-resistant outer layer
Software obfuscation applied within Software obfuscation applied within
Part 4 Software 152
Ryszard Janicki
Insecurity in Software II 10/31
Tamper-Resistance
Tamper-Resistance
Anti-debugger Encrypted code
EnEcnrcyrpytepdtecdodceodweillwpirllevpernetvsetnatisctantaiclysainsaolyf sPisDF plugin of PDF plugin software
software
Anti-debugging to prevent dynamic analysis Anti-debugging to prevent dynamic analysis of PDF plugin
of PDF plugin software
These two designed to protect each other TBheuste tthweo pderssiginsteedntto aptrtoateccktereawchillogtehetrthru!
But the persistent attacker will get through!
Part 4 Software 153
software
Ryszard Janicki
Insecurity in Software II 11/31
Obfuscation
Obfuscation can be used for Key management
Authentication
Caching (keys and authentication info) Encryption and “scrambling”
Key parts (data and/or code)
Multiple keys/key parts
Obfuscation can only slow the attacker The persistent attacker still wins
Ryszard Janicki
Insecurity in Software II 12/31
Other Desired Security Features
Code tamper checking (hashing)
To validate all code executing on system
Anti-screen capture
To prevent obvious attack on digital documents
Metamorphism (or individualization) For BOBE-resistance
More general code obfuscation Code “fragilization”
Code that hash checks itself Tampering should cause code to break
Operating Systems cannot be trusted
How to protect against “bad” OS? Not an easy problem
Ryszard Janicki
Insecurity in Software II 13/31
DRM for Streaming Media
Stream digital content over Internet Usually audio or video
Viewed in real time
Want to charge money for the content Can we protect content from capture?
So content can’t be redistributed We want to make money!
Ryszard Janicki
Insecurity in Software II 14/31
Attacks on Streaming Media
Spoof the stream between endpoints Man in the middle
Replay and/or redistribute data
Capture the plaintext
This is the threat we are concerned with
Must prevent malicious software from capturing plaintext stream at client end
Ryszard Janicki
Insecurity in Software II 15/31
Design Features
Scrambling algorithms Encryption-like algorithms
Many distinct algorithms available A strong form of metamorphism!
Negotiation of scrambling algorithm
Server and client must both know the algorithm
Decryption at receiver end
To remove the strong encryption
De-scrambling in device driver De-scramble just prior to rendering
Ryszard Janicki
Insecurity in Software II 16/31
Scrambling Algorithms
Server has a large set of scrambling algorithms Suppose Nof these numbered 1 through N
Each client has a subset of algorithms
For example: LIST = {12, 45, 2, 37, 23, 31}
The LIST is stored on client, encrypted with server’s key: E (LIST , Kserver )
Ryszard Janicki
Insecurity in Software II 17/31
Server-side Scrambling
Server-side Scrambling
On server side On server side:
encrypted scrambled data
data
scrambled data
Server must scramble data with an
Server must scramble data with an algorithm the client
supports
algorithm the client supports
Client must send server list of algorithms it Client must send server list of algorithms it supports
supports
ServeSr emruvestr smecuusrtelsyecoumremlyucnoicmatmeuanligcoartitehamlgcohroitichemto client
choice to client
Part 4 Software 161
Ryszard Janicki
Insecurity in Software II 18/31
Select Scrambling Algorithm
Select Scrambling Algorithm
E(LIST, Kserver) E(m,K)
Alice scramble (encrypted) data (client) using Alice’s m-th algorithm
Bob (server)
The key K is a session key
The key K is a session key The LIST is unreadable by client
The LIST is unreadable by client Reminiscent of Kerberos TGT
o Reminiscent of Kerberos TGT
Part 4 Software
162
Ryszard Janicki
Insecurity in Software II 19/31
Client-side De-scrambling
Client-side De-scrambling
On client side On client side:
encrypted scrambled scrambled data data
data
Try to keep plaintext away from potential attacker
Try to keep plaintext away from “Proprpieottareyn”tdiaelviactetdarcivkeerr
Scra“mPbrloinpgriaelgtoarityh”mdse“vbiackeedriniv”er AbleotoScdrea-smcrbalmingblealgatorlaitshtmso“mbeankted in”
o Able to de-scramble at last moment
Part 4 Software 163
Ryszard Janicki
Insecurity in Software II 20/31
Why Scrambling?
Metamorphism is deeply embedded in system
If a scrambling algorithm is known to be broken, server will
not choose it
If client has too many broken algorithms, server can force software upgrade
Proprietary algorithm harder for SRE
We cannot trust cryptography strength of proprietary algorithms, so we also encrypt
Ryszard Janicki
Insecurity in Software II 21/31
Why Metamorphism?
The most serious threat is SRE
Attacker does not need to reverse engineer any standard crypto algorithm
Attacker only needs to find the key
Reverse engineering a scrambling algorithm may be difficult This is just security by obscurity
But appears to help with BOBE-resistance
Ryszard Janicki
Insecurity in Software II 22/31
DRM for a P2P Application
Today, much digital content is delivered via peer-to-peer (P2P) networks
P2P networks contain lots of pirated music
Is it possible to get people to pay for digital content on such P2P networks?
How can this possibly work?
A peer offering service (POS) is one idea
Ryszard Janicki
Insecurity in Software II 23/31
P2P File Sharing: Query
P2P File Sharing: Query
Suppose Alice requests “Hey Jude” Suppose Alice requests “Hey Jude”
Black arrows: query flooding Black arrows: query flooding
Red arrows: positive responses Red arrows: positive responses
Frank
Alice Carol Dean Bob Marilyn Pat
Pat
Ted
Carol
Fred
Alice can select from: Carol, Pat
Alice can select from: Carol, Pat
Part 4 Software 167
Ryszard Janicki
Insecurity in Software II 24/31
P2P File Sharing with POS
P2P File Sharing with POS
Suppose Alice requests “Hey Jude” Suppose Alice requests “Hey Jude”
Black arrow: query Black arrows: query
Red arrow: positive response Red arrows: positive response
POS
Bill Ben Joe
Ted
Alice Carol Dean Pat
Bob Marilyn Fred
Carol
Pat
Alice selects from: Bill, Ben, Carol, Joe, Pat Alice selects from: Bill, Ben, Carol, Joe, Pat
Bill, Ben, and Joe have legal content! Bill, Ben, and Joe have legal content
Part 4 Software 168
Ryszard Janicki
Insecurity in Software II 25/31
POS
Bill, Ben and Joe must appear normal to Alice If “victim” (Alice) clicks POS response
DRM protected (legal) content downloaded Then small payment required to play
Alice can choose not to pay
But then she must download again
Is it worth the hassle to avoid paying small fee? POS content can also offer extras
Ryszard Janicki
Insecurity in Software II 26/31
POS Conclusions
A very clever idea!
Piggybacking on existing P2P networks Weak DRM works very well here
Pirated content already exists
DRM only needs to be more hassle to break than the hassle of clicking and waiting
Ryszard Janicki
Insecurity in Software II 27/31
DRM in the Enterprise
Why enterprise DRM?
DRM-like protections needed by corporations for regulatory
compliance
What’s Different in Enterprise DRM? Technically, similar to e-commerce
But motivation for DRM is different Regulatory compliance
To satisfy a legal requirement
Not to make money – to avoid losing money!
Human dimension is completely different Legal threats are far more plausible
Legally, corporation is OK provided an active attack on DRM is required
Ryszard Janicki
Insecurity in Software II 28/31
Enterprise DRM
Moderate DRM security is sufficient
Policy management issues
Easy to set policies for groups, roles, etc. Yet policies must be flexible
Authentication issues
Must interface with existing system
Must prevent network authentication spoofing (authenticate the authentication server)
Enterprise DRM is a solvable problem!
Ryszard Janicki
Insecurity in Software II 29/31
Many examples of DRM failures
One system defeated by a felt-tip pen One defeated my holding down shift key
Secure Digital Music Initiative (SDMI) completely broken before it was finished
Adobe eBooks
Microsoft MS-DRM (version 2) Many, many others
Ryszard Janicki
Insecurity in Software II 30/31
DRM Conclusions
DRM nicely illustrates limitations of doing security in software
Software in a hostile environment is extremely vulnerable to attack
Protection options are very limited Attacker has enormous advantage
Tamper-resistant hardware and a trusted OS can make a difference
We’ll discuss this more later: TCG/NGSCB
Ryszard Janicki
Insecurity in Software II 31/31