SecureMedia DRM: Verizon Apps
Verizon FiOS Mobile:
• Broadcast
• VOD (purchase, rental, subscription)
• HLS and Downloadable
Redbox Instant, by Verizon
• VOD HLS only (purchase, rental, subscription)
• Partnership, shared content / keys.
• Different app and SDK versions.
SecureMedia DRM: Business Models
Business Models --
•
•
•
•
•
•
Broadcast – Live content such as TV
Pay Per View – Customer pays extra for a Broadcast event
Pay Per Block – Customer purchases block of time
Time Shift – Playback of previously recorded Broadcast or PPV
Pause / Live – Pausing and resuming live Broadcast content
VOD (Video On Demand) – On demand content from a
streaming server (such as HLS)
• Download – On demand content played from local disk
• Band– A band is a unique identifier of a group of channels. The
band is used to authorize and manage broadcast channels
SM Terminology: Unique Identifiers
Unique Identifiers --
• SN (SubscriberNumber) - The unique identifier of a client device.
The SN is used to register, authorize, and manage client devices.
• MediaKeyID – A unique identifier for Encryption / Decryption
keys in the Encryptonite System. The MediaKeyID is used to
authorize and manage MediaKeys.
• Band– A band is a unique identifier of a group of channels. The
band is used to authorize and manage broadcast channels
WiFi Diagnostics: Whitepaper
Click below to open HLS Wifi Diagnostics Whitepaper
5
Mobile SDKs: Diagnostic Tools
Android
▪ aLogcat (free)
▪ Wifi Analyzer
▪ Speedtest.net
▪ Android SDK
- Adb tools
▪ ConsoleLog
▪ No WiFi Analyzer Tools
(banned by Apple)
▪ Speedtest.net
▪ iPhone Configuration
Utility (Windows)
▪ Xcode Tools (OS X)
Data Protection can be grouped into three main categories, each
of which must be appropriately addressed if data is to be
adequately protected. Meeting these core security needs is the
objective of the SecureMedia® Encrytonite DRM system.
C – Confidentiality
I – Integrity
A – Authentication
Motoroa Confidential Restricted
08.16.10
Page 6
C – Confidentiality
• Responsible for the protection of information as it passes from
one network device to another.
• Not only the data but potentially the IP addresses, message
length, protocol type etc.
• Generally achieved through the use of encryption algorithms
and can be applied at multiple parts of a network.
08.16.10
Page 7
I – Integrity
• Used to determine whether the information has been modified
as it passes between two network devices.
• “Man in the Middle” attack prevention is a typical reason why
Data Integrity techniques are employed.
• Actual information may or may not be encrypted - this choice is
a matter to be addressed by the content provider.
• Hashing functions are often used in the process of Integrity
checking.
Motorola onfidential Restricted
08.16.10
Page 8
A – Authentication
• Verifies the source of the information transfer and ensures the
source of the information is genuine, therefore prevent
spoofing attacks.
• Often coupled with Integrity checking in the majority of
systems but is in fact a distinct service.
• Authentication of the client can be supported through the use
of secure hashing, digital certificates or AAA (Authentication,
Authorization and Accounting) services.
08.16.10
Page 9
Data Confidentiality
Symmetric Encryption
Encryption and decryption mirror each other, use same key
Data Confidentiality
Asymmetric Encryption
Encryption and decryption processes are carried out using different
keys which are generally referred to as Public Keys and Private
Keys respectively.
Data Confidentiality
Encryption Algorithm Usage
Employs both Symmetric and Asymmetric encryption algorithms
to exploit the advantages of each.
Data Confidentiality
Common Encryption Algorithms
Data Confidentiality
Cryptographic Keys
The primary part of any encryption process is not
the algorithm but the key. It is the key that makes
the cipher text random, not the algorithm.
Key size, generation and distribution are all
critical factors in determining the
robustness of a cipher.
Data Confidentiality
Key Size
Key sizes are described by the number of bits they are
comprised of. For example, a 56-bit key such as that used in
DES is used to block cipher 64-bit blocks of plain text,
producing 64-bit blocks of cipher text.
In order to carry out a “brute force” or “iterative” attack on this cipher
text, an attacker must apply every possible key to a 64-bit block.
Since the key is 56-bits long, this equates to 256 =
72,057,594,037,927,936 possible keys.
Data Confidentiality
Determining Key Size
There are a number of factors which determine key size but
predominantly, the desired level of encryption and the type
of encryption algorithm in use are most important.
NIST (National Institute for Standards and Technology) recommends:
Symmetrical Ciphers: minimum 80-bits (AES can
use 256bit keys).
Asymmetrical Ciphers: minimum 1024-bits
Data Confidentiality
Key Generation
The most important factor associated with key generation
within a cryptographic system is the key’s randomness.
•
Attackers can exploit systems which do not have sufficiently random
key generation, potentially predicting the keys that the system is
likely to use next.
•
Random number or pseudo random number generators are used in
the key generation process, with the latter considered to be less
secure than the former.
Data Confidentiality
Key Distribution
Once the key is formulated, the next significant problem is
ensuring the key can be distributed to the intended recipient.
•
Symmetrical encryption - privacy of the shared key is of critical importance and must be
kept secret at all times.
• Asymmetrical encryption - public key is not secret and can be viewed by any party,
relying on the fact that the private key is kept secret.
Diffie-Hellman key exchange is a popular electronic means of distribution (upon which RPK
encryption is based).
Data Integrity
Hashing
Hash: A mathematical function that is easy to compute in
one direction but computationally impossible to reverse.
Data Integrity
Hashing
• Enables messages to be passed between devices in the
knowledge that they have not been tampered with during
transmission
• Used extensively to support Integrity checking with a wide
variety of protocols, a common example being IPSec.
Common Hashing Algorithms:
Data Integrity
Digital Signatures and Certificates
Digital Signature : an encrypted message digest that is
appended to a document which is used to validate the
identity of the sender.
Data Integrity
Digital Signatures
• Created by combining hash functions with public key
algorithms and, instead of signing a document.
• Sender will encrypt the hash with a private key to create a
digital signature
• The recipient will take the signature and decrypt it using
the corresponding public key.
A Digital Certificate contains a public key which has been signed and
verified by a trustworthy third party termed a CA (Certification Authority).
IPTV Security
IPTV Security
• Digital media transferred to the subscriber on a broadcast
or on demand basis
• Two techniques in the industry for content protection:
User authentication and imposed restrictions carried out at the
video Super Head End, which houses the relevant AAA
(Authentication, Authorization and Accounting) databases eg
SecureMedia’s Encryptonite ONE system
IPTV Security
Digital Rights Management
• DRM gives copyright holders the ability to control their
media, when that media is in a digital format.
• In addition to copy protection, rights to view content under
specific times and conditions can be managed with DRM.
IPTV Security
CAS Encryption
• Key is termed the Control Word. Creation, management,
storage, distribution etc responsibility of the CAS vendor
• For the system to work effectively, both the sender and
receiver need an identical copy of the Control Word.
In order to strengthen security, Control Words are changed
on a very regular basis, in the order of 10s of seconds
IPTV Security
Entitlement Message
•
An EMM (Entitlement Control Message) is used by the CAS to
configure client side entitlements.
• By sending a client an EMM (embedded in the transport stream), the
client can be restricted or entitled to view different content.
SecureMedia® Encryptonite ONE
Introduction
Video content distribution today can be facilitated through
many mechanisms:
Requirement to ensure that the content can be controlled by the
provider is common across delivery methods
SecureMedia® Encryptonite ONE
Introducing Encryptonite ONE
SecureMedia® Encryptonite ONE system supports these
essential elements of content security:
SecureMedia® Encryptonite ONE
Benefits
SecureMedia® Encryptonite ONE
System Architecture
The Encryptonite System
can simultaneously
support both Video on
Demand (VOD) and
broadcast applications
using the same core
Encryptonite System
Services components and
the same client SDK.
SecureMedia® Encryptonite ONE
Key Server
•
•
•
•
•
Secure storage of MK (Media
Decryption Keys).
Provisions content information for
authorized MediaPass databases.
Generates tokens for MediaPass
databases, as required.
Securely dispenses keys to clients.
Key management functionality.
SecureMedia® Encryptonite ONE
Key Server
•
Key Server System has 4 main components:
SecureMedia® Encryptonite ONE
Key Server
•
Key Server System has 4 main components:
SecureMedia® Encryptonite ONE
Key Sever: Key Vault
•
•
•
•
An Oracle / MySQL database where all key information is stored
Generates tokens and provides them to validated MediaPass Databases
Processes requests for verification of tokens by client devices.
Multiple Key Servers can connect to the same Key Vault.
SecureMedia® Encryptonite ONE
Key Sever: KVSS
• HTTP server which provides protection of internal communication within
the Encryptonite system
• Entities which use the KVSS to secure their communication include
Encryptors, MediaPass Admin and the Broadcast Director
KVSS contains two sub-functions, which are:
• KVES (Key Vault Encryptor Services) - used to generate
Media Keys for encryption and decryption purposes
• KVCS (Key Vault Content Services) - used to keep
MediaPass Databases updated with the latest content
offerings.
SecureMedia® Encryptonite ONE
Key Sever: KMC (Key Management Console)
• Administrative interface used by network operations which is operated as
a web application.
• The KMC allows an administrator to configure and manage the data
stored within the key vault.
SecureMedia® Encryptonite ONE
ECMOD
SecureMedia's ECMOD (ECM on Demand) acts as an ECM
(Entitlement Control Message) Generator, which is a logical
function associated with the DVB Simulcrypt architecture. The
ECMOD function may also be termed smecmg.
SecureMedia® Encryptonite ONE
KVHLS
KVHLS provides a management function as part of SecureMedia's
support for HLS+ (HTTP Live Streaming +). KVHLS generates and
protects the control words used for chunk encryption, as well as
generating appropriate metadata for the HLS+ client community
SecureMedia® Encryptonite ONE
KVBands
The KVBands element of the SecureMedia system is managed via the KMC
(Key Management Console). The purpose of KVBands is essentially to provide
the operator with the capability to generate a large number of bands. Band
creation is normally the responsibility of the Broadcast Director and as such,
Broadcast Director must be disabled if KVBands is in use.
SecureMedia® Encryptonite ONE
Tokens
In the Encryptonite System a
token is a unique number
whose possession provides
assurance that the client
device presenting it is entitled
to receive a key. This key will
enable the client device to
play the particular media to
which that token
corresponds.
Lifecycle of a Token:
SecureMedia® Encryptonite ONE
Token Usage
Step 1 Tokens are bulk ordered from the Key Server System.
Step 2 Tokens are delivered to the MediaPass Server System. This process is run
automatically at scheduled intervals to ensure that the MediaPass Server System
has an adequate supply of tokens.
Step 3 MediaPass is securely delivered to the client device via ESAM.
Step 4 Upon receipt of the MediaPass, which includes the token, the client device
requests the Key Server to securely deliver the appropriate Media Decryption Key,
enclosing the token as proof of entitlement.
Step 5 If the token is valid and unused, the Key Server will deliver the appropriate
key and will then mark the token as having been used.
Tokens, therefore, represent a single play of a specific media by providing ‘proof of
entitlement’ for delivery of a requested Media Decryption Key
SecureMedia® Encryptonite ONE
MediaPass Server System
The MediaPass Server System is a BSS (Business Support System) which
provides the main interface for integration between middleware and the
Encryptonite System (essentially, the middleware determines the rights a
particular client holds, and a Business Support Server is used to fulfill the
management of those rights). The roles of the MediaPass Server System include:
SecureMedia® Encryptonite ONE
MediaPass Server System
SecureMedia® Encryptonite ONE
Encryptonite System Access Manager
The ESAM is responsible for providing secure communication between the client
device eg STB and the content delivery network. As such, all client devices carry
out a registration procedure with the ESAM, through which the client is
authenticated as a legitimate device. This effectively allows the ESAM to detect
the presence of cloned devices which can potentially be a significant security
problem.
SecureMedia® Encryptonite ONE
ESAM Protocol
ESAM uses a closed protocol in order to exchange security configuration
information between the ESAM server and the SecureMedia client community.
Based on HTTP, the latest version of the protocol is ESAM3 (introduced in ES2.2),
which utilizes standard encryption algorithms such as RSA (Rivest, Shamir,
Adleman) and AES (Advanced Encryption Standard) in order to protect traffic.
SecureMedia® Encryptonite ONE
Middleware
• Middleware must interact with the Encryptonite System in order to convey the
rights and entitlements a particular subscriber has.
• The middleware will provide to the BSS (as part of the MediaPass system) the
appropriate authorizations for PPV (Pay Per View), Broadcast and Time Shift
content, as well as the authorization to deliver MediaPasses.
SecureMedia® Encryptonite ONE
Broadcast Subsystem
• The Encryptonite Broadcast Services are generic components that have been
designed for reuse in any broadcast implementation of the Encryptonite
System.
• The Encryptonite Broadcast Services use the Encryptonite System Services to
provide MediaPass and Key services, as well as ESAM to provide a secure
and authenticated channel to client devices for the delivery of MediaPasses.
SecureMedia® Encryptonite ONE
Broadcast Director
The Broadcast Director is in control of the BE (Broadcast Encryptors) and is
responsible for activities such as
• Changing the encryption keys in accordance with a key schedule
• Organizing channels into bands
• Ensuring each Broadcast Encryptor has the correct configuration
Broadcast Director monitors BE status and reports to the operations center to
track headend health.
SecureMedia® Encryptonite ONE
Broadcast Director
SecureMedia® Encryptonite ONE
Broadcast Encryptor
• Handle a variety of media formats
• Broadcast Encryptors encrypt video streams on the fly
• Each Broadcast Encryptor can support multiple concurrent video streams, each
of which can have their own encryption key.
• Broadcast Encryptors can potentially receive their video streams from an
upstream broadcast encoder, or could potentially be integrated within the
encoder.
• The Broadcast Encryptor may feed a downstream Media Server or could
potentially multicast content directly to the client device community.
SecureMedia® Encryptonite ONE
VoD Encryptor
• The VoD Encryptor is responsible for encrypting VoD assets
• Exactly how the media asset is encrypted is implementation specific, factoring
in the capabilities of the media server and the media player.
• The VoD Encryptor can also be integrated into an encoder application.
• The VoD Encryptor is a command line app, it is possible that encryption can be
included as part of automatic media ingestion processes.
SecureMedia® Encryptonite ONE
smchunker
smchunker forms part of SecureMedia's HLS+ solution. The role of the smchunker
is to break a transport stream up into media chunks, each of which are accessed
by the client device via a unique URL.
SecureMedia® Encryptonite ONE
Client Device
The client device must support the SecureMedia Client, which is based on the
standard ES-SDK. The SecureMedia Client can support the decryption of a
number of media formats, such as VoD, Broadcast, PVR (Personal Video
Recorder), Download etc. The client software itself is designed to be lightweight,
ensuring that client devices with a low specification can still support the client.
SecureMedia® Encryptonite ONE
Clones
ESAM provides a facility to detect client devices which have been cloned or
duplicated. Through configuration, it is possible to prevent cloned client devices
from running on the system, or simply raise a flag to say a clone has been
compromised.
SecureMedia® Encryptonite ONE
Background Jobs
Each of the administrative applications within the Encryptonite System routinely
conduct a number of background jobs. In each case, management of these
background jobs can be achieved under the Tasks tab within each administrative
GUI.
SecureMedia® Encryptonite ONE
KMC
• Cleaner - deletes old inactive keys and deactivates all expired keys.
• KeyServer Key Changer - generates new a KeyPair used to secure
KeyServer communication (usually disabled).
• Log Archiver - archives database log records to text file and purges the
records from the database requests.
• Key Supply - imports media key details from the Key Supplier (only if
downstream key vault, separate tasks per key supplier).
•
SecureMedia® Encryptonite ONE
MPAdmin
• Cleaner - deletes old client session records from database.
• Key Supply - imports media key details from Key Supplier (separate
tasks per key supplier).
• Log Archiver - archives database log records to text file and purges the
records from the database requests.
SecureMedia® Encryptonite ONE
Broadcast
• Configuration Loader - ensures the Broadcast Configuration in memory is
an accurate reflection of the current database configuration.
• Key Generator - orders new keys from KeyVault as needed to ensure all
Bands have current and next keys available.
• Key Change - changes broadcast keys for all bands that use the
particular key schedule (one job per schedule).
• Log Archiver - archives database log records to text file and purges the
records from the database requests.
• Monitor - monitor Broadcast Encryptor (One job per broadcast encryptor).
SecureMedia® Encryptonite ONE
Encryptonite Basic System Operation
SecureMedia® Encryptonite ONE
IPTV Services
• Broadcast, whereby the service is similar in functionality to "normal" TV
services; you choose your channel and the service provider dictates the
program scheduling.
• Video on Demand, which allows the customer to choose which program
they would like to watch, regardless of the current time.
• OTT (Over The Top), whereby customer receive TV content via the
Internet and as such, that content flows over the top of the service
provider's network.
SecureMedia® Encryptonite ONE
Broadcast
• IP Multicasting is used to deliver the content across the IP distribution
network in order to provide an efficient delivery mechanism
• Protocols such as IGMP (Internet Group Management Protocol) allow
client devices to join multicast groups. As a user flicks from one channel
to another, they are leaving one multicast group and joining another.
• PIM (Protocol Independent Multicast) is also found in the IP distribution
network and is used as mechanism to keep the multicast routes across
the network optimized.
SecureMedia® Encryptonite ONE
Broadcast
SecureMedia® Encryptonite ONE
Video on Demand
• Subscribers can gain access to a menu of available programs which they
can choose to watch as and when they see fit.
• VoD services are based on unicast IP delivery, with video streams often
being established using RTSP (Real Time Streaming Protocol).
• Video is sent on a 1:1 basis between the Media or VoD Server and the
client device.
• VoD servers are found at the network edge in order to reduce the amount
of traffic flowing across the core network.
SecureMedia® Encryptonite ONE
Video on Demand
SecureMedia® Encryptonite ONE
Over the Top Service
• OTT (Over The Top) service describes the notion of a mobile or fixed line
provider providing transport services to a 3rd party’s service offering.
• Content will be transported across a mobile or fixed access network of
some description.
• Can be to the STB, CE Devices, or to mobile devices.
• Usually used to supplement and enhance traditional services.
SecureMedia® Encryptonite ONE
HLS+
• HLS (HTTP Live Streaming) is a protocol designed for the streaming of
VoD and broadcast content.
• Media sources are essentially broken down into small chunks, which are
separately accessible via unique URLs.
• A key advantage to HLS is the concept of adaptive streaming; essentially,
the same content is available at different data rates and the client will use
whichever chunks are applicable to its available bandwidth.
• Adaptive modulation is particularly useful for wireless devices which may
routinely flick between 3G, 3.5G, 4G, Wi-Fi etc.
• HLS+ is a solution designed by SecureMedia which incorporates HLS
functionality with AES128 based content encryption offered by the
Encryptonite One system.
• HLS+ features all the necessary components of a HLS system, including
the chunker (termed smchunker) which is responsible for segmenting and
encrypting media.
SecureMedia® Encryptonite ONE
Media Transport
• Although IP will be the underlying transport mechanism to get video
content from source to the customer, MPEG-2, H.264, VC-1 must be kept
synchronized and in one piece for eventual play out.
• MPEG-2 Transport streams can be encapsulated in:
• RTP (Real time Transport Protocol), which would provide timing
synchronization, sequential packet delivery and packet loss
indication, as well as support for FEC (Forward Error Correction)
• Standards for transporting MPEG-2 TS directly within IP could be
utilized.
• UDP is used in both cases at the Transport Layer because of its low
transmission overhead
SecureMedia® Encryptonite ONE
Media Transport
SecureMedia® Encryptonite ONE
ESAM Responsibilities
The ESAM looks after the initial registration procedures
and any subsequent connection and transaction requests
The ESAM protocol, which is part of KVSS (Key Vault Secure Services), is
used to secure communication between the client device and server (the ES).
SecureMedia® Encryptonite ONE
Initialization
Initialization happens once in the
lifetime of a device. It is supplied
with a HUID (Hardware Unique
Identification) string which is
stored permanently and is
available for the entire lifetime of
the device. This identifier may be
an existing hardware identifier
such as a MAC (Medium Access
Control) address.
SecureMedia® Encryptonite ONE
Registration
The registration
process, which may
occur only once in
the lifetime of the
subscription, typically
starts with the client
device receiving a
HTTP based
command from a
web portal (which
forms part of the
Middleware).
SecureMedia® Encryptonite ONE
Registration
The client device will use
random data to generate a
private/public key pair,
termed dpvk (Device Private
Key) and dplk (Device
Public Key) respectively.
These will be used to
secure subsequent
communication with the
ESAM.
SecureMedia® Encryptonite ONE
Connection
Once registration is
complete, the client
device must establish
a connection with the
ESAM before any
transactions can take
place
The Open Session
contains the following
parameters:
CHD, sn, Regisgration
#, HUID
SecureMedia® Encryptonite ONE
Registration Authorization Models
The two models of Registration are:
Pull
Push
The difference between the two is essentially the point in the process at
which the Middleware authorizes the SecureMedia Client.
SecureMedia® Encryptonite ONE
Pull Registration Flow
SecureMedia® Encryptonite ONE
Pull Registration Process Flow
Step 1 The portal triggers a registration procedure by sending the Register
API.
Step 2 The client device sends a Registration Request to the ESAM.
Step 3 The ESAM uses the Middleware Registration Service to check for
authorization. The ESAM will use the Register message of the Registration
Protocol, which contains information elements such as the client device
Identifier and any application specific data eg. activation code that the client
device has sent.
SecureMedia® Encryptonite ONE
Push Registration Authorization Model
SecureMedia® Encryptonite ONE
Push Registration Authorization Model
Step 1 The Middleware pushes authorization for a client device to the Business
Authorization Service of the BSS. The protocol used on this interface is BSAU
(Business Support Authorization Update) protocol and the message used to
provide authorization to a particular client device is the Start API. The Start API
contains information elements which denote permissions for services such as
broadcast, VoD and PPV, as well as setting time/duration parameters if required.
Step 2 The portal triggers the registration process by sending the Register API.
Step 3 The client device sends a Registration Request to the ESAM.
Step 4 The ESAM sends a Registration Authorization Request to the Business
Support Server to verify that authorization for registration has been received from
the Middleware.
SecureMedia® Encryptonite ONE
VOD Architecture Overview
SecureMedia® Encryptonite ONE
VOD Process Flow
Step 1 Before any media assets are made available to the subscriber, the
asset must be encrypted. This requires the Encryptor Producer to obtain an
appropriate MK (Media Key) from the Key Vault.
Step 2 Once encrypted, the secured asset is sent to the Media Server for
storage and eventual access by subscribers.
Step 3 The Client device purchases the rights to play the media via the
middleware portal. At this stage, authorisation to view the VoD asset may
be passed to the BSS.
Step 4 The client device sends a service request to the ES in order to
obtain a MediaPass.
Step 5 Assuming authorisation has been granted, the BSS provides a
MediaPass to the client via ESAM.
SecureMedia® Encryptonite ONE
VOD Process Flow
Step 6 The SecureMedia client uses the MediaPass to formulate a request
for the corresponding MK (Media Key) from the Key Server. This MK will be
used for decryption.
Step 7 Providing the MK request is valid, the Key Server provides the
correct MK.
Step 8 MK is used to decrypt the media stream received from the Media
Server.
SecureMedia® Encryptonite ONE
Broadcast Architecture Overview
SecureMedia® Encryptonite ONE
Broadcast Middleware
Middleware is integral to the broadcast scenario, providing features such as:
• Portal hosting, to allow the subscriber to browse the available
broadcast channels.
• Client device control, to ensure the client device joins the correct
multicast once a channel has been selected.
• Provision of client authorization confirmation to the BSS.
SecureMedia® Encryptonite ONE
Broadcast Process Flow
Step 1 The Broadcast Director is responsible for triggering the
creation of new broadcast keys and also scheduling key changes
(on a configurable basis) for the Broadcast Encryptor.
Step 2 The Broadcast Encryptor encrypts the live broadcast
streams on a real-time basis, all under the control of the Broadcast
Director.
Step 3 The client device must contact the BSS (Business Support
System) on a regular basis in order to obtain MediaPasses for the
broadcast key set.
NOTE: Communication between the client device and the BSS is
protected by ESAM. This means that client devices are
authenticated and MediaPasses are encrypted in transit.
SecureMedia® Encryptonite ONE
Broadcast Process Flow
Step 4 Just like VoD, the client device will process the MediaPass
in order to create a key request. The key request will be passed to
the Key Server and if successful, will result in the broadcast MKs
being sent to the client device.
Note: The process in Step 4 ensures that client devices can obtain
broadcast keys in advance of any scheduled key changes.
Step 5 Encrypted media is broadcast across the content
distribution network, from the Headend (where the source could be
an encoder, Broadcast Encryptor or Media Server) down to the
client device community.
Step 6 The encrypted media stream contains the information that
the client device needs in order to apply the correct decryption
keys.
SecureMedia® Encryptonite ONE
Timeshift Architecture Overview
SecureMedia® Encryptonite ONE
Timeshift Process Flow
Step 1 Broadcast content is being encrypted on the fly, with control of the
Broadcast Encryptor undertaken by the Broadcast Director and the MK supplied
by the Key Vault.
Step 2 The subscriber issues a command to record live content; this could be
via a NPVR or LPVR mechanism.
Step 3 The subscriber later chooses to view their recorded content. This could
potentially be days or weeks after the recording and as such, the client device
must obtain the correct MK. The process starts with the subscriber browsing
their recorded content and selecting the recorded program. This triggers the
Middleware into issuing a Time Shift command to the client device, which
includes Band and Time reference information which eventually allows the ES
to obtain the correct key.
SecureMedia® Encryptonite ONE
Timeshift Process Flow
Step 4 The client device issues a Time Shift request to the ESAM. Assuming
the subscriber is authorized to use Time Shift, the Band and Time information
sent in this request (obtained in Step 3) is used to generate a MediaPass
NOTE Although recommended by SecureMedia, Band and Time information is
not always used by the Middleware to identify the appropriate key; other
techniques are available.
Step 5 The MediaPass is sent to the client device.
Step 6 The client device uses the MediaPass to obtain the correct MK from the
Key Server.
Step 7 The stored, encrypted content is played out and decrypted as
appropriate.
SecureMedia® Encryptonite ONE
External Verification Service
XVS (External Verification Service) is an add-on to the Encryptonite
System which enables external verification of ESAM registrations.
SecureMedia® Encryptonite ONE
Broadcast Channels, Bands, Groups
A band defines a group of channels that will always be sold together so that
all channels in a band are encrypted with the same media key, meaning that
the client device only has one decryption key for all channels in the band.
SecureMedia® Encryptonite ONE
Groups
A group defines a physical collection of channels. Although a channel may
be sold as part of a particular band, the encryption of the channel is defined
by the group it is in.
SecureMedia® Encryptonite ONE
Groups and Broadcast Encryptors
It is possible that several groups will be assigned to a particular BE.
Likewise, for redundancy purposes, a group can be assigned to several
BEs.
When configuring Broadcast Encryptors, it is possible to specify parameters
that relate to an individual channel, an encryptor or a group of channels.
SecureMedia® Encryptonite ONE
Bundles
Bundles were introduced by SecureMedia as a mechanism for grouping
together multiple services eg bands, VoD assets, PPV events etc into one
administrative entity.
Bundles can also be used to create customized packages if necessary,
where bundles are created to meet the specific requirements of a customer.
All bundles are created and managed in MediaPass Admin.
SecureMedia® Encryptonite ONE
Service Customization
• Certain providers may require a very high level of granularity in terms of
the way in which channels are managed and authorized.
• The KVBand module was introduced in order to more efficiently manage
deployments where the total band number exceeds ~100. When KVBand
is in use, the Broadcast Director is disabled.
SecureMedia® Encryptonite ONE
Service Customization
SecureMedia® Encryptonite ONE
Broadcast Services: Detailed
SecureMedia® Encryptonite ONE
Broadcast Workflow – Detailed
SecureMedia® Encryptonite ONE
Responsibilities of the Client Device
At regular configurable
intervals, a message is sent
to the BSS (Broadcast
Support System) with a list of
the media keys held for use
by broadcast streams.
The BSS will return an
acknowledgement of the
request and, if appropriate,
will send:
• MediaPasses for media
keys that are missing from
the client device.
• A list of mediakeys that are
not required and should be
removed.
SecureMedia® Encryptonite ONE
Responsibilities of the Client Device
Each MediaPass is used by the ES client device to request the media decryption
key (MK) from the Key Server. When the client device receives the MK from the
Key Server, it will be processed into the sm client and held ready for use.
A client device will typically hold three media keys for each authorized band:
• Current – media key for the band that is currently being encrypted.
• Next – media key that will be needed after the next key change.
• Previous – media key used before the current media key.
SecureMedia® Encryptonite ONE
Responsibilities of the Client Device
Each encrypted broadcast media stream contains a Media ID as a reference to
the media key that the client device must use to decrypt the stream. Holding
multiple media keys in the client device has the benefit of rapid channel changes
that are transparent to the user.
SecureMedia® Encryptonite ONE
Responsibilities of the Client Device
Rights are stored server-side and no keys or rights are stored persistently on
the client device. On power-up, the SM client within the client device must
acquire all of the keys for the channels the client device has subscribed to. To
do this, the client device sends a standard request to the BSS
In response, the client device will receive the MediaPasses it needs.
SecureMedia® Encryptonite ONE
Responsibilities of the Encryptonite System
The Business Support System is the server-side component that receives
the regular client device requests. The BSS uses several items of
information to decide the response to send to the client device:
• A record of the bands the client device is subscribed to (based
on the authorization information pushed to the ES from the
Middleware).
• MKs and Media IDs associated with each band.
• MKs held by the client device (based on the BSS Ping message
contents).
SecureMedia® Encryptonite ONE
Responsibilities of the Encryptonite System
This information enables the BSS to get MediaPasses for MKs missing from
the client device and to generate the list of MKs that should be removed.
SecureMedia® Encryptonite ONE
Traffic Flow Management
In addition to managing the mediakeys in the client devices, the BSS also
controls the flow of traffic to the other servers.
SecureMedia® Encryptonite ONE
Authorization Interface
The SMS (Subscriber Management System) is a logical service within a
broadcast solution that manages the subscribers. In order to correctly allow
a client device to play a particular band, the SMS service, which is part of
the Middleware, must be given the client device’s entitlements.
The SMS communicates the band entitlements for each client device
through a simple HTTP interface that allows a client device to be authorized
or de-authorized for a band.
SecureMedia® Encryptonite ONE
Responsibilities of the Headend
At the head-end, the real-time encryption of the streams is performed and
the key change schedules are organised and managed. Two ES broadcast
components support these functions:
SecureMedia® Encryptonite ONE
Controlling the Encryption
The BD (Broadcast Director) controls and organizes the encryption of the
broadcast streams by managing the Broadcast Encryptors. The BD
maintains a record of all channels being encrypted by the BEs.
SecureMedia® Encryptonite ONE
Key Change
Typical key rotation timeline:
SecureMedia® Encryptonite ONE
Key Change
• Key changes occur at regular configurable intervals (for example every 24
hours) and each band may be configured with its own key change
schedule.
• The preparation for a key change is initiated once the previous key
change has been completed. This is undertaken well in advance of the
next key change to give each client device the time to acquire the
decryption key and initialize the decryptor.
• To prepare for the key change, the BD must request a new key pair from
the Key Vault, using the Key Generator task. On instruction from the BD,
the BEs request the encryption key from the Key Vault and prepare their
encryptors.
SecureMedia® Encryptonite ONE
Pay Per View
• In the Encryptonite System, PPV (Pay Per View) events are treated as a
variation of Broadcast. Therefore, authorization for a PPV event must be
pushed to the BSS from the Middleware.
• PPV events are broadcast live on a channel just like a normal broadcast
channel, although there is one significant difference – the MK used for
encryption/decryption purposes is a specific fixed PPV key.
• This key does not change throughout a specific PPV event
SecureMedia® Encryptonite ONE
Pay Per View
• The Business Support Server needs access to client device authorization
information for PPV Events. PPV events:
SecureMedia® Encryptonite ONE
Pay Per Block
PPB (Pay Per Block) describes the notion of providing subscriber access to
a particular band of programming for a set period of time
• The principle of operation is almost identical to PPV operation,
whereby authorization for a service must be pushed to the BSS from
the Middleware as and when the subscriber joins the service.
• The authorization time period is extended over a much longer period
and MKs will change as normal eg every 24hrs.
SecureMedia® Encryptonite ONE
Pause / Live
Trick play with live TV (pausing, picture search etc) is possible due to the
fact that the SM client retains the previous MK for each band.
Within the 24hr period between key changes, the client device can use the
previous key to access “paused” content, after the scheduled key change. Of
course, this is only possible up to 24hrs assuming this is the typical key
change schedule.
SecureMedia® Encryptonite ONE
Clear Broadcast
• Clear Broadcast events are set up in a similar way to PPV events, in
terms of their timing and duration.
• Introduced in ES2.1, clear broadcast allows the operator to choose a
channel and time period where the broadcast is not encrypted.
• Clear Broadcast could potentially be set as a recurring event.
SecureMedia® Encryptonite ONE
Broadcast Configuration Dependencies
During the installation and
configuration of the Encryptonite
System, it is important to consider
certain configuration
dependencies throughout the
system. Failure to do this could
result in disastrous consequences
for the broadcast services.
SecureMedia® Encryptonite ONE
Media Pass Admin Token and Key Supply Frequency
• If the MediaPass database was to run out of tokens, some subscribers
would not be provided with MediaPasses until the token level was
resupplied. The Reorder Level (the token level which, when the available
token count goes below this, will trigger a resupply request).
• Reorder Quantity (the total number of tokens supplied by the KMC in
multiples of 5000) must be set appropriately in order to avoid this. When
determining these settings, the total number of client devices must be
taken into account.
SecureMedia® Encryptonite ONE
Media Pass Admin Max Client Ping
With a 24 hour key change schedule, the maximum ping interval for the
Broadcast Client Ping would be set to 60 minutes by default.
Media Pass Admin KS Session Duration
• Sessions are an optional feature which exist between the Key Server and
the Client.
• KS sessions are designed to be a more efficient way of securing
communication, instead of the client using the normal Key Server public
key.
• It is recommended that Key Server Session Lifetime should last at least 3
times the broadcast key change schedule.
SecureMedia® Encryptonite ONE
Time Synchronization
With broadcast
services, the key
changes for a
particular band take
place in accordance
with a time based
key schedule,
making time
synchronization
between services
imperative.
SecureMedia® Encryptonite ONE
HTTP Live Streaming
HLS (HTTP Live Streaming) is an IETF (Internet Engineering Task Force)
draft by Apple called Pantos. An informational RFC (Request for Comment), it
is designed to work with standard web technology and servers, experiencing
a wide global deployment which can be attributed to its integration with Apple
IOS devices and Android platforms.
SecureMedia® Encryptonite ONE
HTTP Live Streaming
• HLS was designed to deliver multimedia streams to client devices with the
support of a suitable CDN (Content Delivery Network) such as the Internet.
• HLS supports the encryption of content, which is based on AES-128
encryption.
• Client devices can choose from a selection of versions of the same
content, all encoded at different bitrates and transported using HTTP.
• Content sources can be broadcast or VoD.
SecureMedia® Encryptonite ONE
HTTP Live Streaming: Encoding / Transcoding
•
A hardware or potentially software based encoder is responsible for taking
uncompressed video, or audio and video encoded at a higher rate, and encoding
it into a suitable format.
•
The codecs used are H.264 (also termed the AVC (Advanced Video Codec) used
in MPEG-4) for video and AAC (Advanced Audio Codec) for audio.
SecureMedia® Encryptonite ONE
HTTP Live Streaming: Stream Segmentation
•
•
•
•
•
The MPEG-2 TS is delivered to the Stream Segmenter
When a segment contains video, it is important to ensure that the segment contains at
least one I-Frame, in order for the decoder to paint a full picture on screen without
requiring previous segments.
Segments are saved as .ts files.
Each consecutive segment, termed a Media File, is given a unique URI (Uniform
Resource Identifier) which the client can then use in order gain access to the segment
from the web server.
The Stream Segmenter composes an index file, termed a Playlist File, which essentially
lists the URIs for each consecutive segment (the file is an extended M3U playlist file)
SecureMedia® Encryptonite ONE
HTTP Live Streaming: Playlist Elements
• EXT-X-MEDIA_SEQUENCE – this provides the starting sequence number of the
first media segment URI in the Playlist File. Subsequent segments will count
upwards from this number in increments of 1. This parameter is particularly
important in broadcast scenarios, since it allows the client to make sure the most
recent content is being downloaded.
• EXT-X_TARGETDURATION – this is the maximum media segment duration, in
seconds.
•
• EXTINF – this tag contains the URI of a segment, preceded with the segment’s
duration.
SecureMedia® Encryptonite ONE
Distribution Side Activity
The distribution system is typically a web server or a web caching system that delivers
the media files and index files to the client over HTTP. No custom server modules are
required to deliver the content and the web server requires minimal configuration.
Tuning time-to-live values for .M3U8 files may also be necessary to achieve desired
caching behavior for downstream web caches, as these files are frequently overwritten
during live broadcasts, and the latest version should be downloaded for each request.
SecureMedia® Encryptonite ONE
Client Side Activity
In order to view a particular piece of
content, whether it’s broadcast or VoD,
the client must be provided with the
URI of the Playlist File.
• The client will request the Playlist
File from the web server and begin
to download the media files, in
accordance with their unique URI.
• Media files are accessed in the
order in which they are listed in the
Playlist File.
• Once the client has enough content
cached, playout of the stream to the
end user starts.
SecureMedia® Encryptonite ONE
Adaptive Streaming
One of the most important features of
HLS, particularly for mobile clients, is
the use of Adaptive Streaming.
This involves the use of variant
streams, where a client can access
numerous variants of the same
program.
If a mobile user experiences a
degradation in their available
bandwidth, they can seamlessly switch
to a lower data rate variant of the same
program
SecureMedia® Encryptonite ONE
Adaptive Streaming
The Playlist File to the client contains the
URIs of all the playlist files which make up
the overall content offering.
• The variant Playlist file contains
the EXT-X-STREAM-INF tag,
which provides:
• The program ID, which must be
common to all variants of the
stream.
• The bandwidth required for the
stream, which can be used by the
client to determine which Playlist
File it should access.
• The URI of the playlist file.
SecureMedia® Encryptonite ONE
HLS+
•
•
•
To protect the HLS content, the HLS RFC accommodates the use of encryption
techniques. To manage the encryption/decryption keys
The SecureMedia HLS+ extensions seamlessly plug into the Encryptonite System,
leveraging on the rights management framework already provided.
One Encryptonite System can concurrently support both HLS and normal IPTV
deployments.
SecureMedia® Encryptonite ONE
HLS+ Process Flow
SecureMedia® Encryptonite ONE
HLS+ Components
Chunker - the chunking (or segmenting) of content is done either by the
SecureMedia smchunker or by third party software/hardware which supports the
KVHLS protocol.
kvhls – the plugin module to the Encryptonite System to enable HLS support. It
generates and protects the control words used for chunk encryption and
generates necessary meta-data so that the client can identify which key to use
for decryption of protected control words.
HTTP Server – serves both the content segments (media URIs) and the Playlist
(or index) files needed by the HLS players to identify which bit rates and
segments are available.
HLS Player- On the client device, the HLS front end is responsible for selecting
which segments to download, playback the segments and to communicate with
the SecureMedia client to get access to the decrypted control words used to
decrypt the actual chunk.
SecureMedia® Encryptonite ONE
HLS+ Operation
The Encryptonite System integrates with HLS in an HLS+ deployment:
SecureMedia® Encryptonite ONE
HLS+ EXT-X-KEY
In HLS, to decrypt the
segment, the client device
must acquire the control
word.
This is achieved with an
entry in the Playlist File
which determines the URI
at which the control word
can be accessed, termed
the EXT-X-KEY tag.
SecureMedia® Encryptonite ONE
HLS+ Control Word
With HLS+, the control word in the EXT-X-KEY tag entry is actually
encrypted using a Media Key from the Encryptonite System and
concatenated with meta-data needed by the client to identify which
decryption key is used. This forms a “protected control word”, which is
base-64 encoded, and it is this that is included in the EXT-X-KEY tag URI,
rather than the control word being in the clear.
SecureMedia® Encryptonite ONE
HLS+ Control Word
• For HLS and live content, the control word is protected using a
Broadcast Media Key from the Encryptonite System.
• As with normal IPTV broadcast the Broadcast Key Set is regularly
changed (normally every 24 hours). Authorization is done by giving the
client access to the Band of the Broadcast Media Key ID.
• Other business models like Pause/Live and PVR are also supported.
• For HLS and VOD content, the control word is protected using a VOD
Media Key from the Encryptonite System.
• Authorization is achieved by giving the client access to the Media Key
ID or the External Reference of the VOD asset.
SecureMedia® Encryptonite ONE
HLS+ Client Side Operation
• The client (which includes the
HLS frontend and SMClient)
starts by downloading the
master manifest file (also
termed the variant Playlist File)
for a particular program stream.
• Based on available bandwidth,
the client continues by
choosing the most suitable
media manifest file (Playlist
File) and starts downloading
the chunks.
SecureMedia® Encryptonite ONE
VOD Services: Detailed Architecture
SecureMedia® Encryptonite ONE
VOD Services: Detailed Architecture
SecureMedia® Encryptonite ONE
VOD Encryption Process
SecureMedia® Encryptonite ONE
VOD Encryption Process
Step 1 - The Encryptonite Producer requests a new MK (Media Key) from
the KVES (Key Vault Encryptor Services) for each media file that is to be
encrypted. This communication uses KVSS and can be performed over the
public Internet, for example between an encoding house or head end and a
network operations center hosting a Key Vault.
SecureMedia® Encryptonite ONE
VOD Encryption Process
Step 3 - KVES creates a key pair, returning the Media Encryption Key to the
Producer and saving the Media Decryption Key into the Key Vault with a
status of pending.
Step 4 - The producer uses MK to encrypt the media, after which time it is
discarded. The Media Player uses the corresponding MK (obtained from the
Key Server) when decrypting the media.
Step 5 - The Encryptonite Producer encrypts the media file using the Media
Key and saves the encrypted media to disk.
SecureMedia® Encryptonite ONE
VOD Encryption Process
As well as creating the encrypted
VoD asset, the Encryptor
Producer must also generate an
XML based .sma (SecureMedia
Asset) file, which is delivered to
the Middleware as part of the
encrypted asset ingestion
process. The .sma file contains
information about the encrypted
media including the Media Key ID,
which is used in the authorization
process.
SecureMedia® Encryptonite ONE
Commit Media Key
The Encryptonite Producer uses
KVES to commit the Media Key in
the Key Vault. This changes the
key’s status from pending to
active, making the key available
to the MediaPass Server System.
If the encryption process is
unsuccessful the Producer will
instead use KVES to remove the
Media Key from the Key Vault.
SecureMedia® Encryptonite ONE
Encrypted Media Delivery
The encrypted media is delivered
from the Encryptonite Producer
platform to the Media Server. This
delivery is likely to occur through
already existing channels.
The Media Server could stream
the media to the client or
alternatively, make the encrypted
media available for download.
SecureMedia® Encryptonite ONE
Client Play Request
• The Client play request involves the client gaining access to the information that it
needs to be able to play the media.
• This information includes the Media Key (acquired using the MediaPass) and the
encrypted Media.
• The client play request can be broken into the following parts:
• The SecureMedia Encryptonite System Decryptor SDK is available for
use in Media Player applications and provides MediaPass Processing,
Key Management and Decryption functionality.
SecureMedia® Encryptonite ONE
MediaPass Database Update
The MediaPass Database needs to keep an updated list of available media files as
well as a suitable inventory of Tokens.
• The Content Update process is used to ensure that the MediaPass
Server System knows what media is available
• The Token Replenish process is used to restock the MediaPass
Database with the tokens that are needed to create MediaPasses.
SecureMedia® Encryptonite ONE
MediaPass Delivery
• The client browser or media player will request a MediaPass from the
Encryptonite System, using a secure authenticated connection (eg ESAM or
SSL).
• Once the Encryptonite System has validated that the Client is entitled to access
to the selected media (authorization should be provided by the middleware), it
delivers a MediaPass to the Client
• As with registration there are two ways of doing VOD authorization - either push
or pull (or both). The authorization contains the Media Key ID (unique identifier of
VOD asset) and the SN (unique identifier of client device).
SecureMedia® Encryptonite ONE
Push VOD Authorization
• In Push VoD authorisation, the Business
Server System is pre-loaded with the
relevant authorization for VoD assets,
as defined by sn and the Media Key ID.
• The on-demand service request is
triggered by the Middleware generating
the request_service API.
• On receipt of the On-Demand Request,
the ESAM will contact the Business
Server System to verify that
authorization exists.
• Assuming it is authorized, a suitable
MediaPass will then be delivered to the
client.
SecureMedia® Encryptonite ONE
Pull VOD Authorization
Pull VoD authorization works in a
similar fashion to Push, with the
exception that the ODAQ (On Demand
Authorization) protocol is used to allow
the Encryptonite System to explicitly
request authorization from the
Middleware.
SecureMedia® Encryptonite ONE
MK Delivery
• Having received the MediaPass, the Client software requests the
delivery of the Media Key from the Key Server and includes the Token
within this request. This entire process is transparent to the end user.
• The Key Server then requests the Media Key from the Key Vault. The
Key Vault checks that the Token is valid and if so, returns the Media
Key to the Key Server and then records the fact that the Token has
been used.
• The Key Server sends the Media Key, uniquely encrypted, back to the
Client in the response to the initial request.
• Both the key request and response are secured using SecureMedia’s
Encryptonite technology.
SecureMedia® Encryptonite ONE
Streaming
• In the case of streaming media, the Client software requests the
media from the Media Server.
• The Client software decrypts the encrypted media stream (using the
Media Key) and then renders the stream for display.
SecureMedia® Encryptonite ONE
Download
• In the case of downloaded media, the media is typically available
locally on the Client and has been selected at the start of the Client
Play Request.
• The Client software decrypts the encrypted media file (using the
Media Key) and then renders it for display.
SecureMedia® Encryptonite ONE
Encryptonite Deployment Considerations
When deploying the Encryptonite System within a production environment,
several factors must be considered before system integration takes place.
SecureMedia® Encryptonite ONE
Hardware Requirements
Although hardware capabilities are constantly changing, this is an example of a
Bill of Materials (including hardware specification) for deploying a High
Availability Encryptonite System.
SecureMedia® Encryptonite ONE
High Availability
In order to achieve high availability and remove any single points of failure from
the network, system redundancy is an essential feature of any deployment.
Redundancy can be introduced into several elements of the Encryptonite System:
SecureMedia® Encryptonite ONE
General Server Redundancy
In terms of the hardware upon which the Encryptonite System is deployed, there’s
a number of general measures that can be taken in order to protect against failure:
SecureMedia® Encryptonite ONE
Broadcast Encryptor Redundancy
• Broadcast encryptors can be
configured in a fully redundant
setup, running on 2 or more
servers.
• The redundant (passive)
encryptor is actually fully
operational, processing exactly
the same content as the
“active” Encryptor at exactly
the same time.
• The only difference between
the two is that the “passive”
Encryptor is not delivering its
output to the network. Instead,
it simply listens for activity from
the “active”
SecureMedia® Encryptonite ONE
Broadcast Encryptor Redundancy
• For a redundant system,
both encryptors must read
from the same input and
both must continuously
encrypt the live streams.
• If at any point the active fails,
the passive encryptor will
automatically begin
multicasting/unicasting its
encrypted content.
SecureMedia® Encryptonite ONE
Application Server Redundancy
• The request to the servers
comes through a load
balancer, which passes it on
to one of the web application
servers.
• All Application Servers are
active.
• The web application servers
are configured to connect to
the same database instance.
SecureMedia® Encryptonite ONE
Database Redundancy
Database redundancy can come in a number of options:
SecureMedia® Encryptonite ONE
ES High Availability Options
Four options exist with the Encryptonite System in relation to High
Availability deployments:
SecureMedia® Encryptonite ONE
Single Server
The entire SecureMedia
Encryptonite System, or
parts of it, with the
exception of the
broadcast encryptors
which should run on a
separate server in any
production environment,
can be placed on a single
server.
SecureMedia® Encryptonite ONE
Minimal Setup
For a minimal high
availability production
setup four servers can be
used. Two servers for the
broadcast streams
running in redundant
mode and two servers for
the applications and
database.
SecureMedia® Encryptonite ONE
Standard HA Setup
For a standard High
Availability Setup there
are six servers; two for
the broadcast streams,
two for the web
applications and two for
the databases.
The database can be
setup using any of the
database redundancy
modes.
SecureMedia® Encryptonite ONE
Maximum HA Setup
• The maximum high
availability solution means
distributing servers
between different
geographical sites to
handle site disasters and
failures.
• The replication between
the sites is achieved using
Oracle Dataguard Or
GoldenGate.
• The individual sites can
also implement different
High Availability solutions
SecureMedia® Encryptonite ONE
HA Compartive Analysis
SecureMedia® Encryptonite ONE
Upsteam / Downstream Key Vaults
• For key distribution, the central
Encryptonite system will be
considered the master KSS (Key
Server System) and each site that
requires a copy of the media keys
will be running their own slave KSS,
with their respective Key Vaults.
• Providing that the system is
configured correctly, slave Key
Vaults will automatically be provided
with the latest keys.
SecureMedia® Encryptonite ONE
Integration Concepts
Point of Integration:
Server-side middleware –
• Authorizes access using flexible APIs that include
support for pay-per-view, broadcast, time-shifted-TV,
for long-term and short term rights.
• Provides consistent support for Broadcast and VoD
assets within the same set of APIs.
• Validates registration of client devices to the system
SecureMedia® Encryptonite ONE
Integration Concepts
Point of Integration:
The client –
• It must be efficient for the encrypted media stream
to be decrypted immediately before use by the
media player
• The middleware portal and other software must
communicate with the servers, to request play of a
VOD asset, to register the client device onto the
network, to send custom messages to the
middleware
SecureMedia® Encryptonite ONE
Middleware Integration
Depending on the business models in use by the provider, not all of
these integration points need to necessarily be supported:
SecureMedia® Encryptonite ONE
Client Integration Points
SecureMedia® Encryptonite ONE
Client Integration Points
SecureMedia® Encryptonite ONE
Client Integration Points
Key Client Integration Points Include:
smdaemon - this is the SecureMedia “daemon” or
“service” which controls interactions with middleware,
DRM servers and key management systems in servers
and decryption libraries. The smdaemon also controls
access to local persistent storage.
smplugin - this is the SecureMedia decryption library
which must be integrated with the player/video
demultiplexing and decoding software.
smIPC - this is the SecureMedia IPC (Inter Process
Communication) which connects the smdaemon and the
smplugin.
SecureMedia® Encryptonite ONE
Troubleshooting
There are several elements of the Encryptonite system which require
monitoring in order to ensure system resources are not being stretched:
SecureMedia® Encryptonite ONE
Disk Usage
• Application Servers.
• Database Servers.
• Broadcast Encryptor Servers.
• VoD Encryptor Servers.
In each of these cases, logs are available which can assist network
operators. Also, in Linux, disk usage can be checked with the df
command eg # df -h.
SecureMedia® Encryptonite ONE
Memory Usage
• It is prudent to record the baseline memory usage for all servers
under normal operating conditions.
• Both Free Memory and Swap Used should be regularly checked and
measured against the recorded baseline values.
• This can be achieved using the free command in Linux eg # free.
SecureMedia® Encryptonite ONE
SNMP
The Encryptonite
System contains a
SMMA (Secure Media
Master Agent) deployed
on every Application
Server, which gathers
system information from
internal communication
with the various ES
elements and reports to
a suitable NMS
(Network Management
System) via SNMP.
SecureMedia® Encryptonite ONE
Logs
Logs accessible across the end to end Encryptonite System:
SecureMedia® Encryptonite ONE
Oracle Logs
Oracle log locations hold the Listener and Alert logs:
SecureMedia® Encryptonite ONE
Resin Logs
Resin logs are stored in the log and logs directories under the Resin
home directories eg: /usr/resin-8081/resin-2.1.16/logs/error.log
SecureMedia® Encryptonite ONE
Application Logs
Application logs are stored in the logs directory under the Resin home
directory.
The filenames used are of the form {application}-{type}.log where
{application} is the name of the service (eg kmc, bss) and {type} is one of
alert, audit, error or debug.
SecureMedia® Encryptonite ONE
Application Database Logs
• Limited logging information is stored in the application database.
• This log information is logged by the database Stored Procedure code.
• The logging level is configured in the Params -> Logging in the
corresponding administration program.
• It is recommended that database logging be set to Error level during
normal system operation.
SecureMedia® Encryptonite ONE
Broadcast Encryptor Logs
By default the Broadcast Encryptor logs are written to:
/var/opt/securemedia/log
SecureMedia® Encryptonite ONE
VoD Encryptor Logs
By default the VOD Encryptor log is written to stdout :
SecureMedia® Encryptonite ONE
Client Device Logs
By default the client device log is written to stdout. The process to access
this log data is client device dependent and may involve connecting a serial
debug cable or telneting to the box and manually running the client.
SecureMedia® Encryptonite ONE
Random Server Logs
By default the Random Server logs are written to:
/var/opt/securemedia/log.
SecureMedia® Encryptonite ONE
SecureMedia Utilities
Two SecureMedia utility tools are available to assist with system debugging:
smudp – smudp is a tool for capturing and streaming UDP streams to
and from files. Smudp is usually installed under /opt/securemedia/bin
SecureMedia® Encryptonite ONE
SecureMedia Utilities
smm2util - The utility tool smm2util is used to inspect an MPEG2
transport stream, either from file or from a network UDP stream. smm2util
is usually installed under /opt/securemedia/bin
SecureMedia® Encryptonite ONE
3rd Party Utilities
In addition to the SecureMedia utilities, a wide selection of additional
troubleshooting tools are available:
Thank you!
Notes / Actions
Recommendation
Action/Strategy/Plan
Implications /
Desired Results
Timeline
Recommended Owner