2. What is CAS?
A Conditional Access System is the collection of security
components in the end-to-end pipeline of broadcast media,
from source headend equipments to client devices.
PayTV systems generate revenue by enabling media content
rights exclusively to viewers who pay for it.
“Paid channels” or channels with premium content, which are not
available free-to-air.
Video-on-demand and movie-on-demand services.
In simple terms, in general, all devices in the network can
theoretically get access to all the available (free-to-air and
encrypted) media contents/streams. But only those devices
with some specific keys can view the encrypted/protected
contents. The secure management of these keys in the open
network, is the prime responsibility of a CAS vendor.
3. Types of CAS in PayTV systems
Smartcard based solution
Smartcard contains proprietary security logic for decryption.
Proven and tested, and most widely accepted solution.
Recovery time after hacking is high, since cards need to be
replaced.
CAM-based solution
Similar to smartcard based, but the device is just provided with
a slot for CAM module, and any smartcard (meeting CAM
requirements) should be able to work.
More open standard, but poor adoption by market leaders.
Cardless or full-software solution
SoC level security features are used by software modules.
Relatively newer technology, cheaper and growing in
popularity.
Recovery time after hacking is very low, hence discouraging
hackers.
4. CAS for Broadcast Networks
The next few slides explain the end-to-end
management of secure content.
This is a very generalized and simplistic explanation
(intended for engineers with DVB background), and
not specific to any particular CAS vendor.
The basic concept would be similar for all Broadcast
CAS systems, with slight variations in the number of
levels for key encryption, key ladder logic,
encryption/scrambling algorithms used, etc.
5. Scrambling and Descrambling
Free-to-air
service
Scrambled
service
Scrambler
Control
Word (CW)
Random key, from
a Random Number
Generator Can this key be sent to
STB clients without
encryption? Think about
ECM!
Should it same for all
users? Think about
bandwidth!
Scrambled
service
Descrambler
Free-to-air
service
@ Headend Mux
@ STB
Client
How frequently should
this key be changed?
Think about brute-force
attacks!
6. Why is CW shared?
ESPN
(free-to-air)
ESPN (user-1)
Scrambler
CW-1 CW-2 CW-3 CW-4
ESPN (user-2)
ESPN (user-3)
ESPN (user-4)
Bandwidth
wastage. Millions
of users.
Impractical!
Multiple CW
impractical, so use
common CW per
service
7. Why is ECM shared?
Encryptor
Key-1 Key-2 Key-3 Key-4
CW
ECM (user-1)
ECM (user-2)
ECM (user-3)
ECM (user-4)
Multiple ECM
impractical, so use
common ECM per
service
Bandwidth wastage.
Millions of users. Will
run short of PIDs.
Even if sent on same
PID, the overhead to
encrypt & send so
many million ECMs so
frequently is too high.
Thus impractical!
8. End-to-end Key Handling (Headend)
CW
Kser1
CWenc
CWenc
ECM
Kusr1
K-ser1enc
K-ser1enc
EMM
KserN
K-serNenc
K-serNenc
Kusr1
Khw
from SoC/smartcard db
K-usr1enc
K-usr1enc
AUTH
Common to all
User-specific or
group-specific,
common PID
User-specific,
common PID
…
…
Free-to-air service Scrambled serviceScrambler Common to all
CW